OscarRocha

Members
  • Content Count

    27
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by OscarRocha

  1. o sábes que.. podrías usar una trakalosa al llamar el método podrías usar un parámetro, por ejemplo limit ponle de valor esto "50&sort=date_desc" jajajaja igual y jala .. está bien rancio todo 😉
  2. oo busca dónde están definiendo el método ordersSearchGet en esa librería y agrégale el parámetro de "sort" y de valor, le pones "date_desc" &sort=date_desc y cuando la mandes llamar le agregas ese valor date_desc ó duplica el método y le alteras esa parte yo usé node js a patín, porque sus librerías estaban sin actualizarse hace un buen.
  3. la verdad no lo pude resolver... existe una alternativa del API usando algo que le llaman scan o scan_id algo así era.. que es como usar paginación por nav te generaba un id dinámico para ver las siguientes 50 ordenes venía documentado en el recurso de los items o publicaciones... ya no lo encuentro pero el problema es que te consume mucha memoria porque no tiene un índice de donde empezar... entonces ocupas recorrer todas las primeras 10,000 orders con eso para poder ver las siguientes 10,050 y así te vas iterando pero no hay forma de definir límites así que se va hasta el final a menos que tu lo detengas... pero pero pero esas cosas sólo soportan un máximo de 50 ordenes por llamada 🙂 pregunte al soporte y me quejé un buen, el foro está sólo... Si funcionó esa opción, pero tumbaba la memoria y not worth... Mejor en la APP reestrinjo al cliente que sólo puedo sacar hasta 10,000 y ya 🙂 🙂 🙂 es bueno saber que no soy el único con ese problema.
  4. Hola CGFT2008 Si, si hay forma, para las últimas órdenes ocupas poner el orden de forma descendente y el offset en 0 desde la llamada al API. Algo así .. &sort=date_desc&offset=0 https://developers.mercadolibre.com.mx/es_ar/gestiona-ventas La verdad es que los límites del API para obtener datos están están muy pobres el máximo de órdenes por llamada es de 50.. y son muy pocas, entonces si quieres sacar más ocupas iterar la llamada con offset=1 y así 2, 3, 4 hasta las que ocupes. el máximo de órdenes por sacar con offset es hasta 10,000 ordenes o un offset de 199 Si tienes más hay otro método tipo nav que le llama scann_id pero no sirve mucho, te consume toda la memoria y no hay forma de usar indice , entonces ocupas recorrer otra vez las primeras 10,000 ordenes para llegar a sacar las siguientes 10,050 y no puedes ver historial mayor a 1 año, lo borraron así está el API de ... buena 😉
  5. ok gracias Fernando, ya se, estoy de acuerdo en evitar saturar al API, por eso uso los resultados JSON. Esto no se trata de hacer más requests al API, en eso no hay alternativa y creo que es lo mejor. Por eso ellos me dijeron que sacara 1 request a Orders en lugar de usar su nueva forma de obtener ordenes de mshops desde orders con el tag en la url. El problema principal es la solución propuesta para la estructrua de datos. Se mezclaron las ordenes de MeLi con MShops en el request de orders general Para identificar si la orden es mshops, agregaron al atributo "tags" el valor "mshops" en las órdenes. Entonces hay que iterar tags. "tags" es una lista desordenada de tamaño diferente en cada orden que puede seguir creciendo y en la que el valor "mshops" aparece en posiciones diferentes de la lista. Pareciera como un comodín de valores random. Y para identificar si es meli, debemos iterar "tags" también a ver si no tienen mshops... pues ok Sería más simple y eficiente crear una etiqueta "channel" que tuviera 1 de estos valores: "mshops" ó "meli" Por cierto, aunque no es la ruta que quería, al final ya lo iteré para saber si es mshops o meli ojala alguien sepa como hacerlo por JSONPATH gracias
  6. gracias por responder @Fernando Aguirre , ok es lo que imaginé que sería, está bien explicada la lógica, sólo que quería evitar tener que hacer un cálculo previo para nosotros tener que pre-clasificar las órdenes en lugar de usar los resultados del JSON directamente como opción. Estoy buscando algo más del lado de JSONPATH en lugar de hacer esa pre-clasificación en el código o middlewear para evitar usar memoria o recursos de más. /results[status='paid' and tags!='mshops']/total_amount
  7. Hola, Busco ayuda con el tema del tag de mshops, con la comunidad. Tengo unas dudas. Esta es la documentación --> https://developers.mercadolibre.com.pe/es_ar/gestiona-ventas#%C3%93rdenes-Mercado-Shops Mi app intenta mostrar las ventas por ambos canales y me ha dicho soporte que no use el tag="mshops" en la ruta del recurso al hacer la llamada, sino más bien completas o sin el tag (para ahorrar llamadas al API) y en su lugar yo haga el filtro internamente. Tal vez sea algo tonto de mi parte o la solución es muy lógica.. pero no la veo, me dicen.. "pues si no existe un tag meli saca la inversa".. algo como tag!='mshops' pero noo esa no sería su inversa... porque el atributo tag, puede tener más valores como bien saben Vean los resultados que me trae esta ruta json (muy seguramente la tendré mal, ¿alguien sabe como quedaría la correcta?) /results[status='paid']/total_amount --> 401 resultados /results[status='paid' and tags='mshops']/total_amount --> 163 resultados órdenes mshops. Si uso el request de orders con tag=mshops, si me trae las 163 orders /results[status='paid' and tags!='mshops']/total_amount --> 401 resultados -- pero porque acá no le quita los 163 al usar el not tag !=mshops ... bueno si se, es porque la ruta encuentra más tags que no son mshops en cada una de las mismas ordenes y entonces si las cuenta. Hay más tags.. Para obtener el total de ventas por canal mshops si funciona meli no funciona Entonces con estos resultados, estaría duplicando las ventas de mercado shops al esconderlas en mercado libre... y hay quién me dirá.. pues réstale el valor que te da de mshops.. pero pues creo que ya se perdió parte de la eficiencia ahí. Imaginen hacer esto para al menos 10,000 orders. La otra solución que se me ocurre sería iterar o mapear por un lookup para sacar los Order_ID's que si sean mshops y nosotros descartarlos para que sean meli. Esta solución.. quita mucha memoria & recursos. quisiera saber ¿Cómo le hacen para poder distinguirlas, en especial las de 'meli' ya que existe el tag de 'mshops' pero no existe el tag de 'meli'? a varias APPs les debió dar este error o ajuste para las cuentas que hicieron el merge con Mercado Shops 2.0 si antes como yo también sólo hacían el request de orders directamente. le decía al soporte que sería mejor agregar un atributo 'channel' con valores 'meli' ó 'mshops' en lugar del atributo tag con valor adicional 'mshops'. Justo como está el API de Mercado Shops 1.0 sin más valores en las rutas. Alguien, alguna idea? o entendí mal la solución gracias
  8. Hola Quería preguntarles del nuevo update en el recurso de las Ordenes, en el cual agregaron más límites y ya no podremos traer datos históricos mayor a un año por el API https://developers.mercadolibre.com.ar/es_ar/gestiona-ventas#Búsqueda-de-órdenes saben por qué se hizo esto? y si los datos históricos fueron borrados? ó sólo no se pueden consultar.. alguien más ha salido afectado por esto? y tendrán pensado hacer otro end-point para poder leer todo el histórico, algunos me dirán que con las bases de datos que vamos generando será suficiente pero por ejemplo de alguna cuenta nueva que llegáramos a integrar, para poder conocer sus ventas del mismo mes en el año anterior. Creo que este límite nuevo afectará negativamente algunas aplicaciones. Ojala puedan dar una alternativa de revisar la información de años anteriores. Sería bueno que se ampliara el límite a por lo menos 2 ó 1 año y 6 meses en lugar de sólo un año. Había mucha información valiosa que puede mejorar la toma de decisiones para cada temporada con base a históricos y repito, con cuentas recién integradas, no será posible tener. gracias
  9. Hola Ariel pudiste solucionar este problema? en mi caso intenté scroll_id para orders, sólo que se me muere el server al hacer tantas peticiones por minuto para poder recorrer todas las órdenes en una cuenta con más de 28,000.. ando buscando como separar las llamadas. aparte ya tenía hecho scroll_id para items que sigue funcionando, sólo que la diferencia es que son 2500 productos
  10. Mismo problema a mi me respondieron que usara el scroll_id dicen que si funciona para todos los recursos, aunque en la documentación sólo salga para items y questions https://developers.mercadolivre.com.br/es_ar/nueva-modalidad-para-realizar-busqueda-con-el-recurso-search avísame si logras adaptarlo a scroll_id
  11. Hola El día de ayer 16 de mayo, unos recursos de orders que tenía conectados dejaron de funcionar, pero no todos. Sólo los que tenían un offset > 9950. Como si se hubiera hecho un update en el API.. pero no encontré documentación. y lo raro es que al usar ordenamiento ya sea desc o asc , si me traen las ordenes correctas, ya sean las últimas órdenes recibidas ó las primeras históricas y al poner offset > 9950, en ambas marca error. End-Point: https://api.mercadolibre.com/orders/search?seller={props.MeLi_Seller_Id}&offset=9950&sort=date_desc&access_token={props.MeLi_Token} https://api.mercadolibre.com/orders/search?seller={props.MeLi_Seller_Id}&offset=9951&sort=date_desc&access_token={props.MeLi_Token} Alguien más tiene este problema?
  12. Corrijo. Si me está funcionando bien el atributo available_quantity, me está trayendo el real.
  13. Hola Fernando Me pasó lo mismo hace un par de días, todos los tokens que tenía activos con refresh caducaron y apuntaban a null en mi base de datos. Tuve que repetir el proceso de creación de token para cada cliente y pedirles que autorizaran nuevamente desde cada sesión activa. -- Esto mismo ya me había sucedido en Noviembre cuando tenía 1 sólo cuenta activa y que habían cambiado a cuentas colaborativas de esta cuenta, pero en esta ocasión no me enteré de algún cambio similar. Estoy pensando que podría ser alguna falla del lado de mi servidor Heroku que estuviera intentando hacer el refresh y no obtendría respuesta de MeLi en ese momento.. que estuviera dormido o alguna coincidencia de petición y fallo al mismo tiempo. Pero lo tengo configurado para que lo intente nuevamente por si no funcionara la primer llamada, a los 30 segs.. y a las 3 horas otro refresh por precaución. No estoy seguro a que se pudo deber esto, pero me ha pasado 2 veces en 7 meses
  14. Hola, gracias por responder juvian parece que si es eso, directamente ya hice los request y si trae los valores correctos con multiget debo haber omitido el token en mi app
  15. Una idea que tengo desarrollada en la app es un cálculo sobre todo el "histórico de ventas" (mucho procesamiento de datos innecesario) inventario actual = initial_quantity - "histórico de ventas" el resultado si es un valor cercano a las unidades disponibles de la vista del producto .. pero no es el exacto en la práctica .. porque si a un producto se le agrega stock después de un tiempo, el initial_quantity ya no funciona en la fórmula. ojala alguien más pueda aportar a este tema o confirmar lo que dice juvian
  16. Hola Estoy trabajando con available_quantity y sold_quantity del recurso de items para revisar manejo de inventarios de más de 2500 items y Viendo la documentación, por API arrojará un valor referencial en lugar del real como en la vista de producto al público. https://developers.mercadolibre.com.mx/es_ar/items-y-busquedas#close Mis dudas son si Saben de alguna opción / plan para trabajar con el API y poder traer los valores reales, como en la vista de producto? porque al hacer el request.. la mayoría de los productos aparecen con 1 o 50 y es un rango muy limitado para poder hacer cálculos.. o alguien tiene consejo o buenas prácticas para trabajar con inventarios por API thx _________________________________________ copio parte de la documentación de items https://developers.mercadolibre.com.mx/es_ar/items-y-busquedas#close Valores en campos "sold_quantity" y "available_quantity En los recursos públicos de Items y Búsquedas la información de los campos "sold_quantity" y "available_quantity" será referencial en base a estos valores: available_quantity RANGO_0_50 -> 1 RANGO_51_100 -> 50 RANGO_101_150 -> 100 RANGO_151_200 -> 150 RANGO_201_250 -> 200 RANGO_251_500 -> 250 RANGO_501_5000 -> 500 RANGO_5001_50000 -> 5000 RANGO_50001_99999 -> 50000
  17. Hola, el viernes 2 de Noviembre me respondieron al ticket que mandé al soporte del API dijeron que habían encontrado ellos un error en el API y que lo habían corregido pero no me dieron detalles Después de eso hice pruebas con el código en versión local y versión online y todo volvió a funcionar ? ? ? .. les pregunté qué había sido.. pero no me han respondido
  18. gracias por la explicación Fernando ? eso me ayudará a trabajar con esta API.. entonces por las limitantes tiene que ser por base de datos yo lo que hacía era hacer 1 llamada y lo cacheaba en un server tercero, después metía cron jobs entre 4 y 24 horas según el movimiento de las órdenes diario del vendedor, así ya no dejaba que el usuario hiciera llamadas al API de MeLi. Pero el historial yo si lo volvía a pedir completo o al menos la parte que ocupo para presentar. Debo modificar esa parte para que sólo haga llamadas a lo reciente. Lo que me extraña es el limitante de 50 por call. Es decir para sacar 500 datos debo hacer 10 llamadas de jalón... pienso que eso es peor para el server de MeLi que hacer 1 sola de 500. Parecieran bases para saturar al server si fuera un ataque DDoS. También encontré el límite por hora de llamadas por token, eso lo debería prevenir. Me ha tocado trabajar con más APIs de otros marketplaces o e-commerce u apps en donde también ocupo traer información de órdenes.. (pensando que el json x orden es similar en tamaño) .. y la mayoría permite traer un limte más grande a 50 ... por eso me extraña que el server de MeLi lo reestringieran tanto. Te ha pasado que a veces alguna llamada falle con time out y si la vuelves a correr funciona.. ? Me ha estado pasando.. Si tengo que hacer muchas llamadas y falla alguna debo volver a pedir esa para no tener el GAP.
  19. disculpa mldev sabes si hay alguna forma de pedirle a Mercado Libre que se incremente el valor del límite máximo de 50 ? Como crear un thread al respecto, una solicitud o votación de la comunidad? O si con la certificación que conseguí hace poco, que te liberen por decir a 250 o 500 en el limit. Quisiera saber porque está esta restricción del atributo limit.. que según entiendo sólo sirve de 1 - 50.. alguien si preferirá traer menos datos en 1 llamada para paginar más veces? a mi parecer le perjudica más al server de MeLi tener que hacer muchas peticiones para iterar las órdenes en lotes pequeños que hacer un request con varios resultados o por ejemplo en el caso de los products con multiget que se ocupa primero obtener el id de cada producto y después hacer otra llamada para obtener la información.. es como si fuera tendencia de tener el API como una base de datos relacional y me parece que perdería parte del sentido del API, bueno al final es obtener los datos por otro medio pero su estructura se me hace fuera de lo común. Voy a considerar lo que dice Gajosu de lo de guardar los resultados en una base de datos para aquellas órdenes antiguas que es probable que ya no reciban cambios.
  20. Hola, yo estoy teniendo un problema similar. Tenía mi aplicación funcionando ya hace unos 7 meses y de repente .. sin modificar código ni nada empezó a tener errores. Lo que hago con mi aplicación es generar llamadas de orders e iterar el offset para obtener un historial de órdenes.. pero descubrí que de repente, algunas iteraciones las arrojaba como undefined null... por lo tanto no recibo nada y en mi JSON final obtengo GAPS vacíos. Entonces antes podía traerme todas las órdenes en menos de 1 o 2 segundos y ahora es como si me restringiera el número de peticiones en un periodo muy corto. Estuve debuggeando y encontré que me da respuesta de time_out de forma aleatoria por parte del servidor de MeLi. a alguien más le ha pasado? Alejandro.. pudiste resolverlo?
  21. Hola Soy algo nuevo con el API de Mercado Libre, estuve trabajando con el API de Mercado Shops ya unos meses y ahora he estado investigando en la documentación pero por más pruebas que realizo no logro esto, ojala me puedan ayudar. Estoy intentando traerme todo el histórico de órdenes de un vendedor pero sólo logro traerlo en lotes de 50 como máximo. Es posible traer más de una llamada? por decir 500 o 1000 en una sóla llamada. https://api.mercadolibre.com/orders/search?seller={seller_id}&limit=50&access_token={access_token}#json Ya leí la paginación por offset para recorrer las siguientes 50 órdenes, ya la implementé y todo.. sólo agrego el parámetro offset=50 y voy iterando en la url. El problema es que en recursos llega a ser algo tardado por todas las múltiples instancias que llego a crear. Por decir tengo 7500 órdenes, para iterar el offset llego a crear 150 requests... y he tenido problemas de forma aleatoria en donde el servidor de MeLi me regresa undefineds o nulls como si me bloqueara o limitara el número de request en poco tiempo. Por consiguiente me arroja GAPs de periodos sin ordenes.. Creo que si lograra traerme al menos de 1000 órdenes en un request se resolverían varios problemas de performance y reduciría las llamadas en poco tiempo. yo pensaba que agregando limit=1000 podría pero no encuentro nada de un máximo en el limit en la documentación { "message": "Oops! Something went wrong...", "error": "limit.maximum_exceeded", "status": 400, "cause": [ ] } Encontré sobre otros recursos del uso de &search_type=scan pero parece que sólo funciona con items y preguntas Espero que me puedan ayudar con algún ejemplo o un link donde venga esta información, o si fue un tema anterior.. estuve buscando mucho. Por favor no me bateen u.u ya lo han hecho antes con otras de mis dudas y veo que pasa muy seguido en este foro gracias
  22. Hola, buen día. Estoy teniendo problemas con un par de cuentas de mercado libre, a las cuales, al hacer el request de todas las ordenes, el json me lo arroja con la estructura correcta pero los resultados vacíos. Estoy usando el siguiente request de mercadoshops 1er request: https://api.mercadoshops.com/v1/shops/$ID_CUENTA/orders/search?offset=0&access_token=$TOKEN Aclaro que estas cuentas son sólo mercado libre, y si tienen órdenes completadas ya hace más de 5 meses. Sin embargo, tengo otro cliente con las mismas condiciones de sólo tener mercado libre y el request ha funcionado correctamente aun sin tener mercadoshops. Por lo que el request no debe ser el problema sino algún atributo de la cuenta o permiso. O como si hubiera una condición por cumplir para poder hacer uso de la API y su consumo. .. Comparé una cuenta de mercadolibre que a la cual si funciona el request vs estas otras 2 con el siguiente request de mercadoshops https://api.mercadoshops.com/v1/shops/$ID_CUENTA?access_token=$TOKEN Y los resultados los trajo correctos trayendo todos los atributos de la cuenta. Las diferencias que encontré son: Las 2 sólo tienen mercadolibre Cuenta que SÍ funciona el 1er request vs Cuenta que NO funciona el 1er request plan: Basic - Profesional on_trial: False - True los demás parámetros booleanos están iguales Otra prueba usando un request de mercadolibre https://api.mercadolibre.com/users/$ID_CUENTA?access_token=$TOKEN Cuenta que SÍ funciona el 1er request vs Cuentas que NO funciona el 1er request transactions - completed 740 - 117 seller_reputation - level_id "5_green" - "3_yellow" seller_reputation - power_seller_status "silver" - null status - confirmed_email true - false status - mercadopago_account_type: "professional" - " personal" context - source: "mercadopago" - "mercadolibre" Alguien que sepa si nos hace falta algún proceso para poder consumir las órdenes por mercado shops o algún permiso del token necesario. Los tokens al compararlos tienen los mismos permisos. gracias
  23. Debe ser otro problema porque la cuenta de mi cliente es cuenta oficial. De hecho este cliente me pasó acceso a otra cuenta más, también oficial y las dos están presentando el mismo problema de que a pesar de tener pedidos ya hace meses, estos no los muestra en el resultado del JSON, sólo vacío. Encontré este formulario para pedir ayuda al soporte, cuando tenga solución, la comento por aquí. https://developers.mercadolibre.com.mx/support