OscarRocha

Members
  • Content Count

    27
  • Joined

  • Last visited

  • Days Won

    1

OscarRocha last won the day on June 15

OscarRocha had the most liked content!

About OscarRocha

  • Rank
    Newbie

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  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