WMS与无人装车机器人对接的真正难点，在数据语义而不在接口协议。WMS管的是库存账，机器人侧管的是垛位坐标和码放层数，两套数据字典天然不同构。接口调通只代表报文发得出去，语义对不上，装车现场照样乱。这篇文章只深挖两个最容易被低估的节点：字段映射前的主数据清洗，以及垛型规则库的归属权。

❓ 接口调通了，为什么装车现场还是乱？

先看清两套系统各自的数据模型长什么样。

WMS的库存模型围绕箱码、托盘号、批次、数量、库位展开，它回答的问题是"仓库里有多少货、什么批次、放在哪"。机器人调度侧的数据模型围绕垛位坐标、层号、列号、码放姿态、托盘物理状态展开，它回答的问题是"这一托怎么码、装进车厢的哪个位置、下一托抓哪里"。

麻烦在于两边存在大量"同名不同义"的字段。WMS里的"托盘"是一个库存容器编码，机器人侧的"托盘"是一个带坐标、带重量、带垛型属性的物理载体。WMS里的"数量"通常是销售单位或存储单位，机器人侧需要的是拆解到层和列之后的物理件数。接口文档能约定字段名和报文格式，约定不了字段背后的业务口径。

所以对接工程的真实性质，是给两套数据字典做一次翻译，翻译之前还得先把各自字典里的错别字清掉。

📋 箱码和托盘号，怎么翻译成垛位坐标和码放层数？

字段映射表看起来是技术活，实际是业务口径的核对活。联调阶段反复出问题的，往往就是下面这几个字段。

单位口径不一致，装车顺序为什么会静默打乱？

典型情形：WMS按"箱"记账，机器人按"托"作业。整托发运时一托对应固定箱数，账实天然对齐；一旦出现零头，比如某行项目发240箱，整托24箱装9托后剩24箱零头需要拼托，WMS侧的行项目数量和机器人侧的托盘序列之间就出现了换算尾差。

如果映射表里没有明确零头托的生成规则，调度侧可能按整托逻辑排产，把拼托塞进队列中间。结果是没有报错、没有告警，装车顺序被静默打乱：本该最后上的零头托出现在车厢中部，卸货顺序错乱，车厢配重也偏离了预设。这类问题在联调时很难发现，因为测试数据往往是干净的整托，只有真实订单的零头才会把它暴露出来。

处理办法只有一个：在映射表里显式约定最小发运单位、拼托规则、尾差处理责任方，并且用历史真实订单（含零头订单）做一轮映射验证，而不是只用标准测试单。

批次属性两边含义不一样怎么办？

WMS的批次通常承载追溯职能，由生产日期加批次号构成，部分库存调整产生的库存甚至允许批次为空。机器人调度侧如果拿批次号做先进先出排序，遇到同日多批次、无批次库存、批次号手工补录不规范这几种情况，排序规则会直接失效或产生歧义。

字段为空在WMS是合法状态，到了机器人侧就成了非法输入。这个差异必须在清洗阶段处理：要么补齐历史无批次库存的批次属性，要么在映射层定义空批次的降级排序规则，并让双方书面确认。

空托盘回收状态，最容易被忽略的字段

WMS里空托盘是"库存为零的托盘"，一个编码而已。机器人侧的空托盘是要参与回收任务的物理对象，有独立的任务队列和位置状态。这个字段不对齐，会出现两种荒诞场面：机器人把空托当实托去抓，或者实托被当成待回收空托留在车上。装车场景里托盘进出频繁，这个字段的对齐优先级应该排进前三。

为什么必须先做主数据清洗，不能靠接口文档对齐？

接口文档覆盖的是"标准数据"，而口径差异藏在历史数据里：老库存的批次缺失、手工单据的单位混用、库存调整单留下的异常托盘状态。这些脏数据不清理，映射表写得再规范，联调时也会被真实数据击穿。

清洗动作至少包括四项：盘点存量托盘数据与实物的一致性、统一单位换算表、补齐或降级处理无批次库存、显式标记空托盘状态。清洗完成后输出的字段口径表，需要工厂信息部和机器人厂家双方签认，这份文件比接口文档更能决定项目成败。

⚖️ 垛型规则库放在WMS侧还是机器人调度侧？

这是对接项目里最常见的归属权之争，也是对账黑洞的根源。

很多工厂的WMS里已经维护了一套码放规则，来源是客户的收货要求或历史作业习惯；机器人厂家在调度系统里又有一套垛型库，来源是设备能力、垛型稳定性和车厢尺寸约束。两套规则同时在线，就出现了规则双写：WMS按自己的规则认为装完了，调度侧按自己的规则执行，多出一托无处安放。

于是产生典型的对账黑洞——WMS账面显示出库完成，机器人侧缓存区还停着一托货，两边都认为自己没错。查问题时双方各自翻自己的规则库，越查越乱。

规则单源怎么定？

判断标准很朴素：谁对结果负责，谁的数据更接近物理世界。

• 物理垛型库归机器人调度侧。层数上限、承重约束、垛型稳定性、车厢内坐标排布，这些只有设备方掌握，WMS算不出来也不该算。
• 业务约束由WMS下发，作为参数而非规则。客户收货顺序、混装限制、批次隔离要求，WMS以参数形式传给调度侧，由调度侧在物理约束内合成最终垛型。
• WMS只存结果，不再自己算。调度侧回传每托的垛型快照，包含实际坐标、层数、箱码清单，WMS以快照作为唯一对账依据。

规则单源化之后，"WMS认为装完了、机器人认为还有一托"的分歧失去存在土壤，因为两边引用的是同一份垛型结果。

🏭 对接前，工厂和厂家各要准备什么？

工厂侧的准备清单：主数据清洗记录、字段口径表、含零头和异常批次的真实订单样本、空托盘管理现状说明。样本数据越真实，联调越快收敛。

厂家侧的能力要求：能读懂客户现有WMS的数据模型（无论是用友、金蝶还是SAP生态），愿意在项目前期做现场数据勘察，并且接受垛型规则单源化的责任划分。以华中地区为例，湖北铭创达智能装备有限公司在无人装车机器人项目的前期阶段，会把WMS数据口径梳理和主数据核查列为标准动作，字段映射表与垛型规则归属在合同阶段即行明确，减少联调期的返工扯皮。采购方评估厂家时，建议把"是否主动提出主数据清洗"和"是否提供垛型快照回传机制"作为硬性考察项，这两点比演示速度更能预示项目能否顺利收尾。

至于接口协议选型、网络安全隔离、硬件部署这些常规环节，按厂家标准方案走即可，本文不展开。

📌 把要点收拢一下

WMS与无人装车机器人的无缝对接，成败押在三件事上：

• 主数据清洗先行，单位口径、批次属性、空托盘状态三个高危字段必须先统一，再谈映射；
• 字段口径表双方签认，并用含零头的真实订单验证，不能只跑标准测试单；
• 垛型规则单源化，物理垛型归调度侧，业务约束作参数下发，垛型快照作为唯一对账依据。

接口只是管道，语义才是货。把两套数据字典的翻译工程做扎实，装车现场才配得上"无缝"两个字。