openerp-india team mailing list archive

["Alexandre Fayolle @ camptocamp" <alexandre.fayolle@xxxxxxxxxxxxxx>]

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.

-- 
You received this bug notification because you are a member of OpenERP
Indian Team, which is subscribed to OpenERP Addons.
https://bugs.launchpad.net/bugs/944025

Title:
  Bug for return products (of a lot)

Status in OpenERP Addons (modules):
  Confirmed

Bug description:
  Return products (of a lot)

  "Warning ! 
  There are no products to return (only lines in Done state and not fully returned yet can be returned)!"

  Steps to find the bug:

  - Create a new product: 
  Stockable / Make to order / Buy
  Check the boxes for the incoming and the outgoing traceability (Track Incoming/Outcoming Lots)

  - Create a Sale Order for x PRODUCT
  - Run the scheduler
  - Confirm the Request for Quotation
  - Receive the product
  - Process the reception
  - Create a new production lot
  - Process the internal move (toward this new lot)
  - Deliver the product (from this lot) -> State: done
  - Click on Return Products

  -> Window with the error message

To manage notifications about this bug go to:
https://bugs.launchpad.net/openobject-addons/+bug/944025/+subscriptions