Estamos realizando a integração de produtos do Tiny ERP para a VTEX e temos o seguinte cenário:
- Já tenho o Campo de SKU para as variações cadastrado na VTEX, vinculado à categoria raiz e com os valores possíveis já cadastrados também.
- No Tiny, quando vou realizar o envio de um produto para a VTEX o sistema me exibe corretamente o mapeamento das variações (print anexo) como se tivesse encontrado corretamente as correspondências para vincular os registros.
- Mesmo exibindo corretamente o mapeamento, ao enviar os produtos de uma categoria a integração sempre cria um novo campo de SKU na VTEX (mesmo que a categoria já possua um campo com o mesmo nome e opções...)
- Isso é ruim, pois em um cenário ideal precisamos que o mesmo campo de SKU seja utilizado por todas as categorias e subcategorias para podermos realizar filtros mais abrangentes e não somente dentro de uma categoria específica...
Gostaria de saber se alguém já teve algum caso semelhante e se foi possível ajustar para que não sejam criados os campos redundantes.
Quem montou o integrador, não montou corretamente.
---Comentário da VTEX---
A Tiny, como outros integradores, deve seguir a documentação de Integração com ERP abaixo:
https://help.vtex.com/pt/announcements/guias-de-integracao-com-erp-tem-uma-nova-casa--3lqN5Z0ydDBAxxYN9mbQ6K?locale=pt Além disso, aconselhamos verificar com o integrador quais APIs estão sendo utilizadas quando novos produtos são adicionados na loja. Para atualizar o valor de especificação, usa-se essa API: https://developers.vtex.com/vtex-rest-api/reference/catalog-api-put-specification-field-valueSe por ventura a API de PUT (https://developers.vtex.com/vtex-rest-api/reference/catalog-api-put-specification-field) estiver sendo utilizada, pode explicar o por quê de novas especificações estarem sendo criadas toda vez que forem atualizadas.----Fim Comentário VTEX-----
Mas eu já tentei colocar os atributos em todos os níveis, o Tiny sempre cria o próprio dele... A alternativa q encontrei foi deixar ele criar os atributos repetidos e depois desativar, não é o ideal, mas acho q vai ter q ser assim.
A questão é que neste caso, o lojista deseja que o cliente possa realizar, por exemplo, um filtro por "Tamanho" considerando todas as categorias de produtos da loja. Por isso que criamos o atributo na raiz geral. Existe alguma alternativa mais eficaz/correta para este cenário?
A não utilização do campo na raiz é algo mais conceitual ou pode ocasionar algum problema técnico?
Um filtro de tamanho, pode ser criado por ESPECIFICAÇÃO DE PRODUTO e não ESPECIFICAÇÃO DE SKU.
Se você cria um campo sku na raíz, todo produto que adicionar vai ter que alimentar com essa especificação.
Vou dar um exemplo prático:
Você criou o campo sku Tamanho(P,M e G) na raiz
Você cadastrou um categoria Smartphones
No cadastro do sku desse smartphone você vai ter que informar um tamanho P,M ou G... o que não faz nenhum sentido.
O usuário que entrar nessa página de produto vai ter que selecionar tamanho P, M ou G para conseguir comprar um produto
O Campo produto(especificação de produto) foi feito justamente para isso, não ser um campo obrigatório para o seu preenchimento mas pode servir como filtro.
Campo produto pode ser criado na raiz sem problemas, campo sku não!