Power BI DAX Total Acumulado Mês Anterior

No post passado sobre total acumulado (esse post aqui), falei sobre como podemos criar totais acumulados em DAX e um comentário nesse post perguntava o seguinte:

Deixa eu ver se entendi o que ele quer dizer… Então ele fala que fez uma função similar levando em consideração o mês, ok, no código dele tem ALLSELECTED() pra isso.

E aí ele diz que precisa fazer a mesma coisa, só que pro mês anterior.

Bem, eu resolvi esse problema da seguinte forma:

  1. Criei uma dimensão de tempo adequada (leia mais sobre isso aqui)
dimensão de tempo

2. Relacionei o modelo

3. Criei uma medida que me retorna o valor da medida no mês anterior

4. Criei uma medida que me retorna o Total Acumulado do mês passado

A maior diferença, além da dimensão de tempo, foi criar a VAR de vDATACORTE.

parte do código da medida do item 4

Essa medida é importante pra que o gráfico continue sequencia, acumulado mesmo depois que a data máxima padrão da tabela fato tenha se encerrado.

resultado final

Clube do Livro de Dados

O clube do livro de dados chegou!!!

Se você tem interesse em participar de um clube do livro, com objetivo de ler livros e ir discutindo, tirando dúvidas e compartilhando experiências, aqui é o seu lugar!

O clube do livro já está aberto, e nele o foco é BI, Data e Analytics. Então se você tem interesse em ler livros que podem mudar sua carreira, faz o seguinte: me manda uma mensagem privada no whatsapp ou no email e fala que quer participar do clube que eu te adiciono!

As votações para o 1o livro a ser lido pelo clube terminam no dia 10/set, então corre!

Pra você, o que não pode faltar num curso de Power BI?

Somos, ou queremos ser, Data Analysts, certo!? Que nos baseamos em dados e tomamos decisões com base em dados. Então, por causa disso, preciso que vocês me digam o que querem ver no meu curso de Power BI!

Preencham o formulário, não vai demorar nem 20 segundos! É totalmente anônimo, não precisa de colocar nome nem email.

Então vai lá e me diz, o que você busca quando pensa em fazer um curso de Power BI?!

Se eu tiver respostas o suficiente, vou criar esse curso!

Clique aqui, ou na imagem pra ir para o formulário!

clique pra ir para o formulário

Power BI DAX Calculate Evaluation Order

Comecei a fazer uns testes simples com DAX e Calculate pra entender exatamente, passo a passo, como o DAX e a CALCULATE() funcionam.

Para esse exercício vamos considerar o seguinte cenário:

clique pra aumentar

Perceba que temos:

  • uma tabela fato chamada mini
  • uma dimensão chamada dim_dish
  • relacionamento 1:N entre dimensão e fato
  • X, um visual de tabela com a coluna dim_dish[dish] e a medida [UnitsCalculate FilterRawTable Dim]
  • Y, um visual de tabela com a coluna mini[dDish] e a medida [UnitsCalculate FilterRawTable Dim]
  • uma medida [UnitsCalculate FilterRawTable Dim]

Pergunta

Por que no no visual X são exibidas três linhas, cada uma com 1 na medida e no visual Y apenas uma linha é visualizada?

Resposta

Porque no visual X o eixo é feito na coluna da dimensão, enquanto que no visual Y o eixo é feito na fato.

Por “eixo” eu chamo a coluna que define o contexto da medida, que no caso é a coluna da esquerda, “dish” ou “dDish”.

Explicando

Isso acontece por conta de como funciona a Evaluation Order (ordem de avaliação) da CALCULATE(), que é:

  1. avalia argumentos de filtros
  2. realiza transição de contexto
  3. avalia modificadores de contexto
  4. aplica argumentos de filtro e keepfilters

Essa avaliação acontece uma vez pra cada datapoint. Na prática, usando nosso cenário como exemplo o que vai acontecer é o seguinte:

No visual X:

visual X
  1. Existe um filtro externo, que é dim_dish[Dish] = “Burger” que vem por conta do eixo de Dish que você vê no visual. Então ,esse filtro vai ser aplicado e passado pra dentro da sua medida.
    1. Lá dentro da sua medida, o calculate vai receber uma tabela expandida que está com um filtro em dim_dish[Dish], beleza, guarda esse informação.
    2. Então o calculate vai avaliar o argumento de FILTER(), que retorna um filtro que é uma tabela de uma linha e uma coluna, que é dim_dish[Dish] = “Salad”. Guarda isso na memória.
  2. Realiza transição de contexto, que não existe aqui nesse cenário, então não faz.
  3. avalia modificadores de contexto, nesse caso aqui não temos, então não faz nada.
  4. aplica os argumentos de filtro, então nesse momento o argumento que temos é dim_dish[Dish] = “Salad” que é aplicado ao 1o argumento, o SUMX(). A tabela dentro do SUMX(), mini, que é a tabela expandida que está com um filtro no dim_dish[Dish] = “Burger”, vai sofrer um overwrite (sobreescrita) da calculate nessa coluna, passando dim_dish[Dish] = “Salad”.
  5. Esse filtro modifica a tabela expandida, e nessa tabela o SUMX() performa sua expressão, que no caso é somar Units, logo, o resultado vai ser 1.

Desenhando:

Primeiro nós precisamos entender qual é a tabela expandida que estamos tratando, no caso é essa:

A tabela expandida é como o DAX enxerga sua fonte de dados pra realização dos seus cálculos.

Então, lá no primeiro datapoint, que é o Burger de dim_dish[Dish], a visão que vai ser passada pra dentro da nossa medida é uma tabela expandida já filtrada, assim:

tabela expandida modificada pelo filtro externo do primeiro datapoint

Daí, dentro da medida, CALCULATE() primeiro vai avaliar o FILTER(), e no caso o FILTER() ele dá um ALL() em dim_dish[Dish], pegando Salad, e aí ele vai guardar na memória essa informação.

Perceba que em momento nenhum o FILTER() ALL() alterou a tabela temporária expandida, ele apenas faz isso pra conseguir guardar na memória o filtro que desejamos passar no primeiro argumento da CALCULATE().

Com esse filtro em mãos a CALCULATE() vai executar o overwrite nas colunas que são determinadas nos argumentos de filtro. Então, vai acontecer o seguinte:

CALCULATE() dá overwrite nas colunas que estão nos argumentos de filtro

Depois CALCULATE() aplica os filtros dos argumentos de filtros na tabela temporária expandida.

tabela temporária expandida resultante da calculate

Essa é a tabela temporária expandida que CALCULATE() vai passar para o seu primeiro argumento. SUMX() então recebe exatamente essa tabela temporária pra realizar seu cálculo, que no caso é a soma de mini[Units], o resultado vai ser 1.

Portanto, esse resultado 1 será passado de volta para o datapoint, e no seu visual vai mostrar 1 para Burger, porque a CALCULATE() sobreescreveu o filtro que existia na coluna dim_dish[Dish].

E no visual Y?

E no visual Y? Porque o comportamento é diferente no visal Y?

Porque no visual Y a coluna que está sendo afetada pelo filtro externo não é a mesma que utilizamos na CALCULATE().

No visual Y o filtro externo vem da coluna mini[dDish], e como essa coluna não é utilizada nos argumentos de filtro da CALCULATE() ela não é sobreescrita, ou seja, CALCULATE() não faz overwrite na coluna mini[dDish].

Se desenharmos o que acontece no visual Y, vai ficar assim:

Portanto, o resultado será 1 apenas quando dDish for igual a Salad e dim_dish[Dish] também for igual a Salad. Por isso que no visual aparece 1 apenas para o datapoint de Salad no visual X.

DaxStudio

Utilizando o DaxStudio fica legal pra gente ver como funciona essa ideia do filtro externo. O filtro externo ele é como se fosse um CALCULATE() envolvendo a nossa medida, ou seja, um CALCULATE() dentro do outro e, quando isso acontece, a ordem de precedência, ou o evaluation order do CALCULATE(), executa PRIMEIRO o filtro mais externo antes.

Olha o exemplo no DaxStudio:

medida original

Essa é a medida original, é o mesmo que temos no nosso cenário original:

O que acontece quando a gente tem um filtro externo, é isso aqui:

visual X, primeiro datapoint

Então perceba, existe uma CALCULATE() por fora da CALCULATE() passando um filtro, que é o Burger, usando a coluna da dimensão, como no visual X. Veja que o resultado é Salad = 1. Se eu colocar ali Pasta, Burger, Salad, qualquer resultado vai ser 1, por conta do overwrite que a CALCULATE() mais interna realiza antes de criar a tabela que será utilizada pelo SUMX().

Agora vamos ver como ficaria se fosse como no visual Y.

visual Y, primeiro datapoint

Note que, quando alterei o filtro externo da primeira CALCULATE() para uma coluna diferente da utilizada no argumento de filtro da CALCULATE() interna, o resultado ficou como BLANK, porém, se eu passar no filtro externo Salad, o resultado vai ser 1.

Por que? Porque existe uma interseção que resulta verdadeiro somente nesse caso, conforme observamos de acordo com os registros da tabela expandida e também conforme já expliquei ao longo desse post!

Conclusão

Espero que isso possa ajudar a todos a entender melhor como funcionam a ordem de avaliação da CALCULATE()!

Dúvidas ou sugestões, deixem aí no comentário!

Referências

https://www.sqlbi.com/articles/order-of-evaluation-in-calculate-parameters/

https://www.sqlbi.com/blog/marco/2010/01/03/how-calculate-works-in-dax/

https://www.sqlbi.com/articles/expanded-tables-in-dax/

Power BI Trilha de Estudos DAX

Tenho estudado DAX cada dia mais e uma dificuldade que tive foi de encontrar bons recursos e de estruturar uma trilha de estudos pra conseguir chegar no nível que eu quero. Claro que cada pessoa vai ter mais, ou menos, facilidade em aprender os conceitos e realmente dominar o DAX, mas aqui quero compartilhar com vocês o que está funcionando pra mim.

Abaixo vou colocar uma lista do que eu estou efetivamente estudando/lendo/praticando.

  1. estudar e entender modelagem dimensional
    1. curso em vídeo do SQLBI.com; https://www.sqlbi.com/p/data-modeling-for-power-bi-video-course/
    2. livro de modelagem do SQLBI.com; https://www.sqlbi.com/books/analyzing-data-with-microsoft-power-bi-and-power-pivot-for-excel/
    3. curso em vídeo do Joviano; https://www.hotmart.com/product/modelagem-de-dados-dax-e-m-avancados/S49700766G
  2. Dominar o “framework” do DAX (evaluation context); https://www.csgpro.com/blog/elements-of-dax-with-brian-grant/; playlist gratuita no youtube que melhor ensina como DAX realmente funciona. Essa aqui é o conhecimento base que vai te permitir aprender coisas mais avançadas com mais tranquilidade.
  3. Curso de DAX avançado da DATAB; https://conteudo.databinteligencia.com.br/powerbielite
  4. Ler o livro Supercharge Power Bi do Matt Allington; https://www.amazon.com.br/gp/product/1615470522/
  5. Ler o livro Applied DAX with Power BI do Teo Lachev; https://www.amazon.com.br/gp/product/1733046100/
  6. Curso de DAX do SQLBI.com; https://www.sqlbi.com/p/mastering-dax-video-course/
  7. Ler o livro The Definitive Guide to DAX do SQLBI.com; https://www.sqlbi.com/books/the-definitive-guide-to-dax-2nd-edition/

Bônus: learning path da Microsoft pra aprender DAX; https://docs.microsoft.com/en-us/learn/paths/dax-power-bi/

Importante que cada curso e livro seja absorvido ao máximo, fazendo todos exercícios e com muita prática e mão na massa.

Essa é a minha lista, qual é a sua?!

Power BI DAX Total Acumulado

O que é Total Acumulado, ou Running Totals? Total Acumulado é a soma acumulada ao longo de um tempo, ou de alguma outra coluna que possa ser colocada em ordem.

No caso da nossa imagem abaixo é o acumulado de itemValor ao longo da dataItem.

total acumulado

E como fazer isso no Power BI usando DAX?

