食品零售業規劃 ERP 客製開發時，常把需求寫成採購、庫存、銷售、報表與電子發票五個模組，但實際爭議通常發生在模組交界：門市叫貨和總部採購是不是同一張單、收貨短少由誰確認、退貨後庫存和成本如何變動、POS 的商品與 ERP 商品如何對應、發票服務失敗時訂單能不能完成。若這些事件沒有共同定義，新系統只會把多份 Excel 變成多個彼此對不上的畫面。

食品零售 ERP 的規格應先從商品主檔和庫存事件開始，再決定頁面。這不代表所有企業都要採用相同欄位，而是每個編號、狀態與數量都必須有清楚來源、負責人和變更規則。

商品條碼不是完整的商品主檔

GS1 Taiwan 的條碼登記廠商手冊說明，公司前置碼、公司主體位置碼與商品條碼用於獨一識別，登記廠商有責任維護廠商及商品資料正確，並在編定新商品條碼前於台灣產品電子目錄登錄相關資料。這份文件可支持 ERP 把外部識別碼視為受管理資料，但不表示掃到條碼就能自動得到企業營運需要的所有資訊。

內部商品主檔仍要區分銷售單位、採購單位、包裝換算、規格、供應商料號、稅別、啟停用狀態，以及公司實際需要管理的保存或批次欄位。同一內容物若有單包、整箱與促銷組合，必須定義它們是不同可銷售品項，還是透過換算關係扣除同一庫存。條碼、內部 SKU 和供應商料號各有用途，不應在沒有轉換表時互相覆寫。

商品變更也要有程序。名稱修正是否影響既有單據、包裝改版是否建立新品項、停賣後歷史報表是否仍能查到，都應在主檔規格中說明。測試資料要刻意包含相似名稱、不同包裝、停用品和缺漏欄位，才能驗證匯入時不是「檔案成功上傳」卻留下無法下單的資料。

庫存要記事件，不只記目前數字

「WMS Pro 倉儲儀表板」案例把入庫、上架、揀貨到出貨分成作業階段，並集中呈現倉區使用率與異常。這個案例提醒 ERP 驗收不能只看畫面上的現有量；每一次收貨、移轉、揀貨、報廢、退貨與盤點調整，都應留下事件類型、數量、位置、時間、操作人與來源單據。

例如採購一箱商品但只收到部分數量時，系統要能保留原訂量、實收量與未交量，而不是直接把採購單改小。門市調撥途中發生差異時，要知道庫存目前屬於出貨門市、運送中位置或收貨門市。盤點調整則應要求原因與核准權限，讓報表能區分正常交易和人工修正。

涉及食品的批次或日期管理範圍，應依企業實際商品與作業要求由負責人確認，不能因為系統叫 ERP 就假設所有品項採同一規則。規格可先列出哪些品類需要批次、收貨時由誰輸入、揀貨順序如何決定、資料缺漏是否阻擋入庫，以及退貨商品能否回到可售庫存。

門市訂貨與總部採購是兩個決策

「鮮達 FRESHDA 訂貨系統」案例提供買方與賣方雙端介面，讓同一筆訂單兩邊同步，並支援常訂品項快速重複下單。用在食品零售 ERP 規劃時，可以把門市需求和供應商採購分開：門市提出的是補貨需求，總部可能合併多店需求、考量現有庫存後，才形成對外採購單。

驗收情境應包含門市修改或取消需求、總部合併訂單、供應商部分到貨、替代品確認和跨店調撥。每個狀態都要指定誰能變更、下一步由誰處理，以及變更後哪些數量重新計算。若系統要提供建議叫貨，先揭露計算使用的銷售期間、現有量、在途量與安全量；不要把未經驗證的建議直接當成自動採購結果。

「火鍋連鎖店智慧管理系統」案例則整合出勤薪資、交接紀錄、SOP、OCR 貨單辨識與跨店成本比較。OCR 適合降低輸入工作，但辨識結果仍需要原始影像、信心不足提示與人工確認流程。若貨單品名和商品主檔無法對應，系統應進入待處理狀態，而不是自行建立可能重複的商品。

電子發票串接要設計失敗路徑

財政部財政資訊中心的電子發票營業人應用 API 規格 Ver. 1.9說明，其 API 以 HTTPS 提供，部分方法需要 AppID 與 APIKey，回傳結果採 JSON；文件也明確提醒 APIKey 必須防止外流。這些是技術介面的公開規格，不應被延伸解讀為每家公司的開立流程或法規責任都相同。實際導入仍須依使用的發票服務、帳號資格與會計流程確認。

ERP 規格至少要定義：哪一個事件觸發發票作業、訂單編號如何對應發票請求、逾時是否重試、重送如何避免重複處理、失敗由誰收到通知，以及作廢或後續調整如何回寫。APIKey 不應出現在前端程式、一般使用者畫面或可公開的紀錄中；正式和測試環境也要分開管理。

驗收不能只做一筆成功案例。應測試必要資料缺漏、服務逾時、回傳失敗、重複送出與人工補處理，並確認訂單、發票狀態和會計查詢不會各自顯示不同結論。本文不提供發票法律判斷；遇到開立時點、憑證類型或特殊交易問題，應由企業的財會與服務供應商確認後，再轉成系統規則。

用日結對帳驗收整條資料鏈

系統上線前，選一個門市營業日的代表資料，從商品、進貨、調撥、銷售、退貨一路走到發票與報表。對每個節點核對期初、增加、減少與期末，並能從彙總數字追到原始單據。差異不只要顯示「不一致」，還要指出發生在哪個介面、哪個時間區間和哪一批事件。

最後把商品主檔擁有人、庫存調整核准者、串接監控窗口、帳號金鑰管理者與異常處理期限寫進維運文件。ERP 客製開發的價值，不是把所有流程塞進一套系統，而是讓每一個重要數字都能回答從哪裡來、為何改變、由誰確認，以及出錯時如何回復。當這條資料鏈能在驗收環境中反覆走通，才適合進入正式上線。