记录动态审批节点验证(07-27-yang-jun-reimbursement-readiness)
这个提交包含在:
@@ -274,7 +274,9 @@ processingProgress.stages[] = {
|
|||||||
}
|
}
|
||||||
```
|
```
|
||||||
|
|
||||||
- 服务端始终生成“申请提交、主管审批、财务复核、付款批次复核、付款与回单”五个业务阶段。workflow 阶段按提交快照的职责节点映射;不暴露内部 step ID、角色码或权限码。
|
- 服务端固定生成“申请提交”以及“付款批次复核、付款与回单”首尾阶段;中间审批段先按查询的 `created_at,id` 顺序逐项生成真实 task,每个 task 拥有独立 stage key,不再用职责 Map 合并;再从提交时 `workflow_steps_snapshot` 的当前节点之后补齐尚未创建 task 的未来 pending 节点。当前两步审批规则从刚提交起就返回五个阶段,新增或重复角色节点会自然增加时间轴节点,不得丢失、覆盖或因延迟建任务而暂时消失。
|
||||||
|
- 审批标题优先使用非空且不属于“步骤/节点/step + 序号”的 `step_name`;否则把 `manager` 映射为“主管审批”、`finance|finance_mgr` 映射为“财务复核”、`ceo` 映射为“负责人复核”,其余统一为“审批”。标题和详情均不暴露原始 step ID、角色码或序号。
|
||||||
|
- workflow 实例已创建但 `workflow_tasks` 暂为空时,中间审批段按提交快照生成无姓名 pending 节点;workflow 整体不存在时才回退为“主管审批、财务复核”默认占位,避免申请刚提交时出现空白进度。
|
||||||
- workflow task 提供实际 assignee/completer/outcome,history 提供动作、意见和时间。已完成取实际 completer/actor,当前取真实 pending assignee;未来 task 尚未创建时 `actorName=null`,严禁按当前角色持有人猜姓名。
|
- workflow task 提供实际 assignee/completer/outcome,history 提供动作、意见和时间。已完成取实际 completer/actor,当前取真实 pending assignee;未来 task 尚未创建时 `actorName=null`,严禁按当前角色持有人猜姓名。
|
||||||
- 付款汇总读取与当前报销关联的最新 `PaymentBatchItem` 及其 batch,只选择状态、制单/复核/执行人员与时间和未归档回单计数,不返回批次其他报销、金额或材料。只有具备现有付款批次读取权限时才返回可跳转的 batch href。
|
- 付款汇总读取与当前报销关联的最新 `PaymentBatchItem` 及其 batch,只选择状态、制单/复核/执行人员与时间和未归档回单计数,不返回批次其他报销、金额或材料。只有具备现有付款批次读取权限时才返回可跳转的 batch href。
|
||||||
- 没有批次时付款复核 detail 为“待财务创建付款批次”;draft 为“所在付款批次待非制单人复核”;reviewed 为“所在付款批次已复核,待执行付款”;failed/cancelled 如实表达失败或待重新创建。不得写成“您的报销待复核”。
|
- 没有批次时付款复核 detail 为“待财务创建付款批次”;draft 为“所在付款批次待非制单人复核”;reviewed 为“所在付款批次已复核,待执行付款”;failed/cancelled 如实表达失败或待重新创建。不得写成“您的报销待复核”。
|
||||||
@@ -285,6 +287,6 @@ processingProgress.stages[] = {
|
|||||||
### 13.6 验证与回退
|
### 13.6 验证与回退
|
||||||
|
|
||||||
- 后端覆盖迁移、PATCH/GET/submit 字段合同、日期倒置、非差旅报销不误拦截、关联差旅申请摘要与旧单降级。
|
- 后端覆盖迁移、PATCH/GET/submit 字段合同、日期倒置、非差旅报销不误拦截、关联差旅申请摘要与旧单降级。
|
||||||
- 后端补充五阶段 DTO 的 pending/approved/paid、退回/驳回、batch 五种状态、回单有无、三个来源独立缺失、未来节点无姓名和付款链接权限测试。
|
- 后端补充进度 DTO 的 pending/approved/paid、退回/驳回、batch 五种状态、回单有无、三个来源独立缺失、未来节点无姓名和付款链接权限测试;另覆盖第三个未知职责节点、两个同角色节点互不覆盖、未来快照节点尚无 task、实例存在但 tasks 为空四条边界。
|
||||||
- 前端覆盖 PC/移动四块顺序、单头差旅填写/只读、材料列表与合并入口、五阶段紧凑时间轴、加载反馈、企微原件预览和 375px/横屏。
|
- 前端覆盖 PC/移动四块顺序、单头差旅填写/只读、材料列表与合并入口、变长审批节点紧凑时间轴、加载反馈、企微原件预览和 375px/横屏;组件只按数组 `map` 渲染,不按固定长度或位置解释职责。
|
||||||
- 若 JPEG/并发修复未通过目标镜像与合成火车票验收,回滚应用代码到现有 PNG 串行路径,保留原件降级;不删生产数据或回滚整库。
|
- 若 JPEG/并发修复未通过目标镜像与合成火车票验收,回滚应用代码到现有 PNG 串行路径,保留原件降级;不删生产数据或回滚整库。
|
||||||
|
|||||||
@@ -229,6 +229,22 @@
|
|||||||
- [x] 运行 Prisma validate、touched-file `node --check`、server 聚焦/必要全量、client typecheck/build、聚焦 Playwright、task/Trellis/process/docs/sensitive/diff 门禁;只读 review 跨 workflow/付款状态映射与权限,不让 reviewer 改代码。
|
- [x] 运行 Prisma validate、touched-file `node --check`、server 聚焦/必要全量、client typecheck/build、聚焦 Playwright、task/Trellis/process/docs/sensitive/diff 门禁;只读 review 跨 workflow/付款状态映射与权限,不让 reviewer 改代码。
|
||||||
- [ ] 实现完成后分别申请提交、推送和生产部署批准;部署与公网检查通过前不通知真人测试,不执行真实审批、付款或回单写入。
|
- [ ] 实现完成后分别申请提交、推送和生产部署批准;部署与公网检查通过前不通知真人测试,不执行真实审批、付款或回单写入。
|
||||||
|
|
||||||
|
## 6.17 审批节点数据驱动修正
|
||||||
|
|
||||||
|
- [x] 移除 `classifyApprovalTask` + 阶段键 Map 覆盖路径;固定首尾业务阶段,中间按 `workflow_tasks` 的真实稳定顺序逐任务生成唯一节点,并按提交快照补齐尚未创建 task 的未来审批节点。
|
||||||
|
- [x] 节点标题按“可读 step name → assignee role 职责映射 → 审批”降级,过滤“步骤/节点/step + 序号”,不显示 step ID、角色码或序号。
|
||||||
|
- [x] workflow 整体不存在时保留主管/财务 pending 占位,实例 tasks 暂为空时按快照展示;前端 stage key 改为可扩展字符串并继续纯 `map` 渲染,不增加固定位置判断。
|
||||||
|
- [x] 新增第三个未知职责节点、两个同角色节点、未来快照尚无 task、空 task 实例单元测试,并复跑 `reimbursement-workflow-progress.spec.ts` 及既有四块/企微聚焦回归。
|
||||||
|
- [x] 重新运行后端聚焦与全量、Prisma、前端 typecheck/build、Trellis/process/docs/sensitive/diff 门禁;更新稳定审批投影规约后申请提交,随后按本轮授权推送、部署和公网检查。
|
||||||
|
|
||||||
|
验证记录:
|
||||||
|
|
||||||
|
- 服务端聚焦 16 项通过;最终全量 171 个文件、1129 项通过,Prisma validate 与 touched route `node --check` 通过。
|
||||||
|
- 前端 typecheck/生产 build 通过;Wave3 + R111 聚焦 2/2 通过,Wave3 同时覆盖 PC/移动 6 节点变长时间轴。
|
||||||
|
- `reimbursement-workflow-progress.spec.ts` 首轮在临时库首次改密页停止;隔离处理种子账号后,依次暴露手工服务未启 jobs、共享 Page Object 仍等待已不展示的文件名、盲取差旅费用类型却未填概要、旧断言硬编码主管/财务五阶段四个既有测试漂移。逐项收紧测试编排与断言后,最终真实临时 PostgreSQL + server + Mock OCR 路径 1/1 通过;应用认证、OCR、差旅和 workflow 生产合同未为测试放宽。
|
||||||
|
- workflow 实际只创建当前 task 的核查促使 DTO 继续用提交快照补齐未来 pending 审批节点;单元测试覆盖第三节点、同角色双节点、未来 snapshot-only 节点和空 tasks 实例。
|
||||||
|
- 本轮唯一明确命名的临时测试库已关闭服务并删除;未读取或写入生产业务数据,未执行真实审批、付款或回单。
|
||||||
|
|
||||||
## 7. 完成条件
|
## 7. 完成条件
|
||||||
|
|
||||||
- [ ] PRD 全部验收项有脱敏证据或明确由用户完成的真实业务验收结果。
|
- [ ] PRD 全部验收项有脱敏证据或明确由用户完成的真实业务验收结果。
|
||||||
|
|||||||
@@ -52,8 +52,8 @@
|
|||||||
- 当前真实报销为“空白报销”创建且未关联差旅申请,现有数据模型没有独立的出差事由、地点和起止日期,因此详情页无法显示完整差旅概要。轻量差旅报销必须直接持久化这四项可选业务字段;存在任一差旅费用明细时,草稿/驳回态提交前必须补齐。既有审批中单据不自动伪造或回填地点;可以只读显示报销说明和明细日期的明确降级值,需完整补齐时由主管退回后申请人修改。
|
- 当前真实报销为“空白报销”创建且未关联差旅申请,现有数据模型没有独立的出差事由、地点和起止日期,因此详情页无法显示完整差旅概要。轻量差旅报销必须直接持久化这四项可选业务字段;存在任一差旅费用明细时,草稿/驳回态提交前必须补齐。既有审批中单据不自动伪造或回填地点;可以只读显示报销说明和明细日期的明确降级值,需完整补齐时由主管退回后申请人修改。
|
||||||
- KISS 复核确认只读审批人仍需要知道本单有哪些原始材料。PC 与移动端“报销材料”区必须始终显示有序材料列表,整行点击只预览该份原件;“查看材料合并预览”保留为列表上方的一次通览动作。只读审批人不得看到移除、删除或票据池管理动作,费用明细仍不重复展示发票。
|
- KISS 复核确认只读审批人仍需要知道本单有哪些原始材料。PC 与移动端“报销材料”区必须始终显示有序材料列表,整行点击只预览该份原件;“查看材料合并预览”保留为列表上方的一次通览动作。只读审批人不得看到移除、删除或票据池管理动作,费用明细仍不重复展示发票。
|
||||||
- 草稿/驳回报销出现差旅类明细且四项差旅概要不完整时,PC 与移动端应直接显示带标签的填写表单,不先展示四个“未填写”再要求用户点击编辑;概要完整后恢复紧凑只读摘要并保留编辑入口。不新增“普通/差旅”选择,不改变现有字段、差旅判定、提交校验或差旅申请关联规则。
|
- 草稿/驳回报销出现差旅类明细且四项差旅概要不完整时,PC 与移动端应直接显示带标签的填写表单,不先展示四个“未填写”再要求用户点击编辑;概要完整后恢复紧凑只读摘要并保留编辑入口。不新增“普通/差旅”选择,不改变现有字段、差旅判定、提交校验或差旅申请关联规则。
|
||||||
- “处理进度”必须使用移动端友好的纵向时间轴,固定表达五个业务阶段:申请提交、主管审批、财务复核、付款批次复核、付款与回单。节点名使用职责而非序号;已完成节点显示实际处理人/时间/结果,当前节点显示实际待办人(可取得时),未来节点不得预填姓名。退回、驳回和有内容的意见必须展开,普通已完成节点压成一行。
|
- “处理进度”必须使用移动端友好的纵向时间轴。申请提交、付款批次复核、付款与回单是固定业务阶段;中间审批段按当前 workflow 实例的真实任务顺序逐项展开。当前生产规则仍自然形成“申请提交、主管审批、财务复核、付款批次复核、付款与回单”五阶段,但未来新增或重复角色审批节点时不得丢失、覆盖或错误提前显示付款。节点名使用职责而非序号;已完成节点显示实际处理人/时间/结果,当前节点显示实际待办人(可取得时),未来节点不得预填姓名。退回、驳回和有内容的意见必须展开,普通已完成节点压成一行。
|
||||||
- 五阶段是跨状态机只读投影,不把付款批次塞入 workflow。服务端从 workflow 快照/任务/历史、报销付款字段、当前关联付款批次和回单计数生成安全 DTO;任一来源缺失时仅把对应下游节点降级为“待处理”,前面已完成节点继续返回。付款批次为共享对象,节点文案必须写“所在付款批次…”,不能暗示单张报销自身再次被审批。
|
- 处理进度是跨状态机只读投影,不把付款批次塞入 workflow。服务端从 workflow 快照/任务/历史、报销付款字段、当前关联付款批次和回单计数生成安全 DTO;已发生/当前审批逐条使用真实 task,尚未创建的未来审批按提交快照补 pending 占位,workflow 实例存在但任务尚未落库时也按快照展示,不因延迟建任务而出现空白;仅在 workflow 整体缺失时使用主管/财务默认占位。任一来源缺失时仅把对应下游节点降级为“待处理”,前面已完成节点继续返回。审批节点标题按“非序号化 step name → assignee role/快照规则职责映射 → 审批”降级,永远不向界面显示原始 step ID、角色码或“步骤 N”。付款批次为共享对象,节点文案必须写“所在付款批次…”,不能暗示单张报销自身再次被审批。
|
||||||
|
|
||||||
## Scope
|
## Scope
|
||||||
|
|
||||||
@@ -102,6 +102,7 @@
|
|||||||
- [x] PC 与移动报销详情只保留四个稳定内容块;差旅概要并入单头,关联、风险、付款和操作均按数据/权限条件呈现,不形成永久空版块,不增加 Tab 或折叠。
|
- [x] PC 与移动报销详情只保留四个稳定内容块;差旅概要并入单头,关联、风险、付款和操作均按数据/权限条件呈现,不形成永久空版块,不增加 Tab 或折叠。
|
||||||
- [x] “处理进度”按五阶段纵向显示,不出现“第 N 步”;当前责任、实际处理人、时间、结果及必要意见清楚,未来节点无姓名,付款批次共享语义准确。
|
- [x] “处理进度”按五阶段纵向显示,不出现“第 N 步”;当前责任、实际处理人、时间、结果及必要意见清楚,未来节点无姓名,付款批次共享语义准确。
|
||||||
- [x] workflow、付款批次或回单任一来源缺失时进度 DTO 和页面均安全降级,已知节点不丢失;批次 draft/reviewed/executed/failed/cancelled 与回单有/无均有合成回归。
|
- [x] workflow、付款批次或回单任一来源缺失时进度 DTO 和页面均安全降级,已知节点不丢失;批次 draft/reviewed/executed/failed/cancelled 与回单有/无均有合成回归。
|
||||||
|
- [x] workflow 中第三个未知职责节点和多个同角色节点均按真实顺序完整显示且互不覆盖;实例存在但任务为空时审批段仍显示安全占位,前端不假设固定节点数。
|
||||||
|
|
||||||
## Out of Scope
|
## Out of Scope
|
||||||
|
|
||||||
|
|||||||
在新工单中引用
屏蔽一个用户