Préparer une revue des IBAN fournisseurs avec IBANforge et export JSON

Quick overview

Préparer une revue des coordonnées fournisseurs avant une migration ERP : contrôler les IBAN par lot, conserver chaque ligne originale et produire un fichier JSON de constats et de propositions bancaires séparées. Le modèle ne modifie aucun ERP et ne déclenche aucun paiement.

How it works

1. Lancer manuellement le workflow. Le jeu fourni contient quatre lignes fictives avec des anomalies ; il sert à découvrir les sorties avant de brancher une source de données.
2. Préparer de 1 à 100 lignes JSON, conserver toutes leurs colonnes dans original, normaliser les IBAN dans des champs séparés et repérer les doublons sans les supprimer.
3. Quand au moins un IBAN est présent, envoyer uniquement les IBAN non vides au point de terminaison batch d’IBANforge avec le credential configuré. Un lot entièrement vide ne fait aucun appel API.
4. Contrôler la forme de la réponse, le nombre et l’ordre des résultats et la correspondance de chaque IBAN. Une erreur HTTP, un quota épuisé ou une incohérence arrête le traitement sans nouveau fichier.
5. Classer les lignes en ask_supplier, review ou enrichment_proposal. Les données incertaines restent à revoir ; les champs BIC et nom de banque ne sont proposés que selon les références disponibles, sans remplacer les valeurs originales.
6. Produire le fichier JSON téléchargeable dans la sortie Binary du dernier nœud, champ data. Les constats restent consultables par ligne ; payment_authorized reste toujours faux.

Setup

1. Importer le JSON dans n8n. Créer ou réutiliser une clé IBANforge avec un quota suffisant, puis la conserver dans un credential Header Auth : nom Authorization, valeur Bearer suivie d’un espace et de la clé. Ne jamais ajouter le secret au fichier du workflow.
2. Sélectionner ce credential dans le nœud HTTP et conserver l’URL https://api.ibanforge.com/v1/iban/batch. Chaque IBAN non vide consomme une unité, doublons compris. Les redirections et relances automatiques restent désactivées ; aucun achat de crédit ni remplacement de clé n’est automatisé.
3. Exécuter d’abord les lignes fictives fournies et lire le fichier produit. Remplacer ensuite le nœud d’entrée par vos lignes JSON : iban doit être du texte ; bic et bank_name sont facultatifs. Les données d’origine restent dans n8n et son historique : régler les accès et la conservation avant tout usage réel.

Requirements

• n8n avec les nœuds intégrés Manual Trigger, Code, If, HTTP Request et Convert to File. Une clé IBANforge est nécessaire pour les lots contenant des IBAN. Aucun community node, modèle d’IA, compte ERP ou service de notification n’est requis.

Customization

• Brancher une source autorisée de lignes JSON sur la préparation du lot. Garder la limite de 100 lignes, les contrôles de correspondance et les propositions séparées. Tout import dans un ERP demande un traitement distinct et une validation adaptée ; ce modèle ne réalise pas cet import.

Additional info

Modèle et instructions en français. Vérifié dans n8n 2.46.6 en local : douze scénarios, dont erreurs HTTP, réponse désordonnée, redirection, délai dépassé et lot vide, puis un essai sur l’API avec des données fictives et une clé révoquée après usage. Pas d’essai réalisé sur n8n Cloud. IBANforge fournit ce modèle et l’API utilisée. Un IBAN structurellement valide ou une banque identifiée ne confirme ni l’existence du compte ni le titulaire ; aucune sortie ne vaut autorisation de paiement. Guide : https://ibanforge.com/fr/docs/recipes .