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

Rückkaufswert am Vertrag sichtbar machen #8

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

Problem

Der Rückkaufswert hängt heute am Vermögensposten, nicht am Vertrag. In der
Vertragsübersicht steht deshalb kein Betrag — ausgerechnet dort, wo man ihn
beim Telefonat mit dem Versicherer braucht.

Steht in der Roadmap unter 1.1 — Was heute noch falsch sein kann.

Zusammenhang

Das ist die Rückseite der Anfrage: Man fragt den Wert an, bekommt Post, und
will ihn dann dort eintragen, wo man ihn gefragt hat. Heute muss man den
Umweg über den Vermögensposten gehen und beim nächsten Mal wieder danach
suchen.

Was ich will

  • Beim Vertrag stehen der zuletzt mitgeteilte Rückkaufswert und der
    Stichtag, zu dem er gilt
  • Frühere Werte bleiben erhalten — beim Jahresvergleich ist die Entwicklung
    die eigentliche Aussage
  • Der Wert fließt weiterhin ins Vermögensverzeichnis; es soll keine zweite,
    konkurrierende Quelle entstehen

Akzeptanzkriterien

  • In der Vertragsübersicht steht bei Lebens- und Rentenversicherungen
    der letzte bekannte Rückkaufswert mit Stichtag
  • Ein neuer Wert lässt sich direkt am Vertrag eintragen
  • Frühere Werte bleiben abrufbar
  • Der Wert im Vermögensverzeichnis stimmt mit dem am Vertrag überein —
    es gibt genau eine Wahrheit, nicht zwei
  • Ist ein Wert älter als ein Jahr, ist das erkennbar; ein veralteter
    Betrag ohne Datum ist schlimmer als kein Betrag

Hinweis

Migration nötig. Bitte prüfen, ob sich das mit anderen Punkten aus
Roadmap 1.1 zu einer Migration bündeln lässt.

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

## Problem Der Rückkaufswert hängt heute am Vermögensposten, nicht am Vertrag. In der Vertragsübersicht steht deshalb kein Betrag — ausgerechnet dort, wo man ihn beim Telefonat mit dem Versicherer braucht. Steht in der Roadmap unter **1.1 — Was heute noch falsch sein kann**. ## Zusammenhang Das ist die Rückseite der Anfrage: Man fragt den Wert an, bekommt Post, und will ihn dann **dort** eintragen, wo man ihn gefragt hat. Heute muss man den Umweg über den Vermögensposten gehen und beim nächsten Mal wieder danach suchen. ## Was ich will - Beim Vertrag stehen der zuletzt mitgeteilte Rückkaufswert und der Stichtag, zu dem er gilt - Frühere Werte bleiben erhalten — beim Jahresvergleich ist die Entwicklung die eigentliche Aussage - Der Wert fließt weiterhin ins Vermögensverzeichnis; es soll keine zweite, konkurrierende Quelle entstehen ## Akzeptanzkriterien - [ ] In der Vertragsübersicht steht bei Lebens- und Rentenversicherungen der letzte bekannte Rückkaufswert mit Stichtag - [ ] Ein neuer Wert lässt sich direkt am Vertrag eintragen - [ ] Frühere Werte bleiben abrufbar - [ ] Der Wert im Vermögensverzeichnis stimmt mit dem am Vertrag überein — es gibt genau eine Wahrheit, nicht zwei - [ ] Ist ein Wert älter als ein Jahr, ist das erkennbar; ein veralteter Betrag ohne Datum ist schlimmer als kein Betrag ## Hinweis Migration nötig. Bitte prüfen, ob sich das mit anderen Punkten aus Roadmap 1.1 zu einer Migration bündeln lässt. _Angelegt auf Zuruf im Chat, nicht aus dem Dashboard — bitte in Nebula nachtragen._
florian.wilde added the in-arbeit label 2026-08-23 12:25:42 +00:00
florian.wilde started working 2026-08-23 12:25:57 +00:00
florian.wilde commented 2026-08-23 12:26:10 +00:00
Author
Owner
Copy Link
Copy Source

