Flujos de pedidos en PrestaShop: estados, correos y edición

Qué haríamos

Antes de añadir estados, definiríamos el flujo de trabajo que ya utilizas: quién confirma el pago, autoriza la preparación, gestiona las excepciones y confirma el envío. La opción adecuada depende de tus módulos de pago y transporte, integraciones con el ERP o el almacén, tema y proceso de compra, datos de pedidos existentes, mercados, requisitos contables y permisos del equipo. Reserva los estados nativos para eventos comerciales relevantes y utiliza etapas internas independientes cuando lo que falte sea un responsable o una siguiente tarea.

Ensaya los cambios en una copia de staging con pedidos representativos y los mismos módulos, tema e integraciones. Utiliza pagos de prueba y captura de correo, y aísla las exportaciones al almacén y las acciones de los transportistas de los sistemas en producción. Guarda la configuración actual y las correspondencias de estados, prueba el recorrido normal y las excepciones que se indican a continuación y planifica después el cambio en producción con un responsable, pasos para revertirlo y un proceso para los pedidos que ya estén en curso.

Si quieres configurar un módulo existente y comprobar el recorrido acordado, PrestaShop Module Installation & Configuration Service cubre esa configuración delimitada; las licencias, los módulos adicionales y el desarrollo se contratan aparte.

Organiza el trabajo diario con los pedidos

Abre Pedidos > Pedidos y filtra el trabajo que necesites: pedidos sin pagar que requieren revisión, pedidos pagados pendientes de preparación o pedidos con un problema de entrega. Utiliza las columnas y los filtros disponibles en tu versión. Si tu versión conserva los filtros en la URL, prueba a guardar un marcador para una cola habitual y comprueba su intervalo de fechas al volver a abrirlo. Confirma los pedidos seleccionados antes de ejecutar una acción masiva.

Las páginas modernas de pedidos usan controladores Symfony, cuadrículas y gestores de comandos, tras la migración de la página de pedidos en PrestaShop 1.7.7. AdminOrders sigue siendo un identificador útil heredado y de permisos, pero no es el controlador de renderizado de todas las versiones.

El menú masivo nativo de la lista de pedidos permite cambiar estados y abrir pedidos en pestañas nuevas. Una transición masiva puede generar documentos, actualizar stock y enviar correos para cada pedido. Prueba una selección pequeña y revisa los fallos antes de procesar un lote grande.

Usa Pedidos > Facturas y Pedidos > Albaranes de entrega para la generación de PDF por lotes compatible, incluidas selecciones por fecha. No esperes una acción conjunta de impresión de facturas en todos los menús masivos de listas de pedidos. Revisa la numeración, el texto del documento, la información fiscal y la correspondencia de impresiones antes de entregar un lote al almacén.

Utiliza notas privadas para llamadas, instrucciones de embalaje, decisiones de revisión y correcciones. Comprueba el ajuste privado/público antes de enviar un mensaje de pedido. Registra suficiente contexto para que otro empleado pueda continuar el trabajo: la decisión, el responsable, la siguiente acción y el momento de revisión. Evita incluir datos sensibles del cliente en notas que no los necesiten.

Una cola creciente de pedidos a la espera de stock puede requerir una mejor política de reposición o de productos agotados en lugar de otro estado. Revisa el inventario, los plazos de los proveedores y las condiciones de reserva junto con el procesamiento de pedidos. La guía de inventario trata las decisiones de stock que alimentan esta cola.

Entiende los estados de pedido y sus indicadores

Configura los estados modernos en Parámetros de la tienda > Configuración de pedidos > Estados. PrestaShop 1.6 usaba Pedidos > Estados. Un nombre como Preparación o En revisión no define su comportamiento; inspecciona sus indicadores.

Con el prefijo de ejemplo ps_, ps_order_state guarda indicadores, ps_order_state_lang guarda nombres traducidos y nombres de plantillas de correo, ps_orders.current_state guarda el estado actual y ps_order_history registra las transiciones normales. Usa el prefijo real de tu instalación.

Cambia los estados mediante la administración de pedidos o las API del núcleo compatibles. Actualizar current_state directamente evita el comportamiento habitual de historial, documentos, correo y stock. Actualizar una definición de estado es algo distinto: cambia la definición usada por las transiciones futuras.

Para un flujo conceptual, consulta la documentación del ciclo de vida del pedido. Documenta qué equipo aplica cada estado y qué sistema es la fuente autorizada de pago y expedición.

Comprueba el ciclo predeterminado antes de personalizarlo

Las tiendas existentes y los módulos de pago pueden alterar los valores predeterminados. Los valores habituales de instalación proporcionan este punto de partida; compáralos con tus propios ajustes.

