# 一期业务事实模型与基础表结构草案

整理时间：2026-06-03 20:35:35 CST  
依据：用户本轮口述、旧系统复盘、《用户新想法记录》《未闭环事实与重构清单》

## 0. 当前判断：可以先形成一版一期闭环模型

在现在的信息基础上，**可以先形成一版一期可闭环的底层业务事实模型**。

这个模型先不追求完整计算利润、个人账、老板看板，而是先把底层事实表结构盘清楚：

1. 主体可配置，不写死公司名称；
2. 项目必须归属某个主体；
3. 没有明确项目归属的费用/报销，归到该主体的“基础经营/公共项目”；
4. 收入拆成：订单/合同/应收 与 真实资金流水；
5. 支出拆成：应付/费用义务 与 真实资金流水；
6. 报销拆成：报销单、报销明细、发票状态、付款核销；
7. 个人账不是基础表，而是从无票报销、个人垫付、个人注资、个人代付等来源派生计算；
8. 报表/导出作为视图和计算结果，不反向决定基础事实表。

> 核心原则：**事实层稳定，计算层可扩展，导出层可变化。**

---

# 1. 一期总模型

## 1.1 三层结构

```text
事实层 Fact Layer
- 主体、项目、订单/合同、应收、应付、报销、发票、资金账户、真实资金流水、附件、状态、来源

计算层 Calculation Layer
- 公司现金余额、项目收入/支出、应收实收差额、应付实付差额、个人账派生余额、公共经营成本、月度快照

展示/导出层 Report Layer
- 财务明细表、个人对账单、老板总览、旧 Excel 兼容导出
```

一期重点只做 **事实层 + 基础状态 + 最小派生口径**。

## 1.2 最小闭环链路

### A. 收入闭环

```text
主体表
→ 项目表
→ 订单/合同表
→ 应收/收入计划表
→ 资金流水主表
→ 应收-资金流水核销表
```

### B. 支出闭环

```text
主体表
→ 项目表，或主体默认“基础经营/公共项目”
→ 应付/费用义务表
→ 资金流水主表
→ 应付-资金流水核销表
→ 发票/附件
```

### C. 报销闭环

```text
报销单
→ 报销明细：必须挂项目；没有业务项目则挂主体默认基础经营项目
→ 发票状态：有票 / 无票 / 待补票
→ 报销付款：关联真实资金流水，确认实际从哪个资金账户付给谁
→ 报销核销
→ 个人账派生视图
```

---

# 2. 基础配置表

## 2.1 主体类型表 `subject_type`

用于配置主体类型，不在代码里写死。

| 字段 | 说明 |
|---|---|
| `id` | 主键 |
| `code` | 类型代码，如 `company`、`sole_prop`、`person`、`public_group`、`project_group`、`other` |
| `name` | 类型名称，如公司、个体户、个人、公共组、项目组、其他 |
| `can_own_project` | 是否可作为项目归属主体 |
| `can_receive_payment` | 是否可作为收款主体 |
| `can_make_payment` | 是否可作为付款主体 |
| `need_tax_info` | 是否需要税务/发票信息 |
| `is_active` | 是否启用 |
| `sort_order` | 排序 |

说明：

- 公司、个体户通常可以作为项目归属主体和收付款主体；
- 个人通常用于垫付、注资、收款人、申请人等；
- 公共组如果未来需要，也可以作为类型，但一期更建议“公共经营”落成项目，而不是独立全局账户。

## 2.2 状态字典表 `status_definition`

统一维护各业务对象状态。

| 字段 | 说明 |
|---|---|
| `id` | 主键 |
| `object_type` | 对象类型：project/order/receivable/payable/reimbursement/cash_flow/invoice 等 |
| `code` | 状态代码 |
| `name` | 状态名称 |
| `is_terminal` | 是否终态 |
| `is_effective` | 是否计入计算口径 |
| `sort_order` | 排序 |
| `remark` | 说明 |

这样后续状态可以扩展，但不频繁改基础表结构。

## 2.3 来源分类表 `source_category`

用于标记每一笔业务事实来源。

| 字段 | 说明 |
|---|---|
| `id` | 主键 |
| `code` | 来源代码 |
| `name` | 来源名称 |
| `direction` | 对个人账/公司账的默认方向：in/out/neutral/derived |
| `affects_person_ledger` | 是否可能进入个人账派生 |
| `affects_project_cost` | 是否影响项目成本 |
| `affects_company_cash` | 是否影响公司现金 |
| `remark` | 说明 |

