c2c-oerpscenario team mailing list archive
-
c2c-oerpscenario team
-
Mailing list archive
-
Message #26218
Re: [Bug 778170] Re: product - average and standard cost not multicompany
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)" <778170@xxxxxxxxxxxxxxxxxx>
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
--
You received this bug notification because you are a member of C2C
OERPScenario, which is subscribed to the OpenERP Project Group.
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
References