Comment 8 for bug 1266664

Revision history for this message
E.R. Spada II (er-k) wrote : Re: [Bug 1266664] Calculated BOM is incorrect when Purchase UOM is different from product default UOM

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. 518 459 7025
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 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. 450-472-8128 Tel. 888-472-8128 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
>>
>
> --
> 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