Erros comuns e correções: granularidade, calendário, relacionamento e duplicidade

Por que este capítulo existe: erros que “passam” e viram decisões ruins

Em projetos de Power BI para pequenos negócios, os problemas mais caros raramente são “erros que quebram” (como uma coluna que não carrega). O que mais prejudica é o erro silencioso: números que parecem plausíveis, mas estão errados por causa de granularidade inconsistente, calendário incompleto, relacionamentos mal direcionados ou duplicidades escondidas. Este capítulo foca em como identificar esses problemas no dia a dia e como corrigir com passos práticos, sem repetir a teoria já vista em capítulos anteriores.

Você vai aprender a reconhecer sintomas típicos (ex.: total muda quando você troca um visual, mês “some” do gráfico, valores dobram ao filtrar por produto), diagnosticar a causa e aplicar correções no Power Query, no modelo e em medidas DAX quando necessário.

1) Erros de granularidade: quando o nível do dado não combina com a pergunta

Conceito (na prática)

Granularidade é o “tamanho do grão” do registro: cada linha representa o quê? Uma venda? Um item da venda? Um recebimento? Um dia consolidado? O erro comum é misturar níveis diferentes no mesmo cálculo ou no mesmo relacionamento, gerando duplicação, soma indevida ou comparações injustas.

Exemplos típicos de mistura de granularidade:

• Vendas por item (produto) em uma tabela e metas mensais em outra, mas você tenta comparar direto sem ajustar o nível.
• Despesas lançadas por dia e recebimentos lançados por parcela, mas você cruza ambos com uma dimensão que está em nível mensal.
• Estoque em “saldo diário” e vendas em “itens por pedido”, e você tenta calcular cobertura sem padronizar a data de referência.

Sintomas comuns

• O total geral parece certo, mas ao detalhar por produto/canal/cliente os valores “explodem” ou “encolhem”.
• Um KPI muda quando você troca o eixo do gráfico (por exemplo, de mês para dia) sem motivo operacional.
• Ao colocar duas dimensões no visual (ex.: Produto e Canal), o valor dobra ou triplica.
• Você vê o mesmo documento (pedido/nota) repetido em uma tabela visual.

Diagnóstico rápido

Antes de mexer em DAX, confirme o grão de cada tabela:

Continue em nosso aplicativo

Você poderá ouvir o audiobook com a tela desligada, ganhar gratuitamente o certificado deste curso e ainda ter acesso a outros 5.000 cursos online gratuitos.

ou continue lendo abaixo...

Baixar o aplicativo

• Abra a tabela no Power BI (visual de dados) e identifique a chave natural do registro: Pedido+Item? Nota+Produto? Data+SKU? Cliente+Mês?
• Verifique se existe uma coluna de ID que deveria ser única e não é. Se não houver, crie uma chave composta no Power Query para testar unicidade.
• Conte linhas e compare com o esperado: “Tenho 3.000 pedidos no mês, por que a tabela de vendas tem 30.000 linhas?” (provavelmente é por item, o que é correto, mas exige cuidado ao somar métricas por pedido).

Correções práticas (passo a passo)

A) Quando você precisa de métricas no nível do pedido, mas seus dados estão no nível do item

Cenário: sua tabela de vendas está por item (cada linha é um produto dentro do pedido), mas você quer contar pedidos, calcular ticket por pedido ou taxa de devolução por pedido.

Passo a passo:

• No Power Query, garanta que exista um identificador de pedido (ex.: PedidoID). Se não existir, crie a partir de colunas disponíveis (ex.: NúmeroDocumento + Data + Cliente) com cautela.
• No modelo, crie uma tabela auxiliar de pedidos (dimensão ou “bridge” simples) com um registro por PedidoID. Você pode criar via DAX:

  Pedidos = DISTINCT(Vendas[PedidoID])

• Relacione Pedidos[PedidoID] (1) com Vendas[PedidoID] (N).
• Crie medidas no nível do pedido usando a tabela Pedidos, por exemplo:

  Pedidos (Qtde) = COUNTROWS(Pedidos)

• Para ticket médio por pedido:

  Ticket Médio = DIVIDE([Faturamento], [Pedidos (Qtde)])

