Daxone https://daxone.fr 100% Power BI et DAX Thu, 20 Feb 2020 05:23:18 +0000 fr-FR hourly 1 https://wordpress.org/?v=5.3.2 Un choix parmi les nouveautés de février 2020 https://daxone.fr/un-choix-parmi-les-nouveautes-de-fevrier-2020/?utm_source=rss&utm_medium=rss&utm_campaign=un-choix-parmi-les-nouveautes-de-fevrier-2020 https://daxone.fr/un-choix-parmi-les-nouveautes-de-fevrier-2020/#respond Thu, 20 Feb 2020 05:23:17 +0000 https://daxone.fr/?p=689 Janvier est un mois de relâche, ou plus précisément, pas de nouveautés pour Power BI Desktop, l’accent étant mis sur Power BI Server. Nous attendions donc avec impatience Février ! Voici mon choix de trois nouvelles fonctionnalités, dont la très attendue actualisation incrémentielle et le non moins attendu filtre hiérarchique

L’article Un choix parmi les nouveautés de février 2020 est apparu en premier sur Daxone.

]]>
3 nouveautés de Février 2020

L’actualisation incrémentielle

Jusqu’à maintenant réservée à la licence Premium, elle est maintenant disponible pour la licence Pro également.

De quoi s’agit-il ? L’actualisation incrémentielle de votre rapport permet de ne rapatrier que certaines lignes, typiquement toutes les nouvelles lignes depuis le dernier rafraîchissement, en fonction d’une date de transaction par exemple, – ou encore toutes les lignes modifiées depuis, en fonction d’une date de mise à jour, pour un chargement plus rapide des données, lors de l’actualisation dans Power BI Service.

Remarque : je montre la mise en place sur un fichier Excel à titre d’exemple uniquement, car cette fonctionnalité est destinée à des bases de données – voir limitations et réserves en fin d’article.

Comment la mettre en place ?

Pour commencer, dans votre document ouvert avec Power BI Desktop, lancer Power Query et créez deux paramètres RangeStart et RangeEnd :

Les valeurs actuelles saisies ne sont pas déterminantes, mais leur format oui : Date/Heure, ainsi que leur nom (RangeStart et RangeEnd).

Créez ensuite un filtre personnalisé sur le champ Date/Heure de votre table :

En utilisant bien les opérateurs >= et < (ou > et <=) – autrement dit, un seul des deux opérateurs peut être accompagné du Egal :

Vous remarquerez tout de suite que le filtre s’applique sur votre jeu de données.

Fermez et appliquez pour repasser dans Power BI.

Enfin faite un clic-droit sur la table (ou sur chaque table) sur laquelle vous voulez appliquer l’actualisation incrémentielle (Feuil1 pour moi) :

Et renseignez les champs :

  • Activez l’actualisation incrémentielle sur la table
  • Précisez la profondeur historique, c’est-à-dire la période « glissante » de données – toute date antérieure à celle-ci sera écartée lors de l’actualisation. Dans mon exemple, je ne garde que 3 mois de données : lorsque ce rapport sera publié sur Power BI Service la première fois, 3 mois de données seront récupérés.
  • Précisez ensuite la période à récupérer lors de chaque actualisation incrémentielle – ici, à chaque fois qu’est rafraîchi le rapport à partir de Power BI Service, 7 jours de données sont chargés.
  • Sauf si vous cochez la case Détecter les changements de données : dans ce cas, seuls les changements survenus au cours des 7 derniers jours sont chargés. Pour que cela fonctionne, il faut pouvoir indiquer un champ où trouver la date/heure de dernière modification. Attention :  cette colonne ne doit pas être la même que celle sur laquelle sont basés les paramètres. Il faut avoir une colonne spécifiquement destinée à recueillir l’information de mise à jour
  • Enfin dans certaines situations (cours d’une commodité, solde bancaire, …), il est important de ne récupérer que des journées complètes

Appliquez, et voilà ! Il ne reste plus qu’à publier sur Power BI Service et, par exemple, à mettre en place une actualisation automatique (programmée) – attention, le rapport .PBIX ne pourra plus être téléchargé, et le tour est joué.

Limitations et réserves : cette fonctionnalité repose sur le principe d’un partitionnement de la table en petites sections – cette opération doit pouvoir être effectuée par la source de données elle-même (il faut donc qu’ait lieu le « query folding »). C’est le cas pour la plupart de « vraies » baes de données, mais pas pour des fichiers plats (.TXT, .XLSX) ou des sources Web.
D’ailleurs, c’est le sens du message sur fond jaune dans l’image ci-dessus : Power BI indique qu’il ne peut pas confirmer si la requête a été « pliée » (query folding).

Les segments hiérarchiques

Encore en préversion (il faudra donc penser à l’activer dans les Options), le segment hiérarchique permet de regrouper des valeurs sur un ou plusieurs niveaux, et de déployer à l’envie chaque groupe. Comme pour un segment classique, il est possible de choisir une ou plusieurs valeurs ; en outre, il est possible de choisir une ou plusieurs valeurs à un ou plusieurs niveaux : une catégorie de produits, ainsi que certains produits d’une autre catégorie.

La mise en place est très simple, puisqu’il suffit de glisser une ou plusieurs dimensions dans la zone Champs de votre segment :

Attention, vous ne pouvez pas faire n’importe quoi : ces champs doivent être liés de manière hiérarchique, dans une même table ou dans une série de tables liées (pensez « propagation du contexte de filtre »).

Le résultat, c’est la possibilité de plier ou déplier les différents niveaux et de faire les choix comme pour un segment non hiérarchique :

Amélioration du ruban

Le ruban continue d’évoluer : les boutons Enregistrer, Annuler et Recommencer font leur réapparition, mais surtout l’ensemble des fonctions du ruban sont maintenant accessibles par le clavier : appuyer sur Alt et laisser vous guider.

Pour accéder aux raccourcis clavier, pressez Alt et Windows :

En définitive, pour actualiser le document, la bonne combinaison, c’est Alt + Windows, puis H et R :

L’article Un choix parmi les nouveautés de février 2020 est apparu en premier sur Daxone.

]]>
https://daxone.fr/un-choix-parmi-les-nouveautes-de-fevrier-2020/feed/ 0
Intégrer un tableau croisé complexe https://daxone.fr/integrer-un-tableau-croise-complexe/?utm_source=rss&utm_medium=rss&utm_campaign=integrer-un-tableau-croise-complexe https://daxone.fr/integrer-un-tableau-croise-complexe/#respond Mon, 10 Feb 2020 10:32:26 +0000 https://daxone.fr/?p=673 Il n’est pas rare d’avoir à intégrer dans Power BI un tableau croisé dont les en-têtes de colonnes ou de lignes présentent une structure complexe, par exemple des champs fusionnés, des totaux ou des en-têtes sur plusieurs lignes. Voici comment s’y prendre pour décroiser ce type de structure.

