[gnucash-de] Kontenplaene, zum zweiten

[Andreas Schenk]

Hallo,

ich plane (nun sogar noch mehr) den Kontenplan SKR3 so aufzubereiten, dass er
als gute und brauchbare Vorlage in GnuCash verwendet werden kann. Bei der
Frage, wie ich die Daten strukturieren soll, habe ich mir zur Inspiration den
"angeblichen" SKR4 angesehen. Alles was ich von Buchhaltung und Bilanzierung
verstehe sagt mir nun, dass hier etwas voellig durcheinander geht. Daher
moechte ich hier zunaechst die Begriffe praezisieren. Danach (nach viel
Geduld bei der Lektuere) kommen meine Fragen dazu, wie ich mit dem SKR3
umgehen soll. Ich wuerde mich sehr ueber Anregungen freuen. Vielleicht kommt
dadurch etwas heraus, dass auch noch andere Leute verwenden koennen und
wollen.....

(1) Thema Begriffsverwirrung

Im GnuCash-Umfeld gehen die drei Begriffe (a) Bilanz, (b) Gewinn- und
Verlustrechnung (GuV) sowie (c) Kontenplan durcheinander. Das Durcheinander
wird besonders dadurch gefoerdert, dass das Programm die eigentlich voellig
getrennten Strukturen fuer Bilanz, GuV und Kontenplan zu einer Struktur
zusammenfasst. Im einzelnen sind

(a) Bilanz:

Eine Vorschrift im Paragraphen 266 des HGB verlangt eine bestimmte Gliederung
der Bilanz. Sie gilt (mindestens) mit bestimmten groessenabhaengigen
Erleichterungen fuer alle Kapitalgesellschaften. Sie ist voellig unabhaengig
von einem Kontenplan.

(b) GuV

Eine Vorschrift im Paragraphen 275 des HGB verlangt eine bestimmte Gliederung
der GuV. Alles unter (a) genannte gilt hier ebenso.

(c) Kontenplan

Kontenrahmen und Kontenplan dienen dazu, die Konten systematisch zu ordnen.
Die systematische Ordnung der Konten wird durch ihre einheitliche Gliederung
(Nummernsystematik) und Bezeichnung erreicht. (Anmerkung: ohne Nummern also
keine Kontensystematik)

Kontenrahmen enthalten dazu i.d.R. mehrere Kontenklassen. Die Klassen werden
durch eine (oder mehrere) fuehrende Stelle(n) der Kontonummern definiert. Und
genau hierin unterscheiden sich alle Kontenplaene, auch SKR3 und SKR4.

Im SKR3 gibt es die Klassen

0 Anlage und Kapitalkonten
1 Finanz- und Privatkonten
2 Abgrenzungskonten
3 Wareneingangs- und Bestandskonten
4 Betriebliche Aufwendungen
5 frei
6 frei
7 Bestaende an Eraeugnissen
8 Erloeskonten
9 Vortragskonten - Statistische Konten

Im SKR4 gibt es die Klassen

0 Anlagevermoegen
1 Umlaufvermoegen
2 Passiva
3 Passiva
4 Betriebliche Ertraege
5 Betriebliche Aufwendungen
6 Betriebliche Aufwendungen
7 weitere Ertraege und Aufwendungen
8 frei
9 Vortrags- und statistische Konten

Man erkennt den Unterschied: die Konten (deutlicher Kontonummern) sind im SKR3
nach den Betriebsablaeufen gegliedert (Prozessgliederung), die des SKR4 nach
den gesetzlichen Vorschriften der Gliederung von Bilanz und GuV.

Der Unterschied liegt hier lediglich in der Gliederung (Nummernsystematik). In
beiden Faellen gibt es fuer den Jahresabschluss eine Abbildung von Konten
(Kontonummern) auf die Positionen von Bilanz und GuV. Mit anderen Worten: den
Unterschied zwischen beiden Kontenplaenen sieht man nur, wenn man mit
Kontonummern arbeitet.

Beispiel:

Bilanzposition

Aktiva -> Umlaufvermoegen -> Vorraete -> Roh-, Hilfs- und Betriebsstoffe

Im SKR3 werden dieser Bilanzposition die Konten 3970 - 3979 zugeordnet
(Kontenklasse 3 entsprechend Wareneingangs- und Bestandskonten), im SKR4 die
Konten 1000 - 1039 (Kontenklasse 1 entsprechend Umlaufvermoegen).

Die einzelnen Konten bedeuten dabei z.B.

SKR3:

3970 - 3979: Bezeichnung: Bestand Roh-, Hilfs- und Betriebsstoffe

SKR4:

1000 - 1039 Bezeichnung: Roh-, Hilfs und Betriebsstoffe (Bestand)

Wie zu erwarten, sieht man anhand der Bezeichnungen keinen Unterschied und
keine Systematik. Nur die Nummern fuehren zu einer Systematik des
Kontenplanes. Davon getrennt zu betrachten (aber in GnuCash mit dem
Kontenplan zu einer Entitaet verschmolzen) ist die zu einem Kontenplan
gehoerende Bilanzstruktur (= Abbildung der Konten (Kontonummern) auf die
Bilanzpositionen).

Das war die Theorie.

(2) Thema Kontenplaene und Buchung in GnuCash

Wenn man einen Kontenplan in GnuCash ohne Kontonummern sondern nur mit
Bezeichnungen definiert -- wie im angeblichen SKR4 -- so hat man gar keinen
Kontenplan definiert, sondern ein Template, das auf alle Kontenplaene mit
gleicher Granularitaet passt. Daher meine Bezeichnung "angeblicher" SKR4. Ein
Unterschied kann sich lediglich in der Granularitaet ergeben.
Grossunternehmen werden z.B. nicht mit 4-stelligen Kontonummern auskommen, da
sie mehr als 10000 Konten haben. Sie haben dort eher 10-stellige
Kontonummern, aber genauso 10 Kontenklassen wie im SKR3 oder SKR4.

Falls jemand bis hier hin gelesen hat: nun kommen endlich meine Fragen:

(A) Ich wuerde GnuCash gerne so verwenden, dass ich beim Buchen Kontonummern
eingeben kann -- in ueblicher Buchhaltermanier. Dieser Wunsch wurde frueher
schon einmal in einer Liste geaeussert, ich weiss aber nicht, was der
aktuelle Stand ist. Daher die Frage: Kann man in GnuCash mit Kontonummern
buchen, wenn ja wie und ab welchem Release, oder kann man dies ab einem
absehbaren zukuenftigen Release?

(B) Wenn ich einen Kontenplan (z.B. SKR3) "linear" mit Kontonummern anlege,
kann man daraus Bilanz und GuV erzeugen, oder muessen die Konten dazu
zwangsweise in einer Hierarchie angelegt werden, wie im "angeblichen" SKR4?
Falls ein linearer Plan ausreicht, was muss ggf. getan werden, damit man
daraus Bilanz und GuV generieren kann? M.a.W. wo und wie sonst wird die
Abbildung der einzelnen Konten auf die Positionen von Bilanz und GuV
(Bilanzstruktur) hinterlegt?

(C) Falls der SKR3 nun doch in derselben Hierarchie angelegt werden muss, wie
der SKR4: Die Angabe z.B. im Kontobuch der 10 Konten (an das obige Beispiel
anknuepfend) waere dann:

Aktiva:Umlaufvermoegen:Vorraete:Roh-, Hilfs- und Betriebsstoffe:Bestand Roh-,
Hilfs- und Betriebsstoffe

Mit Verlaub: eine Katastrophe.

Zudem haetten alle 10 Konten im Intervall 3970 - 3979 dieselbe Bezeichnung....
(Nach diesem Muster ist jedenfalls der SKR4 aktuell angelegt.) Kann man die
Konten in GnuCash als Hierarchie anlegen, aber die Angabe des Kontos z.B. im
Kontobuch auf den Teil nach dem letzten Doppelpunkt einschraenken? Wenn ja,
wie?

(D) Wenn das alles nicht geht, scheint es mir im Moment am besten, die
Hierarchie folgendermassen anzulegen:

Fuer die Knoten der Hierarchie gelten folgende Bezeichnungen und
Beschreibungen (exemplarisch):

Bezeichnung A, Beschreibung Anlagevermoegen, eine Hierarchie darunter

Bezeichnung II, Beschreibung Sachanlagen, eine Hierarchie darunter

Bezeichnung 1, Beschreibung Grundstuecke und Bauten, eine Hierarchie darunter
die Konten

Unter der Hierarchie Aktiva.A.II.1 wuerde man beim SKR3 dann folgende Konten
finden (Kontonummer als Bezeichnung, "echte" Bezeichnung als Beschreibung):

0050 Grundstuecke, grundstuecksgleiche Rechte und Bauten einschliesslich der
Bauten auf fremden Grundstuecken

0060 Grundstuecke und grundstuecksgleiche Rechte ohne Bauten

0065 Unbebaute Grundstuecke

0070 Grundstuecksgleiche Rechte (Erbbaurecht, Dauerwohnrecht)

0075 Grundstuecke mit Substanzverzehr

usw., insgesammt wuerde man hier alle Konten in den Intervallen

0050 - 0078
0080 - 0119
0140 - 0149
0160 - 0179
0190 - 0194

finden. Das letzte Konto waere (zum Abschluss)

0194 Einrichtungen fuer Wohnbauten.

Die Angabe im Kontobuch waere

Aktiva:A:II:1:0194

Kurz und praegnant.

Immer noch eine Katastrophe? Teufel oder Belzebub?

Ich stelle das hier zur Disposition!

Man wuerde sogar die Kontonummern sehen, obwohl man die "echten" Kontonummern
beim Buchen gar nicht eingeben kann, weil man die Kontonummer als Bezeichnung
gewaehlt hat. Die Beschreibung wuerde immer noch sagen, was sich dahinter
verbirgt.

Das wuerde dann auch noch bei Wertpapieren funktionieren. Hier muss man ja
fuer jede WKN ein einzelnes Konto anlegen. So haette man dann z.B.

Aktiva:B:III:1:1349:BASF AG

fuer ein Konto fuer den Bestand an Aktien der BASF AG. Im Langtext:

Aktiva -> Umlaufvermoegen (B) -> Wertpapiere (III) -> sonstige Wertpapiere (1)
-> Wertpapieranlagen im Rahmen der kurzfristigen Finanzdisposition (Konto
1349) -> BASF AG (Unterkonto dieses Unternehmens dazu)

Noch besser waere natuerlich die Angabe (z.B. im Kontobuch)

1349:BASF AG

-- falls man das erreichen kann, unter korrekter Zuordnung zu der
entsprechenden Bilanzposition (vgl. Frage B)

Eine bessere Idee fuer den schlechtesten Fall habe ich bisher nicht.

Ich wuerde mich sehr ueber Kommentare und / oder bessere Vorschlaege freuen.

Viele Gruesse

Andreas Schenk


(P.S. Danke fuer die Geduld, manche Mails sind einfach lang.)

[Betina Schmidt]

Am Montag, 24. Januar 2005 23:04 schrieb Andreas Schenk:
Hallo Andreas,

Post by Andreas Schenk
ich plane (nun sogar noch mehr) den Kontenplan SKR3 so aufzubereiten, dass
er als gute und brauchbare Vorlage in GnuCash verwendet werden kann. Bei
der Frage, wie ich die Daten strukturieren soll, habe ich mir zur
Inspiration den "angeblichen" SKR4 angesehen. Alles was ich von Buchhaltung
und Bilanzierung verstehe sagt mir nun, dass hier etwas voellig
durcheinander geht. Daher moechte ich hier zunaechst die Begriffe
praezisieren. Danach (nach viel Geduld bei der Lektuere) kommen meine
Fragen dazu, wie ich mit dem SKR3 umgehen soll. Ich wuerde mich sehr ueber
Anregungen freuen. Vielleicht kommt dadurch etwas heraus, dass auch noch
andere Leute verwenden koennen und wollen.....

