Six ventes, sept colis : pourquoi le rapport compte-t-il 200 euros de trop ?

Les ventes de votre portefeuille marketplace passent de 670 à 870 euros après l’ajout des numéros de colis dans le reporting. Aucune nouvelle commande n’a été reçue. Les expéditions sont pourtant réelles, leurs références sont différentes et Power Query n’affiche pas d’erreur de fusion. Avant d’accuser le canal ou de retirer des commandes, examinez le nombre de lignes produit par cette opération.

Une commande de 120 euros expédiée en deux colis peut apparaître deux fois après développement de la table associée. Additionner la colonne commerciale compte alors 240 euros. Le problème n’est pas nécessairement un doublon dans les exports : deux colis légitimes ont répété un montant qui appartenait à une seule commande. Supprimer arbitrairement une ligne corrigerait peut-être le total tout en faisant disparaître une dépense transport.

Le risque est de transformer plusieurs départs logistiques en plusieurs ventes en additionnant un montant répété. Le montant de commande reste au grain commercial auquel il a été défini, tandis que les coûts de colis restent calculés au grain logistique. Le diagnostic ci-dessous suit six ventes fictives, sept colis et une commande encore sans expédition. Il compare une fusion développée, un regroupement préalable et deux corrections trompeuses. Un total identique à la source peut lui-même cacher deux erreurs qui se compensent.

Notre accompagnement des vendeurs marketplace relie ce contrôle à la décision commerciale concernée. Le travail sur votre reporting marketplace vendeur peut partir d’un export existant et de quelques commandes. La reprise remonte à la transformation qui change le montant, avant d’engager une refonte de toute la chaîne de données.

Pour qui : les ventes changent quand les colis rejoignent le rapport

Le symptôme apparaît après une étape précise de préparation

Ce diagnostic concerne le responsable marketplace, l’analyste et le contrôle de gestion qui rapprochent un export commercial avec des expéditions. Le premier fichier contient un montant par commande ; le second décrit plusieurs départs possibles. Les deux fichiers peuvent être justes séparément. Leur réunion devient incorrecte lorsque la restitution traite chaque ligne obtenue comme une vente indépendante.

Le signal faible est une variation concentrée sur les commandes fractionnées. Les ventes en colis unique semblent stables, tandis que les ventes réparties entre deux entrepôts ou deux dates augmentent dans la vue enrichie. Vérifiez ces dossiers avant de chercher une nouvelle formule de chiffre d’affaires. Une erreur de multiplication reste possible même lorsque les identifiants rapprochés sont exacts.

Délimiter ce que la fusion peut expliquer

Si le montant diffère déjà avant la fusion, reprenez la définition de la source, les dates, la devise et le périmètre. Un rapport de règlement ne se compare pas directement à une liste de commandes. Un remboursement tardif peut aussi changer un total sans nouveau colis. Le présent diagnostic n’attribue donc pas tous les écarts entre marketplace, ERP et finance à Power Query.

Une reprise courte suffit lorsque le défaut appartient à une requête identifiée et que les exports contiennent les bonnes clés. Un traitement dédié se discute lorsque plusieurs équipes reproduisent ces enrichissements, que les sources changent souvent ou que les contrôles disparaissent lors du départ de leur auteur. Le nombre de graphiques n’est pas, à lui seul, un motif pour remplacer le rapport existant.

Anatomie des exports : commande commerciale et départ logistique

Écrire ce qu’une ligne représente avant de choisir ses colonnes

Le grain désigne l’objet représenté par une ligne. Dans notre exemple, une ligne commerciale représente une commande identifiée par canal, compte vendeur et référence. Son montant est une convention de travail fictive, déjà arrêtée pour l’exercice. Il ne constitue ni une définition comptable universelle du chiffre d’affaires ni une règle officielle d’Amazon ou de Cdiscount.

Une ligne logistique représente ici un colis distinct associé à cette commande. Elle porte sa propre référence et un coût. Une commande peut avoir plusieurs colis, mais un montant commercial unique. Une table de suivi contenant plusieurs scans pour le même colis aurait encore un autre grain. Il faudrait d’abord qualifier ces événements avant de prétendre compter les colis ou additionner leurs coûts.

Conserver un montant de contrôle indépendant de l’enrichissement

Archivez les deux fichiers bruts et calculez le nombre de commandes ainsi que leur montant avant fusion. Cette référence permet de vérifier l’enrichissement sans utiliser le résultat suspect pour se contrôler lui-même. La période, la devise, la source du montant et les exclusions restent écrites. Si la préparation filtre ensuite certaines ventes, la référence doit changer avec une justification distincte.

