# 公司财务系统后续待办

更新时间：2026-06-08T15:28:40+0800

## 当前优先级

### P0：先用报销审批模板测试飞书审批接入闭环

先不要全面补强合同/付款/应收应付模块，优先用已能支持的报销模块做真实审批测试。

测试范围：

1. 选择一个报销模板作为首测模板：
   - 点绛报销专用：`050F481E-BB96-46CD-BEEA-2E57DBEB291E`
   - 云汉寻真报销专用：`D3F1A466-5843-4492-94E5-B19C5A0A0625`
   - 万物有灵公共账报销专用：`B69B2F92-6BDF-4A44-93C5-616CA41AF9C8`
   - 万物有灵相关项目组报销专用：`81CF84F6-45D1-43E3-A867-019864D25C3F`
2. 从现有 `intake_draft` 生成飞书审批发起 payload。
3. 发起真实飞书审批实例并回写 `intake_draft.approval_instance_id`。
4. 审批通过/驳回后，测试回调或轮询状态同步。
5. 审批通过后再 commit 到：
   - `reimbursement_order`
   - `reimbursement_item`
   - `invoice`
   - `invoice_link`
   - `attachment`
   - `audit_log`
6. 实际付款仍单独记录为：
   - `fund_transaction`
   - `reimbursement_payment`

验收标准：

- 能从机器人/接口创建一条报销草稿。
- 能用报销模板发起飞书审批。
- 能拿到并保存审批实例 ID。
- 审批状态能同步回系统。
- 通过后能正式生成报销单，驳回/撤回不会生成正式报销单。
- 查询数据库能看到完整记录链路。

## 后续补强，暂缓

### P1：审批通用表

后续补：

- `approval_template`
- `approval_instance`
- `approval_event`

目的：替代仅在 `intake_draft.approval_instance_id` 上记录审批实例的轻量做法，支持多模板、多实例、回调去重、审批历史和审计。

### P2：合同模块

后续补：

- `contract`
- `contract_party`
- `contract_attachment`
- `contract_obligation`

目的：承接合同申请类模板，形成正式合同台账，而不是只把合同审批内容存在 `intake_draft.normalized_payload` JSON 里。

### P3：付款 / 应收应付 / 核销模块

后续补：

- `payable`
- `payment_request`
- `receivable`
- `settlement_allocation`
- 必要时增加 `internal_advance_or_loan`

目的：把付款申请、应收应付、实际资金流水、个人垫付/借款/还款分开建模，避免审批通过后直接粗暴生成一条 `fund_transaction`。

## 当前判断

当前数据库一期对报销闭环支持最好，适合先作为飞书审批联调样板。合同和付款审批模板已经记录并能通过 OpenAPI 读取，但暂不作为第一批正式落库对象。