[6.1][7.0][trunk] _product_reserve result is not correct

Bug #1152616 reported by Yann Papouin
52
This bug affects 9 people
Affects Status Importance Assigned to Milestone
Odoo Addons (MOVED TO GITHUB)
Confirmed
Medium
OpenERP R&D Addons Team 2

Bug Description

_product_reserve (stock/stock.py) does not take linked moved into account for computation.

It results in a total mess when using mrp module as a "mrp.production" object when confirmed will always create two moves (the first for the procurement, and a second one that is in a 'waiting' state and attached to the stock.picking list used to check production start availability) for each product line:

"Stock -> Stock" linked to "Stock -> Production" via "move_dest_id" field

The BIG problem is that "_product_reserve" is doing this:

Counted value INCREASED (++) for : location_id <> stock AND location_dest_id = stock AND state='done'
Counted value DECREASED (--) for : location_id == stock AND location_dest_id <> stock AND state in ('done', 'assigned')

As you can see, the first move will never be taken into account, even if assigned because "location_id == location_dest_id" and the second move is also ignored because it is in a 'waiting' state.

In practice, the final issue is that a product procurement is always valid (if Quantity On Hand > 0.0):
  "from stock: products assigned."
but the quantity is permanently decreased without exception from procurement.
So actually, the MRP module cannot be used.

Tags: warehouse
Revision history for this message
Yann Papouin (yann-papouin) wrote :

UP, I think that it's a major issue, it was a source of multiple stock errors in our company, we are using a dirty fix to avoid this but this issue must be reviewed by a stock move expert.

Revision history for this message
Amit Parik (amit-parik) wrote :

Hello Yaan,

First move is internal move between stock to stock. For internal move no need to create stock valuation entry.
Generally this move creates because our input location and stock location both are same = 'stock'.

So the move is for input location to stock location.

Why you need a stock valuation entry for internal move. Please provide a real use case.

Thank you!

Changed in openobject-addons:
status: New → Incomplete
Revision history for this message
Yann Papouin (yann-papouin) wrote :

That's why I wrote that this issue must be reviewed by a stock move expert.

I'm adding a screencast to reproduce.

After seeing this screencast:
=======================
As you can see in that case, OpenERP will never try to buy PRODUCT_ITEM_A.
If you want to know why it's so easy to reproduce, it's because PRODUCT_ITEM_B don't have any stock so the internal picking list of the manufacturing order stay in "Waiting Availability" :

  PTN/XXXX (confirmed: Waiting Availability)
  Move n: PRODUCT_ITEM_A : stock - > stock (assigned: Available)
  Move n: PRODUCT_ITEM_B : stock - > stock (waiting: Waiting Another Move)

  MO/XXXX (confirmed: Awaiting Raw Materials)
  Move n+1: PRODUCT_ITEM_A : stock - > production (waiting: Waiting Another Move)
  Move n+1: PRODUCT_ITEM_B : stock - > production (waiting: Waiting Another Move)

So, again, the problem comes from _product_reserve (stock/stock.py), it should decrease value if a move (location_id=location_dest_id) is assigned and it's move_dest_id is waiting (location_id<>location_dest_id) and this recursively.

Changed in openobject-addons:
status: Incomplete → New
Revision history for this message
Yann Papouin (yann-papouin) wrote :
Revision history for this message
Amit Parik (amit-parik) wrote :

Hello Yaan,

Thanks for the video and detailed explanation.

I can reproduce the same.

Thank you!

Changed in openobject-addons:
assignee: nobody → OpenERP R&D Addons Team 2 (openerp-dev-addons2)
importance: Undecided → Medium
status: New → Confirmed
Amit Parik (amit-parik)
tags: added: warehouse
Revision history for this message
Andreas Brueckl (andreas-brueckl) wrote :

Is there already an idea of how to solve this?
I try to find a solution for this but do not want to analyse all the stuff again if there is already an existing idea.

Revision history for this message
Sid (siddiqmomin) wrote :

First of all

Stock>> Stock move itself is wrong..why somebody wants move Input to Stock??? No WMS system records this..

Alternate way of handling or avoid this is..use Routing even if of single Workcenter and assign the Location to Routing..
This will not create any Stock>>Stock Entry

Rather it will create first move as

Stock>>Routing location
Routing Location>>Production
and then

Production >>Stock (FG)

Regrads,

Sid

Revision history for this message
Yann Papouin (yann-papouin) wrote :

Maybe a FIX could be to consider that all moves in 'assigned' state from the same IN/OUT location have to be decreased. That way, this kind of move would be considered as a reservation.

#YP: We could suppose that all moves in 'assigned' from the same IN/OUT location state have to be decreased
cr.execute("""SELECT product_uom,-sum(product_qty) AS product_qty
              FROM stock_move
              WHERE location_id=%s AND
                    location_dest_id=%s AND
                    product_id=%s AND
                    state in ('assigned')
              GROUP BY product_uom
           """,
           (id, id, product_id))
results += cr.dictfetchall()

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.