# 未形成闭环事实与需要重构的点

整理时间：2026-06-03  
依据：用户本轮口述 + 旧系统复盘 + 新系统业务蓝图

## 一、目前已经比较明确的底层原则

这些可以先作为新系统设计的基础方向：

1. **公司主体是第一层**：系统会有多个公司主体。
2. **项目归属公司主体**：每个项目必须明确属于哪个公司主体。
3. **收入通常来自项目/订单/合同**：钱进来时要能关联到公司主体、项目、订单/合同。
4. **项目不存在时要能新建项目**：收入/合同录入时，如果找不到对应项目，应触发项目建档。
5. **收入和实收要拆开**：订单/合同应收与实际到账不是同一件事。
6. **支出和实付要拆开**：签约/应付与实际付款不是同一件事。
7. **报销必须有归属**：每笔报销要么归属项目，要么归属公共组。
8. **有票/无票是报销核心分类**：报销至少分为有发票、无发票两类。
9. **个人账不是底层事实表**：个人账应由基础数据二次计算得出，而不是在表结构里直接做成原始账本。
10. **个人账来源可扩展**：无票报销、个人垫付、个人向公司注资等都可能成为个人账派生余额的来源。
11. **基础表结构要稳定**：事实表尽量稳定，报表/导出/角色视图在计算层和展示层扩展。
12. **不同角色导出不同**：财务、个人、老板会有不同展示形式和计算方法。
13. **项目跨主体迁移一期不做**：未来若迁移，不直接改原项目 company，而是 A 主体结算 + B 主体新建承接项目。

---

## 二、现在还没有形成闭环的事实

下面这些就是当前最需要继续确认、补模型或重构的点。

## 1. 公司主体闭环还不完整

### 已明确

- 有多个公司主体。
- 项目挂在公司主体下面。
- 公司流入/流出都要知道对应哪个公司。

### 未闭环

1. 具体有哪些公司主体？例如：云汉寻真、万物有灵、元浪、个体户/珍珍日上等，哪些算正式主体？
2. 公司主体是否等同于收付款主体？有些品牌/业务名是否只是项目口径，不是资金主体？
3. 公司主体是否需要绑定资金账户？一个公司可否有多个资金账户？
4. 公司之间代付、借款、内部往来是否进入一期？
5. 公司主体下项目的编号、命名、去重规则未定。

### 旧系统对应问题

旧系统 `Project` 有项目，但没有把 `CompanyEntity -> Project -> Contract/Order -> Income/CashFlow` 这条关系做完整。

### 需要重构

- 新增或强化 `CompanyEntity`。
- `Project` 必须有 `companyEntityId`。
- 资金账户 `CashAccount` 应明确所属公司主体。

---

## 2. 项目 / 订单 / 合同闭环还不完整

### 已明确

- 每一笔公司收入通常伴随一个项目、订单或合同。
- 如果收入进来时没有项目，需要新建项目。

### 未闭环

1. “项目、订单、合同”三者关系未定：
   - 一个项目可以有多个订单/合同吗？
   - 一个合同可以拆多个项目吗？
   - 项目是否可以没有合同，只按订单/口头合作建档？
2. 项目新建触发点未定：
   - 合同录入时建项目？
   - 第一笔收款时建项目？
   - 支出先发生时是否也能建项目？
3. 项目状态未定：待签约、已签约、执行中、已完结、已结算、作废等是否需要。
4. 项目历史迁移只记录了原则，但一期如何备注承接关系未定。

### 旧系统对应问题

旧系统里 `Project` 太薄，主要作为收入/支出的归属对象，未完整表达订单/合同与项目建档流程。

### 需要重构

- 至少需要 `Project` + `Contract/Order` 两层，或一个统一的 `CommercialOrder` 表。
- 收入入账时需要能引用：`companyEntityId + projectId + order/contractId`。
- 项目不存在时的建档流程需要单独设计。

---

## 3. 公司流入闭环还不完整

### 已明确

- 每笔订单/合同收入要有状态。
- 状态要能区分已支付、分期支付。
- 收入要关联公司主体和项目/订单/合同。

### 未闭环

1. 多期收入如何拆分未定：
   - 按合同阶段？
   - 按回款计划？
   - 按实际到账拆？
   - 是否允许一笔到账对应多个项目/订单？
2. “收入确认”和“实际收款”如何区分未定：
   - 合同签了算收入？
   - 开票了算收入？
   - 到账了算收入？
   - 给老板看的收入和财务确认收入是否不同？
3. 收款状态未定：未收、部分收、已收、逾期、退款/冲销等。
4. 收款证据未定：银行流水、截图、飞书审批、手工录入、发票等哪个是来源。
5. 退款、退单、坏账、跨月收款未定。

### 旧系统对应问题

旧系统 `IncomeItem` 与 `CashFlow` 没有形成“应收计划—实际到账—项目归属—公司资金账户”的闭环。

### 需要重构

