Standard charts of accounts contain lots of accounts (in Gernamy about 2.000)
most users just use a small share of it
account properties partially differ, if used in context of balancing or by using the net-income-method (comparison of revenue and expenses)
Goals
simplify the “chart of accounts” in usage, especially for beginners (reducing the number of acounts in use)
avoid the need of parallel caring for “standard chart of accounts” regarding the diffs by balancing/net-income-method
(posibly, is there a need? … adding another feature: account-taxonomy)
Proposal
To my mind it would be nice to have a “used chart of accounts”, but still having the complete “standard chart of accounts” at hand. In a way, that one might “check in” the account within the “standard chart” to make it available in his/her “used chart of accounts”. Always having the chance to “check in” more accounts later.
In my former used software for bookkeeping, accounts within the “standard/template charts of accounts” contained not only the properties in case of balancing, but additionally the properties needed to use in context of the net-income-method (which the majority of smaller companies in Germany use). How is this handled in your places?
a few (about 10?) years ago accounts (by matter of tax reporting in context balancing) were related to taxonomies (with little changes year by year). I don’t need this feature. Others use external services/software to “convert” and turn in their balances. (The reason for this is, that in difference to general german tax reports, which can easily transfered digitalwise to the tax-authority; balances/taxonomies cannot turned in without a crazy “nobody-wants-to-do-certification-process”.) Just wondering how this is handled elsewhere and if there might be a need to think about more properties to be added to accounts.
We already try to provide a sensible defaults for the chart of accounts:
This allows to use the accounting software without accounting knowledge. I see this is missing for the german chart of account. I will suggest adding this values as first step to make everything simpler.
About all other extra accounts I do not think we need to hide them. As far as the user can search their concept it should not be an issue to have more accounts than really needeed. On the other hand, if we hide some accounts this may cause com issues as the user will not find the values and manually create other accounts with wrong configuration.
Do not completly understand you here. Could you please elaborate which are de diferences and which is the problem for the user?
I guess this is related to the point above, but not sure to fully understand the problem.
There is no need unless you explain the concept and why it will be usefull
Using the net-income-method implies the two main differences:
(1) You do not create a balance sheet, but a “calculation sheet” to report your net-income. This is done by listing your (accounts of) revenue and substract (the listed) expenses.
(2) Assets and debts are documented, but not part of your net-income-report.
(3) The VAT accounts are handled differently. Within the net-income-methode these accounts are (and have to be handled as) income and expenses (not asset/debts). At first sight his might be very strange, but using it, it makes sense after all. Nonetheless you have to turn in VAT-reports, and believe it or not, the tax-office will get the correct amount of VAT.
This ends up in a (possibly) different account-type combined with a different account hierarchie depending on using net-income versus balancing. (Actually we use the net-income-method ourselves, and so we made our way thru it.)
One more note: Small companies do not have to use a special chart of accounts, but thru tax-consultances by fact all companies either use a subset of accounts of SKR03 or SKR04.
Conclusion: Right now, companies using the net-income-method do not have the chance to use their Tryton instance for their accounting “out of the box”.
One more note: Very (also a very small) company has the option to use balancing to calculate their income … (but some point are nice to stay with the net-income-method).
But this is just a simple as creating three types of income:
Result:
a) Revenue
b) Expenses
Indeed this is how we handle it on the chart of accounts.
So you should have a simple balance sheet for documenting such accounts.
Indeed this can not be handled in tryton as the tax account should be a balance one.
We have support for non deductible supplier taxes, but I guess this is not the same as you are explaining. But as you do not have a balance sheet. I do not see any issue with having a type for taxes on a fake statement report.
Hi Sergi, I know, to us it’s fairly easy to adjust. But it is more the discussion of tryton being “product” or “framework”. So, I’ld say if this “feature” is only a german one, I would not care about it any further Tryton-wise. But if it is also similar in other countries (what I do not know at all!), I guess it would be something to discuss about. But as I see in Spain you do not have this kind of handling (needed).
No because the chart of accounts and chart of types are based on a structure defined by laws, so we must always follow the same principle.
If this is the case of Germany we should have the templates on the localization module. If there is no fixed structure by law and anyone can follow its own design, then its better to just let the user create anything using the current modules.