L’article Intégrer un tableau croisé complexe est apparu en premier sur Daxone.

]]>
Dépivoter un tableau croisé complexe

Le fichier source

Le tableau que nous allons intégrer donne le nombre trimestriel de commandes pour différents clients, de 2018-T1 à 2020-T2 :

Un tableau croisé complexe

Ce type de structure rend impossible toute analyse dans Power BI, il s’agit donc bien entendu de mettre ces données « à plat », et de se débarrasser des éléments superflus : totaux en ligne et en colonne, cellules fusionnées, et en-têtes de colonnes sur plusieurs lignes.

Appelé dans Power Query, l’aperçu du fichier n’est pas encourageant :

C’est le moment de se retrousser les manches et de Transformer les données : direction Power Query !

Première étape, supprimer les totaux

Commençons par supprimer les totaux : ils se trouvent sur la dernière ligne du tableau, et dans la dernière colonne. Dans le premier cas (total en bas d’une colonne), aucun problème, la fonction Supprimer les lignes > Supprimer les lignes du bas > 1 fait le travail.

Pour le total en ligne (donc, le total pour un client), c’est plus compliqué : en effet, deux cas de figure se présentent. Soit la structure est figée (le nombre de colonnes ne change pas), soit elle évolue (dans notre exemple, on peut imaginer une nouvelle version du fichier avec 2020-T3 et 2020-T4). Dans le premier cas, une fois sélectionnée la colonne des totaux, la fonction Supprimer les colonnes fait l’affaire. Mais regardez le code M :

Table.RemoveColumns(#"Dernières lignes supprimées",{"Column25"})

C’est la colonne appelée « Column25 » qui sera supprimée, et ceci quelque soit son contenu. Une fois ajoutés les deux trimestres de 2020, un problème va survenir, et l’actualisation du rapport génèrera une erreur (un trimestre aura disparu, et le total lui, sera à nouveau présent). Cette suppression de la dernière colonne est donc prématurée, et nous devons la réserver pour plus tard.

Étape suivante, les cellules fusionnées

La colonne Type de compte présente des cellules fusionnées, justifiées dans Excel, mais pas du tout dans Power BI. Une fois la colonne 1 sélectionnée, la fonction Remplir vers le bas (onglet Transformer) rétablit facilement la situation :

Le remplissage vers le bas

Étapes suivantes, mettre sur une seule ligne les en-têtes de colonnes

Le but des nombreuses étapes qui suivent est simple : obtenir une seule ligne où se retrouveront les en-têtes de toutes nos données. L’ensemble des transformations se fait sans recours au langage M, et toutes les fonctions sont disponibles dans les rubans Accueil et Transformer de Power Query. Considérez la description ci-dessous comme une « recette » que vous pourrez adapter à toutes les situations.

  • La première ligne de notre fichier Excel a été automatiquement promue en en-tête : or cette ligne n’apporte rien (c’est le canal de distribution), il s’agit donc de la supprimer. Pour ça, je rétrograde l’en-tête (Utiliser les en-têtes comme première ligne), et je supprime cette première ligne
  • Je vais ensuite traiter le cas des cellules fusionnées dans les en-têtes de colonne :  pour cela, j’inverse lignes et colonnes (fonction Transposer la table), et j’applique à nouveau la fonction Remplir vers le bas :

J’en ai profité au passage pour supprimer la dernière ligne, où se trouvera toujours le total en colonne (total par client dans notre exemple)

  • Attention, étape technique : dans la capture d’écran ci-dessus, les transactions figurent en réalité à partir de la colonne 4 (c’est là que se trouve le nombre de commandes). Pour pouvoir à terme traiter les trois premières colonnes comme je le souhaite, j’ai besoin de les fusionner temporairement (je les sélectionne toutes les trois, puis par clic-droit, j’invoque la fonction Fusionner les colonnes en utilisant le séparateur « : » ou n’importe quel autre) :
Une étape intermédiaire nécessaire
  • Je transpose ensuite à nouveau la table, et le résultat, c’est que les en-têtes de colonnes du fichier initial sont maintenant « aplatis », ils se présentent sur une seule ligne :
  • Je vais à présent pouvoir promouvoir cette ligne et en faire l’en-tête de colonne (Utiliser la première ligne pour les en-têtes) :
  • Et il est maintenant possible de « dépivoter » le tableau croisé, en sélectionnant les 4 premières colonnes et en appelant par clic-droit la fonction Dépivoter les autres colonnes (pour tenir compte d’une évolution future du fichier) :
  • Pour finir, il suffit de fractionner la colonne appelée Attribut (clic-droit, Fractionner > Par délimiteur), et renommer les colonnes :

Voilà, vous êtes au bout de vos peines ; ça paraît long mais en réalité c’est assez rapide, et surtout, vos n’aurez plus à le faire : les nouveaux trimestres seront automatiquement intégrés.

En résumé, les étapes appliquées :

L’article Intégrer un tableau croisé complexe est apparu en premier sur Daxone.

]]>
https://daxone.fr/integrer-un-tableau-croise-complexe/feed/ 0
Les paramètres dans Power Query et dans les rapports (4) : les paramètres What If https://daxone.fr/les-parametres-dans-power-query-et-dans-les-rapports-4-les-parametres-what-if/?utm_source=rss&utm_medium=rss&utm_campaign=les-parametres-dans-power-query-et-dans-les-rapports-4-les-parametres-what-if https://daxone.fr/les-parametres-dans-power-query-et-dans-les-rapports-4-les-parametres-what-if/#respond Mon, 03 Feb 2020 06:22:09 +0000 https://daxone.fr/?p=661 Les paramètres What If ont été introduits en 2018 dans Power BI, pour permettre la mise en place des scenarios de variation d’un facteur : comment évoluerait notre indicateur si tel ou tel facteur variait ? Mode d’emploi.

L’article Les paramètres dans Power Query et dans les rapports (4) : les paramètres What If est apparu en premier sur Daxone.

]]>
Les paramètres What If

Scenario

Dans le scenario que nous allons développer, il s’agit d’identifier les semaines pour lesquelles la croissance du CA HT par rapport à la même semaine de l’année précédente, est supérieure à un facteur que nous faisons varier à l’aide du paramètre :

Seules 6 semaines en 2018 ont un CA supérieur de 40% à celui de la même semaine en 2017

Pour ça, nous posons donc un premier segment sur l’année (ici, il s’agit de comparer 2018 à 2017), puis un deuxième segment pour faire varier le taux de croissance : c’est là qu’intervient le paramètre What If.

