Encaissement des amendesJeu

L’amende reste gérée dans SuperMDT : montant, statut, qui, quand. L’encaissement des amendes ajoute un canal de paiement en jeu : quand un dossier d’infraction est clôturé, son montant est prélevé ou facturé au personnage, et le paiement en jeu passe l’amende payée dans le MDT, sans qu’un agent ait à le déclarer.

Choisir le mode

Dans Configuration › Jeu › Intégrations › Encaissement des amendes, choisis le Mode d’encaissement (administrateurs, ou un grade qui a Administration déléguée › Régler le jeu) :

Mode	Ce qui se passe en jeu	Personnage hors ligne
Aucun (par défaut)	Rien. Un agent déclare le paiement à la main.	—
Prélèvement direct	Le montant est retiré de la banque du personnage (jamais en négatif).	Attend sa connexion.
Facture esx_billing	Une facture ESX ; payée, elle est versée au compte de société.	Facturé quand même.
Facture okokBilling Expérimental	Une facture okokBilling.	Attend sa connexion.
Facture qb-phone	Une facture dans le téléphone qb-phone (QBCore).	Facturé quand même.
Personnalisé	Ton script de factures, ou billing_ui / qs-billing (voir plus bas).	Selon le script.

Sous le réglage, SuperMDT liste les modes utilisables sur ce serveur (d’après ce que la passerelle a détecté) et t’avertit si le mode choisi ne l’est pas.

Comment ça se passe

1. Un agent clôture un dossier d’infraction qui a des amendes impayées, pour un citoyen qui est un personnage du jeu.
2. SuperMDT envoie une seule facture (ou un seul prélèvement) pour ce dossier. Jamais deux : l’identifiant est retenu par la passerelle, même après un redémarrage.
3. Le dossier affiche l’Encaissement en jeu : en cours d’envoi, en attente de la connexion du personnage, facture envoyée (en attente de paiement), payée en jeu, ou échec avec la raison.
4. Au paiement en jeu, l’amende passe payée toute seule : l’historique du dossier note « Amende de … payée en jeu », le journal d’audit « Le système a reçu du jeu le paiement de l’amende de … » (Impayée → Payée). En prélèvement direct, c’est immédiat : l’argent part au moment de l’envoi, l’amende est payée aussitôt. En mode facture, la passerelle écoute l’événement de paiement du script (esx_billing, qb-phone, billing_ui) ou relit la facture toutes les 60 s (okokBilling, qs-billing, CustomBilling.isPaid).

Le bouton Marquer payée reste sur le dossier pour les autres cas : amende réglée hors du jeu, script qui ne signale pas le paiement, ou résultat incertain vérifié en jeu.

Tant que la facture n’est pas partie, elle suit le casier (une amende réglée ou annulée à la main change le montant ou annule l’envoi). Une fois partie, elle ne change plus : annuler l’amende dans le MDT ne retire pas la facture en jeu. Un paiement ultérieur est journalisé, mais l’amende annulée reste annulée.

Repasser le mode à Aucun suspend les encaissements pas encore partis ; ils repartent si tu réactives un mode.

Relancer après un échec

Sur le dossier, Relancer l’encaissement renvoie un encaissement en échec (par exemple après « fonds insuffisants »). Il faut la permission Casiers & amendes › Relancer un encaissement (membres et plus par défaut, visible dans la matrice seulement quand l’intégration au jeu est activée) ; sans elle, le bouton reste visible mais verrouillé, avec l’aide « Réservé : Casiers & amendes › Relancer un encaissement ». Un résultat incertain n’est jamais relancé tout seul : vérifie en jeu, et marque l’amende payée à la main si besoin (Casiers & amendes › Marquer une amende payée). Voir Les permissions.

Les soins médicaux

Le même moteur encaisse aussi les soins du service médical, avec les mêmes modes (prélèvement direct, esx_billing, okokBilling, qb-phone, personnalisé, donc aussi billing_ui et qs-billing). La dette reste gérée dans le MDT : le passage médical est Payé ou Non payé (Dossiers médicaux).

