Eliminar pedidos de prueba: deja tu PrestaShop limpio antes de salir a producción

Revisado y actualizado en junio de 2026 — se ha verificado en PrestaShop 1.7, 8 y 9 la ausencia de una acción nativa para eliminar pedidos y el reinicio del contador de facturas.

El día antes del lanzamiento, tu base de datos de PrestaShop parece una escena del crimen creada por ti mismo. Hiciste pedidos para probar los precios de los transportistas, pasaste una tarjeta por la pasarela de pago dos veces para asegurarte, creaste "asdf asdf" para comprobar el formulario de dirección y activaste todos los estados de pedido para ver cómo se enviaban los correos. Todo eso funcionó — y ese es exactamente el problema. Cada uno de esos pedidos de prueba ya está incrustado en tus estadísticas, en tu secuencia de facturas y en tu lista de clientes, y la primera mañana de ventas reales te dará una imagen falsa de cómo va la tienda. Esta guía trata de una tarea muy concreta: eliminar limpiamente los pedidos de prueba antes de salir a producción, en una tienda que nunca ha recibido un pedido real — porque, una vez que existen pedidos y facturas auténticos, PrestaShop dificulta deliberadamente su eliminación por motivos legales y contables.

El alcance es intencionadamente limitado. Limpiar carritos, registros y tablas de conexión para mantener el rendimiento a largo plazo es otra rutina — la diferencia entre "lanzo la tienda la semana que viene" y "mi base de datos lleva dos años creciendo" — y conviene separarlas para borrar solo lo que un lanzamiento realmente exige.

Por qué un pedido de prueba olvidado sale más caro de lo que parece

Eliminar un pedido puede parecer algo cosmético. No lo es. En PrestaShop, un pedido no es una sola fila: es un pequeño grafo de filas repartidas por una docena de tablas, varias de las cuales alimentan informes y contadores de los que dependerás desde el primer día. Si las dejas ahí, esto es lo que se rompe, de forma concreta:

• Tu primera cifra de ingresos es incorrecta y no puedes saberlo. El panel y las páginas de Estadísticas suman ps_orders (y ps_order_detail) sin saber qué filas eran pruebas de precios de transportista. Los ingresos del primer día, el valor medio del pedido y la tasa de conversión quedan inflados por pedidos que nunca existieron, así que justo cuando más necesitas una señal limpia — "¿la nueva tienda está vendiendo de verdad?" — tus datos están más sucios que nunca.
• Tu primera factura real tiene el número #38. En PrestaShop, los números de factura se asignan desde un contador continuo, no desde el pedido. Cuarenta pedidos de prueba que generaron facturas consumen cuarenta números, así que la primera factura auténtica para tu gestor aparece con un número no secuencial a mitad de la treintena y treinta y siete predecesoras invisibles. Ese es el tipo de hueco por el que pregunta una inspección fiscal.
• Tu lista de clientes queda salpicada de fantasmas. "Usuario de prueba", "asdf asdf" y tus tres cuentas desechables aparecen en ps_customer junto a personas reales. Cada segmento, exportación y estadística de "número de clientes" los cuenta. Exporta esa lista a una herramienta de marketing por correo electrónico y las direcciones de prueba — si usaste direcciones reales — recibirán campañas.
• Se movió stock por ventas que nunca ocurrieron. Si tus pedidos de prueba se hicieron sobre productos reales con la gestión de stock activada, cada uno escribió una fila en ps_stock_mvt y redujo la cantidad. Elimina mal el pedido y el movimiento de stock se queda, de modo que el inventario del día de lanzamiento queda discretamente descuadrado. (Conciliar eso es una tarea de datos de stock por derecho propio — consulta gestión de inventario cuando las hojas de cálculo dejan de funcionar.)

¿Y qué implica? Un pedido de prueba que olvidas borrar no solo llena una pantalla de ruido: corrompe las tres cosas que un lanzamiento debería darte: una cifra de ingresos honesta, una secuencia de facturas limpia y una lista de clientes fiable. Eliminarlos lleva quince minutos y te deja una base de datos que realmente puedes leer.

