ERP 串接怎麼做？電商、LINE、會計軟體的 API 整合

「我們想把 ERP 跟官網、電商平台、LINE、會計軟體全部串起來，資料自己跑，不要再有人重複打字。」

這是很多老闆在第一次聊導入時講的話。廠商的回答通常也很快：這些平台都有 API，都可以串。三個月後，串是串起來了，但同一張訂單偶爾會進來兩次，官網顯示有貨、倉庫卻已經賣完，會計月底還是要找人把兩邊數字對一遍。老闆困惑的是：不是說好自動了嗎？

我是熊董，川輝科技創辦人。帶團隊做系統導入七年，經手超過 34 個案子、14 個以上產業，現在一個人加 AI，一年交付 2,000 萬以上的客製系統。串接是我在專案裡花最多時間「先講清楚」的部分，因為它出事的方式最安靜，往往錯了好幾週才被發現。

ERP 串接的難處從來不在 API 接不接得上，現在多數平台都開放 API，技術上幾乎都串得起來。真正決定成敗的是三個沒人先講清楚的問題：每一種資料以哪一邊為準、資料往哪個方向流、多久同步一次，再加上串接失敗時誰會知道、怎麼補。電商串的是訂單和庫存，LINE 串的是客戶身分，會計軟體串的是傳票和發票，三種的答案完全不一樣。先把這張資料地圖畫出來，再決定要用 API 直接串、用中介工具，還是用匯出匯入；順序反了，你只會得到一條把錯誤資料自動搬來搬去的管線。

為什麼 API 都有了，串起來還是一團亂？

先講老闆想串接的直覺：完全正確。同一筆資料在兩個地方各打一次，本來就是錯誤的最大來源。業助把電商訂單抄進 ERP，抄錯一個數量，出貨就錯；會計把銷貨資料再打進會計軟體，打錯一個稅額，報稅就出問題。能讓資料只輸入一次，是對的方向。

問題在於，大家把串接想成「接一條水管」。水管接好，水就會流過去。但資料不是水，資料有身分、有版本、有先後。官網上的商品叫「經典款 黑色 M」，ERP 裡叫一串料號，電商平台上又是另一個商品編號，三邊如果沒有一張對照表，API 再快也只是把一筆認不出來的資料丟到對面。

我看過的串接問題，大概可以歸成三類：

• 主檔對不上：同一個商品、同一個客戶，在不同系統有不同編號，串接時找不到對應，只好新建一筆，結果重複資料越來越多。主檔亂的問題我在料號亂編的後果那篇拆過，串接之前一定要先處理。
• 方向沒定：兩邊都可以改同一筆資料，改完再互相同步，最後誰覆蓋誰全憑運氣。
• 失敗沒人知道：某天平台改了欄位格式，或網路斷了半小時，那段時間的訂單沒進來，但沒有任何人收到通知。

這三類都不是工程師寫錯程式，是規劃階段沒有人回答那幾個問題。

先畫資料地圖：每一種資料以誰為準？

我在每個串接案子開始前，都會先跟老闆和負責的同事一起填一張表。不用技術背景，用白話回答就好。

資料	以誰為準	流向	建議頻率
商品主檔（名稱、規格、售價）	ERP	ERP → 電商、官網	異動時推送
可售庫存	ERP	ERP → 電商，保留安全量	越即時越好，至少每小時
訂單	電商平台、LINE 下單	平台 → ERP	即時或每幾分鐘
訂單狀態（出貨、取消、退貨）	依事件發生地	雙向，各管各的狀態	即時
客戶身分	CRM 或 ERP 客戶主檔	LINE 帳號綁定到客戶編號	綁定時一次，之後跟著走
銷貨、收款傳票	ERP	ERP → 會計軟體	每日或每月批次

這張表最重要的是第二欄。每一種資料只能有一個「正本」，其他地方都是副本。副本可以顯示、可以參考，但不能直接改；要改，就回到正本改，再讓它同步出去。只要有一種資料出現兩個正本，那就是未來衝突的來源。

