mivita/dev/2026-07-22/entwicklungskonzept.md

Entwicklungskonzept — To-Dos vom 2026-07-22

Basis: dev/2026-07-22/todos.md (Kundenwünsche). Stand der Code-Analyse: 2026-07-22. Noch kein Code geändert — dieses Dokument ist die Planungsgrundlage.

Die To-Dos zerfallen in zwei Blöcke:

• A — Abo-Verwaltung: Pause-Funktion, Kündigung
• B — Statistiken & Dashboard: Home-Dashboard, VIP-Statistik (/user/backoffice/statistics), Abo-Statistik

Die Führungskräfte-Statistik taucht in der To-Do-Liste dreimal auf (Z. 35–36, 62–64, 67–74) — inhaltlich ist das eine Anforderung (→ B7).

---

Übersicht der Arbeitspakete

#	Arbeitspaket	Ist-Stand	Aufwand	Offene Fragen
A1	Abo-Pause (1 Monat, Regeln)	Nur Aktiv/Inaktiv-Toggle, keine Terminverschiebung	mittel	F1, F2
A2	Abo-Kündigung prüfen/finalisieren	Weitgehend vorhanden (Status 4 + Bestätigung)	klein	F3, F4
B1	Provision „Stand heute" (Home + Statistik-Übersicht)	Provision nur monatlich per Batch, admin-only	groß	F5, F6
B2	Abo-Zahlen bei Monatswechsel aktuell	Snapshot friert Bestandszahlen ein	klein–mittel	F7
B3	Neupartner-Liste: Sponsor + Kundenpunkte	Beides fehlt im Drilldown	klein	–
B4	1000-Punkte-Shop: eigene Person zählt mit	Nur Team, Root-User ausgeschlossen	klein	–
B5	Top-10 Kundenabos (Anzahl)	Existiert nicht	klein–mittel	F8
B6	Top-10 Kundenabos (Umsatz/Punkte)	Existiert nicht	klein–mittel	F8
B7	Führungskräfte-Statistik: 4 Kennzahlen + Summe	Nur eigene Abos + eigene Kundenabos	mittel	F9
B8	Abo-Gesamtumsatz in der Payline	Existiert nicht	mittel	F10
B9	„Neue Abos" klickbar → wer sind sie	Nur +N-Badge, kein gefilterter Drilldown	klein	–
B10	Payline-Prognose zum 5./10./20./25.	Existiert nicht; Datenbasis vorhanden	mittel–groß	F11, F12

Update 2026-07-22: Alle Fragen wurden vom Kunden beantwortet — Zusammenfassung im Abschnitt „Entscheidungen" am Ende. Die Entscheidungen sind in die Arbeitspakete unten eingearbeitet. Einzig F12 bleibt eine dokumentierte Annahme (Vorschlag umgesetzt, Kunde prüft nach Umsetzung — siehe B10).

Umsetzungsstand (2026-07-22): ✅ B3, B4, B9 und A2 sind umgesetzt (inkl. Tests: AboOneAboRuleTest, Erweiterungen in BackofficeStatisticsDrilldownTest/BackofficeStatisticsAccessTest). Zu A2: Die Ein-Abo-Prüfungen (AboHelper::userHasAbo/memberHasAbo/hasAboByEmail) blockierten tatsächlich auch nach Kündigung (status >= 1 schloss Status 4/5 ein) — behoben; abo-min-duration hat jetzt Code-Default 6 (AboHelper::DEFAULT_ABO_MIN_DURATION). Offen aus diesem Paket: Produktions-Setting abo-min-duration auf 6 prüfen.

