(In reply to comment #0)
> 4) reflect changes in VAT (page 17 in 432235)

that, of course was meant to read as page 17 in http://www.gdi.de/UST2007/Ums2007-59.pdf

1. As mentioned in https://lists.gnucash.org/pipermail/gnucash-de/2006-October/004479.html
it is free for use.

2. Known bugs and flaws:
 a) I fear, I copied the branch (may be more?) below "A. Eigenkapital:a) Personengsellschaften:x. Privat" from Vollhafter to Teilhafter by Texteditor, so the accounts there will have the same GUIDs. This would mainly be a problem if running a KG, where both are used, but should be fixed.

 b) In my used accounts I renumbered Aktiva:x. Ausstehende Einlagen and "Aufwendungen für die Ingangsetzung..." to 0.x because they are normaly not used and according HGB §§ 271 ff http://www.gesetze-im-internet.de/hgb/index.html should only be shown, if used.

 c) I am not always shure, if acoount no. XYZa, a = 1..9 is a subaccount of XYZ0.

3. ad bug 432235: It uses usual GUV groups " 1." to "22." in the account NAMES, not account NUMBERS. The account numbers are defined by DATEV as four digits.

4. I confirm http://www.gdi.de/UST2007/Ums2007-59.pdf as a very good useable source for changes in VAT

5. I suggest, to put it in SVN for collaborate reworking.

6. Further questions: Is it possible, to put standard tax table definitions and in future tax report relations in the file, too? This would save the user also much work.

I should write a short howto...

I forgot:

2.d) according to bug 421766 there is the question, if "Eigenkapital" should have account type "Passiva", which in reality is liability, or "Eigenkapital"(equity).
The first leads always to red numbers, the second cannot be part of "Passiva".

So, my suggestion would be, first bug 421766 should get the workaround, as mentioned by cstim. Then we should take the first.

SKR04 is quite large.  Would it make sense to break this down into modules?  I am still fairly inexperienced with real-world accounting.  But I assume a Personengesellschaft would not need the same accounts as a Kapitalgesellschaft.  Same goes for EÜR vs. Bilanzierung.  Can this be broken down? If so, what makes sense?

Looking at the accounts it seems that there are some in there which will not be of general use but need to be configured individually.  Example accounts are the "ich" and "mein Partner" account under 2000 (Passive - Eigenkapital - I. Kapital Vollhafter - Festkapital).

Furthermore, I don't understand the motivation of creating a hierarchy with just one sub-entry.  Take a look at 3. Andere aktivierte Eigenleistungen for an example.

€ in description of account 4185 comes out as ¤ instead

(In reply to comment #2)
> 2. Known bugs and flaws:
>  a) I fear, I copied the branch (may be more?) below "A. Eigenkapital:a)
> Personengsellschaften:x. Privat" from Vollhafter to Teilhafter by Texteditor,
> so the accounts there will have the same GUIDs. This would mainly be a problem
> if running a KG, where both are used, but should be fixed.

Maybe I understood this wrong.  But "grep guid /usr/share/gnucash/accounts/de_DE/acctchrt_skr04-05.gnucash-xea |grep -v parent|uniq -d" does not return any results and thus it seems this is not a problem.

