Agence marketplace

Amazon Business : une palette demandée, un colis préparé

Jérémy Chomel Dawap
  • Publié le : 24 octobre 2026
  • Temps de lecture : 18 minutes
  1. Dans quel cas rechercher une instruction palette perdue
  2. Distinguer demande à la ligne, capacité du site et donnée inconnue
  3. Collecter la contrainte sans la perdre dans le mapping API
  4. Vérifier les colonnes des rapports avant toute importation
  5. Cas concret : sept lignes donnent quatre orientations différentes
  6. Exécuter une recette qui attrape les mauvais raccourcis
  7. Traiter une commande mixte sans inventer le plan de transport
  8. Organiser les exceptions, les reprises et la preuve terrain
  9. Mesurer le coût du mauvais circuit et ses signaux faibles
  10. Erreurs fréquentes : ce que le vendeur doit refuser
  11. Plan d’action : ouvrir le pilote, différer l’extension, refuser le contournement
  12. Conclusion : faire parvenir l’instruction jusqu’à la préparation
Portrait de Jérémy Chomel

Votre équipe prépare une commande Amazon Business comme les précédentes : impression du bon, prélèvement, étiquette colis. Pourtant, l’acheteur avait demandé une livraison sur palette. Le symptôme apparaît parfois au quai, parfois au premier refus de réception. La vente est correcte dans Seller Central ; c’est une instruction de préparation qui a disparu entre la commande et l’entrepôt.

Le circuit doit couvrir la contrainte de chaque ligne jusqu’au poste qui choisit le mode d’expédition. Savoir qu’une adresse accepte des palettes ne suffit pas. Savoir qu’une commande est professionnelle non plus. Une agence marketplace qui accompagne les opérations vendeur doit pouvoir expliquer pourquoi une ligne est orientée vers la préparation palette, laissée dans son circuit habituel ou retenue pour vérification.

Le diagnostic porte ici sur Amazon Business expédié par le marchand, la collecte Orders API, les rapports de commandes et leur traduction dans l’OMS. L’exemple fictif suit sept lignes ; il sépare demande explicite, absence correctement observée et information indisponible. Il permet de contrôler le passage vers votre organisation logistique et fulfillment marketplace, sans supposer qu’une lecture API réserve un transport.

La documentation Amazon a été consultée le 24 octobre 2026. Les décisions de mise en attente, les états internes et la recette proposés ci-dessous constituent une méthode d’exploitation à adapter. Ils ne sont ni des statuts Amazon supplémentaires ni la preuve qu’un compte vendeur, un entrepôt ou un transporteur accepte déjà cette prestation.

Dans quel cas rechercher une instruction palette perdue

Une expédition marchand arrive dans le mauvais circuit

Le cas prioritaire est une vente professionnelle dont la préparation relève de votre organisation : stock propre, prestataire logistique ou autre entrepôt mandaté. Comparez la demande d’origine, la ligne importée et le document de préparation. Une capture de la liste générale des commandes ne montre pas nécessairement le détail qui a commandé le choix du transport.

Commencez par une vente réellement concernée et une vente témoin ordinaire. Le vendeur responsable du compte apporte les éléments Amazon ; l’intégrateur suit la transformation ; le responsable logistique montre ce que voit le préparateur. Cette comparaison courte permet de localiser la perte sans demander à toute l’équipe de relire manuellement chaque commande professionnelle.

Délimiter les commandes que l’entrepôt doit préparer

Une vente FBA ne doit pas entrer dans la même file simplement parce qu’elle contient un produit lourd. Le canal de fulfillment et le responsable de l’expédition précèdent le choix du conditionnement. Pour cette frontière, le diagnostic d’une commande FBA qui provoque un second colis dans l’ERP traite la séparation des responsabilités avant tout ordre de préparation.

Le contrôle présenté ici ne décide pas non plus du nombre de palettes, de la compatibilité des marchandises, de la charge admissible ou des moyens de déchargement. Ces données restent nécessaires à l’exploitation. Une exigence de livraison indique une condition à respecter ; elle ne remplace pas le travail de constitution et de validation de l’expédition.

Distinguer demande à la ligne, capacité du site et donnée inconnue

