.umsatztext hatte in der Flex-Zeile .umsatzkopf keinen flex-grow, wodurch
justify-content: space-between die Restfläche auf beide Zwischenräume
verteilte – der Text schwebte dadurch zentriert zwischen Ankreuzfeld und
Betrag statt linksbündig am Ankreuzfeld zu stehen.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Die Umsatzlisten haben jetzt dieselbe Mehrfachauswahl wie ein Kontoblatt:
ein Ankreuzfeld vor jedem Umsatz, eines in der Titelleiste für alle
angezeigten und darüber der Knopf „Auswahl löschen“. Er steht in jedem
Reiter – offen, übernommen und verworfen –, nennt die Anzahl der Auswahl
und bleibt ohne Auswahl gesperrt. Bisher ließ sich ein abgerufener Umsatz
nur übernehmen oder verwerfen; wegräumen ging gar nicht.
Gelöscht wird allein die abgerufene Zeile. Eine daraus entstandene
Buchung gehört ins Kontoblatt und bleibt dort stehen – wer sie loswerden
will, löscht sie dort, und dann kehrt ihr Umsatz ohnehin in die
Vorschlagsliste zurück. Mit dem Umsatz geht aber sein Fingerabdruck: Was
im nächsten Abrufzeitraum liegt, kommt danach wieder herein, bei einem
verworfenen Umsatz also erneut als offen.
- Neue Route POST /banking/umsaetze/loeschen auf
Bankumsatz::mehrereLoeschen(); der Status hängt am Formularziel, sodass
der Weg in denselben Reiter zurückführt. Ohne JavaScript weist der
Controller eine leere Auswahl ab.
- Die Liste ist keine Tabelle, sondern eine Folge von Karten. Die
Kopfzeile, die eine Tabelle von selbst hätte, gibt es deshalb neu als
.listenkopf; die Mechanik dahinter (.alle-waehlen mit data-waehlt) ist
unverändert die des Kontoblatts.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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>
Damit ist der geplante Funktionsumfang beisammen.
Phase 4 abgeschlossen
- Konfigurierbare Cockpit-Kacheln; abgewählte werden nicht berechnet
- Einnahmen/Ausgaben je Monat als Balkenpaare mit Saldolinie, aufgesetzt auf
den Summenbericht statt auf eine eigene Abfrage
- Meine Ausgaben als Ring auf der obersten Kategorieebene
- Offene Vorgänge aus allen Modulen
Phase 5 – Online-Banking
- nemiah/php-fints als Fork auf Codeberg, psr/log direkt eingebaut: die
Anwendung hängt an keinem fremden Update-Zyklus
- PIN AES-256-GCM-verschlüsselt; Schlüssel aus APP_KEY oder aus
data/schluessel/app_key, den der Entrypoint einmalig erzeugt
- TAN-Dialog über mehrere Requests (FinTs::persist plus serialisierte Aktion
in der Sitzung) – ein wartender Prozess wäre mit php-fpm der falsche Weg
- Abgleich statt Direktbuchung: verbinden, übernehmen oder verwerfen
- Regeln mit vier Vergleichsarten, Betragsgrenzen und Split-Schema
Phase 6 – Wertpapiere
- Depotbuchung und Geldbuchung als zwei Seiten eines Geschäfts; betrag ist
der Bruttowert, Nebenkosten stehen daneben
- Einstand nach gleitendem Durchschnitt, realisierte Gewinne, Erträge
- Kursabruf über Leeway oder FMP, täglicher Lauf per Cron
- QIF-Import für !Type:Invst
Dabei behoben: Der Import buchte den Geldfluss jedes Wertpapiergeschäfts als
Abgang – auch bei Verkäufen und Dividenden; und er erkannte das
Verrechnungskonto nicht, wenn dem Konto im L-Feld eine Kategorie vorangeht
(bei Verkäufen also immer).
Phase 7 – Nebenmodule und Zahlungsverkehr
- Buchungsvorlagen inklusive QIF-Import, Splits werden mitskaliert
- Regelmäßige Buchungen mit Fälligkeitslauf, Finanzkalender, Erinnerungen
- Adressen mit IBAN-Prüfung, Verträge mit Kündigungsfrist, Sparziele
- Kredite mit gerechnetem Tilgungsplan
- Überweisungen über FinTS; die Buchung entsteht erst nach Annahme durch die
Bank. Die pain.001-Nachricht erzeugt SepaXml selbst
Nebenbei: .dockerignore ergänzt (ohne sie brach der Build an data/mariadb ab),
PlatzhalterController entfernt, zwei Inline-Handler beseitigt, die die
Content-Security-Policy ohnehin blockierte.
888 PHP-Prüfungen und 45 E2E-Tests grün.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