Por que funciona: você separa o grão “pedido” do grão “item”, evitando contar pedido várias vezes quando o visual está por produto.

B) Quando você tem metas mensais e quer comparar com vendas diárias/por item

Cenário: metas estão em uma tabela com colunas Ano, Mês, Meta; vendas estão em nível diário ou por item.

Passo a passo:

• Garanta que a tabela de metas tenha uma chave de período compatível com o calendário (ex.: Data do primeiro dia do mês, ou AnoMes numérico).
• Crie uma coluna na tabela de metas para “DataRef” (primeiro dia do mês). Ex.: 2025-01-01 para janeiro/2025.
• Relacione Metas[DataRef] com Calendario[Data] (muitos-para-um, dependendo do desenho). Se preferir, relacione por AnoMes com uma coluna equivalente no calendário.
• Crie medida de meta que respeite o contexto do calendário. Ex.:

  Meta (Mês) = SUM(Metas[Meta])

• Se você precisa distribuir a meta ao longo dos dias (meta diária), crie uma medida que divida pela quantidade de dias do mês no contexto:

  Meta Diária = DIVIDE([Meta (Mês)], DISTINCTCOUNT(Calendario[Data]))

Erro comum: tentar relacionar metas mensais diretamente com vendas por item sem passar pelo calendário (ou sem uma chave de período), o que gera repetição da meta em cada dia/produto.

C) Quando você mistura “saldo” (estoque) com “movimento” (vendas/entradas)

Cenário: estoque é uma fotografia (saldo em uma data), vendas são eventos (movimentos). Cobertura e ruptura dependem de alinhar a data de referência do saldo com o período de consumo.

Passo a passo:

• Defina qual data o saldo representa (ex.: fim do dia, início do dia, data de inventário).
• Se o saldo é diário, relacione com o calendário pela data do saldo. Se o saldo é “atual”, crie uma data de referência fixa (ex.: hoje) e trate como snapshot.
• Para cobertura, use medidas que peguem o saldo na data correta e o consumo em um período futuro/recente, evitando somar saldos ao longo do tempo.

Sintoma clássico de erro: gráfico de estoque “somando” saldo diário e crescendo artificialmente. Saldo não se soma no tempo; normalmente se usa último valor do período.

2) Erros de calendário: datas faltando, tipos errados e períodos que não fecham

Conceito (na prática)

O calendário é o eixo que organiza análises por dia/semana/mês. O erro comum não é “não ter calendário”, mas ter um calendário incompleto, com tipo de dado errado, com datas fora do intervalo real, com feriados/semana mal definidos, ou com múltiplas colunas de data competindo (data do pedido, data de emissão, data de pagamento) sem controle.

Sintomas comuns

• Meses “pulam” no gráfico (ex.: não aparece fevereiro porque não houve vendas, mas você queria ver o mês zerado).
• Comparações de período (mês anterior, ano anterior) retornam em branco ou valores estranhos.
• Filtros de data não afetam algumas tabelas (porque a coluna não é do tipo Data ou não está relacionada).
• O mesmo indicador muda muito quando você troca “Data do Pedido” por “Data de Pagamento”, sem clareza do que está sendo medido.

Diagnóstico rápido

• Confira o tipo de dado das colunas de data no Power Query e no modelo: precisa ser Date (não texto, não DateTime quando você quer dia).
• Verifique o intervalo do calendário: ele cobre do menor ao maior valor de data de todas as tabelas relevantes?
• Identifique quantas colunas de data existem nas tabelas fato (ex.: DataVenda, DataEmissao, DataPagamento, DataEntrega). Se você usa mais de uma, precisa de estratégia (tabela de datas única com relações inativas e medidas específicas, ou tabelas de datas separadas por processo).

Correções práticas (passo a passo)

A) Corrigir datas como texto e inconsistências de formato

Passo a passo no Power Query:

• Selecione a coluna de data.
• Use “Alterar Tipo” para Data, mas antes confira se o locale está correto (dd/mm vs mm/dd). Se necessário, use “Alterar Tipo usando Localidade”.
• Se houver valores inválidos (ex.: 31/11), trate com substituição/remoção ou regra de correção conforme a origem.

