User Statistik

dev/2026-05-13-backoffice/ENTWICKLUNGSKONZEPT-BACKOFFICE.md

@@ -10,7 +10,7 @@ Das Partner-Backoffice soll von einer statischen Monats-Kachelansicht zu einer k
 
 Kernziel ist eine einheitliche Datenbasis für:
 
-- Dashboard-Kennzahlen pro Linie 1 bis 8 inklusive Summenzeile
+- Dashboard-Kennzahlen pro vorhandener Linie inklusive Summenzeile
 - Detailansichten je Linie, Firstline und Kennzahl
 - Kundenabos, Teamabos, Kundenabos im Team, Umsatz und Punkte
 - neue Spezial-Kennzahl "1000 Punkte Shop"
@@ -37,7 +37,7 @@ Die aktuelle Statistik wird direkt im Blade-Partial berechnet. Sie nutzt unter a
 Bewertung:
 
 - Die vorhandene Ansicht ist ein guter Einstieg, aber fachlich zu grob.
-- Es gibt noch keine Linien 1 bis 8, keine Summenzeile und keine Drill-down-Routen.
+- Es gibt noch keine dynamische Linienübersicht, keine Summenzeile und keine Drill-down-Routen.
 - Die Kennzahl "Kundenabos" vermischt aktuell eigene Abos und Kundenabos.
 - "Team-Abos" zählt aktuell Beraterabos im Team, aber nicht die separat geforderten Kundenabos im Team.
 
@@ -296,6 +296,48 @@ Geplante Actions:
 
 Die vorhandenen Team-Views bleiben bestehen. Das neue Dashboard verweist für Detailseiten aber auf eigene, schlankere Statistik-Views.
 
+### Erster MVP: VIP-Menüpunkt Statistik
+
+Der erste technische Schritt ist ein eigener Navigationspunkt `Statistik` im User-Backoffice. Dieser Punkt ist bewusst nicht unter `Mein Team` einsortiert, sondern als eigener Einstieg sichtbar, damit die neue Auswertung fachlich als eigenes Modul wahrgenommen wird.
+
+Bereits angelegte Basis:
+
+- Route: `GET /user/backoffice/statistics`
+- Detailroute: `GET /user/backoffice/statistics/details?line=...&metric=...&month=...&year=...`
+- Name: `user_backoffice_statistics`
+- Controller: `App\Http\Controllers\User\BackofficeStatisticsController@index`
+- View: `resources/views/user/backoffice/statistics/index.blade.php`
+- Services: `App\Services\Backoffice\BackofficeDashboardService` und `App\Services\Backoffice\BackofficeDrilldownService`
+- Navigation: eigener Sidenav-Punkt `Statistik` mit `VIP`-Badge
+- Zugriff: nur `Auth::user()->isVIP()`, normale aktive User erhalten `404`
+- MVP-Übersicht: alle tatsächlich vorhandenen Linien mit Beratern inklusive abgelaufener, aber nicht gelöschter Accounts, Neupartnern, Teamabos, Teamkundenabos, Eigenpunkten, externen Punkten, Kundenabo-Punkten, Einzelbestellungs-Punkten, sonstigen Kundenpunkten, Gesamtpunkten und `1000 Punkte Shop`
+- MVP-Details: klickbare Listen für Berater, Neupartner, Teamabos, Teamkundenabos und Punktekennzahlen
+- Summenzeile: ebenfalls klickbar über `line=0` und damit Detailansicht über alle vorhandenen Linien
+- Berater-Detail: abgelaufene, aber nicht gelöschte Accounts werden mit roter Tabellenzeile und Status `Abgelaufen` angezeigt
+- Abo-Detail: zeigt `Besteht seit`; neue Abos im gewählten Monat werden grün markiert und in der Übersicht als Klammerzahl hinter den Abo-Counts gezeigt
+- Zeitraum: gewählter Monat/Jahr bleibt über Query-Parameter und Session erhalten, auch beim Rücksprung aus Detailansichten
+- Detailtabellen: clientseitige Suche, klickbare Sortierung der Spalten und Summenzeile am Tabellenende
+- Detailtabellen: CSV-Export über `GET /user/backoffice/statistics/export?line=...&metric=...&month=...&year=...`
+- Übersicht: Kennzahlen werden als gut anklickbare Badges dargestellt; Nullwerte bleiben sichtbar, aber nicht klickbar
+- Punktetrennung: externe Kundenpunkte werden zusätzlich nach Kundenabo-Punkten, Einzelbestellungs-Punkten und sonstigen Kundenpunkten getrennt
+- Snapshots: abgeschlossene Monate können in `backoffice_statistics_snapshots` gespeichert werden; vorhandene Snapshots werden bevorzugt vor Live-Berechnung geladen
+- Command: `backoffice:store-statistics-snapshots` speichert Snapshots für VIP-User, optional mit `--user`, `--month`, `--year` und `--force`
+- 1000-Punkte-Shop: Detailansicht zeigt die getrennten Punkte nach Eigen-, Abo-, Einzelbestellungs- und sonstigen Kundenpunkten; die vorherige Qualifikations-Einteilung wurde zugunsten des aktuellen Karriere-Levels entfernt
+- Karriere-Level: Detailansichten zeigen den aktuellen Karriere-Level des jeweiligen Beraters
+- Datenschutz: Detailansichten zeigen einen sichtbaren Hinweis, dass personenbezogene Detaildaten rechtlich noch final geklärt werden und aktuell nur für berechtigte VIP-Auswertungen vorgesehen sind
+- Übersichts-Export: Die Linienübersicht kann als CSV exportiert werden, inklusive Summenzeile, neuer Abo-Zählungen und Punktetrennung
+- Tests: CSV-Inhalte, Detail-CSV mit Karriere-Level, Zeitraum-Erhalt, neue Abo-Markierung und Abo-Statusgrund aus Zahlungsfehlern sind gezielt abgesichert
+- Performance-Hinweis: Die Übersicht zeigt Datenquelle (`Live` oder `Snapshot`) und Laufzeit der Berechnung, um große VIP-Teams leichter prüfen zu können
+- Checkout-Herkunft: Kundenbestellungen im Shop speichern eine vordefinierte Herkunft plus optionalen Freitext und zeigen diese im Bestelldetail an
+
+Weitere Umsetzung nach dem MVP:
+
+1. Snapshot-Command nach Migration auf Test-/Produktivdaten einmalig für abgeschlossene Monate laufen lassen.
+2. Umsatzarten weiter fachlich verfeinern, falls neben `shopping_orders.is_abo` zusätzliche Herkunftsarten zuverlässig gespeichert werden.
+3. Optional Excel-Export ergänzen, falls CSV für den Fachbereich nicht reicht.
+4. Spätere rechtliche Einschränkungen für Kundendaten nach finaler Klärung einarbeiten.
+5. `1000 Punkte Shop` nach fachlicher Abnahme ggf. um weitere Herkunftsarten erweitern.
+
 ### Datenmodell und Definitionen
 
 Einheitliche Metriken:
@@ -325,7 +367,7 @@ Jede Detailansicht muss sicherstellen:
 
 - Fachliche Definitionen finalisieren
 - `BackofficeDashboardService` erstellen
-- Stufe-1-Linienübersicht mit Linien 1 bis 8 und Summenzeile bauen
+- Stufe-1-Linienübersicht mit allen tatsächlich vorhandenen Linien und Summenzeile bauen
 - bestehende Dashboard-Kachel durch Link auf neue Statistikseite ergänzen oder neue Seite im Menü aufnehmen
 - Kennzahlen noch ohne vollständigen Deep Dive, aber bereits sauber berechnet
 
@@ -346,10 +388,10 @@ Jede Detailansicht muss sicherstellen:
 
 ### Phase 4: Herkunftsabfrage im Checkout
 
-- Migration und Model-Fillable ergänzen
-- Checkout-Formular erweitern
-- Validierung und Speicherung ergänzen
-- Admin-/Bestelldetail oder Export um Feld erweitern
+- umgesetzt: Migration `shopping_orders.customer_order_source` und `customer_order_source_comment`
+- umgesetzt: Checkout-Formular für Shop-Kundenbestellungen (`is_from = shopping`) mit Auswahlfeld plus optionalem Freitext
+- umgesetzt: Validierung und Speicherung in `CheckoutController` / `CheckoutRepository`
+- umgesetzt: Anzeige im Bestelldetail für `payment_for = 6`
 
 ### Phase 5: Storno-Qualitätssicherung
 
@@ -370,7 +412,7 @@ Jede Detailansicht muss sicherstellen:
 Feature-Tests:
 
 - Dashboard zeigt nur Daten der eigenen Downline.
