O teste de formulário de cobrança é a etapa que decide se uma fatura sai com os dados certos ou se o financeiro vai descobrir o problema semanas depois. Formulários de cobrança empresarial reúnem campos que parecem simples, mas escondem ramificações que variam conforme o país e o tipo de cliente. Neste texto, mostramos o que precisa ser preenchido, quais casos costumam escapar dos testes e como montar uma matriz que cobre o essencial.
O que um formulário de cobrança empresarial precisa ter?
Um formulário de cobrança para empresas costuma pedir seis blocos de informação: identificação do negócio (razão social e forma jurídica), número de registro, número de VAT ou identificação fiscal equivalente, endereço de cobrança, pessoa de contato e, em muitos casos, uma referência interna do comprador, como o número de pedido.
O bloco que muda de país para país é o dos identificadores. Alguns lugares exigem o número de VAT na fatura, outros pedem o número de registro, e há situações em que o número fiscal precisa aparecer com uma descrição específica ao lado. Por isso o formulário não pode ter uma regra única: ele precisa perguntar o país antes de decidir o que exigir.
Há também uma diferença de fundo entre empresas e pessoas físicas. Uma fatura emitida para um negócio carrega identificadores que não existem no caso de uma pessoa, e o caminho de preenchimento é diferente. Tratar os dois casos com o mesmo formulário é uma decisão aceitável, desde que o teste cubra as duas situações.
Por que as quatro ramificações escapam dos testes?
Porque o caminho feliz domina as demonstrações. Quem testa manualmente costuma usar um exemplo completo, com todos os campos preenchidos e um cliente nacional, e esse caminho raramente quebra. O que quebra são as combinações menos óbvias.
São quatro as ramificações que mais aparecem em produção:
- Empresa com número de VAT. O caso mais testado, e ainda assim costuma falhar quando o número vem de outro país.
- Empresa sem número de VAT. Muito comum em negócios pequenos e em países onde a inscrição não se aplica. O formulário precisa permitir seguir adiante ou explicar por que não.
- Operação entre países. Muda o conjunto de campos obrigatórios, o idioma das mensagens e a forma de calcular o imposto.
- Cliente pessoa física. Não tem identificador empresarial e não pode ser obrigado a informar um.
A ramificação que mais causa retrabalho é a segunda, porque envolve uma decisão de negócio e não apenas uma validação: o sistema precisa saber se aceita seguir sem o número e, se aceitar, o que a fatura mostra no lugar dele.
A matriz de casos que costuma faltar
A tabela abaixo cruza o tipo de cliente com a presença do identificador fiscal. Ela serve como ponto de partida para a matriz de testes.
| Caso | Tipo de cliente | Identificador fiscal | O que verificar |
|---|---|---|---|
| Um | Empresa nacional | Presente e válido | Fatura completa e sem aviso |
| Dois | Empresa nacional | Ausente | Mensagem clara e caminho alternativo |
| Três | Empresa estrangeira | Presente | Campos e mensagens do país do cliente |
| Quatro | Empresa estrangeira | Ausente | Decisão de negócio registrada |
| Cinco | Pessoa física | Não se aplica | Campos empresariais ocultos ou opcionais |
| Seis | Empresa | Presente e malformado | Erro localizado no campo certo |
Note que o caso seis não é sobre aceitar ou recusar: é sobre dizer ao usuário exatamente qual campo está errado. Uma mensagem genérica no topo do formulário obriga a pessoa a procurar o problema sozinha.
Fatura única, reenvio e repetição
Além dos campos, o fluxo de emissão tem armadilhas próprias, e elas aparecem justamente quando algo dá errado.
A primeira é a repetição de envio. Se o usuário clica duas vezes no botão, ou se a rede cai no meio da operação, o sistema não pode gerar duas faturas com o mesmo número. A solução usual é uma chave de operação combinada com o registro do que já foi processado, de modo que a segunda tentativa devolva o mesmo resultado em vez de criar um documento novo.
A segunda é a emissão parcial. Quando a fatura é gerada em etapas, uma falha no meio pode deixar o registro criado sem o documento correspondente, ou o contrário. O teste precisa provocar essa falha de propósito e verificar se o sistema sabe se recuperar.
A terceira é o reenvio para o mesmo destinatário. Reenviar uma fatura já emitida é diferente de emitir uma nova: o identificador do documento deve ser preservado, e o histórico precisa deixar claro que houve reenvio, e não uma segunda cobrança.
Dados fictícios para rodar a matriz
No gerador de dados de empresa desta página, você escolhe o país e recebe uma ficha com nome, forma jurídica, sede, telefone e os números de registro e de VAT correspondentes. Como os valores são fabricados, dá para rodar as seis linhas da matriz sem usar nenhum dado de cliente verdadeiro, e o resultado pode ser anexado ao próprio caso de teste.
Se a sua dúvida está nos identificadores, o texto sobre números de VAT explica por que formato e inscrição são perguntas diferentes. Se o problema é o endereço de cobrança, a leitura sobre o checklist de testes de formulário de endereço internacional cobre esse campo em detalhe. E a página do Canadá mostra como o formulário se comporta em um país específico.
Para quem desenvolve: ordem de validação e erro localizado
Dois assuntos decidem a qualidade percebida desse formulário: a ordem em que as verificações rodam e a precisão das mensagens.
Sobre a ordem, valide primeiro o que é local e determinístico. País, tipo de cliente e presença dos campos obrigatórios não dependem de rede e podem ser conferidos de imediato. Deixe a consulta externa, se houver, para o fim e nunca deixe que ela impeça o usuário de continuar quando estiver indisponível.
Sobre as mensagens, cada erro deve apontar o campo, dizer o que se esperava e não usar termos internos. Uma frase como “identificador inválido para o país selecionado” é aceitável; “erro de validação” não é.
Três cuidados fecham o desenho:
- Idempotência explícita. Toda operação de emissão deve ser identificada por uma chave que o cliente envia, e o sistema deve devolver o mesmo resultado para a mesma chave.
- Marcação visível dos dados de teste. As fichas usadas em homologação precisam ser reconhecíveis como fictícias em qualquer tela, relatório ou captura de tela.
- Ambiente separado. Nada de apontar o formulário de teste para o serviço de emissão real: quando isso acontece, uma bateria de testes vira uma série de documentos com valor legal.
Se o seu processo envolve aprovação de empresas antes da cobrança, vale ver o checklist de teste de KYB, porque a ordem entre aprovação e emissão também precisa ser testada.
Próximos passos
Monte a matriz de seis casos em uma planilha, gere as fichas necessárias no gerador de dados de empresa e rode o formulário duas vezes seguidas com a mesma chave de operação para ver se a segunda tentativa cria um documento duplicado.
Este texto trata apenas de testes em ambiente controlado. Os exemplos são fictícios, nenhum dado de cliente real é utilizado e o conteúdo não deve servir para emitir documentos com valor fiscal ou representar operações comerciais verdadeiras.