OMS 说有货、WMS 说没货：两边库存对不上的 5 个排查点

先说结论：OMS WMS 库存对不上，十有八九不是系统 bug，而是出在 5 个地方。先把这 5 个地方查完，再怀疑人生。我做过 30 多个上线项目，这个坑我见过三次——每次客户都先骂系统，最后查出来都是业务或配置的问题。

为什么这两边老是对不上？因为 OMS 和 WMS 根本不是在数同一件事。OMS 数的是"能卖的货"（可售库存），WMS 数的是"物理上在库位里的货"（实物库存）。一个管销售承诺，一个管仓库实物，中间隔着订单、在途、退货、单位换算一堆环节。任何一个环节口径没对齐，数字就分叉。

5 个排查点总览：OMS WMS 库存对不上的查案顺序

下面 5 个排查点，按我查案的顺序排——先时间、再业务、最后配置。每个都给你"怎么验证"和"怎么修"，照着做就行。

先分诊：30 秒判断库存差异出在哪一类

动手查之前，先 30 秒分诊，别 5 个点瞎查。看差异是"全量 SKU 都差"还是"个别 SKU 差"——全量都差，八成是同步时差或仓库映射，直接查第一类和第五类；个别 SKU 差，看差值是不是整倍数关系，是整倍数就是单位换算（第四类），不是整倍数先看退货和在途（二、三类）。分诊对了，10 分钟定位；分诊错了，查一下午。这个习惯能省你一半时间。

第一类：时间问题——同步时差和在途未扣减

**排查点 1：同步时差。**OMS 和 WMS 之间的数据同步，绝大多数项目不是实时的，而是定时任务，常见的是 15 分钟、半小时甚至一小时一跑。大促期间 WMS 那边已经出库了 200 件，OMS 这边同步任务还没跑，数字当然对不上。

怎么验证：找一笔刚出库的订单，看 OMS 的库存变化时间戳，和 WMS 的出库时间戳，差了多少分钟。如果差值正好等于你们的同步间隔，就是它。

怎么修：短期方案是把同步间隔调小（大促期间我一般建议调到 5 分钟以内）；长期方案是对出库、入库这种关键动作做实时推送，别再靠定时任务。注意：调小间隔会增加系统压力，先跟 IT 确认。

怎么预防：上线前把同步任务的监控告警接好——任务失败、延迟超过阈值，短信直接打到值班手机上，别只发邮件。大促前一周做一次全链路压测，模拟同步延迟，看 OMS 的可售库存会不会被击穿。这个坑我见过三次，每次的复盘结论都是同一句："监控没人看"。

**排查点 2：在途未扣减。**货已经从库位里拣出来、装车走了，但 OMS 的"在途"状态没更新，或者 WMS 的出库确认晚了一步，货就卡在"两边都不认"的真空地带。这个坑我见过三次，每次都是大促前夜爆出来。

怎么验证：在 WMS 里查"已分配未出库"和"已出库未确认"的单据，看有没有积压。再去 OMS 查同样时间段的可售库存计算逻辑——在途扣没扣，一眼就能看出来。

怎么修：把 WMS 的出库确认环节卡死，装车扫描后必须当天确认，不许"明天再说"。OMS 侧的可售库存公式里，在途必须明确扣减，写进需求文档，别靠口头约定。

怎么预防：在 WMS 里给"已出库未确认"设一个超时规则，超过 4 小时自动标红推送到班组长。装车扫描和出库确认做成同一个 PDA 界面，扫完装车直接点确认，不给"回头再说"的机会。流程上少一次切换，就少一次遗忘。

第二类：业务问题——退货未回库和单位换算

**排查点 3：退货未回库。**去年有个做服装的客户，大促前夜 OMS 显示某爆款有货 2000 件，WMS 显示 0。运营差点把链接下架，查到最后：退货的货堆在收货区三天了，质检没做，WMS 里还是"待处理"状态，OMS 却早就把退货单算回了可售。两边各说各话。

员工手持 PDA 在货架前扫码盘点

怎么验证：在 WMS 里拉"收货区待处理"的报表，看积压了多少退货。再核对 OMS 的退货入库时间点——如果 OMS 在"客户寄出退货"时就加回了可售，口径就是错的。

怎么修：退货必须走完"收货-质检-上架"全流程，WMS 确认上架后，OMS 才能加回可售。收货区积压超过 24 小时就预警，这个规则写进 SOP。

怎么预防：收货区划出专门的退货暂存区，物理隔离，别跟正常收货混在一起。每天 17:00 盘一次暂存区，积压不过夜。退货质检的 KPI 跟入库时效挂钩，别让质检员觉得"退货不着急"——货在暂存区多躺一天，OMS 和 WMS 的库存就多打架一天。

**排查点 4：单位换算。**这是最蠢但也最常见的一个。OMS 按"箱"卖，WMS 按"件"管，一箱 12 件，换算系数配错了，库存直接差出一个数量级。我见过一个项目，上线第一周全仓库存虚增 12 倍，原因就是系数配成了 1。

怎么验证：找任意一个 SKU，看 OMS 的库存单位和 WMS 的库存单位，再看接口里的换算系数。三处对一遍，错的一目了然。

怎么修：所有 SKU 的换算系数做一次全量核对，新品建档时把"销售单位-库存单位-换算系数"做成必填三联，缺一个不许建档。

怎么预防：ERP、OMS、WMS 三处的单位主数据，指定一个人统一维护，改一处三处联动，不许各改各的。每月跑一次"单位异常"报表：凡是库存单位不等于销售单位的 SKU，换算系数逐条过一遍。这个报表 10 分钟能看完，能挡掉 90% 以上的单位事故。

第三类：多仓映射错——两边都没错，错的是 OMS WMS 对账口径

**排查点 5：多仓映射错。**OMS 里一个"华东仓"，WMS 里可能是"上海 1 号仓"+"上海 2 号仓"两个物理仓。映射关系配错一个，OMS 的数字和 WMS 的数字就永远对不上。这个错法最冤，因为两边系统各自都没错。

怎么验证：把 OMS 的每一个逻辑仓，列出来它映射到 WMS 的哪些物理仓，一个一个对。有新增仓库、仓库合并、仓库更名的，先查映射表。

怎么修：仓库映射表单独维护，任何仓库的新增、合并、更名，必须先更新映射表再上线。建议每月做一次映射表巡检。

怎么预防：仓库映射表加版本号和变更日志——谁改的、什么时候改的、为什么改，全留痕。新仓上线前，映射表先在测试环境跑一轮完整对账，对上了才上生产。最怕的是"就加个仓，五分钟的事"，结果映射漏配，对账对了一个通宵。

**反常识的真相：两边都"没错"，错的是对账口径本身。**很多项目查到最后，OMS 没错，WMS 也没错，错的是两边对"库存"的定义本来就不一样。OMS 的可售 = WMS 实物 - 已分配 - 在途 - 质检中 - 安全库存，这个公式两边必须用同一套。口径不对齐，查一万遍也对不上。先统一公式，再谈对账。