一物一码系统怎么和 ERP、WMS 对接：出入库扫码与渠道流向
一物一码项目上线后卡住的地方，往往不在产线，而在数据接口。码都赋了、层级也绑对了，打开系统却查不出这个码属于哪张生产订单、这箱货发给了哪个经销商——工单在 MES 里，客户和发货单在 ERP 里，实际发货动作在 WMS 里，码在追溯系统里，四个系统各存各的。
这篇讲这几条接缝：每个交接点传什么、谁说了算、用什么方式传、传不过来时产线怎么办。
一、为什么必须对接：码本身不携带业务含义
一个码就是一串字符。它有用，是因为它挂着别的系统里的业务对象：哪张工单产的、哪个批次、发给了谁、去了哪个区域。这些对象的权威数据源都不在追溯系统里。
| 数据对象 | 通常的权威系统 | 追溯系统拿它做什么 |
|---|---|---|
| 生产订单 / 工单 | ERP 或 MES | 决定这批码属于哪一单，赋码任务按它下发 |
| 物料主数据（产品编码、包装规格、商品条码） | ERP | 决定码规则、码里带什么、每箱装几个 |
| 批次、班次、产线 | MES | 溯源页展示的生产信息 |
| 客户与经销商、销售区域 | ERP | 渠道流向与防窜货比对的依据 |
| 库位、库存、出入库单据 | WMS / ERP | 出入库扫码的校验依据 |
由此得出贯穿全篇的一条原则：一条主数据只允许一个系统写，其他系统只读镜像。两个系统各维护一套经销商列表，短期看不出问题，等有人在一边改了名称或区域，数据就永远对不齐——后果是防窜货比对失效：系统查到一个不认识的经销商编码不会报错，只会把这条流向记成空白。
判断谁是主很简单：谁负责日常录入维护，谁就是主。追溯系统一般不做主数据维护界面，只接收。
二、和 ERP 的交接：四个方向
方向一：生产订单 → 赋码任务。ERP 下发订单号、产品编码、计划数量、包装规格（每箱数、每托箱数）。两个容易漏的细节：一是申码数量要大于计划数量，剔除、试机、尾箱零头都会消耗码，按计划数申码到后段一定不够；二是 ERP改单、拆单、取消要能回传，否则码池里躺着已取消订单的码，换单时会被下一单误用。
方向二：物料主数据 → 码规则与商品标识。产品编码、规格、商品条码从 ERP 过来。码若按 GS1 规则编，这里取的是 GTIN（全球贸易项目代码，14 位，标识一种贸易项目），GTIN 加序列号构成 SGTIN，在码里对应应用标识符 AI(01) 与 AI(21)。要注意：同一产品换了包装规格，一般要给新的 GTIN，不少工厂的 ERP 只按料号区分、没随规格更新条码，这条不理清，箱码和单品码会指向同一个标识。
方向三：发货单 → 出库扫码的校验依据。出库扫码不只是"记一下"，要当场判断这一箱该不该出现在这张单上。所以追溯系统要提前拿到发货单头和明细——单号、客户、产品、数量。单据多是 ERP 生成、WMS 执行，那就约定由 WMS 转发或直接从 ERP 取，不要两边都取。
方向四：客户与区域主数据 → 渠道流向。经销商编码、名称、授权区域是防窜货的比对底数。踩坑的是区域口径：ERP 里的"区域"有时是行政区划，有时是销售大区，两套并存必须建映射表并明确由谁维护。口径不统一，"发货区域与扫码地不符"这个判断就没法算。
三、和 WMS 的交接：四个动作
整托入库带层级数据。成品码托后，托盘码下面已挂着箱码和单品码。入库只扫托盘码（GS1 体系里由 SSCC 承载，18 位，用应用标识符 AI(00)，是物流标签上唯一必备的数据元素），箱数和件数由层级数据带出来，WMS 不必逐箱重扫。前提是 WMS 认这个托盘码为容器标识，而不是另生成一套托盘号。两套托盘号并存会直接导致返工，方案阶段就要定死用哪一套。
拆托、并托必须同步。仓库为拼单把整托拆开重组是正常作业，不是异常。但拆完之后父子关系如果没跟着改，出库时按旧关系推算的单品清单就是错的——货发对了，数据发错了。做法是让 WMS 的拆并托作业产生事件推给追溯系统，实时更新父子关系。GS1 的 EPCIS 模型用 AggregationEvent 描述装入与取出，动作字段取 ADD 或 DELETE，可作参照。国内项目多数不强制走 EPCIS，但事件要成对、要有动作方向这个思路通用。
按单拣货出库，三种粒度都要支持。
| 出库形态 | 扫什么 | 系统要做的校验 |
|---|---|---|
| 整托发走 | 托盘码 | 托内箱数与单据数量一致 |
| 拆托整箱发走 | 箱码 | 该箱未被拆封、未被出库过 |
| 拆箱零发 | 单品码 | 单品未出库过，且从原箱中减掉 |
三类扫码共用一套校验：是否已出库过、是否属于本单产品、是否处于冻结或作废状态。校验不通过要在扫码那一刻提示，事后对账再发现就晚了。
退货入库的码状态。退回的货，码状态要从"已出库"改回"在库"，但历史流向记录不能删。删掉等于抹掉这批货原先发给了谁，窜货追溯从此断链。做法是保留全部流向并加序号，二次发货时能看出这是第几次流转。
四、和 MES 的交接：让码认得出批次
工单状态。工单开工才允许下发码池，关闭时冻结未使用的码并回传实际产出，避免已关闭的工单还在消耗码。
批次。批次号是溯源页上消费者真正会看的内容。关键是批次切换点要和赋码任务切换点对齐：MES 换批的那一刻追溯系统也要换，差几分钟就有一段产品记着上一批的批次号。
班次与产线。出质量问题时靠这两个字段圈定召回范围，价值不在日常，在出事那一天。
产出数对账。追溯系统的合格赋码数和 MES 的产出数几乎不会相等，差额来自剔除品、试机品、破损品。差额本身不是问题，差额说不清才是——对账要按类别拆开，不能只对总数。
五、对接方式怎么选
| 方式 | 适合什么数据 | 实时性 | 要注意的 |
|---|---|---|---|
| 接口（HTTP/REST） | 主数据同步、单据下发，量小、要实时 | 秒级 | 对方要开发；接口不通会阻塞业务，必须有重试和降级 |
| 中间表（数据库） | 批量数据、对方不愿开放接口 | 分钟级 | 要自己设计状态字段（未处理/处理中/已处理/失败）和轮询频率 |
| 消息队列 | 扫码流水这类高频事件 | 准实时 | 消息可能重复投递，接口必须做成幂等 |
选型取决于三件事：数据量、实时性要求、对方 IT 能接受什么。不少工厂的 ERP 是外购的封闭系统，改接口要走原厂流程、排期以月计，这时中间表反而是能落地的方案。
对账机制要在上线时就有。每天按订单跑一遍数量比对：申码数、赋码数、入库数、出库数，差异自动出报表。没有对账的接口等于没人看的接口，数据错了要靠客户投诉才发现。
接口暂时不通时，产线不能停。这一段在集成方案里常被略过，实际却必须写清楚。做法分三层：一是码池预先下发到设备，赋码本来就不依赖网络（见产线落地）；二是扫码数据先落本地队列，网络恢复后补传；三是补传必须带原始采集时间戳，不能用补传时刻的时间。第三层容易被忽略，却直接影响防伪判断——首次扫码时间早于正常上市时间是一条判异规则，补传数据全写成同一个恢复时刻，这条规则就废了。
六、实施顺序与常见问题
顺序不能颠倒：先定主数据归属 → 再定字段口径（一份双方认可的数据字典）→ 再定接口报文 → 再联调 → 再上对账。实践中常见的是反过来，先写接口再谈口径，字段含义一改，接口全部返工。
四个高频问题：
- 字段口径不一致。ERP 用内部料号、追溯系统用商品条码，中间要有映射表，并明确由谁维护、新品上市谁先录。计量单位也是重灾区：一边按"瓶"、一边按"箱"，数量对不上却查不出原因。
- 时序问题：扫码早于单据到达。产线已开始赋码，ERP 订单还没下推；或出库扫完了，发货单才生成。处理方式是暂存为"待匹配"，单据到达后回填，不能直接拒绝——拒绝就意味着产线停下等 IT 系统。
- ERP 改单后流向数据不同步。发货单改客户、改数量、整单退回，追溯系统里已写的流向必须跟着变，而且要留变更痕迹而不是覆盖。覆盖之后，稽查时看到的是改后的结果，还原不出当时发生了什么。
- 重复推送产生重复数据。网络重试、消息重投会让同一个扫码事件到达两次。接口做成幂等（同一业务主键重复提交结果不变）是基本要求，靠人工去重不现实。
对接的工作量通常不在写代码，而在把双方口径谈拢。谈得细，联调就快；谈不细，联调阶段每天都在改字段。
常见问题
- 一物一码系统必须对接 ERP 吗？
- 看要做到哪一步。只做产品溯源展示，拿到工单和批次即可，可以人工导入；要做渠道流向和防窜货，客户与区域主数据、发货单必须从 ERP 来，否则出库扫码没有比对依据。
- 对接用接口还是中间表？
- 按数据量、实时性和对方 IT 的接受度定。主数据同步、单据下发用接口；对方系统封闭、改接口周期长的，中间表更容易落地；扫码流水这类高频事件适合消息队列。三种方式可以在同一个项目里混用，不必统一。
- ERP 或 WMS 的接口断了，产线要停吗？
- 不停。码池预先下发到设备，赋码不依赖网络；扫码数据落本地队列，恢复后补传。补传要带原始采集时间戳，用补传时刻的时间会让防伪的首次扫码判异规则失效。
- 仓库出库时没扫码，防窜货还能做吗？
- 做不了。渠道流向的起点就是出库扫码那一次动作，没有这一次，码上只有生产信息、没有"发给了谁"。所以出库扫码是否真的执行，比系统功能多少更关键。
评估你的产线合规改造方案
上海问源信息科技有限公司作为系统集成商，为食品饮料、日化美妆、酒类等制造企业提供 PTS 一物一码产品追溯方案：产线赋码与视觉复核、单品—箱—托三级聚合、防伪与防窜货稽查、扫码营销数据平台，以及五码合一的层级赋码与管控；码的来源可以是企业自有编码，也可以对接药品追溯、俄罗斯诚实码等外部发码平台。
扫码加微信