Acumulado com Gaps

Normalmente criamos uma medida assim:

max data fato

Se olharmos assim numa tabela, parece que deu certo.

Porém, observe as datas, perceba que no período 1 temos gaps, enquanto que no período 2 não temos gaps (vai do dia 1 ao dia 20 direto, sem faltas). Se colocarmos isso num gráfico de linha fica mais fácil de perceber.

O problema com essa medida é que ela gera esses gaps. Isso porque nas datas que não temos dados na fato ela retorna blank, gerando esses gaps, isso acontece porque não há interseção entre datas na dimensão calendário com essas mesmas datas na fato.

E como resolver isso?

Acumulado sem Gaps, mas com Data Futura

Pra resolver o problema dos gaps, podemos ajustar a medida simplesmente alterando a variável de DATACORTE pra utilizar a data da dimensão calendário e não mais da fato.

max data calendario

O problema é que isso vai gerar valores futuros, assim:

Perceba que agora não temos mais gaps, mas os valores continuaram a serem exibidos em datas futuras. Devia ter parado ali em 20-01, mas continuou, se olharmos num gráfico de linha fica mais fácil de perceber.

o gráfico avança no futuro

E como fazer pra resolver isso?

Acumulado com IF

O jeito mais fácil de resolver essa questão é com um bom e velho IF. A medida fica assim:

Nesse caso precisamos adicionar uma variável nova, que é a vDATACORTE, que diz pra gente até que data tem dado pra ser exibido.

Daí no IF é verificado se a dataContexto é menor ou igual a DataCorte, portanto quando a data do contexto for dia 21-01, que é uma data que já não tem mais dados, o que vai ser retornado é apenas o valor da medida [Amount], que vai ser BLANK() já que na fato não temos mais dados pra serem exibidos nessas datas.

Colocar [Amount] ali na condição do else é importante pra exibir os valores de [Amount] nos totalizadores (headers, sub-totals, essas coisas). Vamos ver como fica na matriz:

medida com IF funcionando lindamente =)

Vamos ver como fica o resultado no gráfico de linha:

Pronto! Esse é o resultado que estávamos buscando! Existem outras formas de realizar esse acumulado, eu sei de pelo menos mais outras duas, mas que são mais complexas e fazem uso de coluna calculada adicionada ao modelo, portanto, vou preferir não falar delas aqui também pra não extender mais o post.

Se esse post te ajudou de alguma forma, compartilha! 🙂

O Modelo e a Base de Dados

fato
dimensão

Power BI Períodos Irregulares no mesmo Gráfico de Linha

Como já disse em outros posts, nosso trabalho como analista é gerar insights e resolver problemas da vida real que gerem valor para nossos clientes.

Esse foi um pedido de um cliente de algo que eu ainda não tinha feito e nunca tinha visto ser resolvido, mas dei meu jeito, rs.

O Problema

Olhe primeiro as imagens, depois explico…

O cliente que transformar o primeiro gráfico no segundo, usando exatamente a mesma base de dados.

transformar esse gráfico
nesse gráfico!

Agora que você já deu uma olhadas nos gráficos, explico o problema… O cliente deseja que os gráficos se sobreponham pra ele conseguir identificar desvios, diferenças, ou seja, novembro do ano 2019-2020 tem que comparar com novembro de 2021-2022, porém 2019-2020 tem dois novembros e eles não podem se agrupar!

Analisando e Resolvendo

Com desse modelo de dados temos que ser capazes de realizar toda e qualquer operação de inteligência de tempo, então precisamos de dimensões de datas adequadas. Explico melhor sobre isso nesse post aqui: https://powerbixpert.com/2021/02/10/power-bi-dax-time-intelligence/.

O que eu fiz foi o seguinte, entendi e encontrei o padrão de comportamento das datas e criei uma nova coluna de data na fato que segue esse novo padrão e depois criei uma nova dimensão de data que relaciono com a fato e crio toda inteligência de tempo necessária.

Qual foi a lógica que usei pra criar a nova coluna de data na fato? Esse aqui que é o pulo do gato.

