Flujo de estados de pedido en PrestaShop: personalización y automatización

Esta es la parte de PrestaShop que sostiene en silencio todo tu back office y que casi nadie configura de forma deliberada: el estado del pedido. Cada pedido está exactamente en un estado en cada momento, y ese único valor decide qué ve el cliente en su cuenta, si se ha descontado stock, si existe una factura y qué email acaba de llegar a su bandeja de entrada. Si dejas intactos los valores predeterminados, una tienda con mucho movimiento avanza a base de suposiciones. Si adaptas los estados a la forma real en que preparas y envías los pedidos, el mismo back office empieza a decirle a tu equipo qué hacer a continuación, y a tus clientes qué está pasando antes de que escriban para preguntar. Esta guía trata precisamente de eso en PrestaShop: qué activa de verdad cada estado predeterminado, cómo crear los tuyos en Parámetros de la tienda → Estados, qué guarda por debajo la tabla ps_order_state y cómo automatizar transiciones para que las personas de tu equipo dejen de hacer de disparador de base de datos con pulso.

Última actualización: junio de 2026.

Qué es realmente un estado de pedido en PrestaShop

Un estado de pedido en PrestaShop no es solo una etiqueta. Cada estado es una fila en la tabla ps_order_state (con su nombre traducible en ps_order_state_lang), y esa fila contiene un conjunto de indicadores booleanos que le dicen al núcleo qué hacer cuando un pedido entra en ese estado: generar o no una factura, marcar el pedido como pagado, marcarlo como enviado, mostrar el PDF de entrega, enviar un email. (La deducción de stock no es uno de esos indicadores: PrestaShop reduce el stock disponible cuando el pedido se valida o se crea, no cuando se dispara un indicador de estado; volvemos sobre esto más abajo.) El estado actual del pedido vive en ps_orders.current_state y, además, PrestaShop escribe una nueva línea en ps_order_history cada vez que el estado cambia, de modo que el pedido conserva también una traza de auditoría completa, con fecha y hora, de todos los estados por los que ha pasado. El "estado actual" que ves en la administración es el valor de current_state, mientras ps_order_history registra cómo ha llegado hasta ahí.

La consecuencia práctica para el propietario de una tienda: la lista de estados es donde vive tu lógica operativa. Configura bien los indicadores una vez y PrestaShop los aplicará a todos los pedidos para siempre; ningún miembro del equipo tendrá que recordar "generamos la factura cuando se confirma el pago, no antes". Configúralos mal y puedes acabar generando facturas silenciosamente para pedidos que nadie ha pagado. Volvemos a ese peligro más adelante.

Los estados de pedido predeterminados y qué activa realmente cada uno

PrestaShop incluye un conjunto predefinido de estados. Muchos comerciantes los tratan como un adorno; en realidad, cada uno dispara acciones reales en la base de datos en el instante en que un pedido entra en él. Esto es lo que ocurre de verdad por debajo.

En espera de pago por cheque

Se aplica cuando un cliente elige pagar por cheque durante el proceso de compra. El pedido existe, pero el dinero todavía no ha llegado. El pedido se valida al realizarlo, por lo que el stock disponible se gestiona en ese momento según tu configuración de stock; este estado no lo "reserva" por separado. No se genera ninguna factura y el pedido queda aquí hasta que confirmas manualmente que el cheque se ha cobrado. Nada avanza por sí solo, y eso es intencionado.

En espera de pago por transferencia bancaria

El equivalente para transferencia bancaria. Al cliente se le muestra tu IBAN/BIC y una referencia de pedido, el stock disponible se gestiona al validar el pedido según tu configuración de stock, y el pedido queda aparcado aquí hasta que lo marcas como pagado, normalmente entre uno y tres días laborables después, cuando llega la transferencia. Este es el estado que más merece la pena automatizar (más sobre eso en la sección de automatización), porque confirmar transferencias a mano es pura administración repetitiva.

Pago aceptado

Este es el estado clave. Cuando un pedido llega a Pago aceptado, PrestaShop:

• Genera la factura (si el estado lleva el indicador de factura, como ocurre por defecto);
• Marca el pedido como pagado en la base de datos;
• Envía el email de estado al cliente.

