[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