Why not killing company?

[Cédric Krier]

Hi,

Following my attempt to improve the situation of multi-company [1], I
faced so much problem that I only see to solution:

- a very complicate one where many things will become a list per
company. For example on product, the prices, the accounts etc.
This will make the code very complicate but also the user
interface.

- a very simple, drop company.


I start thinking that the last one is the right move even if it will
prevent none single company database to migrate.

What are the use case of multi-company?

- accounting consolidation

It is a reporting issue that should be fixed by BI

- sharing party

That's a good one if you forget that parties have many properties
directly linked to the company like the accounts, tax rules etc.
And I think this can be acheived by using a synchronisation of the
common data using for example the CardDAV or any other similar
protocol.

- sharing product

Quite similar to party expect that it has much more company related
properties.
So again it could be implemented using a synchronisation mechanism.
I know there are product description message in EDI, so it could be
a way.

I don't see any other cases.

So when I imagine the simplification of removing the company, I really
think it deserve the annoyance of breaking the migration.
And for such cases, a way to go could be to duplicate the DB and drop on
each the other the companies.


[1] https://bugs.tryton.org/issue4080

--
Cédric Krier - B2CK SPRL
Email/Jabber: cedric...@b2ck.com
Tel: +32 472 54 46 59
Website: http://www.b2ck.com/

[Sebastián Marró]

Hi

2014-09-11 7:37 GMT-03:00 Cédric Krier <cedric...@b2ck.com>:

Hi,

Following my attempt to improve the situation of multi-company [1], I
faced so much problem that I only see to solution:

    - a very complicate one where many things will become a list per
      company. For example on product, the prices, the accounts etc.
      This will make the code very complicate but also the user
      interface.

    - a very simple, drop company. 

I start thinking that the last one is the right move even if it will
prevent none single company database to migrate.

That could be a huge problem for a multi company instance in production that we have.

 

What are the use case of multi-company?

- accounting consolidation

    It is a reporting issue that should be fixed by BI

Ok, but it's not the same as open a custom account consolidation report in the Tryton client

 

- sharing party

    That's a good one if you forget that parties have many properties
    directly linked to the company like the accounts, tax rules etc.
    And I think this can be acheived by using a synchronisation of the
    common data using for example the CardDAV or any other similar
    protocol.

- sharing product

    Quite similar to party expect that it has much more company related
    properties.
    So again it could be implemented using a synchronisation mechanism.
    I know there are product description message in EDI, so it could be
    a way.

Those synchronisation solutions don't seem to be trivial

 

I don't see any other cases.

- sharing users

- sharing groups

Very important for the IT department, if you have many of them.

So when I imagine the simplification of removing the company, I really
think it deserve the annoyance of breaking the migration.
And for such cases, a way to go could be to duplicate the DB and drop on
each the other the companies.

I think that not supporting multi company in Tryton is a step back and that this will prevent migration to new versions.

Regards

 
Sebastián Marró

Thymbra

[Cédric Krier]

On 11 Sep 11:58, Sebastián Marró wrote:
> 2014-09-11 7:37 GMT-03:00 Cédric Krier <cedric...@b2ck.com>:
>
> > Hi,
> >
> > Following my attempt to improve the situation of multi-company [1], I
> > faced so much problem that I only see to solution:
> >
> > - a very complicate one where many things will become a list per
> > company. For example on product, the prices, the accounts etc.
> > This will make the code very complicate but also the user
> > interface.
> >
> > - a very simple, drop company.
>
>
> >
> > I start thinking that the last one is the right move even if it will
> > prevent none single company database to migrate.
> >
>
> That could be a huge problem for a multi company instance in production
> that we have.
>
>
> >
> > What are the use case of multi-company?
> >
> > - accounting consolidation
> >
> > It is a reporting issue that should be fixed by BI
> >
>
> Ok, but it's not the same as open a custom account consolidation report in
> the Tryton client

Nothing prevents to open the BI from Tryton client.

> >
> > - sharing party
> >
> > That's a good one if you forget that parties have many properties
> > directly linked to the company like the accounts, tax rules etc.
> > And I think this can be acheived by using a synchronisation of the
> > common data using for example the CardDAV or any other similar
> > protocol.
> >
> > - sharing product
> >
> > Quite similar to party expect that it has much more company related
> > properties.
> > So again it could be implemented using a synchronisation mechanism.
> > I know there are product description message in EDI, so it could be
> > a way.
> >
>
> Those synchronisation solutions don't seem to be trivial

