--- title: "Uma importação repetida não deve duplicar lembretes: testar duplicados" canonical: https://www.billabex.com/pt/blog/importacao-repetida-duplicados-lembretes/ lang: pt 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 --- # Uma importação repetida não deve duplicar lembretes: testar duplicados A sincronização contabilística é interrompida. O apoio técnico propõe repetir a última importação e confirma depois que as faturas voltaram a estar visíveis. Uma hora mais tarde, vários clientes recebem um segundo lembrete idêntico. No entanto, o número de faturas no software não aumentou. Este incidente revela dois assuntos distintos: reconhecer dados já recebidos e reconhecer uma ação já realizada. Um software pode evitar processos duplicados e, ainda assim, repetir uma mensagem. Para avaliar uma integração de cobranças, o teste deve, por isso, chegar até ao resultado visível pelo cliente, num ambiente preparado para ensaios. ## Definir o que significa «repetir sem efeito adicional» As equipas técnicas falam de idempotência quando a repetição da mesma operação não acrescenta um novo efeito no negócio. Este princípio deve ser traduzido para o seu caso: uma fatura continua a ser uma única fatura, um pagamento não é contabilizado duas vezes e a mesma decisão de enviar um lembrete não produz vários envios. A AWS explica que dois pedidos aparentemente idênticos podem, contudo, expressar duas intenções diferentes. A sua biblioteca técnica recomenda tornar a intenção identificável, em vez de deduzir sistematicamente a existência de um duplicado apenas a partir do conteúdo. Esta orientação consta da AWS Builders' Library, no artigo sobre repetições seguras e API idempotentes. Nas cobranças, isto evita outro erro: bloquear indevidamente um lembrete legítimo posterior porque o texto se assemelha ao de um anterior. O teste deve distinguir a repetição da mesma ação de uma nova ação autorizada noutra data. Não exige que um cliente nunca mais seja contactado. ## Manter a identidade estável para além do nome do ficheiro Mudar o nome de um ficheiro não cria novas faturas. Alterar a ordem das linhas também não. Para identificar um documento, o sistema deve encontrar a sua origem e o seu identificador no âmbito em causa, nomeadamente a sociedade emitente. Uma simples comparação do número visível pode confundir duas entidades. O Odoo 18 documenta a utilização de identificadores externos constantes para atualizar registos por importação. Avisa que um identificador eliminado ou alterado pode provocar uma criação em duplicado. Esta regra de importação ilustra a importância de uma identidade persistente, sem provar o comportamento de outra integração. [Odoo 18, importação e atualização de dados](https://raw.githubusercontent.com/odoo/documentation/18.0/content/applications/essentials/export_import_data.rst). Prepare, por isso, uma versão idêntica do ficheiro, uma versão com outro nome e uma versão com as linhas ordenadas de outra forma. O resultado esperado deve manter-se estável. A distinção entre [número de fatura e entidade jurídica](https://www.billabex.com/pt/blog/faturas-mesmo-numero-entidades/) ajuda a escolher as referências que tornam esta verificação fiável. ## Construir um caso em que os totais não escondam o problema Consideremos uma simulação com dez clientes e quarenta faturas de 2 000 €, ou seja, 80 000 € inicialmente em aberto. A importação é transmitida três vezes. Isto representa 120 linhas tratadas ao longo das transmissões, mas continuam a existir quarenta faturas efetivas e dez clientes. Um saldo em aberto de 240 000 € revelaria uma duplicação evidente. Verificar apenas os 80 000 € não basta. O software poderia ter criado oitenta faturas adicionais e depois tê-las excluído do total apresentado. Peça o número de documentos ativos, as suas referências e as ligações às conversas. É normal haver um registo da importação repetida; não é normal existir uma segunda dívida para o mesmo documento. Para uma ronda de teste distinta, escolha seis desses clientes, cada um com duas faturas de 2 000 €, ou seja, doze faturas e 24 000 €. A regra do ensaio prevê uma mensagem agrupada por cliente para esta mesma decisão: esperam-se seis mensagens, não doze. Este agrupamento é uma hipótese de teste, não uma regra universal de cadência. Se a mesma importação for repetida três vezes e forem enviadas dezoito mensagens para esta única ronda, existem doze envios adicionais. O número foi multiplicado por três, mesmo que as faturas e o saldo permaneçam corretos. O relatório deve assinalar o desvio ao nível das comunicações, e não limitar-se a declarar «importação sem duplicados». ## Testar a retoma depois de um resultado incerto O caso mais esclarecedor ocorre quando o serviço realizou a operação, mas a confirmação não chegou a quem a pediu. Uma nova tentativa pode então repetir uma ação que já tinha sido bem-sucedida. Peça uma demonstração controlada desta situação, com destinatários de teste e envios separados da produção. A Stripe documenta retransmissões automáticas de eventos que podem prolongar-se por até três dias em modo de produção. Esclarece igualmente que os eventos podem chegar várias vezes e numa ordem diferente daquela em que foram gerados. Estes comportamentos mostram por que motivo uma integração deve prever novas tentativas; não descrevem a cadência dos seus lembretes. [Stripe, entrega de eventos e duplicados](https://docs.stripe.com/webhooks). O relatório do ensaio deve distinguir tentativa, ação aceite pelo serviço de envio e resultado conhecido. Se faltar a confirmação, o sistema deve tornar a incerteza visível e resolvê-la antes de uma repetição suscetível de chegar ao cliente. Uma linha com a indicação «erro» não prova que nada foi enviado. ## Verificar se dados antigos reabrem uma fatura paga Retomemos os seis clientes da ronda simulada. Antes do envio, um deles paga as suas duas faturas, num total de 4 000 €. O pagamento é verificado e imputado. O âmbito dos lembretes desta ronda passa a ser de cinco clientes, dez faturas e 20 000 €. Repita então a extração antiga que ainda mostrava 24 000 €. O processo deve conservar o efeito do pagamento recente ou pedir uma resolução explícita do conflito entre dados. Uma importação antiga não deve ser interpretada como nova prova de falta de pagamento. Repetir mecanicamente que «prevalecem os últimos dados recebidos» pode inverter a cronologia dos factos. Este cenário complementa o tema das [faturas alteradas depois de um lembrete](https://www.billabex.com/pt/blog/fatura-alterada-apos-lembrete-versoes/). Em ambos os casos, a data de receção de uma informação e a data do acontecimento que descreve não são intercambiáveis. O teste deve observar também as mensagens já preparadas antes da chegada do pagamento. ## Incluir a nova ação legítima na verificação Uma proteção demasiado abrangente pode eliminar o duplicado e todos os lembretes seguintes. Acrescente, por isso, um cenário em que, depois de analisado o processo, é efetivamente decidida uma nova ação. Deve ser possível distingui-la da repetição anterior, tendo em conta os pagamentos, as respostas e os acordos entretanto ocorridos. A AWS salienta também que o tempo durante o qual um pedido continua a ser reconhecido depende do serviço e do respetivo contrato. Pergunte até quando é possível reconhecer uma tentativa repetida e o que acontece depois desse período. Um ensaio bem-sucedido ao fim de cinco minutos não demonstra automaticamente o comportamento após vários dias. ## Pedir uma prova que a equipa financeira consiga reler O resultado útil contém os ficheiros utilizados, os montantes esperados, os documentos encontrados e as mensagens efetivamente produzidas. O [registo de lembretes](https://www.billabex.com/pt/blog/registo-lembretes-rastreabilidade-automatizacao/) ajuda a reunir estes elementos sem confundir as etapas técnicas com uma comunicação ao cliente. Para avaliar o seu circuito, analise as [integrações Billabex](https://www.billabex.com/pt/produto/integracoes/) com estes cenários de retoma. Peça esclarecimentos sobre os resultados observáveis e os limites do conector em causa. Nenhum slogan sobre fiabilidade substitui a verificação de três elementos: o mesmo processo, o saldo atual correto e apenas a ação efetivamente autorizada. ## Fontes - AWS Builders' Library, artigo sobre tornar seguras as novas tentativas com API idempotentes. - Odoo 18, exportação e importação de dados, identificadores e reimportação. - Stripe, receção de eventos Stripe, entrega e duplicados. Fontes consultadas em 7 de setembro de 2026.