从销售订单到销售出库单：库存锁定、释放与扣减的那点事

最近在做库存模块重构的时候，我遇到了一个之前想当然认为"就应该那样做"的问题。仔细琢磨之后，发现自己可能把事情想得太简单了。

在之前做海外仓OMS和WMS的时候，我们通常会采用"一张单走到底"的方式——这张单在创建或审核时先锁定库存，等到确认出库时再扣减库存。在库存流水的处理上，一般会这样做：锁定库存时写一条流水；真正扣减库存前，先写一条释放库存的流水；最后再写一条扣减库存的流水。整体下来就是三条流水。

这种模式比较好理解：我先占用库存，用完之后释放，再正式扣减，整个流程虽然会有些冗余，但逻辑是自洽的，而且所有动作都围绕同一张单据。

但这次刚好要在ERP中新增一个组织间交易、触发自动转卖的业务，我突然发现如果采用这种设计方式，库存流水数据会虚增很多，后续对库存流水排查、对账的时候就会麻烦很多。

于是我开始思考：之前的想法是不是有问题？

我把这个前因后果和纠结的点一起发给了AI，得到了一些解答，对这个问题的理解也有了不一样的视角。接下来，就跟大家分享一下这件小事背后容易被忽略的业务知识，以及我最终更倾向的方案是哪个。

一、库存数量类型的拆分

大多数供应链类系统在设计库存模块的时候，会基于库存的不同用途对库存数量进行拆分，通常会拆分成3类：

字段	含义	举个例子
在库数量	仓库里真实存在的货，On-hand	仓A里某SKU现在有100件
锁定数量	已经被某张单据"占住"但还没出仓的数量	其中30件被某张销售订单锁定了
可用数量	还能分配给新订单的数量	当前还能再接70件新订单

背后的数量计算公式是：可用数量 = 在库数量 - 锁定数量。

二、我纠结的问题

业务在ERP里下了一张销售订单（SO），然后ERP会把SO推给WMS执行出库作业。仓库可能会基于不同的发货要求多次回传结果，此时一张SO可能被拆成好几次发货，在ERP中生成多个销售出库单。

一般来说，在SO创建的时候会对库存进行锁定，以防止库存被其他单据占用。当后面ERP收到了仓库出库回传的数据之后，会生成对应的销售出库单去扣减库存。

此时，我们就会面临一个问题：销售出库单出库扣减库存的时候，是先把SO的锁定释放掉、再重新扣一遍可用库存，还是直接消耗掉SO已经锁定好的那部分？也就是应该选择写入3条库存流水，还是写入2条库存流水？

这个问题听起来好像很简单，就是一个二选一的问题。但仔细琢磨一下，库存流水随着单据的日积月累会逐步变得庞大，如果这里不仔细想清楚背后的细节，后面可能就会欠下一些没必要的技术债务。

三、市面上常见的三种做法

我把这个问题丢给了几个AI，也翻了一些主流ERP的帮助手册和产品介绍，发现大概的做法有这么三种。

第一种：SO不锁定，出库时才扣

这是最"乐观"的做法。销售订单只是记录客户需求，不在库存层面做任何动作，等到仓库真正发货、出库单过账时，才一次性把在库和可用都扣掉。这种做法实现最简单，很多早期的小系统都是这么干的。但问题也很明显：在稍微有点并发或者业务单量的时候就会出现问题——前面的订单还没发货，后面的订单已经把货"抢"走了。系统层面显示有货，业务现场却"无货可发"。本质上就是没有"占坑"机制，谁先发货谁拿货，先下单的反而可能被后下单的截胡。

第二种：SO锁定，出库时"先释放再扣减"

这种做法在创建SO的时候需要锁库存。SO创建时，先做一笔锁定（锁定+N、可用-N、在库不变）；等到出库单发货时，先把这笔锁定释放掉（锁定-N、可用+N），然后再从可用里扣减一次（在库-N、可用-N）。表面上看，账还是能算平的。但这里有一个隐蔽的风险：在"释放"和"扣减"这两个动作之间，可用库存会被短暂放大。在单机小系统里，这个时间窗口可能只有几毫秒；但在多服务、多线程的环境下，就有机会被别的请求插队，去占用那一瞬间"看上去多出来的可用库存"。这是一种隐蔽的超卖风险。

