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

Deploy 10.09.2026 — Statistik-Paket live

Das Paket aus dem Statistik-Audit 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

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.

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.

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.