Estos valores habituales se enumeran en las definiciones de estados de instalación. Los fallos de pago que nunca crean un pedido no tienen historial de pedido desde el que notificar; el comportamiento de la pasarela es independiente.

Un flujo ordinario posible es espera de pago, pago confirmado, preparación, expedición y entrega. No es una secuencia universal impuesta automáticamente. Un indicador de pagado es una decisión contable/de flujo, así que no lo uses como forma cómoda de pasar un pedido no pagado a la cola del almacén.

Crea estados personalizados solo para decisiones útiles: esperando proveedor, listo para recoger, en revisión, esperando respuesta del cliente, devolución solicitada o devolución recibida. Da a cada uno un nombre claro y un color coherente, y elige después sus indicadores de forma independiente. Una etiqueta realmente interna no debe enviar correo solo porque lo haga otra de nombre parecido.

Para condiciones de crédito B2B, controla por separado preparación/entrega y cobro. La aprobación de presupuestos, órdenes de compra y vencimientos de pago necesitan un proceso definido; añadir un estado no crea un sistema de presupuestos o control de crédito. Establece el momento de facturación según la operación, las condiciones de pago y las normas aplicables, no suponiendo que toda factura deba seguir al pago. Consulta la guía de facturación VAT de la UE y tus requisitos nacionales.

Prueba un pedido pagado retenido por una dirección

Un cliente paga un artículo en stock y después pide a soporte que compruebe la dirección de entrega antes del embalaje. Utiliza este caso en staging para demostrar que un pedido pagado puede esperar a que se complete una tarea sin tratarse como no pagado ni enviado.

No apliques la retención pasando por Cancelado o Error de pago: esos estados afectan al stock. Decide quién puede levantar una retención y cómo la excluye un lote de envíos; una etiqueta interna por sí sola no demuestra que el almacén respete la parada.

Mantén coherentes el stock y el dinero

El stock disponible normalmente se reduce al crear el pedido mediante el flujo de pago/validación cuando se aplica la gestión de stock. Pasar un pedido ordinario en espera de pago a Pago aceptado no descuenta esas unidades por segunda vez.

Las transiciones que implican Cancelado o Error de pago pueden restaurar o descontar de nuevo stock disponible. Pasar entre estados enviados y no enviados también afecta a los movimientos de stock. Importan los packs, las cantidades devueltas y los ajustes de producto. Prueba la transición real en lugar de tratar todos los estados como simples etiquetas.

• Cancelación: puede afectar al stock mediante la transición de estado, pero no reembolsa automáticamente un pago capturado ni borra una factura.
• Reducción directa de cantidad o eliminación de línea: usa su propia gestión de variaciones de stock. No es el mismo proceso que elegir la opción de reponer stock de un reembolso.
• Reembolso: usa el flujo estándar o parcial adecuado y decide si generar un abono y si la mercancía debe volver al stock vendible.
• Restablecimiento tras cancelación/error: confirma la disponibilidad y el pago antes de volver a un estado válido. El stock puede descontarse otra vez.

Concilia las transacciones de la pasarela y los pagos registrados. Cambiar el importe de un pedido o establecer un estado pagado no captura dinero adicional, y aplicar Reembolsado no demuestra que la pasarela lo haya devuelto. Registra el cobro o reembolso real, su referencia y cualquier importe pendiente.

Mantén los pedidos de prueba en staging con pagos de prueba y captura de correo. No elimines registros contables reales para limpiar la lista de pedidos en producción. Para eliminar deliberadamente pruebas anteriores al lanzamiento, utiliza la página de ayuda de Delete Orders y conserva los registros necesarios.

Envía correos de estado y seguimiento útiles

Elige notificaciones para eventos significativos, como pago confirmado, un retraso importante, pedido listo para recoger o expedición. Un mensaje de envío debe contener los datos correctos de seguimiento; uno de recogida debe indicar ubicación, horarios e identificación necesaria.

1. Activa la notificación del estado previsto y selecciona su plantilla para el idioma del cliente.
2. Comprueba el tipo de correo configurado. Los archivos HTML y TXT emparejados permiten entrega en formato doble; los requisitos dependen de la configuración de correo.
3. Comprueba la resolución de plantillas mediante el tema de correo/tema activo y cualquier sustitución de módulo. Los archivos raíz de mails/ no son la única ubicación posible de plantillas.
4. Usa las variables proporcionadas por esa ruta de notificación. Prueba el nombre de cliente, referencia de pedido, enlaces, seguimiento y adjuntos renderizados en lugar de suponer que están disponibles todos los marcadores.
5. Haz un pedido en preproducción, aplica la transición e inspecciona el correo capturado y los registros de aplicación/servidor de correo. Un evento enviado no demuestra la entrega en bandeja de entrada.

