# 飞书统一报销入口模板设计方案

更新时间：2026-06-08
适用范围：公司财务 / 报销审批 / 机器人入库测试阶段

## 0. 本次调整边界

本次不修改原先已经存在的分散模板，也不改原先审批单。

现有报销类模板包括：

1. 点绛报销专用
2. 云汉寻真报销专用
3. 万物有灵公共账报销专用
4. 万物有灵相关项目组报销专用

这些模板可以先保留为历史入口 / 兜底入口。新的方向是新增一个统一入口：

```text
公司统一报销申请
```

后续测试稳定后，再逐步把机器人和员工引导到统一入口；旧入口不立即删除。

## 1. 为什么要做统一入口

之前每个公司或项目组单独一个入口，会导致：

1. 用户不知道该选哪个入口；
2. 同一类字段在不同模板里名字不一致；
3. 机器人发起审批时要维护多套字段映射；
4. 后端回调解析复杂，容易把模板差异当成业务差异；
5. 后续新增公司主体 / 项目组时，需要新增模板或复制模板。

统一入口的目标是：

```text
一个报销模板
  + 表单内选择公司主体 / 归属项目 / 报销类型
  + 流程按字段路由
  + 后端按统一字段入库
```

## 2. 新模板建议名称

模板名称建议：

```text
公司统一报销申请
```

测试阶段也可以先命名为：

```text
公司统一报销申请（测试）
```

待验证通过后，再复制/启用正式版。

## 3. 表单字段设计

### 3.1 基础信息

| 字段名 | 控件建议 | 必填 | 说明 | 后端字段 |
|---|---|---:|---|---|
| 公司主体 | 单选 | 是 | 报销最终归属的公司/主体 | `owner_subject_id` |
| 归属项目/公共账 | 单选或下拉 | 是 | 具体项目组、公共经营、基础运营等 | `project_id` |
| 报销人 | 联系人/人员 | 是 | 默认发起人，可允许代提交 | `applicant_subject_id` |
| 收款人 | 联系人/文本 | 是 | 默认等于报销人，特殊情况可改 | `payee_subject_id` |
| 发生日期 | 日期 | 是 | 费用发生日期或订单日期 | `items[].expense_date` |
| 报销类型 | 单选 | 是 | 费用大类 | `items[].expense_category_id` |

### 3.2 金额与内容

| 字段名 | 控件建议 | 必填 | 说明 | 后端字段 |
|---|---|---:|---|---|
| 报销金额 | 金额/数字 | 是 | 本次报销总金额 | `total_amount` / `items[].amount` |
| 报销内容 | 多行文本 | 是 | 实际买了什么、为什么报销 | `items[].description` |
| 明细说明 | 明细表格或多行文本 | 否 | 多笔订单/多项费用时填写 | `items[]` |
| 订单号/交易号 | 文本 | 否 | 电商订单、支付单、合同编号等 | `external_refs[]` |
| 备注 | 多行文本 | 否 | 整单备注，不替代报销内容 | `remark` |

### 3.3 发票与附件

| 字段名 | 控件建议 | 必填 | 说明 | 后端字段 |
|---|---|---:|---|---|
| 发票状态 | 单选 | 是 | 有发票 / 暂无发票 / 后补发票 / 不需要发票 | `items[].invoice_status` |
| 发票类型 | 单选 | 否 | 普票 / 专票 / 数电票 / 无 | `invoice.type` |
| 发票号码 | 文本 | 否 | 有发票时填写，可由机器人/OCR补充 | `invoice.invoice_no` |
| 发票金额 | 金额/数字 | 否 | 用于和报销金额勾稽 | `invoice.amount_total` |
| 附件 | 附件 | 是 | 发票、订单截图、支付截图、聊天记录、合同等 | `attachments[]` |

### 3.4 支付/个人账信息

