库存中心（三层库存模型）

目录

• 三层库存模型
  • WMS
    • 一、货主（Owner）
      • 货主（Owner）业务对象的核心属性：
    • 库位
      • 二、库位的唯一编码规则：确保“一位一码”
      • 一个库位可以放多个sku吗
      • 一、适合一个库位放多个SKU的场景
      • 二、不建议一个库位放多个SKU的场景
    • 3. 库存记录：细化到「SKU+货主+库位」三维度
  • 逻辑库存
    • 一、逻辑层核心业务对象设计
    • 1. 库存主档（LogicalInventory）：核心载体
      • 关键属性：物理库存基数（physicBaseQty）
        • 一、定义逻辑库存的“上限边界”：避免逻辑库存“虚高”
        • 二、作为逻辑库存“数据校准的基准”：解决“账实不符”
        • 三、支撑逻辑库存“多维度拆分”：满足复杂业务需求
      • physicBaseQty数据维护
      • 关键属性：安全库存
        • 关键场景：应对“突发需求”，抓住短期增量机会
        • 三、风险场景：抵御“供应链波动”，降低断货风险
        • 四、优化场景：结合销售数据复盘，动态调整安全库存
  • 库存联动
  • 可销售库存
    • 一、面向渠道的可销售库存：业务对象与属性定义
    • 一、为什么可销售库存要包含“仓库信息”？
      • 1. 支撑“渠道专属仓”的履约逻辑
      • 2. 明确库存的“物理归属”，避免跨渠道库存混淆
      • 3. 简化“库存调拨”的决策逻辑
• 复杂场景举例
  • 1，在途库存
    • 1. 第一步：拆分“可销售库存”，单独设立“在途可售库存”
    • 2. 第二步：明确各环节的库存“锁定”与“流转”规则
      • （1）调拨发起时：激活“在途可售库存”，限制仅承接预售订单
      • （2）用户下单时：锁定“在途可售额度”，避免超卖
      • （3）3天后到货时：“在途库存”转“现货库存”，直接履约预售订单
    • 3. 第三步：异常场景兜底，防止库存混乱
  • 渠道层的独享和共享
• 参考资料

三层库存模型

WMS

一、货主（Owner）

作为独立的业务对象存在
货主是仓库中商品的「所有者」（可能是企业、品牌方、零售商等），在WMS中必须作为独立对象管理，核心原因是：

• 第三方物流仓库（3PL）通常为多个客户（货主）提供仓储服务，需严格区分不同货主的商品和库存；
• 即使是企业自建仓库，也可能存在「自有商品」和「代运营商品」（如品牌代发），需通过货主属性隔离管理。

货主（Owner）业务对象的核心属性：

属性	说明
货主ID（Owner ID）	唯一标识（如OW001），是关联商品、库存、单据的核心字段。
货主名称	企业/个人名称（如「苹果公司」「张三贸易商行」）。
货主类型	区分属性（如自有货主/外部客户/供应商，影响权限和结算逻辑）。
联系方式	联系人、电话、邮箱（用于业务对接和异常通知）。
结算信息	费率协议、结算周期（3PL场景中用于仓储费、操作费计算）。
状态	启用/禁用（如合作终止后标记为禁用，避免新业务产生）。

库位

WMS（仓库管理系统）中的库位，是指仓库内用于精准定位、存储和管理货物的最小物理空间单元，本质是给仓库里的 “每一个存储位置” 分配唯一标识，让货物能被快速找到、存取和盘点，避免混乱

二、库位的唯一编码规则：确保“一位一码”

定义库位的关键是给每个位置分配唯一编码（类似“身份证号”），WMS通过编码精准定位货物。编码规则需“简单易懂、可扩展”，常见结构为“多层级组合”，以手机制造企业的成品仓库为例：

