product - list price, average and standard cost are not multicompany capable

[Graeme Gellatly]

To reproduce, create some companys

say HQ with child Company A and Company B
create a product which is visible in all company at Average cost

Receive product in Company A.
Average Cost updates correctly in Company A.
but it also updates Company B and parent.

For standard price just go to company B and change a standard price product and it will propagate throughout

Surely in a multicompany environment we must allow for different cost prices for each company. And if using average cost it is clearly incorrect to take the average cost of another company (or the combined results) as your own average cost. As a side note we must also allow different companies to use different cost methods for the same products. Additionally it violates all sorts of security rules - a company B user should not be able to affect the accounts of Company A and these 2 fields determine the values for a very large number of journal entries.

[Amit Parik (amit-parik)]

Hello,

This feature is not supported in OpenERP currently So we need to more discussion on this.
So Currently I am set it as a "Triaged".

Thanks

[Olivier Dony (Odoo) (odo-openerp)]

Hello Graeme,

Indeed, sharing a single product in average cost mode between multiple companies is not yet supported in OpenERP v6.0, nor is having different cost prices depending on the company. For such cases, we currently recommend duplicating the products, to avoid the obvious side effects you mentioned (duplicating should not disrupt the product list if each product is only visible in its own company).

In the future we plan to support this by making the cost (and public price) property fields, so they may be different in each company, like the G/L accounts. Perhaps the costing method could be a per-company property too, though I'm not sure this makes sense... What about per-company procurement/supply method, or per-company UoM, etc? At some point the product will turn out to be an empty shell with just a name, making the software more complicated and harder to maintain, for no good reason (people could just make multiple products with the same name).

Anyway, we are discussing these options within R&D, so any additional feedback on this is welcome.

Note that this will certainly require major technical changes in many dependencies, algorithms and reports, so it cannot be done in 6.0 (normal fields and property fields are quite different beasts).

Thanks for your feedback!

[Graeme Gellatly (gdgellatly)]

Regard supply method, I did indeed make this a property field for
multicompany however in fact this is unnecessary. The workflow methods check
produce and check buy handle this scenario without change. Regard costs an
important first step is to move cost out of template and in to product.
This removes 1 layer of error. I think then we need to look at costing
methods. Interestingly I wrote an internal module to do actual costing. It
was only about 70 lines of code but because it was based on prodlot and
location the side effect is that it works for multicompany. Fifo would be
similar.

Regards different costing methods per company, I was with an opw customer
this week and they have this requirement but worse. Their operations team
works on standard but sales on average cost within the same company. Now
they had a bunch of modules (certified only) and while I don't know which it
was it looked partially supported. I'll look closer when I get back to nz.

I actually think this problem might be quite easily solvable

On 2011-06-11 12:15 AM, "Olivier Dony (OpenERP)" <email address hidden>
wrote:

Hello Graeme,

Indeed, sharing a single product in average cost mode between multiple
companies is not yet supported in OpenERP v6.0, nor is having different
cost prices depending on the company. For such cases, we currently
recommend duplicating the products, to avoid the obvious side effects
you mentioned (duplicating should not disrupt the product list if each
product is only visible in its own company).

In the future we plan to support this by making the cost (and public
price) property fields, so they may be different in each company, like
the G/L accounts. Perhaps the costing method could be a per-company
property too, though I'm not sure this makes sense... What about per-
company procurement/supply method, or per-company UoM, etc? At some
point the product will turn out to be an empty shell with just a name,
making the software more complicated and harder to maintain, for no good
reason (people could just make multiple products with the same name).

Anyway, we are discussing these options within R&D, so any additional
feedback on this is welcome.

Note that this will certainly require major technical changes in many
dependencies, algorithms and reports, so it cannot be done in 6.0
(normal fields and property fields are quite different beasts).

Thanks for your feedback!

--
You received this bug notification because you are subscribed to the bug
report.

https://bugs.launchpad.net/bugs/778170

Title:

