Slow chart of accounts tree on version 6.8

After migrating the DB from version 6.0 to 6.8 I noticed that traversing the chart of accounts from the root to a specific leave account in the tree view takes a long time to expand and load the child accounts (nodes). I remember a few months ago in version 6.2 release there was a discussion to replace the MPTT with something else to speed up trees that change often; I don’t know if this is related to that.

Has anyone experience a similar issue?
I noticed someone has already mention this issue in the forum Tree view performance with deeply nested chart of accounts, but the solution was not to fully expand the accounts tree with one click. In my case, I am just traversing to a specific account and not expanding the whole chart of accounts.

Another issue with the tree view in chart of accounts either opening it from Financial > Configuration > General Account > Accounts or from Financial > Reporting > Chart of Accounts is that when I expand a sub account and afterwards try to close the view, it pops up the user alert that This record has been modified do you want to save it? which is very unsual as in neither case any record was modified at all. Should I report this as a bug?

tryton 2023-07-05 09-45

The path option is available but was not used on chart of account because we consider that the chart of account is mainly static so MPTT is better in such case.

Could you check in the console log which fields are considered as modified. sao logs as info such information.
To activate the info output, you need first to run in the console: Sao.Logger.set_level(Sao.Logging.INFO)

1 Like

Thank you for the help.

Sorry I could not find where the console log is nor how to bring it up. By console you mean:

  1. The trytond-console?
  2. Or is it pressing F12 on Firefox to load the developer tools window?
  3. Or is running trytond with the --logconf` <logger.conf> and have the respective modules set to level=INFO. Although I could not find that Sao is a server side module… :thinking:
  4. Running tryton client with the -v -l INFO arguments.

Sorry for my ignorance, I am lost and could not find anywhere in the documentation about the console log :pensive: Can you point me how to do this?

I think I have figured out, it was option 2. Opening the Developer Tools window and pull up the Console. However, when I typed

I get an undefined as response. Hence no log is printed on the console. What should I do?

I have figure out, there was a few buttons on the top of the screen to toggle on/off the type of log output. Info was off, so after enabling it, I see the log now.

So back to the discussion on the modified fields, I found that upon clicking on the first account after the root, the fields: childs and type were apparently modified. I have attached a (somewhat or possibly useless) screenshot of the log.

So it looks like you have some account with a type that is not the same as the type of its parent.
See Enforce same type for children account as their parent (#11143) · Issues · Tryton / Tryton · GitLab

Thank you for the tip. I looked into my chart of accounts and did not find anything strange, but I am still a bit puzzle and confused regarding to the mentioned enforcement.

I don’t understand how this restriction can be helpful if I have my account types defined in a hierarchical manner. For example I have the following account types for my Assets section:

  Short Term Assets
    Cash Equivalents
      Petty Cash Box
      Cash in Bank Accounts
     Raw Materials

And I have the following accounts as template with the corresponding associated type in [square parenthesis]:

Assets [Assets]
  Short Term Assets [Short Term Assets]
    Cash Equivalents [Cash Equivalents]
      Petty Cash
        Purchase Cash [Petty Cash Box]
        POS1 Cash [Petty Cash Box]
        POS2 Cash [Petty Cash Box]
      Cash in Bank
        Account ABC [Cash in Bank Account]
        Account CDE [Cash in Bank Account]
        Account EFG [Cash in Bank Account]

As you can see, just by mirroring the account type hierarchy to the accounts we are already violating this restriction. Could it be that this enforcement indicates that I should remove the type to any account that is not a leaf (i.e. it has children)? However, I checked the Spanish chart of accounts, and I saw that the top type es_normal is assigned as type to the top account node pgc_0_normal which is something very similar to what I am doing. The rest of the child accounts will have assigned as type to other respective child types.

At the end, I did what I interpreted from the my discussion above, i.e. set to NULL all type fields for all accounts that had children accounts and that seem to have solved the problem. This includes the template accounts as well and making sure the XML definitions comply with this enforcement.

Now the tree expands faster (because it is not updating the type of the children accounts in the background) and it not longer asks for saving the record.

I think my error on this was not fully understand how the structure of types and accounts work, and more important is that I don’t need to assign the type field on every accounts to mirror the type hierarchy. If all what I have stated here is true, then it is possible that the Spanish chart of accounts may need some cleanup, because I used it as reference in the past to build my own chart of accounts.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.