[gnucash-de] Re: Kontenplaene, zum zweiten

[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