① 基本信息
| 问题描述 | 项目的调管单位为广西中调，实际并网容量审核提交后，显示发送给了外网用户自己审核，更新中调人员没有接收到审核信息 |
|---|---|
| 一级模块 | 实际并网流程 |
| 二级模块 | / |
| 涉及类型 | 集中式新能源 |
| 所属区域 | 五区 |
| 严重性 | 严重 |
| 当前状态 | 2.1.待开发 |
| 研发处理人 | 何佳星 |
| 处理说明 | 待调整 |
② 问题截图
③ 旧代码涉及的项目文件及行数
xnybw5f / src/views/projectNew/components/actualInfo/components/tabItem.vue
第 136 行引入 soWorkFlowEvent；第 483 行 soWorkFlowEvent.send(true, ress.data, '/th-new-energy-grid-three-web', '同意', ...)（实际并网容量提交送审入口）
projectActualApi.cascadeQuery({ id: resReId.data }).then(ress => {
soWorkFlowEvent.send(true, ress.data, '/th-new-energy-grid-three-web', '同意', async () => {
let todo = null
await projectActualApi.cloudDesktopLoadTodoVO(ress.data).then(result => { todo = result.data })
return Promise.resolve(todo)
}).then((res) => { ... })
})
与 row58 的排查结论一致：
cascadeQuery 接口在 xnybw5b（730backup）自有 Java 源码中检索不到实现类，说明它由平台共享框架依赖（so-integration-* 一类 jar）提供；"提交后流程下一环节该发给谁"这个候选人/收件人计算，是通过 soWorkFlowEvent.send(...) 交给三区应用 /th-new-energy-grid-three-web 及其背后的工作流引擎（BPMS）完成的，并不是 xnybw5f/xnybw5b 自己写的路由分发代码。
参考对照（同一批缺陷中的类似白名单问题）：Excel 第 8 行
"部分调管单位如广东中调、深圳中调，上传资料后点击提交流程直接归档，未走审核流程，广西中调、南方总调可以正常流转"，处理说明写的是"待调整，白名单筛选，只有总调和广西走流程"
第8行的现象恰好印证了"广西中调"在现有白名单/流程配置中理论上是"可以正常走流程"的单位；本条（第59行）广西中调项目确实进入了流程（没有像广东/深圳中调那样被直接归档），问题出在进入流程后，"中调审核"这个环节的目标处理人被解析成了提交人自己，而不是广西中调对应的真实审批人员。这个"环节目标处理人"的解析逻辑同样落在三区/工作流引擎一侧（见上），backup730/730backup 里没有找到"调管单位→审批人"的映射代码。
④ 修复代码涉及的项目文件及行数
未能在 backup730/730backup 中定位到"中调审核环节目标处理人计算"的具体实现代码（该逻辑运行在三区应用与工作流引擎内部），因此不编造五区侧的代码修改点。
⑤ 修复方案
结合 row58、row59 两条记录的排查结果，"环节发送候选人为空"（row58）与"环节目标处理人解析成提交人自己"（row59）本质上是同一类问题：五区（xnybw5f/xnybw5b）只是流程的发起方，通过 cascadeQuery + soWorkFlowEvent.send(..., '/th-new-energy-grid-three-web', ...) 把待办数据投递给三区应用，"这个环节该指派给谁"的计算逻辑运行在三区侧及其对接的工作流引擎（BPMS）中，backup730/730backup 两个仓库里都没有相关实现。
建议：由三区团队排查"中调审核"环节的处理人指派规则，重点确认"调管单位=广西中调"这一条件下，工作流引擎的用户/角色映射配置（或映射接口）是否正确关联到了真实的广西中调审核人员，而不是把发起人自身错误地当作了目标环节的处理人（这通常是流程定义里"发起人=下一节点处理人"的兜底/默认规则被错误触发，或角色查询返回空导致回退到发起人）。五区侧若确有可优化点，是在
cascadeQuery 请求时核实是否正确传递了项目的"调管单位"字段供工作流引擎使用（当前 tabItem.vue 提交时只传了 id，具体传参是否足够需由三区/框架侧确认接口契约）。