【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為了安全而做的限制哦，
現在回頭看看，似乎也沒那么復雜嘛，??，哎，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qiye/285878.html
標籤：SAP
上一篇：F5 api介面開發實戰（一）