Localidade no Power Query: converta datas e valores

Definir a localidade no Power Query é uma forma de controlar como textos serão interpretados ao virar números ou datas. Uma conversão pode terminar sem erro e ainda produzir um valor diferente daquele pretendido pela fonte. Por isso, ausência de erro não basta para aprovar a carga.

Este roteiro usa arquivos hipotéticos de vendas para testar separadores e datas ambíguas. A proposta é manter o dado recebido, declarar o padrão de cada origem e conferir o resultado antes da atualização do relatório. Os testes devem acompanhar mudanças no sistema que exporta os arquivos.

1. Entenda o papel da localidade no Power Query

A documentação de tipos do Power Query explica o uso de localidade na interpretação de textos. No editor, a opção de alterar tipo usando localidade permite selecionar o tipo pretendido e o contexto cultural. Essa escolha trata da conversão, não apenas da aparência exibida no relatório.

Registre no contrato da fonte como datas, números e sinais negativos chegam ao arquivo. Identifique também a unidade monetária, que precisa de informação própria. Escolher uma cultura não demonstra qual moeda o sistema utilizou nem autoriza converter valores entre moedas diferentes sem uma regra adicional.

2. Preserve o texto antes de converter

Crie uma etapa inicial que retenha identificador da linha, nome do arquivo e colunas textuais recebidas. Faça a conversão em colunas destinadas ao modelo, mantendo a origem disponível para auditoria. Se houver uma etapa automática de tipo alterado, confira se ela atuou antes de você declarar a interpretação desejada.

Em um arquivo hipotético, a coluna Valor chega como texto e contém 1.234,56. Outro sistema envia 1,234.56 para representar a mesma quantia. Não substitua todos os pontos e vírgulas indiscriminadamente; estabeleça qual exportação gerou cada linha e aplique uma conversão coerente com essa origem.

3. Monte uma amostra que exponha ambiguidades

Separe exemplos com dia acima de doze, dia abaixo de treze, valor com milhar, decimal sem milhar, negativo e campo vazio. Inclua uma linha com conteúdo inválido de propósito. Anote manualmente o resultado esperado, com base na especificação do sistema exportador, para que a revisão não dependa da mesma transformação que está sendo testada.

Considere a data hipotética 03/04/2026. Sem conhecer o padrão da fonte, você não deve adivinhar se representa três de abril ou quatro de março. Acrescentar um exemplo como 23/04/2026 ajuda a detectar incompatibilidades, mas não prova sozinho que todas as linhas vieram do mesmo padrão.

4. Aplique uma conversão explícita em M

A referência de Table.TransformColumnTypes descreve o argumento opcional de cultura. O exemplo abaixo usa a linguagem M, utilizada pelo Power Query, e uma tabela criada apenas para teste. O padrão declarado é português do Brasil; adapte nomes e tipos ao contrato real da sua fonte.

let
    Fonte = #table(
        type table [Linha = text, Valor = text, Data = text],
        {
            {"A", "1.234,56", "03/04/2026"},
            {"B", "45,90", "23/04/2026"}
        }
    ),
    Convertida = Table.TransformColumnTypes(
        Fonte,
        {{"Valor", Currency.Type}, {"Data", type date}},
        "pt-BR"
    )
in
    Convertida

Para essa amostra, espere valor de mil duzentos e trinta e quatro reais e cinquenta e seis centavos na linha A, considerando a moeda hipotética do exemplo. A data esperada é três de abril. Na linha B, confira quarenta e cinco reais e noventa centavos e vinte e três de abril.

5. Confira componentes em vez de confiar na exibição

Acrescente colunas de conferência para dia, mês e ano nas datas convertidas. Compare esses componentes com o gabarito definido antes da transformação. Para valores, confira algumas linhas individualmente e uma soma manual da amostra; um total aparentemente plausível pode esconder erros que se compensam.

A documentação de tipos sugere extrair componentes da data para verificar a conversão. Depois dessa conferência, teste a ordenação cronológica e a seleção por mês no modelo. Uma máscara visual agradável não corrige um valor já convertido com interpretação incorreta, por isso a aprovação deve acontecer antes da formatação final.

6. Trate fontes com padrões diferentes separadamente

Quando os arquivos vêm de sistemas distintos, mantenha uma identificação de origem e uma especificação por exportação. Converta cada conjunto com seu padrão e só depois consolide as colunas tipadas. Não selecione a cultura linha a linha pela presença de vírgula, pois a mesma notação pode ter significados diferentes.

Se a fonte mistura formatos dentro do mesmo arquivo sem identificá-los, registre uma pendência com o fornecedor do dado. Uma regra de tentativa pode produzir resultados para parte da base, mas não resolve datas que são válidas em duas interpretações. Consulte também o processo de combinação de arquivos para preservar rastreabilidade entre cargas.

7. Diferencie campo vazio de conversão rejeitada

Um campo não preenchido e um texto impossível de converter pedem tratamentos diferentes. Registre o estado original e o resultado da tentativa de conversão. Um valor rejeitado não deve virar zero automaticamente, porque isso permite que um total incompleto pareça um resultado financeiro válido e totalmente conferido.

Use o roteiro de captura de erros com try para estruturar a revisão. Defina uma fila com arquivo, linha, conteúdo e motivo. Antes de liberar a carga, decida quais falhas bloqueiam a atualização e quais registros podem permanecer isolados, com a limitação visível ao leitor.

8. Proteja códigos que parecem números

Identificadores de cliente, produto ou documento podem conter zeros iniciais e não devem ser tratados como quantidades apenas por usar algarismos. Declare esses campos como texto desde a entrada. Uma conversão numérica seguida de retorno para texto pode não reconstruir a representação original que você precisava preservar.

Faça uma lista explícita de campos que permitem cálculo e campos que servem para associação. Teste códigos hipotéticos como 00073 e 73 conforme a regra cadastral do negócio. Eles podem representar entidades diferentes; não una registros apenas porque a transformação numérica fez os dois resultados parecerem iguais.

9. Automatize a conferência da próxima exportação

Mantenha um arquivo de teste com os casos aprovados e execute a transformação após qualquer mudança na consulta. Confira quantidade de linhas, tipos finais, erros e resultados esperados. Inclua ainda uma nova linha fora do padrão para verificar se a rotina realmente a encaminha para revisão, sem ocultar o problema.

Antes de publicar, use o perfil de dados para investigar a distribuição dos campos convertidos. Uma alteração brusca de meses ou de magnitude merece comparação com a fonte. O teste deve explicar a divergência encontrada, em vez de ajustar a transformação até o gráfico simplesmente parecer familiar.

10. Entregue uma regra que outra pessoa consiga revisar

Documente origem, cultura declarada, tipos escolhidos, casos de teste e destino dos registros rejeitados. Informe quando a especificação foi confirmada e por quem. Evite depender da configuração pessoal de um analista para explicar a carga; o comportamento esperado deve estar descrito nas etapas e na documentação do processo.

O resultado útil é uma tabela tipada cuja interpretação pode ser reproduzida e conferida. Se a origem continuar ambígua, mantenha essa limitação registrada e negocie um formato consistente de exportação. A visualização só deve apresentar como validado aquilo que passou pelos testes de significado, não apenas pela execução técnica da consulta.