Ops! Esse email nao possui permissão para abertura de ticket. Por favor, entre em contato com o responsável pela sua loja para providenciar o acesso.

Dafiti - FAQ Interno

ESSE É UM FAQ PARA USO EXCLUSIVAMENTE INTERNO.

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

QUESTIONS | ORDERS


Q: Quando ocorre o erro "Mensagem original: E021: OMS Api Error Occurred"?
A: Este erro ocorre quando Seller habilita a chave FOB sem ter ela cadastrada na Dafiti, ocasionando erro na integração, onde a integração tenta notificar a Dafiti que o tipo da entrega é FOB.

Solução:
1- Desligar a chave FOB no card da integração
2- Entrar em contato com a Dafiti

Como funciona ativação FOB na Dafiti?
Funciona assim, seller solicita para ser habilitado por ticket, esse ticket vai para um time específico que agenda um treinamento com ele, onde tem o material etc e no final se ele participou o nosso time habilita para ele. Ele por conta própria não habilita, até pq tem uma documentação q ele precisa assinar tbm, dai o passo a passo é ensinado no treinamento com o time aplicando para ele em sala (call)

mceclip0.png

Q: Por que alguns pedidos retornam este erro no rastreamento? "E080: Not allowed to change the preselected shipment provider"
A: Esse erro pode ser ocasionado quando a transportadora esta com o nome diferente na VTEX e na Dafiti. O nome da transportadora cadastrada na VTEX impacta diretamente no tracking do pedido. Isso por conta que a Dafiti possui uma lista de nomes específicos de transportadoras que são aceitas. É recomendável entrar em contato com a Dafiti para verificar quais os nomes aceitos. Ou seja, a transportadora cadastrada no pedido precisa ter o nome exatamente como está cadastrado na Dafiti. Após a correção na VTEX, basta reprocessar o rastreamento no Bridge.

Situação onde o erro pode ocorrer:
VTEX = Correios SEDEX
DAFITI = SEDEX

Para funcionar as duas pontas precisam usar o mesmo nome incluindo letras maiúsculas e minúsculas. 
VTEX =   SEDEX
DAFITI = SEDEX

QUESTIONS | SETTINGS

 

Q: A Dafiti consulta nossa api de frete para montar o cart (semelhante Netshoes)?
A: não, é uma planilha de frete na plataforma deles.

 

QUESTIONS | PRODUCTS


Q:
Por que alguns skus retornam erro "E009: Access Denied" na integração?
A: Isso significa que existe alguma configuração incorreta no card da integração, orientamos que o seller confirme as informações com o time da Dafiti, exemplo de informações que podem estar incorretas:
    1. Chave cadastrada esta incorreta;
    2. Email cadastrado não esta vinculado a chave.

Q: Por que alguns skus retornam erro na atualização do preço "Price may not be changed by this user"?
A: Porque o Seller não pode alterar o preço original do produto dentro do período de 90 dias da Black Friday, esta trava é feita pelo time Dafiti e o seller recebe um comunicado. (preço deve ser menor que o preço disponível hoje) 

Q: Por que alguns skus retornam erro "Variation value is not unique"?
A: Este erro pode ocorrer por dois motivos:

1.
O erro "Variation value is not unique" pode ocorrer quando um sku é deletado manualmente no Dashboard da Dafiti.

IMPORTANTE:
Recomendamos que os SKUs sejam manipulados somente na VTEX, caso contrário podem haver inconsistencias e problemas no envio dos SKUs. Caso o seller tenha necessidade de INATIVAR um SKU ele deve remove-lo da Politica comercial aqui na VTEX, assim ele ficara inativo na Dafiti. (Skus não devem ser deletados manualmente no Dashboard da Dafiti.)

Solução:
Todos os SKUs relacionados ao SKU excluido na Dafiti (pai + filhos) devem ser removidos do marketplace e reenviados.

2. Quando o seller cadastra a variação no formato diferente do aceito pela Dafiti.
Para a Dafiti quando um produto possui varias CORES ele é considerado outro produto então não pode ser enviado "agrupado".

Exemplo: Seriam 3 produtos cada 1 com sua cor, e com suas variações apenas para tamanho.

mceclip4.png

INVESTIGATIONS | PRODUCTS


Cenário: "Mapeamento da planilha. Mensagem de erro: “Valor de variação inválido | SellerSku: {{SkuId}} | Name: {{SkuName}}"
Como investigar: É preciso verificar se a planilha de mapeamento foi preenchida com valores válidos segundo a documentação do Help:
https://help.vtex.com/tracks/configurar-integracao-da-dafiti--4wF4RBx9ygEkimW6SsKw8i/3b8BZfB1BC8G8SCe0ao46m