Diseño > Tema de correo electrónico gestiona el diseño de correos en versiones modernas compatibles. Mantén coherentes las traducciones y plantillas generadas al personalizarlo.

Introduce el número de seguimiento y la URL correcta del transportista antes de enviar una notificación de expedición. Guardar el seguimiento y pasar un pedido a Enviado son acciones separadas en el núcleo, y una integración puede enviar su propio correo de seguimiento. Comprueba los mensajes duplicados. Imprimir una etiqueta no demuestra que el paquete haya salido del almacén.

La acción nativa de reenvío del historial del pedido reenvía un correo de estado. Es independiente de la confirmación original order_conf con el resumen del pedido. Para ese proceso específico de reenvío, utiliza la página de ayuda de Resend Order Confirmation.

Automatiza solo eventos que puedas verificar

Define el evento y su fuente autorizada antes de automatizarlo. Una llamada de retorno del proveedor de pago debe autenticarse y corresponder al pedido e importe correctos. Una transferencia bancaria necesita un resultado real de conciliación. Un evento de entrega del transportista es distinto de crear una etiqueta o introducir un número de seguimiento.

Posibles requisitos personalizados incluyen comprobar stock tras el pago, retener pedidos de alto valor para revisión, marcar un pedido totalmente embalado como listo para entregar al transportista o cancelar uno no pagado tras un plazo definido. Necesitan una integración adecuada y pruebas explícitas; añadir una extensión de flujo no implementa automáticamente todas las condiciones.

Para vincular los cambios de estado nativo o las actualizaciones del número de seguimiento con los estados del flujo interno, utiliza la página de ayuda de Advanced Order Fulfilment; los estados internos son independientes de los estados nativos del pedido y no ofrecen condiciones arbitrarias de pago, importe, stock o antigüedad de impago. Sus equipos, transiciones permitidas, permisos por rol y recordatorios organizan la responsabilidad interna; acuerda desde qué cola trabaja cada equipo antes de activar la automatización.

Para las transferencias bancarias, Bank Transfer Revolution importa extractos CAMT.053, MT940 o CSV y vincula los abonos que cumplen los criterios con los pedidos elegibles. Las entradas dudosas quedan pendientes de revisión. Ensaya un cobro parcial y una referencia sin correspondencia antes de permitir que los cobros vinculados marquen pedidos como pagados; aceptar una diferencia a la baja es una decisión distinta de registrar el dinero recibido.

Hooks de transición para desarrolladores

• actionOrderStatusUpdate se ejecuta durante la transición. Trátalo como un hook de notificación, no como un contrato general de veto.
• actionOrderStatusPostUpdate se ejecuta después de actualizar el estado del núcleo dentro de changeIdOrderState(). No garantiza la confirmación de la transacción.
• actionOrderHistoryAddAfter sigue a la inserción del registro de historial. En el flujo normal de setCurrentState(), el historial se añade después del método de actualización de estado.

Usa los servicios de pedido compatibles o la API de pedidos pertinente de tu versión en lugar de SQL directo. Para trabajo externo, pon en cola una tarea persistente con clave de idempotencia y política de reintentos. No supongas que el hook posterior a la actualización significa que todas las operaciones posteriores o correos se completaron. Gestiona llamadas de retorno duplicadas, fallos parciales y eventos desordenados.

Prueba que repetir una llamada de retorno de pago o una notificación de entrega no cree tareas duplicadas de preparación, pagos o mensajes. Genera alertas de fallos en lugar de dejar que un pedido quede silenciosamente entre sistemas.

Gestiona envíos, documentos y referencias

En el modelo de pedidos establecido, la etiqueta Enviado parcialmente no registra qué líneas se incluyeron en cada paquete. Para envíos divididos ocasionales, registra los artículos enviados y el seguimiento de cada envío, explica qué queda pendiente y marca la finalización solo cuando corresponda. Si un pedido contiene una taza disponible y una funda pendiente de reposición, registra la taza con su paquete y deja la funda expresamente pendiente. Si tu tienda instalada no dispone de registros por paquete, anota los artículos, las cantidades y el seguimiento de cada envío en las notas privadas del pedido o en tu sistema de almacén, y conserva los datos del primer envío cuando salga el segundo paquete; sobrescribir el campo de seguimiento original hace que se pierda la distinción. Comprueba que el documento de embalaje de cada paquete incluya solo su contenido: un albarán del pedido completo puede incluir artículos todavía pendientes.

