Der Buchungsbericht zeigt vor der Spalte „Bar“ des Bargeld-Tools die
Spalte „✓“ (abgeglichen) und lässt sich nach abgeglichenen bzw. nicht
abgeglichenen Buchungen filtern. „Buchungen nicht abgeglichen“ unter den
offenen Vorgängen im Cockpit öffnet jetzt diesen Bericht mit dem Filter
„nicht abgeglichen“ statt der Kontenübersicht.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Neuer Schalter „Ohne Bargeld-Abgleich“ in der Buchungsmaske für
Sammelbuchungen und Differenzausgleiche. Solche Buchungen werden nicht
gegen das Bargeld-Tool geprüft, ein früherer Status wird gelöscht, und sie
erscheinen nicht mehr unter den offenen Vorgängen im Cockpit. Kontoblatt
und Buchungsbericht zeigen einen leeren grauen Kreis.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Die offenen Vorgänge „im Bargeld-Tool nicht gefunden“ und „Bargeld-Tool-
Prüfung fehlgeschlagen“ führen in den Buchungsbericht mit dem Filter
„Bargeld-Tool“ – dort steht die Spalte Kategorie/Gegenkonto mit. Die
eigene Liste unter /verwaltung/bargeld/fehler entfällt.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
In „Depotbuchung erfassen“ ergibt sich bei Kauf und Verkauf aus zwei der drei
Felder Betrag, Stück und Kurs das dritte (Betrag = Stück × Kurs). Der
ausgerechnete Wert ist hervorgehoben und zieht nach, wenn sich die anderen
Felder ändern. Serverseitig rechnet Depotbuchung::dritterWert() dieselbe
Regel für den Weg ohne JavaScript.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Die Wertpapiermaske (Dialog im Kontoblatt und Seite ohne JavaScript) sowie
„Depotbuchung erfassen“ bieten eine Klasse an. Im Kontoblatt ist sie mit der
bisherigen Klasse der Buchung vorbelegt und gilt für die Buchung samt aller
Splitzeilen der Nebenkosten; bei der Depotbuchung steht sie an der erzeugten
Geldbuchung. Unbekannte Klassen werden abgewiesen.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Unter den Kategorien stehen überall die aktiven Umbuchungskonten, je
Kontengruppe gruppiert und in deren Reihenfolge (Konto::umbuchungsgruppen()):
Regeln samt Splitzeilen, Umsatzabgleich, Buchungsvorlagen, Regelmäßige
Buchungen, Zahlungsverkehr, Verträge sowie die Filter von Buchungsbericht
und Export. Die Masken nutzen dafür die gemeinsame Liste Kategorie /
Gegenkonto der Buchungsmaske; das getrennte Gegenkonto-Feld der Regel
entfällt.
Regel-Splitzeilen können auf ein Umbuchungskonto zeigen. Zahlungsaufträge
und Verträge bekommen ein Gegenkonto (Migration 030). Ein schon gewähltes
inaktives Konto bleibt sichtbar, damit keine Zuordnung verloren geht.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Neuer Schalter „automatisch abgleichen“ unter „automatisch buchen“
(Vorgabe: eingeschaltet). Gesetzt wird die aus der Reihe entstandene
Buchung als abgeglichen markiert. Die Übersicht erhält die Spalte
„Abgleichen“ zwischen „Auto“ und „Aktiv“.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Neuer Schalter „Bewusst ohne Kategorie“ in der Buchungsmaske für
Abschreibungen und rein rechnerische Solarerträge. Solche Buchungen
erscheinen nicht unter den offenen Vorgängen im Cockpit, nicht im
Prüflauf des Monatsabschlusses, setzen das Konto in der Kontenübersicht
nicht fett und werden von der Regelanwendung sowie dem automatischen
Zusammenführen zu Umbuchungen ausgelassen. Kommt eine Kategorie, ein
Gegenkonto oder eine Splitbuchung hinzu, entfällt die Markierung.
Migration 028_bewusst_ohne_kategorie.sql, Test 59 und E2E-Test.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Meldet die Bank nach der TAN 3045 (noch keine Rückmeldung zum Status),
fragt ein Hintergrundprozess nach der Mindestwartezeit aus HIIPSS per
HKIPS nach (höchstens fünfmal). Ausgeführt wird vermerkt, abgelehnt
entfernt die Buchung; ein verbundener Kontoumsatz klärt den Status
ebenfalls. php-fints-Fork v4.1.7 bringt HKIPS/HIIPS/HIIPSS mit.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- Status „wartet auf Freigabe“, solange die Bank auf TAN/Namensabgleich wartet
- Abbruch der Freigabe (auch durch neuen Sendeversuch) im Übermittlungsprotokoll
als „abgebrochen“ festhalten, Auftrag als fehlgeschlagen vermerken
- Aufträge mit Übermittlungsprotokoll nur stornieren, nicht löschen
- Migration 025, PHP-Test 57, E2E-Spec zahlungsfreigabe
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Elf Listenansichten (Klassen, Buchungsvorlagen, Regelmäßige Buchungen,
Erinnerungen, Verträge, Adressen, Sparziele, Kredite, Abgleichregeln,
Budgets, Berichtsgruppen) zeigten das Formular unter der Liste. Jetzt
öffnet der Knopf „+ Neu“ es als Dialog.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
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>
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>
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>
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>
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>
Ü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>
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>
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>
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>
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
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
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>
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.
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>
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>
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>
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>
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>
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>
Neue Buchung und Buchung bearbeiten zeigen oben das Konto, in dem die
Buchung liegt. Die Maske steht zweispaltig, die Beschriftungen links
neben ihren Eingaben und die Erklärungen in deren Tooltip – damit endet
sie samt Splitzeilen und Knopfleiste oberhalb der Fensterhöhe.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Konto bearbeiten und Neues Konto zeigen ihre vierzehn Felder in zwei
Spalten, damit alles ohne vertikales Scrollen auf einen Bildschirm passt.
- Neue Formularvariante .formular.zweispaltig: Grid mit zwei Spalten, je
Feld ein .feld aus Beschriftung, Eingabe und Hinweis. Überschriften,
Knopfleiste und .feld.ganz laufen über beide Spalten, unter 720 px
fällt das Formular auf eine Spalte zurück.
- Feldreihenfolge zeilenweise; Namen, Werte und Feld-IDs unverändert.
- E2E-Test: Kontoart steht rechts neben dem Namen, das Formular endet
oberhalb der Fensterhöhe.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Aus der Kachel QIF-Import wird Import/Export mit je einem Knopf für beide
Richtungen; davor steht die Wahl des Dateiformats (QIF oder CSV), die als
Dialog und ohne Skript als eigene Seite funktioniert.
- CsvBuchungsImport/CsvTabelle: Buchungen samt Splitzeilen, Spalten über die
Kopfzeile, dieselbe Dublettenerkennung und der Trockenlauf wie beim QIF.
- BuchungsExport/ExportController: Filter nach Zeitraum, Konto, Kategorie und
Klasse; die Datei entsteht im Speicher, ein Exportverzeichnis gibt es nicht.
- Housekeeping: Hochgeladene Importdateien und data/tmp werden nach der
eingestellten Frist gelöscht (Vorgabe 14 Tage, 0 schaltet ab).
Migration 013, Test 29 sowie E2E-Spec importexport.spec.js.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Die Klassenspalte ist anklickbar wie die Zuordnung daneben: Ein Klick
öffnet die Klassenliste in der Zelle, die Auswahl wird sofort über
POST /buchungen/{id}/klasse gespeichert. Buchung::klasseSetzen() lässt
Kategorie, Gegenkonto und Splitzeilen unberührt.
Die Buchungszeilen sind jetzt alle zwei Textzeilen hoch, ihr Inhalt steht
senkrecht in der Mitte. Was nicht auf zwei Zeilen passt, wird
abgeschnitten; den vollständigen Text zeigt der Tooltip – bei Empfänger
und Buchungstext nur dort, wo wirklich etwas fehlt, über dem
Kategoriefeld einer Splitbuchung deren Zeilen mit Kategorie und Betrag.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der Name in Bestandsübersicht, Depotbuchungen und Stammdaten führt jetzt auf
/wertpapiere/papier/{id}: Kennzahlen über die ganze Historie, Stammdaten und
Kurs, Bestand je Depot, Wertentwicklung und die Buchungen eines Zeitraums.
Depot::bestand() und Depot::entwicklung() nehmen dafür eine Wertpapiernummer
entgegen – die Detailseite rechnet nicht selbst, sondern bekommt dieselben
Zahlen wie die Übersicht. Neu sind Wertpapier::kurseckwerte() und
Depotbuchung::datumsgrenzen().
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Die Spec trug ISIN und WKN fest im Verwendungszweck. Ein Papier wird über
seine Kennung wiedergefunden und nicht doppelt angelegt – beim zweiten Lauf
gegen dieselbe Datenbank hing der Test damit am Papier des ersten Laufs und
prüfte dessen Namen vergeblich. ISIN und WKN tragen jetzt die Marke des Laufs.
Der zweite Test bekommt einen Verwendungszweck ohne Wertpapierkennung, wie ihn
eine Sparplanrate hat: So entsteht das Papier wirklich unter dem Namen aus der
Maske, statt still das des ersten Tests mitzubenutzen – was der Test nun auch
prüft.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der Bankabruf bringt die Wertpapierabrechnung als Umsatz auf dem Girokonto, und
erst dort entscheidet sich, dass es ein Kauf war. Wer die Buchung einem Depot
zuordnete, buchte bisher eine Umbuchung – ohne Stückzahl, ohne Kurs, ohne
Einstand. Die Zuordnungsliste im Kontoblatt kennt jetzt neben Kategorie und
Gegenkonto eine dritte Gruppe "Wertpapiergeschäft im Depot", die statt zu
speichern die Wertpapiermaske öffnet; ohne JavaScript führt derselbe Weg auf
/buchungen/{id}/wertpapier.
Die Maske ist auf den "Wertpapier kaufen"-Dialog des FinanzManagers
zugeschnitten: vorne Vorgangsart, Datum, Wertpapier, Stück und Kurs, dahinter
hinter dem Knopf "Kosten …" die Nebenkosten nach Arten – sechs Gebühren und
sechs Steuern. ISIN und WKN werden aus dem Verwendungszweck gelesen, ein
bekanntes Papier ist damit vorausgewählt. Ein Abfluss vom Konto kann nur ein
Kauf sein, ein Zufluss ein Verkauf oder eine Dividende.
Der Buchungsbetrag ist die feste Größe: Die Nebenkosten werden aus ihm
herausgerechnet, was übrig bleibt ist der Kurswert und damit der
Einstandspreis. Im Kontoblatt entsteht eine Splitbuchung mit je einer Zeile pro
belegter Kostenart und dem Rest als Umbuchung ins Depot; ohne Nebenkosten
bleibt es bei der schlichten Umbuchung. Die Depotbuchung hängt sich an die
vorhandene Buchung, statt eine zweite anzulegen (neue Spalte
depot_buchungen.buchung_erzeugt) – wird sie gelöscht, bleibt die Buchung der
Bank stehen und ist nur wieder unzugeordnet.
Die Kategorien der Kostenarten liegen im Einstellungsdialog unter "Wertpapiere",
einmalig je Art; für "Sonstige Kosten" ist die Einstellung nur die Vorgabe und
im Dialog überschreibbar. Arten ohne Kategorie werden zu Splitzeilen ohne
Zuordnung, nicht zu einem Fehler.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der Abrufzeitraum kannte bisher nur Spannen. Der Stichtag steht jetzt an zwei
Stellen: als Vorgabe der Bankverbindung (neuer Abrufzeitraum "Ab Stichtag" mit
Datum in bank_zugaenge.abruf_stichtag) und als einmalige Angabe neben "Umsätze
abrufen", die der Vorgabe vorgeht und nichts speichert.
Der einmalige Stichtag liegt im Abrufzustand, nicht in der Datenbank: Nach einer
TAN-Runde läuft der Abruf im nächsten Request weiter und muss dort denselben
Zeitraum holen wie beim Start.
"Ab Stichtag" ohne Datum und unlesbare Datumsangaben werden abgewiesen; ein
Stichtag in der Zukunft wird auf heute gesetzt, statt den Abruf leer ausgehen zu
lassen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der Import kannte bisher nur den Zeitraum als Filter – ein Export ließ sich
nur ganz einlesen. Neu ist die Option "konten": im Dialog eine Ankreuzliste,
die erst nach dem Trockenlauf erscheint (vorher ist die Datei ungelesen), auf
der Kommandozeile --konto=NAME und --konten.
Maßgeblich ist nicht allein der !Account-Abschnitt, sondern jedes Konto, das
der Eintrag berührt: das eigene, die Umbuchungsziele aus L und den Splitzeilen
und beim Wertpapiergeschäft das Verrechnungskonto. Eine Umbuchung steht nur
einmal in der Datei – sonst fehlte dem gewählten Konto die Gegenseite.
Die Anfangssalden werden weiter über die ganze Datei gerechnet, aber nur für
die gewählten Konten geschrieben; ein Teilimport überschreibt sonst fremde
Salden. Die Fingerabdrücke entstehen jetzt vorab in einem eigenen Durchgang:
Der laufende Zähler für gleiche Fingerabdrücke hing sonst an der Auswahl, und
dieselbe Buchung wäre beim zweiten Lauf mit anderer Auswahl doppelt angelegt
worden.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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>
Nach einem Import, der schiefging, war das Löschen Zeile für Zeile mühsam. Die
Liste der Depotbuchungen räumt jetzt so auf wie das Kontoblatt: Ankreuzfeld je
Zeile, das Feld in der Titelzeile wählt alle angezeigten, „Auswahl löschen“ in
der Aktionsleiste schickt sie an POST /wertpapiere/buchungen/loeschen. Der Knopf
nennt die Anzahl und bleibt ohne Auswahl gesperrt; die Rückfrage nennt sie
ebenfalls. Ohne JavaScript funktioniert alles weiter – dann ist der Knopf offen
und der Controller weist eine leere Auswahl ab.
Mit jeder Depotbuchung geht ihre Geldbuchung, wie beim Löschen einer einzelnen.
Am Bestand ist nichts nachzuziehen: Er wird bei jedem Aufruf aus den
Depotbuchungen gerechnet und gibt die Löschung von selbst wieder her, ebenso
realisierter Gewinn, Veräußerungen und Erträge.
Der eingestellte Filter (Depot, Wertpapier, Vorgang) hängt am Ziel des
Formulars, deshalb steht danach wieder dieselbe Ansicht da. Zusammengesetzt wird
er im Controller neu, damit kein fremdes Ziel eingeschleust werden kann. Das
gilt jetzt auch für das „Löschen“ je Zeile, das bisher zur ungefilterten Liste
zurücksprang.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Kontenzuordnung als dritter Einrichtungsschritt: Welches Bankkonto gehört zu
welchem eigenen Konto? Umsätze merken sich über `bank_konto_id`, woher sie
stammen, und ziehen mit, wenn die Zuordnung erst nach einem Abruf fällt.
Abgerufene Umsätze buchen sich auf Wunsch selbst (`Services\Bankabgleich`).
Im Kontoblatt lassen sich Buchungen sammelweise löschen; Statusmeldungen liegen
jetzt über der Ansicht, statt den Inhalt springen zu lassen.
Dazu drei Fehler, die zusammen dafür sorgten, dass abgerufene Umsätze spurlos
verschwanden – der Abruf meldete sie als vorhanden, das Kontoblatt zeigte
nichts, und in der Vorschlagsliste standen sie ebenfalls nicht:
- Eine gelöschte Buchung ließ ihren Umsatz auf „uebernommen“ stehen. Der
Fremdschlüssel setzte nur `buchung_id` auf NULL. `Buchung::loeschen()` gibt
den Umsatz jetzt vorher frei, `Bankumsatz::verwaisteOeffnen()` fängt die Wege
ab, die daran vorbeiführen – Kaskaden lösen in MariaDB keine Trigger aus.
- Ein Bankkonto entstand doppelt, wenn die Bank die IBAN nicht bei jedem Dialog
mitliefert. Gesucht wird jetzt über die Kontonummer; eine nachgelieferte IBAN
wird am vorhandenen Eintrag nachgetragen.
- Der Fingerabdruck hing an der IBAN und kippte mit ihr. Er nimmt jetzt die
`bank_konto_id`, die fest steht, solange es den Bankzugang gibt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Die Bank lässt sich erst nach ihren TAN-Verfahren fragen, wenn die
Zugangsdaten gespeichert sind. Das Anlegen führt deshalb über „Weiter“
direkt auf die Verfahrensseite, und die holt die Liste selbst – ein
Knopf davor wäre ein Schritt, dessen Ergebnis feststeht.
Scheitert die Abfrage, bleibt das Ergebnis in der Sitzung, damit nicht
jeder Seitenaufruf wieder in dieselbe Zeitüberschreitung läuft; die ist
für die Abfrage kürzer gesetzt als in der Bibliothek.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
