从销售订单到销售出库单：库存锁定、释放与扣减的那点事
21
想系统掌握亚马逊广告的投放逻辑与底层闭环？
最近在做库存模块重构的时候，我遇到了一个之前想当然认为"就应该那样做"的问题。仔细琢磨之后，发现自己可能把事情想得太简单了。
在之前做海外仓OMS和WMS的时候，我们通常会采用"一张单走到底"的方式——这张单在创建或审核时先锁定库存，等到确认出库时再扣减库存。在库存流水的处理上，一般会这样做：锁定库存时写一条流水；真正扣减库存前，先写一条释放库存的流水；最后再写一条扣减库存的流水。整体下来就是三条流水。
这种模式比较好理解：我先占用库存，用完之后释放，再正式扣减，整个流程虽然会有些冗余，但逻辑是自洽的，而且所有动作都围绕同一张单据。
但这次刚好要在ERP中新增一个组织间交易、触发自动转卖的业务，我突然发现如果采用这种设计方式，库存流水数据会虚增很多，后续对库存流水排查、对账的时候就会麻烦很多。
于是我开始思考：之前的想法是不是有问题？
我把这个前因后果和纠结的点一起发给了AI，得到了一些解答，对这个问题的理解也有了不一样的视角。接下来，就跟大家分享一下这件小事背后容易被忽略的业务知识，以及我最终更倾向的方案是哪个。
一、库存数量类型的拆分
大多数供应链类系统在设计库存模块的时候，会基于库存的不同用途对库存数量进行拆分，通常会拆分成3类：
背后的数量计算公式是：可用数量 = 在库数量 - 锁定数量。
二、我纠结的问题
业务在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件
这一步的本质是：把未来一定要发的30件从可用池里"挑"出来，打上"订单锁定"的标签。仓库地面上什么都没发生，所以在库不变；但从此以后，新订单进来时只能看到70件可用库存了。
第二步：第一张出库单发货20件
注意看，可用库存是没有发生变更的。这是因为可用在SO锁定那一步就已经被用掉了，发货只是把锁定变成已出库，不再额外影响可用。
第三步：第二张出库单再发10件
到这里，SO的30件锁定被两张出库单全部消耗掉，锁定归零。整条链路从"承诺给谁"到"实际发给谁"，在流水上都能一条条对上号。
特殊情况：如果订单被取消了呢？
比如SO发完20件之后，剩下的10件被客户取消了。这时候我们需要通过一条"释放锁定"的流水把它还回可用池：
在这个模型里，**"取消锁定"和"发货扣减"是一对对称操作**：前者把锁定退回可用，后者把锁定变成已出库。库存流水只要记录好"变更前、变更量、变更后"，后续无论是业务追溯还是财务对账，都能顺着流水一步步还原。
五、为什么建议选择"直接消耗锁定"
从上面的分析和推演可以看到，这两种方案表面上账都能算平，但我最终还是建议选择"出库单直接消耗锁定"的方案，主要有三个原因：
并发安全："先释放再扣减"在两个动作之间会短暂放大可用库存，给并发请求留下可乘之机。虽然可以通过事务和锁来规避，但这就增加了实现复杂度，而且在跨系统场景下（比如ERP和WMS分属两个服务）更难控制。 业务语义清晰：从业务视角看，SO一旦锁定库存，那部分货就已经"许配"给这个订单了，后面自然应该由这张订单对应的出库单来消耗。如果发货前还要先放回公共池再扣一次，哪怕账面能解释通，语义上也绕了一圈，跟业务同学沟通的成本会变高。 流水种类少，对账简单：采用"直接消耗锁定"的设计，整条链路只有三种核心动作：锁定库存、释放锁定、消耗锁定。既能覆盖绝大部分业务场景，又不会让流水种类爆炸。多一步"释放再扣减"，就意味着流水上会多一类动作类型，跨系统对账时要额外理解这一层语义。
六、总结
把上面的推演收一收，可以用三句话总结SO、销售出库单和库存流水各自的职责：
销售订单（SO）：负责"承诺"。它决定哪些货应该被锁定给哪些客户，对应的库存动作是增加锁定、减少可用，不动在库。 销售出库单：负责"兑现"。它把之前SO锁定的库存真正发出去，对应的库存动作是减少在库、减少锁定，可用通过公式自然维持。 库存流水：负责"讲故事"。每一条流水都要说清楚变更前是多少、这次变了多少、变完之后是多少，让后来的人可以沿着流水把当时发生的事情还原出来。
当这三者的角色被讲清楚之后，哪怕以后再叠加出入库原因、批次维度、多仓、跨组织等复杂因素，你也会有一套可以反复复用的底层逻辑，不至于每遇到一种新业务就重新造轮子。
这件事情如果只站在技术实现的角度看，可能就是几张配置表、几条SQL语句的事，只是一个很简单的Case。但站在产品的视角，我认为更重要的是：这套设计能不能在未来三五年里，经得住业务变化和新人接手？能不能在财务对账、业务追溯、系统扩展时都说得通？
如果你以后也需要在业务型ERP里设计库存流水和单据体系，希望这篇笔记能给你一点启发和参考。供应链模块中还会有很多类似的小设计细节，值得我们细细揣摩、探究更优的方案。
最近在做库存模块重构的时候，我遇到了一个之前想当然认为"就应该那样做"的问题。仔细琢磨之后，发现自己可能把事情想得太简单了。
在之前做海外仓OMS和WMS的时候，我们通常会采用"一张单走到底"的方式——这张单在创建或审核时先锁定库存，等到确认出库时再扣减库存。在库存流水的处理上，一般会这样做：锁定库存时写一条流水；真正扣减库存前，先写一条释放库存的流水；最后再写一条扣减库存的流水。整体下来就是三条流水。
这种模式比较好理解：我先占用库存，用完之后释放，再正式扣减，整个流程虽然会有些冗余，但逻辑是自洽的，而且所有动作都围绕同一张单据。
但这次刚好要在ERP中新增一个组织间交易、触发自动转卖的业务，我突然发现如果采用这种设计方式，库存流水数据会虚增很多，后续对库存流水排查、对账的时候就会麻烦很多。
于是我开始思考：之前的想法是不是有问题？
我把这个前因后果和纠结的点一起发给了AI，得到了一些解答，对这个问题的理解也有了不一样的视角。接下来，就跟大家分享一下这件小事背后容易被忽略的业务知识，以及我最终更倾向的方案是哪个。
一、库存数量类型的拆分
大多数供应链类系统在设计库存模块的时候，会基于库存的不同用途对库存数量进行拆分，通常会拆分成3类：
背后的数量计算公式是：可用数量 = 在库数量 - 锁定数量。
二、我纠结的问题
业务在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件
这一步的本质是：把未来一定要发的30件从可用池里"挑"出来，打上"订单锁定"的标签。仓库地面上什么都没发生，所以在库不变；但从此以后，新订单进来时只能看到70件可用库存了。
第二步：第一张出库单发货20件
注意看，可用库存是没有发生变更的。这是因为可用在SO锁定那一步就已经被用掉了，发货只是把锁定变成已出库，不再额外影响可用。
第三步：第二张出库单再发10件
到这里，SO的30件锁定被两张出库单全部消耗掉，锁定归零。整条链路从"承诺给谁"到"实际发给谁"，在流水上都能一条条对上号。
特殊情况：如果订单被取消了呢？
比如SO发完20件之后，剩下的10件被客户取消了。这时候我们需要通过一条"释放锁定"的流水把它还回可用池：
在这个模型里，**"取消锁定"和"发货扣减"是一对对称操作**：前者把锁定退回可用，后者把锁定变成已出库。库存流水只要记录好"变更前、变更量、变更后"，后续无论是业务追溯还是财务对账，都能顺着流水一步步还原。
五、为什么建议选择"直接消耗锁定"
从上面的分析和推演可以看到，这两种方案表面上账都能算平，但我最终还是建议选择"出库单直接消耗锁定"的方案，主要有三个原因：
并发安全："先释放再扣减"在两个动作之间会短暂放大可用库存，给并发请求留下可乘之机。虽然可以通过事务和锁来规避，但这就增加了实现复杂度，而且在跨系统场景下（比如ERP和WMS分属两个服务）更难控制。 业务语义清晰：从业务视角看，SO一旦锁定库存，那部分货就已经"许配"给这个订单了，后面自然应该由这张订单对应的出库单来消耗。如果发货前还要先放回公共池再扣一次，哪怕账面能解释通，语义上也绕了一圈，跟业务同学沟通的成本会变高。 流水种类少，对账简单：采用"直接消耗锁定"的设计，整条链路只有三种核心动作：锁定库存、释放锁定、消耗锁定。既能覆盖绝大部分业务场景，又不会让流水种类爆炸。多一步"释放再扣减"，就意味着流水上会多一类动作类型，跨系统对账时要额外理解这一层语义。
六、总结
把上面的推演收一收，可以用三句话总结SO、销售出库单和库存流水各自的职责：
销售订单（SO）：负责"承诺"。它决定哪些货应该被锁定给哪些客户，对应的库存动作是增加锁定、减少可用，不动在库。 销售出库单：负责"兑现"。它把之前SO锁定的库存真正发出去，对应的库存动作是减少在库、减少锁定，可用通过公式自然维持。 库存流水：负责"讲故事"。每一条流水都要说清楚变更前是多少、这次变了多少、变完之后是多少，让后来的人可以沿着流水把当时发生的事情还原出来。
当这三者的角色被讲清楚之后，哪怕以后再叠加出入库原因、批次维度、多仓、跨组织等复杂因素，你也会有一套可以反复复用的底层逻辑，不至于每遇到一种新业务就重新造轮子。
这件事情如果只站在技术实现的角度看，可能就是几张配置表、几条SQL语句的事，只是一个很简单的Case。但站在产品的视角，我认为更重要的是：这套设计能不能在未来三五年里，经得住业务变化和新人接手？能不能在财务对账、业务追溯、系统扩展时都说得通？
如果你以后也需要在业务型ERP里设计库存流水和单据体系，希望这篇笔记能给你一点启发和参考。供应链模块中还会有很多类似的小设计细节，值得我们细细揣摩、探究更优的方案。
热门活动 
广东
12-26 周五
热门报告 
