Descuentos programados: cómo configurar promociones que empiezan y terminan automáticamente

Revisado por última vez en junio de 2026. Verificado con PrestaShop 1.7, 8 y 9. Nota sobre PS9: el back office de descuentos se está unificando en cuatro tipos de descuento (Catálogo, Carrito, Envío gratis, Regalo) detrás de una bandera de funcionalidad, pero todos los tipos siguen incluyendo el intervalo de fechas en el que se basa esta guía.

Son las 11 de la noche de un jueves y recuerdas que la promoción de Black Friday debía activarse a medianoche. Te apresuras a crear reglas de carrito y a cambiar precios, esperando no equivocarte con un decimal bajo presión. O la versión más silenciosa del mismo error: configuras un descuento "solo fin de semana" el viernes, te olvidas de él el lunes y regalas margen durante tres días más antes de que alguien lo note. Ambos fallos comparten una causa raíz: una persona actúa como interruptor de encendido y apagado.

PrestaShop puede ser ese interruptor por ti. Los dos mecanismos de descuento de la plataforma — reglas de carrito y precios específicos — tienen sus propias marcas de fecha y hora de inicio y fin, y la tienda las evalúa en cada carga de página. Configura las fechas una vez, y la promoción se activa y se desactiva sola, estés despierto o no. Esta guía trata específicamente de esa capa de programación: dónde están los campos de fecha, cómo decide PrestaShop si un descuento está "activo" en un momento determinado, la trampa de la zona horaria que puede mover silenciosamente tu lanzamiento y el contenido que debe programarse junto con el precio. Para decidir qué tipo de descuento conviene usar en primer lugar, consulta cómo organizar una promoción en PrestaShop; para saber cuándo lanzarlas durante el año, revisa el calendario de promociones estacionales.

Cómo decide realmente PrestaShop que un descuento está "activo"

Conviene entender qué ocurre por debajo, porque de ello depende todo lo demás. PrestaShop no ejecuta una tarea programada a medianoche para activar tu promoción. No hay tarea cron ni cola. En su lugar, tanto las reglas de carrito como los precios específicos guardan un date_from y un date_to en la base de datos, y el precio se recalcula en el momento de la petición: cuando un cliente carga una página de producto o actualiza el carrito, el núcleo compara esas marcas temporales con ahora e incluye el descuento solo si ese ahora cae dentro del intervalo.

¿Qué significa eso en la práctica? Tres cosas. Primero, la activación es instantánea y fiable: no hay una tarea que pueda fallar, así que una promoción configurada para las 00:00 empieza realmente a las 00:00. Segundo, "ahora" se evalúa según la configuración de zona horaria de la tienda y del entorno PHP, no según la zona horaria local del visitante (la trampa de la zona horaria que veremos más abajo). Tercero, como el precio se calcula en vivo y después se almacena en caché, una promoción que ya debería haber empezado puede seguir mostrando el precio antiguo hasta que se reconstruya la caché de página. Por eso la caché agresiva de página completa y los descuentos programados deben coordinarse; lo cubrimos más adelante.

Programar una regla de carrito (Catálogo → Descuentos)

Las reglas de carrito son el motor de cupones de PrestaShop: tanto los códigos que escribe el cliente como los descuentos automáticos que se aplican en silencio cuando se cumplen las condiciones. Creas una en Catálogo → Descuentos → Nueva regla de carrito (en PrestaShop 1.6 la ruta es Reglas de precio → Reglas de carrito). Para programarla, abre la pestaña Condiciones y configura Válido desde / Válido hasta:

• Válido desde — fecha y hora en que la regla empieza a poder usarse. Se guarda como date_from.
• Válido hasta — fecha y hora en que caduca. Se guarda como date_to.

Dentro de ese intervalo la regla está activa; fuera de él, el código se rechaza con "este cupón no es válido" y una regla automática simplemente no se aplica. Hay dos campos que la mayoría de comerciantes pasan por alto y que conviene configurar con intención:

• Total disponible y Total disponible para cada usuario — límites de uso. Un intervalo de fechas programado responde a "cuándo"; estos campos responden a "cuántas veces", que es lo que impide que un código filtrado se abuse durante todo el periodo.
• Destacar y Uso parcial — en la pestaña Acciones. Destacar orienta al cliente hacia un cupón aplicable en el carrito; el uso parcial decide si el saldo no gastado de un cupón de importe fijo sobrevive al siguiente pedido.

Hay algo que el back office no te impedirá hacer: poner "Válido hasta" antes de "Válido desde". No hay barrera de protección; la regla simplemente nunca se activa, y te enteras cuando un cliente escribe preguntando por qué EARLY20 no funciona. Relee las dos fechas antes de guardar.

