0b4a216954
Zwei Features an derselben Stelle, die im Arbeitsverzeichnis nebeneinander lagen und sich dieselben Dateien teilen (Routen, BankingController, Bankzugang, Zugangsformular, Dokumentation) – getrennte Commits ließen sich daraus nur mit einem kaputten Zwischenstand schneiden. PayPal als zweite Art von Bankverbindung ---------------------------------------- „Bankverbindung anlegen“ führt zur Wahl der Art: HBCI/FinTS oder PayPal (bank_zugaenge.typ, Migration 014). Die Abfrage läuft über die Classic-NVP-API (Services\PaypalNvp, TransactionSearch und GetBalance). Kein Dreischritt, da PayPal genau ein Guthabenkonto führt – Zugangsdaten und Kontenzuordnung stehen in einem Formular. Konten, Umsätze, Protokoll, Regeln und Abgleich bleiben dieselben. Bankleitzahlen-Verzeichnis -------------------------- Verwaltung → Bankleitzahlen (/verwaltung/bankinstitute, Migration 015) nimmt die CSV-Institutsliste der Deutschen Kreditwirtschaft auf und beantwortet damit die eine Angabe, die beim Anlegen einer FinTS-Verbindung regelmäßig fehlt: den PIN/TAN-Zugangspunkt. Reine Nachschlagedaten ohne benutzer_id; ein Import ersetzt den gesamten Bestand, statt ihn zu ergänzen. „Nur prüfen“ und „Übernehmen“ sind zwei Knöpfe an derselben Datei – abgelegt wird sie nicht, ihr Inhalt steht ja in der Tabelle. Services\FintsInstituteImport nimmt der Datei ihre Eigenheiten ab: ISO-8859-1 statt UTF-8, ein Institutsname über zwei Zeilen in Anführungszeichen, dieselbe Bankleitzahl vielfach (eine Zeile je Filiale), Hunderte leerer Zeilen am Ende, Text statt Adresse, wo es keinen PIN/TAN-Zugang gibt. Spalten werden über ihre Überschrift angesprochen; fehlen BLZ und Institut, bricht der Import ab. Gesucht wird über Bankleitzahl, BIC, Name und Ort in einem Zug: „1822“ steht bei der 1822direkt im Namen und bei der Frankfurter Sparkasse im BIC, in keiner der beiden Bankleitzahlen. Aus der Trefferliste führt „Verbindung anlegen“ ins gefüllte FinTS-Formular. Die FinTS-Adresse ist damit kein Pflichtfeld mehr – bleibt sie leer, wird sie zur Bankleitzahl nachgeschlagen. Findet auch das nichts, weist Bankzugang den Zugang ab, statt ihn ohne Gegenstelle zu speichern. Tests: 31_PaypalZugangTest, 32_BankinstituteTest, e2e/specs/banking.spec.js, e2e/specs/bankinstitute.spec.js. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
137 lines
7 KiB
Markdown
137 lines
7 KiB
Markdown
# Finanzmanager
|
||
|
||
Persönliche Finanzverwaltung als Web-Anwendung: Konten, Buchungen mit Kategorien und
|
||
Klassen, Jahresbudget, Monatsabschluss, Auswertungen, Online-Banking über FinTS und PayPal
|
||
sowie 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.
|
||
* **Import und Export** – QIF und CSV in beide Richtungen: Stammdaten und Buchungen
|
||
übernehmen, Buchungen nach Zeitraum, Konto, Kategorie und Klasse gefiltert ausgeben.
|
||
Exportdateien werden nicht vorgehalten; das Housekeeping räumt hochgeladene Dateien weg.
|
||
* **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. Alternativ **PayPal** über dessen NVP-Schnittstelle:
|
||
ein Formular statt dreier Schritte, da PayPal genau ein Guthabenkonto führt.
|
||
Die FinTS-Adresse muss niemand suchen: Das **Bankleitzahlen-Verzeichnis** unter
|
||
*Verwaltung → Bankleitzahlen* nimmt die CSV-Institutsliste der Deutschen
|
||
Kreditwirtschaft auf und füllt daraus das Formular einer neuen Verbindung.
|
||
* **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
|
||
|
||
```bash
|
||
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.
|
||
|
||
```bash
|
||
./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, Housekeeping
|
||
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 → Import/Export* oder auf der Kommandozeile. Buchungen ab dem Stichtag kommen
|
||
einzeln in die Datenbank, alles davor wird je Konto zum Anfangssaldo verrechnet:
|
||
|
||
```bash
|
||
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.
|
||
|
||
In die andere Richtung geht es über *Verwaltung → Import/Export → Export*: Buchungen als
|
||
QIF oder CSV, gefiltert nach Zeitraum, Konto, Kategorie und Klasse. Die Datei entsteht
|
||
erst beim Herunterladen und wird nirgends abgelegt. Der CSV-Import liest dieselbe Datei
|
||
wieder ein. Einzelheiten in `docs/import-export.md`.
|
||
|
||
## 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- und PayPal-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/import-export.md` – QIF und CSV in beide Richtungen, Formatwahl, Housekeeping
|