Finanzmanager/Changes.md

Änderungen

Phase 2 – Buchungen, Kontoblatt und Buchungsimport (10.08.2026)

Erkenntnis aus dem Vollexport

Der Plan ging davon aus, Umbuchungen stünden zweimal in der Datei und müssten zusammengeführt werden. Das Gegenteil ist der Fall: 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 im Export hat keine ein zweites Vorkommen. Mit erzeugter Gegenseite stimmen acht gegen den FinanzManager geprüfte Kontosalden auf den Cent.

Datenmodell

• Migration 003_buchungen.sql: buchungen, buchung_splits, buchungsadressen
• Eine Umbuchung ist ein Datensatz mit gegenkonto_id, kein gespiegeltes Paar – das Kontoblatt des Gegenkontos zeigt sie mit umgekehrtem Vorzeichen
• Auch einzelne Splitzeilen dürfen ein Gegenkonto tragen
• Konten führen in_summe (die Σ-Spalte des FinanzManagers) sowie saldo_online

Kontoblatt und Buchungsmaske

• 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; Splitzeilen mit Restbetragsanzeige, geprüft auch serverseitig
• Aktueller und erwarteter Saldo; in die Summen zählen nur Konten mit Σ-Kennzeichen

QIF-Buchungsimport

• QifBuchungsImport mit Stichtag: alles davor wird je Konto zum Anfangssaldo aufsummiert – einschließlich der erzeugten Gegenbuchungen –, alles danach importiert
• Buchungen mit Datum nach dem Importtag gelten als Vorausberechnung und bleiben draußen
• Eröffnungsbuchungen (L[eigenes Konto]) werden nicht zu Umbuchungen
• Wertpapiergeschäfte schlagen vorerst nur mit ihrem Geldfluss auf dem Verrechnungskonto zu Buche; Bestände folgen in Phase 6
• Idempotent über einen Fingerabdruck je Buchung, der auch echte Doppelbuchungen am selben Tag auseinanderhält
• Am Vollexport geprüft: 833 Buchungen ab 01.01.2026, 7946 in die Anfangssalden von 35 Konten verrechnet, eine vorausberechnete verworfen

Behoben

• Die confirm()-Rückfragen vor dem Löschen waren wirkungslos. public/static/app.js brachte den Mechanismus (data-bestaetigen) von Anfang an mit, war aber nie im Layout eingebunden; ersatzweise standen Inline-Handler (onsubmit) im HTML, und die verstoßen gegen die eigene Content-Security-Policy (script-src 'self') – der Browser verwarf sie stillschweigend, gelöscht wurde ohne Rückfrage. Jetzt ist das Skript eingebunden, die Inline-Handler sind raus, und ein E2E-Test besteht auf dem Dialog.

Tests

• 09_BuchungenTest – Umbuchungen mit zwei Sichten, Splitzeilen samt Summenprüfung, Splitzeile mit Gegenkonto, aktueller und erwarteter Saldo, Σ-Kennzeichen, Filter
• 10_QifBuchungsImportTest – Stichtag, Anfangssalden aus der Vorgeschichte, erzeugte Gegenbuchung, Eröffnungsbuchung, Zukunftsfilter, zweiter Lauf ohne Wirkung
• E2E buchungen.spec.js – Ausgabe, Umbuchung auf beiden Kontoblättern, Splitbuchung, abgewiesene Splitsumme, Suche, Löschbestätigung

Phase 1 – Stammdaten und QIF-Stammdatenimport (09.08.2026)

Datenmodell

• Migration 002_stammdaten.sql: kontengruppen, konten, kategorien, klassen
• Alle Tabellen führen benutzer_id; Mandant::id() liefert die Kennung aus der Session oder – im CLI – vom ersten aktiven Benutzer

Konten

• Kontenübersicht nach Kontengruppen gebündelt, mit Gruppensummen und Gesamtsumme
• Die drei Saldospalten des FinanzManagers (Online-Saldo, aktueller und erwarteter Saldo) sind angelegt und werden bis Phase 2 aus dem Anfangssaldo gespeist
• Kontoarten des FinanzManagers samt Zuordnung zu den QIF-Typen
• Kontenpflege mit Anfangssaldo, Kreditlimit, IBAN/BIC, Kontengruppe, aktiv/inaktiv
• Kontengruppen anlegen, umbenennen, sortieren, löschen – die Konten bleiben erhalten

Kategorien und Klassen