Création du paramètre What If

La fonction de création du paramètre se trouve sur l’onglet Modélisation :

Ici, le pourcentage varie de 5% en 5% (incrément), de 0 jusqu’à 100%. Notez que Power BI propose d’ajouter automatiquement le segment à la page.

Une fois la fenêtre validée, une table, une colonne et une mesure sont créées. Dans le cadre d’un pourcentage, la colonne doit être formatée en % (question d’affichage), la mesure peut rester sous forme décimale :

Mise en place des mesures

C’est cette mesure Valeur de croissance qui va permettre d’effectuer tout type de calcul. Dans notre scénario, je souhaite pouvoir filtrer une table affichant le HT par semaine, et ne retenir que les semaines pour lesquelles la croissance est supérieur ou égale de x % à celle de l’année précédente, x % étant la valeur choisie à l’aide du segment.

Pour ça, j’ai donc créé une mesure valant 1 ou 0, que je place ensuite dans le volet Filtre, et que je positionne à 1 (donc « vrai ») :

Le titre est obtenu en utilisant la mise en forme conditionnelle (voir billet précédent), à l’aide de la formule :

Modifier le paramètre What If

Il n’est pas possible de retrouver la fenêtre ayant permis la création du paramètre. En revanche, celle-ci n’est qu’une interface graphique pour implémenter une fonction GENERATESERIES. Si vous souhaitez modifier les bornes, ou l’incrément du paramètre, sélectionnez la colonne (croissance dans notre exemple), et modifiez-en la formule :

croissance = GENERATESERIES(0; 1; 0,05)

Ici, 0 est la borne basse, 1 la borne haute, et 0,05 l’incrément.

L’article Les paramètres dans Power Query et dans les rapports (4) : les paramètres What If est apparu en premier sur Daxone.

]]>
https://daxone.fr/les-parametres-dans-power-query-et-dans-les-rapports-4-les-parametres-what-if/feed/ 0
Les paramètres dans Power Query et dans les rapports (3) : les paramètres dans la visualisation, à l’aide des segments https://daxone.fr/les-parametres-dans-power-query-et-dans-les-rapports-3-les-parametres-dans-la-visualisation-a-laide-des-segments/?utm_source=rss&utm_medium=rss&utm_campaign=les-parametres-dans-power-query-et-dans-les-rapports-3-les-parametres-dans-la-visualisation-a-laide-des-segments https://daxone.fr/les-parametres-dans-power-query-et-dans-les-rapports-3-les-parametres-dans-la-visualisation-a-laide-des-segments/#respond Mon, 03 Feb 2020 06:05:49 +0000 https://daxone.fr/?p=648 Les paramètres servent dans Power Query, mais également dans la visualisation elle-même : nous allons le voir à travers un premier exemple où le paramètre consiste à laisser à l’utilisateur le choix de la mesure affichée

L’article Les paramètres dans Power Query et dans les rapports (3) : les paramètres dans la visualisation, à l’aide des segments est apparu en premier sur Daxone.

]]>
Les paramètres-segments

Voici la vue d’ensemble du cycle de travail :

Le paramètre se présente sous la forme d’un segment (2), basé sur une table créée manuellement (1), permettant à l’utilisateur de faire varier le contenu d’une mesure (3) pour obtenir le visuel (4) – dont le titre est généré de manière dynamique (5).

(1)   Les données en entrée

Commençons donc par la table : elle est créée manuellement à l’aide la fonction Entrer des données du ruban Accueil, elle porte un nom (ChoixUser), la colonne elle aussi est nommée (choix), et j’y ai entré trois valeurs, HT, TTC et TVA, puis j’ai chargé la table. Point important : cette table n’est pas liée au reste du modèle.

(2) et (3) Le segment et la mesure

Sur la base de la colonne choix, j’ai créé un segment qui sera affiché sur le rapport final :

Là où « opère la magie », c’est dans la création d’une mesure dont le contenu varie (SWITCH) en fonction du choix de l’utilisateur (SELECTEDVALUE). C’est cette mesure qui sera affichée dans le rapport :

Arrêtons-nous un instant sur la formule :

  • La fonction SWITCH est l’équivalent d’un IF imbriqué, c’est-à-dire permettant de couvrir plusieurs cas de figures. SWITCH simplifie grandement l’écriture d’un tel scénario. Les trois cas possibles dépendent du choix opéré via le segment : HT, TTC ou TVA. Le premier paramètre de SWITCH est la variable à évaluer (ici, la valeur de la colonne choix), puis viennent des « paires » de paramètres : exemple, si l’utilisateur choisit HT, alors la mesure Indicateur prend la valeur SUM(Facts[HT]), et ainsi de suite.
  • La fonction SELECTEDVALUE est la contraction de la formule IF ( HASONEVALUE () ), c’est-à-dire qu’il s’agit de tester si le paramètre passé (ici, ChoixUser[choix]) a une – et une seule – valeur, auquel cas cette valeur est retournée. En cas d’absence de choix, une valeur par défaut pourrait être retournée.
    J’aurai donc pu améliorer ma formule ainsi : SELECTEDVALUE(ChoixUser[choix] ; « HT »), pour être sûr d’afficher une valeur même si l’utilisateur n’a pas fait de choix à l’aide du segment.
  • De même, la fonction SWITCH admet en dernier paramètre une valeur par défaut : ce serait ici redondant avec le point précédent.

N’oubliez pas de formater la mesure ainsi créée.

(4) et (5) Le visuel et le titre dynamique

Pour terminer, le visuel est créé, et affiche la mesure (Indicateur). Puisque l’utilisateur peut en changer le contenu, il est important d’ajouter un titre pour préciser la nature de l’indicateur (ici, HT). Pour ça, j’ai créé une deuxième mesure (nom_mesure_choisie) utilisée pour la mise en forme conditionnelle du titre :

Notez que pour s’assurer que le titre sera toujours affiché, la fonction SELECTEDVALUE propose aussi un choix par défaut, et pour une question de cohérence, le même que celui de la mesure Indicateur.

L’article Les paramètres dans Power Query et dans les rapports (3) : les paramètres dans la visualisation, à l’aide des segments est apparu en premier sur Daxone.

]]>
https://daxone.fr/les-parametres-dans-power-query-et-dans-les-rapports-3-les-parametres-dans-la-visualisation-a-laide-des-segments/feed/ 0
Les nouveautés de Novembre 2019 https://daxone.fr/les-nouveautes-de-novembre-2019/?utm_source=rss&utm_medium=rss&utm_campaign=les-nouveautes-de-novembre-2019 https://daxone.fr/les-nouveautes-de-novembre-2019/#respond Thu, 21 Nov 2019 06:51:17 +0000 https://daxone.fr/?p=565 Un tour de quelques-unes des nouvelles possibilités de la dernière version. J’en ai choisi deux : le nouveau ruban de l’interface et l’arbre de décomposition. Présentation et avis

