Odoo 多步仓实战设计：收货、质检、上架、拣货、打包、出货到底该怎么配

先说结论

如果你在 Odoo 里做多步仓设计，最容易犯的错不是字段不会配，而是：

还没想清楚仓库里的每个节点到底是在“承接到货”、还是“继续流转”、还是“真正存货 / 备货 / 出货”。

最实用的理解是：

• 收货区：承接供应商到货
• 质检区：承接“到货后先检验再放行”
• 存储区 / 主库存区：真正长期持货
• 拣货区：面向出库作业，把货从主库存拿到待出库链
• 打包区：把已拣好的货做包裹整理
• 出货区：准备真正发给客户的最后节点

所以多步仓不是“步骤越多越高级”，而是：

只在业务上真的需要分工的地方才拆节点。

否则你会得到一套看起来很精细、实际上让仓库和系统一起变慢的流程。

---

为什么这类问题不能只靠“感觉配一下”

因为 Odoo 自己对多步仓并不是随便拼出来的。

在 addons/stock/models/stock_warehouse.py 里，仓库对象本身就内置了两个核心选择：

• reception_steps
• delivery_steps

官方定义非常明确：

Incoming Shipments

• one_step：Receive and Store
• two_steps：Receive then Store
• three_steps：Receive, Quality Control, then Store

Outgoing Shipments

• ship_only：Deliver
• pick_ship：Pick then Deliver
• pick_pack_ship：Pick, Pack, then Deliver

也就是说，Odoo 官方默认就把多步仓拆成了两条主线：

• 入库线
• 出库线

这其实已经暗示了一个设计原则：

不要一上来就按“仓库总共有多少步”思考，而要分别问入库链和出库链到底要不要拆。

---

Odoo 默认帮你建出来的，不只是几个字段

这点很多人低估了。

选了多步仓之后，Odoo 不是只改一个布尔值，而是会围绕仓库自动生成 / 更新一整套东西：

• location
• picking type
• route
• rule
• 对应的默认来源 / 去向位置

源码里甚至明确给仓库准备了这些位置字段：

• wh_input_stock_loc_id
• wh_qc_stock_loc_id
• wh_output_stock_loc_id
• wh_pack_stock_loc_id
• lot_stock_id

翻成人话就是：

• 输入区
• 质检区
• 出货区
• 打包区
• 主库存区

所以当你在后台勾选 2 步、3 步时，本质上不是“加一个流程标签”，而是：

让仓库从“单节点库存模型”切换成“多节点流转模型”。

---

Odoo 官方默认多步仓，其实就是一套“标准骨架”

源码里 get_rules_dict() 直接给出了各类仓库步数对应的默认路由骨架。

这非常值钱，因为它让我们知道：

• Odoo 官方认为什么场景该用 pull
• 什么场景该用 push
• 哪些节点默认应该存在

入库 1 步：Receive and Store

默认逻辑接近：

• 供应商 → 主库存区

这说明：

如果你收完就能直接入主库存，就不需要单独输入区。

入库 2 步：Receive then Store

默认逻辑接近：

• 供应商 → 主库存区（pull 起链）
• 输入区 → 主库存区（push）

直观理解就是：

• 货先到输入区
• 然后再推进到存储区

入库 3 步：Receive, Quality Control, then Store

默认逻辑接近：

• 供应商 → 主库存区（pull 起链）
• 输入区 → 质检区（push）
• 质检区 → 主库存区（push）

这说明 Odoo 官方对质检仓的理解是：

质检更像“到货后继续流转的中间节点”，而不是独立需求点。

所以它默认更偏 push 逻辑。

---

出库多步逻辑也是同样的思路

出库 1 步：Deliver

默认逻辑接近：

• 主库存区 → 客户

适合最简单的仓。

出库 2 步：Pick then Deliver

默认逻辑接近：

• 主库存区 → 客户（pull 起链）
• 出货区 → 客户（push）

