Tareas Automáticas¶
Producto: OpenConnect | Módulo: Administración de la Plataforma | Última actualización: 2026-08-12
Introducción¶
Este libro lo usa el equipo de OpenX, no un comercio. No hay una pantalla para esto: son procesos que corren solos, en el servidor, sin que nadie los dispare. Esta página explica qué hace cada uno en términos de negocio y con qué frecuencia, para que al equipo de OpenX le sirva de referencia cuando un comercio reporta algo que "debería haber pasado solo" y no pasó.
Cada 2 minutos¶
Busca pedidos nuevos en los marketplaces conectados. Es la vía principal por la que un pedido hecho en MercadoLibre, Falabella, Ripley, Paris o Walmart entra a Órdenes en OpenConnect. Si un comercio dice que "no le están llegando los pedidos", este es el primer proceso a revisar.
Cada 5 minutos¶
- Empuja el stock disponible hacia los marketplaces. Para cada conexión con la sincronización de stock activada, publica el disponible actual.
- Barre las reservas de stock vencidas (ver detalle más abajo — es la más delicada de todas).
- Reintenta los avisos (webhooks) salientes que fallaron en las últimas 24 horas.
Cada 10 minutos¶
Revisa la salud de las conexiones activas a marketplaces: comprueba que cada una siga respondiendo y actualiza su estado si algo dejó de funcionar.
Cada 15 minutos¶
- Reenvía los precios hacia los marketplaces conectados, como red de seguridad además del envío que ya ocurre cuando un precio cambia.
- Comprueba el DNS de las solicitudes de dominio propio pendientes y promueve las que ya quedaron correctamente apuntadas. Este es el mismo proceso que dispara el botón "Comprobar ahora" que un comercio puede usar manualmente desde su propia pantalla de dominio: no es un camino aparte, así que un cambio en uno se refleja en el otro.
Cada 30 minutos¶
Renueva los tokens de acceso a MercadoLibre antes de que caduquen, para las conexiones que están por vencer dentro de la próxima hora. Sin esto, una conexión se cae sola por expiración de credenciales aunque el comercio no haya cambiado nada.
Cada 12 horas¶
Reintenta los cobros de suscripción que fallaron. Es lo que le da a un comercio con un pago rechazado una segunda (y tercera) oportunidad antes de llegar a suspensión.
Todos los días¶
| Hora (UTC) | Qué hace | Para qué sirve |
|---|---|---|
| 03:00 | Purga registros de más de 90 días (webhooks, sincronizaciones) | Evita que las tablas de bitácora crezcan indefinidamente |
| 06:00 | Procesa el ciclo de facturación | Genera las facturas del período que corresponde |
| 08:00 | Suspende comercios morosos | Comercios cuyo pago sigue fallando después de los reintentos pasan a estado suspendido |
| 10:00 | Avisa próximas renovaciones | Notifica a los comercios cuya suscripción vence dentro de los próximos 7 días |
La barrida de reservas, en detalle¶
Este es el proceso que corre cada 5 minutos y el que más conviene entender bien, porque trata distinto dos situaciones que se parecen pero no son lo mismo.
Una reserva de stock vencida puede venir de dos orígenes:
- Un carro de la tienda propia (storefront). Es solo una intención de compra: si el cliente se fue sin pagar, la reserva vence a los 15 minutos y se libera en silencio. El stock vuelve al disponible sin que nadie tenga que hacer nada.
- Un pedido de marketplace ya cerrado. Es una venta real, no una intención. Por defecto
su reserva vence recién a los 7 días, y ese plazo largo no es una ventana de compra: es
el punto a partir del cual el sistema asume que el pedido quedó atascado sin despachar. Al
vencer, la reserva no se libera sola: se marca para revisión humana
(
needs_attention), y el stock sigue comprometido hasta que alguien resuelva qué pasó con ese pedido.
⚠️ Advertencia: Si a un comercio "le falta stock" y al investigar encuentra que hay reservas activas de pedidos de marketplace muy antiguos, no es un error del sistema: es exactamente esta protección funcionando. Soltar ese stock sin revisar el pedido real sería peor que dejarlo retenido — podría estar despachándose tarde, no cancelado.
Lo normal es que una reserva se cierre por el camino directo: al cancelar la orden o al despacharla, no por esta barrida. Este proceso es la red de seguridad para cuando ese camino directo no ocurrió — por ejemplo, si un pedido quedó abandonado en un estado intermedio.
Notas Importantes¶
ℹ️ Nota: Casi todos estos procesos recorren cada comercio con base de datos aprovisionada, uno por uno. Un comercio a medio aprovisionar (ver Crear un comercio) simplemente queda fuera de este recorrido hasta que su base de datos esté lista.
💡 Consejo: Cuando un comercio reporte "esto debería pasar solo y no pasó", ubique primero en esta página la frecuencia del proceso correspondiente antes de escalarlo: muchas veces el proceso todavía no volvió a correr, no es que haya fallado.
Preguntas Frecuentes de esta Sección¶
¿Puedo forzar que uno de estos procesos corra ahora mismo, sin esperar su horario? Esta documentación cubre qué hace cada proceso y cuándo corre solo; no hay una pantalla para dispararlos manualmente desde el panel de administración.
Un pedido de marketplace lleva días con la reserva marcada para revisión, ¿qué hago? Revise ese pedido puntual: confirme si el despacho está simplemente atrasado o si el pedido debe cancelarse. Ninguno de los dos casos se resuelve solo con el paso del tiempo.
¿La purga de 90 días borra datos de negocio (órdenes, productos)? No: alcanza a registros de bitácora (webhooks y sincronizaciones), no a las órdenes ni al catálogo del comercio.
¿Necesita ayuda adicional? Contacte a soporte: soporte@openx.cl