Eu pensei o seguinte, eu preciso dar um ponto de partida em comum pra todas as linhas, certo? Ou seja, o preciso que todas as linhas comecem no mesmo lugar e respeitem suas curvas, então pensei, vou pegar todas as datas do primeiro ano e vou colocar em 1900. Então se o primeiro ano é 2017, preciso subtrair 117, se o primeiro ano for 2018, subtrair 118, e assim sucessivamente.

Então pra cada período identificar esse valor a ser reduzido do ano de acordo com o primeiro ano do período, dessa forma vou ter sempre os anos em ordem e garanto que o primeiro ano seja 1900.

um esboço da ideia

Com a lógica bem definida na cabeça, agora é só criar a nova coluna calculada na fato. Poderia ter sido feito em M ou DAX, ou até mesmo no SQL na fonte. Eu fiz em DAX, assim:

Depois foi só criar uma nova dimensão de data, menor e reduzida, porque sei que nunca vou ter mais que 3 anos nessa dimensão. Então criei no M uma dimensão que vai de 1900 a 1902. O modelo final ficou assim:

modelo final

O resultado final ficou assim:

resultado final

Com esse resultado você consegue garantir funcionamento de todas dimensões sobre todos os dois gráficos, também garante funcionamento das funções de inteligência de tempo. Sensacional!

Referências

Sinceramente não achei nada na internet resolvendo um problema como esse, o mais próximo que achei foi isso aqui:

https://youtu.be/M14HX0c3jvo – Chart friendly date table in Power BI

Se você tiver algum dica ou sugestão de como resolver melhor, ou de outra forma, esse problema, deixa aí nos comentários!

Power BI Formatação Condicional Matriz

Um dos posts mais acessados no blog é o Power BI Formatação Condicional em Texto, e hoje precisei fazer uma outra formatação condicional, mas dessa vez em uma matriz, que fica um pouquinho diferente.

O Problema

Antes de mais nada, vamos ver o resultado esperado, conforme imagem abaixo:

clique pra aumentar

Meu cliente pediu pra, no GROSS PROFIT apenas, pintar o resultado do subtotal de vermelho, quando for menor que zero, ou verde quando for maior que zero.

Analisando

Antes de sair fazendo, vamos pensar no que precisamos. Pra esse caso preciso de alguma forma identificar aquela célula do subtotal do Gross Profit. Eu sei que no DAX a função ISINSCOPE() pode me ajudar com isso.

Ou seja, com essa função vou dar um jeito que identificar exatamente aquela posição que eu quero.

Porque pensa assim, eu sei que eu tenho ali duas dimensões, a de KPI e a de Company, então eu preciso identificar quando o KPI for igual a GROSS PROFIT e a company for nada, ou seja, a company não estiver no escopo. Então é só criar uma medida que me retorne essa condição!

Mão na massa

Seguindo o raciocínio do tópico anterior, eu crio a medida utilizando a ISINSCOPE() com SWITCH().

O mais importante nessa medida é a ordem das funções ISINSCOPE(), isso por conta da lógica que o SWITCH() aplica. Portanto, primeiro é preciso verificar dVenture pra só depois verificar dKPI, caso contrário nossa medida não funcionaria, isso porque dKPI retorna TRUE pra todas as linhas, enquanto que dVenture só retorna TRUE para as linhas onde realmente aparecem as company.

Agora no lugar de mostrar “kpi” eu coloco pra mostrar o nome do KPI, faço isso usando SELECTEDVALUE() do dKPI, e trago também uma variável que traz o valor de SalesAmount.

Já coloquei as variáveis em uso junto da lógica, portanto se o ISINSCOPE() do dKPI for TRUE() e o kpi for Gross Profit e o valor de SalesAmount for maior que zero, então escreva “aqui”.

Pronto, a lógica é essa, a medida final fica assim:

SalesAmount CF = 
VAR vSELECTVALUE = SELECTEDVALUE( dKPI[kpiLevel1] )
VAR vSALESAMOUNT = [SalesAmount]
VAR vRESULT = 
SWITCH (
    TRUE,
    ISINSCOPE ( dVenture[VentureMask] ), "company",
    ISINSCOPE ( dKPI[kpiLevel1] ) = TRUE() && vSELECTVALUE = "Gross Profit" && vSALESAMOUNT > 0, "#47C165", // VERDE
    ISINSCOPE ( dKPI[kpiLevel1] ) = TRUE() && vSELECTVALUE = "Gross Profit" && vSALESAMOUNT < 0, "#D64550"  // VERMELHO
)

