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. -- Albert Cervera i Areny Tel. 93 553 18 03 @albertnan www.NaN-tic.com
