Hi Thosten,
I put back the community on the loop.
I understand your method which is clearly correct in some cases
but directly avoid to use multi-company for the implementation.
This is an option but does not answer all implementation cases.
For business reasons, in China/HK/Macau, we have many customers
that use an operating company in China and accounting company in
HK for trading. Usually the HK company staff is light and
companies share most of the information (products, users,
customers etc.). It is not possible to think about duplicating
them when OpenERP is supposed to do the trick ("OpenERP is
multi-company" isn't it?).
We are thinking of developing ICOPS (inter-company process)
modules similar to sale_intercompany but more generic and
focussing on SO/PO automatic creation, invoicing and stock moves
automatic matching.
Best regards
Eric Caudal
CEO
--
Elico Corporation, Shanghai branch
OpenERP Premium Certified Training Partner
Cell: + 86 186 2136 1670
Office: + 86 21 6211 8017/27/37
Skype: elico.corp
[email protected]
http://www.elico-corp.com
On 03/23/2013 08:55 PM, Thorsten Vocks wrote:
Hi Eric,
this slides of OpenERP consultant Francois Pietquin explains
more about coverage of standard multi-company.
OpenERP covers the basics for it, nothing more and nothing
less:
I usually ask very intense what customers wants to do with a
"multi-company" setup.
Do they only want to share some data like product catalogue,
customers / suppliers in one database,
consilidation of balance sheet and P+L, this simple multi
company feature can be enough.
For the purpose of stock valuation, intercompany accounting
transaction there is indeed more to think about,
as your example shows. I have proposed in two multi-company
projects to use two separate databases for their
specific multi company scenario.
Exchange between 2 databases product catalogues, addresses
then have to be done in a different way
(pentaho kettle , or base_synchro module). For intercompany
exchange of orders, deliveries and invoices i proposed to
use the new EDI features (introduced with 6.1). It means
cross-over interchange of orders,
invoices and so on. Each company is represented by their own
unique email adress (
[email protected],
[email protected],
....) and this hub systems controls intercompany exchange of all
relevant business
documents.To my opinion stock valuation, cost price
calculation is easier in different databases. To be forced to
use
the email hub ensures a bit more to be compliant with tax
rules ("nearlly physical" exchange of invoices, orders) and it
needs
manual intervention (like opening the envelope with invoice
inside you have to open the email ).
Another benefit of such separated databases is reduction of
errors. Users are not good protected against that in one
database, especially the employees in accounting having to do
the intercompany account moves. The configuration of user rights
is more straight forward and more clearly separated in two (or
more) seprate databases. Consolidation of different balances
shouldn't be a big deal outside of OpenERP (for instance OLAP).
But in general Nhomar is totally right. For
sure I forgot to mention all the drawbacks (for instance
redundant users have to login / logout in several databases) and
it usually means some double work. My decision to propose such
"workaround" solutions was either driven by a lack of
functionality or my fear against such difficult open heart
surgeries. Last not least decision should
depend of accountants qualification in the company itself.
OpenERP accounting is currently not entirely foolproof even in
a one company scenario;-)
modules.
Best Regards
