Cost price calculation limited to 2 levels in product bom

Bug #702288 reported by Bertrand Hanot
52
This bug affects 9 people
Affects Status Importance Assigned to Milestone
Odoo Addons (MOVED TO GITHUB)
Invalid
Wishlist
OpenERP R&D Addons Team 2

Bug Description

A concrete example better than a long and difficult explanation :-)

We have the following product A composed of the product B and product B is composed from product C. So the below BOM:
A
-----B
-----------C

If the price of B is modified, then the price of A can be also modified.
But if i modify the price of C, only B is modified and not A.

This is a very important blocking issue, since in most of the real prod environment, we've of course more than 2 level of boms (in some customer installation, up to 100 levels !).
So any modification at the bottom should have a consequence on all the bom structure until the top, else OpenERP cannot be used for production.

Tags: maintenance
Changed in openobject-addons:
status: New → Confirmed
tags: added: maintenance
Changed in openobject-addons:
importance: Undecided → Wishlist
assignee: nobody → OpenERP R&D Addons Team 2 (openerp-dev-addons2)
Revision history for this message
Joël Grand-Guillaume @ camptocamp (jgrandguillaume-c2c) wrote :

Hi,

IMHO this should be fixed and not tagged as whislist as this is really needed for a production environment. I agree that this is not really "a bug" in the way it doesn't cause the system to crash, but honestly, it is not "serious" to let something like that in OpenERP !

Somebody else ?

Regards,

Joël

Revision history for this message
filsys (office-filsystem) wrote :

Joël, +1

Revision history for this message
TeMPO (info-tempo-consulting) wrote :

+1 for me

I don't understand why such a limitation, if we can do it for 2 levels we can do it for n levels

Maurice

Revision history for this message
Steffi Frank (Bremskerl, DE) (steffi-frank) wrote :

I DO agree with you, Joël!!!

Revision history for this message
Rudy (rudy-valentin) wrote :

Hi,

I completely agree with Joël.

You say than OpenERP V6 will improve mrp but this point is the base of a real mrp.

With this point, we will be able to put OpenERP in all Manufacturing compagny.

Our customers wait for this point !!!

regards

Revision history for this message
Bertrand Hanot (bertrand-hanot) wrote : RE: [Bug 702288] Re: Cost price calculation limited to 2 levels in product bom

Hi,

I fully agree ! I initially reported it to the support team, in order to have it solved in the scope of the maintenance contract (editor warranty) of our customer.

According to OpenERP, this is not a bug but a missing feature... i don't agree. And i'll have to explain my customer that he paid for the warranty but that bug will not be solved because it's not really a bug. Amazing !

Cheers.

Bertrand.

________________________________________
From: <email address hidden> [<email address hidden>] On Behalf Of Joël Grand-Guillaume @ CampToCamp [<email address hidden>]
Sent: Friday, January 14, 2011 11:06
To: Bertrand Hanot
Subject: [Bug 702288] Re: Cost price calculation limited to 2 levels in product bom

Hi,

IMHO this should be fixed and not tagged as whislist as this is really needed for a production environment. I agree that this is not really "a bug" in the way it doesn't cause the system to crash, but honestly, it is not "serious" to let something like that in OpenERP !

Somebody else ?

Regards,

Joël

--
You received this bug notification because you are a direct subscriber
of the bug.
https://bugs.launchpad.net/bugs/702288

Title:
  Cost price calculation limited to 2 levels in product bom

Status in OpenObject Addons Modules:
  Confirmed

Bug description:
  A concrete example better than a long and difficult explanation :-)

  We have the following product A composed of the product B and product B is composed from product C. So the below BOM:
  A
  -----B
  -----------C

  If the price of B is modified, then the price of A can be also modified.
  But if i modify the price of C, only B is modified and not A.

  This is a very important blocking issue, since in most of the real prod environment, we've of course more than 2 level of boms (in some customer installation, up to 100 levels !).
  So any modification at the bottom should have a consequence on all the bom structure until the top, else OpenERP cannot be used for production.

