florian.wilde/betreuungs-cockpit
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 22 Wiki Activity

Dauerzahlungen zu einem Vertrag gelten als belegt #11

New Issue
Closed
opened 2026-08-22 23:37:20 +00:00 by florian.wilde · 3 comments
florian.wilde commented 2026-08-22 23:37:20 +00:00
Owner
Copy Link
Copy Source

Problem

Aus dem Kontoauszug importierte Buchungen haben keinen Beleg. Bei einer
monatlichen Versicherungsprämie gibt es auch keinen — es gibt einen
Vertrag, und der wird einmal abgeschlossen, nicht monatlich quittiert.

Heute bleibt nur belegFehltBegruendung, ein Freitextfeld pro Buchung.
Für eine Prämie heißt das zwölfmal im Jahr denselben Satz tippen, mal
Anzahl der Verträge. Wer das nicht macht, hat die Zeilen dauerhaft als
„Beleg fehlt" markiert und eine Belegquote, die schlechter aussieht als die
Aktenlage ist.

Beides ist unbefriedigend: Die Arbeit ist stumpf, und das Ergebnis ist
schwächer als die Wahrheit. 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. Ein handgetippter Satz
„regelmäßige Zahlung" belegt dagegen gar nichts — er behauptet nur.

Was ich will

Eine Buchung lässt sich einem Vertrag zuordnen. Diese Zuordnung gilt
als Nachweis: Die Buchung zählt nicht mehr als „Beleg fehlt" und nicht als
„begründet fehlend", sondern als eigene, dritte Kategorie —
durch Vertrag belegt.

Damit das die Arbeit auch wirklich spart:

  • Beim CSV- und CAMT-Import wird automatisch zugeordnet, wenn die
    Gegenstelle eindeutig zu genau einem Vertrag passt
  • Die Zuordnung lässt sich für eine ganze Reihe gleichartiger Buchungen auf
    einmal setzen, nicht nur einzeln

Zwei Sicherungen, die dazugehören

Das darf keine Hintertür werden, mit der sich alles als beleglos abhaken
lässt.

1. Betragsabweichung hebt die Anerkennung auf. Weicht die Zahlung
deutlich vom hinterlegten Beitrag ab, gilt sie nicht automatisch als
belegt, sondern wird zur Prüfung markiert. Eine Prämie, die von 42 € auf
420 € springt, will man sehen — und eine Beitragsanpassung gehört am
Vertrag nachgetragen, nicht stillschweigend geschluckt.

2. Die Rechnungslegung nennt den Vertrag. Statt „ohne Beleg – …" steht
dort „Dauerzahlung zu Vertrag «Bezeichnung», Vertragsnummer …". Die Lücke
wird nicht versteckt, sie wird erklärt. Wer nachprüfen will, weiß sofort,
welches Papier er aus dem Ordner holen muss.

Akzeptanzkriterien

  • Eine Buchung lässt sich einem Vertrag zuordnen; die Zuordnung ist in
    der Buchungsliste sichtbar
  • Eine so zugeordnete Buchung zählt in der Belegquote als nachgewiesen
    und erscheint nicht mehr auf „Heute" unter „Unverbuchte Belege"
  • Die Belegquote weist die drei Fälle getrennt aus: mit Beleg,
    durch Vertrag belegt, begründet ohne Beleg. Nicht zusammengeworfen —
    sonst verliert die Zahl ihre Aussage
  • Weicht der Betrag deutlich vom hinterlegten Beitrag ab, gilt die
    Buchung nicht automatisch als belegt, sondern wird zur Prüfung
    markiert. Die Toleranz ist nachvollziehbar dokumentiert
  • Ist am Vertrag kein Beitrag hinterlegt, findet keine Prüfung statt —
    die Zuordnung gilt trotzdem, aber es wird nicht so getan, als wäre
    geprüft worden
  • Beim Import werden Buchungen automatisch zugeordnet, wenn die
    Gegenstelle eindeutig zu genau einem Vertrag passt; bei Mehrdeutigkeit
    geschieht nichts
  • Automatisch gesetzte Zuordnungen sind als solche erkennbar und
    lassen sich einzeln aufheben
  • Mehrere gleichartige Buchungen lassen sich in einem Schritt zuordnen
  • Die Rechnungslegung weist die Zahlung als Dauerzahlung zum Vertrag
    aus, mit Bezeichnung und Vertragsnummer
  • Wird ein Vertrag gelöscht, verlieren die Buchungen die Zuordnung und
    fallen zurück in „Beleg fehlt" — kein stiller Nachweis auf etwas,
    das es nicht mehr gibt