I don't think so because we are talking about referencial data only.
As far as you define a master that even become simplier.
And for the record, CardDAV is designed to be used for synchronisation.

> >
> > I don't see any other cases.
> >
>
> - sharing users

Can be done via LDAP.

> - sharing groups

Indeed this is an other failure of the current design.
Why would a user have the same rights on every company.
Anyway, such configuration could be managed by extending the LDAP
module.

> Very important for the IT department, if you have many of them.

> > So when I imagine the simplification of removing the company, I really
> > think it deserve the annoyance of breaking the migration.
> > And for such cases, a way to go could be to duplicate the DB and drop on
> > each the other the companies.
> >
>
> I think that not supporting multi company in Tryton is a step back and that
> this will prevent migration to new versions.

multi-company is also a brake to improvement, to scalibility and to user
experience.
Indeed a little bit like the multi-database.

[Sebastián Marró]

multi-company is also a brake to improvement, to scalibility and to user
experience.
Indeed a little bit like the multi-database.

Ok, i like improvement, scalability and better user experience. But i think we will need a clear path to follow for the current multi-company instances upgrades.

[Cédric Krier]

And this one I propose is not good?

[Axel Braun]

Am Donnerstag, 11. September 2014 12:37:33 UTC+2 schrieb Cédric Krier:

Hi,

Following my attempt to improve the situation of multi-company [1], I
faced so much problem that I only see to solution:

    - a very complicate one where many things will become a list per
      company. For example on product, the prices, the accounts etc.
      This will make the code very complicate but also the user
      interface.

    - a very simple, drop company.


I start thinking that the last one is the right move even if it will
prevent none single company database to migrate.

Oops. We are just in the step to move to a multi-company approach...

 

What are the use case of multi-company?

- accounting consolidation

    It is a reporting issue that should be fixed by BI

- sharing party

    That's a good one if you forget that parties have many properties
    directly linked to the company like the accounts, tax rules etc.
    And I think this can be acheived by using a synchronisation of the
    common data using for example the CardDAV or any other similar
    protocol.

You may have a syncronization, but not an integration.
Integration would mean that some common information is held at the client level, while each company has a separate segment e.g. with specific sales or accounting information.
 

- sharing product

    Quite similar to party expect that it has much more company related
    properties.
    So again it could be implemented using a synchronisation mechanism.
    I know there are product description message in EDI, so it could be
    a way.

I don't see any other cases.

intercompany trades and billing for example
cross-company sourcing (one sourcing department servers several companies)

I feel this move would limit the capabilities of Tryton. And the companies using Tryton.

Cheers/Axel

[Cédric Krier]

On 12 Sep 06:26, Axel Braun wrote:
> > What are the use case of multi-company?

> > - sharing party
> >
> > That's a good one if you forget that parties have many properties
> > directly linked to the company like the accounts, tax rules etc.
> > And I think this can be acheived by using a synchronisation of the
> > common data using for example the CardDAV or any other similar
> > protocol.
> >
>
> You may have a syncronization, but not an integration.
> Integration would mean that some common information is held at the client
> level, while each company has a separate segment e.g. with specific sales
> or accounting information.

I don't understand.
What information at the client level?

> >
> > - sharing product
> >
> > Quite similar to party expect that it has much more company related
> > properties.
> > So again it could be implemented using a synchronisation mechanism.
> > I know there are product description message in EDI, so it could be
> > a way.
> >
> > I don't see any other cases.
> >
>
> intercompany trades and billing for example

This should be managed with by preference EDI. Because for each document
on one side, you have to create one on the other side but of course it
could be validated automatically.

So clearly, this doesn't require at all to be on the same database.
Moreover, if someone develop such feature, it will work for companies on
the same hosts but also across any network. So this will be a truly
generic solution.

> cross-company sourcing (one sourcing department servers several companies)

I don't understand.

[Dominique Chabord]

hello

I've never seen, up to now, a sane use of multi-company
As far as business applisation is concerned, I don't even think it can
be a legal approach in EU. Group reports are the worst reason to do
it.

