Commit graph

80 commits

Author SHA1 Message Date
fds2610-bot
1a464b5b17 Fix n.n.: Fälligkeit folgt der Buchung – Löschen öffnet den Termin wieder
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
2026-10-01 09:24:53 +02:00
fds2610-bot
834cd13160 Fix n.n.: Blaue Schrift im Hell- und Darkmode besser lesbar
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
2026-10-01 08:48:50 +02:00
fds2610-bot
0c1983cb1f Fix n.n.: Darkmode-Farben nach Mockup angepasst
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
2026-10-01 08:42:28 +02:00
fds2610-bot
e3df021849 Fix n.n.: Favicon in hellem und dunklem Modus gut sichtbar
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
2026-10-01 08:28:51 +02:00
fds2610-bot
ec72fd213a Fix #102: Offener Vorgang für fehlgeschlagene Bargeld-Tool-Prüfungen
Die Kachel "Offene Vorgänge" im Cockpit zeigt jetzt auch Buchungen, deren
letzter Abgleich mit dem Bargeld-Tool an einem Abrufproblem gescheitert ist
(bargeld_status = 'fehler'). Ein Klick führt auf die neue, kontoübergreifende
Liste unter Verwaltung -> Bargeld-Tool -> fehlgeschlagene Prüfungen.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-30 17:30:59 +02:00
fds2610-bot
f2ffa2bb66 Fix n.n.: phpFinTS auf v4.1.6 (Upstream vom 22.09.2026)
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
2026-09-30 17:02:29 +02:00
fds2610-bot
9a3472f4b7 Fix n.n.: Depot-Zuordnung, Bestand einbuchen mit Stichtag
- Depot der Bank wird einem Depot im Finanzmanager zugeordnet (Migration 022)
- Bestand einbuchen: Ein-/Auslieferungen aus dem Bankbestand, Stichtag per Dialog
- Zuordnungsliste: Depots nur noch als Wertpapiergeschäft

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
2026-09-30 15:10:43 +02:00
fds2610-bot
b4a1b0acbc Fix n.n.: Depotabruf per FinTS und Nachweis zur Überweisung
Depotaufstellung (HKWPD, Version 6) unter Wertpapiere mit Vergleich zum eigenen
Bestand; Prüfsumme und Textnachweis für das Übermittlungsprotokoll einer
Überweisung; phpFinTS v4.1.5.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
2026-09-30 15:10:43 +02:00
fds2610-bot
860e71d1e7 Fix #95: Splitzeilen bleiben bei falscher Summe erhalten
Eine falsche Splitsumme zeigte zwar die Fehlermeldung, leitete aber auf eine
frische Buchungsmaske weiter und riss dabei alle gerade erfassten Splitzeilen
(und übrigen Feldwerte) heraus, obwohl in der Datenbank nichts geändert wurde.
anlegen()/speichern() zeichnen die Maske bei einem Validierungsfehler jetzt
direkt mit den zuletzt abgeschickten Werten neu, statt wegzuleiten.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-29 23:55:18 +02:00
fds2610-bot
619e427a30 Fix #96: Splitbuchungen zeigen Restbetrag, Speichern nur bei Null
Die Summenzeile der Splitbuchungen (Buchungsmaske und Splitdialog im
Kontoblatt) zeigt jetzt den noch offenen Restbetrag zum Buchungswert statt
der Summe der Zeilen. „Speichern" bleibt gesperrt, solange Splitzeilen
befüllt sind und der Restbetrag nicht Null ist; ohne Splitzeilen (auch mit
direkter Kategorie/Gegenkonto) bleibt der Knopf wie bisher an.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-29 23:34:27 +02:00
fds2610-bot
057075368c Fix #94: Regel direkt aus einer Buchung anlegen
Toggle „Regel anlegen“ in der Buchungsmaske (Fix #94); beim Speichern
entsteht daraus eine Regel (AbgleichRegel::ausBuchung()), die das
Kontoblatt danach in einem modalen Dialog zum Prüfen und Anpassen zeigt.
Abbruch (auch per Escape) verwirft die Regel wieder, Speichern übernimmt
Änderungen. Die Regelfelder sind aus regeln.php in regelfelder.php
ausgelagert, damit beide Formulare dieselbe Bauart teilen.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-29 23:11:06 +02:00
fds2610-bot
42b43090bc Fix n.n.: Umbuchungen finden beide Seiten zueinander
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
2026-09-29 13:11:59 +02:00
fds2610-bot
5d39293328 Fix n.n.: Bekannte Umsätze bekommen IBAN und Bank der Gegenseite nachgetragen
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
2026-09-29 11:48:13 +02:00
fds2610-bot
5695e2e3df Fix n.n.: E2E-Läufe sichern Einstellungen, Kippschalter statt Ankreuzfeldern
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
2026-09-29 11:37:52 +02:00
fds2610-bot
054d0d29cb Fix n.n.: Summe der Anteile in den Splittabellen der Regeln
Die Spalte heißt nur noch „Anteil“; darunter steht die Summe der Anteile,
die sich mit jeder Eingabe in derselben Tabelle neu berechnet.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
2026-09-29 11:09:29 +02:00
fds2610-bot
290ab86c26 Fix #89: Echtzeitüberweisung scheitert an SEPA-Format und VOP/TAN-Kombination
SepaXml erzeugt jetzt zusätzlich pain.001.001.09 (Dt-Element für den
Ausführungstermin, BICFI statt BIC, UETR je Zahlung) für Banken, die das
ältere pain.001.001.03 nicht mehr führen. FinTsUeberweisung fängt außerdem
die UnsupportedException ab, die php-fints wirft, wenn die Bank
Namensabgleich-Volltreffer und TAN-Anfrage in einem Antwortsatz kombiniert,
und lässt den vorhandenen automatischen Volltreffer-Namensabgleich den Rest
erledigen.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-28 22:54:58 +02:00
fds2610-bot
dba60c64e4 Fix #77: Splitbuchung und direkte Zuordnung sperren sich gegenseitig
In der Buchungsmaske sperrt eine Eingabe in den Splitzeilen sofort
Kategorie / Gegenkonto und Klasse, und umgekehrt sperrt eine Kategorie
oder Klasse alle Splitzeilen. Der neue Knopf „Splitbuchungen löschen“
rechts über der Splittabelle leert alle Zeilen und gibt die direkten
Felder wieder frei.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-28 22:40:13 +02:00
fds2610-bot
c26c316798 Fix #76: Klassen der Splitzeilen in der Klassenspalte des Kontoblatts
Bei einer Splitbuchung zeigt die Klassenspalte jetzt die gemeinsame Klasse
der Splitzeilen. Unterscheiden sie sich, steht dort die Marke „Splitbuchung“,
der Tooltip nennt je Splitzeile Kategorie und Klasse. Ein Klick auf die
Klassenzelle einer Splitbuchung öffnet den Splitdialog.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-28 12:57:13 +02:00
fds2610-bot
4d833f273b Fix #75: Knopf „Alle Umsätze abrufen“ ruft jede Bank der Reihe nach ab
Über der Tabelle der Bankverbindungen ruft ein neuer Knopf jede aktive
Bankverbindung einzeln nacheinander ab. Die Warteschlange (Services\Sammelabruf)
übersteht TAN-Runden in der Sitzung; nach der Freigabe geht es mit der nächsten
Bank weiter. Die TAN-Maske zeigt den Stand und erlaubt, eine Bank zu
überspringen. Am Ende steht je Bankverbindung eine eigene Meldung.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-28 12:38:24 +02:00
fds2610-bot
a2c02b224e Fix n.n.: Einnahme/Ausgabe entscheidet der Geldfluss, nicht die Kategorie-Art
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-28 08:59:52 +02:00
fds2610-bot
233b570e76 Fix #84: Cockpit-Legendeneinträge öffnen die Buchungen dahinter
Jeder Legendeneintrag der Cockpit-Kacheln führt zu den Buchungen, aus denen
sich sein Wert zusammensetzt: Kategorien, „Nicht kategorisiert“ und „Übrige“
in „Meine Ausgaben“, Einnahmen/Ausgaben/Saldo in „Einnahmen und Ausgaben“,
Konten der Vermögensentwicklung ins Kontoblatt. Ziel ist der Drilldown der
Auswertungen mit dem Filter der Kachel; zeilenbuchungen() kennt dafür einen
Art-Filter, „alle Bewegungen“ und mehrere Kategorien.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-28 08:27:32 +02:00
fds2610-bot
2223ab4e06 Fix n.n.: Kontoblatt zeigt IBAN und Bank der Gegenseite im Verwendungszweck-Tooltip
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-27 15:46:51 +02:00
fds2610-bot
e02bac22c0 Fix n.n.: Buchungen im Kontoblatt lassen sich manuell verknüpfen
Liegen zwei Buchungen, die eigentlich derselbe Vorgang sind, zu weit
auseinander oder gehörte eine ursprünglich einem anderen Ursprungskonto,
findet der automatische Abgleich sie nicht – die Umbuchung und ihre
einzeln erfasste Dublette stehen dann dauerhaft nebeneinander im
Kontoblatt.

Buchung::verknuepfen() führt eine Umbuchung (eigene Seite oder
Gegenseite auf diesem Konto) und eine einzeln erfasste Buchung mit
passendem Betrag zusammen: Die Umbuchung bleibt, die Dublette fällt
weg, ihr Bankumsatz hängt sich an die Umbuchung. Im Kontoblatt lässt
sich dafür jetzt auch die Gegenseite einer fremden Umbuchung ankreuzen;
ein neuer Knopf „Verknüpfen“ nutzt dieselbe Auswahl wie „Auswahl
löschen“.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-27 14:53:56 +02:00
fds2610-bot
c2a6a9b899 Fix n.n.: Buchungsbericht zeigt Splitbuchung nach Konto/Empfänger zusammengefasst
Bei Gruppierung nach Konto oder Empfänger landen alle Zeilen einer
Splitbuchung ohnehin in derselben Gruppe, erschienen dort aber trotzdem
einzeln mit ihrem Teilbetrag statt dem Gesamtbetrag der Buchung – wer nur
eine Zeile sah, hielt sie für den vollständigen Betrag. Bei Kategorie oder
Klasse bleibt es beim bisherigen Verhalten, weil eine Splitbuchung dort auf
mehrere Gruppen verteilt ist und die Gruppensummen sonst nicht mehr zum
Summenbericht passten.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-27 14:16:41 +02:00
fds2610-bot
4bed769810 Fix n.n.: Regel-Testlauf trägt Kategorien direkt nach statt nur zu zählen
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-27 13:50:17 +02:00
fds2610-bot
2bf5bae3bd Fix n.n.: Regel-Testlauf prüft gegen Buchungen ohne Kategorie statt gegen offene Umsätze
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-27 13:42:36 +02:00
fds2610-bot
9ae2dfea40 Fix n.n.: update.sh zieht aus dem Fork und läuft auch bei unverändertem Code weiter
Der Pull nennt Remote und Branch ausdrücklich (origin main, HTTP/1.1), damit kein
Tracking-Branch nötig ist. Quelle ist der Fork, solange es nur die Entwicklungsumgebung
gibt; für eine spätere Produktion gibt es UPDATE_REMOTE=upstream. Das Skript bricht bei
unverändertem Code nicht mehr ab, sodass Migrationen eines von Hand gezogenen Stands
nachgeholt werden. Doku (CLAUDE.md, PLAN.md, README.md, Changes.md) angepasst.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-25 15:44:08 +02:00
fds2610-bot
822458ee0f Fix #71: Echtzeitüberweisung im Überweisungsdialog
Der Überweisungsdialog bietet das Häkchen „Echtzeitüberweisung“. SEPA
behandelt sie als eigenes Verfahren: Über FinTS geht der Auftrag als HKIPZ
(SendSEPARealtimeTransfer) statt als HKCCS hinaus, die pain.001-Nachricht
trägt die Zahlungsart LclInstrm/Cd = INST (nur im ISO-Format
pain.001.001.03). Eine Echtzeitüberweisung hat keinen Ausführungstermin;
bietet die Bank sie nicht an, scheitert der Auftrag mit klarer Meldung,
eine stille Umwandlung in eine gewöhnliche Überweisung ist abgeschaltet.

Neue Spalte zahlungsauftraege.echtzeit (Migration 019), Test 43 und ein
E2E-Test für das Sperren des Termins.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-25 15:21:04 +02:00
fds2610-bot
3caf1dcdca Fix #67: Übermittlungsprotokoll für Überweisungen und Bankkommunikation speichern
Der gesamte FinTS-Dialog (gesendete und empfangene Meldungen) wird je Durchlauf
in bank_protokolle gespeichert, im Erfolgs- wie im Fehlerfall. Im Zahlungsverkehr
öffnet der Status das Protokoll der Überweisung als modalen Dialog; unter
Online-Banking › Protokoll gibt es das Gesamtprotokoll mit Filter nach Bank,
Datum und Freitext.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-21 07:48:10 +02:00
fds2610-bot
9488c2d4ef Fix #61: Verbliebenen roten E2E-Test aus dem Typeahead-Umbau behoben
Die vier in #61 beschriebenen Ursachen waren bereits durch Fix #62 (PR #63)
behoben. Ein Test blieb aber weiterhin zuverlässig rot: Der Abgleich gegen die
absichtlich ungültige Bargeld-Tool-Adresse braucht durch Verbindungsaufbau und
Namensauflösung über 15 Sekunden, bevor er als gescheitert gilt – mehr, als
Playwrights Standard-Timeout von 5 s für toContainText() hergibt. Die
betroffenen Erwartungen tragen jetzt 25 s Timeout, der Test insgesamt 90 s.

Geprüft: tests/e2e/run.sh (87/87 grün, dreifach wiederholt) und
./scripts/run-tests.sh (1895 Prüfungen bestanden).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-04 21:37:57 +02:00
fds2610-bot
a81ec1ceba Fix #64: E2E-Datenbestand vor jedem Lauf aufräumen und neu aufbauen
Die Browser-Tests legten ihre Konten, Kategorien und Buchungen bei jedem Lauf
neu an, weggeräumt hat sie niemand: Zuletzt standen über dreitausend Zeilen
Testdaten in der Datenbank – vierzig „E2E Bankprovision …“ hintereinander im
Kategoriefilter, und kein Bildschirmfoto eines fehlgeschlagenen Tests war mehr
zu gebrauchen.

scripts/e2e-aufraeumen.php räumt weg, was am Testnutzer hängt – nicht, was nach
Testdaten aussieht. Ein Namensmuster übersähe die Buchung „Supermarkt“ und träfe
irgendwann etwas Echtes; die Fremdschlüssel dagegen sagen genau, was zu diesem
Nutzer gehört, und nehmen über ihre Kaskaden auch die Zeilen ohne eigene
benutzer_id mit. Der Nutzer selbst bleibt stehen, und er muss den Anzeigenamen
tragen, den scripts/e2e-benutzer.php setzt: Wer E2E_USER versehentlich auf seinen
eigenen Zugang stellt, bekommt einen Abbruch statt eines leeren Datenbestands.

Aufgerufen wird es vor dem Lauf, nicht danach – ein abgebrochener Lauf
hinterlässt sonst einen Bestand, an den niemand mehr denkt, und so bleiben die
Daten des letzten Laufs bis zum nächsten für die Fehlersuche stehen.

Das deckte auf, dass sieben Tests auf den Resten früherer Läufe standen: Die
Auswertungen prüfen, dass ein Bericht eine Tabelle statt eines Platzhalters
zeigt, das Cockpit, dass „Übrige Konten“ eine Ebene tiefer führt – Daten dafür
legte keiner von ihnen an. scripts/e2e-grundbestand.php stellt deshalb einen
festgelegten Bestand her, dessen Zuschnitte an genau diesen Tests hängen: mehr
Konten als Vermoegensentwicklung::SERIEN, Buchungen in jedem Monat des laufenden
Jahres, ein Vorjahr für den Vergleichsbericht, ein Depot mit Wertpapiergeschäft.
Test 41 prüft jede dieser Grenzen einzeln und nennt den Test, der daran hängt.

87 E2E-Tests grün, in 1,3 statt 2,7 Minuten – die Listen rendern keine
Tausenden Altzeilen mehr.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AQ57wQWZ4xKHcKmp26bzgr
2026-09-04 17:36:13 +02:00
fds2610-bot
5491bb69f6 Fix #62: E2E-Tests an den Typeahead im Kontoblatt angepasst
Zwölf Tests standen auf Rot, ohne dass die Anwendung etwas falsch machte – die
Specs prüften den Stand vor dem Umbau. Vier Ursachen lagen darunter:

Die Kombobox lässt ihr <select> zwar im Formular stehen, setzt es aber auf
hidden; selectOption() wartet darauf vergeblich. Der neue Helfer
tests/e2e/specs/hilfen.js bedient das Eingabefeld, tippt die Beschriftung ein
und klickt den genau passenden Treffer an – exakt, weil [Depot] sonst auch das
[Depot] … des Wertpapiergeschäfts träfe.

Seit dem Schnellspeichern ohne Neuladen stehen zwei Erfolgsmeldungen
übereinander; gemeint ist die neue, also .last().

Die Adressliste ist seit der Adressverwaltung eine Bearbeitungstabelle: Die
Namen stehen in Eingabefeldern, wo toContainText nicht hinsieht. Geprüft wird
jetzt der Feldwert – gespeichert wurde die Adresse die ganze Zeit korrekt.

Die beiden übrigen Fehlschläge waren Folgefehler: Playwright startet nach jedem
Fehlschlag einen frischen Worker, das Spec-Modul wird neu geladen, seine Marke
neu gezogen und beforeAll legt leere Konten an. Sie brauchten keine Änderung.

87 Tests grün, und ohne die Timeouts in 2,7 statt 7,1 Minuten.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AQ57wQWZ4xKHcKmp26bzgr
2026-09-04 12:39:29 +02:00
fds2610-bot
b74cbe5416 FinTS-Bibliothek auf 4.1.4 gehoben
Der Fork steht jetzt auf dem Upstream-Stand vom 03.09.2026. Der Patch fuer
getDifferingPayeeName() ist upstream gemergt und entfaellt als eigener Commit;
im Fork bleiben das eingebaute psr/log und der VOP-Stepwise-Patch, der als
PR #584 offen und auf den neuen Stand rebased ist.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AQ57wQWZ4xKHcKmp26bzgr
2026-09-04 10:01:33 +02:00
fds2610-bot
e7c965c219 Fix #58: Auftragskonto über die Kontenzuordnung finden
Beim Senden suchte FinTsUeberweisung unter den Konten, die die Bank meldet,
nach der IBAN aus dem Konto selbst. Die ist in der Kontenverwaltung als
optional ausgewiesen und bleibt meist leer – dann scheiterte die Überweisung
an "Die Bank führt kein Konto mit der IBAN des Auftragskontos", obwohl der
Umsatzabruf für dasselbe Konto längst lief.

Maßgeblich ist jetzt dieselbe Zuordnung wie beim Abruf: die Zeile in
bank_konten, die dem Konto zugewiesen ist. Dort steht die IBAN, die die Bank
selbst gemeldet hat, und die Kontonummer für die Häuser, die keine IBAN
liefern. Die IBAN am Konto bleibt als Weg bestehen, ebenso der Fall, dass die
Bank nur ein einziges Konto führt.

passendesKonto() ist dafür public static geworden und nimmt den Zugang als
Parameter – so lässt sich die Wahl mit echten SEPAAccount-Objekten prüfen,
ohne eine Bank zu brauchen.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013iURiWYZJQYVGQNXFFGyWu
2026-09-01 20:08:54 +02:00
fds2610-bot
79f617025b Fix #56: Namensabgleich vor der Überweisung
Seit Oktober 2025 gleicht die Bank vor der Ausführung den Empfängernamen mit
dem Kontoinhaber ab (Verification of Payee). Der Finanzmanager kannte diese
Stufe nicht, die Überweisung blieb stehen.

FinTsUeberweisung wartet jetzt auf das Ergebnis, solange die Bank es braucht.
Stimmt der Name überein, wird selbst bestätigt und direkt zur TAN gegangen –
eine Rückfrage ohne Erkenntnis erspart das dem Nutzer. Weicht der Name ab, ist
er nur nahezu gleich oder konnte die Bank nicht prüfen, kommt die neue Maske
zahlungsverkehr/vop.php: Ergebnis in einem deutschen Satz, Aufklärungstext der
Bank als Klartext, Empfänger und IBAN aus dem Auftrag und – sofern die Bank ihn
nennt – der bei ihr hinterlegte Kontoinhaber.

Ohne Ausführungstermin steht jetzt das Platzhalterdatum 1999-01-01 in der
Nachricht. Mit dem heutigen Datum wurde daraus eine terminierte Überweisung
(HKCSE statt HKCCS), die die Bank mit "Die minimale Vorlaufzeit beträgt 1 Tage"
zurückwies.

Der FinTS-Fork steht auf v4.1.3 mit zwei Eingriffen: Die schrittweise Lieferung
des Prüfberichts wird erst abgelehnt, wenn sie wirklich eintritt, und der beim
Close Match gemeldete Kontoinhaber wird an die Anwendung durchgereicht. Beide
liegen zusätzlich auf eigenen Branches für PRs an das Upstream-Projekt.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013iURiWYZJQYVGQNXFFGyWu
2026-09-01 19:58:12 +02:00
fds2610-bot
3444f8f6ec Fix #54: Überweisung im SEPA-Format der Bank
Die Nachricht wurde fest als pain.001.001.03 erzeugt. Banken, die nur das
ältere DK-Format pain.001.003.03 führen, weisen die Überweisung damit schon
beim Einreichen ab, noch vor der TAN.

FinTsUeberweisung liest die unterstützten Formate nach der Anmeldung aus dem
Segment HISPAS; SepaXml::schemaWaehlen() bestimmt daraus den Namensraum –
bevorzugt ISO, sonst DK. Für die Einzelüberweisung sind beide Fassungen im
Aufbau gleich, es genügt der andere Namensraum. Das DK-Schema liegt der
Testsuite bei, damit die Nachricht wirklich dagegen geprüft wird.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013iURiWYZJQYVGQNXFFGyWu
2026-09-01 18:22:04 +02:00
fds2610-bot
85518ad850 Fix #51: Adressverwaltung in der Verwaltung, Typeahead im Zahlungsverkehr
Das Adressbuch bekommt in der Verwaltung eine eigene Kachel statt nur
über die Verträge erreichbar zu sein, denn es speist auch den
Zahlungsverkehr. Auf der Adressliste klappt zu jeder Adresse ein
<details>-Element ihre letzten Buchungen auf (Buchung::letzteFuerEmpfaenger,
kontenübergreifend nach dem exakten Empfängernamen – die Buchung führt
kein Fremdschlüsselfeld auf die Adresse).

Die Empfängerauswahl im Zahlungsverkehr-Formular ist jetzt ein Typeahead:
kombobox.js (bereits für die Kategorie im Kontoblatt im Einsatz) baut das
<select> in ein gefiltertes Eingabefeld um. Geprüft (PHP- und E2E-Tests),
dass "Empfänger ins Adressbuch übernehmen" beim Erfassen einer
Überweisung tatsächlich eine Adresse anlegt.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-31 08:27:15 +02:00
fds2610-bot
da8e3784fa Fix #50: Zahlungsverkehr wählt die Bank automatisch zum Auftragskonto
Das Überweisungsformular fragt nur noch das Auftragskonto ab; die passende
Bankverbindung ermittelt Bankzugang::zugangJeKonto() aus der Kontenzuordnung.
Konten ohne konfigurierte Bank stehen in der Auswahl nicht mehr zur Verfügung.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-31 07:58:07 +02:00
fds2610-bot
606bbb3b35 Fix #46: Reiter 'Profil' zum Ändern des eigenen Passworts 2026-08-20 18:48:27 +02:00
fds2610-bot
94e8057d73 Fix #43: CONTRIBUTE.md und Setup-Skript für Mitwirkende
CONTRIBUTE.md beschreibt Wege für Beiträge, gesuchte Unterstützung und die
drei bindenden Leitlinien (FOSS, Datensparsamkeit, Security) mit einem
Disclaimer, dass VIBE Coding ausdrücklich erlaubt ist. dev-setup.sh im
Repo-Root richtet Docker, Fork/Upstream-Checkout, lokale Container und
optional die E2E-Testinfrastruktur ein.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-19 20:28:10 +02:00
fds2610-bot
088cfbfe66 Fix #41: Typeahead für Kategorien im Kontoblatt
Kategorie-Filter und Schnellzuordnung tragen jetzt data-kombobox: kombobox.js
baut das <select> beim Laden in ein Eingabefeld mit gefilterter, aufklappender
Liste um, ohne Verhalten oder Markup für vorhandenen Code (kontoblatt.js) zu
ändern. Die Klassen-Auswahl bleibt bewusst ein gewöhnliches <select> – ihre
Liste ist kurz.
2026-08-19 20:03:16 +02:00
fds2610-bot
a077e03bee Fix #40: Kategorie im Kontoblatt ohne Neuladen speichern
Das Ändern von Kategorie oder Klasse im Kontoblatt lud bisher die ganze
Seite neu, um die Zeile zu aktualisieren – dabei sprang der Bildschirm
nach ganz oben. kontoblatt.js schickt die Auswahl jetzt per fetch im
Hintergrund; Kategorie, Klasse und das Symbol der Bargeld-Abgleichspalte
aktualisieren sich an Ort und Stelle, die Bildlaufposition bleibt stehen.
Ohne JavaScript bleibt es bei der bisherigen Weiterleitung.
2026-08-19 14:57:09 +02:00
fds2610-bot
aeb8254840 Fix #21: Bargeld-Tool auch bei Adresse mit /api/v1 erreichen
Der Verbindungstest meldete „Das Bargeld-Tool kennt die Schnittstelle nicht
(HTTP 404)“, sobald die hinterlegte Adresse den Schnittstellenpfad schon
enthielt: Der Finanzmanager hängt ihn selbst an und fragte damit unter
/api/v1/api/v1/status an.

Die Adresse aus der Browserzeile zu kopieren ist der naheliegende Weg, und
der Pfad ist dort mit dabei. Ein abschließendes /api oder /api/v1 kürzt
BargeldTool::basisadresse() deshalb weg – beim Speichern und noch einmal im
Konstruktor, damit auch schon gespeicherte Adressen greifen. Ein
Unterverzeichnis davor bleibt erhalten, ein Hostname wie apianbieter.example
bleibt unangetastet.

Bereits gespeicherte Adressen räumt Migration 017 auf.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-19 08:15:45 +02:00
fds2610-bot
ddf0638693 Fix #21: Abgleich mit dem Bargeld-Tool
Beim Zuweisen einer Kategorie fragt der Finanzmanager beim Bargeld-Tool
(FSCash) nach, ob es zum Betrag dort schon eine Buchung gibt.

Eingerichtet wird das unter Verwaltung → Bargeld-Tool: Adresse,
Zugangsdaten (Passwort AES-verschlüsselt), Suchzeitraum und die Auswahl
der abzugleichenden Kategorien. Die Vormerkung steht als
`bargeld_abgleich` an der Kategorie selbst, nicht als Nummernliste in den
Einstellungen – so verschwindet sie mit der Kategorie.

Geprüft wird nur, was geprüft werden soll: Kategorie an der Buchung,
Kategorie vorgemerkt, Adresse konfiguriert. Fällt eines weg, verschwindet
der Status. Gesucht wird rückwärts ab dem Buchungsdatum, weil Bargeld
ausgegeben wird, bevor der Umsatz auf dem Konto ankommt.

Im Kontoblatt steht das Ergebnis zwischen Klasse und Betrag: grauer Kreis,
grüner Haken, rotes X, Ausrufezeichen. Das Ausrufezeichen behält die
Textfarbe des Farbschemas – der Fehler liegt beim Abruf, nicht bei der
Buchung. Ohne hinterlegte Adresse entfällt die Spalte.

Ein Fehlschlag ist ein Ergebnis, kein Abbruch: Die Kategorie wird auch
dann gespeichert, wenn das Bargeld-Tool schweigt.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-19 07:06:20 +02:00
fds2610-bot
a5e50f8529 Listen: Zahlenspalten überall rechtsbündig
Die Klasse .rechts wurde in Listen von der spezifischeren Grundregel
"table.liste th, table.liste td { text-align: left }" überstimmt – die
Ausrichtung war also überall wirkungslos, nicht nur in den Berichten. Die
Regel steht jetzt bei den Tabellen-Grundregeln und gilt für alle Listen:
Kontenübersicht, Kontoblatt, Wertpapiere, Depotbuchungen, Kategorien und
die Berichte. Die berichtseigene Sonderregel entfällt dadurch.

Budgetplaner und Splittabellen bringen ihre eigene Ausrichtung mit und
bleiben unberührt.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-18 21:13:13 +02:00
fds2610-bot
6ca247a40d Berichte: Tabelle mittig statt links ausgerichtet
Linksbündig wirkte die schmale Tabelle verloren neben dem zentrierten
Berichtskopf. Sie steht jetzt mittig unter Überschrift und Zeitraumzeile;
die Zahlenspalten bleiben in sich rechtsbündig. Der E2E-Test prüft, dass
links und rechts gleich viel Luft bleibt.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-18 21:04:19 +02:00
fds2610-bot
43cd73afb7 Berichte: Tabellen so breit wie nötig, Zahlen rechtsbündig
Berichtstabellen nehmen nur noch den Platz, den ihre Spalten brauchen, und
stehen links; erst bei mehr Inhalt wachsen sie bis zur vollen Breite. Im
Scrollrahmen .breittabelle bleibt es beim bisherigen Verhalten, damit die
zwölf Monatsspalten weiter waagerecht scrollen statt umzubrechen.

Dabei kam heraus, dass die Zahlenspalten gar nicht rechtsbündig standen:
.rechts und .betrag sind nur einfach spezifisch, das weiter oben stehende
"table.liste th, table.liste td { text-align: left }" gewann. Für Berichte
steht die Ausrichtung jetzt ausdrücklich, sodass die letzte Spalte ihre
Beträge an der eigenen Kante ausrichtet.

Nachgezogen: Der E2E-Test der eingeklappten Seitenleiste erwartete
toBeHidden() für die Beschriftungen, die aber mit Absicht nur per clip-path
aus dem Bild geschoben werden – für Playwright bleiben sie sichtbar. Geprüft
wird jetzt, dass sie keinen Platz mehr einnehmen und der Verweis seinen
zugänglichen Namen behält.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-18 21:00:32 +02:00
fds2610-bot
280664b8a3 Seitenleiste: Marke mit Münzstapel, ein Klick schiebt sie auf Symbolbreite
Die Marke oben in der Seitenleiste trägt jetzt das Coinstack-Symbol aus den
Altdaten und den zweifarbigen Schriftzug Finanz|manager – wie die
sidebar-brand im Steuerkram. Sie ist zugleich der Schalter: Ein Klick schiebt
die Leiste von 232 px auf 64 px zusammen, ein Klick auf das Symbol klappt sie
wieder auf. Die Menüpunkte behalten dabei Ziel und Symbol.

Der Zustand steht in einem Cookie und nicht im localStorage: So rendert der
Server die Leiste schon in der richtigen Breite, statt sie bei jedem
Seitenwechsel kurz breit aufblitzen zu lassen. Die Beschriftungen wandern
eingeklappt per clip-path aus dem Bild statt per display:none – sonst
verlören die Verweise ihren Namen für Vorleseprogramme.

Nebenbei: Die Marke hieß bisher .marke, wie die kleine Statusmarke weiter
unten im Stilblatt, deren Regeln sie überschrieben. Sie heißt jetzt
.seitenleisten-marke.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-18 11:45:45 +02:00
fds2610-bot
0b4a216954 Sammel-Commit: PayPal-Bankverbindung und Bankleitzahlen-Verzeichnis
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>
2026-08-18 08:48:14 +02:00
fds2610-bot
066879d61f Test: Umbuchungen spiegeln sich zuverlässig
Neuer Test 30. Er hält die zwei Zusagen des Datenmodells fest: Was ein
Gegenkonto trägt, steht im Kontoblatt dieses Gegenkontos – auf allen vier
Wegen, auf denen ein Gegenkonto an eine Buchung kommt – und wer die Buchung
löscht, löscht beide Sichten.

Dazu eine Invariantenprüfung über alle Daten des Mandanten an sieben Stellen
des Ablaufs. Vier absichtliche Eingriffe ins Modell lassen den Test
zuverlässig fehlschlagen.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-18 06:52:33 +02:00