✅ B1 ist umgesetzt (Tests: LiveCommissionServiceTest) — damit sind ALLE Arbeitspakete dieses Konzepts umgesetzt. Neuer App\Services\BusinessPlan\LiveCommissionService: Der bestehende Live-TreeCalcBot-Lauf berechnet entgegen der ursprünglichen Analyse bereits alle drei Provisionsbestandteile (commission_shop_sales in makeUser(), commission_pp_total/commission_growth_total in calcQualPP()) — es brauchte nur einen dünnen Service mit 6-h-Cache (F5). Liegt für den Monat ein UserBusiness-Datensatz vor (Monats-Batch gelaufen), gilt dieser als final (kein Live-Badge). Anzeige: Kachel „Provision (Stand heute)" auf dem Home-Dashboard für jeden Berater (F6) im Umsatz-Cluster (Gesamtwert in €, Live-Badge) + KPI-Card auf der VIP-Statistik-Übersicht mit Aufschlüsselung Payline/Shop/WB.

✅ B8 + B10 sind umgesetzt (Tests: PaylineForecastServiceTest): Neuer App\Services\Abo\PaylineForecastService. Payline = die ersten N Ebenen der Downline, N kommt live aus dem Provisionslevel (TreeCalcBot/BusinessUserItem::getQualLevelPaylines(), kein Bot-Umbau nötig); Kontext (N + Mitglieder-IDs) 6 h gecacht. B8: Karte „Abo-Umsatz in der Payline" auf der Team-Abo-Seite mit Soll (Abo-Punkte pro Zyklus, Berater- + Kundenabos der Payline) und Ist (im Monat abgerechnete Abo-Punkte, neues SQL-Fragment SalesVolumePoints::aboPoints()). B10: vier Prognose-Kacheln auf dem Home-Dashboard (nur laufender Monat): Basis = Kundenumsatz + Payline-Punkte heute, plus kumuliert die bis zum 5./10./20./25. noch offenen Abo-Punkte (next_date > heute); vergangene Termine ausgegraut. F12 wie vorgeschlagen umgesetzt: eigene Abos + eigene Kundenabos zählen mit — Schalter PaylineForecastService::INCLUDE_OWN_ABOS (Default true), ohne Umbau umkehrbar. → Rückfrage an den Kunden nach Livegang: Soll das so bleiben oder sollen nur die Payline-Abos zählen?

✅ A1 ist umgesetzt (Tests: AboPauseTest): Button „1 Monat pausieren" im Abo-Einstellungs-Modal (Berater + Kunden-Portal, nicht Admin-View), verschiebt next_date um genau einen Zyklus auf den gleichen Liefertag des Folgemonats, Abo bleibt aktiv (Status 2). Regeln serverseitig in AboRepository::pauseOneMonth(): 3-Tage-Sperre vor Ausführung, Mindestlaufzeit (abo-min-duration, wie Kündigung), max. 1 Pause pro X Monate rollierend über neues Setting abo-pause-interval-months (Code-Default 6, AboHelper::DEFAULT_PAUSE_INTERVAL_MONTHS). Neue Felder last_pause_date/pause_count an user_abos + neue Tabelle user_abo_status_histories — protokolliert jetzt Pause, Kündigung, Deaktivierung und Reaktivierung (wer/wann/View + Terminverschiebung). UI zeigt bei gesperrter Pause den Hinweis „wieder möglich ab …". Sprachkeys in de/en/es/fr ergänzt (du-Form).

✅ B2, B5/B6 und B7 sind umgesetzt (Tests in BackofficeStatisticsListsTest): Führungskräfte-Liste mit Teamabos/Team-Kundenabos je Führungskraft (Abschneiden an der nächsten Führungskraft, additive Summen) + Gesamt-Spalte; zwei Top-10-Karten „Kundenabos (Anzahl)" und „Kundenabos (Umsatz)" mit Soll (Abo-Punkte-Bestand) und Ist (abgerechnete Kundenabo-Punkte des Monats); Snapshot-Monate überlagern die Abo-Bestandszahlen (Linien, Summen, Führungskräfte, Top 10) jetzt live — Badge „Abo-Bestände tagesaktuell" in der Übersicht, Monats-Punkte/-Umsätze und „+N neu" bleiben eingefroren. Noch offen: A1 (Pause), dann B8+B10 und B1.