PrestaShop 9.1 introdujo una función de envíos bajo un indicador experimental. Comprueba la versión instalada, las funciones activadas y la integración de transporte antes de suponer tanto las limitaciones antiguas como un soporte completo de envíos. Prueba líneas por paquete, seguimiento, documentos y compatibilidad del módulo de pago al adoptar otro flujo de envíos. Consulta los cambios de envíos de 9.1.

Los números de factura y las referencias de pedido visibles al cliente son identificadores distintos. El núcleo proporciona numeración secuencial de facturas. La referencia de pedido predeterminada recurre a nueve letras mayúsculas, sujeta a hooks o módulos de generación de referencias. Una referencia como ORD-2026-00142 es un formato personalizado, no el generador aleatorio estándar.

Elige los procedimientos de numeración y corrección según tus requisitos contables. Una extensión de formato no puede garantizar el cumplimiento en todas las jurisdicciones. Para conocer las opciones de formato, utiliza la página de ayuda de Custom Invoice Numbering o la página de ayuda de Custom Order Numbering.

Al exportar pedidos o facturas, define la base de fecha, los estados incluidos, los importes de impuestos, los reembolsos y la codificación, y concilia después los totales con el periodo contable. Consulta la guía de contabilidad y facturas.

Corrige deliberadamente un pedido realizado

Abre el pedido individual en Pedidos > Pedidos. Comprueba primero permisos del empleado, pago, preparación y entrega, reembolsos y documentos. No hay una casilla universal de estado editable. La edición nativa de precios de línea existía antes de 1.7.6, y las operaciones exactas disponibles y comprobaciones del ciclo de vida varían según la versión.

Para cambiar una talla de M a L, una combinación es una variante de producto distinta con su propio stock y referencia. Si no existe cambio directo, elimina la línea antigua, añade la combinación correcta y concilia stock, precios y pagos. No supongas que una extensión de edición proporciona una única operación de sustitución.

La edición del núcleo puede actualizar importes de facturas existentes y cambiar un PDF regenerado después. La existencia de una factura no es un bloqueo técnico universal de edición. Determina el procedimiento legal de abono o corrección antes de cambiar un documento emitido y conserva los registros originales obligatorios. Un historial de pedido entregado puede imponer límites nativos más estrictos de edición de productos.

Para los cambios de pedido compatibles, utiliza la página de ayuda de Order Editor; revisa la vista previa de la operación y sus efectos sobre el stock, los impuestos, los descuentos, los pagos y las facturas antes de confirmar. Activa solo los tipos de operación que necesite el personal, exige un motivo para las correcciones y conserva el historial que muestra los valores originales y modificados.

1. Registra el cambio solicitado por el cliente y los importes actuales del pedido.
2. Para corregir una dirección o cantidad antes del envío cuando esté permitido, utiliza la edición compatible. Si la cesta cambia sustancialmente, compara la edición con la cancelación y un nuevo pedido, teniendo en cuenta el stock, cualquier reembolso y las correcciones de documentos emitidos, y gestiona los productos ya enviados mediante el proceso de devolución o sustitución. No eludas las restricciones del estado Entregado cambiando la etiqueta del pedido.
3. Aplica la operación compatible y compara cantidades de productos, stock disponible, registros fiscales, descuentos, envío y totales de facturas.
4. Cobra o reembolsa la diferencia mediante la vía de pago adecuada y registra después la transacción.
5. Explica al cliente exactamente qué cambió, el nuevo total y las consecuencias de pago o reembolso. Proporciona los documentos corregidos o la confirmación correspondientes.

Limita las correcciones habituales de dirección del cliente

Order Address Change: Customer Self-Service permite a los clientes que han iniciado sesión seleccionar otra dirección de su propia libreta dentro de las restricciones configuradas de estado, tiempo y transportista. Los productos, el pago, el transportista, los precios, los impuestos, los gastos de envío y los totales no cambian. Las facturas emitidas bloquean ambas direcciones registradas; el seguimiento o el avance del envío impiden cambios de entrega, y los pedidos divididos o con varios envíos quedan fuera de este proceso.

Prueba los controles del cliente en el tema activo. Un cambio de destino que requiera otro tratamiento fiscal, transportista o precio de entrega debe gestionarlo el personal, que deberá evaluar esos efectos en lugar de utilizar el autoservicio para recalcular la venta.

Ensaya una corrección antes del embalaje

