SHOPIFY INVENTORY

Shopify 库存补到 Bin：开发者该改哪些假设

开发者应预留 Bin 级库存模型，谨慎对待 preview。

Shopify 的库存系统过去主要围绕 Location 运转：一个商品库存项放在哪个仓库、门店或履约地点，有多少可售、在途、已承诺、现货数量。对很多商家来说，这套模型已经能支撑前台售卖和基础履约。

但对 ERP、WMS、3PL 和库存类 app 来说，这个颗粒度一直偏粗。

仓库里真实发生的事情，通常不只是“某个 SKU 在某个仓库有 100 件”。更常见的情况是：这个 SKU 在 A 仓 3 号货架有 40 件，在补货区有 20 件，在异常区还有 5 件。不同位置会影响拣货路径、盘点方式、补货动作和异常处理。

Shopify 现在正在把这层能力补上来。

根据 Shopify.dev 2026-07 unstable GraphQL Admin API 文档，Shopify 提供了 Physical inventory feature preview，覆盖 bins、counts、purchase orders 等能力。其中，Bin 被定义为 location 内部的 named storage，可以理解为货架、货架位、货格等物理存储位置。

开发者可以通过 inventoryBinUpsert 创建或更新 bin，也可以通过 inventoryCountCreate 设置某个 inventory item 在某个 bin 下的 on-hand 数量。

这说明 Shopify 的库存模型开始从 Location 级别继续向下细分。它并不代表 Shopify 已经提供了一套完整 WMS。更准确的判断是：Shopify 正在给库存基础设施补一个更接近仓库现场的层级。

Shopify 库存对象关系：Location 仍是库存聚合层，Bin 补充仓内位置表达。图源：Shopify.dev

Location 仍然是核心层

要理解这次变化，需要先回到 Shopify 现有库存对象关系。

在 Shopify 文档中，ProductVariant 负责面向顾客的商品变体信息；InventoryItem 表示用于库存、运输和履约的物理商品；InventoryLevel 连接一个 InventoryItem 和一个 Location，用来跟踪这个商品在该地点下的库存状态。

InventoryLevel 会涉及 available、on-hand、incoming、committed 等数量状态。Location 则是商家开展业务的地理或业务地点，比如 retail store、warehouse。

这套模型的核心关系一直是：

一个 InventoryItem，在一个 Location 下，有一组库存状态。

Physical inventory feature preview 加入 Bin 后，这个关系没有被推翻。Bin 位于 Location 内部，Location 仍然承担库存聚合、销售可用性、履约地点和业务地点的角色。

在 feature preview 文档中，Shopify 给出了一个关键计算关系：

location 总 on-hand = unbinnedQuantity + 所有 bin quantity 之和。

也就是说，Bin 让 on-hand 数量在 Location 内部有了更细的物理分布，但 Location 级别的总量仍然存在。现有 inventorySetQuantities 也继续工作；当开发者按 location-level 设置库存时，这部分数量会进入 unbinned quantity。

这个设计对开发者很关键。Shopify 没有用 Bin 替换 Location，而是在 Location 下面增加了一个可表达物理货位的层级。

Bin 解决的是“仓内位置”问题

在目前公开文档范围内，Bin 可以理解为 Location 内部的 named storage。它的价值主要体现在仓内管理，而不是前台销售逻辑。

对 WMS 和 ERP 来说，Bin 至少会影响三类系统设计。

第一，库存同步不能只看 item + location。

过去很多系统只维护 SKU、InventoryItem、Location 和数量的对应关系。加入 Bin 后，如果应用要表达真实仓内库存，就需要额外维护 item + location + bin 的数量关系。

第二，盘点会更接近仓库现场。

Physical inventory feature preview 覆盖 counts。文档中给出的 inventoryCountCreate 可以设置某个 inventory item 在某个 bin 的 on-hand 数量。这说明 Shopify 正在为“按货位盘点”预留 API 语义，而不只是修改一个 Location 总数。

第三，异常库存有了更清晰的落点。

在没有 Bin 的模型里，仓内多个货位、暂存区、退货区、待质检区的数量，往往只能由外部 WMS 记录，再把汇总结果同步回 Shopify。Bin 层级出现后，开发者有机会在 Shopify 侧表达一部分物理位置分布。

这里需要控制预期。当前文档说的是 feature preview，且位于 unstable API。它适合开发者测试、预研、调整数据模型，不适合直接作为生产系统唯一依赖。

这还不是完整 WMS

Shopify Editions Winter ’26 的公开页面摘要显示，Shopify 支持通过 CSV 或 Order Printer app bulk editor 给 SKU 分配 bin locations，用于提升拣货效率。

把这条信息和 Shopify.dev 的 feature preview 放在一起看，可以看到一个方向：Shopify 正在把“货位”纳入更多官方能力范围。

