出库单系统怎么设计才扛得住业务？拣货、复核、发运、状态机全拆开讲

出库单系统怎么设计才扛得住业务？拣货、复核、发运、状态机全拆开讲

这篇直接按出库单系统来拆，不只讲“发货扣库存”，而是把拣货、复核、发运、状态机和异常处理讲具体。
目标是你看完后，能把出库单从扣减库存，升级成一条面向履约的执行链路。

🦅个人主页
🐼GitHub主页

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

出库流程真正复杂的地方，不是减库存，而是不同步骤、不同角色、不同异常都要有明确状态。

• 订单创建后不一定立刻拣货，可能缺货或等待波次
• 拣货、复核、打包、交接物流是多步骤流程
• 部分拣货、换货、撤单都可能在出库中发生

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

• 销售订单出库、调拨出库、售后换货出库并存
• 热门订单高峰期要波次化处理
• 发货前需要复核和打包

1. 根据订单生成出库单
2. 按库位执行拣货并记录拣货明细
3. 复核通过后打包交接物流
4. 最终更新出库状态和库存账本

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

比如一个订单里有 3 个 SKU，库位分散在不同货架，这时候出库单往往还要拆成多个拣货任务，而不是仓库员手工一件件找货。

1. 出库单先按 SKU 明细生成。
2. 系统根据库存所在库位拆分拣货任务。
3. 拣货完成后进入复核，再进入待发运。
4. 任一步失败都不能直接把订单当成已出库。

代码示例：根据库存位置拆分拣货任务

publicList<PickTask>createPickTasks(OutboundOrderorder){List<StockLocation>locations=stockLocationRepo.findAvailable(order.getSkuId());List<PickTask>tasks=newArrayList<>();intremain=order.getQty();for(StockLocationloc:locations){intpickQty=Math.min(remain,loc.getAvailableQty());tasks.add(newPickTask(order.getId(),loc.getLocationCode(),pickQty));remain-=pickQty;if(remain==0)break;}returntasks;}

核心数据模型我会怎么定

• 建议拆出库单主表、出库明细表、拣货任务表、复核记录表、发运交接表
• 状态至少区分待拣货、拣货中、待复核、待发运、已出库

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

任务生成层

• 按订单、波次或仓区生成出库任务
• 为后续并行作业做准备

拣货执行层

• 记录实际拣货数量和拣货库位
• 部分拣货和缺货都要有状态

复核打包层

• 复核确认商品、数量、包装
• 不通过时要能回退到问题处理流程

发运交接层

• 和物流系统做交接
• 交接完成后才算真正出库完成

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

• 订单系统负责发货意图，仓储负责执行出库
• 物流系统负责运输状态，不直接改仓储账
• 复核失败不应直接改订单状态

监控和审计建议怎么做

• 出库及时率、拣货完成率
• 复核差错率
• 缺货导致的出库失败量
• 交接物流耗时

高频坑位复盘

1. 出库单只有待出库和已出库两个状态

• 中间过程一复杂就全乱了

2. 拣货明细不留库位

• 后续差异和复盘没法做

面试里我会怎么答

如果面试官问出库单怎么设计，我会重点讲任务生成、拣货、复核、发运四段状态链路，并补充部分拣货、缺货、撤单等异常处理，因为出库真正难的是执行过程管理。

结语

出库单系统最核心的，不是减库存，而是把货从库位安全、准确、可追溯地送到物流交接点。

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

• 1 拣货任务建模
• 2 复核打包流程