--- title: "Una importación repetida no debe duplicar recordatorios: probar los duplicados" canonical: https://www.billabex.com/es/blog/importacion-repetida-no-debe-duplicar-recordatorios-probar-duplicados/ lang: es alternate: https://www.billabex.com/fr/blog/import-rejoue-doublons-relances.md alternates: fr: https://www.billabex.com/fr/blog/import-rejoue-doublons-relances.md en: https://www.billabex.com/en/blog/replayed-import-duplicate-reminders.md es: https://www.billabex.com/es/blog/importacion-repetida-no-debe-duplicar-recordatorios-probar-duplicados.md updated: 2026-10-24 index: https://www.billabex.com/llms.txt --- # Una importación repetida no debe duplicar recordatorios: probar los duplicados La sincronización contable se interrumpe. El soporte propone repetir la última importación y después confirma que las facturas vuelven a ser visibles. Una hora más tarde, varios clientes reciben un segundo recordatorio idéntico. Sin embargo, el número de facturas no ha aumentado en la herramienta. Este incidente revela dos asuntos distintos: reconocer un dato ya recibido y reconocer una acción ya realizada. Un programa puede evitar los duplicados de expedientes y, aun así, repetir un mensaje. Para evaluar una integración de cobros, la prueba debe llegar, por tanto, hasta el resultado visible para el cliente, en un entorno previsto para los ensayos. ## Definir qué significa «repetir sin efecto adicional» Los equipos técnicos hablan de idempotencia cuando la repetición de la misma operación no añade un nuevo efecto de negocio. Este principio debe traducirse a su caso: una factura sigue siendo una sola factura, un pago no se cuenta dos veces y la misma decisión de recordatorio no produce varios envíos. AWS explica que dos solicitudes aparentemente idénticas pueden expresar, sin embargo, dos intenciones diferentes. Su biblioteca técnica recomienda hacer identificable la intención en lugar de deducir sistemáticamente el duplicado solo a partir del contenido. [AWS Builders' Library, reintentos y API idempotentes](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/). En el cobro de impagados, esto evita otro error: bloquear por equivocación un recordatorio legítimo más adelante porque su texto se parece a uno anterior. La prueba debe distinguir la repetición de la misma acción de una nueva acción autorizada en otra fecha. No exige que un cliente no vuelva a ser contactado nunca. ## Mantener la identidad estable más allá del nombre del archivo Cambiar el nombre de un archivo no crea facturas nuevas. Modificar el orden de las líneas tampoco. Para identificar un documento, el sistema debe encontrar su origen y su identificador en el alcance correspondiente, en particular la sociedad emisora. Una simple comparación del número visible puede confundir dos entidades. Odoo 18 documenta el uso de identificadores externos constantes para actualizar registros mediante importación. Advierte de que un identificador eliminado o modificado puede provocar una creación duplicada. Esta regla de importación ilustra la importancia de la identidad persistente, sin probar el comportamiento de otra integración. [Odoo 18, importación y actualización de datos](https://raw.githubusercontent.com/odoo/documentation/18.0/content/applications/essentials/export_import_data.rst). Prepare, por tanto, una versión idéntica del archivo, una versión con otro nombre y una versión con las líneas ordenadas de otra manera. El resultado esperado debe mantenerse estable. La distinción entre [número de factura y entidad jurídica](https://www.billabex.com/es/blog/dos-facturas-mismo-numero-verificar-entidad-antes-de-reclamar/) ayuda a elegir las referencias que hacen fiable esta verificación. ## Construir un caso en el que los totales no oculten el problema Tomemos una simulación con diez clientes y cuarenta facturas de 2.000 €, es decir, 80.000 € abiertos al principio. La importación se transmite tres veces. Eso representa 120 líneas procesadas a lo largo de las transmisiones, pero siguen siendo cuarenta facturas de negocio y diez clientes. Un saldo pendiente de 240.000 € revelaría una duplicación manifiesta. Verificar únicamente los 80.000 € no basta. El programa podría haber creado ochenta facturas adicionales y haberlas excluido después del total mostrado. Pida el número de documentos activos, sus referencias y los vínculos con las conversaciones. Una traza de importación repetida es normal; una segunda deuda por el mismo documento no lo es. Para una oleada de prueba distinta, elija seis de esos clientes, con dos facturas de 2.000 € cada uno, es decir, doce facturas y 24.000 €. La regla del ensayo prevé un mensaje agrupado por cliente para esa misma decisión: seis mensajes esperados, no doce. Esta agrupación es una hipótesis de prueba, no una regla universal de cadencia. Si la misma importación se repite tres veces y salen dieciocho mensajes para esa sola oleada, hay doce envíos de más. La multiplicación es de tres, aunque las facturas y el saldo sigan siendo correctos. El informe debe señalar la diferencia en el plano de las comunicaciones, no limitarse a declarar «importación sin duplicados». ## Probar la reanudación tras un resultado incierto El caso más instructivo se produce cuando el servicio ha realizado la operación, pero su confirmación no ha llegado al solicitante. Una reanudación puede entonces repetir una acción que ya se había completado con éxito. Pida una demostración controlada de esta situación con destinatarios de prueba y envíos aislados de producción. Stripe documenta reenvíos automáticos de eventos que pueden durar hasta tres días en modo real. También precisa que los eventos pueden llegar varias veces y en un orden distinto al de su generación. Estos comportamientos muestran por qué una integración debe prever las reanudaciones; no describen la cadencia de sus recordatorios. [Stripe, entrega de eventos y duplicados](https://docs.stripe.com/webhooks). El informe de la prueba debe distinguir entre intento, acción aceptada por el servicio de envío y resultado conocido. Si falta la confirmación, el sistema debe hacer visible la incertidumbre y resolverla antes de una repetición que pueda llegar al cliente. Una línea «error» no prueba que no se haya enviado nada. ## Verificar que un dato antiguo no reabre una factura pagada Retomemos a los seis clientes de la oleada simulada. Antes del envío, uno de ellos liquida sus dos facturas, es decir, 4.000 €. El pago se verifica y se asigna. El alcance a reclamar en esa oleada pasa a ser de cinco clientes, diez facturas y 20.000 €. Repita entonces la extracción antigua que aún mostraba 24.000 €. El expediente debe conservar el efecto del pago reciente o solicitar una resolución explícita del conflicto de datos. Una importación antigua no debe tomarse por una nueva prueba de impago. Repetir mecánicamente que «gana el último dato recibido» puede invertir la cronología de los hechos. Este escenario completa el asunto de las [facturas modificadas tras un recordatorio](https://www.billabex.com/es/blog/factura-modificada-tras-recordatorio-conservar-versiones-del-expediente/). En ambos casos, la fecha de recepción de una información y la fecha del evento que describe no son intercambiables. La prueba también debe observar los mensajes ya preparados antes de que llegara el pago. ## Incluir la nueva acción legítima en el control Una protección demasiado amplia puede suprimir el duplicado y también todos los recordatorios posteriores. Añada, por tanto, un escenario en el que, tras examinar el expediente, se decida realmente una nueva acción. Debe poder distinguirse de la repetición anterior, teniendo en cuenta los pagos, las respuestas y los acuerdos producidos desde entonces. AWS subraya también que el tiempo durante el cual se reconoce una solicitud depende del servicio y de su contrato. Pregunte hasta dónde se remonta una repetición admitida y qué ocurre más allá. Un ensayo satisfactorio a los cinco minutos no demuestra automáticamente el comportamiento pasados varios días. ## Pedir una prueba que finanzas pueda releer El entregable útil contiene los archivos utilizados, los importes esperados, los documentos encontrados y los mensajes efectivamente producidos. El [registro de recordatorios](https://www.billabex.com/es/blog/registro-de-recordatorios-que-trazas-pedir-antes-de-automatizar/) ayuda a reunir estos elementos sin confundir los pasos técnicos con una comunicación al cliente. Para evaluar su circuito, examine las [integraciones de Billabex](https://www.billabex.com/es/producto/integraciones/) con estos escenarios de reanudación. Pida que se precisen los resultados observables y los límites del conector en cuestión. Ningún eslogan sobre la fiabilidad sustituye la verificación de tres cosas: el mismo expediente, el saldo actual correcto y únicamente la acción realmente autorizada. ## Fuentes - AWS Builders' Library, Making retries safe with idempotent APIs. - Odoo 18, Export and import data, identificadores y reimportación. - Stripe, Receive Stripe events, entrega y duplicados. Fuentes consultadas el 7 de septiembre de 2026.