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

1、殊途同归，各有千秋：两种审批流解决 方案审批流是企业中高频业务场景。实现审批流的方法很多，最常见的有两种抽象:BPM方法工作流引擎。虽然BPM的完整概念是商业业务流程，但是多数开发者把BPM 结合国内情况，收敛了 BPM的范围，核心约束在：表单+流程的范围，或更缩 小到自定义表单+自定义审批流程的范围。BPM的核心是：基础表单，步骤执 行人，去向或者去向逻辑。2)层级审批方法更本土化的抽象逻辑，形象描述为：一层一层逐级审批。层级审批的特点是，没 有步骤的去向概念，而是抽象定义为是和否两个分支： 是：继续下一级别审批否：直接结束审批BPM方法的资料很多，开源资源也非常丰富，这里不再赘述。我们来谈

2、谈更加 贴近本土用户使用习惯的层级审批实现方案。首先，我们回归到基础场景，以非常典型的单据订单审批为例，剖析层级 审批的设计逻辑。审批的基础业务数据：订单+订单明细+ （应收计划）。这里的应收计划很容易 在业务角度忽略，实际上，审批订单的核心指标是三个：.价格.交期.应收（计划回款）如忽略应收数据，那么可能会造成大量账期拖延的应收，甚至于带来坏账风险。在 我们开发人员看来，应收数据只不过是基础审批中多了一局部数据而已，关系也 不复杂，并不需要花这么多篇幅来阐述。实际不然，多数业务管理系统的技术后台并不弱，UI也很现代，但是一旦融入 业务运行，就会发现缺胳膊少腿，业务逻辑支离破碎。我们在用户这里

3、学到这样 一句话：UI漂亮有什么用？我要跑通业务！当业务管理系统融入了企业的生产 运营环境，就会发现：业务顺畅高于一切！说了半天，回归业务。用户希望是一组以订单为中心的业务数据参与审批，并在 审批过程中不要被步骤审批人修改原始数据，且没有经过审批的订单，不允许被 执行，不应该纳入销售类统计。那么我们总结为：一组数据参与审批锁定参与审批的数据不允许在过程中随意修改没有经过审批的数据不得继续执行，且不得纳入统计（这是很多用户在用了 BPM审 批流之后，再用超兔的审批流，忽然发现轻松很多的原因之一。在数据层，直接用 业务表本表发起审批，并通过审批状态实现业务执行约束和统计约束）审批的层级：层级，审批

4、人。和BMP相比，这里抽象简化了很多内容，因为简 化所以在配置审批流时非常简单，只需要两个参数层级和审批人。因为其弱化了步骤去向的概念，用审批的要义：否决即中止，防止了设置步骤去 向（并不是说步骤去向没有价值，而是由步骤组成流程时，步骤去向必须是完整 的闭环，虽然有校验逻辑，但是步骤去向仍然是一个看似简单，实际容易出错的 参数）。否决后怎么办？既然层级审批是否决自动中止，申请人希望根据否决意见修改原 始数据后继续审批可以吗？可以，被抽象为重新发起审批。在这个过程中，原始业务数据被允许修改的同时，会保存上次参与审批的数据快 照，比对是否意见做了合理修改。这里有几个要点：步骤只有层级和审批人任何一步否决即中止，不再继续允许申请人在否决后修改业务数据重审，并自动做好数据快照比对扩展：审批人角色扩展，支持上下级关系类的动态角色金额分支的扩展（最高频分支，覆盖中小企业审批流分支95%的场景）自定义动作（在审批步骤中，可以通过代码插件实现特