Você muda o preço na página do produto. A nova oferta entra no ar e as próximas vendas começam.
Dias depois, um cliente pergunta por que a cobrança do mês anterior teve outro valor. O suporte abre o cadastro do plano e encontra apenas o preço novo.
A fatura continua lá. A regra que explica a fatura desapareceu.
Esse cenário ilustrativo não exige um sistema sofisticado para acontecer. Basta calcular o passado consultando uma configuração que foi feita para representar o presente.
Catálogo e histórico respondem a perguntas diferentes
O catálogo descreve o que está sendo oferecido. Uma fatura descreve uma obrigação de cobrança específica.
Se a fatura depende do preço atual para reconstruir seus itens, uma mudança comercial pode alterar retroativamente a explicação de compras antigas.
Considere um plano que incluía uma franquia de consultas e cobrava excedentes. A equipe aumenta a franquia para novos clientes.
Recalcular o último ciclo com a configuração atual pode fazer parecer que o excedente nunca existiu. A soma mudou porque a pergunta foi feita ao contrato errado.
O total precisa continuar explicável pelas condições aplicáveis àquele período.
A versão precisa acompanhar a compra
Uma modelagem útil preserva a referência da versão contratada e os dados usados no cálculo: período, unidade, quantidade, preço unitário e ajustes.
Isso não exige que todas as empresas implementem o mesmo banco de dados. Exige que uma alteração posterior não destrua a evidência da cobrança anterior.
Também exige separar duas decisões que costumam chegar juntas:
- Qual é a oferta para novas compras?
- Quando e sob quais condições a base existente passa para ela?
Publicar um preço novo não responde automaticamente à segunda.
A equipe comercial pode querer preservar condições antigas, migrar no próximo ciclo ou aplicar outra política. O sistema deve representar a escolha efetiva, não deduzi-la a partir da última linha editada.
A correção não deve parecer que o erro nunca existiu
Uma cobrança pode precisar de correção. Preservar histórico não significa proibir ajustes.
Significa registrar o ajuste com identidade, motivo e relação com a operação original, pelo procedimento adequado à fase da cobrança.
Se o consumo foi contado duas vezes, é importante identificar os eventos envolvidos. Se houve um desconto comercial, esse desconto não deve aparecer como um consumo menor que nunca aconteceu.
Do contrário, o financeiro encontra um total, o cliente encontra outro e a engenharia não consegue reproduzir nenhum deles.
O teste que a equipe pode executar
Escolha uma cobrança concluída num ambiente de teste. Anote seus itens e a regra que os produziu.
Publique uma nova versão do produto com outra condição. Em seguida, consulte a cobrança antiga e tente explicar o total sem depender da nova configuração.
Faça o mesmo com um ajuste posterior. O histórico deveria permitir entender tanto a cobrança quanto sua correção.
Esse teste captura um problema que uma validação apenas da página de preços não encontra.
Onde o billing começa a virar infraestrutura
Na Infi, o catálogo tem produto e versão publicada. A documentação distingue o preço base da versão e as taxas ligadas à medição. Essa separação dá nomes aos elementos da oferta antes de criar um link de pagamento. Guia de catálogo.
Configurar esses elementos continua exigindo uma decisão sobre a política comercial. Registrar uso sozinho também não cria um ciclo de cobrança; catálogo, inscrição e período precisam estar coerentes. O modelo documentado de billing hoje é em BRL. Configuração de cobrança.
Uma página de preços precisa mostrar o que vale agora.
O histórico financeiro precisa explicar o que valeu quando cada compra aconteceu.