As Sebastian explained, there is a problem to move existing
multi-companiy solutions.
He may also elaborate on the reasons multi-company has been adopted
despite all its drawbacks.

Axel, if you planned to use it, why did you ?

regarding my positive experience of it :

- I know of a project for a cooperative company for which a
verticalization has been done; This used similar approach to
multi-company, but it was not multi-company
- I get sometimes the requirement for "multi-branding" business which
make the company appear under different brands depending on the
channel.

Multi-company has been a big reason of failure for many projects where
it just cannot fit.
- Group level reports are the worst reason to do it.
- Shared operations (one sells, one buys) just cannot be done with it.

regards

[Axel Braun]

Am Freitag, 12. September 2014, 15:50:57 schrieb Cédric Krier:
> On 12 Sep 06:26, Axel Braun wrote:
> > > What are the use case of multi-company?
> > > - sharing party
> > >
> > > That's a good one if you forget that parties have many properties
> > > directly linked to the company like the accounts, tax rules etc.
> > > And I think this can be acheived by using a synchronisation of the
> > > common data using for example the CardDAV or any other similar
> > > protocol.
> >
> > You may have a syncronization, but not an integration.
> > Integration would mean that some common information is held at the client
> > level, while each company has a separate segment e.g. with specific sales
> > or accounting information.
>
> I don't understand.
> What information at the client level?

Information on the client level can be something that is valid for all
companies, like name of the product, size & weight, EAN-code, product
hierarchy, indicators, e.g. for dangerous goods etc.

On plant or sales region / company level you may have sales unit of
measurement, tax codes or tax rules, minimum order quantities etc.

By this you have integration on many information, but separate values for
companies where it is required

> > > - sharing product
> > >
> > > Quite similar to party expect that it has much more company related
> > > properties.
> > > So again it could be implemented using a synchronisation mechanism.
> > > I know there are product description message in EDI, so it could be
> > > a way.
> > >
> > > I don't see any other cases.
> >
> > intercompany trades and billing for example
>
> This should be managed with by preference EDI. Because for each document
> on one side, you have to create one on the other side but of course it
> could be validated automatically.

I would avoid EDI as much as I could. Complicated, expensive and error-prone
unless you have tested it out completely. And requires additional EAI-software
resp EDI converter

> So clearly, this doesn't require at all to be on the same database.
> Moreover, if someone develop such feature, it will work for companies on
> the same hosts but also across any network. So this will be a truly
> generic solution.
>
> > cross-company sourcing (one sourcing department servers several companies)
>
> I don't understand.

You have a couple of sales companies, who do their sourcing via a central
souring company or department, in order to take advantage from economies of
scale. Physically they (the sales companies) may share the same warehouse, but
sell for a different price. Example: small franchise chain with web-sales. all
different legal units but from supply chain perspective with shared services.
Quite a comon model nowadays.

HTH
Axel

[Axel Braun]

Am Freitag, 12. September 2014, 16:29:28 schrieb Dominique Chabord:
> Axel, if you planned to use it, why did you ?

As I just wrote, economies of scale

[Dominique Chabord]

Le 12/09/2014 16:52, Axel Braun a écrit :>

>
> Information on the client level can be something that is valid for all
> companies, like name of the product, size & weight, EAN-code, product
> hierarchy, indicators, e.g. for dangerous goods etc.

I don't think you use the right word.
These elements are global, but have no reason to be at a client level.

>
> On plant or sales region / company level you may have sales unit of
> measurement, tax codes or tax rules, minimum order quantities etc.
>
> By this you have integration on many information, but separate values for
> companies where it is required

Not sure I understand. Do you mean that managing several companies can
be complex ? or something else ?

>
> I would avoid EDI as much as I could.

EDI is the only official approach to do it

Complicated, expensive and error-prone
> unless you have tested it out completely.

My perception is exactly the opposite. The standard is safe and
proven. If we follow it we cannot get it wrong.

And requires additional EAI-software
> resp EDI converter

Any solution requires converter and EAI

>
>> So clearly, this doesn't require at all to be on the same database.

?? I don't get this point.

>> Moreover, if someone develop such feature, it will work for companies on
>> the same hosts but also across any network. So this will be a truly
>> generic solution.

Do you mean EDI is a generic solution ? Yes, it works also if some
companies don't use Tryton.

