先说结论：WES 与 ERP 对接这件事，技术从来不是难点，难点是三条线没画清楚——订单从哪进、库存回哪写、异常谁兜底。我做过 30 多个上线项目，WES 项目翻车的，十个里有八个是集成边界没定死，上线后两边互相甩锅。这个坑我见过三次，每次都是同一个剧本。
三条数据线：订单从哪进、库存回哪写
任何 WES-ERP 对接，写代码之前先画三条线：
- 订单下行线：ERP 的销售订单、生产订单，以什么颗粒度、什么频率进 WES？整单推还是按行推？释放（release）这个动作谁来做——ERP 里点释放，还是 WES 里人工释放？
- 库存上行线：WES 里拣完、复核完，库存扣减和出库确认回写到哪里？直接回 ERP，还是先回中间的 WMS？批次、效期、序列号这些字段，ERP 要不要？
- 异常回流线：订单在 WES 里卡住了（缺货、波次凑不满、设备故障），这个异常谁看见、谁处理、处理完状态回写到哪？
三条线画完，对接方案基本就定了。画不完，接口写得再漂亮也是空中楼阁。
WES-ERP 对接的三种接法：直连、经 WMS、混合
接法一：直连（WES↔ERP）。 订单 ERP 直推 WES，WES 出库直回 ERP。接口最少，看起来最清爽。适合仓库业务单一、没有复杂库内流程、ERP 本身库存管得细的场景。2023 年我在华东做过一家 3C 配件商，日均 2 万单、旺季冲到 4 万单，用的就是直连——6 周就上线跑起来了。但代价是所有异常都堆在边界上：WES 里波次没凑满，ERP 那边订单状态已经显示"已释放"，客服按 ERP 的状态跟客户承诺了时效，仓库这边货还没拣。三个月后他们被迫在中间补了一个异常待办池——等于把"经 WMS"那一层，事后又亲手加了回去。
接法二：经 WMS（ERP→WMS→WES）。 WMS 做库存真相和订单编排，WES 只管执行层（设备调度、波次优化、路径规划）。订单在 WMS 里释放、分配，WES 拿到的是"干净"的可执行任务；WES 干完把实绩回给 WMS，WMS 再回 ERP。适合多仓、多货主、库内流程复杂、有自动化设备、效期批次管得严的仓。2024 年美国中西部一家食品分销商，冷链仓，选的就是这条：三层走下来上线多花了 6 周，但黑五旺季零事故——缺货、效期拦截这些异常全部在 WMS 层被拦下，WES 收到的永远是能直接干的任务。
接法三：混合。 订单走 WMS 编排，但库存快照直给 ERP 做财务；或者常规订单走 WMS、紧急插单直进 WES。适合集团 ERP 强势、财务要求库存实时可见，但仓库又有自动化要调度的场景。混合最灵活，也最考验边界定义——每条线都要写清楚"正常走哪、异常走哪"，少一行说明，上线后就多一场扯皮。
反常识的判断来了：很多人觉得"系统越少、直连越快"是先进架构。我的经验正好相反——直连省掉的不是复杂度，是把复杂度从"一个中间层"挪到了"两条边界的扯皮"上。多一个 WMS 中间层看似多花钱，实际上是买了一份保险：它吃掉了八成的异常，WES 和 ERP 才能各自干净。这个账，下一节算给你看。
WES-ERP 对接决策账：四个问题卡出你的接法
| 直连 | 经 WMS | 混合 | |
|---|---|---|---|
| 接口数量 | 最少（2 条主线） | 中等（4 条主线） | 最多（5 条以上） |
| 上线周期 | 最短 | 最长（多 4～8 周） | 居中 |
| 异常兜底 | 两端扯皮，最弱 | WMS 待办池兜底，最强 | 看定义，边界不清则最弱 |
| 对账复杂度 | 高（两边口径常打架） | 低（WMS 是唯一真相） | 最高 |
| 适合谁 | 单仓、流程简单、无自动化 | 多仓/多货主、有自动化、效期批次严 | 集团 ERP 强势 + 仓库自动化并存 |
算一笔账：直连省下的 4～8 周实施费，第一次大促出一次"ERP 显示已发货、WES 还在拣"的客诉，客服和运营救火的人力就烧回来了。我见过最贵的一次：某母婴品牌大促超卖 2000 多单，赔付加顺丰加急重发，直接烧掉小 40 万。中间层的钱，是花在明处的保险；直连的坑，是花在暗处的学费。
四个问题，答完就有答案：① 有没有自动化设备要调度？有→直连出局。② 效期/批次/序列号管得严不严？严→经 WMS。③ 集团财务要不要库存实时数？要→混合或经 WMS，直连的口径打架会逼疯财务。④ 上线窗口有多紧？只剩 6 周→直连，但把异常待办池的预算先留好。
上线前夜 checklist：这个坑我见过三次
定完接法，按这个清单逐项打勾，少一项都别上线：
- 主数据归属写死：SKU 主数据、库位主数据、批次/效期规则，到底归 ERP 还是归 WMS？只许一个主人。我见过两边各建一套 SKU 编码规则，上线第三天同一个条码在两边是两个品名。
- 订单状态机对齐：ERP 的"已释放"对应 WES 的哪个状态？WES 的"已复核"回写成 ERP 的"已发货"还是"待发货"？状态映射表打印出来贴墙上。
- 字段清单逐个过：批次、效期、序列号、重量、体积——ERP 有的字段，WES 接不接得住？接不住的，上线前就要定降级方案（比如效期字段丢弃、改由 WMS 侧拦截），不能上线当天才发现。
- 幂等和重发：网络抖一下，同一条订单推了两次，WES 会不会建两个波次？接口必须支持幂等（按 ERP 订单号去重），上线前夜拿测试环境断网重连实测一遍。
- 负库存拦单：WES 拣货数量超过可用库存，拦不拦？谁来拦？直连模式下这个逻辑经常两边都以为对方做了，结果谁都没做。
- 对账 job：T+1 三方对账（ERP 库存 vs WMS/WES 实绩），差异超阈值自动告警。对账不是上线后"有空再做"，是上线第一天就要跑的。
- 异常 owner 和 SLA：波次凑不满、设备停机、缺货——每种异常写清楚谁处理、多久处理完、超时升级给谁。没有 owner 的异常，最后都是客服背锅。
常见翻车点再补三条：① 上线前只测了 happy path，异常路径一条没测——WES 项目八成的 bug 藏在异常路径里；② ERP 打了个补丁字段长度变了，接口半夜挂掉——接口契约要写进变更管理，ERP 侧任何字段变更提前两周通知；③ 压测只压了 WES 内部，没压端到端——从 ERP 推 1 万单到 WES 全链路跑一遍，看看瓶颈到底卡在哪一层。
最后给一句明天就能用的：今晚就去问你们项目组三个问题——订单从哪进、库存回哪写、异常谁兜底。答不上来的，对接方案先别签字。
作者：林晓｜WMS 实施顾问
