前面几篇沿着风机订单走过工程变更、采购、领料、装配、检验和设备恢复。同一件支架会出现在 PLM 的结构里、ERP 的物料账上、WMS 的批次库存里，也会成为 MES 装配谱系的一部分。系统之间已经能传数据，仍可能出现编码对不上、重复扣料，或每张看板都显示成功却查不到过账结果。
这一篇整理这些连接。继续沿用 SO-200、MO-0160 与新支架 BKT-018，另设一个“补发两件尚未在 ERP 记账”的接口差异样本。单据、事件和差异编号均为模拟，不改写前文的既有数量口径，也没有接入生产系统。
先确定哪些对象应当对应起来
主数据、业务记录和消息各有身份
物料、客户、供应商、设备等相对稳定的业务对象，通常需要主数据治理；单位、原因代码、状态代码等受控取值也需要明确维护责任。订单、收货、领料、检验和维修则记录具体业务活动。事件表达某件事已经发生，消息负责把数据传到接收方，业务回执说明目标实际做了什么。
同一个对象可以在不同系统里使用不同本地编码，但映射必须说明身份范围。工厂 A 的物料号、供应商料号、工程零件号与仓库条码之间，可能存在不同粒度的关系。名称相似不能直接作为合并依据，扫描码相同也不能替代物料、批次、容器和序列号的识别规则。
| 对象或记录 | 本组案例的身份 | 接入时还需要核对的范围 |
|---|---|---|
| 产品与工程定义 | FAN-100、产品修订 B | 配置、工厂、工程与制造适用关系 |
| 新支架物料 | BKT-018 | 组织、本地编码、单位与有效版本 |
| 收货批次 | LOT-N01、LOT-N02、LOT-N03 | 物料、工厂、供应商批次与库存维度 |
| 新生产订单 | MO-0160 | 订单行、工序任务、版本与执行系统身份 |
| 组件补发记录 | PICK-0072 / 10 | 明细行、数量、批次与对应业务动作 |
| 事件 | ISSUE-00871 | 来源、事件类型、载荷版本与关联动作 |
| 设备与资源 | AST-ASM-01、ASM-01 | 实体关系、能力及生效时间 |
批次号不能只用一段字符串做全局关联。不同供应商、工厂或物料下可能出现同名批次，库存还可能细分到仓库、状态和容器。序列号是否全局唯一也要按实际规则确认，不能把条码的显示形式当成数据约束已经成立。
责任可以细到属性和适用范围
PLM 可以维护工程结构与变更，ERP 维护采购和库存业务所需属性，EAM 维护设备资产关系；具体企业还可能使用 CAPP、MDM 或其他模块。谁创建对象、谁维护某项属性、谁批准发布、谁在下游应用，需要逐项约定。
同一物料的工程定义、采购参数和仓储属性可能分别由不同岗位负责。若规定“所有字段都以某套系统为准”，却没有说明字段责任和生效机制，就可能把目标系统本地维护的合法属性覆盖掉。MDM 可以承接识别、校验、映射和发布治理，也可以通过现有系统与流程实现这些职责，不必先假设要新建一套中心库。
BKT-017 与 BKT-018 是工程变更中的两个物料，不应为了让接口连通就映射成同一个身份。允许替代或受限使用，应保留批准条件与适用对象；编码映射只解决对象对应，不能暗中创造替代资格。
版本和单位跟着对象关系一起保存
产品修订 B、制造 BOM 04、装配工序 OP-030/3、作业指导书 WI-030/E 和路线 R04，是不同对象的版本。不能用一个笼统的“最新版本”覆盖它们，也不能根据数字大小直接认定哪个业务定义更新。
映射至少保存来源身份、目标身份、关系类型、版本、生效区间和批准依据。历史领料与装配应按当时适用关系解释；映射纠错需要标明修订及受影响范围，保留原始来源，避免重新跑一张今天的映射表就悄悄改变历史谱系。
计量单位也属于契约。本例统一按件记录，不假设箱与件、千克与件之间存在固定转换。若使用包装换算，保存对应物料、包装规格、有效版本和精度规则；需要称重或实际计量时，不能拿一个方便的常数替代实测依据。
一条事件需要让接收方知道什么
已发生事实与待执行请求分开表达
“WMS 已完成某笔发料”可以作为事件；“请 ERP 记入对应消耗”是一项待执行动作。接收事件后能否产生该动作，要检查对象、授权、状态和计量规则。不能把一条历史事实送到任意接口，就默认它已经具备修改目标账目的权限。
放行同样如此。QMS 篇里的批准记录、解除质量限制的动作和 WMS 应用回执各有身份；EAM 篇里的维修验证、批准可用与实际复产也分别保存。事件发生时间、接收时间和业务过账时间，服务于不同问题。
CloudEvents 的事件格式规范定义了 source、id、type 等上下文，其中来源与事件 ID 的组合用于识别不同事件，重复发送可以保留同一事件身份。统一格式有助于传递身份和上下文，订单、数量、版本和权限等业务语义仍需另外约定。
身份、载荷和关联信息一起保留
下方使用 CloudEvents 1.0 外层字段，业务载荷为本文自定义。示例沿用 ERP 篇的两件补发记录 PICK-0072 / 10 与事件身份 ISSUE-00871。额外供给批次为 LOT-B018-03，与最初 20 件待检批次 LOT-N03 不同。
{
"specversion": "1.0",
"id": "ISSUE-00871",
"source": "/plants/A/wms",
"type": "cn.example.manufacturing.material.issued.v1",
"subject": "issues/PICK-0072/lines/10",
"datacontenttype": "application/json",
"data": {
"business_action_id": "PICK-0072",
"line_id": "10",
"plant": "A",
"production_order": "MO-0160",
"material": "BKT-018",
"lot": "LOT-B018-03",
"quantity": 2,
"unit": "EA",
"operation": "ISSUE",
"record_revision": 1,
"mapping_revision": "MAP-B018-05"
}
}
示例省略了可选的事件时间，没有给模拟业务编造现实发生日期。完整契约仍需实际业务时间、所需组织和库存维度、动作状态、数据来源与关联身份。若接口要求整笔单据与多行一起提交，应定义整笔和明细的成功范围，不能只靠这个单行片段处理整张单据。
事件 ID、业务动作 ID、目标应用 ID 与链路追踪 ID 各有作用。重新封装数据可能形成新消息甚至新事件，但仍描述同一笔 PICK-0072 / 10；目标还应依据业务身份避免重复过账。链路追踪 ID 方便查日志，不能单独承担长期业务去重。
载荷版本不能只检查字段有没有
新增可选字段、修改字段单位、改变空值含义和重定义状态，都可能影响接收方。契约要说明哪些变化兼容、哪些需要新版本，以及旧消费者如何处理未知值。不能仅因为 JSON 可以解析，就认定双方理解了一样的业务。
增量事件还需说明它携带差额还是完整状态。quantity: 2 在本例表示该笔发料明细的绝对数量，由业务身份限定；它不代表可以对同一记录无限追加两件。若采用增量记账，应绑定独立动作和更正关系；若采用状态覆盖，应检查版本，避免迟到旧状态覆盖新事实。
发送成功以后还可能在哪些地方断开
来源事实与待发事件尽量共同提交
来源业务已提交，发送进程却在发消息之前退出，会留下没有下游通知的事实；先发消息再提交业务，则可能让下游看到最终没有成立的动作。发送台账需要能回到已提交的来源记录，不能只记录某段代码尝试调用过接口。
事务 Outbox 的一种做法，是在同一可原子提交的事务范围内保存业务变化和待发事件，再由独立转发过程发送。Microsoft 的事件协作模式说明讨论了这种原子保存、重复投递和顺序处理问题。Outbox 降低来源事实与事件脱节的风险，转发成功后的业务处理仍需目标确认。
遗留系统可能无法参与这样的事务，可根据实际能力使用变更捕获、带游标的已提交记录提取或其他机制，并注明保证范围。全量初始化、增量启动和故障补采之间也要防止漏取或重取。不能在来源系统不支持的情况下，仅画一个消息队列就宣称不丢数据。
去重记录和业务副作用要一起成立
目标收到事件后，检查身份、业务条件和载荷，在可行的本地事务中将去重标记、业务更新和结果记录一起提交。并发重复需要数据库唯一约束或等价的原子机制，先查询“没有处理过”再分别扣料和写标记，会留下崩溃与并发窗口。
Microsoft 的幂等消费者说明指出了这个原子提交要求，也讨论了无法加入本地事务的外部副作用。此时要依赖目标支持的幂等身份、动作结果查询及未决状态核对，不能仅凭本地已打标就保证远端只执行一次。
去重范围应包含消费者身份与事件身份，并补充业务动作约束。两个独立订阅系统都需要处理同一事件，不能共享一条无消费者区分的“已完成”标记，让先完成的系统阻止其他目标。去重记录保留多久，还要考虑正常重投、人工补发和历史重放窗口。
乱序处理取决于消息携带的语义
同一业务对象有可靠递增序列时，可以定义对象内顺序与缺口检测。这个序列需要来源保证，不能拿不同系统的时间戳拼成一个并不存在的全局顺序。较大版本先到时，应按契约等待、补取或查询完整状态。
完整状态事件若经过版本校验，可以拒绝迟到的旧覆盖；缺失的增量则不能因为序号小就直接丢掉。例如第二笔补发先到、第一笔发料后到，如果每笔都是独立已完成业务动作，丢掉后到的第一笔就会少记消耗。消费者应按具体聚合与记账规则应用，不能用一套“只收最大版本”的逻辑处理全部事件。
失败消息进入待处理队列后，保存失败原因、原始身份、重试次数、来源和目标结果。短暂故障可以按规则重试；编码缺失、权限不符或业务冲突需要处理依据。内容改变时形成明确的新版本或更正动作，不能偷偷修改旧载荷再复用原身份。
两件补发料怎样把账对清楚
先固定业务范围和可比较的截止位置
本次核对 MO-0160 对应的新支架，不含旧料 BKT-017 的 80 件，也不将旧工单的 40 台风机混入新工单的 160 台。前文实际口径保持不变：先到 160 件新支架，后续额外补发两件，最终新风机合格 160 台，支架净消耗 162 件，没有主线余料退回。
为了手算，再明确本次对账检查点：所选范围期初为零，相关新支架共收货 162 件、净发往生产 162 件；线边没有剩余、在途或未用件，全部装配和处置已经落实。其中 160 件留在最终产品中，拆下的两件损伤组件按批准报废。只有在这些边界都成立时，发料、消耗和组件去向才能使用下面的等式。
仓库范围余额 = 期初 0 + 收货 162 − 净发料 162 = 0 件
组件去向 = 最终装机 160 + 损伤组件报废 2 = 162 件
新工单合格产品 = 按序列号去重后的 160 台
终检执行 = 首次 160 + 返工后复检 2 = 162 次
内部移库在选定仓库范围内不改变总量；跨出范围、退料、盘点调整等业务如果实际存在，需要加入明确的收支项。领料通常不等于立即消耗，本检查点特意排除了线边未用与其他差异，不能将这个等式推广到任意在制时刻。
“同一截止时刻”还不够。来源有些记录已经提交，目标可能仍在应用，取数本身也可能跨越多次变更。对账任务应保存各来源快照身份、已完成位置或游标、查询时间和迟到策略；无法对齐完整性时，先标注尚未可比较的范围。
数量总和之外继续比较业务明细
现在另设一条接口异常分支：WMS 已完成 162 件净发料，ERP 已接收相应收货，但只落实了首批 160 件的生产消耗，补发两件尚未过账。这是本篇构造的差异场景，不改变前文最终业务结果。
| 核对视角 | 本次模拟值 | 需要继续追的记录 |
|---|---|---|
| WMS 新支架范围收货 | 162 件 | 首次供给与额外两件的收货明细 |
| WMS 生产净发料 | 162 件 | 首批发料及 PICK-0072 / 10 两件补发 |
| MES 对应组件去向 | 装机 160 件，损伤报废 2 件 | 序列号谱系、拆换件与处置记录 |
| ERP 已落实生产消耗 | 160 件 | 对应目标凭证及尚未落实的补发明细 |
| 按本次条件计算的 ERP 余额 | 2 件 | 需要核对补发过账，不代表仓库多出实物 |
| 对账差异 | ERP 少记消耗 2 件 | 先查询原业务动作在目标的真实结果 |
对账可以先按工厂、物料、订单、单位与检查点比较汇总，再下钻到动作、单据行、批次和目标凭证。库存需要按适用的仓库、状态、所有权等维度核对；两个系统采用不同粒度时，先定义可验证的汇总映射，不能直接拿报表总数互减。
总数相同也可能对错对象。某订单少记两件、另一订单多记两件，工厂物料合计仍然相等。错误批次、正负方向、重复与遗漏相互抵消，同样可能隐藏在总量里。金额核对还要另外固定币种、估价、期间和成本口径，不能把数量相等理解为成本账已经一致。
查清原动作以后再决定补发还是补偿
可以为差异建立 REC-0160-02，保存比较规则版本、来源快照、明细身份、差额、未完成目标及证据。若 ERP 实际已过账，只是回执丢失，查询并补齐结果；若确认未执行，满足当前业务条件并获准后，以稳定动作身份补发或恢复原处理。
不要为凑齐 162 件直接把累计数覆盖成 162。这样无法证明原发料已经正确映射，也可能在迟到消息再次处理时多记两件。修复需要能够落到一笔具体目标凭证，并避免同一业务身份被再次过账。
如果另设一个重复处理分支，两件补发被错误应用两次，累计消耗会达到 164 件。先定位重复凭证与后续影响，再按批准规则冲销或建立补偿记录，保留与原动作的关系。这个分支与前面的“少记两件”分开验收，不能同时当成同一组样本的当前状态。
修复完成后重新取数，核对 WMS、MES 和 ERP 的对应明细、目标凭证、数量与仍有效的业务条件。差异达到关闭规则才结案，原始差异和修复记录继续可查。后续若又发现错误，建立关联修订或新差异，不删除第一次核对的事实。
把对账做成可以持续运行的工作
验收既看重复消息，也看业务是否重复执行
下面用例用于检查制造业集成设计，站点展示的图和载荷均未连接真实业务系统。
| 验收场景 | 应当能够核实的结果 |
|---|---|
| 同名物料或批次来自不同工厂 | 按完整身份区分，不凭显示名称自动合并 |
| 工程版本、单位或映射发生修订 | 历史按有效版本解释，新增修订可追溯 |
| 业务已提交但转发进程退出 | 从已提交来源恢复待发事件，不凭日志猜测是否完成 |
| 同一事件串行或并发重复到达 | 每个消费者独立处理，目标业务副作用不重复 |
| 新事件 ID 仍描述同一业务动作 | 业务身份约束仍能识别重复过账 |
| 本地已打标但外部接口超时 | 保留未决，查询目标结果，不直接假定成功或失败 |
| 完整状态旧版本迟到 | 不覆盖新状态，保留拒绝或忽略依据 |
| 增量缺失或独立动作乱序 | 检测缺口或按业务契约应用，不因序号较小而漏账 |
| 对账取数位置不齐 | 明确延迟和未完成范围，不提前判为实物短缺 |
| 补发两件未在 ERP 落实 | 差异为 2 件，定位到动作和明细，处理后再核对 |
| 两件被重复记账的独立分支 | 识别累计 164 件，按批准凭证修复并保留原记录 |
| 不同订单的差额相互抵消 | 汇总相等仍能检出明细错配 |
| 重放历史事件或补发失败队列 | 保留原业务身份，不重复领料、放行或过账 |
| 对账规则发现异常 | 先形成差异依据，批准前不自动改写业务事实 |
运行看板可以分别记录待发送、传输失败、目标拒绝、结果未决、超过约定等待时间和真实业务差异。重试次数与消息积压是技术信号，库存错账与未落实放行是业务问题，两类指标需要能互相下钻。
每类差异都明确责任人与关闭证据
映射缺失通常需要主数据或相应业务岗位确认，目标拒绝可能涉及状态和权限，来源记录错误则应由来源责任方更正。维护差异类型、责任角色、处理时限与升级路径，避免所有异常都堆到接口开发人员手里。
对账规则本身也需要版本和验收依据。规则调整后保留新旧比较范围，不静默重写历史结论。实物数量、精度容差、时间延迟和费用差异不能共享一个没有业务意义的“允许误差”；整数件数为两件的缺口，也不能靠调大容差消掉。
Agent 先解释对象关系和未决差异
Agent 可以汇集 MO-0160 的来源明细、映射版本、事件落实台账与目标凭证，解释两件差额位于哪一步，再准备查询、补发或补偿建议。回答应附上对象、来源、截止位置、规则版本与仍未知的部分，不能只引用最终汇总数。
例如问“WMS 和 ERP 为什么差两件”，如果只查到 ERP 消耗 160 件，就先说明还缺 WMS 动作、目标结果和可比检查点。只有这些证据补齐，才把差异定性为未记账、重复、映射错误或时间延迟。
写入仍通过已定义的权限、当前状态核验与受控动作。对账发现差额不会自动授权补料、冲销或解除限制；自然语言里的“帮我把账对平”也需要落到具体业务明细和批准方案。修复后再运行同一规则，才能判断问题是否已经关闭。
至此，首批产品、订单、执行、库存、计划、质量、设备和数据集成已经串起。下一篇回到研发工程工具与工艺数据，继续拆 CAD、PDM、CAPP 与 PLM 之间的文件、结构和工艺对象关系。