Odoo 部分校验后到底该补单还是 Cancel Remaining：backorder 向导、剩余量处置与后续链路讲透

先说结论

Odoo 在部分校验时弹出的 backorder 向导，不是在问你“要不要多生成一张单”这么简单。

它真正让你选择的是：

• 剩余没做完的数量，是否仍然是一个真实存在、以后还要继续执行的库存需求

所以两个按钮的语义完全不同：

• Create Backorder：剩余量还要继续做，只是这次先做了一部分
• No Backorder / Cancel Remaining：剩余量不再继续履约，本次执行到此为止

这不是界面细节，而是业务事实选择。

为什么很多人会把 “Cancel Remaining” 理解错

因为从数量结果看，它常常只是让未完成部分消失。

于是很多用户会觉得：

• 我只是先点过去
• 反正以后再说
• 不想多出一张单而已

但系统层面并不是“临时跳过”。

更准确地说，它在表达：

这次 picking 未完成的剩余需求，不再继续保留为后续履约义务。

一旦你这么理解，就会发现它和“以后补做”是两种完全不同的世界。

主链路应该怎么看

要理解这个分支，通常要连起来看：

• stock.picking.button_validate()
• _pre_action_done_hook()
• _check_backorder()
• stock_backorder_confirmation 向导
• _action_done() 里的 cancel_backorder 上下文

Odoo 的设计重点不是“向导自己把库存都处理完”，而是：

1. Validate 先判断是否存在部分完成
2. 如果存在，就让向导承接“剩余量怎么处理”的决策
3. 决策结果再通过上下文回到标准完成链路

这说明 backorder 向导的职责很纯粹：

它是剩余需求处置决策器，不是另一个库存完成引擎。

为什么部分校验天然需要一个显式分支

现实仓库里，“这次没做完”可能对应两类完全不同情况：

情况 1：只是暂时没做完

比如：

• 这次只发出 8 件，剩余 2 件明天补
• 先收一部分货，尾数晚点到
• 先完成能做的，余量待下一班次继续

这时应该保留补单。

情况 2：剩余量不再做了

比如：

• 客户同意只发这部分
• 现场确认短装后不追发
• 内部转移改计划，余量不再执行

这时才应该 cancel remaining。

也就是说，向导不是在处理技术细节，而是在逼你明确：

• 剩余量究竟是“延期”，还是“终止”。

Create Backorder 真正在保留什么

选择创建补单，本质上是在保留一条未完成需求的延续性。

它意味着：

• 当前已完成部分可以先 done
• 剩余部分不会被抹掉
• 系统会为剩余量保留后续执行载体
• 后面还能继续收、发、转、跟踪

所以 backorder 的重点不是“多一张单”，而是：

未完成义务仍然存在，并且要被正式追踪。

如果你的团队还会继续补货、补发、补收，这通常才是正确语义。

Cancel Remaining 真正在取消什么

很多人误以为它只是“不建 backorder”。

其实它取消的不是“那张额外单据”，而是：

• 原需求里剩余未完成的那一部分执行延续性

换句话说，它表达的是：

• 已完成部分保留
• 未完成部分到这里为止
• 系统不要再为剩余量继续挂一个后续库存动作

所以 cancel remaining 并不是轻量化 backorder，而是：

对剩余履约义务做终止判定。

为什么这个选择会影响后续链路

因为库存动作不是孤立数字，而是会继续影响：

• 下游 move 是否还存在待执行量
• 相关来源单据是否还显示未完成
• 采购 / 销售 / 内部调拨链是否还保留剩余执行空间
• 现场人员之后还能不能继续在系统里“接着做”

如果建 backorder，链路会继续活着。

如果 cancel remaining，链路通常就会在剩余部分这里被剪断。

所以这不是报表层区别，而是执行链层区别。

为什么“先 cancel，后面再补”经常把流程搞坏

因为这等于先告诉系统：

• 剩余量不做了

然后过两天又希望系统当成：

• 剩余量其实还要继续做

这两个表达本身互相冲突。

结果常见表现就是：

• 需要重新建单
• 来源追溯变差
• 销售或采购人员误以为原单已结束
• 现场又靠手工备注解释

本质上，不是 Odoo 麻烦，而是你在用“终止语义”去伪装“延期语义”。

一个最好用的判断法

在点击向导前，先问自己一句：

剩余数量以后还要不要继续按这条业务链履约？

• 如果答案是 要 → 建 backorder
• 如果答案是 不要 → cancel remaining

不要问：

• 哪个按钮更省事
• 哪个不会多出单

那样通常会把业务事实点歪。

三个典型场景

1. 客户允许分批发货

应该建 backorder。

因为剩余量还是有效承诺，只是这次没发完。

2. 收货时供应商确认尾数不补了

更接近 cancel remaining。

因为未到部分已经不再是后续待收事实。

3. 仓库现场先短拣，采购补货后再补发

应该建 backorder。

因为剩余量只是延期，不是终止。

最容易踩的 4 个坑

1. 把 cancel remaining 当成“临时跳过”

它不是暂缓，而是终止剩余履约。

2. 因为不想多一张单就放弃 backorder

结果把未来仍需执行的数量从系统里抹掉。

3. 已经 cancel 后再想沿原链继续补发

通常只会让后续追溯变差。

4. 用户只看 picking 状态，不看上游承诺语义

库存单 done 了，不代表原业务就真的完整结束。

一句话记忆法

Backorder 表达“剩余量以后还要继续做”，Cancel Remaining 表达“剩余量到这里就正式结束”；它们不是单据数量选择，而是剩余履约义务的两种判定。