OMS 说有货、WMS 说没货：库存同步的延迟坑怎么堵

你敢不敢赌，OMS 屏幕上那个"有货"，是几分钟前的数据？

我第一次把这个问题抛给一个客户的运营经理，他愣了三秒，说"应该是实时的吧"。然后我让他打开 OMS 和 WMS，各查同一个 SKU 的可售数——两边差了 40 多件。那批订单当晚还在继续进，客服第二天一早被买家问候了一整天。不是谁的系统坏了，是两个系统之间的库存同步，天然带着延迟。

这事我见得太多了。OMS 和 WMS 明明接了接口，老板也花了钱做集成，可库存数字就是对不上。根子不在代码，在于很多人从头到尾没搞明白：这两个系统传的到底是什么、多久传一次、传丢了怎么办。

OMS 里的库存是"历史资料"，不是直播

先把数据流捋一遍。订单从各平台进来，先到 OMS 做路由分配，再下到 WMS 拣货发货。反过来，WMS 这边的收货、上架、拣选出库、盘点调整，要回传给 OMS，OMS 再把可售数推给各个销售平台。注意这个"反过来"——大部分集成项目 90% 的精力都花在"订单怎么下去"上，回传这条路是顺手搭的，能跑就行。

而延迟就藏在这条回传路上。三个来源，一个比一个常见。

第一，同步频率。很多集成默认是定时任务：每 15 分钟、每半小时、甚至每小时跑一批。这意味着 WMS 里刚被拣走的 200 件，OMS 要到下一个整点才知道。旺季晚上流量最大的那几个小时，延迟就是超卖的窗口期。改成事件驱动（收货上架、盘点差异一发生就推送）当然更好，但接口调用量翻几倍，平台限流、服务器成本都得跟着涨。这是个取舍问题，不是技术问题，是钱的问题。

第二，接口失败没人管。同步任务报错了，重试三次还失败，任务就躺那儿了。最要命的是很多系统失败了也不告警，运营第二天才发现昨晚的库存回传断了六个小时。我见过一个仓，盘点差异批量导入 WMS 后，传给 OMS 的那批任务卡住了，整整两天平台上挂的都是旧库存数。

第三，人工环节的延迟。货到了，收货组忙着卸车，系统里还没做收货确认；盘点发现差异，主管还没复核，账面数就一直是错的。系统延迟是分钟级的，人工延迟是小时甚至天级的。很多"同步不准"的锅，最后都扣在系统头上，其实是流程没闭环。

超卖单砍掉的不是面子，是真金白银

为什么我要把延迟说得这么严重？因为超卖的代价是连锁的。

订单超卖，第一步是取消。自己取消订单在平台眼里是最难看的动作之一：亚马逊的政策是卖家自配送订单的预履行取消率要压在 2.5% 以下（7 天窗口），超了就可能被限制销售权限；订单缺陷率的红线是 1%（60 天窗口）。一个旺季晚上爆几十个超卖单，取消率直接起飞，账号健康度掉下去，流量跟着掉——这账没人替你算，平台直接扣。

第二步是客服和退款。买家付了钱等发货，你告诉他没货了，退款、道歉、差评，一套流程走下来，一个超卖单的人工成本比这单的利润还高。第三步更隐蔽：有些卖家为了不取消，紧急从别的渠道调货补发，运费翻倍，时效还保证不了，等于花钱买差评。

所以别再把"库存对不上"当成 IT 的小毛病。它是直接烧钱的。

延迟消灭不了，只能压短和兜底

先说个判断：OMS 和 WMS 之间的延迟永远消灭不了。物理上就不可能——两个系统、网络传输、平台限流，总有几秒到几分钟的差。目标不是零延迟，是把延迟压到业务能承受的范围内，再加兜底。

压短延迟，看三个配置。第一，把关键事件改成实时推送：收货上架完成、盘点差异复核通过，这两个事件必须即时推给 OMS。订单下行可以批量，但库存上行尽量事件驱动。第二，同步的字段要对：WMS 传给 OMS 的应该是"可售数"（在手数减去已分配、减去质检冻结），而不是毛库存数。很多集成传的是毛库存数，OMS 拿毛数当可售数用，等于自带水分。第三，多仓映射要干净：一个 SKU 在三个仓都有货，OMS 合并计算时别把在途、冻结的也算进去。

兜底看两招。第一招，给热销 SKU 加安全缓冲。OMS 里设置一个"虚拟预留"，比如某爆款实际可售 500，OMS 只放 460 出去卖，留 40 件对冲延迟窗口内的超卖。这 40 件是拿销量换安全，比例自己定——我的建议是按这个 SKU 历史最大单小时销量乘以同步间隔来算，至少能 cover 一个延迟周期。第二招，每日对账加差异告警。每天固定时间（比如凌晨低峰期）把 OMS 和 WMS 的全量库存拉出来比对，差异超过阈值（件数或比例）就告警。对账不是为了好看，是为了在接口断掉的那天早上，有人第一时间知道。

订单系统操作大屏