Skip to main content

​
Edición de tasas desde el panel

Dos operaciones en la página de un producto, y la diferencia entre ellas importa: Ambas guardan únicamente las reglas del producto que está mirando. El resto del ámbito queda intacto, así que establecer * para promo no puede perturbar * para nada más. El editor de ámbito completo en la página Precios sigue reemplazando un ámbito por completo, lo cual es correcto ahí, porque le muestra todo.
Las reglas propias de una cuenta se prueban primero y gana la primera coincidencia, por lo que cualquier cosa que lleve la cuenta vence al valor por defecto, incluido un catch-all desnudo.Eso es lo que hace de una tarifa negociada un override en lugar de una sugerencia. También significa que un catch-all a nivel de cuenta desactiva silenciosamente todos los valores por defecto que establezca después.

​
Dos identidades, no una

Si el crédito de una cuenta cuadra se comprueba contra dos ecuaciones. Equivocarse en esto informa una falsa discrepancia en cada cuenta, así que vale la pena enunciarlo con precisión.
La ecuación obvia es incorrecta. acreditado − consumido = saldo + reservado se escribió así en el diseño y los datos la refutaron inmediatamente: estaba desviada exactamente en el consumo en cada cuenta.El consumo nunca toca las columnas de saldo. El crédito se reserva en bloques (balance -= n, reserved += n), se gasta desde un contador en memoria, y la parte gastada nunca se vuelve a escribir. Por tanto reserved es un contador de consumo vitalicio, no una retención, y cada movimiento que la base de datos ve deja balance + reserved sin cambios.
La identidad del dinero se cumple a la unidad en cada cuenta, que es lo que hace significativa una discrepancia genuina.

​
Qué se excluye, y por qué

​
Vitalicia, nunca un periodo

El crédito es un total corrido. Cualquier ventana más corta necesita un saldo de apertura que nada registra. Y una cifra de apertura errónea inventa una discrepancia cada vez que se ejecuta.
Por eso “concilie esta cuenta para marzo” no es una pregunta a la que los datos puedan responder. “Concilie esta cuenta” sí lo es, y siempre lo ha sido.

​
De dónde vienen los dos lados

Nunca ambos para un día. Esa es la unión que hace que la conciliación sobreviva a la ventana de retención: una vez un día se resume y se purga, su consumo sigue contando.

​
Cuando los números no coinciden

Trabaje en este orden:
1

¿Hay recargas pendientes?

Un RECHARGE para una cuenta sin fila account_balance no acredita nada y queda pendiente. Está en el libro mayor y no en el saldo, que es exactamente un hueco del lado del dinero.
2

¿Hubo un apagado no limpio?

Un kill -9 vara crédito en reserved. balance + reserved sigue conservándose, así que la identidad del dinero se cumple. Pero la cuenta tiene menos gastable de lo que debería hasta que se ejecute POST /ops/credit/release.
3

¿Va el rollup atrasado?

Un día ni resumido ni aún en cdr_submit es consumo que nadie cuenta. Se supone que la purga hace esto imposible; compruebe que no se la ha saltado.
4

¿Lee el panel la misma base de datos?

METRICS_DATABASE_URL frente al FIREFLO_DB_URL de la pasarela. Una división aquí hace que cada cifra discrepe de una forma que parece un bug contable.

​
Relacionado

Cómo funciona la tarificación

Ámbitos, el default * y LCR.

Crédito prepago

Bloques, reservas y el libro mayor.