一期可先配置这些来源：

| code | 名称 | 说明 |
|---|---|---|
| `project_income` | 项目收入 | 项目/订单产生收入 |
| `cash_inflow` | 实际收款 | 钱实际进入某主体/账户 |
| `expense_obligation` | 支出/应付 | 已形成费用或付款义务 |
| `cash_outflow` | 实际付款 | 钱实际流出某主体/账户 |
| `reimbursement_invoice` | 有票报销 | 有发票的个人垫付报销 |
| `reimbursement_no_invoice` | 无票报销 | 无票报销，可能进入个人账派生 |
| `personal_injection` | 个人注资 | 个人向公司或主体注入资金 |
| `personal_advance` | 个人代付/垫付 | 个人替公司或项目付款 |
| `company_repay_person` | 公司还个人 | 公司向个人还款或报销付款 |
| `internal_adjustment` | 内部调整 | 口径修正或历史调整 |
| `reversal` | 冲销 | 冲销错误或撤销记录 |

## 2.4 费用分类表 `expense_category`

费用分类单独配置，避免写死。

示例：项目成本、供应商采购、税费、工资/人工、办公、AI工具、物流、差旅、打样、报销、公共经营、其他。

---

# 3. 主体与账户基础表

## 3.1 主体表 `subject`

这是一期最重要的基础表之一。不要叫死“公司表”，因为公司主体不一定等于收付款主体。

| 字段 | 说明 |
|---|---|
| `id` | 主键 |
| `name` | 主体名称 |
| `short_name` | 简称 |
| `subject_type_id` | 主体类型，引用 `subject_type` |
| `tax_name` | 开票/税务名称，可空 |
| `tax_no` | 税号，可空 |
| `bank_info` | 银行信息，可空或另表 |
| `is_active` | 是否启用 |
| `remark` | 备注 |
| `created_at` / `updated_at` | 时间 |

关键用法：

- 项目归属主体引用它；
- 订单/合同签约主体引用它；
- 实际收款主体引用它；
- 实际付款主体引用它；
- 个人注资的付款人也可以是类型为“个人”的主体。

## 3.2 资金账户表 `cash_account`

记录钱实际在哪里。

| 字段 | 说明 |
|---|---|
| `id` | 主键 |
| `owner_subject_id` | 账户所属主体，引用 `subject` |
| `name` | 账户名称 |
| `account_type` | 银行卡、公户、支付宝、微信、现金、其他 |
| `account_no_masked` | 脱敏账号，可空 |
| `opening_balance` | 期初余额 |
| `actual_balance` | 最近一次人工核对余额，可空 |
| `is_active` | 是否启用 |
| `remark` | 备注 |

说明：

- 资金账户所属主体和项目归属主体可以不同；
- 真实资金流水表要引用 `cash_account_id`，从而知道钱进出哪个账户。

## 3.3 真实资金流水主表 `fund_transaction`

这是对本版模型的重要修正：**真实发生的每一次收款、付款、退款、转账，都先进入资金流水主表**。

`receivable`、`payable`、`reimbursement_order` 等业务表不再自己维护“实收/实付事实”，而是通过关联表引用资金流水，再由金额加和得到已收、已付、未收、未付。

| 字段 | 说明 |
|---|---|
| `id` | 主键，每一笔真实资金进出一条记录 |
| `transaction_no` | 流水编号，可系统生成 |
| `direction` | `in` 收入 / `out` 支出 / `transfer` 内部转账 / `refund` 退款或冲销 |
| `amount` | 资金流水金额，统一用正数，方向由 `direction` 表达 |
| `occurred_at` | 实际发生日期 |
| `payer_subject_id` | 付款主体，可空 |
| `payer_cash_account_id` | 付款账户，可空；向外付款时必填 |
| `receiver_subject_id` | 收款主体，可空 |
| `receiver_cash_account_id` | 收款账户，可空；向内收款时必填 |
| `counterparty_subject_id` | 外部/对方主体，可按场景冗余 |
| `source_category_id` | 来源分类，如项目收款、实际付款、个人注资、公司还个人等 |
| `status` | pending / confirmed / allocated / reconciled / reversed |
| `proof_attachment_id` | 付款/收款凭证，可空 |
| `original_transaction_id` | 退款、冲销、调整时引用原资金流水，可空 |
| `remark` | 备注 |
| `created_at` / `updated_at` | 时间 |

