批發零售通路
全通路整合成一份客戶資料
電商、門市、物流、維修、會員收進同一個平台，而 ERP 主帳一行都不用改
把電商、實體門市、物流、維修預約與會員服務做成單一平台，並與既有 ERP 以「讀走鏡像、寫走 API」的方式協作。全通路整合最難的不是介面，是不讓新系統寫壞多年的主帳。
客服終於查得到全貌
線上下單和到店保養的同一位客戶，在系統裡不再是兩個人。接到電話就能看到完整往來紀錄。
ERP 主帳零改動
讀走鏡像、寫走 API。平台不直接動 ERP 資料表，新平台的錯誤不可能寫進財務主帳。
客戶只要記一個入口
預約、購物、詢問、會員服務都在同一個官網。不必再記「保養要打電話、買東西要上網」。
怎麼運作
資料鏡像同步
ERP 資料同步至平台側並轉換成適合前台查詢的結構，前台流量不會拖慢出貨作業。
前台統一入口
電商、預約、客服、會員在同一個官網，跨通路辨識同一位客戶。
回寫走 ERP API
需要落帳的動作交由 ERP 自己驗證與寫入，邊界清楚。
規格
- 整合通路
- 5 條
- ERP 改動
- 無
- 資料流向
- 讀鏡像／寫 API
- 客戶辨識
- 跨通路統一
問題：五個通路，五份不一致的真相
業主同時經營電商、實體門市、物流配送、維修預約與會員服務。每一條通路都有自己的資料，而它們對「同一位客戶」的認知並不一致——線上下單的張先生和到店保養的張先生，在系統裡是兩個人。
這就是全通路整合真正要解的題：不是把五個網站做得一樣好看，而是讓五條通路指向同一個人。
結果是：客服接到電話查不到完整紀錄、庫存在門市與網站之間對不上、行銷活動無法針對真正的回購客。
最關鍵的決定：不動 ERP 主帳
既有的 ERP（進銷存與會計主帳）已經運行多年，是全公司的帳務根本。任何要求 ERP 改寫或直連的方案都應該被否決——一旦新平台的錯誤寫進主帳，代價是財務資料的正確性，那不是重跑一次就能修的。
平台因此採「讀走鏡像轉換、寫走 API」：
- 讀 — ERP 資料以鏡像同步至平台側，經轉換成適合前台查詢的結構。平台的所有讀取都在鏡像上進行，不對 ERP 造成查詢壓力，也不會因為平台流量而拖垮出貨作業。
- 寫 — 需要回寫的動作一律走 ERP 既有 API，由 ERP 自己驗證與落帳。平台不直接動 ERP 的資料表。
這個邊界劃清楚之後，平台可以放心迭代，ERP 端幾乎不需要配合改動。
繼續看：架構、工程紀律與據實說明
對外與對內是同一套資料
對外是統一官網：預約、購物、客服詢問、會員服務都在同一個入口，客戶不必記得「保養要打電話、買東西要上網」。電商系統開發、門市系統與會員系統在這裡不是三個專案，而是同一份資料的三種介面。
對內則讓各角色即時看到同一份事實：客戶下了什麼單、買了什麼商品、哪個品項缺貨。整合的價值不在於介面好看，而在於全公司終於在同一份資料上討論事情。
規模
五條通路、一套 ERP 整合、一個前台，這個量體已經不是「一個網站」，而是一套需要長期維運的營運系統。因此開發與部署環境用 Docker 統一，文件與環境一致性從第一天就納入規劃——不是上線前才補。
關於這個案子，常被問到的是
全通路整合一定要換掉現有的 ERP 嗎？
不用，而且不建議。運行多年的 ERP 是全公司的帳務根本，任何要求它改寫或直連的方案都該被否決。這個案子採「讀走鏡像轉換、寫走 API」：讀取全在平台側的鏡像上做，回寫一律走 ERP 既有 API 由它自己驗證落帳，主帳一行都不用改。
為什麼讀資料要先做一份鏡像，不直接查 ERP？
兩個理由。一是壓力：前台的查詢流量若打在 ERP 上，出貨作業會被拖垮。二是結構：ERP 的資料表是為了記帳設計的，不是為了前台查詢，直接查會又慢又難維護。鏡像同步之後再轉換成適合查詢的結構，兩邊各自舒服。
門市系統跟電商的庫存怎麼對得起來？
前提是兩邊看的是同一份事實。庫存的權威來源仍在 ERP，平台側讀鏡像呈現，不各自維護一份。過去對不上，多半是因為門市與網站各存各的，而不是同步做得不夠快。
這種規模的平台要怎麼長期維運？
五條通路、一套 ERP 整合、一個前台，量體已經不是一個網站，而是一套要長期維運的營運系統。所以開發與部署環境用 Docker 統一，文件與環境一致性從第一天就納入規劃，不是上線前才補。