>
> You have a couple of sales companies, who do their sourcing via a central
> souring company or department, in order to take advantage from economies of
> scale. Physically they (the sales companies) may share the same warehouse, but
> sell for a different price. Example: small franchise chain with web-sales. all
> different legal units but from supply chain perspective with shared services.
> Quite a comon model nowadays.

This is a typical example why EDI is useful and effective. Regarding
stock management, you cannot share a stock between several companies
in France. I guess the same in EU. Shared service is allowed if you
know to which company belongs any good in the warehouse.

>
> HTH
> Axel
>
>

[Dominique Chabord]

I don't understand this point. (I run several thousands of openerp and
tryton businesses and may miss it.)

[Cédric Krier]

On 12 Sep 16:29, Dominique Chabord wrote:
> hello
>
> I've never seen, up to now, a sane use of multi-company
> As far as business applisation is concerned, I don't even think it can
> be a legal approach in EU. Group reports are the worst reason to do
> it.

> As Sebastian explained, there is a problem to move existing
> multi-companiy solutions.

Indeed I really think it is doable to split such DB into many DB.

- make a copy of the DB for each company
- add delete cascading on all company foreign key
- delete all but one company
- remove the delete cascading
- update the DB

now you have a single-copany DB.
Indeed, I think the migration of Tryton should check if there are no
more than 1 company.

> regarding my positive experience of it :
>
> - I know of a project for a cooperative company for which a
> verticalization has been done; This used similar approach to
> multi-company, but it was not multi-company

And what was it?

> - I get sometimes the requirement for "multi-branding" business which
> make the company appear under different brands depending on the
> channel.

That's just about customization of report/header etc.

> Multi-company has been a big reason of failure for many projects where
> it just cannot fit.
> - Group level reports are the worst reason to do it.

Can you explain "Group reports"?

> - Shared operations (one sells, one buys) just cannot be done with it.

Can you ellaborate?

[Albert Cervera i Areny]

2014-09-11 12:37 GMT+02:00 Cédric Krier <cedric...@b2ck.com>:

I think the proposed simplification provides nice of advantages when
developing new modules and part of trytond including completely
removing fields.Property without the need of a replacement,
performance and what you mentioned in another e-mail about group
management. Also one thing that I like about removing company so other
people can understand the benefits is one there's a "multi-company"
situation where those companies have really different needs. Say one
needs GNU/Health and the other one needs to manage production. Nobody
would put those two setups in the same database.

My main concern is that data synchronization is not really a simple
thing to do, do it right and efficiently. Not to mention that it is
not exactly the same as sharing the same database. For example,
conflicts when writing on the same record database are managed by
comparing the two records just when the user is updating them. That
minimizes the conflict probability.

In fact, the number of conflicts and complexity to manage them
increases when you update asynchronously. For example, sharing
products is not just sharing the product but also the categories which
can have parents and thus the order of sending and updating data is
not so simple. Specially because you can have cyclic references if a
user changed data in the remote system. Category is just an example of
a field that we find in core modules, but if we think Tryton as a
framework we should probably take care of making a reasonably
extensible solution for which we can provide standard solutions to
this kind of problems.

Regarding other data apart from party and product (and their related
information), there can be other information that is interesting to be
shared between companies when we move out of tryton core. For example,
the templates in quality_control module and I'm pretty sure there can
be others. I'm not suggesting Tryton should solve them out of the box
but again maybe we should try to think well what should be the
mechanism of syncronizing that information because that is
non-trivial.

--
Albert Cervera i Areny
Tel. 93 553 18 03
@albertnan
www.NaN-tic.com

[Cédric Krier]

On 12 Sep 18:29, Albert Cervera i Areny wrote:
> My main concern is that data synchronization is not really a simple
> thing to do, do it right and efficiently. Not to mention that it is
> not exactly the same as sharing the same database. For example,
> conflicts when writing on the same record database are managed by
> comparing the two records just when the user is updating them. That
> minimizes the conflict probability.

First, I think it is out of the scope of Tryton to fix how
synchronisation must be done.
Any way, such design should be done with simplity in mind. For example,
there is no need to have multi-write etc.