• 典型编码结构：仓库编号 + 区域编号 + 货架编号 + 层号 + 位号
• 示例：1-ST-03-02-05
  • 1：仓库编号（如“1号成品仓”，区分多个仓库）；
  • ST：区域编号（“Storage”的缩写，代表存储区，区分收货区“SH”、拣选区“PI”等）；
  • 03：货架编号（第3号货架）；
  • 02：层号（货架第2层，从下往上计数）；
  • 05：位号（货架该层的第5个货位）。
• 核心作用：通过编码，WMS能快速定位货物（如“查询型号A手机的库存，显示在1-ST-03-02-05库位”），拣货员按编码找货，避免“到处翻找”。

一个库位可以放多个sku吗

但需根据仓库管理目标、货物特性和WMS系统支持情况，在“效率”和“管理复杂度”之间做权衡，并非所有场景都适合一个库位放多个SKU。

一、适合一个库位放多个SKU的场景

当多个SKU满足“体积小、关联性强、出库频率低”等条件时，混放可提高库位利用率（避免小SKU占用整库位导致浪费），且不会显著增加管理难度。

1. 场景1：小件、低值、出库频率低的配件类SKU
2. 场景2：关联性极强、常被同时出库的SKU
3. 场景3：临时暂存的待处理SKU

二、不建议一个库位放多个SKU的场景

当SKU具备“体积大、价值高、出库频率高、易混淆”等特性时，混放会显著增加库存错误率（如盘点时少算/多算）、拣货错误率（如错拿SKU），甚至导致货物损耗。

1. 场景1：体积大、占用空间足的成品SKU
2. 场景2：高价值、需精准管控的SKU
3. 场景3：出库频率高、需快速拣货的SKU
4. 场景4：特性易混淆的SKU

3. 库存记录：细化到「SKU+货主+库位」三维度

库存记录（Inventory）是核心载体，需通过“SKU+货主+库位”的组合唯一标识库存，确保同一SKU在同一库位下，不同货主的库存可区分。

核心属性	说明	设计逻辑
库存ID	唯一标识（如INV-001）	唯一记录一条库存数据
SKU编码	关联共享SKU（如OPPO find n3 128G）	绑定物理商品
货主ID	关联货主（如货主A）	明确该部分库存的归属（即使SKU相同，货主不同则库存独立）
库位编码	关联库位（如A-1-01）	记录库存的物理位置
数量	该货主在该库位的该SKU库存数量（如货主A在A-1-01有20台）	核心数据：区分同一SKU在同一库位下不同货主的库存
批次号	关联批次（如L20230601，同一批次可被多货主共享）	追溯时需同时关联货主（如批次L20230601中，货主A占10台，货主B占15台）
库存状态	合格/待检/锁定（如货主A的库存被锁定，不影响货主B的可用库存）	状态按货主隔离（同一SKU在同一库位，不同货主的状态独立）

逻辑库存

一、逻辑层核心业务对象设计

逻辑层的核心目标是：基于物理库存，结合业务规则（如预占、锁定、安全库存）计算「可售库存」，并记录全链路库存变动。其业务对象需覆盖「库存主体、状态维度、变动记录、规则配置」四大类，具体设计如下：

1. 库存主档（LogicalInventory）：核心载体

逻辑层的最小库存管理单元，按「SKU+仓库+货主」唯一标识（多仓多货主场景下的核心维度），记录该维度下的各类库存状态汇总值。

