fe40a29f35
Eine Umbuchung war auf dem Gegenkonto nicht mehr zuzuordnen: Die Zeile trug die
Marke „Umbuchung“, die Kategoriespalte daneben blieb leer. Die Daten waren
richtig, die Anzeige verschwieg sie. In der Kategoriespalte steht jetzt auch in
der Gegensicht das Konto in eckigen Klammern, von dem die Umbuchung kommt – die
Abfrage lieferte es längst mit.
Kategorie und Gegenkonto stehen in einem Feld (`Views/buchungen/zuordnungsliste.php`):
Unter den Kategorien stehen die eigenen Konten in eckigen Klammern, wie im
FinanzManager, dessen Kategoriefeld `[Konto]` annimmt. Eines davon macht die
Buchung zur Umbuchung; die Auswahl „Ausgabe / Einnahme“ bestimmt seither nur
noch die Richtung. Dieselbe Liste steht in den Splitzeilen – eine Splitzeile mit
Gegenkonto ließ sich bisher nur im Import anlegen und ging beim Bearbeiten der
Buchung stillschweigend verloren.
Schnellzuordnung: Ein Klick auf die Kategoriespalte öffnet die Liste in der
Zelle, die Auswahl speichert sofort (POST /buchungen/{id}/zuordnung) und kommt
in dieselbe Ansicht zurück. Die Liste gibt es einmal und wandert in die
angeklickte Zelle – eine Liste je Zeile wären bei hundert Zeilen ebenso viele
vollständige Kategoriebäume im HTML. Feld und Liste sind gleich breit und gleich
hoch, sonst rückte beim Anklicken die halbe Zeile. Ohne JavaScript führt
derselbe Klick in die Buchungsmaske: Die Zelle ist ein Link. Die Gegenseite
einer fremden Umbuchung führt zu ihrer Buchung auf dem anderen Konto.
Der Eintrag „Splitbuchung“ öffnet ein modales Fenster mit Zeilen für Kategorie
oder Gegenkonto, Klasse, Notiz und Betrag; der Restbetrag wird mitgerechnet. Ein
Klick auf eine bereits gesplittete Buchung öffnet direkt den Dialog. „Splitbuchung
löschen“ verwirft alle Zeilen samt ihren Zuordnungen – auch die Gegenseite einer
Splitzeile mit Gegenkonto –, die Buchung steht danach unzugeordnet im Kontoblatt.
Beide Wege gehen über `Buchung::zuordnen()` und `Buchung::splitsErsetzen()`,
achten den Monatsabschluss und lassen den Rest der Buchung unberührt.
`public/static/betrag.js` bündelt das Lesen deutscher Beträge und die
Restbetragsrechnung für Maske und Kontoblatt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
117 lines
5.3 KiB
Markdown
117 lines
5.3 KiB
Markdown
# 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),
|
||
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.
|
||
* **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
|
||
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:
|
||
|
||
```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.
|
||
|
||
## 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
|