FAQ Connections - Netshoes

ESSE É UM FAQ PARA USO EXCLUSIVAMENTE INTERNO.

Este FAQ tem como objetivo indicar soluções para problemas e ajudar com duvidas que podem surgir na Integração com a Netshoes. 

ATENÇÃO: MUDANÇAS SPLUNK PARA OPEN SEARCH 

Devido as mudanças relacionadas ao log, favor desconsiderar "queries" relacionadas ao splunk mencionadas neste FAQ, recomendamos a uitlização do seguinte arquivo como referencia, até que o FAQ seja atualizado.  (Estas novas queries tambem estão disponiveis para consulta no canal #team-connections.

O FAQ ESTÁ CLASSIFICADO DA SEGUINTE FORMA:

1. UPDATE FAQ     | ACOMPANHE AS ULTIMAS ATUALIZAÇÕES DO NOSSO FAQ
2. TICKETS        | QUAIS INFOS PODEM AJUDAR O TIME DE PRODUTO EM UMA INVESTIGAÇÃO?
3. NETSHOES       | BOAS PRATICAS
4. QUESTIONS      | PRODUCTS
5. QUESTIONS      | ORDERS
6. QUESTIONS      | SETTINGS
7. INVESTIGATIONS | PRODUCTS
8. INVESTIGATIONS | ORDERS

UPDATE FAQ | CLIQUE AQUI E ACOMPANHE AS ULTIMAS ATUALIZAÇÕES DO NOSSO FAQ

QUAIS INFOS PODEM AJUDAR O TIME DE PRODUTO EM UMA INVESTIGAÇÃO?

Ficou com duvida na hora de criar um ticket para Connections? CLIQUE AQUI
Temos algumas dicas que podem ajudar a melhorar nossa comunicação e diminuir o "vai e vem" dos tickets, dando assim mais agilidade no atendimento/resposta do time de produto. Aqui estão algumas dicas que achamos essencial para iniciar uma investigação.

NETSHOES | BOAS PRATICAS

https://developers.netshoes.com.br/api-portal/producao#section3

QUESTIONS | PRODUCTS

Q: Marketplace aceita alteração de imagem depois que o sku foi aprovado/integrado?
A: Uma imagem só pode ser alterada na Netshoes se tiver alguma critica no sku, em resumo, depois que um sku foi publicado só o time interno de catalogo(netshoes) pode alterar, então para solicitar alteração de imagem o seller precisa abrir chamado na Netshoes.

Q: Existe algum migrador (igual do Mercado Livre) ou documentação para migração?
A: Hoje infelizmente não temos um migrador ou documentação relacionada a migração na Netshoes, mas em resumo a nossa orientação é que o seller sempre que possivel, delete todos os skus no painel da Dafiti e realize uma nova carga (este é o melhor caminho para evitar erros).

Outra alternativa, quando o seller possui o mesmo id sku mapeado na VTEX e na Netshoes conseguimos integrar sem problemas. Isso tem que valer para TODOS os skus, diferente disso terá muitos erros na integração.

Q: Magalu > Suporta Netshoes entrega?
A: Não, Magalu só suportaMagalu Entregas  

Q: Nethsoes > Suporta Magalu entregas?
A: Sim! Netshoes suporta Magalu entregas e Netshoes entregas.

Q: No contexto FOB, enviamos o xml da invoice (campo embeddedInvoice) para a Netshoes?
A: Não encontramos nada em código sobre o embeddedInvoice. Comparando com a Magalu, eu diria que hoje não enviamos para a Netshoes.

Q: É possível enviar produtos sem estoque ou preço para catalogação via API?
A: Não. Quando o produto for cadastrado e não houver chamada de estoque ou preço, ele ficará criticado e não chegará ao time de catalogo para auditoria até que receba tais informações.

Q: Quando um produto já foi enviado para cadastro no marketplace, ele poderá sofrer alterações?
A: Não. Depois que o produto estiver em processo de catalogação e disponível para venda, ele não poderá sofrer alterações. Só poderá ocorrer alterações quando o produto encontrar-se no status de 'recebido' ou 'criticado', conforme disponível em https://developers.netshoes.com.br/api-portal/producao#section2. Caso necessário em Produção, deverá solicitar a exclusão do produto internamente e cadastra-lo novamente, em Sandbox não é possível nenhuma exclusão, uma vez que via API não é liberada nenhuma ação de exclusão.

Q: Quanto tempo um sku pode ficar no status "Produto em fase de catalogação com a Netshoes. Aguardando aprovação"
A: Não existe um prazo definido, pois envolve etapas de verificação manuais (auditoria) no meio do percurso por parte do Marketplace. Normalmente o prazo é de 2 dias, porém dependendo de alguns casos, pode levar até algumas semanas.

Q: Sobre o EAN na Netshoes
A: Obrigatório para marcas já posicionadas no site, deve conter 13 dígitos. É único por sku. (Para mais detalhes sobre o funcionamento e classificação, o ideal é que o seller verifique diretamente com a Netshoes, pois não temos este controle, a moderação é feita por eles).

Q: Sku já estava integrado mas começou a logar erro "Invalid EAN.Required field for informed brand"
A: Existe uma configuração na Netshoes de obrigatoriedade de ean que pode ser configurada por marca, onde provavelmente  a marca "marcadaloja" passou a ter esta restrição. Orientação Marketplace: Cliente precisa abrir um chamado com a Netshoes questionando porque a netshoes começou a pedir ean para esta marca.

Q: Seller questionou porque algumas produtos integraram corretamente, mesmo com a imagem no tamanho 292x292 (nao aceito pela Netshoes)
A: O sku foi aprovado pela moderação da Netshoes pq a imagem chegou pra eles com tamanho 1000x1000 e não 292x292

Q: Mas como este sku foi integrado com imagem 1000x1000 se ele seller cadastrou 292x292?
A: Provavelmente o tamanho esta sendo setado no admin, nesta configuração de arquivos: https://mizunobr.myvtex.com/admin/Site/TipoArquivo.aspx

Q: Error: Invalid image resolution. Height is invalid. Min height is: 400 px
A: Seller esta cadastrando imagem fora das dimensões aceitas pela Netshoes

Developers Netshoes
Ponto importante, Seller precisa ter em mente as regras estabelecidas pelo marketplace, documentação Netshoes, boas práticas em produção evitando assim problemas na integração. 

Validação de urls permitidas: http 
Formato: .jpeg ou .jpg 
Dimensão: Max. 1200X1200px e Mín. 400pX400px 
Tamanho permitido: 5MB 
Quantidade de imagens: mínimo 1 e máximo 6 
Acesso: As imagens devem ser cadastradas como URLs, para isso é necessário que estejam hospedadas em um servidor (exceto Google Drive, Dropbox, etc.)

Q: Imagem com erro "Invalid Http Response: 404"
A: Este errro acontece porque ao acessar a URL enviada a Netshoes esta recebendo 404

Solução
É dificil dizer com certeza oq pode ter ocasionado este erro na url, provavelmente alguma configuração/alteração, mas a recomedação neste caso é que o seller delete todas as imagens cadastradas la na Netshoes e realizar um novo envio.

Q: Kits logando erro "Invalid EAN.Required field for informed brand"
A: Quando um sku é do tipo "KIT" ele precisa estar mapeado como "Kits" na planilha enviada para a netshoes, para que o marketplace identifique ele como um KIT. O que pode estar acontecendo neste caso é que o "tipo de produto" esta chegando para eles como "Tenis", por exemplo, e por este motivo cai na trava de restrição do EAN.

Como resolver?
Na planilha de mapeamento o seller precisa alterar o"Tipo de Produto = Tenis" para "Tipo de Produto = Kits"e então realizar novamente upload da planilha. Importante: deve escrever exatamente neste formato =Kits

Q: Skus com erro: "Invalid groupCode. There is different products with same groupCode."
A: Netshoes possui uma validação relacionada ao ProductGroup, quando um seller cadastra um código agrupador para um determinado "tipo de produto" não é possível cadastrar para outro produto sem ser da mesma categoria. (Ticket referencia para investigação)

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: Pq um pedido se encontra no status FROZEN no marketplace?
A: Quando um pedido aparecer com o status de Frozen na Criação, Aprovação ou adição deTracking, será adicionada uma mensagem de erro no bridge: "O pedido encontra-se em Status de FROZEN no Marketplace. Por favor aguardar até que saia desse Status para efetuar qualquer alteração.". Nossos workers de processamento não irão considerar esse pedido até que saia desse status no Marketplace.

Solução:
Seller precisa aguardar que o pedido saia deste status lá na Netshoes, ou se ele preferir pode acionar o marketplace para entender o motivo.

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: 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: "Bad_Request_Error , description Request invalid or malformed. , notifications Pedido ja foi atualizado para Entregue."
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.