Un cliente solicita un accesorio adicional a juego después de pagar, cuando el pedido todavía admite edición. Detén la preparación, registra las cantidades y el total originales, añade el producto correcto mediante el editor compatible y compara después el stock, los descuentos, los impuestos y el total revisado. Cobra y registra la diferencia por el canal de pago antes de liberar el pedido según las condiciones acordadas. Confirma que el almacén recibe el contenido revisado y que el cliente recibe la actualización y los documentos correspondientes.

Para pedidos parcialmente enviados, conserva lo expedido y gestiona explícitamente los artículos restantes o las devoluciones. Cancelar por sí solo no revierte dinero ni documentos. Una mejor información de tallas, comprobaciones de dirección y una revisión clara durante la compra pueden reducir futuras solicitudes de corrección.

Prueba y revisa el flujo de trabajo

Crea una referencia breve para el personal: significado del estado, responsable, condición de entrada, notificación y siguiente acción. Mantén una lista lo bastante pequeña para usarla de forma coherente sin imponer un número fijo de estados.

En preproducción, prueba cada método de pago, la preparación normal, los fallos de pago antes y después de crear el pedido, cancelación, restablecimiento, reembolso parcial, reposición de stock, cambios de dirección y edición de líneas. Captura el historial de estados, correos, pagos, stock y documentos antes y después de cada operación.

Detecta fallos antes de procesar el siguiente lote

Planifica el cambio y el traspaso al personal

1. Enumera todas las integraciones que leen o escriben estados, incluidas las tareas programadas. Registra los ID reales de los estados y sus correspondencias, además de sus nombres traducidos.
2. Acuerda cómo terminarán su proceso actual los pedidos que ya estén pendientes de pago, retenidos, parcialmente enviados o en proceso de reembolso.
3. Conserva un registro recuperable de la configuración y una copia de seguridad con un procedimiento de recuperación probado. Programa el cambio en función de la actividad del almacén e identifica a la persona que puede detener el procesamiento.
4. Aplica los ajustes ensayados, comprueba pedidos reales representativos y supervisa las siguientes ejecuciones de integraciones y envíos. Si reviertes un ajuste, concilia los efectos ya producidos: los correos enviados, los movimientos de stock, los documentos emitidos y las tareas externas no desaparecen.

Qué preguntar a tu desarrollador o agencia

• ¿Qué tienda, versiones de módulos, tema y correspondencias de integración se probaron exactamente y dónde están las pruebas?
• ¿Qué sistema controla cada decisión de pago, retención, envío y entrega, y quién gestiona las excepciones?
• ¿Cómo llegan al almacén los reintentos, los fallos parciales y las correcciones sin duplicar trabajo ni utilizar datos obsoletos?
• ¿Qué operaciones puede realizar cada empleado y dónde se guardan los motivos y los registros anteriores y posteriores al cambio?
• ¿Qué ocurre con los pedidos abiertos durante el cambio y qué efectos hay que conciliar si lo revertimos?

Utiliza los resultados para actualizar la referencia del personal antes de que el nuevo proceso se convierta en habitual.

Usa las marcas de tiempo del historial para calcular el tiempo hasta la expedición, el tiempo de espera de stock y las cancelaciones por etapa. Define cómo cuentan los estados repetidos y pedidos reabiertos. Una distribución de estados muestra una cola; no explica por sí sola su causa.

Revisa periódicamente las transiciones fallidas, el seguimiento ausente, las discrepancias de documentos y las preguntas de clientes. Ajusta conjuntamente el proceso y la integración para que el estado del pedido siga siendo una descripción útil del trabajo real.

Preguntas de los propietarios de tiendas

¿Debo renombrar un estado o crear uno nuevo?

Cambia el nombre cuando el significado y el comportamiento sigan siendo los mismos, comprobando todos los idiomas de la tienda y las integraciones que comparan nombres. Si cambia el significado, evalúa primero un estado independiente para que las entradas históricas no resulten engañosas. Conserva un registro de los nombres y las correspondencias originales.

¿Puedo eliminar los estados antiguos cuando esté listo el reemplazo?

Comprueba primero los pedidos abiertos, el historial, los ajustes de los módulos de pago y las correspondencias de las integraciones. Impide nuevos usos mediante el proceso acordado y deja que termine el trabajo existente antes de plantearte eliminarlos; un estado ausente de la cola de hoy puede seguir referenciado en otro lugar.

¿Quién debería poder corregir pedidos?

Asigna al personal cuentas individuales y permisos para su trabajo. Mantén los cambios de precio, el registro de pagos, los reembolsos y las correcciones habituales de dirección dentro de los roles acordados, y comprueba que los usuarios restringidos no puedan realizar esas operaciones. El nombre de un estado no es una política de control de acceso.