[gnucash-de] GoB und Buchungen nicht mehr veränderbar machen

Manfred Usselmann usselmann.m at icg-online.de
Sa Feb 16 08:07:34 EST 2008


Christian Stimming <stimming at tuhh.de> schrieb am Fri, 15 Feb 2008
21:54:15 +0100:

> Am Montag, 4. Februar 2008 18:50 schrieb Mario Goppold:
> > Solange eine Änderung vollständig nachvollziehbar ist sollte das
> > (meiner Meinung nach) nicht so eng gesehen werden. Sowas könnte
> > vielleicht auch erst im Bericht/Buchungsjournal zu sehen sein, dass
> > sich die Buchung (möglicherweise mehrfach) geändert hat. Inwieweit
> > sowas konform ist muss dann eben der WP sagen. Ich denke, dass das
> > sowieso ein iterativer Prozess ist.
> >
> > Die Diskussion zeigt mir, das es wichtig wäre, dass sich die
> > Hauptentwickler  äußern ob, unabhängig von einer Zertifizierung, GoB
> > Konformität angestrebt wird.
> 
> Also für mich war die Diskussion insoweit erhellend, als dass es
> tatsächlich vor allem um die GUI, also die für den Anwender
> erreichbaren Änderungsmöglichkeiten geht. Und da können wir als
> Entwickler tatsächlich gerne was einbauen, so dass man bei Erstellung
> einer neuen Datei dann ankreuzt "GoB-Konformität: Alte Buchungen nur
> stornieren, nicht ändern" und dies dann auch so ist.
> 
> Hab das eben als Vorwarnung auf der englischen Liste erläutert: 
> http://article.gmane.org/gmane.comp.gnome.apps.gnucash.devel/22675
> 
> Wie in der gnucash-devel Nachricht erwähnt: Wie sehen die technischen 
> Änderungen denn nun konkret aus? Da brauche ich nun ein paar konkrete 
> Antworten:
> * Eingeschaltet wird das mit einer Einstellung, die in der Datei
> (intern dem "gnc-book") gespeichert wird. 

Gute Loesung. Die Einstellung darf aber nicht mehr rueckgaengig machbar
sein.

> Wenn das da also aktiv ist,
> soll folgendes passieren:
> * Den Knopf "Löschen" weg, aber was noch? Denn man kann ja alle
> Änderungen anklicken und alle Datenfelder darin ändern. Soll das
> Ändern in den Datenfeldern also auch abgeschaltet werden? Vermutlich
> ja. 

Eine Option waere sicher, aendern und loeschen komplett abzuschalten.
Jede Buchung kann ja storniert oder durch eine weitere Buchung
korrigiert werden. Damit entspricht es dem Papierprinzip, wo ich auch
nicht radieren, sondern nur durchstreichen und neu hinschreiben darf.

> * Aber soll das Ändern auch für die eben erst eingegebene Buchung
> abgeschaltet sein? 

Dann ja.

> Oder soll es für die Buchungen von heute erlaubt,
> für den Rest dagegen abgeschaltet sein? Statt "heute" auch gerne: Die
> letzten 24 Stunden, die letzten 7 Tage? 

Das find ich etwas wage und auch eher unpraktikabel. Zumal
Manipulationen durch Umstellung des Rechnerdatums recht einfach sind.
Wenn, dann wuerde ich wahrscheinlich fuer die Buchungen des laufenden
Buchungsmonat eine Aenderung erlauben. Daher dann lieber ein frei
vorgebbares Abschlussdatum fuer die ganze Datei, so dass man keine
davorliegenden Buchungen eingeben darf und auf die Art z.B. einen
Monatsabschluss darstellen und den davorliegenden Zeitraum fixieren
kann. Dieses Abschlussdatum sollte dann nur vorwaerts aenderbar sein.

> * Und man könnte dann immer noch eine Buchung mit einem beliebigen
> Datum eingeben. 

Das waere u.U. schlecht, weil ich damit doch rueckwirkend Salden
veraendern kann. Aber zumindest waere es dann dokumentiert.

> Soll das auch verboten sein, also immer nur das
> Buchungsdatum von heute erlauben? Oder ein Datum der letzten 2..4..7
> Tage?

Ein andere (fuer mich bessere) Moeglichkeit waere, abgeglichene
Buchungen nicht mehr aenderbar zu machen. Damit kann ich Monats- und
Jahresabschluesse machen, indem ich die Konten abgleiche und damit
festschreibe. Die Flags gibt es ja schon und soviel ich weiss, wird
auch das Abgleichsdatum gespeichert. Es muesste aber auch
sichergestellt werden, dass man keine Buchungen mehr vor diesem
Abgleichs(=Abschluss)datum  speichern darf. Evtl. dann eine Option,
Reports auf abgeglichene (festgeschriebene) Buchungen zu beschraenken
und dies im Report auch sichtbar machen. Dann ist klar, dass dieser
Report nicht mehr (uebers GUI) geaendert werden kann.
 
 
> Für's Programmieren wäre am einfachsten: Gar keine Buchungen ändern
> (außer jene, die man soeben eingibt) und Buchungsdatum fest auf heute
> vorgegeben.

Was waere in dem Fall mit Onlineabruf von Kontoumsaetzen bzw. Import
und terminierten Buchungen, die noch nicht bestaetigt sind?

Ausserdem denke ich, ein Buchungsdatum in der Zukunft muesste moeglich
sein. 

Gruss,
Manfred

> 
> @Mario: Kannst auch gerne deine Änderungen nochmal als Patch hier
> einschicken, dann schaue ich, ob man davon nicht einiges direkt ins
> SVN übernehmen kann.
> 
> Gruß
> 
> Christian
> _______________________________________________
> gnucash-de mailing list
> gnucash-de at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-de


-- 
________________________________________________________________________
 Manfred Usselmann                            usselmann.m at icg-online.de