3. 审批流核心概念
设计企业付款审批流，第一步不是画流程图，而是把审批流的核心概念拆解清楚。审批节点、审批路径、条件分支、会签、或签、转签、加签这七个概念，构成了所有审批引擎的底层语义。理解它们之间的组合关系，才能避免"流程能跑通但权限失控"的常见问题。
一、核心原理：审批流是一张带条件的图
审批流本质上是一张有向图：节点代表审批动作，边代表流转方向，条件决定走哪条边。付款审批的特殊性在于，它同时承载金额风险控制和岗位职责分离两重要求，因此节点不只是"谁来审"，还包含"审什么、审到哪一级为止"。
- 审批节点：流程中的最小审批单元，包含审批人（角色/岗位/指定人）、审批动作（同意/驳回/加签）和节点属性（是否必填意见、是否允许转签）。
- 审批路径：从发起到结束的完整节点序列。同一张付款单可能因金额、部门、供应商类型走不同路径。
- 条件分支：路径的分叉点，通常基于金额区间、费用类型、预算科目等字段判断。条件分支是权限矩阵落地的关键载体。
关键认知：审批路径不是固定的，而是由条件分支动态计算出来的。设计时要把"路径"理解为"路径集合"，而不是一条线。
二、多人审批的四种语义：会签、或签、转签、加签
当一个节点需要多人参与时，必须明确采用哪种语义。这四种语义直接决定审批结果的计算方式，也是付款审批中最容易配置错误的地方。
| 类型 | 触发方式 | 通过条件 | 典型付款场景 |
|---|---|---|---|
| 会签 | 节点预设多人 | 全部同意才通过 | 大额付款需财务+法务+业务三方确认 |
| 或签 | 节点预设多人 | 任一人同意即通过 | 部门负责人出差时由代理人审批 |
| 转签 | 审批人主动操作 | 被转签人处理，原审批人退出 | 审批人不在岗，转交同权限同事 |
| 加签 | 审批人主动操作 | 新增审批人，原审批人保留 | 付款涉及税务问题，临时加签税务岗 |
会签与或签是节点级配置，在流程设计时确定；转签与加签是运行时操作，由审批人在处理过程中触发。前者影响权限矩阵的静态设计，后者影响流程的动态可追溯性。
三、方法流程：从概念到可执行配置
把七个概念落到审批引擎配置上，建议按以下顺序推进：
- 定义节点清单：列出所有可能的审批角色，如直属主管、部门负责人、财务专员、财务总监、CFO、CEO。
- 绑定条件分支：为每个节点设置进入条件，例如"金额≥50万进入CFO节点"。
- 确定多人语义：对每个节点标注会签或或签，并设置通过阈值。
- 开放运行时操作：决定哪些节点允许转签、加签，并限制转签目标范围。
- 校验路径完整性：确保每条条件分支都能到达终点，不存在死循环或孤立节点。
节点配置示例（伪配置）：
node: finance_director
condition: amount >= 500000
approvers: [role:finance_director]
multi_mode: countersign # 会签
allow_transfer: true
allow_addsign: true
addsign_scope: [tax_manager, legal_manager]
四、案例与场景：一笔80万付款的审批路径
某制造企业发起一笔80万元设备采购付款。系统按条件分支计算路径：金额≥50万，触发"财务总监+CFO"会签节点；供应商为境外主体，触发"法务"或签节点（法务专员或法务经理任一通过即可）。审批过程中，CFO发现涉及跨境税务，主动加签税务经理。最终路径为：直属主管 → 部门负责人 → 财务总监与CFO会签 → 法务或签 → 税务加签 → 出纳付款。
这个案例说明：条件分支决定主干路径，会签/或签决定节点内通过规则，加签在运行时扩展路径。三者叠加，才是真实的付款审批流。
五、误区与复盘：概念混淆带来的权限漏洞
误区一：把"或签"当成"会签"配置。付款审批中，若将财务总监与CFO设为或签，可能导致CFO一人即可放行大额付款，绕过财务总监复核，形成权限漏洞。
误区二：转签不限制目标范围。审批人可将付款单转给无权限人员，导致越权审批。正确做法是转签目标必须落在同一权限矩阵的候选集合内。
复盘建议：每次流程变更后，用"路径枚举法"检查所有条件分支组合，确认每条路径的终点都是合法付款节点，且每个会签节点的通过阈值符合内控要求。
掌握这七个概念后，下一阶段的工作是把它们映射到权限矩阵：节点对应角色，条件分支对应金额与类型阈值，会签/或签对应审批规则，转签/加签对应例外处理策略。概念清晰，矩阵才不会失控。