FAQ Connections - Netshoes

ESSE É UM FAQ PARA USO EXCLUSIVAMENTE INTERNO.

Este guia tem como objetivo indicar soluções para problemas que podem surgir na Integração com a Netshoes. Este artigo está dividido em 2 seções: "Questions" e "Investigations"

QUESTIONS | PRODUCTS

Q: Cliente está com alguns pedidos da Netshoes que foram cancelados aqui na VTEX, mas ainda estão com status de "Approved" no marketplace, é possivel atualizar estes pedidos na Netshoes?
A: Não temos cancelamento de pedidos na Netshoes porque o marketplace não tem rota para isso, em resumo não fazemos cancelamento do pedido VTEX > Marketplace, apenas Marketplace > VTEX. Neste caso o cliente pode seguir com o cancelamento direto no marketplace.

Q: É possivel excluir um sku na Netshoes?
A: Não, mas é possivel inativar, quando um sku é removido da politica comercial a integração vai notificar a netshoes que o estoque = zero e a Nethsoes vai inativar o sku.

Q: Por que o frete não esta sendo calculado na Netshoes?
A: Verifique o ID cadastrado na Doca vinculada a Netshoes, o seller provavelmente usou um ID alfanumérico na criação das DOCAS, mas a Netshoes aceita apenas ID NUMERICO diferente disso vai gerar erro durante a contação de frete.

OU

O Seller criou politicas de envio utilizando IDalfanumerico desta forma ao realizar simulação a Netshoes vai retornar erro.

Solução é valida para os dois casos: Acessar Admin VTEX > Pedidos > Estoque & Entrega > Estratégia de envio > Docas/Politicas de envio > Recomendamos que o Seller duplique a doca/Politicas de envio > Altere o ID usando apenas numeros > Salve e só depois deletar a Doca/Politicas de envio antiga com ID alfanumerico.

Tela Ilustrativa:

QUESTIONS | ORDERS

Q: Pedidos com erro "Impostos são diferentes dos pretendidos pela loja?"
A: Ele vai acontecer quando o sku possuir algum tipo de imposto e tentar integrar aqui na VTEX, se os Impostos são diferentes dos pretendidos pela loja, basicamente é divergência entre o pedido enviado pela integração e a expectativa da loja sobre quais deveriam ser os valores.

Q: Pedido com erro "Impostos são diferentes dos pretendidos pela loja" mas não existe nenhuma taxa cadastrada na loja.
A: Se o erro ocorreu por um curto periodo e parou, é possivel que a taxa tenha sido removida da conta, neste caso vale um papo com o seller para entender se existiu em algum momento estas taxas, ou alguma taxa externa(usando "taxhub"), neste caso não seria nada do lado do conector.

Q: Pedidos com erro: {"type":"Bad_Request_Error","description":"Request invalid or malformed.","notifications":["O pedido já possui uma nota fiscal. Não é possível alterá-lo"]}
A: Este é um problema já conhecido pela Netshoes e ocorre por uma falha na sincronização do status. Ou seja, mesmo após a execução do PUT /invoiced com sucesso, o pedido não reflete o faturamento e acaba permanecendo com o status de approved.

Solução: Normalmente a ação de reprocessao o pedido resolve, mas quando o pedido segue com erro recomendamos que o seller abra um ticket com a Netshoes solicitando ajustes para o pedido, estes tickets ajudam que a Netshoes tenha visibilidade das ocorrencias e realize as correções necessárias.

Q: Pedidos com erro: {"type":"Bad_Request_Error , description Request invalid or malformed. , notifications One or more errors occurred"}.
A: Este é um problema já conhecido pelo time da Netshoes e ocorre por uma não aceitação no backend. Neste caso, é necessaria uma atuação interna(na Netshoes) para a regularização deste pedido, e assim passar a permitir o faturamento.

Q: Quais são os status dos pedidos na VTEX x Netshoes?
A: A equivalencia é a seguinte:

