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