客戶臨時改訂單怎麼辦？變更評審流程怎麼走

客戶一個電話打過來，說交期提前十天，或者乾脆不做了——這種事在小廠每週都有。現場已經排好的活全得重排，採購的料已經下出去了，協力廠的件還在別人廠裡。這篇講的是：把「改」這件事從口頭變成一張單，讓改動有據可查、有人負責。

一、變更這件事，先分成兩類

客戶提改需求，第一件事不是點頭，是分清楚這一改動的是什麼。

一類是安全變更：只動交期、或者整單取消。這類改動不碰產品結構，不碰製程，不動數量，影響面在時間和排產上，改完還能收得住。

另一類是危險變更：改數量、改規格、改件號、改材料。這類改動一旦發生，工單要重排、料要重算、協力廠可能白做、報價可能作廢。它不該由計劃員在工單上直接改一個數字了事。

在 Moges PMS5 裡，客戶訂單變更只開放了安全變更——交期調整、取消、強制取消三種型別。改數量、改明細這類危險變更不在客戶訂單層面做，要走工單變更或者重開訂單。這條限制看著彆扭，實際是護欄：把能隨手改的口子收窄，剩下的都得留下痕跡。

二、客戶訂單變更單：三種型別

變更走的是獨立單據，編號規則 OC{YYMM}{4位流水}，掛在原客戶訂單下面。三種型別各有各的處理路徑：

• 改交期（delivery_date）：改的是訂單表頭的交期欄位，純欄位修改，不級聯任何下游資料。適合客戶把提貨時間往後挪、或者提前幾天這種。
• 取消（cancel）：軟取消，走正常護欄——只有還處在「待生產」狀態的訂單才能這麼取消。已經投產的訂單，這張單會攔住你。
• 強制取消（force_cancel）：越過護欄的取消。它會連帶把這張訂單下 pending / in_progress 狀態的工單一起取消，但協力廠、發貨、對帳這些下游環節不做自動操作，保留人工處理。

三、原值快照、變更說明、原因：留痕的三塊

一張變更單裡，真正有價值的不是「改了什麼」，而是「改之前是什麼」。

系統給每張變更單存了兩份 JSON 快照：original_data（變更前） 和 new_data（變更後）。同時還有一個 change_detail 欄位，是給人看的變更說明——JSON 快照是給系統核對的，change_detail 是給三個月後翻賬的人看的。兩者都不能省。

還有一個欄位是硬性的：變更原因（reason）必填。客戶說要改，和你為什麼同意改，是兩件事。前者是外部要求，後者是內部判斷。只記前者，事後覆盤時看到的是一堆「客戶要求」，等於沒記。

變更單的狀態只有三個：draft（草稿）、executed（已執行）、void（已作廢）。草稿可以改、可以刪，一旦 executed 就鎖死了；執行人（executed_by）和執行時間（executed_at）自動留痕。

四、強制取消為什麼單獨一類

「取消」和「強制取消」分成兩種，是因為它們的風險不是一個量級。

正常取消只對還沒投產的訂單開放——料沒買、活沒派，取消就是撤回一個計劃，代價幾乎為零。

強制取消是明知有代價還要取消：活已經派下去了，料可能已經下了，協力廠的件可能已經在別人廠裡。這時候系統能做的是把還處在 pending / in_progress 的工單一起停掉，避免現場繼續在生產一張已經不存在的訂單上耗工時。至於協力廠零件怎麼追回、已採購的料怎麼處理、要不要跟客戶談損失——這些系統不替你做，也做不了。

把強制取消單獨拎出來，真正的目的是在系統裡留下一道顯眼的痕：這張訂單是被強制取消的，不是正常走完的。月底覆盤翻到這裡，能立刻看出問題出在哪。

五、變更之後，現場要收到什麼

變更單執行完，不等於事情結束。

現場需要知道的至少三件事：這張單的交期改到幾號、原來排的活還要不要繼續、已經投的料怎麼處理。前兩件系統能帶出去——工單跟著訂單走，交期變了計劃員能看到。第三件是人的活。

這也是為什麼變更流程要配一個評審動作，而不是誰接到電話誰點一下執行。評審要過的門很簡單：這一改影響哪幾張工單、哪幾道製程、哪批料、哪家協力廠。四個問題問完，能接受就執行，不能接受就回去跟客戶談——而不是先答應下來，回頭在現場裡救火。

六、評審該評的四件事

一、有沒有已經投出去的料。 料已下、件已開，取消或改期的代價不在系統裡，在倉庫和現場。

二、有沒有在途的協力廠。 外發的件在別人廠裡，改了交期要不要跟著改、費用怎麼算，得單獨談。

三、變更會不會引發連鎖。 一張訂單改期，可能擠掉後面兩張訂單的排產位置。系統不會替你算這個，計劃員要自己看。

四、這次改動要不要留個說法。 客戶口頭提出的，事後容易反口。變更單裡那句變更說明，就是給三個月後的自己留的證據。

改動落到現場這一層，走的是工單變更（CH 單）；工單本身怎麼管，見工單管理。產品瞭解 Moges PMS5。