Feat #11: Dauerzahlungen zu einem Vertrag gelten als belegt #14

2026-08-23T07:01:31Z

florian.wilde commented

2026-08-23 07:01:31 +00:00

Was es tut

Eine Buchung lässt sich einem Vertrag zuordnen, und diese Zuordnung zählt als Nachweis. Bei einem Dauerschuldverhältnis ist der Vertrag der Beleg — ein Rechtspfleger will für zwölf gleiche Lastschriften keine zwölf Quittungen sehen, sondern die Police.

Die Belegquote weist jetzt drei Fälle getrennt aus: mit Beleg, durch Vertrag belegt, begründet ohne Beleg.

Dazu:

Automatisch beim Import, wenn die Gegenstelle zu genau einem Vertrag passt. Bei Mehrdeutigkeit geschieht nichts — Hausrat und Haftpflicht bei derselben Gesellschaft lassen sich nicht auseinanderhalten, und eine falsche Zuordnung wäre schlimmer als gar keine.
Sammelzuordnung über die Gruppen aus #3. Bei drei Jahren Laufzeit sind das 36 Buchungen mit einem Klick.
Die Rechnungslegung nennt den Vertrag samt Nummer, statt „ohne Beleg".

Die Sicherung — und wie mein erster Entwurf daran scheiterte

Weicht der Betrag um mehr als ein Fünftel vom hinterlegten Beitrag ab, fällt die Anerkennung weg und die Buchung wird als Betrag prüfen markiert.

Mein erster Entwurf verglich großzügiger: Jahresbetrag bilden und gegen jährlich, halbjährlich, vierteljährlich und monatlich prüfen, damit es auch passt, wenn die Bank anders abbucht als der Vertrag es führt.

Der eigene Test hat das widerlegt. Bei einem Monatsbeitrag von 42,50 € liegen 420 € innerhalb von 20 % des Jahresbetrags von 510 € — ausgerechnet der Fall aus der Aufgabenstellung wäre durchgerutscht. Das Toleranzband hatte vier Löcher.

Jetzt wird stur gegen den hinterlegten Beitrag verglichen. Bucht die Bank anders ab, stimmen die Vertragsdaten nicht, und das soll auffallen — die Zahlweise zu berichtigen dauert zehn Sekunden und macht die Akte richtiger.

Steht am Vertrag kein Beitrag, findet keine Prüfung statt. Die Zuordnung gilt trotzdem; es wird nur nicht so getan, als wäre geprüft worden.

Und: Verschwindet der Vertrag, fällt die Buchung zurück in „Beleg fehlt". Ein Nachweis, der auf etwas zeigt, das es nicht mehr gibt, wäre schlimmer als gar keiner.

Behoben — gefunden vom Browsertest

Die Buchungsliste hatte eine eigene, fast gleiche Datenabfrage neben der aus berichte/gemeinsam.ts. Als die Dauerzahlungen dazukamen, wurde nur eine von beiden nachgezogen: In der Liste stand weiter „Beleg fehlt", obwohl der Vertrag hinterlegt war. Typprüfung grün, Einheitstests grün.

Beide benutzen jetzt BUCHUNG_EINBEZUG und zuBuchungEingabe — das kann nicht mehr halb vergessen werden.

Zum Bündeln mit `Buchung.immobilieId`

Im Issue steht der Hinweis, die Migration mit dem Immobilien-Feld aus Roadmap 1.1 zu bündeln. Das habe ich nicht getan. Zu immobilieId gibt es kein Issue, und ein Feld einzubauen, das keine Logik hat und in keiner Oberfläche vorkommt, wäre schlechter als eine zweite Migration — es sähe fertig aus und wäre es nicht.

Geprüft

23 neue Einheitstests. Etwa die Hälfte prüft, dass die Anerkennung auch wirklich wegfällt — der gefährliche Fehler wäre hier ein zu mildes Urteil, nicht ein zu strenges.
Fünf End-to-End-Tests auf beiden Geräteprofilen: Sammelzuordnung, Anzeige in der Liste, abweichende Zahlung, Kachel auf „Heute", Rückfall nach dem Löschen des Vertrags.
560 Unit-Tests, 63 e2e, 0 Typfehler, Lint sauber, Produktionsbau steht.