product - average and standard cost not multicompany

Status in OpenERP Modules (addons):
 Triaged

Bug description:
To reproduce, create some companys

say HQ with child Company A and Company B
...
To manage notifications about this bug go to:
https://bugs.launchpad.net/openobject-addons/+bug/778170/+subscriptions

[Kevin McMenamin (kevin-mcmenamin)]

There is a further layer of error with how the application works at present. Work through the following - multicompany Coy A & Coy B, brand new stock item but shared across the group.

Coy A buys 10 @ $100 and receipts.
Accounting entries
DR Finished Goods 1000
DR GST 150
CR Creditors 1150

SOH 10 @ 100.00 = $1000

All correct.

Coy B buys 1 @ $200 and receipts
Accounting entries
DR Finished Goods 200
DR GST 30
CR Creditors 230

SOH = 1 @ $200

All correct within this company

Now log on as parent - group position is

Balance Sheet:
Finished Goods 1200
GST 180
Creditors 1380

Inventory
SOH = 11 @ $200 $2200 (********* no longer agrees with balance sheet)

Log on as Coy 1 user and process a sale for 1 unit @ $300. Entries created:

DR Debtors 345
DR Cost of Sales 200 (************* at the wrong rate!)
CR GST 45
CR Finished Goods 200 (************* at the wrong rate)
CR Sales 300

Coy1 SOH now 9 @ $200 which does not agree to balance sheet.

The idea of having to duplicate ~20,000 products across 12 companies within a group seems to me to be fraught with issues (not to mention the workload).

Is there a proposed timeline on fixing this?

[Kevin McMenamin (kevin-mcmenamin)]

I actually created a new bug reference 803717 before I found this - there is a spreadsheet with all the detailed working attached to that reference

[Olivier Dony (Odoo) (odo-openerp)]

Note: bug 803717 was marked as duplicate of this one, see further examples/details there.

Kevin, there is no timeline yet for changing this, as it requires a global review of all related product pricing code. We will post it here when we know a time frame for it. However it may be possible to make smaller patches for enabling your specific use case, perhaps Graeme has some further feedback to give about that, I think he's been working on related patches lately.

[Olivier Dony (Odoo) (odo-openerp)]

See also this feeback entry by Michael, with interesting IFRS material and further examples: http://feedback.openerp.com/forums/77459-general-improvements/suggestions/1944011-make-openerp-inventory-valuation-ifrs-compliant

[Graeme Gellatly (gdgellatly)]

Thanks Olivier,

I have added comments and corrections.

On Fri, Jul 15, 2011 at 4:10 AM, Olivier Dony (OpenERP) <
<email address hidden>> wrote:

> See also this feeback entry by Michael, with interesting IFRS material
> and further examples: http://feedback.openerp.com/forums/77459-general-
> improvements/suggestions/1944011-make-openerp-inventory-valuation-ifrs-
> compliant
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/778170
>
> Title:
> product - average and standard cost not multicompany
>
> Status in OpenERP Modules (addons):
> Triaged
>
> Bug description:
> To reproduce, create some companys
>
> say HQ with child Company A and Company B
> create a product which is visible in all company at Average cost
>
> Receive product in Company A.
> Average Cost updates correctly in Company A.
> but it also updates Company B and parent.
>
> For standard price just go to company B and change a standard price
> product and it will propagate throughout
>
> Surely in a multicompany environment we must allow for different cost
> prices for each company. And if using average cost it is clearly
> incorrect to take the average cost of another company (or the combined
> results) as your own average cost. As a side note we must also allow
> different companies to use different cost methods for the same
> products. Additionally it violates all sorts of security rules - a
> company B user should not be able to affect the accounts of Company A
> and these 2 fields determine the values for a very large number of
> journal entries.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/openobject-addons/+bug/778170/+subscriptions
>

[Olivier Dony (Odoo) (odo-openerp)]

