调拨单不是库存加减两次就完了：仓间调拨、在途库存、到货确认怎么设计

调拨单不是库存加减两次就完了：仓间调拨、在途库存、到货确认怎么设计

这篇直接按调拨单系统来拆，不只讲“源仓减、目标仓加”，而是把在途库存、到货确认和差异处理讲具体。
目标是你看完后，能把调拨单从两次库存变更，讲成一条完整的跨仓流转链路。

🦅个人主页
🐼GitHub主页

先看真实业务：为什么这块在仓储里总是容易出事

仓间调拨最大的难点，不是两边库存怎么改，而是调拨过程中的在途状态和责任边界怎么记。

• 源仓发出了货，但目标仓还没收货
• 运输途中可能丢失、损坏、数量差异
• 调拨期间库存不能重复售卖

真实业务场景我会怎么抽象

• 华东仓向华南仓调拨补货
• 门店缺货时从区域仓调货
• 跨仓调拨中可能分批发运和分批到货

1. 先生成调拨单并锁定源仓可调库存
2. 源仓发运后转成在途库存
3. 目标仓收货确认后转入目标仓可用库存
4. 出现差异时走调拨差异处理单

举个具体例子：放到项目里会怎么跑

比如上海仓缺货，要从杭州仓调 20 件过来，真实链路里不是“上海 +20、杭州 -20”这么简单，还要经历出库、在途、入库确认三段状态。

1. 调出仓先冻结可调拨库存。
2. 调拨出库后转成在途库存。
3. 调入仓签收后再把在途转成可用。
4. 如果运输途中丢件，要能按差异数量补记。

代码示例：调拨出库后转成在途库存

@TransactionalpublicvoidshipTransfer(LongtransferOrderId){TransferOrderorder=transferOrderRepo.mustGet(transferOrderId);inventoryService.decreaseLocked(order.getFromWarehouseId(),order.getSkuId(),order.getQty());inventoryService.increaseTransit(order.getToWarehouseId(),order.getSkuId(),order.getQty());order.setStatus(TransferStatus.IN_TRANSIT);transferOrderRepo.save(order);}

核心数据模型我会怎么定

• 建议拆调拨单主表、调拨明细表、发运记录表、到货确认表、差异处理表
• 库存余额要支持 inTransitStock 口径

系统设计我会优先拆哪几块

源仓发运层

• 扣减源仓可用库存并记录发运明细
• 发运后转在途，不直接加目标仓可用

在途管理层

• 记录发运时间、预计到货时间、运输单号
• 在途库存不应参与销售

目标仓收货层

• 按实收数量确认到货
• 支持部分到货和分批收货

差异处理层

• 短收、损坏、丢失走正式差异流程
• 差异处理结果影响账务和责任追踪

跨系统协同时哪些边界最重要

• 源仓负责发运真实性，目标仓负责实收确认
• 物流只负责运输信息，不直接改库存账
• 调拨差异不能靠手工改库存掩盖

监控和审计建议怎么做

• 调拨时长、到货及时率
• 在途库存超时量
• 调拨差异率
• 跨仓补货成功率

高频坑位复盘

1. 源仓减、目标仓同时加

• 会让在途库存完全失真

2. 调拨差异不单独建模

• 后续责任追踪和赔付都很难做

面试里我会怎么答

如果面试官问调拨单怎么设计，我会强调源仓发运、在途管理、目标仓收货、差异处理四段链路，尤其说明在途库存必须单独表达，不能简单做两次库存加减。

结语

调拨单系统最关键的，不是让两边库存变动，而是把跨仓流转过程和在途责任完整留痕。

想继续看哪块，评论区留个 1 或 2 就行：

• 1 在途库存设计
• 2 调拨差异处理