gitmedia/mivita
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

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

Browse source 
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
Download patch file Download diff file Expand all files Collapse all files

46
database/migrations/2026_09_16_090000_add_partner_paid_at_to_users.php Normal file
View file

@ -0,0 +1,46 @@
<?php
use App\Services\Payment;
use App\Services\UserUtil;
use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;
/**
* Wann ist ein Vertriebspartner zum bezahlten Partner geworden?
*
* Die Neupartner-Statistik hing bisher an `active_date`, also am Abschluss der
* Registrierung. Wer Ende August registriert und am 1. September bezahlt hat,
* fiel damit durch: im August fehlte noch das Abrechnungskonto, im September
* lag `active_date` im falschen Monat. Entscheidend ist aber der Zeitpunkt der
* Zahlung (Kundenentscheidung 16.09.2026) — den haelt diese Spalte fest.
*
* Gesetzt wird sie bei der ersten Kontozahlung ({@see Payment})
* bzw. bei manueller Kontofreischaltung durch den Admin, und nur, solange sie
* leer ist. Eine Verlaengerung oder Wiederherstellung aendert sie nicht.
*
* Bestehende Partner werden aus der bezahlten Registrierungsbestellung
* rueckgefuellt ({@see UserUtil::backfillPartnerPaidAt()}).
*/
return new class extends Migration
{
public function up(): void
{
Schema::table('users', function (Blueprint $table) {
if (! Schema::hasColumn('users', 'partner_paid_at')) {
$table->dateTime('partner_paid_at')->nullable()->after('active_date');
}
});
UserUtil::backfillPartnerPaidAt();
}
public function down(): void
{
Schema::table('users', function (Blueprint $table) {
if (Schema::hasColumn('users', 'partner_paid_at')) {
$table->dropColumn('partner_paid_at');
}
});
}
};