-- Linien 1 bis 8 werden korrekt gruppiert.
+- alle tatsächlich vorhandenen Linien werden korrekt gruppiert.
 - Summenzeile entspricht Summe der Linien.
 - Klick auf Teamabos zeigt nur `is_for = 'me'` in der Downline.
 - Klick auf Kundenabos im Team zeigt nur `is_for = 'ot'` mit `member_id` in der Downline.
@@ -395,13 +437,21 @@ Regressionsprüfung:
 ## Offene Fachfragen
 
 1. Soll die neue Statistik die aktuelle Monatslogik nutzen oder standardmäßig den letzten abgeschlossenen Monat zeigen?
+//beides, Wichtig ist immer der aktuelle Monat, das hier um Qualität zahlen gibt und natürlich auch die letzten abgeschlossenen Monat. Hier können wir natürlich auch in Datenbanken entsprechend die Kennzahlen speichern und nicht immer hohe Quere an die Datenbank zu senden.
 2. Sollen Stornos im Stornomonat oder im ursprünglichen Umsatzmonat gegengerechnet werden?
+//ist noch zu prüfen Wird umgesetzt, sobald hier eine deutliche Klärung stattgefunden hat
 3. Wie genau wird "1000 Punkte Shop" definiert: nur Shop-Punkte, alle Kundenpunkte oder Kundenabos plus Einzelbestellungen?
+Ich würde hier erst mal alle Punkte zusammenziehen also Kunden funkte Kunden Abos Einzelbestellungen etc. alles was in die einzelnen Punkte des Kunden geht. Zusätzlich würde ich's einmal trennen nach Eigenpunkten und externen Punkten. D.h. grundsätzlich würde ich hier auch eine Trennung vornehmen der einzelnen Shop Punkte, Kunden, Abos, Einzelbestellung etc.
 4. Welche Kundendaten dürfen Berater in Deep-Dive-Listen sehen?
+In der Entwicklung zeigen wir erst mal die gesamten Inhalte an. Mit einem Hinweis wird gerade rechtlich geklärt.
 5. Ist die Herkunftsabfrage Freitext, Auswahlfeld oder Kombination?
+Kombination ein Auswahlfeld von vordefinierten Sachen alternativ Freitext
 6. Gilt die Herkunftsabfrage für alle Checkout-Flows oder nur für externe Kundenbestellungen?
+Nur für Kundenbestellung in den Shops
 7. Darf eine Incentive-Teilnahme bereits Name/Foto/Land freigeben oder braucht es ein separates Opt-in?
-8. Soll das Event-Archiv nur Bilder und Texte enthalten oder eine echte Galerie mit Mehrfachuploads?
+Auch hier befindet sich noch beim Rechtsanwalt in Klärung. Hier würde ich erst mal einbauen Und mit Hinweisen versehen, die dann gegebenenfalls später rausgenommen werden müssen
+8. Soll das Event-Archiv nur Bilder und Texte enthalten oder eine echte Galerie mit Mehrfachuploads? 
+Echte Galerie mit mehrfach Upload
 
 ## Empfehlung
 
@@ -415,3 +465,15 @@ Priorität für die erste Umsetzung:
 4. 1000-Punkte-Shop
 5. Checkout-Herkunft und Storno-Tests
 6. Incentive-Sichtbarkeit und Event-Archiv
+
+
+
+Snapshots/Caching: Abgeschlossene Monate speichern, damit große Teams nicht jedes Mal live berechnet werden.
+php artisan migrate
+php artisan backoffice:store-statistics-snapshots
+php artisan list backoffice
+1000-Punkte-Shop verfeinert: zählt weiter Berater ab 1000 Gesamtpunkten und zeigt in der Detailansicht den aktuellen Karriere-Level statt einer fachlich erklärungsbedürftigen Qualifikations-Einteilung.
+Datenschutz-Hinweis umgesetzt: Detailansichten weisen sichtbar darauf hin, dass personenbezogene Daten rechtlich noch final geklärt werden.
+Übersichts-Export umgesetzt: CSV-Export steht auch direkt in der Linienübersicht zur Verfügung.
+Tests ausgebaut: CSV-Inhalte und Zeitraum-Erhalt sind näher am Controller-/Export-Flow abgesichert; Abo-Statusgrund und neue Abo-Markierung sind im Service-Test abgedeckt.
+Performance prüfen: Bei echten VIP-Accounts mit großem Team messen, ob die Live-Queries schnell genug sind.