To unsubscribe from this bug, go to:
https://bugs.launchpad.net/openobject-addons/+bug/702288/+subscribe

Revision history for this message
Ferdinand (office-chricar) wrote :

Unfortunately we had a lot and still have situations where a missing detail (often a few liens of code) - I agree these are not technical bugs - renders the module unusable in day2day live although OpenERP claims to offer the feature !!!

I think it is fundamental for the benefit of OpenERP and all partners to establish a steering committee for such issues like
* accounting
** multi currency
** reporting
** fiscal year closing
* layout issues
** to short name fields in GTK do not display essential information and make working an VERY UNPLEASANT experience.
** important fields "hidden" on notebook pages.
** missing unified layout

Revision history for this message
Antony Lesuisse (OpenERP) (al-openerp) wrote :

This feature should not be used. I think cost price should not be automatically updated from cost price of bom component. What happens if a product is listed in 2 different BOMs ?

Changed in openobject-addons:
status: Confirmed → Invalid
Revision history for this message
Steffi Frank (Bremskerl, DE) (steffi-frank) wrote :

both should get updated....

Revision history for this message
Ferdinand (office-chricar) wrote :

for calculation of offers it is mandatory to calculatate ALL exploded quantites multiplied with "a" price - which is determined by the relevant price list.
it's a very valid request.

and obviously all "parent" product prices have to be updated / recalculated if a component price changes
at least for new offers.

Revision history for this message
Rudy (rudy-valentin) wrote :

@Antony: The both top product price should be updated like Steffi said.

I think, it should be a specific addons, so if someone install this addons it's than he wants than all price will be updated.

Revision history for this message
Marco Dieckhoff (dieck) wrote :

If you think it should not be changed at all, please elaborate why.

Cost price calculation is the main and often only option for controlling your end price. Otherwise you could easily end up selling products for less than you need to manufacture them.

In either case, the arbritary limitation to two levels is a bug imho.
You should do either no update at all (which would be wrong), or all upstream prices should be updated, if any component price, independent on the level, is changed.

You could easily avoid this discussion by adding a boolean field "Change product cost price on component price updates" to BoM.

Revision history for this message
conexus.at (conexus.at) wrote :

I totally agree with Marco Dieckhoff.

Also for us it's crucial that the calculation is done thorugh n levels of boms.

Revision history for this message
Ferdinand (office-chricar) wrote :

obviosuly the calculation must be done for cost price and sale price to be able to calculate the contribution at each level of BOM which is crucial for decision making.

Revision history for this message
Michael Schwessinger (schwessinger) wrote :

right! That is the difference between an Enterprise ressource planning software and a "sage clone"... If the latest comments from OpenERP members are really the official decisions, we have to stop introducing OpenERP. For the first, we stop our planned real-time date (which was the 1. of April). Our general manager will be pleased ....

Revision history for this message
Bertrand Hanot (bertrand-hanot) wrote :

Antony,

Could you please elaborate further ?

I don't get your point. This is a very old bug which has been reported several times to OpenERP and never solved. I didn't found any partner that didn't want this bug to be resolved, but on top of that, as stated by other partners too, this bug makes OpenERP not usable in MRP environment.

Of course, you can always say it's up to the partner to solve that, but customers paid an OPW already and will not pay any additional fee to solve a bug by the partner.

Regards.

Bertrand.

-----Original Message-----
From: <email address hidden> [mailto:<email address hidden>] On Behalf Of Antony Lesuisse
Sent: jeudi 31 mars 2011 16:03
To: Bertrand Hanot
Subject: [Bug 702288] Re: Cost price calculation limited to 2 levels in product bom

This feature should not be used. I think cost price should not be automatically updated from cost price of bom component. What happens if a product is listed in 2 different BOMs ?

** Changed in: openobject-addons
       Status: Confirmed => Invalid

