Diogenes Lima

Members
  • Content Count

    159
  • Joined

  • Last visited

  • Days Won

    26

Everything posted by Diogenes Lima

  1. Não é jeitinho brasileiro. O correto é não alterar mesmo. Uma venda deve ter os dados do anúncio no momento da venda e não permitir a alteração se o anúncio original for alterado. Já pensou se toda venda tivesse o valor alterado cada vez que você alterasse o preço do anúncio?
  2. Para integração com o MercadoPago apenas você deve verificar a documentação e o suporte deles diretamente. Este fórum é apenas para a integração com a API do MercadoLivre.
  3. Olha bem o que tá escrito: se você estiver trabalhando com local host poderá utilizar http. No redirect -uri você pode colocar http://localhost para testar de forma local sem problema nenhum.
  4. Só voltei a ver isso hoje. Recomendo não deixar tudo em uma mesma máquina, mas se não puder, se forem instâncias isoladas já ajuda. Só não deixe tudo em uma mesma instância Mesmo que ela seja muito parruda, os recursos ficam concorrendo entre si. Aqui eu uso servidores bem parecidos que o seu e a performance tá suave, mesmo nos picos de processamento. Processo em média 3000 notificações por minuto com picos de até 8000 por minuto e tá de boa. Sua configuração está boa pro banco. Eu separaria o front end nesta máquina de 4GB e deixaria outra instância de 4GB semelhante, para os processos de backend e cron. E esta outra instância de 1GB apenas para receber notificações do ML e colocar em uma fila. Assim ela não concorre com o front end e não prejudica o acesso dos seus usuários nos momentos de pico. Além disso, se ela ficar sobrecarregada, seus usuários não perdem o acesso. Não esqueça de ajustar o nginx com relação à memória usada, quantidade de conexões, etc. O mesmo para a máquina do banco de dados. Se possível troque o mysql pelo mariadb. Eles são compatíveis, mas o mariadb gerencia um pouco melhor a memória na minha opinião.
  5. É o id principal do seu usuário no ML. O mesmo que tem em orders no seller_id e em vários outros lugares.
  6. Aquela redução do multiget que era para o dia 31 parece que entrou hoje também para a impressão de etiquetas. Ao enviar mais de 20 ids para imprimir, vem erro que só pode enviar no máximo 20. ML sendo ML.
  7. Seu erro é porque o picture_ids de cada variação é um array e você está enviando uma única string em cada um.
  8. Parece mais problema com alguma lógica do que com o banco em si. Sua máquina parece parruda demais para ter este tipo de problema. O servidor de aplicação está separado do banco? Caso não esteja desta forma, recomendo separar o banco de dados em uma máquina única. Outra apenas para receber as notificações e outra para processar filas de notificações, por exemplo. Qual servidor de aplicação você usa? Quantas notificações você recebe por minuto aproximadamente?
  9. Isto é um bug do ML. Se o vendedor adicionou a anotação pela interface do ML, a API não irá retornar nestes casos mesmo e só aparece lá no front deles. Se você adicionar pela API, o que você adicionou aparece na API e também lá no front do ML.
  10. Acho que você precisa voltar atrás um pouco pra entender alguns conceitos mais básicos. A sua chamada de upload é para enviar somente o caminho de uma imagem já hospedada. Se você criou um curlfile, não vejo sentido chamar um json_encode para ele. Você precisa entender quais são os dados com os quais está trabalhando para entender o que pode ou não ser feito com eles. Do jeito que você fez está enviando apenas textos (strings) e por isso não funciona. Nem sempre o SDK do ML irá prover tudo que você precisa. Em alguns casos, como este, é necessário criar uma nova chamada específica para atender o que você precisa. Lembre-se também que às vezes, mesmo que o seu código consiga enviar dados em um formato, é necessário que a API esteja preparada para receber e tratar os dados no mesmo formato.
  11. Eu acho o validador desnecessário, mas de qualquer forma, você precisa interpretar o resultado do validador. Note que o tipo é "warning", ou seja, é apenas um aviso. A mensagem informa que o frete grátis obrigatório foi adicionado, ou seja, é apenas um alerta e não um erro impeditivo. É só enviar os dados do anúncio no endpoint de criação que ele será criado normalmente.
  12. Você precisa rever a documentação da API. Normalmente para criação de alguma coisa, usa-se o POST. Para alteração, usa-se o PUT. Existem casos onde a alteração não se enquadra em um PUT, pois ela é uma alteração de condição (não sei se este é o termo correto). Para alterar o listing_type você não envia os dados do anúncio nem usa a URL do anúncio e sim uma URL específica para esta alteração, enviando no ID do corpo da requisição o ID DO NOVO LISTING_TYPE. Esta informação de como alterar o LISTING_TYPE está neste link: https://developers.mercadolivre.com.br/pt_br/tutorial-tipos-de-publicacao-y-atualizacao-de-artigos Com relação ao frete, depende de várias outras condições para saber se está correto ou não e se pode ou não ser alterado.
  13. Dê mais detalhes, pois existem várias formas de "solicitar listagem" de anúncio. Dê exemplo de qual chamada está fazendo, se tem alguma pesquisa, se está usando access_token, etc.
  14. 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.
  15. 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.
  16. A URL correta termina com "description" e não "descriptions". Tire o "s" do final da URL.
  17. 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.
  18. 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.
  19. 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).
  20. 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.
  21. 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.
  22. 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.
  23. 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.
  24. 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 }] } }
  25. 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.