但从已核验资料看，不能把它解读为 Shopify 已经内置完整 WMS。

从已核验资料看，Shopify 公开提到的是 bins、counts、purchase orders，以及给 SKU 分配 bin locations 来提升拣货效率。这些信息足以说明 Shopify 正在补库存和仓内位置相关的基础能力，但不足以支持“Shopify 已经提供完整 WMS”的结论。

目前更稳妥的判断是：Shopify 在补库存基础设施，为 ERP、WMS、3PL 和 app 提供更标准的底座。它会减少一些系统之间对“仓内位置”的自定义映射，但还不能替代专业 WMS 的完整流程能力。

对 ERP、WMS 和 app 开发者的影响

开发者现在最该关注的，不是立刻上线 Bin 功能，而是提前修正模型假设。

如果系统仍然默认“一个 item 在一个 location 只有一个库存数量”，后续会很容易卡住。更安全的设计，是把库存拆成两层：

• 对外同步和履约判断，仍以 item + location 为主；

• 仓内分布和盘点记录，预留 item + location + bin。

这两个层级之间要有明确边界。Location 级别的 on-hand 是聚合结果；Bin 级别数量是物理分布。unbinnedQuantity 则意味着还有一部分 Location 内库存没有分配到具体 Bin。

这会带来一个实际问题：系统之间同步时，谁是货位数据的主系统？

如果 WMS 是主系统，Shopify 的 Bin 数据可能只是同步结果。如果 Shopify 后台或 Shopify app 允许编辑 Bin，WMS 又必须处理回写、冲突和审计。开发者需要提前设计几类边界：

• Bin 的创建和命名规则由谁控制；

• 同一个 Location 下 Bin ID 与外部仓库货位编码如何映射；

• location-level 库存调整进入 unbinnedQuantity 后，外部系统如何处理；

• 盘点覆盖的是某个 Bin，还是整个 Location；

• 当 API 仍处于 unstable / feature preview 时，生产环境是否需要功能开关。

这些问题比“能不能调通一个 mutation”更重要。

尤其是 inventorySetQuantities 仍然可用这一点，意味着新旧库存写入方式会共存。开发者不能假设所有库存都会天然落到 Bin。很多历史数据、第三方 app、人工操作和旧流程，仍可能只在 Location 层级写入数量。

对商家和服务商的影响

对商家来说，Bin 能力最直接的价值，是让拣货和盘点更清楚。

如果一个仓库里 SKU 数量不多、拣货路径简单，Location 级别库存可能仍然够用。引入 Bin 会增加基础资料维护成本，包括货位编码、SKU 绑定、盘点规则和员工操作规范。

如果商家已经有多个仓库、多个拣货区，或者同一 SKU 分散在多个货架，Bin 会更有意义。它能帮助系统表达“货在哪里”，而不只是“这个仓库有没有货”。

服务商在给商家做方案时，也需要避免过度承诺。可以把 Bin 作为库存精细化方向纳入规划，但不要把 unstable feature preview 包装成稳定交付能力。具体是否可用，还要看商家店铺后台、API 版本、应用权限和 Shopify 后续正式文档。

Spring ’26 Editions 公开页面摘要中还提到，permitsSkuSharing 字段移除，任何 fulfillment service 都可在多个 location 存货。这个方向与 Location 层级的灵活履约有关，说明 Shopify 也在继续调整履约服务和多地点库存的边界。具体 API 变更仍应以对应版本文档为准。

现在可以做什么

对于开发者，比较稳妥的准备方式有三步。

先把数据模型改到能容纳 Bin。即使暂时不启用，也不要在核心表结构和同步逻辑里写死 item + location 的唯一库存假设。

再做一层适配器。把 Shopify 的 Location-level 库存、Bin-level 库存、unbinnedQuantity 和外部 WMS 货位库存分开处理，避免直接把 preview API 深度绑定进生产主链路。

最后建立功能开关和版本隔离。Physical inventory 目前是 feature preview / unstable，适合沙盒店、测试店和内部预研。生产系统可以先保留兼容入口，等 Shopify 推进到更稳定版本后再扩大使用。

对于商家，现阶段可以先整理仓库基础资料：Location 是否清晰，SKU 是否稳定，货位命名是否统一，是否真的需要按货位拣货和盘点。基础资料混乱时，提前启用 Bin 只会把混乱搬进系统。

Shopify 正在把库存系统往更细颗粒度推进。Location 仍然是库存聚合和履约判断的核心，Bin 则补上 Location 内部的物理货位表达。对开发者来说，这不是一个可以忽略的小字段，而是库存系统边界会变细的信号。

现在最合适的动作不是抢跑，而是把模型留宽，把同步边界画清楚，把 preview 当作预研对象。等 API 状态稳定后，真正要改的就不会是整套库存底层。