> In fact, the number of conflicts and complexity to manage them
> increases when you update asynchronously. For example, sharing
> products is not just sharing the product but also the categories which
> can have parents and thus the order of sending and updating data is
> not so simple. Specially because you can have cyclic references if a
> user changed data in the remote system. Category is just an example of
> a field that we find in core modules, but if we think Tryton as a
> framework we should probably take care of making a reasonably
> extensible solution for which we can provide standard solutions to
> this kind of problems.

That's a good example about what is synchronisable. And for example, I'm
sure category should not be synchronised. Because each company should
create its own structure.
Indeed, synchronisation of products is also questionable. I think on
this topic, it is more about on-demand creation or template creation.
Very few data about product are sharable and the sharables are static
because it is about the description of the product (name, measures,
description etc)
Indeed the same apply to parties, the sharable information are static.

[David Bruchmann]

No idea if it could be helpful, but how Jamaica set up all its
hospitals in GNU Health?

Concerning Dominiques comment "I've never seen, up to now, a sane use
of multi-company", this can't be measure for Tryton as long as
multi-companies exist.

If I understand the expression multi-company right, then they are even
required for operating in different trading-zones like EU, USA, and
others, including single countries without trading-union, for legal
and profit reasons.

[Cédric Krier]

On 13 Sep 05:28, David Bruchmann wrote:
> If I understand the expression multi-company right, then they are even
> required for operating in different trading-zones like EU, USA, and
> others, including single countries without trading-union, for legal
> and profit reasons.

Of course in such case, you have many companies that buy/sale to each
others. And as we already said, this should be done via a EDI interface
if you want to automate it.

PS: Please don't top-post on this mailing list, see
http://groups.tryton.org/netiquette

[Jan Grasnick | Grasbauer UG]

Am 12.09.2014 17:16, schrieb Dominique Chabord:
> Le 12/09/2014 16:52, Axel Braun a écrit :>

>
>> I would avoid EDI as much as I could.
> EDI is the only official approach to do it

We have to deal with such requests in real life and the two statements
above are right: it's a standard and a p.i.t.a as well. So for example
we have one customer which could get his delivery requests via EDI - but
as protocol Odette File Transfer Protocol is used. This requires a
dedicated hardware setup which is expensive and very old fashioned. But
this is usual in all communication related to Volkswagen, because
everything is set up since ages and every change needs expert groups and
millions of meetings. So they implemented a so called WEB-EDI for
suppliers without the needed infrastructure which is nothing more than a
web frontend to get and put some data into a SAP based system.

But it would be great if Tryton supports a subset of EDI. The first what
we have to care about is that there is no EDI - there are a lot of
standards and protocols - SWIFT in Banking, openTrans for interchanging
documents, ANSI ASC in America, VDA in German automotive industries but
ODETTE in France .... As protocols everything from HTTP to X.400 is
used. In fact EDI means nothing if you don't know the needed structure
of the message and the used protocols.

So possibly we talk about implementing EDIFACT and there from a subset
of service messages which are covering the concepts of the core modules.

Possibly we should have have a talk about this issue at Unconferences -
I could ask at HTWK if there is someone who can give us a general
overview about this ....

Jan

[Cédric Krier]

On 13 Sep 11:50, Jan Grasnick | Grasbauer UG wrote:
> Am 12.09.2014 17:16, schrieb Dominique Chabord:
> > Le 12/09/2014 16:52, Axel Braun a écrit :>
> >
> >> I would avoid EDI as much as I could.
> > EDI is the only official approach to do it
>
> We have to deal with such requests in real life and the two statements
> above are right: it's a standard and a p.i.t.a as well. So for example
> we have one customer which could get his delivery requests via EDI - but
> as protocol Odette File Transfer Protocol is used. This requires a
> dedicated hardware setup which is expensive and very old fashioned. But
> this is usual in all communication related to Volkswagen, because
> everything is set up since ages and every change needs expert groups and
> millions of meetings. So they implemented a so called WEB-EDI for
> suppliers without the needed infrastructure which is nothing more than a
> web frontend to get and put some data into a SAP based system.
>
> But it would be great if Tryton supports a subset of EDI. The first what
> we have to care about is that there is no EDI - there are a lot of
> standards and protocols - SWIFT in Banking, openTrans for interchanging
> documents, ANSI ASC in America, VDA in German automotive industries but
> ODETTE in France .... As protocols everything from HTTP to X.400 is
> used. In fact EDI means nothing if you don't know the needed structure
> of the message and the used protocols.
>
> So possibly we talk about implementing EDIFACT and there from a subset
> of service messages which are covering the concepts of the core modules.

