Una tienda de velas vende de forma muy distinta en julio que en noviembre. En velasdeolor.es los pedidos de reposición se hacen por marca, cada cierto tiempo, y la pregunta es siempre la misma: ¿cuántas unidades de cada producto pido para cubrir hasta el siguiente pedido? Si se pide de más, el dinero se queda parado en el almacén. Si se pide de menos, las clientas se encuentran el «sin stock» justo en temporada alta. Para responder con datos en lugar de a ojo, desarrollamos un módulo de previsión de compras para el backoffice de PrestaShop.
La idea: mirar la misma temporada de años anteriores
La forma más intuitiva de prever es la que ya usaba el dueño de la tienda: ver cuánto se vendió en las mismas fechas en años anteriores y compararlo con el stock actual. El módulo hace exactamente eso, pero con más rigor y en segundos:
- Se elige la marca (y, si se quiere, solo algunas categorías).
- Se indica hasta qué fecha tiene que cubrir el pedido y cuándo llegará, que se calcula sola con el plazo de entrega habitual de esa marca.
- El módulo mira las ventas de ese mismo periodo en los últimos años (tres por defecto), dando más peso a los más recientes.
- Y para cada producto propone las unidades a pedir.
Los detalles que hacen que la previsión sea fiable
Solo cuentan las ventas reales
La previsión se basa en los pedidos válidos, restando las devoluciones. Los movimientos manuales de stock no cuentan como ventas, lo que en esta tienda es importante: a menudo se sacan del almacén cajas de muestras para regalar con los pedidos, y eso no es demanda de las clientas.
«No vendí» no es lo mismo que «no tenía stock»
Este es el error clásico de las previsiones sencillas. Si un producto estuvo agotado tres semanas el noviembre pasado, sus ventas de ese mes fueron bajas, y una media simple diría que hay que pedir poco… para volver a quedarse sin stock.
El módulo detecta esos periodos sin stock (con su propio registro, reconstruyéndolos a partir de los movimientos de stock de PrestaShop o, si no hay datos, detectando con estadística huecos de ventas que no pueden ser casualidad) y corrige las ventas repartiéndolas según la temporada. Si un año el producto estuvo disponible menos del 40 % del periodo, ese año se descarta.
Temporada y tendencia
- Estacionalidad: el reparto de las ventas día a día dentro del periodo se calcula con el comportamiento de toda la marca, suavizado, y se mezcla con el del propio producto cuando este tiene ventas suficientes.
- Tendencia: si la marca está vendiendo más (o menos) que hace un año, la previsión se ajusta, con límites para que un año raro no dispare el pedido. También se puede fijar a mano o desactivar.
- Productos nuevos sin histórico: se usan sus ventas de los últimos 90 días, ajustadas por la temporada.
Del «se venderán» al «hay que pedir»
Saber cuánto se va a vender no es todavía la cifra del pedido. El módulo tiene en cuenta:
- Lo que se venderá antes de que llegue el pedido, que se descuenta del stock actual.
- Los pedidos al proveedor que ya están en camino.
- Un stock de seguridad (un 10 % por defecto).
- El pedido mínimo y los múltiplos de caja de cada marca o producto.
Y deja fuera lo que no se repone: productos descatalogados, de outlet o marcados como últimas unidades.
Explicable, no una caja negra
Una cifra sin explicación genera desconfianza, y con razón. Por eso cada recomendación lleva su desglose paso a paso: ventas de cada año, corrección por roturas, temporada, tendencia, stock a la llegada, seguridad y redondeos. Las gráficas ayudan a verlo de un vistazo:
- Ventas mensuales por año, con el periodo del pedido sombreado.
- Para cada producto, ventas reales, ventas corregidas y previsión.
- Una vista semanal con los huecos sin stock marcados.
La tabla final indica los días de cobertura de cada producto y marca en color los que no llegarían a la fecha de llegada del pedido o al final del periodo. El pedido se exporta a CSV (se abre directamente en Excel) o se imprime, y se puede guardar en el módulo para que sus unidades se tengan en cuenta en la siguiente previsión.
Apartado técnico (para desarrolladores)
- El módulo vive en el backoffice (Catálogo › Previsión de compras) y solo lee datos: pedidos, devoluciones, stock y movimientos de stock. No modifica nada en la tienda.
- El motor de cálculo es independiente de PrestaShop, lo que permite probarlo por separado con datos de prueba.
- Cuenta los días en UTC para evitar los problemas del cambio de hora, y guarda media hora en caché los datos de ventas para que recalcular con otros parámetros sea instantáneo.
- Las gráficas usan Chart.js alojado en el propio módulo, sin depender de servicios externos.
Conclusión
Un buen pedido de reposición no depende de la intuición, sino de cruzar bien tres datos: lo que se vendió en la misma temporada, el stock que hay ahora y lo que tarda en llegar la mercancía. Con un poco de estadística para no confundir roturas de stock con falta de demanda, PrestaShop puede ayudar a comprar mejor. Y si además haces ofertas, te interesa cómo planificarlas cumpliendo la norma del precio anterior.
Si en tu tienda los pedidos a proveedores se hacen a ojo o con hojas de cálculo eternas, contacta con nosotros y vemos cómo automatizarlo. Puedes ver más sobre cómo trabajamos en PrestaShop en El Puerto de Santa María.
Más casos reales de velasdeolor.es
Este artículo forma parte de una serie sobre las mejoras que hemos hecho en la tienda en octubre de 2026:
- Un buscador a medida para PrestaShop
- Asistente con inteligencia artificial para una tienda PrestaShop
- Rediseño de una tienda PrestaShop sin tocar la plantilla
- Productos relacionados automáticos: el mismo aroma en otros formatos
- El banner de cookies que volvía a aparecer
- Acceso con Google y con código por email en PrestaShop
- Precio anterior en las ofertas (norma Omnibus) en PrestaShop
- Error 500 en el blog de PrestaShop tras actualizar el módulo
