19-中央库存体系设计：三层结构模型深度拆解

问题：为什么电商做到一定规模必须上中央库存？

小型电商直接在ERP里管库存就够了，但一旦多平台开店（淘宝+京东+抖音+拼多多）、多渠道发货（自有仓+三方仓+门店发货），就会出现：

超卖：两个渠道同时卖了最后1件，谁先发货谁后赔付？

库存分散：各渠道独立管库存，总部不知道总共有多少货

补货混乱：各渠道自己补货，结果A仓积压、B仓缺货

学习：三层结构模型

中央库存将库存从物理到销售拆分为三层：

┌─────────────┐

│ 3. 销售库存 │ ← 各店铺可卖的库存（映射到渠道）

├─────────────┤

│ 2. 逻辑仓库存│ ← 按业务规则重组的"虚拟库存"

├─────────────┤

│ 1. 物理库存 │ ← WMS里实际的货（仓+库位+批次）

└─────────────┘

第一层：物理库存（实体仓域）

存放实体仓库（含门店仓库）的实际库存。定位到：仓库+货主+SKU+库位+（批次）+数量+单位。

关键机制：

| 库存类型 | 说明 | 业务场景 |

|---------|------|---------|

| 总库存 | 仓里所有货 | 总数 |

| 可用库存 | 可销售/可调拨的货 | 正常售卖 |

| 锁定库存 | 业务订单预占，等着出库 | 已下单待发货 |

| 冻结库存 | 异常场景临时锁定 | 盘点、质检、临期管控 |

为什么必须区分锁定和冻结？

锁定库存是为了"后续出库"（正向流程）

冻结库存是为了"限制流转"（管控动作）

冻结优先级高于锁定：已冻结的库存不能被锁定，已锁定的可被冻结打断

经验教训：锁定和冻结如果用一个字段表示（省事），会导致：

无法区分"履约占用"和"管控限制"

业务执行策略无法区分（冻结后不能参与正常履约）

释放逻辑不同（锁定与订单绑定；冻结由管控动作触发释放）

第二层：逻辑仓库存（调度域）

在物理库存基础上，按业务管理规则对库存做"重组"（分割和组合）。

为什么要加这一层？

业务部门按品类划分：A部门管零食，B部门管日用品（物理上同在一个仓）

事业部管控：各事业部有独立的库存指标，但共享物理仓库

管理在途/在产库存：还未入库，但按业务单据已算出来

设计原则：

逻辑仓将"多变业务规则"与"稳定物理库存"剥离

业务调整只要改逻辑仓配置，不影响物理库存处理逻辑

建议逻辑仓:物理仓 = n:1（多对一），避免多对多的映射复杂度

第三层：销售库存（销售域）

实物库存变为"销售机会"的桥梁。

核心计算： `

可销售库存 = f(逻辑仓可用库存, 在途库存, 供货比例)

` 配置要点：

商品SKU映射（店铺的SKU编号 ⟶ 中央库存的SKU编号）

多仓供货关系（由哪几个仓供货，比例多少）

库存同步规则（定时/固定值/变动即更新）

库存分配策略（独占/共享/比例切分）

分析：物理—逻辑—销售三层解耦的价值

场景一：换WMS系统

如果没有逻辑仓：切换WMS时物理库存数据源变了，所有上层业务都要改——灾难

有逻辑仓：只需改物理到逻辑的对接层，上层销售库存完全不受影响

场景二：大促前调拨

A渠道爆单需要更多库存，B渠道滞销库存充足

逻辑仓层做"库存调整单"（A部门的库存划转给B部门）

物理库存不用变，实物还在原地，只是"谁有权卖"变了

场景三：多店铺共享库存

一个仓供5个店铺，总量1000件

店铺1独占300件，店铺2-5共享700件

店铺1的未占用不影响其他店铺；店铺2的锁库会减少店铺3的可卖量

理解：类比迁移

类比1 — 实体店 vs 电商中央库存

实体店的"柜台库存"=物理库存（货确实在柜台上）

"前台看到的标价签"=逻辑仓库存（你可以卖，也可以调整价签）

"实际卖了多少"=销售库存（最终可卖的渠道分配）

类比2 — API分层设计

物理库存 = 数据库层（底层存储）

逻辑仓 = 业务逻辑层（中间件，处理规则）

销售库存 = 表现层（对外暴露的接口）

关联（本库参考）：

13-仓储自动化与智能物流.md — 物理库存的自动化管理

06-库存系统优化与调度算法.md — 库存算法层面

09-供应链数字化演进路径.md — 系统整体架构

迁移：实战落地要点

中小电商（日均单<500）

简化：逻辑仓合并到物理层，只做物理→销售两层

先用ERP的库存管理功能，别自己造WMS

核心是防超卖：跨平台库存同步（用聚水潭/旺店通/店小秘）

中型电商（日均500-5000）

必须上三层结构，尤其是逻辑仓层

关键：采购入库单驱动库存加减，不做"同步库存值"（避免数据对不上）

每天凌晨做一次"库存快照"，便于追溯问题

大型电商（日均>5000）

批次的精细化管理：按批次锁定、先进先出扣减

库存预警系统：设置安全库存水位线，自动触发补货

多节点实时同步：性能优化（考虑缓存 + 异步队列）

实践：错题本

错题本1：直接用WMS的库存数据做销售

问题：WMS的库存没考虑"已锁定未发货"的状态，容易超卖

解决：销售库存必须在中央库存层计算，加上"锁库"和"冻结"逻辑

错题本2：多对多的逻辑仓—物理仓映射

问题：库存数据对不上，追溯困难

解决：尽量用n:1

错题本3：库存同步用"全量覆盖"

问题：并发冲突导致数据丢失

解决：用业务单据驱动（加减流水），避免直接同步库存值

调整：持续优化方向

从"加减库存"到"预测库存"：结合历史数据做需求预测，提前推算未来库存水位

从"防超卖"到"扩销售"：销售库存 = (实体+在途+虚拟）- 锁定，数据放大但要设置安全边界

AI辅助：预测何时触发库存预警、智能调拨建议

成事：一句话总结

> 中央库存的核心价值：把"货在哪"的记录，变成"货该去哪"的决策引擎。三层结构不是在增加复杂度，而是在为未来的不确定性预留灵活度。

📄 08.58-中央库存体系设计：三层结构模型