Le coût des colis possède son propre contrôle. Un montant commercial juste ne prouve pas que les dépenses transport sont complètes. Une expédition absente du fichier ne devient pas gratuite parce que sa cellule est vide. L’équipe conserve séparément montant de vente, nombre de colis connus, coût connu et dossiers dont le départ ou la dépense reste à confirmer.

Pourquoi développer les colis répète le montant commercial

Distinguer la fusion de la table et son développement

La documentation Microsoft sur la fusion des requêtes, consultée le 12 octobre 2026, décrit la correspondance sur une ou plusieurs colonnes. Le résultat ajoute une colonne contenant les lignes associées de la table de droite. Développer ces correspondances change la forme de la table ; le maintien d’une clé correcte ne garantit donc pas que l’ancien total reste additionnable.

Pour la commande de 120 euros associée aux colis P1 et P2, le développement produit une ligne avec P1 et une autre avec P2. Le montant de 120 euros accompagne chacune. Les coûts de six et sept euros décrivent deux dépenses distinctes, mais les deux montants commerciaux décrivent toujours la même vente. Cette différence explique pourquoi une somme peut être juste sur une colonne et fausse sur une autre.

Une jointure gauche conserve aussi la commande sans départ connu

La référence Microsoft de la jointure externe gauche précise que les lignes de la table de gauche restent présentes, avec les correspondances disponibles à droite. Cette propriété est utile si le rapport doit conserver les commandes dont l’expédition n’est pas encore connue. Elle ne supprime pas la multiplicité des correspondances trouvées pour les autres commandes.

Le choix d’une jointure interne peut faire disparaître le symptôme apparent en excluant les ventes sans colis. Il modifie alors la population commerciale. Avant de changer le type de fusion, écrivez si la vue porte sur les ventes reçues, les ventes expédiées ou un autre ensemble. Une correction technique qui change silencieusement cette population remplace un montant gonflé par une définition différente.

La référence 701 ne suffit pas entre canaux et comptes vendeurs

Vérifier la portée réelle de l’identifiant commercial

Une référence peut être unique dans un compte et réutilisée ailleurs. Dans notre scénario, 701 appartient à trois ventes différentes : Amazon FR compte A, Cdiscount compte A et Amazon FR compte B. Les noms de canaux servent uniquement à rendre le cas lisible ; l’exercice ne reproduit pas leurs formats d’identifiant natifs. La portée correcte doit être vérifiée dans vos propres exports.

Une fusion limitée à 701 associe les colis des trois ventes à chacune d’elles. Elle produit seize lignes sur tout le jeu, au lieu des huit lignes obtenues avec la clé complète. Le défaut ne se corrige pas en regroupant ensuite toutes les références 701 : cette opération fusionnerait trois ventes et trois montants légitimes. Il faut retrouver l’identité commerciale avant de réduire le nombre de lignes.

Contrôler la clé sur les deux côtés de la fusion

Les colonnes choisies doivent représenter les mêmes composantes, dans le même ordre, avec des types compatibles. Des zéros initiaux perdus, un compte omis ou une colonne de boutique remplacée peuvent empêcher les correspondances ou en créer de nouvelles. Le contrôle relève les clés absentes et les clés non uniques du côté supposé représenter une commande, avant toute addition financière.

Une table de commandes contenant plusieurs lignes produit ne possède pas une seule ligne par commande. Ajoutez alors l’identité de ligne pour ses mesures propres, ou construisez une table commerciale au niveau commande selon une règle validée. Regrouper toutes les lignes sans vérifier les montants peut additionner plusieurs fois un total d’en-tête déjà répété dans l’export source.

Regrouper les colis au niveau commande avant leur fusion

Produire une seule ligne logistique par identité commerciale

Pour enrichir la table de commandes sans la multiplier, préparez une synthèse logistique par canal, compte et référence. Dans notre exercice, elle contient le nombre de colis connus et la somme de leurs coûts. La table de droite possède alors au plus une ligne pour chaque clé commerciale. La fusion ajoute ces informations sans répéter les commandes, sous réserve que les clés de la source commerciale soient elles-mêmes uniques.

Microsoft décrit le regroupement sur plusieurs colonnes et les opérations de somme ou de comptage de lignes. Les possibilités de l’interface varient selon l’environnement utilisé. Le comptage des lignes ne devient un comptage des colis que si chaque ligne correspond effectivement à un colis distinct. Cette condition appartient au contrat de vos données, pas au bouton de regroupement.

Garder la distinction entre coût connu et coût absent

