• 0
mldev

Atributos e Desafio Attributes Run - opiniões

Question

o ML lançou o DESAFIO ATTRIBUTES RUN para os desenvolvedores (junto aos clientes integrados) subirem o maior número de atributos possível

em meio à vários problemas relatados aqui no fórum (falhas de requisição e servidor; conflitos entre atributos, variações; etc), é lançado o desafio e ainda é imposto ao vendedor que ele deve subir os atributos para não deixar de vender (perder exposição)

qual a opinião de vocês sobre isso???

Share this post


Link to post
Share on other sites

14 answers to this question

Recommended Posts

  • 0

Penso que isso complica cada vez mais a saúde da integração, pois já possuímos bugs que dificultam este processo.

Para fazer isso acontecer de fato temos que implementar gambiarras nos nossos sistemas, cada vez mais, o que adiciona mais e mais requisições e deixa tudo mais lento.

 

Logo já vamos ter clientes reclamando da lentidão.

Share this post


Link to post
Share on other sites
  • 0

Poxa! o Pedro acertou a pedra na boca da garrafa!

Eles querem os dados para tornar a plataforma mais profissional. Todos sabem qual a imagem que o grande público tem do ML. 
Também poder reutilizar dados, cruzar ofertas, entre outros.
Problemas sempre existirão.
Conflito e duplicidade, se fechar o campo para uma lista de atributos pré-definidos, ficaria engessado. Uma enxurrada de requisições de novos termos de atributos.
A imposição é comercial, se você coloca um prazo final a maioria vai deixar para a madrugada do prazo. Mas, mais uma vez o ML atropela os desenvolvedores. (viu isso??? eu sei usar o "mas" e o "mais")
Estão exigindo que todo os sistemas de gestão de vendas sejam ERPs monstruosos.

Acho que são alguns pontos.
 

Share this post


Link to post
Share on other sites
  • 0

já pegamos atributos absurdos, que não condizem com a categoria (aí o vendedor - com medo de ficar sem exposição - acaba colocando qualquer coisa), outros que são minimamente relevantes, e alguns relevantes são esquecidos...

também tem os casos de produtos totalmente genéricos (pra não dizer falsificados), onde o vendedor completa com dados do original ou mais conhecido... e o que falar dos kits?

 

com isso tudo o cruzamento de informações acaba mais atrapalhando do que ajudando... para se ter uma ideia esses dias mesmo vi um anúncio da loja oficial dos fones da Sennheiser tendo problemas pra explicar que o produto deles é original pois o ML cruzou as opiniões de clientes de outros vendedores (que vendiam produtos falsificados) e colocou elas destacado dizendo ser um produto falsificado

 

o ML faz isso para melhorar a plataforma, mas as custas do vendedor, atropelando o desenvolvedor e não pensando no cliente, ao meu ver o correto seria pedirem somente o EAN e no caso de produtos de grandes marcas (ex.: Apple, Samsung, etc) o ML ter departamentos para coletar dados diretamente com os fabricantes

 

1 hour ago, rodrigojob said:

Mas, mais uma vez o ML atropela os desenvolvedores. (viu isso??? eu sei usar o "mas" e o "mais")
 

ps.: que orgulho de ti guri! kkkk

Share this post


Link to post
Share on other sites
  • 0
5 hours ago, Jean said:

Isso sem contar a confusão que é na API entre ATTRIBUTES e VARIATIONS, uma bagunça só, kkkkkkkk.

nem fale! estão direto mudando coisas (fora as que simplesmente não funcionam como deveria); agora SKU e CONDITION passaram a ser atributos ... porque não fazem a mudança de uma vez só? ficar testando e mudando em ambiente de produção não dá!

Share this post


Link to post
Share on other sites
  • 0
4 minutes ago, mldev said:

nem fale! estão direto mudando coisas (fora as que simplesmente não funcionam como deveria); agora SKU e CONDITION passaram a ser atributos ... porque não fazem a mudança de uma vez só? ficar testando e mudando em ambiente de produção não dá!

Sim e para mim esse negócio de misturar Atributos com Variação é um pé, porque não tratar atributo como uma coisa e variação como outra, seria muito mais simples até para o entendimento da plataforma.

Share this post


Link to post
Share on other sites
  • 0
2 minutes ago, Jean said:

