No description
Find a file
fds2610-bot a7bfbe39e0 Splitbuchungen in den Regeln für den Abgleich
Eine Regel kann jetzt eine Splitbuchung vorgeben: mehrere Kategorien mit einem
Anteil in Prozent. Greift sie, wird der Umsatz in diesem Verhältnis aufgeteilt –
bei jedem Betrag neu gerechnet, sodass eine Abrechnung über 300 € und eine über
450 € nach demselben Schlüssel gebucht werden.

Das Schema lag bereits im Modell und in der Datenbank, war über die Oberfläche
aber nicht erreichbar; die Dokumentation beschrieb ein Feld, das es nirgends zu
sehen gab.

- Unter jeder Regel klappt „Splitbuchung“ die Zeilen auf: Kategorie, Klasse,
  Notiz, Anteil. Dasselbe Formular steht bei „Neue Regel“ – beide binden
  src/Views/banking/regelsplits.php ein.
- Die Anteile gelten zueinander, nicht absolut: 60 zu 30 sind zwei Drittel zu
  einem Drittel. Bisher hätte die letzte Zeile als Rest 40 statt der
  eingetragenen 30 Prozent bekommen, und der Fehler wäre in der fertigen
  Buchung nicht mehr zu sehen gewesen.
- Im Abgleichdialog zeigt der Vorschlag die errechneten Zeilen und schickt sie
  mit. Zuvor gingen sie beim Knopf „Als neue Buchung“ verloren: Das Formular
  kannte nur Kategorie und Klasse, sodass von Hand übernommene Umsätze
  ungeteilt im Kontoblatt landeten. Der automatische Lauf war nie betroffen.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-13 16:02:17 +02:00
docs Splitbuchungen in den Regeln für den Abgleich 2026-08-13 16:02:17 +02:00
migrations Wertpapiergeschäft aus einer Kontobuchung 2026-08-13 13:27:52 +02:00
nginx Phase 0: Projektgerüst mit nginx, php-fpm und MariaDB 2026-08-09 20:21:42 +02:00
php Phase 0: Projektgerüst mit nginx, php-fpm und MariaDB 2026-08-09 20:21:42 +02:00
public Splitbuchungen in den Regeln für den Abgleich 2026-08-13 16:02:17 +02:00
scripts QIF-Import: nur ausgewählte Konten übernehmen 2026-08-12 14:50:43 +02:00
src Splitbuchungen in den Regeln für den Abgleich 2026-08-13 16:02:17 +02:00
tests Splitbuchungen in den Regeln für den Abgleich 2026-08-13 16:02:17 +02:00
.dockerignore Phasen 4 bis 7: Cockpit, Online-Banking, Wertpapiere, Nebenmodule 2026-08-12 06:59:24 +02:00
.env.example Phase 0: Projektgerüst mit nginx, php-fpm und MariaDB 2026-08-09 20:21:42 +02:00
.gitignore Phasen 4 bis 7: Cockpit, Online-Banking, Wertpapiere, Nebenmodule 2026-08-12 06:59:24 +02:00
Aktienkurse.md Kursabruf: Yahoo Finanzen als dritter Anbieter, FMP-Adressen berichtigt 2026-08-13 15:08:27 +02:00
Changes.md Splitbuchungen in den Regeln für den Abgleich 2026-08-13 16:02:17 +02:00
CLAUDE.md Phase 0: Projektgerüst mit nginx, php-fpm und MariaDB 2026-08-09 20:21:42 +02:00
composer.json Phasen 4 bis 7: Cockpit, Online-Banking, Wertpapiere, Nebenmodule 2026-08-12 06:59:24 +02:00
composer.lock Phasen 4 bis 7: Cockpit, Online-Banking, Wertpapiere, Nebenmodule 2026-08-12 06:59:24 +02:00
docker-compose.yml Phasen 4 bis 7: Cockpit, Online-Banking, Wertpapiere, Nebenmodule 2026-08-12 06:59:24 +02:00
docker-entrypoint.sh Phasen 4 bis 7: Cockpit, Online-Banking, Wertpapiere, Nebenmodule 2026-08-12 06:59:24 +02:00
Dockerfile Phase 0: Projektgerüst mit nginx, php-fpm und MariaDB 2026-08-09 20:21:42 +02:00
LICENSE Initial commit 2026-08-09 15:47:46 +02:00
PLAN.md Phasen 4 bis 7: Cockpit, Online-Banking, Wertpapiere, Nebenmodule 2026-08-12 06:59:24 +02:00
README.md Detailseite eines Wertpapiers 2026-08-13 15:08:01 +02:00

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

