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