Nebenbei

Die Roadmap trug noch „Aktuelle Fassung 1.1.2" — Nachwirkung der parallelen Bearbeitung von #3 und #10. Nachgezogen, wie im Kommentar zu #10 zugesagt.

Version auf 1.3.0 angehoben. Eine Migration läuft mit (20260823062000_buchung_vertragszahlung), sie fügt zwei Spalten hinzu und ändert nichts an vorhandenen Daten.

Closes #11

## Was es tut Eine Buchung lässt sich einem **Vertrag** zuordnen, und diese Zuordnung zählt als Nachweis. Bei einem Dauerschuldverhältnis ist der Vertrag der Beleg — ein Rechtspfleger will für zwölf gleiche Lastschriften keine zwölf Quittungen sehen, sondern die Police. Die Belegquote weist jetzt **drei** Fälle getrennt aus: mit Beleg, durch Vertrag belegt, begründet ohne Beleg. Dazu: - **Automatisch beim Import**, wenn die Gegenstelle zu genau *einem* Vertrag passt. Bei Mehrdeutigkeit geschieht nichts — Hausrat und Haftpflicht bei derselben Gesellschaft lassen sich nicht auseinanderhalten, und eine falsche Zuordnung wäre schlimmer als gar keine. - **Sammelzuordnung** über die Gruppen aus #3. Bei drei Jahren Laufzeit sind das 36 Buchungen mit einem Klick. - **Die Rechnungslegung nennt den Vertrag** samt Nummer, statt „ohne Beleg". ## Die Sicherung — und wie mein erster Entwurf daran scheiterte Weicht der Betrag um mehr als ein Fünftel vom hinterlegten Beitrag ab, fällt die Anerkennung weg und die Buchung wird als *Betrag prüfen* markiert. Mein erster Entwurf verglich großzügiger: Jahresbetrag bilden und gegen jährlich, halbjährlich, vierteljährlich und monatlich prüfen, damit es auch passt, wenn die Bank anders abbucht als der Vertrag es führt. **Der eigene Test hat das widerlegt.** Bei einem Monatsbeitrag von 42,50 € liegen 420 € innerhalb von 20 % des Jahresbetrags von 510 € — ausgerechnet der Fall aus der Aufgabenstellung wäre durchgerutscht. Das Toleranzband hatte vier Löcher. Jetzt wird stur gegen den hinterlegten Beitrag verglichen. Bucht die Bank anders ab, stimmen die Vertragsdaten nicht, und das soll auffallen — die Zahlweise zu berichtigen dauert zehn Sekunden und macht die Akte richtiger. Steht am Vertrag **kein** Beitrag, findet keine Prüfung statt. Die Zuordnung gilt trotzdem; es wird nur nicht so getan, als wäre geprüft worden. Und: **Verschwindet der Vertrag, fällt die Buchung zurück in „Beleg fehlt".** Ein Nachweis, der auf etwas zeigt, das es nicht mehr gibt, wäre schlimmer als gar keiner. ## Behoben — gefunden vom Browsertest Die Buchungsliste hatte eine **eigene, fast gleiche Datenabfrage** neben der aus `berichte/gemeinsam.ts`. Als die Dauerzahlungen dazukamen, wurde nur eine von beiden nachgezogen: In der Liste stand weiter „Beleg fehlt", obwohl der Vertrag hinterlegt war. Typprüfung grün, Einheitstests grün. Beide benutzen jetzt `BUCHUNG_EINBEZUG` und `zuBuchungEingabe` — das kann nicht mehr halb vergessen werden. ## Zum Bündeln mit `Buchung.immobilieId` Im Issue steht der Hinweis, die Migration mit dem Immobilien-Feld aus Roadmap 1.1 zu bündeln. **Das habe ich nicht getan.** Zu `immobilieId` gibt es kein Issue, und ein Feld einzubauen, das keine Logik hat und in keiner Oberfläche vorkommt, wäre schlechter als eine zweite Migration — es sähe fertig aus und wäre es nicht. ## Geprüft - **23 neue Einheitstests.** Etwa die Hälfte prüft, dass die Anerkennung auch wirklich *wegfällt* — der gefährliche Fehler wäre hier ein zu mildes Urteil, nicht ein zu strenges. - **Fünf End-to-End-Tests** auf beiden Geräteprofilen: Sammelzuordnung, Anzeige in der Liste, abweichende Zahlung, Kachel auf „Heute", Rückfall nach dem Löschen des Vertrags. - 560 Unit-Tests, 63 e2e, 0 Typfehler, Lint sauber, Produktionsbau steht. ## Nebenbei Die Roadmap trug noch „Aktuelle Fassung 1.1.2" — Nachwirkung der parallelen Bearbeitung von #3 und #10. Nachgezogen, wie im Kommentar zu #10 zugesagt. Version auf **1.3.0** angehoben. Eine Migration läuft mit (`20260823062000_buchung_vertragszahlung`), sie fügt zwei Spalten hinzu und ändert nichts an vorhandenen Daten. Closes #11

