Stock Input/Output Accounts doesn't work well

[Carlos Liebana]

OpenERP v6.1, spanish account localization installed on a common stock profile. Video Example attached.

1) I correctly define in product information the Stock Input/Output Accounts
2) I also define in the product category the information of the Stock Variation Account
3) I made a purchase order of:

Product A: 5 units x 63,28 € = 316,4 €
Pruduct B: 1 unitx x 1 € = 1 €

4) Listing the movements from the stock journal, it's not multiplying the units and the price, and instead of that it's just accounting the price of a single unit.

Best regards.

[DBR (OpenERP) (dbr-openerp)]

Thanks For Reporting!...

[Francisco Pascual -- Ting! (francisco-pascual)]

This patch fixes the problem

[Carlos Liebana (carlos-liebana)]

Please,

Can somebody confirm that our patch fixes the problem? For me it's a big problem, because this bug was not allowing as to have the correct stock values in our accounts.

Thanks.

[Borja López Soilán (NeoPolus) (borjals)]

> Listing the movements from the stock journal, it's not multiplying the units and the price, and instead of that it's just accounting the price of a single unit.

Try to set the product "Costing Method" as "Average Price", does it work then?

[Carlos Liebana (carlos-liebana)]

This is crazy, I can't reproduce the error now without the patch.

Devishree, did you manage to confirm it by yourself?

[Carlos Liebana (carlos-liebana)]

Yes Borja, with "Average Price" works well but with "Standard Price" isn't. I finally manage to reproduce the bug, I was getting crazy :)

Our patch is wrong then, because the calculation is supposed to be in the creation of the account. With it applied, is multiplying twice the products configured as "Average Price"

Francisco from my team is looking at it.

[Francisco Pascual -- Ting! (francisco-pascual)]

This patch fixes the problem correctly, anyway I dont understand why it fails.

the problem is in stock.py in return of function _get_reference_accounting_values_for_valuation (line 2025)

if you print value before return, it appear ok:

        amount_unit = move.product_id.price_get('standard_price', currency_ctx)[move.product_id.id]
        reference_amount = amount_unit * qty or 1.0
        print ('check 1: '+str(reference_amount))
        return reference_amount, reference_currency_id

       ------> check 1: 601.0 (4 products with cost 150,25)

but if you print the returned variable:

                reference_amount, reference_currency_id = self._get_reference_accounting_values_for_valuation(cr,
                uid,move, src_company_ctx)
                print ('check 2: '+ str(reference_amount))

        ------> check 2: 150.25

[Fabien (Open ERP) (fp-tinyerp)]

I did not tried to reproduce, but your patch looks wrong to me.

If there is a bug, it has to be fixed in :
  _get_reference_accounting_values_for_valuation
not in _create_account_move_line

[Francisco Pascual -- Ting! (francisco-pascual)]

The problem is that i dont know how to solve it into _get_reference_accounting_values_for_valuation because the variable before return have the correct value.

[Graeme Gellatly (gdgellatly)]

Hi, I just run in to this. The issue is not in the stock module, but in the purchase module.

In purchase/stock.py it overrides _get_reference_accounting_values_for_valuation and within that function, if move.price_unit is not already written it takes the value from the PO Line, but does not multiply it by the quantity.

Function below

    def _get_reference_accounting_values_for_valuation(self, cr, uid, move, context=None):
        """
        Overrides the default stock valuation to take into account the currency that was specified
        on the purchase order in case the valuation data was not directly specified during picking
        confirmation.
        """
        reference_amount, reference_currency_id = super(stock_move, self)._get_reference_accounting_values_for_valuation(cr, uid, move, context=context)
        if move.product_id.cost_method != 'average' or not move.price_unit:
            # no average price costing or cost not specified during picking validation, we will
            # plug the purchase line values if they are found.
            if move.purchase_line_id and move.picking_id.purchase_id.pricelist_id:
                reference_amount, reference_currency_id = move.purchase_line_id.price_unit, move.picking_id.purchase_id.pricelist_id.currency_id.id
        return reference_amount, reference_currency_id

As you will see by comparing to the stock/stock.py version of this function it fails to multiply by quantity.

[Graeme Gellatly (gdgellatly)]

To patch you just need to recompute qty and multiply so I imagine just insert

qty = product_uom_obj._compute_qty(cr, uid, move.product_uom.id, move.product_qty, default_uom)
and change line
reference_amount, reference_currency_id = move.purchase_line_id.price_unit, move.picking_id.purchase_id.pricelist_id.currency_id.id to
reference_amount, reference_currency_id = move.purchase_line_id.price_unit * qty, move.picking_id.purchase_id.pricelist_id.currency_id.id

[Graeme Gellatly (gdgellatly)]

One last piece, you can see why it doesn't affect average cost, as it is the if not condition for this function

[Carlos Liebana (carlos-liebana)]

Thanks Graeme, we're going to test it and give feedback.

[Francisco Pascual -- Ting! (francisco-pascual)]

Thanks Graeme, it seems to work correctly.

[Valdemar Cantu (vcmanzo)]

Hello,

I reported the very same bug here:

https://bugs.launchpad.net/openobject-addons/+bug/737255

I am glad to see it is finally classified with more importance than low, and also that is fixed!

It is fixed right?

Regards,
V

[Nehal Panchal (OpenERP) (nep-openerp)]

Hello Everyone,

It has been fixed by revision 4614 <email address hidden> in the branch lp:~openerp-dev/openobject-addons/6.0-bug-740964-nep.

Your inputs are always appreciated.

Thanks for pointing out towards such a crucial issue and participating in the fix.

[jlinkels (jlinkels)]

I have applied the patch and I can confirm the booked values are correct now.

However, I would have expected this fix be included in release 6.0.3 but it isn't. I admit I don't have much experience with following how these kind of bug fixes are merged, but it seems so strange to me that a fix is available and still it is not present in the release.

jlinkels