RETURN
vRESULT

Aplicando a Formatação Condicional

Pra finalizar e aplicar a cor verde ou vermelha que definimos na medida, basta selecionar a medida na matriz e definir como Field Value. Importante, pra esse caso, é selecionar Apply To para Values and totals, porque aquele lugarzinho ali é um total.

Power BI Esconder Abas Automaticamente usando RLS

Recentemente recebi um desafio de um camarada lá no Linkedin, que disse o seguinte:

“quero usar RLS pra ocultar as “abas”. Dependendo da pessoa, quer mostrar uma aba ou não…”.

Nota: abas ou páginas são sinônimos nesse post.

Esse é um assunto bastante complexo e nativamente o Power BI não resolve isso, então tem que ser no work around. Inclusive, pra quem quiser saber mais de RLS sugiro ler meu post sobre isso, aqui: https://powerbixpert.com/2020/08/20/power-bi-rls/.

O Problema

São dois os problemas nesse cenário. Primeiro você precisa modelar os dados de forma que você consiga dizer quais usuários acessam quais páginas; e Segundo como fazer pra que apenas as páginas desejadas sejam visíveis e acessíveis pelos usuários.

Vale notar que pra que esse work around funcione todas as abas do relatório precisam estar como escondidas (hide).

Mão na massa

Modelo de dados

Então, pra resolver o primeiro ponto, que é do modelo de dados, você precisa de uma tabela de páginas, de uma tabela de usuários e de uma tabela de usuários_paginas.

tabelas

Com isso já dá pra ver que, Pedro Carvalho tem acesso em todas as páginas, enquanto que Adele e Pradeep tem acesso apenas nas páginas 1 e 2, home e geral, respectivamente.

modelo

Importante: o relacionamento entre USER_PAGINA e PAGINAS que tem sentindo “ambos” deve ser habilitador a opção “apply security filter in both directions” pra que roles de RLS sejam transmitidas nesse relacionamento.

Acesso às páginas

Pra resolver o segundo ponto, de visualização e acesso às páginas, existem algumas formas que são: ou você usa um slicer dropdown com single select na página, que é o que eu usei, e a partir da seleção desse dropdown o usuário acessa a página; ou então você cria um botão pra cada página e esconde os botões de acordo com acesso do usuário, que eu acho mais deselegante porque o botão fica transparente, mas dá pra ver que tem algum objeto ali…

Pra criar esse slicer basta criar um slicer com a coluna de nome das páginas e criar uma medida que pega o nome que tá no slicer. Então importante: o nome da aba tem que ser exatamente igual ao que estiver no slicer. Boa prática é colocar esse slicer como single select.

slicer

Depois, criar um botão que pega o valor da medida e passa como argumento do Page Navigation.

botão com page navigation

Então quando o slicer estiver com a página GERAL selecionada, ao clicar no botão GO o relatório irá pra aba GERAL.

RLS Role

Por fim, é preciso criar uma role do RLS, pra saber como, leia aqui. No caso aqui o RLS ficou assim:

Testando

Com tudo pronto, agora é testar. Antes vamos lembrar das permissões que temos:

permissões

Então se eu pegar o usuário Adele, só vão aparecer 2 páginas pra mim, vamos ver.

Vamos tentar agora com usuário Pedro:

Referências

https://www.daytodatastuff.co.uk/blog/dynamically-hide-a-page-in-power-bi

https://www.linkedin.com/pulse/page-tab-level-security-conditional-navigation-power-bi-a%25C5%259F%25C4%25B1ro%25C4%259Flu/

https://www.youtube.com/watch?v=u8O2wqZ1IGk – Dynamically Filter Page Navigation Per User With Row Level Security (RLS)

Power BI Atualização Automática Onedrive