Boa prática operacional: crie uma etapa de validação que conte quantos valores viraram erro após conversão. Isso evita “perder” linhas silenciosamente.

B) Fazer o calendário cobrir todo o período e mostrar meses sem movimento

Passo a passo:

• Defina a menor e a maior data considerando todas as tabelas que entram no dashboard (vendas, caixa, estoque, etc.).
• Gere o calendário com esse intervalo completo.
• Nos visuais, use o campo de mês do calendário no eixo e habilite “Mostrar itens sem dados” quando aplicável.

Erro comum: calendário baseado apenas em vendas; quando você vai analisar recebimentos ou estoque, faltam datas e os visuais ficam inconsistentes.

C) Controlar múltiplas datas (pedido vs pagamento) sem bagunçar o modelo

Se você precisa analisar por datas diferentes, o problema típico é tentar relacionar todas as colunas de data ao mesmo calendário com relações ativas ao mesmo tempo, gerando ambiguidade ou filtros inesperados.

Passo a passo (estratégia com relações inativas e medidas):

• Mantenha uma relação ativa do calendário com a data principal (ex.: DataVenda).
• Crie relações adicionais como inativas para outras datas (ex.: DataPagamento).
• Crie medidas específicas ativando a relação correta via DAX quando necessário (exemplo genérico):

  Recebido por Data de Pagamento = CALCULATE([Valor Recebido], USERELATIONSHIP(Calendario[Data], Recebimentos[DataPagamento]))

Assim, o usuário escolhe o indicador certo para a pergunta certa, sem trocar colunas no visual e sem quebrar o contexto.

3) Erros de relacionamento: direção de filtro, chaves “sujas” e cardinalidade errada

Conceito (na prática)

Relacionamento é como o filtro “viaja” entre tabelas. Os erros comuns aparecem quando a chave não é única do lado “1”, quando a cardinalidade está errada (muitos-para-muitos sem intenção), quando a direção de filtro está liberada sem necessidade, ou quando você relaciona por colunas que parecem iguais, mas não são (espaços, zeros à esquerda, maiúsculas/minúsculas, códigos reaproveitados).

Sintomas comuns

• Valores duplicados ao cruzar dimensões (ex.: por produto e por cliente ao mesmo tempo).
• Filtros que “não pegam” (seleciona um produto e nada muda).
• Medidas que funcionam em um visual, mas ficam em branco em outro.
• Mensagem de ambiguidade no modelo ou necessidade de “ambas as direções” para funcionar.

Diagnóstico rápido

• No modo de modelo, verifique se o lado “1” realmente tem valores únicos (ex.: DimProduto[SKU]).
• Faça uma checagem de qualidade: conte duplicados na dimensão e valores nulos na chave.
• Compare tipos: SKU como texto em uma tabela e número em outra impede match.
• Procure por chaves com espaços e caracteres invisíveis (muito comum em Excel/CSV).

Correções práticas (passo a passo)

A) Corrigir chave que não casa por tipo, zeros à esquerda e espaços

Passo a passo no Power Query:

• Padronize o tipo da chave em todas as tabelas (geralmente texto para códigos).
• Remova espaços: aplicar “Formatar > Remover espaços” (trim) e, se necessário, “Limpar” (remove caracteres não imprimíveis).
• Se houver zeros à esquerda relevantes (ex.: “00123”), evite converter para número. Mantenha como texto e padronize o tamanho com preenchimento (pad) quando necessário.
• Padronize caixa (maiúsculas/minúsculas) para evitar divergência em sistemas que diferenciam.

B) Resolver cardinalidade errada (muitos-para-muitos acidental)

Cenário: você tenta relacionar Vendas[Produto] com Produtos[Produto], mas Produtos tem duplicados (mesmo SKU repetido por variação, fornecedor, ou erro de cadastro). O Power BI sugere muitos-para-muitos, e os números ficam instáveis.

Passo a passo:

• Identifique por que a dimensão tem duplicados: variações de cadastro, linhas repetidas, histórico de preço misturado com cadastro, etc.
• Separe o que é cadastro (um por SKU) do que é histórico (múltiplos por SKU e data). Histórico não deve ser dimensão simples.
• Crie uma dimensão de produtos deduplicada no Power Query (remover duplicatas por SKU, mantendo a regra correta: mais recente, mais completo, ou fonte oficial).
• Relacione Vendas (N) com DimProduto (1). Evite muitos-para-muitos como “atalho”.

C) Evitar direção de filtro “Ambos” como solução rápida

Direção “Ambos” pode parecer resolver filtros, mas frequentemente cria caminhos múltiplos e resultados inesperados, principalmente quando há mais de uma tabela fato (vendas, recebimentos, estoque) compartilhando dimensões.

Passo a passo:

• Volte a direção para “Única” (da dimensão para a fato) sempre que possível.
• Se um cálculo precisa filtrar uma tabela a partir de outra fato, use medida com DAX (TREATAS, CROSSFILTER, ou tabelas ponte) em vez de abrir “Ambos” no modelo inteiro.
• Teste com um visual simples (um cartão e uma segmentação) para confirmar que o filtro percorre o caminho esperado.

4) Erros de duplicidade: registros repetidos, linhas “fantasmas” e duplicação por junção

Conceito (na prática)

Duplicidade pode nascer em três lugares: na fonte (o sistema exportou duplicado), no Power Query (uma mesclagem/append gerou repetição), ou no modelo (relacionamento que multiplica linhas). O ponto crítico é que duplicidade nem sempre aparece como “linhas iguais”; às vezes são linhas diferentes que representam o mesmo evento (ex.: mesma venda exportada por dois relatórios diferentes).

Sintomas comuns

• Faturamento do mês está exatamente 2x (ou 3x) o valor esperado.
• Ao atualizar, o total cresce sem que o negócio tenha vendido mais (append acumulando histórico repetido).
• Um mesmo documento aparece com pequenas diferenças (ex.: descrição) e passa despercebido.
• Após “Mesclar consultas”, o número de linhas aumenta muito mais do que o esperado.

Diagnóstico rápido

• Escolha uma chave de unicidade do evento (ex.: Nota+Série+Item, PedidoID+Item, MovimentoEstoqueID).
• No Power Query, agrupe por essa chave e conte linhas; qualquer contagem > 1 indica duplicidade potencial.
• Compare totais por período com uma fonte de controle (relatório do ERP, extrato, planilha de conferência).
• Verifique etapas de “Anexar” (Append) e “Mesclar” (Merge) e se há expansão de colunas que multiplica linhas.

Correções práticas (passo a passo)

A) Remover duplicados reais na origem (mesma chave, mesmo valor)

Passo a passo no Power Query:

• Selecione as colunas que definem unicidade (chave do evento).
• Use “Remover Duplicatas”.
• Se você precisa manter a linha “mais recente”, antes ordene por uma coluna de atualização (ex.: DataAtualizacao) e então remova duplicatas mantendo a primeira.

Cuidado: remover duplicatas sem uma chave bem definida pode apagar eventos legítimos (ex.: duas vendas no mesmo valor e data para o mesmo cliente).

B) Corrigir duplicidade causada por Append (histórico sendo anexado de novo)

Cenário: você tem uma pasta com arquivos mensais e, ao atualizar, o mesmo mês entra novamente porque o arquivo foi reprocessado ou renomeado.

Passo a passo:

• Inclua uma coluna “FonteArquivo” (nome do arquivo) ao combinar arquivos.
• Crie uma chave única do registro (ex.: PedidoID+Item+FonteSistema) e deduplique após o append.
• Se a origem é incremental, implemente regra de corte por data (carregar apenas a partir de um período) e mantenha histórico consolidado em um único arquivo/tabela quando possível.

C) Corrigir duplicidade causada por Merge (junção que multiplica linhas)

Cenário: você mescla Vendas com uma tabela de Produtos que tem mais de uma linha por SKU (por exemplo, histórico de preço). Ao expandir colunas, cada venda se repete para cada linha correspondente no cadastro/histórico.

Passo a passo:

