Guthabenkonto, Kontingent und mein Abonnement – Systembeschreibung
Konto und Guthabenjournal, die Regel des sichtbaren Bereichs, Endpunkte für Aufladung, Belastung und manuellen Verbrauch, Entscheidungen der Kontingent-Engine und die Selbstansicht.
Überblick
Verwaltung der Guthabenkonten der Benutzer und Selbstansicht von Guthaben und Verbrauch. Der Menüpunkt „Guthabenkonto“ ist ausgeblendet (per Direktadresse erreichbar); „Mein Abonnement“ erscheint für jeden angemeldeten Benutzer. Die Tabellennamen tragen in der Datenbank das eigene Präfix der Installation.
Datenmodell
| Tabelle | Rolle |
|---|---|
subscription_account | Konto: Benutzer, Heimatmandant (company_client_id), allow_negative, credit_limit |
subscription_credit | Guthabenjournal (Dlbtcredit: balance(), grant(), charge(), entries()) |
usage, usage_event | Verbrauch und Ereignisse |
permission_scope | die Inhaltsregel subscription_usage |
Sichtbarer Bereich
Super-Admin: alle Konten. Andere: getAllowedAccountUserIds() – die eigene Zeile, dazu die in einer Inhaltsregel subscription_usage genannten Benutzer; ohne Regel alle Benutzer des eigenen Mandanten. Zeilen-Endpunkte schützt accountInScope().
Endpunkte
| Endpunkt | Schlüssel | Verhalten |
|---|---|---|
account.list, account.entries | list (BASE) | Saldo, Negativlimit; der Aufklapper zeigt 100 Guthabenbuchungen und Verbrauch je Funktion |
account.topup | topup (SYSTEM) | out: Dlbtcredit::charge() (error_no_cover); in: Dlbtbilling::payIn() (Guthaben + Rechnung + Belegentwurf), bei Fehlschlag Dlbtcredit::grant() |
account.setlimit | setlimit (SYSTEM) | liest und speichert allow_negative, credit_limit |
account.open | open (SYSTEM) | ensureAccount(user_id) |
account.usageadd | usageadd | nur für nicht automatisch gemessene Funktionen; neue manuelle ID, Dlbtquota::consume(..., 'manual', id) |
account.usagereverse | usagereverse | reverseUsageEvent() |
account.my, usage, entrieslist, requestorder | my (SYSTEM) | eigenes Guthaben, Kontingente (Dlbtresource::balances), Wallet, Prämien, Bestellungen, Zeilen und Kontingent je Funktion, Guthabenjournal mit 500 Einträgen; requestorder benachrichtigt die bestellberechtigten Benutzer im sichtbaren Bereich |
Kontingent-Engine (Dlbtquota)
check($user, $feature, $qty) → ok, overage (aufgebraucht, aber deckbar), need_credit (mit Preis, ohne Deckung), need_plan (ohne Preis, nur Tarifwechsel). Das Limit stammt aus den Limitfeldern der eigenen Zeile, sonst aus dem Tarif; ein Kontingent im Ressourcenbuch entscheidet, falls vorhanden; bei metered ist jede Einheit kostenpflichtig. Preis: Mehrverbrauchspreis, sonst Einheitspreis. Die Überschreitungsregel folgt der Einstellung (standardmäßig automatische Guthabenbelastung). Geldquelle: Wallet des Mandanten, falls verfügbar, sonst das Guthabenkonto des Benutzers. consume() bucht nach erfolgreicher Aktion, idempotent.
Bekannte Einschränkungen
setlimitverlässt den Fehlerzweig vor der Ausgabe (leere Antwort).openprüft den Inhaltsbereich des angegebenen Benutzers nicht.usagereverseprüft den Inhaltsbereich ERST nach der Stornierung.my,usage,entrieslistundrequestorderrufen keincanActionauf; der ansehbare Benutzer ist auf den sichtbaren Bereich begrenzt.