Meu cliente pediu pra colocar o report do Power BI pra atualizar toda vez que alguma coisa fosse feita na base de dados, ou seja, é um report que usa um excel num Onedrive como base de dados, daí toda vez que alguém for lá e adicionar ou alterar esse excel ele quer que o relatório do Power BI lá na workspace do Power BI Service atualize.

Dá pra fazer isso só com Power BI? Talvez, se você souber, deixa aí nos comentários, eu só consegui mesmo através do Scheduled Refresh.

Se a fonte de dados fosse um Direct Query seria possível configurar automatic page refresh, mas não é o caso.

O Problema

Então é só habilitar aquela opção de atualizar por Onedrive que tá de boa, certo? Errado!

Muitas pessoas me falaram que o report atualiza de boas usando aquela opção do Onedrive, mas estudando mais a fundo percebi que aquela opção não funciona bem assim… Deixar a opção de atualizar por Onedrive na verdade faz o seguinte:

-> Atualiza o seu report de acordo com o que está no seu arquivo do Power BI, o .pbix que está lá no seu Onedrive.

atualização do onedrive habilitada

Ou seja, se seu arquivo .pbix (power bi desktop) está num Onedrive e essa opção está ativa, quando você abrir o arquivo no seu PC e clicar Refresh de depois salvar, aí beleza, tudo que está nesse .pbix será refletido no seu relatório lá no Power BI Service (que roda mais ou menos a cada 1 hora).

Agora, se você abrir teu arquivo .pbix e não clicar no refresh, mas adicionar ou excluir um visual, por exemplo, e salvar o arquivo, os dados no seu relatório no Power BI Service não serão atualizados, apenas os visuais que tu alterou.

Data Refresh

Esse artigo é meio grandinho, mas a verdade está aí, https://docs.microsoft.com/en-us/power-bi/connect-data/refresh-data#onedrive-refresh, vou destacar na imagem abaixo.

Perceba que o item “1.) OneDrive refresh” só faz sincronizar o que tem no .pbix com o que vai aparecer no service, ou seja, se os dados não foram atualizados no .pbix desktop ele não vai ser atualizado no service.

No item “2.) Data refresh” é onde o dataset vai realmente ser atualizado.

scheduled refresh (item 2 da img anterior)

Conexão do Power BI

Estou assumindo que você fez uma conexão no Power BI com a lista do seu Onedrive ou Sharepoint, usando WEB ou Sharepoint Folder. Isso é importante pra garantir que seu arquivo sincronize com Onedrive/Sharepoint.

Para confirmar se seu datasource está conectado usando um desses tipos verifique lá no Power Query no Editor Avançado.

Ou também no dataSource Settings do Power BI:

Outro problema

Uma coisa que me aconteceu: “meu pbix tá no onedrive, meu arquivo excel tá no onedrive, eu publico o relatório abrindo o pbix e dando publish e quando vou configurar o refresh no dataset a opção de Onedrive não aparece”.

Se isso acontecer, carregue o arquivo pbix usando GET DATA na sua workspace.

get data > files
onedriver business ou sharepoint

Na opção de Onedrive Business você vai ter apenas os arquivos que estão na account logada no power bi service.

Na opção de Sharepoint você informa o site do sharepoint.

sharepoint url

Daí vai aparecer essa tela pra você navegar nas pastas do sharepoint e achar teu arquivo e dar GET DATA.

Fazendo isso deve habilitar a opção de Refresh do Onedrive pra você nesse dataset.

Referências

https://www.youtube.com/watch?v=ClmZ-8p6x9g&t=250s – Use Microsoft Flow, and other options, to refresh your Power BI dataset

Power BI Últimos 3 Meses

Então… Continuando a saga das visões para o cliente kkkkkkk. Mas brincadeiras a parte, nosso trabalho como analista é gerar insights e resolver problemas da vida real que gerem valor para nossos clientes/usuários.

O Problema

No último post falei da visão Full Year e Year to Date, mas agora o cliente falou que quer ver também a visão dos últimos 3 meses, Last 3 Months. O problema é que meu modelo de dados nesse report é um pouco mais complexo do que o normal, deixa eu explicar por cima…

