[FIX] sale_mrp: decrease kit quantity after the delivery
When decreasing the SOL qty, if the SOL product is a kit and if the kit
has already been delivered+returned, an additional and useless return
will be created
To reproduce the issue:
1. Create two products consumable products P_kit, P_compo
2. Create a bill of materials:
- Product: P_kit
- Type: Kit
- Components: 1 x P_compo
3. Create and confirm a sale order SO with 4 x P_kit
4. Process the delivery
5. Process a return with 1 x P_compo
6. Edit SO:
- Quantity: 3 (instead of 4)
Error: once the SO is saved, a second (and useless) return will be
created
When updating the SOL quantity, we try to adapt the pickings. To do so,
we first get the quantity that is currently in delivery, then we compute
the difference between that quantity and the new SOL qty. Eventually, we
create a procurement based on that difference.
https://github.com/odoo/odoo/blob/e11dfa341baf82fedee753502aef5ef2972f75cb/addons/sale_stock/models/sale_order.py#L553
https://github.com/odoo/odoo/blob/e11dfa341baf82fedee753502aef5ef2972f75cb/addons/sale_stock/models/sale_order.py#L573-L578
In case of a kit, the "in delivery" quantity is too simply computed: we
return the old SOL qty (see diff). So, in the above case, we have:
- In delivery : 4
- New sol qty : 3
- Difference : -1
That's the reason why a new return is created, to fulfill the
difference.
We could apply a smarter computation of the "in delivery" qty thanks to
a mix between the computation of the delivered quantity of a kit:
https://github.com/odoo/odoo/blob/e85de8f2d342ac1e69d8eb4020dbb2d4c69ad90b/addons/sale_mrp/models/sale.py#L111-L118
and the way we compute the "in delivery" quantity for a non-kit product:
https://github.com/odoo/odoo/blob/e11dfa341baf82fedee753502aef5ef2972f75cb/addons/sale_stock/models/sale_order.py#L501-L504
https://github.com/odoo/odoo/blob/e11dfa341baf82fedee753502aef5ef2972f75cb/addons/sale_stock/models/sale_order.py#L511-L515
Note: if the kit has several components, and if the user does not return
an entire kit, a similar issue will occur. That's the reason why this
commit solution is smarter than the current code but is not the
smartest. For such a use case, we would need a bigger
solution/refactoring (handle the components one by one instead of the
kit for the quantities and the procurements)
OPW-2917209
closes odoo/odoo#98899
X-original-commit: 9649e1031df60c5ba60424e9fbcf7187f6783b5c
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Adrien Widart
4ee5df7660