* Albert Cervera i Areny: " Re: [tryton] Aplying inhertance to chart of accounts" (Sat, 21 Dec 2013 16:15:03 +0100):
> 2013/12/20 Mathias Behrle <[email protected]>: > > * Sergi Almacellas Abellana: " Re: [tryton] Aplying inhertance to chart of > > accounts" (Thu, 19 Dec 2013 19:01:31 +0100): > > > > [Sorted differently for better reading] > > > >> El 08/12/13 15:26, Cédric Krier ha escrit: > >> > On 07/12/13 11:59 +0100, Sergi Almacellas Abellana wrote: > >> >> >El 07/12/13 10:11, Cédric Krier ha escrit: > >> >>> > >On 06/12/13 20:22 +0100, Sergi Almacellas Abellana wrote: > > > >> >>> > >Why not just have two modules where you put in a separate XML the > >> >>> > >common part. So you just have to keep in sync (with a simple copy) > >> >>> > >both files. > >> >> >That's moreless what we have now (two modules with duplicate data). > >> >> >And when you develop other modules that adds configuration to the > >> >> >original modules (see [1]) you end up duplicating information another > >> >> >time. > >> >> > > >> >> >So we will end up having a ton of modules with _es and es_pyme > >> >> >suffixes. So we are trying to improve this situation. > >> > That's the normal implication because what you name shared data is not > >> > shared by your definition. > >> > Or you have to change your chart definition to have real shared data. > >> > > >> > Also if you want to reduce the number of modules, just move your two > >> > charts into the same module. > >> We have discussed internally in the spanish comunity and found a good > >> solution in our opinion. The solution involves creating a new module to > >> specify charts variants, and join the account_es and account_es_pyme > >> modules in a module. > >> > >> The variants module will add a Many2One field in the create chart of > >> accounts to select the required variant (Full or Pyme) and will override > >> the process creation to create the common accounts (no variant > >> especified) and the specified accounts for the selected variant. > >> > >> Any coments are apreciated. > > > > This could be a solution, but in the discussion until now there is one > > show-stopper for me. You write: > > > >> >>>>> > >>>account_es have accounts (A, A1, A2, B, B1, B2) > >> >>>>> > >>>account_es_pyme have accounts (A, A1,A2, C, C1) > >> >>>>> > >>> > >> >>>>> > >>>On both cases numbered accounts are child of their letters > >> >>>>> > >>>accounts. Also the name of the account A2 is different on both > >> >>>>> > >>>charts, so they have the same code, but can be considered as > >> >>>>> > >>>different accounts. > > > > AFAIS the accounts are not really common, if they have different names. > > Only a few have different names, in fact. Most other differences are > accounts that are only available in one (the account_es) chart. > > >> Will this module fit in tryton core modules? If so, i will try to work > >> on in in the following days. > > > > You would at least have to take care, that the selection process and > > overidden create doesn't have an effect on the other charts. > > It wouldn't have any effect on other charts. If the "variant" field of > the template is empty the account would always be created. If the > "variant" field has an "A" it would only be installed if variant "A" > as selected. The same for variant "B", etc. Implementation should be > trivial. > > > Finally I don't know, if the deduplication of data is really worth the > > effort in those cases. In my view I would also stick to different modules > > as ced proposed, evtl. depending on a common (taxes etc.) module, if they > > contain the same records. > > The thing is that account.tax.code.template has references to accounts > and that field is required, so it is not possible to create those > taxes in a common module unless we drop that constraint. Just became aware, that I looked at our own implementation, where those accounts are not required. Sorry for the noise. > Even if it > was possible, every time a tax is added (more than we'd like lately) > we'd have to add the tax to the common module and also to the other > two modules which is the kind of maintenance that we'd like to > simplify... > > Of course, tax accounts are not among the list of accounts that differ > in account_es and account_es_pyme. But if they would differ, they were also subject to variant, right? And tax codes as well? This seems not to be reflected in the blueprint. Also missing in the blueprint all update routines (not only create) under 'Function to modify:'. -- 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
signature.asc
Description: PGP signature
