Calculated BOM is incorrect when Purchase UOM is different from product default UOM

[E.R. Spada II]

Hello,
I found a bug that was fixed by OpenERP Enterprise Contact. Please see lp:~openerp-dev/openobject-addons/7.0-opw-599727-fka this fixed a bug that the UOM on the sale order line is incorrect when the UOM and purchase UOM are different. Since your module also uses these fields, it now creates the incorrect BOM cost. It divide the cost by the purchase UOM.

For example if the product is sold as a Unit, and the Purchase UOM is Case of 50. When the cost is calculated it is divided by 50. If you review the simple changes in lp:~openerp-dev/openobject-addons/7.0-opw-599727-fka it is quite obvious.
ER

[Guewen Baconnier @ Camptocamp (gbaconnier-c2c)]

Thanks for the report.

Can you point us in which module this bug occurs please?

[E.R. Spada II (er-b)]

Yes, look at the diff from lp:~openerp-dev/openobject-addons/7.0-opw-599727-fka you will see the three modules that were changed. {product/pricelist.py, product_visible_discount/product_visible_discount.py, sale_margin/sale_margin.py, sale_margin/sale_margin.py}

Please note that some of the modules are optional, but I tested them all to make sure this was correct. It was also verifed by a senior developer at Openerp. These were fixed due to my enterprise contract.

