醫美團隊規劃進銷存系統時，最常見的第一張畫面是「目前庫存」。但單一剩餘數字無法回答物品在哪個據點、屬於哪個批次、何時入庫、為何減少、盤點差異由誰核准，以及外部系統重送資料時是否重複扣帳。若開發只把 Excel 欄位搬進後台，問題會從多人檔案衝突，變成一個更難追查的錯誤總數。

本文討論的是一般系統分析與驗收方法，不判定特定品項的醫療、藥事、會計或保存義務。實際需要記錄的欄位、使用方式與保存期限，應由組織依品項性質、供應商資料、內部程序與適用規範確認。開發團隊不能自己猜法規，也不能用一套固定欄位代替業務確認。

先分清楚品項、批次與實際庫存

品項主檔描述「這是什麼」，可以包含內部代碼、名稱、規格、計量單位、供應商與啟用狀態；批次描述某次取得的一組貨，可能有批號、有效日期、到貨日期和來源單據；庫存則描述某批物品目前在哪個地點、處於可用、保留、待檢、損壞或其他狀態，以及數量是多少。三者若混在同一列，日後更名、換供應商或拆分據點時就會破壞歷史紀錄。

GS1 Taiwan 的可追溯性全球標準說明，消費品條碼除了商品識別外，也可能包含批次或批號、序列號、有效期或最佳日期等動態資料，並強調條碼、相關資料與實際品項之間的正確連結。文件也以收貨後掃描物流單元為資料捕捉步驟之一。這表示進銷存規格不應只寫「支援掃條碼」，而要說明掃到的識別值對應品項、批次、效期還是物流單元，沒有資料或格式不符時又如何處理。

驗收資料應刻意包含同品項不同批號、同批號分兩個據點、相同條碼但不同包裝單位，以及沒有可掃描碼的例外。操作人員掃碼後要看到他正在處理哪個層級，不能讓系統把品項碼誤當批號，或因找不到資料就自動建立一筆未經確認的主檔。

餘額應由庫存異動帳推導

可靠的庫存不是一個任何人都能直接改寫的數字，而是一系列有原因的異動。入庫、領用、退回、調撥、報廢、盤盈與盤虧都應建立獨立紀錄，至少包含品項、批次、來源地、目的地、數量、原因、操作者、時間和關聯單據。畫面上的餘額由這些異動彙整；若要更正，應新增反向或調整紀錄，而不是悄悄改掉舊數字。

這種設計讓盤點差異可被說明。盤點作業要先凍結或界定盤點範圍，記錄帳面數、實點數與差異，再由適當角色確認是否產生調整。若盤點期間仍允許領用，系統要能辨識盤點基準時間，否則現場永遠無法判斷差異來自操作、時間差還是資料錯誤。

效期也不只是報表上的排序欄位。需求方要先定義何時提醒、哪些狀態納入可用量、跨據點調撥是否保留原批次，以及領用時是建議先到期先出，還是由授權人員依情境選擇。系統可以提示與阻擋，但規則必須在開發前由組織確認，不能讓工程師自行推定醫療作業。

API 重送不能造成第二次扣庫存

當預約、門診、採購、會計或其他系統透過 API 傳入領用與退回事件時，網路逾時會產生一個常見問題：送出端不知道第一次是否成功，因此再次傳送。如果接收端每收到一次就新增異動，同一筆操作可能被扣兩次。

MDN 的 HTTP request methods 文件列出各方法的語意，並說明 PUT 具有冪等性，而 POST 與 PATCH 並不保證冪等。這不代表把端點名稱改成 PUT 就自然安全；系統仍須依業務設計確保重複請求的預期效果一致。對庫存 API 而言，可以要求來源系統提供穩定的事件識別碼，接收端保存處理結果；同一識別碼重送時回覆既有結果，不再建立第二筆異動。

規格還要處理內容衝突。如果相同事件識別碼第二次帶來不同數量，系統不應默默採用新值，而應拒絕、告警或進入人工檢查。驗收時可以模擬逾時後重送、順序顛倒、來源取消、部分成功及人工補登，確認庫存帳與外部系統都能對回同一事件。

從沐光門診管理案例確認系統邊界

「沐光身心診所 門診管理」（clinic-management）案例把掛號候診、看診狀態與健保申報整合在同一個儀表板。這個案例的重點不是宣稱它具備醫美庫存功能，而是提醒團隊：臨床或櫃檯流程已有自己的狀態與責任，進銷存不應直接以「看診完成」猜測所有物品都已領用。

若要串接，可以由門診流程產生一筆待確認的領用事件，帶入關聯服務與預定品項，再由有權限的人確認實際批次和數量；或者依組織核准流程，在明確事件發生時自動扣帳。兩種方式沒有普遍正解，應以實際工作和風險決定。驗收要包含看診取消、服務變更、只使用部分數量、退回未使用物品，以及事後更正等情境。

介面上也應維持角色邊界。櫃檯需要看到的候診資訊、庫房需要處理的批次庫存、主管需要查看的差異與核准，未必應出現在同一個帳號或同一張表。系統整合的目的，是讓事件有可追查關聯，不是讓所有人看見所有資料。

用 WMS 看板案例設計異常工作台

「WMS Pro 倉儲儀表板」（wms-warehouse）案例涵蓋入庫、上架、揀貨到出貨的即時作業看板，也集中呈現倉區使用率與異常。醫美進銷存可以借用「正常流程與異常分流」的介面觀念：首頁不只顯示總量，還要讓負責人找到待上架、批次資料缺漏、即將到期、盤點待核准、API 失敗和負庫存等需要處理的工作。

但案例中的倉儲流程不能原封不動套用到診所。需求方應選出自己真正需要的事件與狀態，並為每種異常指定負責角色、處理期限或升級方式。系統若只亮紅燈，卻沒有負責人、處理入口與結案條件，儀表板很快會變成無人理會的警示牆。

以一批物品走完端到端驗收

正式驗收可以挑一個測試品項，建立兩個批次與不同效期，完成收貨、分配據點、領用、部分退回、跨點調撥、盤點差異與報廢；中途重送一次 API 事件，並故意讓同一事件帶入衝突內容。每一步都要能從餘額追到異動、從異動追到操作者與關聯事件，並確認更正不會抹掉原始紀錄。

交付清單應包含資料字典、品項與批次識別規則、庫存狀態、異動類型、效期提醒、盤點流程、角色權限、API 去重鍵、錯誤重試、報表定義及資料匯出方式。若現成系統能涵蓋這些核心規則，應優先評估設定與導入；若跨據點、特殊單位換算或既有流程無法合理配合，再界定必要的客製範圍。

醫美進銷存系統的價值，不是讓總庫存數字看起來即時，而是每一個數字都能說明由哪個批次、哪次異動與哪個責任角色構成。把批號、效期、異動帳、盤點與 API 例外寫進驗收，才能從「看得到庫存」走到「查得回庫存為什麼如此」。