Validação em lote parece apenas a versão repetida da conferência de um número, mas o gargalo é outro. Com uma entrada isolada, quase todo o esforço está na aritmética; com milhares de linhas, o esforço está em limpar dados heterogêneos, decidir qual regra se aplica a cada item e produzir um relatório que alguém consiga usar. Este texto descreve um fluxo de quatro etapas que resolve a maior parte dos casos.
O que muda quando a validação é em lote?
Três coisas mudam de escala ao mesmo tempo. A entidade deixa de ser o número e passa a ser a linha, o que significa que cada resultado precisa carregar a sua origem. A variedade aumenta: um lote real mistura formatos, separadores, campos vazios e colagens truncadas. E o output deixa de ser uma mensagem na tela para virar um relatório que outra pessoa vai ler depois, possivelmente sem contexto algum.
Há também uma diferença de tolerância ao erro. Em uma conferência única, uma resposta errada custa pouco. Em um lote, uma regra mal aplicada reprova milhares de linhas legítimas de uma vez — e o retrabalho é proporcional ao tamanho do arquivo.
Por isso o fluxo não deve tentar resolver tudo de uma vez. Ele avança em camadas, e cada camada é verificável separadamente.
| Etapa | Pergunta que responde | Saída esperada |
|---|---|---|
| Limpar | Qual é o valor, sem ruído de formatação? | Sequência normalizada |
| Encaminhar | Qual esquema se aplica a esta linha? | Identificador do esquema |
| Classificar | O que a conferência concluiu? | Resultado por camada |
| Relatar | Onde está o problema e de que tipo? | Linha, campo e motivo |
Cada etapa tem um produto distinto, e isso é deliberado: quando algo dá errado no fim, é possível saber em qual delas o problema nasceu.
Limpar: a etapa que decide todo o resto
A limpeza decide a qualidade de tudo o que vem depois. O objetivo é reduzir cada valor a uma sequência canônica, removendo separadores de exibição, espaços, tabulações invisíveis e caracteres de controle que sobreviveram à exportação.
A armadilha clássica é a planilha. Um valor pode ter sido convertido em número ao ser digitado, perdendo zeros à esquerda, ou ter sido salvo como texto com um apóstrofo à frente. Se o lote vem de uma planilha, a primeira tarefa é recuperar o texto original — não há conferência correta sobre um valor que a ferramenta de origem já alterou.
A segunda armadilha é a entrada mista: algumas linhas com máscara, outras sem, algumas com o número inteiro, outras com o campo cortado. A limpeza precisa ser idempotente e tolerante, e precisa registrar o que mudou, porque linhas alteradas na limpeza são as suspeitas naturais quando o resultado surpreende.
Vale guardar as duas formas: o valor original e o normalizado. Sem o original, ninguém consegue auditar o que a rotina fez; sem o normalizado, a comparação entre linhas diferentes fica impossível.
Encaminhar cada linha para o esquema certo
Depois da limpeza, é preciso decidir qual regra conferir. Em um lote homogêneo, isso é trivial: todas as linhas seguem o mesmo esquema. Em um lote misto — o caso comum quando o arquivo reúne clientes de vários países —, a escolha do esquema é onde a maioria dos erros silenciosos acontece.
O encaminhamento deve ser explícito e auditável. Para cada linha, o resultado precisa dizer qual esquema foi aplicado. Se o esquema vier de uma coluna do próprio arquivo, ela precisa ser tratada como dado de entrada, e não como verdade: quando a coluna aponta para um país e o número claramente não corresponde, a divergência é informação útil.
Quando não há esquema disponível para a linha, a resposta é a mesma discutida em números sem dígito verificador: declarar ausência de regra, em vez de reprovar por padrão. Em lotes grandes, essa distinção é o que separa um relatório acionável de uma lista de alarmes falsos.
Classificar sem perder a linha de origem
Classificar é atribuir a cada linha um resultado, e o resultado precisa ter granularidade suficiente para não destruir a informação. Um único valor booleano por linha joga fora exatamente o que quem vai corrigir o arquivo precisa saber.
Uma classificação útil separa, no mínimo, quatro conclusões: a sequência confere com a regra aplicada, contraria a regra, atende apenas ao formato esperado ou não tem regra conhecida. Cada uma delas sugere uma ação diferente — corrigir o valor, revisar o esquema aplicado, acompanhar manualmente ou simplesmente seguir adiante.
E cada resultado precisa carregar a sua origem: qual arquivo, qual linha, qual campo. Sem isso, um relatório de dez mil linhas vira um problema de arqueologia. Em arquivos longos, vale também considerar uma chave estável por registro, porque a ordem das linhas pode mudar entre uma execução e outra.
| Conclusão | Ação que ela sugere |
|---|---|
| Confere | Nada a fazer |
| Não confere | Corrigir o valor e rodar de novo |
| Apenas formato | Decidir se a checagem é suficiente |
| Sem regra | Conferir por outro caminho |
Como relatar de um jeito que alguém consiga agir?
O relatório é a parte mais subestimada do fluxo. Ele costuma ser escrito para quem construiu a rotina, e lido por quem não participou de nada.
Um bom relatório responde a três perguntas, nessa ordem: quantas linhas foram processadas e quantas ficaram em cada conclusão; quais linhas merecem atenção primeiro; e o que exatamente está errado em cada uma delas, com o valor original e o motivo da conclusão.
Duas decisões ajudam muito. A primeira é agrupar por motivo, e não por ordem de aparição: dez linhas com o mesmo problema se resolvem de uma vez, e ver o agrupamento revela padrões — um lote inteiro reprovado pelo mesmo esquema costuma indicar erro de encaminhamento, não de dados.
A segunda é incluir amostras. Nem todo mundo vai ler dez mil linhas; mostrar alguns casos por motivo permite decidir em segundos se o relatório faz sentido.
Para quem desenvolve: idempotência e reprocessamento
Três propriedades tornam o fluxo sustentável ao longo do tempo.
A primeira é a idempotência. Rodar o mesmo lote duas vezes deve produzir o mesmo resultado e não deve duplicar registros nem acumular efeitos. Isso exige separar a conferência da gravação: o lote gera um relatório, e a gravação é uma decisão posterior.
A segunda é o reprocessamento seletivo. Depois de corrigir parte do arquivo, deve ser possível rodar de novo apenas as linhas afetadas. Isso exige que o resultado carregue a origem de forma estável, conforme discutido acima.
A terceira é o registro da versão das regras aplicadas. Quando uma regra muda, é importante saber quais lotes foram processados com a versão anterior — e, eventualmente, reprocessá-los com a nova. O ponto de contato com serviços remotos, quando existe, merece o mesmo cuidado descrito em validação na API.
Um detalhe operacional que evita sustos: limitar o tamanho do relatório na interface, mas manter o arquivo completo disponível para download. Ninguém navega confortavelmente em dezenas de milhares de linhas.
As listas e os arquivos mencionados nos exemplos são fictícios. Um relatório de validação em lote atesta consistência de formato dentro do critério aplicado, e não a regularidade nem a autenticidade de cada registro.
Próximos passos
Se o seu lote conversa com um serviço remoto, o texto sobre validação na API trata da fronteira entre cliente e servidor. Para revisar as camadas que a conferência precisa distinguir, leia validação de número. E para testar o resultado de uma sequência isolada antes de montar o lote, use a ferramenta de validação de número.