# Neupartner zählen im Monat der Zahlung

**Entscheidung der Kundin, 16.09.2026.** Ein neuer Vertriebspartner gehört in den Monat, in dem
er **bezahlt** hat — nicht in den Monat seiner Registrierung. Das gilt für jede Stelle, die
Neupartner zählt: Kachel, Recruiter-Ranking, Top 3 „Recruiter des Monats", Neupartner-Liste,
CSV-Export.

## Der Fall, der es ausgelöst hat

Partner 1623 (Sponsor 454): registriert am 28.08., erster Zahlungslink abgelaufen, zweiter am
**01.09. um 06:49** bezahlt. Der Snapshot für August wurde am 01.09. um 04:45 eingefroren — da
hatte er noch kein Abrechnungskonto und fiel im August raus. Im September lag sein
Aktivierungsdatum im falschen Monat. **Er tauchte nirgends auf**, auch nicht beim Recruiting
seines Sponsors.

Das ist kein Einzelfall: 2026 betrifft es **8 Partner**, jeweils Ende des Monats registriert und
Anfang des Folgemonats bezahlt — 2 im Januar, 1 im April, 1 im Juni, 3 im Juli, 1 im September.

## Was sich geändert hat

Die Neupartner-Regel hing an `users.active_date` (Abschluss der Registrierung). Neu ist die Spalte
**`users.partner_paid_at`**: der Zeitpunkt der ersten Kontozahlung.

| | vorher | jetzt |
| --- | --- | --- |
| Neupartner im Monat X | `active_date` in X | `partner_paid_at` in X |
| Abrechnungskonto gültig am Stichtag | ja | ja, unverändert |
| Mitgliedsebene gesetzt | ja | ja, unverändert |

Die Regel steht an **einer** Stelle — `User::scopeNewPartnerIn()` und das PHP-Gegenstück
`User::isNewPartnerIn()` — und alle Zählungen gehen darüber.

**Gesetzt wird `partner_paid_at`** bei der ersten Kontozahlung (`Payment::paymentStatusPaidAction`,
Produktaktion `payment_for_account`) und bei manueller Kontofreischaltung durch den Admin. Beides
über `UserUtil::markPartnerPaid()`, das den Wert **nur setzt, solange er leer ist**. Eine
Verlängerung oder eine Wiederherstellung ändert ihn nicht — sonst würde ein alter Partner in der
Neupartner-Statistik wieder auftauchen.

**Rückgefüllt** wurde per Migration aus der ersten bezahlten Registrierungsbestellung
(`shopping_orders.payment_for = 1`): die Punktebuchung dazu entsteht im Moment der Zahlung, deren
Zeitstempel ist der Wert. Ohne Buchung das Änderungsdatum der Bestellung; ohne Bestellung (Konto
vom Admin freigeschaltet, 14 Fälle) das Aktivierungsdatum. **Nicht** verwendet wurde
`payment_account` minus ein Jahr: bei Verlängerungen wird vom alten Ablaufdatum aus verlängert, das
Ergebnis wäre der Jahrestag der Erstzahlung und jeder Verlängerer ein „Neupartner".

## Was sich nicht geändert hat

**Die Teamstruktur.** Ob jemand zum Monatsende zur Linie gehört, hängt weiterhin an `active_date` —
so auch im Provisionsbaum. Das ist eine andere Frage als „wer ist neu dazugekommen": Partner 1623
steht im September in der Struktur seines Sponsors, und er ist der September-Neupartner. Ein Partner,
der am 28.09. registriert und am 02.10. bezahlt, steht im September schon in der Struktur, zählt aber
erst im Oktober als neu.

**Provisionen, Gutschriften, Marketingplan.** Unberührt. Die Migration fügt eine leere Spalte hinzu
und füllt sie; keine vorhandene Zeile wird sonst geändert.

## Wiederhergestellte Partner

Vier Partner haben ein `active_date` Jahre **nach** ihrer Registrierungszahlung (414, 522, 610,
663) — sie wurden offenbar wiederhergestellt, und `restoreUser()` setzt `active_date` neu. Unter der
alten Regel zählten sie als Neupartner im Monat der Wiederherstellung. Unter der neuen Regel zählen
sie im Monat ihrer ursprünglichen Zahlung (2021–2023), also **nicht** als Neupartner 2026. Das ist
fachlich richtig, wenn eine Wiederherstellung keine Neuwerbung ist. Falls die Kundin das anders
sieht, müsste `restoreUser()` den Wert zurücksetzen — bewusst nicht gemacht.

## Die eingefrorenen Monate

Die Snapshots Januar bis August wurden mit der **alten** Regel gebaut. Sieben der acht
Partner von oben fehlen darin vollständig — in beiden Monaten. Der Snapshot friert bewusst ein
(siehe [monatsabschluss-eingefrorene-statistik.md](monatsabschluss-eingefrorene-statistik.md)), ein
Neuaufbau ist deshalb eine Entscheidung, keine Routine:

```bash
php artisan backoffice:store-statistics-snapshots --force
```

Damit landen die sieben in ihren Zahlungsmonaten. Wie am 10.09. gilt: der Neuaufbau friert die
Teamstruktur des **Ausführungstags** ein, nicht die des damaligen Monatsendes. Wer seit dem 10.09.
verschoben wurde oder dazukam, steht danach an seiner heutigen Stelle in den historischen Zahlen.

## Sichtprüfung nach dem Deploy

- Backoffice → September → Neupartner-Liste: Partner 1623 steht drin, Spalte „Bezahlt am" =
  01.09.2026, „Registriert am" = 28.08.2026.
- Recruiter-Ranking September: Sponsor 454 hat ihn angerechnet.
- Backoffice → August (eingefroren): unverändert, solange kein Neuaufbau läuft.