2.8 KiB
2.8 KiB
设计：报销规范核查与审批文案优化
边界
本任务包含两个相互关联但可独立验证的输出：生产 4 笔报销的只读规范性报告，以及负责人本人财务兜底节点的用户文案修复。前者不写业务数据；后者只调整步骤命名与详情显示投影，不改审批规则、角色、权限或数据库结构。
数据流
报销核查
生产只读数据 → 按提交人/日期冻结 4 个业务编号 → 最小字段核查
→ 对照报销/发票/附件事实源 → 脱敏逐笔结论
- 优先使用现有受控生产只读连接或已授权 API 身份。
- 查询结果只在进程内用于判断；任务文档只登记问题分类、业务编号和必要的非敏感摘要。
- 不打开或下载原始附件时，只把“需要财务查看原件”列为保留项，不推断真实性。
审批文案
审批规则解析
→ buildRoleApprovalStep（保存步骤 ID、角色与业务步骤名）
→ workflow task / workflow_steps_snapshot（历史事实）
→ reimbursement processingProgress 显示投影
→ 当前处理 / 下一步 / 时间线
负责人本人兜底的技术原因继续由步骤 ID 后缀 _owner_self_fallback、分支原因和角色规则表达。业务步骤名改为按角色映射后的 财务复核，避免新记录继续污染用户入口。针对已经保存旧步骤名的历史记录，resolveApprovalStageLabel 将 负责人本人申请兜底：<role> 识别为内部标签，再按 assignee_role 映射为 财务复核。
processingProgress 当前阶段的 detail 不再拼接旧步骤名，而使用规范化后的 stage label，因此详情页现有 nextStepText 可直接显示 待财务复核处理。前端无需引入第二套文案映射。
兼容性
- 不回写历史工作流实例或任务。
- 普通的自定义可读节点名继续保留；只把明确的负责人本人兜底内部标签、序号、通用名和技术标识走角色映射。
finance与finance_mgr的显示均为财务复核；审批资格仍按原角色执行。- 报销审批历史如直接读取旧
step_name，需在同一服务端显示边界复用规范化函数，避免详情页不同区域一处修好、一处仍泄漏。 - 待办中心的历史任务若仍直接暴露旧名，本任务只做必要的共享显示归一化，不改变任务 API 的权限与动作模型。
风险与回滚
- 风险：过宽地判定“不可读节点名”会覆盖合法自定义名称。控制方式是只增加负责人本人兜底前缀的精确识别，并保留现有名称优先级测试。
- 风险：仅改生成名无法修复已经提交的 4 笔。控制方式是在读取投影层同时兼容历史名。
- 回滚：代码回退即可；无 schema、配置或数据回滚。
- 公网部署不在默认执行范围，必须另行明确批准。