售后场景里最常见的误解，是把 Helpdesk 的 Return 按钮看成 stock.return.picking 的简单入口。其实它前面有一整套“这张工单到底有没有资格退”的判断。
参考入口：
enterprise/helpdesk_stock/tests/test_helpdesk_stock.py
一、能不能退，不看工单本身，看客户是否已有已完成出库
测试 test_ensure_has_partner_picking 点出了核心：退货按钮是否出现，强依赖 has_partner_picking。它看的不是“这张单有没有 sale_order_id”，而是客户或其 commercial partner 是否存在已完成的 outgoing picking。
这就解释了为什么有时没绑销售单也能退、有销售单却仍点不出退货按钮：决定因素是已交付事实，而不是单据引用关系本身。
二、commercial partner 会把子联系人历史并进来
test_helpdesk_ticket_partner_has_picking 和 test_helpdesk_ticket_product_from_parent_company 都说明，Helpdesk 在售后场景下并不只盯着当前联系人，而会沿 commercial_partner_id 聚合交付与可选商品。公司客户下面多个联系人购买过的货，工单换到母公司或兄弟联系人时，仍可能被识别为可售后对象。
三、有 open backorder 也能退已交付部分
test_helpdesk_stock_return 很重要：即使原销售单还有未完成 backorder，已经交出去的那部分商品仍然可以从 Helpdesk 发起 return。系统不是以整张 SO 是否彻底结束来决定可退，而是以“已经完成的数量”来决定。
四、退货完成后会回写工单日志
测试还验证了 return picking 校验后，ticket 消息流里会出现“Return”相关记录。这意味着 Helpdesk 不是旁路发起库存动作，而是把售后执行结果回写到客服工作流里。
五、实战建议
- 排查退货按钮先查 partner/commercial partner 的 done picking。
- 客服按联系人建单时，要理解 commercial partner 聚合会放大可售后范围。
- 有 backorder 的订单别急着判定“不能退”，先区分已交付与未交付数量。
六、结论
Helpdesk 的售后退货真正围绕的是“客户是否已经收到过什么”，而不是“工单上有没有挂某张销售单”。把 delivered quantity、commercial partner 与 backorder 边界看清，Return 才不会用得一头雾水。
DISCUSSION
评论区