Skip to main content

​
Éditer les tarifs depuis le panneau

Deux opérations sur la page d’un product, et la différence entre elles compte : Les deux ne sauvent que les règles du product que vous consultez. Le reste du scope reste intact, donc définir * pour promo ne peut pas déranger * pour autre chose. L’éditeur de scope complet sur la page Pricing remplace toujours un scope en entier — ce qui est correct là, parce qu’il vous en montre la totalité.
Les règles propres à un compte sont essayées en premier et la première qui correspond gagne, donc tout ce que le compte porte bat le défaut — y compris un attrape-tout nu.C’est ce qui fait qu’un tarif négocié est un override plutôt qu’une suggestion. Cela signifie aussi qu’un attrape-tout au niveau du compte désactive silencieusement chaque défaut que vous définissez ensuite.

​
Deux identités, pas une

Si le crédit d’un compte s’additionne se vérifie contre deux équations. Se tromper à ce sujet signale un faux écart sur chaque compte, donc cela vaut la peine de l’énoncer précisément.
L’équation évidente est fausse. credited − consumed = balance + reserved était écrite ainsi dans la conception et les données l’ont réfutée immédiatement — elle était décalée d’exactement la consommation sur chaque compte.La consommation ne touche jamais les colonnes de solde. Le crédit est réservé par blocs (balance -= n, reserved += n), dépensé depuis un compteur en mémoire, et la partie dépensée n’est jamais réécrite. Donc reserved est un compteur consommé sur la vie du compte, pas un blocage, et chaque mouvement que la base voit laisse balance + reserved inchangé.
L’identité de l’argent tient à l’unité près sur chaque compte, ce qui rend un vrai écart significatif.

​
Ce qui est exclu, et pourquoi

​
Sur la vie du compte, jamais une période

Le crédit est un total courant. Toute fenêtre plus courte nécessite un solde d’ouverture que rien n’enregistre — et un chiffre d’ouverture erroné invente un écart chaque fois qu’il est exécuté.
Donc « réconcilier ce compte pour mars » n’est pas une question à laquelle les données peuvent répondre. « Réconcilier ce compte » l’est, et l’a toujours été.

​
D’où viennent les deux côtés

Jamais les deux pour un même jour. C’est la jointure qui fait que la réconciliation survit à la fenêtre de rétention : une fois qu’un jour est agrégé et purgé, sa consommation compte toujours.

​
Quand les chiffres ne s’accordent pas

Procédez dans cet ordre :
1

Y a-t-il des rechargements pending ?

Un RECHARGE pour un compte sans ligne account_balance ne crédite rien et reste pending. Il est dans le grand livre et pas dans le solde — ce qui est exactement un écart côté argent.
2

Y a-t-il eu un arrêt non propre ?

Un kill -9 bloque du crédit dans reserved. balance + reserved est toujours conservé, donc l’identité de l’argent tient — mais le compte a moins de dépensable qu’il ne devrait jusqu’à ce que POST /ops/credit/release s’exécute.
3

Le rollup est-il en retard ?

Un jour ni agrégé ni encore dans cdr_submit est de la consommation que personne ne compte. La purge est censée rendre cela impossible ; vérifiez qu’elle n’a pas été contournée.
4

Le panneau lit-il la même base de données ?

METRICS_DATABASE_URL contre le FIREFLO_DB_URL du gateway. Un décalage ici fait que chaque chiffre est en désaccord d’une manière qui ressemble à un bug comptable.

​
En lien

Comment fonctionne le pricing

Scopes, le défaut *, et LCR.

Crédit prépayé

Blocs, réservations et le grand livre.