企業(yè)級 OA 多級審批流程設計、實現(xiàn)方案（細節(jié)滿滿）

OA(office automation) 想必大家都已不陌生，甚至還非常熟悉，是的沒錯，本文就來講解一下OA中的核心業(yè)務，審批流程是如何一步步實現(xiàn)的。

?

本文干貨滿滿,建議靜下心來細細品

?

被審核流程

首先填寫好表單相關信息，然后點擊審批人，從公司部門樹中點擊相應部門，加載部門相關角色用戶，最后再指定審批人

值得吹噓的一點是這里的「審批人可供用戶自行動態(tài)選擇,并且審批層級也是隨著審批人的數(shù)量動態(tài)增減」

以加班表單為例子

指定完成之后，點擊提交即可。

然后再由相應的審批人逐級進行審批，當其中有一個不通過，則整個流程不通過，當所有的審批人全部通過才可通過

OK流程已經清楚了，接下來我們來進行表結構的設計

只需要兩張核心的審批表即可，其他需要進行審批流的業(yè)務表通過審批流編號FlowNo 關聯(lián)這兩張核心業(yè)務表，我們來看一下

審批流主表 AuditFlow

這兩張表的關系是一對多，明細表的數(shù)量取決與表單提交添加的審核人數(shù)量

?

ApproFlow：1 =======> n :ApproFlowDetail

?

審批流明細表 AuditFlowDetail

如此一來，OA審批流程的兩張核心業(yè)務表就設計完成了。

那么問題來了，其他相關表呢？

別急，慢慢來嘛。首先用戶表肯定是需要的，因為表單申請人和審核人都是關聯(lián)的用戶No，因為用戶是根據(jù)部門走的，那么還需要設計一張部門表，再設計一張用戶和部門相關聯(lián)的表，把用戶和部門聯(lián)系起來，就可以從部門中選取相應角色。當然簡單點的邏輯可以不用部門，直接搜索全部用戶，這里就不再設計了哈。

有了用戶表和審批業(yè)務核心表，接下來就可以根據(jù)公司業(yè)務需求，來設計相關的審批流程業(yè)務表了，這里就拿加班申請來舉個例子，當用戶需要進行加班的時候，肯定是需要走審批流程的，那么再來設計一張加班申請表

加班表 OverTimeAsk

此時，再回到文章一開始的流程，腦海中的思路是不是就慢慢的浮現(xiàn)出來了呢,嘻嘻

庫設計好了，剩下的就是由程序實現(xiàn)完成了，那么問題又來了，如何去實現(xiàn)呢？

?

借助問題來進行驅動成長，下面就來探討具體如何實現(xiàn)：

?

有了以上設計的表做鋪墊，就可以為所欲為啦！填寫完加班申請表單，選擇部門相關負責審批人

如主管，部門經理，總經理，此時進行表單提交

提交需要進行的操作

• 錄入當前審批業(yè)務表，也就是加班申請表的數(shù)據(jù)
• 審批流主表插入一條數(shù)據(jù)
• 審批流明細表插入三條數(shù)據(jù)
• 對添加的第一個審核人發(fā)送相關通知消息

「注意要點:」

1. 以上三條是同時進行操作，必須要滿足事務，否則數(shù)據(jù)會出現(xiàn)問題

2. 三條數(shù)據(jù)插入的FlowNo字段必須是相同的

3. 插入審批流主表數(shù)據(jù)的時候，BusType字段的值可以設置為OverTimeAsk，審核狀態(tài)默認1(待審核)

4. 插入審批流明細表數(shù)據(jù)的條數(shù)取決與用戶提交表單選擇的審核人數(shù)量，如這里選擇了三個審批人，就需要插入三條數(shù)據(jù)，第一條的審核狀態(tài) 設為 2(待我審批)，其他兩條的審核狀態(tài)設為1(審核中)

5. 插入加班申請表對月份進行判定，不允許跨月加班

表單提交的操作完成了，下面就開始論到審核操作的流程了

首先，要有一個待我審批的入口，查詢出所有待我審核的表單

• 將AuditFlow表和AuditFlowDetail表通過FlowNo關聯(lián)查詢

• 過濾AuditFlow表審核狀態(tài)為1并且AuditFlowDetail表審核狀態(tài)為2的數(shù)據(jù)（也可以根據(jù)AuditFlow表的BusType字段進行審批表單的分類）

審核操作，基本上分為審核通過和不通過， 當然也可以根據(jù)業(yè)務自行擴展其他的審核操作。

「實現(xiàn)思路與細節(jié)如下:」

1. 根據(jù)表單提交操作來判斷審核是否同意

2. 根據(jù)FlowNo和AuditUserNo以及AuditStatus為2(待我審批) 的條件去查詢AuditFlowDetail表,如果數(shù)據(jù)為空,則此單已進行過審核操作,直接返回.

3. 如果上一條查詢的數(shù)據(jù)不為空,則可以將當前審核明細單數(shù)據(jù)的審核狀態(tài)設置為通過or駁回

4. 如果當前審核明細單的待審核數(shù)量大于一,則說明還需要向下一級傳遞審核,同時將下一級數(shù)據(jù)的審核狀態(tài)設置為待我審核,并發(fā)送相關通知

5. 如果當前審核明細單數(shù)據(jù)全部為審核通過,則將AuditFlow表的審核狀態(tài)設為通過

6. 如果當前審核明細單有一條審核不通過,則將AuditFlow表的審核狀態(tài)設為不通過

「實現(xiàn)細節(jié)」

如果審核同意則，根據(jù)FlowNo查詢出所有AuditFlowDetail表數(shù)據(jù)，然后進行過濾，分別統(tǒng)計審核通過和審核不通過的數(shù)據(jù)條數(shù)，并記錄第一個審核狀態(tài)為審核中的數(shù)據(jù)。此時可根據(jù)條件執(zhí)行上面的第4,5,6條

審核不同意操作大致同上

OK，整個多級審批流程就實現(xiàn)完啦，如果你仔細看完此文，相信你一定會茅塞頓開！

當然OA的審批業(yè)務遠遠不止這么一點，還有其他的表單審批，比如工作匯報審批表，還可增加關聯(lián)的附件表，提交工作內容的同時上傳相關文件或者照片存放在服務中,，方便審核人隨時在線預覽或者下載到本地

還可根據(jù)業(yè)務需求自行擴展相關表單

以上所有表單的審批流程都是圍繞基于兩張核心業(yè)務表來實現(xiàn)。

來源：blog.csdn.net/cslx5zx5/

article/details/107566070