Capture à venirgame-care-billing

Configuration › Jeu : la facturation des soins, service médical par service médical

• Le réglage. Dans Configuration › Jeu › Intégrations, section Facturation des soins, chaque service qui a les dossiers médicaux a son propre mode (Aucun par défaut). Il peut différer du mode des amendes. Le changement est journalisé.
• Le déclenchement : la signature. La facture part quand le passage est signé (Signer maintenant à la création, ou Signer ensuite), pour un patient qui est un personnage du jeu. Un passage non signé ne part jamais. Une seule facture par passage, jamais deux, même après un redémarrage de la passerelle.
• Le motif en jeu est « Soins n° 12 — EMS » (numéro du passage, sigle du service). L’argent va au compte de société du premier métier relié au service médical (« ambulance »).
• Le paiement détecté en jeu passe le passage Payé tout seul, au nom du système : l’historique du passage note « Le système a reçu du jeu le paiement de la facture de soins », le journal d’audit aussi (sans contenu médical).
• Tant que la facture n’est pas partie, elle suit le passage : un montant modifié change la facture ; Marquer payé, une suppression ou une modification qui retire la signature l’annulent. Une fois partie, elle ne change plus.
• L’état s’affiche sur le passage, sous Facture en jeu : en cours d’envoi, en attente de la connexion du personnage, facture envoyée, payée en jeu, échec avec la raison, ou annulée.
• Relancer. Après un échec (fonds insuffisants…), Relancer la facture la renvoie. Il faut Dossiers médicaux › Relancer une facture de soins (membres et plus par défaut, visible dans la matrice quand l’intégration au jeu est activée) ; sans elle, le bouton est verrouillé. Un résultat incertain n’est jamais relancé : vérifie en jeu.

Côté passerelle, rien à régler de plus : la commande fine porte source: "care" (le mode Personnalisé reçoit fine.source dans CustomBilling.issue et l’événement supermdt:fineIssued), et la présentation de la passerelle annonce les modes des soins (careModes) pour brancher leurs crochets de paiement.

Compatibilité

Testé en jeu essayé en jeu sur un vrai serveur. Vérifié sur le code écrit d’après le code source ou l’API native du script, couvert par les tests de la passerelle, pas encore essayé en jeu. Expérimental d’après la documentation publique de l’éditeur, jamais essayé : vérifie-le sur ton serveur avant de t’y fier.

Prélèvement direct : où va l’argent

Le prélèvement marche sur les trois frameworks, personnage connecté. La banque décide de la ligne d’historique et du crédit au compte du service :

Framework	Banque	État	Ligne chez le joueur	Montant versé au compte du service
ESX, QBCore, Qbox	Renewed-Banking	Vérifié sur le code	Oui	Oui
QBCore	qb-banking	Vérifié sur le code	Oui	Oui (compte de métier)
ESX	esx_addonaccount (+ esx_banking, sd-phone)	Vérifié sur le code	Avec esx_banking ou sd-phone	Oui (society_ + métier)
ESX, QBCore, Qbox	okokBanking, qs-banking, snipe-banking, tgg-banking	Expérimental	Oui	Oui
ESX, QBCore, Qbox	fd_banking	Expérimental	Non	Oui
ESX, QBCore, Qbox	Aucune banque reconnue	Vérifié sur le code	Non	Non

Qbox n’a pas de factures natives : le prélèvement direct fait la même chose que la commande /fine de qbx_police.

Factures

