Anexar consultas no Power Query: consolide sem misturar dados

anexar consultas no Power Query empilha linhas de tabelas que devem representar o mesmo tipo de registro. A operação parece simples, mas um esquema mal alinhado pode separar informações em colunas diferentes, repetir movimentos ou misturar níveis de detalhe. Este roteiro apresenta uma preparação verificável, com exemplos hipotéticos e controles para a atualização continuar confiável.

O que anexar consultas no Power Query resolve

Anexar consultas reúne registros de fontes semelhantes em uma sequência única. É útil quando pedidos, atendimentos ou movimentos chegam separados por filial, período ou sistema, mas precisam ser analisados juntos. A tabela resultante tem mais linhas; cada linha original deve manter seu significado e sua procedência.

Antes de transformar, declare o que uma linha representa. Uma tabela de pedidos com uma linha por documento e outra com uma linha por item não têm o mesmo grão. Anexá-las sem tratar essa diferença produz uma coluna em que um valor pode representar unidades distintas. O relatório pode atualizar normalmente e ainda assim entregar totais inválidos.

Quando anexar e quando mesclar

A pergunta define a operação. “Quero reunir os pedidos de três lojas” normalmente indica anexação. “Quero acrescentar o nome do cliente ao pedido usando o código do cliente” indica mesclagem. Anexar acrescenta registros; mesclar procura correspondências em outra tabela com base em uma ou mais chaves.

A mesclagem por chave no Power Query exige cuidado com chaves repetidas, pois elas podem multiplicar linhas. Anexar não faz essa correspondência e também não elimina duplicatas. A documentação oficial de Append Queries explica que as colunas são combinadas pelo nome, e não pela posição visual; nomes diferentes podem permanecer como campos separados.

Defina um contrato de colunas

Faça uma lista de campos esperados, seus nomes padronizados e seus tipos. Por exemplo, o identificador do pedido pode ser texto, a data pode ser data, a quantidade pode ser inteira e o valor pode ser decimal. Converta cada origem para esse contrato antes de empilhar as consultas. A ordem das colunas na planilha não deve determinar o sentido dos dados.

Se uma fonte usa “CodVendedor” e outra “VendedorID”, escolha um nome canônico e renomeie a primeira. Preserve códigos como texto quando os zeros à esquerda forem parte do identificador. Também normalize nomes de unidades e categorias; diferenças de grafia podem dividir uma análise em grupos que a equipe entende como iguais, mas o modelo trata como distintos.

Decida o destino de campos extras e ausentes

Uma coluna exclusiva de uma origem pode ser legítima, como o centro de distribuição em um sistema logístico. Mantenha-a se tiver utilidade analítica e documente por que outras fontes terão nulo. Se a diferença veio de um erro de digitação ou de um cabeçalho renomeado, corrija o esquema antes de anexar.

Classifique os campos como obrigatórios, opcionais ou fora do escopo. A falta de uma coluna opcional pode ser aceitável em períodos antigos. A ausência de um identificador essencial pede uma exceção visível. Não substitua automaticamente todo nulo por zero: zero é um valor, enquanto nulo informa ausência, desconhecimento ou não aplicabilidade, situações que podem exigir interpretações diferentes.

Organize as consultas em etapas legíveis

Separe a leitura de cada fonte, a limpeza e a saída final. Use nomes que comuniquem função, como “Pedidos_FilialA_Limpos” e “Pedidos_Consolidados”. A consulta final deve deixar explícito quais entradas foram preparadas e anexadas. Esse desenho facilita localizar a origem de uma linha quando alguém questiona um valor.

As consultas de referência no Power Query permitem reutilizar uma preparação sem copiar todas as etapas. Porém, mudanças na consulta de origem podem afetar dependentes. Após alterar um nome, tipo ou filtro, valide as consultas que usam essa referência. Identifique quais consultas carregam no modelo e quais existem somente para preparar ou auditar dados.

Exemplo hipotético: consolidar três filiais

Imagine três lojas que exportam vendas mensais. Duas chamam o código do vendedor de “VendedorID” e a terceira usa “CodVendedor”. A equipe padroniza o nome, converte os códigos para texto, acrescenta “FilialOrigem” e anexa as três tabelas. A nova coluna de origem permite comparar valores por unidade sem inferir a loja pelo nome do arquivo.

Esse cenário é hipotético; os campos e regras devem vir da operação real. Depois da transformação, filtre cada loja e confronte a contagem de linhas com sua extração. Examine pedidos conhecidos, confira datas e unidades de medida e verifique se cancelamentos usam uma convenção compatível. Se uma origem registra valor negativo e outra usa um tipo de movimento, harmonize a semântica antes de somar.

Investigue duplicidades e sobreposições

Anexar não remove linhas repetidas. Um arquivo reenviado, uma integração duplicada ou dois períodos que se sobrepõem podem incluir o mesmo evento mais de uma vez. Defina uma chave apropriada ao grão — talvez pedido, item e filial — e conte ocorrências antes de excluir algo. Uma repetição pode ser um erro ou um evento legítimo corrigido posteriormente.

Compare datas mínima e máxima por fonte e procure intervalos repetidos. Reconcilie quantidade de registros e valores com totais de controle fornecidos pelo sistema operacional. Totais iguais não provam que cada linha está correta, mas uma diferença ajuda a localizar a origem. Guarde o critério usado para decidir se um arquivo substitui outro ou se ambos devem permanecer.

Preserve o grão e a interpretação das medidas

Uma linha por item exige medidas diferentes de uma linha por pedido. Se o total do pedido aparecer repetido em todas as linhas de item, somá-lo na tabela anexada superestima o valor. Mantenha atributos e valores no nível em que são produzidos ou defina uma agregação deliberada antes de usá-los em indicadores.

Depois da preparação, relacione os fatos a dimensões como calendário, produto e vendedor. Evite replicar descrições para contornar relacionamentos sem entender como os filtros funcionarão. Se uma origem muda seu nível de detalhe, registre isso e trate a mudança antes da consulta final; uma tabela consolidada deve apresentar um único contrato analítico.

Faça mudanças de origem aparecerem

Uma consulta que funciona hoje pode receber uma coluna renomeada ou um arquivo com estrutura diferente na próxima carga. Mantenha uma lista de campos obrigatórios, tipos e exceções aceitas. Se a origem perder um campo essencial, interrompa a atualização ou gere um alerta claro. Uma correção silenciosa pode manter o painel verde enquanto remove a informação que sustenta uma decisão.

Inclua período de extração e identificador de origem quando ajudarem a rastrear os dados. Torne a atualização repetível e teste a nova saída antes de substituir a versão usada pela equipe. No serviço do Power BI, valide credenciais e acesso às fontes. Um fluxo correto no Desktop ainda depende de caminho, permissões e configuração compatíveis no ambiente de atualização.

Checklist antes de carregar

Confirme se cada consulta representa o mesmo tipo de linha, se os nomes e tipos foram harmonizados e se a origem continua rastreável. Revise campos ausentes, duplicidades, intervalos sobrepostos e totais de controle. Confira também uma amostra em detalhe, pois a contagem geral pode parecer correta enquanto uma unidade está incompleta.

Se uma regra depende de suposição, torne-a explícita na consulta ou na documentação do modelo. Compare casos conhecidos com a fonte operacional e peça a uma pessoa do processo para validar as exceções. A consolidação de arquivos mensais complementa esse fluxo quando cada período chega em um arquivo separado. Assim, anexar se torna uma integração controlada, rastreável e mais simples de manter.