我跟 ERP 打交道的經驗有三種：從後端串接過，把自己系統的資料送進 ERP、或從 ERP 拿資料；從 ERP 撈過資料做報表；也在自己的系統裡做過類似 ERP 的功能。
三種角度，遇到的痛點卻是同一組：
- 主檔兩邊不一致：商品、客戶資料在 ERP 和自己的系統各有一份，對不起來。
- ERP 改不動：流程和欄位要配合 ERP，不能照自己的需求改。
- 月結對帳對不起來：自己系統的數字和 ERP 的帳不一樣。
要理解為什麼總是撞在這三個地方，得先看懂 ERP 到底在做什麼。
不用 ERP 會痛在哪
一家公司賣東西，至少有三個部門在記同一件事：業務記了一張訂單、倉庫記了一次出貨、會計記了一筆應收。三個人、三本帳，月底一對，數字對不起來。差在哪？可能是業務改了數量沒通知倉庫，可能是退貨只有倉庫知道。
ERP 要解的就是這件事：讓錢、貨、人只有一份帳。 業務開的訂單，就是倉庫出貨的依據；倉庫的出貨，就是會計開發票的依據；發票一開，帳就自動記好。每個部門看的是同一份資料，而不是各自抄一份。
ERP 有哪些模組
以下截圖來自 ERPNext 的官方公開 demo（GPL-3.0），資料都是示範用的假資料。
左邊的選單就是 ERP 管的範圍：會計、採購、銷售、庫存、資產、人資、薪資、製造、CRM、品質、專案、客服。可以粗分成三塊：
- 錢：會計、薪資、資產
- 貨：採購、銷售、庫存、製造、品質
- 人：人資、專案、客服
注意 CRM 也在裡面。CRM 有兩種那篇提過，像 ERPNext 這類套件內建 CRM，用這套的公司就不用另外買。但很多公司是 ERP 和 CRM 分開用不同系統，這時候兩邊就要串資料。
一張訂單走一遍
打開銷售訂單列表，每張訂單旁邊有兩條進度條：已出貨的比例和已開票的比例。
這兩條進度條說明了 ERP 的核心想法：訂單不是成立就結束了，ERP 會一路追蹤到「貨出了沒」「錢開票了沒」。
點進其中一張：4 台手機，共 80,000 盧比。
右上角的「Create」可以直接從這張訂單產生後續的單據：出貨單、發票、付款。後續單據不是重新輸入，而是從這張訂單帶過去的。
切到「Connections」分頁，看得到這張訂單牽動了哪些單據：
這張訂單有 1 張發票、2 張出貨單（分兩次出貨）、1 份物料清單、1 筆庫存保留。頁面下方的活動紀錄還有一筆「Approved」，代表這張訂單經過簽核才生效。
最後一步最關鍵。打開這張訂單的發票，查它產生的會計分錄：
2 筆分錄，一筆記在「銷售收入」，一筆記在「應收帳款」，日期就是開發票那天。沒有人手動記帳，開發票這個動作本身就產生了帳。
這就是 ERP 的運作方式：每一張業務單據，都會自動寫進對應的帳。 出貨單會影響庫存，發票會影響應收和收入，付款單會沖銷應收。會計不是另外記一本帳，而是從這些單據長出來的。
後端為什麼總在這三個地方撞牆
懂了「單據自動長出帳」，就能理解開頭那三個痛點從哪來。
主檔兩邊不一致。 ERP 的每張單據都參照主檔：商品、客戶、會計科目。自己的系統也有一份商品和客戶。兩邊各自新增、各自修改，遲早對不起來。解法不是技術，是先決定哪一邊說了算。這跟 CRM 會碰到哪些資料講的是同一個問題：每一類資料都要有唯一的來源。通常商品和會計科目以 ERP 為準，自己的系統從 ERP 同步過來，而不是反過來。
ERP 改不動。 ERP 改不動，有一部分是刻意的。上面那條「單據→帳」的鏈是 ERP 最值錢的地方，改了一個欄位，可能就影響到帳怎麼記。所以導入 ERP 時常常是「流程配合 ERP」，而不是「ERP 配合流程」。後端能做的，是把客製的部分放在 ERP 外面：自己的系統處理特殊流程，處理完再用 ERP 的標準單據送進去。
月結對帳對不起來。 自己系統的「訂單」和 ERP 的「帳」不是同一個時間點產生的。自己的系統在下單時就算一筆營收，但 ERP 要等開了發票才記帳；自己的系統取消了一張訂單，ERP 那邊的發票可能已經開了。時間差加上取消、退貨，數字就對不起來。這時候需要的是定期對帳，兩邊各算一個數字比對（見對帳不是會計的事），以及講清楚「營收以哪一邊為準」。
我自己做過的系統裡，庫存和進貨這兩塊，ERP 也都有。但這不是「重做」，是不可能不做。以電商來說，結帳那一刻就要扣庫存，防止同一件商品賣給兩個人，這一步不能等 ERP（見庫存預佔：防超賣的三個數字）。
所以電商和 ERP 一定會各有一份庫存：電商那份要即時，用來決定「現在還能不能賣」；ERP 那份跟著出貨單和進貨單走，用來記帳和管倉庫。真正要設計的不是「要不要做」，而是兩份之間的關係：哪一份說了算、多久同步一次、對不起來時以誰為準。這其實就是第一個痛點「主檔兩邊不一致」的另一種長相。
接 ERP 還會撞到的四件事
下面四點是從跨系統整合的原則推出來的，還沒有在實際對接 ERP 時驗證過。
- 夜間批次窗口。 多數 ERP 晚上會跑結帳批次。這是會計意思的結帳：把一段期間的帳算清楚、關起來，不是購物車結帳。那段時間資料不穩定，甚至會被鎖住。自己的排程要避開這段時間，也要能處理「今天的資料，明天才會出現」。
- 退回與改單。 真實的流程一定有「單子被退回重改」。一張單據會有幾個狀態，例如「草稿 → 已送審 → 已核准」，規定好能從哪個狀態走到哪個狀態，這就是狀態機。設計時不能只有往前走的路，也要有退回去的路，例如「已送審 → 退回草稿」。
- 代碼表地獄。 料號、會計科目、單位、幣別、稅別，各有一套代碼。例如同樣是「個」這個單位，自己的系統存
pcs，ERP 可能存EA；稅別也一樣，兩邊各用各的代碼。所以兩邊系統之間要有一張對映表，寫清楚「我這邊的這個代碼，等於你那邊的哪一個」。這張表要有負責人，每次改了什麼、什麼時候改的也要留下紀錄。 - 不要直連 ERP 的資料庫。 ERP 的資料表結構是套件商的，升版時會變。直接讀寫它的資料庫，等於把自己的系統綁死在某一個版本上。整合要走 ERP 提供的 API，或雙方約定好格式的批次檔，例如欄位順序固定的 CSV 檔。各種交換方式的取捨，見企業系統之間怎麼交換資料。
AI 和 MCP 的角色
ERP 是 MCP 最成熟的領域之一。2026-10 查證時，Odoo 有官方 MCP（推論只在付費的 Enterprise 版），ERPNext 有一個成熟的社群版本。
適合交給 AI 的，是跨單據的查詢。這類問題在 ERP 介面上要點好幾個畫面才拼得出來：
- 「哪些訂單已經出貨，但還沒開發票？」
- 「這個客戶目前的應收帳款有多少，最久的一筆欠多久了？」
- 「這個月出貨量最大的五個商品，庫存還剩多少？」
不能交給 AI 的，是會產生帳的動作：
- 提交單據、取消單據要人按。 上面看到了，發票一提交就產生會計分錄。AI 提交錯一張發票，影響的是帳。MCP 工具可以讓 AI 準備一張草稿，但提交那一步一定要人確認。
- 權限照角色縮。 ERP 本來就有角色權限，例如業務看不到薪資。MCP 用的帳號要照著角色給，不能拿管理員帳號給 AI。
- 查詢不要打正式系統。 跟 名單和報表的 ETL 講的一樣，大量查詢要打唯讀副本或資料倉儲，不要和正在跑交易的資料庫搶資源。
想看實作，可以讀這幾套
| 系統 | 授權 | 特色 | AI／MCP 現況（2026-10） |
|---|---|---|---|
| ERPNext | GPL-3.0，沒有付費版 | 模組完整，有公開 demo | 社群 MCP 成熟（rakeshgangwar/erpnext-mcp-server） |
| Odoo Community | LGPL-3.0 | 會計報表、簽核、薪資等模組只在付費的 Enterprise 版 | 官方 MCP，推論只在 Enterprise |
| Dolibarr | GPL-3.0 | 輕量，適合小公司 | 只有小型社群版本 |
| iDempiere | GPL-2.0 | Java，偏傳統 ERP 架構 | 只有小型社群版本 |
相關主題
- CRM 有兩種：ERP 管成交之後，CRM 管成交之前和會員
- 企業系統之間怎麼交換資料：自己的系統和 ERP 之間怎麼串