Netshoes x VTEX
Approved = Faturado
Invoiced = Faturado + InvoiceKey
Delivered = Faturado + InvoiceKey + TrackingNumber

Q: Significado error 429(throttling) na Netshoes
A: 429 acontece quando o seller atinge o limite de requisições no marketplace, importante saber que este limite é definido pelo prorprio marketplace, neste caso a Netshoes.

Q: Como funciona o throttling(erro 429) na Netshoes?
A: Vai depender do plano que o seller tem com a Netshoes, por exemplo plano de 500 requisições por minuto com bloqueio de 30 segundos ao atingir o limite.

O que podemos considerar como requisições?
As requisições são compartilhadas para todos os requests, e não só de pedido. Portanto para estoque, preço, consulta de status, e tudo mais.

Para baixar um pedido com 1 item, são necessários no mínimo 3 requests.
- Consulta da lista de pedidos;
- Recuperação dos dados do pedido;
- Atualização do estoque.

Importante: Quando um sku recebe throttling, ele volta para o final da fila e a integração faz uma nova tentativa para atualização.

QUESTIONS | SETTINGS

INVESTIGATIONS | PRODUCTS

Cenário: Estoque/Preço não estão sendo atualizados
Como Investigar: O Fluxo de atualização de preço e estoque nos marketplaces funciona assim:

Cliente altera estoque/preço no catálogo/pricing -> catálogo/pricing notifica o Broadcaster -> Broadcaster notifica a integração -> integração altera o estoque/preço no marketplace.

1. Primeira metade do fluxo = Time Merch
2. Segunda metade = Time Connections

É necessário investigar cada passo para identificar a falha no fluxo.
1. Cliente altera estoque/preço no catálogo/pricing:

Se for estoque, verificar histórico de alteração da informação no admin.
Se for preço, verificar histórico de alteração da informação no splunk: splunk

Assim, obter a informação de data e hora da última atualização de informação.
2. Catálogo/Pricing notifica o Broadcaster:

O Broadcaster (ou ccnotificator) é o sub-sistema responsável por distribuir e disparar notificações sobre alguma alteração de produto, preço ou estoque à cada um dos afiliados. Para que ele dispare essas informações, é necessário que ele seja notificado de alguma alteração ocorreu.

Sendo assim, é necessário pesquisar pelo log de notificação no splunk. 

Se for estoque, pesquisar pela seguinte query: index=ccnotificator account={{accountName}} workflow_instance={{idSku}} workflow_type=EnqueueStockChangeNotification

Se for preço, pesquisar pela seguinte query: index=ccnotificator account={{accountName}} workflow_instance={{idSku}} workflow_type=EnqueuePriceChangeNotification

Caso na data e hora em que houve a última alteração da informação (passo 1) não houver um log de notificação, a falha no fluxo deve ser tratada com o time de Merch.

3. Broadcaster notifica a integração:
Após o broadcaster ser notificado de que houve uma alteração de informação, é necessário que ele repasse essa informação para todos os afiliados.

Portanto, é preciso verificar se há logs no splunk de que essa informação foi repassada.

Se for estoque, pesquisar pela seguinte query: index=ccnotificator account={{accountName}} {{affiliateID}} workflow_instance={{idSku}} workflow_type=NotifyAffiliatesAboutStockChangeAsync

Se for preço, pesquisar pela seguinte query: index=ccnotificator account={{accountName}} workflow_instance={{idSku}} workflow_type=NotifyAffiliatesAboutPriceChangeAsync

Caso esse log esteja com a mensagem de erro “Ocorreu um erro de comunicação com o catálogo de produtos. Acesso não autorizado do seller 1  para o sales channel “x”.” é necessário verificar o binding para a política comercial cadastrada no marketplace (tanto da account quanto da subaccount).

Caso esse log esteja apontando para um endpoint diferente de “http://netshoesintegration.vtexinternal.com/api/netshoesintegration/commercialcondition?an={{accountName}}” é necessário ajustar para esse endpoint, provavelmente o cliente fez alguma alteração manual.