(In reply to comment #2)
> 5. I suggest, to put it in SVN for collaborate reworking.

do you have commit rights?

Annotation:
It was developed under gnucash 1.8.x, so it should be coded primary in
ISO-8859-15, some visible umlauts I HTML-quoted &xxx;

my sources:
in http://www.textbuch-fibu.de/tb/download.html gewerbl_Kontpl_IBM.zip and
http://www.rts-d.net/kopla/skr04_2005.htm

Places, where we possible could get some help:
http://www.carookee.com/forum/bilanzbuchhalter-fachthemen
http://www.rechnungswesenforum.de

A simliar project like this bug thread is http://kontenrahmen.berlios.de, 
but the lx-office - for nongerman readers: the german fork of SQL-ledger -
account frame is incomplete. lx-office in my eyes is more a "WWS" than a "FiBu"
and lacks documentation.

Modularisation would be fine, but also bring up some complications. I think,
this is SKR04 like published by datev to their members. After opening it, you
can adjust it to your belongings by hiding or deleting unused branches. I would
only hide. Who knows what next year will be: a new partner field of activity?

"Andere aktivierte Eigenleistungen" is different from "Bestandsveränderungen"
and by any german law to be shown separatly in pofit & loss. The intention is,
"Bestandsveränderungen" you can count or measure, this not. So this position
is more weak. 

BTW. Account with numbers of one or more ending "0" are classes, types,
subtypes. The real accounts are usualy ending with 1, 2 ... - as demonstrated
with the example accounts below.

You also should open description and annotation of the fields. Sometimes you
will find the corresponding §§ or intentions.

As writen in the mail, "ich", "mein Partner", WG "Marmor", "Stein" und "Eisen"
are example accounts.

In editor I see <act:id type="guid">..., but i think, there is a tool. Does us
help this gnucash-make-guids? Or is recreating with copy and paste more quick?

(if I had commit right, I would do instead of ask)

some very nice information there.  Thank you Frank.  I believe it would be best to leave out all sample accounts.  It is better to write a doc on how to use the SKR with gnucash than having unnecessary accounts IMHO.  I see this as a real bare-bone, uncustomized starting point.

https://lists.berlios.de/pipermail/kontenrahmen-devel/2006-December/000011.html has an attachment which nicely lists the changes DATEV made for 2007.

I don't believe SKR04 is Business-specific ... please smack me around if wrong.

http://www.hanft.de/debs/ustpos.pdf has some information relevant for Umsatzsteuervoranmeldung. Might be that this information is already present in some of the other links here.

(In reply to comment #11)
> I don't believe SKR04 is Business-specific...

From an implementation POV: No, it isn't business-related; it's only an account template. From a user POV: totally. Only [German] business users are interested in that template.

@Rolf et al.: As soon as you or anyone else attaches some patch(es) here, we will happily apply them to SVN. I would encourage you to submit even small changes right now, and keep those that still need further discussion for a later point in time.

Created attachment 94705 [details]
Frank's SKR04

Hi Christian,

thank you for your comment.  Funnily enough, I was on the verge to propose the same (release early and often, incremental steps).  Just did not get around to it in the last few days.

Now, I did.  That way, I found out that a diff from Frank's work and the current file is about the same size as Frank's latest file.  Thus, I refer back to my original report, number 1 in the list.  Once http://www.mataram.de/downloads/gnucash/acctchrt_skr04-05.gnucash-xea.bz2 is in SVN, I can attach my diffs for it here.  I have already removed a few glitches from it.  Please apply Frank's work.  Thank you.

Regards

Rolf

Would it be possible to put Frank's file in SVN and grant him and me SVN write access to only that file?

I dont know how technically feasible it would be to grant write access only to a single file.  It's certainly possible to grant write access only to the 'accounts/de_DE' subtree, but the question remains:  which branch?  Trunk?  branches/2.2 (which doesn't exist yet)?  I dont know if the ACL regex engine would support something like:   gnucash/*/accounts/de_DE/...

(In reply to comment #5)
> € in description of account 4185 comes out as ¤ instead

reported as bug 472205

(In reply to comment #14)
> Please apply Frank's work.  Thank you.

Thanks for the clarification. I've committed Frank's account template as a replacement of the previous accounts/de_DE/acctchrt_skr04.gnucash-xea file, according to its description. I hope this is what you expected to happen.

As for SVN write access: I don't think this is really necessary. As soon as you add a file or a diff here with the clear label "Please apply this to SVN", one of the developers should react on this soon enough (and Frank and you can also download those patches/files yourself as well).

(In reply to comment #18)
> Thanks for the clarification. I've committed Frank's account template as a
> replacement of the previous accounts/de_DE/acctchrt_skr04.gnucash-xea file,
> according to its description. I hope this is what you expected to happen.

Thank you.

Essentially, yes, this is what I was asking for.  It might be necessary to revisit that decision since the account template is likely to change every year.  Praise the Lord for our overly competent government.

> As for SVN write access: I don't think this is really necessary. As soon as you
> add a file or a diff here with the clear label "Please apply this to SVN", one
> of the developers should react on this soon enough (and Frank and you can also
> download those patches/files yourself as well).

Well, sorry, but I disagree.  I don't think it is practical to copy the original file, make the change, create a diff, open a bug and attach the diff every time I find a spelling mistake of "Unternhmen" instead of "Unternehmen".  I don't think I as a contributor should or will put up with this.

PS: The spelling mistake does indeed exist.  There are a few more minor such errors.  It is likely nobody will ever fix them, unless they can fix it on the spot.

(In reply to comment #19)
> Well, sorry, but I disagree.

All a moot point by now :-)

> PS: The spelling mistake does indeed exist.  

*did* exist until r16488

current status

(In reply to comment #0)
> Please describe the problem:
> I believe SKR04 could use an update

> 1) Include the enhanced version from Frank Ellenberger

done

> 2) fix the sorting bug 432235

done

> 3) check general sanity and suitability for general public

I will use the account chart and fix anything that I come across.  Consider it done for the purpose of bugzilla.

(In reply to comment #1)
> (In reply to comment #0)
> > 4) reflect changes in VAT (page 17 in 432235)
> 
> that, of course was meant to read as page 17 in
> http://www.gdi.de/UST2007/Ums2007-59.pdf

(In reply to comment #10)
> https://lists.berlios.de/pipermail/kontenrahmen-devel/2006-December/000011.html
> has an attachment which nicely lists the changes DATEV made for 2007.

todo

(In reply to comment #2)
> 2. Known bugs and flaws:
>  a) I fear, I copied the branch (may be more?) below "A. Eigenkapital:a)
> Personengsellschaften:x. Privat" from Vollhafter to Teilhafter by Texteditor,
> so the accounts there will have the same GUIDs. This would mainly be a problem
> if running a KG, where both are used, but should be fixed.

See above.  Don't think this is a valid issue.

done.  Please open a new bug and block this one if you still experience this.

>  b) In my used accounts I renumbered Aktiva:x. Ausstehende Einlagen and
> "Aufwendungen für die Ingangsetzung..." to 0.x because they are normaly not
> used and according HGB §§ 271 ff
> http://www.gesetze-im-internet.de/hgb/index.html should only be shown, if used.

OK.  done.

>  c) I am not always shure, if acoount no. XYZa, a = 1..9 is a subaccount of
> XYZ0.

I will fix this if I encounter it.

done.

> 5. I suggest, to put it in SVN for collaborate reworking.

Done.

> 6. Further questions: Is it possible, to put standard tax table definitions and
> in future tax report relations in the file, too? This would save the user also
> much work.

yes, it seems possible.  I will try to include it soon.

> I should write a short howto...

http://linuxwiki.de/GnuCash/EuerGc


(In reply to comment #4)
> SKR04 is quite large.  Would it make sense to break this down into modules?

Decision postponed until I am more familiar with this stuff.

consider done for now.  Please open a new bug for discussion if you are interested in this.

> Looking at the accounts it seems that there are some in there which will not be
> of general use but need to be configured individually.  Example accounts are
> the "ich" and "mein Partner" account under 2000 (Passive - Eigenkapital - I.
> Kapital Vollhafter - Festkapital).

to be removed.

(In reply to comment #17)
> (In reply to comment #5)
> > € in description of account 4185 comes out as ¤ instead
> 
> reported as bug 472205

fixed.

(In reply to comment #21)
> (In reply to comment #10)
> > https://lists.berlios.de/pipermail/kontenrahmen-devel/2006-December/000011.html
> > has an attachment which nicely lists the changes DATEV made for 2007.

bug 473348

> > 6. Further questions: Is it possible, to put standard tax table definitions and
> > in future tax report relations in the file, too? This would save the user also
> > much work.

bug 473349

> (In reply to comment #4)
> > SKR04 is quite large.  Would it make sense to break this down into modules?

bug 473350

> > Looking at the accounts it seems that there are some in there which will not be
> > of general use but need to be configured individually.  Example accounts are
> > the "ich" and "mein Partner" account under 2000 (Passive - Eigenkapital - I.
> > Kapital Vollhafter - Festkapital).
> 
> to be removed.

fixed in r16495

bug 504935 would solve the problem, to implement in account class 9000 statistical data like working days.

for all practical purposes, this bug should be read-only now.  If there is a task that needs to be done and involves SKR04, please report it as a separate issue and make it block this bug.

Or we all want be able to keep our sanity ;-)

(In reply to comment #24)
> Or we all want be able to keep our sanity ;-)
            ^^^^
won't

Sorry.  I was cleaning up but should have checked with you before changing the status.

This bug has a target of 2.3.0, which has now been released.  Do you want to change it to 2.3.X, marking that it will be ready in the 2.3.X/2.4.0 timeframe (August) or remove the target milestone?

This is more of a meta-bug.  The work is ongoing and I'm not sure this bug can ever be considered fixed.

(In reply to comment #28)
> This is more of a meta-bug.  The work is ongoing and I'm not sure this bug can
> ever be considered fixed.

Uh, no. That's not how to manage bugs. If you want to submit more patches, open a new bug.

(In reply to comment #19)
> (In reply to comment #18)
> > Thanks for the clarification. I've committed Frank's account template as a
> > replacement of the previous accounts/de_DE/acctchrt_skr04.gnucash-xea file,
> > according to its description. I hope this is what you expected to happen.
> 
> Well, sorry, but I disagree.  I don't think it is practical to copy the
> original file, make the change, create a diff, open a bug and attach the diff
> every time I find a spelling mistake of "Unternhmen" instead of "Unternehmen". 
> I don't think I as a contributor should or will put up with this.

Don't do that. Do it this way: http://wiki.gnucash.org/wiki/Git#Patches

(In reply to comment #24)
> for all practical purposes, this bug should be read-only now.

No such thing in Bugzilla. Even a verified-fixed bug can still get comments.

Hi John,

while many of the comments are outdated, 
Rolf seems since years inactive,
there was some technical progress, ...
I think, this bug should kept open, because it is the link between bug 473506 and a whole bunch of other bugs (see dependencies).

I hope, one day we can say GnuCash with this template conform with most german laws and EU directives. That will be as all depends-on-bugs are fixed.

As we have no specific german/european business component here in bugzilla, I can offer to take over this 2 metabugs, if it is too annoying to have them assigned to gnucash-general-maint@gnome.bugs.

Frank,

The assignment to gnucash-general-maint just drives email. If there's no activity, there's no email. No email, no annoyance.

Leggewie is long gone and you haven't found time to touch the German account templates for 3 years. Christian made a change last year and then changed his mind and reverted it. All of these bugs are very old and stale. Most of them are sort of thinking-out-loud from Leggewie about how he might like to restructure the templates. That isn't going to happen. I'm in favor of closing all of them.

It the templates are actually wrong, especially if they'd lead users to break the law, or if you and Christian aren't going to make it a priority to keep them up to date, they should either be trimmed back to what is correct and basic or removed altogether until someone comes along who will maintain them. In any case it would be more useful to write new bugs explicitly stating the problems than to keep these rather vague and speculative things open.

Hello Frank, John et al,
Is there demand for these German/EU business templates to be developed and maintained? Sounds like there's certainly no capacity in the team to do so as it would be a huge task? I certainly don't have the skills required, but perhaps I could assist to facilitate? If readers of this would like this facilitated, please drop me a line here https://patchpitch.com/contact.
Cheers,
Paul.

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=433428. Please continue processing the bug there and please update any external references or bookmarks.