nichts für ungut, aber was heißt hier angeblich;-)? Ich habe natürlich nicht
alle Konten des Datev-SKR-04 aufgenommen, nur die wichtigsten..., aber die
Gliederung nach HGB sollte wohl schon berücksichtigt worden sein- oder? Ist
da was schief gegangen?

Ich habe auch ein bißchen Ahnung von der ganzen Sache. Wenn die anderen nichts
dagegen haben, dann können wir uns gerne mit dieser Problematik befassen und
den SKR 03 mit einarbeiten.
Für Vorschläge, wie man das ganze systematisch aufbaut, wäre ich interessiert.

Grüße

[Andreas Schenk]

Hallo Betina,

Du fragst, "was da schief gegangen ist", insbesondere wegen des Wortes
"angeblich". Ich muss Dich dazu an meine Mail zurueckverweisen. Dort ist
genau und ausfuehrlich beschrieben, warum ich dieses Wort verwende. Solltest
Du konkrete Fragen zu einzelnen Punkten haben, so bin ich gerne bereit, diese
naeher zu erlaeutern.

Viele Gruesse

Andreas Schenk

Post by Betina Schmidt
Hallo Andreas,

Post by Andreas Schenk
ich plane (nun sogar noch mehr) den Kontenplan SKR3 so aufzubereiten,
dass er als gute und brauchbare Vorlage in GnuCash verwendet werden kann.
Bei der Frage, wie ich die Daten strukturieren soll, habe ich mir zur
Inspiration den "angeblichen" SKR4 angesehen. Alles was ich von
Buchhaltung und Bilanzierung verstehe sagt mir nun, dass hier etwas
voellig
durcheinander geht. Daher moechte ich hier zunaechst die Begriffe
praezisieren. Danach (nach viel Geduld bei der Lektuere) kommen meine
Fragen dazu, wie ich mit dem SKR3 umgehen soll. Ich wuerde mich sehr
ueber Anregungen freuen. Vielleicht kommt dadurch etwas heraus, dass auch
noch andere Leute verwenden koennen und wollen.....

nichts für ungut, aber was heißt hier angeblich;-)? Ich habe natürlich
nicht alle Konten des Datev-SKR-04 aufgenommen, nur die wichtigsten...,
aber die Gliederung nach HGB sollte wohl schon berücksichtigt worden sein-
oder? Ist da was schief gegangen?
Ich habe auch ein bißchen Ahnung von der ganzen Sache. Wenn die anderen
nichts dagegen haben, dann können wir uns gerne mit dieser Problematik
befassen und den SKR 03 mit einarbeiten.
Für Vorschläge, wie man das ganze systematisch aufbaut, wäre ich interessiert.
Grüße

[Christian Stimming]

Hallo Andreas,

vielen Dank für die ausführlichen Gedanken und die Erklärungen, die
"sogar ich" verstehen kann :-)

Wenn du sowas genauer ausarbeiten möchtest, würde ich empfehlen, die
Notizen in einer extra Seite im Wiki http://linuxwiki.de/GnuCash zu
sammeln, also z.B. unter einer Adresse wie
http://linuxwiki.de/GnuCash/Kontenrahmen die Notizen reinzustellen und
sie dann Stück für Stück (und auch mit Bettina und anderen) zu
verfeinern. (Probier's einfach aus -- im Wiki kann man nichts kaputt
machen.)

< Vorrede >
Generell bist du nun auf das Problem gestoßen, daß Gnucash eben nicht
von Buchhaltern geschrieben worden ist, sondern "nur" von
Programmierern. Programmierer versuchen immer, "eine bestimmte
Datenstruktur" zu finden, die auf das Problem passt, und das war's. In
diesem Fall ist "das Problem", wie man "für sich selber" einen Haufen
Konten gliedert, und die Lösung aus Programmierer-Sicht ist, die Konten
"in einer Baum-Struktur zu gliedern" und fertig.

Was du nun wünschst, ist nicht mehr und nicht weniger als daß das Design
(endlich, endlich, endlich) nicht von Programmierern alleine ausgedacht
werden soll, sondern daß die tatsächlichen Bedürfnisse von
BuchhalterInnen im Programm abgebildet und befriedigt werden sollen. Das
ist fantastisch! Normalerweise kommen in Open-Source-Projekten gar nicht
genug fachkundige Nicht-Programmierer hinzu, als daß die Programmierer
jemals auf deren Fachkunde, deren Vorstellungen und deren Bedürfnisse
überhaupt eingehen könnten.

Aber nun wird es schwierig. Einen Teil deiner Wünsche kann man mit dem
vorhandenen (internen) Design relativ leicht erfüllen, aber einen
anderen Teil geht nur mit zunehmend schwerwiegenden internen Änderungen
von GnuCash zu erfüllen. Erschwerend kommt jetzt noch hinzu, daß die
Programmierer zur Zeit *nicht* in einer "aktiven Phase" sind (die gab es
zuletzt, äh, zum release von 1.8.0 Anfang 2003). Deshalb könnte es nun
leider häufiger passieren, daß du zusammen mit Programmierern ein
passendes Design erarbeitest, mit dem man deine Wünsche berücksichtigen
würde, aber dann müsste anschließend ein Programmierer 30-40 Stunden
Arbeit reinstecken und da ist zur Zeit kein Programmierer dafür verfügbar.

Es bräuchte nicht viel -- es bräuchte 1-2 neue Programmierer, die die
Herausforderung annehmen und nun für 2-3 Monate hier wirklich was neues
erschaffen wollen (ich kann nicht, da ich eine volle Stelle in der
Mobilfunk-Forschung habe). Aber im Moment sind die nicht da. Leider.
Bitte laß dich davon nicht entmutigen, sondern bleib dran und formuliere
deine Wünsche aus, so gut es geht. Hoffentlich kann jetzt gleich
möglichst viel davon umgesetzt werden, aber unter Umständen muß manches
davon leider noch ein bißchen warten. Ach ja, und da alle aktiven
Programmierer außer mir keine Deutschen sind, müsste man die konkreten
Vorschläge idealerweise irgendwann auf Englisch formulieren, aber das
kann auch gerne noch warten.
< /Vorrede >

