48 行
2.8 KiB
Markdown
48 行
2.8 KiB
Markdown
# 设计：报销规范核查与审批文案优化
|
|
|
|
## 边界
|
|
|
|
本任务包含两个相互关联但可独立验证的输出：生产 4 笔报销的只读规范性报告，以及负责人本人财务兜底节点的用户文案修复。前者不写业务数据；后者只调整步骤命名与详情显示投影，不改审批规则、角色、权限或数据库结构。
|
|
|
|
## 数据流
|
|
|
|
### 报销核查
|
|
|
|
```text
|
|
生产只读数据 → 按提交人/日期冻结 4 个业务编号 → 最小字段核查
|
|
→ 对照报销/发票/附件事实源 → 脱敏逐笔结论
|
|
```
|
|
|
|
- 优先使用现有受控生产只读连接或已授权 API 身份。
|
|
- 查询结果只在进程内用于判断；任务文档只登记问题分类、业务编号和必要的非敏感摘要。
|
|
- 不打开或下载原始附件时，只把“需要财务查看原件”列为保留项，不推断真实性。
|
|
|
|
### 审批文案
|
|
|
|
```text
|
|
审批规则解析
|
|
→ 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、配置或数据回滚。
|
|
- 公网部署不在默认执行范围，必须另行明确批准。
|