审批流与权限模型

用途：设计企业系统的审批链路、代理与权限边界

审批流的两种实现路径

路径	做法	优点	缺点
工作流引擎	流程定义（BPMN 类）、任务中心、会签/或签	可视化、可配置、支持复杂人工环节	引擎与业务状态易混淆，规则外置后不可测试
代码内状态机	状态 + 迁移 + 审批任务表	规则集中可测、性能好	流程变更需发版

关键分工（与状态机建模一致）：引擎负责“谁在什么时候处理待办”，业务状态机负责“业务状态是否允许这次变更”。让引擎直接改业务状态字段，是规则失控的起点。

常见审批模式

模式	说明	坑
串行多级	逐级批准	任一级卡住整体停滞，需要超时提醒与代理
会签	全部通过	一人拒绝即失败，需明确是否允许部分人委托
或签	任一人通过	责任稀释，需记录实际处理人
条件分支	按金额、品类、组织路由	规则表要可查可审计，避免“黑盒路由”
加签/转签	临时增加审批人	权限边界需校验，避免越权
撤回与驳回	发起人撤回、审批人驳回	状态回退必须留痕并允许重新提交（版本化）
免审与自动通过	目录内、限额内自动放行	需明确风险边界与事后抽查机制

权限模型

企业系统通常需要组合三种模型：

RBAC（角色）：功能权限（能点什么按钮、能进哪个页面）。
数据权限（行级）：能看到哪些数据——按组织、采购范围、品类、供应商归属、金额区间过滤。
字段级权限：银行账户、成本价、折扣等敏感字段按需可见。

实现要点：数据权限必须在查询层统一注入（拦截器/视图对象），而不是每个接口手写条件——后者必然漏。

职责分离（SoD）

内控要求的关键约束，常见互斥组合：

供应商准入审批 ≠ 供应商主数据维护（尤其银行账户）。
下单人 ≠ 收货确认人（金额阈值以上）。
付款申请人 ≠ 付款审批人 ≠ 支付执行岗。
同一单据的发起人与最终审批人不得为同一人（含代理链）。

系统应把互斥规则做成配置并在校验点强制，而不是靠制度文档。

代理与例外

场景	处理
休假代理	设生效期与范围，代理行为留痕（实际处理人 + 委托人）
离职	待办强制转移，禁止“无人认领”的挂起任务
紧急放行	允许“先执行后补审”，但必须生成补审任务并统计发生率
审批超时	自动升级或代理，避免流程死等

常见误区

误区	修正
审批规则写在流程配置里，代码无法测试	业务状态与规则回到代码，引擎只管待办
数据权限逐接口实现	统一在查询层注入，并做越权测试
代理无期限	代理必须有生效期与范围
撤回直接改状态	用版本化与状态迁移历史
紧急放行无统计	事后补审率是内控指标，必须看板化
只记录“审批通过”不记录意见	关键决策需要理由与依据留痕

延伸阅读

BPMN 2.0 规范与工作流参考模型（WfMC）
COSO 内控框架中职责分离与授权审批的公开资料
主流工作流引擎（Flowable、Camunda、Activiti）文档