Sim e para mim esse negócio de misturar Atributos com Variação é um pé, porque não tratar atributo como uma coisa e variação como outra, seria muito mais simples até para o entendimento da plataforma.

nesse caso depende muito, por exemplo um microondas tem a voltagem (110v/220v) como atributo, mas esse atributo pode servir como a diferença para a variação... o problema é que a forma como implementaram isso tudo virou uma verdadeira lambança

Share this post


Link to post
Share on other sites
  • 0
On 07/03/2018 at 1:56 PM, mldev said:

nem fale! estão direto mudando coisas (fora as que simplesmente não funcionam como deveria); agora SKU e CONDITION passaram a ser atributos ... porque não fazem a mudança de uma vez só? ficar testando e mudando em ambiente de produção não dá!

Esse lance do SKU é bem sério. Peguei um bug recentemente onde eles estavam enviando na ORDER o SKU principal do anúncio e não da variação escolhida e o suporte informou que agora eles estariam pegando o SKU do atributo SELLER_SKU e não mais do seller_custom_field. Reclamei com eles que embora seller_custom_field não seja necessariamente o SKU, todo mundo usa desta forma, sai na etiqueta escrito SKU e o valor deste campo e inclusive na documentação deles fala prá colocar o SKU neste campo e se fossem alterar teriam que avisar com antecedência e ter um tratamento de compatibilidade copiando o campo seller_custom_field para este atributo novo. Aí repassaram pra equipe deles prá fazer a correção e voltar como era antes.

Share this post


Link to post
Share on other sites
  • 0
8 minutes ago, Diogenes Lima said:

Esse lance do SKU é bem sério. Peguei um bug recentemente onde eles estavam enviando na ORDER o SKU principal do anúncio e não da variação escolhida e o suporte informou que agora eles estariam pegando o SKU do atributo SELLER_SKU e não mais do seller_custom_field. Reclamei com eles que embora seller_custom_field não seja necessariamente o SKU, todo mundo usa desta forma, sai na etiqueta escrito SKU e o valor deste campo e inclusive na documentação deles fala prá colocar o SKU neste campo e se fossem alterar teriam que avisar com antecedência e ter um tratamento de compatibilidade copiando o campo seller_custom_field para este atributo novo. Aí repassaram pra equipe deles prá fazer a correção e voltar como era antes.

Só que ai para voltar como era antes e de fato ser feito, o QUANDO é outros quinhentos, kkkkkkk

Share this post


Link to post
Share on other sites
  • 0
16 minutes ago, Diogenes Lima said:

Esse lance do SKU é bem sério. Peguei um bug recentemente onde eles estavam enviando na ORDER o SKU principal do anúncio e não da variação escolhida e o suporte informou que agora eles estariam pegando o SKU do atributo SELLER_SKU e não mais do seller_custom_field. Reclamei com eles que embora seller_custom_field não seja necessariamente o SKU, todo mundo usa desta forma, sai na etiqueta escrito SKU e o valor deste campo e inclusive na documentação deles fala prá colocar o SKU neste campo e se fossem alterar teriam que avisar com antecedência e ter um tratamento de compatibilidade copiando o campo seller_custom_field para este atributo novo. Aí repassaram pra equipe deles prá fazer a correção e voltar como era antes.

é bem sério esse tipo de problema, tivemos problemas enormes com nossa integração por causa disso, eles copiaram o seller_custom_field para o SELLER_SKU , porém como não avisaram ninguém continuamos tratando pelo seller_custom_field, porém nos casos onde o vendedor alterou o seller_custom_filed posteriormente o SELLER_SKU ficou desatualizado, ou seja, uma enorme dor de cabeça... é muita falta de respeito com os desenvolvedores

Share this post


Link to post
Share on other sites
  • 0
8 minutes ago, mldev said:

é bem sério esse tipo de problema, tivemos problemas enormes com nossa integração por causa disso, eles copiaram o seller_custom_field para o SELLER_SKU , porém como não avisaram ninguém continuamos tratando pelo seller_custom_field, porém nos casos onde o vendedor alterou o seller_custom_filed posteriormente o SELLER_SKU ficou desatualizado, ou seja, uma enorme dor de cabeça... é muita falta de respeito com os desenvolvedores

Desconfio eu que com a última aquisição isto tende a piorar e em muito!

Share this post


Link to post
Share on other sites
  • 0
1 minute ago, Jean said:

