Demo-Fall enthält keine Buchungen #22

New Issue

2026-08-23T16:55:10Z

florian.wilde commented

2026-08-23 16:55:10 +00:00

Problem

prisma/seed.ts legt Konten mit Kontoständen an, aber keine einzige
Buchung. Damit lassen sich am Demo-Fall genau die Funktionen nicht
ausprobieren, die zuletzt dazugekommen sind:

Kassenbuch und Belegpflicht
Erkennung wiederkehrender Zahlungen (Issue #3)
Dauerzahlungen als Beleg zum Vertrag (Issue #11)

Wer die Anwendung zum ersten Mal ansieht, muss erst eine CSV importieren,
bevor die halbe Finanzseite etwas zeigt.

Was ich will

Ein Jahr plausibler Buchungen auf dem Girokonto der Demo-Person, das die
vorhandenen Verträge und Leistungen widerspiegelt:

Monatliche Lastschriften zu den angelegten Versicherungen — mit
leicht schwankender Schreibweise der Gegenstelle, damit die
Zusammenfassung etwas zu tun hat
Heimkosten, Rente, Pflegekasse als regelmäßige Posten
Eine Handvoll Einzelbuchungen mit und ohne Beleg, damit „Beleg fehlt"
und „begründet fehlend" beide vorkommen
Eine abweichende Zahlung zu einem Vertrag, damit die Prüfung aus
Issue #11 sichtbar wird

Akzeptanzkriterien

Nach npm run db:seed zeigt das Kassenbuch Buchungen über
mindestens zwölf Monate
Die Erkennung wiederkehrender Zahlungen findet mindestens zwei
Gruppen
Mindestens eine Buchung ist ohne Beleg und ohne Begründung, damit
der Hinweis erscheint
Die Kontostände passen zur Summe der Buchungen — sonst widerspricht
sich der Demo-Fall selbst

Hinweis

Reine Seed-Änderung, keine Migration.

Angelegt auf Zuruf im Chat, nicht aus dem Dashboard — bitte in Nebula
nachtragen.

## Problem `prisma/seed.ts` legt Konten mit Kontoständen an, aber keine einzige Buchung. Damit lassen sich am Demo-Fall genau die Funktionen nicht ausprobieren, die zuletzt dazugekommen sind: - Kassenbuch und Belegpflicht - Erkennung wiederkehrender Zahlungen (Issue #3) - Dauerzahlungen als Beleg zum Vertrag (Issue #11) Wer die Anwendung zum ersten Mal ansieht, muss erst eine CSV importieren, bevor die halbe Finanzseite etwas zeigt. ## Was ich will Ein Jahr plausibler Buchungen auf dem Girokonto der Demo-Person, das die vorhandenen Verträge und Leistungen widerspiegelt: - Monatliche Lastschriften zu den angelegten Versicherungen — mit leicht schwankender Schreibweise der Gegenstelle, damit die Zusammenfassung etwas zu tun hat - Heimkosten, Rente, Pflegekasse als regelmäßige Posten - Eine Handvoll Einzelbuchungen mit und ohne Beleg, damit „Beleg fehlt" und „begründet fehlend" beide vorkommen - Eine abweichende Zahlung zu einem Vertrag, damit die Prüfung aus Issue #11 sichtbar wird ## Akzeptanzkriterien - [ ] Nach `npm run db:seed` zeigt das Kassenbuch Buchungen über mindestens zwölf Monate - [ ] Die Erkennung wiederkehrender Zahlungen findet mindestens zwei Gruppen - [ ] Mindestens eine Buchung ist ohne Beleg und ohne Begründung, damit der Hinweis erscheint - [ ] Die Kontostände passen zur Summe der Buchungen — sonst widerspricht sich der Demo-Fall selbst ## Hinweis Reine Seed-Änderung, keine Migration. _Angelegt auf Zuruf im Chat, nicht aus dem Dashboard — bitte in Nebula nachtragen._

florian.wilde added the in-arbeit label 2026-08-23 18:31:46 +00:00

florian.wilde started working 2026-08-23 18:32:08 +00:00

florian.wilde commented

2026-08-23 18:33:24 +00:00

🤖 Claude Code hat mit der Umsetzung begonnen.

Branch: feat/22-demo-buchungen
Verstanden als: Der Demo-Fall braucht ein Jahr plausibler Kontobewegungen, damit Kassenbuch, Belegpflicht, Dauerzahlungen und die Erkennung wiederkehrender Zahlungen überhaupt etwas zu zeigen haben.
Geplantes Vorgehen:
- Zwölf Monate auf dem Girokonto, erzeugt aus einem Muster statt einzeln abgetippt: Rente, Betriebsrente und Pflegekasse als Einnahmen, Heimkosten, Barbetrag, Sterbegeldbeitrag, Telefon und Kontoführung als Ausgaben. Dazu Quartals- und Einzelposten.
- Die Gegenstelle bekommt bewusst schwankende Schreibweisen, sonst hat die Zusammenfassung nichts zu tun.
- Für #11: Die Sterbegeld-Lastschriften bleiben unzugeordnet, damit man die Zuordnung selbst ausprobieren kann — mit einer abweichenden Zahlung, an der die Prüfung sichtbar wird.
- Für die Belegpflicht: eine Buchung ohne Beleg und ohne Begründung, eine mit Begründung, eine mit Beleg.
- Zum Kontostand: Statt eine Zahl hinzuschreiben und zu hoffen, dass sie passt, wird der spätere Saldostand aus dem früheren plus der Summe der Buchungen berechnet. Ein Demo-Fall, der sich selbst widerspricht, wäre schlimmer als einer ohne Buchungen.

Zeiterfassung läuft.

🤖 **Claude Code hat mit der Umsetzung begonnen.** - Branch: `feat/22-demo-buchungen` - Verstanden als: Der Demo-Fall braucht ein Jahr plausibler Kontobewegungen, damit Kassenbuch, Belegpflicht, Dauerzahlungen und die Erkennung wiederkehrender Zahlungen überhaupt etwas zu zeigen haben. - Geplantes Vorgehen: - Zwölf Monate auf dem Girokonto, erzeugt aus einem Muster statt einzeln abgetippt: Rente, Betriebsrente und Pflegekasse als Einnahmen, Heimkosten, Barbetrag, Sterbegeldbeitrag, Telefon und Kontoführung als Ausgaben. Dazu Quartals- und Einzelposten. - Die Gegenstelle bekommt bewusst schwankende Schreibweisen, sonst hat die Zusammenfassung nichts zu tun. - Für #11: Die Sterbegeld-Lastschriften bleiben **unzugeordnet**, damit man die Zuordnung selbst ausprobieren kann — mit einer abweichenden Zahlung, an der die Prüfung sichtbar wird. - Für die Belegpflicht: eine Buchung ohne Beleg und ohne Begründung, eine mit Begründung, eine mit Beleg. - **Zum Kontostand:** Statt eine Zahl hinzuschreiben und zu hoffen, dass sie passt, wird der spätere Saldostand aus dem früheren plus der Summe der Buchungen berechnet. Ein Demo-Fall, der sich selbst widerspricht, wäre schlimmer als einer ohne Buchungen. Zeiterfassung läuft.

florian.wilde worked for 1 hour 3 minutes

2026-08-23 19:35:56 +00:00

florian.wilde referenced this issue from a commit

2026-08-23 19:36:20 +00:00

Ein Jahr Kontobewegungen im Beispielfall

florian.wilde referenced a pull request that will close this issue

2026-08-23 19:36:37 +00:00

Feat #22: Ein Jahr Kontobewegungen im Beispielfall #33

florian.wilde closed this issue

2026-08-23 19:36:50 +00:00

florian.wilde referenced this issue from a commit

2026-08-23 19:36:51 +00:00

Merge #33: Ein Jahr Kontobewegungen im Beispielfall

florian.wilde commented

2026-08-23 19:37:50 +00:00

🚀 Umgesetzt und nach main übernommen.

Merge-Commit: 91592cb
Pull Request: #33 (gemergt)
Fassung: v1.10.1 (getaggt, Release angelegt)
Gesamtaufwand: 01:04

Was geändert wurde

107 Buchungen über zwölf Monate im Beispielfall, erzeugt aus einem Muster statt einzeln abgetippt: Rente, Betriebsrente und Pflegekasse als Einnahmen, Heimentgelt, Barbetrag, Sterbegeldbeitrag, Telefon und Kontoführung monatlich, dazu Rundfunkbeitrag und Grundsteuer vierteljährlich sowie Einzelposten.

Betrifft nur SEED_DEMO=true — an einem bestehenden Bestand ändert sich nichts.

Zwei Funde beim Bauen

Der Unique-Index auf (kontoId, importReferenz) hat einen echten Fehler in meinen Daten gefangen: Zwei Renten am Monatsersten ergaben dieselbe Referenz. Genau dafür ist er da.
gGmbH fehlte in der Rechtsformliste beim Zusammenfassen wiederkehrender Zahlungen. Dadurch galten „Seniorenzentrum St. Katharina" und „… gGmbH" als zwei Empfänger — die Gruppe zerfiel ausgerechnet in dem Fachgebiet, in dem fast jeder Träger eine gGmbH ist. Ergänzt, mit Test.

Eine Annahme von mir, die die Anwendung widerlegt hat: Ich hatte erwartet, dass die Sterbekasse gar nicht unter den wiederkehrenden Zahlungen auftaucht, weil ein Vertrag existiert. Tatsächlich führt die Seite sie in einem eigenen Abschnitt „Schon einem Vertrag zugeordnet" mit dem Angebot, alle zwölf Zahlungen zuzuordnen. Mein Test war falsch, nicht die Anwendung.

So prüfst du es

git switch main && git pull
Beispielfall neu einspielen — er wird nicht überschrieben, solange er existiert:
```
# in der Entwicklungsdatenbank
SEED_DEMO=true npx tsx prisma/seed.ts
```
Meldet er „Demofall besteht bereits", muss die betreute Person „Erika Musterfrau" vorher gelöscht werden.
Vermögen & Kasse → Buchungen: rund 107 Einträge über zwölf Monate. Genau einer („Modehaus Lindner", 89,95 €) ist ohne Beleg und ohne Begründung markiert.
Wiederkehrende Zahlungen: sechs Gruppen ohne Vertrag. Beim Heimentgelt steht „3 Schreibweisen zusammengefasst".
Weiter unten der Abschnitt Schon einem Vertrag zugeordnet mit der Sterbekasse und dem Knopf „12 Zahlungen als belegt zuordnen".
Vermögensverzeichnis zum 31.07.2026: Der Kontostand passt zur Summe der Buchungen ab dem 14.02.2026 — nachrechenbar.

Geprüft: 655 Unit-Tests, 133 End-to-End-Tests, Typecheck und Lint sauber.

Ohne Freigabeschritt gemergt — auf ausdrücklichen Zuruf im Chat für die Reihe #21–#28.

🚀 **Umgesetzt und nach `main` übernommen.**  - Merge-Commit: `91592cb` - Pull Request: #33 (gemergt) - Fassung: **v1.10.1** (getaggt, [Release angelegt](https://git.wilde-server.de/florian.wilde/betreuungs-cockpit/releases/tag/v1.10.1)) - Gesamtaufwand: 01:04 **Was geändert wurde** 107 Buchungen über zwölf Monate im Beispielfall, erzeugt aus einem Muster statt einzeln abgetippt: Rente, Betriebsrente und Pflegekasse als Einnahmen, Heimentgelt, Barbetrag, Sterbegeldbeitrag, Telefon und Kontoführung monatlich, dazu Rundfunkbeitrag und Grundsteuer vierteljährlich sowie Einzelposten. Betrifft nur `SEED_DEMO=true` — an einem bestehenden Bestand ändert sich nichts. **Zwei Funde beim Bauen** 1. Der Unique-Index auf `(kontoId, importReferenz)` hat einen echten Fehler in meinen Daten gefangen: Zwei Renten am Monatsersten ergaben dieselbe Referenz. Genau dafür ist er da. 2. **`gGmbH` fehlte in der Rechtsformliste** beim Zusammenfassen wiederkehrender Zahlungen. Dadurch galten „Seniorenzentrum St. Katharina" und „… gGmbH" als zwei Empfänger — die Gruppe zerfiel ausgerechnet in dem Fachgebiet, in dem fast jeder Träger eine gGmbH ist. Ergänzt, mit Test. **Eine Annahme von mir, die die Anwendung widerlegt hat:** Ich hatte erwartet, dass die Sterbekasse gar nicht unter den wiederkehrenden Zahlungen auftaucht, weil ein Vertrag existiert. Tatsächlich führt die Seite sie in einem eigenen Abschnitt *„Schon einem Vertrag zugeordnet"* mit dem Angebot, alle zwölf Zahlungen zuzuordnen. Mein Test war falsch, nicht die Anwendung. **So prüfst du es** 1. `git switch main && git pull` 2. Beispielfall neu einspielen — er wird nicht überschrieben, solange er existiert: ``` # in der Entwicklungsdatenbank SEED_DEMO=true npx tsx prisma/seed.ts ``` Meldet er „Demofall besteht bereits", muss die betreute Person „Erika Musterfrau" vorher gelöscht werden. 3. **Vermögen & Kasse → Buchungen**: rund 107 Einträge über zwölf Monate. Genau einer („Modehaus Lindner", 89,95 €) ist ohne Beleg und ohne Begründung markiert. 4. **Wiederkehrende Zahlungen**: sechs Gruppen ohne Vertrag. Beim Heimentgelt steht „3 Schreibweisen zusammengefasst". 5. Weiter unten der Abschnitt *Schon einem Vertrag zugeordnet* mit der Sterbekasse und dem Knopf „12 Zahlungen als belegt zuordnen". 6. **Vermögensverzeichnis** zum 31.07.2026: Der Kontostand passt zur Summe der Buchungen ab dem 14.02.2026 — nachrechenbar. **Geprüft:** 655 Unit-Tests, 133 End-to-End-Tests, Typecheck und Lint sauber. Ohne Freigabeschritt gemergt — auf ausdrücklichen Zuruf im Chat für die Reihe #21–#28.

florian.wilde removed the in-arbeit label 2026-08-23 19:37:57 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Total Time Spent: 1 hour 3 minutes

florian.wilde

1 hour 3 minutes

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: florian.wilde/betreuungs-cockpit#22