Desafios comuns e práticas recomendadas
Nesta seção, destacamos alguns dos desafios comuns que os desenvolvedores enfrentam ao criar integrações de conectores com a logística multicanal e explicamos algumas das práticas recomendadas que podem ajudá-lo a superar esses desafios.
Obter atualizações do status do pedido
Desafio comum: Às vezes, os desenvolvedores têm dificuldade para ler as notificações de todas as atualizações do status do pedido.
Melhores práticas: Use um dos dois métodos a seguir para obter atualizações do status do pedido:
1. Chamar a API: Chame regularmente a API getOrder para obter atualizações do status do pedido até que um status terminal [Concluído, ConcluídoParcial, Cancelado, Não aptos para venda] seja alcançado no pedido. Os detalhes de rastreamento são compartilhados na resposta quando estão disponíveis, o que pode ocorrer durante os status Processamento, Concluído e Parcialmente Concluído.
2. Inscreva-se para receber notificações: Ao inscrever-se para receber notificações e ouvir o evento FULFILLMENT_ORDER_STATUS. Sempre que há uma alteração no status do pedido ou é gerado um número de rastreamento, é emitida uma notificação que precisa ser lida em uma fila SQS.
A chamada de API é um mecanismo de extração e os desenvolvedores podem não estar cientes da frequência das chamadas de API. A prática sugerida é ler as notificações e só chamar a API getOrder para obter os detalhes completos do pedido depois que ele for concluído.
Ao seguir essa abordagem, você pode:
• Reduza a largura de banda necessária para chamar as APIs com frequência.
• Conheça os detalhes do rastreamento antecipado.
• Receba notificações em tempo real, pois as chamadas de API podem atrasar.
• Receba notificações de atualizações dos números de rastreamento, se houver.
Melhores práticas: Use um dos dois métodos a seguir para obter atualizações do status do pedido:
1. Chamar a API: Chame regularmente a API getOrder para obter atualizações do status do pedido até que um status terminal [Concluído, ConcluídoParcial, Cancelado, Não aptos para venda] seja alcançado no pedido. Os detalhes de rastreamento são compartilhados na resposta quando estão disponíveis, o que pode ocorrer durante os status Processamento, Concluído e Parcialmente Concluído.
2. Inscreva-se para receber notificações: Ao inscrever-se para receber notificações e ouvir o evento FULFILLMENT_ORDER_STATUS. Sempre que há uma alteração no status do pedido ou é gerado um número de rastreamento, é emitida uma notificação que precisa ser lida em uma fila SQS.
A chamada de API é um mecanismo de extração e os desenvolvedores podem não estar cientes da frequência das chamadas de API. A prática sugerida é ler as notificações e só chamar a API getOrder para obter os detalhes completos do pedido depois que ele for concluído.
Ao seguir essa abordagem, você pode:
• Reduza a largura de banda necessária para chamar as APIs com frequência.
• Conheça os detalhes do rastreamento antecipado.
• Receba notificações em tempo real, pois as chamadas de API podem atrasar.
• Receba notificações de atualizações dos números de rastreamento, se houver.
Sincronização de inventário
Desafio comum: Os desenvolvedores avaliam errado o valor do inventário na mensagem de inventário ou não sabem como sincronizar corretamente o inventário, o que pode levar a vendas excessivas e falta de estoque ou excedente de inventário.
Melhores práticas: Recomendamos que você assine o tipo de notificação FBA_INVENTORY_AVAILABILITY_CHANGES, que permite a sincronização em tempo real com o inventário da Amazon e reflete todas as alterações de inventário. Para evitar qualquer notificação não recebida, os desenvolvedores devem chamar a API getInventorySummaries uma vez por dia para obter um panorama completo dos níveis de inventário.
Chamar a API getInventorySummaries mais de uma vez por dia pode gerar dados obsoletos entre as chamadas de API e não é recomendado.
Para os desenvolvedores que usam apenas a API, sugerimos:
• Manutenção do próprio registro interno de inventário, com base nos pedidos realizados e cancelados. Em seguida, é possível substituir esse registro durante o processo de sincronização do inventário, que pode ser feito uma ou duas vezes por dia.
• Operar com algumas configurações de estoque de segurança, para não haver excesso de vendas entre os trabalhos de sincronização de inventário.
Se estiver interessado apenas no inventário em mãos (localizado nos centros de distribuição da Amazon), na resposta os desenvolvedores deverão rastrear inventorySummaries.Fulfillable.
Para os desenvolvedores interessados em contabilizar os produtos que estão em trânsito/entrada, faça a soma de: [inventoryDetails.Fulfillable + inventoryDetails.inboundWorkingQuantity+inventoryDetails.inboundShippedQuantity+inventoryDetails.inboundReceivingQuantity].
Observação: O inventário em trânsito/entrada pode ter uma data de chegada estimada mais longa do que o inventário em mãos.
Melhores práticas: Recomendamos que você assine o tipo de notificação FBA_INVENTORY_AVAILABILITY_CHANGES, que permite a sincronização em tempo real com o inventário da Amazon e reflete todas as alterações de inventário. Para evitar qualquer notificação não recebida, os desenvolvedores devem chamar a API getInventorySummaries uma vez por dia para obter um panorama completo dos níveis de inventário.
Chamar a API getInventorySummaries mais de uma vez por dia pode gerar dados obsoletos entre as chamadas de API e não é recomendado.
Para os desenvolvedores que usam apenas a API, sugerimos:
• Manutenção do próprio registro interno de inventário, com base nos pedidos realizados e cancelados. Em seguida, é possível substituir esse registro durante o processo de sincronização do inventário, que pode ser feito uma ou duas vezes por dia.
• Operar com algumas configurações de estoque de segurança, para não haver excesso de vendas entre os trabalhos de sincronização de inventário.
Se estiver interessado apenas no inventário em mãos (localizado nos centros de distribuição da Amazon), na resposta os desenvolvedores deverão rastrear inventorySummaries.Fulfillable.
Para os desenvolvedores interessados em contabilizar os produtos que estão em trânsito/entrada, faça a soma de: [inventoryDetails.Fulfillable + inventoryDetails.inboundWorkingQuantity+inventoryDetails.inboundShippedQuantity+inventoryDetails.inboundReceivingQuantity].
Observação: O inventário em trânsito/entrada pode ter uma data de chegada estimada mais longa do que o inventário em mãos.
Acesso a informações de rastreamento antecipado
Desafio comum: Os números de rastreamento agora estão disponíveis sem que o pedido esteja com o envio concluído.
Melhores práticas: Para os desenvolvedores que chamam a API getOrder, não suponha que os detalhes de rastreamento estejam disponíveis somente quando o pedido estiver no status Concluído ou ConcluídoParcial. Os detalhes de rastreamento agora estarão disponíveis quando o pedido estiver no estágio de processamento.
Para os desenvolvedores que ouvem as notificações de pedidos, uma notificação é explicitamente emitida com detalhes de rastreamento antecipados com o status do pedido como Processando, que tem a transportadora, o número do pacote e o número de rastreamento.
Geralmente, os desenvolvedores que chamam a API getOrder marcam o pedido como enviado depois de consumirem os detalhes de rastreamento, mas sempre pode haver atualizações nos detalhes de rastreamento quando ocorrem Re-SLAMs (modificações) em um centro de distribuição. Se você marcar os pedidos como enviado, não ficará sabendo de nenhuma atualização e terá detalhes de rastreamento inválidos.
Não deixe de ler as notificações FULFILLMENT_ORDER_STATUS, que enviam um evento para obter detalhes de rastreamento antecipados e também para atualizações dos detalhes de rastreamento, se houver. Essa abordagem garantirá que os vendedores sempre tenham os detalhes corretos de rastreamento dos pedidos.
Melhores práticas: Para os desenvolvedores que chamam a API getOrder, não suponha que os detalhes de rastreamento estejam disponíveis somente quando o pedido estiver no status Concluído ou ConcluídoParcial. Os detalhes de rastreamento agora estarão disponíveis quando o pedido estiver no estágio de processamento.
Para os desenvolvedores que ouvem as notificações de pedidos, uma notificação é explicitamente emitida com detalhes de rastreamento antecipados com o status do pedido como Processando, que tem a transportadora, o número do pacote e o número de rastreamento.
Geralmente, os desenvolvedores que chamam a API getOrder marcam o pedido como enviado depois de consumirem os detalhes de rastreamento, mas sempre pode haver atualizações nos detalhes de rastreamento quando ocorrem Re-SLAMs (modificações) em um centro de distribuição. Se você marcar os pedidos como enviado, não ficará sabendo de nenhuma atualização e terá detalhes de rastreamento inválidos.
Não deixe de ler as notificações FULFILLMENT_ORDER_STATUS, que enviam um evento para obter detalhes de rastreamento antecipados e também para atualizações dos detalhes de rastreamento, se houver. Essa abordagem garantirá que os vendedores sempre tenham os detalhes corretos de rastreamento dos pedidos.
Usar embalagens sem marca (Blank Box) e bloquear os recursos do Amazon Logistics
Desafio comum: Os desenvolvedores não sabem como configurar a embalagem sem marca e bloquear os recursos do Amazon Logistics.
Melhores práticas: A logística multicanal entrega a maioria dos pedidos em embalagens sem marca na região dos EUA, mas alguns vendedores podem exigir que todos os pedidos sejam entregues em embalagens sem marca.
Embalagens sem marca (Blank Box ou BB):
1. Mantenha um marcador no nível do código SKU para marcar embalagens sem marca como código SKUs somente BlankBox (BB). Você pode visualizar seus produtos elegíveis para o BlankBox chamando a API getFeatureInventory.
2. Para códigos SKUs somente BB, rastreie tanto a embalagem sem marca (BlankBox ou BB) quanto o inventário convencional.
3. Defina a alternância no nível do canal de vendas e garanta que os canais de vendas necessários estejam sempre consultando o inventário do BB. Criar pedidos do BB e repassar o inventário do BB para esses canais de vendas.
4. No nível de trabalho do pedido, chame as operações PREVIEW Order e CREATE Order com a restrição de recurso Blank_Box=Required , para garantir que os produtos sejam entregues somente em embalagens sem marca.
Bloqueie o Amazon Logistics (Bloqueie AMZL ou BAMZL):
A Seller Central e o portal da cadeia de suprimentos oferecem uma configuração de bloqueio de AMZL no nível do site de uma conta de vendedor, que pode ser ativada para todos os pedidos e vem com uma sobretaxa de 5%. Os desenvolvedores que têm a necessidade de bloquear o AMZL para pedidos específicos podem usar as seguintes etapas de configuração:
1. Defina a alternância no nível do canal de vendas para garantir que os pedidos dos canais de vendas necessários não sejam entregues pelo Amazon Logistics. Crie pedidos BAMZL para esses canais.
2. No nível de trabalho do pedido, chame a operação PREVIEW pedido e CREATE Order com a restrição de recurso Block_AMZL=Required para garantir que outra transportadora além do Amazon Logistics esteja enviando os produtos.
Melhores práticas: A logística multicanal entrega a maioria dos pedidos em embalagens sem marca na região dos EUA, mas alguns vendedores podem exigir que todos os pedidos sejam entregues em embalagens sem marca.
Embalagens sem marca (Blank Box ou BB):
1. Mantenha um marcador no nível do código SKU para marcar embalagens sem marca como código SKUs somente BlankBox (BB). Você pode visualizar seus produtos elegíveis para o BlankBox chamando a API getFeatureInventory.
2. Para códigos SKUs somente BB, rastreie tanto a embalagem sem marca (BlankBox ou BB) quanto o inventário convencional.
3. Defina a alternância no nível do canal de vendas e garanta que os canais de vendas necessários estejam sempre consultando o inventário do BB. Criar pedidos do BB e repassar o inventário do BB para esses canais de vendas.
4. No nível de trabalho do pedido, chame as operações PREVIEW Order e CREATE Order com a restrição de recurso Blank_Box=Required , para garantir que os produtos sejam entregues somente em embalagens sem marca.
Bloqueie o Amazon Logistics (Bloqueie AMZL ou BAMZL):
A Seller Central e o portal da cadeia de suprimentos oferecem uma configuração de bloqueio de AMZL no nível do site de uma conta de vendedor, que pode ser ativada para todos os pedidos e vem com uma sobretaxa de 5%. Os desenvolvedores que têm a necessidade de bloquear o AMZL para pedidos específicos podem usar as seguintes etapas de configuração:
1. Defina a alternância no nível do canal de vendas para garantir que os pedidos dos canais de vendas necessários não sejam entregues pelo Amazon Logistics. Crie pedidos BAMZL para esses canais.
2. No nível de trabalho do pedido, chame a operação PREVIEW pedido e CREATE Order com a restrição de recurso Block_AMZL=Required para garantir que outra transportadora além do Amazon Logistics esteja enviando os produtos.
Testar o fluxo de autorização em um aplicativo público
Desafio comum: Os desenvolvedores não sabem como testar o fluxo de autenticação do vendedor sem publicar ou publicar oferta do aplicativo no Seller Central.
Melhores práticas: Os desenvolvedores podem validar o fluxo de autenticação de uma conta do vendedor de teste sem precisar publicar o aplicativo. Teste seu fluxo de autenticação adicionando “version=beta” ao URL de consentimento da Seller Central para o fluxo de autenticação da Seller Central e o fluxo de autenticação da loja virtual. Observação: No modo beta, não mais do que 25 vendedores podem autorizar o aplicativo, pois isso se destina apenas a fins de validação.
Exemplo:
https://sellercentral.amazon.com/apps/authorize/consent?application_id=appidexample&state=stateexample&version=beta
Melhores práticas: Os desenvolvedores podem validar o fluxo de autenticação de uma conta do vendedor de teste sem precisar publicar o aplicativo. Teste seu fluxo de autenticação adicionando “version=beta” ao URL de consentimento da Seller Central para o fluxo de autenticação da Seller Central e o fluxo de autenticação da loja virtual. Observação: No modo beta, não mais do que 25 vendedores podem autorizar o aplicativo, pois isso se destina apenas a fins de validação.
Exemplo:
https://sellercentral.amazon.com/apps/authorize/consent?application_id=appidexample&state=stateexample&version=beta
Extração de relatórios essenciais para desenvolvedores da logística multicanal
Desafio comum: Os desenvolvedores não estão cientes dos relatórios que podem ser extraídos usando nossa API de relatórios.
Melhores práticas: Use as informações de chamada abaixo para extrair os principais relatórios para desenvolvedores da logística multicanal.
Relatórios essenciais para desenvolvedores da logística multicanal:
• Relatórios das ofertas: para obter dados das ofertas de produtos de uma conta de vendedor.
GET_FLAT_FILE_OPEN_LISTINGS_DATA e GET_MERCHANT_LISTINGS_ALL_DATA
• Relatórios do inventário: para rastrear os movimentos do inventário nos centros de distribuição da Amazon.
GET_FBA_MYI_UNSUPPRESSED_INVENTORY_DATA e GET_LEDGER_SUMMARY_VIEW_DATA
• Relatórios de pedidos/vendas: para obter todos os dados de pedidos e envios do Enviado pela 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
Melhores práticas: Use as informações de chamada abaixo para extrair os principais relatórios para desenvolvedores da logística multicanal.
Relatórios essenciais para desenvolvedores da logística multicanal:
• Relatórios das ofertas: para obter dados das ofertas de produtos de uma conta de vendedor.
GET_FLAT_FILE_OPEN_LISTINGS_DATA e GET_MERCHANT_LISTINGS_ALL_DATA
• Relatórios do inventário: para rastrear os movimentos do inventário nos centros de distribuição da Amazon.
GET_FBA_MYI_UNSUPPRESSED_INVENTORY_DATA e GET_LEDGER_SUMMARY_VIEW_DATA
• Relatórios de pedidos/vendas: para obter todos os dados de pedidos e envios do Enviado pela 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
Manutenção de credenciais para acesso ao Sandbox
Desafio comum: Os desenvolvedores desejam manter credenciais de aplicativo diferentes para o ambiente Dynamic Sandbox e o ambiente Production.
Para aplicativos privados e públicos, há uma maneira de limitar o acesso apenas ao ambiente Dynamic Sandbox. Qualquer aplicativo aprovado para produção terá acesso aos endpoints Production e Sandbox e não há como restringir o acesso.
Melhores práticas: Para resolver o problema, os desenvolvedores podem criar aplicativos privados diferentes no status RASCUNHO para os ambientes Sandbox e Production e listar produtos somente no Production, caso pretendam manter dois conjuntos separados de credenciais de cliente.
Para aplicativos privados e públicos, há uma maneira de limitar o acesso apenas ao ambiente Dynamic Sandbox. Qualquer aplicativo aprovado para produção terá acesso aos endpoints Production e Sandbox e não há como restringir o acesso.
Melhores práticas: Para resolver o problema, os desenvolvedores podem criar aplicativos privados diferentes no status RASCUNHO para os ambientes Sandbox e Production e listar produtos somente no Production, caso pretendam manter dois conjuntos separados de credenciais de cliente.