Hinweise zur Umsetzung

  • Buchung hat heute belegId und belegFehltBegruendung; die Logik
    liegt in src/lib/finanzen/kassenbuch.ts (belegFehlt,
    belegBegruendet, belegquote)
  • Die Dashboard-Kachel fragt in src/lib/dashboard/laden.ts auf
    belegId: null, belegFehltBegruendung: null ab
  • Die Ausgabe steht in src/lib/berichte/rechnungslegung.tsx
  • Migration nötig: Buchung.vertragId mit Index

Zusammenhang

  • Bündeln mit „Buchung.immobilieId" aus Roadmap 1.1. Das ist dieselbe
    Art von Feld an derselben Tabelle; zwei Migrationen dafür wären
    Verschwendung.
  • Ergänzt „Verträge aufspüren: wiederkehrende Zahlungen ohne hinterlegten
    Vertrag": Dort entstehen die Verträge, hier werden die Zahlungen daran
    gehängt. Zusammen wird aus einer Liste unerklärter Abbuchungen eine
    saubere Rechnungslegung.

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

## Problem Aus dem Kontoauszug importierte Buchungen haben keinen Beleg. Bei einer monatlichen Versicherungsprämie gibt es auch keinen — es gibt einen Vertrag, und der wird einmal abgeschlossen, nicht monatlich quittiert. Heute bleibt nur `belegFehltBegruendung`, ein Freitextfeld **pro Buchung**. Für eine Prämie heißt das zwölfmal im Jahr denselben Satz tippen, mal Anzahl der Verträge. Wer das nicht macht, hat die Zeilen dauerhaft als „Beleg fehlt" markiert und eine Belegquote, die schlechter aussieht als die Aktenlage ist. Beides ist unbefriedigend: Die Arbeit ist stumpf, und das Ergebnis ist schwächer als die Wahrheit. **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. Ein handgetippter Satz „regelmäßige Zahlung" belegt dagegen gar nichts — er behauptet nur. ## Was ich will Eine Buchung lässt sich einem **Vertrag** zuordnen. Diese Zuordnung gilt als Nachweis: Die Buchung zählt nicht mehr als „Beleg fehlt" und nicht als „begründet fehlend", sondern als eigene, dritte Kategorie — **durch Vertrag belegt**. Damit das die Arbeit auch wirklich spart: - Beim CSV- und CAMT-Import wird automatisch zugeordnet, wenn die Gegenstelle eindeutig zu genau einem Vertrag passt - Die Zuordnung lässt sich für eine ganze Reihe gleichartiger Buchungen auf einmal setzen, nicht nur einzeln ## Zwei Sicherungen, die dazugehören Das darf keine Hintertür werden, mit der sich alles als beleglos abhaken lässt. **1. Betragsabweichung hebt die Anerkennung auf.** Weicht die Zahlung deutlich vom hinterlegten Beitrag ab, gilt sie nicht automatisch als belegt, sondern wird zur Prüfung markiert. Eine Prämie, die von 42 € auf 420 € springt, will man sehen — und eine Beitragsanpassung gehört am Vertrag nachgetragen, nicht stillschweigend geschluckt. **2. Die Rechnungslegung nennt den Vertrag.** Statt „ohne Beleg – …" steht dort „Dauerzahlung zu Vertrag «Bezeichnung», Vertragsnummer …". Die Lücke wird nicht versteckt, sie wird erklärt. Wer nachprüfen will, weiß sofort, welches Papier er aus dem Ordner holen muss. ## Akzeptanzkriterien - [ ] Eine Buchung lässt sich einem Vertrag zuordnen; die Zuordnung ist in der Buchungsliste sichtbar - [ ] Eine so zugeordnete Buchung zählt in der Belegquote als nachgewiesen und erscheint nicht mehr auf „Heute" unter „Unverbuchte Belege" - [ ] Die Belegquote weist die drei Fälle **getrennt** aus: mit Beleg, durch Vertrag belegt, begründet ohne Beleg. Nicht zusammengeworfen — sonst verliert die Zahl ihre Aussage - [ ] Weicht der Betrag deutlich vom hinterlegten Beitrag ab, gilt die Buchung nicht automatisch als belegt, sondern wird zur Prüfung markiert. Die Toleranz ist nachvollziehbar dokumentiert - [ ] Ist am Vertrag kein Beitrag hinterlegt, findet keine Prüfung statt — die Zuordnung gilt trotzdem, aber es wird nicht so getan, als wäre geprüft worden - [ ] Beim Import werden Buchungen automatisch zugeordnet, wenn die Gegenstelle eindeutig zu genau einem Vertrag passt; bei Mehrdeutigkeit geschieht nichts - [ ] Automatisch gesetzte Zuordnungen sind als solche erkennbar und lassen sich einzeln aufheben - [ ] Mehrere gleichartige Buchungen lassen sich in einem Schritt zuordnen - [ ] Die Rechnungslegung weist die Zahlung als Dauerzahlung zum Vertrag aus, mit Bezeichnung und Vertragsnummer - [ ] Wird ein Vertrag gelöscht, verlieren die Buchungen die Zuordnung und fallen zurück in „Beleg fehlt" — kein stiller Nachweis auf etwas, das es nicht mehr gibt ## Hinweise zur Umsetzung - `Buchung` hat heute `belegId` und `belegFehltBegruendung`; die Logik liegt in `src/lib/finanzen/kassenbuch.ts` (`belegFehlt`, `belegBegruendet`, `belegquote`) - Die Dashboard-Kachel fragt in `src/lib/dashboard/laden.ts` auf `belegId: null, belegFehltBegruendung: null` ab - Die Ausgabe steht in `src/lib/berichte/rechnungslegung.tsx` - Migration nötig: `Buchung.vertragId` mit Index ## Zusammenhang - **Bündeln mit „Buchung.immobilieId"** aus Roadmap 1.1. Das ist dieselbe Art von Feld an derselben Tabelle; zwei Migrationen dafür wären Verschwendung. - Ergänzt „Verträge aufspüren: wiederkehrende Zahlungen ohne hinterlegten Vertrag": Dort entstehen die Verträge, hier werden die Zahlungen daran gehängt. Zusammen wird aus einer Liste unerklärter Abbuchungen eine saubere Rechnungslegung. _Angelegt auf Zuruf im Chat, nicht aus dem Dashboard — bitte in Nebula nachtragen._
florian.wilde added the in-arbeit label 2026-08-23 06:17:58 +00:00
florian.wilde started working 2026-08-23 06:18:14 +00:00
florian.wilde commented 2026-08-23 06:18:25 +00:00
Author
Owner
Copy Link
Copy Source