Fíjate en lo que este estado no hace: no descuenta stock. El stock disponible se reduce cuando el pedido se crea o se valida en el proceso de compra, algo que ocurre incluso con pedidos que están en En espera de pago, así que el movimiento de inventario normalmente ya se ha producido antes de que el pedido llegue a Pago aceptado.

En pagos con pasarelas como PayPal, Stripe o Mollie, el módulo de pago establece este estado automáticamente en cuanto la pasarela confirma el cargo. Tú no lo tocas. Esa transición automática, impulsada por código, es exactamente el comportamiento que conviene replicar para tus métodos de pago manuales.

Procesamiento en curso / Preparación en curso

Un estado intermedio opcional que dice "el almacén está preparando y empaquetando". No dispara acciones automáticas; todo su valor está en la coordinación humana. Algunas tiendas lo omiten; las tiendas con mucho volumen lo consideran indispensable para distinguir de un vistazo la cola de preparación de la cola de pedidos pendientes de pago.

Enviado

Se aplica cuando el paquete sale de tus manos. Activa un email de confirmación de envío (incluido el número de seguimiento, si existe) y deja disponible el albarán de entrega. El orden importa: introduce el número de seguimiento en la sección Transportistas del pedido antes de cambiar el estado a Enviado, o el email saldrá sin el enlace de seguimiento y recibirás igualmente el mensaje de "¿dónde está mi paquete?".

Entregado

Marca que el cliente ya tiene los productos, ya sea manualmente o mediante una integración con la API del transportista. En la UE es el momento que inicia el plazo de devolución de 14 días para ventas a distancia, así que las fechas de entrega precisas no son un detalle cosmético: son el reloj sobre el que funciona tu política de devoluciones.

Cancelado

Cancelar un pedido puede volver a aumentar el stock disponible de los productos del pedido (a través del comportamiento normal de gestión de stock de PrestaShop, ya que el stock se había reducido al realizar el pedido), y el cliente recibe un email de cancelación. Hay dos cosas que no hace automáticamente: reembolsar el dinero (eso lo procesas aparte) y eliminar una factura que ya se haya generado. Si existe una factura, emite un abono en lugar de fingir que la factura nunca existió; tu contable te lo agradecerá.

Reembolsado

Se aplica una vez procesado un reembolso. Un abono no se crea solo por aplicar esta etiqueta de estado; se genera mediante el flujo de reembolso (el panel Reembolso estándar / Reembolso parcial / Devolver productos) cuando marcas la opción para generarlo. Que los artículos vuelvan o no al stock vendible también depende de cómo hayas gestionado el reembolso en ese panel.

Error de pago

Se establece cuando falla un intento de pago: tarjeta rechazada, fondos insuficientes, un paso de 3-D Secure fallido. No se descuenta stock ni se genera factura. Que el cliente reciba aviso depende por completo del módulo de pago.

En pedido pendiente (pagado / no pagado)

Para tiendas que aceptan pedidos que todavía no pueden enviar. El pedido queda registrado, pero la preparación espera a la reposición. Las variantes "pagado" y "no pagado" te permiten mantener claro el estado del pago mientras la mercancía está de camino hacia ti.

Leer los estados en la base de datos

No necesitas tocar SQL para gestionar una tienda, pero conocer la forma de los datos hace que las pantallas de administración tengan sentido, y es de ahí de donde cuelga cualquier automatización. Las tres tablas importantes:

Como cada cambio de estado añade una nueva fila en ps_order_history (además de actualizar current_state en el pedido), el historial nunca es una sobrescritura destructiva: es una traza de auditoría. Por eso siempre puedes ver por dónde ha pasado un pedido, y por eso una actualización SQL masiva y descuidada sobre estados de pedido es peligrosa: si escribes directamente en las tablas, te saltas todos los indicadores, emails y movimientos de stock que el núcleo dispararía normalmente. La forma compatible de mover un pedido desde código es a través del objeto de pedido, no con UPDATEs en bruto. Entramos en los hooks correctos para eso en la sección para desarrolladores.

Crear estados de pedido personalizados

