Reposición automática en PrestaShop: la lista de compra del lunes, hecha y explicada.

Qué hace en reposición automática en prestashop.

¿Qué es la reposición automática en PrestaShop?

La reposición automática en PrestaShop es el cálculo de qué pedir, cuánto y a quién, hecho cada semana con las ventas de tu tienda, el stock disponible y el plazo de cada proveedor, y presentado como una propuesta que revisas. PrestaShop no la trae en las versiones actuales: te enseña qué producto está bajo mínimos, pero la cuenta del pedido y el pedido en sí quedan fuera.

Lo que sí cambia con el sistema es el origen de la cifra. En vez de un umbral fijo que alguien puso al dar de alta el producto, la cantidad sale de la previsión de venta de ese producto, del tiempo que tarda su proveedor y del riesgo de rotura que aceptas.

¿Qué hace PrestaShop de serie para reponer?

En Catálogo > Stock, la documentación oficial de la versión 8 describe una vista general con filtros por proveedor y por categoría, una búsqueda por nombre, referencia, proveedor y valores de atributo, y la edición de cantidades. Los productos por debajo de su umbral salen resaltados, con un filtro rápido para verlos. Todo lo que muestra la página se exporta a CSV y se puede importar.

En la ficha de cada producto, la pestaña Cantidades tiene el campo Cantidad mínima para la venta, las alertas de stock (el umbral y la casilla para recibir un correo cuando la cantidad baje de él) y las preferencias de disponibilidad, donde eliges si se permiten pedidos con stock agotado. Todo eso describe cómo vendes y avisa de que falta algo, pero ninguna de esas pantallas calcula cantidades de compra.

Es el hueco que se nota en cuanto la tienda crece: hay un proveedor con quince días de plazo, otro con dos, 800 referencias y una persona que cada lunes filtra por proveedor, exporta el CSV y decide a ojo.

¿Qué pasó con los pedidos de suministros de la 1.6?

En PrestaShop 1.6, con la opción de administración avanzada de stock activada, había una sección de Pedidos de suministros a proveedores. Según la documentación de esa versión, un pedido se creaba en dos pasos: primero los datos (referencia única, proveedor, almacén de destino, divisa, idioma, descuento global y fecha de entrega estimada) y luego los productos con un buscador. Tenía estados por defecto, desde «Creación en curso» hasta «Pedido recibido completamente» o «Pedido cancelado», admitía plantillas y permitía registrar recepciones parciales que iban sumando stock.

Aquello se retiró con la 1.7. El equipo de PrestaShop explicó en su blog que algunas funciones avanzadas dejarían de ser nativas, que las herramientas básicas se quedaban en el núcleo para el 90 % de los comerciantes y que lo avanzado iría a módulos de PrestaShop ERP, de pago, en Addons. Es decir: en una tienda 8 o 9, o compras con un módulo de terceros, o compras con un ERP, o compras con un Excel.

La 1.6 tenía el circuito de pedido, pero no el cálculo de cuánto pedir. Entre las plantillas y los estados, cada cantidad la ponía una persona. Eso es lo que el sistema añade.

• PrestaShop 1.5 y 1.6: administración avanzada de stock con pedidos de suministros a proveedores, plantillas y recepciones.
• PrestaShop 1.7 en adelante: stock simple en el núcleo; lo avanzado, en módulos o ERP.
• En ambos casos, la cantidad a pedir la decide una persona. El sistema la calcula y la explica.

¿Cómo se calcula cuánto pedir de cada producto?

Para cada producto o combinación y cada proveedor, el sistema calcula el stock objetivo: lo que venderás hasta que llegue el siguiente pedido (plazo del proveedor más el tiempo hasta tu próxima revisión) más un margen para la variación de la venta, que se ajusta al nivel de servicio que elijas. Al objetivo se le resta lo que tienes disponible y lo que ya viene de camino, y el resultado se redondea al bulto.

El disponible que usa es el de PrestaShop, que es el stock físico menos el reservado en pedidos abiertos. Si permites pedidos fuera de stock y el disponible es negativo, esa cantidad se suma a lo que hay que pedir. Si un proveedor tiene un pedido mínimo, el sistema lo respeta y completa con los productos que más cobertura necesitan.

Un ejemplo con números: un saco de pienso y su proveedor.

Una tienda online de mascotas vende de un pienso de 12 kg unas 11 unidades a la semana, con una variación típica de 4 por semana. Su proveedor tarda 15 días, y la tienda pide los lunes, así que hay que cubrir 22 días: unas 3,1 semanas, que a 11 son unas 35 unidades. Para servir el 95 % de las semanas se añade un margen de unas 12 unidades, y el stock objetivo es 47.

En PrestaShop, el producto tiene 12 unidades de stock físico, 3 reservadas en pedidos sin enviar y 9 disponibles, y no viene nada en camino. El pedido sugerido es 47 menos 9: 38 unidades. El proveedor sirve en cajas de 4, así que la línea sale en 40, con su porqué: «vende 11 a la semana, plazo 15 días, 9 disponibles y 3 reservadas, objetivo 47».

