Une commande Amazon FBA apparaît dans votre ERP. Quelques minutes plus tard, votre entrepôt imprime une étiquette pour le même client. Amazon assure déjà l’expédition, mais le flux interne a créé une préparation vendeur. Le rapprochement des ventes reste juste : une commande, un montant, une référence. C’est l’instruction logistique ajoutée à cette vente qui est fausse.
Le symptôme peut surgir après une migration de connecteur alors que les imports continuent sans erreur. Le nouveau format transmet le responsable de l’expédition ailleurs ; une ancienne règle ne retrouve plus son champ et applique « expédié par le vendeur » par défaut. L’équipe découvre le défaut au ramassage du transporteur ou au message d’un acheteur qui a reçu deux colis. Corriger le stock disponible ne corrige pas cette décision.
Le risque apparaît lorsque l’import commercial d’une commande FBA autorise à tort une préparation dans votre entrepôt. Nous démontons une règle de routage qui confond ces deux opérations, avec un exercice corrigé couvrant neuf situations. La méthode sépare la donnée ayant déclenché la tâche, la responsabilité vendeur réellement établie et les préparations déjà présentes à traiter avant une relance.
Ce diagnostic concerne votre exploitation de vendeur marketplace et l’automatisation des commandes et des stocks marketplace. Il part d’une vente précise et de sa tâche locale. Les décisions d’assortiment, de prix et de répartition du stock entre FBA et FBM restent des arbitrages distincts.
Pour qui : une vente Amazon produit deux circuits d’expédition
Le comptage des commandes ne révèle pas la seconde préparation
Ce cas intéresse les responsables e-commerce, logistique et intégration qui importent des commandes Amazon dans un ERP ou un OMS. La marque peut vendre le même SKU par plusieurs modes de livraison. Une entrée commerciale correcte coexiste alors avec une tâche locale injustifiée. Un tableau de reporting limité aux ventes ne voit rien d’anormal, puisque le doublon concerne l’exécution plutôt que l’enregistrement de la commande.
Relevez l’identifiant Amazon, le compte vendeur, le marché, l’heure de collecte et la tâche créée dans le WMS. Retrouvez ensuite la commande consultable dans Seller Central et le fragment réellement consommé par le connecteur. La comparaison doit porter sur cette vente, pas sur la configuration actuelle de l’offre. Une capture d’écran du catalogue ne suffit pas à expliquer une décision prise plusieurs heures auparavant.
Une commande FBM attendue ne constitue pas le même incident
Si la commande est effectivement à expédier par le vendeur, une proposition de préparation peut être cohérente. Il reste à contrôler son état, ses lignes et l’existence d’un traitement antérieur. L’enquête ne doit donc pas supprimer toutes les tâches Amazon : elle doit séparer les ventes dont le responsable d’expédition est établi de celles qui ont reçu une décision par défaut.
Si deux ventes indépendantes possèdent chacune leur propre identité, le problème relève d’un autre diagnostic. Même chose pour un colis de remplacement expressément décidé par le support client. Ici, on cherche une instruction locale issue de l’import d’une commande confiée à Amazon, sans décision métier distincte. Cette délimitation évite de prendre tout second mouvement logistique pour une anomalie du connecteur.
Anatomie du flux : l’enregistrement commercial devient une instruction d’entrepôt
Trois objets peuvent porter le même identifiant sans avoir la même fonction
L’ERP peut enregistrer une vente pour le suivi commercial et le rapprochement financier. L’OMS peut conserver son état et son responsable d’expédition. Le WMS reçoit, lorsqu’elle est justifiée, une instruction de préparation. Ces objets peuvent partager une référence de commande sans devoir se créer simultanément. Le contrat entre les systèmes doit préciser lequel constate une vente et lequel autorise une opération physique.
Suivez la première transformation qui produit un ordre d’entrepôt. Est-ce une règle du connecteur, un workflow de l’ERP ou une tâche automatique lancée après l’import ? Une correction au niveau du WMS risque de masquer le problème si l’ERP continue à recréer l’instruction. À l’inverse, bloquer tout import empêche aussi la comptabilité de retrouver des ventes dont l’enregistrement n’était pas fautif.
Le responsable de l’expédition appartient à la commande examinée
Amazon distingue FBA et FBM par la responsabilité du traitement logistique : avec FBA, Amazon assure ce traitement ; avec FBM, le vendeur organise l’expédition. Notre diagnostic conserve cette distinction pour la commande importée. Il n’en déduit aucune règle tarifaire, ni les services applicables à un compte particulier.
La configuration de l’offre indique comment vous proposez actuellement un produit. Elle ne doit pas écraser silencieusement la responsabilité conservée lors de la collecte d’une autre commande. Un changement FBA vers FBM peut être justifié pour les ventes suivantes et rester sans effet sur le routage de celle qui est déjà enregistrée. Si les informations de commande paraissent contradictoires, le dossier appelle une vérification ciblée plutôt qu’une substitution automatique.
Le piège de migration : un champ absent reçoit le défaut MFN
La nouvelle réponse n’utilise plus le même emplacement
La documentation officielle de migration Orders décrit le passage de FulfillmentChannel, avec AFN ou MFN dans v0, à fulfillment.fulfilledBy, avec AMAZON ou MERCHANT dans la version 2026-01-01. Le groupe FULFILLMENT fait partie des données que l’appel peut demander. Ce changement impose de vérifier l’adaptateur et la projection réellement utilisés par votre intégration.
Le défaut étudié est une règle fictive qui consulte uniquement FulfillmentChannel et choisit MFN lorsque ce champ manque. Elle reconnaît une ancienne commande AFN, mais oriente à tort vers l’entrepôt un fragment récent contenant AMAZON au nouvel emplacement. L’import n’échoue pas : il fournit une valeur de remplacement parfaitement lisible pour le système suivant. Ce comportement n’est pas attribué à un éditeur ni présenté comme une pratique universelle.
Un validateur de forme ne garantit pas la présence de la donnée de routage
Le modèle officiel Orders 2026-01-01, dans cette révision figée, ne rend pas fulfillment obligatoire sur Order. Dans OrderFulfillment, fulfillmentStatus est requis, mais fulfilledBy ne l’est pas. Les valeurs AMAZON et MERCHANT sont décrites pour ce champ ; elles ne constituent pas une contrainte enum du schéma consulté.
Votre règle d’entrepôt peut exiger une donnée que le contrat général de réponse laisse facultative. Il faut alors vérifier sa présence avant cette décision précise. Absence, valeur inconnue et responsabilité vendeur sont trois sorties différentes. Une valeur manquante doit laisser la commande à qualifier ; elle ne reçoit pas MERCHANT simplement parce que l’ERP exige un choix entre deux circuits.
Construire une décision qui refuse de deviner qui doit expédier
Distinguer la version du contrat et les faits nécessaires au traitement
Le traitement connaît explicitement la version de son entrée. Un adaptateur v0 transforme AFN et MFN ; un adaptateur 2026-01-01 lit le nouvel objet fulfillment. Les deux produisent une représentation interne commune. Évitez une recherche opportuniste qui prend le premier champ disponible dans un mélange de formats : une ancienne propriété ajoutée par un enrichissement peut alors contredire la réponse récente.
Le contexte relie cette représentation au vendeur, au marché et à l’identité de commande. Il conserve aussi l’état connu de la tâche locale et la révision interne de la capture. Ces informations servent au traitement propre à votre organisation ; elles ne sont pas présentées comme des propriétés natives Amazon. Un identifiant de commande lu dans un objet et un contexte appartenant à une autre vente doivent être refusés ensemble.
Autoriser une proposition ne signifie pas avoir créé un colis
Lorsque le responsable est Amazon, la décision n’autorise pas de nouvelle tâche locale. Lorsque le responsable est le vendeur, l’état de commande et le traitement antérieur restent à examiner. La sortie autorisée peut être une proposition à prendre en charge par le système d’exécution, sans annoncer une étiquette imprimée, une réservation de stock ou un colis remis au transporteur.
Cette séparation facilite la recette du middleware : on peut confronter les données reçues aux décisions attendues avant de lui permettre une écriture. La frontière d’exécution doit ensuite protéger son propre contrat : identité, quantités, tâche existante et confirmation du système destinataire. Un classement correct n’établit pas à lui seul que deux travailleurs concurrents ne créeront jamais deux préparations.
Exercice corrigé : neuf situations face à la règle de routage
Comparer l’ancien défaut à une classification sans écriture
L’exercice utilise des fragments de commande fictifs et un contexte fourni par le laboratoire. Ils ne représentent pas des réponses API complètes. Le vendeur, le marché et l’identité de vente sont constants dans les cas simples ; une révision interne permet de refuser une capture périmée. L’état de tâche vaut absente, existante ou incertaine. Aucun appel Amazon ni accès à un ERP n’intervient dans cette comparaison.
La règle défectueuse et le classificateur corrigé reçoivent une ancienne entrée AFN, puis une entrée récente AMAZON. Le scénario B rend le défaut visible : la première règle cesse de distinguer les responsabilités dès que son champ ancien disparaît. Le second traitement lit l’adaptateur déclaré, refuse les données indispensables manquantes et produit les sorties suivantes. Les termes du tableau décrivent des décisions du laboratoire, sans certifier les capacités d’un connecteur installé.
| Cas | Entrée examinée | Décision corrigée | Piège écarté |
|---|---|---|---|
| A | v0, FulfillmentChannel AFN | Aucune tâche locale | La vente ne devient pas une préparation vendeur |
| B | 2026-01-01, fulfilledBy AMAZON | Aucune tâche locale | Le champ ancien absent ne déclenche pas MFN |
| C | MERCHANT, UNSHIPPED, tâche absente | Proposition locale seulement | Le diagnostic n’annonce aucune expédition |
| D | Offre actuelle différente de la capture | Responsabilité de la capture conservée | Le mode de l’offre ne remplace pas celui de la vente |
| E | Objet fulfillment ou fulfilledBy absent, nul | Entrée refusée pour ce routage | Une absence ne signifie pas « vendeur » |
| F | Attente, annulation ou expédition terminée | Attente ou aucune nouvelle tâche, selon l’état | La responsabilité vendeur ne suffit pas |
| G | MERCHANT, PARTIALLY_SHIPPED | Examen des lignes restantes | La commande entière n’est pas recréée |
| H | Tâche locale existante ou état incertain | Réutilisation ou rapprochement ; enquête si AMAZON | La relance ne suppose pas une tâche absente |
| I | Format mélangé, contexte incorrect ou révision périmée | Entrée refusée | Aucune conversion silencieuse ne tranche le conflit |
Ce que démontrent les 38 contrôles exécutés
Le laboratoire Python a passé 38 contrôles répartis dans ces neuf groupes. Ils vérifient notamment l’équivalence des responsabilités entre les deux formats, le refus du champ absent, les tâches incertaines et la conservation des données d’entrée. Un programme PRIME ajouté à une entrée fictive MERCHANT ne la fait pas devenir AMAZON. Ce test protège la priorité du champ de responsabilité dans notre contrat ; il ne simule pas les conditions d’adhésion à Seller Fulfilled Prime.
Le groupe G signale un examen des lignes restantes sans calculer leur quantité. Le groupe H reçoit l’état de tâche comme une entrée, sans interroger le WMS. Aucun test n’exécute une réservation, une file de messages, une transaction durable ou une création d’étiquette. Les résultats établissent le comportement du classificateur limité ; la recette de votre chaîne réelle doit encore prouver ces opérations lorsqu’elles sont requises.
L’état de commande peut interdire une nouvelle préparation vendeur
Une responsabilité MERCHANT n’autorise pas tous les états
Dans le modèle officiel consulté, les états PENDING et PENDING_AVAILABILITY précèdent une commande prête à expédier. UNSHIPPED désigne une commande prête dont aucun article n’est encore expédié. Le classificateur de l’exercice attend dans les deux premiers cas et ne propose une préparation que dans le troisième, sous les autres conditions prévues. Il conserve ainsi la différence entre « à la charge du vendeur » et « prêt pour une tâche ».
Une annulation ou une expédition terminée ne doit pas produire une nouvelle préparation par simple réimport. Les états CANCELLED et SHIPPED empruntent cette sortie dans le laboratoire. La graphie Canceled de v0 est transformée explicitement en CANCELLED. Une variante inconnue est refusée : ajouter une tolérance de casse générale peut masquer un changement de contrat que l’équipe aurait dû examiner.
Une expédition partielle appelle un examen au niveau des lignes
PARTIALLY_SHIPPED ne décrit pas une commande entière encore intacte. Une partie a déjà été expédiée ; recréer toutes les lignes peut provoquer une seconde préparation même avec le bon responsable. Le diagnostic doit conserver les identités de ligne et rapprocher les quantités déjà traitées. Par exemple, une ligne déjà expédiée ne doit pas être ajoutée au reliquat parce qu’une autre attend encore son départ. Le statut global ne suffit pas à construire ce reliquat ni à déterminer les réservations encore présentes.
Le laboratoire s’arrête à cette demande d’examen. Pour votre intégration, faites qualifier la représentation des lignes, des quantités et des confirmations reçues. Un retrait du stock dans l’ERP et une confirmation d’expédition ne prouvent pas nécessairement la même opération. Sans cette correspondance, un reliquat calculé sur des indicateurs incompatibles peut doubler une ligne au lieu de la reprendre.
La tâche existe déjà : corriger la règle ne rappelle pas le colis
Retrouver la préparation avant de rejouer la commande
Une modification de l’adaptateur peut arrêter les prochaines tâches injustifiées tout en laissant les anciennes ouvertes. Retrouvez celles qui correspondent aux commandes concernées, avec leur état : créée, réservée, étiquette produite, prise en charge ou autre étape propre à votre entrepôt. Le traitement de ces états appartient au processus d’exécution ; supprimer une ligne dans le connecteur ne suffit pas à revenir sur leurs effets.
Si la commande AMAZON possède une tâche locale, le laboratoire produit une demande d’enquête. Il ne la supprime pas automatiquement. Elle peut avoir été exécutée, modifiée manuellement ou reliée à une décision de remplacement. La reprise doit alors réunir logistique et support avant de décider une annulation de tâche, une libération de stock ou le traitement d’un colis déjà parti.
Une réponse perdue rend l’état incertain, pas inexistant
Pour une commande MERCHANT admissible, une tâche connue est réutilisée dans l’exercice. Lorsque son existence est incertaine, la sortie demande un rapprochement avant relance. Un délai de réponse peut survenir après création dans le système destinataire. Rejouer parce que le connecteur n’a pas reçu de confirmation ajoute alors un risque distinct du mauvais classement FBA.
La recette réelle doit déterminer comment rechercher cette tâche et quelle identité stable permet de la reconnaître. Prévoir une clé d’idempotence dans un document ne prouve pas son application côté destinataire. Testez séparément la confirmation perdue, le rejeu et, si votre architecture le permet, des traitements concurrents. Le laboratoire de classification n’établit aucune garantie de déduplication durable.
Erreurs fréquentes : changer l’offre ou le stock pour corriger un mauvais routage
Une bascule FBA vers FBM peut brouiller l’enquête
Le vendeur peut modifier son offre parce que le stock FBA devient indisponible. Cette décision commerciale ne décrit pas la responsabilité de toutes les commandes précédentes. Si le connecteur relit le mode courant du listing pour classer les imports anciens, une reprise peut produire un autre résultat que la collecte initiale. Conservez la donnée ayant fondé la décision et qualifiez tout écart au lieu de réécrire son origine.
Deux signaux méritent une enquête : les tâches injustifiées commencent à une date de migration, ou elles concernent surtout les imports dépourvus de l’ancien champ. Ils constituent des pistes, pas la preuve qu’une version précise est responsable. La vérification compare les fragments, l’adaptateur et la première instruction logistique sur une cohorte dont les commandes saines servent de témoin.
Le badge commercial et la réservation de stock ne tranchent pas la responsabilité
Un badge Prime, une référence ASIN ou le SKU présent dans votre entrepôt ne doit pas servir de remplacement au champ de routage. La possibilité physique d’expédier le produit n’établit pas que cette commande vous incombe. Modifier le stock réservé pour faire disparaître une tâche incohérente peut en outre fausser la disponibilité de vos autres canaux.
Paradoxalement, un taux d’import sans erreur élevé peut cacher ce défaut : chaque absence reçoit une valeur admissible et le workflow continue. Cherchez donc les décisions obtenues par défaut, pas seulement les rejets techniques. Une commande suspendue avec un motif explicite rend la donnée manquante visible ; une préparation créée sans justification transforme cette absence en coût réel.
Plan d’action : séparer arrêt du défaut, reprise des tâches et remise en route
Isoler la règle qui donne naissance aux préparations injustifiées
Commencez par une commande AMAZON affectée et une commande MERCHANT saine. Le responsable intégration réunit les entrées datées, les adaptateurs et leurs sorties. La logistique relève les tâches et leurs effets ; l’équipe e-commerce confirme les identités dans son environnement Amazon. Déterminez ensuite où arrêter la transformation fautive, avec une procédure qui préserve les enregistrements commerciaux nécessaires.
La modification retire le défaut MFN et exige les faits de routage sur la bonne version. La recette couvre le champ absent, les deux responsables, l’attente, l’annulation, l’expédition partielle et une tâche incertaine. Prévoyez une sortie exploitable pour les refus : motif, commande concernée et action attendue. Sans ce suivi, les commandes suspendues risquent simplement de quitter les tableaux surveillés.
- Arrêter les nouvelles préparations injustifiées : isoler la règle fautive avec la logistique, sans effacer l’enregistrement commercial des ventes.
- Refuser le défaut vendeur : demander le champ de responsabilité sur la bonne version et conserver un dossier à qualifier lorsqu’il manque.
- Rapprocher les tâches existantes : vérifier les préparations, réservations et étiquettes avant de choisir les commandes autorisées à reprendre.
La reprise historique possède sa propre liste de décisions
La logistique traite ensuite les tâches déjà produites, en distinguant les effets réversibles des opérations accomplies. Chaque commande reçoit une décision et une vérification dans le système concerné. La remise en route ne commence pas par rejouer toute la période : elle repart des ventes qualifiées, avec leurs tâches rapprochées et les lignes restant éventuellement à prendre en charge.
Le retour arrière doit conserver les dossiers examinés. Réinstaller l’ancien adaptateur ne doit pas réintroduire son défaut MFN ni déclencher une nouvelle préparation sur la même vente. Documentez le périmètre arrêté, les dossiers en attente et les conditions de reprise. Ce contrat de passation rend l’incident traitable par une autre équipe, sans dépendre de la mémoire de la personne ayant modifié le connecteur.
Mesurer le résultat sur les tâches, les quantités et les coûts de reprise
Comparer des commandes dont les responsabilités sont établies
Suivez séparément les commandes AMAZON sans tâche locale, les anomalies de tâche sur ces commandes, les MERCHANT admissibles et les dossiers suspendus. Le dénominateur comprend les commandes dont la donnée nécessaire est disponible sur la période étudiée. Les entrées non qualifiées restent dans une file visible ; elles ne sont pas retirées discrètement pour améliorer le taux de traitement.
Pour chaque cas repris, rapprochez la décision du connecteur de l’état retrouvé dans le WMS. Mesurez aussi le délai de qualification et la survie de la correction lors du réimport suivant. Un résultat utile associe une vente à la bonne sortie et conserve les exceptions compréhensibles. Il ne se résume pas au nombre de messages consommés ni à une disparition des alertes.
La marge perdue dépasse le coût du second transport
Sur une commande affectée, relevez les coûts effectivement constatés : préparation supplémentaire, emballage, transport, temps de support, retour et éventuelle remise en stock. N’attribuez pas un montant standard à toutes les anomalies. Une tâche stoppée avant prélèvement et un colis déjà livré n’ont pas le même coût de reprise ; leur distinction permet de prioriser les décisions logistiques.
La marge et la rentabilité du canal se lisent ensuite avec ces coûts documentés, en évitant de compter deux fois une même dépense dans le reporting. Si le rapprochement doit devenir un rituel multicanal, un cockpit comme Ciama pour le pilotage vendeur peut faire l’objet d’un cadrage adapté à vos données. Ce relais n’affirme pas une prise en charge native de la version Orders étudiée : les interfaces et les actions requises restent à vérifier.
Projets liés : conserver la source des expéditions Amazon et ShippingBO
Retrouver les quantités expédiées sans fusionner les responsabilités
La réalisation publiée sur les expéditions ShippingBO et Amazon FBA dans Ciama présente deux chemins de collecte : l’API ShippingBO et un rapport Amazon FBA Europe. Le modèle conserve expédition, colis et lignes de produits. Cette séparation donne un point de comparaison lorsque l’enquête doit retrouver la source d’un départ et les quantités associées à une référence.
La fiche précise aussi les limites du rapprochement : le lecteur ShippingBO conserve l’identifiant de commande sans résoudre le lien vers la commande Ciama dans ce périmètre. Cette réalisation ne démontre pas la correction du routage Orders 2026-01-01 décrit ici. Elle illustre la nécessité de garder l’identité fournisseur et les données disponibles au lieu de fabriquer une relation de commande lorsque les correspondances manquent.
Lectures complémentaires : allocation, automatisation et commande indisponible
Replacer le routage dans les décisions d’exploitation Amazon
Le dossier sur l’allocation entre FBA, FBM et stock disponible traite le choix des pools et la capacité de service. Il aide à préparer les offres futures. Le diagnostic présent intervient après la commande et vérifie quelle responsabilité a réellement déclenché une tâche ; les deux travaux utilisent des données et des moments de décision différents.
Le dossier Amazon pour les vendeurs marketplace replace la logistique parmi les leviers d’exploitation du canal. Il permet de relier une anomalie de préparation au support, à la disponibilité et au suivi vendeur. Une offre performante ne dispense pas de vérifier la transformation qui autorise l’entrepôt à travailler sur chaque vente.
Distinguer rupture après acceptation et doublon de préparation
Une commande acceptée dont le produit devient indisponible pose une autre question : comment traiter une promesse qui ne peut plus être tenue. Le stock insuffisant ne prouve pas que la tâche aurait dû exister ; vérifiez son origine avant d’utiliser ce traitement de rupture sur une vente confiée à Amazon.
Le retour d’expérience sur la double collecte entre Shoppingfeed et Shippingbo examine les circuits pouvant prendre en charge une même commande. Il complète le diagnostic de responsabilité lorsque plusieurs outils créent chacun une instruction. Un bon classement FBA ne corrige pas automatiquement un second chemin de collecte indépendant.
Conclusion : importer la vente ne doit pas autoriser un second colis
Le défaut étudié naît lorsqu’un champ ancien absent reçoit une responsabilité vendeur par défaut. La vente est importée, mais la préparation locale ne repose plus sur la donnée de commande. Le traitement doit connaître sa version, vérifier les faits nécessaires et laisser les absences à qualifier avant toute instruction d’entrepôt.
Dans l’exercice, AMAZON interdit une nouvelle tâche locale ; MERCHANT ne permet qu’une proposition conditionnelle. L’attente, l’annulation, l’expédition partielle et une tâche incertaine changent la sortie attendue. Les 38 contrôles expliquent ces décisions sur des fragments fictifs. Ils ne prouvent pas l’exécution ni la déduplication durable de votre chaîne de préparation.
La reprise doit ensuite examiner les effets déjà produits. Une règle corrigée ne libère pas une réservation, n’annule pas une étiquette et ne rappelle pas un colis. Le dossier conserve l’identité de vente, la décision initiale et la tâche retrouvée pour que logistique et support puissent choisir une action vérifiable.
Faire reprendre le passage de la commande à l’instruction logistique
Le cadrage de votre automatisation des commandes marketplace peut réunir les contrats d’entrée, les règles de responsabilité, les refus et le rapprochement des tâches. Une recette sur quelques ventes représentatives permet de qualifier la remise en route et la reprise historique séparément.
Dawap peut structurer ce diagnostic dans votre accompagnement de vendeur marketplace, avec votre équipe logistique et votre intégrateur ERP. Nous suivons une commande depuis sa collecte jusqu’à l’instruction locale pour identifier le mauvais routage, préparer sa correction et donner à vos équipes les contrôles nécessaires pour reprendre les dossiers concernés.