L’instruction de la commande prime sur un raccourci d’adresse

La documentation Amazon Business situe la demande dans orderItems[].fulfillment.shipping.shippingConstraints.palletDelivery. La valeur MANDATORY correspond au choix de livraison sur palette pour la ligne. L’option concerne les commandes Amazon Business en expédition marchand ; le programme de commande permet de reconnaître ce contexte.

À l’inverse, recipient.deliveryPreference.deliveryCapabilities décrit les capacités générales de l’adresse. Le risque est de croire qu’une adresse équipée impose le même mode de livraison à tous ses achats : un site marqué PALLET_ENABLED peut recevoir une petite commande sans demande particulière. Le modèle officiel Orders 2026 sépare ces propriétés et définit aussi PALLET_DISABLED. Conserver deux champs distincts évite de transformer une capacité permanente en instruction sur toutes les ventes futures.

Une absence ne devient exploitable qu’après observation

Amazon indique que la propriété d’exigence peut être vide ou omise lorsqu’elle ne s’applique pas. Cette indication suppose toutefois que vous regardiez les données pertinentes de la bonne ligne. Une réponse collectée sans les informations de fulfillment, une colonne supprimée ou une transformation interrompue ne permettent pas de conclure que l’acheteur n’a rien demandé.

Nous recommandons donc trois notions internes séparées : exigence acquise, aucune exigence observée dans une collecte qualifiée, contrôle encore incomplet. La deuxième ne signifie pas « expédition autorisée ». Le stock, l’annulation éventuelle, les conditions de service et les autres instructions restent à vérifier. Cette distinction paraît prudente ; elle évite surtout qu’une panne d’information accélère par défaut une mauvaise préparation.

Collecter la contrainte sans la perdre dans le mapping API

Demander le jeu de données qui porte le fulfillment

La référence searchOrders distingue les groupes demandés par includedData, notamment FULFILLMENT et RECIPIENT. Journalisez le groupe effectivement demandé, la version API et l’identifiant de collecte. Le simple fait de recevoir un objet destinataire ne prouve pas que les instructions de chaque ligne ont été récupérées.

Pour examiner une commande précise, getOrder expose la sélection des données complémentaires. Un refus d’accès ou une erreur de requête reste un échec de collecte, jamais une réponse métier négative. Le connecteur doit rendre cette différence visible à l’opérateur qui attend une décision, sans l’obliger à ouvrir les journaux techniques.

Rattacher la valeur à une ligne identifiable

La clé locale de notre exemple assemble compte vendeur, boutique, commande et identifiant de ligne. Le SKU et l’ASIN restent des informations utiles à la préparation, mais ils ne remplacent pas cette identité : le même produit peut apparaître dans plusieurs ventes, pour plusieurs destinataires, avec des conditions différentes. Un mapping au seul SKU contaminerait les commandes suivantes.

Conservez la valeur reçue, sa provenance et la décision calculée. Une valeur nouvelle, un type inattendu ou une ligne introuvable déclenche une exception explicable. Évitez les conversions générales en booléen : une chaîne inconnue ne mérite pas davantage d’être traitée comme « oui » que comme « non ». Le modèle d’échange évolue ; votre comportement de repli doit rester compréhensible.

Vérifier les colonnes des rapports avant toute importation

Contrôler le format réel du fichier

La documentation Business mentionne l’activation du champ dans Seller Central pour les rapports concernés. Le catalogue officiel des rapports de commandes liste notamment le rapport texte de préparation marchand et sa colonne pallet-delivery. Le tutoriel utilise l’appellation PalletDelivery. Cette différence de présentation justifie de vérifier l’en-tête réellement exporté avant d’écrire le mapping.

Dans l’adaptateur fictif, les deux noms sont des alias explicitement connus. Un nom différent, deux colonnes concurrentes ou une ligne dont le nombre de valeurs ne correspond pas à l’en-tête rendent l’observation inexploitable. La recette de production doit conserver un fichier témoin expurgé et préciser quel format est accepté pour chaque source. N’acceptez pas tous les noms ressemblants par approximation.

Ne pas confondre rapport de suivi et instruction de préparation

