[gnucash-de] Vorschlag zum Thema Buchungen loeschen

Heinz Repp heinz.repp at freenet.de
Di Okt 22 06:50:04 EDT 2013


Hallo Michael,

Am 21.10.2013 11:47, schrieb Michael Faßbender:
> ich habe eben den Beitrag von Mario gelesen

Ich habe eben noch mal so die letzten 100 Mailinglist-Nachrichten nach 
einem Mario durchsucht und bin nicht fündig geworden. Aber halt, da 
stand ja was von

> /Betreff Beitrag:
> *Mario Goppold * ml at goppold.net<mailto:gnucash-de%40gnucash.org>
> Mi Jan 30 11:59:15 EST 2008
> /

Oops, das ist ja schon fast 6 Jahre her, gut, dass im Archiv der 
Mailingliste die letzten 10 Jahre noch auffindbar sind, es ging also um 
folgendes Thema (hier die Antwort von Christian):

Am Mittwoch, 30. Januar 2008 22:12 schrieb Christian Stimming:
> Am Mittwoch, 30. Januar 2008 17:59 schrieb Mario Goppold:
>> Um dem Steuerberater den Wind aus den Segeln zu nehmen der mit Aussagen
>> kommt wie "... das ist kein richtiges Buchhaltungsprogramm, da kann man
>> ja jederzeit Buchungen löschen ..." haben wir auf allen (wir setzten
>> seit über 10 Jahren auf Linux z.Z. openSUSE) PCs eine spezial-Version
>> von GC installiert in der der Button "Buchung löschen" hinausgepatched
>> worden ist. Das ist sicher nicht der Weisheit letzter Schluss und um zu
>> einem Programm zu kommen was den GoB genügt sind bestimmt auch noch ein
>> paar andere Sachen zu berücksichtigen. Wir würden hier z.B. folgendes
>> Vorschlagen:
>> Buchungen sind solange sie nicht abgeglichen sind veränderbar und auch
>> löschbar. Wenn ein Abgleich gemacht wurde (z.B. Wochenweise oder
>> Monatsweise) sind die Buchungen unveränderlich. Das lässt einen die
>> Freiheit die Buchung zu korrigieren und wenn der/die Buchhalter/in der
>> Meinung ist alles ist stimmig kann ein Abgleich vorgenommen werden.
>
> das heißt also, in der Software sind die Buchungen nicht mehr veränderbar,
> aber in der gespeicherten Datei wären sie weiterhin für jeden Texteditor
> erreichbar? Wenn der fehlende Button in der Software tatsächlich schon so
> viel ausmachen würde für eine GoB-"Ähnlichkeit" :-), dann kann das von mir
> aus gerne als Patch mit in den Source, und man würde das mit einem
> configure-switch aktivieren können. Vorschläge für patches?

Danach ist es seinerzeit nicht mehr weitergegangen - kein Wunder, denn 
durch solche Fake-Sperren werden die gesetzlichen Forderungen in A0 § 
146 Absatz 4 wohl nicht wirklich erfüllt, der da heißt:

> Eine Buchung oder eine Aufzeichnung darf nicht in einer Weise verändert werden, dass der ursprüngliche Inhalt nicht mehr feststellbar ist. Auch solche Veränderungen dürfen nicht vorgenommen werden, deren Beschaffenheit es ungewiss lässt, ob sie ursprünglich oder erst später gemacht worden sind.

Um diese Forderungen in GnuCash zu erfüllen, müsste GnuCash jede 
Änderung protokollieren und dauerhaft archivieren - und dann auch noch 
die Unveränderlichkeit der Aufzeichnungen sicherstellen. GnuCash 
protokolliert zwar die letzten Änderungen, um die im Falle eines Crashes 
wieder in die letzte erhaltene Dateiversion einspielen zu können, in der 
Datei selbst werden die Transaktionen allerdings nicht mehr 
protokolliert. Eine entsprechene Änderung wäre mit erheblichem Aufwand 
und einer Änderung des Speicherformates verbunden.

