* If the sale order includes MTO and MTS products and you try to return the delivery, only the MTS products are proposed. You don't get the error messages, but some lines are lacking in the form.
I have dug into this and the problem is that stock_move has a pair of attributes move_history_ids and move_history_ids2 which are used for two completely different things:
* for MTO products, the purchase_order will handle the MTO procurement by creating a stock_move from the supplier location to the stock location, and this move will have move_dest_id set to the stock_move from stock location to warehouse out location (methods _prepare_order_line_move and _create_pickings) . When the move is done (method action_done in stock/stock.py), any move refered to by move_dest_id is added to move_history_ids. As this is a m2m relation, the purchase move is also refered to by move_history_ids2 of the original stock->out move
* when handling shipping returns, the same move_history_ids/move_history_ids2 attributes are used to record partial returns for a delivery of a product. If the user shipped 5 items, and the customer returns 2 of them, the stock move for the return will be linked to the outgoing move using the move_history_ids relation. The wizard checks that the number of returned items is lower than the number of shipped items (by checking the outgoing move's move_history_ids2) and only proposes to create return moves for the remaining quantity.
Taken in isolation, both behaviours are ok. But when the returned good was MTO, the outgoing move already has a move_history_ids2 relation refering to the provider -> stock move, generally with exactly the shipped quantity. The return wizard gets confused and "thinks" that this refers to returned goods, and will refuse to return more than the shipped quantity.
We need to be able to tell these different move apart, for example by using different relations for purchase and returns or by flagging the moves as returns or purchases. Maybe the second option is already available indirectly by looking at the picking for example, in which case the return wizard needs to use this information.
Additional information on this:
* If the sale order includes MTO and MTS products and you try to return the delivery, only the MTS products are proposed. You don't get the error messages, but some lines are lacking in the form.
I have dug into this and the problem is that stock_move has a pair of attributes move_history_ids and move_history_ids2 which are used for two completely different things:
* for MTO products, the purchase_order will handle the MTO procurement by creating a stock_move from the supplier location to the stock location, and this move will have move_dest_id set to the stock_move from stock location to warehouse out location (methods _prepare_ order_line_ move and _create_pickings) . When the move is done (method action_done in stock/stock.py), any move refered to by move_dest_id is added to move_history_ids. As this is a m2m relation, the purchase move is also refered to by move_history_ids2 of the original stock->out move
* when handling shipping returns, the same move_history_ ids/move_ history_ ids2 attributes are used to record partial returns for a delivery of a product. If the user shipped 5 items, and the customer returns 2 of them, the stock move for the return will be linked to the outgoing move using the move_history_ids relation. The wizard checks that the number of returned items is lower than the number of shipped items (by checking the outgoing move's move_history_ids2) and only proposes to create return moves for the remaining quantity.
Taken in isolation, both behaviours are ok. But when the returned good was MTO, the outgoing move already has a move_history_ids2 relation refering to the provider -> stock move, generally with exactly the shipped quantity. The return wizard gets confused and "thinks" that this refers to returned goods, and will refuse to return more than the shipped quantity.
We need to be able to tell these different move apart, for example by using different relations for purchase and returns or by flagging the moves as returns or purchases. Maybe the second option is already available indirectly by looking at the picking for example, in which case the return wizard needs to use this information.