Confirmer l'expédition Amazon depuis Odoo : le délai exigé et le suivi qui compte vraiment

Une commande Amazon ne se clôture pas quand le colis quitte l'entrepôt : elle se clôture quand Amazon reçoit la confirmation d'expédition avec son transporteur et son numéro de suivi. Jusque-là, la commande reste en attente pour Amazon, même si la marchandise est déjà en cours de livraison. Cet avis est un appel à l'API, et il est fait soit par votre ERP, soit par une personne qui recopie des numéros à la main.

Le délai est fixé par Amazon, et il y en a un par commande

Chaque commande arrive avec sa date limite d'expédition. Ce n'est ni une recommandation ni un objectif interne : c'est l'engagement qu'Amazon a pris auprès de l'acheteur en votre nom. Cette date doit passer de la commande au bon de livraison d'Odoo et être visible pour celui qui prépare, car dans l'entrepôt l'ordre qui compte est celui des dates limites, pas celui d'arrivée. Préparer dans l'ordre d'arrivée, c'est être en retard sur les commandes urgentes et en avance sur celles qui ne pressaient pas.

Que se passe-t-il quand vous confirmez en retard

Amazon mesure deux choses distinctes et les pénalise séparément : les expéditions confirmées après la date limite et les suivis qu'il ne peut pas tracer. Les seuils exacts sont publiés par Amazon dans le tableau de bord Santé du compte de Seller Central et révisés de temps à autre ; consultez-les donc là-bas et non dans un article. Ce qui est stable, c'est la conséquence : la métrique se dégrade, l'acheteur peut annuler sans frais et, si la situation se prolonge, la capacité de vente est restreinte.

En FBA, vous lisez le statut ; en FBM, vous l'écrivez

C'est la confusion la plus courante. Avec FBA, vous ne confirmez rien : Amazon prépare et expédie, et le numéro de suivi naît dans son système, pas dans le vôtre. Ce qu'il vous faut alors, c'est le chemin inverse : rapatrier ce statut dans Odoo pour que le bon de livraison se clôture. Avec FBM, c'est l'inverse : vous faites l'expédition et vous donnez l'avis, dans le délai. Une activité mixte fait les deux sur le même catalogue, et chaque commande doit savoir dès le départ de quel type elle est.

Le code transporteur détermine si le suivi compte

Amazon n'accepte pas n'importe quel texte dans le champ du transporteur : il a sa propre liste de codes et suit l'expédition d'après celui que vous déclarez. Si vous envoyez le bon numéro avec le mauvais transporteur, ou avec un code générique du type « autres », le suivi existe mais Amazon ne peut pas le suivre : pour la métrique, c'est comme si vous ne l'aviez pas envoyé. C'est pourquoi la correspondance entre votre transporteur Odoo et le code Amazon doit être une table explicite et modifiable, et non une chaîne écrite à la main dans le code.

Là où se rejoignent le connecteur de transport et celui de la marketplace

Le point de rencontre, c'est le bon de livraison. La séquence saine est la suivante : la commande arrive avec sa référence Amazon et sa date limite, elle est préparée, le bon de livraison est validé, le connecteur du transporteur demande l'étiquette et renvoie le numéro de suivi, et c'est seulement alors que le connecteur Amazon envoie la confirmation avec ce numéro et le bon code. Si vous inversez l'ordre, vous confirmez des expéditions qui n'ont pas encore d'étiquette. S'il n'y a aucun lien entre les deux, quelqu'un recopie des numéros à la main, et ce quelqu'un se trompe un mardi après-midi.

Le défaut que nous rencontrons le plus souvent en révisant des intégrations tierces se trouve précisément là : la confirmation est lancée en arrière-plan, échoue (erreur de l'API, jeton expiré, transporteur lent à fournir le numéro) et personne ne s'en aperçoit, parce que le bon de livraison d'Odoo est déjà validé et au vert. La confirmation doit laisser une trace sur la commande : envoyée, échouée, relancée. Une tâche qui échoue en silence est pire que l'absence d'intégration, car en plus elle vous donne confiance.

Une commande, deux colis

Les expéditions partielles sont le cas que presque personne ne prépare. Si une commande part en deux expéditions, Amazon attend deux confirmations avec leurs lignes et leurs quantités, et non une seule avec le suivi du premier colis. Dans Odoo, cela fait deux bons de livraison sur la même commande client, donc la correspondance doit se faire par ligne et non par commande. Bien la mettre en place dès le départ coûte peu ; la corriger après avoir mal confirmé deux cents commandes, beaucoup plus.

Quand il faut automatiser cela, et quand ce n'est pas nécessaire

Si vous expédiez dix commandes par jour et que vous les confirmez à la main dans Seller Central en cinq minutes, vous n'avez pas besoin d'une intégration pour cela : il vous faut une routine et un rappel. L'automatisation devient rentable quand recopier des numéros est déjà un travail à part entière, quand plusieurs transporteurs sont en jeu ou quand le même catalogue se vend à plusieurs endroits et que personne ne sait ce qui est parti. Vous dire le contraire serait vous vendre quelque chose dont vous n'avez pas besoin.

Le connecteur Amazon pour Odoo couvre ce volet : table de correspondance des transporteurs, confirmation par ligne avec numéro de suivi, statut de l'avis et dernière erreur d'Amazon directement sur le bon de livraison, relances automatiques et, en FBA, lecture du statut au lieu de son écriture. Il fonctionne sur Odoo 17, 18, 19 et 20. Les connecteurs de transporteurs se trouvent dans le catalogue de modules, et la façon de les mettre en place sans mauvaise surprise est expliquée dans étiquettes et suivi dans Odoo.

Questions fréquentes

Liens utiles chez FlexigoTech

Ce que nous faisons sur ce sujet