Ve a Parámetros de la tienda → Estados (en PrestaShop 1.6 estaba en Pedidos → Estados). Haz clic en Añadir nuevo estado de pedido y estarás configurando desde la interfaz una de esas filas de ps_order_state. Los campos importantes:

• Nombre del estado: lo que lee tu equipo en la lista de pedidos. "Esperando proveedor" gana siempre a "Estado 7": la claridad aquí elimina toda una categoría de preguntas del tipo "¿qué significaba este otra vez?".
• Icono y color: la señal visual en la lista de pedidos. Elige una convención y mantenla: verde para lo correcto, naranja para lo pendiente, rojo para problemas. Un comerciante debería poder priorizar la lista de pedidos por color desde el otro lado de la habitación.
• Indicadores de comportamiento: este es el motor real:
  • Considerar el pedido asociado como validado: cuenta el pedido en tus estadísticas de ventas.
  • Permitir al cliente descargar y ver versiones PDF de sus facturas: controla la visibilidad de la factura en la cuenta del cliente.
  • Marcar el pedido como pagado: le dice al resto de PrestaShop que se ha recibido el dinero.
  • Mostrar PDF de entrega / Marcar el pedido como enviado: marca la mercancía como enviada y muestra el albarán de entrega.
  • Generar factura: crea el PDF de factura en esta transición.
  • Enviar un email al cliente cuando el estado del pedido haya cambiado: el disparador que convierte un estado en una notificación al cliente.
• Plantilla de email: qué mensaje se envía cuando el indicador de email está activado.

El "¿y qué?" de esos indicadores: son la diferencia entre un estado que solo es un color y uno que lleva tu contabilidad en silencio. Configúralos de forma deliberada y PrestaShop hará lo correcto en cada pedido futuro sin que nadie tenga que supervisarlo.

Estados personalizados que vemos con más frecuencia

Trabajando a diario con tiendas PrestaShop, estos son los estados personalizados que se ganan su sitio:

• Esperando proveedor: pagado, pero hay que pedir un artículo. Sin email al cliente: es una señal interna, no una noticia que el cliente necesite recibir.
• Listo para recoger: para recogida en tienda. Email activado, indicando al cliente la dirección, el horario y qué debe traer.
• Parcialmente enviado: algunos artículos ya han salido, otros siguen pendientes. Informa al cliente de qué se ha enviado y qué queda pendiente.
• En revisión: pedidos de alto importe o marcados por posible fraude retenidos para revisión manual. Sin email al cliente.
• Esperando respuesta del cliente: ya has contactado con él (corrección de dirección, pregunta sobre el producto) y el pedido queda pausado hasta su respuesta.
• Devolución solicitada / Devolución recibida: las dos mitades de un RMA: el cliente la ha solicitado y, más tarde, el paquete ha vuelto a tus manos para inspección.

Disparadores de email para cada estado

Cuando un estado tiene activado su indicador de email, PrestaShop envía al cliente la plantilla asignada a ese estado. Las plantillas viven en /mails/LANGUAGE_CODE/ como archivos HTML y TXT emparejados (la versión de texto plano es el recurso alternativo para clientes de correo que bloquean HTML, así que ambas deben existir).

Conectar un email a un estado personalizado

Activa el email para un estado personalizado y la plantilla pasa a ser responsabilidad tuya; si no existe, el envío falla silenciosamente y queda en los registros. Para conectarlo bien:

• Crea los archivos HTML y TXT correspondientes en cada carpeta de idioma bajo /mails/: el nombre de la plantilla debe coincidir con lo que espera el estado.
• Reutiliza los marcadores de variables que el núcleo ya expone: {firstname}, {lastname}, {order_name}, {id_order}, {shipping_number} para el seguimiento, y los demás.
• Define el aspecto una sola vez en Diseño → Tema de email en lugar de editar cada archivo a mano.

Si prefieres no crear plantillas, el caso realmente habitual es simplemente volver a enviar un email de pedido que el cliente ha perdido. PrestaShop puede reenviar la confirmación existente directamente desde la página del pedido; explicamos exactamente dónde está ese botón en cómo reenviar un email de confirmación de pedido.

Enviar los emails adecuados, no todos