核心属性	说明	业务意义
库存ID	唯一标识（如INV-123）	逻辑层库存记录的唯一键
商品SKU	关联商品的SKU编码（如SKU001）	明确管理的商品单元（最小可售单位）
所属仓库ID	关联仓库（如WH-BJ，北京仓）	绑定物理存储位置（逻辑库存需对应具体仓库的物理库存）
所属货主ID	关联货主（如OW001，品牌A）	区分库存归属（多货主场景下避免混淆）
可用库存（availableQty）	当前可被销售的库存数量（=物理库存-预占库存-锁定库存-安全库存）	前端销售展示的核心依据（直接影响是否允许下单）
预占库存（allocatedQty）	已被订单下单但未完成支付/履约的库存数量（如用户下单未支付时锁定的库存）	防止超卖（同一库存不会被多个订单同时占用）
锁定库存（lockedQty）	因异常/特殊业务被冻结的库存（如质检不合格、临期待处理、售后锁定）	限制这类库存参与销售（避免问题商品被卖出）
在途库存（inTransitQty）	从其他仓库/供应商运输中，尚未入库的库存（如调拨在途、采购在途）	用于中长期库存规划（可展示为「预售库存」）
物理库存基数（physicBaseQty）	同步自WMS的实际库存数量（基础数据源）	逻辑层所有计算的基准（需与WMS物理库存保持一致）
安全库存（safetyQty）	为应对突发需求设置的最低库存阈值（如设置10件，低于此值触发补货提醒）	避免库存售罄导致断货（平衡库存周转和服务体验）
最后同步时间	与WMS物理库存的最近同步时间	用于校验库存数据新鲜度（判断是否需要重新同步）

关键属性：物理库存基数（physicBaseQty）

是逻辑库存的“数据根基”，核心作用是锚定“仓库实际拥有的货物数量”，确保逻辑库存（用于前端展示、下单扣减）与物理库存（仓库真实库存）不脱节，避免超卖、少卖或库存数据混乱。

要理解其具体用途，需先明确电商三层库存的基本逻辑：物理库存（仓库真实货量）→ 逻辑库存（系统层面可分配的货量）→ 可用库存（前端用户可下单的货量）。而 physicBaseQty 正是连接“物理库存”与“逻辑库存”的关键桥梁，具体用途可拆解为3点：

一、定义逻辑库存的“上限边界”：避免逻辑库存“虚高”

逻辑库存是系统根据业务需求（如预留、调拨）从物理库存中划分出的“可管理货量”，而 physicBaseQty 直接决定了逻辑库存的最大可能值，防止逻辑库存超过仓库实际拥有的货量。

• 举例：某电商仓库实际有1000台手机（物理库存），physicBaseQty 就设为1000。
  此时逻辑库存最多只能设为1000（如“预留200台给大促，可售逻辑库存800台”），无法设为1200——若没有 physicBaseQty 限制，逻辑库存可能被错误设置为超出物理库存的数值，导致后续下单后仓库无货可发，引发超卖。
• 核心逻辑：逻辑库存 ≤ physicBaseQty（物理库存基数），确保逻辑库存始终有真实货物支撑。

二、作为逻辑库存“数据校准的基准”：解决“账实不符”

电商运营中，逻辑库存可能因订单取消、退货、盘点差异等原因与物理库存脱节（如逻辑库存显示800台，但仓库实际只剩750台），此时 physicBaseQty 就是校准逻辑库存的核心依据。

• 具体场景：
  1. 定期盘点后，发现仓库实际库存（750台）与 physicBaseQty（原1000台）不一致，需先将 physicBaseQty 修正为750（匹配真实物理库存）；
  2. 再以修正后的 physicBaseQty（750）为基准，调整逻辑库存（如原逻辑库存800台，需同步下调至750台以内），确保逻辑库存与真实货量对齐。
• 核心价值：避免逻辑库存“悬浮”——若没有 physicBaseQty 作为基准，逻辑库存可能长期与物理库存脱节，导致前端展示的库存不准（如实际没货但仍显示可售），或仓库有货但逻辑库存已归零（导致少卖）。

三、支撑逻辑库存“多维度拆分”：满足复杂业务需求

电商逻辑库存常需按业务场景拆分（如“可售库存”“预留库存”“调拨中库存”），而所有拆分后的逻辑库存之和，必须以 physicBaseQty 为总量限制，确保拆分不混乱。

• 举例：physicBaseQty 为1000台（物理库存），逻辑库存可拆分为：
  • 可售逻辑库存：700台（前端用户可直接下单）；
  • 预留逻辑库存：200台（预留给即将开始的直播活动）；
  • 调拨中逻辑库存：100台（已分配给异地仓库，待出库）；