Le catalogue Amazon distingue les rapports destinés au suivi des ventes de ceux utilisés pour la préparation ; leurs contenus et leurs conditions d’accès diffèrent. Sélectionner un export parce qu’il contient le bon numéro de commande ne garantit pas qu’il fournisse les éléments nécessaires au transport. L’inventaire des colonnes est donc une preuve de couverture, pas une formalité d’import.

Si une colonne nécessaire disparaît après un changement de paramétrage, conservez le fichier en anomalie et identifiez la dernière importation qualifiée. Le support vendeur peut alors vérifier l’activation et relancer l’extraction. L’entrepôt voit une attente d’information, avec un propriétaire et une échéance ; il ne reçoit pas une nouvelle série d’étiquettes standard fondée sur des cellules artificiellement vides.

Cas concret : sept lignes donnent quatre orientations différentes

Construire un jeu dont chaque décision est vérifiable

Dans ce scénario fictif, A possède deux lignes : L1 exige une palette, L2 n’a pas cette exigence dans une collecte complète. B accepte les palettes à son adresse mais n’en demande aucune pour L1. C porte une exigence explicite et une capacité de réception contradictoire. D n’a été collectée que partiellement. E relève d’Amazon pour l’expédition. F contient une valeur inconnue.

Les identifiants sont inventés et les entrées sont normalisées pour l’exercice. Le tableau ne reproduit pas une réponse SP-API. Il représente ce que l’équipe doit pouvoir expliquer après la collecte et avant toute action d’expédition. La présence d’une instruction pour A/L1 ne permet ni de modifier A/L2, ni de réserver automatiquement un véhicule pour l’ensemble de la commande.

LigneConstat qualifiéDécision locale
A / L1Palette exigée ; réception compatibleFile palette
A / L2Aucune exigence observéeContrôles habituels
B / L1Adresse compatible, aucune demandeContrôles habituels
C / L1Exigence et capacité contradictoiresRevue réception
D / L1Collecte incomplèteRecollecte requise
E / L1Expédition AmazonHors de cette file
F / L1Valeur non reconnueAnalyse du mapping

Lire le résultat sans additionner des objets différents

Le résultat comporte une ligne orientée palette, deux lignes sans exigence observée, trois lignes à examiner et une ligne hors périmètre. Le total est bien sept. Il ne donne ni sept colis ni une palette physique. Les quantités, dimensions, règles de consolidation et responsabilités de transport n’ont pas été modélisées ; aucun nombre d’expéditions ne peut être déduit de ce comptage.

Pour C, l’exigence reste visible pendant l’examen. L’opérateur ne la retire pas afin de faire disparaître le conflit. Pour D, il demande une collecte suffisante. Pour F, il vérifie le contrat de données et son adaptation. Trois causes d’attente distinctes exigent trois actions ; un unique statut « erreur Amazon » ferait perdre cette capacité de résolution.

Exécuter une recette qui attrape les mauvais raccourcis

Tester les décisions et leurs contre-exemples

L’exercice Python téléchargeable s’exécute avec la bibliothèque standard. Il contrôle les sept orientations, six permutations des premières lignes, les valeurs inattendues, les alias de colonnes, les doublons et la séparation des comptes vendeurs. Les 35 vérifications ont été exécutées localement. Elles n’appellent ni Amazon, ni un OMS, ni un transporteur.

Trois témoins volontairement insuffisants montrent ce que la recette doit détecter : décider d’après la capacité de l’adresse classe mal B ; remplacer une information non collectée par une absence classe mal D ; réduire A à un booléen commande fait perdre la distinction entre L1 et L2. Le contrôle porte sur les décisions attendues, pas seulement sur un nombre de lignes importées.

python3 palette_preparation.py
# 35 contrôles ; 6 permutations ; 3 raccourcis incorrects détectés
# 7 lignes : 1 palette, 2 sans exigence observée,
# 3 à examiner, 1 hors périmètre.
# Aucun transport réservé ; aucune commande modifiée.

Réceptionner ensuite le connecteur et le poste de préparation

