← 部落格← Blog

導入實務Implementation

把產品主檔從 ERP 接進溯源系統：常見對應與陷阱Bringing product masters from your ERP into a traceability system

溯源系統的好壞，幾乎在它讀到第一筆資料之前就決定了。產品主檔是整條追溯鏈的地基——地基若歪了，後面掃出來的每一碼都會跟著歪。這篇文章談如何把產品主檔從 ERP 乾淨地接進溯源系統：要對應哪些欄位、最常見的陷阱藏在哪，以及為什麼「先清資料、再分批匯入」幾乎永遠是對的。Most of what makes a traceability system good or bad is decided before it ever reads its first record. The product master is the foundation of the whole chain — and if the foundation is crooked, every code you scan afterwards inherits the tilt. This article looks at how to bring product masters from your ERP into a traceability system cleanly: which fields to map, where the common pitfalls hide, and why "clean first, import in stages" is almost always the right call.

為什麼產品主檔是溯源的地基Why the product master is the foundation

溯源的本質，是讓一個實體物件（一瓶、一箱、一棧板）對應到一筆可信、可查的數位紀錄。要做到這件事，系統必須先知道「這是什麼產品」——而這個答案，來自產品主檔。主檔定義了每個品項的識別碼、名稱、規格與包裝結構。生產線掃描、出貨綁定、客訴回溯，甚至日後若需要召回，全都建立在主檔之上。Traceability is, at heart, the act of tying a physical object — a bottle, a case, a pallet — to a trustworthy digital record that anyone can look up. To do that, the system first has to know what the product is, and that answer comes from the product master. The master defines each item's identifiers, name, specification and packaging structure. Line scanning, shipment binding, complaint investigation, and any future recall all rest on it.

正因為它是地基，主檔的錯誤特別昂貴：一個重複的品項、一個對不上的單位，在匯入時看起來只是小瑕疵，卻會沿著整條鏈往下擴散，等到掃描現場或客戶端才爆出來，那時要修代價高得多。所以值得在一開始就把它做對。Because it is the foundation, mistakes in the master are unusually expensive. A duplicate item or a mismatched unit looks like a minor blemish at import time, but it propagates down the entire chain and only surfaces on the line — or worse, at the customer — where it is far more costly to fix. That is exactly why it pays to get it right at the start.

需要對應的核心欄位The core fields to map

不同 ERP 的欄位命名千差萬別，但溯源系統真正需要的東西其實相當穩定。下面這張表整理了最常見、也最關鍵的對應欄位，以及它們為什麼重要。Field names vary wildly from one ERP to another, but what a traceability system actually needs is remarkably stable. The table below lists the most common and most load-bearing fields to map, and why each one matters.

實務上，先把 GTIN 與包裝層級這兩件事確認好，多數對應問題就解決了一大半。其餘欄位（保存期限格式、批號規則、進階屬性）可以等基礎穩了再逐步補上。In practice, nailing down two things — GTIN and packaging level — solves a large share of mapping problems on its own. The rest (expiry-date formats, batch-number rules, richer attributes) can be layered in once the basics are stable.

最常見的五個陷阱The five most common pitfalls

大部分匯入會卡住，原因不是技術太難，而是來源資料藏著這幾類問題。先認得它們，就能在匯入前攔下大半。Most imports stall not because the technology is hard, but because the source data hides a handful of recurring problems. Recognising them up front lets you catch the majority before import.

1. 識別碼缺漏或不一致1. Missing or inconsistent identifiers

有些品項根本沒有 GTIN；有些則在不同表格、不同部門用了不同的碼指同一個東西。匯入前先確認每個可交易品項都有唯一且正確的 GTIN，且前導零與長度格式一致——這是最值得花時間的一步。Some items have no GTIN at all; others use different codes for the same thing across spreadsheets or departments. Before importing, confirm every tradeable item has a single correct GTIN with consistent leading zeros and length. This is the step most worth your time.

2. 計量單位對不上2. Unit-of-measure mismatches