• 关键约束：可售+预留+调拨中=1000台=physicBaseQty，确保各维度的逻辑库存拆分后，总量仍与物理库存一致，避免“重复分配”（如同一批货既算可售，又算预留）。

physicBaseQty数据维护

这是最主流的模式，适用于电商企业自有仓库（或与第三方仓储共用一套WMS）的场景，能最大程度减少数据中转环节，降低误差。

1. 同步触发机制
   WMS会在“影响物理库存的关键动作”发生后，主动或被动将数据同步给电商库存系统（如ERP、SCM），进而更新 physicBaseQty：

   • 主动同步：当WMS完成“入库确认”（如采购到货、生产入库）、“出库确认”（如订单发货、调拨出库）、“盘点调整”（如盘盈/盘亏后修正库存）时，系统自动触发数据推送，实时更新 physicBaseQty。
   • 被动同步：电商库存系统按固定频率（如每5分钟、每小时）向WMS发起“库存查询请求”，拉取当前各SKU的物理库存数量，对比并更新 physicBaseQty（适用于WMS不支持主动推送的老旧系统）。

2. 同步数据内容
   WMS同步给电商库存系统的，不仅是“数量”，还包括匹配 physicBaseQty 所需的关键维度，确保精准对应：

   • 基础信息：SKU编码（如“手机型号A-黑色-128G”）、仓库编码（如“北京仓”“上海仓”）；
   • 库存数量：当前仓库该SKU的“实际可用物理库存”（需扣除已拣货但未出库的“锁定库存”，避免重复计算）；
   • 库存状态：如“正常库存”“残次库存”（physicBaseQty 通常仅统计“正常可销售的物理库存”，残次库存需单独管理）。

关键属性：安全库存

关键场景：应对“突发需求”，抓住短期增量机会

电商常面临“临时流量爆发”（如直播带货、平台突然推流）或“需求应急”（如某SKU突然成为网红款），安全库存可作为“应急储备”，避免因库存不足错失增量。

• 核心动作：
  1. 提前预留“应急安全库存”：对有潜在爆品属性的SKU（如新品、节日相关配件），在常规安全库存外，额外预留10%-20%的“应急安全库存”（如常规300件，应急加60件，共360件）。
     示例：某新品耳机原本日均售50件，直播期间1小时售200件，常规安全库存150件（3天量）+应急60件，可支撑直播需求，无需临时下架。
  2. 手动触发安全库存释放：当突发需求导致可售库存售罄时，运营可快速手动释放部分或全部安全库存（如释放60件应急库存至可售层），延长销售窗口期，同时同步启动加急补货。
• 业务价值：将“突发流量”转化为实际销量，避免“有流量没库存”的浪费，尤其适合直播、短视频带货等强时效性场景。

三、风险场景：抵御“供应链波动”，降低断货风险

电商供应链常面临“供应商延迟发货”“物流中断”“质检不合格”等风险，安全库存可作为“缓冲垫”，避免因供应链问题导致长期断货。

• 核心动作：
  1. 按供应链风险等级调整安全库存：对供应链不稳定的SKU（如海外采购配件、小厂供应商产品），将安全库存比例提高20%-50%（如常规3天量，提至4-5天量）。
     示例：某海外采购的手机镜头，正常补货需7天，若供应商常延迟2天，安全库存从700件（100件/天×7天）提至900件（100件/天×9天），覆盖延迟风险。
  2. 锁定安全库存避免误消耗：当供应链出现明确风险（如供应商告知“延迟5天发货”），运营可在系统中“锁定全部安全库存”，禁止释放至可售层，确保这部分库存仅用于“应急供应”（如维持核心渠道需求）。
• 业务价值：降低供应链风险对销售的影响，避免因供应商问题导致“长期断货”，尤其对依赖单一供应商的SKU，安全库存是关键保障。

四、优化场景：结合销售数据复盘，动态调整安全库存

安全库存不是“固定值”，需通过业务数据复盘，避免“安全库存过高导致积压”或“过低无法防风险”，实现“成本与风险的平衡”。

