誰改動了網上售價？哪些訂單採用了新價？

先界定改動的是哪個價格

顧客問為何網站昨天與今天的售價不同；經理問改價有否批核；會計則問哪些訂單採用了新價。這是三個不同問題，只顯示現價的產品頁無法回答。先列明各種價格欄位及適用情況：產品基本價、客戶協議價、推廣折扣、如適用的稅項處理、運費及最終訂單總額。產品頁可能只顯示預計金額，結帳時才計算實際報價。須註明每個數字以哪個系統為準，亦要說明訂單在哪個事件把價格固定下來。否則，即使技術日誌齊全，也可能答不到真正的業務疑問。

建議價、已批核價、已排期價及生效價應是不同狀態。星期一上載的試算表可能指定星期五才開始，若立即發布，即使數字正確仍屬流程錯誤。要記錄預定生效時間和時區、適用產品或客戶範圍，以及已建立購物籃或報價如何處理。生效時間不能從檔案修改日期或同事發出批核電郵的時間猜測。若系統不支援預約生效，就應在批核人確認準備妥當後才發布，並記下實際啟用時間。處理顧客查詢的員工亦須看得到這些狀態。

有用的改價紀錄應包含產品或價格規則識別碼、舊值、新值、幣別、適用客群、預定及實際生效時間、原因、提出人、批核人、結果，以及批次或要求參照。OWASP 日誌指引要求應用程式記錄何時、何處、誰和甚麼；其業務邏輯指引亦要求涉及價值的操作保留足夠資料，以審視計算價格、優惠券及新狀態。這是設計原則，不表示每家零售商都要用同一欄位清單。只收集重建正當業務改動所需資料，限制敏感資料存取，避免把權杖、密碼或不必要的個人資料複製進日誌。

把批核與實際生效改動連起來

批核必須對應最終真正生效的改動。若經理批核試算表後，檔案再被修改，原批核便無法證明發布值曾獲審閱。建議改價應有穩定版本或摘要，向批核人顯示易讀的新舊值，並把決定綁定該版本。其後如需修正，應建立附有新原因的建議，而非悄悄改寫歷史。小團隊的職責可能重疊，但仍可記錄誰輸入、誰覆核，以及未能依正常流程處理時用了甚麼例外。負責人可據此決定哪些高風險改動需要第二次檢查。

大量匯入價目表與單項修改需要不同的覆核方式。畫面應顯示成功讀取、拒絕及建議改動的行數，並列出影響較大的差異供檢視。要檢查幣別意外轉換、小數點錯置、不容許的負數價格、推廣範圍外產品及有效期重疊。覆核畫面須說明不合格的行會令整批停止，還是只拒絕該等行。保留來源檔案參照、驗證結果及已批核版本；顧客所見系統則應讀取受控的已發布狀態。「上載成功」只證明檔案已收到，不能證明正確價格在正確日期生效。

在可行的情況下，提出改價、批核及發布應由不同權限控制。若緊急修正必須由同一人完成，應要求填寫原因、安排事後覆核，並在紀錄中標明用了該路線。OWASP 建議防止日誌被竄改，並限制及監察日誌存取。因此，編輯價格的人不應只靠再次打開產品頁便可刪除自己改動的證據。資料庫歷史表、只追加的事件紀錄，或受妥善保護的審計服務，都可達到目的；重點是有正當需要的員工能在事後找回紀錄。

追查每位顧客實際獲得的價格

改價日誌可說明系統設定過甚麼，卻不能單憑它證明每位顧客看到或支付了甚麼。公司在視為接受訂購的時點，應把報價單價、折扣依據、幣別及最終金額寫入訂單，並保留計算所用價格版本或規則參照。日後才能由某個價格版本查到受影響訂單，亦要清楚區分生效前訂單、未完成購物籃及已修改訂單。顯示價與已付金額不同，可能是因為有效的客戶協議或運費；不能把每項差異都直接判作錯價。先重建計算，再核對結帳時向顧客展示的條款。

舉一個假設例子：批發商建議某款燈具標價由港幣一百八十元改為一百九十五元，指定某工作日上午九時起適用於新訂單。批核人核准確切版本，發布工作則記下實際於九時零二分啟用。八時五十九分接受的訂單保留舊報價；九時零三分接受的訂單採用新標價，除非有客戶專屬協議價。金額和時間只供邊界測試說明，並非真實交易。團隊應查詢兩張訂單，比較已保存的價格規則版本，並解釋例外。生效時間規則須在上線前議定，事後日誌無法彌補原本含糊的業務政策。

回復舊價本身是新決定，不能當作把錯誤價格抹去。若錯價曾生效一段時間，記下起止時間、期間哪些顧客完成訂單，以及各類訂單如何處理。有些可能需要通知顧客、更正或退款決定；不能單憑價格不一致便自動作出商業決定。原改價及修正事件、各自的批核人和原因都應保留。若快取頁面或外部平台在來源系統修正後仍顯示舊資料，完整時間線尤其重要。須查核各銷售渠道實際發布狀態，不能假設更新一個資料庫就等於所有顧客都看到新價。

以可重建的證據驗收

可要求開發者用測試紀錄示範四項查詢：某產品改了甚麼、誰批核確切版本、各渠道何時套用，以及哪些訂單用了該版本。測試應包含被拒絕的匯入、緊急修改與回復舊價，並把審計結果與訂單快照及當時擷取的頁面或渠道狀態比較。同時檢查誰可讀寫日誌、按公司政策保存多久，以及事故調查時能否匯出可用資料。OWASP 提醒日誌目的會決定需要哪些細節，所以先界定業務問題，再決定收集欄位。

起步不一定要購買大型管治平台。先選一組影響較大的產品，寫明以哪個系統的價格為準、生效時間怎樣判定，並要求每次改價都有新舊值和真正的批核參照。讓一宗小改動走正常流程，再請沒有輸入該價格的同事解釋相關訂單。若他仍須翻查私人聊天、現時產品目錄及憑記憶推斷，審計線索便未完成。先修補這個缺口，再擴展到所有價目表。目標是能解釋顧客實際金額與負責任的決定，而非累積一個無人看得懂的事件儀表板。