Con un nivel de stock bajo de 10 puesto al dar de alta el producto, PrestaShop habría resaltado el producto con 9 disponibles, sí, pero no habría dicho que hay que pedir 40, ni que con ese plazo ya se iba tarde. La cifra y el momento salen del cálculo, no del umbral.

¿Qué lee de PrestaShop y qué escribe de vuelta?

Se conecta por el webservice, activado en Parámetros avanzados > Webservice, con una clave creada solo para el programa y con permisos marcados recurso por recurso, como recomienda la documentación. Lee orders y order_details para las ventas, products y combinations para el catálogo, stock_availables para el disponible y, si los usas, suppliers y product_suppliers para saber a quién se compra cada cosa.

El webservice de la versión 9 lista también recursos de suministros (supply_orders, supply_order_details y sus estados), de almacenes y de movimientos de stock. Si tu tienda los usa, por un módulo o una instalación antigua, el programa los lee para aprender plazos reales y entradas. Si no, la información sale de las fechas de las entradas de stock que ya registras.

Por defecto no escribe en la tienda. Si lo pides, puede registrar la entrada de mercancía actualizando stock_availables cuando confirmas la recepción, o dejar el stock bajo de cada producto al día. Son cambios que apruebas tú.

Traslados entre tiendas y almacenes.

Si además de la web tienes tiendas físicas, el programa trata cada sitio con su propia venta. Antes de proponerte comprar mira si en otro sitio hay unidades que no se van a vender a tiempo y propone el traslado, con las cantidades y con el origen. Una unidad movida es una unidad que no se compra.

El stock de las tiendas físicas puede estar en el TPV, en un módulo multialmacén o en un ERP conectado. Se lee de donde esté. Lo importante es que cada sitio tenga una cifra de stock fiable y una venta, y eso se comprueba en el diagnóstico.

Lo que no hace.

No compra por ti: no hay pedido que salga sin que alguien lo apruebe. No negocia con el proveedor ni cambia precios. No sustituye a tu ERP si tienes uno: se monta encima. Y no garantiza que no haya roturas, porque un proveedor que falla sigue fallando. Reduce el riesgo y te dice cuál queda en cada línea.

Si compras a un único proveedor con servicio en 48 horas y pocos productos, un Excel bien puesto es suficiente, y te lo diremos.

Cómo se comprueba y cómo se empieza.

Primero se repite el pasado. El sistema vuelve a decidir cada semana de tus últimos meses solo con lo que se sabía ese día y se compara con lo que pediste: pedidos servidos, roturas, unidades compradas y dinero parado en stock. Las medidas se fijan antes. Después, uno o dos meses en modo sombra, con la propuesta junto a tu compra real.

Si antes quieres una primera idea, el análisis gratuito parte de un export de pedidos y del CSV de Catálogo > Stock. La puesta en marcha lleva de tres a seis semanas.

¿Te suena alguno de estos casos?

• Si el pedido a proveedor se hace los lunes mirando un Excel con el CSV de Catálogo > Stock y los pedidos de la semana. Esa lista aparece hecha, con el criterio escrito en cada línea.
• Si pasaste de la 1.6 a la 1.7 o a la 8 y perdiste los pedidos de suministros La gestión avanzada de stock de la 1.6 los tenía. En las versiones nuevas hay que ponerlos fuera, y aquí vuelven con cálculo detrás.
• Si trabajas con varios proveedores por producto y a veces compras al que tiene stock o al más rápido. El sistema calcula el pedido por proveedor preferente y señala qué alternativa usar cuando el principal no llega a tiempo.
• Si repones tiendas físicas desde el almacén de la web La propuesta de traslado sale con la venta de cada tienda y con lo que ya viaja, y evita que la tienda de Sevilla reciba lo que necesitaba la de Bilbao.
• Si compras en bultos o palés El pedido se redondea al múltiplo que sirve el proveedor, y el programa te dice cuánto sobra del último bulto y cuántas semanas de cobertura supone.
• Si tu catálogo cambia cada temporada y lo que se pide hoy es lo que se venderá dentro de dos meses. El pedido de pre-temporada se calcula con la curva de la familia y se corrige con lo que vende de verdad.

El cálculo está fuera de PrestaShop y la decisión sigue siendo tuya.

No instalamos un módulo de pedidos a proveedor ni cambiamos cómo compras. El motor lee de PrestaShop, calcula la compra y el traslado, y te los propone. Nada sale hacia el proveedor sin tu visto bueno, y por defecto no se escribe nada en la tienda. Antes de empezar, se repiten semanas pasadas y se compara lo que habría pedido el sistema con lo que pediste tú.

• Lectura por el webservice con una clave de permisos acotados; sin módulos.
• Pedido por proveedor, por producto y por combinación, redondeado al bulto.
• Traslado entre tiendas o almacenes antes que compra nueva.
• Cada línea con su porqué, y tú decides.