🤖 Claude Code hat mit der Umsetzung begonnen.

  • Branch: feat/11-dauerzahlungen-belegt
  • Verstanden als: Bei einem Dauerschuldverhältnis ist der Vertrag der Beleg — eine Buchung, die einem Vertrag zugeordnet ist, zählt als nachgewiesen, ohne dass zwölfmal im Jahr dieselbe Begründung getippt werden muss.
  • Geplantes Vorgehen:
    • Buchung.vertragId als Fremdschlüssel mit onDelete: SetNull
    • Belegzustand in kassenbuch.ts von zwei auf drei Fälle erweitern, getrennt ausgewiesen — als reine Funktionen, mit Einheitstests
    • Betragsprüfung gegen den hinterlegten Beitrag, Toleranz dokumentiert
    • Automatische Zuordnung beim Import bei eindeutiger Gegenstelle, als solche erkennbar
    • Sammelzuordnung, Rechnungslegung, Dashboard-Kachel

Zum Bündeln mit Buchung.immobilieId: Das geht so nicht. 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. Ich lege nur vertragId an. Wenn der Immobilien-Punkt aus Roadmap 1.1 drankommt, kostet ihn seine eigene Migration wenige Sekunden Laufzeit; das ist der geringere Preis.

Zur Toleranz bei der Betragsprüfung: Ich vergleiche die Zahlung mit dem Jahresbeitrag des Vertrags, heruntergerechnet auf die üblichen Zahlweisen (jährlich, halbjährlich, vierteljährlich, monatlich). So passt es auch, wenn der Vertrag monatlich hinterlegt ist, die Bank aber jährlich abbucht. Die genaue Toleranz und ihre Begründung stehen am Ende im Abschlusskommentar.

Zeiterfassung läuft.

