fds2610-bot 851e8204e9 Phase 3: Budgetplaner und Monatsabschluss

Budgetplaner mit Monatswerten je Kategorie, Monatsabschluss mit Prüflauf,
Snapshot und Buchungssperre. Dazu drei Vorarbeiten in der Oberfläche.

Budgetplaner
- Migration 004: budgets, budget_positionen, monatsabschluesse
- Zeilen sind der Kategoriebaum, Spalten die Monate; die ganze Tabelle wird in
  einem Formular gespeichert, damit mehrere Änderungen zusammen ankommen
- Zwei Ansichten: Verlauf (Jahressumme, abgelaufene Monate zusammengefasst,
  laufender Monat mit Budget/Ist/Saldo, danach Folgemonate) und alle Monate
- Ausgaben ohne Vorzeichen eingeben, es kommt aus der Kategorieart. Saldo ist
  Ist minus Budget: positiv heißt besser als geplant, negativ ist die
  Überschreitung und wird rot ausgewiesen
- Übergeordnete Kategorien summieren ihre Nachfahren und sind nicht beplanbar
- Ein Monat ohne Position ist "nicht geplant" und damit etwas anderes als
  "mit 0,00 geplant"
- Wert auf Folgemonate übertragen, Budget als Kopie ins neue Jahr

Monatsabschluss
- Prüflauf über nicht kategorisierte Buchungen, nicht abgeglichene Umsätze und
  Splitsummen-Differenzen; er hält niemanden auf, sondern zeigt den Stand
- Snapshot der Kontosalden und Kategoriesummen als JSON, bleibt auch nach einer
  Wiedereröffnung stehen
- Abgeschlossene Monate sperren Buchungen in beide Richtungen: weder hinein noch
  heraus verschieben. Abschaltbar über monatsabschluss_sperrt_buchungen

Vorarbeiten
- .knopf.primaer trug einen eigenen margin-top und stand dadurch in jeder
  Knopfleiste tiefer als seine Nachbarn - sichtbar an "Abbrechen" neben
  "Konto anlegen". Der Abstand liegt jetzt allein bei der Knopfleiste
- Kontengruppen werden wie Konten und Kategorien auf einer eigenen
  Formularseite gepflegt statt inline; dort hängt auch die Zuordnung der
  Konten (ankreuzen statt jedes Konto einzeln zu öffnen)
- Der QIF-Export enthält keine Kontengruppen: kein Feld im !Account-Eintrag,
  nichts in der QSD-Datei. Import-Oberfläche und Doku sagen das jetzt
- Die Baum-Einrückung lief über ein style-Attribut und wurde von der
  Content-Security-Policy verworfen; sie steht jetzt als data-ebene im Markup.
  Aus demselben Grund blendete app.js Erfolgsmeldungen nie aus

Tests: 11_BudgetTest, 12_MonatsabschlussTest (76 Prüfungen), E2E planung.spec.js.
Einzelheiten in docs/planung.md.

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

2026-08-11 07:31:25 +02:00

3.4 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 3 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; Budgetplaner mit Monatswerten je Kategorie und der Monatsabschluss samt Prüflauf, Snapshot und Sperre. Als Nächstes folgen nach PLAN.md die Auswertungen und das Cockpit (Phase 4).

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/planung.md – Budgetplaner und Monatsabschluss
docs/qif-import.md – Aufbau des QIF-Exports und Arbeitsweise des Importeurs

3.4 KiB Raw Blame History Unescape Escape