No hay un botón limpio de "eliminar pedido" — y por qué importa

La primera sorpresa es esta: PrestaShop nativo (1.7, 8, 9) no ofrece una acción normal en el panel de administración para eliminar un pedido. Los pedidos se tratan como registros financieros y deben conservarse por integridad legal y contable, así que los menús de acciones masivas y de fila que irías a buscar simplemente no ofrecen un "Eliminar" como sí ocurre en las listas de productos o clientes. Es deliberado, no un descuido.

Precisamente por eso, la única forma segura de eliminar pedidos de prueba es hacerlo antes de que exista ningún pedido real. Tus opciones realistas son:

• Restaurar una copia de seguridad limpia previa al lanzamiento. El reinicio más simple y seguro: toma la instantánea anterior a tus pruebas y vuelve a ese punto. Todo lo que sigue asume que prefieres no hacerlo, pero esta es la opción con riesgo cero de filas huérfanas.
• Trabajar sobre una base de datos de staging. Prueba sobre una copia y después despliega una base de datos de producción limpia que nunca haya visto un pedido de prueba.
• Usar un módulo o script específico de limpieza de pedidos. Eliminar un pedido correctamente significa recorrer todo el grafo de filas relacionadas, por eso debe hacerlo una herramienta probada por versión, no una acción manual en el panel. Ejecútalo solo en una tienda con cero pedidos reales.

E incluso cuando un pedido se elimina (mediante un módulo o mediante la propia lógica de objeto Order::delete() de PrestaShop), nunca limpia todo lo que orbita alrededor del pedido a un paso de distancia:

• El cliente (ps_customer) y sus direcciones (ps_address): eliminar un pedido nunca borra a la persona que lo hizo. Tus clientes ficticios sobreviven.
• El carrito de origen (ps_cart, ps_cart_product): el carrito que se convirtió en pedido queda atrás como carrito "abandonado".
• La fila de factura (ps_order_invoice) y el contador de números de factura: eliminar el pedido no devuelve el número que consumió.
• Cualquier movimiento de stock (ps_stock_mvt) ya escrito contra productos reales.

Así que eliminar pedidos es solo el primer paso, no todo el trabajo. El patrón que realmente deja la tienda limpia es: eliminar los pedidos en una tienda previa al lanzamiento, después borrar sus clientes y carritos, y por último fijar explícitamente el siguiente número de factura. A continuación tienes cómo hacer cada parte de forma determinista.

La limpieza previa al lanzamiento, paso a paso

