Buchhaltung mit BASE

Deutsch
#1

Nachdem ich bisher meine Einnahme-Überschussrechnung mit CALC gemacht habe, möchte ich meine Buchhaltung auf BASE umstellen. Dabei sollte es auch möglich sein, die GoBD im Hinblick auf die Unveränderbarkeit zu beachten.

Nach § 146 Absatz 4 AO darf eine Buchung oder Aufzeichnung nicht in einer Weise
verändert werden, dass der ursprüngliche Inhalt nicht mehr feststellbar ist. Dazu
dürfen keine Veränderungen vorgenommen werden, die keinen Rückschluss darauf
zulassen, ob sie ursprünglich oder erst später initiiert wurden. 5 Das zum Einsatz
kommende DV-Verfahren muss Gewähr dafür bieten, dass alle Informationen (Pro-
gramme und Datenbestände), die einmal in den Verarbeitungsprozess eingeführt
werden (Beleg, Grundaufzeichnung, Buchung), nicht mehr unterdrückt oder ohne
Kenntlichmachung überschrieben, gelöscht, geändert oder verfälscht werden kön-
nen. Bereits in den Verarbeitungsprozess eingeführte Informationen (Beleg, Grund-
aufzeichnung, Buchung) dürfen nicht ohne Kenntlichmachung durch neue Daten
ersetzt werden.

Ich habe aber leider keine Ahnung, ob man das machen kann und wie man das umsetzen könnte.

Vielen Dank für eure Ideen!

#2

Wenn ich das richtig verstehe, dann dürfen Datensätze nicht geändert, wohl aber gelöscht werden. Das kann natürlich ein Formular übernhmen, aber das Formular kann überlistet werden (Direkteingabe in eine Tabelle). Das kann bei der Tabelle durch einen Trigger vermieden werden, so dass die Tabelle auch nur neue Datensätze und das Löschen von Datensätzen zulässt.

Für Änderungen muss dann ein neuer Datensatz erstellt werden, der sich auf den vorhergehenden Datensatz bezieht und dann nur die Änderung abspeichert. Auch diesen kannst Du nur noch löschen, nicht wieder ändern (Trigger). Wenn Du die Standardbeziehung zwischen den Datensätzen bestehen lässt, dann ist es auch unmöglich, einen alten Datensatz zu löschen, wenn er von einem neueren Datensatz benötigt wird.

#3

Leider darf man nicht löschen ohne das zu dokumentieren. Also einfach löschen ist nicht in Ordnung.
Es gibt 2 Möglichkeiten:

  1. Dokumentiertes Löschen (analog dem Durchstreichen auf einem Kontoblatt auf Papier) und eine korrigierte Buchung (die “richtige” Buchung) speichern.

  2. Löschen technisch verhindern und über die Buchung über eine Korrekturbuchung berichtigen:

  • indem man durch eine gegenläufige Buchung die falsche Buchung neutralisiert (“Generalumkehr”) und dann “richtig” bucht (das wäre meine favorisierte Lösung)
  • indem man mit einer Buchung eine korrigierende Differenzbuchung vornimmt (was m.E. sehr unübersichtlich ist)

Also ein Löschen ohne Dokumentation sollte nicht möglich sein.

Kann man das in BASE bewerkstelligen? Mir wäre am liebsten, das würde ohne externe Datenbank (MySQL/MariaDB) sondern am besten mit der internen Firebird-Datenbank möglich sein.

#4

Ich kenne kein System, das Löschen technisch sicher verhindern kann.
Setze ich z.B. einen Trigger, um das Löschen von Datensätzenm nach dem Speichern unmöglich zu machen, so kann ich natürlich den Trigger auch wieder entfernen, wenn ich über das System Bescheid weiss.
Unterbinde ich das Löschen, indem ich eine weitere Tabelle mit lauter Fremdschlüsseln erzeuge, die zuerst gelöscht werden müssten, dann ist das genauso.
Vergebe ich bestimmte Benutzerrechte (bei den internen Datenbanken und bei einer externen Firebird-Datenbankdatei nicht möglich), dann brauche ich mich anschließend nur als der berechtigte Administrator einzuloggen und kann weiter Daten löschen.

Genauso wenig lässt sich natürlich die Änderung sicher verhindern.

Vermutlich brauchst Du, um den Ansprüchen zu genügen, eine Serverdatenbank wie MariaDB/MySQL oder PostgreSQL mit entsprechender Benutzerverwaltung und dauernder Sicherung der Logdateien.

Auch hier gilt: Ich kann das Löschen erschweren, aber technisch verhindern kann ich es nicht. Das gilt ja auch für eine ganz altertümliche Buchhaltung. Stell Dir einfach die Tintenroller der heutigen Zeit vor. Die haben den Radierer gleich dabei…