L’article Les nouveautés de Novembre 2019 est apparu en premier sur Daxone.

]]>
La dernière mouture de Power BI Desktop est là : l’occasion de regarder ce que Microsoft nous a mijoté.
Comme vous le savez certainement, le blog de Power BI propose une présentation très complète des nouveautés : https://powerbi.microsoft.com/fr-fr/blog/ (malgré le /fr-fr, c’est bien de l’anglais …).
Daxone vous propose un regard critique sur certains de ces points.

La nouvelle interface de Power BI

C’était dans l’air depuis quelque temps : un nouveau ruban, qui s’approche de ceux des autres outils de la suite Office. Les avis sont partagés : pour certains, un pas en avant, pour d’autres, un raté.

Notez d’abord que la fonction est encore en preview, il faudra donc penser à l’activer par le biais des options (Menu Fichier > Options et paramètres > Options : dans la section Fonctionnalités en préversion, cocher Ruban mis à jour).

La volonté est très claire : se rapprocher le plus possible du ruban d’Excel, et unifier les produits.

Les bénéfices incluent un comportement dynamique (les fonctions indisponibles ne sont plus seulement grisées, elles sont ôtées du ruban) et l’apparition d’un onglet spécifique en fonction de l’objet sélectionné.

Le ruban Outil de mesure apparaît lorsque je sélectionne une mesure. Il regroupe l’ensemble des fonctions utiles pour manipuler l’objet.

Comme dans Office, il est aussi possible de réduire le ruban à une ligne pour gagner de la place (utilisez pour ça le petit triangle à droite du ruban) :

Enfin le ruban corrige un bug ou deux, notamment celui par lequel la partie supérieure de l’écran se figeait parfois, obligeant à minimiser et relever l’application.

D’après Microsoft, ce n’est que le premier pas : d’autres nouveautés sont prévues, notamment l’interface sombre (dark theme), l’ajout d’une galerie de visuels (comme dans Excel), et l’ajout de fonctionnalités pour paramétrer les visuels.

Notez que l’interface de Power Query, elle, n’a pas bougé.

Un blog destiné à recueillir vos remarques et demandes est disponible : https://powerbi.microsoft.com/fr-fr/blog/updated-ribbon-experience-for-power-bi-desktop/

Mon avis :

Si globalement j’accueille positivement ce nouveau ruban, je regrette l’absence de possibilité de personnalisation (j’aimais bien mes raccourcis Enregistrer, Actualiser, Annuler tout à fait en haut de la fenêtre), et je ne suis pas convaincu non plus par le menu Fichier (notamment pour enregistrer)

Un nouveau visuel : l’arbre de décomposition

Bon, le nom en français a un côté morbide, mais pensez à un arbre de répartition permettant d’analyser une mesure en fonction de dimensions que vous aurez choisies, avec une touche d’IA.

Notez d’abord que la fonction est encore en preview, il faudra donc penser à l’activer par le biais des options (Menu Fichier > Options et paramètres > Options : dans la section Fonctionnalités en préversion, cocher Enable decomposition tree visual).

Mise en place

La mise en place est très simple : sélectionnez une mesure, et un ensemble de dimensions pour l’analyser (l’ordre des dimensions n’est pas important).

Le résultat initial montre la valeur totale de la mesure :

Le signe + permet de décomposer soit en fonction d’une dimension que vous choisissez, soit en laissant l’IA calculer la catégorie qui contribue le plus (Valeur élevée) ou le moins à la valeur de la mesure, parmi toutes les catégories de toutes les dimensions de l’analyse :

Le résultat dans ce cas :

Notez l’icône Ampoule, qui indique (ici et dans d’autres visuels) le recours à l’IA. 

Dans le cas où vous utilisez l’IA, la catégorie qui contribue le plus est recalculée à chaque rafraîchissement.

Pour aller plus loin

Le nouveau visuel, à l’instar de tous les autres, permet le filtrage croisé : en cliquant sur l’une des barres de l’arbre, vous filtrez tous les autres visuels :

Et maintenant en jouant sur le filtrage (j’ai cliqué sur la barre représentant le montant pour T2) :

Les autres visuels (cartes, tableau) sont bien filtrés

Il existe des possibilités de formatage, notamment sur la densité de l’arborescence, la couleur des barres positives et négatives, et la mise à l’échelle de la barre (niveau maximal, ou relatif au nœud parent, ou encore au nœud supérieur – total) :

NB : il y a une option dont je n’ai pas compris le fonctionnement, à savoir le type d’analyse – relatif ou absolue – de l’IA. Si vous avez une idée, laissez un commentaire 😊

******

Il y a bien sûr d’autres fonctionnalités présentent dans cette mise à jour :

  • La mise en forme conditionnelle pour les boutons (possibilité de changer le texte du bouton, sa couleur, …)
  • De nouveaux visuels personnalisés, dont le prometteur Filtre hiérarchique
  • Et du côté de l’accès aux données, un connecteur LinkedIn Sales, et une mise à jour du connecteur Web par l’exemple, qui prend en charge les liens sur la page cible (plus là-dessus dans un futur billet)
  • Enfin dans Power Query, un très alléchant module d’AI permettant l’analyse de texte et d’image, mais réservé aux détenteurs d’un compte Premium…

L’article Les nouveautés de Novembre 2019 est apparu en premier sur Daxone.

]]>
https://daxone.fr/les-nouveautes-de-novembre-2019/feed/ 0
Time Intelligence : les bases fondamentales des calculs cumulatifs https://daxone.fr/time-intelligence-les-bases-fondamentales-des-calculs-cumulatifs/?utm_source=rss&utm_medium=rss&utm_campaign=time-intelligence-les-bases-fondamentales-des-calculs-cumulatifs https://daxone.fr/time-intelligence-les-bases-fondamentales-des-calculs-cumulatifs/#respond Thu, 14 Nov 2019 04:55:55 +0000 https://daxone.fr/?p=554 Power BI offre de nombreuses fonctions de Time Intelligence (« analyse historique », « analyse dans le temps » ?) toutes prêtes à l’emploi. Des « syntax sugars » comme disent les anglophones. Mais encore faut-il comprendre comment elles fonctionnent, et savoir revenir aux fondamentaux de ce type d’analyse. C’est ce que nous allons voir dans ce post, avec les sommes cumulatives et le cas du cumul hebdomadaire, que Power BI n’a pas prévu

