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

@ -53,6 +53,7 @@ beforeEach(function () {
$table->unsignedInteger('m_sponsor')->nullable();
$table->boolean('active')->default(false);
$table->timestamp('active_date')->nullable();
$table->timestamp('partner_paid_at')->nullable();
$table->unsignedTinyInteger('admin')->default(0);
$table->unsignedTinyInteger('wizard')->default(0);
$table->unsignedTinyInteger('blocked')->default(0);
@ -69,6 +70,7 @@ beforeEach(function () {
$table->char('is_for', 2)->nullable();
$table->boolean('active')->default(true);
$table->unsignedTinyInteger('status')->default(2);
$table->string('status_reason')->nullable();
$table->date('start_date')->nullable();
$table->date('next_date')->nullable();
$table->timestamps();
@ -216,6 +218,7 @@ it('aggregiert Linien, Abos und Punkte fuer die Backoffice-Statistik', function
'm_sponsor' => $root->id,
'm_level' => 1,
'active_date' => '2026-05-03 00:00:00',
'partner_paid_at' => '2026-05-03 00:00:00',
'payment_account' => '2030-01-01 00:00:00',
]);
@ -226,6 +229,7 @@ it('aggregiert Linien, Abos und Punkte fuer die Backoffice-Statistik', function
'm_sponsor' => $lineOne->id,
'm_level' => 1,
'active_date' => '2026-04-03 00:00:00',
'partner_paid_at' => '2026-04-03 00:00:00',
'payment_account' => '2030-01-01 00:00:00',
]);
@ -236,6 +240,7 @@ it('aggregiert Linien, Abos und Punkte fuer die Backoffice-Statistik', function
'm_sponsor' => $root->id,
'm_level' => 1,
'active_date' => '2026-01-03 00:00:00',
'partner_paid_at' => '2026-01-03 00:00:00',
'payment_account' => '2020-01-01 00:00:00',
]);
@ -249,6 +254,7 @@ it('aggregiert Linien, Abos und Punkte fuer die Backoffice-Statistik', function
'm_sponsor' => $sponsor->id,
'm_level' => 1,
'active_date' => '2026-04-03 00:00:00',
'partner_paid_at' => '2026-04-03 00:00:00',
'payment_account' => '2030-01-01 00:00:00',
]);
}