先说结论：WMS 和 TMS 集成的烂尾项目，十个里有七个不是技术问题。接口调通了、报文能跑了，上线照样天天救火——出事的永远是这三个地方：波次计划什么时候推给 TMS 约车、装车顺序的数据怎么传到月台、运单号和签收怎么回传对账。这三个地方谈清楚，WMS 和 TMS 集成基本就稳了；谈不清楚，你接再多字段也是摆设。
这个坑我见过三次，死法都一样。
2023 年，加州 Ontario 一个 8 万平方英尺的 3PL 仓，WMS 和 TMS 用的都是大牌产品，接口文档厚厚一本。波次计划每天下午 3 点由 WMS 自动释放，推给 TMS 做运力预约。问题出在时间差：TMS 那边找承运商确认要 2～4 小时，拣选员下午 4 点已经开始干了。货拣出来了，车还没约到，暂存区堆到叉车转不过身，夜班又继续往里压，整整堵了两天才疏通。复盘时发现：WMS 只管推，TMS 只管接，"车到底约没约到"这件事，压根没人负责。接口是通的，业务是断的。
第一处对接：WMS 和 TMS 集成先谈波次计划怎么推给 TMS 约车
这是 WMS 和 TMS 集成里最容易翻车的地方。两个系统对"计划"的理解根本不一样：WMS 的波次是作业计划（几点释放、谁去拣），TMS 要的是运输计划（哪票货、哪辆车、几点到门）。中间缺一个翻译层，就只能靠人工翻译，早晚出事。
分步做法：
- 波次释放前先查运力。WMS 释放波次之前，先调 TMS 的运力查询接口，确认承运商有车。没车就不释放，或者只释放"已确认运力"的部分。记住顺序：先有车，再放波次。顺序反了，就是 Ontario 那个仓的下场。
- 定死 cutoff 时间。承运商确认运力一般要 2～4 小时，旺季更长，倒推回去定波次释放时间。比如承运商要求提前 4 小时约车、车辆 18 点得到门，波次最晚 14 点释放。把这个时间写进 SOP，贴在计划员的屏幕边上。
- 约不到车要有兜底。TMS 约车失败，WMS 必须能自动把波次打回"待约车"状态，而不是让货继续往下走。兜底规则要在上线前夜测：故意让 TMS 返回约车失败，看 WMS 拦不拦得住。
反常识的一点：波次计划不要追求实时推送。很多项目一上来就要"波次一释放秒级推给 TMS"，结果 TMS 那边的承运商根本没那么快响应，实时推了也白推。一天固定 3～4 个波次窗口、批量推送，反而稳得多。实时是给异常用的，不是给日常用的。
还有个细节：cutoff 时间旺季和淡季不能用同一套。有个客户淡季 cutoff 定 4 小时跑得好好的，旺季承运商确认要 6 小时，波次还是按 4 小时放，结果旺季第一个月就堵了两次。后来我们做了两套 cutoff，系统按日期自动切换——10 月到 12 月用旺季版，其他月份用淡季版。这个开关写在 TMS 的配置里，WMS 只管读，别两边各存一套，否则改的时候总有一边忘。
第二处对接：WMS 和 TMS 之间的装车顺序（load sequence）怎么传到月台
波次和车都齐了，第二处坑在月台上。WMS 里算好的装车顺序——先卸的货后装、重货在下轻货在上——传到月台时经常走样。我见过最离谱的一次：顺序字段传过去了，但月台看板按字母排序显示，司机照着"顺序"装了一车，到门店卸货时发现先卸的压在最里面，整车倒了一遍才卸出来，门店收货员脸都绿了。
分步做法：
- 谁算顺序要定死。一般是 WMS 按配送路线和门店优先级算，TMS 只负责传和执行。两个系统都算，必打架。
- 字段定义写死。装车顺序不能只有一个"序号"，要带上：托盘号、对应门店或订单、卸货顺序号、特殊要求（比如冷链、易碎）。月台看板显示什么、司机手持终端显示什么，接口文档里逐屏定下来，截图存档。
- 月台要有确认回执。装车完成，月台扫描确认实际装车顺序，回传 WMS。实际和计划不一致（比如某托盘没赶上），WMS 自动标红，TMS 同步更新给司机——别让司机开到半路才发现货不对。
多说一句：司机手持终端上，装车顺序一定要配离线缓存。月台信号死角多，终端一断网顺序刷不出来，司机只能凭记忆装，前面定的字段再全也白搭。这个坑我见过两次，都是上线前夜才发现月台有个信号盲区。验收的时候拿着终端在月台走一圈，断网也能看顺序，才算过。
第三处对接：WMS 和 TMS 之间运单号和签收回传的对账闭环
货发出去了，WMS 和 TMS 集成还没完。运单号、实际发运时间、签收 POD 回传，是第三处对接，也是财务结账的命根子。另一个项目里，签收数据回传延迟了三天，财务按 WMS 的"已发出"结了账，客户那边说有两票没收到，扯皮扯了一个月，最后是翻监控录像才定责。
分步做法：
- 运单号在"车辆离场"时回传，不要等签收。离场扫描一次，回传 TMS 和 WMS，状态变成"在途"。这是两个系统对同一票货的共同锚点，先把锚点钉死。
- 签收回传走批量，一天三次足够。签收 POD 本来就有延迟，司机回场才上传，做实时接口是浪费钱。定好三个批次时间，早中晚各一次，雷打不动。
- 每天一张对账表，自动跑。逻辑很简单：WMS 已发出减去 TMS 已签收，等于在途未签收。差值超过 48 小时没签收，自动标红推给客服。表不用花哨，能每天早上 8 点准时出现在客服邮箱里就行。别小看这张表——有个客户就是靠它抓到过一票"幽灵在途"：WMS 显示发出去了，TMS 那边三天没签收，标红一查，是司机把回单落在驾驶室，货早到了，单子没交。没有这张表，这票货能挂两个月才有人问。
下面这张表是接口清单的最小可用版本，三个接口、每个接口的触发时机和负责人，一页纸就能说清：
| 接口 | 触发时机 | 实时还是批量 | 出了问题找谁 |
|---|---|---|---|
| 波次计划推 TMS 约车 | 波次释放前，先查运力 | 批量，一天 3～4 个窗口 | 计划员 |
| 装车顺序传月台 | 装车前 | 实时 | 月台主管 |
| 运单号、签收回传 | 车辆离场、签收后 | 运单实时，签收批量一天三次 | 客服/财务 |
上线前夜 checklist：这 8 项必须打勾
- 波次释放和运力确认的顺序测过：故意约不到车，看 WMS 拦不拦得住。
- cutoff 时间写进 SOP，计划员、承运商、月台三方签字确认。
- 装车顺序字段在月台看板和司机终端上逐屏验收过，截图存档。
- 实际装车与计划不一致时，标红和通知链路测过。
- 运单号在车辆离场时准时回传，延迟超过 10 分钟告警。
- 对账表连续跑 7 天，差值逻辑和人工抽查结果一致。
- 异常流程（约车失败、甩货、拒收）每条都走过一遍端到端。
- 回滚方案：接口挂了，人工流程能不能顶 4 小时，演练过。
最后说一句：WMS 和 TMS 集成，技术只占三成，七成是把"谁先动、谁负责、异常找谁"这三句话写进文档、测进系统。接口文档签完字别急着庆祝，先问一句：如果明天 TMS 约不到车，WMS 会自己停下来吗？答不上来，就别上线。
作者：林晓｜WMS实施顾问
