很多售后团队把退款当成客服动作，但在 Odoo 企业版里，Helpdesk 的 credit note 更像库存事实与财务事实之间的受控桥梁：先退了多少、退的是哪个产品、挂在哪些原始发票上，都会影响最后的退款结果。
参考入口：
enterprise/helpdesk_stock_account/tests/test_helpdesk_stock_account.py
一、退款数量默认跟着“已退数量”走，不跟着原销售数量走
test_refund_after_return_single_so 和 test_refund_after_return_multi_so 都说明：生成 credit note 时，系统不会把原发票整张冲回，而是根据已经完成的 return quantity 来算退款数量。多张销售单时，也会分别按各自退货数量拆开。
二、可以只退某个产品，而不是整张发票全退
test_refund_only_one_product 里，refund wizard 传入 product_id 后，生成的 credit note 只保留目标产品行。对客服来说，这很关键：售后争议可能只涉及订单中的一个 SKU，没必要把其他正常交付项一起冲掉。
三、首付款场景不会被“退货数量”粗暴重写
test_refund_after_return_down_payment 暴露了一个非常容易误会的边界：下游 credit note 里，商品行数量会按退货逻辑调整，但 down payment line 不应被按相同规则重算。也就是说，退款向导会区分“可回滚的货物行”和“首付款这类财务占位行”。
四、Helpdesk ticket 不是会计对象，但会成为退款上下文
测试创建 reversal wizard 时传入 helpdesk_ticket_id，说明 ticket 在这里承担的是售后上下文和责任归集，而不是替代发票或库存单本身。真正的会计动作依然发生在 account.move.reversal / credit note 上。
五、实战建议
- 先完成退货，再谈退款，避免 credit note 和仓库实物状态脱节。
- 多产品订单一定要明确退款粒度，必要时用 product-scoped refund。
- 首付款、服务费等特殊行要单独核对，不要默认和货物数量同步回滚。
六、结论
Helpdesk 退款不是“客服点一下财务就冲回去”，而是基于退货事实、目标产品和原始发票结构进行的受控重算。售后与财务要对上，关键就在这些边界。
DISCUSSION
评论区