florian.wilde added 1 commit 2026-08-23 07:01:31 +00:00

Dauerzahlungen zu einem Vertrag gelten als belegt fa994350d6

Bei einer monatlichen Praemie gibt es keinen Beleg - es gibt einen
Vertrag, und der wird einmal abgeschlossen, nicht monatlich quittiert.
Bisher blieb nur ein Freitextfeld pro Buchung: zwoelfmal im Jahr
derselbe Satz, mal Anzahl der Vertraege.

Buchung.vertragId mit onDelete: SetNull. Der Belegzustand kennt jetzt
drei Faelle statt zwei, getrennt ausgewiesen - ein Vertrag belegt, eine
Begruendung erklaert nur; zusammengeworfen verliert die Belegquote ihre
Aussage gegenueber dem Rechtspfleger.

Dazu: automatische Zuordnung beim Import bei eindeutiger Gegenstelle,
Sammelzuordnung ueber die Gruppen aus Issue #3, und die Rechnungslegung
nennt den Vertrag samt Nummer statt "ohne Beleg".

Die Sicherung dagegen: Weicht der Betrag um mehr als ein Fuenftel vom
hinterlegten Beitrag ab, faellt die Anerkennung weg und die Buchung wird
als "Betrag pruefen" markiert. Sonst waere die Zuordnung eine Hintertuer.

Zur Toleranz - ein Entwurf und seine Korrektur: Zuerst verglich ich den
Betrag gegen alle ueblichen Zahlweisen, damit es auch passt, wenn die
Bank anders abbucht als der Vertrag es fuehrt. Der eigene Test hat das
widerlegt: Bei 42,50 monatlich liegen 420 innerhalb von 20 Prozent des
Jahresbetrags von 510 - ausgerechnet der Fall aus der Aufgabenstellung
waere durchgerutscht. Jetzt wird stur gegen den hinterlegten Beitrag
verglichen. Bucht die Bank anders ab, stimmen die Vertragsdaten nicht,
und das soll auffallen.

Behoben: Die Buchungsliste hatte eine eigene, fast gleiche Datenabfrage
neben der aus berichte/gemeinsam.ts. Nur eine von beiden wurde
nachgezogen, in der Liste stand weiter "Beleg fehlt". Beide benutzen
jetzt BUCHUNG_EINBEZUG und zuBuchungEingabe - das kann nicht halb
vergessen werden. Gefunden hat es der Browsertest.

Nebenbei: Die Roadmap trug noch "Aktuelle Fassung 1.1.2" - Nachwirkung
der parallelen Bearbeitung von #3 und #10. Nachgezogen wie zugesagt.

Geprueft: 23 neue Einheitstests, die Haelfte davon darauf gerichtet, dass
die Anerkennung auch wirklich wegfaellt. Fuenf End-to-End-Tests auf
beiden Geraeteprofilen. 560 Unit-Tests, 63 e2e, null Typfehler.

Refs #11

florian.wilde referenced this pull request

2026-08-23 07:02:14 +00:00

Dauerzahlungen zu einem Vertrag gelten als belegt #11

florian.wilde merged commit de21f1c320 into main

2026-08-23 07:06:26 +00:00

florian.wilde referenced this pull request

2026-08-23 07:07:06 +00:00

Dauerzahlungen zu einem Vertrag gelten als belegt #11

Sign in to join this conversation.