openerp-india team mailing list archive

["Saurang Suthar\(OpenERP\)" <1006494@xxxxxxxxxxxxxxxxxx>]

** Branch linked: lp:~openerp-dev/openobject-addons/trunk-
bug-1006494-ssu

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

Title:
  unit factor is applied twice in account valuation

Status in OpenERP Addons (modules):
  In Progress

Bug description:
  lets say you have a product:
    - a product with base UoM 'Units'
    - default purchase unit: dozen
    - no UoS defined
    - cost method: 'average'
    - standard cost: 300
    - real time valuation

  now, do a purchase of  one dozen.  the price unit field shows $3,600,
  quantity: 1

  checking the 'stock.move' record:
    - product_qty: 1.00
    - product_uom: dozen
    - product_uos_qty: 1.00
    - product_uos: dozen
    - price_unit: 3600.00   (price of one dozen)

  when the movement is processed, the account journal entry amount is
  $43,200 !!!

  looking in the 'stock.move'
  _get_reference_accounting_values_for_valuation() method, there's this
  code:

  
          default_uom = move.product_id.uom_id.id
          qty = product_uom_obj._compute_qty(cr, uid, move.product_uom.id, move.product_qty, default_uom)

          # if product is set to average price and a specific value was entered in the picking wizard,
          # we use it
          if move.product_id.cost_method == 'average' and move.price_unit:
              reference_amount = qty * move.price_unit
              reference_currency_id = move.price_currency_id.id or reference_currency_id

  so, it calculates the quantity by calling _compute_qty(), which
  transforms the "one dozen" specification into "12 units"; so far so
  good.  but then it multiplies that quantity (12) by the price_unit
  field which holds 3600.00 (price of one dozen).  finally it returns an
  amount of 43200.00

  i think there are two possible fixes:

  option A: _get_reference_accounting_values_for_valuation() shouldn't
  call _compute_qty(), since the movement price_unit is already
  expressed in the movement unit (dozens in this case)

  or

  option B: the purchase code should store the base unit price in the
  stock.move price_unit field.

  Option A sounds better, but want to check other people's opinion.

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