殊途同归，各有千秋：两种审批流解决方案

审批流是企业中高频业务场景。实现审批流的方法很多，最常见的有两种抽象：

1.BPM方法：工作流引擎。虽然BPM的完整概念是商业业务流程，但是多数开发者把BPM结合国内情况，收敛了BPM的范围，核心约束在：表单+流程的范围，或更缩小到自定义表单+自定义审批流程的范围。BPM的核心是：基础表单，步骤执行人，去向或者去向逻辑。

2.层级审批方法：更本土化的抽象逻辑，形象描述为：一层一层逐级审批。层级审批的特点是，没有步骤的去向概念，而是抽象定义为是和否两个分支。是：则继续下一级别审批；否：则直接结束审批。

BPM方法的资料很多，开源资源也非常丰富，这里不再赘述。我们来谈谈更加贴近本土用户使用习惯的：层级审批实现方案。首先，我们回归到基础场景，以非常典型的单据：订单审批为例，剖析层级审批的设计逻辑。

1.审批的基础业务数据：订单+订单明细+（应收计划）。这里的应收计划很容易在业务角度忽略，实际上，审批订单的核心指标是三个：1）价格2）交期3）应收（计划回款）。如忽略应收数据，则可能会造成大量账期拖延的应收，甚至于带来坏账风险。在我们开发人员看来，应收数据只不过是基础审批中多了一部分数据而已，关系也不复杂，并不需要花这么多篇幅来阐述。实际不然，多数业务管理系统的技术后台并不弱，UI也很现代，但是一旦融入业务运行，就会发现缺胳膊少腿，业务逻辑支离破碎。我们在用户这里学到这样一句话：UI漂亮有什么用？我要跑通业务！当业务管理系统融入了企业的生产运营环境，就会发现：业务顺畅高于一切！

说了半天，回归业务。用户希望是一组以订单为中心的业务数据参与审批，并在审批过程中不要被步骤审批人修改原始数据，且没有经过审批的订单，不允许被执行，不应该纳入销售类统计。

那么我们总结为：1）一组数据参与审批2）锁定参与审批的数据不允许在过程中随意修改3）没有经过审批的数据不得继续执行，且不得纳入统计。（这是很多用户在用了BPM审批流之后，再用超兔的审批流，忽然发现轻松很多的原因之一。在数据层，直接用业务表本表发起审批，并通过审批状态实现业务执行约束和统计约束）

2.审批的层级：层级，审批人。和BMP相比，这里抽象简化了很多内容，因为简化所以在配置审批流时非常简单，只需要两个参数：层级和审批人。因为其弱化了步骤去向的概念，用审批的要义：否决即中止，避免了设置步骤去向。（并不是说步骤去向没有价值，而是由步骤组成流程时，步骤去向必须是完整的闭环，虽然有校验逻辑，但是步骤去向仍然是一个看似简单，实际容易出错的参数）

【超兔CRM设置审批人】

【超兔CRM审批路径条件设置】

【超兔CRM金额自动路径+动态角色】

否决后怎么办？既然层级审批是否决自动中止；申请人希望根据否决意见修改原始数据后继续审批可以吗？可以，被抽象为重新发起审批。在这个过程中，原始业务数据被允许修改的同时，会保留上次参与审批的数据快照，比对是否意见做了合理修改。这里有几个要点1）步骤只有层级和审批人2）任何一步否决即中止，不再继续3）允许申请人在否决后修改业务数据重审，并自动做好数据快照比对。

3.扩展。1）审批人角色扩展，支持上下级关系类的动态角色2）金额分支的扩展（最高频分支，覆盖中小企业审批流分支95%的场景）3）自定义动作（在审批步骤中，可以通过代码插件实现特殊的业务动作）

综上，我们完整分析了层级审批流的解决方案。从第一视觉上，它没有BPM看起来更花俏，但是在业务层却远比BPM更实用，更便捷。