Cannot return outgoing moves if there are chained moves (including MTO products, products in a lot, settings with chained warehouse locations...)

Hello,

This is not a low priority bug it block all the logistical process.
It should be tagged as high.

Regards

Nicolas

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.

Additional information:

products in MTO are not the only one concerned by this. Any stock.move with the move_dest_id column filled in will trigger the filling of move_history_ids when the action_done method is called. This means that if there are any chained moves in the processing of a shippment, it will not be possible to process returns in the final outgoing move.

Examples of configurations generating this situation:

* if a stock.location has a chained location with a chaining type different from "automatic"
* if the stock_location addon is used to configure push or pull flows
* mrp also generates moves with move_dest_id set

I'm changing the title of the bug report to reflect this.

Hello FGI, Nicolas and Alexandre,

Issue has been fixed in https://code.launchpad.net/~openerp-dev/openobject-addons/6.1-opw-575526-pso with rev-no: 6836

It will be merged soon with Stable 6.1.

Thank you for reporting and contribution,
Priyesh

I will also fix this issue in 6.0 and will let you know the updates on it, soon.

Thanks,
Priyesh

Hello FGI, Nicolas and Alexandre,

Issue of preventing user to add more products than available to return has been fixed in https://code.launchpad.net/~openerp-dev/openobject-addons/6.0-opw-575526-pso with rev-no: 5253 for stable 6.0.

Issue of return of only one product is possible is not producible in 6.0 as there is constraint defined for picking name in stable 6.0.

It will be available soon in Stable 6.0

Thank you for reporting,
Priyesh

This has been fixed in OpenERP 6.1 as of revision [1]. It will be merged in trunk along with the next batch of forward-port between 6.1 and trunk. The fix for 6.0 is being reviewed as well.

[1] rev 6839 rev-id: <email address hidden>

When will this be pushed into the official 6.0 and 6.1 branches?

This patch is released in official 6.1 branch, state should be changed