--
You received this bug notification because you are a direct subscriber of the bug.
https://bugs.launchpad.net/bugs/702288

Title:
  Cost price calculation limited to 2 levels in product bom

Status in OpenERP Modules (addons):
  Invalid

Bug description:
  A concrete example better than a long and difficult explanation :-)

  We have the following product A composed of the product B and product B is composed from product C. So the below BOM:
  A
  -----B
  -----------C

  If the price of B is modified, then the price of A can be also modified.
  But if i modify the price of C, only B is modified and not A.

  This is a very important blocking issue, since in most of the real prod environment, we've of course more than 2 level of boms (in some customer installation, up to 100 levels !).
  So any modification at the bottom should have a consequence on all the bom structure until the top, else OpenERP cannot be used for production.

To unsubscribe from this bug, go to:
https://bugs.launchpad.net/openobject-addons/+bug/702288/+subscribe

Revision history for this message
TeMPO (info-tempo-consulting) wrote :

Dear all

I just came back from a potential future customer who is willing to use the production module
and the calculation of the cost price of a product using a multi level BOM is required

this is MANDATORY for MRP

regards

Revision history for this message
Antony Lesuisse (OpenERP) (al-openerp) wrote :

I said: think cost price should not be AUTOMATICALLY updated from cost price of bom component. What could possibly go wrong... ?

This feature will go back in the product_extended module (or maybe a specific mrp_bom_price one) and will be correctly implemented there. Because i think there are different possible policies on how to do it and that specific module should implement them all.

For example: Updating a price from bom children vs updating the parents when a children is updated (but then what happens if a product is parent of multiple bom with the same children and different coeficients?).

Revision history for this message
Jan Verlaan (jan-verlaan) wrote :

@Antony Why did you set this defect in that case to "Invalid"? If you see the point made like you did in your latest comment please reopen then.
B.t.w. it is not a feature as you call it, it is functionality that should be in a serious ERP. In my opinion for performance reasons there should be a manual trigger on the top BOM item and a automic action via the scheduler before the MRP run is executed. That way no extra module is needed and it could be implemented in standard.

Revision history for this message
Jan Verlaan (jan-verlaan) wrote :

Oh, I forgot to mention with my request to reopen "for the sake of clarity"

Revision history for this message
Fabien (Open ERP) (fp-tinyerp) wrote :
Download full text (4.2 KiB)

I tend to agree with Antony, but I will try to explain why he invalidates this discussion.

Introduction
----------------

OpenERP supports two costing methods: standard price and average price.

In average price, the cost price must be computed on the manufacturing orders itself, based on raw materials and work orders. So, in that case the cost price is updated at each transaction, based on the reallity. -> I don't think this feature is already implemented in OpenERP.

In standard price, companies fix a price for each products, usually once a year and the price usually do not change during this period. If you change the price of a product, the law requires that you are able to explain why and how you decided this new price.

These two methods are used to compute the Cost Price which reflects the cost of the product (and also the inventory valuation). The cost of the product reflects the average purchase price, the shipping costs, the raw materials, the work orders, etc... Each company has it's own may to compute a cost price. You can use specific rules if you are able to proove an auditer why you used this valuation method.

Why what you required has been refused ?
--------------------------------------------------------

The problem is not that OpenERP does the multi-level computation or not. The real bug here is that OpenERP should not update finished products if you change the price of a raw material.

Why ?
  - some products have different BoM (but only one cost price)
  - some products have different ways to procure them (you can purchase or produce them)
  - some products's cost price are based on others rules than simply the sum of raw materials for the BoM (integrate
    border taxes or shipping in the cost, ...).
  - this would allow companies to enrich themselves very easily, which is not legal:
      * You have & stock of 1m€ of product A which is produced in a certain way
      * By the end of the year, you change the cost of the raw materials of the product A, now your stocks values 1.2m€
         even if you don't really did anything.
      * very useful, but not very legal :)

