6.6 KiB
6.6 KiB
报销规范核查与审批文案优化
Goal
核查 majianyong 于 2026-08-28 提交的 4 笔报销是否满足当前报销、发票和附件规范，并将“负责人本人申请兜底：finance”这类内部审批路由说明替换为用户能直接理解的财务处理文案，同时保持禁止自审和历史审批事实不变。
Background
- 用户反馈
majianyong当前提交了 4 笔填写不够规范的报销，并提供了其中BX-20260828-0018的详情截图。 - 截图可确认该单为办公用品报销：整单事由与唯一明细说明均为泛化的“办公用品采购”，未关联项目；5 张发票自动归入 1 条总额明细，材料对应区提示“待关联发票或补充无票说明”。
- 当前正式组织口径是
majianyong为公司负责人ceo、不配置直属主管且不得自审；负责人本人提交报销时由唯一 active 非本人finance处理。 - 后端在生成负责人本人兜底步骤时把内部原因和角色代码拼为
负责人本人申请兜底：finance，报销详情的处理进度投影把它当作可读节点名，因而在“下一步”“当前处理”和时间线中直接展示。 - 现有稳定规约已经规定审批投影不得暴露角色代码或技术标识，
finance|finance_mgr应显示为“财务复核”。
Scope
- 生产 4 笔报销的最小字段只读核查与脱敏结论。
- 负责人本人财务兜底步骤的新记录业务命名。
- 报销详情、PC/移动审批任务等用户入口对历史兜底步骤名的只读显示投影。
- 聚焦后端回归、前端构建与报销详情页面验证；不包含公网部署。
Requirements
R1 生产报销只读核查
- 只读定位
majianyong在 2026-08-28 提交的 4 笔报销；若实际结果不恰好为 4 笔，应停止逐笔结论并报告范围漂移。 - 仅读取核查所需的最小字段：业务编号、状态、报销日期、事由、项目关联、费用类型、明细日期/金额/说明、发票与明细关联状态、补充附件类型/说明、材料完整性提示和审批节点摘要。
- 按当前事实源检查：事由和明细说明是否能说明购买/支出内容及业务用途；费用类型和日期是否准确；项目性费用是否关联项目；多张发票是否合理拆分或能与明细对应；发票是否逐条关联；支付截图、订单或情况说明等补充材料是否足以支撑实付与用途。
- 输出逐笔脱敏问题清单，区分“应退回补正”“建议补充”“仅需财务核对”；不得在任务文件、仓库或聊天中记录完整发票号码、附件原文、原始 payload、账号、凭据或存储路径。
- 本任务不替用户编辑、撤回、审批或付款，不写生产数据库，不写企业微信。
R2 用户可见审批文案
owner_self_fallback继续作为内部路由/审计语义，仍须保持 active 非本人财务处理和禁止自审。- 报销详情中该节点统一显示为
财务复核；“当前处理”按现有结构显示财务复核 · <实际处理人姓名>，不显示内部角色代码；“下一步”显示待财务复核处理。 - 处理进度时间线对当前和历史负责人本人兜底快照均显示
财务复核，不得要求迁移或重写历史workflow_steps_snapshot。 - 新提交报销生成的业务步骤名使用可读文案，内部兜底原因保留在稳定步骤 ID/路由逻辑中，不能因文案调整丢失自审保护或审批人解析依据。
- 聚焦核对待办/移动审批等直接使用任务步骤名的用户入口；如它们会继续暴露该内部文案，应复用同一服务端显示语义或确保新任务不再生成内部文案。不得进行通用工作流 UI 重构。
Acceptance Criteria
- 生产只读结果恰好覆盖
majianyong于 2026-08-28 提交的 4 笔报销，并形成不含敏感原文的逐笔规范性结论。 - 每笔结论至少覆盖事由、项目、明细拆分/说明、日期与金额、发票对应、补充材料六类检查，并给出明确处理建议。
BX-20260828-0018不再把 5 张发票仅以泛化“办公用品采购”视为充分说明；结论明确指出其明细对应和用途证据缺口。- 负责人本人申请仍只由 active 非本人
finance处理，不产生自审、不改变普通员工审批链。 - 报销详情的“当前处理”“下一步”和处理进度不再显示
负责人本人申请兜底、finance或其他内部步骤标识，分别使用“财务复核 · 处理人”“待财务复核处理”和“财务复核”。 - 已存在的历史兜底快照无需数据迁移即可得到同样的用户可读投影；新提交记录不再生成内部原因作为用户可见步骤名。
- 后端聚焦测试覆盖历史步骤名、新步骤名、普通财务节点、非财务节点与禁止自审回归；相关前端类型检查、构建和报销详情 Playwright 通过。
- 审批/workflow 变更完成后进行一次只读代码复核，确认权限、状态机、快照和审批规则语义未扩大。
- 未经另行批准不部署公网；部署并通过公网只读检查前，不告知用户线上可测试。
Out of Scope
- 修改、撤回、驳回、通过这 4 笔真实报销，或替员工补录材料。
- 修改审批角色、负责人直属主管、审批金额档、生产审批规则或历史快照。
- 执行真实付款、付款批次操作、附件下载、企业微信写入或数据库迁移。
- 新增通用 BPM、重构全部业务域审批文案或改变现有页面布局。
Risks and Constraints
- 生产数据可能已发生状态变化；只读查询必须冻结查询时间并以业务编号为结论锚点。
- 发票 PDF 和支付证明需要人工看原件才能判断真实性；本轮自动/字段核查只能判断材料结构与对应关系，不能替代财务验真。
- 历史快照是审批事实，文案修复必须在显示投影层兼容，不得回写历史数据。
Test Plan
- 聚焦后端：
cd server && npx vitest run tests/unit/utils/workflow.test.js tests/unit/routes/reimbursements.detail.test.js。 - 基础后端：
cd server && npm run prisma:validate，修改的 JavaScript 文件执行node --check。 - 前端：
cd client && npm run typecheck && npm run build；运行覆盖 PC 报销详情的聚焦 Playwright。 - 流程治理：
node scripts/qa/check-process-contract.mjs --baseline --json、node scripts/qa/audit-docs.mjs --check-registry、node scripts/qa/check-trellis-governance.mjs、git diff --check。 - 人工只读复核：检查 diff 未改变审批资格、任务推进、历史快照持久化或生产数据。