Indeed for me, we need first an API inside Tryton to manage «messages»
which means:

- Interface for reception which could be plugged with any kind of protocol
- Interface for processing probably similar to the [1]
- Interface for generating message (with trigger)
- Interface for sending message

> Possibly we should have have a talk about this issue at Unconferences -
> I could ask at HTWK if there is someone who can give us a general
> overview about this ....

I don't doubt a minute there will be hard discussion about it :-)


[1] http://hg.tryton.org/modules/account_payment_sepa/rev/81f4ed8cd809

[Dominique Chabord]

2014-09-12 17:55 GMT+02:00 Cédric Krier <cedric...@b2ck.com>:

>> - I know of a project for a cooperative company for which a
>> verticalization has been done; This used similar approach to
>> multi-company, but it was not multi-company
>
> And what was it?

It was based on access rules as multi-company.

>
>> - I get sometimes the requirement for "multi-branding" business which
>> make the company appear under different brands depending on the
>> channel.
>
> That's just about customization of report/header etc.

as a minimal definition, yes
in real life, it is a bit more complex because content of the document
has to take it into account.

>
>> Multi-company has been a big reason of failure for many projects where
>> it just cannot fit.
>> - Group level reports are the worst reason to do it.
>
> Can you explain "Group reports"?

-reporting at the head of a group of companies

>
>> - Shared operations (one sells, one buys) just cannot be done with it.
>
> Can you ellaborate?

nothing new in this thread. Multi-company is not the rght solution for
intercompany business.
>

[Dominique Chabord]

2014-09-13 0:28 GMT+02:00 David Bruchmann <david.b...@gmail.com>:


> Concerning Dominiques comment "I've never seen, up to now, a sane use
> of multi-company", this can't be measure for Tryton as long as
> multi-companies exist.

Multi-company was designed for tiynyerp 4.2 by Camptocamp for some
historical and internal reasons, as a quick and dirty project. It was
then supported by Openerp-sa. Since then I had to know about many
failures in delivering it and not about any success.
If you know about a correct (reliable accounting, safe isolation,
etc...) of a multi-company solution, either Tryton or Openerp, please
let us know and I will revise my standpoint. It is an open discussion.

[Cédric Krier]

On 13 Sep 13:31, Dominique Chabord wrote:
> 2014-09-13 0:28 GMT+02:00 David Bruchmann <david.b...@gmail.com>:
> > Concerning Dominiques comment "I've never seen, up to now, a sane use
> > of multi-company", this can't be measure for Tryton as long as
> > multi-companies exist.
>
> Multi-company was designed for tiynyerp 4.2 by Camptocamp for some
> historical and internal reasons, as a quick and dirty project.

I did not remember why I implemented the record rules :-)

> It was
> then supported by Openerp-sa. Since then I had to know about many
> failures in delivering it and not about any success.
> If you know about a correct (reliable accounting, safe isolation,
> etc...) of a multi-company solution, either Tryton or Openerp, please
> let us know and I will revise my standpoint. It is an open discussion.

For the record, we fixed a lot of those issues in Tryton but now we face
some design issues which prevents to solve them.

[Albert Cervera i Areny]

In case others are interested, SymmetricDS [1] seems it could be a
good solution for data synchronization for companies that need sharing
a lot of information such as: product categories, accounts, etc.

[1] http://www.symmetricds.org/

[Mathias Behrle]

* Albert Cervera i Areny: " Re: [tryton] Why not killing company?" (Mon, 15 Sep
2014 16:08:26 +0200):

Thanks for sharing, Albert, interesting approach. Will have a closer look and
come back. Java...:(...;).

--

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6

[Axel Braun]

Hi Dominique,

Am Freitag, 12. September 2014, 17:16:28 schrieb Dominique Chabord:
>
> > Information on the client level can be something that is valid for all
> > companies, like name of the product, size & weight, EAN-code, product
> > hierarchy, indicators, e.g. for dangerous goods etc.
>
> I don't think you use the right word.
> These elements are global, but have no reason to be at a client level.