• No envíes emails de más. Los clientes no quieren un mensaje por cada salto interno. "Preparación en curso" es para tu equipo, no para su bandeja de entrada. Reserva los emails para los momentos que de verdad les importan: pago confirmado, enviado (con seguimiento), entregado.
• Haz que cada email sea accionable. El email de envío incluye el número y el enlace de seguimiento; el email de listo para recoger incluye la dirección, el horario y qué debe traer el cliente. Un email sin siguiente paso solo genera una respuesta.
• Marca expectativas. En un pedido pendiente de reposición, indica la espera. Un vago "el estado de tu pedido ha cambiado" sin detalle es un ticket de soporte esperando a abrirse.

Automatizar cambios de estado

Gestionar estados a mano está bien con diez o veinte pedidos al día. A partir de ahí, cada transición manual es tiempo que estás pagando y una oportunidad para olvidar un paso. Las oportunidades, en orden aproximado de retorno:

Confirmación de pago

Las pasarelas de tarjeta ya automatizan esto: PayPal, Stripe y Mollie pasan el pedido a Pago aceptado al confirmar, sin intervención humana. La brecha está en las transferencias bancarias y los cheques, donde te queda la confirmación manual, una integración con movimientos bancarios que empareje transferencias entrantes con pedidos por referencia, o una comprobación programada contra un webhook de la pasarela. Cerrar esa brecha suele ser el mayor ahorro de tiempo de todo el flujo de pedidos.

Envío

Un módulo de integración con transportistas (Colissimo, DHL, Mondial Relay y similares) debería cambiar el pedido a Enviado y escribir el número de seguimiento en cuanto imprimes la etiqueta. Si el tuyo no lo hace, casi siempre existe un ajuste para activarlo dentro del módulo; simplemente suele venir desactivado por defecto.

Confirmación de entrega

Las API de los transportistas pueden informar de la entrega. Una tarea programada que consulte la API a diario y mueva los paquetes confirmados a Entregado mantiene honesto ese reloj de devoluciones de la UE sin que nadie tenga que vigilar páginas de seguimiento. Esto es terreno clásico de cron: configúralo una vez y déjalo trabajar mientras duermes.

Automatización de flujos basada en reglas

Para la lógica de "si esto, entonces aquello" que el núcleo no cubre — si el método de pago es transferencia bancaria y el total supera los 500 EUR, establecer En revisión y avisar al administrador — necesitas automatización de estados basada en reglas, no código personalizado que se rompa en la siguiente actualización. Ese es el tipo de flujo condicional para el que nuestro equipo crea módulos en mypresta.rocks: defines las condiciones y acciones desde el back office, y PrestaShop encamina cada pedido por la ruta correcta por sí solo. El beneficio no es la "automatización" como palabra de moda; es que el cuello de botella deja de ser una persona que tiene que estar sentada frente al ordenador.

Hooks de estado de pedido para desarrolladores

Si vas a crear la automatización tú mismo, PrestaShop dispara hooks alrededor de cada cambio de estado para que nunca tengas que escribir directamente en las tablas:

• actionOrderStatusUpdate: se dispara mientras se está aplicando un cambio de estado. Es un hook de tipo notificación, así que trátalo como el lugar para ejecutar tu propia validación y lógica de módulo alrededor de una transición, no como una forma garantizada y soportada por el núcleo de bloquearla limpiamente.
• actionOrderStatusPostUpdate: se dispara después de confirmar el cambio: el lugar para trabajos posteriores como sincronizar el pedido con un ERP o una plataforma de envíos.
• actionOrderHistoryAddAfter: se dispara después de escribir una nueva fila en ps_order_history; útil para tus propios registros y trazas de auditoría.

Un patrón típico: al pasar a Enviado, publicar un webhook en la API de tu partner logístico; al pasar a Entregado, poner en cola un email de solicitud de reseña para siete días después. Como mueves el pedido a través de su objeto y escuchas estos hooks, todos los indicadores, emails y movimientos de stock que pertenecen al núcleo siguen disparándose correctamente; precisamente por eso recurres a hooks en lugar de a un UPDATE SQL en bruto sobre ps_order_state.

Editar y corregir pedidos sobre la marcha