🤖 Claude Code hat mit der Umsetzung begonnen.

  • Branch: feat/8-rueckkaufswert-am-vertrag
  • Verstanden als: Der Rückkaufswert soll dort stehen und dort eintragbar sein, wo man ihn braucht — am Vertrag —, ohne dass eine zweite Wahrheit neben dem Vermögensverzeichnis entsteht.
  • Geplantes Vorgehen:
    • Voraussichtlich ohne Migration. Die Werthistorie gibt es bereits: Wertstand (Stichtag, Betrag, Wertquelle, Nachweisdokument) am Vermoegensposten, und der kann schon heute per vertragId auf einen Vertrag zeigen. Ein neues Feld am Vertrag wäre genau die zweite Quelle, die das Issue ausschließt. Ich hole den bestehenden Wert an den Vertrag, statt ihn zu duplizieren.
    • Eintragen am Vertrag schreibt einen Wertstand. Fehlt der Vermögensposten noch, wird er angelegt und mit dem Vertrag verknüpft — damit taucht der Wert automatisch im Vermögensverzeichnis auf.
    • Alter als reine Funktion: älter als ein Jahr wird sichtbar gekennzeichnet. Ein veralteter Betrag ohne Datum ist schlimmer als kein Betrag.
    • Frühere Werte bleiben abrufbar — die Historie steht am Vertrag, nicht nur im Vermögensverzeichnis.

Zum Hinweis auf die Bündelung mit #9: Wenn #8 wie geplant ohne Schemaänderung auskommt, bringt eine gemeinsame Migration nichts mehr — #9 bekommt dann seine eigene, kleine. Sollte sich beim Bauen doch eine Schemaänderung als nötig erweisen, melde ich mich, bevor ich sie anlege.

Zeiterfassung läuft.

🤖 **Claude Code hat mit der Umsetzung begonnen.** - Branch: `feat/8-rueckkaufswert-am-vertrag` - Verstanden als: Der Rückkaufswert soll dort stehen und dort eintragbar sein, wo man ihn braucht — am Vertrag —, ohne dass eine zweite Wahrheit neben dem Vermögensverzeichnis entsteht. - Geplantes Vorgehen: - **Voraussichtlich ohne Migration.** Die Werthistorie gibt es bereits: `Wertstand` (Stichtag, Betrag, Wertquelle, Nachweisdokument) am `Vermoegensposten`, und der kann schon heute per `vertragId` auf einen Vertrag zeigen. Ein neues Feld am Vertrag wäre genau die zweite Quelle, die das Issue ausschließt. Ich hole den bestehenden Wert an den Vertrag, statt ihn zu duplizieren. - Eintragen am Vertrag schreibt einen `Wertstand`. Fehlt der Vermögensposten noch, wird er angelegt und mit dem Vertrag verknüpft — damit taucht der Wert automatisch im Vermögensverzeichnis auf. - Alter als reine Funktion: älter als ein Jahr wird sichtbar gekennzeichnet. Ein veralteter Betrag ohne Datum ist schlimmer als kein Betrag. - Frühere Werte bleiben abrufbar — die Historie steht am Vertrag, nicht nur im Vermögensverzeichnis. Zum **Hinweis auf die Bündelung mit #9**: Wenn #8 wie geplant ohne Schemaänderung auskommt, bringt eine gemeinsame Migration nichts mehr — #9 bekommt dann seine eigene, kleine. Sollte sich beim Bauen doch eine Schemaänderung als nötig erweisen, melde ich mich, bevor ich sie anlege. Zeiterfassung läuft.
florian.wilde worked for 40 minutes 2026-08-23 13:06:34 +00:00
florian.wilde added zu-testen and removed in-arbeit labels 2026-08-23 13:07:29 +00:00
florian.wilde commented 2026-08-23 13:08:01 +00:00
Author
Owner
Copy Link
Copy Source

✅ Umsetzung abgeschlossen — bereit zum Testen.

