Ein nicht angehaktes Ankreuzfeld steht nicht im POST. KontenController:: formulardaten() reichte "in_summe" gar nicht durch, also griff im Model der Standardwert "zählt zur Summe" – die Anwendung meldete "Konto gespeichert", geändert hatte sich nichts. formulardaten() nimmt das POST-Array jetzt als Parameter und ist damit ohne HTTP prüfbar; die Ankreuzfelder werden ausdrücklich auf true/false abgebildet. Der Standard bleibt für Aufrufe ohne den Schlüssel bestehen – der QIF-Import gibt das Feld nicht an. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|---|---|---|
| docs | ||
| migrations | ||
| nginx | ||
| php | ||
| public | ||
| scripts | ||
| src | ||
| tests | ||
| .env.example | ||
| .gitignore | ||
| Aktienkurse.md | ||
| Changes.md | ||
| CLAUDE.md | ||
| composer.json | ||
| docker-compose.yml | ||
| docker-entrypoint.sh | ||
| Dockerfile | ||
| LICENSE | ||
| PLAN.md | ||
| README.md | ||
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
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 PhasenCLAUDE.md– EntwicklungsregelnChanges.md– Änderungsprotokolldocs/stammdaten.md– Konten, Kontengruppen, Kategorien, Klassendocs/buchungen.md– Kontoblatt, Umbuchungen, Splitbuchungen, Saldendocs/qif-import.md– Aufbau des QIF-Exports und Arbeitsweise des Importeurs