Archivar pedidos antiguos en PrestaShop: un back-office rápido sin perder facturas

Abres «Pedidos» en el back-office y tarda. Filtras por cliente y tarda más. La tienda lleva años vendiendo, y cada pedido ha dejado filas en una veintena de tablas: líneas, historial de estados, pagos, facturas, transportes, mensajes, el carrito del que salió. Ninguna de esas filas se va sola.

La tentación es borrar pedidos viejos. No lo hagas: tienes obligaciones de conservación, y un pedido borrado a mano en PrestaShop deja huérfanos en otras tablas. Lo que sí puedes hacer es archivar.

Por qué se vuelve lento

El listado de pedidos de PrestaShop no consulta una sola tabla. Para pintar cada fila une el pedido con el cliente, la dirección, el país, el estado actual y la moneda, y para filtrar y ordenar tiene que recorrer muchas filas. Con decenas o cientos de miles de pedidos, cada búsqueda trabaja sobre todo el histórico aunque tú solo quieras ver los de esta semana.

Afecta también a otras pantallas: la ficha del cliente, las estadísticas, algunos módulos que calculan cosas sobre el historial de pedidos y las exportaciones.

Archivar no es borrar

Archivar significa sacar los pedidos antiguos de las tablas activas y guardarlos completos en otras tablas, de donde se pueden consultar y, si hace falta, devolver. La diferencia con borrar es total:

• El pedido sigue existiendo con todos sus datos: líneas, importes, impuestos, facturas, abonos, pagos y mensajes.
• Puedes buscarlo y verlo cuando un cliente o tu asesoría lo pidan.
• Puedes restaurarlo con su mismo número si vuelve a necesitarse en el día a día.

La normativa mercantil y la fiscal te obligan a conservar facturas y documentación durante años. Archivar es compatible con eso; borrar, no.

Qué tiene que viajar con cada pedido

Un pedido en PrestaShop no es una fila. Si solo mueves la tabla de pedidos, el resto queda colgando. Como mínimo tienen que ir juntos:

• El pedido y sus líneas.
• El historial de estados.
• Facturas, albaranes, pagos y abonos.
• Devoluciones y sus líneas.
• Transportista y seguimiento.
• El carrito del que salió y sus productos.
• Los mensajes del pedido.

Y tiene que hacerse como una transacción: o se mueve el pedido entero, o no se mueve nada. Un archivado que falla a mitad y deja medio pedido en cada lado es peor que no archivar.

Las trampas de la numeración

Aquí está el detalle que más problemas da. PrestaShop calcula el siguiente número de pedido, de factura y de albarán a partir de los que existen en las tablas. Si archivas justo el pedido que tiene el último número de factura, PrestaShop puede «no verlo» y repetir el número en la siguiente factura. Una factura duplicada es un problema fiscal serio.

Reglas prudentes:

1. No archivar nunca el pedido que tiene el último número de pedido, de factura o de albarán.
2. Impedir que un pedido nuevo reciba el número de uno archivado.
3. Si usas series o numeraciones propias con otro módulo, comprueba en una copia cómo calcula el siguiente número antes de archivar.

Qué pedidos archivar

El criterio habitual es la antigüedad, pero conviene afinarlo:

• Antigüedad mínima. Medio año o un año es un punto de partida razonable; depende de tu plazo de devoluciones y de garantía.
• Estados. Solo pedidos cerrados: entregados, cancelados, reembolsados. Un pedido pendiente de pago o en devolución no se archiva.
• Movimiento reciente. Si un pedido antiguo ha tenido un cambio de estado hace poco (un abono tardío, una garantía), mejor esperar.
• Pedidos divididos. Si un carrito generó varios pedidos, se archivan todos juntos o ninguno.

Qué cambia para ti y para el cliente

Un pedido archivado sale de las tablas del núcleo, así que:

• Deja de contar en las estadísticas del núcleo de PrestaShop.
• No aparece en el historial de «Mi cuenta» del cliente hasta que lo restaures; conviene avisarle con un texto de que sus pedidos antiguos están archivados y que puede pedirlos.
• Los módulos que calculan cosas sobre el historial (fidelización, segmentos, recomendaciones) dejarán de verlo. Revisa cuáles usas.

Cómo hacerlo con cabeza

1. Copia de seguridad completa de la base de datos antes del primer archivado.
2. Simulación: cuenta los candidatos y las filas que se moverían, sin mover nada.
3. Tandas pequeñas al principio, y comprueba el listado del archivo y una restauración.
4. Automatiza con una tarea programada y un informe por correo de cada ejecución.
5. Deja el borrado definitivo bloqueado. Si algún día se borra algo del archivo, que exija desbloquearlo a propósito y un permiso específico.

Una nota sobre versiones: si tu tienda sigue en una 1.7 temprana o en una 1.6, el archivado alivia el back-office, pero no sustituye la actualización. PrestaShop 8 y 9 con un PHP actual también rinden mejor en las mismas consultas. Si vas a migrar, archivar antes reduce el volumen de datos que hay que pasar y probar.

Preguntas frecuentes

¿Puedo seguir emitiendo un abono de un pedido archivado? No directamente: primero lo restauras, emites el abono con normalidad y, si quieres, vuelve al archivo en la siguiente pasada. Por eso conviene que la antigüedad mínima supere tu plazo de devoluciones y de garantía.

¿Archivar libera espacio en disco? Mueve filas de unas tablas a otras, así que el tamaño total de la base no baja. Lo que mejora es la velocidad de las consultas sobre las tablas activas. Optimizar las tablas tras cada ejecución ayuda a recuperar parte del espacio que dejan los huecos.

¿Y mi asesoría, puede seguir pidiendo facturas antiguas? Sí. Las facturas siguen guardadas con el pedido archivado y se pueden consultar o restaurar cuando hagan falta.

Cómo resolverlo en PrestaShop

RKR Order Archive saca los pedidos antiguos de las tablas activas y los guarda completos, con sus 20 tablas (líneas, historial, facturas, pagos, devoluciones, abonos, carrito y mensajes), en un archivo con listado, buscador y filtros. Eliges antigüedad, estados, tienda, importe mínimo y tamaño de cada pasada, y puedes excluir pedidos con movimiento reciente. Trae modo simulación, cron con token propio, informe por correo y restauración exacta con el mismo número. Cada operación es una transacción, no archiva el pedido con el último número de factura, albarán o pedido, espera a que los pedidos divididos se puedan archivar juntos y mantiene el borrado definitivo bloqueado por defecto.