On the one hand yes, e.g. the equity accounts could be splitted in the modules personal and capital company. there are a few other, I thought about. But there are possible relations, I didn't check, like a VAT relevant "Privatentnahme" (private abstraction(?)).

On the other hand I think, maintenance would become more difficult. To cite an example, take increasing tax rate, last time you had simply to search one file for "16%" and then you had to look at DATEV, if you will have to insert a new account for "19%" or could overwrite the old account. To make this on a set of files makes it more difficult and dangerous.

I believe the better approach for SKR chart of accounts will likely be to hide by default a large number of seldomly used accounts (inform the user about this!) and release new accounts as they become necessary.  The user can then add them to the existing account tree via "File - New - New Account hierarchy"

Hm it is a question of philosophy. 

And who decides, what is seldom used? I don't know, if ...
* the user has a personal company or a capital company,
* is he a trader or a producer,
* must he declare his tax according cash flow or profit & loss,
...

My philosophy tends to openness: 

Give the user the full visible file and tell him in the file description that he should hide the unused parts. Then he should also remember, that they are there, if something in his business changes like ...
* a new partner in the company,
* additional export or import,
...

After some discussion, I came to the conclusion to basically split along the line of the thousand group for DATEV account numbers

kern: 4,5,6 (should be sufficient for simple EÜR business)
bilanz: 0,1*,2,3*,6,8,9
personal: 6
kapital: 7

This is just a very rough guidance for now and things marked with * will at least partially go to kern as well.  Final attribution will be decided on a case-by-case basis.

I wonder if the placeholer can be separated out as well to avoid duplicate entries.  to be investigated.

General question: How can modules be imported and properly integrated into an already existing account tree?

I am wondering how this works since I believe the import routine assigns a NEW internal account ID (these long numeric beasts) to every new account such that I don't know how a new account finds its already existing parent. The ID of the latter was created earlier and the child does not know.

Any idea? If the modules just coexist after import and need to be manually merged, this might become a tedious work ... and not even simple.

IIRC the internal IDs are created on a random basis, but I am not sure ...

Created attachment 114430 [details]
two modules (cash and bank) to form a single hierarchy

(In reply to comment #6)
> General question: How can modules be imported and properly integrated into an
> already existing account tree?

There is a general mechanism to do that already implemented in Gnucash.  With German UI it can be reached at "Datei - Neu - Kontenhierarchie hinzufügen".  Leaf accounts probably need to be duplicate across module definitions.

I have prepared two test modules "Modul Cash" and "Modul Bank" for you to try things out and attach them here.  If there is anything still left unclear, don't hesitate to ask.

Furthermore, I think we eventually might end up with manipulating the account tree by whichever method we find in bug 538913

(In reply to comment #7)
> There is a general mechanism to do that already implemented in Gnucash.  With
> German UI it can be reached at "Datei - Neu - Kontenhierarchie hinzufügen". 

Thanks, good simple sample. Works on my machine too. 

Remark 1: I cannot see the entry "Kontenhierarchie hinzufügen", just "Kontenhierarchie ..." which is sort of misleading since there is another line with "Kontenhierarchie" above, but without the plus-icon. Could this be fixed such that the common user chooses the right command and is not frustrated making the first steps?

Remark 2: It would be nice if the short instruction for merging modules is added to the description shown in the list of CoA's window. Is a longer text shown in any case in this small window? 

> Furthermore, I think we eventually might end up with manipulating the account
> tree by whichever method we find in bug 538913

I do hope that there will be some solution to that, since I bet my house, my car and ... that the CoA SKR04 will need an update every single year in the future. ;)

(In reply to comment #8)
> Remark 1: I cannot see the entry "Kontenhierarchie hinzufügen", just
> "Kontenhierarchie ..." which is sort of misleading

Hehe.  you should really start to consider using trunk until the German business stuff becomes more mature.  Already reported and fixed as bug 538900.

> > Furthermore, I think we eventually might end up with manipulating the account
> > tree by whichever method we find in bug 538913
> 
> I do hope that there will be some solution to that, since I bet my house, my
> car and ... that the CoA SKR04 will need an update every single year in the
> future. ;)

I won't counterbet :-(

GnuCash bug tracking has moved to a new Bugzilla host. The new URL for this bug is https://bugs.gnucash.org/show_bug.cgi?id=473350. Please continue processing the bug there and please update any external references or bookmarks.