• Antes de mesclar, garanta que a tabela do lado “lookup” tenha uma linha por chave (deduplique ou agregue).
• Se você precisa do histórico (ex.: preço por período), não faça merge simples por SKU; inclua também a data (SKU+Data) ou use uma lógica de “intervalo de vigência” (mais avançado) para retornar apenas o registro válido.
• Após o merge, valide a contagem de linhas: ela deve permanecer igual à tabela base (na maioria dos casos). Se aumentou, investigue imediatamente.

D) Duplicidade “invisível” por relacionamento e medidas

Às vezes os dados não estão duplicados, mas o cálculo duplica por causa do contexto. Exemplo: você soma um valor de cabeçalho do pedido (total do pedido) em uma tabela por item, e o total do pedido se repete em cada item.

Como corrigir:

• Não some colunas de cabeçalho em tabela de itens. Transforme em medida que agregue no nível correto (por pedido) ou crie uma tabela de cabeçalho (Pedidos) separada.
• Quando precisar trazer um atributo “do pedido” para o nível do item, use relacionamento com a tabela de pedidos e busque o atributo por chave, não por repetição de valor.

5) Roteiro de depuração: do sintoma à causa em 10 minutos

Checklist prático de investigação

• Confirme o total com uma fonte de controle (ERP/planilha/relatório). Se o total já está errado, o problema é dado/transformação/modelo, não visual.
• Quebre o total por um único eixo (ex.: por mês). Se o erro aparece em meses específicos, procure duplicidade/append/arquivo repetido naquele período.
• Troque o eixo para uma dimensão (ex.: produto). Se o total muda ao detalhar, suspeite de granularidade ou relacionamento multiplicando.
• Verifique se a dimensão usada no eixo tem chave única. Se não tiver, corrija a dimensão.
• Revise merges no Power Query: toda mesclagem deve ter expectativa clara de cardinalidade (1:1 ou N:1). Se for N:N, pare e redesenhe.
• Valide o calendário: intervalo completo, tipo Date, e relação correta com a data usada no indicador.

Visuais de auditoria (úteis para achar o erro)

• Tabela com colunas de chave (PedidoID, Item, Data) e a medida principal para localizar repetições.
• Cartões com contagens: linhas da fato, contagem distinta de pedidos, contagem distinta de clientes, etc.
• Matriz com AnoMes do calendário e a medida: identifica “saltos” e meses faltantes.

6) Exemplos de correção com mini-casos (para aplicar imediatamente)

Mini-caso 1: “Meu faturamento dobra quando coloco Produto no visual”

Diagnóstico provável: você está somando um valor de cabeçalho (total do pedido) em uma tabela por item, ou há relacionamento muitos-para-muitos com produto.

Correção:

• Verifique se a coluna usada para faturamento é por item (valor do item) ou por pedido (total do pedido). Se for total do pedido, mova para uma tabela de pedidos e calcule por lá.
• Cheque duplicidade na dimensão de produtos (SKU repetido). Deduplique e ajuste relacionamento para 1:N.

Mini-caso 2: “Fevereiro não aparece no gráfico”

Diagnóstico provável: o eixo está usando a data da fato (que não tem fevereiro) em vez do calendário, ou o calendário não cobre o período.

Correção:

• Use o campo de mês do calendário no eixo.
• Ative “Mostrar itens sem dados” no visual quando aplicável.
• Garanta que o calendário inclua fevereiro no intervalo.

Mini-caso 3: “Recebimentos por mês não batem com o extrato”

Diagnóstico provável: você está analisando por data errada (emissão vs pagamento) ou a coluna de data está como texto e não filtra corretamente.

Correção:

• Converta DataPagamento para tipo Date no Power Query.
• Crie medida que use a relação correta com o calendário (USERELATIONSHIP) para análise por pagamento.
• Valide por um período curto (uma semana) comparando linha a linha com o extrato.

Mini-caso 4: “Depois de mesclar com a tabela de produtos, minhas linhas triplicaram”

Diagnóstico provável: a tabela de produtos tem múltiplas linhas por SKU (variações, histórico, duplicidade).

Correção:

• Crie uma DimProduto com uma linha por SKU (deduplicada).
• Se precisar de histórico, trate como tabela separada com chave composta (SKU+Data) e use lógica apropriada, não merge simples.
• Refaça o merge e confirme que a contagem de linhas da tabela base não mudou.