食品零售做企業系統外包時，需求常被寫成「門市可以查庫存、總公司可以匯入盤點結果」。若資料表只有商品、門市與數量三欄，畫面雖然很快做出來，卻無法回答架上有貨但已被訂單保留、商品等待品管、調撥正在路上，或舊試算表覆蓋剛發生銷售等日常問題。

庫存不是一個可任意改寫的總數，而是一組有原因、有位置、有時間的狀態。發案前先定義商品識別、門市位置、數量狀態與異動事件，再把批次匯入的衝突處理寫進驗收，才能避免上線後繼續用人工群組訊息修正系統。

把「有幾個」拆成可營運的狀態

Shopify 的 Understanding inventory states 將庫存區分為現有、可售、已保留、不可售與在途等狀態；其中可售不包含已保留或不可售，在途也要等收貨後才成為可售。這是特定平台的設計，不是所有食品零售系統都必須照抄，但它清楚說明同一件商品不能只用一個「庫存量」支撐所有決策。

需求訪談可以從現場語言開始：門市說的庫存，是實際看到的總量，還是今天仍能賣的量？網路訂單成立後何時保留？破損、待檢、逾期或內部留樣要放在哪個狀態？店間調撥在出貨門市扣除後，收貨門市何時增加？每個答案都應變成狀態轉換，不是讓人直接改最後數字。

每筆異動至少記錄商品或規格、門市、原狀態、目標狀態、數量、原因、來源單據、操作者與時間。這樣盤點差異才有路徑可查，也能區分銷售扣庫、調撥、報廢、盤盈虧與人工更正。若食品業務還有批號、效期或保存條件，是否納入本期範圍應由實際流程決定，不能只因套裝系統有欄位就假設已完成追溯需求。

商品與位置要有穩定識別，不靠顯示名稱對資料

「原味餅乾」「原味餅乾大包」或門市改名，都可能讓試算表比對錯列。系統需要不隨顯示文案變動的商品／規格識別與門市識別；名稱是給人閱讀，識別碼才是串接與匯入的依據。停售也不等於刪除：既有訂單、調撥與歷史報表仍要能指向原商品。

規格表要定義同一商品在不同門市能否分別啟用、中央倉與門市是否使用相同狀態、包裝單位如何轉換，以及轉換後是否允許小數。若一箱與單件都會操作，不能只寫「數量」而不寫單位與換算基準。任何換算都應以企業確認的商品主檔為準，不由開發者猜測。

批次匯入不能無條件覆蓋現況

Shopify 的庫存 CSV 匯入文件說明，匯出檔可包含不同地點與庫存狀態；當檔案同時帶有匯出時的現有量與預計新量，平台會比較目前資料，若匯出後庫存已變動，受影響列會拒絕匯入並回報驗證失敗。這提供企業系統一個可驗收的模式：長時間開著的試算表，不應悄悄蓋掉期間發生的銷售或收貨。

客製系統可以用資料版本、最後更新時間或批次快照實作相同保護概念。每一列匯入結果應分成成功、格式錯誤、找不到識別、版本衝突與權限不足；失敗列不應被算進成功數，也不能只回覆「部分失敗」而沒有可下載明細。

重新匯入時要避免成功列重複套用。最簡單的驗收是：同一批次檔送兩次，第二次不應讓數量再增加一次；修正失敗列後，系統只處理尚未完成的項目。若採用「設為新數量」與「增減數量」兩種操作，介面與權限必須明確區分，因為兩者重送後的風險完全不同。

用跨角色看板案例檢查資訊優先順序

沐光身心診所門診管理展示案例把掛號、候診、看診狀態與申報流程集中在同一儀表板。它是診所管理展示作品，不是食品零售客戶案例，也不能證明零售導入成果；可借用的是「不同角色共用狀態，但看到的待辦不同」這個介面驗收方法。

套用到食品零售，門市人員先看到需收貨、待盤點與不可售處理，區域主管看到跨店差異與逾時調撥，總公司則看到主檔錯誤與批次匯入衝突。所有角色讀取同一筆庫存異動，但操作權限與下一步不同。如此才能避免為每個部門另做一份互不一致的 Excel。

可用一組模擬情境驗收：總公司上午匯出門市庫存，期間門市售出商品並建立調撥；下午總公司修改舊檔再匯入。系統應拒絕有版本衝突的列，保留期間銷售與調撥，並讓人逐列決定重新整理或人工調整。接著將一批商品標成不可售，確認它仍算在現有量，但不出現在可售量。

外包交付要包含對帳、回復與營運演練

驗收資料不要只準備正常正數。還要包含零庫存、不存在的商品、停用門市、重複列、錯誤單位、同時更新與只有部分列成功。每次測試保存匯入檔、批次識別、結果明細與異動紀錄，確認能從門市總數一路對回事件。

交付清單也要說明誰維護商品與門市主檔、誰可調整庫存、失敗通知給誰、錯誤批次能否撤銷，以及撤銷是否會傷到批次後的新異動。若外部 POS、購物網站或物流系統參與同步，還要分別列出資料主責與斷線時的補送方式。

食品零售的門市管理系統不應只是把盤點表搬上網。先讓每個庫存數字有狀態、有位置、有來源，再用版本衝突與重送情境驗收批次更新，系統才能在多人、多店與持續交易中維持可信，而不是成為另一份需要人工對帳的表格。