填這張表時，最常卡住的是訂單狀態那一列。客戶在電商平台上取消，取消這件事發生在平台；倉庫出貨，出貨發生在 ERP；客戶退貨，可能從平台申請，實體卻寄回倉庫。所以狀態沒辦法簡單說以誰為準，要拆成一個一個事件：取消以平台為準、出貨以 ERP 為準、退貨申請以平台為準、退貨入庫以 ERP 為準。每個事件只有一個地方能觸發，觸發之後再通知另一邊。拆到這個程度，兩邊才不會互相覆蓋。

第四欄也常被誤解。很多老闆覺得「越即時越好」，所以每一條都要求即時同步。但即時是有成本的：要處理的錯誤情境變多、系統負擔變重、出錯時影響範圍更大。庫存和訂單需要即時，因為慢了會超賣、會漏單；會計傳票不需要，每天收工後批次送一次，反而比較好對帳。

電商、LINE、會計軟體，三種串接各自要注意什麼？

電商平台：訂單去重與庫存超賣

電商串接最常出的兩個問題，一個是重複訂單，一個是超賣。

重複訂單的原因通常是重送機制：網路不穩，系統沒收到確認就再送一次，ERP 那邊又沒有檢查，就變成兩筆。解法是用平台的訂單編號當唯一識別，ERP 收到時先查有沒有這個編號，有就更新、沒有才新增。

超賣則是因為多個通路共用同一批庫存，但同步有時間差。做法是不要把全部庫存都丟給電商，而是保留一個安全量，或是依通路分配可售數量。多平台訂單怎麼進 ERP，我在電商多平台訂單怎麼進 ERP裡講過三件要先想清楚的事，這裡不重複。

LINE：先解決「這個人是誰」

LINE 串接的核心不是訊息，是身分。客戶在 LINE 上傳訊息、下單，你拿到的是一個 LINE 的使用者識別碼，它本身不等於你系統裡的客戶編號。第一步要設計綁定：客戶第一次互動時，用手機號碼、會員編號或店家代碼，把他的 LINE 帳號對應到你的客戶主檔。綁定完成之後，他之後的每一筆訂單、每一則訊息，才會落在正確的客戶身上。

這件事做好，LINE 就能變成一個正式的下單通路。我們做過一個跨境 B2B 品牌的 LINE Bot 自動接單，系統裡有 1,218 項商品、2,204 家店、橫跨 4 個地區。這種規模能跑起來，靠的不是 LINE 本身，而是每家店的身分、每個商品的編號、每個地區的規則，在串接之前就已經對好。經銷商用 LINE 下單的設計，可以看經銷商下單系統那篇。

會計軟體：不要即時，要對得起來

會計串接最常見的錯，是把它當成訂單一樣即時處理。每成立一筆銷貨就立刻產生一張傳票送過去，結果訂單一取消、一退貨，會計軟體裡就多出一堆要沖銷的傳票，會計看得頭昏。

比較好的做法是批次。每天或每月，把當期的銷貨、收款、退貨彙總成傳票，一次送過去，送完再比對兩邊的總金額。另外要先做好科目對照：ERP 裡的銷貨類別對應到會計軟體的哪個科目、稅別怎麼帶、折讓怎麼記。這張對照表要由會計確認，不是工程師自己猜。

用 API 直接串、用中介工具，還是匯出匯入？

地圖畫好之後，才輪到選技術做法。常見的有三種，沒有哪一種一定比較好，看的是資料量、頻率和出錯代價。

API 直接串接：由系統直接呼叫對方的 API，最即時，錯誤處理也最能客製。適合訂單量大、需要即時、出錯代價高的情境，例如電商訂單和庫存。缺點是要有人寫、有人維護，平台改版時要跟著改。

中介工具串接：用 n8n、Make 這類流程自動化工具當中間人，把兩邊的 API 接起來。好處是建置快、改流程方便，適合量不大、規則簡單的串接，例如把表單資料丟進系統、把新訂單通知推到 LINE 群。缺點是流程一多就難管理，錯誤處理通常比較陽春。這三種工具怎麼選，我在 n8n、Make 還是客製那篇比較過適用情境。

匯出匯入：定時從一邊匯出檔案，再匯入另一邊。聽起來很原始，但對會計傳票這種一天一次、需要人確認的資料，反而是最穩的做法，出錯時也容易追。

一個專案裡三種混用很正常。訂單用 API、通知用中介工具、會計用匯出匯入，這不是不專業，而是每條資料都用了最適合它的方式。