🤖 **Claude Code hat mit der Umsetzung begonnen.** - Branch: `feat/11-dauerzahlungen-belegt` - Verstanden als: Bei einem Dauerschuldverhältnis ist der Vertrag der Beleg — eine Buchung, die einem Vertrag zugeordnet ist, zählt als nachgewiesen, ohne dass zwölfmal im Jahr dieselbe Begründung getippt werden muss. - Geplantes Vorgehen: - `Buchung.vertragId` als Fremdschlüssel mit `onDelete: SetNull` - Belegzustand in `kassenbuch.ts` von zwei auf **drei** Fälle erweitern, getrennt ausgewiesen — als reine Funktionen, mit Einheitstests - Betragsprüfung gegen den hinterlegten Beitrag, Toleranz dokumentiert - Automatische Zuordnung beim Import bei eindeutiger Gegenstelle, als solche erkennbar - Sammelzuordnung, Rechnungslegung, Dashboard-Kachel **Zum Bündeln mit `Buchung.immobilieId`:** Das geht so nicht. 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. Ich lege nur `vertragId` an. Wenn der Immobilien-Punkt aus Roadmap 1.1 drankommt, kostet ihn seine eigene Migration wenige Sekunden Laufzeit; das ist der geringere Preis. **Zur Toleranz bei der Betragsprüfung:** Ich vergleiche die Zahlung mit dem Jahresbeitrag des Vertrags, heruntergerechnet auf die üblichen Zahlweisen (jährlich, halbjährlich, vierteljährlich, monatlich). So passt es auch, wenn der Vertrag monatlich hinterlegt ist, die Bank aber jährlich abbucht. Die genaue Toleranz und ihre Begründung stehen am Ende im Abschlusskommentar. Zeiterfassung läuft.
florian.wilde worked for 42 minutes 2026-08-23 07:00:20 +00:00
florian.wilde added zu-testen and removed in-arbeit labels 2026-08-23 07:01:38 +00:00
florian.wilde commented 2026-08-23 07:02:14 +00:00
Author
Owner
Copy Link
Copy Source

✅ Umsetzung abgeschlossen — bereit zum Testen.

Was geändert wurde

  • Buchung.vertragId mit onDelete: SetNull, dazu ein Kennzeichen für automatisch gesetzte Zuordnungen.
  • Der Belegzustand kennt drei Fälle statt zwei, in der Belegquote getrennt ausgewiesen.
  • Zuordnung im Buchungsformular; in der Liste als eigenes Abzeichen sichtbar, automatische Zuordnungen als solche gekennzeichnet.
  • Automatisch beim Import bei eindeutiger Gegenstelle; bei Mehrdeutigkeit geschieht nichts.
  • Sammelzuordnung unter Wiederkehrende Zahlungen: alle Zahlungen einer Gruppe mit einem Klick.
  • Die Rechnungslegung nennt „Dauerzahlung zu Vertrag «Bezeichnung», Nr. …" statt „ohne Beleg".
  • Version 1.3.0; die Roadmap-Versionszeile nachgezogen, wie bei #10 zugesagt.

Geänderte Dateien

  • src/lib/finanzen/kassenbuch.ts, rechnungslegung.ts, wiederkehrend.ts, wiederkehrend-laden.ts
  • src/lib/berichte/gemeinsam.ts, rechnungslegung.tsx, src/lib/dashboard/laden.ts
  • src/server/actions/finanzen.ts, src/lib/validierung/finanzen.ts
  • src/components/finanzen/{bausteine,buchungs-formular,wiederkehrend-aktionen}.tsx
  • vier Seiten unter src/app/(app)/finanzen/
  • tests/dauerzahlung.test.ts (neu), e2e/dauerzahlung.spec.ts (neu), Schema, Migration, Doku

So testest du es

  1. git switch feat/11-dauerzahlungen-belegt und npm run db:deploy
  2. npm run dev. Lege einen Vertrag mit Gesellschaft, Beitrag und Zahlweise an — die Zahlweise ist wichtig, sie ist der Maßstab
  3. Kontoauszug importieren. Passt die Gegenstelle eindeutig zu diesem Vertrag, sind die Buchungen schon zugeordnet und in der Liste als Vertrag (automatisch) gekennzeichnet
  4. Vermögen & Kasse → Wiederkehrende Zahlungen: Unter „Schon einem Vertrag zugeordnet" steht ein Knopf, der die restlichen Zahlungen der Gruppe auf einmal zuordnet
  5. Kassenbuch: Die Zeilen tragen durch Vertrag belegt, nicht mehr Beleg fehlt. Die Belegquote oben steigt entsprechend
  6. Gegenprobe: Ändere bei einer Buchung den Betrag auf das Zehnfache → sie zeigt Betrag prüfen und zählt wieder als nicht belegt
  7. Zweite Gegenprobe: Lösche den Vertrag → die Buchungen fallen zurück auf Beleg fehlt
  8. Rechnungslegung erzeugen: Im Belegverzeichnis steht „Dauerzahlung zu Vertrag …" mit Nummer

