從訂單到發貨全程可查：一件產品的追溯路徑怎麼建

客戶拿著一件貨來問：這個件是什麼時候做的、誰做的、中途改過什麼？能答上來，是能力；翻三天記錄才找到，是常態。追溯這件事，靠的不是多記幾張表，而是把單據串成一條鏈。

一、追溯靠的是鏈條，不是表格

很多廠的「追溯」其實是翻賬：找當時的檢驗單、找當時的派工本、問當時的班組長。三樣湊齊了，也只是拼出一個大概。

真正的追溯是一條單向不亂的鏈：客戶訂單 → 工單 → 工單工段 → 每一道製程的工單回報記錄。每一環都帶上一環的標識，順著任何一個點都能往上往下走。

這條鏈之所以能立起來，關鍵在一個欄位：工單號。它從訂單轉工單那一刻生成，之後貫穿工單回報、協力廠、發貨、對帳。工單號是這條鏈的主鍵，不是附屬資訊。

二、正查：訂單 → 工單 → 工段 → 工單回報

正查是日常用得最多的一種：拿到一張訂單，問這批貨做到哪了。

順序是這樣的：客戶訂單下面掛著它的工單（一張訂單可以拆多張工單）；工單下面掛著工段列表，每個工段有序號、工段定義、計劃工時；每個工段下面掛著工單回報記錄——開工時間、完工時間、完成數量、操作人、裝置，還有工時（duration_hours，完工時自動算出）。

正查的價值在進度可見：不用問人，就知道這批貨卡在哪一道製程、卡了幾天。

三、反查：從一件產品倒推

反查是追溯真正的用途：客戶拿一件貨來，問它是怎麼做出來的。

路徑反過來走：先憑件號或工單號找到工單，再拉開這張工單的全部記錄——

• 各個工段什麼時候開工、什麼時候完工、誰報的工
• 工單回報來源是人工還是協力廠自動生成（工單回報記錄裡有 source 欄位，區分 manual 與 outsourcing）
• 協力廠那段發給了哪家、什麼時候回、驗收合不合格
• 中間改過什麼：變更單上的原值和新值
• 誰改過工單的哪些欄位：工單操作日誌裡的欄位、原值、新值、原因、操作人

這幾樣湊起來，才是一份能拿給客戶的加工檔案。缺一樣，追溯就有斷口。

四、變更記錄是追溯鏈上最容易缺的一環

進度和工單回報，多數廠多少有一點記錄。真正缺的是變更。

一件產品出問題，往往不是因為它按原計劃做的，而是因為它被改過——客戶改了交期、換了製程、加了數量。當時的改動只在一個電話裡，事後完全查不到。

所以變更單在追溯裡的地位，比它看起來重要得多：

• 客戶訂單變更單（OC 單）：改動前的資料快照、改動後的資料、變更說明、變更原因、執行人和執行時間
• 工單變更單（CH 單）：變更型別、明細裡的原計劃工時與原備註、變更原因、建立/提交/作廢的完整日誌
• 工單操作日誌：欄位級的改動記錄——哪個欄位、原值、新值、原因、操作人、時間

三層疊加，才能回答「這一件為什麼和圖紙不一樣」這個問題。

五、追溯的邊界：能證明什麼，不能證明什麼

這一節必須說清楚，因為很多系統在這上面含糊。

能證明的：這張工單走過哪些製程、每道製程誰報的工、什麼時候報的、數量多少、協力廠去了哪家、中途改過什麼、誰改的。

不能證明的：這一件產品具體用的哪一批料、哪個爐號。離散加工的系統按「單」記賬，不按「批次」記賬——料是按工單領的，領的是哪種規格有記錄，但同規格的料混在一起用是常態，系統不追到批次。

這條邊界不必諱言。真要做批次級追溯，那是另一套體系（批次號、爐號、有效期、先進先出），成本和維護量都是另一個量級。多數 50 人以下的機械加工廠並不需要走到那一步——客戶要的通常是一份「這件活怎麼做的」的記錄，而不是「這塊料從哪爐來的」的譜系。

六、追溯能力怎麼一步步建

第一步，先把工單號變成唯一主軸。 任何一張單據、任何一條記錄，都要能問出「屬於哪張工單」。這一步做不到，後面全是散的。

第二步，讓工單回報落到工段上。 不是記「今天干了多少活」，而是記「這張工單的第幾道製程，誰在什麼時候做完了幾件」。顆粒度差這一層，追溯就斷在現場。

第三步，把變更走成單據。 交期、數量、製程的每一次調整都留一張單，附上原因。這是最容易被跳過的一步，也是事後最需要的一步。

第四步，把協力廠掛在製程上。 外發的件不是「發出去了」，而是「這張工單的這道製程發給了某家」。回來驗收的結果掛回去，鏈就閉合了。

四步走完，追溯不再靠翻箱倒櫃，靠查一張單號。

「一單到底」的思路另見工單號查全程（B6）；工單回報這一環的做法見條碼掃描工單回報。產品瞭解 Moges PMS5。