

Jonathan
MemberForum Replies Created
Bonjour Eric,
C’est une segmentation statique. Vous pouvez suivre ce paterne pour obtenir le résultat souhaité.
La démarche :
- On s’appuie sur une colonne calculée qui va aller chercher l’ID de la ligne de la table de segmentation,
- On relie ensuite la table de faits à la table de segmentation,
- On calcule ensuite dans une mesure les pénalités selon le taux de pénalité trouvé pour chaque ligne de la table.
- J’imagine que votre table doit ressembler à quelque chose comme ça :
- Date,
- Code Produit,
- Pourcentage défaut,
- Tonnes,
- Vous pourrez donc faire une mesure de ce genre :
- Penalites = SUMX(TableProduction, TableProduction[Tonnes] * RELATED(Penalites[Penalite]))
- J’imagine que votre table doit ressembler à quelque chose comme ça :
N’hésitez pas à partager un modèle fictif avec vos données pour qu’on puisse vous aider plus facilement.
-
This reply was modified 11 months ago by
Jonathan.
Bonjour,
Au tout début de la requête Power Query, vous pouvez mettre ça :
= DateTime.From(DateTimeZone.SwitchZone(DateTimeZone.FixedLocalNow(),2))
J’ai testé, le résultat est correct, aussi bien dans Power BI Desktop que dans le service.
Bonjour,
Il faut vérifier la connexion dans Power BI desktop puis s’assurer que le même email a bien des droits d’accès sur le jeu de données dans Power BI. Est-ce qu’on parle bien d’utilisateurs internes (du même tenant) ?
Bonjour Florian,
Si vos mesures ressemblent à ce que j’ai mentionné précédemment, c’est juste le fait de poser le semestre de la table calendrier qui ventilera correctement la mesure.
N’hésitez pas à partager plus d’informations (modélisation, mesures, etc…) pour qu’on puisse vous aider plus simplement.
A plus tard, bonne après-midi.
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 ?
-
This reply was modified 11 months, 1 week ago by
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
Ce sera donc plus simple 👌
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
Member9 juin 2024 at 11h04 en réponse à: Comment se familiariser avec les tables de faits et de dimensions dans Power BIBonjour 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 👍
- Les tables de faits sont celles dans lesquelles on cherche à compter quelque chose (nombre de lignes, somme d’une colonne, moyenne etc…),
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
Member9 juin 2024 at 10h44 en réponse à: Comment Agrandir et Prioriser un Point dans un Nuage de Points Power BI ?Parfait 👍bonne continuation dans votre projet
C’est franchement laborieux pour formater son texte ici 😂
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”.
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>