• 核心动作：
  1. 定期复盘安全库存有效性：每周/每月统计“安全库存触发次数”（如本月某SKU触发了3次安全库存释放）、“缺货次数”（如仍断货1次）、“库存积压天数”（如安全库存长期未动，积压15天）。
     分析结论：若频繁触发释放且仍断货，说明安全库存过低；若长期未触发且积压，说明过高。
  2. 动态调整安全库存阈值：根据复盘结果调整比例，如“某SKU本月断货2次，安全库存从3天量提至5天量”；“某SKU积压20天，从5天量降至2天量”。
• 业务价值：避免“无效安全库存”占用资金和仓储空间（如滞销款安全库存过高导致过期），同时确保安全库存能真实应对风险，降低整体库存成本。

库存联动

事件	可销售库	逻辑库存	物理库存
下单	占可销售库存
支付	扣可销售库存	占逻辑库存（如有库存）
给wms发货通知单			占库位库存
出库			扣库位库存

可销售库存

为什么需要销售库存？
1 满足销售侧业务需求，如预售，超卖， 渠道共享或者独享库存。
渠道共享：如我有100台手机，我希望天猫店和抖音店共享这100台
渠道独享。我有100台手机，我设置60台给抖音店，40台给天猫店
2 确保库存的一致性，避免超卖。
销售侧下单需要预占库存。 如果没有销售库存，仓库作业是无法支持销售侧的预占能力的（WMS 库内作业仅支持出库操作和入库操作） 容易导致下了单没有货发。 比如销售侧查询WMS库存有100台，下单100台.到订单评审通过给WMS发货指令的时候发现库存已经没了。
做法：所有场景（销售，供应链等）对库存的减少操作（占用和扣减）经过销售库存，占用成功后才能往下走流程。

一、面向渠道的可销售库存：业务对象与属性定义

面向渠道的可销售库存业务对象可定义为“渠道-可销售库存单元”，即“每个渠道下每个SKU的可销售库存独立核算”，其属性需覆盖“渠道标识、库存额度、规则约束、超卖配置”四大维度，具体如下：

属性分类	属性名称	数据类型	属性解释	业务作用
1. 基础标识属性	渠道可售库存ID	字符串（唯一）	全局唯一编码，如“JD-SKU001-BJ”（JD=京东渠道，SKU001=手机型号A，BJ=北京仓）	唯一识别每个渠道-SKU的可售库存单元，用于系统查询、对账和追溯
	渠道编码	字符串	渠道唯一标识，如“JD”（京东）、“TM”（天猫）、“XM”（线下经销商XM）	关联具体渠道，确保库存仅归属该渠道，不与其他渠道混用
	SKU编码	字符串	商品唯一标识，如“PHONE-A-BLK-128G”（手机A-黑色-128G）	绑定具体商品，确保库存与SKU精准对应
	仓库编码	字符串	库存归属仓库，如“WH-BJ-01”（北京1号仓）	明确库存物理存储位置，支撑后续出库、调拨逻辑
2. 库存数量属性	渠道可售基础额度	整数	从逻辑库存中分配给该渠道的“基础可售量”，如“500台”	渠道常规销售的库存基数，不包含超卖额度
	已售数量	整数	该渠道已下单且未取消的数量，如“300台”	实时计算“剩余可售量”（基础额度+超卖额度-已售数量），支撑前端库存展示
	冻结数量	整数	因订单取消待恢复、售后退货待质检等原因冻结的数量，如“50台”	避免冻结库存被重复下单，确保库存计算准确
3. 渠道规则属性	渠道专属库存标识	布尔值（是/否）	“是”表示该库存仅归该渠道使用，“否”表示可跨渠道调拨（如紧急时支援其他渠道）	控制库存灵活性，如核心渠道（京东）设为“专属”，避免库存被其他渠道占用
	库存生效时间/失效时间	日期时间	如“2024-11-01 00:00”生效，“2024-11-11 23:59”失效	适配渠道短期活动（如双11），活动结束后自动回收未售库存至逻辑层
	最低展示库存	整数	前端展示的“最低库存数”，如“10台”（即使实际剩余5台，仍显示10台）	避免因库存过低导致用户放弃购买，提升转化