ERP 裡的「箱」不一定等於溯源系統理解的「箱」。換算數量寫錯、或庫存單位與銷售單位混用，會讓聚合數量整個歪掉。匯入前把每個層級的單位與換算數量逐一對清楚。A "case" in your ERP is not always the "case" the traceability system expects. A wrong conversion quantity, or mixing the stock-keeping unit with the selling unit, throws aggregation counts off entirely. Reconcile the unit and conversion at every level before import.

3. 多層包裝沒有清楚的關係3. Multi-level packaging without clear relationships

單品、內盒、外箱、棧板各自有 GTIN，但它們之間「誰裝在誰裡面、裝幾個」的關係常常沒被明確記錄。這層關係一旦模糊，從外箱回溯到單品就會斷掉。把層級結構畫成一張清楚的關係圖，往往比任何工具都有用。Eaches, inner packs, cases and pallets each get a GTIN, but the relationship between them — what nests inside what, and how many — often goes unrecorded. Once that is fuzzy, tracing from a case back to its eaches breaks. Drawing the hierarchy out as a clear diagram often helps more than any tool.

4. 重複與「殭屍」紀錄4. Duplicate and zombie records

多年累積下來，主檔裡常有同一品項的多筆紀錄、停產卻沒下架的舊品、或測試用的假資料。把這些一起匯進去，只會讓現場掃描時對到錯的紀錄。匯入前做一次去重與汰舊，能省下後續一大半的麻煩。After years of accumulation, a master often holds several records for the same item, discontinued products that were never retired, and test data that was never cleaned out. Import all of it and you simply give the line a way to match the wrong record. A round of de-duplication and pruning beforehand removes most of the future pain.

5. 把編碼錯誤一起搬進來5. Carrying coding errors across with the data

如果產線打印與標示設備吐出來的碼，本身就和主檔對不上，那再乾淨的匯入也救不了。對應主檔的同時，順手核對標示設備實際印出的內容，能省下很多上線後的來回。If the codes your line coding and marking equipment actually print do not line up with the master, no amount of clean importing will save you. While you map the master, cross-check what the marking equipment really prints — it saves a great deal of back-and-forth once you go live.

先清資料，再分批匯入Clean first, then import in stages

面對上述陷阱，最務實的做法只有兩個原則。第一，在資料離開 ERP 之前就把它清乾淨——修正識別碼、統一單位、移除重複與停產品項。在來源端修，永遠比在溯源系統裡補破洞便宜。第二，採用分批、迭代的方式：先匯入一小組你最有把握的品項，在實際掃描中驗證它們，確認無誤後再擴大範圍。Faced with those pitfalls, the practical approach comes down to two principles. First, clean the data before it leaves the ERP — fix identifiers, normalise units, remove duplicates and discontinued items. Fixing at the source is always cheaper than patching holes inside the traceability system later. Second, work in stages: import a small, high-confidence set of items first, validate them with real scanning, and only then widen the scope.

迭代的好處是，問題會在規模還小的時候浮現，而不是在你已經把幾千個品項全推上線之後。把它當成一段持續的對齊，而不是一次性的搬遷——主檔本來就會隨新品、改版而變動，建立一個能持續同步的節奏，比追求一次到位更實際。The value of iterating is that problems surface while the scale is still small, rather than after you have pushed thousands of items live. Treat it as ongoing alignment rather than a one-off migration — the master changes anyway as new products and revisions appear, so a rhythm that keeps things in sync is more realistic than chasing a perfect single cutover.

選擇溯源平台時，值得留意的，正是它能不能支持這種務實的節奏：是否容許分批匯入、能否在匯入前就把對應問題標示出來、是否清楚地以 GTIN 與包裝層級為核心建模。一個尊重「資料現實」的平台，會讓導入順很多。When choosing a traceability platform, the thing worth watching for is whether it supports exactly this kind of practical rhythm: does it allow staged imports, does it flag mapping problems before they land, and is it built cleanly around GTIN and packaging level? A platform that respects the messy reality of real-world data makes the whole rollout far smoother.