Es gibt allerdings *außerhalb* von GnuCash durchaus Möglichkeiten, um 
mit wenig Aufwand eine solche Unveränderbarkeit sicherzustellen. Eine 
bestände etwa darin, regelmäßig, z. B. monatilich, eine Kopie der Datei 
(XML/Sqliite) oder einen Datenbank-Dump (MySQL/MariaDB/PostgreSQL) 
anzulegen und diese digital zu signieren. Streng genommen müsste das 
eine Qualifizierte elektronische Signatur sein, aber mittlerweile setzt 
sich denke ich langsam die Auffassung durch, dass dies einen 
unverhältnismäßigen Aufwand darstellt, man dürfte vor Gericht wohl auch 
mit einer vernünftig dargelegten OpenPGP-Signatur bestehen können.

...  Michael Faßbender:
> und moechte dem noch eins
> drauf setzen bzw. den Vorschlag machen, dass in den Grundeinstellungen
> "einfach" Periodenabschlüsse bzw. passwortgeschuetzte Einstellungen
> moeglich sein sollten wie:
>
> Aenderungen nur nach Passworts-Abfrage moeglich (lokal sind ja alle User
> Admins, oder?):

Nun, lokal können Anwender ganz unterschiedliche Rechte haben, je nach 
dem, wie der Administrator das eingerichtet hat, aber ich denke, du 
meinst etwas anderes. Wenn ein Anwender in einer GnuCash-Datei 
irgendetwas eintragen können soll, braucht er für diese Datei natürlich 
Schreibrechte - und damit kann er alles ändern (Für den Betriebsprüfer 
reicht allerdings eine Nur-Lesen-Berechtigung).

> Buchungen zulassen von:  01.01.2013
> Buchungen zulassen bis:   31.08.2013
> Loeschungen von Buchungen sollten dann nur noch ab 1.9.2013 moeglich sein.
> Programmiertechnisch muesste hier doch nur eine separate Funktion
> abgefragt werden, die die Aenderung des bei Buchungserfassung
> vorgeschlagenen Tagesdatum nur ab "Buchungen zulassen bis" zulaesst.
> Somit waere eine Sicherheit eingebaut!

Was du vorschlägst, würde, seriös implementiert, eine komplette, fein 
abgestimmte Benutzerverwaltung in GnuCash erfordern. Das ist nicht 
einmal ansatzweise vorhanden. Eine solche Implementation müsste dazu 
auch alle Vorgänge (natürlich einschließlich Berichterstellung, 
Rechnungswesen, usw.) erfassen - die dazu notwendigen Änderungen würden 
so ziemliche jede Quelldatei betreffen - ein immenser Aufwand, und eben 
gerade nicht "nur eine separate Funktion".

Allerdings: auch hier gäbe es durchaus *außerhalb* von GnuCash selbst 
Ansätze, um ähnliches zu erreichen. So wäre es etwa möglich, mittels 
manuell direkt in der Datenbank gespeicherten Stored Procedures 
(PostgreSQL,MariaDB,MySQL) oder Triggern (SQLite) nur bestimmte 
Veränderungen zuzulassen, andere würden dann fehlschlagen. Ich weiß 
allerdings nicht, wie GnuCash darauf reagiert, wenn 
Datenbanksoperationen fehlschlagen. Im Falle "richtiger" 
Server-Datenbanken läßt sich das auch mit einer ausgefeilten 
Rechtevergabe kombinieren - und der Benutzer ist in den Stored Procdures 
abfragbar. Die SQLite-Datei ist natürlich trotzdem noch mit jedem 
anderen SQLite-Frontend veränderbar. GnuCash müßßte dazu nicht geändert 
werden, man müßte sich allerdings intensiv mit dem Datenformat beschäftigen.

Jm2C

Heinz


Mehr Informationen über die Mailingliste gnucash-de