Quién cambió ese precio: historial de cambios de productos en PrestaShop

Lunes por la mañana. Un cliente escribe porque ha comprado un producto a un precio que no tiene sentido: la mitad de lo normal. Miras la ficha y, efectivamente, el precio está mal. ¿Quién lo cambió? ¿Cuándo? ¿Cuánto valía antes? ¿Cuántos pedidos han entrado con ese precio?

En una tienda PrestaShop de serie, la respuesta honesta es «no lo sabemos». Y la conversación siguiente en el equipo suele ser incómoda, porque todo el mundo dice que no ha tocado nada.

Por qué PrestaShop no lo sabe

La base de datos de PrestaShop guarda el estado actual de cada producto: su precio, su stock, su descripción, si está activo. Cuando alguien guarda un cambio, el valor nuevo sustituye al anterior y el anterior desaparece.

Lo que sí guarda:

• La fecha de la última modificación del producto (date_upd), sin decir qué cambió ni quién.
• El registro del sistema (Parámetros avanzados > Registros), que según la versión anota algunas acciones de empleados, pero sin el valor de antes y el de después.
• Los movimientos de stock, cuando la gestión avanzada está activa o en las versiones que los registran, que dicen cuánto se movió pero no te cuentan el resto de la ficha.

Para saber qué pasó necesitas lo que se llama un registro de auditoría: una línea por cambio, con quién, cuándo, qué campo, el valor anterior y el nuevo.

Qué cambios conviene registrar

No todos los campos importan igual. En orden de lo que más disgustos da:

1. Precio de venta y precio de coste. Un error aquí se convierte en dinero el mismo día.
2. Stock. Separando ajustes manuales de los movimientos que vienen de pedidos y de sincronizaciones con el ERP.
3. Activación. Un producto que se desactiva desaparece del catálogo y de los feeds de Google Shopping o de los marketplaces.
4. Categoría por defecto y asociaciones. Afectan a la URL, a la miga de pan y al posicionamiento.
5. Nombre, descripción y URL amigable. Un cambio de URL sin redirección es una página perdida en Google.
6. Referencias y códigos (referencia, EAN): de ellos dependen el almacén, el ERP y los marketplaces.
7. Peso y medidas. Cambian lo que cobras de envío.

Qué tiene que tener un buen historial

• El empleado, con su nombre, no solo un número.
• Fecha y hora exactas.
• El origen: back-office, importación CSV, servicio web o un módulo. Muchas sorpresas no las hace una persona, sino una integración.
• El antes y el después de cada campo, en la misma línea.
• Filtros por producto, empleado, campo y fechas.
• Exportación para cruzarlo con pedidos o enseñárselo a quien corresponda.
• Retención configurable: guardar todo para siempre llena la base de datos; un plazo razonable y limpieza automática.

Casos en los que se usa

El precio que nadie cambió

Una tienda de alimentación ve cada pocos días productos con el precio a cero. Nadie del equipo lo ha tocado. El historial muestra que el cambio llega por el servicio web, siempre a la misma hora: el conector del ERP manda el precio vacío cuando un artículo no tiene tarifa asignada. Sin el origen anotado, habrían seguido sospechando del equipo.

El stock que no cuadra

Un distribuidor B2B hace inventario y faltan unidades. Con la línea de tiempo del producto se ve cada ajuste manual, cada movimiento de pedido y cada sincronización. El descuadre aparece en un ajuste manual que alguien hizo sobre la combinación equivocada.

La ficha que perdió posiciones

Un producto que se vendía bien baja en Google. El historial dice que hace tres semanas se cambió el nombre y la URL amigable, y que no se puso redirección. Se restaura la URL anterior o se crea la redirección, y se sabe exactamente qué texto había antes.

Cuántos pedidos entraron con el precio malo

Con la hora exacta del cambio y la de su corrección, filtras los pedidos de ese intervalo con ese producto. Ya sabes a quién tienes que escribir y cuánto te ha costado.

Cómo organizarlo en el equipo

• Un empleado por persona. Si tres personas comparten la misma cuenta del back-office, cualquier historial dirá solo «fue la cuenta de tienda». Cada uno con la suya y con el perfil que necesita.
• Cuentas propias para integraciones. El ERP, el conector de proveedores y el marketplace, cada uno con su clave del servicio web: así su origen se distingue.
• Revisión semanal. Un vistazo al resumen de la semana: quién ha cambiado más, qué campos y qué productos. Lo raro salta a la vista.
• Retención acordada. Unos meses suelen bastar para el día a día; si vendes productos con precios regulados o por contrato, quizá necesites más.

También ayuda al actualizar

Cuando actualizas PrestaShop o un módulo, o migras de versión, es habitual que algún proceso empiece a tocar campos que antes no tocaba: un módulo que reescribe precios al reinstalarse, una importación que ahora interpreta distinto los decimales. Tener el historial activo antes de la actualización te permite ver, al día siguiente, si algo ha cambiado productos sin que nadie lo pidiera.

Checklist

• Cada persona del equipo con su propia cuenta de empleado.
• Cada integración con su propia clave de servicio web.
• Historial activo al menos para precio, coste, stock, activación, categoría, nombre y URL.
• Plazo de retención decidido y limpieza automática.
• Revisión periódica del resumen.
• Antes y después de una actualización, un vistazo a los cambios.

Cómo resolverlo en PrestaShop

Full Product Log registra cada cambio de tus productos con el empleado, la fecha y la hora, la dirección desde la que se hizo y el valor anterior junto al nuevo, en hasta 84 campos que eliges vigilar. Encima del listado tienes el resumen del periodo, con quién cambia más, qué campos y qué productos, y cada nombre es un atajo que filtra el listado. Cada producto tiene su línea de tiempo, los movimientos de stock que llegan por el servicio web desde el ERP quedan anotados, exportas a CSV lo que estás viendo y decides cuánto tiempo se conserva. No modifica tus productos ni añade nada al escaparate, y funciona en multitienda, de PrestaShop 1.7.6 a 9.