食品零售業者評估電商網站製作時，常把金流、物流與電子發票各寫成一個串接項目。但真正容易出錯的時刻，不是顧客第一次結帳，而是結帳後發現某項缺貨、改取貨方式、取消部分數量，或客服需要補收與退款。訂單總額一變，付款、庫存、履約與發票不會自動成為同一件事。

需求書若只寫「訂單可修改」，開發團隊仍不知道哪些狀態允許改、誰能改、舊內容如何保留，以及外部服務失敗時要停在哪一步。先把變更拆成有版本的事件，再分別定義交易與發票的後續動作，才有可測試的邊界。

訂單成立後不要覆蓋原始快照

Shopify 的 Editing orders 文件說明，訂單建立後可在履約前增減商品、調整數量與運費，或套用、移除折扣；變更後若金額增加，可傳送更新後的付款通知，若金額下降則可退款。文件也提醒，編輯前要理解變更對付款、履約與報表的影響。

這個設計重點不是要求客製網站照抄 Shopify，而是「改訂單」必須留下前後差異。系統至少應保存原始品項、數量、單價、折扣、運費與總額，再以變更版本記錄新增、刪除及調整內容。客服畫面要能回答誰在何時因何原因修改，而不是只看到改完後的結果。

食品訂單還要處理不可逆的現場進度。商品已揀貨、已交付物流或已由門市備妥時，是否仍能直接刪除品項，應由營運規則決定。較安全的做法是讓每個動作先檢查履約狀態；超出自動處理範圍時改成申請、核准或人工例外，而不是讓前台金額變了、倉庫卻仍照舊出貨。

差額不是直接改付款成功金額

付款狀態應與訂單版本分開。加購可能需要新的一筆收款請求，減量可能產生部分退款；兩者都不應回頭覆寫原交易。規格要保存金流服務的交易識別、請求金額、回應結果與關聯訂單版本，讓財務能從目前應收一路對回每次收款及退款。

驗收時可先建立一張含三項商品的訂單，付款成功後刪除一項，再增加另一項。系統應清楚顯示原始總額、減項、增項、已收、待補收與待退，而不是只出現一個不知如何形成的「最新總額」。若付款通知重複或晚到，也不能把已取消的補款重新標成完成。

庫存也要依事件處理。刪除品項後，是立即解除保留、等待客服核准，還是等退款完成才釋放，應依企業流程明定。對短效期、限量或門市取貨商品尤其不能讓客服、倉庫與網店各自推測。

電子發票要跟交易事件對照，不與訂單共用狀態

財政部電子發票整合服務平台在 2024 年 12 月 12 日發布的 MIG 4.1 修訂公告指出，新版配合「統一發票使用辦法」第 20 條之 1，主要調整包含折讓證明單僅能由賣方開立或作廢並上傳平台，並說明自 2025 年 1 月 1 日施行。這是一項可驗證的交換規格變更，也說明發票處理不能靠電商系統自行猜測固定流程。

專案應先確認實際採用的加值中心、B2C 或 B2B 情境、開立時點，以及退貨、折讓、作廢或重開由哪個服務與角色執行。網站後台可以發出請求，但不能只要 HTTP 已送出就顯示成功；應保存業務事件、發票請求識別、外部回應與最後確認狀態。法規與訊息版本仍應由業者、會計或服務供應商依實際情境確認，本文不代替稅務判斷。

訂單狀態、付款狀態與發票狀態也不能共用一欄。例如訂單已取消，不代表退款已完成，更不代表對應發票處理已被外部平台接受。後台應分欄呈現，並提供需要人工處理的異常清單，避免客服只看「已取消」便向顧客承諾所有後續都完成。

用 MORIÉ 案例拆解前台與交易後台

MORIÉ 森澄研展示案例把商品分類、需求篩選、收藏、購物車與站內結帳串成完整購物動線。這個案例適合用來盤點「顧客看見的購物內容」與「後台保存的交易快照」：商品頁可以持續更新文案與售價，已成立訂單仍應保留購買當下的品名、規格、數量與價格，不應因商品主檔後來修改而改變歷史。

可用案例中的購物車建立測試：顧客買兩種保養品，客服在付款後因缺貨移除其中一項。前台應看見變更內容與退款進度；後台應保留原訂單、變更版本、庫存釋放、退款請求及發票後續的關聯。案例是網站展示作品，不代表食品零售的實際營運成果；它提供的是可操作的介面與資料邊界參考。

食品零售還可以追加重量商品、組合包、贈品、門市限定與不同稅別等自己的情境。重點不是沿用保養品欄位，而是逐一確認變更後哪些資料必須重新計算、哪些必須保留原值，以及哪一步需要人工判斷。

用失敗路徑完成驗收

正式驗收至少應涵蓋付款前改量、付款後減項、付款後加購、部分缺貨、已揀貨後取消、退款失敗、發票服務逾時與相同請求重送。每個情境都要列出訂單版本、付款差額、庫存保留、履約進度、發票狀態、顧客通知及人工待辦。

也要核對報表口徑。銷售報表採原始訂單、最新訂單還是實際收款？退款日與下單日跨期時如何呈現？這些定義應由業務與會計確認，系統只負責保存足以重算的事件，不用一個總額取代所有歷史。

食品電商網站製作的難點，不是把金流、物流與電子發票三個 Logo 放進規格，而是訂單變更後仍能讓每個系統對到同一組事實。保留原始快照、記錄變更版本、拆開付款與發票狀態，再用失敗路徑驗收，才能避免一筆客服調整演變成庫存、帳款與發票三邊不一致。