商品上架・庫存・訂單・發票一條龍
2026
一句話摘要：這是一套訂閱制的多通路電商 SaaS ERP，把「商品上架、SKU 對應、庫存聯動、訂單與物流單、經營報表」收進同一個帳號，並延伸出載具發票與現金回饋 App。以 Laravel + GraphQL 多租戶架構開發，由渙潮科技（CS Studio）設計與實作。
這是一套專為台灣電商賣家打造的 SaaS ERP。賣家同時在多個平台開店，商品命名、價格、庫存各自為政；貨源又常來自境外，要先翻成在地內容才能上架；每天光是對帳、改庫存、印物流單就耗掉大半時間。我們把這些重複工作收進同一個帳號，做成訂閱制的雲端服務。
產品從「商品怎麼上架」開始：貨源進暫存區、認領到多個店鋪成為草稿、簡轉繁與匯率換算後批次發布；上架成功後自動建立店鋪 SKU 與內部 SKU 的對應，之後的訂單、庫存、採購與報表都以內部 SKU 為準，跨通路只算一次。
訂單進來後先鎖庫存、確認出貨、自動取回物流單，交運後才正式扣庫存並入帳。整條線上賣家只需要做兩件需要人判斷的事：確認訂單與揀貨裝箱。
同一個產品線還有一支載具發票 App，把消費者的手機載具發票、開獎對獎、導購現金回饋與提領放在一起，與 ERP 共用同一套設計語言與後端能力。
同一件商品上架到不同平台，命名習慣不一樣、定價策略也不一樣，本來就不該強求一致。後台把它們匹配成同一件商品，庫存扣同一批、採購算同一筆、營銷報告看同一條線。
畫面取自產品官網介紹，內容皆為模擬資料。
每件商品設一條安全量，庫存掉到線以下就跳警示，清單上直接標示出來。看到警示接著前往採購功能處理，不用等盤點才發現斷貨。
畫面取自產品官網介紹，內容皆為模擬資料。
各平台的訂單集中在同一個地方處理：訂單一進來庫存就自動鎖住，不怕超賣；一鍵安排出貨，物流單自動取回，你只要印出來貼上、把貨裝箱。
畫面取自產品官網介紹，內容皆為模擬資料。
營收、訂單、客單價、通路貢獻、熱銷排行，所有關鍵指標都幫你算好，不用再匯 Excel 自己拉樞紐。
畫面取自產品官網介紹，內容皆為模擬資料。
ERP 服務賣家，發票 App 服務買家。消費者用手機條碼綁定載具後，所有電子發票自動歸戶，每期開獎自動對獎；透過 App 導購到電商平台下單還能累積現金回饋，達門檻後提領到自己的銀行帳戶。 目前處於第一階段：全模擬資料的可操作原型，Android 與 iOS 都能執行，用來先把畫面與動線走順，再接真實服務。
把境外貨源商品先收進暫存區，保留原文標題、原幣價格與原始圖片；已認領與未認領分開檢視，避免同一批貨被重複處理。
勾選 N 件商品、M 個店鋪，一次產生 N×M 筆獨立草稿；每家店的定價、描述與分類可各自調整，重複商品可選擇複製或跳過。
簡體轉繁體並替換台灣慣用語、人民幣依匯率與利潤率換算新台幣、圖片上的簡體文字改以替換圖處理，讓境外商品能合規上架。
草稿經待發布、發布中到在線，失敗時把平台回傳的原因寫回草稿，修正後一鍵重發，不必整批重做。
蝦皮、momo、露天、酷朋共用同一組介面與同一份資料模型，平台差異收斂在轉接類別，新增平台不動主流程。
各店鋪 SKU 對應到同一個內部 SKU：編碼相同自動匹配、搬家時繼承原店匹配關係，其餘由賣家手動匹配或生成。
以內部 SKU 為單位看在庫與已鎖定量，一個通路賣出，其他通路的顯示庫存同步更新，不再各店各算。
訂單集中處理、先鎖後扣，安排出貨時自動取回物流單號與託運單，交運後才正式扣減庫存並入帳。
多倉、多庫區、多貨位逐格編號，出入庫與盤點全程留紀錄，揀貨不憑記憶找貨。
營收、客單價、通路貢獻與熱銷排行即時彙整，廣告成效、折價券與活動集中管理。
一個帳號一個商店，資料以租戶隔離；方案、試用與續訂由控制層統一管理，自助註冊即可開始使用。
手機載具同步發票、開獎對獎、導購回饋與提領集中在一支 App，與 ERP 同屬一個產品線的消費端延伸。
貨源商品先進暫存區，賣家勾選商品與目標店鋪「認領」，每個店鋪各產生一筆獨立草稿；經簡轉繁、匯率換算與人工調整後批次發布，平台回傳商品編號就同步成在線商品，並觸發 SKU 自動匹配、接上庫存。
認領是 N 件商品 × M 個店鋪的乘法：16 件商品選 2 家店會產生 32 筆草稿，因為每家店的價格、描述與分類本來就可能不同。
每筆草稿都只會處在五種狀態之一。失敗不是終點：平台回傳的錯誤原因會寫回草稿，賣家修正後可批次重發。
訂單從各電商平台進來後，不需要賣家逐筆搬資料：系統先比對店鋪 SKU 並鎖住共用庫存，賣家確認並排出貨，再由系統向物流端取得單號；賣家揀貨裝箱、物流取件交運後，系統回寫庫存與營收。
「鎖庫存」發生在賣家確認之前、「扣庫存」發生在交運之後，兩段分開處理，才能同時做到不超賣、也不會因為訂單被取消而讓庫存帳對不上。
訂單匯入即鎖定可用量，避免多個通路同時賣出最後一件；實際扣減等到物流交運，取消或退件只需釋放鎖定，不會動到帳面庫存。
各平台的商品名稱與價格各異，統一對應到同一個內部 SKU 後，庫存、採購與報表才能跨通路彙整，這是整個系統最不能出錯的一層。
匯入、對應、取單號、回寫都由系統自動完成，賣家只需要做需要人判斷的事：確認訂單與揀貨裝箱。
商品從暫存、草稿、在線一路往右流動；店鋪 SKU 在發布成功後對應到內部 SKU，內部 SKU 再接上倉儲儲位與訂單明細。上架端與出貨端因此共用同一個庫存真相。
會員以手機條碼登入後，發票從財政部載具資料同步進來，依期別列出並在開獎後對獎；另一條線是導購回饋：貼上商品連結或掃 QR 到電商平台下單，訂單成立後入帳，累積到可提領金額再申請提領。
發票與回饋是兩條獨立的資料線，只在「我的帳號」匯合：一邊決定會員看到什麼發票，一邊決定會員能提領多少。
產品拆成四個獨立服務：營運控制層（行銷官網、註冊、方案、訂閱與業主總後台）、ERP 業務 API（商品、訂單、庫存等純 API）、ERP 前端（賣家登入後的操作介面），以及載具發票 App。各自迭代、各自部署，營運端調整方案定價不會動到業務邏輯。
控制層與業務層使用同一台資料庫伺服器、兩個獨立 schema，各自擁有自己的 migration，避免資料表撞名與權責不清；業務表一律帶租戶識別，並以 Global Scope 在查詢時自動加上租戶條件、新增時自動填入，開發者不必也不應該手動帶條件，從機制上避免漏寫造成跨租戶讀取。
控制層負責登入並簽發 JWT，payload 內含租戶識別；業務 API 以共用金鑰驗證，並把租戶綁進請求上下文供資料層使用。登入入口與資料服務分離，卻不需要另外維護一套帳號同步。
後端只有一份商品與店鋪資料模型，平台差異全部收斂在轉接類別：每個平台實作同一組介面，包含發布、更新、同步、下架、取得分類、取得授權網址、交換授權碼。前端的草稿與在線商品頁是同一個元件，只靠平台參數切換；平台專屬欄位放在彈性的專屬欄位中，避免為了個別平台改動共用資料表。新增第五個平台時，只需補一個轉接類別、註冊授權流程，並補上少量專屬欄位。
蝦皮採 OAuth 2.0 授權，且一個租戶可以綁定多個店鋪並以店鋪組歸類；其他平台多為單店、以合作夥伴金鑰串接。授權憑證與重新整理憑證一律以加密欄位儲存。授權回呼放在業務 API 而不是控制層，因為發布商品與撈庫存每次都要用到憑證，跨服務呼叫的延遲與耦合不划算。
暫存商品保留貨源原文、原幣價格、原始圖片與採集帳號；認領時依「商品數 × 店鋪數」展開成多筆草稿，每筆獨立編輯，所以暫存商品與草稿是多對多關係。草稿狀態只能依序流轉，發布失敗時錯誤原因寫回草稿，讓重發有依據。
文字以 OpenCC 做簡轉繁，再套用一份人工維護的台灣用語對照表（例如視頻改影片、質量改品質、優惠券改折價券）；價格由租戶層級的匯率與預設利潤率換算，可手動覆蓋；圖片上的簡體文字短期以「上傳替換圖」處理，長期規劃以 OCR 辨識、繁體化後重繪。這一層決定境外商品能不能合規上架，是產品真正的價值所在。
發布成功回傳店鋪 SKU 後觸發匹配，規則有兩條：店鋪 SKU 編碼與既有內部 SKU 相同則自動綁定；商品從 A 店搬家到 B 店時，B 店的 SKU 繼承 A 店的匹配關係。其他情況由賣家手動匹配，或一鍵生成新的內部 SKU。內部 SKU 同時記錄在庫量與已鎖定量，庫存模組據此做聚合、聯動與補貨預警。
商品、訂單、庫存等資料以 GraphQL 提供，前端可精確指定欄位，列表與明細共用同一組型別，減少過度抓取。後端以 Laravel 模組化切分，各通路的匯入與對應邏輯獨立成服務。
方案、租戶、訂閱、付款紀錄各有專屬資料表；賣家自助註冊後自動建立租戶並進入試用，方案支援一次性、月繳與年繳。收款採綠界 ECPay，付款通知回呼成功後才更新訂閱狀態，整段以資料庫交易包覆。金流串接仍在持續開發中。
總後台以 Filament 建構，營運方可管理方案、租戶、訂閱與付款紀錄；付款紀錄為唯讀，避免人為改動對帳依據。
App 以 Flutter 搭配 Riverpod 分層，每個功能拆成資料模型、資料存取、組合邏輯與畫面四層。資料存取層只依賴介面，目前掛的是記憶體模擬實作（可真的增刪改，並帶有模擬延遲與「下一次呼叫故意失敗」開關，讓載入與錯誤畫面都能看到），之後以編譯參數切換成 REST API 或 Firebase 實作，畫面與業務邏輯不需重寫。路由以 go_router 做底部五個分頁與登入導向，新帳號與老帳號兩種情境可從開發者區塊切換，空狀態也都有下一步引導。
現成 ERP 多半只涵蓋常見通路與固定流程。電商賣家的痛點常在細節：同一件商品在各平台命名、定價不同，卻共用同一批庫存；商品要從境外貨源轉成在地內容再上架；出貨還要對接各家物流單。客製或 SaaS 化的好處，是能把這些對應規則做成系統的一等公民，而不是靠人工對帳補洞。
資料模型只有一份，各平台差異收斂在「平台轉接層」：每個平台實作同一組介面（發布、更新、同步、下架、取得分類、授權），前端的草稿與在線商品頁也是同一個元件、傳入不同平台參數。新增平台是補一個轉接類別與少量平台專屬欄位，而不是重寫一半程式。
業務資料表統一帶租戶識別，並在資料存取層以全域範圍（Global Scope）自動加上租戶條件；租戶身分來自登入簽發的 JWT，查詢與新增都不經過開發者手動帶參數，從機制上避免漏寫條件造成跨租戶讀取。各店鋪的平台授權憑證也以加密欄位儲存，不以明碼落地。
目前是第一階段：以模擬資料做出可在 Android 與 iOS 操作的完整原型，涵蓋載具登入、發票列表與對獎、現金回饋、提領與會員等級等流程，用來先確認畫面與動線。資料層預留了 API 與 Firebase 兩個切換點，之後接上真實服務時，畫面與業務邏輯不需重寫。
這類產品屬於持續迭代型專案：先以控制層（訂閱、金流、租戶）與業務 API 搭好骨架，再依通路與模組逐步擴充。核心骨架一般 3–4 個月可上線試用，之後依串接的通路數量、在地化工具與報表需求滾動交付。
