Mathias Behrle <[email protected]> ha escrit: >* 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. >
I didn't include it on the blueprint as we currently didn't need it, but they can also be included if needed. >Also missing in the blueprint all update routines (not only create) >under >'Function to modify:'. Yes! Update routines should be also modified with the same behaviour. I will try to update it as soon as possible to reflect this changes. -- Enviado desde mi teléfono Android con K-9 Mail. Disculpa mi brevedad
