fds2610-bot 1dbc848cd1 Phase 2: Buchungen, Kontoblatt und QIF-Buchungsimport

Der Plan ging davon aus, Umbuchungen stünden zweimal im Export und müssten
zusammengeführt werden. Der Vollexport zeigt das Gegenteil: Eine Umbuchung
steht einmal, in dem Konto, in dem sie erfasst wurde; die Gegenseite ist nur
durch L[Zielkonto] benannt und muss beim Import erzeugt werden. Von 965
Umbuchungen hat keine ein zweites Vorkommen. Mit erzeugter Gegenseite stimmen
acht gegen den FinanzManager geprüfte Kontosalden auf den Cent.

Datenmodell: Migration 003 mit buchungen, buchung_splits und buchungsadressen.
Eine Umbuchung ist ein Datensatz mit gegenkonto_id, kein gespiegeltes Paar -
zwei Zeilen laufen früher oder später auseinander. Das Kontoblatt des
Gegenkontos zeigt sie mit umgekehrtem Vorzeichen. Auch einzelne Splitzeilen
dürfen ein Gegenkonto tragen. Konten führen zusätzlich in_summe, die
Sigma-Spalte der Kontenübersicht, und saldo_online für Phase 5.

Oberfläche: Kontoblatt mit laufendem Saldo, Filter auf Zeitraum, Kategorie,
Klasse und Abgleich, Volltextsuche und Seitenblättern. Buchungsmaske für
Einnahme, Ausgabe und Umbuchung in beide Richtungen, mit Splitzeilen und
Restbetragsanzeige.

Import: QifBuchungsImport arbeitet mit Stichtag. Alles davor wird je Konto zum
Anfangssaldo aufsummiert, Gegenbuchungen eingerechnet; alles danach bis zum
Importtag kommt einzeln in die Datenbank. Spätere Buchungen sind
Vorausberechnungen des FinanzManagers und bleiben draußen. Wertpapiergeschäfte
schlagen vorerst nur mit ihrem Geldfluss auf dem Verrechnungskonto zu Buche.
Am Vollexport geprüft: 833 Buchungen ab 01.01.2026, 7946 in die Anfangssalden
von 35 Konten verrechnet.

Behoben: Die confirm()-Rückfragen vor dem Löschen waren wirkungslos.
public/static/app.js brachte den Mechanismus mit, war aber nie im Layout
eingebunden; die ersatzweise gesetzten onsubmit-Attribute verstoßen gegen die
eigene Content-Security-Policy und wurden vom Browser verworfen - gelöscht
wurde ohne Rückfrage. Ein E2E-Test besteht jetzt auf dem Dialog.

Tests: 307 PHP-Prüfungen und 21 Playwright-Tests, alle grün.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-08-10 16:40:31 +02:00

3.3 KiB

Raw Blame History

Finanzmanager

Persönliche Finanzverwaltung als Web-Anwendung: Konten, Buchungen mit Kategorien und Klassen, Jahresbudget, Monatsabschluss, Auswertungen, Online-Banking über FinTS und Wertpapierdepots.

Ersetzt den Lexware FinanzManager Deluxe, läuft auf einem Debian-Server statt auf einem Windows-Client. Die fachlichen Begriffe bleiben bewusst identisch zum Original – im Haushalt wird beides parallel genutzt.

Stand

Phase 0 bis 2 sind gebaut: Anmeldung, zentraler Einstellungsdialog, Debug-Log, Migrationsmechanik und Test-Harness; Konten, Kontengruppen, Kategorien und Klassen; Kontoblatt, Buchungsmaske mit Splitbuchungen und Umbuchungen sowie der QIF-Import für Stammdaten und Buchungen. Als Nächstes folgt nach PLAN.md der Budgetplaner mit dem Monatsabschluss (Phase 3).

Technik


Sprache	PHP 8.3, kein Framework, eigenes MVC
Datenbank	MariaDB 11
Webserver	nginx + php-fpm
Betrieb	Docker Compose (drei Services)
Frontend	serverseitiges HTML, Vanilla JS, CSS Custom Properties
Fremdbibliotheken	keine im Kern; FinTS folgt in Phase 5 als eigener Fork

Diagramme werden als eigenes SVG erzeugt, PDF-Berichte gehen über die Druckfunktion des Browsers – bewusst keine Chart- oder PDF-Bibliothek.

Start

cp .env.example .env      # Werte anpassen, APP_KEY erzeugen
docker compose up -d

Danach http://localhost:8000 aufrufen. Beim ersten Aufruf führt die Anwendung zur Ersteinrichtung und legt den ersten Benutzer an.

./scripts/run-tests.sh    # Tests
./scripts/backup.sh       # Backup mit Rotation
./scripts/update.sh       # Update (auf dem Produktionsserver)

Verzeichnisse

src/            Anwendungscode (Controllers, Models, Services, Views)
public/         Front-Controller und statische Dateien
migrations/     nummerierte SQL-Migrationen, laufen beim Containerstart
scripts/        Migration, Update, Backup, Tests
tests/          PHP-Testsuite; tests/e2e/ für Playwright
data/           Nutzdaten: mariadb, logs, import (nicht im Repository)
Altdaten/       Screenshots und QIF-Export der Altanwendung (nicht im Repository)

Migration der Altdaten

Datenquelle ist der QIF-Export aus dem FinanzManager – die .QDF-Datei ist verschlüsselt und nicht auswertbar. Der Importer liest Klassen, Kategorien, Konten, Buchungen samt Splits sowie Wertpapierbuchungen. Einzelheiten zum Format und den Fallstricken stehen in PLAN.md, Kapitel 4.

Klassen, Kategorien, Konten und Buchungen lassen sich übernehmen – im Dialog unter Verwaltung → QIF-Import oder auf der Kommandozeile. Buchungen ab dem Stichtag kommen einzeln in die Datenbank, alles davor wird je Konto zum Anfangssaldo verrechnet:

docker compose exec -u www-data php php scripts/qif-import.php data/import/Export.QIF
docker compose exec -u www-data php php scripts/qif-import.php --uebernehmen data/import/Export.QIF

Ohne --uebernehmen läuft nur der Trockenlauf.

Dokumentation

PLAN.md – Projektplan mit allen Phasen
CLAUDE.md – Entwicklungsregeln
Changes.md – Änderungsprotokoll
docs/stammdaten.md – Konten, Kontengruppen, Kategorien, Klassen
docs/buchungen.md – Kontoblatt, Umbuchungen, Splitbuchungen, Salden
docs/qif-import.md – Aufbau des QIF-Exports und Arbeitsweise des Importeurs

3.3 KiB Raw Blame History Unescape Escape