Resposta direta
Trate o formato da data como requisito de contrato, não como detalhe de tela. Antes de assinar, peça ao fornecedor que mostre onde o campo é validado, quais formatos de entrada aceita e o que faz com data ambígua como 03/04. Exija que a data fique armazenada em formato único e que a exibição siga a preferência do usuário. Se o sistema aceitar texto livre sem regra, o problema só muda de lugar. Defina quem responde pela conversão dos registros antigos e como o erro será identificado depois.
- Objetivo
- Orientar avaliação e contratação
- Formato indicado
- Projeto de implementação
- Atualizado em
O que esta página acrescenta: Foca na fase de contratação: o que exigir por escrito de um sistema que vai receber datas em texto livre.
Onde o requisito precisa ficar registrado
Formato de data é decisão de dado, não de interface. O ponto de checagem é onde o valor é gravado e como ele é lido por relatórios, filtros e integrações. Um sistema com máscara na tela ainda pode guardar o texto exatamente como foi digitado.
Peça que a proposta descreva, por escrito, quais formatos de entrada são aceitos, o que acontece quando o valor não corresponde a nenhum deles e se existe conversão antes do armazenamento. Sem essa descrição, a avaliação fica presa à demonstração comercial.
Teste com registros reais antes de assinar
Leve uma amostra dos registros atuais para o teste, com os casos que aparecem na operação: data incompleta, apenas mês e ano, intervalo entre duas datas, anotação junto ao valor. O comportamento nesses casos define se o sistema serve para o uso pretendido.
Defina também a responsabilidade pela conversão do histórico. Se o fornecedor converte, ele precisa indicar como o registro duvidoso fica marcado para revisão. Se a conversão fica com a empresa, ela exige tempo e uma pessoa designada, o que costuma ser subestimado na proposta.
O que essa exigência não resolve
Validar o campo de data não corrige a origem do erro. Se quem registra não sabe a data correta, o sistema vai recusar a entrada ou aceitar um valor aproximado, e nenhuma das duas opções produz informação confiável.
Existe ainda o limite do produto padrão. Quando o fornecedor não permite configurar o campo, a escolha é aceitar o comportamento existente ou não contratar. Exigir o que o produto não faz apenas atrasa a decisão sem mudar o resultado.
Recurso prático
Checagens de contratação para data em formato livre
| Item a avaliar | Pergunta objetiva ao fornecedor |
|---|---|
| Onde a data é validada | O campo aceita texto livre ou só formatos definidos? |
| Formato de armazenamento | A data é gravada em formato único ou como foi digitada? |
| Regra para valor ambíguo | O que o sistema faz com 03/04/05 sem contexto de dia e mês? |
| Correção do histórico | Quem converte os registros antigos e como marca o que ficou duvidoso? |
O erro mais comum é avaliar a tela de entrada e ignorar onde a data é armazenada. Se o texto livre continua aceito, a falha reaparece nos relatórios e nas integrações.
Sobre o que está escrito aqui
Conceitos relacionados: campo de data estruturado · máscara de entrada · validação de formato · data ambígua de dia e mês · conversão de registros históricos. 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
- Migração de dados: o que conferir antes e depois — migração sem conferência
- Dados desatualizados: o que precisa estar em dia — dados desatualizados
Páginas relacionadas
O mesmo problema em outro objetivo
- Data em formato livre: como dizer se o campo é confiável — Diagnosticar
- Data em campo livre: como tornar o registro utilizável — Organizar um processo
- Campo de data em texto livre: comparar as formas de tratar — Comparar alternativas
- Data em formato livre: como medir o que dá para recuperar — Explicar medição
- Data em campo de texto: o que converter e o que anotar — Orientar implementação
Outras leituras em Integrações, sistemas e qualidade de dados
- Campo numérico aceitando texto: o que fazer com o registro — Regra de tratamento para registros com texto em campo numérico: o que corrigir na hora, o que separar para conferência e quem responde pela decisão.
- Histórico de alteração não registrado: alternativas possíveis — Compara os caminhos para lidar com alteração sem histórico registrado: reconstruir pelos vestígios, começar a registrar agora e conviver com a lacuna.
- Sincronização sem janela definida: o corte que ninguém fecha — Um processo para definir data de corte, dono do número e rotina de conferência quando a sincronização entre sistemas não tem janela combinada.
- Fonte única para cada indicador: o que exigir na contratação — O que declarar como fonte oficial de cada indicador e o que constar no contrato e na rotina para sustentar essa escolha na operação.
- Integração por API: o que definir antes de ir para produção — O que precisa estar definido antes de uma API entrar em produção: contrato de dados, comportamento em falha, reprocessamento e responsável pela integração.