Le WMS a fermé les cartons destinés à Amazon FBA, mais l’impression s’arrête sur IncorrectPackageIdentifier. Le préparateur relance le même lot et le support compare des numéros qui portent tous le nom de colis. Pendant ce blocage, le coût des recherches et des réimpressions augmente ; remplacer un identifiant au hasard peut surtout produire une étiquette qui ne correspond pas au carton posé sur la table.
Le diagnostic doit commencer par deux correspondances différentes. Le parcours Fulfillment Inbound 2024 décrit une expédition et ses cartons, tandis que l’opération getLabels reste dans l’interface v0. L’identifiant d’expédition utilisé pour demander les étiquettes n’est pas celui du chemin 2024. La sélection des cartons demande également une propriété précise, distincte de la référence interne du WMS et du packageId retourné par le modèle.
Nous allons suivre ce passage entre les deux versions, qualifier l’association avec les contenants physiques et classer neuf dossiers fictifs. Le contrôle local n’appelle pas Amazon, ne récupère aucun PDF et n’imprime rien. Son résultat explique quelles données permettent de préparer une demande ; l’acceptation distante et la pose de l’étiquette gardent leurs propres preuves.
Notre prestation d’intégration API relie ces correspondances au parcours de préparation. Le raccordement Amazon FBA à votre SI se qualifie avec l’équipe vendeur, l’entrepôt et le mainteneur du WMS : départ retenu, cartons déclarés, documents récupérés et actions encore autorisées, sans promettre une réception de stock à partir d’une impression.
Pour qui : un WMS qui prépare des cartons entrants vers Amazon
Retrouver le départ concerné avant de toucher aux références
Le cas concerne un approvisionnement entrant du réseau FBA préparé avec Fulfillment Inbound v2024-03-20. Il ne traite pas l’étiquette d’un colis client Multi-Channel Fulfillment. Le vendeur confirme le compte et le départ, l’entrepôt retrouve les contenants déjà préparés et le connecteur indique quelles opérations ont produit les identifiants actuellement enregistrés.
Cette séparation compte lorsque le même WMS gère les commandes clients et les approvisionnements FBA. Une référence transporteur du premier parcours n’identifie pas automatiquement un carton du second. La fiche d’incident doit nommer le plan entrant, l’expédition interne Amazon et la demande d’étiquettes. Elle retrouve ensuite les associations locales, au lieu de chercher seulement un numéro qui commence par les mêmes caractères.
Distinguer les étiquettes de carton, de produit et de transport
Avant toute reprise, précisez le document refusé. Une étiquette de produit, une étiquette unique de carton et un document lié au transport ne répondent pas au même besoin. Notre périmètre porte sur la sélection de cartons pour getLabels. La configuration doit qualifier le type de document, le format et les exigences du départ, sans déduire ces paramètres du seul modèle d’imprimante installé.
Si les informations de contenu passent encore par le FBA Inbound Shipment Carton Information Feed, une autre règle de correspondance s’applique. Il faut donc conserver l’origine de la déclaration. Une migration progressive peut laisser coexister plusieurs parcours dans le logiciel ; elle ne justifie pas que le worker choisisse indifféremment un CartonId historique ou une propriété du modèle 2024.
Anatomie du refus : cinq identités que le connecteur doit séparer
Lire le rôle de chaque propriété, pas son libellé dans le WMS
La référence officielle de getLabels précise que PackageLabelsToPrint doit correspondre aux identifiants des cartons renvoyés par listShipmentBoxes lorsque leur contenu a été transmis avec l’interface 2024. Un écart à cette correspondance produit IncorrectPackageIdentifier. Dans le parcours par feed, la référence attend les CartonId déclarés dans ce feed.
Le modèle officiel Fulfillment Inbound distingue, dans Box, boxId et packageId. Le nom exact de la propriété JSON est boxId, même si certaines pages de documentation emploient boxID. La présence d’un champ contenant le mot package ne suffit donc pas à le sélectionner pour cette demande.
| Identifiant | Origine ou rôle | Usage à conserver |
|---|---|---|
| inboundPlanId | Plan entrant Amazon | Périmètre des lectures 2024 |
| shipmentId 2024 | Expédition du plan | Chemin de getShipment et listShipmentBoxes |
| shipmentConfirmationId | Expédition confirmée | Identifiant de chemin pour getLabels v0 |
| Box.boxId | Carton renvoyé par Amazon | Sélection PackageLabelsToPrint du parcours 2024 |
| Référence contenant WMS | Carton suivi par l’entrepôt | Association qualifiée avec le carton Amazon |
Conserver les identités dans des champs distincts
Le mapping interne doit éviter une colonne unique appelée shipmentId, successivement remplie avec une référence WMS puis un identifiant Amazon. Donnez à chaque propriété une origine et une destination. Le schéma du connecteur conserve le compte vendeur, le plan, l’expédition 2024, sa confirmation et le carton concerné. Les valeurs restent opaques : leur sens vient de la réponse qualifiée, pas d’un découpage de chaîne.
Une erreur de propriété se corrige au contrat d’échange et à ses consommateurs. Réparer seulement une ligne en base peut laisser l’export suivant reproduire le même défaut. Retrouvez l’étape qui a fourni le champ, sa version et le worker qui l’a consommé. Le support doit pouvoir expliquer pourquoi une valeur a été envoyée, même si le libellé affiché au préparateur est volontairement plus simple.
Passer de l’expédition 2024 à la demande d’étiquettes v0
Retrouver la confirmation dans le bon plan
La FAQ Fulfillment Inbound indique que les étiquettes uniques d’un départ créé avec l’interface 2024 restent accessibles par getLabels v0. Dans ce parcours, le paramètre de chemin nommé shipmentId reçoit shipmentConfirmationId. Il ne reçoit pas le shipmentId interne employé par les lectures 2024.
La lecture getShipment appartient à un plan et à une expédition déterminés. Votre adaptateur doit retrouver la confirmation dans ce périmètre, puis la ranger séparément. Si elle n’a pas été observée, une référence reconstruite à partir d’un autre départ ne permet pas de poursuivre ; le dossier reste à qualifier avec son état natif.
Ne pas recréer un plan pour réparer un paramètre
Dans un scénario fictif, le connecteur transmet shipment-A au lecteur v0 alors que la confirmation enregistrée est confirmed-A. Le contrôle local détecte cette divergence avant la demande. Il ne démontre pas qu’Amazon acceptera les autres paramètres. Le correctif remet la bonne propriété dans le chemin et conserve le plan existant ; il n’invente pas un second départ pour faire disparaître le premier message d’erreur.
Avant une nouvelle mutation du parcours entrant, relisez les opérations déjà engagées et leurs résultats. Un timeout de création ou de confirmation reste une incertitude différente d’un refus de sélection des étiquettes. La journalisation conserve operationId lorsqu’il appartient à l’opération native concernée, ainsi que son état observé. La reprise d’un lecteur ne doit pas relancer silencieusement une action qui engage le transport ou modifie le départ.
Collecter les cartons sans prendre la première page pour le départ complet
Suivre la pagination et le périmètre de chaque réponse
L’opération listShipmentBoxes fournit une liste paginée de contenants pour le plan et l’expédition demandés. Le paginationToken permet d’obtenir la page suivante. Un écran montrant dix cartons ne prouve donc pas que le départ en contient dix ; la collecte doit conserver les réponses et terminer son parcours avant d’annoncer sa complétude.
Le connecteur rattache chaque page au même compte vendeur, au même plan et à la même expédition. Un cache rempli lors d’une préparation précédente ne devient pas la liste de ce nouveau départ parce que les références produits se ressemblent. Si une page échoue, l’inventaire reste incomplet. Le worker peut reprendre la lecture selon le contrat qualifié, sans considérer les cartons non encore observés comme supprimés.
Revoir les associations lorsqu’un contenant est modifié
La liste collectée devient une observation datée, reliée à la version interne du dossier de préparation. Cette révision est un mécanisme de votre application, pas une propriété Amazon inventée. Si le contenu ou l’affectation d’un carton change, l’équipe retrouve quelles correspondances et quels documents ont été produits avec l’ancien dossier. Une nouvelle association demande sa qualification avant une réimpression.
La fin de la pagination ne garantit pas à elle seule une photographie immuable pendant des modifications concurrentes. Organisez une fenêtre de préparation contrôlée et faites relire les divergences. Un boxId absent, une répétition inattendue ou une association devenue introuvable doit ouvrir un dossier précis. L’export ne remplit pas le manque avec le carton situé au même rang dans une autre réponse.
Associer le contenant WMS au carton Amazon avant l’impression
Refuser les correspondances déduites de l’ordre des lignes
En réalité, un carton reconnu par Amazon peut encore être associé au mauvais contenant WMS. Deux cartons peuvent contenir les mêmes références, les mêmes quantités et des poids proches. Ces ressemblances ne prouvent pas leur identité. L’association doit venir d’un parcours qualifié dans votre WMS et votre adaptateur, avec une confirmation exploitable par l’entrepôt. Ne supposez pas que le numéro de ligne de l’export correspond à l’ordre des contenants retournés par Amazon.
Le contrat décrit comment une référence physique est conservée pendant la déclaration et retrouvée à l’impression. Si le WMS ne fournit pas cette continuité, l’équipe choisit une procédure de rapprochement contrôlée avant d’automatiser le lot. La disponibilité d’un champ dans une réponse ne démontre pas qu’il a été envoyé depuis votre logiciel ni qu’il représente déjà sa clé interne.
Garder une preuve de l’association et de la pose du document
Pour le pilote, partez d’un contenant identifiable et de son départ confirmé. Le préparateur retrouve le carton, le dossier déclare son association avec boxId et le poste d’impression conserve le document destiné à cette association. La méthode de confirmation physique se qualifie avec l’entrepôt : scan disponible, contrôle supervisé ou autre dispositif déjà maîtrisé. Aucun programme hors connexion ne remplace cette étape.
Une réponse de document reçue, un travail envoyé à l’imprimante et une étiquette posée correspondent à trois observations. Une panne du poste peut interrompre leur succession. Le suivi doit retrouver le dernier point confirmé, puis permettre une reprise du même document sur le même contenant. La réimpression n’autorise pas à créer une deuxième identité de carton ni à annoncer que le départ a quitté l’entrepôt.
Atelier : neuf dossiers pour préparer une sélection d’étiquettes
Comparer des données fictives déjà qualifiées
Le programme local de sélection des cartons reçoit un périmètre vendeur, plan et expédition, une confirmation, une liste complète supposée observée et des associations WMS. Les identifiants courts du banc sont fictifs ; ils ne respectent pas nécessairement les formats d’une requête native. Leur rôle consiste à rendre visibles les correspondances, sans construire un payload prêt à envoyer.
Exécutez python3 labels_inventory.py avec Python 3.10 ou supérieur. Le banc compare neuf dossiers et seize assertions. Il prépare une sélection à partir des observations fournies, mais ne contrôle ni les rôles du compte Amazon, ni les paramètres de format, ni le contenu des cartons. Les autres préconditions du départ restent à établir dans la recette réelle avant toute demande distante.
| Dossier fictif | Écart fourni | Décision locale |
|---|---|---|
| A | Deux associations confirmées et connues | Sélection prête, aucune étiquette imprimée |
| B | shipmentId 2024 dans le chemin v0 | Revoir l’identité d’expédition |
| C | Confirmation non observée | Attendre la propriété requise |
| D | Une page de cartons reste à obtenir | Attendre la liste complète |
| E | packageId employé comme boxId inconnu | Revoir la propriété sélectionnée |
| F | Le même contenant WMS apparaît deux fois | Revoir le doublon local |
| G | Deux contenants locaux pointent vers un boxId | Revoir l’association multiple |
| H | L’association vient d’une ancienne révision interne | Requalifier le dossier courant |
| I | Le rapprochement physique n’est pas confirmé | Reprendre la confirmation terrain |
Lire exactement ce que les assertions prouvent
Les neuf décisions sont obtenues. Les contrôles supplémentaires retrouvent les deux boxId sélectionnés, autorisent une sélection limitée à un seul contenant connu, refusent un autre vendeur, une sélection vide et une liste native supposée incohérente. Ils vérifient également que les associations d’entrée restent identiques et que le banc contient neuf dossiers. Ces seize assertions ne simulent pas une réponse Amazon.
Le cas E échoue parce que la valeur fournie n’appartient pas aux boxId observés. Le programme ne sait pas reconnaître universellement un type d’identifiant à sa forme. Le cas G porte une règle interne de rapprochement de deux contenants physiques distincts ; il ne décrit pas toutes les structures logistiques possibles du modèle. Le résultat nominal reste SELECTION_READY_NOT_LABEL_PRINTED, sans statut Expédié ni Reçu.
Reprendre la demande et le poste d’impression sans changer le carton
Qualifier le refus avant de remettre le lot dans la file
Un refus IncorrectPackageIdentifier demande d’abord la comparaison des propriétés envoyées avec leurs sources. Un incident d’autorisation, un format non admis ou une limitation de débit suit un autre diagnostic. Le worker conserve la réponse brute utile, la version d’interface et les paramètres non sensibles de la sélection. Il ne renomme pas tous les échecs en Problème d’impression, car leur prochaine action diffère.
Une queue de reprise peut isoler le départ et les cartons concernés. Son retry conserve la même intention et les références qualifiées tant que le dossier n’a pas changé. Le backoff traite une attente technique selon les règles de l’opération ; il ne transforme pas un identifiant erroné en valeur acceptable. Les refus persistants gardent leur motif et leur responsable, au lieu d’être relancés jusqu’à l’heure du ramassage.
Séparer la récupération du document de sa réimpression
Le poste retrouve un document reçu par son association au contenant et au dossier retenu. Il peut ensuite confirmer les étapes réellement observées par le dispositif d’impression. Si le document reste inconnu après une coupure, le support reprend sa récupération dans le même périmètre avant de décider du traitement du poste. Une page produite ne prouve pas qu’elle a été posée sur le bon carton.
L’idempotence locale de cette reprise concerne la commande du poste et la traçabilité des impressions ; elle n’est pas une garantie native attribuée à getLabels. Le journal conserve une corrélation interne, telle qu’un correlationId, sans publier jetons ou documents sensibles dans les logs partagés. Le runbook explique comment retrouver le travail, retirer une ancienne étiquette si la procédure l’exige et faire confirmer le contenant avant son départ.
Mesurer le blocage sans inventer un départ prêt à expédier
Conserver les statuts natifs à côté du suivi du poste
Le parcours officiel de création d’un envoi entrant précise que récupérer les étiquettes avec getLabels ne fait pas passer, à lui seul, le départ à ready_to_ship. La documentation indique un passage par la génération d’étiquettes dans Send to Amazon pour ce statut. Le suivi interne doit donc garder l’état effectivement observé, sans le remplacer par la fin d’un téléchargement.
Votre application peut afficher Document récupéré ou Pose confirmée lorsqu’elle possède les observations correspondantes. Elle garde également le statut Amazon, son origine et son instant de lecture. Ces états ne suffisent pas à certifier l’enlèvement transporteur, la livraison ou la réception des unités. L’ERP ne doit pas solder son dossier d’approvisionnement parce que le dernier fichier du lot est sorti de l’imprimante.
Calculer le travail de reprise sur vos propres observations
Exemple concret fictif : quinze cartons exigent chacun quatre minutes de recherche, puis cinq demandent deux minutes de reprise au poste. Le calcul représente soixante-dix minutes de travail. Il n’annonce aucune économie réalisée, pénalité Amazon ou coût transport. Il aide seulement à distinguer l’enquête de correspondance et l’opération physique, que votre équipe doit mesurer sur des dossiers réels.
Le monitoring suit les départs bloqués, les contenants concernés, les demandes refusées et les poses encore à confirmer. Une répétition de la même requête n’ajoute pas nécessairement un nouveau carton affecté. Rapprochez les événements au dossier et observez le plus ancien contenant en attente. La priorité dépend aussi du délai restant avant le ramassage, sans autoriser un carton mal identifié à partir pour tenir l’horaire. L’arbitrage pourra alors porter sur une correction du mapping, un ajustement du poste ou une amélioration de la procédure de préparation.
Erreurs fréquentes : corriger le fichier sans retrouver son contenant
Remplacer un champ par une valeur qui semble plausible
Le premier raccourci remplace boxId par packageId parce que le nom paraît plus proche du paramètre PackageLabelsToPrint. Le deuxième prend la référence du carton WMS comme si Amazon l’avait forcément conservée dans ce champ. Le troisième reconstruit le numéro depuis un préfixe d’expédition. Dans les trois cas, le correctif doit revenir à la propriété retournée et à une association qualifiée, pas à une intuition de format.
Un signal faible apparaît lorsque seul le premier carton du lot fonctionne, ou lorsque les réimpressions réussissent uniquement après une correction manuelle de la liste. Un autre apparaît quand plusieurs contenants physiques affichent le même document. Ces observations ne démontrent pas la cause à elles seules, mais elles imposent de relire pagination, unicité locale et provenance des références avant de remettre tout le départ en circulation.
Fermer le dossier dès que l’API ne renvoie plus d’erreur
Un document récupéré peut encore rester sur le poste, être imprimé plusieurs fois ou être posé sur le mauvais carton. La recette porte donc sur la relation entre contenant, document et préparation physique. Elle doit aussi qualifier le format retenu pour le marché et le parcours du départ. Un réglage utilisé ailleurs ne devient pas automatiquement une configuration valide pour cette demande.
La dernière erreur modifie le contenu du carton après l’impression tout en gardant la même confirmation interne. Retrouvez alors les déclarations, associations et documents qui demandent une revue. Le repli conserve le contenant en attente et ses preuves. Il évite de laisser le transport emporter un carton dont la description ou l’étiquette vient d’être rendue incertaine par une correction informatique.
Plan d’action : recetter un contenant de bout en bout avant le lot complet
Attribuer les données et les confirmations à leurs intervenants
Le vendeur qualifie le départ Amazon et les conditions qui lui sont applicables. Le mainteneur du WMS explique la référence physique et sa continuité pendant les changements de préparation. L’intégrateur décrit les lectures 2024, le passage vers getLabels v0 et les correspondances stockées. Le responsable entrepôt confirme comment le document sera retrouvé, imprimé et associé au carton dans le parcours réellement utilisé.
Le contrat conserve les entrées, les sorties et leurs preuves : périmètre vendeur, plan, expédition, confirmation, liste collectée et association. Si le fournisseur publie un schéma OpenAPI, comparez ses noms de propriétés à la version consommée par l’adaptateur. L’écran métier peut simplifier les libellés ; les traces doivent permettre de retrouver le champ natif sans reconstruire l’historique depuis un fichier corrigé à la main.
Éprouver les refus et décider l’extension
Commencez par un carton reconnaissable et un départ déjà qualifié. Faites ensuite varier un paramètre à la fois dans l’environnement de recette : identité d’expédition erronée, page manquante, association ancienne, carton inconnu et confirmation physique absente. Le dossier doit retrouver l’erreur attendue et la prochaine action. Une simulation locale réussie ne ferme pas la recette du connecteur distant ni celle du poste d’impression.
Le seuil d’arrêt intervient dès que deux contenants deviennent indiscernables dans le suivi, qu’une liste incomplète est annoncée complète ou qu’un document ne retrouve plus son association. Le repli suspend la sélection concernée, conserve les déclarations engagées et isole les cartons à reprendre. L’extension du pilote attend une procédure exécutable par le remplaçant, avec les accès et les observations dont il dispose réellement.
- À retrouver d’abord : l’origine de chaque identifiant et le plan auquel il appartient.
- À valider : une sélection de boxId issue d’une collecte complète et d’associations confirmées.
- À différer : le lot dont une correspondance physique reste ambiguë.
- À refuser : un départ déclaré expédié sur la seule récupération des étiquettes.
Lectures complémentaires : stock FBA, contrat SI et investigation
Replacer les étiquettes dans la chaîne d’approvisionnement
La lecture API Amazon FBA : stocks, MCF et statuts distingue les familles d’opérations du réseau fulfillment. Il complète le présent diagnostic lorsque l’étiquette est récupérée mais que le suivi doit encore expliquer départ entrant, inventaire et opérations sur les commandes clients.
Le contrat d’échange ERP–e-commerce organise correspondances, versions et reprises. Pour les cartons FBA, il aide à conserver le rôle de chaque propriété entre la préparation WMS, les réponses Amazon et le dossier interne d’approvisionnement.
Distinguer la recette du programme et celle du parcours distant
Le dossier API sandbox et environnements de test précise les limites d’une validation réalisée hors production. Les associations fictives du banc ne démontrent pas les droits d’un vendeur, les paramètres d’un départ réel ni le comportement du poste utilisé par votre entrepôt.
Le runbook d’incident API structure les éléments de diagnostic et la passation. Ici, le dossier doit rapprocher plan, expédition, carton et document, puis retrouver la dernière étape confirmée avant de remettre une demande ou un travail d’impression dans la file.
Conclusion : résoudre le refus sans perdre l’identité du carton
IncorrectPackageIdentifier doit mener à une comparaison des identifiants envoyés avec leur source. Le chemin getLabels v0 du parcours 2024 utilise shipmentConfirmationId ; sa sélection de cartons retrouve les boxId observés. La référence interne du WMS garde son association distincte.
Une collecte paginée complète et une correspondance qualifiée préparent la demande. Elles ne prouvent pas la récupération du document, son impression ou sa pose. Le suivi doit conserver ces observations et les statuts Amazon sans annoncer une réception de stock depuis le poste.
Les neuf dossiers fictifs et seize assertions éprouvent les refus de notre sélection locale. Aucun appel Amazon, PDF ou travail d’impression n’est exécuté. La recette réelle doit confirmer le parcours retenu avec le vendeur, le mainteneur et l’entrepôt.
Dawap accompagne l’intégration de vos applications métier à partir de ce parcours identifiable. Nous qualifions les correspondances, les réponses et les reprises avec vos équipes pour que le support puisse retrouver le bon carton et la prochaine action sans modifier des identifiants au hasard.
