Amazon 集成最容易被误读成“拣货 done 后同步个平台状态”。sale_amazon 对这件事明显更保守：先确认一个销售行相关的 move 是否一起完成，再检查 carrier 与 tracking 是否满足 Amazon 要求，最后才把 picking 推进到待同步或确认发货链路。
主要参考源码：
enterprise/sale_amazon/models/stock_picking.py
一、为什么先看 sales order line 完整度
_check_sales_order_line_completion() 的设计目标很清楚：同一个 Amazon 销售行的组件不能拆成多个时刻分别确认发货。因为 Amazon 侧把它当一个履约单元，客户也会按整套商品来预期。
所以 Odoo 在 stock 层阻止了“物流上做完一部分就先同步”的冲动。
二、carrier 和 tracking 是平台合规边界
_check_carrier_details_compliance() 会拦截缺失 carrier_id 或 carrier_tracking_ref 的出库。这里不是纯物流字段完整性，而是平台合规：Amazon 要求带着合规承运商和运单号确认 shipment。
三、真正进入同步前，还要标 pending
在 picking write 链里，只有满足“Amazon 订单 + 最终客户目的地 + 尚未 done 同步”的 picking 才会被标成 amazon_sync_status='pending'。之后 _confirm_shipment() 才会进入 Amazon shipment feed 逻辑。
也就是说，平台发货同步至少跨了三层：
- 销售行履约完整度；
- 物流承运商/运单号合规；
- feed 提交与回执状态。
四、为什么这条链对对账也重要
如果你跳过前两层，可能出现：
- Odoo 里部分 move done 了，但 Amazon 侧不接受；
- Amazon 已被确认发货，但 carrier/tracking 口径在 Odoo 中不完整；
- 一条销售行被拆分多次同步，平台侧和内部库存/收入口径都乱掉。
五、结论
Amazon 履约不是“订单进来、发货出去就完了”，而是销售行完整度 -> carrier/tracking 合规 -> shipment feed 回执三段链。只有这样，库存动作、平台状态和后续对账才对得上。
DISCUSSION
评论区