供應商 CSV 改動業務紀錄前，如何驗證與審批？

先訂明匯入可以更改甚麼

供應商試算表一旦可以新增或覆蓋貨品、價格、庫存或顧客紀錄，匯入就成為正式業務操作。先決定匯入的權限，而不是先設計上載按鈕。列明目標紀錄類型、負責人，以及每行資料可以新增、更新，還是只供職員審核。例如貨品目錄可先接收描述及供應商貨號，售價則留待採購員確認。這條界線能協助團隊逐欄處理例外；檔案格式正確，並不等於它有權改動商店資料。

編寫匯入功能前，要先選定穩定的配對鍵。貨品名稱雖然易讀，卻可能改名、翻譯或重複；供應商貨號亦可能只在該供應商範圍內唯一。如果現有紀錄沒有可靠鍵，應把該行留在待核對區，由人手配對，不要以相似名稱猜測。更新時空白儲存格究竟代表保留舊值、清空欄位，還是拒絕該行，也要逐欄寫清楚。保留原始檔及經確認的欄位對照，讓日後可追查輸入，但保存期與查閱權限仍須按公司政策設定。

先正確解析，再對照欄位

CSV 有引號與分隔規則，不能簡單地每逢逗號或換行便切開。貨品描述可能在引號內包含逗號、引號或換行。應採用可靠的 CSV 解析器，先約定文字編碼和分隔符，拒絕損壞的檔案，並在大量處理前限制檔案大小及行數。PostgreSQL 的 COPY 文件也說明，引號內外的空白值可以有不同意思。系統毋須照搬它的做法，但一定要定義「沒有欄位」、「空白」及「刻意輸入空字串」各代表甚麼，避免匯入時悄悄清除資料。

把辨認到的欄名顯示給操作員，逐一對照系統接收欄位。重複欄名、未知欄位及缺少必需欄位，都應有明確處理方式。常用對照可以保存，但要綁定供應商及檔案版本；欄名一有變動便重新檢視。單靠欄位次序十分危險，供應商插入一欄後，整份檔案仍可能順利解析，數值卻全部錯位。正式寫入前，顯示資料樣本及系統理解的目的欄位，並列出預計新增、更新、拒絕與待人手處理的行數。預覽幫助決策，並不能代替全檔驗證。

同時驗證格式與業務意思

欄位規則要對應實際操作。必需識別碼、可接受日期及數字格式、數量範圍、分類與狀態選項都要定清楚；相關欄位亦須互相比對，例如完結日期應在開始日期之後。價格數字看似合理，不代表幣別正確。OWASP 指出格式驗證與業務語意驗證並不相同，而且要驗證伺服器實際處理的資料。瀏覽器提示可協助職員修正檔案，卻不能成為唯一防線。權限也要獨立檢查：即使檔案完全有效，沒有權限的帳戶也不應修改目錄。

上載檔案本身是不可信輸入。只接受業務需要的檔案類型，檢查內容，不能只相信副檔名或聲稱的 MIME 類型，也不要用職員提供的檔名，把檔案直接存進公開網頁目錄。OWASP 亦建議限制大小，並核實上載者的權限。解析後，每個儲存格仍只應當作資料；寫入資料庫時使用參數化操作，顯示在頁面時依輸出位置編碼。文字編碼損壞或結構無法解析，便清楚拒絕整份檔案。若容許部分匯入，必須事先訂好政策並逐行交代原因，否則職員看見「成功」卻不知道目錄只改了一半。

用小型供應商更新演練

假設商店收到供應商檔案，欄位包括供應商貨號、中英文名稱、單位成本、幣別及供貨狀態。供應商今月新增了促銷備註欄。匯入器應識別新欄，保留已知欄位的對照，並詢問備註如何處理；不應依欄位位置把其後資料全部移位。現有貨號成為待確認更新，新貨號成為待確認新增，空白貨號則按預定規則拒絕或送審。幣別若為空白，除非檔案協議明訂預設值，否則不要自行當作港元。這是說明流程的假設案例，並非聲稱已觀察到的客戶成效。

演練時加入三種麻煩資料：名稱含逗號、引號內有換行的描述，以及相同貨號卻價格不同的兩行。正確解析器應完整保留首兩行。第三種需要事先定規則：兩行都拒絕、由職員選定，或依已約定的供應商優先次序處理。讓操作員查看重要欄位的修改前後對照。在測試環境把同一檔案匯入兩次，第二次應顯示已處理或相同的待確認修改，而不是再新增一批重複貨品。紀錄檔案識別、欄位對照版本、匯入狀態及逐行決定；日誌不要存放不必要的個人資料。

讓核准、寫入與復原可追查

把解析及預覽與最後寫入分開。正式確認畫面要說清哪些紀錄會改動，哪些仍待處理。資料庫及流程容許時，把已核准的一組變更以完整交易寫入，避免故障後留下無法解釋的新舊混合資料。如果業務刻意只接受有效行、保留無效行，預覽頁就要明示，並提供附原因的拒絕清單供匯出。不要把無效日期或價格悄悄改成另一數值。錯誤報告應指出來源行及目標欄位；若會交予授權團隊以外的人，敏感內容須先遮蓋。

第一次正式匯入前便要規劃復原。按系統特性保留可還原快照或變更紀錄，指定誰可撤回已核准批次，並用測試批次演練。如果其後有職員根據匯入資料作修改，「一鍵復原」可能會一併抹掉後續工作；此時經審核的修正匯入可能較安全。最後給操作員一份列明行數及執行時間的收據，保留足夠來源資料，日後可追問爭議數值來自哪份供應商檔案。先從風險較低的一個供應商開始，抽查來源與結果，確認解析、審批、重複執行及復原流程後再擴大。

一條實用的核准規則，是要求匯入器用業務語言解釋預計變更。「更新四十二行」不及列明受影響供應商、更改欄位、價格變動數量，以及未能配對的紀錄有用。操作員應可停止流程、下載修正報告、修改來源檔，再重新開始，而不會失去較早嘗試的紀錄。若供應商發來修訂版本，須識別新舊版本的取代關係，不能簡單把兩份檔案都附加。核准寫入後，從檔案開首、中段及結尾抽查，再檢查預覽標示的特殊類別，把系統數值逐項與來源及欄位對照比較。即使資料型別接受某個數值，也可能是成本誤入售價欄這類看似合理的錯誤。完成這些核對，才適合把對照擴至更多供應商。

匯入範本應視為可能更新的資料協議。提供一份小型樣本檔，列出必需欄名、可接受編碼、欄位意思，以及更新時空白值的清楚例子。告知供應商哪些改動必須升級範本版本，例如新增必需欄或改變貨號規則。操作員收到陌生版本時，應先預覽及核准新對照，再連同版本保存，而不是默默套用上月格式。這亦有助支援人員分辨供應商格式問題與系統錯誤。範本清楚不代表可省略驗證；供應商仍可能送來超出範圍的價格、重複鍵或引號格式錯誤的欄位。

首次正式匯入時，指定一人核准預覽，另安排一人在操作時段回答供應商資料問題。任何人手覆核或例外處理，都要記下原因及受影響資料行。若職員反覆為同一規則開例外，應修訂並公開匯入協議，而不是讓未記錄的慣例一直存在。批次結束後，請負責人確認拒絕清單已交回來源單位，避免下一次仍送來相同問題。