Défis courants et meilleures pratiques
Dans cette section, nous mettons en évidence certains des défis courants auxquels les développeurs sont confrontés lors de la création d'intégrations de connecteurs Ventes Multi-Sites, et expliquons certaines des meilleures pratiques qui peuvent vous aider à surmonter ces défis.
Obtenir des mises à jour sur l'état des commandes
Défi commun : les développeurs rencontrent parfois des difficultés pour lire toutes les notifications des mises à jour concernant l'état des commandes.
Meilleure pratique : utilisez l'une des deux méthodes suivantes pour accéder aux mises à jour de l'état des commandes :
1. Appelez l'API : appelez régulièrement l'API getOrder pour obtenir des mises à jour sur l'état des commandes jusqu'à ce que le statut du terminal [Terminée, Partiellement terminée, Annulée, Non expédiable] soit atteint pour la commande. Une fois disponibles, les informations de suivi sont partagées dans la réponse et cela peut se faire lorsque la commande est au statut Traitement en cours, Terminée et Partiellement terminée.
2. Abonnez-vous aux notifications : abonnez-vous aux notifications et tenez-vous informé concernant l'événement FULFILLMENT_ORDER_STATUS. Chaque fois que le statut de la commande change ou qu'un numéro de suivi est généré, une notification est émise et celle-ci qui doit être lue s'ajoute à une file d'attente SQS.
L'appel d'API représente un mécanisme d'extraction et les développeurs peuvent ne pas être conscients de la fréquence des appels d'API. La pratique suggérée consiste à lire les notifications et à appeler uniquement l'API getOrder pour obtenir tous les détails des commandes une fois celles-ci terminées.
En suivant cette approche, vous pouvez :
• réduire la bande passante requise pour appeler fréquemment les API ;
• prendre connaissance des détails du suivi anticipé ;
• recevoir des notifications en temps réel, dans la mesure où les appels d'API peuvent être retardés ;
• recevoir des notifications concernant les mises à jour des numéros de suivi, le cas échéant
Meilleure pratique : utilisez l'une des deux méthodes suivantes pour accéder aux mises à jour de l'état des commandes :
1. Appelez l'API : appelez régulièrement l'API getOrder pour obtenir des mises à jour sur l'état des commandes jusqu'à ce que le statut du terminal [Terminée, Partiellement terminée, Annulée, Non expédiable] soit atteint pour la commande. Une fois disponibles, les informations de suivi sont partagées dans la réponse et cela peut se faire lorsque la commande est au statut Traitement en cours, Terminée et Partiellement terminée.
2. Abonnez-vous aux notifications : abonnez-vous aux notifications et tenez-vous informé concernant l'événement FULFILLMENT_ORDER_STATUS. Chaque fois que le statut de la commande change ou qu'un numéro de suivi est généré, une notification est émise et celle-ci qui doit être lue s'ajoute à une file d'attente SQS.
L'appel d'API représente un mécanisme d'extraction et les développeurs peuvent ne pas être conscients de la fréquence des appels d'API. La pratique suggérée consiste à lire les notifications et à appeler uniquement l'API getOrder pour obtenir tous les détails des commandes une fois celles-ci terminées.
En suivant cette approche, vous pouvez :
• réduire la bande passante requise pour appeler fréquemment les API ;
• prendre connaissance des détails du suivi anticipé ;
• recevoir des notifications en temps réel, dans la mesure où les appels d'API peuvent être retardés ;
• recevoir des notifications concernant les mises à jour des numéros de suivi, le cas échéant
Synchroniser des stocks
Défi commun : les développeurs rencontrent des difficultés pour interpréter la valeur du stock dans le message de stock ou ne savent pas comment le synchroniser correctement, ce qui peut entraîner des surventes et des ruptures de stock ou un excédent de stock.
Meilleure pratique : nous vous recommandons de vous abonner au type de notification FBA_INVENTORY_AVAILABILITY_CHANGES, qui permet une synchronisation en temps réel avec le stock Amazon et reflète toute modification de stock. Pour ne manquer aucune notification, les développeurs doivent appeler l'API getInventorySummaries une fois par jour pour obtenir un aperçu complet des niveaux de stock.
Notez qu'appeler l'API getInventorySummaries plus d'une fois par jour peut entraîner la perte de données entre les appels et n'est pas recommandé.
Nous suggérons aux développeurs qui s'appuient uniquement sur l'API :
• de tenir leur propre stock interne à jour, en fonction des commandes passées et annulées. Ils peuvent ensuite remplacer cet enregistrement dans le cadre du processus de synchronisation du stock, qui peut être effectué une ou deux fois par jour ;
• d'utiliser certains paramètres de stock de sécurité, afin d'éviter les surventes entre les tâches de synchronisation des stocks.
Les développeurs qui s’intéressent uniquement au stock DÉTENU (situé dans les centres de distribution Amazon) doivent rechercher inventorySummaries.Fulfillable.
En revanche, les développeurs qui souhaitent compter les articles EN TRANSIT/ENTRANTS doivent procéder au calcul suivant : [inventoryDetails.Fulfillable + inventoryDetails.inboundWorkingQuantity+inventoryDetails.inboundShippedQuantity+inventoryDetails.inboundReceivingQuantity].
Remarque : la date d'arrivée estimée du stock EN TRANSIT/ENTRANT peut être plus éloignée que celle du stock DÉTENU.
Meilleure pratique : nous vous recommandons de vous abonner au type de notification FBA_INVENTORY_AVAILABILITY_CHANGES, qui permet une synchronisation en temps réel avec le stock Amazon et reflète toute modification de stock. Pour ne manquer aucune notification, les développeurs doivent appeler l'API getInventorySummaries une fois par jour pour obtenir un aperçu complet des niveaux de stock.
Notez qu'appeler l'API getInventorySummaries plus d'une fois par jour peut entraîner la perte de données entre les appels et n'est pas recommandé.
Nous suggérons aux développeurs qui s'appuient uniquement sur l'API :
• de tenir leur propre stock interne à jour, en fonction des commandes passées et annulées. Ils peuvent ensuite remplacer cet enregistrement dans le cadre du processus de synchronisation du stock, qui peut être effectué une ou deux fois par jour ;
• d'utiliser certains paramètres de stock de sécurité, afin d'éviter les surventes entre les tâches de synchronisation des stocks.
Les développeurs qui s’intéressent uniquement au stock DÉTENU (situé dans les centres de distribution Amazon) doivent rechercher inventorySummaries.Fulfillable.
En revanche, les développeurs qui souhaitent compter les articles EN TRANSIT/ENTRANTS doivent procéder au calcul suivant : [inventoryDetails.Fulfillable + inventoryDetails.inboundWorkingQuantity+inventoryDetails.inboundShippedQuantity+inventoryDetails.inboundReceivingQuantity].
Remarque : la date d'arrivée estimée du stock EN TRANSIT/ENTRANT peut être plus éloignée que celle du stock DÉTENU.
Accéder aux informations du suivi anticipé
Défi commun : les numéros de suivi sont désormais disponibles avant même que l'expédition de la commande ne soit terminée.
Meilleure pratique : les développeurs qui appellent l'API getOrder ne doivent pas partir du principe que les informations de suivi sont uniquement disponibles lorsque la commande est au statut Complete ou CompletePartialled. Les informations de suivi seront désormais disponibles dès que la commande est au statut Processing.
Pour les développeurs qui s'appuient sur les notifications de commande : une notification est explicitement émise avec les détails de suivi anticipé accompagnés du statut de la commande Traitement en cours, du transporteur, du numéro de colis et du numéro de suivi.
Les développeurs qui appellent l'API getOrder marquent souvent leur commande comme Expédiée une fois qu'ils ont généré les informations de suivi, toutefois ces informations peuvent encore être mises à jour lorsque des modifications sont apportées à un centre de distribution. Si vous marquez les commandes comme Expédiée, vous ne recevrez aucune mise à jour et les informations de suivi seront invalides.
Veillez à lire les notifications FULFILLMENT_ORDER_STATUS contenant les détails du suivi anticipé ainsi que toute mise à jour des informations de suivi, le cas échéant. En tant que vendeur, vous disposerez ainsi toujours des informations de suivi correctes sur les commandes.
Meilleure pratique : les développeurs qui appellent l'API getOrder ne doivent pas partir du principe que les informations de suivi sont uniquement disponibles lorsque la commande est au statut Complete ou CompletePartialled. Les informations de suivi seront désormais disponibles dès que la commande est au statut Processing.
Pour les développeurs qui s'appuient sur les notifications de commande : une notification est explicitement émise avec les détails de suivi anticipé accompagnés du statut de la commande Traitement en cours, du transporteur, du numéro de colis et du numéro de suivi.
Les développeurs qui appellent l'API getOrder marquent souvent leur commande comme Expédiée une fois qu'ils ont généré les informations de suivi, toutefois ces informations peuvent encore être mises à jour lorsque des modifications sont apportées à un centre de distribution. Si vous marquez les commandes comme Expédiée, vous ne recevrez aucune mise à jour et les informations de suivi seront invalides.
Veillez à lire les notifications FULFILLMENT_ORDER_STATUS contenant les détails du suivi anticipé ainsi que toute mise à jour des informations de suivi, le cas échéant. En tant que vendeur, vous disposerez ainsi toujours des informations de suivi correctes sur les commandes.
Utiliser des fonctionnalités d'emballage sans marque (Boîte neutre) et de blocage d'Amazon Logistics
Défi commun : les développeurs ne savent pas comment configurer les fonctionnalités d'emballage sans marque et de blocage d'Amazon Logistics.
Meilleure pratique : le service Ventes Multi-Sites livre la plupart des commandes dans des emballages sans marque dans la région des États-Unis, toutefois certains vendeurs peuvent exiger que toutes leurs commandes soient livrées uniquement dans des emballages sans marque.
Emballages sans marque (Boîtes neutres ou BN) :
1. signalez les SKU qui requièrent des emballages sans marque comme des SKU nécessitant des Boîtes neutres (BN) uniquement. Vous pouvez consulter vos produits éligibles aux Boîtes neutres en appelant l'API getFeatureInventory.
2. Pour les SKU nécessitant des Boîtes neutres (BN) uniquement, assurez-vous de suivre à la fois les emballages sans marque (Boîtes neutres ou BB) ainsi que le stock régulier.
3. Activez le paramètre au niveau du canal de vente et veillez à ce que les canaux de vente requis consultent toujours le stock de BN. Créez des commandes BN et transmettez le stock BN vers ces canaux de vente.
4. Au niveau opérationnel des commandes, appelez les opérations PREVIEW Order et CREATE Order avec la contrainte de fonctionnalité Blank_Box=Required afin de vous assurer que les articles sont livrés uniquement dans des emballages sans marque.
Blocage d'Amazon Logistics (Blocage AMZL ou BAMZL) :
Seller Central et le portail de la chaîne d'approvisionnement proposent tous deux un paramètre Blocage AMZL au niveau du site de vente d'un compte vendeur, qui peut être activé pour toutes les commandes, moyennant un supplément de 5 %. Les développeurs qui souhaitent en profiter pour des commandes spécifiques peuvent suivre les étapes de configuration suivantes :
1. Activer cette option au niveau du canal de vente pour s'assurer que les commandes des canaux de vente requis ne sont pas livrées par Amazon Logistics, puis créer des commandes BAMZL pour ces chaînes.
2. Au niveau opérationnel des commandes, appelez les opérations PREVIEW Order et CREATE Order avec la contrainte de fonctionnalité Block_AMZL=Required afin de vous assurer qu'un autre transporteur qu'Amazon Logistics expédie les articles.
Meilleure pratique : le service Ventes Multi-Sites livre la plupart des commandes dans des emballages sans marque dans la région des États-Unis, toutefois certains vendeurs peuvent exiger que toutes leurs commandes soient livrées uniquement dans des emballages sans marque.
Emballages sans marque (Boîtes neutres ou BN) :
1. signalez les SKU qui requièrent des emballages sans marque comme des SKU nécessitant des Boîtes neutres (BN) uniquement. Vous pouvez consulter vos produits éligibles aux Boîtes neutres en appelant l'API getFeatureInventory.
2. Pour les SKU nécessitant des Boîtes neutres (BN) uniquement, assurez-vous de suivre à la fois les emballages sans marque (Boîtes neutres ou BB) ainsi que le stock régulier.
3. Activez le paramètre au niveau du canal de vente et veillez à ce que les canaux de vente requis consultent toujours le stock de BN. Créez des commandes BN et transmettez le stock BN vers ces canaux de vente.
4. Au niveau opérationnel des commandes, appelez les opérations PREVIEW Order et CREATE Order avec la contrainte de fonctionnalité Blank_Box=Required afin de vous assurer que les articles sont livrés uniquement dans des emballages sans marque.
Blocage d'Amazon Logistics (Blocage AMZL ou BAMZL) :
Seller Central et le portail de la chaîne d'approvisionnement proposent tous deux un paramètre Blocage AMZL au niveau du site de vente d'un compte vendeur, qui peut être activé pour toutes les commandes, moyennant un supplément de 5 %. Les développeurs qui souhaitent en profiter pour des commandes spécifiques peuvent suivre les étapes de configuration suivantes :
1. Activer cette option au niveau du canal de vente pour s'assurer que les commandes des canaux de vente requis ne sont pas livrées par Amazon Logistics, puis créer des commandes BAMZL pour ces chaînes.
2. Au niveau opérationnel des commandes, appelez les opérations PREVIEW Order et CREATE Order avec la contrainte de fonctionnalité Block_AMZL=Required afin de vous assurer qu'un autre transporteur qu'Amazon Logistics expédie les articles.
Tester le flux d'autorisation sur une application publique
Défi commun : les développeurs ne savent pas comment tester leur flux d'autorisation des vendeurs sans publier ou répertorier l'application dans Seller Central.
Meilleure pratique : les développeurs peuvent valider le flux d'authentification d'un compte Test Seller sans avoir à publier l'application. Testez votre flux d'authentification en ajoutant « version=beta » à l'URL d'autorisation de Seller Central, à la fois pour le flux d'authentification de Seller Central et pour le flux d'authentification de la boutique en ligne. Remarque : en mode bêta, 25 vendeurs maximum peuvent autoriser l'application, dans la mesure où cela n'est prévu qu'à des fins de validation.
Exemple :
https://sellercentral.amazon.com/apps/authorize/consent?application_id=appidexample&state=stateexample&version=beta
Meilleure pratique : les développeurs peuvent valider le flux d'authentification d'un compte Test Seller sans avoir à publier l'application. Testez votre flux d'authentification en ajoutant « version=beta » à l'URL d'autorisation de Seller Central, à la fois pour le flux d'authentification de Seller Central et pour le flux d'authentification de la boutique en ligne. Remarque : en mode bêta, 25 vendeurs maximum peuvent autoriser l'application, dans la mesure où cela n'est prévu qu'à des fins de validation.
Exemple :
https://sellercentral.amazon.com/apps/authorize/consent?application_id=appidexample&state=stateexample&version=beta
Extraire des rapports essentiels pour les développeurs Ventes Multi-Sites
Défi commun : les développeurs n'ont pas connaissance des rapports qui peuvent être extraits à l'aide de notre API Rapports.
Meilleure pratique : utilisez les informations d'appel ci-dessous pour extraire les principaux rapports destinés aux développeurs Ventes Multi-Sites.
Principaux rapports destinés aux développeurs Ventes Multi-Sites :
• Rapports sur les offres : permet d'obtenir les données relatives aux listings de produits d'un compte vendeur.
GET_FLAT_FILE_OPEN_LISTINGS_DATA et GET_MERCHANT_LISTINGS_ALL_DATA
• Rapports de stock : permet de suivre les mouvements de stock dans les centres de distribution Amazon.
GET_FBA_MYI_UNSUPPRESSED_INVENTORY_DATA et GET_LEDGER_SUMMARY_VIEW_DATA
• Rapports sur les commandes/ventes : permet de récupérer toutes les données relatives aux commandes et aux expéditions Expédié par Amazon.
GET_XML_ALL_ORDERS_DATA_BY_ORDER_DATE_GENERAL, GET_FLAT_FILE_ALL_ORDERS_DATA_BY_ORDER_DATE_GENERAL et GET_AMAZON_FULFILLED_SHIPMENTS_DATA_GENERAL
Meilleure pratique : utilisez les informations d'appel ci-dessous pour extraire les principaux rapports destinés aux développeurs Ventes Multi-Sites.
Principaux rapports destinés aux développeurs Ventes Multi-Sites :
• Rapports sur les offres : permet d'obtenir les données relatives aux listings de produits d'un compte vendeur.
GET_FLAT_FILE_OPEN_LISTINGS_DATA et GET_MERCHANT_LISTINGS_ALL_DATA
• Rapports de stock : permet de suivre les mouvements de stock dans les centres de distribution Amazon.
GET_FBA_MYI_UNSUPPRESSED_INVENTORY_DATA et GET_LEDGER_SUMMARY_VIEW_DATA
• Rapports sur les commandes/ventes : permet de récupérer toutes les données relatives aux commandes et aux expéditions Expédié par Amazon.
GET_XML_ALL_ORDERS_DATA_BY_ORDER_DATE_GENERAL, GET_FLAT_FILE_ALL_ORDERS_DATA_BY_ORDER_DATE_GENERAL et GET_AMAZON_FULFILLED_SHIPMENTS_DATA_GENERAL
Gérer les identifiants permettant d'accéder à Sandbox
Défi commun : les développeurs souhaitent conserver différents identifiants d'application pour l'environnement Dynamic Sandbox et l'environnement Production.
Pour les applications privées et publiques, il existe un moyen de limiter l'accès uniquement à l'environnement Dynamic Sandbox. Toute application approuvée pour la production aura accès aux endpoints Production et Sandbox. Notez également que la restriction d'accès est impossible.
Meilleure pratique : pour résoudre le problème, les développeurs peuvent créer différentes applications privées au statut BROUILLON pour les environnements Sandbox et Production et répertorier les produits uniquement dans Production s'ils souhaitent conserver deux ensembles distincts d'identifiants client.
Pour les applications privées et publiques, il existe un moyen de limiter l'accès uniquement à l'environnement Dynamic Sandbox. Toute application approuvée pour la production aura accès aux endpoints Production et Sandbox. Notez également que la restriction d'accès est impossible.
Meilleure pratique : pour résoudre le problème, les développeurs peuvent créer différentes applications privées au statut BROUILLON pour les environnements Sandbox et Production et répertorier les produits uniquement dans Production s'ils souhaitent conserver deux ensembles distincts d'identifiants client.
