i have been struggling the last few hours how to get the SKR04 module installed into Tryton 6.4.
The SKR04 seems to have been written for tryton 6.0, and i have not managed to get it installed into my installation of Tryton 6.4 without overwriting trytond with an earlier version.
How would i need to solve this?
My setup is Tryton 6.4 running in docker with a Postgres DB. I have already tried to modify the module to not break the installation here, which now doesn’t override and break trytond anymore, and installs without any errors. Problem is that the module doesn’t show up in the module list, even after running trytond-admin --update-modules-list and trytond-admin -u tryton_account_de_skr04 --activate-dependencies (source)
My suspicion as to why that is the case is because the __init__.py of the module doesn’t contain a register() function, which the documentation explicitly calls for, but I don’t know enough about Tryton to know how important that is.
– or is there a whole different way to get the SKR04 chart account plan into tryton?
The module when activated will raise errors because the 1530 account type is receivable and this is no longer compatible with tryton 6.4. To fix this you must comment out or remove lines 221 and 228 from the account_type_template.xml file.
I celebrate that you got it working. It will be great if we can merge the SKR04 module with the SKR03 that is already part of Tryton giving more visilibty to the project and more stability to the module.
Just one note about our SKR04: Please have a look at the included tax codes (DE: Steuerkennziffern). We didn’t keep them up-to-date, though especially intra-EU-tax (DE: innergemeinschaftlicher Erwerb) should be looked at. But it only effects 2 or three codes, if I recall it right. Hope we find the time to update it, soon.
By the way: If you find any error or have proposals to improof SKR04, please drop a note!
To add some background, an overview of the most important german chart of accounts:
Lots of german consultants use (by tradition?) SKR03, but SKR04 is for sure my preference.
The other charts are “special”
SKR 03: Companies subject to mandatory disclosure - process structured
SKR 04: Companies subject to mandatory disclosure - closing structured, according the Accounting Directive Act (BiRiliG)
SKR 07: Based on the Austrian standard framework (quiet simalar structured as SKR04)
SKR 14: Agriculture and Forestry
SKR 30: Retail chart of accounts (has not been maintained by DATEV since 2007)
SKR 45: Homes and social institutions (nursing bookkeeping regulation (PBV)), is based on SKR 04
SKR 49: Association , foundation , non-profit GmbH
SKR 51: Car trade (car dealers and workshops)
SKR 70: Hotel and restaurants
SKR 80: Dentists
SKR 81: doctor’s offices
SKR 97: Private Asset Management (DATEV specific) [1]
SKR 99: Hospitals, homes, as well as so-called free chart of accounts (basis for self-processing)
SKR-InsO: for Insolvency Law and Reorganization
All are supplied by the DATEV the “central” IT-service for consultants on accounting and taxes.
SKR03 and SKR04 are available also in English versions => SKR 04 Englisch
Shortly I worked on SKR49 for clubs/foundations/non-profit assosiations and created a very trimmed version within Tryton, just containing about 75 accounts. If someone is interested, welcome to share.
That sound very similar to what we have in Spain but with more variations. For example we also have a chart of accounts for non profits (but is not already available on Tryton).
I guess that all chart of accounts share at least all the taxes aplicable. Does not make sense to have a single module where all the taxes are defined in a single place and each chart has it’s own accounts.
Does each account share some accounts or the accounts are completly diferent bettween each account?
Having a single module with both charts as template allows to use the one that is applicable for the company. For example in Spain we have two charts one for SME and other for Big Enterprises, and the company needs to choose one when setting up the system.
Changing the chart of accounts is possible, but it should be done in different fiscalyears. So what we do is set the end date for all the previous chart accounts and set the end date for all the new chart.
I just had a look at the SKR03 and the SKR04 definition from your links and I see that there are some accounts shared on both. Just go to the last page of both documents and you will see that there are some accounts that are exactly the same.
I’m not really sure about your question, Sergi. But the acounts in SKR03 and SKR04 are pretty much the same (>95%) . The main differance is the “code”/numbering. The “codes” within SKR04 are structed as the later balance-sheet (eg assets all start with a code "0"xxx, expenses "6"xxx … this makes it very logical, even for beginners). SKR03 is supposed to be “production-oriented”; coding starting with assets, kapital, expenses … actually I never used it, because to me it looks/feels just unstructured … I know the are strong, different opinons on that
The main purpose with my post was just to give an idea on how we (have to) handle our acounting in Germany. I do not have the intention to integrate SKR03 with SKR04 in any way.
My points/ideas on “chart of accounts” I put on an extra topic:
Then it will be probably easier to have a single module for both charts an just have a variation of codes for the accounts that are different. This also have the benefit that taxes are defined in just a single place.
For the spanish chart of account we have implementing something similar, but the variation is just on the name:
Please do not feel forced to do so. I just wanted to explore this possibility in case this is interesting and it feels something that helps developers but also users.
I do not think that putting SKR03 and SKR04 together into one module is a good idea as it would make the maintenance of the charts a manual nightmare.
There have been times with a lot of changes on the charts and i would prefer a solution that would allow us to keep the charts up-to-date in a semi-automatic-way.
As the relations between the accounts of both charts are not provided by the publisher we would need to maintain these relations by hand. And relating account names with the same name would be not enough as there are accounts that do have the same purpose but with slightly different names. This shows that even the publisher does not handle these relations very well by himself.
Indeed if the accounts are completly different you can create a separate file for them an manage them manually.
But I guess the taxes are the same for both charts, so managing them in a single module will allow to simplify the maintenance of taxes and tax rules.
But the publisher will show a list of new and old accounts for each chart. So if there are new accounts with same name and same type on both you can directly relate or not.
Normally the account chart should be static, so once the work is done there is not so much to update.
But my point is: If I am able to update a chart from a CSV-File or something similar, why should I even think about updating the chart from these kind of PDF-File that is not provided in a machine readable way?
Yes. They are the same. Because of this it may make sense to put the charts into one module.
But I am not willing to link the accounts of the two charts together. I had the update of the chart on my bucket list. But if anybody is willing to link the accounts I am happy to give the task to him. Otherwise i will provide the update without the links.
