minifakt · PGfakt · Ralf Burger

Theoretische Überlegungen zu möglichen Plänen – minifakt und PGfakt

Stand 30.10.2026. Hier stehen nur Überlegungen. Nichts davon ist beschlossen, begonnen oder zugesagt.

Die Frage dahinter: Wie könnte minifakt optional im Netz und an mehreren Arbeitsplätzen laufen? Und welche Rolle könnte PostgreSQL dabei spielen, auf dem schon der Vorgänger PGfakt aufgebaut war?

1. Ausgangslage

Leitlinie für alles Folgende: minifakt bleibt ohne Netz voll nutzbar. Netz und Mehrplatz gibt es nur als Zusatz, den man bewusst einschaltet.

2. Wege zu Netz und Mehrplatz (vom kleinsten zum größten)

AGemeinsamer Ordner, ohne eigenen Server

• Die Sicherungsdatei liegt in einem geteilten Ordner, etwa Nextcloud, Syncthing oder einer Netzwerkfreigabe.
• Variante 1: Man speichert und lädt von Hand und nutzt das vorhandene Zusammenführen.
• Variante 2: minifakt liest und schreibt die Datei selbst (File System Access API). Eine Sperrdatei bzw. ein Zeitstempelvergleich warnt, wenn jemand anderes zwischendurch gespeichert hat.

Dafür: kein Server, wenig Programmieraufwand, die Daten bleiben beim Nutzer.

Dagegen: Man kann nur nacheinander arbeiten, nicht gleichzeitig. Variante 2 geht nur in Chromium-Browsern, nicht in Firefox. Das Synchronisierungsprogramm kann Konfliktkopien erzeugen.

BKleiner Abgleichdienst mit Gesamtstand und Sperre

• Ein sehr kleiner Dienst (eine PHP-Datei auf dem eigenen Webspace oder WebDAV) hält den Stand je Mandanten bereit: abrufen und speichern.
• Gegen das Überschreiben schützt eine Versionsnummer. Wer auf einem veralteten Stand speichern will, wird abgewiesen und muss erst zusammenführen.
• Optional gibt es eine Sperre je Mandant („wird gerade von … bearbeitet“).
• Ende-zu-Ende-verschlüsselt: minifakt verschlüsselt vor dem Senden mit der schon vorhandenen Sicherungs-Verschlüsselung. Der Server sieht nur unlesbare Daten, man muss dem Anbieter des Webspace also nicht vertrauen.

Dafür: passt zu einfachem Webhosting, kleiner Eingriff in minifakt, kein Datenbankserver, datenschutzfreundlich.

Dagegen: Es wird immer der ganze Stand übertragen. Gleichzeitig arbeiten geht nur an verschiedenen Mandanten.

CÄnderungsprotokoll statt Gesamtstand

• Jede Änderung wird als Ereignis gespeichert, etwa „Buchung kontiert“ oder „Rechnung festgeschrieben“. Der Dienst sammelt die Ereignisse, und jeder Arbeitsplatz spielt die der anderen nach.

Dafür: feiner als B, mehrere Personen können am selben Mandanten arbeiten, und nebenbei entsteht ein Änderungsprotokoll, das auch für die Nachvollziehbarkeit nach GoBD hilft.

Dagegen: Alle Stellen in minifakt, die Daten ändern, müssten Ereignisse erzeugen. Für jede Art von Ereignis braucht es Regeln für Konflikte. Das ist ein deutlicher Umbau.

D„Local-first“ mit automatischem Zusammenführen (CRDT)

• Bibliotheken wie Automerge oder Yjs führen die Daten selbsttätig zusammen. Mehrere Arbeitsplätze können gleichzeitig arbeiten, auch offline mit späterem Abgleich.

Dafür: modern, robust ohne Netz, Zusammenarbeit fast in Echtzeit.

Dagegen: Buchhaltung braucht harte Regeln, die solche Verfahren nicht kennen: Rechnungsnummern müssen fortlaufend und eindeutig sein, Festgeschriebenes darf sich nicht mehr ändern, Abschlüsse sperren Zeiträume. Dafür bräuchte es doch wieder eine zentrale Stelle. Dazu kommen fremde Bibliotheken und deutlich mehr Code.

EServer mit PostgreSQL als führendem Datenbestand (der PGfakt-Weg)

• Die Daten liegen in PostgreSQL, davor steht eine Schnittstelle (z. B. PHP oder PostgREST), und minifakt wird zur Oberfläche dafür.

