Resposta direta
Padrão de preenchimento se resolve com uma decisão escrita por campo, não com treinamento. Para cada campo do cadastro, alguém precisa definir o que ele aceita, quem responde pela regra e o que acontece quando o valor chega fora dela. O trabalho começa pelos campos que entram em relatório, contrato ou cobrança. Depois disso, a regra precisa caber no momento do preenchimento, não numa conferência posterior. Campo sem responsável nomeado volta a divergir.
- Objetivo
- Orientar implementação
- Formato indicado
- Projeto de implementação
- Atualizado em
O que esta página acrescenta: Trata o padrão como decisão de conteúdo por campo, não como regra de validação técnica do sistema.
A regra nasce do uso do campo, não do formulário
Antes de fechar formato, vale listar em que decisões o campo participa: relatório gerencial, emissão de contrato, cálculo de margem, cobrança. Campo que não entra em nenhuma decisão pode continuar livre ou deixar de ser obrigatório.
Para cada campo que entra em decisão, a regra precisa cobrir o que é aceito, quem decide quando surge um caso novo e onde o padrão fica registrado. Registro em documento acessível, não na memória de quem opera há mais tempo.
Onde o padrão costuma quebrar depois de definido
O padrão quebra na digitação manual, na importação de planilha e na troca de sistema. São portas de entrada diferentes, e cada uma aceita um conjunto próprio de valores se ninguém tiver combinado o contrário.
Toda porta de entrada precisa aceitar a mesma regra. Se a planilha aceita o que o formulário recusa, o padrão existe só no papel, e a conferência posterior vira trabalho recorrente.
O que o padrão de preenchimento não resolve
Padrão de campo não corrige cadastro duplicado, não decide qual sistema é a fonte do dado e não substitui a conciliação entre bases. Também não serve para campo cuja resposta muda por contexto, como observação de atendimento.
Em cadastro pequeno, com um único responsável pela entrada, o custo de escrever e manter a regra pode passar do benefício. Nesse caso, faz sentido fixar apenas os campos que alimentam relatório ou obrigação fiscal.
Recurso prático
O que a regra precisa definir por tipo de campo
| Tipo de campo | Decisão que precisa estar por escrito |
|---|---|
| Campo de identificação, como documento ou código | Formato aceito, quando é obrigatório e o que fazer quando o valor não existe na fonte |
| Campo de classificação, como segmento ou categoria | Lista fechada de valores, quem pode incluir item novo e o que fazer com o valor antigo |
| Campo de texto livre, como observação ou descrição | Limite de uso, o que não pode ser registrado ali e onde a informação deve morar de fato |
O erro mais comum é tratar o campo de texto livre como área de recado. Quando ele passa a guardar informação operacional, a regra perde sentido, porque não há lista fechada para comparar.
Sobre o que está escrito aqui
Conceitos relacionados: dicionário de valores · campo obrigatório · responsável pelo campo · regra de preenchimento · origem do cadastro. Exemplos são ilustrativos. Não há cliente, resultado, preço, prazo ou certificação nesta página. Quando o formato indicado é Projeto de implementação, ele descreve uma possibilidade de trabalho — a conversa inicial avalia contexto e aderência.
Para continuar
- Integrações, sistemas e qualidade de dados — Página central do tema
- Dados desatualizados: o que precisa estar em dia — dados desatualizados
- Validação na entrada: onde o dado errado nasce — dado errado na origem
Páginas relacionadas
O mesmo problema em outro objetivo
- Campo livre no cadastro: fechar o padrão de preenchimento — Organizar um processo
- Mesmo campo, formatos diferentes: o que cada escolha cobra — Comparar alternativas
- Campo vazio no cadastro: como medir o padrão de preenchimento — Explicar medição
- Padrão de preenchimento de campo: o que exigir no contrato — Orientar avaliação e contratação
Outras leituras em Integrações, sistemas e qualidade de dados
- Valor sem unidade: o que registrar antes de somar — O que definir no registro, na conversão e na conferência de valores sem unidade para que a soma entre sistemas faça sentido.
- Campo obrigatório sem uso: como decidir o que fazer — Descreve um processo para revisar campos obrigatórios sem uso: quem pediu, quem preenche, quem consome e o que acontece quando o dado falta.
- Base de dados sem dono: quem responde pelo dado — Define papéis, critérios de decisão e rotina de manutenção para uma base de dados sem responsável formal.
- Chave de ligação ausente: o que medir antes de corrigir — Medição de chave de ligação ausente entre cadastros: denominador, corte por origem, taxa por período e leitura das lacunas que impedem conciliação.
- Campo obrigatório sem uso: o que a exigência trava — Separa campos obrigatórios sem uso por origem e distingue exigência de norma, controle interno e costume, e indica o que manter, tornar opcional ou remover.