Odoo Cluster Picking 为什么不是“高级版 Batch”：波次、拣货车格口与一次一人多单拣货边界讲透

先说结论

在 Odoo 语境里，batch transfer、wave、cluster picking 不是同义词。

最实用的区分方式是：

• batch：把一组可兼容 picking 装进同一个执行容器
• wave：把一批需求按同一放货节奏一起释放到仓库现场
• cluster：让同一个拣货员在一次路径里，同时为多张订单、多个格口完成拣货分拣

所以 cluster picking 不是“更复杂的 batch”。

它真正增加的是：

同一次拣货路径里，系统要持续知道“这一件货最终应该落进哪一个订单格口”。

这就是为什么做 cluster 时，重点不再只是把几张单放到一起，而是车、箱、格口、订单映射和现场防混单。

为什么很多团队会把 batch 和 cluster 混为一谈

因为从界面观感上看，它们都像：

• 一次处理多张单
• 尽量少走路
• 集中完成校验

但如果只看这些表面特征，就会忽略一个关键差别：

• batch 关心的是“哪些单可以一起执行”
• cluster 关心的是“同一趟执行里，每件货最后落进哪个格口”

也就是说，batch 解决的是聚合执行，cluster 解决的是聚合执行下的细粒度分单。

前者偏调度，后者偏现场作业控制。

从仓库现场看三者的真正差别

假设你有 12 张小电商订单，都从同一货架区出货。

只用普通单张 picking

结果通常是：

• 一人拿一张单走一趟
• 路径重复
• 走路时间高

用 batch transfer

结果会变成：

• 几张兼容单据被合成同一作业容器
• 可以一起分配、一起执行、一起验证
• 但现场仍可能需要拣货员自己额外判断“每件货放哪单”

用 wave

重点则变成：

• 某个时段要一起放出的订单被统一释放
• 仓库按波次组织人力和设备
• 它更像作业编排，而不是最终的分单工具

用 cluster

系统真正要支持的是：

• 一辆拣货车上有多个 bin / tote / compartment
• 每个格口对应一张订单或一类目的单
• 拣货员沿路径一次取货
• 取到每件货时，需要明确落到哪个格口

这就是 cluster 的核心增量。

为什么 cluster picking 的难点不在“合单”，而在“防混单”

如果只是把多张单合在一起，batch 已经够用了。

cluster picking 真正困难的地方是：

• 同一个 SKU 可能同时属于多张订单
• 同一货位一次会拿出多个订单所需数量
• 现场人员必须知道哪几件分到 A 格口，哪几件分到 B 格口
• 后续打包时还要能从格口反推到订单

所以 cluster 关注的是一个比 batch 更细的问题：

聚合拣货之后，订单边界怎么保持不丢。

如果这层做不好，效率虽然提升，错发率也会一起升。

源码和模型层应该抓什么

研究 Odoo 官方库存源码时，cluster 相关能力虽然常常通过扩展模块、扫描流程或仓库实施方案落地，但你仍然可以围绕这些核心对象理解它：

• stock.picking
• stock.move
• stock.move.line
• stock.picking.batch
• package / package level 相关对象
• barcode / scanner 交互中的 line confirmation 逻辑

要点不是“有没有一个名叫 cluster 的神奇模型”，而是：

• 多单聚合由谁组织
• 拣货粒度落在哪一层
• 目的格口如何被表达
• 现场扫描时如何防止把货落错格

在 Odoo 里，真正承载现场事实的通常还是 stock.move.line，因为它最接近：

• 从哪拣
• 拣了多少
• 属于哪张 picking
• 落到哪个包裹 / 结果包裹 / 容器

cluster 能否实现，核心不是“多一个批次对象”，而是move line 能否稳定表达每笔现场分拨事实。

为什么 cart/bin split 是 cluster 的灵魂

cluster picking 一定会遇到一个问题：

• 一次从货架拿了 8 件同款商品
• 其中 3 件给订单 A
• 2 件给订单 B
• 3 件给订单 C

这时系统必须帮助现场回答：

1. 这 8 件是一次拣的，还是三次拣的？
2. 每张订单实际分到多少？
3. 每份货落进了哪一个 bin？
4. 如果现场扫错 bin，系统能不能阻止？

这就是 cart/bin split 的价值。

它表达的不是简单包裹，而是：

同一次拣货动作之后，多张订单在同一拣货车上的临时归属关系。

没有这层映射，cluster 很快就会退化成“人工记忆版 batch”。

为什么 wave 常常在 cluster 前面，而不是替代 cluster

很多实施项目里，正确顺序不是“batch 升级成 wave，再升级成 cluster”，而是：

• wave 负责决定这一波哪些单现在放
• batch / cluster 负责决定放出来以后如何执行

也就是说：

• wave 偏计划释放
• cluster 偏现场路径与分单

你可以把它们理解成两个维度：

• 什么时候干：wave
• 怎么一趟干多单且不混：cluster

所以 wave 并不替代 cluster。

为什么 cluster picking 特别依赖条码与扫描确认

单张 picking 时，人的心智负担还不算大。

cluster picking 时，人的心智负担会急剧上升：

• 多张订单一起拣
• 同 SKU 反复出现
• 还要记住格口映射

这时如果没有扫码辅助，靠人工记忆很容易出错。

因此 cluster 流程最理想的系统支持通常包括：

• 扫货位
• 扫商品
• 扫目标 bin / tote
• 必要时扫订单标签

这样系统才能把“路径聚合”和“订单分流”同时守住。

为什么 package 和 cluster 不能完全画等号

很多人一看到格口、tote、箱子，就直接把 cluster 等同于 package。

这会带来误判。

因为 package 更偏：

• 货现在装在哪个物理容器里
• 之后如何搬运、打包、出库

而 cluster bin 往往还是执行中的临时分单容器。

它们当然可以重叠，但语义并不完全相同：

• package 偏物流承载
• cluster bin 偏现场分单控制

一个 bin 最后可能变成 package，也可能只是中间作业格口。

实施时最容易踩的 5 个坑

1. 把 batch 当成 cluster 用

结果是单据一起拣了，但现场分单完全靠人记。

2. 只追求少走路，不控制落格口

效率看似高，错发率却会上升。

3. 同一格口复用规则不清

容易导致上一单残留、下一单混入。

4. 没把订单标签和 bin 编码做成可扫描对象

现场执行只能靠肉眼识别，稳定性差很多。

5. 把 wave 配置成“巨波次”

一次释放太多单，会让 cluster 车位数量、人员认知和打包节奏全部失控。

一个实用判断法：什么时候该上 cluster

如果你的场景同时满足下面几项，就很适合 cluster：

• 单张订单行数少，但订单数多
• SKU 重复率高
• 仓库路径成本高于打包成本
• 现场已有推车、箱格、tote 等容器条件
• 团队已经使用条码流程

反过来，如果：

• 每单都很大
• 定制化拣货多
• 包装规则差异极大
• 现场无法保证扫描纪律

那 cluster 可能反而会让流程更乱。

一句话记忆法

batch 解决“哪些单一起干”，wave 解决“什么时候一起放”，cluster 解决“一趟一起拣时，每件货究竟落进哪个订单格口”。

理解这三层分工，你就不会再把 cluster picking 误解成“batch transfer 的豪华版”。