n8n 串 ERP 實戰：訂單、報價請款、異動通知 3 條流程怎麼搭，什麼時候 n8n 不夠用

n8n 可以串 ERP。訂單進 ERP、報價核准後開請款單、ERP 單據異動通知相關的人，這三條中小企業最常想自動化的流程，用 n8n 內建的節點就搭得出來。真正會卡住的地方很少是「節點不夠」，多半是三件事：ERP 給不給你寫入的權限、同一張單會不會被寫兩次、流程壞掉的時候有沒有人知道。

我們自己的 n8n 架在 Zeabur 上，內部寄信、網站監控、社群數據同步都靠它在跑，踩過的坑不算少。最近來聊 ERP 需求的人裡，也有人是先把我們的 n8n 課程頁看了兩次，才回頭來談系統。這讓我們確定一件事：很多老闆想知道的，是「n8n 到底能幫我的 ERP 做到哪裡」，而這個問題的答案，比 n8n 教學影片裡的範例複雜一點。

先看一個背景數字。MuleSoft 的 2025 Connectivity Benchmark 報告 調查發現，企業平均用了 1,061 個應用程式，真正彼此串起來的只有 29%。規模小很多的台灣中小企業也是同一個樣子：ERP、LINE 官方帳號、Google 表單、Excel 報價單各自為政，中間靠人複製貼上。n8n 剛好就是補這個縫的工具。

這篇會把三條流程拆成節點圖，講清楚每一步該開哪個設定、哪裡最容易出事，最後誠實講 n8n 的天花板在哪，什麼情況該改成客製中介層。

n8n 串 ERP 速覽：三條流程、核心節點與最容易出事的地方

先給答案：三條流程的觸發方式不同，風險也不同。訂單流程怕重複建單，請款流程怕金額算錯，通知流程怕漏通知或洗版。

如果你要的是「LINE 下單有哪幾條路、各花多少錢」的比較，我們在 LINE 訂單系統怎麼串 ERP 那篇整理過四種做法；想看報價、請款、出貨這條單據鏈的資料要怎麼對齊，可以看 報價單、請款單、出貨單自動串接。這篇專講 n8n 這一層怎麼搭。

n8n 串 ERP 之前：先確認 ERP 給你哪一種入口

一句話：ERP 有開寫入 API，n8n 就好接；只能讀資料庫或只能匯入檔案，n8n 能做的事會少一大截。動手前先拿下面這張表去問你的 ERP 廠商。

n8n 有現成 ERP 節點的不多。官方文件裡的 Odoo 節點 支援聯絡人、商機、筆記，再加一個 Custom Resource 可以操作其他資料模型；台灣常見的本地 ERP 大多沒有現成節點，要靠 HTTP Request 自己打 API。

直接寫資料庫是最常見的誘惑，也是最危險的捷徑。ERP 建一張訂單，背後通常會連帶扣庫存、產生應收、寫稽核紀錄。你從資料庫直接 INSERT 一筆訂單，這些連帶動作全部不會發生，帳就這樣悄悄歪掉。我們的建議很硬：資料庫只讀不寫，寫入一律走 API，沒有 API 就先別寫。

如果盤下來發現 ERP 根本沒有好的入口，而你最痛的其實是「報價要算階梯價、要主管審核」這種前段流程，有時候比較划算的做法是把前段做成一套自己的系統，再把結果交給 ERP。這類系統我們做過：食品階梯報價與型錄系統 就是成本連動四階梯報價、主管審核加中英型錄匯出的一條龍流程，報價那一段不再卡在 ERP 裡面。你的情況如果類似，找我們聊會比從零開始描述需求快很多。

流程一：LINE 或表單訂單自動寫進 ERP

先講結論：這條流程的成敗在「冪等」，也就是同一筆訂單送進來兩次，ERP 裡也只能有一張單。其他都是細節。

收單：Webhook 節點與驗簽

Webhook 節點 有測試網址和正式網址兩組，正式網址要等工作流發布後才會生效，很多人在測試網址測完就以為上線了。驗證方式可選 Basic auth、Header auth、JWT auth。

