審批流是工作流比較簡單的應用。審批流的特點是乙個審批流模板相應一種單據。在審批流中僅處理單據的狀態，如審批通過、審批不通過；審批流中會用到單據資料，如條件中、各種須要引用單據變數的地方。審批流沒有涉及到多個單據之間的處理，因此審批流是相對簡單的。從業界的大多數工作流來看，也不過實現了審批流而已，比方協同辦公、以及erp中的一些單據的審批。工作流如今應該是處於0基礎階段。
假設須要做真正的多單據的工作流，即業務流。比方從採購申請、採購訂單、收貨單到採購發票，可以定製乙個完整的採購流程，更進一步，採購可以跟庫存、生產或者銷售模組連線起來，就更為完好了。同一時候，假設這些流程可以定製的，比方標準流程是這種，不同企業可以定製符合本企業須要的流程，就更完美了。在這乙個過程中，我覺得須要解決兩個較複雜的問題。
1、實體間架構對映問題。
biztalk中源架構（source schema）到目標架構（target schema）之間通過xslt來建立對映。乙份源架構的例項（就是乙份xml），能夠參照或者生成乙份目標架構的例項（新的xml）。這是比較好的解決方案，當然，能夠定義乙份簡單的對映關係對比表，通過**來轉換生成了。這個工作難度應該不大。
2、實體的例項間多對多的關係。
比方收貨單到發票，1張收貨單能夠開n張發票，n張收貨單也可能開1張發票。所以就存在單據例項間的多對多的關係。這樣的關係的處理，對於傳統的功能性流程來說是比較簡單的，通過多次參照就能夠實現。單據例項間的關係是在兩個單據資料之中來維護。可是對於利用工作流來處理這類問題時就變得比較棘手。第乙個問題是是否引入流程例項的處理，假設沒有流程例項，這跟傳統的以功能為主的應用有何差別，僅僅是將流程通過圖形化顯示出來，這僅僅是乙個殼。假設引入了，就會帶來第二個問題。那就是單據例項之間到底具有什麼約束？假設約束，那麼僅僅能處理1對1的關係，比方1張收貨單，就必須有1張發票相應，這樣整個流程就能流轉下來。假設沒有約束，錄入發票時，通過什麼條件來選擇訂單？從業務角度來看，應該是符合這個流程模板的全部流程例項的上一種訂單。假設選擇了別的流程例項關聯的發票，則那個流程例項就要中止。所以，就會出現流程例項的分之和合併，注意，不是流程模板的活動的分之和合併，而是流程例項。此處的處理，是業務工作流的關鍵所在。
考慮了幾天，沒有徹底想明確，寫下來，供以後參考，希望做過這方面研究的看到了討論一下。
odoo 在原有工作流中新增審批流
odoo 在原有工作流中新增審批流 步驟 1 加入所需的工作流節點以及相連的線 即所新增的審批流 如下 1 1.0 encoding utf 8 23 4 model workflow.activity 5 wkf id ref sale.wkf sale 6 name7 kind function...
odoo 在原有工作流中新增審批流
odoo 在原有工作流中新增審批流 步驟 1 加入所需的工作流節點以及相連的線 即所新增的審批流 如下 1 1.0 encoding utf 8 23 4 model workflow.activity 5 wkf id ref sale.wkf sale 6 name7 kind function...
Activiti 工作流引擎 獲取審批記錄
審批意見儲存在act hi comment表中 審批狀態儲存在act hi varinst表中，為任務變數 historyservice historyservice this.gethistoryservice taskservice taskservice this.gettaskservice...