关键规则：

1. 一笔真实收款、付款、退款、冲销，就是一条 `fund_transaction`。
2. `fund_transaction` 是资金事实主账，不直接等同于项目收入或项目成本。
3. 一笔资金流水可以通过关联表分摊到多个应收、多个应付、多个报销或多个项目。
4. 一个应收、应付或报销，也可以关联多笔资金流水。
5. 后续如果接银行流水、支付宝流水、微信流水，也是先进入这张表，再做业务归属。

一期建议把原来的 `cash_inflow` / `cash_outflow` 理解为：

```text
cash_inflow_view  = fund_transaction where direction = 'in'
cash_outflow_view = fund_transaction where direction = 'out'
```

也就是说，`cash_inflow` 和 `cash_outflow` 可以作为视图或前端筛选，不一定作为两张原始事实表。

---

# 4. 项目与订单/合同

## 4.1 项目表 `project`

项目是收入、支出、报销最终归属的核心对象。

| 字段 | 说明 |
|---|---|
| `id` | 主键 |
| `owner_subject_id` | 项目归属主体，引用 `subject` |
| `name` | 项目名称 |
| `project_code` | 项目编号，可自动生成 |
| `project_type` | `business` 业务项目 / `base_operation` 基础经营公共项目 / `internal` 内部项目 |
| `status` | 项目状态 |
| `is_default_base_operation` | 是否为该主体默认基础经营/公共项目 |
| `parent_project_id` | 承接/来源项目，可空，二期项目迁移时用 |
| `start_date` | 开始日期 |
| `end_date` | 结束日期，可空 |
| `remark` | 备注 |
| `created_at` / `updated_at` | 时间 |

关键规则：

1. 每个项目必须有 `owner_subject_id`。
2. 每个可经营主体可以有一个默认 `base_operation` 项目。
3. 报销/支出如果无法准确归属业务项目，就归到该主体默认基础经营项目。
4. 项目跨主体迁移一期不做直接迁移；未来用 `parent_project_id` 或备注表达承接关系。

## 4.2 订单/合同表 `commercial_order`

一期建议用一个统一表承接“订单/合同”，避免一开始拆得太碎。

| 字段 | 说明 |
|---|---|
| `id` | 主键 |
| `project_id` | 所属项目 |
| `owner_subject_id` | 归属主体，通常从项目带出，冗余便于查询 |
| `order_type` | 合同 / 订单 / 口头合作 / 其他 |
| `order_no` | 合同号/订单号 |
| `name` | 订单/合同名称 |
| `customer_subject_id` | 客户主体，可引用 `subject`，也可为空 |
| `signing_subject_id` | 签约主体，引用 `subject` |
| `amount_total` | 合同/订单总金额 |
| `currency` | 币种，默认 CNY |
| `status` | 状态 |
| `signed_at` | 签约日期 |
| `remark` | 备注 |

说明：

- 一个项目可以有多个订单/合同；
- 一期暂不处理一个合同拆多个项目的复杂情况，如遇到可以拆成多个 order 或用备注处理。

---

# 5. 公司流入：应收与实收

## 5.1 应收/收入计划表 `receivable`

记录“应该收多少钱”，不等于已经到账。

| 字段 | 说明 |
|---|---|
| `id` | 主键 |
| `project_id` | 所属项目 |
| `commercial_order_id` | 所属订单/合同，可空 |
| `owner_subject_id` | 项目归属主体，冗余便于查 |
| `expected_receiver_subject_id` | 应收主体，引用 `subject` |
| `name` | 应收名称，如首付款、尾款、一期款 |
| `amount` | 应收金额 |
| `expected_date` | 预计收款日期 |
| `status` | planned / confirmed / partially_received / received / overdue / void |
| `source_category_id` | 来源分类，一般为项目收入 |
| `remark` | 备注 |

一期建议状态：

| 状态 | 含义 |
|---|---|
| `planned` | 计划中/草稿 |
| `confirmed` | 已确认应收 |
| `partially_received` | 部分到账 |
| `received` | 已全部到账 |
| `overdue` | 逾期未收 |
| `void` | 作废 |

