Kundenabo-Vorschau: bereits abgerechnete Punkte fehlten in der Basis

Die Kachelreihe "Punkte aus meinen Kundenabos zum 5./10./20./25." startete bei
einer Basis von 0 und addierte nur die noch offenen Ausfuehrungen. Damit standen
die bereits vergangenen Termine auf null, obwohl im Monat laengst Lieferungen
gebucht waren, und die spaeteren Termine zeigten nur den Rest statt des
Monatsstands.

Berater 454 im September: vorher 0 / 0 / 131 / 319, jetzt 457 / 457 / 588 / 776.
Betrifft im September 86 Berater mit zusammen 15.936 Punkten — reine Anzeige,
gebucht und abgerechnet wurde korrekt.

Die Basis ist jetzt die im Monat aus den eigenen Kundenabos abgerechnete
Punktzahl, ueber dieselbe Abgrenzung wie die Backoffice-Statistik
(SalesVolumePoints::customerAboPoints(), Stornos vorzeichengetreu). Damit liest
sich die Kachel wie die Prognose-Kachel auf dem Dashboard: Stand heute plus das,
was bis zum Termin noch hereinkommt. Hinweistext in allen vier Sprachen
nachgezogen.

Nicht aus dem Audit-Paket: Die Null-Basis stammt aus der K9-Umsetzung vom 07.09.,
nicht aus der A13-Korrektur.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

dev/2026-07-22/deploy-2026-09-10.md

@@ -76,3 +76,50 @@ Arbeitsbaum (DHL, Stripe/Payone, DATEV, `shipped_at`).
 Ebenfalls unverändert: die vorbestehenden Testfehler auf dem Branch (rund 42 SQLite-Schemafehler in
 Unit-Tests, 25 fehlende Übersetzungsschlüssel in `payment.php` für es und fr, verwendet in einer
 Admin-Ansicht). Gehören in ein eigenes Aufräumpaket.
+
+---
+
+## Nachtrag 11.09.2026 — Kundenabo-Vorschau zeigte nur den Rest des Monats
+
+Beim Nachsehen auf Produktion aufgefallen (Berater 454): Auf `/user/abos/ot` stand die Kachelreihe
+„Punkte aus meinen Kundenabos zum 5. / 10. / 20. / 25." für die bereits vergangenen Termine auf
+**null**, obwohl im Monat längst Lieferungen gebucht waren.
+
+**Ursache.** Die Vorschau startete bei einer Basis von 0 und addierte nur die noch **offenen**
+Ausführungen. Die im Monat bereits abgerechneten Kundenabo-Punkte fehlten vollständig. Die Kachel
+beantwortete damit „was kommt noch" statt der Frage aus der Anforderung vom 07.09. („wieviel
+Volumenpunkte habe ich am 5. / 10. / 20. / 25.").
+
+Berater 454, September 2026:
+
+| | vorher | jetzt |
+| --- | --- | --- |
+| 05.09. | 0 | 457 |
+| 10.09. | 0 | 457 |
+| 20.09. | 131 | 588 |
+| 25.09. | 319 | 776 |
+
+Die 457 Punkte waren bereits abgerechnet (Lieferungen am 1., 5. und 10.), die 319 stehen noch aus.
+Der Monatsstand aus Kundenabos beträgt 776.
+
+**Umfang.** Im September betrifft das **86 Berater** mit zusammen **15.936 Punkten**, die in dieser
+Kachel nicht sichtbar waren. Nur eine Anzeige — es wurde nichts falsch gebucht oder abgerechnet.
+
+**Nicht aus dem Audit-Paket.** Die Null-Basis stammt aus der Umsetzung des Kundenwunschs vom 07.09.
+(K9), nicht aus der A13-Korrektur; dort wurde in dieser Methode nur der Datumsfilter ersetzt. In die
+Git-Historie ist sie erst mit `94e2b13` gekommen, weil der ganze Arbeitsstand vorher nicht committet
+war.
+
+**Behebung.** Die Basis ist jetzt die im Monat aus den eigenen Kundenabos abgerechnete Punktzahl —
+dieselbe Abgrenzung wie in der Backoffice-Statistik (`SalesVolumePoints::customerAboPoints()`),
+Stornos vorzeichengetreu. Damit liest sich die Kachel wie die Prognose-Kachel auf dem Dashboard:
+Stand heute plus das, was bis zum Termin noch hereinkommt. Der Hinweistext unter der Überschrift ist
+in allen vier Sprachen nachgezogen.
+
+**Bewusste Grenze.** Ein vergangener Termin zeigt jetzt den **Monatsstand**, nicht den Stand genau an
+jenem Tag — die Kachel am 05.09. enthält also auch die Lieferungen vom 10. Das ist dieselbe Lesart
+wie auf dem Dashboard, und das Unterlabel sagt „Termin liegt bereits im Ist-Umsatz". Wer stattdessen
+den echten Tagesverlauf sehen will, braucht eine Gruppierung der Buchungen nach Liefertag — das wäre
+ein eigener Umbau.
+
+**Deployment:** nur Dateien, keine Migration, kein Skript. Danach `php artisan view:clear`.