diff --git a/dev/2026-07-22/README.md b/dev/2026-07-22/README.md index 16a4f4dd..8a2a6184 100644 --- a/dev/2026-07-22/README.md +++ b/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 | diff --git a/dev/2026-07-22/audit-statistiken-2026-09-09-bewertung.md b/dev/2026-07-22/audit-statistiken-2026-09-09-bewertung.md index eecab090..c8937ea6 100644 --- a/dev/2026-07-22/audit-statistiken-2026-09-09-bewertung.md +++ b/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 ``` --- diff --git a/dev/2026-07-22/deploy-2026-09-10.md b/dev/2026-07-22/deploy-2026-09-10.md new file mode 100644 index 00000000..c973f71a --- /dev/null +++ b/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.