# 飞书统一报销入口字段方案

更新时间：2026-06-08
适用范围：公司财务 / 报销审批 / 统一报销入口
当前状态：测试模板已通过 OpenAPI 更新并回查验证为 ACTIVE；发票状态只保留“有票/无票”，已删除“付款/处理方式”；旧模板未修改

## 0. 设计目标

统一入口不是把所有旧模板字段机械合并，而是做成：

```text
用户少填字段
机器人/后端多做解析
审批人能看懂
账务入库字段不丢
```

核心原则：

1. 旧公司/项目分散模板先不动；
2. 新增一个统一入口，不复制多套入口；
3. 飞书表单只收集审批必要信息；
4. 后端和机器人负责字段映射、默认值、风险提示和入库；
5. 发票、附件、个人账、付款状态要能支撑后续账务闭环。

建议模板名：

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

已创建测试模板：

```text
模板名：公司统一报销申请（测试）
approval_code：04E7B2B1-DCD7-44E1-84DA-7590CDD3DFE1
approval_id：7649042051241118901
状态：ACTIVE
创建方式：OpenAPI approval/v4/approvals
旧模板：未修改
测试路由：审批/办理均为钱丽云，人员 ID 已在文档中脱敏
管理地址：https://www.feishu.cn/approval/admin/createApproval?id=7649042051241118901&definitionCode=04E7B2B1-DCD7-44E1-84DA-7590CDD3DFE1
```

注意：飞书官方文档说明，通过 OpenAPI 创建的审批定义无法从审批管理后台或 API 停用、删除；本次是在用户确认接受该限制后创建的测试模板。


正式稳定后再复制为：

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

---

## 1. 字段分层

字段分三层：

```text
A. 用户必填核心字段：尽量少，保证能审批。
B. 条件字段：只有特定情况才需要填写。
C. 后端派生字段：不放在飞书表单里，由机器人/系统解析。
```

---

## 2. A 层：用户必填核心字段

建议控制在 8 个以内。

| 顺序 | 字段名 | 控件建议 | 必填 | 用途 | 后端映射 |
|---:|---|---|---:|---|---|
| 1 | 公司主体 | 单选 | 是 | 这笔钱算到哪个公司/主体 | `owner_subject_id` |
| 2 | 归属项目/公共账 | 单选/下拉 | 是 | 这笔钱算到哪个项目、组或公共账 | `project_id` |
| 3 | 报销类型 | 单选 | 是 | 费用大类，用于统计和风险判断 | `expense_category_id` |
| 4 | 发生日期 | 日期 | 是 | 费用发生日期/订单日期 | `items[].expense_date` |
| 5 | 报销金额 | 金额/数字 | 是 | 本次申请报销总额 | `total_amount` |
| 6 | 报销内容 | 多行文本 | 是 | 实际买了什么、为什么报销 | `items[].description` |
| 7 | 发票状态 | 单选 | 是 | 只分有票/无票 | `items[].invoice_status` |
| 8 | 附件 | 附件 | 是 | 发票、订单、支付截图、凭证 | `attachments[]` |

说明：

- `报销人` 默认取发起人，不作为核心必填字段，避免普通用户重复填。
- `收款人` 默认等于报销人，只有代报销/代收款时才出现。
- `备注` 不作为核心字段，避免用户把报销正文写到备注里。

---

## 3. B 层：条件字段

### 3.1 代提交/代收款

| 字段名 | 触发条件 | 控件建议 | 必填 | 后端映射 |
|---|---|---|---:|---|
| 报销人是否为本人 | 默认隐藏或单选 | 单选 | 否 | `applicant_is_submitter` |
| 实际报销人 | 选择“不是本人”时 | 联系人/文本 | 条件必填 | `applicant_subject_id` |
| 收款人是否为报销人 | 默认隐藏或单选 | 单选 | 否 | `payee_is_applicant` |
| 实际收款人 | 收款人不同于报销人时 | 联系人/文本 | 条件必填 | `payee_subject_id` |

### 3.2 多笔明细

| 字段名 | 触发条件 | 控件建议 | 必填 | 后端映射 |
|---|---|---|---:|---|
| 是否多笔明细 | 金额包含多笔订单/费用 | 单选 | 否 | `has_line_items` |
| 明细说明 | 选择多笔明细时 | 明细表格/多行文本 | 条件必填 | `items[]` |
| 订单号/交易号 | 有订单/交易凭证时 | 文本 | 否 | `external_refs[]` |

说明：

- 如果飞书模板里明细表格维护成本高，第一版可以先用“明细说明”多行文本。
- 机器人后续可从附件/OCR/用户私聊中拆分明细，再写后端 `reimbursement_item`。

### 3.3 发票信息

| 字段名 | 触发条件 | 控件建议 | 必填 | 后端映射 |
|---|---|---|---:|---|
| 发票类型 | 发票状态=有发票 | 单选 | 否 | `invoice.type` |
| 发票号码 | 发票状态=有发票 | 文本 | 否 | `invoice.invoice_no` |
| 发票金额 | 发票状态=有发票 | 金额/数字 | 否 | `invoice.amount_total` |
| 是否需要后补发票 | 发票状态=暂无/后补 | 单选 | 否 | `invoice_followup_required` |

说明：

- 发票结构化字段建议不强制用户手填，优先由机器人/OCR 从附件中提取。
- 审批时只要附件和发票状态明确即可；精确发票号可后补。