LINE 這一段要另外注意兩件事。第一，n8n 內建的 Line 節點只支援 LINE Notify，而 LINE Notify 已在 2025 年 4 月 1 日停止服務，官方文件 標示這個節點從 1.64.0 版起棄用。要收 LINE 訊息、回覆客戶，得走 LINE Messaging API，用 HTTP Request 自己打。第二，LINE 送來的 webhook 會在 x-line-signature 標頭帶簽章，LINE 官方文件 要求處理事件前先驗簽，也建議非同步處理事件，別讓後面的請求排隊等。

擋重複：同一筆訂單不能寫兩次

重複送單比你想的常見。LINE 官方文件寫得很直白：同一個 webhook 事件可能因為網路路由等原因送到你的伺服器不只一次，要用 webhookEventId 判斷重複；開啟 Webhook redelivery 之後，重送的事件內容和原本一樣，只差 deliveryContext.isRedelivery 這個欄位。

n8n 這邊可以用 Remove Duplicates 節點 的 Remove Items Processed in Previous Executions 模式，拿 webhookEventId 或你自己的訂單編號當比對值，之前處理過的就丟掉。這是第一道防線。

第二道防線要放在 ERP 那一端：寫入 API 時帶一個由訂單內容算出來的唯一鍵（業界叫 idempotency key，Stripe 的 API 文件 是這個做法最常被引用的範例），ERP 收到同一個鍵就回傳既有那張單，不再新建。ERP 不支援的話，就先用 HTTP Request 查「這個外部單號有沒有建過」，查到就跳過。兩道都做，才睡得著。

對資料：料號和客戶編號對不上怎麼辦

LINE 訂單最亂的地方在文字。客戶打「紙杯 8 盎司 白色 2 箱」，ERP 要的是料號和單位。能用固定格式（表單、選單、LIFF 頁面）就別讓客戶自由打字；真的要吃自由文字，就在 If 節點把「料號對不上」的單分流給業務人工確認，不要讓 n8n 硬猜。用 AI 解析訂單文字可以，但解析結果一定要經過料號主檔比對，對不上就退人工。

流程二：報價核准後自動開 ERP 請款單

一句話分工：n8n 負責「等人核准」和「把結果送進 ERP」，金額怎麼拆、稅怎麼算，留給 ERP 或一段寫好測試的程式。

「等主管按核准」以前是 n8n 最難搭的一段，現在有現成做法。Gmail、Slack 等節點都有 Send and Wait for Response 操作，送出訊息後工作流會暫停，等收件人回覆才繼續。另外 Wait 節點 也能設成 On Webhook Call，產生一個每次執行都不同的 resume 網址，你可以把它嵌進自己系統的「核准」按鈕。暫停期間，執行資料會先存進資料庫，不會一直占著記憶體。

這條流程我們最常提醒的是分期請款。訂金 30%、交貨 60%、驗收 10%，再加上部分客戶要開兩張發票，規則一多，Code 節點裡的 JavaScript 很快就變成沒人敢動的黑盒子。判斷方式很簡單：請款規則超過三種、或會因客戶而異，就把「算金額」抽成一支有單元測試的服務，n8n 只負責呼叫它。

分期收款算錯的痛，我們在 汽車包膜報價與簽約系統 這個案子看得很清楚：每台車部位、材料、尺寸都不同，分階段收款時訂金常被重複扣。後來做成線上報價加電子簽約，勾選就出單，訂金自動分配，客戶在 LINE 簽完就通知。金額邏輯集中在一個地方，流程工具只負責傳話，這個分工到 n8n 上一樣適用。

流程三：ERP 單據異動，主動通知業務與客戶

先給答案：這是三條裡最適合 n8n、也最該先做的一條。它只讀 ERP、不寫 ERP，出錯頂多是通知晚了，不會把帳弄壞。

典型的需求長這樣：出貨單建立了要通知客戶物流單號、應收逾期三天要提醒業務、庫存低於安全量要通知採購。ERP 能主動推 webhook 最好；不能的話，就用 Schedule Trigger 每 5 到 15 分鐘查一次「最近更新的單據」。