- 拆出：
  - `Receivable` / `IncomeRecognition`：应收或收入确认；
  - `CashInflow` / `PaymentReceived`：实际到账；
  - 两者的核销关系。
- 收款要能多对一、一对多地关联订单/项目。

---

## 4. 公司流出 / 支出闭环还不完整

### 已明确

- 公司支出需要更细分类。
- 有些支出已形成签约/应付关系，但还未实际打款。

### 未闭环

1. 支出分类体系未定：项目成本、供应商、采购、税费、工资、办公、AI工具、物流、报销、公共费用等如何分。
2. 应付和实付的拆分规则未定。
3. 支出是否必须关联项目？不关联项目时归公共组还是公司主体？
4. 支出状态未定：待确认、已签约、待付款、部分付款、已付款、待补票、已核销、作废等。
5. 一笔支出是否可以拆到多个项目/多个公司主体未定。
6. 供应商、合同、付款申请、发票、附件的关系未定。

### 旧系统对应问题

旧系统 `ExpenseItem` 和 `CashFlow` 容易混在一起，无法完整表达“签约/应付”和“实际付款”的不同阶段。

### 需要重构

- 拆出：
  - `Payable` / `ExpenseObligation`：费用义务或应付；
  - `CashOutflow` / `PaymentMade`：实际付款；
  - `ExpenseAllocation`：费用归属项目/公共组/公司主体；
  - `Invoice`：发票状态。

---

## 5. 报销闭环还不完整

### 已明确

- 报销分为有发票、无发票。
- 每笔报销必须归属项目或公共组。
- 有项目归属时，公司主体由项目确定。
- 无票报销接近个人公共账来源，但个人账不作为底层事实表。

### 未闭环

1. 报销和支出的关系未定：
   - 报销本身就是支出？
   - 还是报销只是对个人垫付的付款核销？
   - 有票报销和无票报销是否影响财务口径不同？
2. 有票报销需要记录哪些发票字段未定。
3. 无票报销是否可以报、怎么审批、是否有额度/说明要求未定。
4. 报销状态未定：草稿、待审批、已通过、待付款、已付款、驳回、作废、待补票等。
5. 一张报销单是否允许多条明细，分别挂不同项目/公共组未定。
6. 谁是垫付人、谁是申请人、谁是收款人可能不同，规则未定。
7. 报销付款从哪个资金账户出，和原支出归属如何核销未定。

### 旧系统对应问题

旧系统 `ReimbursementOrder` 只有申请人、月份、金额、状态、付款时间等，无法表达项目归属、发票、垫付、付款、审批、核销完整链路。

### 需要重构

- `ReimbursementOrder` 需要拆成：
  - 报销单主表；
  - 报销明细；
  - 发票/附件；
  - 报销付款记录；
  - 与项目/公共组/支出/资金流水的引用。

---

## 6. 个人账派生逻辑还不完整

### 已明确

- 个人账不是基础表结构。
- 个人账是根据基础逻辑数据二次盘出来的数额。
- 来源可能包括无票报销、个人垫付、个人向公司注资等。

### 未闭环

1. 哪些来源进入个人账还未定：
   - 无票报销；
   - 个人垫付有票但未还；
   - 个人向公司注资；
   - 个人借款给公司；
   - 公司还给个人；
   - 个人代公司付款；
   - 内部调整。
2. 每类来源的加减方向未定。
3. 个人账和权益账户、公共组账户、公司往来款之间的关系未定。
4. 个人账是否按公司主体分别计算未定。
5. 个人账是否按项目拆分、还是只出个人总额未定。
6. 已结清、未结清、部分结清如何计算未定。

### 旧系统对应问题

旧系统 `EquityAccount` 容易被当成基础账户，但按用户新口径，个人账更像派生报表/计算结果，不应直接作为原始事实来源。

### 需要重构

- 基础事件必须带：`personId`、`sourceCategory`、`direction`、`companyEntityId`、`projectId/publicGroupId`、`settlementStatus`。
- 个人账由计算层生成，例如 `PersonalLedgerView` / `PersonalBalanceSnapshot`。

---

## 7. 来源分类表 / 状态表还不完整

### 已明确

- 每一笔账要把来源分类分清楚。
- 需要状态表或来源表，以及引用关系，方便扩展。

### 未闭环

1. 来源分类枚举未定：收入、收款、应付、付款、报销、注资、借款、还款、内部调整、冲销等。
2. 状态枚举未定：待确认、已形成、待审批、已审批、待付款、部分付款、已付款、已核销、已结清、作废等。
3. 状态流转规则未定：谁能把记录从 A 状态改到 B 状态。
4. 来源和状态是否按不同事件类型分表未定。
5. 修改历史、冲销、撤回、重新提交未定。

### 旧系统对应问题

旧系统已有一些状态字段，但没有统一的状态机和来源分类体系。

### 需要重构

- 设计 `SourceCategory` / `EventType` / `Status` / `AuditLog`。
- 不同业务事件共享一套审计和引用机制。