Post by Andreas Schenk
(A) Ich wuerde GnuCash gerne so verwenden, dass ich beim Buchen Kontonummern
eingeben kann -- in ueblicher Buchhaltermanier. Dieser Wunsch wurde frueher
schon einmal in einer Liste geaeussert, ich weiss aber nicht, was der
aktuelle Stand ist. Daher die Frage: Kann man in GnuCash mit Kontonummern
buchen, wenn ja wie und ab welchem Release, oder kann man dies ab einem
absehbaren zukuenftigen Release?

http://bugzilla.gnome.org/show_bug.cgi?id=144669 Bisher gibt es keine
Aktivitäten, um das einzubauen. Geschätzter Aufwand: 8-12 Stunden Arbeit.

Post by Andreas Schenk
(B) Wenn ich einen Kontenplan (z.B. SKR3) "linear" mit Kontonummern anlege,
kann man daraus Bilanz und GuV erzeugen, oder muessen die Konten dazu
zwangsweise in einer Hierarchie angelegt werden, wie im "angeblichen" SKR4?

Die Bilanz und GuV sind ja als "Berichte" hinterlegt, die jeweils durch
einen ganz eigenen Programmcode erzeugt werden (der hier zufälligerweise
auch in der Programmiersprache "Scheme" ist, aber das nur am Rande, und
das ist nicht mal sonderlich kompliziert -- jeder Bericht ist ca. 500
Zeilen Programmcode). Die Abbildung der Gnucash-Konten auf die
Bilanzpositionen hängt also davon ab, wie diese Berichte programmiert
sind. Im Moment sind die (und alle anderen Berichte ebenfalls) so
programmiert, daß sie die Zuordnung einzig und allein über die
Hierarchie machen. Damit ist mit den momentanen Berichten die Antwort:
"Hierarchie ist zwangsweise erforderlich". Diese Beschränkung fällt in
dem Moment weg, wo jemand andere Berichte programmiert. Diese könnten
dann sich nur an den Kontonummern orientieren und dann wäre eine
vorhandene oder nicht vorhandene Hierarchie bedeutungslos. Oder so ein
neuer Bericht kann auch eine ganz eigene Zuordnung von den Kontonummern
zu den Bilanzpositionen mitbringen. Geschätzter Aufwand pro Bericht:
Wenn sich jemand in die Programmiersprache Scheme eingearbeitet hat,
dann 6-8 Stunden. (Der Aufwand, die Berichte in einer anderen
Programmiersprache einzubinden, übersteigt den Aufwand für das Erlernen
von Scheme bei weitem.)

Post by Andreas Schenk
(C) Falls der SKR3 nun doch in derselben Hierarchie angelegt werden muss, wie
der SKR4: Die Angabe z.B. im Kontobuch der 10 Konten (an das obige Beispiel
Aktiva:Umlaufvermoegen:Vorraete:Roh-, Hilfs- und Betriebsstoffe:Bestand Roh-,
Hilfs- und Betriebsstoffe
Mit Verlaub: eine Katastrophe.
Zudem haetten alle 10 Konten im Intervall 3970 - 3979 dieselbe Bezeichnung....
(Nach diesem Muster ist jedenfalls der SKR4 aktuell angelegt.)

Ja, wenn man in der Hierarchie bleiben muß, ergibt sich sowas
grauenhaftes. Solange niemand andere Berichte programmiert, geht das
leider nicht anders.

Post by Andreas Schenk
Kann man die
Konten in GnuCash als Hierarchie anlegen, aber die Angabe des Kontos z.B. im
Kontobuch auf den Teil nach dem letzten Doppelpunkt einschraenken? Wenn ja,
wie?

Äh... gibt das nicht eine Einstellung in den globalen Einstellungen?
http://bugzilla.gnome.org/show_bug.cgi?id=129099 Hm, anscheinend gibt es
bisher noch keine solche Einstellung. Geschätzter Aufwand: 3-4 Stunden
für die, die den Code etwas kennen.

Post by Andreas Schenk
(D) Wenn das alles nicht geht, scheint es mir im Moment am besten, die

Tja, das wiederum müsst ihr ausdiskutieren, da hab ich keine Ahnung.

Gruß

Christian

[Andreas Schenk]

Hallo Christian,

vielen Dank fuer Deine Antworten auf meine Fragen -- und fuer Deine Einladung,
mich fuer GnuCash zu engagieren. Ich denke aber nicht, dass ich Deine
Erwartungen erfuellen kann. Ich sage das lieber gleich, damit es nicht
spaeter zu Enttaeuschungen kommt. (Ich habe zudem auch das Problem, dass ich
meine Zeit im Wesentlichen mit dem Verdienen meiner Broetchen verbringen
muss....) Und um Dich noch mehr zu enttaeuschen: ich kann auch
Programmieren ;-)

Gerne bin ich bereit, mein Wissen zur Verfuegung zu stellen. Die Frage ist
nur, welches Wissen -- und wie? Sicherlich kann man GnuCash weiterentwickeln,
in Bezug auf die Abbildung fachlicher Anforderungen und in Bezug auf das
Anwendungsdesign. Was aber sind die Rahmenbedingungen, d.h. die Ziele und
Visionen?

Die Frage zu den Kontenplaenen ist nur ein Punkt. Das "Alles in einen Topf --
eine Datenstruktur -- werfen" schraenkt auch an anderen Stellen sowohl
funktional als auch in Bezug auf die Weiterentwicklung sehr ein. Ein zweites
Beispiel ist die Wertpapierverwaltung. Sie ist in GnuCash so abgebildet, dass
man zu jeder WKN ein Unterkonto anlegt, um den Bestand darauf zu verwalten.
Alles wird hier im "Kontenplan" (oder genauer Hauptbuch) verwaltet.