Dafür: echter Mehrplatzbetrieb mit Transaktionen, Benutzern und Rechten, Rechnungsnummern aus Sequenzen, Änderungsprotokoll per Trigger, Sicherung mit pg_dump.

Dagegen: Das ist im Kern ein neues Programm, gewissermaßen ein „PGfakt 2“. Es braucht Anmeldung, HTTPS und laufende Pflege. Die Daten liegen auf einem Server, und wer das für andere betreibt, braucht einen Vertrag zur Auftragsverarbeitung. Offline-Arbeit geht nur mit viel Aufwand. Das widerspricht dem Gedanken „mini“.

3. PostgreSQL ohne Mehrplatz

Diese Ergänzungen hängen nicht von Abschnitt 2 ab.

FSicherungsdatei → PostgreSQL, zum Auswerten und Archivieren

• Ein Skript liest eine minifakt-Sicherung als Ganzes in eine Tabelle mit einer jsonb-Spalte.
• Sichten (Views) teilen das JSON in Tabellen auf: Mandanten, Kunden, Rechnungen, Positionen, Zahlungen, Buchungen, Kontierungen, Kategorien.
• Danach geht alles mit SQL: Auswertungen über mehrere Mandanten und Jahre, Zugriff aus LibreOffice Base oder Grafana. Jede eingelesene Sicherung bleibt als Stand erhalten, auch zum Vergleichen.
• minifakt selbst bleibt dabei unverändert.
• Zu beachten:
  • Beträge stehen in Cent.
  • Menge und Preis der Positionen liegen so vor, wie sie eingegeben wurden, also als Text.
  • Verschlüsselte Sicherungen müssen vorher entschlüsselt werden.

GPGlite: PostgreSQL im Browser

• Nicht als Hauptspeicher: Die ganze Programmlogik von minifakt arbeitet auf einem JavaScript-Objekt. Ein Umstieg hieße umschreiben oder alles doppelt halten. Dazu kämen mehrere Megabyte zusätzlicher Code, und ob das Laden direkt als Datei klappt, ist offen.
• Gut denkbar als Zusatz „SQL-Abfrage“: Das Modul wird nur bei Bedarf nachgeladen und mitgeliefert, nicht aus fremdem Netz. Der aktuelle Stand kommt in eine Datenbank im Arbeitsspeicher, mit denselben Sichten wie bei F. Es wird nur gelesen, das Ergebnis lässt sich als CSV speichern.
• Für F und G würde dieselbe SQL-Datei mit den Sichten gelten.

HMehr Platz im Browser: IndexedDB statt localStorage

• Damit entfällt die Grenze von etwa 5–10 MB, vor der minifakt heute mit einer Füllstandsanzeige warnt. Der Eingriff ist klein.
• Die Umstellung wäre außerdem eine gute Grundlage für die Wege B bis D.

IBrücke von PGfakt zu minifakt

• Für den Umstieg: SQL-Abfragen auf eine PGfakt-Datenbank könnten mit den JSON-Funktionen von PostgreSQL direkt eine minifakt-Sicherungsdatei mit Kunden und eventuell Rechnungen erzeugen. Das wäre die umgekehrte Richtung von F.
• Das passt zum schon geplanten Einlesen von Kunden aus CSV- und PDF-Dateien.

4. Fragen, die jeder Mehrplatz-Weg beantworten muss

1. Rechnungsnummern: Sie müssen fortlaufend und eindeutig sein. Dafür braucht es entweder eine zentrale Vergabe beim Festschreiben oder getrennte Nummernkreise je Arbeitsplatz, etwa mit Vorsatz A-, B-.
2. Festschreiben und Abschlüsse: Festgeschriebenes darf auch durch einen Abgleich nicht verändert werden. Bei einem Konflikt gewinnt immer der festgeschriebene Stand.
3. Wer hat was geändert: Ein Name je Arbeitsplatz und ein Änderungsprotokoll, auch wegen der GoBD.
4. Rechte: Reicht „alle dürfen alles“, oder braucht es zum Beispiel einen Steuerberater, der nur lesen darf?
5. Offline: Was passiert, wenn ein Arbeitsplatz tagelang ohne Netz gearbeitet hat?
6. Verschlüsselung und Datenschutz: Liegen die Daten verschlüsselt auf dem Server (B), oder kann der Server sie lesen (E)?
7. Sicherung: Die lokale Sicherungsdatei bleibt in jedem Fall, auch als Rückfallebene, wenn der Dienst ausfällt.
8. Browser: Firefox und Chromium sollen gleichwertig bleiben.

5. Einschätzung (vorläufig)

Anregungen und Bedarf gern über die Kontaktdaten im Impressum.