客户临时改订单怎么办？变更评审流程怎么走

客户一个电话打过来，说交期提前十天，或者干脆不做了——这种事在小厂每周都有。车间已经排好的活全得重排，采购的料已经下出去了，外协的件还在别人厂里。这篇讲的是：把「改」这件事从口头变成一张单，让改动有据可查、有人负责。

一、变更这件事，先分成两类

客户提改需求，第一件事不是点头，是分清楚这一改动的是什么。

一类是安全变更：只动交期、或者整单取消。这类改动不碰产品结构，不碰工序，不动数量，影响面在时间和排产上，改完还能收得住。

另一类是危险变更：改数量、改规格、改件号、改材料。这类改动一旦发生，工单要重排、料要重算、外协可能白做、报价可能作废。它不该由计划员在工单上直接改一个数字了事。

在 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。