1. Haz primero una copia de seguridad de la base de datos — no es negociable. Crea un volcado real de la base de datos: la herramienta de copias de tu hosting, phpMyAdmin o Adminer, o un mysqldump si tienes acceso por shell. (Nota: Gestor SQL, en Parámetros avanzados, sirve para ejecutar consultas guardadas sobre tus datos, no para hacer una copia completa; no confíes en él para esto.) Eliminar pedidos es destructivo y no hay deshacer. Si algo de lo siguiente te sorprende, restauras y vuelves a intentarlo.
2. Crea una lista definitiva de los ID de pedidos de prueba. En Pedidos → Pedidos, ordena por fecha e identifica todos los pedidos anteriores al lanzamiento. Anota el rango de ID; casi siempre son un bloque contiguo al principio (del 1 hasta el que corresponda). La trampa aquí es un lanzamiento limitado: si recibiste pedidos reales tempranos, esos ID estarán mezclados con las pruebas. Enumera explícitamente los reales para no borrar nunca a un cliente que ha pagado.
3. Elimina los pedidos. Como PrestaShop nativo no tiene una acción en el panel para eliminar pedidos, este es el paso que necesita un módulo de limpieza específico o un pequeño script que llame a Order::delete() para cada ID de prueba — o, lo más simple de todo, restaurar tu copia de seguridad limpia previa al lanzamiento. Hazlo solo en una tienda con cero pedidos reales.
4. Elimina los clientes de prueba. Ve a Clientes → Clientes, localiza las cuentas claramente ficticias y bórralas; esto también elimina sus direcciones. De nuevo, vigila los compradores del lanzamiento limitado que quieras conservar.
5. Fija explícitamente el siguiente número de factura en 1. Ve a Pedidos → Facturas y, en Opciones de factura, establece Siguiente número de factura disponible en 1 — hazlo solo en una tienda donde nunca se haya emitido una factura auténtica y confirma que no haya empezado ya ninguna secuencia legal de facturación. (Esto fija directamente el número inicial; no esperes que configurarlo en 0 haga que "empiece automáticamente en 1".) Haz lo mismo con la numeración de albaranes si probaste entregas (Pedidos → Albaranes de entrega). Este es el paso que casi todo el mundo olvida, y es el que tu gestor nota; pero si ya existen facturas reales, deja la secuencia como está y consulta tus requisitos contables.
6. Vacía la caché. Parámetros avanzados → Rendimiento → Vaciar caché. Los contadores y las vistas de lista se almacenan en caché; sin esto, el panel puede seguir mostrando totales antiguos.
7. Verifica contra los números, no contra tu memoria. Abre Pedidos → Pedidos (debería estar vacío o contener solo pedidos reales del lanzamiento limitado), Clientes y el panel. Si los ingresos no están a cero (o no muestran la cifra real del lanzamiento limitado), algo no se eliminó; vuelve a tu copia de seguridad y a tu lista antes de lanzar con datos sucios.

Cuando tienes docenas de pedidos de prueba: la vía SQL

Hacer clic en cincuenta pedidos uno por uno es tedioso y propenso a errores. Si te manejas con Parámetros avanzados → Base de datos → Gestor SQL (que está bien para consultas de investigación de solo lectura), al menos puedes delimitar los datos de prueba con precisión; pero, como explica la siguiente sección, la eliminación real debería pasar por código probado, no por un DELETE escrito a mano. El motivo es el esquema de PrestaShop: muchas tablas no tienen claves foráneas en cascada, así que borrar primero el registro padre deja huérfanos los hijos en lugar de eliminarlos, y es fácil contar de menos el conjunto completo de tablas relacionadas.

Primero, localiza los pedidos de prueba para trabajar con ID reales, no con suposiciones. Por ejemplo, todo lo realizado antes de tu fecha de lanzamiento:

SELECT id_order, reference, total_paid, date_add FROM ps_orders WHERE date_add < '2026-06-13 00:00:00' ORDER BY id_order;

Es mucho mejor dejar que el propio Order::delete() de PrestaShop gestione las filas hijas (ejecutándolo desde un pequeño script sobre tus ID de prueba) que escribir la eliminación a mano. Un pedido real de PrestaShop toca mucho más que la media docena de tablas evidentes: detalles e historial del pedido, pero también transportistas del pedido, mensajes, devoluciones y abonos, personalizaciones, facturas, impuestos y filas de ps_order_payment asociadas por la referencia del pedido en lugar de por un enlace hijo ordenado mediante id_order, además de cualquier tabla propia de módulos que añada tu instalación. Esa es exactamente la razón por la que una lista de DELETE escrita a mano es peligrosa: cualquier tabla que olvides se convierte en un huérfano invisible.

Por eso esta guía, deliberadamente, no te entrega una receta SQL parcial de "borra estas N tablas en este orden"; esa receta estaría incompleta para casi cualquier tienda real. Usa la lógica de objeto (Order::delete()) o un script de limpieza probado por versión que enumere todas las tablas relacionadas, incluidas las filas de pago que debe buscar por referencia. Después limpia los satélites — clientes, carritos, contador de facturas — por separado.

¿Y qué implica? Saltarse una tabla relacionada no es una cuestión de purismo: si te equivocas, dejas filas huérfanas invisibles que siguen contaminando los informes aunque en el panel parezcan eliminadas. Ese es exactamente el fallo que todo este proceso pretende evitar, y por eso nos apoyamos en código probado en lugar de en un bloque SQL copiado y pegado.