Exemplo: Não é possível preencher uma especificação de Tamanho com o valor “0”.

Cenário: "Preço do sku não foi atualizado no marketplace".
Como Investigar:
Primeiro passo, avaliar se o sku possui preço fixo cadastrado no catalogo e se foi atualizado.

Sim, preço fixo foi atualizado no Marketplace > Pular este passo e seguir com a próxima analise (Estoque/Preço não estão sendo atualizados (como investigar))

Não, não possui preço fixo cadastrado > Neste caso a integração não é notificada sobre alteração de preço. Somente alterações de "Preço Fixo geram notificações ao broadcaster.

Ainda tenho duvidas sobre atualização do preço fixo
Esta é a documentação do time de Merch que explica como funciona atualização preço fixo.

https://help.vtex.com/pt/tracks/precos-101--6f8pwCns3PJHqMvQSugNfP/3HxF2u5VwidqnUGnFoKdDy?locale=pt

Mas o Seller não usa "Preço Fixo" o que fazer neste caso?

Caso o seller queira que os preços notifiquem para atualizações de preços não fixos, ele pode definir uma regra de preço, mesmo que vazia para essa política específica e o workflow do pricing de notificação de preços irá chamar o broadcaster.

Como Configurar esta regra de preço?
Acesse o Admin > Produtos > Preços > Regras de Preço > Nova Regra 

Nova Regra: Quais os dados gerais dessa regra? Selecione a politica comercial (recomendamos criar uma regra para cada politica comercial existente na loja). Em quais itens esta regra será aplicada?  Selecione a opção "Aplicar em todos os produtos"



Para os outros campos nenhuma seleção é necessária > Clique em "Salvar"
Realizei o mesmo procedimento para as outras politicas comerciais. 



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 da seguinte maneira >
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: link do 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

1. 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).

2. Caso esse log esteja apontando para um endpoint diferente de “http://sellercenterintegration.vtexcommerce.com.br/api/sellercenterintegration/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 Channels, 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 Dafiti, é preciso verificar nos logs do splunk o envio dessa informação:
Se for estoque ou preço, pesquisar pela seguinte query: index=sellercenterintegration account={{accountName}} workflow_instance={{skuId}} workflow_type=ProcessUpdateFeedResultAsync

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 Channels, 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.

QUESTIONS | ORDERS


Cenário: "Pedido Incompleto".

Como Investigar: Artigo bem legal do time de Orders que ajuda a investigar um pedido nesta situação:
https://support.vtex.com/hc/en-us/articles/360060106912-How-to-investigate-incomplete-orders

Complementando:
O pedido está com status de sucesso no bridge, mas foi criado como pedido incompleto no OMS.
Procurar pelo primeiro log de PlaceOrderAsync no splunk da integração:

index=skyhubintegration account={{accountName}} workflow_instance={{orderId}}

Na evidência desse log existe um campo chamado "Key": "x-vtex-operation-id".
É preciso procurar no splunk o que ocorreu no checkout no momento que a integração estava tentando inserir esse pedido na VTEX, para isso você deve usar o valor que estiver nessa chave: index=checkout operation_id={{operationId}}. Ao fazer isso, você vai ter a mensagem de erro do checkout e o motivo para o pedido ter sido criado incompleto.

Cenário: "Erro de atualização de Tracking. Mensagem de erro: “A transportadora utilizada para entrega não está cadastrada na Dafiti”.
Como Investigar: O nome da transportadora cadastrada na VTEX impacta diretamente no tracking do pedido. Isso por conta que a Dafiti possui uma lista de nomes específicos de transportadoras que são aceitas. É recomendável entrar em contato com a Dafiti para verificar quais os nomes aceitos. 

Ou seja, a transportadora cadastrada no pedido precisa ter o nome exatamente como está cadastrado na Dafiti. Após a correção na VTEX, basta reprocessar o rastreamento no Bridge.

Cenário: "Pedidos com erro de SLA ou SKU sem etoque".
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

curl --location --request POST 'https://.vtexcommercestable.com.br/api/fulfillment/pvt/orderForms/simulation?sc={{Pol%C3%ADticaComercial}}&affiliateId={{Afiliado}}' \

 

--header 'Content-Type: application/json' \

--data-raw '{

  "items": [{

    "id": "32309",

    "quantity": 1,

    "seller": "1"

  }],

  "marketingData": null,

  "postalCode": "22250040",

  "country": "BRA",

  "selectedSla": null,

  "clientProfileData": null,

  "geoCoordinates": [],

  "isCheckedIn": false,

  "storeId": null

}'

 

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 Channels, sendo imprescindível constar no ticket a simulação de fullfilment realizada e os detalhes identificados na análise.

 



Tem mais dúvidas? Envie uma solicitação

Comentários