Make openerp inventory valuation IFRS compliant
Openerp has succeeded in many attributes but has fallen behind many other erp systems when it comes to financial accounting. Any company that is involved with trading of inventory or manufacturing needs to account for its inventory costs accurately, and will not be able to use openerp for their financial accounting if this is not the case.
Openerp 6.0 does not comply with IFRS or the older GAAP accounting standard in a multicompany environment.
IFRS is the most globally accepted accounting standard.
IFRS is legislatured in more than 80 countries around the world, (for details click here), Most countries have are moving this standard including EU,UK and US. IFRS only allows FIFO or AVCO (Average Cost) inventory valuations for financial accounting. Standard costing and LIFO are not compliant with IFRS’s financial reporting. Most governments do not accept LIFO or standard costing as it underestimates the company’s profit and hence its tax liability to the government.
Here is a brief explanation: (http://www.osbornebooks.co.uk/files/a2_stock_valuation.pdf)
METHODS OF STOCK VALUATION
The difficulty in stock valuation is in finding out the cost price of stock – this is not easy when
quantities of a particular stock item are continually being bought in – often at different prices – and
then sold. Some companies have stock in a number of different forms, eg a manufacturer may well
have stocks of raw materials, work-in-progress and finished goods.
IAS 2, Inventories, allows companies to use one of two methods to calculate the cost price of their
FIFO (first in, first out)
In this method, the first (oldest) stocks acquired are assumed to be used first. This means that the
stock on hand at any time is assumed to consist of the most recently acquired items.
AVCO (average cost)
In this method, the weighted average cost of items held at the beginning of the year is calculated,
using the formula:
weighted average cost = total cost of goods in stock
number of items in stock
The weighted average cost is then used to value goods sold. A new weighted average cost must be
calculated each time that further stocks are bought during the year.
Openerp 6.0's "Average Cost" fails to work in a multicompany environment.
The problem is that openerp only caters for a product having one cost, even though it is shared between multiple companies. The product should be able to have separate costs in each company. Each company can buy the same product at different prices creating different average costs for that product in each company.
At the moment, openerp only has one cost for a product which is shared between different companies.
Please see the example below: For instance:
Create a shared product in Head office (HO)
The problem is:
If Branch 1 buys a product at EURO 10 the average cost is EURO 10. Branch 2 then buys the same product at EURO 20, this changes the cost of Branch 1 incorrectly to EURO 20.
This is wrong. Branch 1's cost should still be EURO 10, and not overwritten to EURO 20.
Cost for Branch 1 should be EURO 10 and Cost for Branch 2 should be EURO 20.
It is important for Openerp that the accounting of trading stock be calculated correctly. These are fundamental building blocks to making openerp a successful product.
As an openerp partner we cannot implement inventory into a multicompany or branch environment, where other erp providers are able to.
Do you have an idea if you will be implementing this, or whether it has been implemented in other installations.
Thank you for your insight in advance.
Emililiyan Tanev commented
Is there any information regarding this issue?
Joana Mateus commented
Any news in this matter? we're having problems with sharing partners and products in a multi company enviroment..
according to wikipedia.org these countries have adopted IFRS
* Ecuador is also adopting IFRS.
I can not find any information about this capability of openerp and it seems that it doesn't have it, but I would like to be confirmed.
http://db.tt/ZfUh1Ew for reference. This from NZ Institute of Chartered Accountants IFRS and Differential Financial Reporting Standards Manual. Sorry had to photocopy, they only give us the templates electronically, not the specification - NZ while not fully adopted IFRS - the inventory clauses are identical.
Sorry the implication for manufacturing is that you need to maintain as a minimum a standard and either a FIFO or AVCO
I am glad to see this raised but this is only partially correct, in fact I read the document referenced and it is like it started halfway through the standard.
IFRS allows and in fact only allows actual costing where inventory items are not interchangeable. Additionally where an item is identifiable it recommends actual costing. It is in fact the first method specified and other methods are ONLY allowed where this is not practical.
Where a subset of goods is interchangeable or identifiable as a group then FIFO or AVCO of that group is acceptable where specific items cannot be identified (e.g. items from the same production lot). Additionally this specification does not refer to manufactured goods, for which it is impossible to use FIFO, AVCO or a true actual cost. This is because the cost must be estimated on expected total volumes to take in to account production overheads, and those production overheads must be systematically allocated to inventory and COGS. So in that case we use standard cost, and manage variances, adjusting standard price as input costs change.
Now in practice when it comes to selling of homogenous manufactured inventory we end up using an average of standard costs or FIFO at standard cost. And where goods are individually identifiable we use the standard cost as the actual cost.
Paraphrased from NZ IFRS and IFRS Differential Reporting Manuals sections - Inventory Valuation.
We have done most of the work in making our own implementation compliant, but it required a lot of changes, so many that we did not release publicly because it changes so much.
e.g. Cost Price is a property field of product. (as opposed to general float field of product.template)
New cost methods.
Storing costs against production lot (not necessary but computationally expensive not to)
Storing price_unit against all stock moves
Changing price fetching functions to take location in to context. (to handle branch and many other scenarios where property field fails)
Changing about 40 other modules to be compliant.