[UoM issue] Warning pop-up when entering prodlot on stock_move gives wrong quantity

[Alexis de Lattre]

Here is the step-by-step scenario to reproduce the bug on an up-to-date OpenERP 7.0 (server/7.0 revno 5084 and addons/7.0 revno 9474) :

1. Create a new DB with demo data

2. install the purchase module

3. Add your user to the following groups :
  - Technical Settings
  - Manage multiple Units of Measures
  - Manage serial numbers
  - Manager Logistic Serial Numbers

4. Create a new product :
  - Name : Perfume
  - Product type : Stockable Product
  - Unit of measure : g
  - Purchase unit of measure : kg
  - Track Manufacturing lots : yes
  - Track Incoming lots : yes
  - Track Outgoing lots : yes

5. Create a new Purchase order :
  Supplier : Asustek
  Add one purchase order line :
  - Product : Perfume
  - Quantity : 2.0
  - Product Unit of Measure : kg (it is the default, because we set kg as Purchase UoM)
  Click on the button "Confirm Order".

6. On the incoming shipment that has been generated, you should see one stock move line with :
  - Quantity : 2.0
  - unit of measure : kg.
  Edit the stock move line, create a serial number 'SN12' and save.
  Then click on the "Receive" button and validate the reception of the goods.

7. If you look on the product tree view, you should see for the perfume :
- Qty on Hand : 2000
- Unit of measure : g
=> that's OK, OpenERP gives the right value for the stock level.

8. Now, let's ship 5g of perfume from the prodlot 'SN12'.
  Create a new delivery order with 1 stock move line :
  - Product : perfume
  - Quantity : 5.0
  - Unit of measure : g (it's taken by default when you select the product because the UoM of this product is "g")
  Then select the Serial number 'SN12'.
  When do you that, you get a warning pop-up : "You are moving 5.00 g but only 2.00 g available for this serial number".

=> That's wrong : we have 2000.0 g of perfume (= 2.0 kg), not 2.00 g !

Here is my analysis of the code :

1) The warning pop-up is generated in stock/stock.py line 1842 in the function onchange_lot_id(). When you enter this function, you have :
product_qty= 5
uom = browse record of ID 4 (= g)
product_uom = browse record of ID 4 (= g)
prodlot.stock_available = 2.0
You have a line :
amount_actual = uom_obj._compute_qty_obj(cr, uid, product_uom, prodlot.stock_available, uom, context=ctx)
The proto of this function is _compute_qty_obj(self, cr, uid, from_unit, qty, to_unit, context=None)

So amount_actual = 2.0 because the function _compute_qty_obj has "g" as from_unit and "g" as "to_unit"

So I think that this code is OK, but I consider that the fields.function "stock_available" on prodlot should be in the unit of measure of the product, so it should give a value of 2000 and not 2.

2) The field 'stock_available' on prodlot is defined in stock/stock.py line 1473. The function is _get_stock on line 1423. This function doesn't do much and doesn't have any notion of unit of measure. All the intelligence of this function is in the SQL view "stock_report_prodlots".

3) The SQL view "stock_report_prodlots" is defined in stock/report/report_stock.py line 41. First, I suppose that this SQL view should give the quantity in the UoM of the product ("g" in this case). When I read the SQL code, I see that it takes into account the field product_uom of the stock_move (kg), it joins the UoM of the stock_move (kg) with the ID of the table product_uom to read the "factor" field (1 for kg), but it never reads the uom of the product (g). The funny thing is that it reads the "factor" field on the table product_uom, but it doesn't even read the field "uom_type" on the table product_uom which give the information "smaller" or "bigger" !

So my conclusion is that the code of the SQL view "stock_report_prodlots" doesn't make any sense if you are using different UoMs for the same product !

I would love to have some feedback on my code analysis.

[jeffery chen fan (jeffery9)]

analysis is right

[Alexis de Lattre (alexis-via)]

According to my tests, the bug is solved in Odoo v8.

[Alexis de Lattre (alexis-via)]

I made a new test today and I confirm that this scenario is fixed in v8.