Los estados describen dónde está un pedido; igual de a menudo necesitas cambiar lo que hay en él: corregir una cantidad, cambiar una dirección, aplicar un descuento a posteriori. PrestaShop permite editar un pedido ya realizado desde su página de detalle, con límites reales una vez que existe una factura. La explicación completa de qué es seguro cambiar y cuándo está en cómo editar un pedido después de que se haya realizado, y el trabajo diario más amplio con la lista de pedidos — filtros, acciones masivas, estados en contexto — está cubierto en nuestra guía completa para gestionar pedidos en PrestaShop.

Gestionar envíos parciales

Los envíos parciales son el flujo más difícil que los valores predeterminados de PrestaShop llegan a manejar. El núcleo asume silenciosamente que un pedido equivale a un envío: el soporte nativo para envíos parciales es limitado, y los albaranes de entrega son documentos a nivel de pedido; PrestaShop no modela de forma limpia envíos parciales a nivel de artículo de serie. Un enfoque manual viable se parece a esto:

• Crea un estado personalizado Parcialmente enviado;
• Registra el número de seguimiento de los artículos que salen ahora;
• Cuando el resto esté listo, envíalo con un nuevo número de seguimiento;
• Solo pasa a Enviado cuando todo haya salido.

El punto de fricción: la página de detalle de pedido predeterminada no registra de forma nativa qué artículos fueron en qué paquete, y generar un documento de entrega por envío solo para los artículos de ese paquete no es una operación nativa. Las tiendas que dividen pedidos con regularidad necesitan un flujo personalizado o un módulo para tener seguimiento y documentos reales por artículo y por envío encima del núcleo; de lo contrario, el historial del pedido te dice que algo se envió, pero no qué.

Flujos de pedido B2B

La preparación de pedidos B2B no sigue el camino B2C, y la lista de estados es donde codificas la diferencia:

• Presupuesto y aprobación: pedidos que necesitan aprobación antes del pago, modelados como "Presupuesto enviado" → "Presupuesto aprobado" → "En espera de pago" → "Pago aceptado".
• Órdenes de compra: condiciones a 30/60/90 días significan que la preparación y el cobro del pago son dos relojes distintos; tus estados deben seguir ambos sin mezclarlos.
• Envíos parciales: los pedidos B2B con varios artículos y plazos de entrega mixtos se apoyan en la configuración de envíos parciales anterior como rutina, no como excepción.
• Control de pedido mínimo: los pedidos por debajo del umbral pueden pasar por "En revisión" antes de que nadie los prepare.

Informes sobre tus estados

Como cada transición es una fila con fecha y hora en ps_order_history, tus datos de estado son tus informes operativos, gratis, si los miras:

• Tiempo en cada estado: cuánto tiempo permanecen los pedidos en Pago aceptado antes de Enviado es, literalmente, tu velocidad de preparación y envío.
• Distribución de estados: una pila creciente en "Esperando proveedor" es un problema de suministro apareciendo antes de que tu proveedor lo admita.
• Cancelación por etapa: si los pedidos mueren de forma desproporcionada en un estado concreto, esa etapa de tu proceso tiene una fuga.
• Ciclo de vida completo: del pedido a la entrega, seguido en el tiempo, te dice si estás acelerando o volviéndote más lento en silencio.

Errores comunes que conviene evitar

• Demasiados estados. Pasada la docena, nadie los recuerda y la lista deja de ayudar a priorizar. Si tu equipo no puede recitarlos, tienes demasiados.
• Nombres poco claros. "Estado A" y "Estado B" no le dicen nada a nadie. Nómbralos por lo que significan.
• Un estado personalizado con email activado pero sin plantilla. Es el caso de fallo silencioso: el envío muere en los registros y el cliente no recibe nada.
• Personal sin formación. El flujo más limpio no sirve de nada si el equipo no sabe cuándo aplicar cada estado. Una hoja de referencia de una página se amortiza sola.
• El peligro del indicador de factura. Activa Generar factura en un estado que no esté confirmado por pago y empezarás a emitir facturas para pedidos que nadie ha pagado: un verdadero lío contable y fiscal que deshacer. Revisa dos veces ese indicador antes de guardar.

Una nota sobre pedidos de prueba

