ERP 直连之后发生了什么？库存同步的两种做法对比

连上只是最容易的那一步

ERP 和仓库系统连上之后，订单数据第一天就跑通了，看起来很干净。难的是一周以后——订单开始出库，库存数字开始打架。

处理这个分歧基本上就两条路，走错的那条会让你和仓库反复拉锯。

做法一：仓库数字说了算

每一次实物移动——入库、拣货、装箱、退回——都立刻改仓库系统的库存，然后由仓库推给 ERP 和店铺。

维度	仓库为主
触发时机	实物移动
实物库存准确度	高
风险	推送失败时店铺数字变旧
对仓库系统要求	高

只要你有真实库存，这就是正确做法。它不会漂移，因为它数的是箱子，不是意图。

前提是仓库系统要在动作发生的那一刻就记下来。邮满满云仓用的是极风 WMS，入库、拣货、增值加工都是离散事件记录，不是夜里跑一个总数对一下。

做法二：店铺数字说了算

反过来。店铺的可卖库存决定仓库能卖多少，仓库照着这个数往下走。

维度	店铺为主
触发时机	下单那一刻
实物库存准确度	靠纪律
风险	订单跑得比拣货快就超卖
对仓库系统要求	没那么高

库存真的无限的时候这招能用——缺货就临时进一点，数字错两小时也没人发现。大部分卖实物的卖家没有这个条件。

没人会在电话里问的延迟问题

两种做法都有一段「箱子下架了但店铺还没更新」的空档。这段空档有多长，取决于事件是怎么批处理的：

同步方式	大致延迟	代价
事件触发	秒级	系统压力最大
几分钟一次	几分钟	多数人的默认选择
每小时批量	最多一小时	超卖窗口从这里开
夜里跑一次	第二天	等于没有回传

事件驱动的体验最好，运行成本也最高。多数人落在「每小时批量」，这没问题——前提是你知道这个窗口存在，并且别在上面堆假设。

退货这件事，仓库为主才显出价值

退回来一件货，对库存准确度来说是个小灾难。它到仓了，要检验，可能能卖，可能不能。

在仓库为主的模型里，每一步都是一条记录，系统里的数字跟着实物的状况走。在店铺为主的模型里，一次没人手工登回去的退货就是凭空消失的量，而且它不会自己报警。

如果你的退货率不低，光是这个不对称，就够理由选仓库为主了。

如果你现在的货其实都压在供应商那边、自己手里没有实物库存，那就完全是另一回事了——那种情况下Smartdropping的代采购加一件代发更合适，库存责任本来就在供应商那边，仓库为主这个模型对你没有意义。

到底怎么选

问两个问题。正常情况下仓库里压着多少货——如果答案是几千件，仓库为主。你团队能不能在一天之内把某个 SKU 数清楚——如果不能，店铺为主一周之内必然漂移。

还有第三个问题能省更多时间：仓库的数字推过来的时候，你那个 ERP 会怎么处理它。如果是直接覆盖店铺原来的数，那就等着吵一架。如果是做对账，那就没事。

推给多个店铺这件事本身还有一层坑——同一套库存要同时喂给几个渠道，谁先谁后、冲突了听谁的，得提前定。这也是云雀驿站那条链路能帮你省下来的部分：17+ 个平台的官方 API 打通，订单、库存、运单回传不用你手动分店铺处理。

两种习惯，选哪种方案都该有

定期做一次实物盘点，跟系统对一遍，哪怕同步跑得很好。自动化能捕捉每一笔交易，但它抓不住第一天就被人数错的那一箱。

另外准备一份很短的记录，写清每个 SKU 放在哪——哪个货位、哪一层架子。有了这张单子，每次盘点能省一半时间。

FAQ

Q：接了 ERP 之后库存会自动同步吗？ A：仓库侧的实物移动会被实时记录，再由仓库往外推。需要你自己决定的是推送频率——秒级、几分钟还是每小时。上线时先问清楚默认是哪一种。

Q：仓库为主和店铺为主，选哪个？ A：只要手里有真实库存，就是仓库为主。店铺为主只在库存实际上无限、数字错一小时代价为零的时候才合适。

Q：店铺库存多久更新一次？ A：这取决于你选的同步方式，不是取决于连接本身。事件触发是秒级，批量是分钟级，夜里跑是隔天。三种都合理，但要主动选，别默认。

Q：ERP 直连包含退货流程吗？ A：退货是按离散事件记录的，这也是把仓库作为事实来源的一个实际理由。配置的时候单独把退货流程问一遍。

Q：我们有自己的仓库系统，只同步库存可以吗？ A：在有些架构下这是更干净的做法。取决于你们系统和仓库系统怎么分工——把现有架构发给我们，我们会照实说这个拆分值不值那点复杂度。

正在接 ERP，不确定哪边该当事实来源？把现有架构发到联系我们，我们陪你把两条路都过一遍。