SAP-Speech, sorry.
Yes, some information is on global/database level, and some on company level.

> > On plant or sales region / company level you may have sales unit of
> > measurement, tax codes or tax rules, minimum order quantities etc.
> >
> > By this you have integration on many information, but separate values for
> > companies where it is required
>
> Not sure I understand. Do you mean that managing several companies can
> be complex ? or something else ?

It definitely can, but thats not what it should say.
My point is that you need to have different prices e.g. by company (and even
within company). Prices are just ONE example.

> > I would avoid EDI as much as I could.
>
> EDI is the only official approach to do it

Between independent companies, between supplier etc. Yes.
When you have several companies in a group, integration on a single system is
higher and faster (e.g. intercompany-postings etc).
Why do you think are integrated packages like SAP so successful?

> Complicated, expensive and error-prone
>
> > unless you have tested it out completely.
>
> My perception is exactly the opposite. The standard is safe and
> proven. If we follow it we cannot get it wrong.

I have never seen 'the 'standard' . Even if you talk EDIFACT or a similar
'standard', you always have exceptions/extentions.

> And requires additional EAI-software
>
> > resp EDI converter
>
> Any solution requires converter and EAI
>
> >> So clearly, this doesn't require at all to be on the same database.
>
> ?? I don't get this point.
>
> >> Moreover, if someone develop such feature, it will work for companies on
> >> the same hosts but also across any network. So this will be a truly
> >> generic solution.
>
> Do you mean EDI is a generic solution ? Yes, it works also if some
> companies don't use Tryton.
>
> > You have a couple of sales companies, who do their sourcing via a central
> > souring company or department, in order to take advantage from economies
> > of
> > scale. Physically they (the sales companies) may share the same warehouse,
> > but sell for a different price. Example: small franchise chain with
> > web-sales. all different legal units but from supply chain perspective
> > with shared services. Quite a comon model nowadays.
>
> This is a typical example why EDI is useful and effective. Regarding
> stock management, you cannot share a stock between several companies
> in France. I guess the same in EU. Shared service is allowed if you
> know to which company belongs any good in the warehouse.

Dont mess up logistics and financial requirements.

Best/Axel

[Dominique Chabord]

2014-09-15 18:22 GMT+02:00 Axel Braun <axel....@gmx.de>:
>

> When you have several companies in a group, integration on a single system is
> higher and faster (e.g. intercompany-postings etc).
> Why do you think are integrated packages like SAP so successful?

I agree, but this is not what is meant by multi-company in Tryton
today and this discussion is undoubtly about getting closer to what
you mention. Either we improve it or we replace it.

>
> I have never seen 'the 'standard' . Even if you talk EDIFACT or a similar
> 'standard', you always have exceptions/extentions.

If we use EDI to synchronize operations between Tryton databases, we
don't have to implement industry specifics. A standard is a help for
development and maintenance in particular when it allows a trusted
third party like EDI.
Good news is that if someone needs an industry specific, hopefully it
can be an extension of the core implementation.

>

[Erik Myllymaki]

On 15 Sep 2014, at 7:08, Albert Cervera i Areny wrote:
>
> In case others are interested, SymmetricDS [1] seems it could be a
> good solution for data synchronization for companies that need sharing
> a lot of information such as: product categories, accounts, etc.
>
> [1] http://www.symmetricds.org/
>

fist I've heard of this - thanks.

[Denis Goldberg]

Tryton

Why not killing company?

Good afternoon folks.

Having followed the recent discussion about company module with respect to integrating different legal entities, I would like to take the opportunity and add a different perspective on this:

1. Financial consolidation

As I have stated many times before and would like to emphasize here again, I do not recommend any integration of financial accounting for consolidated statements or bookkeeping ventures. This theme is simply to complex and subject to so many changes in tax code that it is simply not serious to integrate this feature. The meaning of inter-company turnovers and average purchase price admissions vary from state to state and situation to situation in such a significant manner that this remains an issue for accountants to take the lead if at all. Most companies that are in need of financial consolidation in this extent will have to outsource this subject anyhow to a certain extent.

2. Operations

From an operation point of view, there are two main paths, how companies grow: First, via organic growth, second via transactionary growth.

2.1 Organic growth

