点击上方“芋道源码”，选择“设为星标”
管她前浪，还是后浪？
能浪的浪，才是好浪！
每天 10:33 更新文章，每天掉亿点点头发...
源码精品专栏
OA(office automation) 想必大家都已不陌生，甚至还非常熟悉，是的没错，本文就来讲解一下OA中的核心业务，审批流程是如何一步步实现的。
本文干货满满，建议静下心来细细品
被审核流程
首先填写好表单相关信息，然后点击审批人，从公司部门树中点击相应部门，加载部门相关角色用户，最后再指定审批人
值得吹嘘的一点是这里的审批人可供用户自行动态选择，并且审批层级也是随着审批人的数量动态增减
以加班表单为例子
指定完成之后，点击提交即可。
然后再由相应的审批人逐级进行审批，当其中有一个不通过，则整个流程不通过，当所有的审批人全部通过才可通过
OK流程已经清楚了，接下来我们来进行表结构的设计
只需要两张核心的审批表即可，其他需要进行审批流的业务表通过审批流编号FlowNo 关联这两张核心业务表，我们来看一下
基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能
项目地址：https://gitee.com/zhijiantianya/ruoyi-vue-pro
视频教程：https://doc.iocoder.cn/video/
审批流主表 AuditFlow
| Column Name | Data Type | Describe |
|---|---|---|
| FlowNo | Varchar(50) not null primary key | 审批编号返回yyyMMddHHmm+n位随机数 |
| Title | Nvarchar(50) not null | 标题(例如:某某人的加班申请) |
| BusType | Varchar(20) not null | 审批类型(根据业务表定义Code,区分表单) |
| AddUserNo | Datetime not null | 申请人 |
| AddTime | Varchar(50) not null | 添加时间 |
| ApproStatus | Int not null | 审核状态(1.待审,2.通过.3.驳回,4.撤销) |
这两张表的关系是一对多，明细表的数量取决与表单提交添加的审核人数量
ApproFlow：1 =======> n :ApproFlowDetail
基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能
项目地址：https://gitee.com/zhijiantianya/yudao-cloud
视频教程：https://doc.iocoder.cn/video/
审批流明细表 AuditFlowDetail
| Column Name | Data Type | Describe |
|---|---|---|
| ID | Int not null primary key identity(1,1) | 主键自增列 |
| FlowNo | Varchar(50) not null | 审批编号，关联主表 |
| AuditUserNo | Varchar(50) not null | 审核人 |
| AuditRemark | Nvarchar(500) | 审核备注 |
| AuditTime | Datetime | 审核时间 |
| AuditStatus | Int not null | 审核状态(1.审核中,2.待我审批.3.通过,4.驳回) |
如此一来，OA审批流程的两张核心业务表就设计完成了。
那么问题来了，其他相关表呢？
别急，慢慢来嘛。首先用户表肯定是需要的，因为表单申请人和审核人都是关联的用户No，因为用户是根据部门走的，那么还需要设计一张部门表，再设计一张用户和部门相关联的表，把用户和部门联系起来，就可以从部门中选取相应角色。当然简单点的逻辑可以不用部门，直接搜索全部用户，这里就不再设计了哈。
有了用户表和审批业务核心表，接下来就可以根据公司业务需求，来设计相关的审批流程业务表了，这里就拿加班申请来举个例子，当用户需要进行加班的时候，肯定是需要走审批流程的，那么再来设计一张加班申请表
加班表 OverTimeAsk
| Column Name | Data Type | Describe |
|---|---|---|
| FlowNo | Varchar(50) not null primary key | 关联AuditFlow表 |
| AddUserNo | Varchar(20) not null | 添加用户No |
| AddTime | Datetime not null | 添加时间 |
| AskReason | Nvarchar(50) not null | 加班事由 |
| Remark | Nvarchar(100) | 备注 |
| LeaveTimeFrom | Datetime not null | 加班开始时间 |
| LeaveTimeTo | Datetime not null | 加班结束时间 |
| OverTimeHours | decimal(10,2) | 加班总小时 |
此时，再回到文章一开始的流程，脑海中的思路是不是就慢慢的浮现出来了呢，嘻嘻
库设计好了，剩下的就是由程序实现完成了，那么问题又来了，如何去实现呢?借助问题，来进行驱动成长，下面就来探讨具体如何实现。
有了以上设计的表做铺垫，就可以为所欲为啦!
填写完加班申请表单，选择部门相关负责审批人，如主管，部门经理，总经理，此时进行表单提交
提交需要进行的操作
录入当前审批业务表，也就是加班申请表的数据
审批流主表插入一条数据
审批流明细表插入三条数据
对添加的第一个审核人发送相关通知消息
注意要点:
以上三条是同时进行操作，必须要满足事务，否则数据会出现问题
三条数据插入的
FlowNo字段必须是相同的插入审批流主表数据的时候，
BusType字段的值可以设置为OverTimeAsk，审核状态默认1(待审核)插入审批流明细表数据的条数取决与用户提交表单选择的审核人数量，如这里选择了三个审批人，就需要插入三条数据，第一条的审核状态 设为 2(待我审批)，其他两条的审核状态设为1(审核中)
插入加班申请表对月份进行判定，不允许跨月加班
表单提交的操作完成了，下面就开始论到审核操作的流程了
首先，要有一个待我审批的入口，查询出所有待我审核的表单
将
AuditFlow表和AuditFlowDetail表通过FlowNo关联查询过滤
AuditFlow表审核状态为1并且AuditFlowDetail表审核状态为2的数据也可以根据
AuditFlow表的BusType字段进行审批表单的分类
审核操作，基本上分为审核通过和不通过， 当然也可以根据业务自行扩展其他的审核操作。
实现思路与细节如下:
根据表单提交操作来判断审核是否同意
根据
FlowNo和AuditUserNo以及AuditStatus为2(待我审批) 的条件去查询AuditFlowDetail表，如果数据为空，则此单已进行过审核操作，直接返回。如果上一条查询的数据不为空，则可以将当前审核明细单数据的审核状态设置为通过or驳回
如果当前审核明细单的待审核数量大于一，则说明还需要向下一级传递审核，同时将下一级数据的审核状态设置为待我审核,并发送相关通知
如果当前审核明细单数据全部为审核通过，则将
AuditFlow表的审核状态设为通过如果当前审核明细单有一条审核不通过，则将
AuditFlow表的审核状态设为不通过
实现细节
如果审核同意则，根据FlowNo查询出所有AuditFlowDetail表数据，然后进行过滤，分别统计审核通过和审核不通过的数据条数，并记录第一个审核状态为审核中的数据。此时可根据条件执行上面的第4,5,6条
审核不同意操作大致同上
OK，整个多级审批流程就实现完啦，如果你仔细看完此文，相信你一定会茅塞顿开
当然OA的审批业务远远不止这么一点，还有其他的表单审批，比如工作汇报审批表，还可增加关联的附件表，提交工作内容的同时上传相关文件或者照片存放在服务中，方便审核人随时在线预览或者下载到本地
还可根据业务需求自行扩展相关表单
以上所有表单的审批流程都是围绕基于两张核心业务表来实现。
欢迎加入我的知识星球，一起探讨架构，交流源码。加入方式，长按下方二维码噢：
已在知识星球更新源码解析如下：
最近更新《芋道 SpringBoot 2.X 入门》系列，已经 101 余篇，覆盖了 MyBatis、Redis、MongoDB、ES、分库分表、读写分离、SpringMVC、Webflux、权限、WebSocket、Dubbo、RabbitMQ、RocketMQ、Kafka、性能测试等等内容。
提供近 3W 行代码的 SpringBoot 示例，以及超 4W 行代码的电商微服务项目。
获取方式：点“在看”，关注公众号并回复 666 领取，更多内容陆续奉上。
文章有帮助的话，在看，转发吧。
谢谢支持哟 (*^__^*）
2703
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