Some companies do not want side effects: you change one raw material price -> all finnished products have their standard price updated. If you do that, try to explain an accounting auditor how you value your stock. This is very complex.

If the raw material are in average price and the finnished products are in standard price, it means your finnished product's cost price is updated at each transaction, which is not what you want for a standard price.

The proposed solution
-----------------------------

In V5, it was clean. We have to make it again like in V5.

So, there is clearly a bug in OpenERP but it's not the one explained here but rather:
  - When we update a price or a BoM, standard prices of finnished products should not be updated. To do that, just
    remove the method do_change_standard_price in the line 57 in mrp/product.py

The best way to update your standard price for finnished products (because once a year or periodically you want to do ittio for your stock valuation computan) is to use the module we developed for v5: product_extended. T...

Read more...

Revision history for this message
Mark van Deursen (Neobis) (mark-neobis) wrote :

I totally agree with everybody who thinks this is a mandatory feature for a serious MRP solution.
Either it's there, which makes OE a step closer to a full blown MRP or it isn't which, IMHO, is a missed opportunity.
But I think it's not acceptable to implement it only half. With this I mean if this feature is offered it shouldn't be limited to only 1 level recursion.

Revision history for this message
Fabien (Open ERP) (fp-tinyerp) wrote :

Mark, please read the comment just above:
  https://bugs.launchpad.net/openobject-addons/+bug/702288/comments/21

If it has been refused it's simply because:
  - it may be not legal in some countries,
  - it's simply not the way to implement this feature.

Revision history for this message
Olivier Dony (Odoo) (odo-openerp) wrote :

Please everyone, adding more comments with "I agree with the others" will not help, they will just be ignored.
If you want to make a difference, please show that you have looked deeply into this issue and have some real technical/business feedback to provide about this.

What we are trying to explain here, is that this bug relates to a feature that is very dangerous, and Fabien has tried to give a list of the many things that can go wrong in comment #21.

Your numerous comments show that you already have different opinions about what this should do, some people are even suggesting that this should automatically update the cost_price *and* sale_price of related products?! Really, does everyone realize all the possible dangerous and hidden things that this could do to your accounting and stock valuation??

This is the reason why we think this feature should not be available by default (e.g in an extra module), and the people using it need to fully realize all the implications.

If you still think this is wrong, then please explain properly what you would expect the system to do in all situations. This could be done with a real example that includes products with multiple BOMs per product and multiple levels, and taking into consideration the stock valuation in accounting: manual *and* real-time!

Based on this, we could discuss "seriously" what to do, and decide if it makes sense to provide this feature in the core of OpenERP. [ On this bug or on bug 747056 ]

Revision history for this message
Mark van Deursen (Neobis) (mark-neobis) wrote :

Fabien,

We posted almost simultaneously. The posts must have crossed.

I understand your point of view. But I don't know if I totally agree with you (yet).
It may be possible that due to legislation in some countries some use-cases can bring up problems.
But in other countries or in some industrial sectors other functionality is needed.

I have to dive in the problem/solution first to the give some constructive feedback.

Revision history for this message
Steffi Frank (Bremskerl, DE) (steffi-frank) wrote :

#21
"In standard price, companies fix a price for each products, usually once a year and the price usually do not change during this period" - I think Fabien is right!

We start mixing up two different requirements. First is to ensure the (legal) stock amount based on what you decide through 'Costing Method' in product. I agree with Fabien: as far as you decide to calculate your stock amount your standard price won't change during the fiscal year - therefor a price modification in BoM level 7 should not change the standard price in level 1 (finished good)....

But obviously all "colleagues" are missing a funcionality - and use the cost price calculation through BoM instead (therefor this bug is generally understandable): how the cost price for a finished product will be calculated when I replace a component somewhere in a multi-level BoM?

In every manufacturing componay there lots of crtiteria you need to consider while calculating a sales price, one of theese is the material - by choosing between different suppliers or raw materials this is quite often the only way to calculate a price which enables you to "get the business"...