业务上更像：

• 先把货从库存拿到待发货节点
• 然后从出货区正式交付

出库 3 步：Pick, Pack, then Deliver

默认逻辑接近：

• 主库存区 → 客户（pull 起链）
• 打包区 → 出货区（push）
• 出货区 → 客户（push）

也就是说，Odoo 官方默认把：

• 拣货
• 打包
• 发货

看成一条典型的连续作业链。

---

这里最值得学的，不是默认路线本身，而是官方的设计哲学

把源码翻成人话，其实能看出 Odoo 的默认设计哲学很清楚：

1. 入库线更偏“到货后往里推进”

所以输入区、质检区、上架区这些节点，多数时候更偏 push 语义。

2. 出库线更偏“下游先有需求，再往前拉”

所以从客户需求往回追的出库主链，更偏 pull 起链 + 中间 push 流转。

3. 节点不是为了“看起来专业”而拆

而是为了表达真实职责：

• 承接到货
• 质检
• 暂存
• 分拣
• 包装
• 发货

这其实就是多步仓最根本的设计原则。

---

实战里到底什么时候该拆“收货区”

适合拆收货区的情况

• 货到仓后不会立刻算可用库存
• 收货和上架不是同一批人 / 同一时点完成
• 需要先登记、清点、等待处理
• 供应商来货经常集中到门口或月台，再批量入库

这时“输入区 / 收货区”非常有价值，因为它能表达：

• 货已经到了仓
• 但还没真正进入主库存

不适合拆收货区的情况

• 仓很小
• 到货后就是直接入库
• 没有独立收货环节
• 系统里不需要体现“已到未上架”状态

这种情况硬拆一个输入区，只会让流程多一张内部调拨单，没有多少管理价值。

---

什么时候该加“质检区”

这是很多仓最容易过度设计的地方。

应该加质检区的情况

• 入库必须先检验，合格后才能进主库存
• 不合格品可能会退回、隔离或等待判定
• 你希望系统能清楚区分：
• 已到货但待检
• 已检合格可上架
• 异常待处理

这时候质检区是非常合理的。

不该随便加质检区的情况

• 所谓“质检”只是收货时顺手看一眼
• 没有实际的隔离等待过程
• 业务上不需要追踪待检库存

这种情况，质检区往往只会让入库链平白多一跳。

一句话说：

如果质检只是动作，不是节点，就别硬建成 location。

---

“上架”到底要不要单独做一层

这个问题和收货区有点像。

如果你的业务里“上架”只是：

• 收完货后直接放到主库存位

那很多时候不必额外拆一个系统节点。

但如果你真的存在：

• 收货区暂存
• 等待叉车 / 库管批量上架
• 上架前货位还没最终确定
• 上架策略和 putaway rule 很关键

那就应该把“到货”和“上架完成”在系统里分开。

这里很多仓其实不是缺“多一步”，而是缺对 putaway 的正确理解。

因为有时候问题不是要不要多一个 location，而是：

• 货进主库存后该落到哪个具体子货位

这时优先看的往往是 putaway rule，而不是继续盲目增加流程步数。

---

出库时什么时候该拆“拣货区”

适合拆拣货区的情况

• 主库存位和出库作业位分离
• 出库前需要先把货集中到作业区
• 拣货人员和发货 / 打包人员分工明确
• 一张客户单可能要先完成拣货，再统一进入后续操作

这时“拣货区”能帮助你清楚表达：

• 货已经从长期存储位拿出来了
• 但还没真正完成打包 / 发货

不适合拆拣货区的情况

• 仓很小
• 拿起就发，不存在中间作业区
• 拣货与发货本来就是同一动作

这时候多一层 pick 只会制造额外内部流转。

---

打包区什么时候值得单独建

很多仓以为“既然 Odoo 有 3 步发货，那我就应该用”。

不一定。

应该拆打包区的情况

