hyb-oa/.trellis/tasks/archive/2026-08/07-27-yang-jun-reimbursement-readiness/research/domestic-reimbursement-detail-kiss.md

国内报销详情页 KISS 调研

1. 调研问题

面向 10 人以下国内科技公司，报销详情页是否需要把概况、差旅概要、费用明细、材料、关联事项、风险、审批、付款和操作拆成多个常驻区域；如果不需要，最小但完整的信息结构是什么。

2. 公开资料结论

• 合思公开产品资料覆盖申请、消费、报销、对账、记账、归档、报表，并强调票据识别、费用可追踪和审核；这些是全链路能力域，不等于单据详情页需要常驻同等数量的版块。
• 汇联易公开产品资料强调费用管理、合规规则、发票管理、智能审核、会计与流程能力；其复杂预算、风险和核算能力面向中大型企业，不应直接成为本项目小团队详情页的默认结构。
• 每刻报销公开产品资料强调出差申请、费用、发票、审核、支付和归档，并明确其相对传统 OA 的优势来自预算、智能审核、ERP 和银企集成；本项目当前没有这些真实配置或集成，不能为了“像费控系统”而展示空区域。
• 人人都是产品经理的费控设计案例把差旅移动流程概括为事项申请、发票采集、场景报销、领导审批和财务审核，并指出不同费用类型应使用动态单据模板和附件清单。可复用原则是“按业务事实动态展示”，不是固定堆叠所有能力域。

3. 项目现状

• 移动报销详情当前至少有：报销概况、独立差旅概要、报销明细、报销材料、审批、操作。
• PC 详情除上述主线外，还可能出现关联事项、预算与审核提示、付款状态和更多操作；多数已按数据条件隐藏，但差旅概要仍形成独立卡片。
• 当前公司费用标准和预算没有形成真实常用数据；风险区没有内容时本来就不显示。审批动作在审批任务页，普通业务详情不应复制审批动作。
• 当前真实单据规模小，适合单页纵向滚动；Tab、折叠和二级抽屉只会增加企微 WebView 的状态与返回验证成本。

4. 推荐结构

只保留四个稳定内容块，PC 与移动端信息顺序一致：

1. 单头概况：单号、状态、申请人、部门、总额、说明；差旅单把事由、地点和起止日期并入同一块，普通报销自然不显示差旅行。
2. 费用明细：费用类型、发生日期、金额和说明；编辑态在这里保留新增、编辑和删除。
3. 报销材料：计数与合并预览在上，下面始终显示可单份打开的发票/补充附件列表；只读审批人没有移除或删除动作。
4. 审批与处理记录：提交、当前节点和历史。付款事实仅在实际存在时作为本块内的处理结果显示，不新建永久空版块。

状态性内容不形成新的常驻区域：

• 真实风险或校验异常以内联提示放到单头或对应明细附近；无风险不显示。
• 项目或差旅申请关联作为单头的一行链接；无关联不显示。
• 草稿/驳回操作继续使用页面底部命令区或移动固定操作条，不算内容块。
• 打印、返回列表等低频动作收进“更多”，不占主阅读流。

5. 明确不做

• 不做 Tab、折叠、底部抽屉或左右分页。
• 不保留独立“差旅概要”卡片。
• 不新增常驻预算、合规、风险、财务或付款版块。
• 不把审批按钮搬进报销业务详情，不改变审批任务返回链路。
• 不新增普通/差旅类型，不改变现有数据字段、权限、状态机或 API。

6. 来源

• 合思官网，合思费控与全链路产品说明：https://www.ekuaibao.com/（访问：2026-08-01）。
• 汇联易官网，全面费用管理产品功能：https://www.huilianyi.com/products/helios（访问：2026-08-01）。
• 每刻报销官网，企业差旅及费用管理平台：https://www.maycur.com/mkbx（访问：2026-08-01）。
• 人人都是产品经理，《费控报销系统，如何设计？》：https://www.woshipm.com/pd/5292016.html（访问：2026-08-01）。

以上公开资料只用于提炼信息与流程共性，不把供应商宣传中的预算、AI、ERP、银企直连或大型集团能力视为本项目需求。

7. 审批与付款进度补充调研

7.1 国内产品共性

• 企业微信官方“获取审批申请详情”数据合同把审批流程表达为多个审批节点；节点含审批人、节点/审批人状态、操作时间和审批意见，备注另行记录。可复用原则是按节点展示职责、处理人、状态、时间和必要意见，而不是显示“节点 1 / 节点 2”。
• 飞书、钉钉等国内审批产品同样把实例详情、任务/节点和操作记录分开建模。公开资料没有要求统一视觉，但移动端纵向时间轴符合用户既有审批心智，也适合本项目企业微信 WebView。
• 国内费控产品通常把费用审批与支付、回单、归档串成端到端业务链；实现上审批 workflow 与付款对象仍是不同状态机。详情页可以给用户一条连续进度，但不能把付款批次伪造成 workflow 节点。

企业微信官方资料：https://developer.work.weixin.qq.com/document/path/91983（访问：2026-08-01）。

7.2 本项目真实状态机

• 报销 workflow 快照当前固定为“主管审批 → 财务复核”，最终把报销状态置为 approved。
• 付款另由 PaymentBatch 承担：财务创建批次（maker）→ 非制单人复核批次（checker）→ 执行付款；执行后报销进入 paid，银行回单可随后留存。
• 当前 PC workflowProgress 显示“第 N 步”，且只在 workflow pending 时返回；移动端只显示当前节点和历史。报销详情没有付款批次安全摘要，因此还不能诚实展示付款复核、执行和回单状态。

7.3 推荐的端到端纵向进度

第四个稳定内容块命名为“处理进度”，使用一条纵向时间轴，按职责显示五个业务阶段：

1. 申请提交
2. 主管审批
3. 财务复核
4. 付款批次复核
5. 付款与回单

显示规则：

• 节点名称使用业务职责，不显示“第 1 步 / 第 2 步”。
• 已处理节点显示实际处理人、时间和结果；当前节点显示实际待办处理人（可取得时）和“处理中”；未来节点只显示职责与“待处理”，不根据当前角色持有人猜姓名。
• 审批意见、退回/驳回原因仅在有内容时显示；退回/驳回原因不得隐藏。
• 付款批次未创建时，付款复核节点显示“待财务创建付款批次”；批次 draft 显示“待非制单人复核”；reviewed 显示“复核通过，待执行付款”；failed/cancelled 如实显示异常或重新处理。
• 报销进入 paid 后，最后节点显示付款时间/处理人；回单状态作为该节点的次级状态，不额外增加第六块内容。
• 前端时间轴消费统一的只读进度 DTO；服务端分别读取 workflow 快照/历史、当前 task、报销付款字段和当前关联付款批次摘要，再做安全映射。不得修改 workflow 或 PaymentBatch 状态机。

7.4 KISS 边界

• 不画 BPMN、分支图或横向步骤条。
• 不展示内部 step ID、角色码、权限码或状态机枚举。
• 不在报销详情复制审批、付款或回单操作；需要处理时仍跳到当前审批任务或付款批次详情。
• 不硬编码自然人姓名；历史用实际 actor，当前用实际 assignee，未来只写职责。