Aufgewendete Zeit: 00:42
Pull Request: #14

Anmerkungen

Ich habe die Toleranzprüfung während der Umsetzung umgebaut. Der erste Entwurf verglich den Betrag gegen alle üblichen Zahlweisen, damit es auch passt, wenn die Bank anders abbucht als der Vertrag es führt. Der eigene Test hat ihn widerlegt: Bei 42,50 € monatlich liegen 420 € innerhalb von 20 % des Jahresbetrags von 510 € — ausgerechnet der Fall aus dieser Aufgabenstellung wäre durchgerutscht. Jetzt wird stur gegen den hinterlegten Beitrag verglichen.

Zum Bündeln mit Buchung.immobilieId: nicht getan, siehe Startkommentar. Ein Feld ohne Logik sähe fertig aus und wäre es nicht.

Nebenbei aufgefallen (gehört ins Dashboard, nicht Teil dieses PR):

  1. prisma migrate diff will zum dritten Mal die Trigramm-Indizes löschen. Ich habe die DROP INDEX-Zeilen erneut von Hand entfernt. Beim vierten Mal wird jemand es übersehen, und dann ist die unscharfe Suche still weg — ohne Fehlermeldung. Ein npm run db:migration, das erzeugt und gleich bereinigt, kostet zwanzig Zeilen.
  2. Die Buchungsliste hatte eine eigene Datenabfrage neben der gemeinsamen. Ist in diesem PR behoben, aber lohnt einen Blick: Es könnte weitere Stellen geben, die Buchungen von Hand abbilden.
  3. Der Demofall hat weiterhin keine Buchungen — dieselbe Beobachtung wie bei #3. Ohne sie lässt sich weder das Kassenbuch noch die Belegquote noch diese Funktion vorführen.

Nach Freigabe: /issue-freigabe 11