I marked bug 815436 as a duplicate. It was raising the multicompany question for cost price, but also for list price, so I broadened a bit the title of the current bug - these issues seem quite related to me, aren't they?

[Graeme Gellatly (gdgellatly)]

I think list price should be treated seperately but evaluated at the same
time. The reasoning here is quite simple.

The issue with cost price is not its value per se. It is in the calculation
of its value and the errors this introduces in to our accounts. In fact
what we are really saying is inventory valuation methods are not
multi-company. Also the situation is much more critical for costs than it
is for list price. With costs we also have a broader issue in the inventory
valuation methods themselves. It would be a shame if in fixing this issue,
we ignore the relatively little extra effort to implement FIFO and actual
costing methods.

Afterall, list price is not used directly, we use pricelists, which can be
based off list price so a very valid workaround exists in the rarer
situation where list prices are different, without making product creation
overly onerous, where they are all the same. (Imagine 9 companies, having
to create 9 list prices each time (and all the same), whereas with cost
price if using average there is no setup required) In fact even when list
prices differ, I'd argue the pricelist workaround is actually easier to
implement for the end user. This relates back to the other mail I sent you
where list price, and list pricelist are really synonymous and should be
treated that way. But equally there are some other seperate areas where
list price and its associated lst_price in product.product are used
differently to how standard_price is used.

Also as said before, the issue for cost is not just multicompany, it is also
shop and warehouse related as different shops will have different costs.
 This is simple for list price, as we assign pricelists to shops so I would
argue that while it is not directly obvious, the workaround is already
implemented and used.

On Wed, Jul 27, 2011 at 11:04 AM, Olivier Dony (OpenERP) <
<email address hidden>> wrote:

> I marked bug 815436 as a duplicate. It was raising the multicompany
> question for cost price, but also for list price, so I broadened a bit
> the title of the current bug - these issues seem quite related to me,
> aren't they?
>
> ** Summary changed:
>
> - product - average and standard cost not multicompany
> + product - list price, average and standard cost are not multicompany
> capable
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/778170
>
> Title:
> product - list price, average and standard cost are not multicompany
> capable
>
> Status in OpenERP Modules (addons):
> Triaged
>
> Bug description:
> To reproduce, create some companys
>
> say HQ with child Company A and Company B
> create a product which is visible in all company at Average cost
>
> Receive product in Company A.
> Average Cost updates correctly in Company A.
> but it also updates Company B and parent.
>
> For standard price just go to company B and change a standard price
> product and it will propagate throughout
>
> Surely in a multicompany environment we must allow for different cost
> prices for each company. And if using average cost it is clearly
> incorrect to take the average cost of another co...

[Graeme Gellatly (gdgellatly)]

1 more issue to think about. Lets say we do go multicompany in some way.
 Do we also now need to consider multi currency?

On Wed, Jul 27, 2011 at 3:57 PM, Graeme Gellatly <email address hidden>wrote:

> I think list price should be treated seperately but evaluated at the same
> time. The reasoning here is quite simple.
>
> The issue with cost price is not its value per se. It is in the
> calculation of its value and the errors this introduces in to our accounts.
> In fact what we are really saying is inventory valuation methods are not
> multi-company. Also the situation is much more critical for costs than it
> is for list price. With costs we also have a broader issue in the inventory
> valuation methods themselves. It would be a shame if in fixing this issue,
> we ignore the relatively little extra effort to implement FIFO and actual
> costing methods.
>
> Afterall, list price is not used directly, we use pricelists, which can be
> based off list price so a very valid workaround exists in the rarer
> situation where list prices are different, without making product creation
> overly onerous, where they are all the same. (Imagine 9 companies, having
> to create 9 list prices each time (and all the same), whereas with cost
> price if using average there is no setup required) In fact even when list
> prices differ, I'd argue the pricelist workaround is actually easier to
> implement for the end user. This relates back to the other mail I sent you
> where list price, and list pricelist are really synonymous and should be
> treated that way. But equally there are some other seperate areas where
> list price and its associated lst_price in product.product are used
> differently to how standard_price is used.
>
> Also as said before, the issue for cost is not just multicompany, it is
> also shop and warehouse related as different shops will have different
> costs. This is simple for list price, as we assign pricelists to shops so I
> would argue that while it is not directly obvious, the workaround is already
> implemented and used.
>
>
> On Wed, Jul 27, 2011 at 11:04 AM, Olivier Dony (OpenERP) <
> <email address hidden>> wrote:
>
>> I marked bug 815436 as a duplicate. It was raising the multicompany
>> question for cost price, but also for list price, so I broadened a bit
>> the title of the current bug - these issues seem quite related to me,
>> aren't they?
>>
>> ** Summary changed:
>>
>> - product - average and standard cost not multicompany
>> + product - list price, average and standard cost are not multicompany
>> capable
>>
>> --
>> You received this bug notification because you are subscribed to the bug
>> report.
>> https://bugs.launchpad.net/bugs/778170
>>
>> Title:
>> product - list price, average and standard cost are not multicompany
>> capable
>>
>> Status in OpenERP Modules (addons):
>> Triaged
>>
>> Bug description:
>> To reproduce, create some companys
>>
>> say HQ with child Company A and Company B
>> create a product which is visible in all company at Average cost
>>
>> Receive product in Company A.
>> Average Cost updates correctly in Company A.
>> but it also updates Company B and parent.
>>
>> For s...

[Joël Grand-Guillaume @ camptocamp (jgrandguillaume-c2c)]

Hi all,

I just want to share my experience here as I already implement part of that in OpenERP 5.0... Let's start with a state-of-the-art summary :

1) I completely agree with Graeme : The list price is less important here, we do have a workaround that make it well enough for now : making different price lists

2) We do want to handle one product stock quantity for all company (actually work), but different costs price per company (this is missing)

3) We want to manage multi-currency in product costs (actually working with one currency and cost per company)

4) We want to be FIFO/LIFO compliant for future version

5) We want the average price to compute correctly for each company

Already tested solution :
---------------------------------
a) Add a price_type field on the company as a property field, defining the product field and currency to use for costing operation in this company (by default : standard_price, EUR).

b) Add as many float field on the product as different costs price & currency

c) Change all computation and on_change everywhere where it is needed (finance, analytic, stock, ...) to take the right price for each company and make the right currency rate convertions.

d) Add an historic_amount float field in the stock move to store the historical amount of the operations.

PLUS/CONS:
----------------
 + Very simple, may be the simplest one
 + Very easy to update (import/export) a cost price, you have as many field as value
 + Usability is good : cost manager can see all cost on a product tab
 + Can compute a average price per company
 + The historic_amount in stock move allow to recompute everything in any case

 - One field per price could be bad if lots of company and difference cost price
 - ?

Others possible solution:
--------------------------------
a) Idem that the first solution, but with a price list field as a property on the company as well as a new price list type "costing"

PLUS/CONS:
----------------
 + Allow complex rule for price costing (but is this really needed ?)
 + Usability is good : cost manager can see all cost on a product tab
 + Can compute a average price per company
 + The historic_amount in stock move allow to recompute everything in any case

 - More difficult to update and see prices than first solution as stored in price list
 - More power required to compute cost as we'll use the compute method of price list

b) We make the standard price a property field and change everything else accordingly and Add an historic_amount float field in the stock move to store the historical amount of the operations.

PLUS/CONS:
----------------
 + One "multi"/property field for all company
 + Can compute a average price per company

 - No support for multi-cunrrency here, all cost will be in a same currency for all company
 - More difficult to update (import/export) and see prices
 - Very hard to work to achieve, lots of changes and side effect to be expected

I have to leave now, I hope this helps a bit !

Regards,

Joël

[Amit Parik (amit-parik)]

Hello Folks,

The same type of issue reported on lp:1068037 and there is one good suggestion, So we can check it on lp:1068037.

Thanks!