【odoo14】經典好書學習沒有爛尾，主體已完成，可移步瞭解。https://www.cnblogs.com/xushuotec/p/14428210.html
背景
近期，有朋友打算上odoo系統。目前已有一套ERP系統了，由於是標準化產品，所以用起來各種不爽，終於在使用了兩年後打算遷移。PS，我接的時候已經有一家odoo二開公司在做了，名氣還是比較大的，我原本以為開發的東西還是蠻好的。但從朋友的反應及二開出來的程式碼質量看來，確實名不副實。至少給他們做二開的技術人員有點砸招牌的感覺。
所以，請各位打算上odoo的朋友要仔細甄別哦。odoo雖好，但是二開市場差異性還是蠻大的，別隻看公司名氣，要看來實際負責的技術哦
資料遷移
資料遷移是所有打算從老系統遷移至odoo的朋友所面對的一大難題，這裡的道道就比較多了。
方案
- 新建模組
這種事最簡單的了。就是將現有資料直接匯入到新的模組，資料與odoo其實中的業務流程模組基本上是資料分割的，歷史資料僅做查詢時候。
優點：遷移簡單，開發量根據資料原型設計即可，開發週期相對較短，保持原始資料的真實性。
缺點：與odoo系統業務流程分割，無法實現在相關模組的整合，比如採購、銷售等資料要到單獨的模組進行查詢。 - 深度整合
這種就複雜多了，對於資料遷移人員的要求會很高，將歷史資料整合到odoo的業務中去。簡單講就是，將歷史資料在odoo中走一遍。
優點：對於使用者而言，可專注於系統本身的業務邏輯，資料更加完整。
缺點：工作量大，需要技術人員對於資料細緻的拆分，對於odoo現有模組有深入理解，否則會出現資料丟失或者不準確的情況。
基於以上，我個人建議做方案二，雖然工作量大很多，但是對於使用者而言更加友好。
實施
由於朋友是做跨境電商服務，涉及幾個odoo中核心的模組包括：採購、庫存、銷售、會計、匯率、聯絡人等。歷史資料包括：採購訂單、內部調撥、銷售、商品報損、商品報溢、退款等。
以上在做資料遷移的時候，需要重點注意的是：時間和金額。這兩點是重中之重，不然對於最後的期末估值會有很大影響。
-
新建資料遷移模組
為什麼此處又寫新建模組了呢？因為這是實現資料錄入odoo系統最快的方式了(別問我怎麼知道的，說多都是淚)。這裡要注意，是錄入。並未與odoo系統的業務邏輯做任何的繼承。 -
資料轉odoo模型資料
對於原始資料而言，odoo是不知道它的真實意義的。所以我們要做的是將這些資料分解到各個模組中去。比如，採購資料其中就涉及到採購單(purchase.order、purchase.order.line)、採購員(res.users、res.partner)、供應商(res.partner)、商品(product.template、product.prodcut)等，這些內容分屬於不同的模組。
坑位: 1) 產品的唯一標識(SKU)不唯一， 2) 採購單後續是庫存，這對於原始資料是隱藏的資訊，需我們自己分析並新增資料來源 -
基於odoo原生業務的流程資料處理
在上面我們將原始資料匯入odoo模型後，其實我的做法是所有資料都處於draft階段，這個階段的資料對於系統而言類似於草稿箱資料。本階段，我們要做的就是將草稿箱資料轉正。
此處又有兩種轉正的方式：
1）最業務簡單但開發複雜的是，按照原始資料的時間順序，開發處理邏輯。比如，處理方式的是 時間1的採購、時間2的到貨、時間3的銷售、時間4的發貨。其中穿插著新的採購銷售的流程。
2）也是我採用的方式，下面重點介紹。
對於庫存而言，只有兩種方式，入和出；內部調撥想怎麼玩怎麼玩。因此，我首先梳理了入，包括採購、退貨、報溢。出，包括銷售、報損。
我首先將所有的採購、退貨、報溢進行資料處理，實現庫存數量的最大化；然後將內部調撥處理，將商品分配到各自的倉庫；最後處理出的問題，實現庫存的減操作。
在資料來源完整的情況下，以上流程最後的資料是對的起來的。至於如何批量實現基於odoo流程的資料處理，就需要我們針對每個階段做定製化的處理了。
坑一，必要的流程資料對不上
上面情況處理完後，總數最後雖然對上了，但是缺少部分流程資料。比如，商品A在倉庫A發貨，但是整個業務資料中並沒有發往倉庫A的內部調撥，因此商品A理論上發不出的貨。這種情況，沒好辦法，找甲方吧。
坑二，時間修正
不管採用哪種方式進行資料遷移，在資料進odoo的那個瞬間，就已經決定了原始時間資料變了。比如採購商品的到貨時間變成了我們在odoo中操作的時間、基於到貨的庫存價值(stock.valuation.layer)也是錯。
因此，我進行時間的修正，包括採購時間、到貨時間、銷售時間等內容。以上通過odoo模組實現修正可以實現，但是效率不高，且create_datetime是修正不過來的，odoo底層做了限制。因此我在修正庫存價值的時候發現時間一直都是錯誤的，是當前操作的確認收貨時的時間。最後，解決方案，直接到postgresql中去運算元據庫吧。這操作比較危險，但是是效率最高，準確性最高的方式了。此處，再次強調，對於odoo結構不瞭解的朋友，別直接去碰資料庫，這將繞過很多odoo為了安全而做的限制哦。
現在回頭看看，似乎也沒那麼複雜嘛。?，哎。