## 5.2 实际收款视图 `cash_inflow_view`

实际收款不再建议作为独立原始表，而是 `fund_transaction` 中 `direction = in` 的资金流水视图。

```text
cash_inflow_view = fund_transaction where direction = 'in'
```

也就是说：

- 钱实际进来时，先生成一条 `fund_transaction`；
- 这条资金流水可以直接关联项目/订单，也可以先保持待分配；
- 真正算某个应收“已收多少”，通过 `receivable_settlement` 加和得到。

## 5.3 应收实收核销表 `receivable_settlement`

用于把实际收款分配到应收上。

| 字段 | 说明 |
|---|---|
| `id` | 主键 |
| `receivable_id` | 应收记录 |
| `fund_transaction_id` | 真实资金流水记录，通常为 `direction = in` |
| `amount` | 本次核销金额 |
| `settled_at` | 核销日期 |
| `remark` | 备注 |

为什么需要这张表：

- 一笔资金收款可能对应多个应收；
- 一个应收可能分多次到账；
- 这样分期收入、部分付款、合并到账都能处理。

---

# 6. 公司流出：应付与实付

## 6.1 应付/费用义务表 `payable`

记录“已经形成费用或付款义务”，不等于已经付款。

| 字段 | 说明 |
|---|---|
| `id` | 主键 |
| `project_id` | 费用归属项目；无明确项目时填主体默认基础经营项目 |
| `owner_subject_id` | 项目归属主体，冗余便于查 |
| `paying_subject_id` | 预计付款主体，可空 |
| `counterparty_subject_id` | 供应商/收款对象，可空 |
| `expense_category_id` | 费用分类 |
| `source_category_id` | 来源分类，如支出/应付、报销转应付等 |
| `name` | 费用名称 |
| `amount` | 应付金额 |
| `incurred_at` | 费用发生/签约日期 |
| `due_date` | 预计付款日期，可空 |
| `status` | draft / confirmed / pending_payment / partially_paid / paid / void |
| `invoice_status` | no_invoice / pending_invoice / invoiced / verified 等 |
| `remark` | 备注 |

一期建议状态：

| 状态 | 含义 |
|---|---|
| `draft` | 草稿 |
| `confirmed` | 已确认费用/应付 |
| `pending_payment` | 待付款 |
| `partially_paid` | 部分付款 |
| `paid` | 已付清 |
| `void` | 作废 |

## 6.2 实际付款视图 `cash_outflow_view`

实际付款不再建议作为独立原始表，而是 `fund_transaction` 中 `direction = out` 的资金流水视图。

```text
cash_outflow_view = fund_transaction where direction = 'out'
```

也就是说：

- 钱实际付出去时，先生成一条 `fund_transaction`；
- 这条资金流水可以关联供应商、个人、项目、报销单，也可以先保持待分配；
- 真正算某个应付“已付多少”，通过 `payable_settlement` 加和得到。

## 6.3 应付实付核销表 `payable_settlement`

用于把实际付款分配到应付上。

| 字段 | 说明 |
|---|---|
| `id` | 主键 |
| `payable_id` | 应付记录 |
| `fund_transaction_id` | 真实资金流水记录，通常为 `direction = out` |
| `amount` | 本次核销金额 |
| `settled_at` | 核销日期 |
| `remark` | 备注 |

---

# 7. 报销模型

## 7.1 报销单主表 `reimbursement_order`

记录一次报销申请。

| 字段 | 说明 |
|---|---|
| `id` | 主键 |
| `order_no` | 报销单号 |
| `applicant_subject_id` | 申请人，引用 `subject`，通常为个人 |
| `payee_subject_id` | 实际收款人，通常为个人，可与申请人不同 |
| `default_owner_subject_id` | 默认归属主体，用于无项目时找基础经营项目 |
| `status` | draft / submitted / approved / rejected / pending_payment / partially_paid / paid / void |
| `total_amount` | 报销总额，可由明细汇总 |
| `submitted_at` | 提交时间 |
| `approved_at` | 审批通过时间 |
| `remark` | 备注 |

一期建议状态：

| 状态 | 含义 |
|---|---|
| `draft` | 草稿 |
| `submitted` | 已提交 |
| `approved` | 已通过 |
| `rejected` | 已驳回 |
| `pending_payment` | 待付款 |
| `partially_paid` | 部分付款 |
| `paid` | 已付款/已结清 |
| `void` | 作废 |