La réussite de ce programme ne valide pas votre intégration. Rejouez les cas pertinents sur des données de test autorisées, dans le format réellement reçu. Contrôlez l’en-tête du rapport ou la réponse API, l’enregistrement OMS, la vue préparateur et le document imprimé. Un champ correctement enregistré mais absent du bon de préparation laisse le défaut opérationnel entier.

Ajoutez un cas de reprise après interruption : même commande, même ligne, même observation. Le système ne doit pas créer deux travaux de préparation. Ajoutez ensuite une lecture partielle après une instruction acquise : elle ne doit pas effacer la contrainte précédente. Enfin, simulez le transfert vers une file incompatible et vérifiez qu’un responsable voit le refus avant toute production d’étiquette.

Traiter une commande mixte sans inventer le plan de transport

Faire remonter le détail dans la décision de regroupement

Une bannière « contient une ligne palette » peut aider à repérer A. Elle ne doit pas écraser le détail des deux lignes. Si le logisticien propose de regrouper L2 avec L1, il doit vérifier que ce regroupement respecte les instructions applicables, les délais annoncés et les conditions du service choisi. L’OMS conserve ensuite l’affectation de chaque ligne à l’expédition décidée.

À l’inverse, une préparation séparée doit rester traçable jusqu’aux colis ou aux unités logistiques. Le client, le service après-vente et la comptabilité peuvent avoir besoin de comprendre pourquoi une commande comporte plusieurs mouvements. Le diagnostic des commandes déclarées livrées sans colis retrouvé complète ce contrôle lorsque le statut global masque la réalité des expéditions.

Conserver les preuves de prise en charge séparément

La file palette est une orientation de travail. Le devis transport accepté, la réservation, l’enlèvement et la livraison constituent des événements différents. Une automatisation qui convertit immédiatement cette orientation en statut « expédié » produit une preuve fictive. Reliez les références transport lorsque leurs événements existent, avec leur source et leur date, sans remplir les étapes manquantes par anticipation.

Le contact de réception mérite aussi son propre contrôle. Une adresse techniquement compatible ne désigne pas la personne disponible pour organiser l’arrivée. Le cas du lien de livraison GEODIS envoyé au mauvais contact montre une difficulté voisine : conserver le destinataire opérationnel et sa portée, sans assimiler un contact commercial au responsable du quai.

Organiser les exceptions, les reprises et la preuve terrain

Donner un propriétaire à chaque attente

Les entrées de la file comprennent l’identité de ligne, la source, l’heure de collecte, le périmètre observé et le motif. Ses sorties sont une orientation validée ou une demande de complément attribuée. Dans notre proposition, le support compte vendeur vérifie la donnée source ; l’intégrateur corrige le mapping ; le responsable entrepôt tranche la faisabilité de préparation. Personne n’est propriétaire d’une ambiguïté générale.

La journalisation conserve les changements de décision et leur justification, sans recopier inutilement les coordonnées du destinataire dans toutes les alertes. Fixez une échéance opérationnelle avant le départ prévu, avec un seuil d’escalade convenu. Le bon seuil dépend de votre cut-off et du service transport ; il ne peut pas être remplacé par un délai universel ajouté au connecteur.

Ne pas effacer une exigence pour débloquer la file

Dans l’exercice, une nouvelle observation qui contredit une exigence acquise ouvre une revue. Cette politique conservatrice est un choix local, pas une règle de versionnement publiée par Amazon. Elle conserve l’exigence et le nouveau constat côte à côte jusqu’à vérification. Le gestionnaire peut ainsi distinguer une correction réelle d’une collecte moins complète ou d’un import ancien rejoué.

Le repli après défaut du connecteur consiste à suspendre l’orientation automatique sur les cas concernés, puis à traiter la file avec les preuves disponibles. Il ne consiste pas à revenir à « colis standard pour tous ». Lors du rollback applicatif, vérifiez particulièrement les anciennes versions du modèle qui ignorent le nouveau champ : un retour technique réussi peut réintroduire silencieusement la perte métier.

Mesurer le coût du mauvais circuit et ses signaux faibles

Comparer le coût d’une erreur au coût du contrôle ciblé

