Kevin
96545364f1
K11 aus dem September-Protokoll (Tickets C1 und C2 im Entwicklungsplan), live seit 14.09.2026. C1 – Statistik rechnet wie die Provision - Standard-Baum ist der Provisionsbaum (Mitglieder wie TreeCalcBot: Mitgliedsebene, Abrechnungskonto, active_date; ausgefilterte Knoten kappen ihren Unterbaum, max. 21 Linien). Gesamte Downline bleibt per Umschalter erreichbar, Wahl in der Session. - Punkte-Definition: Provisionspunkte (TP + Shop), reine Karrierepunkte ausgewiesen statt eingerechnet, negative Monatssalden je User wie in der Provision auf 0 gekappt. - Abgeschlossene Monate nehmen die Mitglieder je Linie aus dem gespeicherten Provisionslauf (user_businesses), Snapshots je Baum-Definition (Payload-Version 3, Migration). - Struktur-Modal: Gesamt aus den Linien-Punkten mit Dezimalen statt der int-Spalte total_pp. - Messlauf statistics:compare-trees (Downline / Provisionsbaum / Struktur je VIP, Laufstand-Drift). C2 – Laufstand-Race (Provision zu niedrig bei zeitgleichen Buchungen) - Neuberechnung liest die Zeilen des Beraters sperrend (FOR UPDATE), Index (user_id, year, month). - Paid-Pfad der Payone- und Stripe-Webhooks als DB::transaction mit 3 Anlaeufen; Deadlock und Lock-Timeout aus der Rechnungserstellung werden nicht mehr geschluckt. - Sicherheitsnetz sales:repair-running-totals taeglich 02:45 vor dem Provisionslauf; abgeschlossene Monate werden nicht angefasst (Entscheid 14.09.: keine Nachzahlung fuer 06/08). Doku: Entwicklungsplan zum Protokoll, Deploy-Notiz 14.09. (inkl. Migrations-Stolperstein: Migrationen tragen Werte als Literale, nicht als Konstanten aus dem Anwendungscode). Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
2.2 KiB
ABOs #1 Ausführungstag und sperren Der Tag, an dem das Abo ausgeführt wird, soll beliebig definiert werden Über ein Datum im Monat nicht mehr nur der 5. 10. usw. Sondern 1-31 bzw. bei 31 wird dann immer der letzte Tag genommen 30, 29 .. Das Abo muss aber weiterhin einmal im Monat versendet werden d.h. diesmal im aktuellen Monat kann man natürlich das Datum im Monat so lange verändern bis der Versand raus ist für diesen Monat. Dann bestimmt man den Tag für den nächsten Monat wenn man das ändern möchte. Automatisch wird natürlich der gleiche Tag für den Folgemonat genommen. Damit Monate nicht übersprungen werden können. Kann natürlich ein Datum nur in die Zukunft geändert werden nicht vom zehnten auf den fünften des Monats. Heißt aber vom 10 kann zum Beispiel auf den 24 gestellt werden. Die Einstellung kann jederzeit gemacht werden und wird erst am ausführt Tag fixiert. Heißt, steht es zum Beispiel auf dem 24. kann es am 24. um 0:00 Uhr nicht mehr geändert werden und wir dann auch ausgeführt.
Produkte ändern hinzufügen bei einem Abo kann genauso gemacht werden. Es wird am ausführt Tag um 0:00 Uhr fixiert. Vorher können Produkte geändert werden. Die Sperre jetzt existiert einige Tage. Vorher soll es nicht mehr geben. Ich würde es trotzdem in der Entwicklung lassen, falls es noch mal irgendwann nötig wird. Vielleicht stellen wir die Sperre einfach auf null oder so.
Die zusätzlichen Produkte bleiben, wie sie sind. Diese können einige Tage, wie sie eingestellt sind, vorher hinzugefügt werden und auf wieder geändert werden.
#2 Es muss für Berater Admin oder für den User selbst deutlich ersichtlich sein warum ein Abo nicht versendet wird und wie der Status ist. Ist es Aktiv und wurde ordnungsgemäß ausgeführt, ist es in Aktiv beziehungsweise pausiert und bis wann, ist eine Zahlung nicht rausgegangen und warum zumindest hinschreiben, dass die Zahlung nicht funktioniert hat und so weiter.
#3 Hat ein Abo seine Mindestausführungen erreicht. Derzeit sechs Monate kann es pausiert oder auch gelöscht werden. Hier beim Löschen muss noch einmal deutlich geschrieben werden, was das Aufsicht hat, dass bei einem neuen Abo wieder die sechs Ausführungen nötig sind Und ob man das Abo nicht erst mal pausieren möchte.