第三种：SO锁定，出库时"直接消耗锁定"

这是我更建议选择的方案。SO在创建或审核时就锁定库存，只影响锁定和可用，不动在库（锁定+N、可用-N、在库不变）。后续出库单发货过账时，不把这部分库存"放回公共池"，而是直接去消耗SO阶段形成的锁定——在同一个事务里同时减少在库和锁定（在库-N、锁定-N，可用不变）。换句话说，这部分货从一开始就被SO"认领"了，出库单只是把它从"锁定"状态变成"已发货"状态，中间不会再回到可用库存里兜一圈。

四、简单的案例推演说明

光讲概念可能还是有点抽象，我们用一个具体的数字例子来推演。在开始之前，先用一个流程图把整条链路串起来：

这个图展示的是上面提到的第三种方案（直接消耗锁定）的核心逻辑。SO锁定库存时，只影响锁定和可用，不动在库；出库单发货时，同时减少在库和锁定，可用通过公式自然维持；如果订单取消，就把锁定释放回可用池。

假设某个SKU在仓库A的初始状态是：在库100、锁定0、可用100。现在有一张SO要占用30件，最终会拆成两张出库单分别发20和10。

第一步：SO审核通过，锁定库存30件

操作	在库（前→后）	锁定（前→后）	可用（前→后）
SO锁定30	100→100	0→30	100→70

这一步的本质是：把未来一定要发的30件从可用池里"挑"出来，打上"订单锁定"的标签。仓库地面上什么都没发生，所以在库不变；但从此以后，新订单进来时只能看到70件可用库存了。

第二步：第一张出库单发货20件

操作	在库（前→后）	锁定（前→后）	可用（前→后）
出库20	100→80	30→10	70→70

注意看，可用库存是没有发生变更的。这是因为可用在SO锁定那一步就已经被用掉了，发货只是把锁定变成已出库，不再额外影响可用。

第三步：第二张出库单再发10件

操作	在库（前→后）	锁定（前→后）	可用（前→后）
出库10	80→70	10→0	70→70

到这里，SO的30件锁定被两张出库单全部消耗掉，锁定归零。整条链路从"承诺给谁"到"实际发给谁"，在流水上都能一条条对上号。

特殊情况：如果订单被取消了呢？

比如SO发完20件之后，剩下的10件被客户取消了。这时候我们需要通过一条"释放锁定"的流水把它还回可用池：

操作	在库（前→后）	锁定（前→后）	可用（前→后）
取消锁定10	80→80	10→0	70→80

在这个模型里，**"取消锁定"和"发货扣减"是一对对称操作**：前者把锁定退回可用，后者把锁定变成已出库。库存流水只要记录好"变更前、变更量、变更后"，后续无论是业务追溯还是财务对账，都能顺着流水一步步还原。

五、为什么建议选择"直接消耗锁定"

从上面的分析和推演可以看到，这两种方案表面上账都能算平，但我最终还是建议选择"出库单直接消耗锁定"的方案，主要有三个原因：

并发安全："先释放再扣减"在两个动作之间会短暂放大可用库存，给并发请求留下可乘之机。虽然可以通过事务和锁来规避，但这就增加了实现复杂度，而且在跨系统场景下（比如ERP和WMS分属两个服务）更难控制。
业务语义清晰：从业务视角看，SO一旦锁定库存，那部分货就已经"许配"给这个订单了，后面自然应该由这张订单对应的出库单来消耗。如果发货前还要先放回公共池再扣一次，哪怕账面能解释通，语义上也绕了一圈，跟业务同学沟通的成本会变高。
流水种类少，对账简单：采用"直接消耗锁定"的设计，整条链路只有三种核心动作：锁定库存、释放锁定、消耗锁定。既能覆盖绝大部分业务场景，又不会让流水种类爆炸。多一步"释放再扣减"，就意味着流水上会多一类动作类型，跨系统对账时要额外理解这一层语义。