Par exemple, une expédition fictive coûte 18 € en colis. Un refus déclenche 18 € de retour, 12 € de manutention et 95 € de nouvel envoi palette : le total atteint 143 €. Un départ directement adapté à 95 € aurait évité 48 € de dépense. Ces montants sont des hypothèses de calcul, sans tarif transporteur ni estimation de fréquence réelle.

La comparaison n’intègre ni compensation commerciale, ni temps du service client, ni effet sur les indicateurs du compte vendeur. Mesurez-les séparément lorsqu’ils sont connus. Ne multipliez pas le surcoût fictif par toutes les commandes B2B : seules les erreurs effectivement rattachées à ce mécanisme justifient une attribution. Le suivi doit permettre une décision économique, pas fabriquer un gain apparent.

Rechercher deux signes avant les réclamations

Premier signal faible : après une mise à jour du connecteur, la fréquence des contraintes reçues tombe à zéro alors que les commandes professionnelles continuent. Cela ne prouve pas que les clients ont changé leurs habitudes. Comparez quelques commandes sources avant de conclure à une amélioration. Une rupture de collecte peut ressembler à une disparition des cas difficiles.

Deuxième signal : le nombre de lignes orientées palette reste stable, mais le poste de préparation ne montre plus leur détail ou imprime le même document qu’une vente ordinaire. Le pipeline de données semble sain ; la transmission à l’opérateur ne l’est plus. Contrôlez un écran et un document après chaque changement de modèle d’impression, de prestataire ou d’outil entrepôt.

Erreurs fréquentes : ce que le vendeur doit refuser

Transformer une indication utile en autorisation générale

Le badge Amazon Business, le poids du produit, la catégorie catalogue et la capacité de l’adresse peuvent orienter une recherche. Aucun ne remplace la consigne de la ligne. De même, une confirmation technique d’import ne prouve pas que l’entrepôt a vu l’information. Il faut pouvoir montrer la chaîne de preuves jusqu’à la décision de préparation.

Refusez les corrections qui rendent simplement les alertes vertes : valeur inconnue remplacée par vide, contradiction ignorée, commande entière marquée « palette traitée » après la première ligne. Pour clore l’incident, exigez le détail de la consigne, la décision prise et son auteur. Un indicateur global vert ne permet pas de reconstituer ces éléments après une réclamation.

Étendre trop vite le correctif à tous les canaux

La logique de qualification peut servir ailleurs, mais les propriétés Amazon et les colonnes de ses rapports ne sont pas un vocabulaire universel. Un flux Mirakl, un portail B2B ou une commande directe peut porter une instruction différente. Définissez l’adaptation de chaque source avant de la faire entrer dans la même file. Une harmonisation utile conserve l’origine et les limites du renseignement.

Si le besoin devient récurrent entre ventes, stocks et préparation, Ciama comme cockpit de commerce multicanal constitue un relais à étudier. Son périmètre public présente ces univers et précise que les connexions dépendent du projet. La prise en charge exacte de cette contrainte, du connecteur et du document entrepôt doit être qualifiée ; aucune compatibilité palette native n’est supposée ici.

Plan d’action : ouvrir le pilote, différer l’extension, refuser le contournement

Le premier livrable est une commande témoin expliquée de bout en bout, accompagnée d’un cas ordinaire et d’un cas incomplet. Le second est une décision d’ouverture signée par les responsables du compte et de la préparation. Le troisième est un dispositif de reprise qui préserve les instructions acquises. Ces preuves permettent une ouverture limitée sans attendre une refonte générale du SI.

  • Ouvrir le pilote : un compte, un entrepôt, des lignes identifiées ; réceptionner la donnée, le mapping, l’écran et le bon avant d’activer l’orientation.
  • À différer : l’extension à d’autres boutiques et transporteurs tant que leurs formats, conditions de prise en charge et responsables ne sont pas vérifiés.
  • À refuser : une reprise en colis standard lorsque la contrainte est inconnue ou contradictoire ; attribuer l’exception et obtenir une preuve exploitable.

Le suivi quotidien rapproche lignes concernées, exceptions ouvertes et décisions de préparation. Gardez les coûts constatés et les incidents attribuables à côté de ce suivi, sans confondre volumes importés et qualité de service. Une file vide ne suffit pas : contrôlez aussi qu’aucune ligne attendue n’a disparu du périmètre et qu’aucune expédition n’a été annoncée prématurément.

