[Jonathan]

[Jonathan]

Bonjour,

• C’est quoi le message d’erreur ?
• Quelle version est installée sur votre poste ? Version installée avec un .exe ou via le store Microsoft ?
• Est-ce que le refresh fonctionne dans le service Power BI ?

• Cette réponse a été modifiée Il y a 3 mois par  Jonathan.

[Jonathan]

Bonjour Florian,

Ce qui m’inquiète le plus dans votre question c’est “J’ai donc créé mes différentes mesures pour avoir mon CA par catégorie” parce qu’il n’y a qu’une seule mesure à faire, le Total CA.

Le reste, c’est de la modélisation, pas des calculs DAX. En effet, il vous faut une table calendrier (indispensable dans tous vos projets BI), une table des catégories et une table de faits. Une simple relation de date à date des faits et de catégorie à catégorie des faits fera le job et ventilera le CA par dates et par catégories.

Pour le comparatif N vs N-1, utilisez la fonction SAMEPRIODLASTYEAR elle permettra de comparer des choses comparables. Par exemple, si vous choisissez le premier semestre 2024 dans la table calendrier, ça comparera tout seul avec le 1er semestre 2023 (c’est vraiment de date à date).

Vous devriez donc avoir 2 mesures :

• Total CA = SUM(Faits[Montant])
• Total CA N-1 = CALCULATE([Total CA], SAMEPERIODLASTYEAR(Calendrier[Date]))

Pour la table calendrier, plusieurs solutions, DAX, M, SQL, fichier Excel, Dataflow…

Bon courage, à plus tard sur le forum

[Jonathan]

Ce sera donc plus simple 👌

[Jonathan]

Oui et non, dans mon exemple, c’est un premier appel qui permet d’obtenir les infos de la pagination, qu’à priori vous n’avez pas.

[Jonathan]

Bonjour Franck,

• Les tables de faits sont celles dans lesquelles on cherche à compter quelque chose (nombre de lignes, somme d’une colonne, moyenne etc…),
  • Une bonne table de faits ne doit, en théorie, contenir que des dates, des codes et des montants,
  • Toutes les choses qu’on utilisera pas dans la dataviz (donc à masquer dans la vue modèle),
    • A la place des dates, on utilisera la table des dates,
    • A la place des codes, on utilisera les dimensions,
    • A la place des montant, on utilisera des mesures,
• Les dimensions sont les axes d’analyse (ou référentiels) qui vont permettre d’analyser ces faits :
  • Le temps (table calendrier indispensable pour gérer le DAX facilement et pour faire votre analyse à la maille souhaitée),
  • Une table des produits par exemple,
  • Une table clients, etc…

Une bonne modélisation pour Power BI, c’est une modélisation en étoile, précisément, un modèle en étoile dénormalisé (c’est-à-dire que c’est à vous de mettre tous les attributs relatifs à une même dimension dans la même dimension).

• On évitera de faire une table Catégorie de produits, puis sous-catégorie de produits, puis produits.
• Si possible, on essaie de n’avoir que des relations de 1 à plusieurs entre les dimensions et les faits,
• On évite le bidirectionnel (qui crée de l’ambiguïté dans le modèle, le DAX vous permettra de gérer cela à la place),
• On ne fait jamais communiquer deux tables de faits entre elles (puisqu’on aura nécessairement du plusieurs à plusieurs),
• On les fait communiquer par un axe commun (par exemple la date, de date vers table de faits 1 puis de date vers table de faits 2),
• Si les faits n’ont pas la même granularité (factures à la maille journalière et budgets à la maille mensuelle par exemple), on les sépare dans deux tables de faits,

Ce sera déjà un bon début ! Un bon modèle, c’est du DAX facile et un modèle facilement requêtable par les utilisateurs finaux. Pensez à masquer tout ce qui est technique et qui ne les concerne pas, tables de faits, mesures intermédiaires, clés techniques etc… et pensez à documenter votre modèle, les tables, les colonnes, les mesures et même la partie Power Query.

