Comment transférer les données d'inspection vers l'ERP et la comptabilité sans double saisie ?

Réponse courte : comment prévenir le double enregistrement ?

Attribuez à chaque intervention d'inspection une identité source immuable ; exécutez le transfert ERP de manière idempotente avec cette identité, forcez l'unicité dans la base de données et ne liez à la comptabilité que le document cible vérifié.

Il ne suffit pas qu'une intégration fonctionne en flux normal. Lorsque la réponse réseau se perd, qu'un message de file arrive en double ou que deux workers prennent la même tâche, le résultat doit rester un seul client, une seule commande et un seul lien de facturation.

Pourquoi un double enregistrement se produit-il ?

Réponse courte : la plupart des doubles enregistrements surviennent non pas parce que l'utilisateur a cliqué deux fois, mais à cause d'une nouvelle tentative non contrôlée effectuée au moment ambigu où la première requête a réussi sans que sa réponse parvienne.

Le système d'inspection envoie à l'ERP une requête de création de commande. L'ERP crée l'enregistrement, mais la connexion se ferme et l'intégration ne reçoit pas la réponse. Si un worker renvoie la même requête comme une nouvelle opération, une seconde commande peut être ouverte. On retrouve le même risque avec la livraison « au moins une fois » dans les files, les workers parallèles, les relances manuelles après délai d'attente et la synchronisation par lots.

L'IETF RFC 9110 définit la méthode idempotente comme une méthode dont l'application multiple d'une même requête a le même effet visé qu'une seule application. PUT possède cette propriété ; la création d'une nouvelle ressource par POST doit en revanche être protégée séparément. La conception technique ne doit pas supposer que le réseau délivre exactement une fois.

Quelle identité doit porter l'enregistrement ?

L'intervention d'inspection, la commande ERP, l'écriture comptable et le document électronique n'ont pas la même identité. Au début de la chaîne doit figurer un UUID d'intervention source immuable ; les identités produites par les autres systèmes doivent être conservées dans des champs distincts comme correspondances.

OASIS UBL 2.4 Invoice définit des champs de référence entre la facture, la commande et les autres documents. Le guide du portail e-Fatura de la GİB indique également que des factures portant le même UUID et le même numéro de facture ne peuvent pas être chargées de nouveau. La conclusion pratique n'est pas de remplacer l'identité d'inspection source par le numéro de document électronique, mais de conserver les identités séparées dans une table de correspondance bidirectionnelle.

Comment générer la clé d'idempotence ?

La clé ne doit pas être régénérée aléatoirement à chaque nouvelle tentative ; elle doit rester identique pour toutes les tentatives du même effet commercial. Un exemple de périmètre peut être dérivé de la combinaison canonique des éléments suivants :

tenant + hedef_sistem + işlem_türü + kaynak_iş_uuid + kaynak_sürümü

La version source compte. Renvoyer la même version de rapport doit retourner le résultat existant ; si une révision autorisée crée un nouvel effet commercial, elle doit constituer un événement distinct avec une règle de gestion explicite. L'enregistrement d'idempotence doit conserver, outre la clé, l'empreinte de la charge utile, l'heure de première apparition, le statut et l'identité de la réponse cible.

La référence API actuelle de Stripe documente qu'après une erreur de connexion, une requête create/update peut être répétée en toute sécurité avec la même clé d'idempotence, et qu'une requête est rejetée si la clé est identique mais que les paramètres ont changé. Ce comportement propre à ce prestataire est aussi un exemple de contrat utile pour l'adaptateur ERP interne : si la même clé arrive avec un client, un montant ou une correspondance fiscale différents, n'écrasez pas silencieusement ; soumettez le conflit à examen.

Pourquoi un contrôle applicatif ne suffit-il pas seul ?

Avec l'approche « vérifier d'abord l'existence, puis insérer », deux workers peuvent simultanément conclure à l'absence. L'unicité doit aussi être forcée dans la base de données.

Dans la table de correspondance d'intégration tenant_id + target_system + document_type + source_job_uuid établissez une contrainte d'unicité composée. La documentation actuelle d'INSERT de PostgreSQL indique qu'avec une contrainte d'unicité ON CONFLICT explique que l'usage sous concurrence peut aboutir à un insert/update atomique. Si votre règle métier n'autorise pas la mise à jour, renvoyez en cas de conflit l'identifiant cible existant ; si les données diffèrent, ouvrez une fiche d'examen selon le principe fail-closed.

UNIQUE (tenant_id, target_system, document_type, source_job_uuid)

aynı anahtar + aynı payload özeti  -> mevcut sonucu döndür
aynı anahtar + farklı payload       -> çakışma, otomatik belge açma

Comment structurer le flux Outbox et la file d'attente ?