L’article Time Intelligence : les bases fondamentales des calculs cumulatifs est apparu en premier sur Daxone.

]]>
Les briques de base de la Time Intelligence

Toute analyse historique est basée sur la modification du contexte de filtre, autrement dit sur les données prises en compte pour le calcul. Les Syntax Sugars font cela implicitement, et c’est la raison pour laquelle leur utilisation peut être complexe (on ne sait pas toujours ce qui se passe sous le capot).
C’est là qu’une bonne connaissance de la fonction CALCULATE et de la manière dont Power BI filtre les données jouent un rôle capital. Associée la FILTER, à MAX et aux opérateurs > et <, CALCULATE permet de faire à peu près tout.


Dans le cadre d’un calcul cumulatif, l’une des clés est la comparaison

Datum[Date] <= MAX(Datum[Date])


MAX([Date]) signifie ici la date courante (ce qui n’est pas nécessairement intuitif), c’est celle du contexte de filtre initial (ou naturel) : dans une table affichant les revenus quotidiens, c’est la ligne où vous vous trouvez (mais ça marcherait tout aussi bien avec les années, les trimestres, les mois etc.).

La syntaxe

FILTER (ALL(Datum) ; Datum[Date] <= MAX (Datum[Date]))

revient donc à générer une table contenant toutes les dates jusqu’à la date courante.

Et par conséquent

CALCULATE([Montant] ;
            FILTER(ALL(Datum);
                    Datum[Date] <= MAX(Datum[Date])
            )
)

permet de calculer, pour chaque ligne de la table, le montant cumulé depuis le début (première ligne de la table).

A partir de là, tout devient possible : imaginons que vous ayez lancé une campagne de promotion le 2 mai et que vous souhaitiez connaître le revenu cumulé depuis :

CALCULATE([Montant] ;
            FILTER(ALL(Datum);
              	Datum[Date] <= MAX(Datum[Date]) &&
		Datum[Date] >= DATE(2019,5,2)
            )
)


Le cumul mensuel, lui, s’écrit

CALCULATE([Montant] ;
            FILTER(ALL(Datum);
                    Datum[Date] <= MAX(Datum[Date]) &&
                    MONTH(Datum[Date]) = MONTH(MAX(Datum[Date]))
            )
)

C’est aussi simple que ça !


Nota bene : il est souvent utile, lors de la mise en place de ces formules, de créer une variable pour la date max :

VAR DDate = Max(Datum[Date])
RETURN


Dans ce cas, le CALCULATE peut s’écrire simplement :

CALCULATE([Montant] ;
            Datum[Date] <= DDate
)


Mais vous ne pouvez pas utiliser la fonction MAX directement dans le CALCULATE :

CALCULATE([Montant] ;
            Datum[Date] <= Max(Datum[Date])
)

génère une erreur « Une fonction MAX a été utilisée dans une expression TRUE/FALSE utilisée en tant qu’expression de filtre de table ».


Les Syntax Sugars


Pour ce qui concerne les cumuls, il existe un ensemble de fonctions prêtes à l’emploi. Elles sont le plus souvent simples à utiliser, et vous en trouverez des descriptions très facilement (https://docs.microsoft.com/fr-fr/dax/time-intelligence-functions-dax par exemple, ou encore https://dax.guide/).


DATESYTD et ses variantes DATESQTD et DATESMTD remplacent la partie filtre de CALCULATE, et retournent respectivement une liste de dates depuis le début de l’année / du trimestre / du mois jusqu’à la date courante :

CALCULATE(
    [Montant];
    DATESYTD(Datum[Date])
)


TOTALYTD (et TOTALQTD, TOTALMTD) simplifient encore la syntaxe (plus besoin du CALCULATE) :

TOTALYTD([Montant];
            Datum[Date])

affiche ainsi un cumul pour chaque année (idem pour les trimestres et les mois respectivement).


Notez que pour être sûr que les fonctions Time Intelligence fonctionnent correctement, il est impératif de disposer d’une table du temps.


Le cas non prévu du cumul hebdomadaire


Les Syntax Sugars sont pratiques, mais ne couvrent pas tous les cas de figure – tout ce qui sort de l’ordinaire impose de repartir de la syntaxe fondamentale à base de CALCULATE et de filtrage.

Or un type d’analyse courant n’est pas proposé par Power BI : il s’agit du cumul hebdomadaire. Voyons sa mise en place dans un exemple détaillé.


L’objectif ici est de réaliser le tableau ci-dessous, permettant de suivre le cumul hebdomadaire des montants, et de calculer le pourcentage de progression du montant cumulé par rapport au total de la semaine :


La donnée critique ici, c’est le champ Année_Semaine_ISO, dont nous avons vu la mise en place dans le billet consacré à la semaine (ICI). En effet, pour obtenir le cumul hebdomadaire, le filtre ne devra retenir que les dates inférieures ou égales à la date courante, partageant la même semaine ISO. A partir de là, le calcul est très simple :

    CALCULATE(
        [Montant];
        FILTER(ALL(Datum);
                Datum[Année_Sem_ISO] = AnSemISO_DDate &&
                Datum[Date] <= DDate
        )
    )


DDate et AnSemISO_DDate sont définies dans des variables, en utilisant les règles de calcul précisées dans le billet évoqué plus haut, consacré à la semaine. Voici donc le script en intégralité :


De même, pour la progression hebdomadaire, il suffit de diviser le cumul par le total hebdomadaire. Ce dernier est calculé à l’aide d’un filtre retenant toutes les dates partageant la même semaine que la date en cours :

L’article Time Intelligence : les bases fondamentales des calculs cumulatifs est apparu en premier sur Daxone.

]]>
https://daxone.fr/time-intelligence-les-bases-fondamentales-des-calculs-cumulatifs/feed/ 0
La création de la colonne Semaine : quelle norme ? https://daxone.fr/la-creation-de-la-colonne-semaine-quelle-norme/?utm_source=rss&utm_medium=rss&utm_campaign=la-creation-de-la-colonne-semaine-quelle-norme https://daxone.fr/la-creation-de-la-colonne-semaine-quelle-norme/#respond Wed, 13 Nov 2019 05:06:10 +0000 https://daxone.fr/?p=525 Le calcul de la semaine s’avère plus complexe qu’il n’y paraît : deux normes co-existent, et celle que nous utilisons en Europe (considérée comme universelle) – la norme ISO 8601 – n’est pas celle que Power BI utilise par défaut. Détails, calculs et une pépite non-documentée dans le billet.

L’article La création de la colonne Semaine : quelle norme ? est apparu en premier sur Daxone.

]]>
Les normes de calcul de la semaine

