El mismo pedido aparece dos veces en el ERP. El equipo comprueba los productos, intenta determinar qué registro debe pasar a preparación y revisa si también se descontó el inventario por duplicado. Antes de corregir los registros, conviene aclarar si hubo dos compras o si una misma compra se procesó más de una vez.
Las integraciones deben funcionar incluso cuando la comunicación falla. Una respuesta puede retrasarse, una notificación puede llegar de nuevo y una tarea puede repetir un intento después de perder la conexión. La duplicación surge cuando cada recepción se interpreta como una operación nueva. Evitarla requiere identificar la compra original y controlar los efectos del procesamiento.
1. Distingue una compra repetida de un registro duplicado
Un cliente puede realizar dos compras legítimas con los mismos productos, dirección e importe. Rechazar un pedido porque sus datos se parecen a los de otro puede bloquear una venta real. La identificación debe partir de la referencia de la compra en el sistema de origen, junto con el canal de venta y la cuenta correspondiente.
Por ejemplo, el pedido externo 7842 pertenece a la cuenta LOJA-01 del CANAL-A. Otra cuenta podría tener un pedido con el mismo número. Una segunda compra del mismo cliente debe tener identidad propia aunque repita los artículos. Estos identificadores son ilustrativos; la estructura concreta depende de los sistemas conectados.
El equipo y el software necesitan compartir este criterio. El nombre del cliente ayuda a una persona a investigar, pero no sustituye la clave del pedido. Tampoco se debe utilizar el SKU como identidad de la compra: el mismo producto puede formar parte de numerosos pedidos independientes. Primero se define qué identifica la operación y después qué constituye una repetición.
2. Comprende cómo un reintento crea otro pedido
Imagina esta secuencia ilustrativa: a las 10:00:01, la integración solicita crear el pedido en el ERP. El ERP lo guarda, pero la conexión se interrumpe antes de entregar la respuesta. A las 10:00:02, la integración todavía desconoce el resultado y vuelve a intentarlo.
Si el destino interpreta la segunda solicitud como otra compra, se crean dos registros. Si reconoce la operación original, puede devolver la referencia del pedido ya creado. Un error observado por quien envía no demuestra, por tanto, que el destino no haya hecho nada.
Las notificaciones y las tareas programadas también pueden repetirse. Identifica si el segundo intento provino del canal, de una cola, de una intervención manual o de dos rutinas que trabajan sobre el mismo flujo. Desactivar todos los reintentos puede cambiar el problema de pedidos duplicados por el de pedidos que nunca llegan al destino.
3. Separa pedido, evento y acción ejecutada
Tres referencias distintas ayudan a reconstruir lo sucedido:
- Identidad del pedido: la compra dentro de su canal y cuenta de origen.
- Identidad del evento: una notificación concreta, cuando el proveedor facilita un identificador.
- Identidad de la acción: el efecto aplicado, como crear el pedido en el destino o registrar una transición de estado.
Recibir dos veces el mismo evento es diferente de recibir dos eventos distintos relacionados con un pedido. La integración debe reconocer ambas situaciones sin impedir cambios legítimos, como el paso de pago pendiente a pago confirmado.
Un control basado únicamente en el identificador de la notificación puede dejar pasar dos notificaciones diferentes que provocan la misma creación. Por el contrario, ignorar todo lo relacionado con un pedido conocido impide que avance su ciclo de vida. Define qué acción debe ocurrir una sola vez y qué actualizaciones posteriores siguen permitidas.
4. Diseña un procesamiento seguro para repeticiones
La idempotencia permite repetir una operación sin repetir indebidamente su efecto. Para crear pedidos, suele requerir una referencia estable de la operación, una relación entre el pedido externo y el registro interno, y protección frente a ejecuciones simultáneas.
Consultar si el pedido existe antes de guardarlo no siempre basta. Dos procesos pueden consultar al mismo tiempo y concluir que todavía no existe. La implementación debe garantizar la unicidad al escribir los datos y coordinar el registro del procesamiento con la modificación correspondiente, según la arquitectura utilizada.
Una transacción local no vuelve atómica la comunicación entre dos sistemas independientes. Si una llamada al ERP pierde su respuesta, hará falta consultar el resultado mediante una referencia fiable o utilizar la idempotencia del destino, cuando esté disponible. Crear una referencia nueva en cada reintento elimina precisamente la relación que permitiría reconocer la repetición.
5. Revisa los efectos sobre inventario y preparación
Corregir la lista de pedidos no garantiza que todos sus efectos estén corregidos. Comprueba qué provocó cada registro: reserva, descuento de inventario, generación de documentos, envío a preparación o actualización en otro sistema.
Define qué sistema controla el inventario y en qué etapa se produce cada movimiento. Si el ERP mantiene el saldo oficial, los demás componentes deben respetar ese diseño. Reservas, descuentos y liberaciones de disponibilidad necesitan reglas que impidan aplicar la misma transición otra vez por recibir una notificación repetida.
Una duplicación existente exige conciliación. Antes de cancelar un registro, determina cuál representa la compra válida y qué acciones se realizaron. Borrar un pedido o modificar existencias manualmente sin esa comprobación puede ocultar la causa y generar una nueva diferencia. Conserva un historial comprensible de la corrección y ten en cuenta el trabajo ya realizado por el equipo de preparación.
6. Investiga con referencias comparables
Reúne el canal y la cuenta de origen, la referencia externa, los identificadores creados en el destino, los horarios de los intentos, sus respuestas y las acciones ejecutadas. Incluye la zona horaria de cada registro: comparar horarios expresados en zonas distintas puede llevar a interpretar mal la secuencia.
Contrasta las evidencias de ambos sistemas. Un mensaje de error aislado no demuestra si el ERP creó el pedido, y un registro en el ERP no explica por sí solo por qué hubo otro intento. Anota también si alguien solicitó un reprocesamiento manual mientras la rutina automática seguía intentando completar la operación.
Comparte solo los datos necesarios para el análisis. El soporte suele necesitar identificadores y contexto, no contraseñas, claves de API ni copias completas de los datos de clientes. Un registro organizado del incidente aporta más que capturas que no pueden relacionarse con una misma compra.
7. Prueba los reintentos y los fallos antes de activar el flujo
Una compra que recorre correctamente el camino normal no verifica la protección frente a duplicados. En un entorno de pruebas, incluye al menos estos escenarios:
| Situación | Resultado que debe comprobarse |
|---|---|
| Se envía otra vez la misma solicitud | Existe un solo pedido en el destino |
| Dos intentos se ejecutan simultáneamente | No se crea un segundo registro |
| El destino guarda el pedido, pero se pierde la respuesta | El siguiente intento reconoce el resultado anterior |
| Los eventos relacionados llegan fuera de orden | El estado final sigue siendo coherente |
| La misma referencia llega con datos incompatibles | Se identifica el conflicto sin sobrescribir silenciosamente |
| El cliente realiza otra compra legítima | El nuevo pedido se acepta con normalidad |
Comprueba también que un reprocesamiento autorizado repita únicamente la etapa pendiente. Un botón de reintentar no debería ejecutar de nuevo todo lo que ya terminó. Revisa el pedido de destino y sus efectos sobre el inventario, no solo el mensaje de éxito de la tarea.
8. Convierte la recuperación en un proceso controlado
Después de corregir el flujo, mantén visibles los fallos pendientes y los reintentos. El equipo debe distinguir entre pedidos pendientes de envío, en procesamiento, completados o en análisis, y saber quién puede autorizar un nuevo intento cuando el resultado no está claro.
Documenta cómo se identifica la compra, qué sistema controla las existencias y cómo se realiza la conciliación. Una integración fiable permite seguir trabajando durante fallos de comunicación, con trazabilidad y sin depender de descubrir duplicados cuando la preparación ya comenzó.
Si tu tienda afronta este tipo de trabajo manual, AGTI puede evaluar el flujo entre los sistemas y ayudar a localizar los controles que faltan. Conoce los servicios de AGTI.
Referencias técnicas
- Reintentos seguros con API idempotentes — AWS Builders’ Library.
- Comportamiento de webhooks y eventos duplicados — documentación de Stripe.
- Solicitudes idempotentes — referencia de la API de Stripe.
Fuentes verificadas el 19 de octubre de 2026. Los identificadores y los escenarios operativos son ilustrativos. La implementación depende de los contratos de las API y de las reglas de cada negocio.