En resumen
- Webhooks y reintentos repiten mensajes, y la integración tiene que estar diseñada contando con ello.
- Usa un identificador estable del pedido en origen y guárdalo en el ERP para reconocer las repeticiones.
- Separa los estados (recibido, enviado, confirmado, error) y, antes de reintentar, comprueba qué pasó con el envío anterior.
- Limita los reintentos y manda los fallos a una cola de incidencias con alertas que digan qué pedido falla y qué hacer.
Pocos problemas generan tanta desconfianza en una integración como los pedidos duplicados en el ERP. El cliente compra una vez y en el ERP aparecen dos pedidos, dos albaranes o, peor, dos facturas. Almacén prepara mercancía de más, contabilidad tiene que anular documentos y nadie sabe exactamente cuándo empezó. Rara vez se trata de un fallo puntual. Lo normal es que la integración se diseñara dando por hecho que cada mensaje llega una sola vez.
Por qué aparecen pedidos duplicados en el ERP
Las conexiones entre sistemas fallan, y no siempre de la forma que esperas. Estos son los escenarios más habituales:
- Webhooks repetidos. Muchas plataformas reenvían la notificación si no reciben una respuesta correcta a tiempo, de modo que si tu endpoint tarda demasiado puede recibir otra vez un pedido que ya había procesado.
- Timeouts ambiguos: la integración envía el pedido, el ERP lo crea y la respuesta se pierde por el camino. Desde la tienda parece un error y se reintenta.
- Procesos reiniciados. Una tarea programada se corta a mitad de lote y, al relanzarse, vuelve a procesar pedidos que ya había enviado.
- Reprocesos manuales, cuando alguien pulsa "reenviar" en un panel sin saber que el pedido ya estaba en el ERP.
Pongamos una tienda que sincroniza pedidos cada cinco minutos. Un día el ERP va lento, la petición supera el tiempo de espera y la integración marca el pedido como fallido. En la siguiente ejecución lo vuelve a enviar, y el ERP, que sí lo había creado, crea otro. Ningún sistema se ha caído; simplemente nadie decidió qué hacer cuando la respuesta no llega.
Un identificador estable para reconocer repeticiones
La base para evitar duplicados es la idempotencia: repetir una operación tiene que producir el mismo efecto que hacerla una vez. Para conseguirlo necesitas una referencia estable del pedido en origen que viaje con cada mensaje y que el destino sepa reconocer.
Cómo elegir esa referencia
- Usa el identificador interno del pedido en la tienda. El número visible solo sirve si nunca cambia ni se reinicia.
- Si hay varias tiendas o canales, combina canal e identificador para que sea único en todo el sistema.
- Guárdalo en un campo del ERP que se pueda consultar, ya sea una referencia externa, un campo personalizado o una tabla de correspondencias, según lo que permita tu ERP.
- Descarta combinaciones como nombre del cliente, fecha e importe, porque dos pedidos legítimos pueden coincidir.
Con esa referencia, la lógica es sencilla. Antes de crear, consulta si el pedido ya existe; si existe, actualiza o devuelve "ya procesado", y si no, créalo. Si el ERP permite imponer unicidad sobre ese campo, mejor todavía, porque el propio sistema rechazará el duplicado aunque falle la consulta previa.
Es uno de los puntos que más revisamos en cualquier proyecto de integración ERP y ecommerce. Diseñarlo al principio cuesta poco y corregirlo después cuesta mucho.
Estados de la operación, de recibido a confirmado
Entre "sincronizado" y "no sincronizado" hay varios estados, y cada uno pide una acción distinta:
- Recibido: la integración tiene el pedido, pero todavía no lo ha validado.
- Validado: los productos existen, el cliente está identificado y los importes cuadran.
- Enviado: la petición al ERP ha salido, pero aún no hay confirmación.
- Confirmado: el ERP ha devuelto su referencia y se ha guardado.
- Rechazado: el ERP o la validación han detectado un problema que no se arregla reintentando.
El estado delicado es "enviado". Si hay un error después de enviar, el reintento tiene que preguntar primero al ERP si el pedido existe y crearlo solo si no está. Así se cierra el hueco de los timeouts ambiguos.
Cancelaciones y modificaciones
Los duplicados también aparecen después de crear el pedido. Si se modifica o cancela uno que ya estaba importado, la integración debe localizarlo por la misma referencia y actualizar el documento existente en vez de generar uno nuevo. Decide desde el principio qué cambios se propagan al ERP y cuáles necesitan intervención manual.
Reintentos con límites y alertas
Hay que reintentar, pero con control. Si el ERP está caído y la integración reintenta sin pausa, satura un sistema que ya tenía problemas. Un esquema razonable incluye:
- Intervalos crecientes entre intentos (por ejemplo, al minuto, a los cinco y a los treinta).
- Un número máximo de reintentos, tras el cual el pedido pasa a una cola de incidencias.
- Separar los errores transitorios (timeout, servicio no disponible) de los definitivos (producto inexistente, datos inválidos), que no se reintentan.
- Alertas que digan qué pedido es, qué paso falló, el mensaje de error y qué puede hacer el equipo sin riesgo.
Una alerta que solo dice "error en la sincronización" obliga a investigar desde cero. Con "pedido 1234 enviado al ERP sin respuesta; comprobar si existe antes de reenviar", el equipo lo resuelve en minutos. Si quieres ir más lejos, la automatización de pedidos con excepciones visibles convierte esa cola en un panel que el equipo revisa a diario.
Pruebas que destapan duplicados antes de producción
Una demo con un pedido perfecto no te dice nada sobre duplicados. Antes de dar por buena una integración, provoca los fallos a propósito:
- Simula una respuesta lenta del ERP que supere el timeout y comprueba que el pedido no se crea dos veces.
- Envía el mismo webhook dos veces seguidas.
- Corta la conexión justo después de que el ERP cree el pedido.
- Envía un pedido con un artículo que no existe en el ERP.
- Provoca un error de autenticación y verifica que no se pierde ningún pedido.
- Haz llegar eventos desordenados, con una cancelación antes que la creación.
- Cancela un pedido después de haberlo importado.
Cada caso tiene que acabar en un estado explícito y trazable, sin documentos duplicados ni pedidos perdidos. Si tu tienda está en Shopify, estas pruebas forman parte de cualquier proyecto de integraciones Shopify bien planteado, porque los webhooks de la plataforma pueden repetirse.
Qué exigir al proveedor de la integración
Tanto si la desarrollas internamente como si la encargas, pide como mínimo:
- Poder consultar, pedido a pedido, qué se envió, cuándo y qué respondió el ERP.
- Una política de reintentos documentada: cuántos, cada cuánto y qué errores quedan fuera.
- Un procedimiento para reprocesar un pedido sin duplicarlo.
- La referencia cruzada, con el identificador de origen guardado en el ERP y viceversa.
- Pruebas de que se han ensayado los escenarios de fallo anteriores.
Si ya tienes duplicados en producción, averigua dónde se rompe la idempotencia antes de poner parches. Una auditoría técnica ecommerce de la integración suele localizarlo revisando logs, estados y el punto exacto en que se pierde la referencia.
Checklist rápida
- Cada pedido tiene una referencia estable que viaja en todos los mensajes.
- El ERP guarda esa referencia y se puede consultar antes de crear.
- Los estados intermedios están separados y el reintento comprueba antes de crear.
- Los reintentos tienen límite, intervalo y distinción de errores.
- Las alertas indican pedido, paso y acción recomendada.
- Se han probado timeouts, repeticiones, cancelaciones y eventos desordenados.
