# 用户新想法记录

记录时间：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` 太薄，需要补：项目归属、公共组归属、公司主体、垫付人、付款账户、报销状态、发票状态、审批来源等字段。

## 03｜报销按发票状态区分，个人公共账不应作为基础表结构

用户当前口述要点：

1. 报销统一分为两类：
   - 有发票的报销；
   - 没有发票的报销。
2. 没有发票的报销，本质上接近之前说的“个人公共账”那部分。
3. 但用户当前倾向：**不要在表结构设计里明确做一个“个人账”设定**。
4. “个人账”更应该是根据基础业务数据和规则，二次盘出来/计算出来的数额，而不是第一层原始表。

初步理解：

- 基础表不应直接建成“个人公共账流水表”作为事实源。
- 原始事实应记录：谁垫付、为哪个项目/公共组、是否有发票、是否已报销/付款、由哪个公司主体/资金账户承担。
- “个人公共账余额”应作为派生指标，由无票报销、个人垫付、公共组归属、已还/未还状态等基础数据计算出来。
- 旧系统中的 `EquityAccount` / `InternalAdjustment` / `ReimbursementOrder` 需要重新定位：个人账不一定是原始账本表，而可能是报表/余额计算结果。

## 04｜个人向公司注入资金也可能构成“个人账”的来源之一

用户当前口述要点：

1. “个人账”除了无票报销/个人公共账这一类来源之外，还有另一类组成部分。
2. 例如：某个人以某种名义，直接打了 50 万到某一个公司里，形成对公司的资金注入。
3. 在二次计算时，这笔钱也可能被算作该个人账的一部分。
4. 具体计算逻辑暂时不急着定，后续盘表结构时，需要把每一笔账的**来源分类**分清楚。
5. 底层结构需要有清晰的：
   - 状态表；
   - 来源表；
   - 引用关系；
   - 方便后续扩展的基础结构。

初步理解：

- “个人账”不只是报销余额，也可能包括个人向公司注入资金、个人代公司付款、个人借款/垫资等不同来源。
- 这些不应混成一个模糊字段，而应在底层通过 `sourceType / sourceCategory / eventType / status` 等方式区分。
- 个人账仍然应是派生结果：系统根据不同来源类型和状态，计算某个人对公司/项目/公共组的应收、已收、未结余额。
- 新系统需要设计可扩展的来源分类和状态机，避免未来新增资金来源时推翻表结构。