Desafíos comunes y prácticas recomendadas
En esta sección, destacamos algunos de los desafíos comunes a los que se enfrentan los desarrolladores al crear integraciones de conector Logística Multicanal y explicamos algunas de las prácticas recomendadas que pueden ayudar a superar estos desafíos.
Recepción de actualizaciones del estado de los pedidos
Desafío común: los desarrolladores a veces tienen dificultades para leer las notificaciones de todas las actualizaciones del estado de los pedidos.
Prácticas recomendadas: utiliza uno de los dos métodos siguientes para obtener las actualizaciones del estado de los pedidos:
1. Llama a la API: llama regularmente a la API getOrder para actualizar el estado de los pedidos hasta que el estado de la terminal sea [Completo, Completo parcialmente, Cancelado, No apto para envío] en el pedido. Los detalles del seguimiento se comparten en la respuesta cuando está disponible, lo que puede ocurrir durante los estados Procesado, Completado y Parcialmente completado.
2. Suscríbete a las notificaciones: al suscribirte a las notificaciones y estar al tanto del evento FULFILLMENT_ORDER_STATUS. Cada vez que se produce un cambio en el estado del pedido o se genera un número de seguimiento, se emite una notificación que debe leerse desde una cola de SQS.
Las llamadas a la API son un mecanismo de extracción y es posible que los desarrolladores no conozcan la frecuencia de estas llamadas. La práctica sugerida es leer las notificaciones y solo llamar a la API getOrder para obtener todos los detalles del pedido una vez que se haya completado.
Si sigues este enfoque, puedes:
• Reducir el ancho de banda necesario para llamar a las API con frecuencia.
• Conocer los detalles del seguimiento anticipado.
• Recibir notificaciones en tiempo real, ya que las llamadas a la API pueden retrasarse.
• Recibir notificaciones de las actualizaciones de los números de seguimiento, si las hubiera.
Prácticas recomendadas: utiliza uno de los dos métodos siguientes para obtener las actualizaciones del estado de los pedidos:
1. Llama a la API: llama regularmente a la API getOrder para actualizar el estado de los pedidos hasta que el estado de la terminal sea [Completo, Completo parcialmente, Cancelado, No apto para envío] en el pedido. Los detalles del seguimiento se comparten en la respuesta cuando está disponible, lo que puede ocurrir durante los estados Procesado, Completado y Parcialmente completado.
2. Suscríbete a las notificaciones: al suscribirte a las notificaciones y estar al tanto del evento FULFILLMENT_ORDER_STATUS. Cada vez que se produce un cambio en el estado del pedido o se genera un número de seguimiento, se emite una notificación que debe leerse desde una cola de SQS.
Las llamadas a la API son un mecanismo de extracción y es posible que los desarrolladores no conozcan la frecuencia de estas llamadas. La práctica sugerida es leer las notificaciones y solo llamar a la API getOrder para obtener todos los detalles del pedido una vez que se haya completado.
Si sigues este enfoque, puedes:
• Reducir el ancho de banda necesario para llamar a las API con frecuencia.
• Conocer los detalles del seguimiento anticipado.
• Recibir notificaciones en tiempo real, ya que las llamadas a la API pueden retrasarse.
• Recibir notificaciones de las actualizaciones de los números de seguimiento, si las hubiera.
Sincronización del inventario
Desafío común: los desarrolladores malinterpretan el valor del inventario en el mensaje de inventario o no saben cómo sincronizarlo correctamente, lo que puede provocar sobreventas y desabastecimiento o exceso de inventario.
Prácticas recomendadas: Te recomendamos suscribirte al tipo de notificación FBA_INVENTORY_AVAILABILITY_CHANGES, que permite la sincronización en tiempo real con el inventario de Amazon y refleja cualquier cambio en el mismo. Para evitar que se pierda ninguna notificación, los desarrolladores deben llamar a la API getInventorySummaries una vez al día para obtener una instantánea completa de los niveles de inventario.
Llamar a la API getInventorySummaries más de una vez al día puede generar datos obsoletos entre las llamadas a la API y no se recomienda hacerlo.
Para los desarrolladores que solo usan la API, sugerimos:
• Mantener tu propio registro interno de inventario, en función de los pedidos realizados y cancelados. A continuación, puedes sobrescribir ese registro durante el proceso de sincronización del inventario, que se puede realizar una o dos veces al día.
• Utilizar una configuración de inventario de seguridad, de modo que no se produzcan ventas excesivas entre los trabajos de sincronización de inventario.
Si están interesados solo en el inventario en mano (ubicado en los centros logísticos de Amazon), en respuesta, los desarrolladores deberían hacer un seguimiento de inventorySummaries.Fulfillable.
Para los desarrolladores interesados en contabilizar los productos que están EN TRÁNSITO/EN ENVÍO, deben sumar: [inventoryDetails.Fulfillable + inventoryDetails.inboundWorkingQuantity+inventoryDetails.inboundShippedQuantity+inventoryDetails.inboundReceivingQuantity].
Nota: Es posible que el inventario en tránsito o en envío tenga una fecha de llegada estimada más larga que el inventario en mano.
Prácticas recomendadas: Te recomendamos suscribirte al tipo de notificación FBA_INVENTORY_AVAILABILITY_CHANGES, que permite la sincronización en tiempo real con el inventario de Amazon y refleja cualquier cambio en el mismo. Para evitar que se pierda ninguna notificación, los desarrolladores deben llamar a la API getInventorySummaries una vez al día para obtener una instantánea completa de los niveles de inventario.
Llamar a la API getInventorySummaries más de una vez al día puede generar datos obsoletos entre las llamadas a la API y no se recomienda hacerlo.
Para los desarrolladores que solo usan la API, sugerimos:
• Mantener tu propio registro interno de inventario, en función de los pedidos realizados y cancelados. A continuación, puedes sobrescribir ese registro durante el proceso de sincronización del inventario, que se puede realizar una o dos veces al día.
• Utilizar una configuración de inventario de seguridad, de modo que no se produzcan ventas excesivas entre los trabajos de sincronización de inventario.
Si están interesados solo en el inventario en mano (ubicado en los centros logísticos de Amazon), en respuesta, los desarrolladores deberían hacer un seguimiento de inventorySummaries.Fulfillable.
Para los desarrolladores interesados en contabilizar los productos que están EN TRÁNSITO/EN ENVÍO, deben sumar: [inventoryDetails.Fulfillable + inventoryDetails.inboundWorkingQuantity+inventoryDetails.inboundShippedQuantity+inventoryDetails.inboundReceivingQuantity].
Nota: Es posible que el inventario en tránsito o en envío tenga una fecha de llegada estimada más larga que el inventario en mano.
Acceder a la información de seguimiento anticipado
Desafío común: Los números de seguimiento ahora están disponibles sin que el pedido esté en proceso de envío.
Prácticas recomendadas: los desarrolladores que llamen a la API getOrder, no deben dar por sentado que los detalles de seguimiento sólo están disponibles cuando el pedido está en estado Completo o Completo parcialmente. Los detalles de seguimiento ahora estarán disponibles cuando el pedido esté en la fase de procesamiento.
Para los desarrolladores que están al tanto de las notificaciones de pedidos, se emite una notificación explícita con detalles de seguimiento anticipado con el estado del pedido como En proceso, que incluye el transportista, el número de paquete y el número de seguimiento.
Normalmente, los desarrolladores que llaman a la API getOrder marcan su pedido como Gestionado después de obtener los datos de seguimiento, pero siempre puede haber actualizaciones de los datos de seguimiento cuando se producen cambios (modificaciones) en un centro logístico. Si marcas los pedidos como Gestionados, no estarás al tanto de ninguna actualización y los detalles de seguimiento no serán válidos.
Asegúrate de leer las notificaciones de FULFILLMENT_ORDER_STATUS, que envían un evento para obtener detalles de seguimiento anticipado y también para cualquier actualización de los detalles de seguimiento, si la hubiera. Este enfoque garantizará que los vendedores siempre tengan los detalles de seguimiento correctos de los pedidos.
Prácticas recomendadas: los desarrolladores que llamen a la API getOrder, no deben dar por sentado que los detalles de seguimiento sólo están disponibles cuando el pedido está en estado Completo o Completo parcialmente. Los detalles de seguimiento ahora estarán disponibles cuando el pedido esté en la fase de procesamiento.
Para los desarrolladores que están al tanto de las notificaciones de pedidos, se emite una notificación explícita con detalles de seguimiento anticipado con el estado del pedido como En proceso, que incluye el transportista, el número de paquete y el número de seguimiento.
Normalmente, los desarrolladores que llaman a la API getOrder marcan su pedido como Gestionado después de obtener los datos de seguimiento, pero siempre puede haber actualizaciones de los datos de seguimiento cuando se producen cambios (modificaciones) en un centro logístico. Si marcas los pedidos como Gestionados, no estarás al tanto de ninguna actualización y los detalles de seguimiento no serán válidos.
Asegúrate de leer las notificaciones de FULFILLMENT_ORDER_STATUS, que envían un evento para obtener detalles de seguimiento anticipado y también para cualquier actualización de los detalles de seguimiento, si la hubiera. Este enfoque garantizará que los vendedores siempre tengan los detalles de seguimiento correctos de los pedidos.
Uso de las funciones de embalaje sin marca (BlankBox) y de bloqueo de Logística de Amazon
Desafío común: los desarrolladores no saben cómo configurar las funciones de embalaje sin marca y de bloqueo de Logística de Amazon
Prácticas recomendadas: Logística Multicanal entrega la mayoría de los pedidos en embalajes sin marca en la región de EE. UU., pero es posible que algunos vendedores exijan que todos los pedidos se entreguen en paquetes sin marca.
Paquetes sin marca (BlankBox o BB):
1. Mantén un indicador en el nivel de SKU para marcar los embalajes sin marca como los SKU de BlankBox (BB). Puedes ver tus productos aptos para BlankBox llamando a la API getFeatureInventor.
2. En el caso de los SKU sólo BB, asegúrate de realizar un seguimiento tanto del embalaje sin marca (BlankBox o BB) como del inventario normal.
3. Establece la conmutación a nivel de canal de ventas y asegúrate de que los canales de ventas requeridos siempre consulten el inventario de BB. Crea pedidos de BB y transmite el inventario de BB a estos canales de venta.
4. En el nivel de trabajo del pedido, llama a las operaciones PREVIEW Order y CREATE Order con la restricción de función Blank_Box=Required, para asegurarte de que los productos se envían sólo en embalajes sin marca.
Bloqueo de Logística de Amazon (Bloqueo AMZL o BAMZL):
Tanto Seller Central como el portal de la cadena de suministro ofrecen una configuración de Bloqueo AMZL a nivel del sitio web de una cuenta de vendedor, que puede activarse para todos los pedidos y conlleva un recargo del 5 %. Los desarrolladores que necesiten Bloqueo AMZL para pedidos específicos pueden seguir los siguientes pasos de configuración:
1. Establece el conmutador a nivel de canal de ventas para garantizar que los pedidos de los canales de ventas requeridos no se envíen a través de Logística de Amazon. Crea pedidos BAMZL para estos canales. Crea pedidos BAMZL para estos canales.
2. En el nivel de trabajo del pedido, llama a las operaciones PREVIEW Order y CREATE Order con la restricción de la función Block_AMZL=Required para asegurarte de que otro transportista además de Logística de Amazon envía los productos.
Prácticas recomendadas: Logística Multicanal entrega la mayoría de los pedidos en embalajes sin marca en la región de EE. UU., pero es posible que algunos vendedores exijan que todos los pedidos se entreguen en paquetes sin marca.
Paquetes sin marca (BlankBox o BB):
1. Mantén un indicador en el nivel de SKU para marcar los embalajes sin marca como los SKU de BlankBox (BB). Puedes ver tus productos aptos para BlankBox llamando a la API getFeatureInventor.
2. En el caso de los SKU sólo BB, asegúrate de realizar un seguimiento tanto del embalaje sin marca (BlankBox o BB) como del inventario normal.
3. Establece la conmutación a nivel de canal de ventas y asegúrate de que los canales de ventas requeridos siempre consulten el inventario de BB. Crea pedidos de BB y transmite el inventario de BB a estos canales de venta.
4. En el nivel de trabajo del pedido, llama a las operaciones PREVIEW Order y CREATE Order con la restricción de función Blank_Box=Required, para asegurarte de que los productos se envían sólo en embalajes sin marca.
Bloqueo de Logística de Amazon (Bloqueo AMZL o BAMZL):
Tanto Seller Central como el portal de la cadena de suministro ofrecen una configuración de Bloqueo AMZL a nivel del sitio web de una cuenta de vendedor, que puede activarse para todos los pedidos y conlleva un recargo del 5 %. Los desarrolladores que necesiten Bloqueo AMZL para pedidos específicos pueden seguir los siguientes pasos de configuración:
1. Establece el conmutador a nivel de canal de ventas para garantizar que los pedidos de los canales de ventas requeridos no se envíen a través de Logística de Amazon. Crea pedidos BAMZL para estos canales. Crea pedidos BAMZL para estos canales.
2. En el nivel de trabajo del pedido, llama a las operaciones PREVIEW Order y CREATE Order con la restricción de la función Block_AMZL=Required para asegurarte de que otro transportista además de Logística de Amazon envía los productos.
Prueba del proceso de autorización en una aplicación pública
Desafío común: los desarrolladores no saben cómo probar el proceso de autenticación de vendedores sin publicar la aplicación en Seller Central.
Prácticas recomendadas: los desarrolladores pueden validar el proceso de autenticación de una cuenta de vendedor de prueba sin tener que publicar la aplicación. Pon a prueba tu proceso de autenticación al añadir “version=beta” a la URL de consentimiento de Seller Central tanto para el proceso de autenticación de Seller Central como para el proceso de autenticación de la tienda en Internet. Nota: En el modo beta, sólo 25 vendedores como máximo pueden autorizar la aplicación, ya que únicamente se hace con fines de validación.
Ejemplo:
https://sellercentral.amazon.com/apps/authorize/consent?application_id=appidexample&state=stateexample&version=beta
Prácticas recomendadas: los desarrolladores pueden validar el proceso de autenticación de una cuenta de vendedor de prueba sin tener que publicar la aplicación. Pon a prueba tu proceso de autenticación al añadir “version=beta” a la URL de consentimiento de Seller Central tanto para el proceso de autenticación de Seller Central como para el proceso de autenticación de la tienda en Internet. Nota: En el modo beta, sólo 25 vendedores como máximo pueden autorizar la aplicación, ya que únicamente se hace con fines de validación.
Ejemplo:
https://sellercentral.amazon.com/apps/authorize/consent?application_id=appidexample&state=stateexample&version=beta
Extracción de informes esenciales para los desarrolladores de Logística Multicanal
Desafío común: los desarrolladores no conocen los informes que se pueden extraer con nuestra API de informes.
Prácticas recomendadas: Utiliza la información de la llamada que aparece a continuación para extraer los informes clave para los desarrolladores de Logística Multicanal.
Informes clave para los desarrolladores de Logística Multicanal:
• Informes de listings: para obtener los datos de listings de productos de una cuenta de vendedor.
GET_FLAT_FILE_OPEN_LISTINGS_DATA y GET_MERCHANT_LISTINGS_ALL_DATA
• Informes de inventario: para realizar un seguimiento de los movimientos del inventario en los centros logísticos de Amazon.
GET_FBA_MYI_UNSUPPRESSED_INVENTORY_DATA y GET_LEDGER_SUMMARY_VIEW_DATA
• Informes de pedidos y ventas: para obtener todos los datos de pedidos y envíos gestionados por Amazon.
GET_XML_ALL_ORDERS_DATA_BY_ORDER_DATE_GENERAL, GET_FLAT_FILE_ALL_ORDERS_DATA_BY_ORDER_DATE_GENERAL y GET_AMAZON_FULFILED_SHIPMENTS_DATA_GENERAL
Prácticas recomendadas: Utiliza la información de la llamada que aparece a continuación para extraer los informes clave para los desarrolladores de Logística Multicanal.
Informes clave para los desarrolladores de Logística Multicanal:
• Informes de listings: para obtener los datos de listings de productos de una cuenta de vendedor.
GET_FLAT_FILE_OPEN_LISTINGS_DATA y GET_MERCHANT_LISTINGS_ALL_DATA
• Informes de inventario: para realizar un seguimiento de los movimientos del inventario en los centros logísticos de Amazon.
GET_FBA_MYI_UNSUPPRESSED_INVENTORY_DATA y GET_LEDGER_SUMMARY_VIEW_DATA
• Informes de pedidos y ventas: para obtener todos los datos de pedidos y envíos gestionados por Amazon.
GET_XML_ALL_ORDERS_DATA_BY_ORDER_DATE_GENERAL, GET_FLAT_FILE_ALL_ORDERS_DATA_BY_ORDER_DATE_GENERAL y GET_AMAZON_FULFILED_SHIPMENTS_DATA_GENERAL
Mantenimiento de las credenciales para el acceso a Sandbox
Desafío común: los desarrolladores desean mantener diferentes credenciales de aplicación para el entorno aislado dinámico y el entorno de Producción.
Tanto para las aplicaciones privadas como para las públicas, hay una forma de limitar el acceso solo para el entorno aislado dinámico. Cualquier aplicación aprobada para producción tendrá acceso a los puntos finales de Producción y Sandbox y no hay forma de restringir el acceso.
Prácticas recomendadas: para resolver el problema, los desarrolladores pueden crear diferentes aplicaciones privadas en estado BORRADOR para los entornos de Sandbox y de Producción y publicar los productos solo en Producción, si tienen la intención de conservar dos conjuntos separados de credenciales de cliente.
Tanto para las aplicaciones privadas como para las públicas, hay una forma de limitar el acceso solo para el entorno aislado dinámico. Cualquier aplicación aprobada para producción tendrá acceso a los puntos finales de Producción y Sandbox y no hay forma de restringir el acceso.
Prácticas recomendadas: para resolver el problema, los desarrolladores pueden crear diferentes aplicaciones privadas en estado BORRADOR para los entornos de Sandbox y de Producción y publicar los productos solo en Producción, si tienen la intención de conservar dos conjuntos separados de credenciales de cliente.