## 7.2 报销明细表 `reimbursement_item`

每条明细必须能归属到项目。

| 字段 | 说明 |
|---|---|
| `id` | 主键 |
| `reimbursement_order_id` | 报销单 |
| `project_id` | 归属项目；无明确业务项目时填主体默认基础经营项目 |
| `owner_subject_id` | 项目归属主体，冗余便于查 |
| `expense_category_id` | 费用分类 |
| `source_category_id` | 有票报销 / 无票报销 / 个人垫付等 |
| `advancer_subject_id` | 垫付人，通常为个人 |
| `amount` | 明细金额 |
| `occurred_at` | 发生日期 |
| `invoice_status` | invoiced / no_invoice / pending_invoice |
| `description` | 说明 |
| `payable_id` | 可选：生成或关联的应付记录 |
| `personal_ledger_effect` | 是否进入个人账派生，可由来源分类默认带出，也可人工调整 |
| `remark` | 备注 |

关键规则：

1. 能挂具体业务项目就挂具体项目；
2. 不能挂具体业务项目，就挂该主体默认 `base_operation` 项目；
3. 无票/有票是发票状态和来源分类，不决定是否有项目；
4. 报销明细可以生成应付记录，也可以直接作为派生计算来源，具体实现后续定。

## 7.3 报销付款关联表 `reimbursement_payment`

把报销单和实际付款关联起来。

| 字段 | 说明 |
|---|---|
| `id` | 主键 |
| `reimbursement_order_id` | 报销单 |
| `fund_transaction_id` | 真实资金流水记录，通常为 `direction = out` |
| `amount` | 本次报销付款金额 |
| `paid_at` | 付款日期 |
| `remark` | 备注 |

说明：

- 报销付款本质上引用一笔 `fund_transaction`；
- 这张表用于表达“这笔真实资金流水是在还哪张报销单”。

---

# 8. 发票与附件

## 8.1 发票表 `invoice`

| 字段 | 说明 |
|---|---|
| `id` | 主键 |
| `invoice_no` | 发票号码 |
| `invoice_type` | 普票/专票/数电票/其他 |
| `buyer_subject_id` | 购买方/抬头主体 |
| `seller_subject_id` | 销售方 |
| `amount_total` | 价税合计 |
| `tax_amount` | 税额，可空 |
| `issued_at` | 开票日期 |
| `status` | pending / received / verified / invalid / void |
| `file_id` | 附件文件 |
| `remark` | 备注 |

## 8.2 发票关联表 `invoice_link`

同一张发票可能关联报销明细、应付、订单等。

| 字段 | 说明 |
|---|---|
| `id` | 主键 |
| `invoice_id` | 发票 |
| `target_type` | reimbursement_item / payable / receivable / commercial_order |
| `target_id` | 关联对象 ID |
| `amount` | 关联金额 |

## 8.3 附件表 `attachment`

保存合同、付款截图、发票 PDF、审批附件等文件索引。

| 字段 | 说明 |
|---|---|
| `id` | 主键 |
| `target_type` | 关联对象类型 |
| `target_id` | 关联对象 ID |
| `file_name` | 文件名 |
| `file_path` / `file_token` | 本地路径或 Feishu 文件 token |
| `attachment_type` | contract/invoice/payment_proof/approval/other |
| `uploaded_at` | 上传时间 |
| `remark` | 备注 |

---

# 9. 审批与审计

## 9.1 审批来源表 `approval_instance`

| 字段 | 说明 |
|---|---|
| `id` | 主键 |
| `platform` | feishu/manual/other |
| `approval_code` | 审批模板代码 |
| `instance_code` | 审批实例 ID |
| `status` | pending/approved/rejected/canceled |
| `applicant_subject_id` | 申请人 |
| `raw_payload` | 原始表单 JSON |
| `created_at` / `updated_at` | 时间 |

## 9.2 审批关联表 `approval_link`

审批可以生成或关联多个业务对象。

| 字段 | 说明 |
|---|---|
| `id` | 主键 |
| `approval_instance_id` | 审批实例 |
| `target_type` | reimbursement_order / payable / receivable / project / fund_transaction 等 |
| `target_id` | 业务对象 ID |
| `action` | created / approved / updated / voided |

## 9.3 审计日志表 `audit_log`

记录所有重要修改。