Deux systèmes de calcul du numéro de semaine co-existent (dans Power BI ou ailleurs) : pour le calendrier grégorien, la semaine 1 commence le premier janvier, et se termine le premier dimanche ou le premier lundi de l’année (respectivement WEEKNUM([Date] ;1) ou WEEKNUM([Date] ;2) en DAX). C’est le système utilisé aux USA notamment.

L’autre système, largement utilisé en Europe, « est un système de calendrier faisant partie de la norme d’horodatage ISO 8601. Le système est principalement utilisé par les gouvernements et entreprises pour baser également les années comptables et fiscales et la planification de projets à cycles hebdomadaires de travail, ainsi que pour le paiement des salaires ou des loyers (quand ceux-ci sont versés hebdomadairement) » (Wikipédia). Dans cette norme, la première semaine de l’année est celle contenant 4 jours au moins. D’où l’existence d’un décalage entre les deux calendriers : dans le premier, une semaine 53, d’une durée comprise entre 1 et 6 jours, va s’intercaler en fin d’année (le 31 décembre 2018 fait donc partie de la semaine 201853) ; dans le second, la semaine 1 peut débuter dès les derniers jours de l’année précédente (le 31 décembre 2018 fait donc partie de la semaine 201901).

Une différence de numérotation

Le calcul de la semaine en norme ISO 8601 : un paramètre caché

C’est, je crois, Gerhard Brueckl, dans son blog, qui signale dès 2012 l’existence d’un paramètre caché pour la fonction WEEKNUM (http://blog.gbrueckl.at/2012/04/iso-8601-week-in-dax/) : en effet, WEEKNUM([Date] ;21) renvoie directement le numéro de semaine dans la norme ISO.

Par convention, cette semaine est notée W suivi du numéro de semaine :

"W" & FORMAT(WEEKNUM([Date];21);"00")

Mais comme le montre l’image ci-dessus, l’année ISO peut également varier : le 31 décembre 2018 appartient à 2018-S53 et à 2019-W01. Gerhard Brueckl propose donc le calcul suivant pour la colonne Année_ ISO :

Que j’adapte en introduisant des variables (pour optimiser le script) et en complétant avec le numéro de semaine (selon la norme officielle) :

Cette colonne va s’avérer particulièrement importante pour le calcul des cumuls hebdomadaires, comme nous le verrons dans le prochain billet.

Un nouveau script pour la table Datum

Je vous propose donc un nouveau script pour la table, que vous pouvez afficher ICI.

La table filtrée sur 2018 et 2019 semaine W01 et W52

L’article La création de la colonne Semaine : quelle norme ? est apparu en premier sur Daxone.

]]>
https://daxone.fr/la-creation-de-la-colonne-semaine-quelle-norme/feed/ 0
Le choix des couleurs pour le rapport https://daxone.fr/le-choix-des-couleurs-pour-le-rapport/?utm_source=rss&utm_medium=rss&utm_campaign=le-choix-des-couleurs-pour-le-rapport https://daxone.fr/le-choix-des-couleurs-pour-le-rapport/#respond Wed, 06 Nov 2019 10:54:53 +0000 https://daxone.fr/?p=505 Un petit pas de côté dans cet article, où il ne s’agit ni de M ni de Dax, mais plus simplement de ce qui va embellir et personnaliser votre rapport : les couleurs. Le choix judicieux de la palette de couleurs est un aspect important de la « composition visuelle » de votre rapport, et participe de l’utilisation qui en sera faite, et du plaisir à le lire

L’article Le choix des couleurs pour le rapport est apparu en premier sur Daxone.

]]>
Les couleurs vous serviront à harmoniser l’apparence de vos rapports, à le rendre donc plus agréable à consulter, mais aident aussi à reposer l’œil : quand vous passez votre journée à consulter des rapports, autant que ça ne soit pas une source de stress oculaire … Et (accessoirement) c’est aussi comme ça que vous pourrez implémenter une charte graphique, par exemple en vous inspirant d’un logo.

Voyons ça de plus près …

Les couleurs

Dans mon livre (aux éditions ENI – https://www.editions-eni.fr/livre/power-bi-desktop-de-l-analyse-de-donnees-au-reporting-9782409019906), j’évoque en détail les règles de composition – en deux mots, rester simple ! C’est vrai en particulier des couleurs.
Marco et Alberto, de SQLBI, proposent des rapports quasi-monochromes, où la touche de couleur n’est justifiée que si elle a du sens (un point rouge pour indiquer une valeur minimale ou aberrante).

Sans aller jusque-là, il est néanmoins important que l’équilibre des couleurs soit agréable, et reflète l’identité du service ou de l’entreprise, ou la vôtre, tout simplement.

Mais comment choisir les couleurs, et comment les utiliser dans Power BI ?

Les choix des couleurs

Le Net propose de nombreux outils pour créer des palettes équilibrées, ou retrouver un code couleur à partir d’une image ou d’un logo. Et de son côté, Power BI permet de personnaliser les couleurs, en utilisant le code HEX, mais aussi d’importer un thème de couleurs.

Afin d’illustrer ces points, je vous propose un rapport de départ, basé sur les couleurs par défaut de Power BI :

Imaginons maintenant que nous souhaitions améliorer ces couleurs, en nous basant sur un logo (celui du site daxone.fr).

Récupérer les codes couleurs

Un premier site nous permet de rapidement trouver le code des couleurs : https://imagecolorpicker.com/fr. Il suffit d’y envoyer l’image, puis de cliquer sur les différentes couleurs pour récupérer le code correspondant (il est précédé d’un #, et apparaît surligné en blanc sur l’image ci-dessous) :

Dans cet exemple, le code à récupérer est FED020.

Il s’agit ensuite d’utiliser la couleur personnalisée dans Power BI :

Au fur et à mesure que vous importez les couleurs, la palette se précise. Rapidement, vous disposez de vos 2 ou 3 couleurs de base (+ le noir).

Dans notre exemple, voici le résultat, où l’on « voit » bien mieux l’identité visuelle :

Il existe bien d’autres sites, je vous recommande en particulier celui d’Adobe (https://color.adobe.com/fr/create), qui permet de créer de nombreuses palettes, soit à partir d’un code, soit à partir d’une image :

Utiliser et partager un thème de couleur

Vous pouvez pousser cette logique un peu plus loin, et souhaiter par exemple utiliser le même thème dans plusieurs rapports, voire partager un thème avec d’autres personnes.

Les thèmes de couleurs dans Power BI sont basés sur des fichiers JSON. Or il est très simple de changer de thème, et d’en importer de nouveaux (onglet Accueil) :

La question est donc de créer le thème. C’est là que les choses se complique un peu. Peut-être disposez-vous d’une équipe de graphistes, en mesure de coder un fichier JSON (description complète sur le site de Microsoft, en suivant le lien Comment créer un thème sur l’image ci-dessus).

Mais il existe une alternative : le Report Theme Generator (https://powerbi.tips/tools/report-theme-generator-v3/ ). Cet outil graphique permet de créer des thèmes très complets, et de générer le fichier JSON, sans avoir besoin de coder.

En voici un exemple simple. Il suffit d’entrer le code dans la section Selected Color en haut à gauche, et de l’ajouter avec la fonction Add Selected Color en bas de l’image, puis de télécharger le thème :

Une fois le fichier JSON sur votre poste, utilisez la fonction Importer un thème de Power BI pour retrouver la palette de couleurs dans votre rapport :

L’article Le choix des couleurs pour le rapport est apparu en premier sur Daxone.

]]>
https://daxone.fr/le-choix-des-couleurs-pour-le-rapport/feed/ 0
Les paramètres dans Power Query et dans les rapports (2) https://daxone.fr/les-parametres-dans-power-query-et-dans-les-rapports-2/?utm_source=rss&utm_medium=rss&utm_campaign=les-parametres-dans-power-query-et-dans-les-rapports-2 https://daxone.fr/les-parametres-dans-power-query-et-dans-les-rapports-2/#respond Sat, 02 Nov 2019 05:34:00 +0000 https://daxone.fr/?p=453 Suite du dossier consacré aux paramètres : cette fois-ci, j’évoque les paramètres-filtres et les autres modifications du code de la requête. Les paramètres-filtres nous donneront l’occasion de voir la génération d’une liste de valeurs pour le paramètre

L’article Les paramètres dans Power Query et dans les rapports (2) est apparu en premier sur Daxone.

]]>