Rédiger séparément le passage du rapport d'inspection en « prêt pour facturation » et le message ERP peut produire des états intermédiaires. L'état métier et l'événement d'intégration doivent être validés dans la même transaction locale.

1. L'utilisateur autorisé approuve la version du rapport et le périmètre de facturation.
2. L'application met à jour l'état métier dans la même transaction et ajoute une ligne outbox avec l'UUID de l'événement.
3. Le worker envoie l'événement outbox à l'adaptateur cible avec une clé d'idempotence fixe.
4. En cas de réponse positive, l'identifiant cible ERP et le résumé de réponse sont enregistrés dans la table de liaison.
5. Si l'ACK est perdu, le même événement revient ; le consommateur voit l'UUID de l'événement et la liaison métier et renvoie le résultat existant.
6. Une erreur de données permanente n'entre pas dans une boucle de retry ; elle est orientée vers un examen ou une dead-letter queue.

Le guide Transactional Outbox de Microsoft recommande de stocker l'objet métier et l'événement dans la même transaction ; le guide Service Bus recommande quant à lui que le consommateur soit idempotent via le MessageId ou une identité métier, en raison des ACK perdus et des livraisons répétées. La détection de doublons côté émetteur ne remplace pas le contrôle d'unicité côté récepteur.

Comment sécuriser l'équivalence client, prestation et taxe ?

Éviter les doublons n'est pas qu'une question de retry technique. Rouvrir le même client avec une variante d'orthographe de sa raison sociale ou facturer la même prestation sous un code différent produit aussi une duplication opérationnelle.

• Client : mettez en correspondance via un VKN/TCKN vérifié à l'échelle du tenant ou via la clé maîtresse de l'organisation ; n'utilisez jamais la seule raison sociale comme clé.
• Prestation : reliez la méthode d'inspection à la table approuvée des codes stock/prestation de l'ERP ; ne créez pas automatiquement un code non apparié en texte libre.
• Taxe et devise : appliquez une correspondance versionnée vers la liste de codes du système cible ; en cas de correspondance manquante ou invalide, suspendez la production du document.
• Montant : verrouillez les lignes calculées, les remises et la taxe avec le résumé de la version source ; après approbation, toute modification passe par un nouveau flux de révision.
• Habilitations : gérez avec des pistes d'audit distinctes les rôles de création de client, de modification de correspondance et de production de documents financiers.

Une correspondance ambiguë ne doit pas sélectionner « le résultat le plus proche ». Le transfert doit attendre la fin de l'examen humain ; la décision prise doit être consignée avec son auteur, l'horodatage, les valeurs antérieure/nouvelle et la justification.

Comment suivre l'état du transfert ?

Un unique champ « succès/échec » masque l'ambiguïté. La machine à états doit indiquer quelle étape peut être rejouée.

Supprimer l'enregistrement de transfert réussi puis renvoyer n'est pas une méthode de correction. Si un document financier a été créé, l'annulation, le remboursement ou l'écriture inverse doit suivre son propre identifiant et son propre flux d'approbation.

Quels contrôles la réconciliation doit-elle effectuer ?

La réconciliation quotidienne doit comparer les enregistrements source et cible au niveau des identifiants, et non se contenter de compter les logs d'erreurs.

• Les dossiers prêts pour facturation sans liaison cible.
• Plusieurs documents cibles liés au même UUID de dossier source.
• Les documents présents côté cible sans correspondance dans la table de liaison source.
• Les enregistrements dont l'empreinte du payload envoyé ne correspond pas à la version source.
• Les tentatives restées en état ambigu au-delà de la durée définie.
• Les manques d'approbation/preuve sur les correspondances manuelles, annulations et écritures inverses.

Le résultat de la réconciliation ne doit déclencher ni suppression automatique ni fusion groupée. Il doit présenter à l'utilisateur autorisé les enregistrements suspects, leurs identités dans les deux systèmes et l'action sécurisée proposée.

Comment piloter l'intégration VizyonTech ?

Vizyon Periyodik pour les flux d'inspection vers l'ERP, testez les scénarios d'erreur avant le scénario nominal. Doivent être testés : le double clic sur un même dossier, l'ERP qui crée l'enregistrement sans répondre, un même message de file arrivant à deux workers, la même clé avec des payloads différents, une correspondance client invalide et une révision de rapport.

Le critère de succès du pilote n'est pas « l'intégration fonctionne ». Pour chaque scénario, il faut prouver combien d'enregistrements ont été créés côté cible, si la liaison source-cible a été établie, si le retry renvoie le même résultat, si l'ambiguïté reste visible et si l'opération financière non autorisée a été bloquée. Afin de préserver la chaîne décisionnelle du rapport d'inspection, le guide du flux de travail e-imza peut également être consulté conjointement.