| 字段 | 说明 |
|---|---|
| `id` | 主键 |
| `target_type` | 对象类型 |
| `target_id` | 对象 ID |
| `action` | create/update/status_change/delete/reverse |
| `before_json` | 修改前 |
| `after_json` | 修改后 |
| `operator_subject_id` | 操作人 |
| `operated_at` | 操作时间 |
| `remark` | 备注 |

---

# 10. 个人账派生基础口径

个人账不建成底层事实表，而是从基础表派生。

## 10.1 个人账派生视图 `personal_ledger_view`

这可以先是数据库 view 或计算服务结果，不一定建实体表。

基础字段：

| 字段 | 说明 |
|---|---|
| `person_subject_id` | 个人主体 |
| `owner_subject_id` | 归属主体/公司/个体户 |
| `project_id` | 项目，可为基础经营项目 |
| `source_type` | 来源类型 |
| `source_id` | 来源记录 ID |
| `amount_delta` | 对个人账的增减金额 |
| `status` | open / partially_settled / settled / reversed |
| `occurred_at` | 发生日期 |
| `remark` | 备注 |

## 10.2 暂定派生方向

先不定复杂计算，只定基础来源方向：

| 来源 | 触发记录 | 对个人账方向 | 说明 |
|---|---|---:|---|
| 无票报销/个人垫付 | `reimbursement_item`，`invoice_status=no_invoice`，垫付人为个人 | + | 公司/项目/公共经营可能欠个人 |
| 有票报销但未付款 | `reimbursement_item`，垫付人为个人，报销单未 paid | + | 有票也可能形成应还个人款 |
| 报销付款 | `reimbursement_payment` / `fund_transaction(direction=out)` 付给个人 | - | 公司已还个人 |
| 个人向公司注资 | `fund_transaction(direction=in)`，来源 `personal_injection`，打款人为个人 | + | 个人对主体形成注资/往来余额 |
| 公司归还个人注资/借款 | `fund_transaction(direction=out)`，来源 `company_repay_person` | - | 公司还个人 |
| 个人代公司付款 | `fund_transaction(direction=out)` 或 `payable_settlement` 中实际付款人为个人，费用归属公司/项目 | + | 个人替公司付出 |
| 内部调整 | `internal_adjustment` | +/- | 人工调整，必须审计 |
| 冲销 | `reversal` | 反向 | 抵消错误记录 |

注意：

- 上表只是一期基础方向，不是最终计算公式；
- 个人账必须能按个人、主体、项目、月份、来源类型拆分；
- 最终给个人看的账单可以从这个视图导出。

---

# 11. 基础经营/公共项目规则

## 11.1 规则

每个可经营主体可以维护一个默认基础经营项目：

```text
主体：云汉寻真
项目：云汉寻真-基础经营
project_type = base_operation
is_default_base_operation = true
```

## 11.2 使用场景

1. 报销无法归属具体项目；
2. 公司日常办公支出；
3. 公共经营费用；
4. 无票零散支出；
5. 暂时无法判断项目归属但能判断主体。

## 11.3 录入规则

- 如果能选具体业务项目，必须选具体业务项目；
- 如果不能选具体业务项目，但能确定主体，系统自动或提示选择该主体基础经营项目；
- 如果连主体也不能确定，则进入 `待确认归属`，不进入最终口径。

---

# 12. 一期状态总表建议

## 12.1 项目状态

| 状态 | 含义 | 是否计入口径 |
|---|---|---|
| `draft` | 草稿/待建档 | 否 |
| `active` | 执行中 | 是 |
| `completed` | 已完成待结算 | 是 |
| `settled` | 已结算 | 是，但锁定 |
| `void` | 作废 | 否 |

## 12.2 订单/合同状态

| 状态 | 含义 |
|---|---|
| `draft` | 草稿 |
| `signed` | 已签约/已确认 |
| `executing` | 执行中 |
| `partially_received` | 部分回款 |
| `received` | 已全额回款 |
| `closed` | 已关闭 |
| `void` | 作废 |

## 12.3 应收状态

| 状态 | 含义 |
|---|---|
| `planned` | 计划应收 |
| `confirmed` | 已确认应收 |
| `partially_received` | 部分到账 |
| `received` | 已到账 |
| `overdue` | 逾期 |
| `void` | 作废 |

## 12.4 应付状态