=== modified file 'product/pricelist.py'
2 --- product/pricelist.py 2013-09-20 14:45:29 +0000
3 +++ product/pricelist.py 2013-11-12 05:32:02 +0000
4 @@ -296,7 +296,11 @@
5 price_limit = price
6 price = price * (1.0+(res['price_discount'] or 0.0))
7 price = rounding(price, res['price_round']) #TOFIX: rounding with tools.float_rouding
8 - price += (res['price_surcharge'] or 0.0)
9 + fact = 1.00
10 + if context.get('uom'):
11 + fact = product_uom_obj.read(cr, uid, context['uom'], ['factor'])['factor']
12 + if res['price_surcharge']:
13 + price += ((res['price_surcharge'] / fact) or 0.0)
14 if res['price_min_margin']:
15 price = max(price, price_limit+res['price_min_margin'])
16 if res['price_max_margin']:
17
18 === modified file 'product_visible_discount/product_visible_discount.py'
19 --- product_visible_discount/product_visible_discount.py 2013-01-25 07:09:52 +0000
20 +++ product_visible_discount/product_visible_discount.py 2013-11-12 05:32:02 +0000
21 @@ -59,11 +59,11 @@
22 product_read = product_obj.read(cr, uid, product_id, [field_name], context=context)
23
24 factor = 1.0
25 - if uom and uom != product.uom_id.id:
26 + if uom:
27 product_uom_obj = self.pool.get('product.uom')
28 - uom_data = product_uom_obj.browse(cr, uid, product.uom_id.id)
29 + uom_data = product_uom_obj.browse(cr, uid, uom)
30 factor = uom_data.factor
31 - return product_read[field_name] * factor
32 + return product_read[field_name] / factor
33
34
35 res=super(sale_order_line, self).product_id_change(cr, uid, ids, pricelist, product, qty,
36
37 === modified file 'sale_margin/sale_margin.py'
38 --- sale_margin/sale_margin.py 2012-12-19 01:25:10 +0000
39 +++ sale_margin/sale_margin.py 2013-11-12 05:32:02 +0000
40 @@ -34,8 +34,12 @@
41 frm_cur = self.pool.get('res.users').browse(cr, uid, uid).company_id.currency_id.id
42 to_cur = self.pool.get('product.pricelist').browse(cr, uid, [pricelist])[0].currency_id.id
43 if product:
44 - purchase_price = self.pool.get('product.product').browse(cr, uid, product).standard_price
45 - price = self.pool.get('res.currency').compute(cr, uid, frm_cur, to_cur, purchase_price, round=False)
46 + product_obj = self.pool.get('product.product').browse(cr, uid, product)
47 + frm_uom = product_obj.uom_id.id
48 + to_uom = uos or uom
49 + purchase_price = product_obj.standard_price
50 + price = self.pool.get('product.uom')._compute_price(cr, uid, frm_uom, purchase_price, to_uom)
51 + price = self.pool.get('res.currency').compute(cr, uid, frm_cur, to_cur, price, round=False)
52 res['value'].update({'purchase_price': price})
53 return res

[E.R. Spada II (er-k)]

Hello again,
I have looked at the product module. In the product.py appox line 92, the UOM factor is calculated. If I change the / to * then BOM cost will calculate correctly. def _compute_factor_inv(self, factor):
#er change / to * THEN BOM COST IS CORRECT
        return factor and (1.0 /* factor) or 0.0

It basically uses the inverse of the UOM.

So it seems when the module product_get_cost_field does not take into account of the purchase UOM factor, it will get the same cost as Openerp uses, but for the calculation of cost it must use the field factor_inv field.
tx,
ER

[E.R. Spada II (er-k)]

Hello again,
Still testing, but in the module product cost_incl_bom is where the problem lies. When it calculated the cost for the BOM line, the quantity was divided by uom_po_id, not the uom_id. I changed both fields in product_cost_incl_bom.py to:

###### eagerly read all the dependencies products - REPLACE uom_po_id WITH uom_id
        sub_read = self.read(cr, uid,
                             list(chain.from_iterable(depends.itervalues())),
LINE 168 - ['cost_price', 'uom_po_id'], context=context)
                                         + ['cost_price', 'uom_id'], context=context)

AND

LINE 206 ####replace uom_po_id WITH uom_id
                    to_uom_id=subproduct['uom_id'][0])
                cost += subcost * qty

[E.R. Spada II (er-k)]

This was fix in v7 and v8, after I complained a year later.

[E.R. Spada II (er-k)]

As for the BOM issue, it was updated in product_extended.py, but the forgot to / produc_effecieny on the cost so I add it to my module. Plus I added a cron to update all the standard cost products with a BOM. I can have it if you want it.
ER

[Gilles Lehoux (q-gilles-a)]

I am currently operating OpenERP v7.0 with no pending updates. Since there
are no pending updates, I'm assuming there are no bugfixes I haven't
gotten. Still, I'm experiencing the problem you describe in your bug
report, as I understand it. That is, when calculating the cost of a bom, if
the purchase uom is different than the uom then the cost is applied with a
wrong factor.

I'm afraid that the switch to github has confused me. You say that bug
1266664 has been fixed and yet Launchpad has no sign of that. The FAQ for
the transition from launchpad to github says that bugs in launchpad will
not be transferred to github. I don't understand how anyone is tracking
which old bugs have been fixed.

I am a part-time amateur programmer. I've learned a lot to get OpenERP to
work but there is much left.

You say you have a module. What is the purpose of this module?

A search has led me to this conversation where you were involved.
https://www.odoo.com/forum/help-1/question/is-there-a-product-extended-for-v7-4258
I'm not sure if this is telling me to use product_extended instead of
product_cost_incl_bom.

The more I dig into this problem, the more it seems I'm not suppose to have
it. ;)

Gilles Lehoux <email address hidden> www.isogarde.com
Isogarde inc. Tel. [phone] Tel. [phone] Fax.
450-472-5207

On Tue, Mar 24, 2015 at 3:01 PM, E.R. Spada II <email address hidden>
wrote:

> As for the BOM issue, it was updated in product_extended.py, but the
> forgot to / produc_effecieny on the cost so I add it to my module. Plus I
> added a cron to update all the standard cost products with a BOM. I can
> have it if you want it.
> ER
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1266664
>
> Title:
> Calculated BOM is incorrect when Purchase UOM is different from
> product default UOM
>
> Status in OpenERP Financial controlling and costing:
> New
>
> Bug description:
> Hello,
> I found a bug that was fixed by OpenERP Enterprise Contact. Please see
> lp:~openerp-dev/openobject-addons/7.0-opw-599727-fka this fixed a bug that
> the UOM on the sale order line is incorrect when the UOM and purchase UOM
> are different. Since your module also uses these fields, it now creates the
> incorrect BOM cost. It divide the cost by the purchase UOM.
>
> For example if the product is sold as a Unit, and the Purchase UOM is
> Case of 50. When the cost is calculated it is divided by 50. If you review
> the simple changes in lp:~openerp-dev/openobject-addons/7.0-opw-599727-fka
> it is quite obvious.
> ER
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/margin-analysis/+bug/1266664/+subscriptions
>

[E.R. Spada II (er-k)]

Yes, it is very confusion with the open bugs in lp to Git.As for v8, the intregtrated product_cost_incl_bom. to product_extended module. The error exists that the qty are correct as well as including the routing costs. But when the price is calculated the forgot to divide correctly to calculate the correct cost it should be (my_qty = sbom.product_qty / sbom.product_efficiency).

Since this module you must manually update the BOM cost I created a schedular (cron) that would update the BOM cost twice a day so if raw material and/or child BOM changes the correct cost is on the sale order line.

Since the WMS was totally changed for v8, for my purpose I migrated all my v7 modules.

As for the UOM issue was fixed in v7 and v8 from my support odoo:
v7:
Hello,
I come back to you regarding your bug on product pricelist. Sorry that we had never integrated this fix before.
I have reviewed and integrated two fixes (rev 79ebe10 and 42bf0a5) in 7.0 about this.
This should fix two issues:
1. when using a different unit of measure, the pricelist did not apply correctly the discount (e.g. with pack of 4 unit, the unit prices was reduced only once of the discount amount instead of 4)
2. when using a different unit of measure, the discount (with module product_visible_discount) would stay at zero instead of displayed the difference after applying the pricelist
Was that indeed the two issues you had with it ?
If you still have issues on this, let me know.
It was integrated in 7.0 but will be soon be available in 8.0 as well.

v8
Hello,
Following the issue you have reported on github, I have integrated another fix for this issue (revision 7978708).
Thanks for the report.
Regards
read less
Martin Trigaux (mat) to EUGE Consulting , EUGE Consulting, E.R. Spada II • Mon Oct 27 2014 1:22 PM •like

Hope this helps.
ER

--

E.R. Spada II owner | er@e <mailto:<email address hidden>>ugeconsulting.com | Direct. 518 365 7854 | Fax. [phone]
EUGE Consulting | 107 Everett Road | Albany, New York 12205 | http://www.e <http://www.digital-page.com/>ugeconsulting.com

CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

> On Mar 24, 2015, at 8:25 PM, Gilles Lehoux <email address hidden> wrote:
>
> I am currently operating OpenERP v7.0 with no pending updates. Since there
> are no pending updates, I'm assuming there are no bugfixes I haven't
> gotten. Still, I'm experiencing the problem you describe in your bug
> report, as I understand it. That is, when calculating the cost of a bom, if
> the purchase uom is different than the uom then the cost is applied with a
> wrong factor.
>
> I'm afraid that the switch to github has confused me. You say that bug
> 1266664 has been fixed and yet Launchpad has no sign of that. The FAQ for
> the transition from launchpad to github says that bugs in launchpad will
> not be transferred to githu...