#5

Danke für Deine Antwort.
In jedem System gibt es einen, der alles darf: root, admin etc.

Bei den professionellen Buchhaltungssystemen wird es so sein, dass der Hersteller als admin einem user=Buchhalter alle Rechte einräumt, um vernünftig arbeiten zu können, aber Löschen und Veränderung der zugrundeliegenden Tabellen verbietet. Dieser admin wird dem Kunden das Passwort nie preisgeben. Dadurch ist die GoBD gewährleistet.

Es gibt bei diesen Buchhaltungen zwei Phasen:

Phase 1: Man kann Buchen, Löschen und Ändern was man möchte.

Phase 2: Die Buchungen werden zu einem bestimmten Termin (auf Knopfdruck) “festgeschrieben” und sollten dann nicht mehränderbar sein. Das Löschen von Datensätzen sollte entsprechend protokolliert und dokumentiert werden.

Dann beginnt man für die folgenden Buchungen wieder mit Phase 1.

Am Ende des Wirtschaftsjahres werden dann die letzten Buchungen festgeschrieben und das Buchungsjahr ist abgeschlossen.

Leider muss man dem Hersteller jeden Handgriff bei jeder Gesetzesänderung (neue Umsatzsteuersätze, neue Buchungskonten usw.) mit entsprechenden Updates teuer bezahlen (mindestens) jährlich.

Ich möchte jetzt so eine Buchhaltungsdatenbank für meine selbständig tätige Tochter und auch für mich “revisionssicher” und entsprechend der GoDB “unveränderbar” gestalten.

Das bedeutet, ein admin richtet alles ein und gibt dem user=Buchhalter alle erforderlichen Rechte zum Buchen, Einrichten von neuen Konten, unbenutzte Konten werden einfach nicht mehr bebucht, womit sich ein Löschen erübrigt. Nach dem Festschreiben sind Änderungen an den Buchungen nicht mehr möglich. Dieses admin-Konto könnte dann mit einer Passwort-Änderung durch ein Zufallskennwort, welches das System erzeugt, unbrauchbar gemacht werden. Damit wäre als einziger Benutzer der Datenbank nur der user=Buchhalter mit entsprechenden Beschränkungen eingerichtet.

Was meint ihr?

P.S. Warum ich das machen möchte und nicht einfach den Lexware Buchhalter oder das WISO-Programm benutze?
Ich möchte BASE lernen und ein Buchhaltungsprogramm für meine Familie einrichten. Das notwenige steuerliche Fachwissen ist vorhanden.

#6

Base kann man nicht lernen. Base ist überhaupt keine Datenbank. Base ist ein ziemlich rudimentärer Werkzeugsatz, um mit klassischen relationalen Datenbanken im Kontext von LibreOffice zu arbeiten. Das beinhaltet die manuelle Eingabe von relationalen Datensätzen mittels Formularen (eher so im Stil der 90iger Jahre) sowie das Füllen von Office-Dokumenten mit Datenbankdaten, insbesondere Berichte, Serienbriefe und Tabellenkalkulationsmodelle.
Hast Du also eine Datenbank, mit der Du vertraut bist und verbindest Du diese Datenbank mit einem Base-Dokument, dann wirst Du kaum irgendwelche Überraschungen erleben, weil Du 1. die Datenbank schon kennst, 2. die Funktionalität, die Du mit Base erhältst, ziemlich überschaubar ist und 3. die Fehlstellen und Fehler dieses komplett unterentwickelten Werkzeugsatzes vielleicht das überraschendste ist.
Für eine Buchhaltung, die den gesetzlichen Anforderungen genügt, braucht es eine professionelle Plattform zur Entwicklung von Datenbankanwendungen und ein Team von Juristen und Entwicklern.

#7

Hallo Villeroy,

ich finde Deine Antworten (auch in anderen Posts) immer erfrischend und erhellend. Z.B. dass BASE gar keine Datenbank ist. Trotzdem empfiehlst Du die Nutzung von BASE bei komplexeren Zusammenhängen, für die CALC nicht verwendet werden soll (CALC ist ja auch keine Datenbank).

Wie gesagt nutze ich seit Jahren CALC für meine Einnahme-Überschuss-Rechnung (EÜR) und das funktioniert ganz gut. Bei einer Steuerprüfung wird es aber höchstwahrscheinlich Diskussionen geben wegen der GoBD (“Unveränderbarkeit”). Daher kam der Gedanke, die EÜR mit BASE einzurichten und für die GoBD entsprechende Vorkehrungen zu treffen.

Es soll hier nicht eine Finanzbuchhaltung für einen international tätigen Konzern programmiert werden, deswegen ist ein Team von Juristen und Entwicklern sicherlich nicht notwendig.

