引言
由於從Odoo 9.0開始Odoo 官方社區將可視化審批流的功能模塊移除，改用Button+Context+Python代碼的混用方式形成通用化的定製審批工作流的需求。爲此很多Odoo粉絲從10.0之後在想去通過可視化配置與操作工作流變得異常的困難，當然我們開源智造諮詢有限公司（OSCG）作爲實施客戶數量最多的公司也是經常遇到實施服務人員被工作流弄的只能通過二次開發來解決，確實效率不高，也無法將實施經驗傳遞給到客戶。這使我潛心下來開發一套先進且符合odoo新標準的工作流。
一起來緬懷經典的Odoo8.0審批工作流功能模塊
這是另外一種流程圖呈現形式，至今依然很多人都不知道如何打開
當然Odoo官方從9.0去掉審批工作流模塊也是因爲從某種意義上來說，除了專業的實施公司會使用以外，客戶操作起來仍舊在一些按條件審批或跳轉的審批上依然依賴Python開發代碼才能解決，某種意義上形成了雞肋。所以站在產品角度我認爲odoo此舉做法非常正確。
高級的判斷跳轉依舊逃不開python動作代碼
還是讓一般用戶來設置比較複雜
我也看到了網上有形形色色的審批流，大多都是隻能做到固定的（1級審覈或2級審覈），而條件往往都是隻能從金額去判斷工作流走向，但對其他的數據項無法去定義和判斷工作流走向，在這裏只能說：目前比較痛心疾首的是大多數Odoo從業者都是技術開發出身，產品經理及諮詢顧問還有甲方業務專家的人才實在是太少了，纔會出現這樣的窘境。又或者我理解下來就是怕麻煩，畢竟做套通用化的審批流模組是非常困難的，同時技術要求也頗高。所以大多數也就只能做到個模塊了不起了。
吊打友商的審批工作流模組
開源智造一貫的軟件工程思想，化繁爲界，大道之極！通用、好用、易用是我們的軟件設計哲學。這點上我們既有老肖的IBM軟件的嚴謹思想，也有老楊的蘋果軟件的極簡風思維。纔有了這樣一個菜單搞定一切的邏輯，就算他是BPM級的工作審批流也是一樣的。
簡易的全局Odoo工作審批流,一覽無餘!利用視圖特性可以分組
- 引用模型：作用在具體Odoo哪個模塊需要進行審批流
- 驗證者：可以是用戶組、可以是具體的指定的用戶
- 審覈者：根據驗證的身份信息絕對最終的選項用戶或用戶組
- 定義：域（domian）
- 定義域：已經可以支持手寫domian修飾代碼或可視化指定數據源拖拉配置
- 序號：這個很關鍵，當同一個作用在功能應用（這裏舉例是採購訂單）時則直接根據序號倒序規則判斷第一級流程審批是走哪個規則。
看來真的做到了無代碼化的可視化流程規則配置
來個實際的例子跑個分看看
我們這裏舉個採購訂單的審批案例，在這裏由於我們服務的500家客戶大多數客戶對標準Odoo功能不滿的地方基本覺得就是採購審批流程自身只支持1級審覈這點覺得比較遺憾，一直希望作爲中國最權威最厲害的Odoo實施服務商開源智造是不是能有所作爲來彌補國內大多數針對採購審批這塊的謹慎的規範流程的完善。我們開源智造一直以來秉承着把客戶當朋友的原則，既然要解決這樣的缺陷且又是通用的，乾脆我們把所有Odoo應用功能模塊的工作審批流全做了好了。這樣一勞永逸，願意用的按照之前的方式去配，不願意用的不需要配，還是保留Odoo原有的架構特性。
增加了一個工作審批流發起引擎按鈕
當按照上圖所示，點擊了請求驗證按鈕後，則會啓動一個工作流，當主管查閱到審覈的這張PO00006單據時，單據會如下圖所示的效果：
這就是第一個節點審批的人的界面
爲了追尋喬老爺子的風格，我們將審批儘可能的做極簡，這裏說明一下，我們不是爲了去開發一套專業級和協同級的BPM或者OA工作流，我們僅僅是爲了解決Odoo業務數據的靈活的可視化審批工作流的設置缺陷，所以不要把一些複雜的審批流程植入腦海了。
終審覈之後，業務審批流結束
同樣我們利用了Odoo的單據Messges機制打通審批日誌和消息推送功能，讓審批工作利用Odoo自身的功能實現協同化、可追溯化及整合化。
寫在最後
如果各位有對Odoo可視化工作審批流需求的或者需要此功能模塊，可以直接百度訪問【開源智造】-【關於我們】-【聯繫我們】致電或填寫線上反饋信息或郵件與我們聯繫，我們將通過服務工程師免費贈送給到有需求的人。
如果您對免費開源ERP Odoo整體產品不瞭解以及實施操作不瞭解的可以百度訪問【開源智造】-【資源下載】-【書籍教程】免費下載 Odoo實施、開發、架構全套教材
來源：開源智造(OSCG) - 源自歐洲，業界領先的免費開源ERP Odoo金牌服務機構