Diogenes Lima

Members
  • Content Count

    146
  • Joined

  • Last visited

  • Days Won

    23

Diogenes Lima last won the day on December 12

Diogenes Lima had the most liked content!

3 Followers

About Diogenes Lima

  • Rank
    Newbie

Recent Profile Visitors

571 profile views
  1. Diogenes Lima

    Atualização de anúncio - nova variação

    Eu acho que tem algum erro de entendimento da sua parte. Quando for criar anúncios, precisa recuperar os dados da categoria e sua estrutura de atributos. Os atributos que estiverem com tag allow_variations somente devem ser utilizados em attribute_combinations de variações. Não use-os em attributes do anúncio. Os atributos que estiverem com tag variation_atribute somente devem ser utilizados nos attributes de variações. Não use nos attributes do anúncio. Para os demais atributos que não tiverem as tags destes acima, só devem ser utilizados nos attributes do anúncio e não devem ser usados em attribute_combinations nem em attributes das variações. Seguindo estas regras, diminui a quantidade de problemas. Aí só acontece problema quando o ML altera a regra de algum destes atributos e para corrigir o problema deve revalidar os dados, de forma que estejam dentro destes regras que citei. Lembrando que para corrigir, pode ser necessário efetuar alterações em 2 passos, por exemplo, enviando attributes vazio e depois os dados corretos, ou zerando as variações e depois enviando-as da forma correta, etc. No seu caso, não faz sentido enviar todos dados como atributes, como você citou que faz. Se o anúncio é simples e está criando sem variação, não deveria enviar os dados de COLOR e SIZE em attributes, senão vai ter problema mesmo, porém para a categoria informada, se eles são obrigatórios, significa que pelo menos uma variação é obrigatória, então deve montar um attribute_combinations e enviar estes dados lá em uma variação. Pode ou não enviar mais de uma variação, desde que esteja no mesmo formato. Se quiser, depois pode adicionar outras variações, sem alterar a estrutura de attribute_combinations.
  2. Diogenes Lima

    Atualização de anúncio - nova variação

    Funciona sim, pq ele está limpando attributes e não variations. Mesmo se tiver variações obrigatórias, o ML aceita. O problema é que vai perder os dados de atributos e a ficha técnica ficar incompleta, precisando preencher novamente depois. Mas seu problema era ao criar um item ou ao alterar? Ao criar, sua estratégia funciona, mas não teria motivo para enviar somente uma variação se está criando, pode enviar todas que vai funcionar da mesma forma. Se o problema for na alteração, alterar enviando só uma variação ou enviando uma lista também dá no mesmo. O problema costuma ser quando o ML troca um atributo "raiz" transformando-o em atributo de variação ou id de combinação de variação, ou vice-versa. Aí só "zerando" os atributos ou variações e enviando os dados de acordo com a nova estrutura.
  3. Diogenes Lima

    Atualizar descrição do anuncio

    A URL correta termina com "description" e não "descriptions". Tire o "s" do final da URL.
  4. Diogenes Lima

    gerenciamento de notificações

    Tem que tratar todas. Quando tiver alteração em SHIPMENTS, não necessariamente terá em ORDERS_V2. Este seria o funcionamento correto, porém as notificações falham muito e é bom ter processos redundantes para verificar os dados. Isso já foi comentado várias vezes aqui no forum. Com relação à tratar as duplicidades, não precisa. Se você recebe 2 notificações do mesmo resource e ainda não foi buscar os dados relacionados, quando for buscar, já estarão com os últimos dados, então pode tratar somente uma vez.
  5. Diogenes Lima

    Atributos caindo de forma errada.

    HEEL _TYPE é string, mas como tem uma lista com id e valor, envie value_id e value_name. RELEASE_SEASON a princípio parece correto. Eu cadastrei um anúncio nesta categoria para testar e estes dados foram cadastrados corretamente com os valores que informei.
  6. Diogenes Lima

    Atualização de anúncio - nova variação

    O problema neste caso é que antes de fazer a atualização do produto, o ML faz uma validação, então na validação eles encontraram a repetição dos atributos e já retornaram o erro, que poderia não existir caso a alteração fosse efetuada, mas aí precisaria fazer uma validação dos dados atuais e dos dados futuros e eles não fazem isso (o que é até justificável).
  7. Este fórum é para o MercadoLivre. O que você está tentando usar é o ME dentro do MercadoPago e as regras são diferentes. Tente entrar em contato com eles ou pesquise no forum do MercadoPago.
  8. Diogenes Lima

    Atualização de produtos.

    O que não pode ser alterado, não tem o que fazer. Finalizar e criar outro anúncio é meio irrelevante, pq ao criar um anúncio do zero ele não herda os dados do anúncio anterior, então não tem como considerar como se isso fosse uma alteração e sim um anúncio completamente novo (o que é diferente de recadastrar um anúncio finalizado). Como citado, seu questionamento está meio vago. Explique melhor a situação dando um exemplo.
  9. Lá no MyFeeds aparecerá o que foi enviado, para onde e qual foi a resposta. Confira se os dados lá estão corretos e qual a resposta registrada. Outra coisa, como você testou passando os mesmos parâmetros que o ML te enviaria se não recebeu nenhuma notificação? Como você realmente sabe se os parâmetros estão corretos? A Notificação é enviada para a sua URL via POST e não GET. Os dados vem no corpo da requisição e não na URL. Certifique-se de estar tratando como POST.
  10. Diogenes Lima

    Seller_invoices - Documentação incompreensível

    Sim, está no caminho certo. Mas pare de usar downvote para ordenar as postagens. Não é prá isso que serve e só dificulta entender a sequencia das mensagens.
  11. Diogenes Lima

    Seller_invoices - Documentação incompreensível

    Item 2 - A documentação não vai informar mesmo. Produto é um produto mesmo. Anúncio é a forma como você vende um produto. O ML trabalha com anúncios, a maioria dos ERPs trabalha com produtos, então precisa ter uma associação entre os produtos do ERP e os anúncios no ML e muitas vezes um único produto pode ter mais de um anúncio, ou um anúncio ser composto por mais de um produto. A forma de mapear essa relação é usando SKU, seja simples ou agrupado, agregado ou qualquer outro termo. Item 6 - Corrigindo o que informei antes, você pode associar a regra a vários campos, não somente ao NCM, dependendo da sua necessidade. Acredito que associar ao NCM seja mais prático, pois produtos com mesmo NCM devem compartilhar as regras fiscais, mas isso deve ser confirmado com seu contador. Na documentação informa que pode associar as regras usando NCM, EAN, SKU, CEST ou ITEM_ID (este último é o ID do anúncio no ML). Itens 5 e 7 - Tem exemplo lá na documentação sim. Precisa ler a documentação inteira. Para cadastrar as regras deve fazer conforme este modelo abaixo (o que vai mudar é code_type e product_code, conforme a forma de associar e também o rule e a configuração do value, que tem exemplo em cada item na documentação): Para o PIS por exemplo, no rule vai "PIS" e o value será conforme o template do PIS. Note que existe PIS e PIS_COMPOSITION que são regras diferentes e assim por diante. Json para Configurar as regras fiscais: EXEMPLO DE ICMS CST 10. curl -X PUT "https://api.mercadolibre.com/users/{user_id}/invoices/fiscal_rules?access_token=$ACCESS_TOKEN" { "code_type": "NCM", "product_code": "95030099", "customer_type": "TAXPAYER", "operation_type": "B2C", //atualmente só temos operações B2C*** "origin": "SP", "origin_detail": 0, "product_origin_type": "RESELLER", "rule": "ICMS", "transaction_type": "SALE", "tax_system": "NORMAL", "value": { "destinations": [{ "uf": "AC", "cst": "10", "modbc": 3, "picms": 18, "modbcst": 2, "pmvast": 18, "predbcst": 12, "picmsst": 7 }, { "uf": "AL", "cst": "10", "modbc": 3, "picms": 18, "modbcst": 2, "pmvast": 18, "predbcst": 12, "picmsst": 7 }, { "uf": "AM", "cst": "10", "modbc": 3, "picms": 18, "modbcst": 2, "pmvast": 18, "predbcst": 12, "picmsst": 7 }, { "uf": "AP", "cst": "10", "modbc": 3, "picms": 18, "modbcst": 2, "pmvast": 18, "predbcst": 12, "picmsst": 7 }, { "uf": "BA", "cst": "10", "modbc": 3, "picms": 18, "modbcst": 2, "pmvast": 18, "predbcst": 12, "picmsst": 7 }, { "uf": "CE", "cst": "10", "modbc": 3, "picms": 18, "modbcst": 2, "pmvast": 18, "predbcst": 12, "picmsst": 7 }, { "uf": "DF", "cst": "10", "modbc": 3, "picms": 18, "modbcst": 2, "pmvast": 18, "predbcst": 12, "picmsst": 7 }, { "uf": "ES", "cst": "10", "modbc": 3, "picms": 18, "modbcst": 2, "pmvast": 18, "predbcst": 12, "picmsst": 7 }, { "uf": "GO", "cst": "10", "modbc": 3, "picms": 18, "modbcst": 2, "pmvast": 18, "predbcst": 12, "picmsst": 7 }, { "uf": "MA", "cst": "10", "modbc": 3, "picms": 18, "modbcst": 2, "pmvast": 18, "predbcst": 12, "picmsst": 7 }, { "uf": "MT", "cst": "10", "modbc": 3, "picms": 18, "modbcst": 2, "pmvast": 18, "predbcst": 12, "picmsst": 7 }, { "uf": "MS", "cst": "10", "modbc": 3, "picms": 18, "modbcst": 2, "pmvast": 18, "predbcst": 12, "picmsst": 7 }, { "uf": "MG", "cst": "10", "modbc": 3, "picms": 18, "modbcst": 2, "pmvast": 18, "predbcst": 12, "picmsst": 7 }, { "uf": "PA", "cst": "10", "modbc": 3, "picms": 18, "modbcst": 2, "pmvast": 18, "predbcst": 12, "picmsst": 7 }, { "uf": "PB", "cst": "10", "modbc": 3, "picms": 18, "modbcst": 2, "pmvast": 18, "predbcst": 12, "picmsst": 7 }, { "uf": "PR", "cst": "10", "modbc": 3, "picms": 18, "modbcst": 2, "pmvast": 18, "predbcst": 12, "picmsst": 7 }, { "uf": "PE", "cst": "10", "modbc": 3, "picms": 18, "modbcst": 2, "pmvast": 18, "predbcst": 12, "picmsst": 7 }, { "uf": "PI", "cst": "10", "modbc": 3, "picms": 18, "modbcst": 2, "pmvast": 18, "predbcst": 12, "picmsst": 7 }, { "uf": "RJ", "cst": "10", "modbc": 3, "picms": 18, "modbcst": 2, "pmvast": 18, "predbcst": 12, "picmsst": 7 }, { "uf": "RN", "cst": "10", "modbc": 3, "picms": 18, "modbcst": 2, "pmvast": 18, "predbcst": 12, "picmsst": 7 }, { "uf": "RO", "cst": "10", "modbc": 3, "picms": 18, "modbcst": 2, "pmvast": 18, "predbcst": 12, "picmsst": 7 }, { "uf": "RS", "cst": "10", "modbc": 3, "picms": 18, "modbcst": 2, "pmvast": 18, "predbcst": 12, "picmsst": 7 }, { "uf": "RR", "cst": "10", "modbc": 3, "picms": 18, "modbcst": 2, "pmvast": 18, "predbcst": 12, "picmsst": 7 }, { "uf": "SC", "cst": "10", "modbc": 3, "picms": 18, "modbcst": 2, "pmvast": 18, "predbcst": 12, "picmsst": 7 }, { "uf": "SE", "cst": "10", "modbc": 3, "picms": 18, "modbcst": 2, "pmvast": 18, "predbcst": 12, "picmsst": 7 }, { "uf": "SP", "cst": "60", "pfcpufdest": 0, "picmsufdest": 0, "picmsinter": 0 },{ "uf": "TO", "cst": "10", "modbc": 3, "picms": 18, "modbcst": 2, "pmvast": 18, "predbcst": 12, "picmsst": 7 }] } }
  12. Diogenes Lima

    Seller_invoices - Documentação incompreensível

    Você precisa verificar várias coisas. Em primeiro lugar, veja a Consideração importante: Esta documentação está destinada aos Sellers que são Regime Normal e atuam em Fulfillment Partindo deste princípio, o que esta documentação trata é como associar os dados fiscais e as regras para que o sistema do ML faça a geração das notas de forma automática, logo, pode-se presumir que já existe um processo interno da empresa para emissão de notas e a documentação trata apenas de receber esta mesma configuração para que a emissão dos itens do fulfillment seja feita de forma automática pelo sistema do ML. Sendo assim já deve-se considerar que os anúncios (produtos) já estão cadastrados de forma correta no ML com o SKU e que já existe um mapeamento interno da empresa no ERP dela com relação ao CFOP, NCM, PIS, COFINS, ICMS (normalmente fornecido ou controlado pelo contador). Basta fazer um levantamento dos dados dos anúncios e das regras existentes na empresa e montar um processo de inclusão e atualização destes dados junto ao ML. Precisa entender a diferença entre produto e anúncio e como identificá-los tanto no ERP quanto no ML e quais dados fazem parte dos mesmos. Com relação às suas dúvidas: 1) O que seria o "sku"? O código interno do produto no ERP? O código do produto já anunciado no ML? É um código interno do vendedor associado ao anúncio. Entre outras coisas, serve justamente para associar o anúncio ao código de produto no ERP. Não é o ID do anúncio. 2) Devo primeiro enviar um produto pela API e depois vincular os dados fiscais? São processos separados, porque a configuração é feita partindo do SKU e o produto só precisa ter o SKU para que seja associado às regras. Após criar uma regra, se criar um novo anúncio e usar o mesmo SKU, a configuração anterior já vale para ele, porque está associada ao SKU. Se tem um produto com variações e cada uma tem um SKU, deve associar as regras para cada SKU existente. 3) O id do anúncio já não é o produto/SKU? Não 4) transaction_type (sale, inbound, devolution): o que exatamente devo enviar? Se a intenção é gerar nota de venda de forma automática, deve informar que é venda. Acredito que isso seja auto-explicativo. 5) Como e onde faço o vínculo de PIS/COFINS? Na documentação tem as informações de Configuração do PIS e Configuração do COFINS. É só usar o template. Com relação aos dados, seu contador pode informar (ou o processo já existente no ERP da empresa) 6) Campo "destinations": é enviado por produto? Por SKU? Por NCM? Seu contador pode informar como se aplicam as regras. A configuração do ICMS é feita por NCM. Pela documentação, você associa um SKU a um NCM e associa as regras ao NCM. O anúncio já deve ter o SKU associado. 7) CFOP: deve ser informado por mim? Como? Onde? Vale a mesma regra dos itens acima e tem um item chamado Configuração do CFOP.
  13. Diogenes Lima

    Lentidão ao listar produtos

    Olhando só código não tem como determinar onde está a lentidão. Você precisa incluir estruturas de log e monitoramento no seu código, nem que sejam temporárias para verificar quais são os pontos de maior lentidão. Note que você tem interação entre tela (interface ou navegador), seu servidor PHP, a API do ML e um banco de dados, fazendo consultas e inserções de dados. Qualquer um destes pontos pode apresentar lentidão e note também que é um processo em lote, logo, qualquer lentidão em 1 ponto será multiplicada pela quantidade de itens. Se prá buscar 1 item demora 0,5 segundo, para 50 itens, serão 25 segundos e assim por diante.
  14. Diogenes Lima

    Refresh Token Expirado ou Usado

    Às vezes acontece erro mesmo neste processo. Infelizmente não tem muito o que fazer a não ser forçar o usuário a fazer outro login para pegar tudo novo de novo. De qualquer forma, verifique se não tem algum erro na sua aplicação. A renovação do token preferencialmente deve usar um processo "singleton" para evitar que 2 ou mais processos concorrentes tentem atualizar o token do mesmo usuário ao mesmo tempo.
  15. A forma que você postou seu objeto aqui é horrível para entender a estrutura. Às vezes não basta dar um dump da variável e postar porque continua ruim. Da próxima vez tente formatar melhor os dados antes de postar. Sua estrutura está errada, pois "attribute_combinations" precisa ter uma estrutura definida. Uma "combination" é um conjunto de dados e cada conjunto possui um conjunto de atributos, portanto, traduzindo em PHPês, significa que deve ser um array dentro de outro array, mesmo que este primeiro array possua somente um objeto (tamanho, no seu caso). Algo assim: $combination = [ "id" => "SIZE", "name" => "Tamanho", "value_id" => "317548", "value_name" => "P" ]; $attribute_combinations[] = $combination; //caso tivesse outras combinações, como COR, você repete os passos acima, criando a combinação e adicionando ao array attribute_combinations. O erro no seu código é que em attribute_combinations você colocou os dados da combinação direto e não dentro de outro array, por isso o ML está retornando este erro que citou. Outra coisa, você precisa verificar a categoria para ver se as variações obrigatórias foram informadas, pq no seu código você não informou o ID da combinação (SIZE, no meu código), mas se for obrigatório, vai dar erro. Além disso, se realmente não for usar o que a categoria informa como variações, náo deve usar o value_id nas combinações, pois eles só s]ao válidos quando usa os dados da combinação conforme a categoria estabelecer.