工作流&审批流的思考

1.背景

以前一直不了解，为什么需要自定义审批流，很早的时候接触到的审批流都是固定。需要在写需求的时候确定好，工作流的逻辑是什么，也对审批流缺乏最真实的了解。这一次，公司的后台系统需要我重新设计审批流，我才慢慢窥探到审批流的真正用意。所以想记录下来，这次思考的过程，希望今后可以提炼出来，做出属于自己的“架构”。

2.了解

平台工作流&审批流的定义

工作流：可以自定义的一种自动运行的工作流程，由单据的数据发生改变时或者按钮触发事件，导致连锁产生下一条事件。
审批流：可以自定义的一种自动运行的审批流程，需要有权限的用户操作同意才会触发下一步事件， 触发审批流需要满足审批的条件和规则。

工作流的优点

• 减少了工作流程，在任务指派中减少不必要的操作；
• 建立标准化的流程，提高工作效率；

业务场景

工作流：部门给财务部门提交设备审批，由实施部门员工提交到部门经理中，由部门经理审批通过后发送给财务部门，财务部门通过内部审批后合并采购。
审批流：审批流主要定义其中实施部门提交给谁进行审批，审批完成后是否进入到下一个阶段， 需要有系统业务人员对流程进行定义。被定义后业务单据根据定义好的流程进行传递。

概述

• 流程：指某业务中的详细顺序，例：请假、采购、报销；
• 步骤：指某一种特定业务的封装类型；

审批流程

• 流程定义；
• 步骤定义：触发规则；操作人；执行操作（发起审批、驳回）；业务操作（通知、字段变化、移动数据、生成单据）；
• 步骤反复：触发条件；操作者（串签、并签）；业务动作（审批处理：驳回、委托、转办、批准、抄送）；业务操作（批准、拒绝包含（通知、通知、字段变化、移动数据、生成单据）操作）；
• 流程结束；

3.术语定义

操作人处理

• 串签：用户1操作完成后用户2进行审批，其他用户不可进行查看和操作，必须由上一位处理完成后，下一位才能处理。
• 并签：用户1操作完成后用户2、用户3、用户4…，均可以处理，任意一位用户处理完成后，任务均完成，流转到下一阶段。
• 会签：用户1操作完成后用户3、用户3、用户4…，均要求处理，全部处理完成后，任务才完成，流转到下一阶段。

按钮动作

• 申请：针对当前单据进行申请，开始进入审批流。由操作人手动提交申请，由程序根据条件判断是否满足触发条件，然后发送申请通知。
• 批准：当前单据审核通过后，点击批准，单据流转到下一个节点，若为终结点，则流程完成。
• 驳回：流程直接结束，单据返回至第一步骤。
• 转办：将审批单据转移到另一个用户处理，被转转办人处理后，单据流转到下一个节点。
• 委托：将审批单据让另一用户处理，处理完成后，单据流回到委托人。
• 抄送：当前单据创建子节点， 指定一个或多个分配人，这些子任务不会挂到相应的审批流中去，不参与节点流转。
• 协办：当前任务创建两个子节点，任意一个用户完成后流转到下一个节点。

运行操作

• 通知：定义好系统内的单据通知触发规则，在流转运行中适当发送通知消息给相关人员。
• 数据更新：根据数据流程的事务，能够在流转到相应位置，根据提前预设好的规则进行数据改变，指定表单数据进行更新，或者关联相应数据发生改变。
• 表单转换：设置表单数据，根据要求转换成一个新的单据。假设表单中拥有子扁担，也可以设置对应关系到到新的单据子单据中去。
• 数据流转：可以将表单中的数据转移到目标用户，可以将数据存在工作流和审批流中。如果需要数据流转可以直接调用此数据。
• 传递接口：工作流和审批流结果触发跳转到第三方系统；