Pour les ressources, une bonne formation sera toujours la meilleure option à mon sens car vous bénéficierez de l’expérience des formateurs et non pas seulement de la théorie des bouquins. J’ai personnellement démarré seul, avec des bouquins et des certifications en tout genre, j’ai également fait une formation en présentiel avec un formateur pas du tout à la hauteur… et jusque là, tout était ultra compliqué je trouve. Puis un jour j’ai eu la chance de tomber sur un excellent formateur, et là, tout est devenu bien plus clair !

Bon courage pour la suite et à bientôt sur le forum.

P.S. : la référence pour la modélisation, c’est Kimball 👍

[Jonathan]

Parfait, j’espère que vous arriverez à finaliser votre requête. Je pense que si l’API ne retourne rien comme info intéressante, il faudra faire une fonction récursive qui s’appelle elle-même jusqu’au moment où le résultat est vide. J’ai préparé un exemple pour plus tard 👌

[Jonathan]

Parfait 👍bonne continuation dans votre projet

[Jonathan]

C’est franchement laborieux pour formater son texte ici 😂

[Jonathan]

Bonjour Samuel,

Quand vous faites cet appel API de manière unitaire, par exemple pour la page 1, l’API ne vous renvoie pas d’information concernant le nombre de pages au total c’est bien ça ?

Assez souvent les APIs renvoient des informations, soit sur le nombre de pages à appeler, soit sur le nombre d’éléments total et le nombre d’éléments par page (à nous de calculer le nombre d’appels à faire).

Si ce n’est pas le cas, vous pouvez générer par exemple une liste de 1 à 10 pour tester = {1..10} puis vous appliquez votre fonction sur cette liste (que vous aurez au préalable convertie en table).

Vous verrez déjà si cela fonctionne et peut-être verrez-vous des tables vides ou des erreurs à la suite de cet appel. Vous pourrez gérer ça assez facilement côté Power Query je pense.

Je vous donne un exemple d’appel avec de la pagination :

let

method = “Document.getList”,

param = “””doctype””: “”invoice”””,

Source = FactAPICallInfo(method, APINbPerPage, “1”, param),

infos = Source[infos],

nbpages = infos[nbpages],

List_Pages= {1..nbpages},

Converted_to_Table = Table.FromList(List_Pages, Splitter.SplitByNothing(), null, null, ExtraValues.Error),

Renamed_Columns = Table.RenameColumns(Converted_to_Table”, {{“Column1”, “NumPage”}}),

Changed_Type = Table.TransformColumnTypes(Renamed_Columns, {{“NumPage”, type text}}),

Added_Custom = Table.AddColumn(Changed_Type, “Custom”, each FactGetAPIData(method, [NumPage], param))

in

Added_Custom

Au début, j’appelle l’API pour connaître le nombre de pages. Ensuite je crée une liste de 1 au nombre total puis j’appelle ma fonction X fois.

Donc je récapitule : vous gardez votre fonction en l’état. Vous créez pour le moment une liste de 1 à mettons 10 (Dans une nouvelle requête). Vous convertissez cette liste en table (vous changez le type en texte) puis vous appelez votre fonction sur cette colonne.

Ensuite si ça marche, vous agrandissez le 10 jusqu’à trouver des nuls pour voir comment gérer les “problèmes”.

• Cette réponse a été modifiée Il y a 3 mois, 1 semaine par  Jonathan.
• Cette réponse a été modifiée Il y a 3 mois, 1 semaine par  Jonathan.
• Cette réponse a été modifiée Il y a 3 mois, 1 semaine par  Jonathan.

[Jonathan]

Bonjour Samuel,

Quand vous faites cet appel API de manière unitaire, par exemple pour la page 1, l’API ne vous renvoie pas d’information concernant le nombre de pages au total c’est bien ça ?

Assez souvent les APIs renvoient des informations, soit sur le nombre de pages à appeler, soit sur le nombre d’éléments total et le nombre d’éléments par page (à nous de calculer le nombre d’appels à faire).

Si ce n’est pas le cas, vous pouvez générer par exemple une liste de 1 à 10 pour tester = {1..10} puis vous appliquez votre fonction sur cette liste (que vous aurez au préalable convertie en table).

Vous verrez déjà si cela fonctionne et peut-être verrez-vous des tables vides ou des erreurs à la suite de cet appel. Vous pourrez gérer ça assez facilement côté Power Query je pense.

Je vous donne un exemple d’appel avec de la pagination :

