背景
#23 全流程实测发现:一期实现里「分公司核对(并行)」节点由状态机按方案内全部分公司参与主体统一生成核对任务(除本主体自己那张单),没有「每条指标下达指定核对方」的能力。结果是研发部、财务部等与分公司无关的填报单也要 3 家分公司逐一确认,分公司核对人员的「待我核对」队列里充满与本分公司无关的单据。
需求文档 §1.1 的原始表述是「每个部门需要和不同的分公司核对数据」,设计方案表 2 第 4 步写「方案里没有需要核对的分公司时自动跳过本节点」——两处都是下达级的口径(哪条下达涉及哪家分公司),实现是方案级。维护者 2026-09-03 拍板:#23 按现状合并,本项另立工作项。
待细化事项(需 PM / 客户确认后才能进开发)
- 核对方的粒度:按指标下达指定(一条下达可指定 0~N 家分公司)/ 按参与主体指定(某部门固定由哪些分公司核对)/ 两者都要。
- 无核对方的填报单是否跳过「分公司核对」节点直接进人力审核(设计方案表 2 已写「自动跳过」,需确认在按下达路由后仍成立)。
- 驳回退回核对节点时,是否只让「相关分公司」重新核对(现口径第 10 章第 8 项:全部分公司重新核对)。
- 与设计方案 V1.1 第 27 项「审批人来源扩展与退回节点」是否合并处理。
影响面(方案分级预判:高风险)
- 数据模型:指标下达(或参与主体)新增核对方字段;
- 状态机:
src/hooks/sheet.hook.ts 生成核对任务与「全部确认才推进」的判定要按路由后的集合计算——改已有状态机,必须先过 os-project-dev-design 方案分级;
- 发布检查:核对方引用的分公司必须是参与主体;
- 数据范围:分公司核对人员只见与本分公司相关的核对任务(现状已按任务共享,路由后自然收窄)。
就绪门禁
以上 4 项待确认事项有答复、方案分级通过后再切「待开发」。在此之前不派发。
背景
#23 全流程实测发现:一期实现里「分公司核对(并行)」节点由状态机按方案内全部分公司参与主体统一生成核对任务(除本主体自己那张单),没有「每条指标下达指定核对方」的能力。结果是研发部、财务部等与分公司无关的填报单也要 3 家分公司逐一确认,分公司核对人员的「待我核对」队列里充满与本分公司无关的单据。
需求文档 §1.1 的原始表述是「每个部门需要和不同的分公司核对数据」,设计方案表 2 第 4 步写「方案里没有需要核对的分公司时自动跳过本节点」——两处都是下达级的口径(哪条下达涉及哪家分公司),实现是方案级。维护者 2026-09-03 拍板:#23 按现状合并,本项另立工作项。
待细化事项(需 PM / 客户确认后才能进开发)
影响面(方案分级预判:高风险)
src/hooks/sheet.hook.ts生成核对任务与「全部确认才推进」的判定要按路由后的集合计算——改已有状态机,必须先过 os-project-dev-design 方案分级;就绪门禁
以上 4 项待确认事项有答复、方案分级通过后再切「待开发」。在此之前不派发。