Alle sieben Phasen aus PLAN.md sind umgesetzt.

  • Stammdaten und Buchungen – Konten, Kontengruppen, Kategorien, Klassen; Kontoblatt mit Schnellzuordnung und Splitdialog, Buchungsmaske mit Splitbuchungen und Umbuchungen; QIF-Import mit Stichtag.
  • Planung – Budgetplaner mit Monatswerten je Kategorie, Monatsabschluss mit Prüflauf, Snapshot und Sperre.
  • Auswertungen – Summen-, Buchungs-, Vergleichs-, Kontostands- und Budgetbericht mit Zeitraumvorgaben, Spalten-Aufteilung, Drilldown und CSV-Export; gespeicherte Berichte in Gruppen.
  • Cockpit – konfigurierbare Kacheln: Vermögensentwicklung, Einnahmen/Ausgaben je Monat, Ausgaben nach Kategorie, Kontostände, offene Vorgänge.
  • Online-Banking – FinTS-Abruf mit TAN-Dialog über mehrere Requests, Einrichtung in drei Schritten (Zugangsdaten, TAN-Verfahren, Kontenzuordnung mit Anlegen fehlender Konten), Abrufzeitraum als Spanne oder Stichtag – auch für einen einzelnen Abruf –, abgerufene Umsätze buchen sich auf Wunsch selbst, Abgleich gegen vorhandene Buchungen, Regeln für die automatische Kategorisierung.
  • Wertpapiere – Depotbestände mit Einstand und Bewertung, Depotbuchungen, Kursabruf, Veräußerungsgeschäfte und Erträge; Bestandslisten der Bank lassen sich als CSV übernehmen. Eine abgerufene Wertpapierabrechnung wird im Kontoblatt zum Geschäft: Das Depot in der Zuordnungsliste öffnet die Maske für Stück, Kurs und Nebenkosten, und daraus entstehen die Depotbuchung mit dem Einstandspreis und die Splitbuchung, die die Gebühren und Steuern auf ihre Kategorien verteilt. Jeder Wertpapiername führt auf eine Detailseite mit Stammdaten, Kurs, Bestand je Depot, Wertentwicklung und den Buchungen eines wählbaren Zeitraums.
  • Nebenmodule – Buchungsvorlagen, regelmäßige Buchungen mit Fälligkeitslauf und Finanzkalender, Erinnerungen, Adressen, Verträge, Sparziele, Kredite mit Tilgungsplan.
  • Zahlungsverkehr – Überweisungen und Terminüberweisungen über FinTS.

Einzelheiten je Modul in docs/, die Entwicklung in Changes.md.

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 genau eine: nemiah/php-fints als eigener Fork auf Codeberg

Diagramme werden als eigenes SVG erzeugt, PDF-Berichte gehen über die Druckfunktion des Browsers, die SEPA-Nachricht für Überweisungen entsteht selbst – bewusst keine Chart-, PDF- oder SEPA-Bibliothek. Der FinTS-Fork trägt psr/log direkt in sich; damit hängt die Anwendung an keinem fremden Update-Zyklus.

Start

cp .env.example .env      # Werte anpassen (APP_KEY darf leer bleiben)
docker compose up -d

Ist APP_KEY leer, erzeugt der Container beim ersten Start einen Schlüssel unter data/schluessel/app_key. Er verschlüsselt die Zugangsdaten der Bankverbindungen und gehört ins Backup – ohne ihn sind sie nicht mehr lesbar.

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, Kursabruf
tests/          PHP-Testsuite; tests/e2e/ für Playwright
data/           Nutzdaten: mariadb, logs, import, schluessel (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. Mit --konto=NAME (mehrfach angebbar, im Dialog als Ankreuzliste nach dem Trockenlauf) bleibt der Import auf einzelne Konten beschränkt; --konten nennt die Konten der Datei.

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/auswertungen.md – Berichtsmodul, Filterleiste, Drilldown, CSV
  • docs/cockpit.md – Startseite und ihre Kacheln
  • docs/banking.md – FinTS-Abruf, TAN-Dialog, Abgleich und Regeln
  • docs/wertpapiere.md – Depots, Einstand, Kurse, Invst- und CSV-Bestandsimport
  • docs/nebenmodule.md – Vorlagen, Termine, Verträge, Sparziele, Kredite, Zahlungsverkehr
  • docs/qif-import.md – Aufbau des QIF-Exports und Arbeitsweise des Importeurs