✅ **Umsetzung abgeschlossen — bereit zum Testen.** <!-- claude-status branch: feat/11-dauerzahlungen-belegt pr: 14 zeit_sekunden: 2526 --> **Was geändert wurde** - `Buchung.vertragId` mit `onDelete: SetNull`, dazu ein Kennzeichen für automatisch gesetzte Zuordnungen. - Der Belegzustand kennt **drei** Fälle statt zwei, in der Belegquote getrennt ausgewiesen. - Zuordnung im Buchungsformular; in der Liste als eigenes Abzeichen sichtbar, automatische Zuordnungen als solche gekennzeichnet. - **Automatisch beim Import** bei eindeutiger Gegenstelle; bei Mehrdeutigkeit geschieht nichts. - **Sammelzuordnung** unter *Wiederkehrende Zahlungen*: alle Zahlungen einer Gruppe mit einem Klick. - Die Rechnungslegung nennt „Dauerzahlung zu Vertrag «Bezeichnung», Nr. …" statt „ohne Beleg". - Version 1.3.0; die Roadmap-Versionszeile nachgezogen, wie bei #10 zugesagt. **Geänderte Dateien** - `src/lib/finanzen/kassenbuch.ts`, `rechnungslegung.ts`, `wiederkehrend.ts`, `wiederkehrend-laden.ts` - `src/lib/berichte/gemeinsam.ts`, `rechnungslegung.tsx`, `src/lib/dashboard/laden.ts` - `src/server/actions/finanzen.ts`, `src/lib/validierung/finanzen.ts` - `src/components/finanzen/{bausteine,buchungs-formular,wiederkehrend-aktionen}.tsx` - vier Seiten unter `src/app/(app)/finanzen/` - `tests/dauerzahlung.test.ts` *(neu)*, `e2e/dauerzahlung.spec.ts` *(neu)*, Schema, Migration, Doku **So testest du es** 1. `git switch feat/11-dauerzahlungen-belegt` und `npm run db:deploy` 2. `npm run dev`. Lege einen Vertrag mit **Gesellschaft, Beitrag und Zahlweise** an — die Zahlweise ist wichtig, sie ist der Maßstab 3. Kontoauszug importieren. Passt die Gegenstelle eindeutig zu diesem Vertrag, sind die Buchungen schon zugeordnet und in der Liste als *Vertrag (automatisch)* gekennzeichnet 4. **Vermögen & Kasse → Wiederkehrende Zahlungen**: Unter „Schon einem Vertrag zugeordnet" steht ein Knopf, der die restlichen Zahlungen der Gruppe auf einmal zuordnet 5. **Kassenbuch**: Die Zeilen tragen *durch Vertrag belegt*, nicht mehr *Beleg fehlt*. Die Belegquote oben steigt entsprechend 6. **Gegenprobe:** Ändere bei einer Buchung den Betrag auf das Zehnfache → sie zeigt *Betrag prüfen* und zählt wieder als nicht belegt 7. **Zweite Gegenprobe:** Lösche den Vertrag → die Buchungen fallen zurück auf *Beleg fehlt* 8. **Rechnungslegung** erzeugen: Im Belegverzeichnis steht „Dauerzahlung zu Vertrag …" mit Nummer **Aufgewendete Zeit:** 00:42 **Pull Request:** #14 --- **Anmerkungen** **Ich habe die Toleranzprüfung während der Umsetzung umgebaut.** Der erste Entwurf verglich den Betrag gegen alle üblichen Zahlweisen, damit es auch passt, wenn die Bank anders abbucht als der Vertrag es führt. Der eigene Test hat ihn widerlegt: Bei 42,50 € monatlich liegen 420 € innerhalb von 20 % des Jahresbetrags von 510 € — ausgerechnet der Fall aus dieser Aufgabenstellung wäre durchgerutscht. Jetzt wird stur gegen den hinterlegten Beitrag verglichen. **Zum Bündeln mit `Buchung.immobilieId`:** nicht getan, siehe Startkommentar. Ein Feld ohne Logik sähe fertig aus und wäre es nicht. **Nebenbei aufgefallen** (gehört ins Dashboard, nicht Teil dieses PR): 1. **`prisma migrate diff` will zum dritten Mal die Trigramm-Indizes löschen.** Ich habe die `DROP INDEX`-Zeilen erneut von Hand entfernt. Beim vierten Mal wird jemand es übersehen, und dann ist die unscharfe Suche still weg — ohne Fehlermeldung. Ein `npm run db:migration`, das erzeugt und gleich bereinigt, kostet zwanzig Zeilen. 2. **Die Buchungsliste hatte eine eigene Datenabfrage** neben der gemeinsamen. Ist in diesem PR behoben, aber lohnt einen Blick: Es könnte weitere Stellen geben, die Buchungen von Hand abbilden. 3. **Der Demofall hat weiterhin keine Buchungen** — dieselbe Beobachtung wie bei #3. Ohne sie lässt sich weder das Kassenbuch noch die Belegquote noch diese Funktion vorführen. Nach Freigabe: `/issue-freigabe 11`
florian.wilde commented 2026-08-23 07:07:06 +00:00
Author
Owner
Copy Link
Copy Source

🚀 Freigegeben und nach main übernommen.

  • Merge-Commit: de21f1c
  • Pull Request: #14 (gemergt)
  • Gesamtaufwand: 00:42
  • Veröffentlicht als v1.3.0

Beim Ausrollen: Eine Migration läuft mit (20260823062000_buchung_vertragszahlung). Sie fügt zwei Spalten hinzu und ändert nichts an vorhandenen Daten — ohne Zuordnung bleibt alles, wie es war.

cd /opt/docker/configs/betreuungs-cockpit
./scripts/update.sh

Issue wird geschlossen.

🚀 **Freigegeben und nach `main` übernommen.** <!-- claude-status merge: de21f1c3204685f5ccca516a7c74036946c04e6b pr: 14 zeit_sekunden: 2526 --> - Merge-Commit: `de21f1c` - Pull Request: #14 (gemergt) - Gesamtaufwand: 00:42 - Veröffentlicht als **v1.3.0** **Beim Ausrollen:** Eine Migration läuft mit (`20260823062000_buchung_vertragszahlung`). Sie fügt zwei Spalten hinzu und ändert nichts an vorhandenen Daten — ohne Zuordnung bleibt alles, wie es war. ```bash cd /opt/docker/configs/betreuungs-cockpit ./scripts/update.sh ``` Issue wird geschlossen.
florian.wilde removed the zu-testen label 2026-08-23 07:07:13 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
blockiert
Offene Rueckfrage, Uhr steht
 in-arbeit
Claude arbeitet daran, Stopwatch laeuft
 zu-testen
Umgesetzt, PR offen, wartet auf Test
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
florian.wilde (Florian Wilde)
No Assignees
1 Participants
Notifications
Total Time Spent: 42 minutes
florian.wilde
42 minutes
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: florian.wilde/betreuungs-cockpit#11