[6.1, 7.0, trunk] return product messed up when output location manually chained to customer location

[Alexandre Fayolle - camptocamp]

If you setup you warehouse with the Output location manually chained to the customer location, then returning goods is messed up.

A Sale Order will generate a move from Stock to Output, and the chained location setup will generate a move from Output to Customer. When the customer returns the good for any reason, the user will use the stock return picking wizard from the OUT picking. This generates an incoming move from Customer to Output, and the chained location setup generates in turn an outgoing move from Output to Customer (and when the incoming picking is processed, the outgoing move gets available...)

This is wrong, as it totally messes up the logistics of the company, and it is a big problem for an e-commerce company handling over 100 SO per day, with 5% return rate, as it requires a lot of manual processing. In my opinion, there should never be an *incoming* move to the *Output* location of the warehouse. This would solve the problem.

There should be a setting on the shop specifying which location is to be used for returns, or the stock return picking wizard should provide a way of specifying a location on a case by case basis.

[Alexandre Fayolle - camptocamp (alexandre-fayolle-c2c)]

OPW opened for this ticket

[Alexandre Fayolle - camptocamp (alexandre-fayolle-c2c)]

For those affected by the bug, here is a patch for 6.1 that works around it.

=== modified file 'stock/wizard/stock_return_picking.py'
--- stock/wizard/stock_return_picking.py 2012-08-10 13:41:53 +0000
+++ stock/wizard/stock_return_picking.py 2012-11-27 15:17:10 +0000
@@ -188,6 +188,9 @@

             if returned_qty != new_qty:
                 set_invoice_state_to_none = False
+ current_move = move
+ if current_move.move_history_ids2:
+ current_move = current_move.move_history_ids2[0]
             if new_qty:
                 returned_lines += 1
                 new_move=move_obj.copy(cr, uid, move.id, {
@@ -195,7 +198,7 @@
                     'product_uos_qty': uom_obj._compute_qty(cr, uid, move.product_uom.id,
                         new_qty, move.product_uos.id),
                     'picking_id':new_picking, 'state':'draft',
- 'location_id':new_location, 'location_dest_id':move.location_id.id,
+ 'location_id':new_location, 'location_dest_id':current_move.location_id.id,
                     'date':date_cur,})
                 move_obj.write(cr, uid, [move.id], {'move_history_ids2':[(4,new_move)]})
         if not returned_lines:

[Alexandre Fayolle - camptocamp (alexandre-fayolle-c2c)]

Improved fix for 6.1 in the attached branch

[Alexandre Fayolle - camptocamp (alexandre-fayolle-c2c)]

Still exists in 7.0

[Yannick Vaucher @ Camptocamp (yvaucher-c2c)]

Confirmed in trunk as well

[Yannick Vaucher @ Camptocamp (yvaucher-c2c)]

The fix won't work with a duplication of a picking.out as picking's move will have Output location as oldest ancestor location. Thus the fix won't be able to descend on a valid location.

A patch is attached which ensure we use Stock location of warhouse if location found in history is an Output location