Skip to main content

​
Editando rates a partir do painel

Duas operações na página de um product, e a diferença entre elas importa: Ambas salvam apenas as regras do product que você está olhando. O restante do scope é intocado, portanto configurar * para promo não perturba * para nada mais. O editor de scope inteiro na página Pricing ainda substitui um scope por completo. E isso está correto ali, porque mostra tudo dele.
As regras próprias de uma account são tentadas primeiro e a primeira que casar vence, portanto qualquer coisa que a account carregue bate o default. Inclusive um catch-all puro.É isso que faz de uma tarifa negociada um override em vez de uma sugestão. Também significa que um catch-all no nível da account desabilita silenciosamente todos os defaults que você configurar depois.

​
Duas identidades, não uma

Se o crédito de uma conta bate é verificado contra duas equações. Errar isso reporta uma discrepância falsa em toda conta, portanto vale a pena declarar com precisão.
A equação óbvia está errada. credited − consumed = balance + reserved foi escrita dessa forma no design e os dados a refutaram imediatamente. Estava errada por exatamente o consumo em toda conta.Consumo nunca toca as colunas de balance. Crédito é reservado em blocos (balance -= n, reserved += n), gasto de um contador em memória, e a parte gasta nunca é escrita de volta. Portanto reserved é um contador de lifetime-consumed, não um hold, e todo movimento que o banco vê deixa balance + reserved inalterado.
A identidade do dinheiro se mantém no décimo em toda account, o que é o que torna uma discrepância genuína significativa.

​
O que é excluído, e por quê

​
Lifetime, nunca um período

Crédito é um total corrente. Qualquer janela mais curta precisa de um saldo inicial que nada registra. E uma cifra inicial errada inventa uma discrepância toda vez que roda.
Portanto, “reconcilie esta conta para março” não é uma pergunta que os dados podem responder. “Reconcilie esta conta” é, e sempre foi.

​
De onde vêm os dois lados

Nunca ambos para um dia. Esse é o join que faz a reconciliação sobreviver à janela de retenção: uma vez que um dia é resumido e purgado, seu consumo ainda conta.

​
Quando os números não batem

Vá por esta ordem:
1

Há recharges pendentes?

Um RECHARGE para uma account sem linha account_balance credita nada e permanece pendente. Está no ledger e não no balance — o que é exatamente uma lacuna no lado do dinheiro.
2

Houve um shutdown não limpo?

Um kill -9 deixa crédito preso em reserved. balance + reserved ainda é conservado, portanto a identidade do dinheiro se mantém — mas a account tem menos gastável do que deveria até que POST /ops/credit/release rode.
3

O rollup está atrasado?

Um dia nem resumido nem ainda em cdr_submit é consumo que ninguém conta. O purge deveria tornar isso impossível; verifique se ele não foi contornado.
4

O painel está lendo o mesmo banco?

METRICS_DATABASE_URL contra o FIREFLO_DB_URL do gateway. Uma divergência aqui faz toda cifra discordar de uma forma que se parece com um bug de contabilidade.

​
Relacionado

Como o pricing funciona

Scopes, o default * e LCR.

Crédito prepaid

Blocos, reservas e o ledger.