Programar una bajada de precio en productos (precios específicos)

Las reglas de carrito descuentan la cesta. Para mostrar un precio tachado en la propia página de producto — la presentación clásica de rebajas, con el precio antiguo tachado y el nuevo precio en rojo — se usa un precio específico, configurado por producto en Catálogo → Productos → [tu producto] → Precio → Precios específicos → Añadir un precio específico. El mismo cuadro de diálogo aparece cuando asignas en bloque una regla de precio de catálogo desde Catálogo → Descuentos → Reglas de precio de catálogo, que es la forma de programar un descuento para toda una categoría o proveedor de una vez, en lugar de producto por producto.

El cuadro incluye sus propios campos de fecha y hora Desde y Hasta — las mismas columnas from/to de la tabla ps_specific_price — además de controles que las reglas de carrito no tienen:

• Para (grupo de clientes) — restringe el precio programado a un grupo, de modo que "semana mayorista, −20% para revendedores" conviva con el precio minorista normal en el mismo intervalo.
• Cantidad disponible / A partir de la cantidad — escalona el descuento por unidades compradas, programado dentro de un intervalo de fechas.
• Dejar las fechas en blanco — y el precio específico será permanente. Los campos de fecha son los que convierten un precio estable en una promoción temporal; borrarlos es la forma de hacer que un precio rebajado "se quede" deliberadamente.

La diferencia visible para el comprador es el motivo para elegir un mecanismo u otro: un precio específico aparece en el catálogo y en la página de producto antes de añadir nada al carrito, por lo que anuncia la oferta; una regla de carrito normalmente se revela en la cesta. Si no tienes claro qué mecanismo necesita una promoción concreta, el análisis de reglas de carrito frente a precios específicos te da el marco de decisión.

Auditar tus intervalos programados con una sola consulta

Cuando has preparado con antelación un trimestre de promociones, conviene leerlas todas en un único lugar en vez de ir haciendo clic por cada producto. Estas son comprobaciones de solo lectura: no cambian nada. Para ver todas las reglas de carrito cuyo intervalo se abre en el futuro o está activo ahora mismo (ajusta el prefijo ps_ a tu instalación):

-- Cart rules with their scheduled windows, soonest first.
SELECT id_cart_rule, code, active, date_from, date_to,
       quantity, quantity_per_user
FROM ps_cart_rule
WHERE date_to >= NOW()
ORDER BY date_from;

Y para detectar el clásico error de "Válido hasta antes de Válido desde" en todas las reglas a la vez, antes de que lo encuentre un cliente:

-- Any rule whose window can never open (to is before from).
SELECT id_cart_rule, code, date_from, date_to
FROM ps_cart_rule
WHERE date_to < date_from;

El equivalente para bajadas de precio en productos lee la tabla ps_specific_price: las columnas from y to son los mismos campos de programación que escribe el cuadro de diálogo, y una fila con ambos valores en 0000-00-00 00:00:00 es un precio permanente (sin fecha), no uno programado.

La trampa de la zona horaria que desplaza tu lanzamiento

Esta es la forma más habitual de que un descuento programado salga mal, y es invisible hasta que te afecta. PrestaShop evalúa date_from / date_to contra la zona horaria configurada en la tienda, definida en Internacional → Localización → Zona horaria (internamente se guarda como PS_TIMEZONE), que no tiene por qué coincidir con el reloj del sistema de tu servidor de hosting y casi nunca coincide con la de un cliente que compra desde otro país.

El fallo se ve así: la zona horaria de la tienda queda en el valor predeterminado elegido por el hosting, o en UTC, mientras tu negocio y tus clientes trabajan en CET (UTC+1). Configuras la promoción para empezar a las 00:00. Para tus clientes de Europa Central, en realidad se activa a la 01:00, y la "oferta relámpago de medianoche" anunciada por email ya nace muerta durante la primera hora. Las horas de finalización se desplazan igual: un corte de "domingo 23:59" en UTC termina localmente a las 00:59 del lunes, regalando una hora extra que no habías previsto.

Antes de cualquier lanzamiento importante, confirma primero la zona horaria de la tienda y luego interpreta la hora de inicio como "00:00 en esa zona horaria", no como "00:00 en mi hora".

El detalle que casi todo el mundo olvida: la caché y la parte visual

Hay dos cosas entre un descuento correctamente fechado y que el cliente llegue a verlo.