4. 超卖支持属性	超卖阈值	整数/百分比	允许超卖的最大额度，如“50台”或“基础额度的10%”（500台基础额度则超卖50台）	定义超卖上限，避免无限制超卖导致履约风险
	超卖启用状态	布尔值（是/否）	“是”表示该渠道-SKU允许超卖，“否”表示禁止超卖	灵活控制超卖场景，如热销款启用超卖，滞销款禁止超卖
	超卖订单锁定时间	整数（分钟）	超卖订单下单后需在规定时间内付款，否则自动取消，如“30分钟”	控制超卖订单履约风险，避免用户下单后不付款导致库存长期占用
	超卖冻结库存数	整数
	超卖可用库存数	整数

一、为什么可销售库存要包含“仓库信息”？

渠道可售库存绑定“仓库编码”，核心是为了打通“前端销售”与“后端履约”的直接关联，避免“渠道下单后找不到对应库存”或“跨仓调拨导致履约延迟”，具体原因有3个：

1. 支撑“渠道专属仓”的履约逻辑

很多电商会为核心渠道设置“专属仓库”（如京东自营仓、天猫优选仓），渠道订单需从专属仓发货（减少跨仓物流成本、提升时效）。此时“仓库信息”是“渠道可售库存”的核心约束——若不绑定仓库，系统无法判断“该渠道的可售库存对应哪个仓”，可能导致订单分配到无货的仓库，引发履约混乱。

• 示例：京东渠道的“手机A”可售库存绑定“北京京东专属仓”，用户在京东下单后，系统直接分配北京仓的库存发货，无需从上海仓调拨，次日达时效才能保障。

2. 明确库存的“物理归属”，避免跨渠道库存混淆

同一SKU可能在多个仓库有库存，且不同仓库的库存归属不同渠道（如北京仓库存归京东，上海仓库存归天猫）。若可售库存不标仓库，会出现“总库存够但渠道对应仓库没货”的问题——比如“手机A”总库存1000台（北京仓500台归京东，上海仓500台归天猫），若京东渠道可售库存不绑仓库，可能显示“可售1000台”，但实际京东只能用北京仓的500台，用户下单后发现上海仓库存不能用，导致超卖。

3. 简化“库存调拨”的决策逻辑

当渠道可售库存不足（含超卖后），需从其他仓库调拨时，“仓库信息”能快速定位“可调拨的库存来源”。比如京东北京仓的“手机A”可售库存售罄，系统可通过“仓库编码”筛选“同渠道其他仓库”（如京东天津仓）或“可共享库存的仓库”（如企业备用仓），快速发起调拨，无需逐一排查所有仓库的归属关系。

复杂场景举例

1，在途库存

案例：某卖家A没货了。从B卖家调拨100台机器过来，预计3天到货，卖家希望在到货之前就可以在商场预售。
设计可销售库存和逻辑库存联动，避免重复增加库存。
【总结】逻辑层增加 在途库存（无需在途占用属性），可销售库存层增加 可用预售库存，冻结预售库存。

这种场景本质是“在途库存预售”，核心是通过拆分可售库存状态+锁定在途库存额度+到货后精准流转来实现，既要满足提前售卖的需求，又要杜绝库存重复计算和超卖风险。

1. 第一步：拆分“可销售库存”，单独设立“在途可售库存”

不能把“在途库存”直接混入常规可售库存，而是要给它单独的“身份标识”，让系统和用户都明确这是“预售库存”：

• 可销售库存拆分为两类：
  • 「现货可售库存」：已入库、能立即履约的库存（如A卖家原有的0台，到货后会从这里增加）。
  • 「在途可售库存」：调拨中、未入库但允许提前售卖的库存（如A从B调拨的100台，发起调拨时就计入这里）。
• 用户端展示：商品详情页需标注“预售（3天后到货）”，下单时明确告知发货时间，避免误解；系统端则通过两个库存字段分别统计，互不干扰。

