Rueckkaufswert am Vertrag sichtbar machen

Am Telefon mit der Gesellschaft braucht man die Zahl dort, wo man sie
gefragt hat. Auf der Vertragsseite steht jetzt oben der zuletzt
mitgeteilte Wert mit Stichtag und Quelle, darunter die Historie; in der
Uebersicht traegt ein Wert, der aelter als ein Jahr ist, ein Abzeichen.

Ohne Migration, und das ist keine Einsparung, sondern der Punkt: Die
Werthistorie gibt es schon als Wertstand am Vermoegensposten, und der
kann auf einen Vertrag zeigen. Ein Feld am Vertrag waere genau die
zweite Wahrheit, die das Issue ausschliesst - dieselbe Zahl steht im
Vermoegensverzeichnis, weil es dieselbe Zahl ist.

Aufbau:
- Die Ein-Jahres-Grenze als eine getestete Regel in
  finanzen/wertalter.ts. Sie stand bisher als "> 365" mitten in der
  Vermoegensseite; jetzt gilt sie am Vertrag genauso.
- wertHistorie() fuehrt die Wertstaende aller mit dem Vertrag
  verknuepften Posten zu einer Reihe zusammen.
- Wo ein Rueckkaufswert zu erwarten waere, aber keiner erfasst ist,
  steht "noch nicht erfasst" statt einer leeren Zelle.

Zwei Fehler dabei behoben:
- Vertrag und Vermoegensposten wurden ueber die ART des Postens
  zusammengefuehrt. Ein von Hand als "Sonstiges" angelegter Posten wurde
  nicht gefunden, und beim ersten Erfassen am Vertrag entstand still ein
  zweiter - Bericht und Vertrag haetten verschiedene Zahlen gezeigt.
  Massgeblich ist jetzt die Verknuepfung.
- Beim Speichern eines Vermoegenspostens wurde geprueft, ob das
  verknuepfte Konto zur betreuten Person gehoert; bei Vertrag und
  Immobilie fehlte die Pruefung, beim Vertragsverweis einer Buchung
  ebenso. Bei mehreren betreuten Personen haette ein manipuliertes
  Formular ueber Aktengrenzen hinweg verknuepfen koennen.

Geprueft: zehn Einheitstests, vier End-to-End-Tests - darunter der neu
eingetragene Wert, der unveraendert im Vermoegensverzeichnis
wiederauftaucht, und der Posten mit abweichender Art.

Refs #8

src/lib/finanzen/wertalter.ts

@@ -0,0 +1,52 @@
+import { tageZwischen } from '@/lib/finanzen/datum'
+
+/**
+ * Wie alt ist ein Wert - und ab wann ist das ein Problem?
+ *
+ * Ein Rueckkaufswert ohne Datum ist schlimmer als kein Rueckkaufswert:
+ * Man rechnet mit einer Zahl, die drei Jahre alt sein kann, und merkt es
+ * erst, wenn der Bezirk nachfragt. Deshalb steht neben jedem Betrag der
+ * Stichtag, und ab einem Jahr steht daneben, dass er alt ist.
+ *
+ * Die Grenze liegt bei 365 Tagen, weil der Bezirk jaehrlich prueft und
+ * das Betreuungsgericht jaehrlich Rechnung legen laesst. Ein Wert, der
+ * den letzten Jahresbericht ueberlebt hat, gehoert erneuert.
+ *
+ * Bewusst eine eigene Datei und nicht in vermoegen.ts: Die Regel gilt am
+ * Vertrag genauso wie im Vermoegensverzeichnis, und sie soll an beiden
+ * Stellen dieselbe sein - nicht zweimal als `> 365` hingeschrieben.
+ */
+
+export const WERT_VERALTET_TAGE = 365
+
+export type Wertalter = {
+  /** Tage zwischen Stichtag und heute. Negativ bei kuenftigem Stichtag. */
+  alterTage: number
+  veraltet: boolean
+  /** Kurztext fuer ein Abzeichen neben dem Betrag, sonst null. */
+  hinweis: string | null
+}
+
+/** Ist ein Wert dieses Alters erneuerungsbeduerftig? */
+export function wertVeraltet(alterTage: number): boolean {
+  return alterTage > WERT_VERALTET_TAGE
+}
+
+/**
+ * Das Alter eines Werts zum Stichtag.
+ *
+ * Ohne Stichtag gibt es kein Alter - dann null, und die Oberflaeche
+ * zeigt gar nichts an, statt eine Null zu behaupten.
+ */
+export function wertalterBestimmen(stichtag: Date | null, heute: Date): Wertalter | null {
+  if (!stichtag) return null
+
+  const alterTage = tageZwischen(stichtag, heute)
+  const veraltet = wertVeraltet(alterTage)
+
+  return {
+    alterTage,
+    veraltet,
+    hinweis: veraltet ? 'über ein Jahr alt' : null,
+  }
+}

src/lib/version.ts

@@ -17,7 +17,7 @@
  */
 
 /** Muss zur "version" in der package.json passen. */
-export const VERSION = '1.7.0'
+export const VERSION = '1.8.0'
 
 /**
  * Kurzer Git-Stand, beim Bauen hineingereicht:

src/lib/vertraege/rueckkaufswert.ts

@@ -114,3 +114,31 @@ export function anfrageStatus(
     tageSeitAnfrage: tage,
   }
 }
+
+/**
+ * Die Rueckkaufswert-Historie eines Vertrags, juengster Wert zuerst.
+ *
+ * Der Wert lebt nicht am Vertrag, sondern als Wertstand am
+ * Vermoegensposten - genau derselbe, aus dem das Vermoegensverzeichnis
+ * rechnet. Es gibt also keine zweite Zahl, die abweichen koennte, und
+ * der Vertrag zeigt nur an, was ohnehin schon in der Akte steht.
+ *
+ * Verknuepft wird ueber die Vertrags-Id, nicht ueber die Art des Postens.
+ * Wer einen Posten von Hand als "Sonstiges" anlegt und mit dem Vertrag
+ * verknuepft, meint denselben Vertrag - er darf dadurch nicht eine
+ * zweite, unsichtbare Wahrheit bekommen.
+ */
+export function wertHistorie<T extends { stichtag: Date }>(
+  posten: { wertstaende: T[] }[],
+): T[] {
+  return posten
+    .flatMap((p) => p.wertstaende)
+    .sort((a, b) => b.stichtag.getTime() - a.stichtag.getTime())
+}
+
+/** Der zuletzt mitgeteilte Wert, oder null, wenn noch keiner vorliegt. */
+export function juengsterWert<T extends { stichtag: Date }>(
+  posten: { wertstaende: T[] }[],
+): T | null {
+  return wertHistorie(posten)[0] ?? null
+}