PL-300 : 7 erreurs de DAX, de modèle et de sécurité

AVERAGEX parcourt les clients, mais cela ne suffit pas à filtrer leurs ventes. Un SUM écrit directement à l’intérieur conserve le même contexte de filtre à chaque tour. Avec deux clients à 100 € et 300 €, il renvoie 400 € à chaque fois. La moyenne reste donc à 400 €.

Appelle plutôt la mesure [CA]. Elle applique ce filtre automatiquement, c’est la transition de contexte, et la moyenne retombe à 200 €.

CA = SUM(Ventes[Montant])

CA moyen par client =
AVERAGEX(VALUES(Clients[ClientId]), [CA])

Un client dont [CA] renvoie BLANK sort du calcul. Un client à zéro est inclus et fait baisser la moyenne.

Clients actifs = DISTINCTCOUNT(Ventes[ClientId])

Un client qui achète dans deux catégories apparaît sur deux lignes, mais une seule fois au total. Avec 60 clients en Jeux et 50 en Livres, dont 20 dans les deux, le total affiche 90. Les 20 clients présents dans les deux catégories ne sont comptés qu’une fois au total.

Pour un indicateur de clients uniques, 90 est le résultat attendu. Additionner les catégories avec SUMX(VALUES(Produits[Categorie]), [Clients actifs]) donne bien 110, mais compte deux fois les 20 clients communs. La mesure répond alors à une autre question. Il faut donc aussi changer son nom, pas seulement son total.

DISTINCTCOUNT compte aussi BLANK comme une valeur. Pour exclure les identifiants vides, utilise DISTINCTCOUNTNOBLANK.

Une vente de 100 € à 50 % de marge et une vente de 1 000 € à 10 % font 30 % en moyenne simple. La marge réelle est de 150 € sur 1 100 €, soit 13,6 %. Il faut diviser la somme des marges par la somme des ventes.

Vérifie d’abord que Montant et Cout sont dans la même devise et au même niveau de détail. Si le coût d’une commande est recopié sur chacune de ses lignes, la formule le soustrait plusieurs fois.

Marge sur CA =
DIVIDE(
    SUM(Ventes[Montant]) - SUM(Ventes[Cout]),
    SUM(Ventes[Montant])
)

Sans valeur de remplacement, DIVIDE renvoie BLANK quand le dénominateur vaut zéro ou est vide. Afficher 0 % ferait croire à une marge nulle, alors que le ratio n’existe pas.

Avec une relation active entre Produits et Ventes, cette mesure force Rouge sur la colonne Couleur. Si le lecteur du rapport a choisi Bleu dans un segment sur la même colonne, son choix est remplacé.

CA rouge = CALCULATE([CA], Produits[Couleur] = "Rouge")

Pour ne garder que les ventes rouges parmi les couleurs sélectionnées, ajoute KEEPFILTERS. Les deux filtres s’appliquent alors en même temps.

CA rouge dans la selection =
CALCULATE([CA], KEEPFILTERS(Produits[Couleur] = "Rouge"))

Si le segment ne garde que Bleu, aucune vente n’est à la fois bleue et rouge, et la mesure renvoie BLANK. Les filtres posés sur les autres colonnes ne bougent pas.

Dans ce modèle, Calendrier filtre Ventes par DateCommande. Un visuel construit sur Calendrier[Date] répartit donc le chiffre d’affaires par date de commande. Pour calculer sur DateLivraison, une seconde relation doit déjà exister entre Calendrier et DateLivraison. Elle est forcément inactive, car une seule relation peut être active entre deux tables. La mesure l’active le temps du calcul.

CA livre =
CALCULATE(
    [CA],
    USERELATIONSHIP(Calendrier[Date], Ventes[DateLivraison])
)

La RLS ne se propage jamais par une relation inactive, même avec USERELATIONSHIP. Une mesure qui utilise USERELATIONSHIP peut aussi renvoyer une erreur quand la RLS est définie sur une table de la relation activée. Dès que des rôles RLS existent, ou que les visuels doivent filtrer par les deux dates à la fois, Microsoft recommande une table de dates par usage, chacune reliée activement à Ventes.

Dans une dimension historisée de type 2, un produit a une ligne par version, chacune avec sa clé technique. Un produit qui a changé deux fois de gamme a donc trois lignes. Chaque vente porte la clé de la version valable à sa date.

Le bouton « Supprimer les doublons » ferait disparaître le problème visuel, mais aussi l’historique. Garde les versions et relie Ventes à leur clé technique, unique dans la dimension. Une relation plusieurs-à-plusieurs sur le seul code produit ne sait pas choisir la version valable à la date de vente.

Les autorisations de plusieurs rôles RLS s’additionnent. Un utilisateur qui cumule les rôles France et Île-de-France garde l’accès à toute la France. Avant de conclure, regarde tous les rôles attribués à la personne, directement ou par les groupes de sécurité dont elle est membre.

Le compte utilisé pour le test compte aussi. Dans l’espace de travail, la RLS s’applique au Viewer, pas aux rôles Admin, Member ou Contributor. Pour vérifier ce qu’un lecteur voit réellement, reprends ses droits dans l’espace de travail et l’ensemble de ses rôles RLS.