Rodrigo R1
-
Total de itens
420 -
Registro em
-
Última visita
Tipo de Conteúdo
Perfis
Fóruns
Desafios
Calendário
Downloads
Galeria
Posts postados por Rodrigo R1
-
-
21 horas atrás, Geraldo Cezar Duarte Fonse disse:
@Rodrigo R1 Bom dia,
Qualquer coisa eu te mando o projeto original, mas como é de instituição pública, não pode ser no blog.
VlwwBom dia, Geraldo. Hoje a noite eu vejo suas dúvidas, amigo e respondo aqui. Abraço.
-
1
-
-
6 minutos atrás, Geraldo Cezar Duarte Fonse disse:
@Rodrigo R1 Boa noite,
Vc chegou a mexer em alguma outra coisa fora as medidas dax?
Está dando uma zebra rsrsNão amigo. Somente fiz as medidas mesmo...rsrsrs...
Só não vou conseguir te ajudar agora. Estou no celular.
Mas assim que der eu te respondo.
Coloca suas dúvidas.
-
2 horas atrás, Raphael Hamdan disse:
Que ajuda, Rodrigo! Muito obrigado a todos pela atenção... Realmente o ponto que faltava era considerar a base de clientes atuais, no mesmo contexto que os clientes do mês passado!
Muito obrigado, abraços a todos.
Obrigado pelos créditos, @Raphael Hamdan. Que bom que você encontrou a solução.
Sucesso, amigo.
-
Oi @getswitch....
Bom....vamos lá...rsrsrsPrecisaremos dar alguns passos pra trás...rsrsrs
A primeira coisa a ser feita é ajustar o seu modelo:
Nele tem apenas 2 tabelas que tem relacionamento bidirecional - o que não é interessante manter esse tipo de relacionamento entre tabelas.
Outro detalhe é que as 2 tabelas me parecem tabelas fato - mais um motivo para evitar esse relacionamento, pois não se deve relacionar tabelas fato.
Além do que, penso que seu modelo precisa das seguintes dimensões:
dcalendario,
dClientes,
dImobiliaria,
dEmpreendimento,
dGestor,
dMétodoPagamento.
E penso que talvez 2 tabelas fato seriam suficientes para atender o seu modelo:
fVendasEmpreendimento - para informar o valor do imóvel e a entrada, por exemplo.
fpagamentoParcelas - para controle de pagamento das parcelas futuras.
Nas dimensões você irá deixar apenas a chave única e as características que pertencem a elas.
Nas fatos, você vai deixar apenas as chaves únicas de cada dimensão e as informações das vendas, como data, valor, parcelas, % comissão....
Isso estou falando pensando por alto mesmo...rsrsrs....pq tudo depende do modelo de negócios.
Mas posso te garantir que com o modelo bem estruturado assim, será muito mais fácil fazer as análises depois, via DAX.
Outra coisa que percebi é que você está criando várias colunas calculadas nas sua tabelas - em Excel fazemos assim, mas no PBI não é recomendado essa prática.
Isso não é performático e também não é a melhor alternativa. Tente evitar isso sempre!
Quando se envolve cálculos com valores, devemos sempre priorizar criar medidas - por serem dinâmicas.
Por essa razão, que está havendo essa divergência entre a solução que estou apresentando - via medidas - e você está fazendo a adaptação delas para usa-las em colunas.
Aí vai dar ruim mesmo....rsrsrs
Resumindo....
pra conseguirmos uma solução ideal para o seu case, será necessário realizar antes essas etapas acima.
Eu poderia até criar aqui a coluna calculada como você deseja....mas eu não estaria contribuindo em nada com seu aprendizado, entende?
Vai por mim....seguir o que eu escrevi acima vai ser bem melhor....esse é o caminho ideal, conforme é ensinado pelo Mestre Leonardo.
Espero que tenha conseguido contribuir.
Sucesso aí, amigo.
-
Poderia disponibilizar o PBIX pra eu verificar?
Acredito que assim seja mais fácil pra eu conseguir analisar e construir a solução...
-
Boa noite, @Raphael Hamdan, tudo bem amigo?
Se me permite uma sugestão, acredito que a comparação correta entre os períodos analisados devemos acrescentar a mesma condição na tabela de clientes atuais, conforme tela abaixo:
Assim, eu acrescentei o mesmo filtro da variável VClientesPM, usando uma Calculatetable na variável ClientesAtuais - até para o comparativo ficar equivalente.
Entendo que a medida correta a se utilizar é a segunda versão que você criou, apenas acrescentando esse ajuste que eu citei. Obs.: claro que isso vai depender dos requisitos que você quer analisar em seu case - até porque as 3 versões tem interpretações diferentes para cada uma delas.
Espero que tenha ajudado.
Sucesso aí, amigo.
-
Boa noite, @Geraldo Cezar Duarte Fonse, tudo bem amigo?
Fiz algumas medidas no seu modelo, para chegar no resultado abaixo:
Vi que você estava usando visual customizado para segmentação de dados...mas eu prefiro o tradicional mesmo...rsrsrrsrs...e inclusive recomendo...rsrsrs
Fiz 5 medidas simples para você analisar com calma posteriormente.
Percebi que as suas medidas estavam bem mais complexas para chegar no mesmo resultado. E devem ter dado muito trabalho para serem criadas...rsrsrs
Obs.:
1. Deixei o segmentador de dados como seleção única, pois acredito que faça mais sentido para sua análise.
2. A medida de Total Ano Fixo, irá manter o total do ano independente do filtro, ok? Veja que está com o ALL.
3. Criei uma medida dinâmica do mês atual que irá fazer o comparativo da variação de acordo com o mês selecionado no segmentador.
4. Inclui também outra medida do mês atual de forma fixa - para que você possa visualizar o mês atual independente da seleção do mês no segmentador - talvez faça algum sentido deixar essa informação no visual.
5 . Em anexo o PBIX.
Espero que tenha ajudado.
Sucesso aí, amigo.
-
Boa noite @Paulo Rodrigues, tudo bem amigo?
Poderia demonstrar e explicar melhor qual o resultado esperado?
Teria como fornecer o PBIX para que possamos compreender melhor o seu case?
Analisando sua medida, percebo que as combinações de filtros dentro da Calculate, me parecem excludentes.
Não tenho certeza se é o que você espera como resultado, mas acredito que você precisa criar uma variável para cada combinação e no RETURN fazer a soma dessas variáveis (combinações).
Enfim....espero que tenho ajudado de alguma maneira.
Sucesso aí, amigo.
-
É mesmo amigo, vc tem razão...rsrsrs....me desculpa...rsrs
E na minha explicação acima falei exatamente o que estava acontecendo: da análise linha a linha. mas não me dei conta que isso iria acontecer na parcela final...rsrsrsrs
Enfim....o que precisamos agora é "setar" o valor da parcela de número 1.
Para isso precisamos definir uma coluna que a identifique.
Temos a coluna "Parc" - mas ela pode não ser ideal, caso o parcelamento seja diferente de 3.
A ideia seria fazer o seguinte para o valor da primeira parcela:
Comissão Fixa Primeira Parcela = Calculate([Comissão Primeira Parcela], SuaTabela[Parc] = "1/3")
Dessa forma, irá retornar o valor referente a primeira parcela para todas as linhas. E aí poderemos usar essa medida na subtração do segundo argumento do SWITCH.
Mas tem um outro detalhe...rsrs: se tiver um parcelamento diferente de 3, essa condição não será atendida.
Então sugiro ajustar também sua tabela para que ela tenha uma coluna "Parcelas" e outra de "Parcelamento", assim:
Cliente Parcelas Parcelamento A 1 3 A 2 3 A 3 3 B 1 4 B 2 4 B 3 4 B 4 4 C 1 2 C 2 2 D 1 3 D 2 3 D 3 3 Aí iremos ajustar a medida novamente para que ela considere o valor da comissão quando a parcela for igual a 1, entendeu? Isso evitará futuros problemas no seu modelo.
Obs.: Pensando bem...rsrsrs....talvez nem seja necessária essa coluna de "parcelamento" no seu modelo....rsrsrs....mas deixei para ficar mais detalhada a minha explicação. A quantidade de parcelas você pode conseguir depois com uma contagem de linha da sua tabela.
Espero que agora tenhamos chegado no seu resultado esperado.
Continuo à disposição em ajuda-lo, amigo.
-
Ele é 400 porque é um iteração linha a linha. Aí ele considera o valor que está na parcela, que é 4.000, que 10% é 400.
Por isso, que no segundo argumento vc coloca o valor total da comissão - o valor da primeira comissão, (que já foi paga) como fiz acima.
Veja que são condições diferentes no Switch, pra atender sua necessidade: uma verifica o valor da parcela paga x acumulado e a outra verifica o valor da entrada X acumulado, entendeu?
Ajusta a medida como eu te enviei e verifica se o valor confere, por favor.
-
Amigo, mas nessa sua medida vc colocou pra retornar o valor da primeira parcela no segundo argumento do segundo switch - também não entendi porque usar 2 switch..rsrsrs
Confere aí por gentileza a minha sugestão, com a sua medida.
Sugestao: quando for usar as medidas, não precisa informar a tabela onde elas estão.
Assim, deixa as outras medidas mais enxutas e facilita a compreensão.
Aguardo seu retorno.
-
Bom dia, @getswitch, tudo bem amigo?
Para a sua dúvida, talvez seja mais fácil fazer o cálculo da comissão a partir do valor acumulado.
Para isso eu fiz duas medidas de comissão:
1 - Comissão Primeira Parcela = [Valor Pago] * 0.10
2 - Comissão Total = [Valor Entrada] * 0.10
A partir daí, a medida final:
Comissão da Imobiliária =
SWITCH(
true(),
[Valor Acumulado] = [Valor Pago], [Comissão Primeira Parcela],
[Valor Acumulado] >= [Entrada], [Comissão Total] - [Comissão 1],
0)
As medidas Valor Pago e Entrada são apenas somas das colunas.
Veja se assim daria certo no seu modelo.
Espero que tenha ajudado.
Sucesso aí, amigo.
-
Boa tarde, @Fernando Barreto, tudo bem #incomparável???
Estou há alguns dias testando aqui essa sua dúvida, e percebi que essa solução/medida não é muito performática.
Vi que alguns profissionais ensinam a fazer esse cálculo de acumulado, conforme você mencionou.
A partir disso, eu criei uma medida usando tabela virtual, pra comparar a performance.
Também não ficou das melhores, mas diminuiu alguns segundos o tempo de processamento, conforme telas abaixo:
Essa tela é a performance com as suas medidas, que tiveram duração de processamento de 13,7 segundos
Abaixo a tela com as medidas que eu criei, com tempo de processamento de 8,8 segundos - melhoria de 35,7%...rsrsrs
Como eu disse anteriormente, ainda não seria o ideal...mas de fato não encontrei alguma outra maneira ainda mais performática.
Caso tenha encontrado alguma solução, gentileza compartilhar, amigo.
Segue PBIX com as medidas testes que fiz.
Espero que tenha ajudado.
Sucesso aí.
-
1
-
-
Bom dia, @Adolfo Pizzarino, tudo bem amigo?
É possível sim.
Você só precisa fazer uma medida para que ela busque o maior ano do seu modelo.
Segue sugestão:
Soluão R1 =
var maiordia = CALCULATE(Max(dCalendario[Data]),
all(dCalendario))
Var ano = YEAR(maiordia)
return
CALCULATE([Soma],
dCalendario[Ano] = ano)
Da forma acima, você fará com que a sua medida fique dinâmica.
Ao chegar 2023, ela irá considerar o ano 2023 e fará o comparativo.
Espero que tenha ajudado.
Sucesso aí, amigo.
-
1
-
-
Bom dia @Nelson, tudo bem amigo?
Acredito que essa diferença seja em função do quarter de 2022 ainda não estar "completo".
Estamos em Maio, faltando 1 mês para completa-lo.
Acredito que o valor de 340k, seja o valor do ano de 2021 até o mês de maio - ou seja, até a mesma data do ano 2022 em que possui dados no seu modelo.
A medida está considerando o mesmo período do ano atual - maio de 2022 X maio de 2021.
Faça uma análise mês a mês e verifique se o valor acumulado até maio de 2021 seria 340k.
Mas como o Paulo disse acima, importante compartilhar o PBIX pra gente analisar e encontrar a melhor resposta.
De qualquer forma, espero que tenha conseguido ajuda-lo de alguma maneira.
Sucesso aí, amigo.
-
Amigo @Reginaldo Batista, boa noite. Tudo bem?
Sugiro a Live 28 do Leo sobre cálculos de horas e complementa com esse vídeo aqui:
Num dos vídeos da X-Dashboards da CarPinski ele tbm ensina a criar uma dimensão horas e diaponibiliza um script apenas pra copiar e colar:
Acho que seguindo esses vídeos aí e mais a Live 28, você conseguirá ajustar seus dados pra chegar na solução pretendida, inclusive para exibir no formato hh:mm:ss.
Espero que tenha ajudado.
Abraço meu amigo e sucesso aí.
-
2
-
-
Boa tarde @luciana.borgrever, tudo bem?
A sua dificuldade está sendo em função da falta de relacionamento entre as tabelas.
Veja que sua tabela fDespesas está relacionada apenas com a dcalendário.
Você precisa encontrar uma forma de relacionamento entre a fDespesas com a dPlanosdeContas e dFiliais.
Elas precisam ter uma coluna em comum para isto.
Sugiro "dar um passo atrás" e revisar seu modelo de dados.
Sucesso aí.
-
Boa tarde, @Givanildo, tudo bem, amigo?
Sua dúvida precisava ser melhor contextualizada, além de incluir uma base de dados ou um PBIX pra poder lhe ajudar melhor.
De qualquer forma, eu elaborei uma solução que talvez possa atender a sua necessidade.
Primeiro eu tive que criar uma tabela virtual dentro das medidas para conseguir encontrar o valor do décimo pedido.
Parti do pressuposto que cada linha da tabela fato seria um pedido, então uma contagem de linhas seriam a quantidade de pedidos, e consequentemente, a sua contagem acumulada, chegaríamos aos números de quantos pedidos realizados até a data do contexto - guarde essa informação para compreender a medida criada.
Cheguei então nos seguintes resultados:
Considerei que cada dia da minha tabela fato seria um pedido único.
A coluna soma é uma medida de soma dos valores dos pedidos.
A coluna contagem acumulada é a contagem acumulada de quantos pedidos realizados até a data daquele contexto.
A coluna Menor representa o valor do primeiro pedido realizado - e consequentemente a data do pedido também.
A coluna Solução R1 é o valor do décimo pedido realizado - e sua data.
Os cartões são a diferença de dias entre o primeiro e o 10º pedido e o cartão abaixo é a diferença de valor entre eles, conforme pode-se verificar pela imagem.
Vamos para as medidas:
Soma = sum(fDados[Valor])
Contagem = COUNTROWS(fDados)
contagem acumulada = CALCULATE(
[Contagem],
filter(all(dCalendario),
dCalendario[Data] <= max(dCalendario[Data])))
Menor =
var menordata = MINX(all(dCalendario[Data]),
dCalendario[Data])
var resultado = CALCULATE(
[Soma],
FILTER(
all(dCalendario),
dCalendario[Data] = menordata),
VALUES(dCalendario[Data]))
return
resultado
Solução R1 =
var tabela = ADDCOLUMNS(VALUES(dCalendario[Data]),
"Pedidos", [Contagem Acumulada],
"valores", [Soma])
var maior10 =
MAXX(
FILTER(tabela,
[Pedidos] = 10),
[Soma])
return
maior10
diferença dias =
var tabela =
ADDCOLUMNS(VALUES(dCalendario[Data]),
"Pedidos", [contagem acumulada],
"valores", [Soma])
var menordia =
MIN(
dCalendario[Data])
var maiordia =
CALCULATE(
VALUES(dCalendario[Data]),
FILTER(
tabela,
[Pedidos] = 10))
return
DATEDIFF(menordia, maiordia, DAY)
Diferença valor =
[Solução R1] - [Menor]
Bom...a medida Solução R1 foi feita através de tabela virtual, sendo o Dax Studio uma excelente ferramenta para visualizar a tabela "materializada", conforme abaixo:
Veja que a partir dessa tabela virtual, podemos usar as suas colunas como filtro dentro das medidas - como foi usado: Pedido = 10.
A medida de diferença de dias também segue o mesmo raciocínio lógico....
Enfim...agora precisa ajustar o que eu apresentei acima, a sua realidade/necessidade.
Pois ainda poderá haver necessidade de mais algum ou outro ajuste nas medidas - talvez usar ALLSELECTED ao invés de ALL na medida de Min para encontrar a data mínima do primeiro pedido....talvez seu modelo ainda tenha alguma coluna que represente o seu cliente e vc queira alguma visualização por clientes, etc.
Agora é contigo para ajustar....rsrsrs
Espero que eu tenha conseguido lhe ajudar, amigo.
Sucesso aí.
-
-
Boa tarde, @Flávio Pinheiro, tudo bem amigo?
Quanto tempo? Achei que já tivesse solucionado...rsrsrsrsrs
Fico feliz que a minha indicação da Live tenha te ajudado a compreender o seu problema.
Vamos lá....no caso da diferença de granularidade entre o seu caso e o da Live não tem problema algum.
Basta somente ajustar à sua necessidade.
O Leo usa a Dateinsperiod para o mês e você irá usar para o dia - colocando no último argumento da medida que você deseja o período em dias - day.
Para tanto, no seu modelo será preciso criar uma dcalendário auxiliar.
Pode ser criada em Dax mesmo - sem problemas - como o Leo faz na Live.
Aí vc irá criar um relacionamento inativo entre essa dcalendário auxiliar e sua tabela fato de onde vem os valores da medida.
No eixo do visual você irá colocar a coluna de dias da sua tabela calendário auxiliar.
Feito isso, você irá criar a medida abaixo e depois coloca-la no seu visual:
Medida R1 =
VAR vDataFiltrada = MAX(dCalendario[Data])
VAR vPeriodo =
DATESINPERIOD(
'Auxdcalendario'[Data],
vDataFiltrada,
-4,
DAY)
VAR vResultado =
CALCULATE(
[SUA MEDIDA],
ALL(dCalendario),
KEEPFILTERS(vPeriodo),
USERELATIONSHIP('Auxdcalendario'[Data], suatabelaFato[Data])
)
RETURN
vResultado
Na segmentação de dados você continuará usando normalmente a coluna de data da sua dcalendário original, ok? - IMPORTANTE ISSO!!!
Bom....acredito que seguindo os passos acima você irá conseguir.
Caso ainda não consiga, favor anexar seu PBIX atualizado com suas tentativas, dcalendário auxiliar e medidas criadas, pra ficar mais fácil identificar os erros.
Sucesso aí, amigo.
-
-
Boa tarde @Thiago Pedrazi.
Estou desconfiado que o problema está na sua medida Total Meta.
Acredito que talvez ela esteja com um ALL(dcalendário), assim:
Calculate(
sum(meta),
All(dcalendário))
Aí quando vc faz a medida de Meta 2022, vc adiciona um filtro com ano = 2022, mas ele não é capaz de remover o All que está dentro da medida Total Meta:
Meta 2022 =
CALCULATE(
[Total Meta],
dCalendario[Ano] = 2022
)Era como se você estive escrevendo sua medida assim:
Calculate(
sum(meta),
all(dcalendário),
dcalendario[Ano] = 2022)Veja que existe um filtro de ano = 2022 e a remoção de todos os filtros existentes com a função All - o que anula a existência desse filtro de ano, entendeu?
Portanto, acredito que o correto seria você utilizar a medida de meta assim:
Calculate(
sum(meta),
allselected(dcalendario))Dessa maneira, ela irá respeitar os filtros externos.
Ou
Calculate(
sum(meta),
dcalendário[ano] = 2022)Assim, ela irá considerar o ano = 2022 e também irá considerar os filtros de mês no visual.
Seu caso é somente ajuste na medida mesmo, amigo.
Espero que agora tenhamos chegado na solução desejada.
Sucesso aí....
-
Boa noite, @Thiago Pedrazi, tudo bem amigo?
Suas medidas tem comportamento diferente porque estão analisando contexto distintos.
Veja que a medida Pax 2022 está considerando o filtro na tabela dcalendário, quando o ano for 2022.
Já na medida All Selected Meta 22, está considerando o filtro na tabela fMetas.
Portanto, são análises distintas e, por essa razão, seus resultados também serão distintos.
Assim, você precisa ajustar sua medida Meta 22 para que o filtro considere a tabela dcalendário - tal como na medida anterior.
All Selected_Meta 22 =
CALCULATE(
[Meta 2022],
ALLSELECTED(dcalendario)
)Lembre-se que as funções ALL e ALLSELECTED são seletivas - elas consideram apenas o contexto informado.
Espero que tenha ajudado.
-
Boa noite @Lucas Soldateli, tudo bem amigo?
Isso acontece porque está havendo uma divisão por zero.
Sugiro você tentar ajustar a sua medida usando a função DIVIDE - pois ela trata esses casos e retorna "zero" ao invés desse erro.
Espero que tenha ajudado.
Comparativo Dados Mês Anterior x Mês atual
em Linguagem DAX
Postado
Boa tarde, @Geraldo Cezar Duarte Fonse.
Estou analisando as telas que você enviou, e percebi divergências entre as duas tabelas.
Na de cima temos 11 cidades e na debaixo, apenas 9.
Quando aparece uma linha em branco - pode significar que as tabelas dimensão não tem os mesmos dados na tabela fato.
Teria que fazer essa verificação se todos os munícipio que aparecem na fato, estão registrados na dimensão.
Na coluna de variação, provavelmente não está aparecendo valores em algumas linhas, porque os meses em que é feito esse comparativo estão zerados. Esse é o comportamento esperado.
Quanto aos valores zerados, teria que verificar no modelo de dados, tentar fazer filtros pra encontrar os valores, enfim....é conferência dos dados. E para isso, apenas com o PBIX.
Outra coisa foi que você disse sobre um BI original. Nesse caso, é importante que os 2 PBIX tenha a mesma estrutura de dados, colunas e relacionamentos, para que as medidas sejam reutilizadas, sem que haja necessidade de algum ajuste.
Abri novamente o arquivo que eu te enviei e conferi as medidas. Estão todas funcionando e respeitando os filtros selecionados.
Enfim....o que precisa ser feito são essas conferências que mencionei e revisar as medidas no seu modelo original, ou seja, rotinas que nós realizamos constantemente nos PBIXs....rsrsrsrs.
Espero que tenha ajudado.