Was geändert wurde

  • Der letzte Wert steht oben auf der Vertragsseite — Betrag groß, darunter Stichtag und Quelle. Wer beim Telefonat mit der Gesellschaft danach gefragt wird, hat keine Zeit, eine Historie zu lesen. Die vollständige Historie steht wie bisher darunter.
  • Alter erkennbar: Ist der jüngste Wert älter als ein Jahr, steht „über ein Jahr alt" daneben — in der Vertragsübersicht und auf der Vertragsseite, dort mit dem Zusatz „vor dem nächsten Bericht neu anfragen".
  • Die Ein-Jahres-Grenze ist jetzt eine Regel statt einer Zahl im Code. Sie stand als > 365 mitten in der Vermögensseite; jetzt liegt sie in src/lib/finanzen/wertalter.ts und gilt an beiden Stellen dieselbe.
  • „noch nicht erfasst" statt leerer Zelle, wo ein Rückkaufswert zu erwarten wäre (Lebens-, Renten-, Sterbegeldversicherung, Bestattungsvorsorge, Sterbekasse).

Zum Hinweis „Migration nötig": es war keine nötig — und das ist der Punkt. Die Werthistorie gibt es bereits als Wertstand am Vermoegensposten, und der kann auf einen Vertrag zeigen. Ein eigenes Feld am Vertrag wäre genau die zweite Wahrheit gewesen, die das Issue ausschließt. Die Zahl am Vertrag ist dieselbe wie im Vermögensverzeichnis, weil es dieselbe Zahl ist. Damit entfällt auch die Bündelung mit #9 — das bekommt dann seine eigene, kleine Migration.

Zwei Fehler, die dabei aufgefallen sind, und die ich mitbehoben habe

  1. Ein Vertrag konnte zwei Wertreihen bekommen. Vertrag und Vermögensposten wurden über die Art des Postens zusammengeführt (art: 'VERSICHERUNG'). Wer einen Posten von Hand anlegte und ihn anders führte — etwa als „Sonstiges" —, sah dessen Werte am Vertrag nicht, und beim ersten Eintragen am Vertrag entstand still ein zweiter Posten. Der Bericht hätte die eine Zahl gezeigt und der Vertrag die andere. Maßgeblich ist jetzt die Verknüpfung mit dem Vertrag, nicht die Art.
  2. Fehlende Zugehörigkeitsprüfung bei zwei Verweisen. Beim Speichern eines Vermögenspostens wurde geprüft, ob das verknüpfte Konto zur betreuten Person gehört; bei Vertrag und Immobilie fehlte dieselbe Prüfung, und beim Vertragsverweis einer Buchung ebenso. Bei mehreren betreuten Personen hätte ein manipuliertes Formular eine Verknüpfung über Aktengrenzen hinweg anlegen können. Alle drei Verweise werden jetzt gleich behandelt.

Geänderte Dateien

  • src/lib/finanzen/wertalter.ts (neu)
  • src/lib/vertraege/rueckkaufswert.ts — wertHistorie(), juengsterWert()
  • src/app/(app)/vertraege/page.tsx, src/app/(app)/vertraege/[id]/page.tsx
  • src/components/vertraege/rueckkaufswert.tsx
  • src/app/(app)/finanzen/vermoegen/page.tsx — nutzt die gemeinsame Regel
  • src/server/actions/vertraege.ts, src/server/actions/finanzen.ts
  • tests/wertalter.test.ts (neu), tests/vertraege.test.ts, e2e/rueckkaufswert-vertrag.spec.ts (neu)

