昨天討論常用收件資訊與出貨資訊的修改流程，哪些檢查可以共用，哪些規則應該各自處理。接著往資料看：兩邊都有姓名、電話與地址，為什麼還要分開保存？

程式是否共用，與資料是否分開保存，需要分別判斷。電話格式檢查可以共用，但客戶的常用電話與這次配送的收件電話，仍然各有用途。

建立時相同，之後各自代表不同的事情

建立出貨單時，系統把常用收件資訊帶入並獨立保存，這是資料快照（Snapshot）的概念：保留帶入當下的內容，不隨客戶主檔後續更新。兩份內容一開始相同，但常用資料供之後建立單據時使用，出貨資料則屬於這一次配送。快照保留的是當時的資料，不代表建立後一律不可修改；單據上的收件資訊能否修改，仍要依出貨流程決定。

例如客戶平常都寄到家裡，這次想改寄公司。客服修改這張待出貨單的地址，就只影響這次配送，不表示客戶希望往後都寄到公司。

反過來，客戶搬家後更新常用地址，之後建立出貨單時就能帶入新地址；既有出貨單仍保留自己的收件資訊。若某張尚未交付的出貨單也需要改寄，就針對那張單據另外確認與修改。

這就是分開保存的原因：兩份資料各自表達一件事，也有不同的修改範圍。即使此刻的姓名、電話與地址完全相同，它們仍然屬於不同的業務對象。

資料可以修改到什麼時候？

常用收件資訊會隨客戶需求更新。出貨單上的資訊，則跟著出貨流程走：依本文的規則，交付物流前可以修改，交付後就不能再透過原編輯功能更改，要保留此次配送使用的資訊。

所以出貨地址有自己的生命週期。建立時從常用資料帶入，待出貨時可依規則調整，交付後留下配送紀錄。把資料獨立存下來，只是其中一步；允許哪些操作修改、修改到哪個階段，也必須在程式裡落實。

這些背景會影響查詢使用哪份資料。建立新單據時，可以讀取常用收件資訊；查看某次出貨內容時，則讀取該出貨單保存的資訊。同樣都是查地址，目的不同，資料來源就不同。

保留出貨資料，不等於保留所有修改歷史

再往下看一層。假設客服在交付前修正了門牌號碼，出貨單保存修正後的地址，讓這次配送使用正確資訊。交付後查詢，也能看到配送時採用的地址。

但如果要問「最初填的是什麼？誰在什麼時候改過？」，就需要查修改歷史。出貨單上的目前值回答的是這張單據現在採用什麼內容，異動紀錄則用來追溯它如何變成現在這樣。

這些紀錄也能協助處理客訴與釐清物流責任。例如客戶反映「我明明改過地址，為什麼還寄到舊地址？」，就要查明改的是常用資料還是這張出貨單、修改發生在何時，再對照交付物流的時間與資料，才能還原處理過程。

因此，要先確認需要回答哪些問題，再決定保留哪些紀錄。若規格要求追查地址更動，就核對既有異動紀錄是否包含對應單據、修改前後內容、操作者與時間戳記。這些資訊可作為客訴查證與稽核的依據；保存配送資訊與保存修改過程，是兩個需要分別確認的需求。

「下次要用的」叫常用資料，「這次在跑的」叫單據資料，「吵架要查的」叫異動紀錄。內容再怎麼像，也是三份用途不同的資料；搞混了，修的是一個地址，吵的卻是一整段責任。

「這個地址是誰改的？」
「我查一下。」
「查到了嗎？」
「查到了，最後修改時間是下午三點。」
「誰改的？」
「下午三點。」