La synthèse apporte treize euros de transport pour la première commande et cinq pour la deuxième. La commande sans colis conserve une absence de coût connu. Afficher zéro partout rendrait le rapport plus confortable, mais pourrait présenter une contribution artificiellement favorable. La restitution peut afficher un coût provisoire ou un dossier à compléter, avec sa cause.

Conservez le détail des colis dans une autre requête pour la recherche opérationnelle. Le regroupement sert la mesure au niveau commande ; il ne remplace pas les preuves de départ, les transporteurs et les justificatifs. Le responsable logistique doit encore pouvoir expliquer les treize euros à partir de deux colis, sans demander que le chiffre d’affaires soit porté deux fois dans cette vue de détail.

Exercice corrigé : six ventes, sept colis et deux erreurs qui se compensent

Poser les données et la convention de montant

Les données ci-dessous sont entièrement fictives. Elles représentent des commandes distinctes dans une seule devise, avec un montant commercial convenu pour l’exercice. Le laboratoire exécute vingt-cinq contrôles sémantiques dans SQLite en mémoire. Il ne lance ni Power Query, ni Power BI, ni une API marketplace ; ses résultats illustrent les relations entre tables et ne certifient pas votre fichier ou votre logiciel.

Le total commercial de départ vaut 670 euros. Les sept colis connus représentent 43 euros de coût. La somme commerciale et la somme logistique n’ont pas besoin du même nombre de lignes pour être correctes. La commande 704 reste dans la population des ventes, bien que le fichier fourni ne contienne encore aucune expédition qui lui corresponde.

Comparer les résultats sans se contenter de leur total

La jointure gauche sur la clé complète, puis son développement, produit huit lignes et 870 euros si tous les montants commerciaux sont additionnés. Les commandes 701 et 703 du compte A ajoutent respectivement 120 et 80 euros indus. L’écart de 200 euros provient donc de deux répétitions légitimes du côté colis, devenues répétitions incorrectes du côté vente.

La jointure interne produit sept lignes et retrouve pourtant 670 euros. Elle retire la commande 704 de 200 euros, tandis que les deux répétitions ajoutent toujours 200 euros. Le total paraît juste par compensation. Paradoxalement, contrôler seulement l’égalité de la somme aurait validé un rapport qui exclut une vente et en surestime deux autres. La recette doit retrouver les identités et les montants commande par commande.

Une somme des montants distincts donne 550 euros : les deux ventes légitimes de 120 euros deviennent une seule valeur. Le regroupement préalable des colis, suivi d’une jointure gauche sur la clé complète, conserve en revanche six lignes commerciales, 670 euros de ventes et 43 euros de coûts connus. Il laisse la commande sans départ explicitement incomplète du côté logistique.

Éprouver l’ordre, le fractionnement et les collisions d’identité

Le laboratoire réordonne ensuite les colis : le résultat corrigé reste identique. Il remplace un colis à six euros par deux colis de trois euros ; le nombre de colis augmente, mais le montant commercial et le coût total restent stables. Enfin, une clé de colis déjà présente est refusée explicitement. Ces variantes distinguent fractionnement réel et répétition technique du même objet.

Dans votre recette, ajoutez les cas qui appartiennent réellement au métier : changement de compte, référence réutilisée, colis annulé, coût encore estimé et commande partiellement expédiée. Leur résultat attendu doit être écrit avant le test. La liste fictive ne remplace pas cette qualification, surtout si un même colis contient plusieurs commandes ou si votre export décrit des événements successifs.

Erreurs fréquentes : retirer une vente ou un colis en dédoublonnant

Une valeur identique n’identifie pas une transaction identique

Deux acheteurs peuvent commander le même article au même prix. Leurs montants identiques restent deux ventes distinctes. Dédupliquer sur le montant, ou additionner uniquement ses valeurs distinctes, confond égalité numérique et identité commerciale. Dans le scénario, cette correction efface une vente de 120 euros sans fournir aucun motif de rejet ou d’annulation.

Supprimer les répétitions sur la référence seule produit un autre défaut : six identités commerciales deviennent quatre références. La référence 701 doit continuer à désigner trois ventes séparées dans leurs comptes et leurs canaux. La règle de dédoublonnage exige donc une clé dont la portée est connue et une preuve que les occurrences représentent le même objet, plutôt que des valeurs seulement ressemblantes.

Une commande unique ne rend pas ses expéditions interchangeables

Garder arbitrairement une seule ligne par commande dans la table développée peut préserver le montant commercial tout en perdant P1 ou P2. Le rapport ne retrouve plus treize euros de transport ni les deux preuves de départ. Une commande expédiée en plusieurs colis doit conserver ses relations logistiques, même lorsque la vue de ventes revient à une ligne commerciale.

