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

Manfred Usselmann usselmann.m at icg-online.de
Sa Feb 16 14:10:26 EST 2008


Manfred Usselmann <usselmann.m at icg-online.de> schrieb am Sat, 16 Feb
2008 14:07:34 +0100:

> 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.

Evtl. muesste man dann auch die Buchung(en) auf de(m/n) Gegenkont(o/en)
gleich mitfestschreiben. Beim derzeitigen Abgleichen wird, soweit ich
weiss, nur der Buchungsteil im aktuellen Konto abgeglichen.

Gruss,
Manfred

 

> > 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