Framework	Script	Mode	État	À savoir
ESX	esx_billing	Facture esx_billing	Vérifié sur le code	Hors ligne possible. Payée au compte society_ du premier métier relié : il faut un métier relié au service. Montant plafonné par esx_billing (100 000 par défaut). Non refusable (esx_billing ne sait pas refuser). Au démarrage de la passerelle, une facture payée pendant son arrêt est retrouvée et passe payée.
ESX, QBCore	okokBilling	Facture okokBilling	Expérimental	Personnage connecté. Paiement détecté en relisant la facture toutes les 60 s.
QBCore	qb-phone	Facture qb-phone	Testé en jeu	Hors ligne possible, non refusable si la table phone_invoices a la colonne candecline (sinon supermdt status prévient que le joueur pourra peut-être la refuser ; correctif : ALTER TABLE phone_invoices ADD COLUMN candecline INT(1) NOT NULL DEFAULT 1). Une facture refusée reste facturée dans SuperMDT. Une erreur de la base est un échec clair, relançable. Au démarrage de la passerelle, une facture payée pendant son arrêt passe payée. Inutile si le serveur utilise un autre téléphone (lb-phone, qs-smartphone…) : personne ne lirait la facture.
ESX, QBCore	billing_ui (jaksam)	Personnalisé	Expérimental	Fourni d’office : utilisé en mode Personnalisé tant que custom.lua n’est pas complété. Hors ligne possible. Il faut un métier relié.
ESX, QBCore	qs-billing (Quasar)	Personnalisé	Expérimental	Fourni d’office, après billing_ui. Personnage connecté. Paiement détecté en relisant la facture. Il faut oxmysql.
ESX, QBCore	codem-billing, RxBilling, tgg-billing	Personnalisé, à compléter	Non pris en charge	Pas d’adaptateur fourni : leur API publique ne permet pas de facturer sans joueur émetteur connecté, ou de savoir qu’une facture est payée. Détectés et signalés. Utilisables par le mode Personnalisé si tu complètes custom.lua.

Le mode Personnalisé

Le mode Personnalisé branche n’importe quel script de factures (CodeM, RxBilling, tgg-billing, une application lb-phone, un script maison) par un fichier de la passerelle : integrations/billing/custom.lua.

1. Ouvre integrations/billing/custom.lua.
2. Complète CustomBilling.issue(fine, done) : crée la facture dans ton script, puis appelle done avec son résultat.
3. Si ton script ne prévient pas du paiement, complète aussi CustomBilling.isPaid(reference) : la passerelle l’interroge toutes les 60 s.
4. Passe CustomBilling.configured = true.
5. ensure supermdt-bridge, puis choisis Personnalisé dans SuperMDT.

Un paiement peut aussi être signalé depuis n’importe quelle ressource par exports['supermdt-bridge']:markFinePaid(fineRef). L’événement serveur supermdt:fineIssued est déclenché à chaque facture, dans tous les modes.

Ordre de priorité en mode Personnalisé : ton custom.lua complété, puis billing_ui, puis qs-billing. Sans aucun des trois, l’encaissement échoue avec « mode personnalisé non configuré ».

Garde une copie de custom.lua

Ce fichier t’appartient. Avant une mise à jour de la passerelle, garde ta version complétée pour la remettre après.

Dépannage

Ce que tu vois	Cause	Que faire
« ressource de factures absente du serveur »	Mode choisi sans son script (esx_billing, okokBilling, qb-phone)	supermdt status (ligne « Amendes ») ; changer de mode.
« mode personnalisé non configuré »	custom.lua pas complété, ni billing_ui ni qs-billing	Compléter le fichier, CustomBilling.configured = true, ensure supermdt-bridge.
« En attente de la connexion du personnage »	Prélèvement direct, okokBilling ou qs-billing : personnage hors ligne	Il part à sa prochaine connexion.
« fonds insuffisants »	Solde trop bas au prélèvement	Relancer l’encaissement plus tard.
« résultat incertain »	Serveur arrêté pendant l’encaissement, ou facture introuvable après création	Vérifier en jeu ; marquer payée à la main si besoin.
« le script de factures a refusé » (esx_billing)	Montant au-delà du plafond d’esx_billing	Relever Config.MaxBillAmount d’esx_billing.