---

Block A — Abo-Verwaltung

A1 — Pause-Funktion (max. 1× pro 6 Monate, verschiebt um 1 Monat)

Kundenwunsch: Pausieren erst nach 6 Monaten möglich, maximal 1× in 6 Monaten, Pause = 1 Monat, die Ausführung verschiebt sich um einen Monat. Button in den Abo-Einstellungen.

Ist-Stand:

• Es gibt heute keine echte Pause. Der Toggle „aktiv" in den Abo-Einstellungen setzt Status 2 ↔ 6 (AboRepository::updateStatus(), AboRepository.php:102-127). Dabei wird next_date nicht verschoben — das Abo steht einfach still, bis es jemand wieder aktiviert.
• Sperrfrist existiert: 3 Tage vor Ausführung keine Pause/Kündigung (Setting abo-lock-days-pause-cancel).
• Es gibt keine Historie für Pause-Aktionen — man kann heute nicht feststellen, wann/wie oft ein Abo pausiert wurde.

Konzept:

1. Neuer Button „1 Monat pausieren" im Abo-Einstellungs-Modal (modal_abo_update.blade.php) für Berater- und Portal-View (mit Bestätigungsabfrage, analog Kündigen-Button).
2. Wirkung: next_date wird um genau einen Ausführungs-Zyklus verschoben (nächster abo_interval-Tag im Folgemonat via AboHelper::setNextDate()). Das Abo bleibt aktiv (Status 2) — kein Status-Wechsel nötig, dadurch bleiben alle Statistiken konsistent.
3. Neue Felder an user_abos (Migration): last_pause_date (Datum der letzten Pause) und pause_count — oder alternativ Pause-Einträge in einer kleinen Historie (siehe Punkt 5).
4. Regeln (serverseitig in AboHelper/AboRepository, UI blendet Button entsprechend aus):
   • Erlaubt erst ab 6 bezahlten Lieferungen (entschieden, F1) — gleiche Basis wie Kündigung: getCountPaidOrders() gegen das Setting abo-min-duration; vorhandene Mechanik canCancelAbo() wird zu canPauseAbo() gespiegelt.
   • Maximal 1 Pause pro X Monate, rollierend (entschieden, F2): last_pause_date muss länger als X Monate zurückliegen. X kommt aus einem neuen Admin-Setting abo-pause-interval-months (Default 6, änderbar — vom Kunden explizit gewünscht).
   • Bestehende 3-Tage-Sperre vor Ausführung gilt auch für die Pause.
5. Historie: Pause (und idealerweise auch Kündigung, s. A2) wird protokolliert — Vorschlag: kleine Tabelle user_abo_status_histories (abo_id, action, actor_user_id, created_at) oder Erweiterung der bestehenden AboItemHistoryService-Mechanik um Status-Aktionen. Ohne Log ist die „1× in 6 Monaten"-Regel nicht sauber durchsetzbar und nicht nachvollziehbar.
6. Selfservice-Regel beachten: wie bei den Lock-Settings gilt die Prüfung auf Basis des Consultant-Views, kein Admin-Bypass im Selfservice-Bereich (Admin-Bereich darf weiterhin frei agieren).

Abgrenzung: Der bestehende Aktiv/Inaktiv-Toggle bleibt unverändert bestehen (Admin-Werkzeug); die neue Pause ist eine separate, regelgebundene Funktion.

