# 用户新想法记录

记录时间：2026-06-03 20:20:43 CST

> 本文只记录用户当前口述的新业务想法，后续会再整理进“已明确口径 / 待确认问题 / 需要重构闭环”。

## 01｜多公司主体、公司下分项目、收入入账与项目关联

用户当前口述要点：

1. 公司体系里会有**多个公司主体**。
2. 每个公司主体下面还要继续区分**项目**。
3. 每一笔公司收入，通常都伴随着某一个项目或某一个订单/合同。
4. 当合同进来、款项转入时，系统需要检查这个收入对应的项目是否已经存在：
   - 如果没有项目，需要新建项目；
   - 同时把这笔钱计入对应公司的流入；
   - 这笔公司流入要和具体公司主体、项目/订单/合同形成关联关系。

初步理解：

- 旧系统里的 `Project` 模型方向可保留，但需要明确 `CompanyEntity -> Project/Order/Contract -> Income/CashInflow` 的层级关系。
- 旧系统中 `IncomeItem` 与 `CashFlow` 需要拆清：收入确认和实际收款可能是两件事，但用户当前强调“合同进来、有钱转进来”时，至少需要把实际公司流入与项目建立关联。
- 新系统应避免只有一张收入表；应能回答：这笔钱进了哪个公司主体、对应哪个项目/订单/合同、是否为新项目、是否已完成项目建档。

## 02｜公司流入/流出状态，以及个人报销归属逻辑

用户当前口述要点：

### A. 公司流入

1. 每一笔订单/合同收入的状态需要明确。
2. 状态至少要能区分：
   - 是否已经支付；
   - 是否分成多期支付。
3. 多期收入/回款如何拆分，用户当前还没有完全想清楚，需要后续继续确认。

初步理解：

- 需要区分“订单/合同应收”和“实际收款”。
- 一个项目/订单可能对应多期回款。
- 旧系统的 `IncomeItem` 与 `CashFlow` 需要拆成更清楚的应收/实收关系，不能只用一个金额字段表达全部。

### B. 公司支出

1. 公司支出也需要更细分类。
2. 有些支出可能还没有实际打款，但已经形成签约/应付关系。

初步理解：

- 需要区分“支出/采购/合同已形成”和“实际付款”。
- 公司流出也可能存在：已签约未付款、部分付款、已付款、待补票等状态。
- 旧系统的 `ExpenseItem` 与 `CashFlow` 也需要拆清应付与实付。

### C. 个人报销

1. 每一笔个人报销都应该关联到具体项目。
2. 如果没有明确项目归属，至少应归到公共组报销。
3. 如果有项目归属，那么该项目属于哪个公司主体应当是明确的。

初步理解：

- 报销不能孤立存在，必须挂到：项目，或公共组。
- 报销如果挂到项目，则公司主体可以通过项目反推。
- 旧系统的 `ReimbursementOrder` 太薄，需要补：项目归属、公共组归属、公司主体、垫付人、付款账户、报销状态、发票状态、审批来源等字段。