Données et accès
Une jointure gonfle le chiffre d’affaires : vérifier les clés
Pour qui : Analyste qui joint des factures et plusieurs lignes de paiement ou de livraison.
2026-11-08
Notre avis
Ramener chaque mesure à son grain puis joindre ; ne pas masquer le défaut par un DISTINCT sans règle.
Quand un chiffre augmente après rapprochement de deux tables, nous vérifierions d’abord ce qu’une ligne représente. Une facture, une ligne de facture et un paiement n’ont pas le même grain. La bonne correction consiste à retrouver la mesure métier attendue, pas à enlever arbitrairement les lignes qui gênent le total.
Dans l’ordre
- Grain de chaque table
- Contrôle de cardinalité et mesure témoin
- Modèle corrigé avant visuel
Pourquoi
- Une relation un-à-plusieurs peut répéter une mesure du côté un.
- Un total correct dans un exemple ne garantit pas les sous-totaux.
Ce qui change le choix
Un rapport qui compte précisément les combinaisons, et non un montant métier, peut utiliser cette multiplicité.
Deux factures, trois paiements, un total qui change
Prenons un exemple fictif. F1 vaut 100 € et a reçu deux paiements de 40 € et 60 €. F2 vaut 200 € et a reçu un paiement de 200 €. La table des factures totalise 300 €. Après jointure sur le numéro de facture, le montant de F1 figure sur deux lignes : additionner la colonne facture donne alors 400 €. Les encaissements, eux, donnent bien 300 €. Aucune source n’est nécessairement fausse ; les colonnes ne portent simplement plus la même unité d’observation.
| Facture | Montant facture répété | Paiement |
|---|---|---|
| F1 | 100 € | 40 € |
| F1 | 100 € | 60 € |
| F2 | 200 € | 200 € |
| Somme naïve | 400 € | 300 € |
Choisir la question avant la réparation
Pour suivre le chiffre facturé, conservez une mesure au niveau facture ou un modèle qui permet de l’agréger correctement. Pour rapprocher facturé et encaissé par facture, une préagrégation des paiements peut être adaptée. Pour analyser chaque paiement, gardez son détail sans laisser croire que chaque ligne contient une nouvelle facture. Microsoft recommande généralement de ne pas relier directement deux tables de faits en plusieurs-à-plusieurs ; cette recommandation ne remplace pas l’examen de votre grain et de vos relations.
Pourquoi enlever les doublons peut aggraver le problème
Deux factures différentes peuvent avoir le même montant. Un dédoublonnage fondé sur le seul montant les confondrait. Même une clé facture ne suffit pas si l’analyse exige les lignes de produits ou les répartitions de taxe. Notez pour chaque table la clé et la phrase « une ligne représente… ». Puis faites expliquer quelle mesure doit rester additive après rapprochement. Une relation de modèle et une fusion physique de tables ne sont pas la même opération : exigez la preuve sur le montage réellement livré.
La réception porte sur les sous-totaux
Ajoutez au cas fictif une facture sans paiement, une facture réglée en plusieurs fois et deux factures de même valeur. Contrôlez total, détail et sous-total par client après un filtre. Le responsable métier approuve les résultats attendus avant la démonstration. Si le rapport compte volontairement des combinaisons facture-paiement, la multiplication peut être légitime ; le nom de la mesure doit alors le dire. Nous n’avons exécuté ce scénario dans aucun produit : c’est une méthode de réception à demander au prestataire.
Limites
Analyse de documents publics et méthode éditoriale. Aucun compte ou logiciel testé ; exemples explicitement fictifs. Les paramètres et engagements propres à votre environnement restent à faire confirmer.
Prochaine action
Faites écrire le grain et la clé de chaque table, puis exigez le total attendu sur le cas F1/F2 avant de modifier le graphique.
Preuves et sources
Faits lus, déclarations d’éditeurs, méthodes et avis restent distincts. Notre méthode.
Fait lu. Microsoft déconseille généralement une relation directe plusieurs-à-plusieurs entre deux tables de faits et propose un schéma en étoile.
Daté du 8 novembre 2026. Portée : Power BI Desktop, relations entre tables de faits
Contexte : FR pour lecteur ; documentation officielle EN ou FR citée
Réserve : Lecture documentaire du périmètre cité ; aucun compte, test produit, contrat client ou performance mesurée.
Microsoft — Many-to-many relationship guidanceLu le 8 novembre 2026. Documentation primaire lue.
Portée : Many-to-many relationship guidance
Recommandation de modélisation, pas une règle universelle de jointure SQL ni une preuve de notre calcul fictif.
Notre calcul ou déduction. Exemple fictif de jointure : factures 100 + 200 = 300 € ; après répétition de F1, 100 + 100 + 200 = 400 € ; paiements 40 + 60 + 200 = 300 €.
Daté du 8 novembre 2026. Portée : Scénario fictif explicitement décrit ; calcul ou déduction éditoriale
Contexte : FR
Unité : EUR fictifs, sans prix produit
Réserve : Aucune consommation, facture ou expérience client observée ; exemple illustratif uniquement.
Notre méthode. Ramener chaque mesure à son grain puis joindre ; ne pas masquer le défaut par un DISTINCT sans règle. Le protocole proposé est notre méthode de réception.
Daté du 8 novembre 2026. Portée : Analyste qui joint des factures et plusieurs lignes de paiement ou de livraison.
Contexte : FR
Réserve : Avis conditionnel et méthode éditoriale ; ne vaut pas test, validation juridique ou résultat garanti.