【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為了安全而做的限制哦。
現在回頭看看，似乎也沒那么復雜嘛。😂，哎。