En este artículo
Odoo y n8n: crear pedidos sin duplicarlos al reintentar
Supón que Odoo guarda el pedido, pero la respuesta nunca llega a n8n. Una persona ve una ejecución fallida y pulsa reintentar. El diseño de recuperación decide ahora si esa compra termina en un pedido o en dos.
Para reintentar la creación de pedidos en Odoo, asigna una identidad persistente a la operación prevista, haz que el destino la respete al escribir y comprueba el resultado cuando la respuesta sea incierta. Conserva la misma identidad y los mismos datos en cada intento. Envía a revisión los cambios de contenido o los resultados sin resolver.
La idempotencia significa que repetir una operación deja el mismo resultado de negocio previsto. Esa propiedad debe estar implementada en la operación; una opción de reintento no la proporciona por sí sola.
Investigación revisada: 5 de noviembre de 2026. Las características del producto proceden de fuentes oficiales de Odoo 20 y n8n. Ejecutamos diez casos sintéticos en Python/SQLite, incluida una respuesta descartada deliberadamente después de un commit local. No ejecutamos Odoo, n8n ni PostgreSQL, no interrumpimos una red real y no medimos una integración de cliente.
¿Por qué una ejecución fallida de n8n puede dejar un registro en Odoo?
Una ejecución fallida de n8n puede dejar un registro en Odoo porque el destino termina de escribir antes de que el solicitante reciba la respuesta. Trata una respuesta perdida como un resultado desconocido hasta aclararlo con evidencia. El indicador de error describe la ejecución observada; no demuestra que se hayan revertido todos sus efectos anteriores.
En el ejemplo, la tienda solicita un pedido para la empresa A con referencia de origen SO-77 e importe de 125,00 €. El destino crea el registro y después se pierde la respuesta. Repetir una solicitud normal de creación puede generar otro registro para la misma compra. El segundo intento puede aparecer como correcto aunque ya exista un duplicado.
La documentación de n8n sobre Retry On Fail explica los reintentos automáticos y la espera entre intentos. Esos controles determinan cuándo volver a intentar. La operación receptora debe definir qué significa repetir la acción.
También importa el fallo contrario. Imagina que el flujo marca la operación como procesada antes de crear el pedido y se detiene entre ambos pasos. Al repetir, encuentra esa marca y omite el trabajo. No hay duplicado, pero tampoco hay pedido. Separa la recepción de la finalización y comprueba el registro de destino antes de cerrar el incidente.
¿Qué debe identificar una única creación de pedido en Odoo?
Identifica la creación prevista de un pedido en Odoo mediante una clave persistente de negocio, limitada a su origen y empresa propietaria. Conserva junto a ella los datos aprobados. Las identificaciones de entrega y ejecución describen intentos, no necesariamente la compra. Define cómo distinguir una revisión legítima de una repetición antes de activar reintentos automáticos.
Puedes partir del siguiente contrato. Son campos propuestos para la integración, no campos incorporados en Odoo ni una garantía de que reconozca una cabecera HTTP concreta.
| Campo | Ejemplo | Finalidad |
|---|---|---|
| Origen y empresa | shop, A | Separar los espacios de identificación de propietarios independientes. |
| Referencia de negocio en origen | SO-77 | Reconocer la compra entre entregas y repeticiones manuales. |
| Comando y revisión | create_draft_order, 1 | Distinguir esta creación de una modificación aprobada posterior o de otra acción. |
| Huella del contenido | Resumen de los campos de negocio acordados | Rechazar la reutilización de la clave con un contenido distinto. |
| Referencias de los intentos | ID de entrega del webhook e ID de ejecución de n8n | Seguir cada intento sin convertirlo en una compra nueva. |
| Evidencia en destino | ID del registro Odoo, empresa y estado aceptado | Identificar el registro que cumplió la operación. |
La guía de idempotencia de n8n indica que un reintento manual o una nueva activación recibe otro execution.id. Recomienda claves derivadas de los datos de entrada para mantener continuidad entre ejecuciones. Guarda la identidad de negocio de forma persistente antes de depender de ella para recuperar el flujo.
Define qué campos incluye la huella. Un cambio de importe o moneda no debe quedar oculto detrás del mismo número de pedido. Excluye los metadatos de entrega que puedan cambiar en cada intento. Normaliza solo según el contrato acordado: quitar ceros iniciales de un identificador de cliente puede cambiar su significado.
En el modelo, repetir los 125,00 € devuelve el registro original. Reutilizar la clave con 130,00 € genera un conflicto de contenido y conserva el importe anterior. Una persona responsable debe decidir si la nueva entrada es una corrección, una revisión aprobada o un defecto del origen.
¿Dónde debe aplicarse la protección contra duplicados?
Aplica la protección contra duplicados donde se confirma la escritura del registro de negocio. La operación receptora debe reservar la clave y guardar su resultado de forma consistente con esa escritura. Una tabla separada en n8n puede coordinar intentos, pero no convierte por sí sola una escritura posterior en Odoo en parte de la misma transacción.
La documentación de transacciones JSON-2 establece que las llamadas usan transacciones separadas y que los pasos que requieren una sola deben ejecutarse mediante un método del servidor. La guía de arquitectura de la API de Odoo cubre las restricciones de alojamiento y protocolo que condicionan la implementación.
Un método receptor propio podría comprobar al solicitante actual, consultar el registro de operación, crear el registro permitido cuando corresponda y guardar el resultado en una transacción. También debe resolver solicitudes simultáneas. Buscar SO-77 antes de crearlo deja una carrera: dos procesos pueden consultar antes de que cualquiera escriba.
La referencia del nodo Odoo de n8n enumera operaciones CRUD de Custom Resource. Esa lista no demuestra que crear un registro cumpla tu contrato de operación. Comprueba el nodo instalado y el método receptor. Enviar Idempotency-Key solo ayuda cuando el receptor lo implementa.
Si no puedes implementar o verificar un contrato en destino, documenta el alcance menor de la garantía. La ejecución serializada y las consultas al destino pueden reducir incertidumbre, siempre que participen todos los caminos de escritura y repetición. Investiga el caso si no puedes distinguir entre «no se creó» y «se creó, pero aún no se ha encontrado».
Los efectos externos requieren sus propios límites. Un registro de operación guardado con el pedido no demuestra que un correo posterior se enviara una sola vez. La guía de recuperación de envíos de correo duplicados trata esa operación por separado. No incluyas tácitamente el envío o el pago en una garantía sobre la creación del pedido.
¿Qué mostraron los diez casos locales de fallo?
Los diez casos locales mostraron que evitar duplicados y recuperar trabajo pendiente requieren evidencias distintas. El modelo reprodujo registros duplicados y trabajo perdido, y después recuperó el registro original mediante una operación atómica en destino. Todas las observaciones coincidieron con lo esperado. Los resultados describen nuestro modelo Python/SQLite, incluidos sus bloqueos, y no validan Odoo ni n8n.
El modelo tiene una tabla de pedidos y otra de operaciones dentro de una misma base SQLite. El camino correcto escribe ambas en una transacción. Un punto de fallo descarta la respuesta después del commit; otro detiene el proceso antes. El caso concurrente inicia dos trabajadores locales. La búsqueda insegura usa una secuencia documentada de lecturas y escrituras intercaladas.
| Caso | Observación esperada | Observado |
|---|---|---|
| Reintento ciego después del primer commit | Dos registros para una creación prevista | 2 registros |
| Marca de procesado guardada antes del efecto, seguida de interrupción | La repetición omite el trabajo pendiente | 0 registros |
| Dos búsquedas terminan antes de la primera creación sin protección | Ambos intentos crean un registro | 2 registros |
| Registro atómico de operación en destino; respuesta perdida tras commit | La repetición devuelve el borrador original | 1 registro; mismo ID |
| Misma clave de operación, importe modificado | Conflicto; el registro original no cambia | Conflicto; se mantienen 125,00 € |
| Misma referencia de origen en empresas A y B autorizadas por separado | Un registro independiente por empresa | 2 registros en espacios separados |
| Repetición tras retirar la autorización para A | La autorización actual bloquea el acceso | Denegado |
| Fallo antes del commit de la transacción atómica | Ningún registro confirmado; el reintento crea uno | 0 antes; 1 después |
| Dos solicitudes simultáneas al destino protegido del modelo | Ambas resuelven al mismo registro | 1 registro; mismo ID |
| Existe registro local de operación, pero la consulta al destino no es concluyente | Se mantiene el resultado desconocido | unknown |
Descarga el modelo ejecutable de reintentos y los resultados registrados del modelo. Guarda el archivo Python y ejecútalo localmente:
python3 retry-model.pyEl script utiliza bases locales temporales y no accede a la red. No es un módulo Odoo. Su estado draft es un campo propio del modelo: la ejecución no creó presupuestos, no reservó existencias, no contabilizó asientos y no envió mensajes en Odoo. Úsalo para cuestionar el diseño y después prueba la operación receptora real.
¿Cómo debe recuperarse un resultado desconocido?
Recupera un resultado desconocido relacionando primero la operación prevista con evidencia del destino. Vuelve a comprobar la autorización actual y la revisión del contenido. Conserva la clave original durante la investigación. Si la consulta no permite establecer lo ocurrido, mantén UNKNOWN y asigna un responsable, en lugar de convertir la falta de evidencia en otra creación.
| Evidencia | Decisión | Siguiente acción |
|---|---|---|
| Un resultado coincidente con la empresa y el contenido aceptados | Creación completada | Guardar la referencia de destino y continuar solo con acciones posteriores autorizadas por separado. |
| Misma clave con distinto contenido de negocio | Conflicto | Revisar la modificación; no sobrescribir el resultado original durante la repetición. |
| Más de una coincidencia en destino | Incidente por duplicados | Detener nuevas escrituras e investigar los registros dependientes antes de corregir. |
| El solicitante actual ya no está autorizado | Bloqueado | Escalar al responsable aprobado sin reutilizar credenciales con privilegios superiores. |
| No hay un resultado concluyente en destino | Desconocido | Usar una operación receptora con repetibilidad verificada o investigar antes de volver a crear. |
«Creación completada» describe el resultado de la integración. No ordena confirmar un presupuesto ni contabilizar una factura. Separa el ciclo del registro de operación del estado del documento de negocio.
Un flujo de errores de n8n se configura para un flujo y comienza con Error Trigger. Úsalo para enviar la clave y la evidencia del destino al responsable de recuperación. La cola de reintentos necesita un límite y un estado sin resolver visible; una alerta por sí sola no repara la escritura.
Registra el alcance de la consulta. Buscar con la empresa equivocada o un rol más limitado puede ocultar una coincidencia existente. El operador necesita la referencia de origen, la identidad exacta del destino y evidencia obtenida con un contexto autorizado. La guía para verificar acciones autenticadas aborda el mismo problema de evidencia en acciones del navegador.
¿Qué evidencia de aceptación necesitan Odoo y n8n?
Acepta la integración de Odoo y n8n después de probar comandos repetidos con su configuración real e inspeccionar los registros resultantes. Incluye respuesta perdida tras escritura confirmada e intentos simultáneos, con usuarios autorizados y no autorizados. El resultado exigido es el registro previsto en su estado previsto, sin efectos adicionales no autorizados o inexplicados.
Utiliza los casos propuestos de aceptación de la integración real. Todos empiezan en NOT_RUN. Registra las versiones de Odoo y n8n, la revisión del módulo, los ajustes del nodo, las identidades de prueba, la entrada aprobada, la consulta de destino y el resultado observado. Una captura del flujo puede apoyar la evidencia, pero no sustituye el contraste de registros.
Prueba los caminos de recuperación que usará el equipo: reintento automático, repetición manual tras editar el flujo y recuperación después de reiniciar un proceso de trabajo. Añade un importe modificado bajo la clave anterior y otra empresa autorizada con la misma referencia de origen. Comprueba que una identidad revocada no acceda a información protegida por haber tenido éxito anteriormente.
En facturación, nombra el estado esperado. La documentación de facturas de Odoo distingue la creación en Draft de la confirmación a Posted, que genera el asiento. Recibir un ID de factura no prueba su contabilización ni la aprobación contable. Prueba la confirmación posterior como un comando autorizado independiente.
Haz el ensayo en un entorno aislado con servicios externos controlados. Los casos de correo o pago duplicado requieren un sustituto seguro del destinatario real. Finanzas y operaciones deben aprobar sus respectivos resultados; la afirmación del desarrollador de que el nodo terminó correctamente no basta para decidirlos.
¿Cuándo conviene mantener desactivados los reintentos automáticos?
Mantén desactivados los reintentos automáticos de escrituras inciertas hasta verificar el contrato de repetibilidad del receptor y disponer de un responsable que concilie su resultado. Las lecturas o comandos expresamente repetibles pueden tener otra política limitada. Cambia la decisión cuando la integración real supere los fallos relevantes, con evidencia de trabajo completado y operaciones denegadas.
Empezaríamos con un comando de creación de pedido y su registro de aceptación. Añadiríamos confirmación o envío después de especificar su recuperación por separado. Acuerda los registros esperados durante el proceso de descubrimiento y definición de requisitos, incluido quién atiende un resultado desconocido fuera del horario habitual.
El servicio de integración de API de Wavect permite encargar esta lógica de transferencia de registros. Lleva una ejecución fallida y la evidencia de su destino. El primer entregable útil es un caso de recuperación reproducible con una decisión clara sobre la puesta en producción.