El pedido 88214 se facturó dos veces. Misma cantidad, mismo cliente, misma fecha — dos documentos. Nadie lo digitó dos veces, nadie se equivocó de pantalla. La integración con el transportista respondió dos veces, y el sistema creyó en las dos.

Es el defecto más molesto de la operación de distribución, porque no rompe nada. El proceso sigue, el camión sale, la factura se emite. El error aparece después — en la conciliación, en el stock negativo, o en la llamada del cliente preguntando por qué le cobraron el doble.

Por qué el mensaje llega dos veces

No es un defecto exótico. Es el comportamiento normal de cualquier transporte que no puede garantizar entrega exactamente una vez.

El tiempo límite que no es un final. El transportista manda la confirmación, su API tarda en responder, el tiempo límite se agota del lado de él. Reenvía. Pero el primero llegó y fue procesado — solo la respuesta se perdió en el camino.

El reintento automático. Toda cola seria reintenta ante un fallo. Si el fallo está en la respuesta y no en el procesamiento, el reintento se convierte en duplicado.

El reproceso manual. Alguien ve el mensaje en error, lo corrige y lo manda otra vez — sin saber que el original ya había pasado.

Los dos canales. La misma información llegando por archivo y por API, cada uno con su horario, porque la migración de uno al otro nunca se concluyó.

La solución tiene nombre y es más simple de lo que parece

Se llama clave de idempotencia: un identificador que el origen genera y repite en cada reenvío de la misma operación. Quien recibe guarda la clave, y cuando vuelve, responde «ya lo procesé» en lugar de procesarlo de nuevo.

La parte difícil no es el concepto. Es acordar con el socio cuál campo es la clave — y esa conversación casi nunca ocurre.

Una verificación que suele rendir al día siguiente, directo en la base:

-- misma entrega, mismo socio, mensajes distintos
SELECT a.docnum, b.docnum, a.mestyp, a.rcvprn,
       a.credat, a.cretim, b.credat, b.cretim
  FROM edidc AS a
  JOIN edidc AS b ON  b.mestyp = a.mestyp
                  AND b.rcvprn = a.rcvprn
                  AND b.docnum > a.docnum
 WHERE a.status = '53'
   AND b.status = '53'
   AND a.credat >= '20260801'
 ORDER BY a.credat, a.cretim;

El resultado casi nunca está vacío, y buena parte es legítima — el mismo tipo de mensaje para el mismo socio ocurre todo el tiempo. Lo que interesa son los pares con pocos segundos o minutos de diferencia, porque el duplicado por reintento tiene firma temporal: llega pegado.

Lo que sale mal, con nombre

Deduplicar por el campo equivocado. Usar el número de pedido como clave falla cuando el mismo pedido tiene, legítimamente, dos entregas parciales. La clave tiene que identificar la operación, no el documento de negocio.

Deduplicar solo en la ventana corta. Guardar las claves de las últimas dos horas resuelve el reintento inmediato y no resuelve el reproceso manual, que ocurre al día siguiente. La ventana tiene que cubrir el comportamiento humano, no solo el de la cola.

Tratarlo como error en lugar de estado. Un mensaje repetido no es un fallo — es lo esperado. Si cae en la cola de error, alguien lo va a reprocesar y va a crear la tercera copia.

Descubrirlo por el reclamo del cliente. Es el costo más alto y el más común. El duplicado existe desde hace semanas, ahí arrinconado, y la primera persona en notarlo está afuera.

Dónde la IA ayuda de verdad aquí

La deduplicación en sí es una regla determinística y debe seguir siéndolo — nadie quiere un modelo decidiendo si dos pedidos son el mismo. Pero tres partes caras del trabajo son lectura y comparación.

Encontrar los pares sospechosos en el histórico. Barrer meses de mensajes y proponer qué pares tienen firma de duplicado es comparación en volumen, con criterio observable.

Leer el layout del socio y señalar el candidato a clave. La documentación de integración es larga y la parte que interesa son dos campos. Es el mismo razonamiento que aplicamos al observar el ciclo bancario antes de automatizar.

Explicar por qué ese mensaje específico falló. Cruzar el error con el histórico del socio acorta la investigación.

Donde no entra: anular documento, reversar facturación y decidir qué hacer con la carga que ya salió. Esas tres siguen con gente.

El límite honesto

La idempotencia bien hecha elimina el duplicado técnico. No elimina el duplicado de negocio — el cliente que realmente pidió dos veces, el vendedor que cargó el mismo pedido en dos canales. Esos casos son idénticos a los ojos del sistema y distintos a los ojos de la operación, y ninguna regla automática los resuelve sola.

Y hay un límite de frontera: si el socio no genera una clave estable, usted no tiene qué guardar. Se puede sortear con una huella digital del contenido, pero es una aproximación — dos entregas legítimamente idénticas existen, y la aproximación va a bloquear una de ellas en algún momento.

Lo que cambia es dónde se encuentra el problema. Con el ciclo observado, el duplicado aparece en minutos, en el panel, antes de convertirse en factura. Sin eso, aparece en la conciliación del mes — o en el teléfono.

Si el punto de partida es entender lo que existe hoy antes de tocar nada, empiece por el diagnóstico de TI. Para el panorama del sector, vea TI para servicios y distribución. Y si el volumen de documentos que llegan es el dolor inmediato, el camino es leer el XML y contabilizar dentro de SAP.

Preguntas frecuentes