Normalerweise lagert man so etwas in ein eigenes Nebenbuch aus. D.h. man hat
eigene Datenstrukturen und -bestaende, eigene Bearbeitungsmasken etc. nur zur
Verwaltung des Bestandes an Wertpapieren -- voellig unabhaengig vom
Hauptbuch. GnuCash stellt so etwas rudimentaer zur Verfuegung, durch Sichten
auf Konten, die vom Kontentyp abhaengen. Weitere Nebenbuecher kann es geben
fuer z.B. Debitoren, Kreditoren, die Anlagenverwaltung, die
Materialverwaltung, die Immobilienverwaltung (Hallo Betina, wo in GnuCash
wuerdest Du z.B. die Mietvertraege Deiner 27 Einheiten verwalten? Wo die
Nebenkostenabrechnungen?) .......

Im Nebenbuch fuer die Wertpapierverwaltung werden z.B. die Stammdaten fuer
Wertpapiere, Depots, ... angelegt. (Schliesslich werden Wertpapiere in Depots
verwaltet, nicht auf Konten. Also sollte man auch Depots als eigenstaendige
Objekte in der Anwendung abbilden koennen.) Auch die Geschaeftsvorfaelle, wie
z.B. ein Kauf, werden im Nebenbuch (als Bewegungen) erfasst. Auswertungen zum
Wertpapierbestand stuetzen sich dann auf das Nebenbuch.

Daneben gibt es ein Hauptbuch. Bewegungen in den Nebenbuechern, fuehren i.d.R.
zu Buchungen im Hauptbuch. Das Hauptbuch ist dann z.B. die Basis fuer die
Erstellung von Bilanz und GuV. Je mehr Nebenbuecher man einfuehrt, um so
weniger bucht man direkt im Hauptbuch. Und umso mehr buchungsunabhaengige
Daten kann man verwalten (z.B. Mietvertraege oder Nebenkostenabrechnungen)

Ich moechte das Visionen "spinnen" hier beenden. Ich wollte damit lediglich
andeuten, dass man den Horizont beliebig weit stecken kann -- bis hin zu
einem GnuERP System. Worauf ich hinaus will ist folgendes: Was ist die
Planung fuer GnuCash? Wo soll sich die Anwendung hinentwickeln? Sind die
Ziele formuliert und abgestimmt (mit wem?). Passen die Ziele zur aktuellen
(oder einer anderen) Anwendergemeinde?

Falls die Vision hinreichend gross ist, muss man ein entsprechend modulares
Design zugrunde legen. Wahrscheinlich muss man GnuCash (proper) dann auf ein
reines Hauptbuch reduzieren, mit Schnittstellen, die es erlauben, fuer jedes
gewuenschte Nebenbuch ein eigenes Projekt zu schaffen, dass dieses mehr oder
weniger unabhaengig davon entwickeln kann. Lediglich die Fortschreibung ins
Hauptbuch
wuerde dann ueber die wohldefinierte Schnittstelle erfolgen. Je nach
geplantem Umfang muss man auch die laenderspezifischen Anforderungen
herausdividieren. Das waere sicherlich eine grosse aber auch spannende
Aufgabe. Und eine sehr schwere: denn der Uebergang zu einer derart
modularisierten Anwendung sollte nach Moeglichkeit ohne grosse Stoerung der
bestehenden Funktionalitaet und damit der Anwendergemeinde vollzogen werden.
Er wuerde zudem die Weiterentwicklung der Funktionalitaet fuer ein ganzes
Weilchen bremsen. Trotzdem dies eine Herkulesaufgabe ist: Ich kenne keine
Open-Source-Anwendung mit einem solchen (dann moeglichen) Funktionsumfang.

Soll der Funktionsumfang von GnuCash signifikant weiterentwickelt werden, wird
man um eine Modularisierung der beschriebenen Art sicher nicht umhinkommen.
Diese Modularisierung wird aber zwangsweise auch Auswirkungen auf die
Benutzerschnittstelle haben und mehr von dem Anwender verlangen. Wieviel auch
immer.

Erst wenn die Ziele (und Visionen) formuliert und aufgeschrieben sind, und
wenn sie von einer hinreichenden Menge von engagierten Entwicklern und
Anwendern getragen werden, kann man eine Weiterentwicklung oder ein
(Re)design von GnuCash diskutieren, dass mit einer gewissen
Wahrscheinlichkeit nicht im Papierkorb (oder /dev/null) landen und die
Beteiligten frustrieren wird.

Falls es hierzu etwas gibt, wuerde ich es gerne lesen (egal ob deutsch oder
englisch).

Mit freundlichen Gruessen

Andreas Schenk

[Christian Stimming]

Hallo Andreas,

Post by Andreas Schenk
Sicherlich kann man GnuCash weiterentwickeln,
in Bezug auf die Abbildung fachlicher Anforderungen und in Bezug auf das
Anwendungsdesign. Was aber sind die Rahmenbedingungen, d.h. die Ziele und
Visionen?

Visionen? In einem Open-Source-Projekt? (Wie war das mit Helmut Schmidt
http://www.google.com/search?q=visionen+soll+zum+arzt) Die sind so eine
Sache. Dabei hilft selbst die schönste Vision nichts, wenn diejenigen,
die sie formuliert und getragen haben, dann eh irgendwann wieder
verschwinden. Auf http://www.gnucash.org/en/roadmap.phtml (das Dokument
ist aus dem Jahr 2000) hat der ursprüngliche Initiator von gnucash,
Linas Vepstas, seine Ideen ausgebreitet. Der ist aber schon länger weg.
Seitdem hat niemand sonst eine Vision formuliert, so daß ich nur davon
ausgehen würde, daß halt jeder aktive Developer so sein eigenes Ziel
verfolgt. (In meinem Fall ist das "eine deutsche Finanzverwaltung für
den Heimanwender" mit Homebanking und bunten Bildern, und an beidem hab
ich maßgeblich mitgewirkt http://www.gnucash.org/en/history.phtml und
habe da ein Auge drauf.)