### 3.4 付款处理

| 字段名 | 触发条件 | 控件建议 | 必填 | 后端映射 |
|---|---|---|---:|---|
| 付款/处理方式 | 全部申请 | 单选 | 是 | `payment_plan` |
| 收款账户说明 | 需要打款时 | 文本/多行文本 | 条件必填 | `payee_account_note` |

`付款/处理方式` 建议选项：

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

安全建议：

- 飞书审批表里尽量不放完整银行卡号。
- 如果必须放，后端看板和文档中必须脱敏展示。

---

## 4. C 层：后端派生字段，不放飞书表单

这些字段不建议让用户在飞书表单里填：

| 后端字段 | 来源 |
|---|---|
| `applicant_subject_id` | 默认由发起人映射；代提交时由“实际报销人”覆盖 |
| `payee_subject_id` | 默认等于报销人；代收款时覆盖 |
| `owner_subject_id` | 由“公司主体”解析 |
| `project_id` | 由“公司主体 + 归属项目/公共账”解析 |
| `expense_category_id` | 由“报销类型”解析 |
| `invoice_status` | 由“发票状态”解析 |
| `risk_flags` | 系统根据无票、大额、主体/项目待确认、附件缺失等生成 |
| `approval_instance_code` | 飞书创建审批后返回 |
| `payment_status` | 后续打款/核销流程更新，不由本审批表决定 |
| `source_file_storage_key` | 附件入 COS/源文件系统后生成 |

---

## 5. 建议选项

### 5.1 公司主体

第一版建议：

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

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

第一版建议不要太细，避免用户选错：

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

后端解析时使用：

```text
公司主体 + 归属项目/公共账
```

共同定位具体项目。

### 5.3 报销类型

建议：

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

### 5.4 发票状态

当前模板只保留两个选项：

```text
有票
无票
```

说明：

- “有票”表示财务审批后可进入打款流程。
- “无票”表示财务审批同意后暂不打款；这类记录作为月度个人账核算的来源之一。
- 不在入口中出现“进入个人账/内部核销”等处理结果，个人账由系统按来源记录二次计算。

---

## 6. 推荐的飞书表单顺序

面向普通用户，建议顺序如下：

```text
1. 公司主体
2. 归属项目/公共账
3. 报销类型
4. 发生日期
5. 报销金额
6. 报销内容
7. 发票状态
8. 附件
9. 收款账户说明（可选）
10. 明细说明（可选）
11. 订单号/交易号（可选）
12. 备注（可选）
```

第一屏尽量只出现 1-9，后面字段尽量做条件展示或非必填。

---

## 7. 测试流程建议

测试模板建议：

```text
模板名：公司统一报销申请（测试）
审批节点：钱丽云
办理节点：钱丽云
抄送：空或钱丽云
```

原因：

1. 不打扰钱丽娜、杭婷和项目负责人；
2. 方便快速测试字段、附件、回调、看板状态；
3. 旧模板完全保留，不影响原工作流。

正式版再做条件路由：

```text
公司主体 / 归属项目/公共账
  -> 负责人审批
  -> 财务办理
  -> 必要抄送
```

---

## 8. 后端映射重点

统一入口上线后，后端只维护一套表单映射：

```text
统一报销模板 approval_code
  -> field_id map
  -> normalized reimbursement draft
  -> approval callback
  -> reimbursement_order / reimbursement_item / attachment / invoice
```

必须坚持：

1. `报销内容` 是 `reimbursement_item.description` 的主来源；
2. `备注` 是整单备注，不替代报销内容；
3. `公司主体` 和 `归属项目/公共账` 不等于部门；当前系统没有部门表，主表不显示部门；
4. 审批通过只代表报销被批准，不代表已经打款；
5. 付款状态由后续付款流水/核销更新。

---

## 9. 当前创建结果

本轮已按第一版最小可用字段集创建测试模板，并回查验证为 ACTIVE。实际控件 ID 以 `docs/feishu_unified_reimbursement_template_mapping.json` 为准；后端映射不得再用草案字段名猜测。

第一版新模板不要做得太重。

建议先按这个最小可用字段集创建测试版：

```text
公司主体
归属项目/公共账
报销类型
发生日期
报销金额
报销内容
发票状态
附件
付款/处理方式
收款账户说明（条件/可选）
明细说明（可选）
备注（可选）
```

等测试发现真实缺口，再加字段。不要一开始把合同、付款申请、供应商付款、个人账核销都塞进报销入口。


### 2026-06-08 更新结果：发票状态二分、删除付款处理方式

已对测试模板 `公司统一报销申请（测试）` 做全量覆盖更新并回查验证：

```text
approval_code：04E7B2B1-DCD7-44E1-84DA-7590CDD3DFE1
状态：ACTIVE
字段数：12
发票状态：有票 / 无票
已删除字段：付款/处理方式
旧模板：未修改
```

当前业务逻辑：

1. 统一报销入口只记录来源，不把个人账作为用户可选来源或处理方式。
2. `有票`：财务审批后进入打款流程，后续由付款/核销记录更新 `已打款`。
3. `无票`：财务审批同意后暂不打款；系统在月度按“无票 + 已审批 + 未打款”的来源记录自动核算个人账。
4. 个人账是来源记录的二次计算结果，不是飞书入口字段。