輪詢最容易出的事是重複通知。Remove Duplicates 有一個 Value Is a Date Later than Any Previous Date 的比對方式，拿單據的更新時間當比對值，只放行比上次還新的資料，正好解決這個問題。

第二個是打爆 API。一次撈回 300 筆異動、每筆都要再查一次明細，ERP 的 API 很可能直接拒絕你。n8n 官方的速率限制處理文件 給了兩招：開 Retry On Fail 並把 Wait Between Tries 設得比對方的限制還長，或用 Loop Over Items 分批、搭配 Wait 節點在每批之間停一下。HTTP Request 節點本身也有 Batching 選項可以做到同樣的事。

三條 n8n ERP 流程共用的四道防線

一句話：權限要小、寫入要冪等、重試要有上限、壞了要有人知道。這四件事做齊，n8n 串 ERP 才算可以上正式環境。

節點的錯誤行為有三個選項，官方文件 寫得很清楚：On Error 可以選 Stop Workflow（整條停下）、Continue（帶著上一筆有效資料繼續）、Continue (using error output)（把錯誤資訊送到另一個輸出，讓你接一段處理）。寫入 ERP 的節點，我們建議用最後一個，失敗的那筆另外記下來給人看，不要讓 Continue 帶著舊資料往下跑。

想看重試策略更細的分類（哪些錯誤該重試、該退避多久），我們在 排程治理 SOP 那篇整理過一張完整的錯誤類型對照表；fallback 怎麼設計，可以看系列第一篇的 內部報價自動化 SOP。

我們自己的 n8n 怎麼跑：四個真的踩過的坑

我們公司自己每天就在跑 20+ 個 AI 流程，其中一部分跑在自架的 n8n 上（部署在 Zeabur，資料庫用 PostgreSQL）。下面這幾條沒有串 ERP，但每一條都是串 ERP 時一定會再遇到的問題。

還有一個坑跟節點接法有關：兩個平行的 HTTP Request 同時接進同一個 Code 節點，Code 節點會被觸發兩次，其中一次會因為另一個節點還沒跑完而報錯。我們的解法是改成序列連接。串 ERP 時常會「同時查客戶資料和庫存再合併」，這種情況請用 Merge 節點 明確合流，或乾脆排成前後兩步。

這些問題換成任何流程工具都會遇到，只要把流程交給機器跑，就得先想好它們。我們在 N8N + ChatGPT 企業自動化實戰 整理過更多正在運行的案例，入門操作可以先看 n8n 教學。

什麼時候 n8n 串 ERP 不夠用，該改客製中介層

我們的判斷很直接：n8n 很適合當 ERP 的「傳話筒」，不適合當 ERP 的「第二個大腦」。只要流程裡開始出現自己的商業規則、自己的資料狀態，就該考慮把那一段搬出 n8n。

上面幾條限制都寫在 n8n 官方文件裡：Data tables 適合輕到中量資料，自架可以用環境變數調高上限；同時執行數 在一般模式下預設不設限，太多執行同時跑會拖垮事件迴圈，官方建議用 N8N_CONCURRENCY_PRODUCTION_LIMIT 限流。

費用也要算進來。n8n 的官方定價以「整條工作流跑完一次」計次，不論中間有幾個步驟：雲端 Starter 年繳每月 20 歐元含 2,500 次、Pro 每月 50 歐元含 1 萬次；自架的 Community Edition 免授權費，但主機、備份、升級要自己顧。

中介層要怎麼評估、自建和買 iPaaS 各花多少，我們在 客製化跨系統 API 整合中介層完整指南 有完整的決策表。n8n 和 Make、Zapier 怎麼選，看 三巨頭比較。如果你還在猶豫要不要買 ERP，ERP 太貴的 5 條替代路徑 裡的「Excel 加 n8n」那條路，適合先拿來驗證流程。

如果卡關的原因是 ERP 本身不合用，自動化只是在補洞，那該處理的是 ERP 選型。可以先看 現成 ERP 為什麼總是不符需求、台灣 12 套 ERP 對照，以及 企業 ERP 選型指南。電子發票要一起串的，電子發票整合外包指南 列了該問廠商的問題；LINE 這端要做到對話式下單，可以看 LINE Bot 客製化開發指南。