--- title: "Ripetere un’importazione senza duplicare i solleciti: verificare i doppioni" canonical: https://www.billabex.com/it/blog/importazione-ripetuta-evitare-solleciti-duplicati/ lang: it 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 de: https://www.billabex.com/de/blog/wiederholter-import-doppelte-mahnungen.md es: https://www.billabex.com/es/blog/importacion-repetida-no-debe-duplicar-recordatorios-probar-duplicados.md it: https://www.billabex.com/it/blog/importazione-ripetuta-evitare-solleciti-duplicati.md nl: https://www.billabex.com/nl/blog/import-herhalen-dubbele-herinneringen-voorkomen.md pl: https://www.billabex.com/pl/blog/ponowny-import-unikaj-podwojnych-przypomnien.md pt: https://www.billabex.com/pt/blog/importacao-repetida-duplicados-lembretes.md updated: 2026-10-24 index: https://www.billabex.com/llms.txt --- # Ripetere un’importazione senza duplicare i solleciti: verificare i doppioni La sincronizzazione contabile si interrompe. L’assistenza propone di ripetere l’ultima importazione, poi conferma che le fatture sono nuovamente visibili. Un’ora dopo, diversi clienti ricevono un secondo sollecito identico. Eppure il numero di fatture nel software non è aumentato. Il ripristino sembra riuscito se osservi soltanto i dati, ma il cliente ha ricevuto una comunicazione aggiuntiva che nessuno intendeva inviare. Questo incidente mette in luce due questioni distinte: riconoscere un dato già ricevuto e riconoscere un’azione già eseguita. Un software può evitare pratiche duplicate e, nello stesso tempo, ripetere un messaggio. Per valutare un’integrazione per il recupero crediti, la prova deve quindi arrivare fino al risultato visibile dal cliente, in un ambiente predisposto per i test. Il controllo non termina quando ritrovi le fatture nella schermata. ## Definisci che cosa significa «ripetere senza effetti aggiuntivi» I team tecnici parlano di idempotenza quando ripetere la stessa operazione non aggiunge un nuovo effetto sul processo aziendale. Devi tradurre questo principio nel tuo caso: una fattura resta una sola fattura, un pagamento non viene conteggiato due volte e la stessa decisione di sollecito non produce più invii. Sono risultati distinti, da verificare uno per uno, perché un totale corretto non dimostra che anche le comunicazioni siano corrette. AWS spiega, nella Builders’ Library, che due richieste apparentemente identiche possono esprimere due intenzioni diverse. La sua biblioteca tecnica raccomanda di rendere identificabile l’intenzione, invece di dedurre sistematicamente un doppione dal solo contenuto. Questo riferimento metodologico aiuta a formulare la domanda da porre al fornitore: quale elemento distingue la ripetizione di un tentativo dalla decisione di avviare un’azione nuova? Nel recupero crediti, ciò evita un altro errore: bloccare in seguito un sollecito legittimo perché il suo testo assomiglia a quello di un messaggio precedente. La prova deve distinguere la ripresa della stessa azione da una nuova azione autorizzata in un’altra data. Non richiede che un cliente non venga mai più contattato. Richiede che ogni invio corrisponda a una decisione effettiva, leggibile nel contesto della pratica. ## Mantieni un’identità stabile oltre il nome del file Rinominare un file non crea nuove fatture. Nemmeno modificare l’ordine delle righe. Per identificare un documento, il sistema deve ritrovarne l’origine e l’identificativo nel perimetro pertinente, in particolare la società emittente. Confrontare soltanto il numero visibile può confondere due società. Anche un cliente condiviso tra più entità non rende intercambiabili le fatture emesse da ciascuna di esse. Odoo 18 documenta l’uso di identificativi esterni costanti per aggiornare i record tramite importazione. Avverte che eliminare o modificare un identificativo può provocare una creazione duplicata. Questa regola di importazione illustra l’importanza di un’identità persistente, senza dimostrare il comportamento di un’altra integrazione. La [documentazione Odoo 18 sull’importazione e sull’aggiornamento dei dati](https://raw.githubusercontent.com/odoo/documentation/18.0/content/applications/essentials/export_import_data.rst) descrive la funzionalità specifica. Prepara quindi una versione identica del file, una versione rinominata e una versione con le righe ordinate diversamente. Il risultato atteso deve rimanere stabile. La distinzione tra [numero di fattura e società emittente](https://www.billabex.com/it/blog/fatture-stesso-numero-verificare-entita/) aiuta a scegliere i riferimenti che rendono affidabile questa verifica. Conserva le diverse versioni usate, così il risultato sarà riproducibile anche da una persona che non ha assistito alla prova. ## Costruisci un caso in cui i totali non nascondano il problema Consideriamo una simulazione con dieci clienti e quaranta fatture da 2.000 €, quindi 80.000 € aperti all’inizio. L’importazione viene trasmessa tre volte. Questo rappresenta 120 righe elaborate nel corso delle trasmissioni, ma sempre quaranta fatture effettive e dieci clienti. Un saldo complessivo di 240.000 € rivelerebbe una duplicazione evidente. Le righe elaborate descrivono l’attività tecnica, non il numero di crediti distinti. Verificare soltanto gli 80.000 € non basta. Il software potrebbe aver creato ottanta fatture aggiuntive e averle poi escluse dal totale mostrato. Chiedi il numero di documenti attivi, i loro riferimenti e i collegamenti con le conversazioni. Una traccia di importazione ripetuta è normale; un secondo debito per lo stesso documento non lo è. Controlla che ogni conversazione rimandi alla fattura corretta, senza copie parallele della pratica. Per una fase di prova distinta, scegli sei di questi clienti, ciascuno con due fatture da 2.000 €: dodici fatture e 24.000 €. La regola del test prevede un messaggio raggruppato per cliente per quella stessa decisione: sono attesi sei messaggi, non dodici. Questo raggruppamento è un’ipotesi di prova, non una regola universale sulla frequenza o sulla composizione dei solleciti. Se la stessa importazione viene ripetuta tre volte e partono diciotto messaggi per questa sola fase, ci sono dodici invii aggiuntivi. Il numero di messaggi è triplicato, anche se le fatture e il saldo restano corretti. Il resoconto deve segnalare lo scostamento nelle comunicazioni, senza limitarsi alla formula «importazione senza doppioni». Confronta il risultato con i sei invii attesi, non con le dodici fatture presenti. ## Verifica la ripresa dopo un risultato incerto Il caso più istruttivo si verifica quando il servizio ha eseguito l’operazione, ma la conferma non è tornata al richiedente. Un nuovo tentativo può allora ripetere un’azione già riuscita. Chiedi una dimostrazione controllata di questa situazione, con destinatari di prova e invii separati dalla produzione. Deve essere possibile capire che cosa è accaduto anche quando un componente non ha ricevuto la risposta attesa. Stripe documenta ritrasmissioni automatiche degli eventi che, in modalità live, possono proseguire fino a tre giorni. Precisa inoltre che gli eventi possono arrivare più volte e in un ordine diverso da quello di generazione. Questi comportamenti mostrano perché un’integrazione deve prevedere nuovi tentativi; non descrivono la frequenza dei tuoi solleciti. La [documentazione Stripe sulla consegna degli eventi e sui duplicati](https://docs.stripe.com/webhooks) chiarisce questo funzionamento. Il rapporto di prova deve distinguere il tentativo, l’azione accettata dal servizio di invio e il risultato noto. Se manca la conferma, il sistema deve rendere visibile l’incertezza e risolverla prima di una ripetizione che potrebbe raggiungere il cliente. Una riga «errore» non dimostra che non sia stato inviato nulla. Allo stesso modo, una richiesta registrata non dimostra da sola che il destinatario abbia ricevuto il messaggio. ## Verifica che un dato vecchio non riapra una fattura pagata Riprendiamo i sei clienti della fase simulata. Prima dell’invio, uno di loro paga le sue due fatture, per 4.000 €. Il pagamento viene verificato e imputato. Il perimetro da sollecitare per questa fase diventa quindi di cinque clienti, dieci fatture e 20.000 €. Questi valori sono il riferimento aggiornato da confrontare con ciò che il sistema prepara e invia. Ripeti ora l’importazione dell’estrazione precedente, che mostrava ancora 24.000 €. La pratica deve mantenere l’effetto del pagamento recente oppure richiedere una risoluzione esplicita del conflitto tra dati. Un vecchio import non deve essere interpretato come una nuova prova di mancato pagamento. Applicare meccanicamente la regola «vince l’ultimo dato ricevuto» può invertire la cronologia dei fatti: l’estrazione arriva dopo, ma descrive una situazione precedente. Questo scenario completa il tema delle [fatture modificate dopo un sollecito](https://www.billabex.com/it/blog/fattura-modificata-dopo-sollecito-conservare-versioni/). In entrambi i casi, la data di ricezione di un’informazione e la data dell’evento che descrive non sono intercambiabili. La prova deve osservare anche i messaggi già preparati prima dell’arrivo del pagamento, per verificare se restano appropriati dopo l’aggiornamento del saldo. ## Includi nel controllo una nuova azione legittima Una protezione troppo ampia può eliminare il doppione e tutti i solleciti successivi. Aggiungi quindi uno scenario in cui, dopo aver esaminato la pratica, venga realmente decisa una nuova azione. Deve poter essere distinta dal tentativo ripetuto precedente, tenendo conto dei pagamenti, delle risposte e degli accordi intervenuti nel frattempo. Non basta consentire l’invio: il messaggio deve utilizzare il contesto corrente. AWS sottolinea anche che il periodo durante il quale una richiesta resta riconoscibile dipende dal servizio e dal suo contratto. Chiedi fino a quanto tempo prima il sistema riconosce un tentativo ripetuto e che cosa succede oltre quel limite. Una prova riuscita dopo cinque minuti non dimostra automaticamente il comportamento dopo diversi giorni. Riporta il periodo effettivamente verificato, senza trasformarlo in una garanzia generale. ## Chiedi una prova che il team finance possa rileggere Il materiale utile comprende i file usati, gli importi attesi, i documenti ritrovati e i messaggi effettivamente prodotti. Il [registro dei solleciti](https://www.billabex.com/it/blog/registro-solleciti-tracce-prima-dell-automazione/) aiuta a riunire questi elementi senza confondere le fasi tecniche con una comunicazione al cliente. Il resoconto deve permettere di confrontare aspettative e risultati per ciascuna fase, compresa quella successiva al pagamento. Per valutare il tuo processo, esamina le [integrazioni Billabex](https://www.billabex.com/it/prodotto/integrazioni/) con questi scenari di ripresa. Fai precisare i risultati osservabili e i limiti del connettore interessato. L’esistenza di una scheda marketing non prova un collegamento nativo: per gli altri raccordi occorre qualificare l’assistenza e il perimetro disponibili. Nessuno slogan sull’affidabilità sostituisce la verifica di tre aspetti: la stessa pratica, il saldo attuale corretto e soltanto l’azione realmente autorizzata. ## Fonti - AWS Builders’ Library, Making retries safe with idempotent APIs. - Odoo 18, Export and import data, identificativi e nuove importazioni. - Stripe, Receive Stripe events, consegna e duplicati. Fonti consultate il 7 settembre 2026.