# 旧方案复盘：公司财务管理平台

复盘时间：2026-06-03  
旧项目：`/Users/bot1/Volumes/root_for_ai/AI工作区/公司财务_系统开发_财务管理平台_20260530_1748`

## 1. 旧方案一：飞书多维表 + 原 Excel 导出

### 已实现内容

旧项目已经实现过：

```text
飞书多维表真实记录
→ apps/api/src/bitable-reader.ts 分页读取 Base
→ packages/core/src/feishu-input.ts 转 FinanceInput
→ packages/core/src/finance-engine.ts 计算
→ 原表导出映射表 1950 个非空单元格覆盖原 Excel 模板
→ packages/exporter/src/template-writer.ts 写回原 Excel 模板
→ apps/api/src/server.ts 输出 xlsx / 工作流下载链接
```

旧项目 `PROJECT_CONTEXT.md` 记录的验证结果：

- 13 个 sheet 保留；
- 1950 个模板单元格读取覆盖；
- 真实 API snapshot 非空；
- `npm test -- --run`、`npm run typecheck`、`npm run build` 曾通过；
- 真实 Base 导出验证通过。

旧项目中真实导出文件：

```text
exports/财务原表格式导出_飞书实时数据_20260531T062220Z.xlsx
```

### 多维表方案的价值

可复用的地方：

1. **迁移参考**：旧飞书 Base 里已经有项目表、权益账户表、收入明细表、支出明细表、利润分配规则表、报销单表、资金账户表、收付款流水表、个人账内部周转流水表等结构。
2. **字段命名参考**：`packages/core/src/feishu-input.ts` 里已经把多维表字段映射到系统对象。
3. **导出兜底**：旧 Excel 的 13 个 sheet 和原样式导出已经打通过，可以作为后续月结/给人看的兜底输出。
4. **真实联调经验**：已经证明机器人/代码可以从飞书 Base 读到真实记录并生成 Excel。

### 多维表方案的问题

1. **多维表不应作为最终账本**：旧文档 `APPROVAL_INPUT_MODEL.md` 已经明确：飞书多维表不是事实源；事实源应改为自建 Node/PostgreSQL 财务系统。
2. **状态和动作不清晰**：报销、付款、审批、发票、个人垫付、公司走账都带状态变化，多维表容易变成“字段堆叠”，但不天然保证事件顺序和幂等。
3. **权限/审计不足**：多维表适合展示和轻录入，但很难稳定表达“谁在何时批准、哪笔审批生成哪笔入账、是否重复入账”。
4. **计算口径容易散**：如果公式、字段、脚本、人工改表同时存在，就容易产生多个版本的事实。
5. **Excel 复刻会绑住新系统**：旧系统为了导出原表格式做了大量映射，但这不等于业务模型已经想清楚。

## 2. 旧方案二：Node/PostgreSQL 数据库账本

### 已设计内容

旧项目 `prisma/schema.prisma` 已有这些模型：

- `Project`：项目/合同/收入归属；
- `EquityAccount`：个人、项目组、公共、公司主体等权益账户；
- `IncomeItem`：收入明细；
- `ExpenseItem`：支出明细；
- `ProfitAllocationRule`：利润分配规则；
- `ProfitAllocationEntry`：利润分配结果；
- `InternalAdjustment`：内部调整；
- `ReimbursementOrder`：报销单；
- `CashAccount`：资金账户；
- `CashFlow`：资金流水；
- `FeishuApprovalDefinition` / `FeishuApprovalInstance` / `FeishuEventLog`：审批模板、审批实例、事件日志。

### 数据库方案的价值

1. **方向是对的**：自建数据库更适合作为事实源，可以做幂等、审计、状态机、月结锁定。
2. **已有核心对象**：项目、权益账户、收支、报销、资金账户、审批事件这些骨架可以保留。
3. **能接飞书审批**：旧文档已设计“审批是入口，不是账本；本地数据库是账本”。
4. **能重算看板和导出**：`finance-engine.ts` 已经把部分口径固化到代码，而不是依赖 Excel 公式。

### 数据库方案的问题

1. **公司走账语义还不够清楚**：`CashFlow` 只是资金流水，但没有完整表达“付款原因、申请单、发票、个人垫付、公司代付、报销核销”的业务链路。
2. **报销单模型太薄**：现有 `ReimbursementOrder` 只有申请人、月份、金额、状态、付款时间，缺少发票、费用明细、垫付人、实际付款账户、承担对象、审批来源、核销关系。
3. **支出与付款容易混在一起**：费用归属、付款动作、资金账户出账、报销给个人是不同层级，旧模型还没有完全拆开。
4. **利润分配和现金余额混合度高**：权益账户余额、资金账户余额、项目利润池、个人应得/已付之间需要更清楚地分层。
5. **一期边界过大**：旧项目同时做审批、数据库、Excel导出、线上看板、工作流，容易变成大而全。

## 3. 旧 Excel 模板复盘

旧 Excel 原始参考：

```text
source/万物有灵项目利润分配表2026_原始参考.xlsx
```

现场检查到的 sheet：

1. 收入分配表
2. 公共组收入支配情况（实际扣款时间）
3. 公共组收入支配情况（应支付时间）
4. 苏薇提成支取表
5. 小蒋提成支取表
6. 木雨提成支取表
7. 妹妹项目组
8. 自研产品组
9. AIGC组
10. 电商渠道组
11. 元浪公共账户
12. 个体户账户
13. Sheet1

这个 Excel 的真实含义不是“单纯报销系统”，而是一套混合账：

- 项目收入分配；
- 个人/项目组权益账户；
- 公共账户实际扣款口径；
- 公共账户应支付口径；
- 报销、工资、税费、第三方成本；
- 元浪公共账户和个体户账户等资金/主体账户。

## 4. 核心结论

旧系统不是不能用，而是“技术实现跑在业务梳理前面了”。后续应保留：

- 旧 Excel 的业务口径线索；
- 已抽取的 13 个 sheet 结构；
- FinanceInput / FinanceSnapshot 思路；
- PostgreSQL 作为事实源；
- 飞书审批作为录入/审批入口；
- 原 Excel 导出作为过渡输出。

但应暂缓：

- 继续把飞书多维表当主账本；
- 继续只围绕原 Excel 单元格做开发；
- 在没有确认业务事件模型前继续扩展数据库；
- 一期做复杂 ERP 前端。