Una advertencia honesta: truncar las tablas de pedidos (TRUNCATE ps_orders y similares) es la opción de fuerza bruta que verás sugerida en Internet. Es rápida y reinicia los ID de autoincremento a 1 — algo tentador para un lanzamiento —, pero se salta todas las salvaguardas, no toca las tablas satélite y puede destruir sin contemplaciones un pedido de lanzamiento suave. Considérala solo en una tienda con cero datos reales y únicamente con una copia de seguridad cuya restauración hayas comprobado.

Limpia también los datos de demostración mientras estás ahí

Los pedidos de prueba son el bloqueo principal del lanzamiento, pero si instalaste PrestaShop con datos de demostración, el catálogo de ejemplo es su propio problema previo a la salida a producción, y merece resolverse en la misma sesión. Instalado con datos demo, PrestaShop puede incluir productos, categorías, proveedores, marcas y páginas CMS de ejemplo (los marcadores de posición "Entrega", "Aviso legal", "Sobre nosotros"); cuáles exactamente varían según la versión, la distribución y el idioma. Dejarlos ahí implica dos riesgos: que un producto real acabe por accidente en una categoría demo y que Google indexe una página de "Términos y condiciones" que todavía es texto de relleno Lorem ipsum.

Elimina o reescribe, en Catálogo y Diseño → Páginas, los productos y categorías demo, y las páginas CMS de marcador de posición (sustitúyelas por tus textos legales reales, no las escondas sin más). Hazlo desde el panel de administración o mediante un proceso de importación controlado; no borres archivos a mano dentro de /img, donde viven tus imágenes reales de producto, categoría, marca, proveedor, tema y sistema, no solo las de demostración. Eliminar los productos demo desde el panel de administración limpia sus registros de imagen de forma segura; si después quieres recuperar espacio en disco, regenera o depura imágenes no usadas solo con una copia de seguridad a mano. Si partes de un catálogo demo grande y vas a importar el real, hacerlo limpiamente mediante CSV es una tarea propia: consulta importación y exportación de productos en PrestaShop.

Prevención: evita crear el mismo desorden la próxima vez

Volverás a hacer pruebas: con cada cambio de tema, actualización de módulo de pago y actualización de PrestaShop. El objetivo es que las pruebas futuras no dejen residuos en tus datos reales:

• Prueba en una copia de staging, no en la tienda en producción. Una instalación duplicada donde cada pedido de prueba, reembolso y cambio de estado ocurre aparte. Es la mayor mejora posible: tu ps_orders en producción solo contiene ventas reales, así que no hay nada que limpiar.
• Usa el modo sandbox para los pagos. Stripe, PayPal y la mayoría de pasarelas ofrecen una clave de prueba/sandbox que procesa transacciones ficticias sin cargos reales. Prueba el flujo de pago sin tocar nunca una tarjeta real, y recuerda volver a poner todas las pasarelas en modo real antes del lanzamiento (una clave sandbox olvidada es el error de lanzamiento en espejo).
• Etiqueta la prueba inevitable en producción. Si tienes que probar contra producción, usa una marca reconocible — un cliente llamado ZZ-TEST, un patrón de email dedicado, una nota en el pedido — para que un único filtro ordenable saque a la superficie cada fila de prueba para eliminarla. La idea de marcar claramente los pedidos de prueba conecta con cómo gestionas los estados de pedido en general; si te encuentras probando repetidamente correos de estado, la automatización de esas transiciones se explica en personalización y automatización del flujo de estados de pedido.

Preguntas frecuentes

¿Cómo elimino un pedido de prueba en PrestaShop?

PrestaShop nativo (1.7, 8, 9) no tiene una acción "Eliminar pedido" en el panel de administración: los pedidos se tratan como registros financieros y se conservan por diseño. La única forma segura de eliminar pedidos de prueba es antes de que exista ninguno real: restaurar una copia de seguridad limpia previa al lanzamiento, desplegar una base de datos de staging que nunca haya visto un pedido de prueba, o ejecutar un módulo/script de limpieza probado por versión que llame a Order::delete() sobre tus ID de prueba. Haz primero una copia de seguridad de la base de datos; eliminar pedidos es destructivo y no hay deshacer.