Für mich ist wichtig zu wissen und zu verstehen, wie ich Buchungen, die nachweislich nicht mehr verändert werden sollen, kennzeichnen kann (“festschreiben”) und eben vor Veränderungen schützen kann. Evtl. ginge das mit einer schreibgeschützten Tabelle, in die die festgeschriebenen Buchungen kopiert werden (aber dazu müsste man ja wieder temporär den Schreibschutz aufheben). Wenns so einfach wäre, müsste ich dieses Forum nicht bemühen.

In CALC ginge das ganz gut mit einem Status “Festschreibung”, der über bedingte Formatierung erzeugt wird. Man kann das auch absichern. Dazu dürfte aber der Haken bei den Zirkulären Bezügen (Iterationen) NIE mehr entfernt werden. Das habe ich nicht hinbekommen. Selbst mit einem Makro nicht. Evtl. hat da jemand eine Idee?

#8

Es reicht ja schon, eine Tabelle so einzurichten, dass nur das Einfügen von Daten erlaubt ist. Damit könntest Du das Ganze festschreiben. Nur solltest Du auf jeden Fall vorbeugen und eine externe Datenbank nehmen, damit die Daten auch sofort geschrieben werden und nicht doch noch verloren gehen können, falls irgendetwas mit dem Schließen der Datei nicht hin hat.

Für den Hausgebrauch reicht schon eine Tabelle, die keinen definierten Primärschlüssel hat. die ist nur für direkte SQL-Eingaben zugänglich. Da kannst Du dann Deine festgeschriebenen Daten rein packen und gut is.

#9

Entziehe dem Datenbankanwender das Recht, Datensätze zu löschen.

#10

Das Recht entziehen geht dann aber nur mit einer Serverdatenbank, oder?

#11

Nö, das geht mit jeder Datenbankverbindung z.B. auch mit jdbc:hsqldb:file: oder mit befreitem Firebird3, nur halt nicht mit dem eingebetteten Kram.
ADD USER, ADD GROUP, GRANT und REVOKE sind die Schlüsselworte.

#12

Das klingt ja super.
Ich wollte jetzt nicht einen Datenbankserver starten müssen …

#13

Was hältst Du von SQLite?

#14

Das ist vollkommen wurscht. Was hältst Du von den Regeln der doppelten Buchführung und beherrscht Du SQL Transactions?

#15

Doppelte Buchführung = Bilanzieren kenne ich. Für EÜR ist das aber nicht erforderlich. Das ist der Vorteil bei Freiberuflern. SQL Transactions sagt mir (noch) nix.

#16

OK, für EÜR brauchst Du nicht unbedingt Transaktionen (“führe den Buchungssatz nur aus wenn beide Seiten der Buchung konsistent sind”).
“Mal einfach so” ohne Vorkenntnisse eine Buchhaltung zusammenschustern funktioniert trotzdem nicht, weil Du nicht wissen kannst, was Du zu tun hast. Da ist § 146 Absatz 4 AO das allergeringste Problem.

#17

Ich mag Sqlite, aber in obiger Argumentation käme es erstmal nicht in Frage, weil es keine Benutzerverwaltung gibt.

#18

@Villeroy : “befreite Firebird3” - damit meinst Du dann wohl eine, die nicht über den Datenbankassistenten als externe Firebird DB erstellt wurde, oder? Dort kann ich zwar klaglos Passwörter vergeben, mich aber ebenso mit gleichem Namen ohne Passworteingabe anmelden. Gerade noch einmal getestet: Es erscheint die Passwortnachfrage, ich gebe nichts ein (obwohl definiert) und habe den vollen Zugriff. Ich kann auch den Benutzernamen bei der Passworteingabe auf irgendeinen beliebigen Namen ändern. Ist dann auch schön unten angezeigt, hat aber keine Bewandnis.

#19

Denk darüber eventuell nochmal nach. Ich habe bei meinen ersten Tests fur eine DB auf meinem Synology-NAS auch eine MariaDB lokal auf meinem Laptop installiert, was ziemlich einfach war. Und damit hat man einerseits eine Benutzerverwaltung und andererseits diverse Werkzeuge, die mit MySQL/ MariaDB zusammenarbeiten, falls LibreOffice/Base mal nicht reicht…
.
Unsere heutigen Rechner verkraften das recht problemlos.

#20

Dann werde ich das mal versuchen. Das erscheint mir doch vernünftig, sichere Passwörter zu vergeben, die man nicht einfach ignorieren kann. Sonst könnte ich gleich dBase verwenden. Das hatte ich schon vor langer, langer Zeit …

Impressum (Legal Info) | Datenschutzerklärung (Privacy Policy)   Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.