2. 第二步：明确各环节的库存“锁定”与“流转”规则

核心是让“在途可售库存”仅用于承接预售订单，到货后直接转为“现货库存”履约，不重复新增：

（1）调拨发起时：激活“在途可售库存”，限制仅承接预售订单

• A卖家发起从B的100台调拨后，系统操作：
  • 逻辑库存下的「在途库存」+100（记录调拨事实）。
  • 可销售库存下的「在途可售库存」+100（开放预售权限）。
  • 「现货可售库存」仍为0（无货可立即发）。
• 履约系统承接规则：用户下单时，若选择“预售”，系统自动扣减「在途可售库存」，生成“预售型履约承接单”，并标注“待在途到货履约”，进入专属的“预售订单池”（而非普通待履约池）。

（2）用户下单时：锁定“在途可售额度”，避免超卖

• 比如用户C下单购买20台预售机器，系统同步做两件事：
  • 「在途可售库存」从100→80（锁定20台额度，防止其他用户再买这20台）。
  • 履约承接单中记录“占用在途库存20台”，明确这部分订单的库存来源是“调拨到货”，而非现货。

（3）3天后到货时：“在途库存”转“现货库存”，直接履约预售订单

这是避免重复增加的关键一步——到货后只做“状态转移”，不做“新增”：

• WMS实物入库：A卖家实物库存+100，同步触发逻辑库存流转：
  • 逻辑库存下的「在途库存」从100→0（调拨完成，在途状态消失）。
  • 可销售库存下的「现货可售库存」从0→100（转为可立即履约的现货）。
• 自动触发预售订单履约：
  • 系统找到“预售订单池”中占用这100台在途库存的订单（如用户C的20台）。
  • 从「现货可售库存」中锁定20台（100→80），将“预售型履约承接单”转为“正式履约订单”，开始拣货发货。
• 此时「在途可售库存」已为80（因之前下单扣减20），到货后无需再增加，直接随着“在途库存”的清零而同步清零，彻底避免重复。

3. 第三步：异常场景兜底，防止库存混乱

• 在途库存取消/延误：若B无法发货或到货延迟，需立即操作「在途可售库存」扣减（如100→0），并自动通知已下单用户“预售取消/延期”，同时关闭该商品的预售入口，避免超卖。
• 部分到货：若只到80台，則「在途库存」100→20，「现货可售库存」0→80，优先履约已下单的80台（如用户C的20台+其他用户60台），剩余20台仍保留「在途可售库存」，直至全部到货。

渠道层的独享和共享

案例1：我物理库存有 1000 台，那我要求是 500 台做秒杀活动，另外 500 台作为普通销售，如何设计库存模型？
案例2：制造业，做一个线上线下打通的项目。 买家可以在商场买线下门店的货。门店有100个手机，其中留30台在门店渠道销售，70台放在电商平台放在线上销售。

方案1：在原逻辑库存主档（LogicalInventory）中，新增「库存用途（inventoryPurpose）」字段，作为核心拆分维度，使 “SKU + 仓库 + 货主 + 库存用途” 成为逻辑层的唯一库存单元。

方案2：
在逻辑库存层的「可售库存」下新增库存分类子层，叫销配层。为了渠道层做分配，不同的渠道设置独占，或者共享。销配层有独立的实体。销配层也有货主的概念

，本质是将逻辑层从 “单一层级” 拆分为 “总览层 + 分类子层”，形成「物理库存层→逻辑总览层→库存分类子层→渠道库存层」的四层结构。核心是通过 “子层” 承接具体业务场景（如秒杀、普通销售）的库存管控，既保留逻辑层对库存的整体把控，又让场景化控制更灵活。

方案2核心优势：比 “直接拆分逻辑库存主档” 更灵活，适合场景多（秒杀、普通、预售、大客户、员工内购等），需严格控制总量，灵活调整场景库存
与 WMS 的映射：仅需总览层对接，子层不直接关联物理层。

参考资料