Doku: Deploy-Notiz zum Statistik-Paket vom 10.09.2026

Haelt fest, was live gegangen ist, welche Daten der Snapshot-Neuaufbau
tatsaechlich angefasst hat (nur backoffice_statistics_snapshots, 8 Monate,
7 VIP-Konten) und welche nicht (Provisionen, Gutschriften, Marketingplan).

Wichtig fuer spaetere Rueckfragen: Die historischen Monatswerte koennen sich
verschoben haben, weil der neue Snapshot die Struktur des Ausfuehrungstags
einfriert und Shop-Stornos jetzt zu den Kundenpunkten zaehlen. Ein
Vorher/Nachher-Vergleich wurde nicht erstellt, die alten Snapshot-Staende sind
ueberschrieben.

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

dev/2026-07-22/README.md

@@ -8,6 +8,9 @@ welches der aktuelle Stand ist.
 **[audit-statistiken-2026-09-09-bewertung.md](audit-statistiken-2026-09-09-bewertung.md)** — ganz
 oben unter „Stand" stehen erledigte und offene Befunde mit Sprungmarken. Das ist der Einstieg.
 
+**[deploy-2026-09-10.md](deploy-2026-09-10.md)** — was am 10.09. live gegangen ist, was sich dabei in
+den Daten geändert hat und was das für die historischen Zahlen bedeutet.
+
 ## Entscheidungen, die dauerhaft gelten
 
 | Dokument | Inhalt |

dev/2026-07-22/audit-statistiken-2026-09-09-bewertung.md

@@ -60,10 +60,13 @@ Dazu zwei Regeln, die dabei entschieden wurden:
 
 ## Deployment des gesamten Pakets
 
+**Erledigt am 10.09.2026, ohne Fehler** — Einzelheiten und Auswirkung auf die historischen Zahlen in
+[deploy-2026-09-10.md](deploy-2026-09-10.md).
+
 ```bash
 php artisan migrate
 php artisan backoffice:store-statistics-snapshots --force   # einmalig, Payload-Version 2
-php artisan view:clear
+php artisan config:clear && php artisan view:clear && php artisan cache:clear
 ```
 
 ---

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

@@ -0,0 +1,78 @@
+# Deploy 10.09.2026 — Statistik-Paket live
+
+Das Paket aus dem [Statistik-Audit](audit-statistiken-2026-09-09-bewertung.md) ist auf Produktion.
+Upload per SFTP, anschließend Migration, Snapshot-Neuaufbau und Cache-Leerung im Terminal.
+**Ohne Fehler durchgelaufen.**
+
+## Was live gegangen ist
+
+| Commit | Inhalt |
+| --- | --- |
+| `42ec51c` | Stornos mindern die richtige Punktekategorie (A02, A06, A15, R01–R03) — enthält beide Migrationen |
+| `8d7a98c` | Abgeschlossene Monate werden vollständig eingefroren (A03, A04, A06, A12) |
+| `94e2b13` | Übrige Audit-Korrekturen (A01, A08–A11, A13, A14, A16–A19) |
+| `9a3940f` | Dokumentation |
+
+```bash
+php artisan migrate
+php artisan backoffice:store-statistics-snapshots --force
+php artisan config:clear && php artisan view:clear && php artisan cache:clear
+```
+
+Die Reihenfolge ist nicht beliebig: ohne die Migration bricht der Neuaufbau mit
+`Unknown column storno_origin_status` ab.
+
+## Was sich in den Daten geändert hat
+
+**Migrationen.** `user_sales_volumes` bekommt die Spalte `storno_origin_status` (leer, nullable), und
+`status_turnover` wird nullable — letzteres zieht nur das Schema auf den Stand nach, der auf
+Produktion ohnehin galt. **Keine vorhandene Zeile wurde verändert.**
+
+**Snapshot-Neuaufbau.** Geschrieben wurde ausschließlich `backoffice_statistics_snapshots`, für
+**8 abgeschlossene Monate** (Januar bis August 2026) und die VIP-Konten (`admin >= 1 AND admin < 4`,
+derzeit 7). Der Dienst dahinter hat keine Service-Abhängigkeiten und liest nur aus
+`user_sales_volumes`, `user_abos`, `user_levels`, `shopping_order_items` und `users`.
+
+**Nicht angefasst:** Provisionen (`user_businesses`), Gutschriften, Rechnungen, Marketingplan. Die
+für April bis August ausgestellten Gutschriften bleiben unverändert — genau das ist die
+[Einfrier-Regel](monatsabschluss-eingefrorene-statistik.md).
+
+## Was das für die Zahlen bedeutet
+
+Die historischen Monatswerte in der Backoffice-Statistik **können sich gegenüber vorher verschoben
+haben**, aus zwei Gründen:
+
+1. Shop-Stornos zählen jetzt zu den Kundenpunkten statt zu den Eigenpunkten (A15).
+2. Der neue Snapshot friert die Struktur des **Ausführungstags** ein, nicht die des damaligen
+   Monatsendes — früheres Sponsoring wird nirgends historisiert. Wer seit damals verschoben wurde
+   oder dazugekommen ist, steckt jetzt in den historischen Zahlen an seiner heutigen Stelle.
+
+Punkt 2 war die bewusste Entscheidung, einen **einheitlichen** Stand herzustellen. Ab jetzt friert
+jeder Monatswechsel den Stand fest, und die Werte bleiben stehen.
+
+Ein Vorher/Nachher-Vergleich der alten gegen die neuen Monatswerte wurde **nicht** erstellt; der
+Neuaufbau lief direkt. Die alten Snapshot-Stände sind damit überschrieben. Falls später Rückfragen zu
+einzelnen Monatszahlen kommen, lässt sich der frühere Stand nur noch aus einem Datenbank-Backup
+holen.
+
+## Woran man merken würde, dass etwas nicht stimmt
+
+- **Backoffice-Statistik, abgeschlossener Monat:** Das Abzeichen muss „Monat abgeschlossen · Stand
+  eingefroren" zeigen, und die Zahl in der Kachel muss mit der verlinkten Detailliste übereinstimmen.
+- **Laufender Monat:** weiterhin live, keine Einfrier-Kennzeichnung.
+- **Provisionskachel auf dem Dashboard:** Bei einer fehlgeschlagenen Berechnung steht jetzt ein
+  Hinweis statt „0,00 €" (A19).
+- **Abo-Einstellungen (Selbstbedienung):** Zustandswechsel nur noch über Pause und Kündigung. Der
+  Admin-Pfad ist unverändert.
+
+## Offen
+
+Unverändert offen: **A07** (gehört planerisch zu K11), **A22/A23** und die drei Kundenfragen
+**A05, A20, A21** — siehe Stand-Block in der [Bewertung](audit-statistiken-2026-09-09-bewertung.md).
+
+Nicht mit deployt und weiterhin nicht committet: die Arbeit aus anderen Themen im selben
+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.