Desconfio eu que com a última aquisição isto tende a piorar e em muito!

sim, exemplo disso é que ninguém nem aparece mais por aqui :(

Share this post


Link to post
Share on other sites
  • 0
19 hours ago, mldev said:

é bem sério esse tipo de problema, tivemos problemas enormes com nossa integração por causa disso, eles copiaram o seller_custom_field para o SELLER_SKU , porém como não avisaram ninguém continuamos tratando pelo seller_custom_field, porém nos casos onde o vendedor alterou o seller_custom_filed posteriormente o SELLER_SKU ficou desatualizado, ou seja, uma enorme dor de cabeça... é muita falta de respeito com os desenvolvedores

Eita, então fui o culpado, rsrs? Quando eu peguei o bug eu dei a sugestão de eles copiarem o conteúdo do seller_custom_field para o SELLER_SKU, mas eu falei que eles deveriam avisar com antecedência.

Veja a resposta deles quando questionei o problema:

Quote

 

Em retorno de nossa equipe responsável houve um equivoco ao capturar o seller_custom_field da variação ao invés do valor do seller_custom_field do item. Eles revisaram a lógica por trás da API de Orders e passaram que é esta:
 
Recomendamos usar o atributo SELLER_SKU para definirem as SKU's das variações, este atributo pode ser visto na API de categories/CATEGORY_ID/attributes ou mesmo, aproveitando este caso, sugiro ajustarem o sistema de vocês para verificar no item a variação que foi comprada na order pelo mesmo id, pois ambas estão na order e na variação do item.
  • atributo SELLER_SKU da variação
  • seller_custom_field de la variação
  • atributo SELLER_SKU no item
  • seller_custom_field no item

 

  •  

Minha resposta:

 
Quote

 

Não entendi muito bem. Houve um equívoco de qual lado? Na API por retornar os dados errados, ou no meu lado por usar os dados retornados pela API? Se foi na API, isso já foi corrigido?
 
De qualquer forma, esta explicação não faz sentido. Este atributo SELLER_SKU é recente e vários itens e variações não tem ele informado. Se vão usar ele como prioridade vocês deveriam ter copiado o conteúdo de seller_custom_field para o atributo SELLER_SKU. Mesmo assim, seguindo a lógica que vocês informaram não bate, pois se o atributo não existe, deveria ter pegado o seller_custom_field  da variação e isso não aconteceu. Na Order, veio o seller_custom_field do Item.
 
Não faz sentido a minha aplicação receber uma Order com um seller_custom_field e não poder confiar nesta informação, tendo que buscar no Item pelo ID da variação comprada para usar o SKU dela. Os dados retornados na Order são os dados no momento da compra e não sofrem alteração, já os dados do Item são os dados atuais e podem ser alterados. Se os dados do Item mudarem e meu sistema tiver que buscar estes dados do Item poderá haver inconsistências.
 
Eu entendo que seller_custom_field não necessariamente é o SKU do produto, mas se todos os usuários utilizam desta forma, se na documentação existe uma orientação quanto à isso e se até na etiqueta do ME este campo é utilizado como SKU, ele não pode ser alterado ou desconsiderado sem uma grande comunicação prévia para que todos possam se adaptar.
 

Peço que encaminhem estes questionamentos ao setor responsável, pois isso está gerando problemas com meus clientes.

 

A última resposta deles:

Quote

Houve um equivoco do lado do lado da equipe que ativou a captura do valor em seller_custom_field e enviou para o atributo SELLER_SKU, eles já estão verificando o ocorrido e enquanto isso não é efetivamente resolvido, foi sugerido que usem o id da variação que também vai na order para cruzar com i id do item.

 

 

 

 

 

Share this post


Link to post
Share on other sites
  • 0

a resposta deles mostra claramente que não sabem o que estão fazendo:

"Houve um equivoco do lado do lado da equipe que ativou a captura do valor em seller_custom_field e enviou para o atributo SELLER_SKU, eles já estão verificando o ocorrido e enquanto isso não é efetivamente resolvido, foi sugerido que usem o id da variação que também vai na order para cruzar com i id do item."

 

volta no problema que, capturar dados do anúncio = capturar dados atuais, sendo que podem não corresponder com os dados do item quando foi feita a compra (até porque ontem mesmo vi um caso de um cliente que pagou um pedido iniciado o ano passado, o que é um absurdo...)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now