Die angefragten/vorgeschlagenen Änderungen für weitere deutsche
Geschäfts-Features dagegen würden wieder "eine neue Vision" dafür
benötigen und vor allem 1-2 Leute, die dieses eben auch wirklich tragen
und umsetzen wollen. Solange es das nicht gibt, kann man die
strukturellen Änderungen zwar denken, aber muß sich dann eine Lösung
ohne deren Verfügbarkeit aus den Fingern saugen.

Post by Andreas Schenk
Die Frage zu den Kontenplaenen ist nur ein Punkt. Das "Alles in einen Topf --
eine Datenstruktur -- werfen" schraenkt auch an anderen Stellen sowohl
funktional als auch in Bezug auf die Weiterentwicklung sehr ein. (...)

Natürlich. Ich hab ja nur den Ist-Zustand erläutert und wie er
seinerzeit begründbar war. Ich verstehe deine prima Ausführungen also
als Bestätigung, daß die grundsätzliche Struktur von Gnucash in einer
einzigen Kontenhierarchie eine fundamentale Begrenzung für zukünftige
Features ist.

Post by Andreas Schenk
Soll der Funktionsumfang von GnuCash signifikant weiterentwickelt werden, wird
man um eine Modularisierung der beschriebenen Art sicher nicht umhinkommen.

Es gibt eine Sorte von Modularisierung bereits im aktuellen
GnuCash-Code: Verschiedene Teile der GUI können über einzelne Module
eingebunden werden. Dadurch ist ja HBCI als extra Modul eingebunden.
Aber die Speicherungsmöglichkeiten eines solchen externen Moduls sind
nur rudimentär. Es fehlt also z.B. eine Modularisierung auf Datenebene,
d.h. mehrere Bücher in einer Datei oder Datenbank. Ich will also nur
darauf hinweisen, daß das Stichwort "Modularisierung" ziemlich allgemein
ist und man das noch genauer schärfen müsste.

Post by Andreas Schenk
Erst wenn die Ziele (und Visionen) formuliert und aufgeschrieben sind, und
wenn sie von einer hinreichenden Menge von engagierten Entwicklern und
Anwendern getragen werden, kann man eine Weiterentwicklung oder ein
(Re)design von GnuCash diskutieren, dass mit einer gewissen
Wahrscheinlichkeit nicht im Papierkorb (oder /dev/null) landen und die
Beteiligten frustrieren wird.

Genau. Deswegen erkläre ich hier wieder und wieder den Ist-Status von
GnuCash, bis 1-2 Leute die Herausforderung annehmen und selber etwas
Code in die Hand nehmen. Aber bis dahin ändert sich nix.

Post by Andreas Schenk
Falls es hierzu etwas gibt, wuerde ich es gerne lesen (egal ob deutsch oder
englisch).

Es gibt das GNUe-Projekt
http://www.gnu.org/software/gnue/project/what.html aber das geht auch
nur schleppend voran. Zu gnucash gibt es den obigen uralten Text und
sonst http://www.linuxwiki.de/GnuCash/DevelTexts und
http://www.linuxwiki.de/GnuCash/WeiterEntwicklung

Christian

[Andreas Schenk]

Hallo Christian,

Post by Christian Stimming
Visionen? In einem Open-Source-Projekt? (Wie war das mit Helmut Schmidt
http://www.google.com/search?q=visionen+soll+zum+arzt) Die sind so eine
Sache. Dabei hilft selbst die schönste Vision nichts, wenn diejenigen,
die sie formuliert und getragen haben, dann eh irgendwann wieder
verschwinden. Auf http://www.gnucash.org/en/roadmap.phtml (das Dokument

Ich habe bisher nicht herausgefunden, was Leute antreibt, sich aktiv in
Open-Source-Projekten zu engagieren. Ich stelle mir aber vor, dass laufend
Leute kommen und gehen. Damit kommen staendig neue Interessen hinzu, andere
verschwinden. Wenn man das Ueberleben des Projektes aber als oberstes Ziel
fixiert, so gibt dies vielleicht schon eine Leitlinie fuer die Entwicklung:
Die Anwendung sollte leicht in die eine oder andere Richtung erweiterbar
sein. Vielleicht (ich weiss es aber nicht) hat man dadurch die besten
Chancen, dass sich immer wieder neue Leute finden, die es weiter treiben.

Post by Christian Stimming
ist aus dem Jahr 2000) hat der ursprüngliche Initiator von gnucash,
Linas Vepstas, seine Ideen ausgebreitet. Der ist aber schon länger weg.

Danke, ich werde sie einmal lesen.

Post by Christian Stimming
Seitdem hat niemand sonst eine Vision formuliert, so daß ich nur davon
ausgehen würde, daß halt jeder aktive Developer so sein eigenes Ziel
verfolgt. (In meinem Fall ist das "eine deutsche Finanzverwaltung für
den Heimanwender" mit Homebanking und bunten Bildern, und an beidem hab

Das ist ein Ziel.

Wie gesagt, ich kenne die Open-Source-Szene nicht. Aktuell verfolge ich aber
ein Projekt, das sehr gut organisiert ist, man koennte sagen, dass dort ein
professionelles Projektmanagement gelebt wird. Soweit ich weiss, steckt kein
Unternehmen hinter diesem Projekt. Und die Leute (vielleicht eine Hand voll)
arbeiten sehr (!!!) engagiert daran, die gesetzten Ziele zu erreichen. Da
wird man leicht neidisch.

Post by Christian Stimming
ich maßgeblich mitgewirkt http://www.gnucash.org/en/history.phtml und
habe da ein Auge drauf.)
Die angefragten/vorgeschlagenen Änderungen für weitere deutsche
Geschäfts-Features dagegen würden wieder "eine neue Vision" dafür
benötigen und vor allem 1-2 Leute, die dieses eben auch wirklich tragen

Full time? ;-)

Post by Christian Stimming
und umsetzen wollen. Solange es das nicht gibt, kann man die
strukturellen Änderungen zwar denken, aber muß sich dann eine Lösung
ohne deren Verfügbarkeit aus den Fingern saugen.