Caché. Como los precios se calculan en el momento de la petición y después se almacenan en caché, una tienda con caché de página completa, caché de Smarty o una CDN puede seguir sirviendo el precio anterior a la promoción después de que haya pasado date_from, y seguir sirviendo el precio rebajado después de que termine. Para una promoción con inicio rígido, el patrón seguro es programar las fechas con normalidad y después limpiar la caché en el momento de activación (Parámetros avanzados → Rendimiento → Vaciar caché) para que la primera renderización recalcule el precio. Si usas una caché de borde con una TTL larga, tenla en cuenta al decidir cuándo purgar de verdad.

Si la hora de inicio de tu promoción es realmente fija (una oferta relámpago de medianoche), también puedes sacar a la persona del vaciado de caché. PrestaShop no programa la activación de descuentos, pero tu servidor sí puede programar el vaciado de caché: una línea de cron que ejecute el comando de consola para limpiar la caché en el momento de activación, de modo que la primera renderización posterior al lanzamiento recalcule los precios sin que tengas que iniciar sesión:

# crontab entry: clear PrestaShop's cache at 00:00 on 27 Nov 2026,
# the minute a hard-start sale opens. Run as the web user.
# (path to the PrestaShop root; --no-debug for prod)
0 0 27 11 * cd /var/www/html && php bin/console cache:clear --env=prod --no-debug

Eso no activa el descuento: el intervalo de fechas lo hace por sí solo. Solo garantiza que la página anterior a la promoción, almacenada en caché, desaparezca en el instante en que se abre el intervalo. En una CDN o una caché de borde, lo combinarías con la purga del proveedor en el mismo minuto. Trátalo como una doble garantía para promociones en las que el primer minuto importa, no como un requisito para la programación cotidiana.

La parte visual. El descuento está programado, pero el carrusel de la página de inicio sigue diciendo "Oferta de verano" mientras la promoción de otoño está activa, o el banner que anuncia el código caducó tres días antes que el propio código. La programación de precios y la programación de contenido son sistemas separados en PrestaShop, y el segundo no tiene campos de fecha nativos en el carrusel predeterminado. Acompaña cada descuento programado con un cambio creativo también programado, para que el mensaje y el precio cambien en el mismo minuto: nuestro enfoque de banners para promociones cubre cómo producirlos sin depender de un diseñador.

Descuentos solapados: qué gana cuando dos reglas chocan

En cuanto programas más de una promoción, puedes apilarlas por accidente. Un producto con un precio específico del 20% que además entra en una regla de carrito automática del 15% no siempre se comporta como espera el cliente (o tu margen). PrestaShop resuelve esto mediante prioridades y ajustes de combinación, no simplemente sumándolo todo:

• Precios específicos — cuando pueden aplicarse varios, los conflictos se resuelven mediante las reglas de prioridad de precios específicos de PrestaShop y los criterios de coincidencia (tienda/moneda/país/grupo, además de cantidad y fecha); prueba el precio de producto resultante.
• Las reglas de carrito tienen su propia Prioridad y un interruptor por regla que controla si puede combinarse con otros cupones en el mismo carrito.
• Una reducción por precio específico y un descuento de regla de carrito se calculan en etapas distintas (precio de línea frente a total del carrito), así que pueden acumularse si no lo has previsto.

La lógica es realmente enrevesada y no merece la pena razonar sobre ella en abstracto. Antes de cualquier intervalo en el que se solapen promociones, haz la única prueba que lo aclara: realiza un pedido real de prueba con los descuentos programados activos y revisa el importe final. Si es mayor de lo que pretendías, ajusta la prioridad o compatibilidad de la regla de carrito, las restricciones de producto, o excluye los productos ya rebajados, y vuelve a probar. La mecánica más profunda de combinar reducciones está en la guía de estrategias de promoción; para productos que deben quedar protegidos de cualquier descuento programado, consulta exclusión de descuentos.

Lista de comprobación previa al lanzamiento para cualquier promoción programada

Configura cada promoción aproximadamente una semana antes de que empiece, para revisar los ajustes con calma en lugar de hacerlo a las 11 de la noche. Antes de activarla, recorre esta lista:

• Las fechas se leen correctamente — "Válido hasta" va realmente después de "Válido desde", y ambas están en la zona horaria de tu tienda, no en la de tu reloj.
• El alcance es correcto — una regla de "20% de descuento en accesorios" que se aplica discretamente a todo el catálogo puede salir cara en una tarde. Confirma la condición de categoría, grupo o producto.
• Límites de uso configurados — límites totales y por usuario en cualquier código que pueda filtrarse.
• Solapamiento probado — un pedido real de prueba pasando por los descuentos programados; revisa el total final.
• Plan de caché — sabes si vas a vaciar la caché al inicio y al final.
• Creatividad programada — banner, carrusel y cualquier email ajustados al mismo intervalo que el precio.