Meu modelo tem 2 tabelas de datas, uma que controla a data de referencia e outro a data de input. Então pra cada mês de referencia eu tenho um ano inteiro de input. E claro, os últimos 3 meses não podem levar como base o mês atual, e sim o mês filtrado na data de referencia.

Primeiros Passos

Então quando o cliente fala que quer os últimos 3 meses na verdade ele quer os meses Março, Abril e Maio e não Outubro, Novembro e Dezembro, porém, se mudarmos a seleção da data de referencia pra o mês 4 os últimos 3 meses também vão mudar, você entendeu, rs!

A lógica do cálculo em si é simples, basta pegar duas variáveis, uma que retorne a data para o mês que corresponde ao filtro da data de referencia, e outra com a data de 3 meses atrás.

Na imagem acima temos um exemplo simples do que precisamos fazer. O desafio é gerar as medidas que vão nos retornar DataIni e DataFim.

Antes de começar, vamos ver o que temos:

clique pra ver maior

A medida “teste 3 month” está com o código da imagem anterior. Nosso objetivo é automatizar isso.

Mão na massa

Já sabemos o que precisamos, vamos criar uma medida que retorne a data fim, porque essa é a data que vem do meu filtro da data de referencia.

Pra “facilitar” o filtro que tenho na minha data de referencia não é numa coluna data, e sim numa coluna texto, que retorna várias datas. Veja na imagem anterior o slicer LE Version que está em 5+7, isso significa que estou no mês 5.

clique pra ver maior

Pra conseguir pegar a data da seleção do filtro da data referencia eu criei 3 VAR.

Na VAR maxDateReference eu pego o max da data. Eu faço isso porque dDateReference[DateReference] não é um valor scalar, ele nesse momento tá trazendo uma lista de datas e eu só quero uma, qualquer uma, não importa, porque sei que todas as datas estão no mesmo mês.

Depois, na VAR monthDt eu pego o MONTH() dessa data, que vai ser 5, porque meu filtro da date reference tá em 5+7.

Depois, na VAR vDateEnd eu calculo mesmo a data de corte que preciso, o resultado aqui vai ser 01-05-2021. Perceba que no FILTER() eu verifico qual data é igual ao mês que peguei nas VARs acima e também filtro pra tirar fora os blanks.
Tirar os BLANKS() ali foi necessário pra garantir que só vamos tratar de campos que tem valores, caso contrário o resultado seria null porque como estrou trazendo MIN() de dateInput com FILTER() de ALL() de dateInput no mes 5, logo, o resultado seria o valor mínimo do mes 5 de toda minha tabela de dateInput, que no caso é 01/05/2020. Ah, e eu sei que não vou ter dados em 2020 porque na tela tenho um slicer filtrando 2021, caso contrário essa fórmula não funcionaria, hehe.

Com isso, finalizamos nossa data fim.

clique pra ver maior

Na imagem acima já ajustei a fórmula pra usar nossa nova fórmula que criamos agora.

Na sequencia preciso criar a data de inicio, que nada mais é do que a data fim 3 meses atrás. Pra isso vou usar a função EDATE(), que eu não conhecia, só fui conhecer resolvendo esse problema e quem me apresentou ela foi o Fred, o mago!

clique pra ver maior

Perceba que mudei o sinal da lógica, por conta do resultado que EDATE() me retorna.

Pronto, a medida está finalizada, o resultado é exatamente o mesmo que tinhamos no começo, mas agora com medidas automáticas =)

clique pra ver maior

Extra, adicionando a medida no slicer

Talvez vocês tenham percebido que agora além de Full Year, Year to Date temos Last 3 Months no slicer que temos no report, de forma que o usuário pode escolher como quer ver seus dados.

Eu expliquei como criar esse slicer nesse post aqui.

Pra adicionar mais uma opção no slicer você precisa:

  1. alterar sua tabela criada manualmente, editando source e adicionando Last 3 Month
clique pra ver maior

2. Adicionar na sua medida Switch, que expliquei como fazer nesse post, mais uma fórmula, que vai retornar o Last 3 Months.

Básicamente é isso pessoal, qualquer dúvida, deixem aí nos comentários!

× Como posso te ajudar?