• Hierarchische Kategorien mit : als Trenner; der vollständige Pfad wird mitgeführt und beim Umbenennen oder Verschieben für den ganzen Teilbaum neu geschrieben
• Art (Einnahme/Ausgabe) gilt für den ganzen Ast und vererbt sich an Unterkategorien
• Verschieben, Zusammenführen und Löschen; Verschieben in den eigenen Teilbaum wird abgewiesen
• Register Alle / Einnahmen / Ausgaben / Umbuchungskonten wie im Original
• Klassen als flache zweite Auswertungsdimension, in der Liste direkt bearbeitbar

QIF-Import

• QifParser: zustandsbehaftetes, sequenzielles Lesen; ISO-8859-1 nach UTF-8, US-Beträge, Datumsformat aus der Kopfzeile, Mehrfachfelder für spätere Splitzeilen
• QifStammdatenImport für Klassen, Kategorien und Konten – idempotent, mit Trockenlauf und Protokoll; fehlende Zwischenstufen im Kategoriepfad entstehen selbsttätig
• Dialog unter Verwaltung → QIF-Import mit Upload, Trockenlauf und Übernahme
• scripts/qif-import.php für dieselbe Aufgabe auf der Kommandozeile
• Geprüft am echten Export: 17 Klassen, 105 Kategorien, 37 Konten

Tests

• 06_KategorienTest – Hierarchie, Pfadpflege, Artvererbung, Verschieben, Zusammenführen
• 07_KontenTest – Kontoarten, Gruppierung und Summen, Betragseingabe
• 08_QifImportTest – Parser, Zeichensatz, Beträge und Datum, Import, Trockenlauf, Prüfung der Dateinamen
• E2E stammdaten.spec.js – Konto, Kategorie mit Unterkategorie, Register, Klasse, QIF-Upload mit Trockenlauf

Korrektur – Monatsnamen auf Deutsch (09.08.2026)

• Der Einstellungsdialog zeigte unter Buchhaltung englische Monatsnamen, weil date('F') sprachlich nicht umschaltbar ist.
• Monatsnamen liegen jetzt zentral als View::MONATE und View::MONATE_KURZ vor, abrufbar über View::monat(). Budgetplaner und Auswertungen greifen später darauf zu.
• 05_DarstellungTest prüft Monatsnamen, Betrags- und Datumsformat gegen eine feste Sollliste – der Vergleich gegen date('F') allein würde April, August, September und November nicht auffallen lassen.

Phase 0 – Projektgerüst (09.08.2026)

Grundgerüst der Anwendung. Fachliche Module folgen ab Phase 1.

Betrieb

• Docker Compose mit drei Services: nginx (Port 8000), php (php-fpm 8.3), db (MariaDB 11)
• docker-entrypoint.sh legt Datenverzeichnisse an und spielt Migrationen ein
• scripts/migrate.php – nummerierte SQL-Migrationen, idempotent, mit Journal-Tabelle
• scripts/update.sh – Update für den Produktionsserver: Backup, git pull, Image-Neubau bei Bedarf, Migrationen, Rechte, Tests
• scripts/backup.sh – Datenbank- und Dateisicherung mit Rotation (7 Tage / 4 Wochen / 12 Monate), gegen Parallelläufe per flock abgesichert

Anwendung

• Config, Database (PDO-Wrapper, verschachtelbare Transaktionen), Router (Platzhalter-Routen, CSRF-Prüfung für alle verändernden Requests), View, Auth
• Anmeldung mit Session-Härtung, Ersteinrichtung des ersten Benutzers
• Zentraler Einstellungsdialog mit Reitern (Allgemein, Darstellung, Buchhaltung, Online-Banking, Import/Export, Wertpapiere, Diagnose); Werte in Tabelle einstellungen
• Debug-Log, ein- und ausschaltbar, mit Maskierung von PINs, Passwörtern, TANs und API-Keys; Ausnahmen werden immer protokolliert
• Layout nach Vorbild des FinanzManagers: feste Navigation links, Werkzeugleiste oben, Tab-Leiste; Farbschema hell/dunkel/System

Tests

• Test-Harness mit Transaktions-Rollback und Aufräumen temporärer Pfade
• 01_AuthTest – Anmeldung, Passwort-Hashing, CSRF, Cookie-Attribute
• 02_EinstellungenTest – Lesen/Schreiben, Cache-Invalidierung, Bereichsabdeckung
• 03_RouterTest – Pfad-Muster, Platzhalter, keine Treffer über Pfadgrenzen
• 04_DebugLogTest – Schalter, Maskierung, Fehlerprotokollierung