审批流设计方案的探究

 

审批流属于工作流的范畴，一提起工作流，一般都会觉得那东西太复杂了，确实要做到一个方便的比较通用的工作流不是件简单的事情，但也不是那么难的事情，只是要花多的时间去琢磨和研究。这里我想给大家分享一个项目中涉及的一个审批流的简单的设计方案，完全按工作流的原理去设计可能就比较复杂了，也欢迎大家探讨。

　　此项目中各节点审批环节必须满足的要求：

　　1）要求现实多人多级审批

　　2）只有第一级全部审批意见通过时（一票否决制），下一级审批人员才能进行审批操作。

　　3）若第一级审批有审批不通过和审批通过情况并存，审批通过并送审下级审批，下级审批人员可以看到内容但不能操作。

　　4）若当前审批级别中一个审批人进行了回退回退操作，启动人可以编辑再次送审，无需等待其它他审批人员审批完成。

　　5）第二审批级别(或以上)回退时，重新启动第一级审批操作，启动人重新送审。

　　6）当所有级别的审批人员全部审批同意时，该项目节点完成。

基本上以上要求和一般的审批流程相似，下面是物理数据模型的设计：

　　

　　审批规则对应到节点，一个项目由多个环节（节点组成），如立项，合同订立，发公告等，一个节点可设置一个或多个审批级别，每个审批级别可以设置一个或多个审批角色。项目流程表的数据是当启动一个节点时会向该表插入一条数据，节点状态分为未启动，已启动，送审中，审批完成，审批不通过，当前审批级别和当前审批轮次在节点启动时默认都为1，表示开始从第一级第一轮审批开始，这里的审批轮次是必要的，由上面需求的第4点可确定，之所以有轮次，是由于有审批不通过的情况存在。比如项目启动人送给第一级的两个人（A和B）审批，假设A审批不通过，B审批通过，该级审批是不通过的，启动人可以重新编辑发起该级别的下一轮送审，这里有一个问题需要考虑到，有可能第一轮送审给A,B,C三人，A,B不同意，C没有即使参与第一轮审批，启动人第二轮只送审了A,B，这时审批轮次其实已经到了第二轮了，C之后的审批只是针对第一轮，无论同意与否也不会影响最终结果。但是如果启动人第二轮还是送审了A,B,C三个人，C只会看到一次审批操作而不是两次，那么C此时审批操作会涉及到第一轮和第二轮审批情况，如果C同意，第一轮的意见也会置为同意，这并不矛盾，之前错过审批轮次的意见以最后轮次的意见为主，也就是以最后决定作为判决结果，其实这也就意味着每一级审批通过的条件是已最后一轮的审批全部通过为依据的(如果该级有多轮审批的话)。审批记录表的操作状态分为待审批，审批通过，审批不通过，该表也有审批级别和审批轮次两个字段记录，这两个字段记录与项目流程表里的级别和轮次是不同的，只有当审批记录表的审批级别与项目流程表的当前审批级别相同并且操作状态为待审批时，才可以进行审批操作。审批记录表的审批轮次我们可以理解为操作轮次，因为有可能当前审批轮次到第5轮了，某个审批人员的操作轮次停留在第三轮。下面是流程图，还是有图有真相，直观些。

 

 

图中最大操作轮次是当前审批人参与的最后一轮的审批的轮次，就是之前所说的一个人可能参与多轮审批，之前几轮没有登录系统操作，最后登录审批时一次性审批。这里的最大操作轮次的值始终是小于等于当前审批轮次的值的，每进行一次回退操作，当前审批轮次的值加1，条件是当前最大操作轮次与当前审批轮次的值相等时，因为有两种情况不需要加1，一是同一轮次多人回退时，进入下一轮只需进行一次加1操作，二是当前审批操作的是以前的审批轮次时也不需要加1操作（例如现在已经进入某一级审批的第三轮审批，而审批人进行的是第二轮审批的回退操作），审批操作按钮的显示是根据审批人在审批记录表中是否有当前审批级别的待审记录。

　　下面是验证效果运行图：

　 1）设置立项节点为两级审批

　　

2）用户luce登录系统送审

　　

2) 数据库表数据情况：项目流程表和审批记录表

　　

3）peace登录系统审批通过

　　

4）justlike审批不通过

　　

5）节点情况和数据库记录情况：

　　

　　

6）luce登录系统重新送审

　　

7）peace审批不通过

　　

8）luce在kitty审批前重新送审给peace和kitty

　　

如上图，进入一级审批的第三轮审批

　9）kitty登录系统进行审批操作

　　

　　之前没有审批的第二轮操作，在进行第三轮审批时进行了同样的操作，最后一轮的决定影响以前没有审批过的轮次的决定。

　10）peace登录系统审批通过

　　

　　

第一级审批完成，启动第二级第一轮审批

　　第二轮由jim和kite审批，jim审批的记录有两条，是一级审批第一轮peace送审的和第三轮kitty送审的

11）jim登录系统审批通过

　　

因为立项节点只设置了两级审批，jim属于最高级别审批人员，所以不需再向上送审。

　　

　　

12）kite审批不通过

　　

重新回到第一级审批，启动一审第四轮审批

　　

　　

　　13）节点启动人luce重新送审

　　

　　14）peace登录系统审批通过

　　　　

　　

　　　　peace审批通过时，第一级审批通过，启动第二级审批的第二轮审批

　　

　　15）jim审批通过

　　

　　

　　

　　上图中两级审批通过后节点状态为完成状态

　　

　　

　　模拟的是两级审批，基本上审批过程如上图，这个流程设计还是有一个缺陷地方，如果当前审批级别为二级(或以上级别)，并且有多个人审批，若第一个人审批不通过的话，那么会直接退回到第一级审批，那么处在第二级(或以上级别)有待审记录的操作用户也没法进行审批操作了，因为当前的审批级别已经不是第二级了，重新送审流程走到二级时用户才能操作，上面的截图流程没有走这种情况，当然这并不影响最终的项目节点流程走向。如果要考虑存在的缺陷，那么可能还是要遵从工作流的设计原理了，到此算是写完了，仅供参考，有叙述不正确之处望指正。