Problematiche comuni e best practice
In questa sezione vengono illustrate alcune delle problematiche più comuni che gli sviluppatori devono affrontare durante la creazione di integrazioni con connettori Gestione multicanale e vengono descritte alcune best practice che possono aiutarti nella risoluzione di tali problematiche.
Ricezione degli aggiornamenti sullo stato degli ordini
Problematica comune: talvolta gli sviluppatori riscontrano difficoltà nel leggere le notifiche relative a tutti gli aggiornamenti sullo stato degli ordini.
Best practice: utilizza uno dei due metodi seguenti per recuperare gli aggiornamenti sullo stato degli ordini:
1. Chiama l’API: chiama regolarmente l’API getOrder per gli aggiornamenti sullo stato degli ordini fino a quando l’ordine non raggiunge uno stato terminale [Completato, Completato parzialmente, Annullato, Non gestibile]. I dettagli di tracciabilità vengono condivisi nella risposta quando sono disponibili, ad esempio durante lo stato In elaborazione, Completato e Parzialmente completato.
2. Iscriviti alle notifiche: effettuando la sottoscrizione delle notifiche e rimanendo in ascolto dell’evento FULFILLMENT_ORDER_STATUS. Ogni volta che lo stato dell’ordine viene modificato o viene generato un numero di spedizione, viene emessa una notifica che deve essere letta da una coda SQS.
Le chiamate API sono un meccanismo pull e gli sviluppatori potrebbero non essere a conoscenza della frequenza delle chiamate API. È quindi consigliabile leggere le notifiche e chiamare l’API getOrder per i dettagli completi dell’ordine solo dopo che l’ordine è stato completato.
Seguendo questo approccio, puoi:
• Ridurre la larghezza di banda necessaria per chiamare le API di frequente.
• Acquisire informazioni sui dettagli di tracciabilità anticipati.
• Ricevere notifiche in tempo reale, poiché le chiamate API potrebbero subire ritardi.
• Ricevere notifiche sugli eventuali aggiornamenti dei numeri di spedizione, se presenti.
Best practice: utilizza uno dei due metodi seguenti per recuperare gli aggiornamenti sullo stato degli ordini:
1. Chiama l’API: chiama regolarmente l’API getOrder per gli aggiornamenti sullo stato degli ordini fino a quando l’ordine non raggiunge uno stato terminale [Completato, Completato parzialmente, Annullato, Non gestibile]. I dettagli di tracciabilità vengono condivisi nella risposta quando sono disponibili, ad esempio durante lo stato In elaborazione, Completato e Parzialmente completato.
2. Iscriviti alle notifiche: effettuando la sottoscrizione delle notifiche e rimanendo in ascolto dell’evento FULFILLMENT_ORDER_STATUS. Ogni volta che lo stato dell’ordine viene modificato o viene generato un numero di spedizione, viene emessa una notifica che deve essere letta da una coda SQS.
Le chiamate API sono un meccanismo pull e gli sviluppatori potrebbero non essere a conoscenza della frequenza delle chiamate API. È quindi consigliabile leggere le notifiche e chiamare l’API getOrder per i dettagli completi dell’ordine solo dopo che l’ordine è stato completato.
Seguendo questo approccio, puoi:
• Ridurre la larghezza di banda necessaria per chiamare le API di frequente.
• Acquisire informazioni sui dettagli di tracciabilità anticipati.
• Ricevere notifiche in tempo reale, poiché le chiamate API potrebbero subire ritardi.
• Ricevere notifiche sugli eventuali aggiornamenti dei numeri di spedizione, se presenti.
Sincronizzazione dell'inventario
Problematica comune: gli sviluppatori non interpretano correttamente il valore dell’inventario nel messaggio relativo all’inventario o non sanno come sincronizzare in modo appropriato l’inventario e quindi rischiare la vendita di prodotti non disponibili, l’esaurimento delle scorte o l’accumulo di inventario in eccesso.
Best practice: ti consigliamo di sottoscrivere il tipo di notifica FBA_INVENTORY_AVAILABILITY_CHANGES, che consente la sincronizzazione in tempo reale con l’inventario Amazon e riflette eventuali modifiche all’inventario. Per evitare di perdere le notifiche, è opportuno che gli sviluppatori chiamino l’API getInventorySummaries una volta al giorno per un’istantanea completa dei livelli di inventario.
La chiamata all’API GetInventorySummaries più di una volta al giorno può causare dati non aggiornati tra le chiamate API ed è un’operazione sconsigliata.
Per gli sviluppatori che utilizzano solo le API, suggeriamo di:
• Gestire un record interno personale dell’inventario, in base agli ordini ricevuti e annullati. Sarà quindi possibile sovrascrivere tale record durante il processo di sincronizzazione dell’inventario, che può essere eseguito una o due volte al giorno.
• Utilizzare alcune impostazioni per le scorte di sicurezza, per evitare di vendere prodotti non disponibili tra i processi di sincronizzazione dell’inventario.
Se sono interessati solo all'inventario DISPONIBILE (situato nei centri logistici Amazon), gli sviluppatori dovranno tenere sotto controllo InventorySummaries.Fulfillable.
Gli sviluppatori interessati a verificare gli articoli IN TRANSITO/IN INGRESSO dovranno eseguire la somma di: [inventoryDetails.Fulfillable + inventoryDetails.inboundWorkingQuantity+inventoryDetails.inboundShippedQuantity+inventoryDetails.inboundReceivingQuantity].
Nota: l’inventario IN TRANSITO/IN ENTRATA potrebbe avere una data di arrivo stimata più lunga rispetto all’inventario disponibile.
Best practice: ti consigliamo di sottoscrivere il tipo di notifica FBA_INVENTORY_AVAILABILITY_CHANGES, che consente la sincronizzazione in tempo reale con l’inventario Amazon e riflette eventuali modifiche all’inventario. Per evitare di perdere le notifiche, è opportuno che gli sviluppatori chiamino l’API getInventorySummaries una volta al giorno per un’istantanea completa dei livelli di inventario.
La chiamata all’API GetInventorySummaries più di una volta al giorno può causare dati non aggiornati tra le chiamate API ed è un’operazione sconsigliata.
Per gli sviluppatori che utilizzano solo le API, suggeriamo di:
• Gestire un record interno personale dell’inventario, in base agli ordini ricevuti e annullati. Sarà quindi possibile sovrascrivere tale record durante il processo di sincronizzazione dell’inventario, che può essere eseguito una o due volte al giorno.
• Utilizzare alcune impostazioni per le scorte di sicurezza, per evitare di vendere prodotti non disponibili tra i processi di sincronizzazione dell’inventario.
Se sono interessati solo all'inventario DISPONIBILE (situato nei centri logistici Amazon), gli sviluppatori dovranno tenere sotto controllo InventorySummaries.Fulfillable.
Gli sviluppatori interessati a verificare gli articoli IN TRANSITO/IN INGRESSO dovranno eseguire la somma di: [inventoryDetails.Fulfillable + inventoryDetails.inboundWorkingQuantity+inventoryDetails.inboundShippedQuantity+inventoryDetails.inboundReceivingQuantity].
Nota: l’inventario IN TRANSITO/IN ENTRATA potrebbe avere una data di arrivo stimata più lunga rispetto all’inventario disponibile.
Accesso anticipato alle informazioni di tracciabilità
Problematica comune: i numeri di spedizione sono ora disponibili anche se lo stato dell’ordine non è Spedizione completata.
Best practice: gli sviluppatori che chiamano l’API getOrder non devono presupporre che i dettagli di tracciabilità siano disponibili solo quando l’ordine è nello stato Completato o Completato parzialmente. I dettagli di tracciabilità saranno ora disponibili quando l’ordine è nella fase In elaborazione.
Per gli sviluppatori che rimangono in ascolto delle notifiche degli ordini, viene emessa esplicitamente una notifica con i dettagli di tracciabilità anticipati con lo stato dell’ordine come In elaborazione, che include il corriere, il numero del pacco e il numero di spedizione.
Spesso gli sviluppatori che chiamano l’API getOrder contrassegnano l’ordine come Evaso dopo aver utilizzato i dettagli di tracciabilità, ma potrebbero essere apportati ulteriori aggiornamenti ai dettagli di tracciabilità in caso di modifiche di localizzazione e mappatura simultanea (SLAM) presso un centro logistico. Se contrassegni gli ordini come Evasi, non riceverai alcun aggiornamento e i dettagli di tracciabilità in tuo possesso non saranno validi.
Assicurati di leggere le notifiche relative a FULFILLMENT_ORDER_STATUS, che inviano un evento per i dettagli di tracciabilità anticipati e anche per eventuali ulteriori aggiornamenti ai dettagli di tracciabilità, se presenti. Questo approccio garantirà che i venditori dispongano sempre dei dettagli di tracciabilità degli ordini corretti.
Best practice: gli sviluppatori che chiamano l’API getOrder non devono presupporre che i dettagli di tracciabilità siano disponibili solo quando l’ordine è nello stato Completato o Completato parzialmente. I dettagli di tracciabilità saranno ora disponibili quando l’ordine è nella fase In elaborazione.
Per gli sviluppatori che rimangono in ascolto delle notifiche degli ordini, viene emessa esplicitamente una notifica con i dettagli di tracciabilità anticipati con lo stato dell’ordine come In elaborazione, che include il corriere, il numero del pacco e il numero di spedizione.
Spesso gli sviluppatori che chiamano l’API getOrder contrassegnano l’ordine come Evaso dopo aver utilizzato i dettagli di tracciabilità, ma potrebbero essere apportati ulteriori aggiornamenti ai dettagli di tracciabilità in caso di modifiche di localizzazione e mappatura simultanea (SLAM) presso un centro logistico. Se contrassegni gli ordini come Evasi, non riceverai alcun aggiornamento e i dettagli di tracciabilità in tuo possesso non saranno validi.
Assicurati di leggere le notifiche relative a FULFILLMENT_ORDER_STATUS, che inviano un evento per i dettagli di tracciabilità anticipati e anche per eventuali ulteriori aggiornamenti ai dettagli di tracciabilità, se presenti. Questo approccio garantirà che i venditori dispongano sempre dei dettagli di tracciabilità degli ordini corretti.
Utilizzo delle funzionalità per imballaggi senza marchio (pacco senza marchio) e Blocco di Logistica di Amazon
Problematica comune: gli sviluppatori non sanno come configurare le funzionalità per imballaggi senza marchio e Blocco di Logistica di Amazon.
Best practice: Gestione multicanale consegna la maggior parte degli ordini in imballaggi senza marchio all’interno dell’area geografica degli Stati Uniti, ma alcuni venditori potrebbero richiedere che tutti gli ordini vengano consegnati in pacchi senza marchio.
Pacchi senza marchio:
1. utilizza un flag a livello di SKU per contrassegnare i pacchi senza marchio come SKU solo Pacchi senza marchio. Puoi visualizzare i tuoi prodotti idonei per Pacchi senza marchio chiamando l’API getFeatureInventory.
2. Per gli SKU solo Pacchi senza marchio, assicurati di monitorare sia l’inventario con imballaggi senza marchio sia l’inventario normale.
3. Imposta l’opzione a livello di canale di vendita e assicurati che i canali di vendita appropriati controllino sempre l’inventario per i pacchi senza marchio. Crea ordini per Pacchi senza marchio e trasmetti l’inventario dei prodotti con pacco senza marchio a questi canali di vendita.
4. A livello di elaborazione degli ordini, chiama le operazioni PREVIEW Order e CREATE Order con il vincolo di funzionalità Blank_Box=Required, per garantire che gli articoli vengano consegnati solo in pacchi senza marchio.
Blocco di Logistica di Amazon:
nei portali Seller Central e Supply Chain è disponibile un'impostazione Blocco di Logistica di Amazon a livello di marketplace dell’account venditore, che può essere attivata per tutti gli ordini e prevede un supplemento del 5%. Gli sviluppatori che hanno un requisito di Blocco di Logistica di Amazon per ordini specifici possono utilizzare i seguenti passaggi di configurazione:
1. Imposta l’opzione a livello di canale di vendita per assicurarti che gli ordini dei canali di vendita specificati non vengano consegnati tramite Logistica di Amazon. Crea ordini con Blocco di Logistica di Amazon per questi canali.
2. A livello di elaborazione dell’ordine, chiama l’operazione PREVIEW Order e CREATE Order con il vincolo di funzionalità Block_AMZL=Required per garantire che gli articoli vengano spediti da un corriere diverso da Logistica di Amazon.
Best practice: Gestione multicanale consegna la maggior parte degli ordini in imballaggi senza marchio all’interno dell’area geografica degli Stati Uniti, ma alcuni venditori potrebbero richiedere che tutti gli ordini vengano consegnati in pacchi senza marchio.
Pacchi senza marchio:
1. utilizza un flag a livello di SKU per contrassegnare i pacchi senza marchio come SKU solo Pacchi senza marchio. Puoi visualizzare i tuoi prodotti idonei per Pacchi senza marchio chiamando l’API getFeatureInventory.
2. Per gli SKU solo Pacchi senza marchio, assicurati di monitorare sia l’inventario con imballaggi senza marchio sia l’inventario normale.
3. Imposta l’opzione a livello di canale di vendita e assicurati che i canali di vendita appropriati controllino sempre l’inventario per i pacchi senza marchio. Crea ordini per Pacchi senza marchio e trasmetti l’inventario dei prodotti con pacco senza marchio a questi canali di vendita.
4. A livello di elaborazione degli ordini, chiama le operazioni PREVIEW Order e CREATE Order con il vincolo di funzionalità Blank_Box=Required, per garantire che gli articoli vengano consegnati solo in pacchi senza marchio.
Blocco di Logistica di Amazon:
nei portali Seller Central e Supply Chain è disponibile un'impostazione Blocco di Logistica di Amazon a livello di marketplace dell’account venditore, che può essere attivata per tutti gli ordini e prevede un supplemento del 5%. Gli sviluppatori che hanno un requisito di Blocco di Logistica di Amazon per ordini specifici possono utilizzare i seguenti passaggi di configurazione:
1. Imposta l’opzione a livello di canale di vendita per assicurarti che gli ordini dei canali di vendita specificati non vengano consegnati tramite Logistica di Amazon. Crea ordini con Blocco di Logistica di Amazon per questi canali.
2. A livello di elaborazione dell’ordine, chiama l’operazione PREVIEW Order e CREATE Order con il vincolo di funzionalità Block_AMZL=Required per garantire che gli articoli vengano spediti da un corriere diverso da Logistica di Amazon.
Test del flusso di autorizzazione in un’app pubblica
Problematica comune: gli sviluppatori non sanno come testare il flusso di autenticazione del venditore senza pubblicare l’app in Seller Central.
Best practice: gli sviluppatori possono convalidare il flusso di autenticazione di un account venditore di prova senza dover pubblicare l’app. Verifica il tuo flusso di autenticazione aggiungendo ”version=beta” all’URL di consenso di Seller Central sia per il flusso di autenticazione di Seller Central che per il flusso di autenticazione del webstore. Nota: nella modalità beta, non più di 25 venditori possono autorizzare l’app in quanto questa operazione è intesa solo per scopi di convalida.
Esempio:https://sellercentral.amazon.com/apps/authorize/consent?application_id=appidexample&state=stateexample&version=beta
Best practice: gli sviluppatori possono convalidare il flusso di autenticazione di un account venditore di prova senza dover pubblicare l’app. Verifica il tuo flusso di autenticazione aggiungendo ”version=beta” all’URL di consenso di Seller Central sia per il flusso di autenticazione di Seller Central che per il flusso di autenticazione del webstore. Nota: nella modalità beta, non più di 25 venditori possono autorizzare l’app in quanto questa operazione è intesa solo per scopi di convalida.
Esempio:https://sellercentral.amazon.com/apps/authorize/consent?application_id=appidexample&state=stateexample&version=beta
Estrazione dei report essenziali per gli sviluppatori di Gestione multicanale
Problematica comune: gli sviluppatori non sono a conoscenza dei report che si possono estrarre tramite l’API Report.
Best practice: utilizza le informazioni sulla chiamata riportate di seguito per estrarre i report principali per gli sviluppatori di Gestione multicanale.
Report principali per gli sviluppatori di Gestione multicanale:
• Report sulle offerte: per ottenere i dati delle offerte di prodotti di un account venditore.
GET_FLAT_FILE_OPEN_LISTINGS_DATA e GET_MERCHANT_LISTINGS_ALL_DATA
• Report sull'inventario: per tenere sotto controllo la movimentazione dell’inventario presso i centri logistici Amazon.
GET_FBA_MYI_UNSUPPRESSED_INVENTORY_DATA e GET_LEDGER_SUMMARY_VIEW_DATA
• Report su ordini/vendite: per recuperare tutti i dati sugli ordini e sulle spedizioni gestiti da Amazon.
GET_XML_ALL_ORDERS_DATA_BY_ORDER_DATE_GENERAL, GET_FLAT_FILE_ALL_ORDERS_DATA_BY_ORDER_DATE_GENERAL e GET_AMAZON_FULFILLED_SHIPMENTS_DATA_GENERAL
Best practice: utilizza le informazioni sulla chiamata riportate di seguito per estrarre i report principali per gli sviluppatori di Gestione multicanale.
Report principali per gli sviluppatori di Gestione multicanale:
• Report sulle offerte: per ottenere i dati delle offerte di prodotti di un account venditore.
GET_FLAT_FILE_OPEN_LISTINGS_DATA e GET_MERCHANT_LISTINGS_ALL_DATA
• Report sull'inventario: per tenere sotto controllo la movimentazione dell’inventario presso i centri logistici Amazon.
GET_FBA_MYI_UNSUPPRESSED_INVENTORY_DATA e GET_LEDGER_SUMMARY_VIEW_DATA
• Report su ordini/vendite: per recuperare tutti i dati sugli ordini e sulle spedizioni gestiti da Amazon.
GET_XML_ALL_ORDERS_DATA_BY_ORDER_DATE_GENERAL, GET_FLAT_FILE_ALL_ORDERS_DATA_BY_ORDER_DATE_GENERAL e GET_AMAZON_FULFILLED_SHIPMENTS_DATA_GENERAL
Gestione delle credenziali per l’accesso all’ambiente Sandbox
Problematica comune: gli sviluppatori desiderano gestire diverse credenziali di app per l'ambiente Sandbox dinamico e l’ambiente di Produzione.
Sia per le app private che per quelle pubbliche, è possibile limitare l’accesso solo per l'ambiente Sandbox dinamico. Qualsiasi app approvata per la produzione avrà accesso agli endpoint Produzione e Sandbox e non è possibile limitare l’accesso.
Best practice: per risolvere il problema, gli sviluppatori possono creare diverse app private in stato BOZZA per gli ambienti Sandbox e Produzione e pubblicare i prodotti solo in Produzione, se intendono gestire due set separati di credenziali client.
Sia per le app private che per quelle pubbliche, è possibile limitare l’accesso solo per l'ambiente Sandbox dinamico. Qualsiasi app approvata per la produzione avrà accesso agli endpoint Produzione e Sandbox e non è possibile limitare l’accesso.
Best practice: per risolvere il problema, gli sviluppatori possono creare diverse app private in stato BOZZA per gli ambienti Sandbox e Produzione e pubblicare i prodotti solo in Produzione, se intendono gestire due set separati di credenziali client.
