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

> 2014-09-12 18:29 GMT+02:00 Albert Cervera i Areny <[email protected]>:
> > 2014-09-11 12:37 GMT+02:00 Cédric Krier <[email protected]>:
> >> 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.
> >
> > 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.
> 
> 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/

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

Attachment: signature.asc
Description: PGP signature

Reply via email to