Caso esse log esteja com algum erro não identificável, a falha no fluxo deve ser tratada com o time de Connections, sendo imprescindível constar no ticket a query utilizada no splunk e o erro identificado

4. Integração altera o estoque/preço no marketplace:
Considerando que o passo 3 tenha sido realizado com sucesso no fluxo, é necessário verificar agora se a integração realizou a alteração necessária no marketplace.

Para o caso da Netshoes, é preciso verificar nos logs do splunk o envio dessa informação:}

Se for estoque, pesquisar pela seguinte query: index=netshoesintegration account={{accountName}} workflow_instance={{skuId}} workflow_type=UpdateStockAsync

Se for preço, pesquisar pela seguinte query: index=netshoesintegration account={{accountName}} workflow_instance={{skuId}} workflow_type=UpdatePriceAsync

Caso esse log não exista ou esteja com um erro não identificável, a falha no fluxo deve ser tratada com o time de Connections, sendo imprescindível constar no ticket a query utilizada no splunk

Caso esse log esteja com um valor diferente do cadastrado no admin da VTEX ou no módulo de Pricing, é necessário realizar uma simulação de fulfillment para analisar quais as informações de estoque e preço estão sendo repassadas para a integração , pois a integração utiliza a informação retornada pela simulação de fullfilment para consultar os valores de estoque e preço que serão enviados ao marketplace. 

API de fulfillment:
POST https://{{accountName}}.vtexcommercestable.com.br/api/fulfillment/pvt/orderForms/simulation?sc={{PolíticaComercial}}&affiliateId={{Afiliado}}

1. Se a simulação de fulfillment retornar o valor que a integração enviou, então esse é o valor realmente cadastrado no sku. É necessário entender com o time de Checkout o motivo da divergência de valores.

2. Se a simulação de fulfillment retornar um valor diferente do que a integração enviou, então é porque houve uma mudança recente nos valores do sku. Para atualizar a informação, basta realizar uma mudança no sku para que ele seja atualizado novamente no marketplace.

Cenário: "Sku não integra. Mensagem de erro: “productGroup: Field contains invalid characteres”
Como investigar: Esse ocorre quando a especificação de NetshoesproductGroup contém caracteres especiais como pontos, vírgulas, hífens, etc.

INVESTIGATIONS | ORDERS

Cenário: "Pedidos com erro de SLA ou sku sem estoque"
Como Investigar: A integração sempre que identifica um novo pedido no marketplace que deve ser integrado para a loja realiza uma simulação de fulfillment, com o objetivo de selecionar o SLA do pedido, antes de efetivamente criar o pedido. Nesse momento, se a simulação retornar que o sku não possui estoque, está indisponível ou que não há SLA disponível para aquele item naquele CEP o pedido não será criado na loja e a integração irá logar um erro de SLA no bridge.

Para validar se o erro persiste, é necessário clicar em “Reprocessar pedido”. Caso o erro continue, para analisar o motivo específico (preço, estoque, SLA ou disponibilidade do item) é preciso realizar uma simulação de fulfillment.

cURL

No resultado dessa simulação, é necessário analisar os campos:

1. “Price” para validar seo sku possui preço válido;
2. “Sla” para validar se há algum retorno de SLA para o sku no CEP indicado;
3. “Stockbalance” para validar se o sku possui estoque;
4. “Message” para validar a disponibilidade do sku.

Caso alguma das informações acima não esteja válida, o pedido continuará com erro no Bridge. Neste caso deve-se analisar as configurações da loja ou verificar com o time de Checkout o motivo da informação não estar válida.

Após a correção, basta reprocessar o pedido. Caso o erro permaneça, a falha deverá ser tratada com o time de Connections, sendo imprescindível constar no ticket a simulação de fullfilment realizada e os detalhes identificados na análise.