Odoo 采购收货完成时，库存、收货数量和采购单状态是怎么回写的？
很多人以为采购单收货“点一下 Validate 就结束了”，其实背后是一整条从采购单、收货单、stock move 到 qty_received 回写的联动链。本文把这条链拆开讲清。
TOPIC PICKS
这个专题的推荐入口
这个专题里读者更常先点开的文章
优先看新补的内容
可以顺着继续读的相邻方向
Odoo Blanket Order 的数量为什么不会自动“扣合同余额”：释放数量、已下单统计与 supplierinfo 回写边界讲透
很多人把 Odoo Blanket Order 想成“合同总量逐笔释放、每下一个 PO 就自动扣减余额”。源码并不是这么严。它会统计已下单数量，会把价格回写到 supplierinfo，也会在协议结束时清理这些数据，但不会把 Blanket Order 做成强制余额控制引擎。
Odoo 招标为什么不会自动帮你“选中标人”：比价行、替代供应商与授标边界讲透
很多团队以为 Odoo 既然能比较 Call for Tenders 的替代 RFQ，就应该顺手帮你自动选出中标供应商。源码其实不是这么设计的。它负责组织候选单、按产品比较总价/单价/交期，并在确认时把“其他替代单怎么办”推回给采购员。
Odoo 采购为什么不能只在 Dropship 和分包之间二选一：Buy to Stock、Dropship、Subcontracting 三路线分流讲透
站里已经讲过 Dropship 和分包采购不是一回事，但实际实施里更常见的误判是：只要不是标准入库，就在 Dropship 和分包里硬选一个。真正应该一起比较的，是 Buy to Stock、Dropship 和 Subcontracting 三条采购路线，因为它们分别对应补库存、直发履约和外包生产三种完全不同的责任链。
Odoo 供应商价目为什么在多币种下更容易看起来“选错”：日期区间、最小起订量与币种排序链讲透
站里已经讲过 Odoo 会先按日期和最小起订量过滤 supplierinfo，但很多现场真正困惑的是：同一家供应商挂了多币种价目后，系统到底按什么口径比较？答案是先过滤资格，再把折后价统一换算到公司币种排序，而采购单币种又往往来自供应商采购币种属性。
Odoo 采购收货控制为什么经常被误解成“开票开关”：Bill Control Policy、收货数量与 3-Way Matching 边界讲透
采购现场最常见的误会之一，就是把 Bill Control Policy 和 3-Way Matching 当成同一件事。其实前者决定“采购行什么时候变得可开票”，后者决定“账单在付款审批上是否还要看收货事实”。再叠加服务、耗材、库存型产品不同的 qty_received 计算方式，误判就更多了。
Odoo Call for Tenders 和 Blanket Order 为什么不能只按“长期/短期”来分：授标、替代 PO 与协议落地边界讲透
很多人把 Call for Tenders 和 Blanket Order 的区别理解成“一个比价、一个长期采购”。这当然没错，但还不够。真正决定两者完全不是一套玩法的，是替代 PO 分组、比较行、确认时的授标提醒，以及 Blanket Order 把协议条件注入 supplierinfo 的方式。