From 979a12d1cbd1e19ef5dd4108edcadbbf7a537d1d Mon Sep 17 00:00:00 2001 From: Kevin Date: Fri, 25 Sep 2026 10:28:27 +0000 Subject: [PATCH] Doku: Deploy-Stand 25.09. markiert, Challenge-Start 9. Oktober A1-A4 und E1 live seit 23.09., B2, A07, Abo-Warnung und E1-Nachtraege live seit 25.09., Settings auf 0, Montenegro beendet. Offen: erster user:cleanup-Lauf, Seeder fuer den Challenge-Start 09.10. Co-Authored-By: Claude Opus 5.5 (1M context) --- .../audit-statistiken-2026-09-09-bewertung.md | 4 +- dev/2026-07-22/deploy-2026-09-22-e1.md | 10 ++-- ...2026-09-18-recruiting-challenge-inhalte.md | 50 ++++++++++--------- ...-09-23-mitgliedschaft-ablauf-uebersicht.md | 4 +- ...twicklungsplan-protokoll-september-2026.md | 47 +++++++++-------- 5 files changed, 61 insertions(+), 54 deletions(-) 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 6f8fe197..c4e27b96 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 @@ -42,7 +42,7 @@ offen so benannt; genau diese Lücke schließt die folgende Bewertung. | **A13** | Der heutige Liefertag zählt zur Prognose, solange die Ausführung aussteht | [15](#15-nachtrag-10092026--a11-a13-und-a14-behoben-randfälle) | | **A14** | Tabellen sortieren über unformatierte Werte statt über den Anzeigetext | [15](#15-nachtrag-10092026--a11-a13-und-a14-behoben-randfälle) | | **R01–R03** | Befunde der Nachprüfung an der eigenen Umsetzung | [11](#11-nachtrag-10092026--r01-r02-und-r03-behoben) | -| **A07** | Payline-Kontext (Home-Kacheln „Teampartner/Abos in der Payline“, Payline-Prognose) nimmt die Mitglieder aus dem Provisionsbaum wie Team-Statistik und Level-Prognose — umgesetzt 23.09. An der Live-Kopie betrifft das 102 von 162 Beratern mit Payline (z. B. 527 → 403 Mitglieder). Nach dem Deploy `cache:clear` (6-h-Cache `payline_context_*`). | `PaylineForecastService::buildPaylineContext()`, Test in `PaylineForecastServiceTest` | +| **A07** | Payline-Kontext (Home-Kacheln „Teampartner/Abos in der Payline“, Payline-Prognose) nimmt die Mitglieder aus dem Provisionsbaum wie Team-Statistik und Level-Prognose — umgesetzt 23.09., **live seit 25.09.** An der Live-Kopie betrifft das 102 von 162 Beratern mit Payline (z. B. 527 → 403 Mitglieder). `cache:clear` nach dem Deploy ist erledigt (6-h-Cache `payline_context_*`). | `PaylineForecastService::buildPaylineContext()`, Test in `PaylineForecastServiceTest` | Dazu zwei Regeln, die dabei entschieden wurden: @@ -264,7 +264,7 @@ Aufwand grob geschätzt, jeweils inklusive Regressionstest. | 2 | **A02, A03** | Übersicht, Detail und persönliche Statistik müssen dieselbe Punktedefinition benutzen — das hat die Kundin bereits mehrfach angemerkt. | 0,5 Tag | erledigt | | 2 | **A08, A19** | Beides sichtbare Löcher für neue Berater bzw. im Fehlerfall; kleine, isolierte Änderungen. | 0,5 Tag | erledigt | | 3 | **A04, A12** | Zeitbezug historischer Auswertungen sauber trennen. Konzeptionell die aufwendigste Gruppe. | 1–2 Tage | erledigt | -| 3 | **A07** | Gemeinsamer Payline-Kontext; berührt K11 und sollte mit dessen Entscheidung zusammen geplant werden. | 0,5 Tag | **offen** | +| 3 | **A07** | Gemeinsamer Payline-Kontext; berührt K11 und sollte mit dessen Entscheidung zusammen geplant werden. | 0,5 Tag | erledigt, live 25.09. | | 4 | **A10, A17, A18** | Kleine, unabhängige Korrekturen; als Sammelpaket sinnvoll. | 1 Tag | erledigt | | 4 | **A21, A14** | Mehrsprachigkeit und lokalisierte Sortierung. | | **offen** | | 5 | **A01, A16** | Vorsorge: Regel serverseitig festziehen, Statushistorie in allen Schreibpfaden protokollieren. Kein aktueller Schaden. | 0,5 Tag | **offen** | diff --git a/dev/2026-07-22/deploy-2026-09-22-e1.md b/dev/2026-07-22/deploy-2026-09-22-e1.md index 0231a99a..bb242de7 100644 --- a/dev/2026-07-22/deploy-2026-09-22-e1.md +++ b/dev/2026-07-22/deploy-2026-09-22-e1.md @@ -1,4 +1,6 @@ -# Deploy 22.09.2026 — E1 Recruiting Challenge (vorbereitet, noch nicht live) +# Deploy 22.09.2026 — E1 Recruiting Challenge (live seit 23.09.) + +> **Stand 25.09.:** Deployt am 23.09., Nachträge (Gleichstand, Zählung nach Zahlungsdatum, Schalter „Abos berücksichtigen“) live seit 25.09. Montenegro ist beendet. Start der Challenge verschoben auf den **9. Oktober**; Seeder mit neuem Datum und EN/ES/FR-Texten erneut einspielen (`php artisan db:seed --class=RecruitingChallenge2026Seeder --force`). Aktueller Stand im [Entwicklungsplan E1](../_tickets/entwicklungsplan-protokoll-september-2026.md). Paket aus dem [Entwicklungsplan E1](../_tickets/entwicklungsplan-protokoll-september-2026.md), Inhalte in [2026-09-18-recruiting-challenge-inhalte.md](../_tickets/2026-09-18-recruiting-challenge-inhalte.md). @@ -88,7 +90,7 @@ an, keine Prämie, für alle sichtbar). Kein Snapshot-Neuaufbau, keine Datenänd 2. Status auf „Aktiv“ stellen. Sichtbar ist die Challenge dann nur für VIP-Konten (Sidenav mit Badge „VIP“, Dashboard-Karte, Seite `/incentive/recruiting-challenge-2026-27`). 3. Nach Freigabe durch Dani/Alois: Haken „Nur für VIP sichtbar“ entfernen. Ab dann sehen alle Berater die Challenge. -Gezählt wird ab 01.10. automatisch, unabhängig vom Zeitpunkt der Freischaltung (`incentive:calculate` +Gezählt wird ab 09.10. (bis 24.09. geplant: 01.10.) automatisch, unabhängig vom Zeitpunkt der Freischaltung (`incentive:calculate` läuft täglich 05:00 für alle aktiven Incentives). ## Woran man merkt, dass etwas nicht stimmt @@ -100,5 +102,5 @@ läuft täglich 05:00 für alle aktiven Incentives). ## Offen (nicht in diesem Paket) -Gleichstandsregel „zuerst erreicht“, Storno entfernt Wertung, Export nur bestätigte Teilnehmer, Übersetzungen -EN/ES/FR — siehe Abschnitte 9 und 10 der Inhaltsvorlage. Vor dem 01.10. nur die Gleichstandsregel nötig. +~~Gleichstandsregel „zuerst erreicht“~~ (live 25.09.), Storno entfernt Wertung, Export nur bestätigte Teilnehmer, +~~Übersetzungen EN/ES/FR~~ (im Seeder, 25.09.) — siehe Abschnitte 9 und 10 der Inhaltsvorlage. diff --git a/dev/_tickets/2026-09-18-recruiting-challenge-inhalte.md b/dev/_tickets/2026-09-18-recruiting-challenge-inhalte.md index 34f55fb3..1c3f3521 100644 --- a/dev/_tickets/2026-09-18-recruiting-challenge-inhalte.md +++ b/dev/_tickets/2026-09-18-recruiting-challenge-inhalte.md @@ -1,7 +1,7 @@ # Recruiting Challenge Oktober 2026 bis Januar 2027: Inhalte und Abstimmung -**Stand:** 22.09.2026 (Texte überarbeitet, Bonus festgelegt, Challenge lokal angelegt) · **Zweck:** Vorlage für die Abstimmung mit Dani/Alois. Technik ist fertig (E1, Commit `b28f51b`), die Texte sind fertig formuliert und als Seeder hinterlegt. Offen sind noch das Bild (liefert Kevin) und die Entscheidungen in Abschnitt 9. -**Bezug:** [Entwicklungsplan E1](entwicklungsplan-protokoll-september-2026.md#e1--recruiting-challenge-oktoberjanuar--umgesetzt-1809-deploy-offen) +**Stand:** 25.09.2026 · **Live seit 23.09.** (nur VIP sichtbar). Start verschoben auf den **9. Oktober** (Kundenentscheid 25.09.), Texte entsprechend angepasst, EN/ES/FR-Übersetzungen im Seeder. Gleichstandsregel und Zählung nach Zahlungsdatum sind live, Abos zählen nicht (Schalter „Abos berücksichtigen“ aus). Offen: Seeder mit neuem Datum auf Produktion einspielen, Freigabe für alle Berater, die Regelfragen 2 bis 7 in Abschnitt 9. +**Bezug:** [Entwicklungsplan E1](entwicklungsplan-protokoll-september-2026.md#e1--recruiting-challenge-oktoberjanuar--live-seit-2309-nur-vip-start-0910) --- @@ -9,11 +9,11 @@ Jeder direkt gesponserte Neupartner zählt, sobald er im Zeitraum eine Registrierung mit Starterpaket bezahlt hat. Reine Mitgliedschaft ohne Paket zählt nicht. Bestandskunden, die zum Berater werden, zählen ebenfalls (Datum der bezahlten Registrierung). -Zeitraum ist der 01.10.2026 bis 31.01.2027, jeweils nach Bestelldatum. Ein Neupartner ist ein Punkt, die Rangliste ist also die Anzahl Neupartner. Umsätze und Abos spielen keine Rolle. +Zeitraum ist der 09.10.2026 bis 31.01.2027 (bis 24.09. geplant: ab 01.10.), jeweils nach Zahlungsdatum der Registrierung (live seit 25.09., wie in der Statistik). Ein Neupartner ist ein Punkt, die Rangliste ist also die Anzahl Neupartner. Umsätze und Abos spielen keine Rolle. Die Prämie: 50 € je Neupartner plus 500 / 300 / 200 € für die Plätze 1 bis 3. Auszahlung gesammelt im Februar. -Sichtbar ist die Challenge als Dashboard-Karte und als eine Incentive-Seite (Teilnahme oben, dann Titelbild, Text, Kacheln, "So funktioniert die Challenge", unten das Live-Ranking) für alle aktiven Berater. Namen erscheinen in der Rangliste erst nach Bestätigung der Teilnahmebedingungen, die Punkte laufen aber ab dem ersten Tag mit. Montenegro kann parallel stehen bleiben, bis die Gewinner bekannt sind. Danach auf "Beendet" stellen. +Sichtbar ist die Challenge als Dashboard-Karte und als eine Incentive-Seite (Teilnahme oben, dann Titelbild, Text, Kacheln, "So funktioniert die Challenge", unten das Live-Ranking) für alle aktiven Berater. Namen erscheinen in der Rangliste erst nach Bestätigung der Teilnahmebedingungen, die Punkte laufen aber ab dem ersten Tag mit. Montenegro ist beendet und ausgewertet (25.09.). ## 2. Größenordnung aus den echten Zahlen (Datenbankstand 18.09.) @@ -47,7 +47,7 @@ Erscheint auf der Teaser-Seite und im Teilnahme-Fenster. Fett wird im Design gel > **Jeder neue Partner bringt dir 50 €. Sofort gezählt, im Februar ausgezahlt.** > -> Vom 1. Oktober bis zum 31. Januar zählt jeder neue Partner, der mit dir startet und ein Starterpaket bestellt. Kein Mindestumsatz. Keine Mindestanzahl. Der erste zählt genauso wie der zwanzigste. +> Vom 9. Oktober bis zum 31. Januar zählt jeder neue Partner, der mit dir startet und ein Starterpaket bestellt. Kein Mindestumsatz. Keine Mindestanzahl. Der erste zählt genauso wie der zwanzigste. > > Und wer am 31. Januar die meisten neuen Partner im Team hat, holt sich obendrauf den Top 3 Bonus: **500 € für Platz 1, 300 € für Platz 2, 200 € für Platz 3.** > @@ -69,9 +69,9 @@ So im Seeder hinterlegt. Die Punkte 2 (Bestätigung als Voraussetzung), 6 (Gleic > > **1. Worum es geht.** mivita veranstaltet die Recruiting Challenge 2026/27. Für jeden neuen Partner, den ein Berater im Aktionszeitraum gewinnt, zahlt mivita eine Prämie. Die drei Berater mit den meisten neuen Partnern erhalten zusätzlich einen Bonus. > -> **2. Wer mitmachen kann.** Alle Berater mit aktivem Beraterkonto. Die Teilnahme wird einmal im Backoffice bestätigt. Neue Partner werden ab dem 1. Oktober 2026 gezählt, egal wann die Bestätigung erfolgt. Ohne Bestätigung erscheint der Berater in der Rangliste anonym und erhält keine Auszahlung. +> **2. Wer mitmachen kann.** Alle Berater mit aktivem Beraterkonto. Die Teilnahme wird einmal im Backoffice bestätigt. Neue Partner werden ab dem 9. Oktober 2026 gezählt, egal wann die Bestätigung erfolgt. Ohne Bestätigung erscheint der Berater in der Rangliste anonym und erhält keine Auszahlung. > -> **3. Aktionszeitraum.** 1. Oktober 2026 bis 31. Januar 2027. Es zählt das Datum der bezahlten Registrierungsbestellung des neuen Partners. +> **3. Aktionszeitraum.** 9. Oktober 2026 bis 31. Januar 2027. Es zählt das Datum der bezahlten Registrierungsbestellung des neuen Partners. > > **4. Was zählt.** Ein neuer Partner ist eine Person, die sich im Aktionszeitraum mit dem Teilnehmer als Sponsor als Berater registriert und ein Starterpaket bezahlt hat. Eine Registrierung nur mit Mitgliedschaft zählt nicht. Jeder neue Partner wird einmal gezählt. Die Rangliste ergibt sich aus der Anzahl neuer Partner. > @@ -101,8 +101,8 @@ Das Badge auf der Dashboard-Karte heißt bei Geldprämie automatisch "Challenge" | Wann | Was | Kanal | |---|---|---| -| ca. 25.09. | Ankündigung: "Ab 1. Oktober: 50 € für jeden neuen Partner" | Newsletter, Dashboard-News | -| 01.10. | Challenge auf "Aktiv", Dashboard-Karte erscheint, Teilnahme bestätigen | Backoffice | +| vor dem 09.10. | Ankündigung: "Ab 9. Oktober: 50 € für jeden neuen Partner" | Newsletter, Dashboard-News | +| 09.10. | Haken "Nur für VIP sichtbar" entfernen (Status ist schon "Aktiv"), Dashboard-Karte erscheint, Teilnahme bestätigen | Backoffice | | Anfang Nov, Dez, Jan | Zwischenstand: Top 3 und Gesamtzahl Neupartner | Newsletter, Dashboard-News | | Mitte Januar | Endspurt: "Noch zwei Wochen" | Mail | | 01.02. | Ende, Status "Beendet", Gewinner bekannt geben | Mail, Dashboard-News | @@ -116,33 +116,33 @@ Bonushöhe ist entschieden (500 / 300 / 200 €). Übrig bleiben die Regelfragen | # | Frage | Vorschlag in den Bedingungen | Technische Folge | |---|---|---|---| -| **1** | Gleichstand in den Top 3: wer gewinnt? Historisch liegen regelmäßig fünf bis sechs Berater gleichauf. | Wer die Anzahl zuerst erreicht hat | Rangfolge nach Zeitpunkt des letzten zählenden Neupartners: 0,5 PT, vor dem Start | +| **1** | Gleichstand in den Top 3: wer gewinnt? Historisch liegen regelmäßig fünf bis sechs Berater gleichauf. | Wer die Anzahl zuerst erreicht hat | **Erledigt, live 25.09.** | | **2** | Widerruf oder Storno einer Registrierung: zählt der Neupartner weiter? | Nein, Wertung entfällt. Stichtag Auszahlung, danach keine Rückrechnung | Automatik (Storno entfernt Tracking): 1 PT. Alternativ manuelle Prüfung des Exports vor Auszahlung | | **3** | Muss die Teilnahme bestätigt sein, um die Prämie zu bekommen? | Ja | Export filtert auf bestätigte Teilnehmer: 0,25 PT. Erinnerung an Unbestätigte im Januar | | **4** | Auszahlungsweg: Gutschrift auf der Februar-Abrechnung, Überweisung, oder Gutschrift-PDF? | Gutschrift auf der Februar-Abrechnung, Liste aus dem Export | Automatische Gutschrift-Erzeugung: 1 bis 2 PT, sonst manuell in der Buchhaltung | | **5** | Zählt jedes Starterpaket gleich, oder erst ab einer Paketgröße? | Jedes Paket zählt (so gebaut) | Paketgrenze: 0,5 PT | | **6** | Zählen Kunden, die mit Starterpaket zum Berater werden? | Ja (so gebaut, wie Montenegro) | Ausschluss: 0,5 PT | | **7** | Sollen Admins, VIP-Konten und das Firmenkonto in der Rangliste mitspielen? | Nein, Sichtprüfung vor Auszahlung | Filter im Export: 0,25 PT | -| **8** | Montenegro: wann auf "Beendet"? | Nach Bekanntgabe der Reiseteilnehmer, spätestens 05.10. | Statuswechsel | -| **9** | Challenge schon im September sichtbar ("bald geht es los")? | Ja, ab ca. 25.09. auf "Aktiv". Gezählt wird erst ab 01.10., die Rangliste ist bis dahin leer | keine | -| **10** | Texte auch auf EN, ES, FR? | Ja, Übersetzung im Admin-Formular je Sprache | Eingabe | +| **8** | Montenegro: wann auf "Beendet"? | Nach Bekanntgabe der Reiseteilnehmer, spätestens 05.10. | **Erledigt 25.09.** | +| **9** | Challenge schon vor dem Start sichtbar ("bald geht es los")? | Ja, auf "Aktiv". Gezählt wird erst ab 09.10., die Rangliste ist bis dahin leer | keine | +| **10** | Texte auch auf EN, ES, FR? | Ja | **Erledigt 25.09.:** Übersetzungen im Seeder, im Admin-Formular je Sprache änderbar | ## 10. Technische Folgearbeiten | Punkt | Aufwand | Wann | |---|---|---| -| Gleichstandsregel "zuerst erreicht" (Frage 1), steht bereits in den Bedingungen | 0,5 PT | vor dem 01.10. | +| ~~Gleichstandsregel "zuerst erreicht" (Frage 1)~~ | 0,5 PT | **live 25.09.** | | Storno entfernt Neupartner-Wertung (Frage 2), falls Automatik gewünscht | 1 PT | vor der Auszahlung | | Export nur bestätigte Teilnehmer (Frage 3) | 0,25 PT | vor der Auszahlung | | Gutschrift-Erzeugung aus dem Export (Frage 4), falls gewünscht | 1 bis 2 PT | Januar | ## 11. Anlegen auf Produktion -Die Challenge liegt mit allen Texten und Werten im Seeder [`RecruitingChallenge2026Seeder`](../../database/seeders/RecruitingChallenge2026Seeder.php). Er legt sie als Entwurf an. Läuft er ein zweites Mal, aktualisiert er nur die Texte und lässt Admin-Änderungen an den Werten stehen. +Die Challenge liegt mit allen Texten und Werten im Seeder [`RecruitingChallenge2026Seeder`](../../database/seeders/RecruitingChallenge2026Seeder.php). Er legt sie als Entwurf an. Läuft er ein zweites Mal, aktualisiert er Texte, Übersetzungen und den Qualifikationsbeginn (09.10.) und lässt alle anderen Admin-Werte stehen. Achtung: Texte, die im Admin geändert wurden, überschreibt er. ```bash -php artisan migrate # falls E1 noch nicht deployt -php artisan db:seed --class=RecruitingChallenge2026Seeder +php artisan migrate # erledigt 23.09. +php artisan db:seed --class=RecruitingChallenge2026Seeder --force # 23.09. angelegt; erneut für Start 09.10. + Übersetzungen php artisan view:clear && php artisan route:clear ``` @@ -150,11 +150,13 @@ Beim Deploy den Ordner `public/img/incentive/montenegro-incentive-2026/` mit hoc ## 12. Checkliste bis zum Start -- [ ] Fragen 1 bis 10 mit Dani/Alois entschieden -- [ ] Texte freigegeben (Name, Untertitel, Beschreibung, Bedingungen), ggf. Übersetzungen +- [ ] Fragen 2 bis 7 mit Dani/Alois entschieden (1, 8, 9, 10 erledigt) +- [ ] Texte freigegeben (Name, Untertitel, Beschreibung, Bedingungen) inkl. Übersetzungen EN/ES/FR - [x] Titelbild geliefert und abgelegt -- [ ] Gleichstandsregel deployt -- [ ] Deploy E1 und Seeder auf Produktion -- [ ] Challenge im Admin geprüft, Teaser und Rangliste angesehen -- [ ] Ankündigungsmail raus -- [ ] Status "Aktiv" und Haken "Nur für VIP sichtbar" entfernen +- [x] Gleichstandsregel deployt (25.09.) +- [x] Deploy E1 und Seeder auf Produktion (23.09.) +- [ ] Seeder erneut einspielen: Start 09.10., Übersetzungen +- [ ] Challenge im Admin geprüft (Qualifikationsbeginn 09.10.2026), Teaser und Rangliste angesehen, auch auf EN/ES/FR +- [ ] Ankündigungsmail raus ("Ab 9. Oktober") +- [x] Status "Aktiv" +- [ ] Haken "Nur für VIP sichtbar" entfernen diff --git a/dev/_tickets/2026-09-23-mitgliedschaft-ablauf-uebersicht.md b/dev/_tickets/2026-09-23-mitgliedschaft-ablauf-uebersicht.md index 33beb23b..6c9227dc 100644 --- a/dev/_tickets/2026-09-23-mitgliedschaft-ablauf-uebersicht.md +++ b/dev/_tickets/2026-09-23-mitgliedschaft-ablauf-uebersicht.md @@ -1,8 +1,8 @@ # Wenn ein Berater seine Mitgliedschaft nicht verlängert -**Übersicht für mivita · Stand 23.09.2026** +**Übersicht für mivita · Stand 23.09.2026 · live seit 25.09.2026** -Diese Seite beschreibt, was ab dem nächsten Update passiert, wenn die Jahresgebühr eines Beraters +Diese Seite beschreibt, was seit dem Update vom 25.09. passiert, wenn die Jahresgebühr eines Beraters nicht bezahlt wird: wann was geschieht, wer welche E-Mail bekommt und was mit Team, Kunden, Abos und Punkten passiert. Grundlage sind die Absprachen aus dem Zoom-Meeting vom 08.09. und eure Rückmeldung vom 14.09. diff --git a/dev/_tickets/entwicklungsplan-protokoll-september-2026.md b/dev/_tickets/entwicklungsplan-protokoll-september-2026.md index 2cdeb6dc..c3c47f12 100644 --- a/dev/_tickets/entwicklungsplan-protokoll-september-2026.md +++ b/dev/_tickets/entwicklungsplan-protokoll-september-2026.md @@ -1,6 +1,6 @@ # Entwicklungsplan – Protokoll Zoom-Meeting 08.09.2026 -**Stand:** 23.09.2026 · **Seit 18.09.:** B2 umgesetzt (Deploy offen), E1 Gleichstand + Zählung nach Zahlungsdatum, A07, Warnung für überfällige Abos (`abo:check-overdue`) — Details in den Abschnitten. Kundenübersicht B2: [2026-09-23-mitgliedschaft-ablauf-uebersicht.md](2026-09-23-mitgliedschaft-ablauf-uebersicht.md). · Vorher: **Status:** C1/C2 live seit 14.09., A4, A3 und A1+A2 umgesetzt (committet, Deploy offen); Abo-Paket damit bis auf A5 komplett. Audit vom 18.09. ([2026-09-18-audit-commits-16-09-2026.md](2026-09-18-audit-commits-16-09-2026.md)) geprüft, alle Befunde umgesetzt — Stellungnahme und Deploy-Folgen dort. **E1 (Recruiting-Challenge) umgesetzt 18.09., Deploy offen** — Konfiguration im Admin, Details unten. +**Stand:** 25.09.2026 · **Alles bis Commit `792d553` ist live.** A1–A4 und E1 seit dem Deploy vom 23.09., B2, A07, Warnung für überfällige Abos (`abo:check-overdue`), E1-Nachträge (Gleichstand, Zählung nach Zahlungsdatum, Schalter „Abos berücksichtigen“) und die Kundenrückmeldungen vom 24.09. (Punkte-Legende entfernt, Prognose-Titel „Stand Monatsende“) seit 25.09.; Migrationen, Cache-Befehle und die Sperrfrist-Settings (0) sind ausgeführt. Montenegro ist beendet und ausgewertet. **Offen:** erster Lauf von `user:cleanup` (B2, Liste an Alois), Start der Recruiting Challenge am **09.10.** (Seeder mit neuem Datum und EN/ES/FR-Texten noch einspielen), dann A5, B1, D1, D2. Kundenübersicht B2: [2026-09-23-mitgliedschaft-ablauf-uebersicht.md](2026-09-23-mitgliedschaft-ablauf-uebersicht.md). Audit vom 18.09.: [2026-09-18-audit-commits-16-09-2026.md](2026-09-18-audit-commits-16-09-2026.md). **Quellen:** `2026 09 Protokoll September-komprimiert.pdf` (Protokoll), `2026-09-14.md` (Ticket-Entwurf Abos #1–#3) **Verwandte Pläne:** `dev/2026-07-22/entwicklungsplan-2026-09-07.md` (K11–K14 behandeln dieselben Themen aus dem Kundenbrief; die dortigen Rückfragen F4–F7 sind weiterhin offen), `dev/2026-09-10-business-plan/` (Ledger-Plan, löst A07/K11 langfristig) @@ -10,24 +10,24 @@ | # | Thema | Quelle | Aufwand | Risiko | Blockiert durch | |---|---|---|---|---|---| -| **A1** | Abo-Ausführungstag frei wählbar (1–31, Monatsende-Regel) – **umgesetzt 16.09., Deploy offen** (Lager/Versand: Freigabe Kevin 16.09.) | Ticket #1, Protokoll | 3–4 PT | mittel | – | -| **A2** | Änderungssperre erst ab 0:00 Uhr am Ausführungstag – **umgesetzt 16.09., Deploy offen (Settings auf 0!)** | Ticket #1 | 1 PT | niedrig | zusammen mit A1 | -| **A3** | Abo-Status und Grund sichtbar (Zahlung / Kunde / Admin) – **umgesetzt 16.09., Deploy offen (Migration + Backfill)** | Ticket #2, Protokoll | 2–3 PT | niedrig | – | -| **A4** | Pausieren/Kündigen beschriften, Kündigungs-Hinweis (6 Ausführungen) – **umgesetzt 16.09., Deploy offen** | Ticket #3, Protokoll | 1 PT | niedrig | – | +| **A1** | Abo-Ausführungstag frei wählbar (1–31, Monatsende-Regel) – **live seit 23.09.** (Lager/Versand: Freigabe Kevin 16.09.) | Ticket #1, Protokoll | 3–4 PT | mittel | – | +| **A2** | Änderungssperre erst ab 0:00 Uhr am Ausführungstag – **live seit 23.09., Settings auf 0 seit 25.09.** | Ticket #1 | 1 PT | niedrig | zusammen mit A1 | +| **A3** | Abo-Status und Grund sichtbar (Zahlung / Kunde / Admin) – **live seit 23.09.** | Ticket #2, Protokoll | 2–3 PT | niedrig | – | +| **A4** | Pausieren/Kündigen beschriften, Kündigungs-Hinweis (6 Ausführungen) – **live seit 23.09.** | Ticket #3, Protokoll | 1 PT | niedrig | – | | **A5** | Kundenabo → Partnerabo automatisch umwandeln | Protokoll | 4–6 PT | hoch | Rückfragen R5 | | **B1** | Jahresgebühr automatisch abbuchen (Opt-in-Häkchen) | Protokoll | 6–8 PT | hoch | Rückfragen R6 | -| **B2** | Berater fällt aus: Pausieren nach 2 Tagen, Rückgabe bei Zahlung, harter Cut nach 4 Wochen, Sponsor-Mail | Protokoll, Rückmeldung 14.09. | 3–4 PT | mittel (einmaliger Massen-Effekt, akzeptiert) | – | +| **B2** | Berater fällt aus: Pausieren nach 2 Tagen, Rückgabe bei Zahlung, harter Cut nach 4 Wochen, Sponsor-Mail – **live seit 25.09.**, erster Lauf nach Freigabe der `--dry-run`-Liste | Protokoll, Rückmeldung 14.09. | 3–4 PT | mittel (einmaliger Massen-Effekt, akzeptiert) | – | | **C1** | Team-Statistik = Team-Struktur (gleiche Punkte) – **live seit 14.09.** ([Deploy-Notiz](../2026-07-22/deploy-2026-09-14.md)) | Protokoll | 3–5 PT | hoch (jede Zahl ändert sich) | – (F4: Umschalter) | | **C2** | Laufstand-Race: Provision liest zu niedrigen Monatsstand bei zeitgleichen Buchungen – **Stufe 1+2 live seit 14.09.**, Stufe 3 offen | Befund aus C1 | 0,5 + 1 PT | hoch (Provision) | – (keine Nachzahlung, Entscheid 14.09.) | | **D1** | Neuer Reiter „Events“ mit Foto-Galerien (wie News-Archiv) | Protokoll | 2–3 PT | niedrig | Fotos liegen vor | | **D2** | Top 3 firmenweit im Backoffice | Protokoll | 0,5 PT | rechtlich | Network-Anwalt (F3) | -| **E1** | Recruiting-Challenge Okt–Jan (50 €/Neupartner, Top 3) – **umgesetzt 18.09., Deploy offen (Migration + Anlage im Admin)** | Protokoll | 0,5 PT Konfiguration + 1–2 PT Erweiterung | niedrig | Bonushöhe/Texte Dani/Alois | +| **E1** | Recruiting-Challenge Okt–Jan (50 €/Neupartner, Top 3) – **live seit 23.09. (nur VIP)**, Start **09.10.** | Protokoll | 0,5 PT Konfiguration + 1–2 PT Erweiterung | niedrig | Bonushöhe/Texte Dani/Alois | **Reihenfolge (festgelegt 14.09.):** 1. **Team-Statistik zuerst (C1)** – die Seite wird ständig angeschaut, und die abweichenden Zahlen erzeugen laufend Rückfragen der Kundin. Schritt 1 (Mess-Command) und Schritt 2 (gemeinsames Baum-Prädikat) können sofort starten; nur die Umstellung selbst (Schritt 3) braucht vorher die Antwort auf F4 (abgelaufene Berater: Empfehlung Provisionssicht als Standard mit Umschalter „inkl. abgelaufene“). 2. **Abo-Paket** – A4 → A3 → A1+A2 (A1 und A2 greifen ineinander, gemeinsam testen). -3. **Termingebunden** – E1 (Challenge startet 01.10., Nachtragen ist möglich, s. u.), B2 (Ausfall-Ablauf komplett in einem Paket: Pausieren, Rückgabe, harter Cut, Sponsor-Mails – nicht in Teilen ausliefern, sonst entstehen Zwischenzustände ohne Rückweg). +3. **Termingebunden** – E1 (Challenge startet 09.10., bis 24.09. geplant 01.10.; Nachtragen ist möglich, s. u.), B2 (Ausfall-Ablauf komplett in einem Paket: Pausieren, Rückgabe, harter Cut, Sponsor-Mails – nicht in Teilen ausliefern, sonst entstehen Zwischenzustände ohne Rückweg). 4. **Backoffice** – D1 (Events-Reiter). 5. **Groß, mit offenen Rückfragen** – B1, A5. Ohne die Antworten in Abschnitt 6 nicht beginnen. @@ -37,7 +37,7 @@ ## 1. Abo-Paket -### A1 – Ausführungstag frei wählbar (1–31) — umgesetzt 16.09., Deploy offen +### A1 – Ausführungstag frei wählbar (1–31) — live seit 23.09. **Ziel (Ticket #1):** Jeder Tag 1–31 wählbar; bei 29/30/31 in kürzeren Monaten der letzte Monatstag. Genau eine Ausführung pro Monat. Änderung nur „nach vorne“ (10. → 24. ja, 10. → 5. nein, wenn der 5. schon vorbei ist). Wird am Ausführungstag 0:00 Uhr fixiert (→ A2). @@ -72,7 +72,7 @@ - **Rückfrage R1:** Wenn der gewünschte Tag im laufenden Monat schon vorbei ist – Fehlermeldung, oder Änderung automatisch für den Folgemonat übernehmen (dann würde diese Monatslieferung noch am alten Tag laufen)? - Bestehende Abos ändern sich nicht; keine Datenmigration. -### A2 – Änderungssperre erst am Ausführungstag ab 0:00 Uhr — umgesetzt 16.09., Deploy offen +### A2 – Änderungssperre erst am Ausführungstag ab 0:00 Uhr — live seit 23.09., Settings auf 0 seit 25.09. **Ziel (Ticket #1):** Tag und Produkte bis 23:59 Uhr des Vortags änderbar, dann fixiert. Die Sperre bleibt im Code (Setting), Default effektiv 0. Einmalprodukte behalten ihr eigenes Fenster (4 Tage vorher). @@ -113,7 +113,7 @@ Keine Migration, keine Datenänderung. Danach prüfen: Abo-Einstellungen zeigen 31 Tage; ein Abo mit Termin morgen lässt sich noch ändern; heute fälliges Abo ist gesperrt. - **Nicht enthalten:** die Mindestfrist 10 Tage bis zur Erst-Ausführung bleibt (`MIN_DAYS_UNTIL_FIRST_ABO_EXECUTION`); das Cron-Fenster 04:00 Uhr bleibt; Einmalprodukte behalten ihr eigenes 4-Tage-Fenster. -### A3 – Status und Grund eines Abos sichtbar machen — umgesetzt 16.09., Deploy offen +### A3 – Status und Grund eines Abos sichtbar machen — live seit 23.09. **Ziel (Ticket #2, Protokoll):** Für Admin, Berater und Kunde sofort erkennbar: aktiv und ordnungsgemäß ausgeführt / pausiert bis wann und durch wen / Zahlung fehlgeschlagen (und dass sie fehlgeschlagen ist) / gekündigt durch wen. @@ -149,7 +149,7 @@ - Sprachdateien de/en/es/fr (`state_*`, `state_text_*`, `actor_by_*`, `filter_state`). Tests: `AboStatusExplainTest` (11 Tests), alle 40 Abo-Testdateien grün bis auf `AboPendingInitialPaymentTest` „zeigt gesendete Abo-Zahlungslinks“, der schon auf dem committeten Stand fehlschlägt (rendert `user/abo/index` mit `Form::open` ohne Session) — nicht Teil von A3. - **Deploy:** Dateien hochladen, dann `php artisan migrate`, `php artisan abo:backfill-status-reasons --dry-run` (Zahlen prüfen), `php artisan abo:backfill-status-reasons`, `php artisan view:clear`. Keine Settings. -### A4 – Pausieren/Kündigen beschriften, Kündigungs-Hinweis — umgesetzt 16.09., Deploy offen +### A4 – Pausieren/Kündigen beschriften, Kündigungs-Hinweis — live seit 23.09. **Ziel (Ticket #3, Protokoll):** Im Partnershop/Portal sofort sichtbar, dass und wo man pausieren/kündigen kann. Beim Kündigen deutlicher Hinweis: neues Abo braucht wieder 6 Ausführungen; Vorschlag, stattdessen zu pausieren. @@ -297,7 +297,7 @@ Dazu gibt es einen dritten, abweichenden Pfad: setzt ein Admin das Datum in die **Aufwand:** 3–4 PT. **Entschieden (14.09.):** Sponsor bekommt bei Stufe 1 die Kurzinfo ohne Listen, bei Stufe 2 die Listen-Mail; der Status-Umbruch beim Deploy ist akzeptiert. **R3 beantwortet:** 2 Tage Versatz für alle Zahlungsarten. -#### Umsetzung B2 (23.09.2026) — Deploy offen +#### Umsetzung B2 (23.09.2026) — live seit 25.09. - **Ein Weg für alle drei Pfade:** [`ConsultantSuspensionService`](../../app/Services/ConsultantSuspensionService.php) mit `suspend()`, `reinstate()`, `terminate()`. `user:cleanup`, der Zahlungseingang (`Payment::paymentStatusPaidAction`) und das Ablaufdatum im Admin (`AdminUserController`, save-account) rufen nur noch diese Methoden. - **Fristen** in `config/mivita.php`: `cleanup_suspend_days` = 2, `cleanup_delete_days` = 28 (Env `MIVITA_CLEANUP_SUSPEND_DAYS` / `MIVITA_CLEANUP_DELETE_DAYS`). @@ -312,7 +312,7 @@ Dazu gibt es einen dritten, abweichenden Pfad: setzt ein Admin das Datum in die **Messung an der Live-Kopie (23.09.):** Der erste Lauf würde 6 Berater pausieren (64 Kundendatensätze, 2 Teampartner) und 20 Berater endgültig entfernen (150 Kundendatensätze, 1 Portal-Login). Keine aktiven Kundenabos betroffen. Heute liegen bei 24 inaktiven Beratern 162 Kundendatensätze, deren Umsätze bei niemandem ankommen. -**Deploy:** +**Deploy (erledigt 25.09.):** ```bash php artisan migrate # consultant_suspension_transfers (+ Schema-Angleichung, auf Produktion ohne Wirkung) @@ -320,7 +320,7 @@ php artisan view:clear && php artisan config:clear php artisan user:cleanup --dry-run # Liste an Alois, erst danach laufen lassen ``` -Der reguläre Lauf um 03:30 übernimmt danach. Kein Snapshot-Neuaufbau. +Der reguläre Lauf um 03:30 übernimmt danach. Kein Snapshot-Neuaufbau. **Offen:** Freigabe der `--dry-run`-Liste und der erste Lauf (Thema folgt). **Offen / bewusst nicht gebaut:** eigenes Berater-Abo (`is_for = me`) eines pausierten Beraters läuft zu Partnerkonditionen weiter (heute kein Fall); Admin-Restore nach dem harten Cut holt wie bisher nur das Team über die Logs zurück. @@ -454,7 +454,7 @@ Die Zeilen entstehen in [`Payment::paymentStatusPaidAction()`](../../app/Service ## 5. Aktionen -### E1 – Recruiting-Challenge Oktober–Januar — umgesetzt 18.09., Deploy offen +### E1 – Recruiting-Challenge Oktober–Januar — live seit 23.09. (nur VIP), Start 09.10. **Ziel (Protokoll):** Pro Neupartner mit Paket 50 € im Qualifikationszeitraum, Top 3 erhalten zusätzlich einen Bonus, Auszahlung gesammelt im Februar, wieder ein Ranking. Details klären Dani und Alois. @@ -487,7 +487,7 @@ Das Incentive-Modul trägt jetzt optional eine Geldprämie; Montenegro bleibt un | Feld | Wert | |---|---| -| Qualifikationsbeginn / -ende | 01.10.2026 / 31.01.2027 | +| Qualifikationsbeginn / -ende | **09.10.2026** (bis 24.09.: 01.10.) / 31.01.2027 | | Berechnungsende | 31.01.2027 (ohne Umsatzpunkte gibt es keinen Nachlauf; 28.02. wäre nur nötig, wenn Umsätze zählen) | | Einmalpunkte pro Partner / pro Abo | 1 / 0 | | Mind. direkte Partner / Kundenabos | 0 / 0 | @@ -495,21 +495,24 @@ Das Incentive-Modul trägt jetzt optional eine Geldprämie; Montenegro bleibt un | Prämie je Neupartner | 50,00 | | Bonus Platz 1 / 2 / 3 | **offen – Dani/Alois** | | Umsatzpunkte mitzählen | **aus** | -| Status | Aktiv (ab 01.10.; früher anlegen ist unschädlich, getrackt wird nur im Zeitraum) | +| Abos berücksichtigen | **aus** (seit 25.09.) | +| Status | Aktiv (früher anlegen ist unschädlich, getrackt wird nur im Zeitraum ab 09.10.) | | Bild, Untertitel, Beschreibung, Teilnahmebedingungen | **Dani/Alois** – ohne Beschreibung erscheint der Montenegro-Fallbacktext („Adria“), also Beschreibung unbedingt füllen | -**Nachtragen nach dem 01.10.:** `php artisan incentive:calculate {id}` zieht Neupartner ab Qualifikationsbeginn nach (läuft ohnehin täglich 05:00 für alle aktiven Incentives). +**Nachtragen nach dem 09.10.:** `php artisan incentive:calculate {id}` zieht Neupartner ab Qualifikationsbeginn nach (läuft ohnehin täglich 05:00 für alle aktiven Incentives). **Offen / bewusst nicht gebaut** - Bonushöhe Top 3, Beschreibungstexte, Bild (Dani/Alois). - ~~**Punktgleichstand** in den Top 3~~ — **umgesetzt 23.09.** (Teilnahmebedingungen Punkt 6): bei gleichen Punkten bestätigte Teilnahme vor anonym, danach wer den Stand zuerst erreicht hat (Zeitpunkt des letzten zählenden Neupartners bzw. Neuabos aus `incentive_new_partners.registered_at` / `incentive_new_abos.activated_at`), zuletzt die Teilnehmer-ID. `IncentiveTracker::updateRanking()`, Tests in `IncentiveRankingTest`. An der Live-Kopie gegengerechnet: Montenegro tauscht nur Plätze ab 81, die 20 Gewinner bleiben gleich. -- **Neupartner zählen ab der Zahlung (23.09.):** wie in der Statistik (Kundenentscheid 16.09.) zählt `users.partner_paid_at`, nicht das Bestelldatum — im Live-Tracking, in der nächtlichen Reparatur und im Neuaufbau (`IncentiveTracker::newPartnerCountedAt()`). Wer am 29.09. bestellt und am 01.10. zahlt, zählt in der Challenge. Montenegro ist abgeschlossen und bleibt unberührt; im Admin auf „Beendet“ stellen, damit der Nachtlauf es nicht mehr anfasst. +- **Neupartner zählen ab der Zahlung (23.09.):** wie in der Statistik (Kundenentscheid 16.09.) zählt `users.partner_paid_at`, nicht das Bestelldatum — im Live-Tracking, in der nächtlichen Reparatur und im Neuaufbau (`IncentiveTracker::newPartnerCountedAt()`). Wer am 07.10. bestellt und am 09.10. zahlt, zählt in der Challenge. Montenegro ist beendet und ausgewertet (Status „Beendet“ seit 25.09.) und bleibt unberührt. +- **Schalter „Abos berücksichtigen“ (24.09., live 25.09.):** Die Challenge erfasste Eigen- und Kundenabos mit 0 Punkten (Live-Kopie: 175 Eigenabos); sie standen in „Meine Berechnung“ und im Admin und hätten Berater ohne Neupartner in die Rangliste gebracht. Neues Feld `incentives.include_abos` (Migration `2026_09_24_133443`, für die Challenge aus). Aus = kein Abo-Tracking in Tracker, Neuaufbau und Reparatur, `incentive:calculate` räumt vorhandene Abo-Zeilen ab, Abo-Punkte und Mindestabos werden auf 0 gesetzt, Abo-Spalten und -Bereiche entfallen. Tests: `IncentiveIncludeAbosToggleTest`. +- **Start 9. Oktober und Übersetzungen (25.09.):** Qualifikationsbeginn 09.10.2026 statt 01.10. (Kundenentscheid 25.09.); Beschreibung und Teilnahmebedingungen nennen den 9. Oktober. Name, Untertitel, Beschreibung und Bedingungen liegen jetzt auch auf Englisch, Spanisch und Französisch vor (`trans_*`). Der Seeder gleicht Texte, Übersetzungen und den Beginn ab, alle anderen Admin-Werte bleiben unberührt. Einspielen: `php artisan db:seed --class=RecruitingChallenge2026Seeder --force`, danach im Admin Datum und Texte prüfen. Wer vom 01.10. bis 08.10. bezahlt, zählt nicht. - **Stornos/Rücktritte:** Ein einmal getrackter Neupartner bleibt gezählt, auch wenn die Registrierung später storniert wird (Verhalten wie Montenegro). Vor der Auszahlung die Liste gegen stornierte Registrierungsbestellungen prüfen oder Regel mit Dani/Alois klären. - Gutschrift-Erzeugung aus dem Export (siehe oben). - Firmenweite Rangliste (D2) unverändert offen; die Challenge-Rangliste ist wie Montenegro für alle aktiven Berater sichtbar. -**Deploy** +**Deploy (erledigt 23.09., Nachträge 25.09.)** ```bash php artisan migrate # incentives: amount_per_partner, bonus_rank_1..3, include_sales_points, vip_only @@ -547,5 +550,5 @@ Wäre auch eine Ankündigung, wenn eine automatische Buchung kommt zwei Tage vor - **Sprachdateien:** jede Textänderung in de/en/es/fr (`LocalizationSyncTest`). - **Tests:** Suite läuft auf SQLite in-memory; Stand 14.09.: 92 vorbestehende Fehlschläge (siehe `2026-09-08.md`), neue Tests müssen isoliert grün sein. Admin-Routen-Tests brauchen den CRM-Host-Trick aus `ConsultantTransferTest`. -- **Settings/Deploy:** A2 setzt `abo-lock-days-change` (und ggf. `-pause-cancel`) auf 0; C1 braucht `cache:clear` und Snapshot-Neuberechnung; B2 braucht `--dry-run`-Liste vor dem ersten Lauf. +- **Settings/Deploy:** A2 setzt `abo-lock-days-change` (und ggf. `-pause-cancel`) auf 0 (erledigt 25.09.); C1 braucht `cache:clear` und Snapshot-Neuberechnung (erledigt 14.09.); B2 braucht `--dry-run`-Liste vor dem ersten Lauf (offen). - **Pint** nach jeder Änderung.