# 用户新想法记录

记录时间：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` 等方式区分。
- 个人账仍然应是派生结果：系统根据不同来源类型和状态，计算某个人对公司/项目/公共组的应收、已收、未结余额。
- 新系统需要设计可扩展的来源分类和状态机，避免未来新增资金来源时推翻表结构。

## 05｜项目跨公司主体迁移：一期暂不做，但需记录未来口径

用户当前口述要点：

1. 项目如果后续从 A 公司主体迁到 B 公司主体，这个逻辑在一阶段设计里暂时不考虑。
2. 但需要先记录未来口径：
   - 以迁出时间节点为止，对 A 公司主体做一次结算；
   - 然后在 B 公司主体下重新录入该项目；
   - 新录入项目做好备注，说明它来自原 A 公司主体下的哪个项目；
   - 不直接把原项目的公司主体关联关系从 A 改成 B。
3. 这样可以保留历史公司主体归属和结算边界，不会把旧主体期间的数据混到新主体。

初步理解：

- 项目主体迁移不应是简单 update `project.companyId = B`。
- 更像是：A 主体项目关账/结算 + B 主体新项目建档 + 两者建立“承接/备注/来源”关系。
- 后续如果做二期，需要设计 `project_successor / project_transfer_note / settlement_cutoff` 之类的关系。
- 一期只需保证项目有明确公司主体和历史结算边界，不做复杂迁移状态机。

## 06｜本次完整设计目标：表结构 + 前后端分离系统

用户当前口述要点：

1. 这一次完整设计肯定要走表结构。
2. 系统不是单纯 Excel/多维表，而是需要一整套独立系统。
3. 系统形态应是单独的前后端分离架构。

初步理解：

- 旧系统里的 Node/PostgreSQL 方向可作为参考，但需要按这次重新梳理后的业务闭环重画表结构。
- 飞书多维表不作为核心事实源。
- Excel/旧模板导出只作为输出层或过渡兼容。
- 后续需要整理：数据库 ERD、状态机、API 边界、前端页面清单、审批/附件/导出接入方式。

## 07｜基础表结构稳定，导出/展现/计算口径需要可扩展

用户当前口述要点：

1. 基础表结构现在不应该频繁变化。
2. 但后续导出的格式会按不同对象变化，例如：
   - 给财务看的导出；
   - 给个人看的导出；
   - 给老板/管理层看的导出。
3. 不同导出对象可能需要不同展现形式和不同计算方法。
4. 所以系统设计时，需要把导出层和计算口径的可扩展性考虑进去。

初步理解：

- 基础事实表应尽量稳定，记录原始业务事件、状态、来源和引用关系。
- 报表/导出不应反过来决定底层表结构；导出应该是基于基础事实和可配置口径生成的视图。
- 后续可考虑三层结构：
  1. **事实层**：公司主体、项目、订单/合同、收入、应收、支出、应付、付款、报销、发票、资金流水、审批来源。
  2. **计算层**：按不同口径生成财务指标、个人账派生余额、老板看板指标、月结口径。
  3. **展示/导出层**：财务报表、个人对账单、老板总览、旧 Excel 兼容导出。
- 旧系统里原 Excel 导出器可复用为导出层参考，但不应继续让 Excel 格式主导底层表结构。

## 08｜主体不写死：公司主体/收付款主体做成可配置主体表

用户当前口述要点：

1. 公司主体不需要在设计里写死具体有哪些主体。
2. 可以单独做一张主体录入/维护表，由系统配置。
3. 收付款主体也一样，不一定等同于公司主体。
4. 一个主体可以选择类型，例如：公司、个体户等。
5. 后续系统录入时，从主体表中选择对应主体，而不是在代码或表结构里固定“云汉寻真/万物有灵/元浪”等。

初步理解：

- 需要设计一个通用的 `主体表`，而不是写死 `公司表`。
- 主体表应支持主体类型，例如：公司、个体户、个人、项目组、公共组、其他。
- “项目归属主体”和“实际收付款主体”都可以引用这张主体表，但二者不必相同。
- 这能解决：某项目挂在 A 公司名下，但实际收款/付款可能通过 B 主体或个体户完成。
- 后续表结构应避免把主体类型写成死字段，而应通过可配置类型/字典表扩展。

## 09｜无明确项目归属的报销：按公司固定“基础经营/公共项目”承接

用户当前口述要点：

1. 无票报销或无法准确归属到具体项目的报销，可以定义一个公司维度的固定项目来承接。
2. 这个固定项目可以叫类似：公司基础经营、公共项目开支、公司公共组等。
3. 它本质上是某一个公司主体下面的公共组/公共项目概念。
4. 如果某笔报销没有办法准确套到任何业务项目上，就走对应公司主体下的公共项目开支，未来计入该公司公共经营成本。

初步理解：

- “公共组”不一定要做成独立于公司的全局账户，而可以落为每个主体下的一个特殊项目。
- 这样报销归属规则就更闭环：
  - 能归具体项目 → 挂具体项目；
  - 不能归具体项目 → 挂该公司主体的“基础经营/公共项目”；
  - 无票/有票只是发票状态，不决定是否能入项目，只影响财务/个人账派生口径。
- 系统可以为每个可经营主体自动或手动维护一个默认公共项目，例如：`云汉寻真-基础经营`、`某个体户-基础经营`。
- 报销录入时若选择“无明确项目”，必须仍然选择/推导公司主体，然后系统挂到该主体默认公共项目。

## 10｜资金流水应作为真实主账：实收/实付从资金流水关联汇总得到

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

用户当前口述要点：

1. 多笔支付/多笔收款确实是需要单独解决的问题。
2. 可以额外设计一张以“每一次真实资金进出”为核心的表。
3. 不管是向内收款，还是向外打款，每一笔实际发生的资金流水都单独成为一条记录。
4. 这张表以每一笔资金流水为主键，再通过关联表挂到对应的收付款事项上。
5. 这样其他表里的“实收”“实付”不必人工重复维护，可以通过资金流水关联金额加和得到。

初步理解：

- 这是对上一版模型的重要修正：`cash_inflow` / `cash_outflow` 不一定要作为两张原始事实表；更合理的是抽象出统一的 `fund_transaction` / `cash_transaction` 资金流水主表。
- 资金流水主表记录真实发生的钱：方向、金额、日期、付款主体、收款主体、付款账户、收款账户、对方、备注、凭证、状态。
- 应收实收核销表、应付实付核销表、报销付款关联表都引用这张资金流水主表。
- `receivable` 的已收金额 = 关联到该应收的资金流水核销金额加和。
- `payable` 的已付金额 = 关联到该应付的资金流水核销金额加和。
- 报销单的已付款金额 = 关联到该报销单的资金流水加和。
- 这样可以支持一笔收款拆多个项目、一个项目多笔收款、一笔付款核销多个应付、一个应付多次付款、合并付款、部分付款、退款/冲销等场景。

## 11｜系统面向机器人使用：前端弱化，后端接口与 MCP 契约要清晰

记录时间：2026-06-03 21:11:35 CST

用户当前强调要点：

1. 系统前端不需要设计很多录入页面。
2. 后端接口必须对应设计清楚。
3. 用户设想的主要录入路径是：内部成员直接和财务机器人对话。
4. 财务机器人读取系统入库规则，主动追问用户缺失字段。
5. 机器人收集完整数据后，由机器人发起入库动作。
6. 中间会加入飞书审批作为人为把控环节，但当前设计阶段可以先不展开审批实现。
7. 当前重点是：后端接口、接口文档、机器人使用契约、MCP 工具封装必须清楚。

初步理解：

- 新系统不是“人打开后台页面逐项录入”的传统财务后台，而是“机器人优先”的财务入库系统。
- 前端一期只保留少量管理和核对页面，例如主体/项目/资金流水/异常待确认/汇总查看。
- 主要业务写入入口应封装为后端 API 和 MCP tools，供财务机器人调用。
- MCP 工具不应暴露过细数据库表操作，而应暴露业务动作，例如：创建或查找项目、创建应收、录入资金流水、核销应收、创建报销草稿、校验入库数据、提交审批前预览、审批通过后入库。
- 机器人需要先调用“入库规则/字段要求”接口，判断缺哪些字段，再追问用户；不能凭空补关键财务事实。
- 审批动作可在系统中抽象为 `approval_pending` / `approval_ref` / `approved_at` 等状态和引用，具体飞书审批对接后续再做。