Comment 21 for bug 702288
Revision history for this message
| Fabien (Open ERP) (fp-tinyerp) wrote | #21 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
bbfa235
(Get the code!)
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_
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. This module is not quality certified and I don't know if it has been ported to v6 or not. That's why it's not covered by the OPW and that's why antony said it's a missing feature, not a bug.
The product_extended module allows to decide, product per product if you compute the cost price based on the BoM or not. If yes, you have buttons in the product form (or an action on a whole list) that allows to recompute the standard price on demand (usually once a year when you do your stock valuation, and not when a raw material's price change). This method is clean because you choose how and when you want to update cost price per product and that's very important if your accounting is audited.
What we will do
-------
Fix this bug: https:/
As we have two OPW customers that reported this need we will develop the product_extended module for v6, even if it's not covered by certified modules.
I propose to keep this bug as invalid as the discussion at the top of this bug may confuse the developers that will work on it. (unless I am wrong, then we rediscuss)