So testest du es

  1. git switch feat/8-rueckkaufswert-am-vertrag und npm run dev
  2. Verträge öffnen.
    Erwartet: In der Spalte Rückkaufswert steht bei erfassten Werten Betrag und Stichtag; bei Lebens-/Rentenversicherungen ohne Wert steht „noch nicht erfasst"; bei Haftpflicht und Strom bleibt „–".
  3. Bei einem Vertrag mit einem Wert, dessen Stichtag über ein Jahr zurückliegt: Das gelbe Abzeichen „über ein Jahr alt" steht unter dem Datum.
  4. Einen Versicherungsvertrag öffnen.
    Erwartet: Im Kasten Rückkaufswert steht oben „Zuletzt mitgeteilt" mit Betrag, Stichtag und Quelle; darunter die Tabelle mit allen früheren Werten.
  5. Mitgeteilten Wert eintragen → Stichtag, Betrag, Quelle, speichern.
    Erwartet: Der Wert steht sofort oben und in der Historie.
  6. Vermögen & Kasse → Vermögensverzeichnis mit einem Stichtag nach dem eben eingetragenen Datum aufrufen.
    Erwartet: Genau derselbe Betrag — eine Quelle, nicht zwei.
  7. Gegenprobe zum Fehler 1: Unter Vermögen einen Posten der Art „Sonstiges" anlegen, ihn mit einem Versicherungsvertrag verknüpfen und ihm einen Wert geben.
    Erwartet: Der Wert erscheint am Vertrag — und ein anschließendes Eintragen am Vertrag landet in derselben Reihe, nicht in einer zweiten.

Geprüft: 10 Einheitstests, 4 End-to-End-Tests. Volle Suite grün — 622 Unit-Tests, 107 End-to-End-Tests, Typecheck und Lint sauber.

Aufgewendete Zeit: 00:40
Pull Request: #19

Nach Freigabe: /issue-freigabe 8