Conclusion : faire parvenir l’instruction jusqu’à la préparation

Une vente professionnelle peut être importée correctement sur le plan commercial et perdre une condition essentielle de livraison. La réparation consiste à maintenir l’identité de la ligne, le sens de la contrainte, la qualité de l’observation et la preuve de sa prise en compte. Une adresse compatible reste une capacité ; une instruction reste une instruction.

Le scénario à sept lignes fournit une base de discussion précise pour vos équipes vendeuses et logistiques. Il montre pourquoi certaines lignes partent vers une file spécialisée, pourquoi d’autres restent à vérifier et pourquoi les totaux de commande ne permettent pas de déduire le nombre d’expéditions. La recette locale rend ces décisions contrôlables.

Votre dispositif logistique et fulfillment marketplace doit ensuite confirmer le parcours réel : source reçue, règle appliquée, consigne affichée, préparation validée et prise en charge constatée. Les opérations transport conservent leurs propres validations. Une bonne transmission d’information donne les moyens de les effectuer, sans prétendre les avoir déjà réalisées.

Commencez par la prochaine commande pour laquelle la demande et le circuit de préparation semblent diverger. Notre agence marketplace Dawap accompagne vos équipes pour suivre cette ligne entre Amazon, votre connecteur, l’OMS et l’entrepôt, puis cadrer la correction au bon endroit. L’objectif est une expédition explicable et adaptée, avec moins de reprises évitables au quai et au service client.

Portrait de Jérémy Chomel

Transmettre les bonnes consignes à votre entrepôt

Dawap relie les données de vos canaux, les règles de préparation et les outils logistiques pour rendre les décisions d’expédition vérifiables.

Articles recommandés

Référence de bon de commande Amazon Business suivie jusqu’au document vendeur Agence marketplace Amazon Business : retrouver le numéro d’achat client Lire l'article
  • 11 octobre 2026
  • Lecture ~19 minutes

L’acheteur cherche son bon de commande, mais le document ERP reste vide. Treize observations fictives distinguent données non demandées, mauvais rattachement, chaîne transformée et rejeu. La recette vérifie trois métadonnées documentaires locales et leur rendu, sans facture émise ni accès Amazon. La casse originale reste intacte.

Contact de réception désigné pour le site livré et notification de rendez-vous GEODIS Agence marketplace GEODIS : qui reçoit le lien de rendez-vous ? Lire l'article
  • 10 octobre 2026
  • Lecture ~15 min

Le lien de rendez-vous arrive à l’acheteur ou à la comptabilité, alors que la réception dépend d’un autre site. Le diagnostic suit la sélection du contact jusqu’aux champs GEODIS RDW. Quatorze cas fictifs distinguent rôle confirmé, site incohérent, email manquant et service inconnu, sans appel transporteur ni notification envoyée.

Responsabilité Amazon et tâche d’entrepôt rapprochées pour une commande FBA importée dans l’ERP Agence marketplace Commande Amazon FBA : l’ERP crée un second colis Lire l'article
  • 5 octobre 2026
  • Lecture ~13 min

Amazon assure l’expédition, mais votre entrepôt prépare le même achat. Un champ ancien absent peut avoir déclenché un défaut vendeur. Neuf situations distinguent responsabilité, état de commande, tâche existante et réponse incertaine pour qualifier le mauvais routage et organiser la reprise des préparations.

Population de colis attendus rapprochée des états observés avant clôture de la commande Agence marketplace OMS : aucun colis, mais la commande est livrée Lire l'article
  • 9 octobre 2026
  • Lecture ~15 min

Le cockpit confirme une livraison sans retrouver les colis attendus. Onze commandes fictives montrent comment une liste vide, filtrée ou incomplète peut produire ce verdict. Le diagnostic rapproche les identités avant les états, puis prépare la recette des notifications et la reprise des commandes exposées.

Fiabiliser la préparation de vos ventes marketplace

Dawap relie les données de vos canaux, les règles de préparation et les outils logistiques pour rendre les décisions d’expédition vérifiables.