fds2610-bot 78f1b91bc0 Online-Banking: Kontenzuordnung, Sammellöschen und drei Umsatz-Fehler

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>

2026-08-12 11:54:23 +02:00

4.4 KiB

Raw Blame History

Stammdaten

Konten, Kontengruppen, Kategorien und Klassen – die Grundlage aller Buchungen und Auswertungen. Die Begriffe entsprechen dem Lexware FinanzManager.

Kontengruppen und Konten

Kontengruppen gliedern die Kontenübersicht (etwa „Anlage“). Konten ohne Gruppe erscheinen unter Nicht gruppiert – das ist keine eigene Gruppe, sondern kontengruppe_id IS NULL. Wird eine Gruppe gelöscht, bleiben ihre Konten erhalten und rutschen dorthin (ON DELETE SET NULL).

Gruppen werden wie Konten und Kategorien auf einer eigenen Formularseite gepflegt (Verwaltung → Kontengruppen). Dort hängt auch die Zuordnung: Die Konten der Gruppe werden angekreuzt, Kontengruppe::kontenZuordnen() setzt sie in einem Zug. Ein Konto gehört zu genau einer Gruppe – wird es hier angehakt, verlässt es seine bisherige.

Der QIF-Export enthält keine Kontengruppen (siehe docs/qif-import.md); nach einem Import stehen deshalb alle Konten unter „Nicht gruppiert“ und werden einmalig zugeordnet.

Kontoarten (Konto::ARTEN) und ihre Herkunft aus dem QIF-Export (Konto::QIF_ARTEN):

Kontoart	Bezeichnung	QIF-Typ
`bank`	Bank	`Bank`
`kreditkarte`	Kreditkarte	`CCard`
`bar`	Bar	`Cash`
`sparkonto`	Tagesgeld/Sparkonto	`Oth T`
`vermoegen`	Vermögen	`Oth A`
`verbindlichkeit`	Verbindlichkeit	`Oth L`
`rente`	Rentenversicherung	`Oth P`
`sonstiges`	Sonstiges Vermögen	`Oth E`, `Oth F`
`depot`	Depot	`Port`, `Invst`

Die Kontenübersicht (Konto::uebersicht()) bündelt nach Gruppe, bildet je Gruppe eine Summe und darunter die Gesamtsumme. Sie führt schon jetzt die drei Saldospalten des FinanzManagers:

Online-Saldo – Stand des letzten Bankabrufs, bleibt bis Phase 5 leer
Aktueller Saldo – gebuchte Umsätze bis heute
Erwarteter Saldo – einschließlich künftig datierter Buchungen

Solange es keine Buchungen gibt (bis Phase 2), entsprechen alle drei dem Anfangssaldo. Die Werte entstehen zentral in Konto::mitSalden(); dort kommen in Phase 2 die Buchungen dazu, ohne dass die Aufrufer sich ändern.

Fett gedruckt steht ein Konto, in dem Buchungen aus dem laufenden Jahr ohne Kategorie liegen (Buchung::unkategorisierteJeKonto(), Zahl im Titel des Kontonamens). Gezählt wird wie im Cockpit: keine Kategorie, kein Gegenkonto, nicht gesplittet – eine Umbuchung und eine Splitbuchung sind zugeordnet. Das ist vor allem die Gegenprobe zum Online-Banking, das abgerufene Umsätze selbst bucht (siehe docs/banking.md).

Anfangssalden stehen nicht im QIF-Export. Sie werden nach dem Import je Konto im Kontoformular nachgetragen.

Kategorien

Hierarchisch, Trenner ist : wie im FinanzManager. name hält den Blattnamen, pfad den vollständigen Namen (400 - Leben:B-Essen alleine). Der Pfad steht redundant in der Tabelle, weil praktisch jede Anzeige, jede Auswahl und der gesamte Import darüber laufen; Umbenennen und Verschieben schreiben die Pfade des ganzen Teilbaums neu (Kategorie::pfadeNeuAufbauen()).

Regeln:

Die Art (Einnahme/Ausgabe) gilt für den ganzen Ast. Unterkategorien erben sie, und ein Wechsel an der Wurzel zieht alle Nachfahren mit.
Ein Name darf keinen Doppelpunkt enthalten – der trennt die Ebenen.
Eine Kategorie kann nicht unter ihren eigenen Teilbaum verschoben werden.
Zusammenführen hängt die Unterkategorien der Quelle unter das Ziel und löscht die Quelle. Ab Phase 2 wandern dort auch die Buchungen mit.
Löschen nimmt die Unterkategorien mit (ON DELETE CASCADE). Wer eine Kategorie nur aus den Auswahllisten nehmen will, setzt sie auf inaktiv.

Die Oberfläche hat die vier Register des Originals: Alle, Einnahmen, Ausgaben, Umbuchungskonten. Umbuchungskonten sind keine Datensätze – dort stehen die Konten, weil sie in der Kategorieauswahl einer Buchung an derselben Stelle erscheinen (in eckigen Klammern).

Klassen

Flach, ohne Hierarchie – die zweite Auswertungsdimension neben der Kategorie (Ehemann, Ehefrau, Haus 1, Projekt …). Im QIF hängen sie mit / an der Kategorie: 400 - Leben:B-Essen alleine/Privat. Kategorie::zerlegeQifAngabe() trennt beides.

Mandantenfähigkeit

Alle Stammdatentabellen führen benutzer_id. Die Oberfläche ist einbenutzerig; die Kennung liefert Mandant::id() – aus der Session, im CLI ersatzweise der erste aktive Benutzer. Mandant::setze() gibt sie in Skripten und Tests fest vor.

4.4 KiB Raw Blame History Unescape Escape