Statistik: Neupartner zaehlen im Monat der Zahlung, nicht der Registrierung

Wer Ende August registriert und am 1. September bezahlt hat, tauchte in keiner
Neupartner-Zaehlung auf: Der August-Snapshot wurde um 04:45 eingefroren, da
fehlte noch das Abrechnungskonto; im September lag active_date im falschen
Monat. Betroffen sind 2026 acht Partner, auch im Recruiting ihrer Sponsoren.

Kundenentscheidung 16.09.2026: der Zeitpunkt der Zahlung ist massgeblich.

Neue Spalte users.partner_paid_at, gesetzt bei der ersten Kontozahlung
(Payment::paymentStatusPaidAction) und bei manueller Freischaltung durch den
Admin — nur, solange sie leer ist; Verlaengerung und Wiederherstellung aendern
sie nicht. Bestehende Partner werden per Migration aus der ersten bezahlten
Registrierungsbestellung rueckgefuellt (Zeitstempel der Punktebuchung, ersatzweise
Bestelldatum, ohne Bestellung das Aktivierungsdatum). Bewusst nicht
payment_account minus ein Jahr: das ergaebe bei Verlaengerern den Jahrestag der
Erstzahlung.

User::scopeNewPartnerIn() und isNewPartnerIn() lesen jetzt partner_paid_at —
damit Kachel, Recruiter-Ranking, Top 3 und Neupartner-Liste gleichermassen.
Die Liste und der CSV-Export zeigen "Bezahlt am" neben "Registriert am".

Unveraendert: die Teamstruktur haengt weiter an active_date (auch im
Provisionsbaum). Wer ist neu dazugekommen und wer gehoert zur Linie sind zwei
verschiedene Fragen.

Die eingefrorenen Monate Januar bis August enthalten sieben dieser Partner
nicht; ob sie per --force neu gebaut werden, ist eine Entscheidung — siehe
dev/2026-07-22/neupartner-zahlungsmonat.md.

Mit drin: die handgebaute SQLite-Tabelle in BackofficeDashboardServiceTest
kannte status_reason aus d6efe56 noch nicht.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Kevin 2026-09-16 14:48:01 +00:00
parent cf0311afc1
commit b7e8bbd951
21 changed files with 547 additions and 20 deletions

View file

@ -288,7 +288,7 @@ class BackofficeStatisticsController extends Controller
}
if ($metric === 'new_partners') {
return ['Name', 'E-Mail', 'Telefon', 'Karriere-Level', 'Sponsor', 'Punkte seiner Kunden', 'Gesamt inkl. Eigenbestellung', 'Aktiv seit', 'Account gueltig bis'];
return ['Name', 'E-Mail', 'Telefon', 'Karriere-Level', 'Sponsor', 'Punkte seiner Kunden', 'Gesamt inkl. Eigenbestellung', 'Bezahlt am', 'Registriert am', 'Account gueltig bis'];
}
return ['Name', 'E-Mail', 'Karriere-Level', 'Aktiv seit', 'Account gueltig bis', 'Account Status'];
@ -348,6 +348,7 @@ class BackofficeStatisticsController extends Controller
$row['sponsor'] ?? '',
$row['customer_points'] ?? 0,
$row['total_points'] ?? 0,
$row['paid_at'] ?? '',
$row['active_date'] ?? '',
$row['payment_account'] ?? '',
];
@ -385,10 +386,10 @@ class BackofficeStatisticsController extends Controller
}
if ($metric === 'new_partners') {
// Neun Werte fuer neun Spalten: die Telefonspalte kam nachtraeglich dazu,
// wodurch die Summen um eine Spalte verrutscht waren (Kundenpunkte
// standen unter "Sponsor").
return ['Summe', $summary['count'].' Eintraege', '', '', '', $summary['customer_points'], $summary['total_points'], '', ''];
// Zehn Werte fuer zehn Spalten — die Breitenpruefung im Test faengt ein
// Verrutschen der Summen ab, wie es beim Nachruesten der Telefonspalte
// passiert war (Kundenpunkte standen unter "Sponsor").
return ['Summe', $summary['count'].' Eintraege', '', '', '', $summary['customer_points'], $summary['total_points'], '', '', ''];
}
return ['Summe', $summary['count'].' Eintraege', '', '', '', ''];