Para construir dashboards de Vendas, Caixa e Estoque que realmente funcionem no dia a dia do pequeno negócio, a base é uma estrutura de dados consistente. “Estrutura” aqui significa: quais tabelas você precisa, quais colunas são obrigatórias, como elas se relacionam e quais regras evitam números divergentes (por exemplo, venda diferente do recebimento, ou estoque negativo sem explicação). Este capítulo organiza o mínimo essencial para você modelar quatro áreas: vendas, despesas, recebimentos e estoque.
1) Conceito: o que é “estrutura de dados essencial”
Estrutura de dados essencial é o conjunto mínimo de tabelas e campos que permite responder perguntas operacionais com confiança, sem depender de planilhas paralelas. Em Power BI, isso normalmente se traduz em um modelo com tabelas de fatos (transações) e tabelas de dimensões (cadastros), com relacionamentos claros e chaves estáveis.
Uma regra prática: tudo que “acontece” (venda, pagamento, entrada de estoque) vira uma linha em uma tabela de fatos; tudo que “descreve” (produto, cliente, fornecedor, loja) vira dimensão. Assim, você evita duplicidade, facilita filtros e mantém o histórico.
1.1) Fatos x dimensões (na prática)
- Tabelas de fatos: grandes, com muitas linhas, cada linha é um evento datado (ex.: item vendido em uma nota, pagamento recebido, lançamento de despesa, movimentação de estoque).
- Tabelas de dimensões: menores, com cadastros e atributos (ex.: Produto com categoria e marca; Cliente com cidade; Fornecedor; Conta bancária; Centro de custo).
Em pequenos negócios, é comum começar com “uma planilha para tudo”. O problema é que isso mistura eventos e cadastros, e você perde rastreabilidade (por exemplo, altera o nome do produto e muda o histórico). Separar fatos e dimensões ajuda a manter consistência.
2) Padrão recomendado de tabelas (mínimo viável)
A seguir está um conjunto de tabelas que atende a maioria dos cenários de comércio, serviços e operações com estoque. Você pode começar com o mínimo e ir refinando.
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
2.1) Dimensões (cadastros)
- DimCalendario: datas, mês, ano, semana, dia da semana, feriados (se houver). Essencial para análises temporais consistentes.
- DimProduto: ProdutoID, SKU/Código, Nome, Categoria, Subcategoria, Marca, Unidade, Ativo/Inativo.
- DimCliente: ClienteID, Nome, Tipo (PF/PJ), Cidade, Estado, Canal de aquisição (se existir).
- DimFornecedor: FornecedorID, Nome, Categoria do fornecedor (opcional), Cidade/Estado.
- DimLoja/Filial (se aplicável): LojaID, Nome, Cidade, Região.
- DimContaFinanceira: ContaID, Banco, Agência, Conta, Tipo (Caixa, Banco, Carteira digital), Ativa.
- DimFormaPagamento: FormaPagamentoID, Nome (Dinheiro, Pix, Cartão, Boleto), Prazo padrão (opcional).
- DimCentroCusto (opcional, mas útil): CentroCustoID, Nome (Administrativo, Marketing, Operação, etc.).
2.2) Fatos (transações)
- FatoVendas (preferencialmente em nível de item): uma linha por item vendido (não apenas por pedido).
- FatoRecebimentos: uma linha por recebimento (entrada de dinheiro), com data de recebimento e valor recebido.
- FatoDespesas: uma linha por despesa (saída de dinheiro), com data de pagamento e valor pago.
- FatoEstoqueMov: uma linha por movimentação de estoque (entrada, saída, ajuste, transferência).
Observação importante: vendas e recebimentos não são a mesma coisa. Venda é o compromisso/registro comercial; recebimento é o dinheiro entrando. Separar as duas tabelas evita confusão quando há vendas a prazo, parcelamentos, inadimplência, antecipação de cartão ou estornos.
3) Estrutura essencial de Vendas
O ideal é registrar vendas em nível de item, porque isso permite analisar mix de produtos, margem por categoria, impacto de descontos e devoluções com precisão. Se você só tiver dados por pedido, ainda dá para começar, mas você perde detalhes.
3.1) Campos mínimos em FatoVendas (nível item)
- VendaItemID (chave única da linha) ou combinação estável (VendaID + ProdutoID + SequenciaItem).
- VendaID (identificador do pedido/nota).
- DataVenda (data do evento comercial; pode ser data de emissão).
- ProdutoID (chave para DimProduto).
- ClienteID (chave para DimCliente; pode ser “Consumidor final” quando não identificado).
- LojaID (se houver mais de uma unidade).
- Quantidade.
- PrecoUnitarioBruto (antes de desconto).
- DescontoItem (valor ou percentual; prefira valor para somas).
- ValorItemLiquido (Quantidade * Preço - Desconto; se não vier pronto, calcule).
- Impostos (opcional; se não tiver, deixe fora para não inventar).
- CustoUnitario (se você tiver custo; pode vir do estoque ou cadastro; importante para margem).
- CanalVenda (Loja física, WhatsApp, Marketplace, etc., se existir).
- Status (Concluída, Cancelada, Devolvida). Se houver devolução, registre como linha negativa ou como evento separado (mas com regra clara).
3.2) Regras práticas para evitar erros em vendas
- Cancelamentos e devoluções: defina um padrão. Exemplo: registrar devolução como quantidade negativa e valor negativo na mesma FatoVendas, com DataVenda = data da devolução e Status = “Devolução”. Isso preserva o efeito no período correto.
- Desconto: evite misturar desconto no preço unitário e também em coluna de desconto. Escolha um método e padronize.
- Frete: se o frete é receita (cobrado do cliente), trate como item separado (Produto “Frete”) ou como coluna específica. Se for custo, entra em despesas ou custo de venda, mas não misture sem regra.
- Chaves: ProdutoID e ClienteID devem ser estáveis. Não use nome como chave.
3.3) Exemplo de estrutura (tabela de vendas)
VendaItemID | VendaID | DataVenda | ProdutoID | ClienteID | Quantidade | PrecoUnitarioBruto | DescontoItem | ValorItemLiquido | Status1 | 1001 | 2026-01-02 | P10 | C5 | 2 | 50,00 | 10,00 | 90,00 | Concluída2 | 1002 | 2026-01-03 | P11 | C0 | 1 | 120,00 | 0,00 | 120,00 | Concluída3 | 1001 | 2026-01-05 | P10 | C5 | -1 | 50,00 | 0,00 | -50,00 | Devolução4) Estrutura essencial de Recebimentos (entradas de caixa)
Recebimentos representam o dinheiro que entrou (ou vai entrar) no caixa/banco. Em muitos negócios, o recebimento pode ocorrer em data diferente da venda, em parcelas, com taxas (cartão) e com conciliação bancária. Por isso, a tabela de recebimentos deve ser orientada a transações financeiras.
4.1) Campos mínimos em FatoRecebimentos
- RecebimentoID (chave única).
- DataRecebimento (quando o dinheiro entrou).
- ValorRecebido (valor líquido que entrou na conta).
- ContaID (para DimContaFinanceira).
- FormaPagamentoID (Pix, Dinheiro, Cartão etc.).
- VendaID (quando for possível vincular; pode ser nulo para recebimentos não relacionados a vendas, como aporte do sócio).
- Taxa (opcional; se você tiver taxa de cartão, registre para separar bruto x líquido).
- TipoRecebimento (Venda, Juros, Reembolso, Aporte, Outros) para não misturar.
- Status (Confirmado, Pendente, Estornado). Se houver estorno, registre como valor negativo ou como linha de estorno.
Se você trabalha com “contas a receber” (títulos), pode existir uma tabela adicional de FatoReceber (previstos) e outra de FatoRecebimentos (realizados). Se você ainda não tem esse controle, comece pelo realizado, que é o que alimenta o caixa.
4.2) Regras práticas para recebimentos
- Bruto x líquido: defina se ValorRecebido é líquido (o que entrou) e Taxa é separado. Isso facilita bater com extrato bancário.
- Parcelas: cada parcela é uma linha. Ex.: VendaID 1001 pode ter 3 recebimentos em datas diferentes.
- Conciliação: se você importar extrato, use um identificador de transação do banco (quando existir) para evitar duplicidade.
5) Estrutura essencial de Despesas (saídas de caixa)
Despesas são pagamentos e saídas de dinheiro: aluguel, fornecedores, impostos, salários, marketing, tarifas bancárias, compras de estoque, entre outros. Para dashboards de caixa, o mais importante é ter data de pagamento, valor e classificação.
5.1) Campos mínimos em FatoDespesas
- DespesaID (chave única).
- DataPagamento (quando saiu o dinheiro).
- ValorPago (valor efetivamente pago).
- FornecedorID (quando aplicável).
- ContaID (de onde saiu).
- CategoriaDespesa (pode ser uma dimensão DimCategoriaDespesa ou coluna; para começar, coluna funciona).
- CentroCustoID (opcional).
- FormaPagamentoID (Pix, boleto, cartão etc.).
- Competencia (opcional, útil para regime de competência; se não usar, não invente).
- Status (Pago, Estornado, Cancelado).
- Observacao/Documento (opcional: número da nota, referência).
5.2) Compras de estoque: despesa ou estoque?
Uma compra de mercadoria é uma saída de caixa (despesa financeira), mas também é uma entrada de estoque (movimentação). Para não duplicar análises, trate como dois registros em tabelas diferentes, cada uma com seu objetivo:
- Em FatoDespesas: registra o pagamento ao fornecedor (impacto no caixa).
- Em FatoEstoqueMov: registra a entrada de itens no estoque (impacto no saldo e no custo).
Se você tentar usar apenas uma tabela para os dois, vai sofrer para responder perguntas simples como “quanto paguei este mês?” e “quantas unidades entraram?”.
6) Estrutura essencial de Estoque
Estoque é uma área onde inconsistências aparecem rápido: saldo negativo, custo médio errado, produto sem movimentação. A estrutura essencial é uma tabela de movimentações (kardex simplificado): cada entrada ou saída é uma linha, com data, produto, quantidade e custo.
6.1) Campos mínimos em FatoEstoqueMov
- MovEstoqueID (chave única).
- DataMov (data da movimentação).
- ProdutoID.
- LojaID/DepositoID (se houver mais de um local).
- TipoMov (EntradaCompra, SaidaVenda, Ajuste, TransferenciaEntrada, TransferenciaSaida, DevolucaoCliente, DevolucaoFornecedor).
- Quantidade (positiva para entradas, negativa para saídas, ou use coluna Sinal; escolha um padrão).
- CustoUnitario (quando aplicável; para saída pode ser custo médio/último custo conforme sua regra).
- ValorMov (Quantidade * CustoUnitario; pode ser calculado).
- DocumentoRef (VendaID, NotaCompraID, AjusteID etc.).
6.2) Regras práticas para estoque
- Não calcule saldo “na mão” por soma de entradas e saídas em várias planilhas: centralize em FatoEstoqueMov.
- Transferências: registre duas linhas (saída do local A e entrada no local B) com o mesmo DocumentoRef.
- Ajustes: sempre com motivo (quebra, perda, inventário). Mesmo que seja uma coluna simples “MotivoAjuste”.
- Devolução de cliente: é entrada de estoque (quantidade positiva) e, se houver estorno financeiro, também afeta recebimentos (ou gera despesa/estorno). Não misture os efeitos.
6.3) Estoque atual: por que não é uma tabela “fixa”
O “estoque atual” geralmente é um cálculo: soma das quantidades por produto (e por depósito) até a data. Você pode ter uma tabela de snapshot (estoque diário) se o volume for grande, mas o essencial para começar é a movimentação. O snapshot é uma otimização, não um requisito inicial.
7) Relacionamentos essenciais no modelo
Com as tabelas definidas, o próximo passo é garantir que os relacionamentos sejam simples e previsíveis. O padrão mais comum é: dimensões filtram fatos (um-para-muitos), com direção de filtro da dimensão para o fato.
7.1) Relacionamentos recomendados
- DimCalendario[Data] → FatoVendas[DataVenda]
- DimCalendario[Data] → FatoRecebimentos[DataRecebimento]
- DimCalendario[Data] → FatoDespesas[DataPagamento]
- DimCalendario[Data] → FatoEstoqueMov[DataMov]
- DimProduto[ProdutoID] → FatoVendas[ProdutoID]
- DimProduto[ProdutoID] → FatoEstoqueMov[ProdutoID]
- DimCliente[ClienteID] → FatoVendas[ClienteID]
- DimFornecedor[FornecedorID] → FatoDespesas[FornecedorID]
- DimContaFinanceira[ContaID] → FatoRecebimentos[ContaID] e → FatoDespesas[ContaID]
- DimFormaPagamento[FormaPagamentoID] → FatoRecebimentos[FormaPagamentoID] e → FatoDespesas[FormaPagamentoID]
Se você tiver mais de uma data relevante na mesma tabela (ex.: DataVenda e DataEntrega), o essencial é escolher uma como “principal” para relacionamento com DimCalendario e manter as outras como colunas para análises específicas (ou usar tabelas de datas alternativas quando necessário).
8) Passo a passo prático: montando a estrutura a partir de planilhas comuns
Este passo a passo assume que você tem dados em Excel/CSV vindos de sistema, planilhas internas ou exportações. O objetivo é transformar isso em tabelas consistentes para o modelo.
8.1) Passo 1 — Liste as fontes e identifique o “grão” de cada uma
Grão é o nível de detalhe de cada linha. Exemplos:
- Planilha “Vendas”: uma linha por pedido (grão = pedido).
- Planilha “Itens”: uma linha por item do pedido (grão = item).
- Planilha “Recebimentos”: uma linha por parcela recebida (grão = recebimento).
- Planilha “Extrato”: uma linha por transação bancária (grão = lançamento bancário).
- Planilha “Estoque”: uma linha por produto com saldo atual (grão = produto, snapshot).
Para o modelo essencial, prefira transações (itens, recebimentos, movimentos). Se você só tiver snapshot de estoque, dá para começar, mas você perde rastreabilidade de entradas/saídas.
8.2) Passo 2 — Padronize IDs (chaves) antes de qualquer cálculo
- Crie/garanta ProdutoID único (SKU/código interno). Evite usar nome do produto.
- Crie/garanta ClienteID (mesmo que seja “C0” para consumidor final).
- Crie/garanta FornecedorID.
- Crie/garanta ContaID para cada conta/banco/caixa.
Se a fonte não tem IDs, você pode gerar uma chave a partir de colunas (por exemplo, “Banco-Agencia-Conta”), mas isso precisa ser estável no tempo.
8.3) Passo 3 — Separe cadastros (dimensões) das transações (fatos)
Exemplo prático: se sua planilha de vendas traz colunas de produto (nome, categoria) repetidas em cada linha, extraia uma DimProduto com valores únicos e deixe na FatoVendas apenas ProdutoID.
O mesmo vale para clientes e fornecedores. Isso reduz tamanho, melhora performance e evita inconsistência (categoria escrita de dois jeitos diferentes em linhas distintas).
8.4) Passo 4 — Normalize datas e valores
- Converta datas para tipo data (não texto).
- Garanta que valores monetários sejam numéricos e na mesma moeda.
- Padronize separador decimal e milhares (muito comum em CSV).
Uma falha típica é ter “R$ 1.234,56” como texto. Isso quebra somas e medidas. Limpe símbolos e converta para número.
8.5) Passo 5 — Trate cancelamentos, estornos e devoluções com sinal
Escolha um padrão de sinal e aplique em todas as tabelas:
- Vendas: devolução como valor negativo (ou tabela separada, mas com regra fixa).
- Recebimentos: estorno como valor negativo.
- Despesas: estorno como valor negativo.
- Estoque: entradas positivas, saídas negativas.
Isso simplifica medidas e evita “subtrair duas vezes”.
8.6) Passo 6 — Crie uma DimCalendario e conecte todas as tabelas
Crie uma tabela de calendário cobrindo todo o período dos seus dados (do menor ao maior). Inclua colunas úteis como Ano, Mês, AnoMês, Trimestre, Semana, Dia da semana. Em seguida, relacione cada fato à data correspondente (DataVenda, DataRecebimento, DataPagamento, DataMov).
8.7) Passo 7 — Valide com reconciliações simples
Antes de construir visuais, valide totais básicos:
- Soma de ValorItemLiquido em FatoVendas (excluindo canceladas) bate com o relatório do sistema?
- Soma de ValorRecebido bate com extrato/caixa do período?
- Soma de ValorPago bate com extrato/caixa do período?
- Saldo de estoque (soma de quantidades por produto) faz sentido para itens principais?
Se não bater, o problema geralmente está em: duplicidade de importação, datas erradas, estornos sem sinal, ou chaves inconsistentes (produto com dois códigos).
9) Exemplos de cenários comuns e como estruturar
9.1) Venda no cartão com taxa
Você vende R$ 100 no cartão, taxa de R$ 3, e recebe R$ 97 dois dias depois.
- FatoVendas: registra R$ 100 na DataVenda.
- FatoRecebimentos: registra ValorRecebido = 97 na DataRecebimento, Taxa = 3, FormaPagamento = Cartão, VendaID = correspondente.
Assim você consegue ver faturamento (vendas) e caixa (recebimentos) sem confundir.
9.2) Compra de mercadoria paga à vista
Você compra 50 unidades do Produto P10 por R$ 20 cada e paga R$ 1.000 no Pix.
- FatoEstoqueMov: DataMov, ProdutoID=P10, Quantidade=+50, CustoUnitario=20, TipoMov=EntradaCompra.
- FatoDespesas: DataPagamento, ValorPago=1000, FornecedorID, FormaPagamento=Pix, CategoriaDespesa=Compra de Mercadoria.
9.3) Ajuste de inventário
Você contou o estoque e faltam 3 unidades do P11.
- FatoEstoqueMov: Quantidade=-3, TipoMov=Ajuste, MotivoAjuste=Inventário.
Se houver impacto financeiro (ex.: perda/avaria segurada), isso entra em recebimentos/despesas separadamente, não no estoque.
10) Checklist de qualidade da estrutura (para pequenos negócios)
- Existe uma DimCalendario única e todas as tabelas de fatos têm uma coluna de data relacionada a ela.
- ProdutoID, ClienteID, FornecedorID, ContaID são chaves estáveis e não dependem de texto livre.
- Vendas estão no nível de item (ou você sabe exatamente qual é o grão e suas limitações).
- Recebimentos e despesas representam fluxo de caixa real (data de entrada/saída), com estornos tratados por sinal.
- Estoque é baseado em movimentações, com tipos de movimento padronizados.
- Não há colunas “misturadas” (ex.: valor de venda dentro de recebimentos sem referência, ou custo de compra dentro de vendas sem regra).
- Totais básicos batem com relatórios externos (sistema/caixa/extrato) antes de criar visuais.
