审批流程中的会签与或签，关键区别是一个节点何时算通过：会签通常要求指定审批者全部同意，或签通常允许其中一人同意。但“出现一票拒绝怎么办”“其他待办何时关闭”“退回后重审哪些人”必须另写规则，不能从这两个名称自动推导。
以采购申请同时交给财务和业务负责人为例，可以先用墨刀原型演示申请与审批待办的联动，把申请人、两名审批者和下一节点的视角放在同一评审中。画出两条箭头只是开始，真正需要确认的是每一次决定改变了哪些状态。
把人员、顺序和通过条件拆开
“会签”不一定意味着大家同时审批，也可以按顺序依次处理。“两个人审批”也不意味着一定要两人同意。产品规格应分别记录审批人如何确定、任务并行还是串行、什么条件结束当前节点。
Camunda多实例活动文档分别描述执行方式与完成条件，可以帮助理解这几个维度为什么不能混为一谈。这里借用这种建模思路，不要求业务系统必须采用某个流程引擎。
| 规则 | 本例会签 | 本例或签 |
|---|---|---|
| 审批者 | 财务A、业务B | 同岗值班人员A、B |
| 执行方式 | 并行发出待办 | 并行发出待办 |
| 通过条件 | A与B均同意 | A或B任一人同意 |
| 拒绝规则 | 任一人拒绝即退回申请人 | 所有人拒绝才退回；一人拒绝仍等待另一人 |
| 节点结束后 | 保留决定记录，进入下一节点 | 取消尚未处理的待办并说明已由他人完成 |
表中拒绝策略是本例业务约定，不是“或签”的通用法律。另一个团队可能要求任一人拒绝就结束；允许哪种规则，应由业务风险、职责和审批目的决定，并在配置界面或说明中写清。
一张申请要有申请状态，也要有个人任务状态
A已经同意、B尚未处理时，申请整体可能仍是“审批中”，A的个人任务则是“已同意”。若列表只显示一个状态，A可能误以为自己的操作没有保存，申请人也看不出还在等谁。
详情页可同时展示整体进度和节点记录：采购申请审批中；财务A已同意；业务B待处理。审批意见、操作时间和当时角色与记录一起保存。组织里的人员后来改名或转岗，不应把历史决定改成看不懂的空白。
若用户只需要查看自己待办，默认列表不必展示所有节点细节；进入详情后再提供完整关系。页面信息密度应服务当前任务，不能为了“透明”把整条流程压成难读的长表格。
退回修改后，旧同意是否还有效
财务拒绝后，申请人把金额从8000改为12000，业务负责人先前的同意不能被默认当成对新金额的同意。审批实际上针对某个申请版本，需要记录决定绑定的是哪一版内容。
本例采用简单规则：退回后修改并重新提交，当前节点全部重新审批；详情保留上一轮记录，但不计入新一轮通过条件。若业务希望只重审受影响的人，应先定义哪些字段影响哪些审批者，并显示重审原因，而不是交给系统随意判断。
申请人撤回与审批者退回也不同。撤回是否允许、何时禁止、是否终止现有待办，都应独立定义。已经进入付款等后续执行阶段，不能把撤回申请等同于撤销所有实际业务结果。
处理同时操作，避免旧页面再次决定新状态
或签中A刚同意，B仍打开着原来的审批页。如果B随后点击拒绝，系统应重新判断该任务是否仍有效，再给出“已由A完成，当前无法继续审批”的反馈。只在界面上隐藏按钮不足以解决并发问题，提交时仍须由服务端核验。
类似地，审批页打开后申请被撤回，或流程管理员更换了审批人，旧页面都不能继续生效。原型里可演示状态更新与提示，技术交付则要约定任务编号、申请版本、重复提交和已结束任务的返回结果。
对于加签，要明确新增的人属于当前通过集合还是只提供意见；对于转交，要明确原审批者是否失去处理权。若本期不支持这些能力，写为不支持即可，不必为了“流程完整”画出无法兑现的按钮。
用六条路径检查节点规则
- 会签：A同意、B同意，整体只推进一次。
- 会签：A同意、B拒绝，申请退回，旧同意留在上一轮。
- 或签：A同意、B未处理，B待办结束并说明原因。
- 或签：A拒绝、B同意，按本例规则通过。
- 申请退回后修改金额，重新提交，审批者看到新旧差异。
- 同一待办被重复提交，或提交时已经结束，不重复推进后续任务。
更完整的工作台、组织和通知设计，可与OA系统整体规划衔接。先让一个审批节点的行为明确，再复制到更多流程，比先画几十种模板更能减少实现分歧。
