1dbc848cd1
Der Plan ging davon aus, Umbuchungen stünden zweimal im Export und müssten zusammengeführt werden. Der Vollexport zeigt das Gegenteil: 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 hat keine ein zweites Vorkommen. Mit erzeugter Gegenseite stimmen acht gegen den FinanzManager geprüfte Kontosalden auf den Cent. Datenmodell: Migration 003 mit buchungen, buchung_splits und buchungsadressen. Eine Umbuchung ist ein Datensatz mit gegenkonto_id, kein gespiegeltes Paar - zwei Zeilen laufen früher oder später auseinander. Das Kontoblatt des Gegenkontos zeigt sie mit umgekehrtem Vorzeichen. Auch einzelne Splitzeilen dürfen ein Gegenkonto tragen. Konten führen zusätzlich in_summe, die Sigma-Spalte der Kontenübersicht, und saldo_online für Phase 5. Oberfläche: 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, mit Splitzeilen und Restbetragsanzeige. Import: QifBuchungsImport arbeitet mit Stichtag. Alles davor wird je Konto zum Anfangssaldo aufsummiert, Gegenbuchungen eingerechnet; alles danach bis zum Importtag kommt einzeln in die Datenbank. Spätere Buchungen sind Vorausberechnungen des FinanzManagers und bleiben draußen. Wertpapiergeschäfte schlagen vorerst nur mit ihrem Geldfluss auf dem Verrechnungskonto zu Buche. Am Vollexport geprüft: 833 Buchungen ab 01.01.2026, 7946 in die Anfangssalden von 35 Konten verrechnet. Behoben: Die confirm()-Rückfragen vor dem Löschen waren wirkungslos. public/static/app.js brachte den Mechanismus mit, war aber nie im Layout eingebunden; die ersatzweise gesetzten onsubmit-Attribute verstoßen gegen die eigene Content-Security-Policy und wurden vom Browser verworfen - gelöscht wurde ohne Rückfrage. Ein E2E-Test besteht jetzt auf dem Dialog. Tests: 307 PHP-Prüfungen und 21 Playwright-Tests, alle grün. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
86 lines
3.3 KiB
Markdown
86 lines
3.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
|
||
|
||
Phase 0 bis 2 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. Als Nächstes folgt nach `PLAN.md` der Budgetplaner mit dem
|
||
Monatsabschluss (Phase 3).
|
||
|
||
## 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
|
||
|
||
```bash
|
||
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.
|
||
|
||
```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
|
||
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:
|
||
|
||
```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/qif-import.md` – Aufbau des QIF-Exports und Arbeitsweise des Importeurs
|