openerp-india team mailing list archive

["Twinkle Christian\(OpenERP\)" <tch@xxxxxxxxxxx>]

** Changed in: openobject-addons
   Importance: Undecided => Low

** Changed in: openobject-addons
       Status: New => Confirmed

** Changed in: openobject-addons
     Assignee: (unassigned) => OpenERP R&D Addons Team 2 (openerp-dev-addons2)

-- 
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/1229271

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

Status in OpenERP Addons (modules):
  Confirmed

Bug description:
  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.

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