openerp-india team mailing list archive

[Javier Guerra <javier@xxxxxxxxxxx>]

Public bug reported:

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.

** Affects: openobject-addons
     Importance: Undecided
         Status: New

-- 
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):
  New

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