MembreTristan
MembreRéponses céées sur le Forum
Bonjour Nicolas,
Dans Power BI, les totaux ne sont jamais la somme / min / max / moyenne des valeurs du dessus. Et heureusement ! Ce serait souvent faux mathématiquement (notamment pour des calculs non-additifs).
Par défaut, le total se recalcule… à la maille totale. Si vous voulez changer ce comportement, je vous encourage à encapsuler votre mesure dans un SumX.
Plus d’infos ici: https://www.sqlbi.com/articles/obtaining-accurate-totals-in-dax/
et ici: https://www.sqlbi.com/articles/why-power-bi-totals-might-seem-inaccurate/
Bonjour Randriatahina,
Le problème vient de votre dénominateur qui reste statique (28) si vous agrégez à la semaine ou au mois.
Vous devez diviser votre mesure DAX actuelle par le nombre de jours présents dans le contexte afin d’avoir un calcul juste quelque soit la maille temporelle à laquelle vous le regardez.
New Mesure = Divide ( [Votre mesure actuelle] , Countrows(DimDates) )
Ce qui revient à faire:
= Divide ( [Nb Résas] , [Nb Bureaux] * Countrows (DimDates) ) si vous voulez simplement modifier votre mesure DAX existante.
Bonjour Magalie,
Une solution équivalente à celle proposée par Olivier mais cette fois-ci en Power Query / M.
= Table.AddColumn(Tabl, “Heures_Clean”, each try [NbHeuresTravailees] / 1 otherwise 0)
Bonjour Romain,
Problème malheureusement “classique” où les utilisateurs sont souvent tentés d’utiliser des relations bidirectionnelles pour y pallier. Je vous le déconseille fortement car cela dégraderait la performance de votre modèle de données et perturberait potentiellement la propagation des filtres dans votre modèle.
Il existe une solution bien meilleure: l’utilisation de mesures DAX comme critères de filtres dans le segment (slicer). Lire ceci: https://www.sqlbi.com/articles/syncing-slicers-in-power-bi/
Enjoy !
Bonjour,
il faut encapsuler votre logique dans un SumX afin d’avoir un total correct !
Lire: https://www.sqlbi.com/articles/obtaining-accurate-totals-in-dax/
Bonjour,
Calcul assez complexe effectivement. Je l’ai développé en DAX il y a quelques années mais je ne le mets malheureusement pas à disposition gratuitement (IP).
Nous pouvons en reparler en privé si besoin.
Bonjour Guillaume,
Les groupes Microsoft 365 ne sont pas supportés dans la RLS Power BI. Il faut y renseigner soit des utilisateurs soit des groupes de sécurité (Azure).
Bon courage!
Bonjour Amine,
Il s’agit d’un problème classique de segmentation dynamique.
Une approche possible ici: https://addendanalytics.com/blog/dynamic-segmentation-of-customers-power-bi-daxBon courage !
Bonjour Anne,
Il faut encapsuler la logique de votre calcul dans un SumX afin que vos totaux soient corrects.
Plus d’informations sur les raisons de ce comportement et la solution à envisager, ici: https://www.sqlbi.com/articles/obtaining-accurate-totals-in-dax/
Bonjour Magalie,
Soit aucune date ne correspond entre les 2 tables, soit il y un problème de typage des données dans vos colonnes.
Avez-vous bien typé en “dates” dans Power Query ? N’hésitez pas à partager votre fichier si besoin.
Bonjour Ludovic,
Le mode import est à privilégier dans Power BI car c’est celui qui vous offre des performances optimales et vous donne accès à toutes les fonctionnalités de Power BI ainsi que toutes les fonctions DAX.
Le mode DirectQuery est alléchant mais pose très souvent des problèmes de performances (car chaque interaction renvoie une requête SQL sur la source).
Dans le cas de SAP Hana, il vaut souvent mieux d’abord stocker les données dans une couche intermédiaire (datawarehouse/datalake) qui est ensuite exposée à Power BI. Pourquoi pas dans Fabric, oui !
Je vous encourage fortement à visionner ce meetup du Club Power BI: https://youtu.be/xn1CTGY20R8?si=besIE8h_8NQkvu2A
Tristan Malherbe
Expert/Formateur Power BI
MVP Microsoft depuis 2017
Co-Fondateur du Club Power BI