Mientras construyes todo esto, crearás pedidos de prueba para ver cómo se disparan los estados y los emails, y cada uno de ellos contamina tus estadísticas, tu secuencia de facturas y tu ps_order_history si lo dejas ahí. Límpialos antes de pasar a producción; la forma segura de eliminarlos (y por qué no deberías limitarte a hacer DELETE de las filas) está en cómo eliminar pedidos de prueba en PrestaShop.

Preguntas frecuentes

¿Dónde añado un estado de pedido personalizado en PrestaShop?

Ve a Parámetros de la tienda → Estados y haz clic en Añadir nuevo estado de pedido. En PrestaShop 1.6, la misma pantalla estaba en Pedidos → Estados. Cada estado que creas es una fila en la tabla ps_order_state, y las casillas de ese formulario (pagado, enviado, generar factura, enviar email) son los indicadores de comportamiento que el núcleo dispara cada vez que un pedido entra en ese estado.

¿Cambiar un pedido a "Pago aceptado" descuenta stock?

No. El stock disponible se reduce cuando el pedido se valida o se crea en el proceso de compra, algo que ocurre incluso mientras el pedido está en "En espera de pago", no cuando se dispara el indicador de pagado. Para cuando un pedido llega a Pago aceptado, el movimiento de inventario normalmente ya se ha producido. El estado pagado genera la factura, marca el pedido como pagado y envía el email de estado; no toca el stock.

¿Por qué nunca se envió el email de mi estado personalizado?

Casi siempre falta una plantilla. Cuando activas el indicador de email para un estado, PrestaShop busca archivos HTML y TXT con el nombre correspondiente bajo /mails/LANGUAGE_CODE/ en cada carpeta de idioma. Si esos archivos no existen, el envío falla silenciosamente en los registros y el cliente no recibe nada. Crea las plantillas HTML/TXT emparejadas para cada idioma antes de depender de ese email.

¿Puedo cambiar el estado de un pedido desde código sin escribir SQL?

Sí, y deberías hacerlo. Mueve el pedido a través de su objeto de pedido para que todos los indicadores, emails y movimientos de stock sigan disparándose, y escucha los hooks que ofrece PrestaShop: actionOrderStatusUpdate (mientras se aplica el cambio), actionOrderStatusPostUpdate (después de confirmar, útil para sincronización con ERP/envíos) y actionOrderHistoryAddAfter (después de escribir la fila de historial). Un UPDATE en bruto sobre ps_order_state se salta todo eso y es la forma de acabar con facturas y emails desincronizados.

¿Cómo evito generar facturas para pedidos no pagados?

Vigila el indicador Generar factura. Si lo activas para un estado que no está confirmado por pago, PrestaShop emitirá facturas para pedidos que nadie ha pagado: un verdadero lío contable y fiscal que deshacer. Mantén la generación de facturas ligada únicamente a tu estado de pago confirmado y revisa dos veces esa casilla antes de guardar un nuevo estado.

¿Puedo automatizar cambios de estado para transferencias bancarias y reglas condicionales?

Las pasarelas de tarjeta ya envían los pedidos a Pago aceptado automáticamente; la brecha está en transferencias bancarias, cheques y lógica condicional como "si es transferencia bancaria y el total supera los 500 EUR, establecer En revisión". Ese tipo de flujo basado en reglas es exactamente lo que nuestro módulo de automatización de flujos de pedido gestiona desde el back office, para que el cuello de botella deje de ser una persona que tiene que estar frente al ordenador cambiando estados.

Un flujo de estados de pedido bien diseñado es la columna vertebral de un back office tranquilo: el equipo sabe qué hacer a continuación, el cliente recibe la información correcta en el momento adecuado y la contabilidad se mantiene limpia porque los indicadores, no una persona agotada a las 6 de la tarde, deciden cuándo existe una factura y cuándo se mueve el stock. Planifica el flujo antes de conectarlo, porque una vez que los pedidos circulan por tus estados, cambiarlos a mitad de camino es mucho más disruptivo que acertar a la primera. Cuando las transiciones manuales se te queden pequeñas, la automatización basada en reglas de mypresta.rocks quita de encima a tu equipo los cambios repetitivos de estado para que cada pedido siga el mismo camino desde su creación hasta la entrega, siempre, lo esté mirando alguien o no.