I think an approach could be the following idea: add a new field 'manufacturing_costs' in product.product - real time calculated through ALL level BoMs....

Revision history for this message
Fabien (Open ERP) (fp-tinyerp) wrote :

Steffi, Stéphane will get back to you following your OPW request with the product_extended. I think it will fit your need for the computation of the cost price, when you need it (by pressing buttons) based on BoM.

For sale prices, it's different:
- sale price are not on the product form. What you have on the product form is the public sale price or, sometimes called,
   the catalog price.
- the sale price (for a particular customer) is computed by the pricelist. You can easily do a pricelist that compute the sale
  price based on the cost price.

If you need the sale price and cost price that changes according to BoMs and/or costs of raw material, you probably need to work in average prices instead of standard prices ?

Revision history for this message
Steffi Frank (Bremskerl, DE) (steffi-frank) wrote :

Fabien, little missunderstanding:I don't expect a sale price calculation! But be before I offer a new prodzct to my customers I first have to calculate the costs...

So: no automatic sales price calculation through BoM is required :)

Revision history for this message
Jan Verlaan (jan-verlaan) wrote :

I see the site effects Fabien has mentioned in comment 21.
I also see the need for having calculated the costs for a item that contains a BOM.
The proposal Steffie made is in my opinion a good one, that way a user has the calculated cost available while the cost price field isn't updated.
Please rethink my proposal to have manual calculation button on a BOM item to direct calculate the price and a calculation triggert by the scheduler for mass updates (so daily system performance isn't affected)

If this is acceptable the bug description in https://bugs.launchpad.net/openobject-addons/+bug/747056 should be changed.
Don't remove the method do_change_standard_price in the line 57 in mrp/product.py but
change the function to update the new suggested field and make the calculation multilevel.

Revision history for this message
Marco Dieckhoff (dieck) wrote :

If you read this in launchpad, you can easily miss the "Read more..." under Fabians statement.

There, he suggests having the requested features in an additional module "product_extended", and thus the request of removing the method from the base code.

Revision history for this message
Jan Verlaan (jan-verlaan) wrote :

Thanks Marco, but then still we have the problem with inventory valuation as product_extended does currently update the standard price field in V5. If it is ported to V6 we have the same issue here.
I like the suggestion from Steffie to add a new field to overcome this issue and do have the ability to read the calculated BOM price.
That's why I added comment 29 or do I oversee some other functional issues?

Revision history for this message
Stephane Wirtel (OpenERP) (stephane-openerp) wrote :

Hi all,

You will find the product_extended module in lp:openobject-addons/extra-6.0 and there is a bug fix.

Regards,

Revision history for this message
Ferdinand (office-chricar) wrote :

Hmm unfortunately I am not able to get any numbers
please see attachment - blue lines
IMHO these quantities AND values have to be shown to give a clear picture of "exlpoded" bom = all parts of the final product

Revision history for this message
Steffi Frank (Bremskerl, DE) (steffi-frank) wrote :

When working on a solution: please check https://bugs.launchpad.net/openobject-addons/+bug/705869 Printig 'Product Cost Structure' should should calculate /print through all levels as well - independed of the BoM type...

Revision history for this message
Bertrand Hanot (bertrand-hanot) wrote :
Download full text (3.2 KiB)

Fabien, Olivier, Antony, all,

Thanks for the clarification.

1. I agree this should not be the default behaviour of OpenERP, wether it's an option in the mrp module or a new functionnality brought by an extra module like product_extended is fine for me.

2. It's good to have product_extended available in V6. Thanks.

3. I understand the problem of legal or not legal calculation for cost price of a finished product. And i agree it's not because you update the price of a component of the BOM that the finished product cost price should be automatically updated.
BUT, you should have a mean to update it manually when required (i.e. once a year).
That's what product_extended is doing, but only for two levels not more.
Which is not usable for my customers. (i.e. one have around 100 level in its BOM). So we should have a kind of "compute all products cost price based on their BOM" method or something like that.

We could develop something like that from partner side but i think it's better to have it globalized and standardized from OpenERP.

So the bug i reported was not for OpenERP MRP module but for product_extended one... and it was not certified yet, sorry i didn't noticed it.
But now that it's certified, can you please re-consider to solve it to have n level of BOM calculated now ? :-)

________________________________________
From: <email address hidden> [<email address hidden>] On Behalf Of Antony Lesuisse [<email address hidden>]
Sent: Friday, April 01, 2011 00:04
To: Bertrand Hanot
Subject: [Bug 702288] Re: Cost price calculation limited to 2 levels in product bom

I said: think cost price should not be AUTOMATICALLY updated from cost
price of bom component. What could possibly go wrong... ?

This feature will go back in the product_extended module (or maybe a
specific mrp_bom_price one) and will be correctly implemented there.
Because i think there are different possible policies on how to do it
and that specific module should implement them all.

For example: Updating a price from bom children vs updating the parents
when a children is updated (but then what happens if a product is parent
of multiple bom with the same children and different coeficients?).

--
You received this bug notification because you are a direct subscriber
of the bug.
https://bugs.launchpad.net/bugs/702288

Title:
  Cost price calculation limited to 2 levels in product bom

Status in OpenERP Modules (addons):
  Invalid

Bug description:
  A concrete example better than a long and difficult explanation :-)

  We have the following product A composed of the product B and product B is composed from product C. So the below BOM:
  A
  -----B
  -----------C

  If the price of B is modified, then the price of A can be also modified.
  But if i modify the price of C, only B is modified and not A.

  This is a very important blocking issue, since in most of the real prod environment, we've of course more than 2 level of boms (in some customer installation, up to 100 levels !).
  So any modification at the bottom should have a consequence on all the bom structure until the top, else OpenERP cannot be used for production.

