Olá, Sou da equipe de desenvolvimento da Leroy Merlin
Temos uma integração não nativa da vtex ou seja “feita pela Leroy Merlin” com aproximadamente uma centena de clientes usando.
Temos a nescessidade de enviar os dados de Intermediador da Venda + Intermediador do Pagamento para seguir a Nota Técnica 2020/006 da Sefaz
1 - Como podemos enviar os dados, dado que não somos uma integração de marketplace nativa?
2 - Quais são as chamas de api e campos que devemos usar para mandar os dados corretamente?
Encontramos outra pergunta similar porém a resposta contempla apenas marketplaces nativos ou sellers que usam vtex como marketplace, o que não é o nosso caso.
Olá @bee , é uma excelente pergunta! Não sou da VTEX, mas fiquei curioso também e fui pesquisar. Com base no que a outra postagem menciona, meu palpite seria incluir essas informações nestes campos: orderForm (vtex.com) Acha que faz algum sentido?
No outro topico não tem nenhuma instrução de como “gravar os dados” do intermediador da venda e nem do pagamento, apenas diz como ler os dados gravados por Sellers que vendem seus produtos em marketplaces VTEX ou parceiros nativos.
Existem 3 tipos de integrações de marketplace:
1 - Parceiros nativos: neste caso são integrações implementadas pela propria vtex as quais já foi atualizado para gravar esses dados, por isso só tem a instução de como consumir no topico anterior
2 - Marketplaces VTEX : que naturalmente já estão gravando os dados corretamente pois foi atualizado, e novamente no topico anterior só tinha como consumir.
3 - Parceiros não nativos: Que é o nosso caso, são empresas grandes como a Leroy Merlin ou pequenas que a integração é implementada e mantida não pela equipe da vtex mas sim pela equipe da propria empresa (No caso da Leroy ). Então e dependemos de receber as instruções de como informar o intermediador da venda e do pagamento, para que seja seguida a Nota Técnica 2020/006 da Sefaz.
Quais os payloads e apis que devemos chamar? quais são campos etc…
Lembrando que temos pouco mais de uma centena de sellers grandes e não queremos que eles sejam afetados, Fora isso como podem ver tem outras pessoas com mesma dúvida.
Acho que até faz, mas o problema é sobrescrever outros dados nao pertinentes pra esse update especificamente, fora que nao parece haver uma forma segura pra se testar, só em prod, se por ventura algum field indevido receber update tu pode prejudicar uma order
Vou na mesma linha do Eduardo e do Nathan que é a inserção dos dados no campo customData no orderForm antes de criarem o pedido na VTEX.
Em um segundo momento, vai ser necessário falar com os sellers para avisá-los que a informação passou a ser disponibilizada no pedido como foi feito pela VTEX para outros marketplaces ( Fetching marketplace information with the Orders API (vtex.com)).
Os sellers vão ter que atualizar a integração deles com a VTEX para pegar o campo.
Opa, boa tarde.
Estamos desenvolvendo uma integração do nosso lado e também estamos com a mesma dúvida.
O pessoal comentou sobre o customData no orderForm, mas não existe uma forma de só fazer o update (PUT ou PATCH), de um novo APP, certo?
Pelo que vi, é preciso dar um GET na estrutura, adicionar o meu APP e fazer um POST para atualizar.
Achei arriscado pois se deixarmos algum “APP” de fora, o orderForm do lojista vai ficar desatualizado.
Outro ponto é, essas chamadas de POST (para atualizar o orderForm), precisam de alguma autorização específica na API para chamarmos?
Nome do intermediador da transação/venda (marketplace, aplicativo, etc)
CNPJ do intermediador da transação/venda (marketplace, aplicativo, etc)
Na teoria, estão contempladas no trecho da documentação:
It is possible to see who the marketplace is by checking the order object with the Get order API request, in the affiliateId field, like in the example below.
Como o seller já tem o nome e CNPJ do marketplace com que está transacionando, com o affiliateId já dá pra acessar a informação necessária.
Quanto a:
Nome do intermediador financeiro (gateway de pagamento)
CNPJ do intermediador financeiro (gateway de pagamento)
Dá para fazer um “solução de contorno” usando uma tabela no Master Data em que o lojista cadastre essas informações de cada conector que ele usa em cada método de pagamento e via customização adicione isso em um custom data depois da escolha da forma de pagamento. Apesar de não ser nativo, daria para prosseguir desta forma.
Acredito que em breve teremos uma solução mais simples e nativa, porém não temos previsão ainda para esse lançamento.