A2 — Kündigung nach 6. Lieferung („bitte noch mal genau prüfen")

Kundenwunsch: Kündigung nach der 6. Lieferung, monatlich, über Berater oder Kunden-Login. Button „Abo jetzt kündigen" + Rückfrage, dann Entfernung (Softdelete).

Ist-Stand — weitgehend vorhanden:

• Kündigen-Button mit confirm()-Rückfrage existiert im Abo-Einstellungs-Modal für Berater- und Portal-View (modal_abo_update.blade.php:110-116).
• Mindestlaufzeit wird über AboHelper::canCancelAbo() gegen das Setting abo-min-duration geprüft (Zählung: bezahlte + extern erledigte Lieferungen). Vorher wird der Button gar nicht angezeigt, stattdessen ein Hinweis mit Rest-Lieferungen.
• Kündigung setzt status = 4 (storniert), active = false, cancel_date = now() — kein Softdelete. 3-Tage-Sperre vor Ausführung greift.

Prüf-/Restpunkte:

1. Setting-Wert kontrollieren: abo-min-duration hat keinen Code-Default und keinen Seeder — fehlt der DB-Eintrag, ist die Mindestlaufzeit faktisch 0. In Produktion prüfen, dass das Setting auf 6 steht, zusätzlich Default 6 im Code hinterlegen. Kündigung ab der 6. bezahlten Lieferung ist bestätigt (F4) — bei rechtzeitiger Kündigung findet die 7. Lieferung nicht mehr statt.
2. Kein Softdelete, Status-Modell bestätigt (F3): Beim regulären Kündigen bleibt es bei status = 4 — das Abo bleibt für Statistik/Abrechnung nachvollziehbar und verschwindet aus den aktiven Listen.
3. Neues Abo nach Kündigung darf nicht blockiert werden (F3, wichtig): Es gilt „immer nur EIN Abo pro Kunde". Die Prüfung, die ein zweites Abo verhindert, muss gekündigte/beendete Abos (Status 4/5, soft-deleted) ignorieren — nach einer Kündigung muss sofort ein neues Abo angelegt werden können. Ist-Verhalten der Ein-Abo-Prüfung analysieren, ggf. fixen, mit Test absichern.
4. Kündigungs-Historie analog A1 (wer hat wann gekündigt — Berater oder Kunde) mitloggen.
5. Kleiner UI-Review: Button-Beschriftung/Platzierung ggf. an Kundenwunsch anpassen („Abo jetzt kündigen").

---

Block B — Statistiken & Dashboard

B1 — Provision „Stand heute" (Home-Dashboard + Statistik-Übersicht)

Kundenwunsch: Auf dem Dashboard (und auf der Übersichtsliste, Z. 46) die aktuelle Provision Stand heute anzeigen.

Ist-Stand:

• Provision wird ausschließlich per Batch business:store-optimized nach Monatsende berechnet und in UserBusiness gespeichert (commission_pp_total, commission_shop_sales, commission_growth_total). Anzeige heute nur im Admin-Bereich.
• Live läuft im HomeController bereits ein TreeCalcBot — aber nur für Payline-Punkte, nicht für Provision (HomeController.php:169-183, Cache 6 h).

Konzept:

1. Den vorhandenen Live-TreeCalcBot-Lauf so erweitern, dass zusätzlich zu payline_points auch die Provisions-Kennzahlen für den User berechnet werden (die Rechenlogik existiert in TreeCalcBot/BusinessStoreOptimized, muss aber für einen Einzel-User-Livelauf extrahiert werden).
2. Ergebnis im selben 6-h-Cache mitführen (home_payline_* → erweitern), damit kein zweiter Baum-Lauf nötig ist.
3. Anzeige: neue Kachel „Provision (Stand heute)" auf dem Home-Dashboard (_statistics.blade.php) mit „Live"-Badge + Hinweis „vorläufig, final nach Monatsabschluss"; gleiche Kennzahl als KPI-Card auf der VIP-Statistik-Übersicht.
4. Für abgeschlossene Monate: fertigen Wert aus UserBusiness anzeigen (kein Live-Lauf).

Entschieden (F5/F6): Die Kennzahl enthält alle Provisionsbestandteile (Payline/Team + Shop + Wachstum), Aktualisierung alle ~6 h reicht, und sie wird jedem Berater auf dem Home-Dashboard angezeigt (nicht nur VIP).

Risiko/Hinweis: Die Live-Provision ist rechnerisch immer „vorläufig" (Ränge/Qualifikationen können sich bis Monatsende ändern). Das muss im UI klar gekennzeichnet sein. Aufwand ist der größte im Statistik-Block, weil Provisionslogik bisher nur im Monats-Batch für den Gesamtbaum läuft. Da die Kachel für alle Berater kommt, ist die Performance des Live-Laufs (6-h-Cache pro User, Berechnung beim ersten Dashboard-Aufruf) besonders zu beachten.

B2 — Abo-Zahlen aktuell halten beim Monatswechsel

Befund (Kundenbeobachtung bestätigt): Der Monats-Snapshot (backoffice:store-statistics-snapshots) friert alle Kennzahlen ein — auch die Abo-Zahlen (Teamabos, Teamkundenabos, Führungskräfte-Liste). Diese Abo-Zahlen sind aber Bestandszahlen ohne Monatsbezug (Zählung activeAbo ohne Datumsfilter). Wählt man einen vergangenen Monat, sieht man den eingefrorenen Bestand vom Snapshot-Zeitpunkt statt aktueller Zahlen. Nur die *_neu-Zahlen sind echt monatsbezogen.

Konzept (vom Kunden bestätigt, F7): Beim Anzeigen eines Snapshot-Monats die Bestands-Kennzahlen (Abos) live nachrechnen und über den Snapshot-Payload legen; die monatsbezogenen Zahlen (Punkte, Neupartner, neue Abos) weiter aus dem Snapshot. So sind Abo-Bestände immer tagesaktuell, historische Monatswerte bleiben stabil.

B3 — Neupartner-Liste: Sponsor + tagesaktuelle Kundenpunkte

Ist-Stand: Der Drilldown der Neupartner-KPI-Card zeigt Name, E-Mail, Karriere-Level, Aktiv-seit, Account-Gültigkeit — weder Sponsor noch Punkte.

Konzept: BackofficeDrilldownService::newPartnerRows() erweitern:

• Sponsor: Join auf m_sponsor → Sponsorname als Spalte.
• Kundenpunkte (tagesaktuell): externalPoints-Summe des laufenden Monats je Neupartner über die vorhandenen SalesVolumePoints-SQL-Fragmente.
• View details.blade.php um die beiden Spalten ergänzen. Kleiner, klar umrissener Eingriff.

B4 — 1000-Punkte-Shop: eigene Person zählt mit

Ist-Stand: lineBuckets() beginnt bei den Kindern des Root-Users — der VIP selbst ist in shop1000Count() und im Drilldown nie enthalten (gleiches Muster auf dem Home-Dashboard via activeTeamUserIds()).

Konzept: Für die 1000-Punkte-Kennzahl (KPI-Card, Drilldown, Home-KPI) die Root-User-ID mit in die geprüfte ID-Menge aufnehmen. Erreicht der User selbst ≥ 1000 Punkte, erscheint er in Zählung und Liste (z. B. mit Kennzeichnung „(ich)"). Bewusst nur für diese Metrik — die übrigen Teamzahlen bleiben ohne den Root-User.

B5 + B6 — Top-10 Kundenabos (Anzahl und Umsatz/Punkte)

Kundenwunsch: Zwei Ranglisten „unabhängig vom Incentive": Top 10 nach Anzahl Kundenabos (z. B. „Platz 1: Monika Kunz, 15 Kundenabos") und Top 10 nach Kundenabo-Umsatz in Punkten.

Ist-Stand: Es gibt bereits das Ranking „Neue Kundenabos" (nur Neuzugänge im Monat). Ein Gesamt-Ranking (Bestand) existiert nicht.

Konzept (Entscheidungen aus F8 eingearbeitet):

• Zwei neue Listen auf der VIP-Statistik-Übersicht, technisch analog newCustomerAboRanking() in BackofficeDashboardService. Scope: das eigene Team des Statistik-Nutzers (nicht unternehmensweit).
  • Top 10 Anzahl: aktive Kundenabos (is_for = ot) je Berater zählen — Gesamtbestand, unabhängig vom Incentive —, absteigend, Top 10.
  • Top 10 Umsatz mit zwei Werten „Soll" und „Ist" (Kundenwunsch):
    • Soll = Abo-Punkte-Bestand je Berater (Produktpunkte × Menge der laufenden Kundenabos, getTotalPoints()-Logik als SQL-Summe) — was die Abos pro Zyklus bringen.
    • Ist = im gewählten Monat tatsächlich abgerechneter Kundenabo-Umsatz (Abo-Punkte aus user_sales_volumes über die SalesVolumePoints-Fragmente).
    • Sortierung nach Soll, Ist als zweite Wertspalte daneben.
• Darstellung mit Platz-Nummerierung (Platz 1, 2, …), Name, Wert(e); Linie/Level klein darunter wie bei den bestehenden Listen.

B7 — Führungskräfte-Statistik: 4 Kennzahlen + Gesamtsumme

Kundenwunsch (3× in der Liste genannt, eine Anforderung): Pro Führungskraft (ab Vertriebsleiter): eigenes Abo, eigene Kundenabos, Teamabos, Kundenabos im Team, plus Summe aller 4 Kennzahlen.

Ist-Stand: Die Liste „Abos Führungskräfte" (leaderAboOverview()) zeigt nur die eigenen Abos und eigenen Kundenabos je Führungskraft. Downline-Aggregate pro Führungskraft gibt es nicht.

Konzept:

1. leaderAboOverview() erweitern: pro Führungskraft den eigenen Teilbaum ermitteln (BFS über m_sponsor, Mechanik aus lineBuckets()/teamUserIds() wiederverwendbar) und darauf zählen:
   • team_abo_count: aktive Berater-Abos (is_for = me) der Downline
   • team_customer_abo_count: aktive Kundenabos (is_for = ot) der Downline
2. Neue Spalten + Summenspalte total = own + own_customer + team + team_customer in index.blade.php, Sortierung nach Summe.
3. Performance: Teilbäume aller Führungskräfte einmalig aus einer gemeinsamen Sponsor-Map im Speicher ableiten (ein Query für alle User-Beziehungen, keine N Abfragen pro Leader). Ergebnis landet mit im Monats-Snapshot (alte Snapshots zeigen dann den bestehenden „bitte Snapshot neu erzeugen"-Hinweis).
4. Zählweise (entschieden, F9): an der nächsten Führungskraft abschneiden. Der Teilbaum einer Führungskraft endet, sobald darunter die nächste Führungskraft (ab Vertriebsleiter) beginnt — deren Team zählt nur bei ihr selbst. Vorteil: keine Überlappungen, die Teamzahlen der Führungskräfte sind untereinander additiv.

B8 — Abo-Gesamtumsatz in der Payline (Abo-Statistik)

Kundenwunsch: Auf der Abo-Statistik zusätzlich den Abo-Gesamtumsatz in der Payline ausweisen.

Ist-Stand: Die Team-Abo-Seite zeigt Abo-Punkte pro Linie und gesamt (Bestandspunkte). Eine Verknüpfung „Abo-Punkte ∩ Payline" existiert nicht; die Payline wird nur im Live-TreeCalcBot als Gesamtpunktzahl berechnet.

Konzept (entschieden, F10 — „Soll und Ist"): Die Payline-Berechnung liefert (bzw. kann liefern), welche Linien/User in der Payline des Users liegen. Darauf aufbauend zwei Kennzahlen auf der Abo-Statistik-Seite, gecacht analog home_payline_*:

• Soll = Summe der aktiven Abo-Punkte aller Payline-Mitglieder (Berater-Abos + Kundenabos), Stand heute.
• Ist = im laufenden Monat bereits abgerechneter Abo-Umsatz der Payline-Mitglieder (aus user_sales_volumes).

Voraussetzung ist, dass der Live-Bot die Payline-Mitglieder-IDs exponiert (kleine Erweiterung an TreeCalcBot).

B9 — „Neue Abos" klickbar: wer sind sie?

Ist-Stand: Die +N-Badges (Home-Dashboard-Kacheln und VIP-Übersicht) sind reine Anzeige; die Kacheln verlinken nur auf generische Abo-Listen. Der Abo-Drilldown markiert neue Abos mit „Neu"-Badge, filtert aber nicht.

Konzept: Der vorhandene Abo-Drilldown (metric=team_partner_abos / team_customer_abos) bekommt einen Filter-Parameter only_new=1 (Filter auf start_date im gewählten Monat — Logik aus newAboCount() existiert). Die +N-Badges werden zu Links auf den gefilterten Drilldown. Auf dem Home-Dashboard verlinken die Badges auf dieselben Drilldowns.

B10 — Payline-Prognose: voraussichtlicher Gesamtumsatz am 5./10./20./25.

Kundenwunsch: Vier Kennzahlen auf der Übersicht (HOME): voraussichtlicher Payline-Gesamtumsatz zum 5./10./20./25. = aktueller Kundenumsatz + Payline-Gesamtumsatz Stand heute + Abo-Umsätze der Payline, die bis zum jeweiligen Termin dazukommen. Ziel: Anfang des Monats absehen, wo die Payline an den Ausführungsterminen stehen wird.

Ist-Stand / Datenbasis (gut vorhanden):

• Feste Ausführungstage existieren als UserAbo::$aboDeliveryDays = [5, 10, 20, 25]; jedes Abo trägt abo_interval (gewählter Tag) und next_date (konkreter nächster Termin).
• Punkte je Abo über getTotalPoints() (Produktpunkte × Menge).
• Aktueller Kundenumsatz und Live-Payline-Punkte werden auf dem Home-Dashboard bereits berechnet.
• Eine Auswertung „Abo-Umsätze pro Ausführungstag" existiert noch nirgends.

Konzept:

1. Neuer Service (z. B. PaylineForecastService): ermittelt für den laufenden Monat je Termin T ∈ {5, 10, 20, 25}: Prognose(T) = Kundenumsatz heute + Payline-Punkte heute + Σ Abo-Punkte aller aktiven Abos in der Payline mit next_date im laufenden Monat und Tag ≤ T, die heute noch nicht ausgeführt sind. Bereits ausgeführte Abos stecken automatisch im Ist-Umsatz und werden nicht doppelt gezählt (Abgrenzung über next_date > heute).
2. Kumulative Logik (bestätigt, F11): die Prognose zum 25. enthält auch die Termine 5./10./20. (sofern noch offen) — „so steht die Payline am 25.".
3. Payline-Zugehörigkeit der Abos — Annahme zu F12 (vom Kunden noch nicht final entschieden):
   • Vorschlag/Umsetzung: Die eigenen Abos und eigenen Kundenabos des Beraters zählen mit — zusätzlich zu den Abos der Payline-Downline (Mitglieder-Menge wie B8). Begründung: Die Basis der Formel enthält den aktuellen Kundenumsatz; kommende eigene Abo-Ausführungen erhöhen genau diesen Anteil. Ohne sie wäre die Prognose systematisch zu niedrig.
   • Umsetzungs-Notiz (wichtig): Die Auswahl wird an EINER Stelle im PaylineForecastService gekapselt (Parameter/Konstante includeOwnAbos, Default true), sodass die Entscheidung später ohne Umbau umkehrbar ist. Nach der Umsetzung bekommt der Kunde eine Notiz, wie es umgesetzt wurde, mit der Frage, ob es so bleiben soll (siehe Entscheidungen, F12).
4. Anzeige: vier Kacheln (oder eine kleine Tabelle „Prognose") auf dem Home-Dashboard mit „Live"-Kennzeichnung; Cache zusammen mit home_payline_* (6 h), tagesaktuell wie vom Kunden beschrieben.
5. Ausfall-Risiken (fehlgeschlagene Zahlungen, Pausen, Kündigungen bis zum Termin) machen die Zahl naturgemäß zur Prognose — im UI so benennen.

B8 und B10 teilen sich die Grundlage „Payline-Mitglieder + deren aktive Abos" und sollten zusammen umgesetzt werden.

---

Empfohlene Umsetzungsreihenfolge

1. Schnelle, klar definierte Pakete: B3, B4, B9, A2 (Prüfung/Feinschliff)
2. Statistik-Ausbau: B5/B6, B7, B2
3. Abo-Pause: A1 (nach Klärung F1/F2)
4. Payline/Provision (aufwändig, gemeinsame Basis): B8 + B10, danach B1

---

Entscheidungen (Kundenantworten vom 2026-07-22)

#	Frage (Kurzform)	Entscheidung
F1	Pause-Voraussetzung	6 bezahlte Lieferungen (wie Kündigung, gegen abo-min-duration)
F2	Pause-Zyklus	Rollierend: letzte Pause muss X Monate zurückliegen; X als änderbares Setting (abo-pause-interval-months, Default 6)
F3	Kündigung „Softdelete"	Status-Modell bestätigt (nachvollziehbar für Statistik/Abrechnung). Wichtig: Nach Kündigung darf die Ein-Abo-Regel ein neues Abo nicht blockieren — gekündigte Abos zählen bei der Prüfung nicht mit
F4	Mindestlaufzeit Kündigung	Bestätigt: ab der 6. bezahlten Lieferung; Setting in Produktion auf 6 + Code-Default 6
F5	Provision live — Umfang	Alle Bestandteile (Payline + Shop + Wachstum); Aktualisierung alle ~6 h
F6	Provision live — Sichtbarkeit	Jeder Berater (Home-Dashboard)
F7	Abo-Zahlen bei Monatswechsel	Wie empfohlen: Abo-Bestände live/tagesaktuell, Monats-Punkte/-Umsätze bleiben eingefroren
F8	Top-10-Listen	a) Scope: eigenes Team; b) Bestand aktiver Kundenabos, unabhängig vom Incentive; c) Umsatz-Ranking mit Soll UND Ist
F9	Verschachtelte Führungskräfte	An der nächsten Führungskraft abschneiden (keine Überlappung, Zahlen additiv)
F10	Payline-Abo-Umsatz	Soll und Ist (Abo-Punkte-Bestand + abgerechneter Monatsumsatz)
F11	Prognose kumuliert	Ja, kumuliert (25. enthält 5./10./20.)
F12	Eigene Abos in der Prognose	Vom Kunden offen gelassen — siehe unten

F12 — dokumentierte Annahme (Kunde entscheidet nach Umsetzung)

Der Kunde konnte nicht entscheiden, ob eigene Abos/eigene Kundenabos des Beraters in die Payline-Prognose (B10) einfließen; wir sollen einen Vorschlag umsetzen und dokumentieren.

• Umgesetzt wird (Vorschlag): Eigene Abos + eigene Kundenabos zählen mit, weil die Prognose-Basis den aktuellen Kundenumsatz enthält und kommende eigene Abo-Ausführungen genau diesen erhöhen. Ohne sie wäre die Prognose systematisch zu niedrig.
• Umkehrbar: Die Auswahl liegt an einer Stelle im PaylineForecastService (Schalter includeOwnAbos, Default true).
• Offener Punkt an den Kunden nach Umsetzung: „Die Prognose zum 5./10./20./25. enthält auch deine eigenen Abos und deine Kundenabos. Soll das so bleiben oder sollen nur die Team-Abos der Payline zählen?"