To unsubscribe from this bug, go to:
https://bugs.launchpad...

Read more...

Revision history for this message
conexus.at (conexus.at) wrote :

Hello,

may I ask about the current Status? I'm not sure if I missed something since April.

I know we can use the product_extended Module, but we then have to calculate the price for each bom manually.

Has there anything been done yet for calculation over n-levels of boms?

with kind regards,

Revision history for this message
Bertrand Hanot (bertrand-hanot) wrote :

Hi,

No update since april. I discussed this in further details with openerp and some partner during the community days, and this is one of the main priority in the mrp scope...

... but until now, no more details or planning.

Kind regards.

Bertrand.

________________________________________
From: <email address hidden> [<email address hidden>] On Behalf Of conexus.at [<email address hidden>]
Sent: Friday, July 01, 2011 12:28
To: Bertrand Hanot
Subject: [Bug 702288] Re: Cost price calculation limited to 2 levels in product bom

Hello,

may I ask about the current Status? I'm not sure if I missed something
since April.

I know we can use the product_extended Module, but we then have to
calculate the price for each bom manually.

Has there anything been done yet for calculation over n-levels of boms?

with kind regards,

--
You received this bug notification because you are subscribed to the bug
report.
https://bugs.launchpad.net/bugs/702288

Title:
  Cost price calculation limited to 2 levels in product bom

Status in OpenERP Modules (addons):
  Invalid

Bug description:
  A concrete example better than a long and difficult explanation :-)

  We have the following product A composed of the product B and product B is composed from product C. So the below BOM:
  A
  -----B
  -----------C

  If the price of B is modified, then the price of A can be also modified.
  But if i modify the price of C, only B is modified and not A.

  This is a very important blocking issue, since in most of the real prod environment, we've of course more than 2 level of boms (in some customer installation, up to 100 levels !).
  So any modification at the bottom should have a consequence on all the bom structure until the top, else OpenERP cannot be used for production.

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

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.