Odoo 仓间调拨为什么不是“库存从 A 仓瞬移到 B 仓”：transit location、internal transfer 与补货路由讲透

很多实施项目在讲仓间调拨时，都会先画一个很直观的流程图：

• 仓库 A 减库存；
• 仓库 B 加库存；
• 完成。

这个图不算错，但它隐去了 Odoo 最重要的设计：

系统不想把仓间流转建模成“两个仓位数值瞬时改写”，而是想把它建模成一段真实在途链路。

这就是为什么源码里会反复出现：

• transit location
• internal_transit_location_id
• inter-warehouse resupply route
• 一串 pull rule

Odoo 想保留的，是“货已经离开源仓，但还没到目标仓”的中间状态。

一句话先讲透

在 Odoo 里，仓间调拨不是一个抽象的库存平移，而是通常要拆成：

1. 源仓向 transit 发出；
2. transit 再向目标仓接收；
3. 两端通过 route / rule 串成一条补货链。

所以 transit location 的价值，不是多一个中间库位，而是让在途事实有了明确落点。

为什么公司上要有 internal_transit_location_id

res.company 会维护 internal_transit_location_id，并且还能自动创建缺失的 transit location。

这说明 Odoo 认为同公司内部仓间流转不是偶发需求，而是应该有默认基础设施的标准能力。

只要这层默认 transit 存在，后续：

• 仓间补货路由；
• 内部调拨链路；
• 在途库存识别；

都能落到一个明确节点，而不是让 move 直接从 A 跳到 B。

同公司和跨公司为什么要选不同 transit

stock.warehouse.create_resupply_routes() 里有个关键判断：

• 如果 supplier warehouse 和当前仓库属于同一公司，就用 internal_transit_location_id；
• 如果不是同一公司，就尝试用 stock_location_inter_company 这类 external transit。

这说明 Odoo 很清楚两类在途不是一回事：

• 同公司仓间在途，更像内部物流；
• 跨公司在途，还带着主体边界与 partner 语义。

所以 transit 并不是单一技术点，而是业务边界的承载体。

resupply route 为什么不是“一条规则走到底”

同一个 create_resupply_routes() 里，Odoo 并不是简单建一条 A→B 规则，而是可能拆成多段 pull rule：

• 供应仓 Output → Transit
• 必要时 Stock → Output
• Transit → 目标仓 Stock

如果供应仓是多步出库，还会把 Output 作为独立中间环节；如果是 ship only，甚至还要额外生成 MTO 规则。

这说明 Odoo 在仓间调拨上优先保留的是仓库操作现实：

• 有的仓先拣再发；
• 有的仓直接从 stock 发出；
• 有的补货需求来自 orderpoint / procurement；
• 都不能被粗暴压成一条“库存平移”。

transit location 为什么会影响可用量与在途理解

在 stock 里，transit usage 并不是纯展示类型。很多逻辑明确把 internal 与 transit 放在一起看，例如：

• 循环盘点 / quant 盘点域；
• lot / quant 某些库存统计；
• move / quant 的可用位置边界。

这意味着 transit 不是“仓外黑洞”，而是系统承认的库存存在状态。

只不过它表达的是：

• 货已经不在源仓可拣区；
• 也还没正式进入目标仓可执行区。

为什么仓间调拨调试不能只看一张 picking

很多团队排查失败调拨时，只打开目标仓入库单，然后说“看起来没生成完整”。

但 inter-warehouse flow 真正应按链看：

• 上游出库 picking 是否已建立；
• transit 段 move 是否存在；
• 下游入库 picking 是否已挂接；
• route / rule 是否来自正确 resupply warehouse 组合；
• supplier warehouse 的 delivery steps 是否影响了额外节点。

因为这从来不是单单据问题，而是 route 生成问题。

新手最容易误解的 4 件事

1. 以为 transit 只是报表中间态

其实它是 route 设计的一部分，不是 UI 装饰。

2. 以为仓间调拨默认一定直接 A 到 B

源码里恰恰优先保留在途段。

3. 以为同公司与跨公司只差 company 字段

它们可能连 transit location 类型都不同。

4. 以为补货路由失败只要重建 picking

很多时候要回到 warehouse route 生成逻辑看。

推荐排查顺序

如果问题是“为什么仓间调拨不对劲”，建议按这个顺序查：

1. 公司是否已有正确的 internal_transit_location_id；
2. 两个 warehouse 是否正确建立 resupply 关系；
3. route 里是否生成了 Output→Transit、Transit→Stock 等规则；
4. 供应仓的 delivery steps 是 ship_only 还是多步出库；
5. 当前异常发生在源仓、transit，还是目标仓这一段。

最后的结论

Odoo 对仓间调拨最成熟的地方，在于它拒绝把仓间流转简化成库存瞬移。

它更愿意明确表达：

• 货从哪里发出；
• 货在哪个 transit 节点上路；
• 货何时真正进入目标仓；
• 这一切如何由 resupply route 自动串联。

所以只要你把 transit 看成“真实在途库存的锚点”，很多 inter-warehouse flow 的设计就会一下变清楚。