串接失敗時誰會知道？最常被忽略的那一段

串接上線那天大家都很開心，資料自己跑了。真正的考驗在三個月後，某個平台改了欄位、某個憑證過期、某天主機忙不過來，有一段資料沒有傳過去。

這時候只有一個問題：誰會知道？

如果答案是「客戶打電話來問為什麼沒出貨」，那這條串接其實是不及格的。一條合格的串接至少要有四個機制：

1. 失敗會重試：傳送失敗時自動再試幾次，而且重試不會產生重複資料。
2. 失敗會留紀錄：每一筆傳送成功或失敗都有紀錄，查得到是哪一筆、什麼時間、錯誤訊息是什麼。
3. 失敗會通知人：重試仍失敗時，通知一個明確的負責人，而不是寫進一個沒人看的紀錄檔。
4. 每天自動對帳：比對兩邊當天的訂單筆數、金額總和，對不起來就發警示。

第三點有個細節：通知要發給一個明確的人，而不是一個群組。發到十個人都在的 LINE 群，每個人都以為別人會處理；發到一個沒人每天打開的信箱，等於沒有發。通知對象應該是一個負責人，外加一個他請假時的代理人，而且通知內容要寫清楚是哪一筆、錯在哪裡、建議怎麼處理，讓收到的人不用登入系統就知道下一步該做什麼。

第四點最便宜也最有效。即使前三點都做得不完美，只要每天有一張「兩邊筆數對不對得上」的報告，問題最晚隔天就會浮出來。

還有一件事要先講好：平台會改版，API 會更新。串接不是做完就結束的東西，它需要有人持續顧。上線前就要約定好，平台改 API 的時候誰負責改、多久內要改好。

寫給廠商的串接規格，至少要有這幾項

如果你要找廠商做串接，規格書不用寫程式細節，但下面這幾項一定要寫清楚，否則報價會差很多，驗收時也沒有依據：

• 要串哪幾個系統、每個系統串哪幾種資料
• 每種資料以誰為準、流向、同步頻率（也就是前面那張地圖）
• 雙方系統的對照方式：商品、客戶、門市用什麼編號對應
• 重複資料怎麼判斷、怎麼處理
• 失敗時的重試次數、紀錄方式、通知對象
• 每日對帳的比對項目與警示方式
• 對方平台改版時的維護責任與處理時間

這份清單寫完，你會發現一半以上都不是技術問題，而是公司內部要先做的決定。這正是重點：串接的規格寫得出來，代表你的資料流已經想清楚了；寫不出來，就算廠商做得再快，也只是把模糊的地方延後到上線之後才爆。

常見問題

ERP 串接一定要用 API 嗎？

不一定。訂單、庫存這類需要即時、量又大的資料適合用 API；會計傳票這類每天一次、需要人確認的資料，用匯出匯入反而比較穩。先看資料的頻率和出錯代價，再決定做法，同一個專案裡混用很正常。

電商平台跟 ERP 的庫存要怎麼同步才不會超賣？

庫存以 ERP 為唯一正本，單向推送到各電商平台，盡量即時，至少每小時一次。同時不要把全部庫存都開放販售，保留安全量或依通路分配可售數量，用來吸收同步時間差。

舊的 ERP 沒有 API，還能串接嗎？

多數情況可以。舊系統若能匯出檔案或可以讀取資料庫，就能透過中介程式或定時匯出匯入的方式接起來。但要先評估舊系統的資料結構是否穩定，如果主檔本身就很亂，先整理主檔會比急著串接更划算。

串接上線後還需要維護嗎？

需要。電商平台、LINE、會計軟體都會改版或更新 API，憑證也會到期，任何一個變化都可能讓串接中斷。上線前就要約定誰負責監控、誰負責修改，並建立每日自動對帳，讓問題最晚隔天就被發現。

串接是在畫資料地圖，不是在接水管

一句話收尾：API 只是管子，真正讓串接成功的是你先決定了每種資料的正本在哪、往哪裡流、壞掉時誰會知道。地圖畫清楚了，用哪一種技術做都不難；地圖沒畫，再好的工具也只是把混亂自動化。

如果你正在規劃 ERP 跟其他系統的串接，想先知道整個導入該怎麼排順序，可以從 ERP 導入怎麼做開始看起。