思考如何完成一个审批流
这篇文章,可能没有太多的干货,只是对于自己做过项目的一个反思与整理,同时,让这篇文章暴露在公共视野,虚心接受批评指导,向各位前辈同仁进行学习。
如果此文又不当之处,逻辑有问题的地方,设计不合理的地方,希望各位进行批评指正
初步设计
1.创建数据库
主表设计
字段 | 名称 |
---|---|
id | 主键id |
applicant | 申请人 |
apply_time | 申请时间 |
step | 审批进度 |
status | 审批状态 |
comment | 审批意见 |
revoke_time | 撤回时间 |
副表设计
字段 | 名称 |
---|---|
pid | 审批主表主键id |
user_id | 审批人 |
approve_time | 审批时间 |
2.接口设计
设计相应的接口来实现审批流程的功能。例如,可以设计以下接口:
- 创建审批记录:用于申请人提交审批请求。
- 获取审批记录:用于查询某个审批记录的详细信息。
- 更新审批状态:用于更新审批记录的状态(如已通过、已拒绝等)。
- 撤回审批:用于撤回已经提交的审批请求。
3.业务逻辑
实现相应的业务逻辑,如多人审批、撤回等功能。例如,可以采用以下策略实现多人审批功能:
- 当一个审批请求提交后,系统自动分配一个初始审批人。
- 如果初始审批人同意审批,则将审批状态设置为“已通过”,并通知申请人。
- 如果初始审批人拒绝审批,则将审批状态设置为“已拒绝”,并通知申请人。
- 如果初始审批人未在规定时间内做出决策,则自动将其从审批人列表中移除,并通知申请人重新选择审批人。
- 申请人可以选择其他已有的审批人作为新的审批人,或者添加新的审批人。
- 当所有指定的审批人都同意或拒绝时,审批流程结束。
4.数据权限
所有的审批只有申请人和审批人可见
当审批被驳回,客户可通过修改进行二次申请
审批人进行审批,更改主表数据状态,在副表插入数据
涉及到二级审批,依然审批人进行审批,更改主表数据状态,在副表插入数据
最后的数据展示获取副表审批记录和申请人,进行数据过滤
反思与优化
1. 审批流程的灵活性
在设计中,确保审批流程具有一定的灵活性,以适应不同业务场景。考虑是否允许在审批流程中动态添加或删除审批人,以便在流程进行中灵活应对变化。这可以通过设计支持动态审批人的接口和功能来实现。
2. 审批记录的完整性
除了主表和副表中的基本审批信息外,考虑是否需要更详细的审批日志记录。具体记录每位审批人的操作,包括操作类型(同意、拒绝、撤回等)、操作时间等信息。这样的详细记录有助于审批流程的追溯和审计,确保审批记录的完整性。
3. 通知机制
实现一个强大而灵活的通知机制,确保在审批流程的各个阶段都能及时通知相关人员。可以通过邮件、短信或系统内消息等多种方式进行通知。考虑设计通知模板,以便在通知内容需要调整时能够方便地进行修改。
4. 审批状态的扩展
审批状态目前包括“已通过”和“已拒绝”,但在一些场景下可能需要更多状态。考虑扩展审批状态,例如“待审批”、“审批中”等,以满足更多业务需求。确保系统设计能够轻松扩展和定制审批状态,以适应不同的业务流程。
5. 数据权限与二次申请的优化
在数据权限方面,确保只有申请人和相关审批人能够查看相应的审批记录。对于二次申请,设计一个灵活的机制,允许客户通过修改已有的申请进行二次申请,同时保留相关的审批历史记录。
6. 二级审批的数据展示优化
对于涉及二级审批的情况,优化数据展示方式。可以考虑在界面上清晰地展示主表和副表的关联关系,以及审批人的操作记录,以便用户能够直观地了解整个审批流程的进展和历史。