---

## 8. 审批与审计闭环还不完整

### 已明确

- 旧系统已经设计过飞书审批作为入口。
- 审批不是账本，审批通过后写入自建系统。

### 未闭环

1. 哪些动作必须审批、哪些可以手工录入未定。
2. 小额口述记账是否走审批未定。
3. 飞书审批字段与新业务模型未重新对应。
4. 审批通过后是创建哪些事件/状态未定。
5. 驳回、撤回、作废、修改已审批记录的处理方式未定。
6. 附件、发票、合同、付款凭证如何保存和追溯未定。

### 旧系统对应问题

旧系统有 `FeishuApprovalInstance` 和 `FeishuEventLog`，也有审批模板草稿，但映射的是旧模型，需要按这次新口径重画。

### 需要重构

- 审批模板按事件类型重构。
- 审批实例只作为来源，生成业务事件和状态变更。
- 加强幂等和审计。

---

## 9. 月结 / 锁定 / 历史修改闭环还不完整

### 已明确

- 旧系统里提到过月度导出和月结。
- 项目跨主体迁移未来需要结算边界。

### 未闭环

1. 是否需要月结锁定未最终确认。
2. 月结后发现错账，是直接修改原记录，还是做调整/冲销未定。
3. 个人账、项目利润、公司余额是否都按月生成快照未定。
4. 项目迁移时 A 公司主体截止结算如何生成未定。
5. 历史版本和导出文件保存规则未定。

### 旧系统对应问题

旧系统有 `ProfitAllocationEntry.locked`，但整体月结、锁定、调整、导出快照没有完整闭环。

### 需要重构

- 设计 `MonthlyClose` / `Snapshot` / `Adjustment` / `Reversal`。
- 月结后尽量通过调整记录修正，而不是直接改历史事实。

---

## 10. 导出和角色视图闭环还不完整

### 已明确

- 底层表结构要稳定。
- 财务、个人、老板会有不同导出形式和计算方法。
- 旧 Excel 导出只是兼容或过渡输出。

### 未闭环

1. 给财务看的报表需要哪些字段未定。
2. 给个人看的报表需要显示哪些内容未定：个人应收、已收、未结、无票报销、注资、项目归属等。
3. 给老板看的报表需要哪些指标未定：公司现金、项目利润、待收/待付、个人往来、公共组余额等。
4. 不同角色是否有不同权限未定。
5. 旧 Excel 13 个 sheet 是否仍要保留，保留到什么程度未定。
6. 报表计算口径如何版本化未定。

### 旧系统对应问题

旧系统过度围绕旧 Excel 单元格导出，导出层和底层业务模型绑定过深。

### 需要重构

- 明确三层：事实层、计算层、展示/导出层。
- 报表作为 `ReportDefinition` / `ViewModel` / `ExportTemplate`，不反向影响基础表结构。

---

## 三、旧系统最需要重构的核心点

按优先级排序：

1. **补公司主体模型**：旧系统缺少明确的多公司主体层。
2. **重构项目/订单/合同关系**：项目不能只是一个名字，需要挂公司、订单/合同、状态。
3. **拆分收入确认与实际收款**：解决分期、部分到账、应收实收核销。
4. **拆分支出义务与实际付款**：解决已签约未付款、部分付款、发票状态。
5. **重构报销模型**：报销要有明细、项目/公共组归属、有票/无票、垫付人、付款账户、审批来源。
6. **个人账改为派生计算**：不把个人账作为底层账本，而是由来源分类和状态计算。
7. **设计来源分类与状态机**：支持注资、垫付、报销、还款、内部调整等扩展。
8. **重构审批映射**：飞书审批只作为入口和证据，不作为账本。
9. **增加月结/调整/审计**：避免历史数据随意改。
10. **导出层解耦**：财务/个人/老板/旧 Excel 导出都从计算层生成。

---

## 四、下一步建议先确认的 10 个问题

1. 一期正式纳入哪些公司主体？
2. 项目、订单、合同三者是否分表？还是一期用一个“项目/订单”统一表？
3. 收入状态怎么定义：签约、应收、部分收、已收、退款？
4. 支出状态怎么定义：已签约、待付款、部分付款、已付款、待补票？
5. 报销单是否允许多条明细、拆多个项目？
6. 无票报销是否全部进入个人账派生口径？有无例外？
7. 个人注资、个人借款、个人代付三类是否都进入个人账派生口径？
8. 公共组到底是一个归属对象、一个派生账户，还是一个项目特殊类型？
9. 月结是否一期就做锁定？
10. 财务、个人、老板三类导出分别最想先看到什么？

## 五、当前判断

现在还没有形成闭环的核心不是“代码没写完”，而是：

> 原始事实、状态流转、来源分类、资金动作、报销核销、个人账派生、角色报表之间的边界还没有完全定清楚。

所以下一步应该先做 **业务事实模型 + 状态机 + 派生计算口径**，再去写数据库表结构和前后端页面。