Eine Weiterentwicklung in Richtung Geschaefts-Features ist sicher sehr schoen,
aber eine heikle Sache mit vielen Fallen. Man sollte sich so einen Schritt
sehr gut ueberlegen und vorsichtig zu Werke gehen.

Post by Christian Stimming
nur rudimentär. Es fehlt also z.B. eine Modularisierung auf Datenebene,
d.h. mehrere Bücher in einer Datei oder Datenbank. Ich will also nur
darauf hinweisen, daß das Stichwort "Modularisierung" ziemlich allgemein
ist und man das noch genauer schärfen müsste.

Klar. Bei der Gelegenheit: Was ist der Status der Datenbankanbindung? Die
Homepage stellt da was in Aussicht, der Artikel traegt aber leider kein
Datum.

Post by Christian Stimming

Post by Andreas Schenk
Erst wenn die Ziele (und Visionen) formuliert und aufgeschrieben sind,
und wenn sie von einer hinreichenden Menge von engagierten Entwicklern
und Anwendern getragen werden, kann man eine Weiterentwicklung oder ein
(Re)design von GnuCash diskutieren, dass mit einer gewissen
Wahrscheinlichkeit nicht im Papierkorb (oder /dev/null) landen und die
Beteiligten frustrieren wird.

Genau. Deswegen erkläre ich hier wieder und wieder den Ist-Status von
GnuCash, bis 1-2 Leute die Herausforderung annehmen und selber etwas
Code in die Hand nehmen. Aber bis dahin ändert sich nix.

Hier bin ich mir nicht so sicher. Vielleicht horchen ja Leute im Web, die man
nur durch eine Vision, nicht aber durch einen Ist-Zustand zur Teilnahme
einladen kann. Vielleicht horcht aber auch niemand. Wie schon gesagt, ich
verstehe Open-Source-Projekte nicht....

Ich habe mir fest vorgenommen, in diesem Projekt keinen Code in die Hand zu
nehmen. Ich kenne Scheme nicht und meine C/C++ Vergangenheit liegt schon ein
Weilchen zurueck.

Trotzdem, wer bestimmt eigentlich, was in die Sources aufgenommen wird? Welche
Dev-Mailing-Listen gibt es?

Langsam driften wir aber vom Thema ab......

Viele Gruesse

Andreas Schenk

[Christian Stimming]

Post by Andreas Schenk

Post by Christian Stimming
Visionen? In einem Open-Source-Projekt?

Ich habe bisher nicht herausgefunden, was Leute antreibt, sich aktiv in
Open-Source-Projekten zu engagieren.

Ich weiß es auch nicht endgültig. Ich kann mich nur auf Anekdoten und
eigene Erfahrung verlassen, und da sehe ich als Gründe 1. eigene
Bedürfnisse erfüllen ("scratching a personal itch") und 2.
Erfolgserlebnisse und Ruhm und Ehre einheimsen.

Damit der erste Grund ausreicht, um sich zu engagieren, ist es
entscheidend, daß der Ist-Zustand nicht mehr allzu weit vom gewünschten
Zustand entfernt ist -- und das ist die Erklärung, warum ich hier wieder
und wieder den genauen Ist-Zustand beschreibe: Ich will diejenigen
anlocken, die dort *fast* ihre Bedürfnisse drin wiederfinden und sich
gleichzeitig zutrauen, den fehlenden Teil selber beisteuern zu können.

Für den zweiten Grund wiederum muß jemand Ziele setzen und die auch
erreichen (können), man braucht also ein anerkanntes Projektmanagement.
In GnuCash haben wir das nur schwach. Das ist auch knifflig, denn jeder
Teilnehmer ist freiwillig da und wie will man dem Vorschriften machen,
welche Prioritäten er zu setzen hat?

Post by Andreas Schenk
Ich stelle mir aber vor, dass laufend
Leute kommen und gehen. Damit kommen staendig neue Interessen hinzu, andere
verschwinden.

Na ja. Um sich zu engagieren bzw. das Projekt zu beeinflussen, müsste
jemand schon über ein Jahr lang sich beteiligen. Das machen die
wenigsten. Daher ist das kurzfristige "kommen und gehen" in Hinsicht auf
das Projekt ziemlich wirkungslos. Der letzte, der gekommen ist, war Neil
Williams, und der wiederum ist genau aus dem "scratching a personal
itch"-Grund gekommen und baut sein gewünschtes feature ein.

Post by Andreas Schenk
Wie gesagt, ich kenne die Open-Source-Szene nicht. Aktuell verfolge ich aber
ein Projekt, das sehr gut organisiert ist, man koennte sagen, dass dort ein
professionelles Projektmanagement gelebt wird.

Glück für das Projekt. In GnuCash ist der Linas Vepstas notorisch
schlecht im project management gewesen (und das sagt er auch selber),
und daran krankt das ganze bis heute. Wir haben halt eine Reihe
selbstbewusster Individuen, die sich nur lose im Projekt zusammenfinden
und ihre jeweiligen Bereiche relativ autonom bearbeiten. Wie ich eben
hier in Deutschland. Für die Aufteilung der Bereiche müsste man sich das
ChangeLog der letzten Monate ansehen. Keiner von denen ist im Moment ein
eindeutiger Chef, und keiner davon würden seine eigene Agenda zugunsten
einer übergeordneten Vision erheblich zurückstellen. Also die
Zusammenarbeit ist gut und fruchtbar, solange man die Unterteilung in
die Bereiche implizit hat (z.B. ich und HBCI), aber wenn eine Vision
eine Prioritätensetzung verlangen würde, so daß man seinen eigenen
Bereich vernachlässigen müsste, dann wäre diese Vision nicht
mehrheitsfähig.

Daher ist das momentane Ziel "nur", das Projekt weiterleben zu lassen,
und darüber hinaus kann jeder eben mit seiner Agenda schalten und
walten, solange man keinem anderen Entwickler in die Quere kommt. So
verfolge ich eben das Ziel des "onlinefähigen privaten Finanzmanager"
und das mach ich auch.

