同一張工單，三個端都在動：多端工單回報的資料從哪來、怎麼合

一張工單從下料到出貨，它的工單回報可能來自好幾個入口：工人用 PDA 條碼掃描報、文員發現漏報在電腦上補、協力廠完工後系統自動生成。多個入口往同一張工單上寫資料，賬為什麼不會亂？這篇從工單回報資料的「來源」設計講起。

一、每條工單回報都有出身：來源欄位

看一條工單回報記錄的結構，除了工單、製程、人員、裝置、數量、時長這些業務欄位，還有一個容易被忽略但很關鍵的欄位：來源（source）。

在 Moges PMS5 的工單回報模型裡，來源區分了 manual（人工工單回報） 和 outsourcing（協力廠自動驅動）——人工報的、協力廠完工後系統自動生成的，各自帶各自的出身。

這個欄位的價值當時看不出來，事後全是它：

• 對帳時：這條工單回報是人報的還是協力廠自動生成的？出處決定核對的路徑
• 排查時：數量對不上，先按來源分堆——人工錄入的錯誤和協力廠資料對接的錯誤，排查方向完全不同
• 統計時：自動生成的資料可信度高於手工錄入，來源標識讓統計口徑可以分層

來源標識是多端資料一致性設計的第一塊磚：先讓每條資料說出自己從哪來。

二、多入口為什麼不會寫亂：單點寫入

多端協同容易做歪的地方是「各端各有一套本地邏輯」。穩的做法是所有端寫同一個後端：

• PDA、小程式、Web 端的工單回報操作，提交的都是同一個工單回報介面
• 端只負責採集和呈現，業務規則（數量校驗、狀態流轉、防重）在後端統一執行
• 一條工單回報不管從哪個端來，走的是同一套校驗、生成的是同一種記錄

這樣「三端一致」不是靠各端對齊達成，而是根本沒有三個賬本——端是視窗，賬本只有一個。

三、離線資料怎麼合：補傳而非覆蓋

離線工單回報的資料（見離線工單回報那篇）在本機暫存、恢復後同步。它的合併邏輯有兩個要點：

• 工單回報是「新增」型資料：一條工單回報就是一條新記錄，不存在兩臺裝置同時改同一條的衝突場景——新增型資料的合併天然簡單
• 按序補傳 + 異常標記：暫存的多條按時間順序補傳；萬一出現異常衝突（如重複提交），系統標記出來人工確認，而不是靜默覆蓋

新增型資料靠順序，修改型資料靠規則——工單回報以新增為主，這是多端工單回報一致性容易保證的結構性原因。

四、自動生成也是工單回報：協力廠的例子

協力廠完工後系統自動驅動生成工單回報記錄，這個設計說明兩件事：

• 工單回報的入口不止人工——能自動的事實就不該讓人手工再錄一遍：協力廠零件回來了、驗收確認了，工單回報跟著自動生成，工人不用重錄
• 自動生成的記錄同樣帶來源標識——它和人工工單回報在統計時可以分層看

「錄入一次」原則在多端場景的延伸：每個事實只在一個環節錄入一次，其餘環節自動帶出。

五、給選型者的檢查清單

評估一套系統的多端能力，別看演示裡幾塊螢幕，看三件事：

• [ ] 各端是不是寫同一個後端（還是各端各有一套資料）
• [ ] 資料有沒有來源標識（出問題時能不能分堆排查）
• [ ] 離線資料的合併是補傳還是覆蓋（覆蓋會丟歷史）

三件事過關，多端才是真協同；不過關，螢幕再多也只是演示好看。

離線資料的暫存與同步見離線工單回報方案（F24）；工單回報的業務面見條碼掃描工單回報。產品瞭解 Moges PMS5。

---