盤點舊系統
讀鼎新 T100(Genero 4GL)風格的來源程式與資料結構,產出 inventory.json。
不支援的語法是盤點結果的一部分,會誠實列出,不是失敗。
來源資料表
| 資料表 | 欄位數 | 主鍵 | 外鍵 |
|---|---|---|---|
| 尚未執行盤點。 | |||
不支援的語法
| 檔案 | 行號 | 片段 | 原因 |
|---|---|---|---|
| 尚未執行盤點。 | |||
欄位映射
含信心分數
把來源欄位對應到 Odoo 的模型與欄位,產出 mapping.json。
信心分數採 ISO2ERP UX 規格 §1.3 的門檻:≥85% 綠/60–85% 黃/<60% 紅,
低於 60% 不自動採用。
| 來源欄位 | 型別 | Odoo 欄位 | 轉換 | 信心 | |
|---|---|---|---|---|---|
| 尚未執行映射。 | |||||
未對應的欄位
| 資料表 | 欄位 | 型別 | 原因 |
|---|---|---|---|
| 尚未執行映射。 | |||
載入 Odoo
mapping.json,換上刻意有問題的來源資料:訂單指向不存在的客戶、
明細指向不存在的品號、日期是 2026-02-30。
重點不是它會失敗,而是它會怎麼失敗——每一筆都要指得出是哪一列、哪個欄位、
Odoo 自己怎麼說。看完按右上角的重置圖示就回得來。
依照 mapping.json 走 JSON-RPC 寫進 Odoo。密碼走環境變數,不進指令列。
每一筆都帶一個可回溯的 external_id,重跑是更新不是重複建立。
| 來源 | 主鍵 | Odoo 模型 | external_id | Odoo ID | 動作 |
|---|---|---|---|---|---|
| 尚未執行載入。 | |||||
驗證
只讀不寫。逐表比對筆數、逐張訂單比對金額。報告永遠產出——即使每一項都失敗。
| 檢查 | 來源表 | Odoo 模型 | 來源 | Odoo | 結果 |
|---|---|---|---|---|---|
| 尚未執行驗證。 | |||||
版本漂移
本專案的 Odoo catalog 是針對 Odoo 17 手寫的,而這台跑的是 Odoo 19。
把 catalog 宣告的每一個欄位丟給真機的 fields_get,少了哪個就直說少了哪個。
這裡沒有任何預先寫好的答案——結果完全來自當下那台 Odoo 回給我們的東西。
按「對真機比對」開始。
直接問 Odoo
這一區不是把上面的結果換個樣子重印,而是即時打 Odoo 的 JSON-RPC 撈回來的。
按「重新查詢」向 Odoo 取現況。
上線後:使用者每天在用的畫面
前面五步是導入專案:把舊系統的資料盤出來、對應好、寫進 Odoo、驗完。 做完之後客戶真正每天面對的是這些畫面——採購、庫存、銷售,加上系統管理與 AI 治理。
static/data/ 的前端示範資料,
操作結果不落地到資料庫、也不會回寫 Odoo,重新整理即還原。
真的寫進 Odoo 的是左邊的步驟 2 到 5——同一台伺服器上真的執行
migrai。步驟 1 的 14 頁同理。