MES 与 ERP 对接：比接口清单更重要的是数据契约

对接的终点是业务状态一致

“ERP 下达工单，MES 回传产量”只有一句话，真正落地却涉及订单版本、单位换算、工序含义、报废与返工以及入库边界。如果两边对“完工”理解不同，接口返回成功也可能留下数量差异。

ISA-95 为企业业务与制造运营之间的信息交换提供模型和术语框架，其价值之一是帮助团队讨论活动边界与交换对象。[1] 项目中仍需要把这些概念落到具体字段、责任人和状态规则，不能以“符合某个分层图”代替现场确认。

本文以一张离散制造工单为例，整理可用于接口评审的数据契约思路。字段与编号均为设计示例，不限定采用哪一家消息平台。

点击放大

第一层：谁维护，谁可以改

产品、工艺路线、物料清单和工作中心并不一定来自同一个系统。应先列出每类主数据的权威来源、业务负责人、发布条件和下游使用方式，再安排接口方向。

例如，ERP 维护物料经营信息，工艺系统维护批准后的路线版本，MES 维护具体执行记录。这是一种可讨论的分工，不是所有企业的固定答案。关键是避免同一字段两边都能修改，而又没有冲突处理规则。

工单必须引用明确的产品与路线版本。新版路线发布后，已开工工单是否继续使用旧版，应由工艺变更规则决定；接口不能静默替换已经执行过的工序依据。

第二层：把事件身份与数量含义写清

工单号只标识业务对象，不足以唯一标识一次完工事件。一张工单可能分多次报工，也可能发生撤销与重新确认。事件应有稳定标识，并同时携带工单、工序、数量类型、单位、业务发生时间与来源版本。

以教学编号 WO-260911-008 为例，第一次报工与第二次报工使用不同事件标识；第一次事件因网络重试而再次发送时，必须保留原标识。接收方先判断它是否已经处理，再决定是否改变业务累计数。

Microsoft 的消息去重说明展示了基于消息标识和时间窗口消除重复发送的机制。[2] 这不能替代业务侧幂等：如果接收程序更新了产量却未记录处理结果，下一次消费仍可能再次增加数量。需要让业务写入与已处理事件记录保持一致，或设计可恢复的处理流程。

字段名称仅用于评审示例，正式契约还需包含类型、精度、必填条件与错误码。

点击放大

第三层：回执要说明业务有没有完成

建议至少区分“已接收”“业务处理成功”“业务拒绝”和“处理中”。返回 HTTP 200 可以表达通信或接收层面的成功，但它本身不能说明工单已被业务系统接受，更不能说明实物已经完成入库。

回执应携带事件标识、处理结果、目标单据号和可解释的失败原因。产品编码不存在、路线版本未生效、工单已关闭等情况，通常需要先修正业务条件；反复自动重试不会消除这些问题。

网络超时则要先查目标状态，再使用相同事件标识重试。接收方不确定是否已执行时，应给出可查询状态，而不是要求发送方不断生成新事件来“再试一次”。

点击放大

第四层：乱序、补传和冲销怎么处理

当完工消息先于工单到达，接收方需要明确是暂存等待、返回可重试状态，还是转入异常队列。延迟补传也要保留业务发生时间与系统接收时间，避免夜班产量被错误算到次日白班。

数量更正宜关联原事件，采用约定的撤销、冲销或差额事件。应说明更正影响生产累计、质量状态还是库存，不要让两边各自修改总数后失去原始依据。

消息保存和重试窗口应覆盖可接受的故障恢复周期。跨系统的权限、时区、精度和计量单位也属于契约内容。比如“件”与“箱”转换需要绑定明确装箱数量，不能只改单位名称。

点击放大

最后用异常和对账来验收

把接口测试从一条正常路径扩展到重复消息、相同标识不同内容、乱序、下游停机、跨日补传与已入库后的更正。每种情况都应说明预期单据、累计数量、异常状态与负责岗位。

日常对账可以按工厂、日期、工单和事件范围比较：下达数、已接收数、已完成数、失败数与待处理数。数量差异要能下钻到单个事件，技术人员看传输日志，业务人员看对应单据与处理动作。

接口验收的重点，是在故障发生后仍能恢复到可解释的一致状态。先把这些规则约定清楚，后续增加物料、质量或库存接口时，才能沿用可靠的协作方式。