✅ **Umsetzung abgeschlossen — bereit zum Testen.** <!-- claude-status branch: feat/8-rueckkaufswert-am-vertrag pr: 19 zeit_sekunden: 2437 --> **Was geändert wurde** - **Der letzte Wert steht oben auf der Vertragsseite** — Betrag groß, darunter Stichtag und Quelle. Wer beim Telefonat mit der Gesellschaft danach gefragt wird, hat keine Zeit, eine Historie zu lesen. Die vollständige Historie steht wie bisher darunter. - **Alter erkennbar:** Ist der jüngste Wert älter als ein Jahr, steht „über ein Jahr alt" daneben — in der Vertragsübersicht und auf der Vertragsseite, dort mit dem Zusatz „vor dem nächsten Bericht neu anfragen". - **Die Ein-Jahres-Grenze ist jetzt eine Regel statt einer Zahl im Code.** Sie stand als `> 365` mitten in der Vermögensseite; jetzt liegt sie in `src/lib/finanzen/wertalter.ts` und gilt an beiden Stellen dieselbe. - **„noch nicht erfasst"** statt leerer Zelle, wo ein Rückkaufswert zu erwarten wäre (Lebens-, Renten-, Sterbegeldversicherung, Bestattungsvorsorge, Sterbekasse). **Zum Hinweis „Migration nötig": es war keine nötig — und das ist der Punkt.** Die Werthistorie gibt es bereits als `Wertstand` am `Vermoegensposten`, und der kann auf einen Vertrag zeigen. Ein eigenes Feld am Vertrag wäre genau die zweite Wahrheit gewesen, die das Issue ausschließt. Die Zahl am Vertrag ist dieselbe wie im Vermögensverzeichnis, weil es dieselbe Zahl ist. Damit entfällt auch die Bündelung mit #9 — das bekommt dann seine eigene, kleine Migration. **Zwei Fehler, die dabei aufgefallen sind, und die ich mitbehoben habe** 1. **Ein Vertrag konnte zwei Wertreihen bekommen.** Vertrag und Vermögensposten wurden über die *Art* des Postens zusammengeführt (`art: 'VERSICHERUNG'`). Wer einen Posten von Hand anlegte und ihn anders führte — etwa als „Sonstiges" —, sah dessen Werte am Vertrag nicht, und beim ersten Eintragen am Vertrag entstand still ein zweiter Posten. Der Bericht hätte die eine Zahl gezeigt und der Vertrag die andere. Maßgeblich ist jetzt die Verknüpfung mit dem Vertrag, nicht die Art. 2. **Fehlende Zugehörigkeitsprüfung bei zwei Verweisen.** Beim Speichern eines Vermögenspostens wurde geprüft, ob das verknüpfte *Konto* zur betreuten Person gehört; bei *Vertrag* und *Immobilie* fehlte dieselbe Prüfung, und beim Vertragsverweis einer *Buchung* ebenso. Bei mehreren betreuten Personen hätte ein manipuliertes Formular eine Verknüpfung über Aktengrenzen hinweg anlegen können. Alle drei Verweise werden jetzt gleich behandelt. **Geänderte Dateien** - `src/lib/finanzen/wertalter.ts` *(neu)* - `src/lib/vertraege/rueckkaufswert.ts` — `wertHistorie()`, `juengsterWert()` - `src/app/(app)/vertraege/page.tsx`, `src/app/(app)/vertraege/[id]/page.tsx` - `src/components/vertraege/rueckkaufswert.tsx` - `src/app/(app)/finanzen/vermoegen/page.tsx` — nutzt die gemeinsame Regel - `src/server/actions/vertraege.ts`, `src/server/actions/finanzen.ts` - `tests/wertalter.test.ts` *(neu)*, `tests/vertraege.test.ts`, `e2e/rueckkaufswert-vertrag.spec.ts` *(neu)* **So testest du es** 1. `git switch feat/8-rueckkaufswert-am-vertrag` und `npm run dev` 2. **Verträge** öffnen. Erwartet: In der Spalte *Rückkaufswert* steht bei erfassten Werten Betrag und Stichtag; bei Lebens-/Rentenversicherungen ohne Wert steht „noch nicht erfasst"; bei Haftpflicht und Strom bleibt „–". 3. Bei einem Vertrag mit einem Wert, dessen Stichtag über ein Jahr zurückliegt: Das gelbe Abzeichen „über ein Jahr alt" steht unter dem Datum. 4. Einen Versicherungsvertrag öffnen. Erwartet: Im Kasten *Rückkaufswert* steht oben „Zuletzt mitgeteilt" mit Betrag, Stichtag und Quelle; darunter die Tabelle mit allen früheren Werten. 5. **Mitgeteilten Wert eintragen** → Stichtag, Betrag, Quelle, speichern. Erwartet: Der Wert steht sofort oben und in der Historie. 6. **Vermögen & Kasse → Vermögensverzeichnis** mit einem Stichtag nach dem eben eingetragenen Datum aufrufen. Erwartet: Genau derselbe Betrag — eine Quelle, nicht zwei. 7. Gegenprobe zum Fehler 1: Unter *Vermögen* einen Posten der Art „Sonstiges" anlegen, ihn mit einem Versicherungsvertrag verknüpfen und ihm einen Wert geben. Erwartet: Der Wert erscheint am Vertrag — und ein anschließendes Eintragen am Vertrag landet in derselben Reihe, nicht in einer zweiten. **Geprüft:** 10 Einheitstests, 4 End-to-End-Tests. Volle Suite grün — 622 Unit-Tests, 107 End-to-End-Tests, Typecheck und Lint sauber. **Aufgewendete Zeit:** 00:40 **Pull Request:** #19 Nach Freigabe: `/issue-freigabe 8`
florian.wilde commented 2026-08-23 13:30:24 +00:00
Author
Owner
Copy Link
Copy Source

🚀 Freigegeben und nach main übernommen.

  • Merge-Commit: 5e7d88c
  • Pull Request: #19 (gemergt)
  • Fassung: v1.8.0 (getaggt)
  • Gesamtaufwand: 00:40

Issue wird geschlossen.

🚀 **Freigegeben und nach `main` übernommen.** <!-- claude-status merge: 5e7d88cf64f476a5b9667aec3966fbcd7376a039 pr: 19 zeit_sekunden: 2437 --> - Merge-Commit: `5e7d88c` - Pull Request: #19 (gemergt) - Fassung: **v1.8.0** (getaggt) - Gesamtaufwand: 00:40 Issue wird geschlossen.
florian.wilde removed the zu-testen label 2026-08-23 13:30:29 +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: 40 minutes
florian.wilde
40 minutes
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: florian.wilde/betreuungs-cockpit#8