| 状态 | 含义 |
|---|---|
| `draft` | 草稿 |
| `confirmed` | 已确认应付 |
| `pending_payment` | 待付款 |
| `partially_paid` | 部分付款 |
| `paid` | 已付清 |
| `void` | 作废 |

## 12.5 报销状态

| 状态 | 含义 |
|---|---|
| `draft` | 草稿 |
| `submitted` | 已提交 |
| `approved` | 已通过 |
| `rejected` | 已驳回 |
| `pending_payment` | 待付款 |
| `partially_paid` | 部分付款 |
| `paid` | 已付清 |
| `void` | 作废 |

## 12.6 资金流水状态

| 状态 | 含义 |
|---|---|
| `pending` | 待确认 |
| `confirmed` | 已确认发生 |
| `allocated` | 已分配到项目/应收/应付/报销的一部分，但未完全核销 |
| `reconciled` | 已与应收/应付/报销核销 |
| `reversed` | 已冲销 |

## 12.7 发票状态

| 状态 | 含义 |
|---|---|
| `no_invoice` | 无发票 |
| `pending_invoice` | 待补票 |
| `invoiced` | 已有发票 |
| `verified` | 已核验/确认 |
| `invalid` | 异常/不可用 |

---

# 13. 一期可以先不做或弱化的内容

1. 项目跨主体迁移的完整状态机；
2. 复杂利润分配公式；
3. 自动银行流水接入；
4. 发票验真自动化；
5. 多公司合并报表；
6. 旧 Excel 13 个 sheet 的 100% 还原；
7. 复杂权限体系；
8. 多币种；
9. 税务申报级口径。

---

# 14. 初步表清单

按一期落表优先级：

## P0：必须先有

1. `subject_type` 主体类型表
2. `subject` 主体表
3. `cash_account` 资金账户表
4. `fund_transaction` 真实资金流水主表
5. `project` 项目表
6. `commercial_order` 订单/合同表
7. `receivable` 应收/收入计划表
8. `receivable_settlement` 应收-资金流水核销表
9. `payable` 应付/费用义务表
10. `payable_settlement` 应付-资金流水核销表
11. `reimbursement_order` 报销单主表
12. `reimbursement_item` 报销明细表
13. `reimbursement_payment` 报销-资金流水关联表

## P1：建议一期同时有

14. `invoice` 发票表
15. `invoice_link` 发票关联表
16. `attachment` 附件表
17. `source_category` 来源分类表
18. `status_definition` 状态定义表
19. `expense_category` 费用分类表
20. `approval_instance` 审批来源表
21. `approval_link` 审批关联表
22. `audit_log` 审计日志表

## P2：可以先用视图/计算服务，不急着实体化

23. `cash_inflow_view` 实际收款视图，由 `fund_transaction` 筛选得到
24. `cash_outflow_view` 实际付款视图，由 `fund_transaction` 筛选得到
25. `personal_ledger_view` 个人账派生视图
26. `project_finance_summary_view` 项目财务汇总视图
27. `subject_cash_summary_view` 主体资金汇总视图
28. `report_definition` 报表定义表
29. `monthly_snapshot` 月度快照表

---

# 15. 这版模型的闭环程度

## 已经能闭环的

1. 主体可配置，不写死公司；
2. 项目归属主体；
3. 无明确项目费用可以进入主体基础经营项目；
4. 真实资金流水成为收付款事实主账；
5. 收入应收和资金流水核销拆开；
6. 支出应付和资金流水核销拆开；
7. 报销能挂项目/基础经营项目；
8. 有票/无票能记录；
9. 个人账可由来源分类和资金流水派生；
10. 财务/个人/老板报表可以从计算层扩展。

## 仍然需要下一步细化的

1. 项目、订单、合同是否最终拆成两表还是三表；
2. 报销明细是否自动生成 `payable`；
3. 个人账每类来源的最终加减规则；
4. 月结锁定是否一期就做；
5. 审批流具体字段；
6. 前端页面模块；
7. 老板/财务/个人三类导出模板。

## 当前建议

可以基于这版模型继续下一步：

```text
1. 画 ERD
2. 把 P0 表转成 Prisma schema 草案
3. 设计一期前端页面：主体维护、项目维护、收款录入、付款录入、报销录入、基础经营项目、个人账视图
4. 再决定是否从旧项目代码重构
```