Le traitement d’un véritable doublon technique intervient avant la synthèse des colis, sur l’identité logistique validée. Il doit aussi distinguer une nouvelle version de coût d’une répétition du même enregistrement. Si votre source ne fournit pas cette distinction, le dossier reste à qualifier ; choisir la première ligne du fichier n’établit pas qu’elle représente l’état correct.

Le coût par SKU exige encore une règle d’affectation

Ne pas recopier treize euros sur chaque ligne produit

Le regroupement au niveau commande répond à la question du montant commercial et du coût logistique de cette commande. Il ne décide pas comment répartir treize euros entre ses produits. Si le rapport contient ensuite trois lignes de SKU et recopie treize euros sur chacune, le coût transport devient trente-neuf euros. La même erreur de grain revient sur la colonne de dépense.

Une répartition au poids, au montant, au nombre d’unités ou au colis réellement associé répond à des usages différents. La finance et la logistique doivent valider la convention disponible. Une allocation analytique doit rester reconnaissable comme telle, notamment lorsqu’un produit encombrant explique presque tout le coût ou qu’un départ supplémentaire provient d’un reliquat plutôt que du produit lui-même.

Séparer le suivi de la vente et celui de la contribution

Un chiffre de ventes stabilisé ne signifie pas que la marge est devenue complète. Commissions, remboursement, achat produit et gestes commerciaux restent d’autres objets à rapprocher. Ajoutez ces sources avec leurs propres clés et leurs propres dates, puis contrôlez à nouveau la population. La correction commandes–colis ne doit pas recevoir le statut « marge fiable » par simple extension de son résultat.

Lorsque ce suivi doit durer sur plusieurs canaux, Ciama peut être étudié comme relais de pilotage. Les données disponibles, les conventions de contribution et les fonctions retenues se qualifient dans votre périmètre. Une page produit ne prouve ni la reprise native de votre fichier Power Query ni une allocation automatique des coûts adaptée à vos commandes.

Plan d’action : isoler la première transformation qui change les ventes

Revenir aux étapes de la requête sur une cohorte bornée

Choisissez une période fermée et quelques commandes comprenant un colis unique, plusieurs colis et une absence de départ. Archivez les exports et la version de la requête. À chaque étape, relevez le nombre de clés commerciales, le nombre de lignes et le montant. Le premier changement inexpliqué désigne la transformation à examiner ; une nouvelle présentation du dashboard ne réparerait pas cette opération.

L’analyste identifie les colonnes et les types de fusion. Le responsable marketplace confirme la population de ventes. La logistique qualifie les lignes de colis et les coûts. Le contrôle de gestion signe la convention de mesure. Cette répartition permet de refuser une correction qui conserve la somme globale mais change les dossiers auxquels elle se rapporte.

Recetter puis diffuser la correction sans écraser l’historique

Préparez la synthèse logistique dans une requête séparée et vérifiez son unicité avant fusion. Comparez les six résultats attendus aux commandes d’origine, puis les coûts agrégés à leurs colis. Conservez une copie de l’ancienne restitution pour expliquer le changement. Un historique recalculé doit indiquer les périodes touchées et la convention appliquée, afin de distinguer le recalcul technique d’une baisse commerciale.

Le contrat de contrôle reçoit en entrée les deux exports figés, leur période et leurs clés complètes. Sa sortie conserve montant source, montant enrichi, commandes sans colis et coût connu. La journalisation rattache ces résultats à la version de requête et au responsable qui autorise la diffusion. Le seuil de publication impose ici six identités conservées et le même montant pour chacune ; une égalité globale ne suffit pas.

Le seuil d’arrêt du pilote est une identité commerciale perdue, un montant modifié sans motif, un coût dupliqué ou une absence convertie en certitude. Le repli revient à la dernière version vérifiée du rapport et signale son périmètre. Une sortie corrigée reste suspendue tant que le contrôle commande par commande ne permet pas de lever le motif d’arrêt. Le recalcul du rapport ne réinjecte aucune commande dans l’ERP et ne relance aucune préparation : la correction analytique reste séparée de l’exécution des commandes.

• À corriger d’abord : le changement de grain qui multiplie le montant commercial.
• À valider ensuite : la clé complète, la population conservée et les coûts rapprochables.
• À différer : l’allocation par SKU lorsque ses données ou sa convention manquent.
• À refuser : une somme globale juste obtenue en supprimant des ventes encore valides.

Mesurer la correction sans annoncer un revenu récupéré

Séparer l’écart affiché de son effet commercial réel

