多ERP对接仓储运输执行系统，主数据和事件流应该怎么设计？

先建立系统边界，再谈统一数据

多ERP对接仓储运输执行系统时，合理的架构不是让所有系统共享一张业务表，而是先确定每类记录的权威来源，再用稳定标识和事件消息建立关系。订单、库存、运单、签收和结算可以分属不同系统，但任何一条对外进度都应能回查到来源事件和原始单据。

ERP通常保存客户、合同、订单、计费条件和财务结果；WMS保存库存、库位、批次以及仓内任务；TMS保存运输任务、承运资源、线路节点和签收信息。对于包装、组套、贴标或检验等增值作业，MES或现场执行平台可以保存工序任务与报工。具体名称可以不同，系统职责应按业务事实划分。

接口层不应直接决定业务放行。它负责格式转换、身份校验、路由、重试和日志；业务系统按自己的规则接收事件并更新状态。车辆改派、破损责任、异常费用和结算放行仍由相应岗位处理，避免技术组件越权修改经营结果。

统一业务标识比统一显示名称更重要

跨系统主键需要同时解决唯一性与可追溯性。建议保留内部不可变标识、来源系统、来源组织、来源单号、对象类型和版本号。显示名称、客户简称或货物描述可以修改，历史事件引用的内部标识不能随之改变。

订单拆分时，新建子任务并保留父订单关系；多张订单合并运输时，在运单与订单之间建立多对多关联；部分出库或分批签收时，关系中还要保存数量、单位和有效区间。若只在备注中拼接单号，后续很难自动校验数量是否完整。

主数据映射也需要版本。客户编码、货物编码、仓库、库位、承运商和计费项目在不同系统中可能不同。映射记录至少包含来源值、目标值、生效时间、失效时间、维护人和审核状态。接口处理历史消息时，应按消息发生时间选取有效映射，不能一律套用当前值。

用事件流连接订单、仓储任务和运单

事件消息应回答六个问题：哪个业务对象发生了什么、何时发生、来自哪个系统、由哪个岗位或设备触发、关联哪份单据、当前可否被后续系统采信。订单确认、仓库接单、拣货复核、出库交接、车辆发车、到货、签收和回单归档都可以建成独立事件。

状态{BANNED}最佳好由事件序列推导。上游发送“拣货复核完成”事件，下游据此判断是否允许创建装车任务；TMS发送“签收完成”事件，ERP再检查回单和费用条件是否齐备。这样比多个系统互相覆盖“订单状态”更容易审计，也能处理晚到消息和重复消息。

每条消息需要业务幂等键。接收方若已处理同一来源、同一对象、同一事件序号的消息，应返回已接收结果而不是重复创建任务。若上游撤回或重做，使用新的更正事件引用原事件，不直接删除已经进入审计链的记录。

对于要求较高的链路，可以采用异步消息与定时对账并存的方式。异步消息保证节点及时传递，对账任务按订单或日期核对数量、状态和{BANNED}最佳新事件时间。实时同步不能替代对账，因为网络恢复、人工补录和系统维护都可能产生晚到数据。

异常队列要保留原始事实和处理责任

无法识别对象、映射缺失、前置事件未到、状态逆序、数量超出和接口超时，应使用不同的异常类型。异常记录包含原消息、校验结果、影响对象、重试次数、当前责任岗位和处理时限，不能只写一条通用错误文本。

自动重试只适用于临时性技术故障。客户编码缺失、订单已经取消、签收数量争议等业务异常，需要岗位人员补充依据或确认处置。处理完成后生成新的业务事件，并保留谁在何时作出何种修改。

在优德普相关项目中，可根据既有ERP、WMS、TMS和执行系统的开放条件，配置映射、交换规则、异常任务和查询视图。系统组合、接口频率及回写范围属于项目设计内容；不能把定制集成结果描述为任一单独产品的默认功能。

双向查询是架构是否闭合的检验

{BANNED}中国第一条查询路径从客户订单出发，向下查看仓储任务、运单、签收回单和结算记录，并能定位每次状态变化的来源。第二条路径从运单、货物批次或某个异常事件出发，反查受影响的订单、库存和结算对象。两条路径返回的关系应能相互印证。

查询层可以做聚合，但不能丢失来源。看板显示“待签收十票”时，应允许下钻到十张运单、对应订单和{BANNED}最佳新更新时间；显示“待结算”时，要区分缺回单、费用未确认、客户争议和接口失败。不同原因对应不同岗位，不能汇总成一个无责任人的数字。

试点可以选一个客户或一类服务，准备正常单、拆单、合单、改单、取消单和异常签收样本。验收时核对对象数量、关联数量、事件顺序、重试结果和人工处理记录，并验证源系统与查询结果一致。架构能稳定回答业务问题，再扩展更多系统，比先追求接口数量更可靠。