Cuando el calendario supera al back office

Los campos de fecha nativos gestionan bien una promoción aislada. La tensión aparece cuando trabajas con un calendario continuo: campañas estacionales encadenadas, ofertas recurrentes de fin de semana, eventos relámpago con tiempo limitado, y ahora editas a mano decenas de reglas de carrito y precios específicos, cada uno con su razonamiento de zona horaria y vaciado de caché. Esa es la carga de trabajo que nuestros módulos de automatización están pensados para eliminar. Sales Revolution ejecuta ofertas relámpago programadas y con caducidad automática como una campaña gestionada, no como una pila de reglas manuales: defines el intervalo, los productos y la profundidad del descuento, y se encarga de iniciar y finalizar la oferta; lo presentamos en ofertas relámpago automatizadas para PrestaShop. La ventaja es la misma de la que trata todo este artículo, pero escalada: el interruptor de encendido y apagado ya no es una persona a medianoche. Para la psicología de ejecutar esas ofertas con límite de tiempo de forma honesta — cuentas atrás reales, sin temporizadores falsos que se reinician — consulta ventas relámpago sin manipulación.

El atractivo de los descuentos programados es deliberadamente poco emocionante: decides una vez, de día, con las fechas y el alcance delante, y la tienda los aplica exactamente. Configura bien la zona horaria, ten en cuenta la caché, programa la creatividad junto al precio y prueba los solapamientos; después, deja que funcione. Tu yo futuro, a las 11 de la noche de un jueves, no tendrá que pensar en ello.

Descuentos programados: preguntas frecuentes

¿PrestaShop necesita una tarea cron para activar un descuento a su hora de inicio?

No. La activación no es una tarea programada: no hay ninguna tarea cron que encienda las promociones. PrestaShop guarda un date_from/date_to en cada regla de carrito y precio específico, y recalcula el precio en el momento de la petición, incluyendo el descuento solo cuando "ahora" cae dentro del intervalo. Por eso una promoción configurada para las 00:00 empieza realmente a las 00:00, sin ninguna tarea que pueda fallar. Un cron solo es útil para el vaciado de caché en el momento de activación, no para el descuento en sí.

La fecha de mi promoción ya había pasado, pero seguía apareciendo el precio antiguo. ¿Por qué?

Por la caché. Los precios se calculan en el momento de la petición y después se almacenan en caché, así que una caché de página completa, la caché de Smarty o una CDN pueden seguir sirviendo el precio previo a la promoción después de abrirse el intervalo. Vacía la caché en el momento de activación (Parámetros avanzados → Rendimiento → Vaciar caché) y, si usas una caché de borde o CDN, púrgala también y ten en cuenta su TTL. Para una promoción con inicio rígido, programa ese vaciado para que la primera renderización posterior al lanzamiento recalcule los precios.

La promoción se activó una hora tarde. ¿Qué ocurrió?

La trampa de la zona horaria. PrestaShop evalúa el intervalo según la zona horaria configurada en la tienda (PS_TIMEZONE, en Internacional → Localización → Zona horaria), no según el reloj del servidor ni la hora local del visitante. Si tu tienda queda en UTC mientras tu mercado opera en CET, un inicio a las "00:00" se dispara a la 01:00 para tus clientes. Configura la zona horaria de la tienda según tu mercado principal y luego lee cada hora de promoción como "medianoche en esa zona horaria".

¿Puedo configurar un intervalo de descuento sin fecha de fin?

Sí: deja en blanco el campo Hasta / Válido hasta. En un precio específico, borrar ambos campos de fecha convierte el precio en permanente (una rebaja estable en lugar de una promoción temporal). En una regla de carrito, un Válido hasta abierto significa que la regla seguirá pudiendo usarse hasta que la desactives o se agoten sus límites de uso. Los campos de fecha son precisamente lo que convierte un precio estable en uno temporal, así que dejarlos en blanco es una decisión deliberada, no un descuido.

¿Cómo evito que dos descuentos programados se acumulen hasta generar pérdidas?

No intentes resolverlo en abstracto: pruébalo. Realiza un pedido real con ambos descuentos programados activos y revisa el total final. Si el descuento es más profundo de lo previsto, las palancas son: la Prioridad de la regla de carrito, el interruptor por regla de "combinar con otros cupones" y "Excluir productos rebajados" en una regla de carrito porcentual para que ignore lo que ya tenga un precio específico. Ajusta y vuelve a probar. Para SKUs que no deben verse afectados por ninguna promoción, consulta exclusión de descuentos.