| 字段名 | 控件建议 | 必填 | 说明 | 后端字段 |
|---|---|---:|---|---|
| 付款/报销方式 | 单选 | 是 | 立即打款 / 进入个人账 / 已由公司支付 / 待确认 | `payment_plan` |
| 收款账户说明 | 文本 | 条件必填 | 需要打款时填写，避免在普通页面明文扩散完整账号 | `payee_account_note` |
| 是否需要后补发票 | 单选 | 否 | 暂无发票时用于后续追踪 | `invoice_followup_required` |

## 4. 建议选项

### 4.1 公司主体

先用当前常见主体：

```text
万物有灵
云汉寻真
点绛
秘色破茧
其他/待确认
```

后端不要直接依赖中文显示值，应映射到 `subject` 表或配置中的 `subject_key`。

### 4.2 归属项目/公共账

建议一开始不要把每个公司拆成独立模板，而是放在同一个字段里：

```text
公共经营/公共账
AIGC组
电商业务
国博业务
良渚业务
产品开发/打样
行政/办公
其他/待确认
```

后端根据 `公司主体 + 归属项目/公共账` 共同解析 `project_id`。

### 4.3 报销类型

```text
日常采买
差旅费
住宿费
交通费
招待费
团建费
通讯费
软件/会员/订阅
办公设备
样品/打样/产品开发
服务费
其他
```

### 4.4 发票状态

```text
有发票
暂无发票，后续补票
无发票，进入个人账/内部核销
不需要发票
待确认
```

### 4.5 付款/报销方式

```text
审批通过后打款
先进入公司个人账
已由公司账户支付，仅补资料
暂不打款，仅登记
待确认
```

## 5. 流程设计

### 5.1 测试阶段

为方便测试，新模板测试版建议：

```text
发起人：实际提交人/机器人代提交用户
审批节点：钱丽云
办理节点：钱丽云
抄送：可为空，或钱丽云
```

这样所有测试都只打到钱丽云，不再打扰钱丽娜、杭婷或其他人。

### 5.2 正式阶段

正式版可以改为字段路由：

```text
公司主体 / 归属项目
  -> 对应负责人审批
审批通过
  -> 财务办理/打款/入账
必要时
  -> 抄送财务或项目负责人
```

建议保留一个后端/机器人配置开关：

```text
FEISHU_APPROVAL_TEST_OVERRIDE_APPROVER=钱丽云
```

测试环境启用，正式环境关闭。

## 6. 后端入库映射

统一模板回调后，后端按统一字段处理：

```text
Feishu instance approved
  -> parse unified reimbursement fields
  -> find intake_draft by instance_code or external id
  -> update approval status
  -> validate reimbursement facts
  -> commit reimbursement_order / reimbursement_item / attachment / invoice metadata
```

字段映射原则：

1. `报销内容` 映射到 `reimbursement_item.description`；
2. `备注` 只作为整单备注，不替代报销内容；
3. `公司主体` 和 `归属项目/公共账` 共同解析主体和项目；
4. `附件` 进入附件/源文件审计链路；
5. `发票状态` 影响后续发票追踪和风险提示；
6. 审批通过不等于已打款，打款仍需要后续付款流水/核销状态。

## 7. 和旧模板的关系

建议迁移策略：

1. 旧模板先不删、不停用；
2. 新建 `公司统一报销申请（测试）`；
3. 机器人优先发起新模板测试版；
4. 测试字段、附件、回调、看板显示全部稳定后，再复制为正式版；
5. 正式版稳定后，再逐步把旧模板标注为历史入口或只读参考。

## 8. 待确认问题

1. 统一模板里“归属项目/公共账”的首批选项要不要只放常用项目，还是一次性放全？
2. 是否允许“代提交”：报销人不是发起人？
3. 收款账户信息是否放飞书模板中，还是只让机器人在私聊中采集并后端加密/脱敏保存？
4. 测试版是否直接固定审批人/办理人为钱丽云？
5. 新模板正式名称用 `公司统一报销申请` 还是带公司品牌名？

## 9. 建议下一步

下一步建议先做：

```text
公司统一报销申请（测试）
```

测试版字段尽量完整，但流程简单：审批、办理、抄送都只走钱丽云。验证通过后再设计正式路由。