Sobald ein neuer Entwickler nun eine "Buchhaltung für deutsche
Kleinunternehmen" haben möchte, hat er praktisch freie Hand, dieses auch
umzusetzen -- solange er damit den anderen nicht in die Quere kommt. Die
von dir erklärte Änderung in Haupt- und Nebenbücher ist daher
knifflig... wenn der neue und die Haupt-Entwickler eine Lösung finden,
die die anderen nur wenig betrifft, dann kann man das sicher einbauen.
Vielleicht stehen die Chancen für sowas gar nicht so schlecht.

Post by Andreas Schenk

Post by Christian Stimming
Die angefragten/vorgeschlagenen Änderungen für weitere deutsche
Geschäfts-Features dagegen würden wieder "eine neue Vision" dafür
benötigen und vor allem 1-2 Leute, die dieses eben auch wirklich tragen

Full time? ;-)

Nö, aber im Durchschnitt 5-10 Stunden pro Woche schon.

Post by Andreas Schenk

Post by Christian Stimming
Es fehlt also z.B. eine Modularisierung auf Datenebene,
d.h. mehrere Bücher in einer Datei oder Datenbank.

Klar. Bei der Gelegenheit: Was ist der Status der Datenbankanbindung? Die
Homepage stellt da was in Aussicht, der Artikel traegt aber leider kein
Datum.

Die läuft, soweit ich weiß. Man kann aber keine der "Geschäfts"-Features
nutzen und HBCI geht auch nur eingeschränkt.

Post by Andreas Schenk
Ich habe mir fest vorgenommen, in diesem Projekt keinen Code in die Hand zu
nehmen. Ich kenne Scheme nicht und meine C/C++ Vergangenheit liegt schon ein
Weilchen zurueck.

Ok, das ist eindeutig. Dann kannst du aber immerhin noch die
Strukturüberlegungen von dir an irgendeinem Ort ablegen (wiki...), wo
ein später ankommender dies in Ruhe lesen kann. Ist ja immerhin ein
guter Beitrag.

Post by Andreas Schenk
Trotzdem, wer bestimmt eigentlich, was in die Sources aufgenommen wird? Welche
Dev-Mailing-Listen gibt es?

Wer das bestimmt? Aktuell Derek Atkins, Josh Sled, ich, gelegentlich
(noch) Linas Vepstas. Es gibt noch ein paar mehr Leute mit
CVS-Schreibzugriff, aber insgesamt nur wenige. Haupt-Mailingliste ist
gnucash-devel. Sollte in der Datei HACKING im tarball drinstehen.

Christian

[Micha Lenk]

Hallo,

mit großem Interesse habe ich alle Ausführungen und Fragen zur Zukunft
von GnuCash von Andreas Schenk gelesen. Leider lese ich die Mailingliste
nicht immer zeitnah, so dass ich erst jetzt zum Antworten komme.

Post by Andreas Schenk
Eine Weiterentwicklung in Richtung Geschaefts-Features ist sicher sehr schoen,
aber eine heikle Sache mit vielen Fallen. Man sollte sich so einen Schritt
sehr gut ueberlegen und vorsichtig zu Werke gehen.

Dass eine Weiterentwicklung in Richtung Geschäfts-Features auch sehr
heikel ist sehe ich auch so. Eigentlich alle der von GnuCash angebotenen
Geschäfts-Features sind für mich unbrauchbar, weil sie in meinen Augen
nicht die nötige Flexibilität bieten bzw. ihre Anpassung bei weitem zu
komplex ist.

Post by Andreas Schenk

Post by Christian Stimming

Post by Andreas Schenk
Erst wenn die Ziele (und Visionen) formuliert und aufgeschrieben sind,
und wenn sie von einer hinreichenden Menge von engagierten Entwicklern
und Anwendern getragen werden, kann man eine Weiterentwicklung oder ein
(Re)design von GnuCash diskutieren, dass mit einer gewissen
Wahrscheinlichkeit nicht im Papierkorb (oder /dev/null) landen und die
Beteiligten frustrieren wird.

Genau. Deswegen erkläre ich hier wieder und wieder den Ist-Status von
GnuCash, bis 1-2 Leute die Herausforderung annehmen und selber etwas
Code in die Hand nehmen. Aber bis dahin ändert sich nix.

Hier bin ich mir nicht so sicher. Vielleicht horchen ja Leute im Web, die man
nur durch eine Vision, nicht aber durch einen Ist-Zustand zur Teilnahme
einladen kann. Vielleicht horcht aber auch niemand. Wie schon gesagt, ich
verstehe Open-Source-Projekte nicht....

Ich horche!
Über die Zukunft von GnuCash habe ich mir auch schon hin und wieder
Gedanken gemacht. Genauer angesehen habe ich mir den Code von GnuCash
noch nicht, aber ich schwanke in meiner Meinung zwischen einem "oh, das
müsste man alles von Grund auf neu machen" und einem "oh, da muss man
aber noch ganz viel machen, damit GnuCash an sowas wie Lexware ran
kommt". Ja, in der professionellen Buchhaltung würde ich GnuCash
tatsächlich gerne sehen.

Die von Dir angedeuteten notwendigen Strukturänderungen gehen in meinen
Augen definitiv in die richtige Richtung, dass GnuCash wirklich
großartig und mächtig durch die Vielzahl der Anwender wird - so wie
jetzt z.B. KDE oder Gnome eine riesige Fangemeinde haben.

Insbesondere die Reduzierung des eigentlichen Kerns von GnuCash auf das
Hauptbuch halte ich für einen richtigen und nötigen Schritt, der GnuCash
eine große Zukunft bahnen kann.

Ich hätte jedenfalls ein gewisses Interesse daran, an einer Vision für
GnuCash mit zu entwickeln, sofern sich denn irgendwie noch mehr Anhänger
dieser Vision finden (ansonsten ist die Vision vielleicht ja doch nicht
so toll). Dass ich Zeit finde, mich auch in die Programmierung
einzubringen, mag ich jedoch nicht versprechen.

Gruß
Micha