Odoo Dropship 和分包采购为什么看起来都像“向供应商买”，却完全不是一回事

先说结论

在 Odoo 里，Dropship 和 Subcontracting 都会让你看到采购动作，所以很多人会自然得出一个错误结论：

• 反正都是向供应商买东西
• 只是后面去向不同

这理解太浅了。

更准确地说：

• Dropship 解决的是“供应商直接替你向客户履约”
• Subcontracting 解决的是“供应商替你完成某道制造/装配工作，你仍然对生产语义负责”

两者都经过采购，不代表是同一类采购。

它们在源码里的区别至少体现在：

• 目标位置和拣货类型不同
• 采购需求为什么产生不同
• 提前期叠加逻辑不同
• 后续追踪和责任边界不同

所以如果把这两条路线混着理解，项目实施几乎一定会在日期、库存责任、交付判断上踩坑。

这篇为什么不是已有 Dropship 或分包文章的重复

站里已经有：

• 一篇讲标准 Dropship 路线和单据链
• 一篇讲分包制造、补料和供应商收货语义

但实际实施里，客户最容易问的不是“单条路线怎么跑”，而是：

它们为什么都像采购，却不能按同一种脑回路理解？

这篇专门做横向边界拆分：

• 什么时候你应该想到 Dropship
• 什么时候应该想到 Subcontracting
• 为什么两者在采购侧表现相似，但业务责任完全不同

第一层差异：目标位置语义完全不同

在 /home/ubuntu/odoo-temp/addons/stock_dropshipping/models/stock.py 中，官方给 dropship 增加了专门的 picking_type.code = 'dropship'。

而且这个拣货类型的默认位置非常鲜明：

• 来源位置：supplier
• 目标位置：customer

这相当于直接在库存语义上宣布：

这批货根本不进你的仓，它是供应商直接发给客户。

所以 dropship 虽然经过采购，但它的物流结果更像“采购驱动的客户履约”。

分包采购的采购语义为什么不一样

在 /home/ubuntu/odoo-temp/addons/mrp_subcontracting_purchase/models/stock_rule.py 中，官方扩展的是 stock.rule._get_lead_days()，而不是去增加一个像 dropship 那样的专用客户交付拣货类型。

它关心的重点是：

• 这个供应商是不是某个分包 BOM 的 subcontractor
• 分包提前期要按什么逻辑叠加

源码注释写得很明白：

Subcontracting delay = max(Vendor lead time, Manufacturing lead time + Days To Prepare MO) + Days to Purchase

这句直接暴露了两者在本质上的差异：

• Dropship 在意的是“供应商如何直达客户”
• Subcontracting 在意的是“供应商替你完成生产环节，需要把制造准备时间一起算进去”

所以分包采购不是物流捷径，而是生产责任外包。

第二层差异：采购为什么会被触发，答案也不同

Dropship

dropship 的采购，通常是为某条销售承诺服务。

在 stock_dropshipping 里，官方还专门避免不同 sale_line_id 的 procurement 随便合并，就是为了保证交付数量计算正确。

这说明它的采购动作从一开始就带有非常强的销售履约属性。

Subcontracting

分包采购的采购动作虽然也是 buy，但它要满足的是制造侧需求。

源码会先找：

• 当前产品有没有对应的 subcontract BOM
• 当前供应商是不是该 BOM 的 subcontractor

也就是说，它不是“卖出去所以去买”，而是：

• 为了完成制造承诺，所以向分包商发起采购型补给

这两条需求链的源头完全不同。

第三层差异：提前期为什么不能按同一套公式理解

很多实施人员最容易在这里出错。

Dropship 的日期脑回路

你主要要想清楚：

• 供应商什么时候能把货直送给客户
• 销售行的履约日期能否撑住

这条链的时间重点更偏：

• 供应商交付客户
• 销售履约承诺

Subcontracting 的日期脑回路

源码里直接把两层时间叠到一起：

• Vendor Lead Time
• Manufacturing Lead Time
• Days to Prepare MO
• Days to Purchase

而且不是简单相加，而是先比较：

• vendor delay
• manufacturing delay + dtpmo

取两者较大，再继续叠采购准备时间。

这背后的业务逻辑很成熟：

• 供应商不是只卖你一个成品
• 他是在某个制造准备框架里替你完成加工

所以只拿普通采购 lead time 去看分包，结论往往会偏差很大。

第四层差异：库存责任边界不同

Dropship

货从 supplier 去 customer。

因此你最该关心的是：

• 客户是否收到了货
• 销售是否可视为已履约
• 采购与销售的行级关联是否清楚

Subcontracting

虽然也经过供应商，但系统语义仍然把它放在生产责任链里。

你更该关心的是：

• 组件如何供应给分包商
• 分包 BOM 是否匹配当前供应商
• 产出物什么时候视为完成制造

所以它不是“采购替代仓配”，而是“制造替代内部工序”。

业务上最容易误解的 5 个点

1. 以为两者都是 Buy route，所以管理逻辑也该一样

Buy 只是采购动作的入口，不代表业务语义一致。

2. 以为 dropship 和分包都不进自有仓，所以差不多

不进仓只是表象。一个是客户履约，一个是制造外包。

3. 以为分包提前期只看供应商 delay

源码明确还要看生产提前期和准备 MO 的时间。

4. 以为 dropship 采购可以随便合并

不同销售行的交付归属会因此失真。

5. 以为分包采购和普通采购只差一个 BOM

实际上它改变的是整条责任链：从采购逻辑进入制造语义。

开发和实施时最该注意什么

1. 设计路线时，先问“这批货到底在替谁履约”

• 替客户履约：优先想 dropship
• 替制造履约：优先想 subcontracting

这比先盯“要不要采购”更重要。

2. 定制日期逻辑时，不要把 dropship 和 subcontracting 共用一套 lead time 公式

两者在源码里就不是同一套模型。

3. 分包项目一定要验证 BOM 与 subcontractor 匹配

如果只看供应商设置，不看 BOM 命中，很多日期和补货结果都会看起来“不合理”。

4. dropship 项目要特别关注销售行追踪

你如果把销售侧追踪抹平，后面 delivered quantity、客户履约和售后判断都会变脆弱。

一句话记忆法

Dropship 是“供应商替你向客户发货”，Subcontracting 是“供应商替你完成制造环节”；它们都经过采购，但责任边界根本不是一回事。