Les paramètres dans Power Query et dans les rapports (2)

Les paramètres Filtre et Tri et les listes de valeurs

Les paramètres-filtres

Il faut le rappeler ici : l’effet d’un paramètre se manifeste au moment de l’envoi de la requête à la source de données.

Un paramètre-filtre de requête est donc très différent d’un filtre de rapport (slicer), puisque le paramètre va réduire le volume de données.

C’est par conséquent particulièrement utile lorsqu’il s’agit de maîtriser la masse de données ramenée au moment de l’actualisation du rapport. Associé à un modèle de document (PBIT), le paramètre-filtre est un outil particulièrement efficace pour encadrer la requête envoyée par un utilisateur.

Dans une moindre mesure, c’est un outil qui facilite la modification du périmètre de la requête (basculer rapidement d’un périmètre à un autre, sans avoir besoin de passer par Power Query).

Le point de départ, à nouveau, c’est créer une première requête sur la source : dans cet exemple, un fichier Excel de relevés de la qualité de l’air, fourni par l’OMS. Le fichier propose des relevés des niveaux de particules PM10 par Région, Ville et Année, entre autres. Il fait 12000 lignes, et je veux m’assurer qu’un nombre restreint de lignes sera extrait.

Je vais créer un paramètre-filtre pour l’année, un autre pour la région. La subtilité ici, c’est que je souhaite que ces paramètres s’appuient sur une liste de valeurs générée automatiquement à partir des données du fichier.

Rappelez-vous : lors de la création d’un paramètre, un choix s’offre, de permettre toutes les valeurs, de les limiter à une liste saisie manuellement, ou d’utiliser une requête. C’est cette troisième option qui va nous intéresser.

Regardons-en dans un premier temps la démarche générale :

  1. Il s’agit d’abord de créer une nouvelle requête basée sur la même source (utilisez pour ça le raccourci Sources récentes)
  2. Puis ne garder qu’une colonne (Supprimer les autres colonnes)
  3. Supprimer les doublons
  4. En enfin, convertir cette requête en liste

J’effectue aussi cette opération pour les années, pour me retrouver avec deux listes.

Passons maintenant aux paramètres. Leur création ne pose aucune difficulté, puisque les listes sont disponibles avec l’option … Requête :

A ce stade, j’ai donc 5 entrées dans la zone requête de Power Query :

  • La liste Années
  • Le paramètre Année
  • La liste Régions
  • Le paramètre Région
  • La requête utile, celle dont je me servirai dans le rapport

C’est sur cette dernière que je vais maintenant appliquer un filtre basé sur chacun des paramètres.

Attention : à ce jour, il n’est pas possible de créer simplement des « listes en cascade », c’est-à-dire des listes dont les valeurs dépendent d’un autre paramètre (ex., une liste de villes générée en fonction du pays choisi préalablement). Par ailleurs, il n’est pas possible de choisir plusieurs valeurs lors de l’appel du paramètre. Ces deux points sont prévus dans une version prochaine de Power BI.

Lors de l’application d’un filtre textuel « Egal à » sur la colonne Région, je vais pouvoir invoquer le paramètre et le choisir dans la liste déroulante (il est d’ailleurs possible de créer le paramètre à la volée) :

Cette opération est répétée pour les années.

Notez le script M résultant :

 = Table.SelectRows(#"Lignes filtrées", each [Year] = Année)
et
= Table.SelectRows(#"Colonnes supprimées", each [Region] = Région)

 Remarque : avant de passer au rapport lui-même, notez qu’il est inutile de charger les listes Année et Région !

Reste à appliquer et fermer Power Query. Le résultat de la requête tient compte des deux valeurs actuelles définies à la création des paramètres.

Pour exécuter la requête sur un autre périmètre (c’est là que la démarche pêche un peu, mais nous verrons comment améliorer ce point avec les modèles de document), il faut utiliser la fonction Modifier les requêtes > Modifier les paramètres, et choisir dans la liste déroulante.

Attention à bien penser à appliquer les modifications (à relancer la requête) :

Si vous souhaitez afficher sur le rapport les choix de région et d’année, la formule suivante suffit :

                AnnéeRégion = MAX(PM_10[Year]) & " / " & MAX(PM_10[Region])

 

Les paramètres modificateurs du script de la requête

Les paramètres peuvent également servir à rendre dynamique des portions du script M de la requête.

Dans le scénario que je vous propose, je souhaite extraire le top X des villes en termes de moyenne annuelle de particules PM10 (colonne Annual mean du tableau) pour une région et une année données.

Ici, top X signifie que je laisse à l’utilisateur le soin d’extraire 5, 10 ou 25 villes (je pourrais bien entendu laisser un choix totalement ouvert, voire facultatif).

Sur la base du fichier précédent, je vais donc créer un nouveau paramètre Top X :

Je vais ensuite, en m’appuyant sur l’UI, trier les lignes de la table par ordre décroissant de moyenne annuelle. Enfin, toujours à l’aide de l’UI (fonction Conserver les lignes > Conserver les premières lignes), je vais appeler et choisir dans la liste déroulante le paramètre Top X :

Notez le code M généré :

      = Table.FirstN(#"Lignes triées",#"Top X")

(Ici, l’appel du paramètre est encadré de doubles guillemets et précédé d’un dièse : c’est parce son nom contient un espace).

***

En définitive, si j’actualise le rapport, voici la fenêtre des paramètres et le résultat :

Ceci est un exemple parmi beaucoup d’autres d’utilisation des paramètres pour modifier le script.

Dans le prochain article, j’évoquerai les modèles de document PBIT et leur rapport avec les paramètres et les fonctions dans Power Query

L’article Les paramètres dans Power Query et dans les rapports (2) est apparu en premier sur Daxone.

]]>
https://daxone.fr/les-parametres-dans-power-query-et-dans-les-rapports-2/feed/ 0
Les paramètres dans Power Query et dans les rapports (1) https://daxone.fr/les-parametres-dans-power-query-et-dans-les-rapports-1/?utm_source=rss&utm_medium=rss&utm_campaign=les-parametres-dans-power-query-et-dans-les-rapports-1 https://daxone.fr/les-parametres-dans-power-query-et-dans-les-rapports-1/#respond Wed, 30 Oct 2019 04:43:49 +0000 https://daxone.fr/?p=429 Modifier simplement la requête Power Query, changer facilement de source, de filtre, mais aussi proposer à l’utilisateur de faire varier les calculs des mesures, et même la structure d’un visuel, - c’est tout cela que permettent de réaliser les paramètres. Tour d’horizon en trois parties.

L’article Les paramètres dans Power Query et dans les rapports (1) est apparu en premier sur Daxone.

]]>