• 打包是独立工位
• 打包后还需要称重、贴单、核包裹
• 一个订单会先全部拣齐，再统一打包
• 你想在系统里明确区分：
• 已拣货
• 已打包
• 待发出

这时 pack 节点很有意义。

不值得拆打包区的情况

• 拣完就直接发
• 没有单独包裹处理工位
• 打包只是出货动作里的一个顺手步骤

这种情况强上 pick_pack_ship，往往只是让员工多点一张内部单。

---

出货区的价值到底是什么

出货区最核心的意义不是“最后一个位置”，而是：

它把“仓内已完成准备”和“真正离仓交付”分成两个状态。

这在下面几类仓里很有价值：

• 发货高峰时需要先把货集中到月台
• 装车和拣货不是同一时刻
• 已备好的货需要等待承运商
• 需要区分“已出库准备完成”和“真正发运”

如果你的仓没有这种需求，出货区也可能不是必须的。

---

最常见的 4 种实战仓型，应该怎么选

方案 1：小仓 / 电商小团队

建议：

• 入库 1 步
• 出库 1 步 或 2 步

适合：

• 人少
• 仓位简单
• 动作连续
• 不追求太细的过程状态

方案 2：有独立收货但无严格质检

建议：

• 入库 2 步
• 出库 1~2 步

适合：

• 货先到月台或收货区
• 然后再批量上架

方案 3：有待检库存的规范仓

建议：

• 入库 3 步
• 出库 2~3 步

适合：

• 质检必须隔离
• 合格后才能进入可用库存

方案 4：较成熟的配送 / 运营仓

建议：

• 入库 2~3 步
• 出库 3 步

适合：

• 拣货、打包、发运分工明确
• 波次、月台、包裹处理都比较成熟

---

一套非常实用的设计顺序

如果你要给客户设计多步仓，我建议按这个顺序问，而不是先去点 Odoo 选项。

问题 1：到货后会不会立刻进主库存？

• 会 → 入库可能 1 步
• 不会 → 至少考虑 2 步

问题 2：质检是不是独立等待节点？

• 是 → 考虑 3 步入库
• 否 → 别为了“专业感”硬加 QC 区

问题 3：出库前有没有独立拣货作业区？

• 有 → 至少考虑 2 步出库
• 没有 → 1 步可能就够

问题 4：打包是不是独立工位 / 独立状态？

• 是 → 可以考虑 3 步出库
• 否 → 不必强拆 pack

问题 5：你是想追踪过程状态，还是只是想“流程看起来完整”？

如果只是后者，通常就该减步骤。

---

实战里最容易踩的 8 个坑

1. 觉得多步仓一定比一步仓高级

错。复杂度和管理价值不总是正相关。

2. 把“动作”误建成“节点”

比如收货时顺手看一眼，也硬建一个质检区。

3. 忽略员工实际操作路径

系统步骤如果和现场作业不一致，最后只会逼人走形式。

4. 把所有中间状态都想进系统

最后单据很多，但现场根本不配合维护。

5. 出库链拆太细，入库链却不拆

或者反过来。要分别看入库、出库，不要一刀切。

6. 把 putaway 问题误当成流程步数问题

有些问题该靠上架规则解决，不该靠多建 location 解决。

7. 只看 Odoo 能不能配，不看客户仓库是不是这样干

系统能配很多，不代表业务值得配。

8. 一上来就用最复杂方案，后面再做减法

通常很难推回去。更稳的是先用最小可行流程，再按真实痛点加步骤。

---

一句话记忆法

把多步仓设计记成一句话：

不是先问 Odoo 能拆几步，而是先问每个节点是不是在业务上真的承担了独立职责；只有职责独立，才值得在系统里拆成一步。

理解这一句之后，你再做收货、质检、上架、拣货、打包、出货设计，就不会只是在“套模板”，而是在真正用 Odoo 复刻仓库的业务结构。