In organic growth scenarios, companies tend to use different legal entities (usually Limiteds) to setup different structures in geographical or industry markets. A company may use two different legal entities, one covering the Nothern regions of Leipzig and one covering the Southern regions of Leipzig. Or they may even use both legal entities to curve in the same market with different legal presences.

The reason for this are various and highly individual: Ranging from reasons to be present with different entities in the market, to integrating people under certain legal entities, using incentive programs, diverting direct investments to the entity where it belongs, using different concepts (one premium pricing, one low pricing), separating customer responsibilities, limiting corporate liability, concentrating risks, using different entities for fast and slow growing segments, etc.

One of the main questions for management has always been how to handle your business model with a structure (legal and organizational) that will fit it in the correct manner (Mintzberg, Structuring of Organizations, 1979). These structures must of course change over the years and move correspondingly with operational and strategic developments.

The ability to differentiate those legal entities while at the same time using the same basis for the operational business model is crucial to growth. Neglecting this element may quickly lead to dysfunctional organizational processes and the inability to control and steer your company.

2.2 Transactionary growth

The most common way to grow for companies are takeovers. Friendly or not friendly, from an operational point of view, the main challenge is to integrate existing operations into your business model and processes without loosing too much time and keeping the integration phase as short as possible, as integration usually means that you have no control of those operations compared to your own ones.

Different legal entities here again, will be kept as they are known in the market and used by thousands of suppliers and customers and partners. The main task is to make sure not to loose these existing networks and connections. Also, many legal entities are simply registered as suppliers or partners with certain companies. Attempting to switch these existing registrations to the new parent company is usually commercially irresponsible from a compliance and due diligence point of view.

3. Requirements

The main aspect that needs to be respected for your work processes is the ability to manage all operations internally from one system, while using different legal entities externally.

When we takeover a company with long-standing client relations and network, we will of course continue to use the company name and its legal framework, while processing all operations internally on the same system - because the legal entity does not make a difference to process standards and quality levels. Externally, we may even use a different address and different directors and different capital assets to present the unit in the marketplace. Also, the participation of individuals in the various legal entities are a crucial element to adopting fitting incentive systems to lay a framework for loyalty.

Cheers,

Denis

[Albert Cervera i Areny]

2014-09-12 17:55 GMT+02:00 Cédric Krier <cedric...@b2ck.com>:
> On 12 Sep 16:29, Dominique Chabord wrote:
>> hello
>>
>> I've never seen, up to now, a sane use of multi-company
>> As far as business applisation is concerned, I don't even think it can
>> be a legal approach in EU. Group reports are the worst reason to do
>> it.
>
>> As Sebastian explained, there is a problem to move existing
>> multi-companiy solutions.
>
> Indeed I really think it is doable to split such DB into many DB.
>
> - make a copy of the DB for each company
> - add delete cascading on all company foreign key
> - delete all but one company
> - remove the delete cascading
> - update the DB

I've created a simple script that helps in removing stuff. It's been
quick and for the usage in a working database so there are some
specific tables, but at least there's a function that can be easily
used to cascade without setting cascade in all foreign keys. Of
course, the latter would be better and more generic, but just in case
it is useful to somebody else:

https://bitbucket.org/nantic/tryton-tasks/src/e9b83654b3b4a1da0c3555401bc8c1a268f67e92/single-company.py?at=default

[Raimon Esteve]

Hello everybody

About issue "Improve company concistancy" (1), a message (2) will do
more details in latest TUL2014.

Could you explain about "Kill Company" you have been spoken during TUL2014?

Thanks

(1) https://bugs.tryton.org/issue4311
(2) https://bugs.tryton.org/msg18782

[Cédric Krier]

On 04 Dec 12:55, Raimon Esteve wrote:
> Hello everybody
>
> About issue "Improve company concistancy" (1), a message (2) will do
> more details in latest TUL2014.
>
> Could you explain about "Kill Company" you have been spoken during TUL2014?

It was said that *real* multi-company could be acheived but not without
a large work.
The tasks are:

Property fields must be removed and replace by an explicit design where
values are stored per company (like a product.company that will contain
prices, account etc.). But Function field will still be available to
show and edit value from the main Model by the User (but never used by
code). The setter of those Function field will accept a company
argument to override the company from context (to use by code).