Les paramètres dans Power Query et dans les rapports (1)

Le paramètre Source de données, création d’un paramètre

Les paramètres offrent la possibilité de modifier le périmètre de la requête Power Query, de passer par exemple d’une base de données de DEV à une base de PROD, d’un fichier à un autre, ou encore de modifier, de manière simple, le filtre appliqué à une ou plusieurs colonnes (changer d’année, de produit, etc.).

Dans la première partie de ce dossier, j’évoquerai tout ce qui touche aux paramètres de Power Query, et leur création, ainsi que les limites de la solution.

Associé à un modèle de document (template .pbit), ils permettent de maîtriser la manière dont l’utilisateur va interroger la source de données, tout en lui laissant une certaine dose de liberté quant au périmètre de la requête. Et ce dans le but principal de limiter la taille du résultat.

Enfin ils peuvent également servir de base à la création d’une fonction : nous en verrons un exemple facilitant la création de table.

Ces notions seront abordées dans une deuxième partie.

Mais le terme « paramètre » s’entend aussi au niveau du rapport, avec les scénarios What If – « que se passerait-il si tel ou tel « paramètre » évoluait ? » -, et j’étendrai encore cette notion, en évoquant le « paramètre » permettant à l’utilisateur de choisir l’indicateur analysé (CA hors-taxe ? Ou TTC ? Ou peut-être encore la TVA ?).

Ces points seront traités dans la troisième partie du dossier.

L’utilisation la plus connue des paramètres de Power Query est la possibilité de changer rapidement de source de données : c’est très utile lorsqu’il s’agit de passer facilement d’un environnement de développement (test) à un environnement de production ; d’une base de données historisée à une base à l’instant t ; ou encore d’un fichier stocké en local à un fichier stocké sur le réseau. A condition, bien entendu, que les deux sources aient la même structure, ou du moins que les colonnes utilisées pour générer les visuels soient présentes et organisées de même manière dans les deux sources.

Un peu d’UI et une pincée de M

Il suffira pour créer ce paramètre (dans Power Query, Accueil > Gérer les paramètres > Nouveau paramètre) de renseigner manuellement les noms des instances (dans le cas d’une base) et de créer un second paramètre pour les noms des bases elles-mêmes (voir l’image ci-dessus).

Dans le cas d’un paramètre pour changer de fichier source, c’est plus simple encore.  Une fois le document Power BI créé (dans mon cas, il est initialement basé sur un des deux fichiers source, Facts -2019.xlsx), il suffit de renseigner le paramètre avec le ou les chemins d’accès et le nom des fichiers :

Notez que le paramètre peut être facultatif et qu’il est typé (texte, numérique, date pour l’essentiel). Les valeurs suggérées sont soit libres (« Toutes les valeurs »), soit basées sur une liste saisie manuellement (« Liste de valeurs »), soit basées sur une liste générée à partir d’une requête (nous en verrons un exemple plus loin). Enfin une valeur par défaut et une valeur actuelle peuvent être demandées.

Une pincée de M

Attention : une fois le paramètre créé, il faut ouvrir l’éditeur avancé de la table initiale (Facts -2019.xlsx), pour modifier la ligne Source du script M :

Source = Excel.Workbook(File.Contents("C:\Users\andre\Desktop\Facts - 2019.xlsx"), null, true)

devient

Source = Excel.Workbook(File.Contents(ChoixFichier), null, true)

ChoixFichier est le nom du paramètre.

Pour SQL Server, le script modifié ressemblera à ça :

Source  = Sql.Database(SqlSrvInstance, Database, [Query="SELECT…” (etc.)

SqlSrvInstance, Database sont les deux paramètres.

 

Une fois la requête exécutée, pour passer d’un fichier à un autre, il suffit (…) d’ouvrir le menu Modifier les requêtes > Modifier les paramètres, et d’utiliser le menu déroulant pour choisir le fichier :

Et d’appliquer les modifications (bandeau jaune en haut de la page).

(Nous verrons dans la suite du dossier qu’il existe d’autres possibilités d’invoquer le paramètre).

Le petit plus : et si nous décidions de créer un titre dynamique dans le rapport en affichant le nom de la source et la date d‘actualisation ? Une démarche possible consiste, d’abord dans Power Query :

  • A référencer le paramètre (clic droit > Référence)
  • A convertir le résultat en table (onglet Transformer > Vers la table)
  • A renommer et typer la colonne
  • Et à fermer et appliquer

Dans le rapport, créer une mesure

Source_actualisation = MAX(ChoixSource[source]) & " - "& TODAY()

 Et le résultat (j’utilise le visual Carte):

Dans la suite de ce dossier, nous verrons la création de deux autres types de paramètres (filtre et tri), la création de modèles de document et leur lien avec les paramètres, et la création de fonction.

L’article Les paramètres dans Power Query et dans les rapports (1) est apparu en premier sur Daxone.

]]>
https://daxone.fr/les-parametres-dans-power-query-et-dans-les-rapports-1/feed/ 0