¿Por qué mi primera factura real empieza en el número 38 en vez de en el 1?

Los números de factura proceden de un contador continuo, no del pedido, así que cada pedido de prueba que generó una factura consumió un número. Después de limpiar las pruebas, ve a Pedidos → Facturas → Opciones de factura y establece Siguiente número de factura disponible en 1, pero solo en una tienda donde nunca se haya emitido una factura auténtica. Configurarlo en 0 no hace que "empiece automáticamente en 1"; fija directamente el número inicial. Si ya existen facturas reales, deja la secuencia como está.

¿Eliminar un pedido también elimina el cliente y el carrito?

No. Eliminar un pedido nunca borra a la persona que lo hizo (ps_customer) ni sus direcciones (ps_address), y el carrito que se convirtió en pedido queda atrás como carrito "abandonado" (ps_cart). Tampoco retrocede el contador de números de factura ni cualquier movimiento de stock ya escrito. Por tanto, eliminar el pedido es el primer paso, no todo el trabajo: después borras los clientes y carritos de prueba y reinicias el contador por separado.

¿Puedo ejecutar simplemente una consulta DELETE o hacer TRUNCATE de las tablas de pedidos?

Evítalo. Un pedido real toca mucho más que la media docena de tablas evidentes: detalles e historial del pedido, transportistas, mensajes, devoluciones, abonos, personalizaciones, facturas, impuestos y filas de ps_order_payment enlazadas por la referencia del pedido en lugar de por id_order, además de tablas propias de módulos. Un DELETE escrito a mano que olvida una sola tabla deja filas huérfanas invisibles que siguen contaminando los informes aunque parezca eliminado. TRUNCATE es más rápido y reinicia los ID a 1, pero se salta todas las salvaguardas y destruirá cualquier pedido de lanzamiento suave. Usa Order::delete() o un script de limpieza probado. Una SELECT de solo lectura para encontrar primero los ID de prueba está bien.

¿Cómo evito crear este desorden la próxima vez?

Haz pruebas en una copia de staging, no en la tienda en producción; así tu ps_orders real solo contiene ventas auténticas. Usa el modo sandbox/prueba de cada pasarela para probar pagos (y recuerda devolver cada pasarela a modo real antes del lanzamiento). Si tienes que probar contra producción, etiqueta los pedidos con una marca reconocible (un nombre de cliente ZZ-TEST o un patrón de email dedicado) para que un único filtro ordenable muestre todas las filas de prueba que debes eliminar.

Dónde encaja esto en el panorama general

Eliminar pedidos de prueba es una puerta puntual del lanzamiento. Los hábitos que mantienen una base de datos de pedidos limpia y fiable después del lanzamiento son una disciplina aparte y continua: corregir el pedido real ocasional que salió mal mediante edición de pedidos, reenviar una confirmación a un cliente que la perdió con reenvío de confirmaciones de pedido, extraer cifras limpias para tu gestor con exportaciones CSV de pedidos y facturas, y la rutina diaria que mantiene todo en marcha en flujos de gestión de pedidos que te ahorran horas.

El principio para el día de lanzamiento es sencillo: los únicos pedidos en tu base de datos deberían ser los que un cliente hizo de verdad. Saca los pedidos de prueba — en el orden correcto, con el contador de facturas reiniciado y la copia de seguridad bien guardada — y la primera cifra de ingresos de tu tienda te dirá la verdad. A partir de ahí, cada informe limpio que consultes será una pequeña recompensa por los quince minutos que dedicaste ahora. Si una base de datos ordenada y unas estadísticas precisas importan en la forma en que gestionas la tienda, ese es exactamente el tipo de fiabilidad entre bastidores que nuestros módulos PrestaShop están diseñados para proteger.