# 公司财务报销与公司走账系统重构

创建时间：2026-06-03 20:06 CST  
所属：公司财务 / 云汉寻真 / 万物有灵内部财务  
用途：复盘旧财务系统设计，重新梳理报销、公司走账、个人垫付与项目利润分配的新系统方向。


## 2026-06-05 最新进展：报销闭环已部署云端

当前最新系统已经从本地 JSON 试运行推进到云端 PostgreSQL 入库版本：

```text
公网入口：https://wwyl.yipeng.online/finance-reimbursement/
健康检查：https://wwyl.yipeng.online/finance-reimbursement/health
云端服务：company-finance.service
云端路径：/srv/company-finance/current
数据库：PostgreSQL / company_finance
内部端口：127.0.0.1:8102
```

本次优先补完了财务报销闭环：

1. `intake_draft`：机器人先创建报销草稿；
2. `reimbursement_order` / `reimbursement_item`：用户确认后正式入库报销单和明细；
3. `invoice` / `invoice_link`：记录发票结构化信息并关联报销明细；
4. `attachment`：登记发票/凭证附件引用；
5. `audit_log`：记录草稿提交为正式报销单的审计事件；
6. 预留 `fund_transaction` + `reimbursement_payment`：等实际付款发生后做报销付款核销。

本次没有覆盖旧线上 `/finance/` 看板；新系统暂走 `/finance-reimbursement/`，避免误伤旧页面。等新系统边用边稳定后，再决定是否切换正式 `/finance/` 入口。

详细说明见：

```text
docs/云端部署与报销闭环说明.md
```

## 这次新项目要解决的问题

之前已经做过一套“大财务管理平台”，但旧方案里混合了三类目标：

1. 复刻旧 Excel 利润分配表；
2. 从飞书多维表读取数据并导出原 Excel 格式；
3. 设计 Node/PostgreSQL 自建财务系统，并接飞书审批。

这次重启时，先不要急着继续写代码，而是先把“业务到底要管什么、哪些数据是事实源、哪些动作需要审批、哪些余额需要对账”重新梳理清楚。

## 已找到的旧项目

旧项目路径：

```text
/Users/bot1/Volumes/root_for_ai/AI工作区/公司财务_系统开发_财务管理平台_20260530_1748
```

项目索引卡片：

```text
/Users/bot1/Volumes/root_for_ai/AI工作区/00_AI工作区项目索引/projects/公司财务_系统开发_财务管理平台_20260530_1748.md
```

旧项目核心文件：

- `PROJECT_CONTEXT.md`：旧项目阶段总结。
- `docs/DATA_MODEL.md`：旧系统结构拆分。
- `docs/APPROVAL_INPUT_MODEL.md`：飞书审批作为录入入口、自建系统作为账本的设计。
- `docs/FEISHU_APPROVAL_CALLBACK_DESIGN.md`：审批回调写入本地系统设计。
- `docs/FRONTEND_AND_DASHBOARD_STRATEGY.md`：前端只做看板/查询/少量配置/导出。
- `docs/REAL_BITABLE_READER_AND_FULL_TEMPLATE_EXPORT.md`：真实飞书多维表读取与原 Excel 格式导出。
- `prisma/schema.prisma`：PostgreSQL/Prisma 数据库模型。
- `packages/core/src/finance-engine.ts`：财务计算核心。
- `source/万物有灵项目利润分配表2026_原始参考.xlsx`：旧 Excel 事实模板。
- `exports/财务原表格式导出_飞书实时数据_20260531T062220Z.xlsx`：旧系统从飞书实时读取后导出的验证文件。

## 本项目文档

- `PROJECT_CONTEXT.md`：当前新项目上下文和工作边界。
- `docs/旧方案复盘.md`：对多维表、数据库、导出器、前端/审批方案的复盘。
- `docs/新系统业务蓝图.md`：建议的新业务拆分、核心对象和一期边界。
- `docs/待确认问题清单.md`：后续和用户一起确认的问题。
- `docs/API_MCP_机器人接口设计草案.md`：机器人优先的后端 API / MCP 接口分层设计。
- `docs/mcp_tools_一期草案.json`：一期 MCP 工具 schema 草案。
- `docs/一期机器人入库规则与追问策略.md`：各类财务 intent 的字段要求、追问策略、默认规则和风险提示。
- `docs/intake_rules_一期草案.json`：结构化入库规则配置草案，供后续 MCP/后端实现使用。
- `docs/后端服务架构与本地试运行方案.md`：本地后端服务模块、接口和试运行边界。
- `docs/云端部署与报销闭环说明.md`：云端 PostgreSQL 部署、报销闭环表结构和接口说明。
- `backend/`：一期后端服务；本地无数据库时为 JSON 试运行，云端配置 PostgreSQL 后为正式入库服务。
- `backend/README_LOCAL_RUN.md`：本地启动、自测、数据库迁移和接口说明。
- `frontend/`：前后端分离的财务看板中心；当前先实现报销审批看板，后续其他看板继续在这里添加。
- `frontend/README.md`：前端看板启动方式、API 参数和后续扩展约定。

## 当前结论摘要

1. **飞书多维表不适合作为最终账本**：旧项目已经验证能读多维表并导出 Excel，但也已经在文档中明确“多维表不是事实源”。它更适合作为临时录入/展示/迁移参考。
2. **数据库设计有可复用骨架，但要重画业务边界**：Project、EquityAccount、Income/Expense、Reimbursement、CashAccount、CashFlow、ApprovalInstance 等对象方向是对的，但公司走账、个人垫付、报销付款、项目利润分配之间还需要更清楚的事件模型。
3. **新系统应先从“账务事件流水”出发**：每一笔业务都要明确：谁申请、谁承担、谁付款、钱从哪个资金账户出、是否有票、是否需要报销、是否已经付清、归属哪个项目/月度。
4. **一期不要追求完整 ERP**：先做报销/付款/收款/内部调整/资金账户对账 + 简单看板 + 原 Excel 导出兜底。

## 安全边界

- 本项目只整理系统设计，不写入 `03_用户资料`。
- 不复制或公开密钥、Token、Feishu App Secret、数据库密码、审批回调密钥。
- 旧项目 `.env`、服务器凭据、Base token 只记录“在哪里配置”，不在文档正文写值。