<div>
<div>let</div>
<div> method = “Document.getList”,</div>
<div> param = “””doctype””: “”invoice”””,</div>
<div> Source = FactAPICallInfo(method, APINbPerPage, “1”, param),</div>
<div> infos = Source[infos],</div>
<div> nbpages = infos[nbpages],</div>
<div> List_Pages= {1..nbpages},</div>
<div> Converted_to_Table = Table.FromList(List_Pages, Splitter.SplitByNothing(), null, null, ExtraValues.Error),</div>
<div> Renamed_Columns = Table.RenameColumns(Converted_to_Table”, {{“Column1”, “NumPage”}}),</div>
<div> Changed_Type = Table.TransformColumnTypes(Renamed_Columns, {{“NumPage”, type text}}),</div>
<div> Added_Custom = Table.AddColumn(Changed_Type, “Custom”, each FactGetAPIData(method, [NumPage], param))</div>
<div>in</div>
<div>Added_Custom</div>
<div> </div>
<div>Au début, j’appelle l’API pour connaître le nombre de pages. Ensuite je crée une liste de 1 au nombre total puis j’appelle ma fonction X fois. </div>
<div> </div>
<div>Donc je récapitule : vous gardez votre fonction en l’état. Vous créez pour le moment une liste de 1 à mettons 10 (Dans une nouvelle requête). Vous convertissez cette liste en table (vous changez le type en texte) puis vous appelez votre votre fonction sur cette colonne.</div>
<div> </div>
<div>Ensuite si ça marche, vous agrandissez le 10 jusqu’à trouver des nulls pour voir comment gérer les “problèmes”.</div>
</div>

[Jonathan]

Bonjour Franck,

La taille du point est fonction d’une mesure donc en faisant une mesure qui renvoie une plus grande valeur, vous pourrez augmenter la taille du point. Mais il y a un gros “Mais”, ça fausse la lecture du graphique, pourquoi faire ça ? Je ne vois pas bien le cas d’usage en réalité.

Pour la deuxième partie de la question, on ne peut pas gérer l’ordre mais on peut gérer la transparence des points. On peut donc imaginer les points non essentiels en légère transparence et le point principal sans aucune transparence.

Pour gérer la transparence, vous pouvez ajouter deux chiffres à votre code HEX, 50 veut dire 50% d’opacité, 10, 10% d’opacité etc…

Bon courage pour la suite de votre projet, n’hésitez pas à partager un exemple de ce que vous souhaiteriez obtenir.

[Jonathan]

Bonjour Laurence,

Voici 2 images qui synthétisent les mesures, le modèle et le résultat attendu au niveau de l’info-bulle.

J’espère que ça vous aidera.

[Jonathan]

Bonjour Brice, bonjour Nathalie,

Ici le CALCULATE ne sert strictement à rien. Si l’on veut juste faire des sommes, SUM est suffisant. Une bonne pratique sera d’ailleurs de faire réellement ces mesures de base puis de les utiliser ensuite.

Dans ce cas précis, on cherche à faire la somme de colonnes qui viennent de la même table, un simple SUMX sera suffisant. SUMX(Ma_Table, Ma_Table[Col1] + Ma_Table[Col2] + Ma_Table[Col3])

P.S. : ce n’est pas très clair, mais je répondais à ce message plus haut 😀 :

“Mon Total des valeurs =
Var Sommedesoccurences1 = CALCULATE(SUM(Valeur1))
Var Sommedesoccurences2 = CALCULATE(SUM(Valeur2))
Var Sommedesoccurences3 = CALCULATE(SUM(Valeur3))
Var SommeTotal = Sommedesoccurences1 + Sommedesoccurences2 + Sommedesoccurences3
RETURN SommeTotal”

• Cette réponse a été modifiée Il y a 3 mois, 1 semaine par  Jonathan.

[Jonathan]

Bonjour Dalia,

Voici une vidéo qui pourrait t’aider dans ce projet.

Il y a d’autres approches, tu peux par exemple faire des mesures qui calculent directement les N derniers Mois (avec la fonction DATESINPERIOD).

Mais l’approche décrite dans la vidéo est simple à mettre en œuvre et t’évitera d’avoir à gérer du DAX un peu complexe.