Les deux cents euros d’écart du laboratoire ne représentent pas une perte ou un gain commercial. Ils décrivent un défaut de restitution sur des données fictives. Dans l’entreprise, le coût peut venir d’une promotion décidée sur un total gonflé, d’une famille jugée trop rentable ou du temps passé à rechercher une commande manquante. Ces effets doivent être observés séparément avant de chiffrer le bénéfice de la reprise.

La mesure immédiate porte sur les identités préservées, les montants expliqués, les coûts connus et les absences encore ouvertes. Comparez ensuite le temps de préparation du même rapport et les corrections manuelles restantes. Un tableau qui économise des manipulations mais exige toujours une vérification secrète avant comité n’a pas encore résolu la dépendance de l’équipe à son auteur.

Choisir une maintenance proportionnée au nombre de sources

Le coût de maintien inclut modifications d’export, nouvelles boutiques, évolution des identifiants, coûts transport révisés et passation. Une requête documentée peut rester suffisante pour un besoin limité. Un raccordement supervisé devient plus crédible si plusieurs fichiers arrivent à des cadences différentes et si la direction exige une restitution reproductible sans opérateur présent au moment de chaque rafraîchissement.

Un cockpit tel que Ciama pour le pilotage marketplace se discute lorsque les mêmes décisions reviennent avec plusieurs canaux. Le cadrage doit alors conserver les conventions de vente et de coût déjà validées. Changer d’outil ne rend pas une référence globale unique et ne transforme pas une absence de dépense en coût nul.

Lectures complémentaires : normalisation, source et revue vendeur

Normaliser les objets et choisir la taille de la reprise

La normalisation des données marketplace dans Power BI élargit le travail aux objets, aux dates et aux responsabilités du modèle. Elle devient utile lorsque le défaut de fusion révèle plusieurs conventions concurrentes. Le diagnostic présent reste concentré sur les relations entre commandes commerciales et colis, avec des résultats calculables ligne par ligne.

La réflexion sur le reporting marketplace standard ou enrichi aide à limiter la reprise au besoin démontré. Une jointure incorrecte ne justifie pas automatiquement un nouveau socle de données. Des clés vérifiées, un regroupement adapté et un contrôle conservé peuvent suffire tant que les décisions et les sources restent stables.

Expliquer les différences avant la prochaine revue vendeur

Le diagnostic des données marketplace non fiables distingue sources, temporalité et usages des chiffres. Il prolonge l’enquête si les montants commerciaux divergent dans les fichiers bruts. Conserver ce niveau de lecture évite d’attribuer à un développement de table un écart qui provient en réalité d’un remboursement ou d’une date de versement.

La méthode de revue mensuelle vendeur marketplace replace la qualité des données dans les arbitrages de commerce, finance et opérations. La correction doit laisser un résultat utilisable et une population explicable. Le comité peut alors choisir une action sur les faits, en gardant visibles les coûts et dossiers encore provisoires.

Conclusion : préserver la vente lorsque ses expéditions se multiplient

Une commande expédiée en deux colis reste une commande. Le développement de ses correspondances peut pourtant répéter son montant commercial, sans erreur dans l’export logistique. La reprise commence par le grain des lignes et la portée des clés, puis compare les identités avant et après chaque transformation. Un total plausible ne remplace pas cette vérification.

Le scénario fictif montre trois pièges : la somme gonflée après développement, la somme exacte par compensation dans une jointure interne et la vente supprimée par une addition de montants distincts. Le regroupement préalable des colis conserve les six ventes et leurs coûts connus au niveau commande. Il ne décide pas seul de la contribution par produit ni du traitement comptable de ces montants.

Le détail logistique reste accessible et la commande sans expédition garde son statut incomplet. Cette lecture permet de corriger le rapport sans effacer un colis, inventer un coût nul ou relancer une opération métier. La recette de votre requête doit encore éprouver ses exports, ses types de colonnes et ses dossiers particuliers, au-delà des vingt-cinq contrôles du laboratoire SQLite.

Transmettre une requête dont les contrôles restent accessibles

La reprise de votre reporting commercial multicanal conserve exports, clés, regroupement et résultats de recette. La personne qui reprend le rapport doit pouvoir retrouver l’origine d’une commande sans recalculer son montant depuis les colis. Cette passation prépare la correction suivante lorsqu’un nouveau compte ou un nouveau format arrive.

Dawap peut cadrer ce travail dans votre organisation de vendeur marketplace. Nous partons du premier enrichissement qui change les ventes, puis définissons une mesure, des contrôles et une passation que votre équipe peut reproduire sur la période suivante.