> Amélioration continue des processus > Traitement des paiements > FIS Global > Modèle de données

Votre modèle de données pour le traitement des paiements

FIS Global

Attributs du traitement des paiements (19) Activités du traitement des paiements (13) Guides d'extraction (1)

Votre modèle de données pour le traitement des paiements

Ce modèle fournit un guide complet des attributs de données et des activités de processus essentiels à une analyse efficace du traitement des paiements. Il comprend également des conseils pratiques pour extraire ces informations importantes de vos systèmes. Utilisez cette ressource pour vous assurer de recueillir toutes les données nécessaires à une initiative de Process Mining fiable.

Attributs recommandés à recueillir
Activités clés à suivre
Guide d'extraction

Vous découvrez les journaux d’événements ? En savoir plus sur la création d’un journal d’événements pour le Process Mining.

Télécharger le modèle

Attributs du traitement des paiements

Voici les champs de données recommandés à inclure dans votre journal d’événements pour analyser de manière complète le traitement des paiements.

3 Obligatoire 7 Recommandé 9 Facultatif

	Nom	Description
	Horodatage de l’événement EventTimestamp	Date et heure précises auxquelles l’activité s’est produite.
Description Cet attribut fournit le contexte temporel de chaque événement du processus de paiement. Il enregistre le moment exact où une action a été consignée par le système, ce qui permet de classer les activités dans l’ordre chronologique. Dans l’analyse, il sert à calculer les durées entre les étapes, les temps de cycle totaux et les taux de débit. Il permet d’identifier les goulots d’étranglement en mettant en évidence les retards entre certaines étapes du processus. Pourquoi c’est important Toute analyse fondée sur le temps est impossible sans ce champ, qui alimente tous les KPI de performance et d’efficacité. Où les obtenir Consulter la documentation de FIS Global Exemples 2023-10-12T08:30:15Z2023-10-12T09:45:00Z2023-10-13T14:20:10Z
	Identifiant de transaction de paiement PaymentTransactionId	Identifiant unique de l’instruction ou de la transaction de paiement concernée.
Description Cet attribut constitue la clé centrale permettant de relier tous les événements d’un même cycle de vie de paiement. Il permet aux analystes de suivre le paiement depuis la demande initiale jusqu’à la validation, l’approbation, puis au règlement ou au rapprochement final. Dans l’analyse, cet identifiant est essentiel pour regrouper les événements distincts en instances de processus. Il permet de visualiser le flux de bout en bout et sert de base à toutes les métriques au niveau du cas, notamment la durée du cycle et les boucles de reprise. Pourquoi c’est important Il constitue le lien fondamental du Process Mining, en permettant de reconstituer des activités disparates sous la forme d’un parcours cohérent. Où les obtenir Consulter la documentation de FIS Global Exemples TRX-2023-899102PAY-US-99281ACH-7721-X99WIRE-2210-001
	Nom de l’activité ActivityName	Nom de l’étape de processus ou de l’événement spécifique qui s’est produit.
Description Ce champ enregistre l’action précise effectuée à un moment donné, par exemple « Demande de paiement créée » ou « Paiement réglé ». Il définit les nœuds de la cartographie du processus et détermine la structure du flux de processus. Les analystes utilisent cet attribut pour comprendre la séquence des opérations. Il est essentiel pour repérer les écarts par rapport au parcours nominal, les étapes ignorées ou les activités redondantes, comme les boucles d’approbation multiples. Pourquoi c’est important Il définit le « quoi » du processus et permet de visualiser les cartographies de processus ainsi que les variantes. Où les obtenir Consulter la documentation de FIS Global Exemples Demande de paiement crééeDétails du paiement validésPaiement approuvéPaiement réglé
	Code devise CurrencyCode	Code ISO à trois lettres désignant la devise du paiement.
Description Cet attribut précise la devise du montant du paiement, par exemple USD, EUR ou GBP. Il est essentiel pour normaliser les données financières lors de l’analyse de flux de paiements internationaux. Dans l’analyse, ce champ permet de segmenter la performance des processus par devise, ce qui est souvent lié à différents systèmes de compensation et réglementations. Il aide à expliquer les écarts de délai de règlement entre les paiements transfrontaliers et nationaux. Pourquoi c’est important Indispensable dans les environnements multidevises pour interpréter correctement les volumes financiers. Où les obtenir Consulter la documentation de FIS Global Exemples USDEURGBPJPY
	Date d’échéance du paiement PaymentDueDate	Date à laquelle le paiement doit être réglé.
Description Cet attribut enregistre la date limite du paiement, demandée par l’initiateur ou définie par les conditions de facturation. Il sert de référence pour mesurer le respect des délais. Ce champ est essentiel au Dashboard « respect de la date d’échéance des paiements ». En comparant cette date à la date réelle du « Paiement réglé », les analystes peuvent repérer les paiements en retard, calculer les pénalités potentielles et évaluer le respect des accords conclus avec les fournisseurs. Pourquoi c’est important Il fournit la référence nécessaire pour mesurer le respect des niveaux de service et des délais. Où les obtenir Consulter la documentation de FIS Global Exemples 2023-11-012023-11-15
	Date réelle de règlement ActualSettlementDate	Date à laquelle le paiement a effectivement été finalisé et réglé.
Description Cet attribut enregistre la date effective à laquelle les fonds ont été transférés ou la transaction considérée comme terminée. Elle diffère de l’horodatage de traitement, car elle correspond à la date de valeur. Dans l’analyse, elle est utilisée avec la date d’échéance pour calculer le « taux de paiements effectués dans les délais ». Elle déclenche également la phase de rapprochement, ce qui la rend essentielle à l’analyse du « délai de rapprochement du paiement ». Pourquoi c’est important Elle représente l’aboutissement financier du paiement et constitue un élément clé de l’analyse des flux de trésorerie. Où les obtenir Consulter la documentation de FIS Global Exemples 2023-11-022023-11-14
	Montant du paiement PaymentAmount	Valeur monétaire de la transaction de paiement.
Description Cet attribut représente la valeur financière associée à la demande de paiement. Il constitue la principale métrique pour analyser le débit financier et le risque. Les analystes utilisent ce champ pour segmenter les processus selon que les paiements sont de montant élevé ou faible, car ils suivent souvent des circuits d’approbation différents. Il alimente le Dashboard « débit des paiements » et aide à déterminer si les paiements de montant élevé présentent des durées de cycle plus longues en raison de contrôles plus stricts. Pourquoi c’est important Il ajoute une dimension financière au Process Mining et permet de hiérarchiser les priorités selon la valeur. Où les obtenir Consulter la documentation de FIS Global Exemples 1500.00250.501000000.0045.99
	Type de paiement PaymentType	Classification du mode ou de l’instrument de paiement.
Description Cet attribut classe le paiement selon des types tels que virement, ACH, SEPA, paiement en temps réel (RTP) ou chèque. Chaque type de paiement suit des règles de traitement et des SLA distincts. Les analystes utilisent ce champ pour comparer le « délai de rapprochement du paiement » entre les différents circuits. Il aide à expliquer pourquoi certains paiements sont réglés instantanément tandis que d’autres prennent plusieurs jours, afin que la performance soit mesurée par rapport au référentiel approprié. Pourquoi c’est important Il constitue la dimension principale pour segmenter les flux de processus, chaque type présentant des caractéristiques propres en matière de routage et de délais. Où les obtenir Consulter la documentation de FIS Global Exemples Virement bancaireCrédit ACHSEPA InstantChèque
	Unité opérationnelle BusinessUnit	Division ou service interne à l’origine du paiement.
Description Cet attribut rattache le paiement à une unité organisationnelle précise, telle que « Banque de détail », « Financement commercial » ou « Trésorerie ». Il sert à agréger des KPI tels que le « débit des paiements » et la « durée moyenne du cycle de paiement » par service. Il aide la direction à comparer la performance des différentes divisions et à affecter efficacement les ressources. Pourquoi c’est important Il permet de comparer les performances en interne et de responsabiliser les équipes quant à la performance des processus. Où les obtenir Consulter la documentation de FIS Global Exemples TrésorerieComptes fournisseursOpérations de banque de détailGestion de patrimoine
	Utilisateur de traitement ProcessingUser	Identifiant ou nom de l’utilisateur ou de l’agent système qui exécute l’activité.
Description Cet attribut indique qui ou quoi a exécuté l’étape du processus. Il permet de distinguer les opérateurs humains, par exemple « J.Smith », des comptes système automatisés, par exemple « SYSTEM_BATCH ». Ces données servent à analyser l’utilisation des ressources, à repérer les goulots d’étranglement manuels et à contrôler la séparation des tâches. Elles contribuent au calcul du « Processing User Utilization Rate » et à la distinction entre les tâches manuelles et automatisées. Pourquoi c’est important Indispensable pour l’analyse des ressources, le taux d’automatisation et les audits de conformité. Où les obtenir Consulter la documentation de FIS Global Exemples jsmithSYSTEM_AUTOBOTmdoe_approverAPI_GATEWAY
	Autorité d’approbation ApprovalAuthority	Rôle, groupe ou personne responsable de l’autorisation du paiement.
Description Cet attribut indique le niveau d’autorité ou le groupe d’utilisateurs requis pour approuver le paiement, souvent en fonction d’un seuil de montant. Il aide à suivre le routage du flux de travail d’approbation. Les analystes l’utilisent pour alimenter le Dashboard « Payment Authorization Bottlenecks ». Il permet de ventiler les délais d’approbation par niveau d’autorité afin de déterminer si certains échelons hiérarchiques provoquent des retards. Pourquoi c’est important Il permet d’analyser la hiérarchie des approbations de l’organisation et de détecter les goulots d’étranglement. Où les obtenir Consulter la documentation de FIS Global Exemples Responsable de niveau 1CFOÉquipe ConformitéSystème d'approbation automatique
	Canal de paiement PaymentChannel	Canal par lequel la demande de paiement a été initiée.
Description Cet attribut décrit l’origine de l’instruction de paiement, par exemple la banque en ligne, l’application mobile, une API ou une agence. Il permet de comprendre le canal d’entrée de la transaction. Les analystes l’utilisent pour comparer l’efficacité du traitement entre les différents canaux. Il permet notamment de déterminer si les paiements initiés par API présentent moins d’erreurs que ceux saisis manuellement en agence. Pourquoi c’est important Il contribue à l’optimisation des canaux et à la compréhension du comportement des clients. Où les obtenir Consulter la documentation de FIS Global Exemples Banque en ligneApplication mobilePasserelle d'entrepriseGuichetier
	Code d’erreur de validation ValidationErrorCode	Code ou motif indiquant pourquoi un paiement n’a pas passé la validation.
Description Cet attribut est renseigné lorsqu’un paiement entre dans l’activité « Erreur de paiement identifiée ». Il contient des informations précises sur l’échec, telles que « IBAN non valide », « Fonds insuffisants » ou « Adresse du bénéficiaire manquante ». Ce champ alimente le Dashboard « taux d’erreur de validation des données de paiement ». Le regroupement par attribut révèle les causes les plus fréquentes des reprises et permet de cibler les corrections dans la saisie des données en amont ou la configuration du système. Pourquoi c’est important Il identifie les causes profondes des difficultés du processus et des boucles de reprise. Où les obtenir Consulter la documentation de FIS Global Exemples ERR-001 : Compte invalideERR-055 : Correspondance avec une liste de sanctionsERR-009 : Transaction en double
	Compte émetteur SenderAccount	Numéro du compte sur lequel les fonds sont débités.
Description Cet attribut identifie le compte source de la transaction. Il fournit un niveau de détail supplémentaire pour analyser les paiements effectués depuis certains comptes internes. Dans l’analyse, il aide à déterminer si certains comptes de financement sont davantage sujets aux erreurs, par exemple en cas de fonds insuffisants, ou aux retards. Il facilite le rapprochement en permettant d’associer les écritures du grand livre aux activités du processus. Pourquoi c’est important Il est fondamental pour le rapprochement financier et la résolution des problèmes au niveau des comptes. Où les obtenir Consulter la documentation de FIS Global Exemples 123456789987654321ACC-TREASURY-01
	Dernière mise à jour des données LastDataUpdate	Horodatage de la dernière extraction ou actualisation de l’enregistrement.
Description Cet attribut indique l’actualité des données utilisées pour l’analyse. Il aide les utilisateurs à déterminer s’ils consultent des données en temps réel ou un instantané d’une période précédente. Dans les Dashboards, ce champ sert souvent à afficher la mention « Données à jour au ». Il garantit que les décisions reposent sur les informations les plus pertinentes disponibles et facilite la gestion des chargements incrémentiels de données. Pourquoi c’est important Il établit l’actualité des données et renforce la confiance dans la fraîcheur des rapports. Où les obtenir Métadonnées du processus ETL Exemples 2023-10-14T00:00:00Z2023-10-15T06:00:00Z
	Intervention manuelle IsManualIntervention	Indicateur précisant si l’activité a nécessité une intervention humaine.
Description Cet attribut booléen signale les activités ou les cas ayant nécessité une intervention humaine, comme « Erreur de paiement résolue » ou les approbations manuelles, par opposition au traitement automatisé de bout en bout (STP). Il est essentiel au Dashboard « taux d’intervention manuelle dans les paiements ». Il aide à quantifier le pourcentage de paiements qui ne sont pas entièrement automatisés et à repérer les possibilités de transformation numérique. Pourquoi c’est important Il distingue le débit automatisé de l’effort manuel et contribue au calcul du retour sur investissement de l’automatisation. Où les obtenir Dérivé de ActivityName ou ProcessingUser Exemples truefalse
	Paiement en retard IsLatePayment	Indicateur précisant si le paiement a été réglé après la date d’échéance.
Description Il s’agit d’un attribut booléen calculé. Il renvoie la valeur true si la date du « Paiement réglé » est postérieure à la « Date d’échéance du paiement ». Cet attribut alimente directement le KPI « taux de paiements effectués dans les délais ». Il simplifie la création des Dashboards en permettant aux utilisateurs de filtrer rapidement les cas problématiques, sans devoir intégrer une logique complexe de dates dans la couche de visualisation. Pourquoi c’est important Il simplifie les rapports d’exception et l’analyse de conformité. Où les obtenir Dérivé de PaymentDueDate et ActualSettlementDate Exemples truefalse
	Pays du bénéficiaire BeneficiaryCountry	Code du pays du destinataire du paiement.
Description Cet attribut identifie le pays de destination des fonds. Il sert à distinguer les paiements nationaux des paiements internationaux. Ce contexte est essentiel au « suivi de la conformité des paiements » et à l’analyse du routage. Les paiements internationaux font souvent intervenir des intermédiaires, des contrôles de conformité et des durées de cycle plus longues. L’analyse par pays aide donc à isoler ces variables. Pourquoi c’est important Il constitue une dimension clé de l’analyse géographique et de l’évaluation des risques de conformité. Où les obtenir Consulter la documentation de FIS Global Exemples USDECNGB
	Système source SourceSystem	Nom du système à l’origine des données d’événements.
Description Cet attribut identifie le composant logiciel ou la base de données précise depuis laquelle l’enregistrement a été extrait, par exemple le moteur bancaire central, la passerelle de paiement ou l’outil de filtrage des sanctions. Il est indispensable pour assurer la traçabilité des données et leur validation. Lors de l’analyse de flux de bout en bout couvrant plusieurs plateformes, ce champ aide à déterminer où les activités ont eu lieu et facilite le diagnostic des problèmes de qualité des données. Pourquoi c’est important Il garantit la traçabilité et le contexte, notamment dans les environnements complexes intégrant plusieurs moteurs de paiement. Où les obtenir Consulter la documentation de FIS Global Exemples FIS OPFTraxPaymentHub_01SanctionsScreeningDB

Obligatoire Recommandé Facultatif

Activités du traitement des paiements

Voici les principales étapes et les jalons du processus à enregistrer dans votre journal d’événements pour découvrir précisément le processus et l’optimiser.

6 Recommandé 7 Facultatif

	Activité	Description
	Demande de paiement créée	Il s’agit du premier événement du cycle de vie d’un paiement. Il correspond au moment où une nouvelle transaction de paiement est initiée dans le système FIS. Cet événement est généralement enregistré explicitement dans une table de journal des transactions lorsqu’un utilisateur ou un système automatisé soumet une nouvelle demande de paiement.
Pourquoi c’est important Cette activité constitue le début officiel du processus. Elle est essentielle pour mesurer la durée du cycle de paiement de bout en bout et analyser le débit ainsi que le volume globaux des paiements. Où les obtenir Enregistré dans une table centrale des transactions, cet événement est identifié par l’horodatage de création associé au Payment Transaction ID. Recherchez des tables telles que « Payment_Transactions » ou « Payment_Requests », avec un champ « creation_date » ou « entry_date ». Collecte Événement enregistré lors de la création d’un nouvel enregistrement de transaction de paiement. Type d’événement explicit
	Instruction de paiement envoyée	Cette activité correspond au moment où le système FIS envoie l’instruction de paiement finalisée au réseau de paiement concerné, tel que ACH, Fedwire ou SWIFT. Il s’agit d’un événement essentiel généré par le système.
Pourquoi c’est important Il s’agit d’une étape importante, qui indique que le paiement a quitté l’environnement de traitement interne. Elle est essentielle pour analyser l’efficacité du routage et le temps nécessaire au traitement externe. Où les obtenir Enregistré dans un journal des transactions ou des messages qui suit les communications avec les réseaux de paiement externes. Recherchez un enregistrement indiquant la transmission réussie d’un message sortant, avec son horodatage. Collecte Événement généré par le système lorsque le message de paiement est envoyé au réseau de compensation. Type d’événement explicit
	Paiement approuvé	Il s’agit d’une étape importante au cours de laquelle un utilisateur habilité approuve le paiement, ce qui lui permet de passer à l’étape suivante. Cet événement est presque toujours enregistré explicitement avec l’identifiant de l’approbateur et un horodatage au moment de son intervention dans le système.
Pourquoi c’est important Ce point de contrôle est essentiel pour mesurer la durée des cycles d’approbation et garantir le respect des contrôles financiers. Les retards à cette étape peuvent avoir un impact important sur la ponctualité des paiements. Où les obtenir Enregistré dans une table de journal des approbations ou comme événement explicite dans l’historique principal des transactions. Le journal d’événements associe le Payment Transaction ID, l’identifiant utilisateur de l’approbateur et l’horodatage de l’approbation. Collecte Enregistré lorsqu’un utilisateur disposant des droits d’approbation sélectionne l’action « approve » pour un paiement. Type d’événement explicit
	Paiement autorisé	Cette étape correspond à une autorisation finale, souvent requise pour les paiements d’un montant élevé ou par une autre autorité après l’approbation initiale. L’action est enregistrée explicitement lorsqu’un utilisateur disposant des droits d’autorisation confirme le paiement.
Pourquoi c’est important Cette activité est essentielle au Dashboard « Payment Authorization Bottlenecks ». La distinguer de « Payment Approved » permet d’identifier précisément les retards dans les processus de validation à plusieurs niveaux. Où les obtenir Enregistré dans un journal d’audit ou des transactions. Cet événement est déclenché par l’intervention d’un utilisateur disposant d’autorisations spécifiques sur le paiement, ce qui génère un enregistrement avec son identifiant et un horodatage. Collecte Une entrée de journal explicite est créée lorsqu’un utilisateur effectue l’action d’autorisation finale. Type d’événement explicit
	Paiement rapproché	Il s’agit de l’activité comptable finale au cours de laquelle la transaction de paiement est rapprochée d’un relevé bancaire ou d’une écriture du grand livre interne. Cette opération peut être automatisée par lots ou effectuée manuellement par un utilisateur.
Pourquoi c’est important Cette activité marque la fin absolue du cycle de vie du paiement. L’analyse du « délai de rapprochement du paiement » est essentielle pour comprendre l’efficacité des processus de clôture financière. Où les obtenir Souvent déduit du renseignement du champ « reconciliation_date » ou d’une modification finale du statut vers « Rapproché » dans un module financier ou comptable lié au système de paiement. Collecte Identifié par le renseignement d’une date de rapprochement ou par une modification du statut vers « Rapproché ». Type d’événement inferred
	Paiement réglé	Cette activité marque la fin du transfert de fonds, lorsque la transaction est considérée comme financièrement réglée. Elle est généralement enregistrée à la réception de la confirmation finale de règlement du réseau de paiement ou de la chambre de compensation.
Pourquoi c’est important Il s’agit du point de terminaison principal pour mesurer la durée du cycle de paiement et le taux de paiements effectués dans les délais. Il signale la réussite du processus central d’exécution du paiement. Où les obtenir Déduit d’une modification finale du statut de l’enregistrement du paiement vers « Réglé », « Terminé » ou « Comptabilisé ». Cette modification est déclenchée par des fichiers de règlement par lots ou par des messages en temps réel du système de compensation. Collecte Modification du statut de la transaction de paiement vers « Réglé » ou un statut équivalent. Type d’événement inferred
	Détails du paiement validés	Cette activité indique que les données du paiement ont passé les contrôles de validation automatisés initiaux portant sur le format, l’exhaustivité et l’exactitude. Elle est souvent déduite d’un changement de statut de l’enregistrement de paiement, par exemple de « New » à « Validated » ou « Pending Approval ».
Pourquoi c’est important Le suivi de cette activité permet d’identifier la fréquence et l’emplacement des erreurs de saisie. Il constitue un prérequis pour analyser le KPI Payment Data Validation Error Rate et comprendre les sources des reprises. Où les obtenir Déduit d’un champ de statut ou d’état dans la table des transactions de paiement. Le passage d’un état initial à l’état « validated », accompagné de l’horodatage correspondant, marque cet événement. Collecte Identifié par le changement du champ de statut du paiement vers « Validated » ou une valeur similaire. Type d’événement inferred
	Erreur de paiement identifiée	Indique qu’une erreur a été détectée à un moment donné du processus après la validation initiale, par exemple un rejet de la banque destinataire ou un signalement interne de conformité. Il s’agit souvent d’un événement explicite enregistré lorsqu’une exception est déclenchée.
Pourquoi c’est important Cette activité constitue le point d’entrée de toutes les boucles de reprise et de traitement des exceptions. Elle est essentielle au calcul des KPI de taux d’intervention manuelle et de délai de résolution des erreurs de paiement. Où les obtenir Enregistré dans un module de traitement des exceptions ou dans un journal des transactions. L’événement peut être déclenché automatiquement par une règle système ou manuellement par un utilisateur signalant un problème, ce qui crée un journal contenant un code d’erreur et un horodatage. Collecte Un code d’exception ou d’erreur est enregistré pour la transaction de paiement. Type d’événement explicit
	Erreur de paiement résolue	Marque la résolution d’une erreur de paiement précédemment identifiée, ce qui permet de retraiter ou d’annuler le paiement. Il s’agit d’une action explicite effectuée par un utilisateur pour supprimer le statut d’exception.
Pourquoi c’est important Cette activité clôt la boucle de traitement de l’exception. La durée entre « Erreur identifiée » et cet événement constitue une mesure importante de l’efficacité opérationnelle du traitement des exceptions. Où les obtenir Enregistré lorsqu’un utilisateur supprime un indicateur d’erreur ou retire la transaction d’une file d’exceptions. Cette action est consignée dans une piste d’audit ou un historique des transactions avec un horodatage. Collecte Une action utilisateur supprime l’état d’erreur, ce qui est enregistré dans un journal d’audit. Type d’événement explicit
	Paiement confirmé	Représente la réception d’un accusé de réception du réseau de paiement ou de la banque du bénéficiaire confirmant que le paiement a été reçu. Cet événement est déclenché par un message système entrant ou une mise à jour de statut.
Pourquoi c’est important La confirmation garantit que le paiement est bien arrivé à destination. Le délai entre « Instruction envoyée » et « Confirmé » mesure la latence du réseau externe et le temps de traitement. Où les obtenir Généré lors de l’analyse des messages de confirmation entrants provenant des réseaux de paiement. Le système met à jour le statut du paiement et enregistre un horodatage de confirmation. Collecte Un message entrant du réseau de compensation met à jour le statut du paiement et le définit sur « Confirmé ». Type d’événement explicit
	Paiement en retard identifié	Événement dérivé indiquant que le paiement a été réglé après sa date d’échéance. Cette activité n’est pas enregistrée explicitement, mais calculée en comparant deux champs de date.
Pourquoi c’est important Cette activité calculée contribue directement au KPI « taux de paiements effectués dans les délais » et au Dashboard « respect de la date d’échéance des paiements ». Elle aide à quantifier l’impact des retards de processus sur les relations avec les fournisseurs et les éventuels frais de retard. Où les obtenir Cet événement n’est pas extrait directement. Il est calculé lors de la transformation des données en comparant l’horodatage « Settlement Date » au champ « Payment Due Date ». Si la date de règlement est postérieure à la date d’échéance, l’événement est généré. Collecte Calculé si « Settlement Date » > « Payment Due Date ». Type d’événement calculated
	Paiement envoyé pour approbation	Représente le moment où un paiement validé est soumis au flux de travail d’approbation. Cet événement est généralement enregistré par un changement de statut indiquant que le paiement attend désormais l’intervention d’un approbateur.
Pourquoi c’est important Cette activité marque le début du sous-processus d’approbation. L’analyse du délai entre cette activité et « Payment Approved » est essentielle pour comprendre les goulots d’étranglement des approbations. Où les obtenir Déduit du changement de la valeur du champ de statut du paiement vers « Pending Approval », « Submitted for Approval » ou un état similaire dans un journal de statut de flux de travail ou de transaction. Collecte Changement du statut de la transaction de paiement de « Validated » à « Pending Approval ». Type d’événement inferred
	Paiement rejeté	Cette activité survient lorsqu’un approbateur refuse une demande de paiement, ce qui nécessite généralement de la corriger et de la soumettre à nouveau, ou de l’annuler complètement. Il s’agit d’une action utilisateur explicite, enregistrée à des fins d’audit.
Pourquoi c’est important Le suivi des rejets permet d’identifier les causes fréquentes des échecs de paiement, les écarts du processus et les boucles de reprise. Il met en évidence les problèmes liés à la qualité initiale des données ou à la conformité. Où les obtenir Enregistré comme événement explicite dans une table d’historique des approbations ou des transactions lorsqu’un approbateur sélectionne l’option « reject ». L’enregistrement comprend généralement un horodatage, l’identifiant utilisateur et, souvent, un code motif. Collecte Événement enregistré lorsqu’un utilisateur exécute l’action « reject » pour un paiement. Type d’événement explicit

Recommandé Facultatif

Guides d'extraction

Comment extraire vos données de FIS Global

Étapes

Vérifiez que le moteur de paiement FIS Global archive les messages XML ISO 20022 bruts, notamment les instructions de paiement pacs.008 et les rapports de statut de paiement pacs.002, dans un emplacement de fichiers accessible. Obtenez le chemin d'archive, la convention de nommage des fichiers, la configuration des espaces de noms, la durée de conservation ainsi que la correspondance entre le Payment Transaction ID et les identifiants ISO 20022 tels que EndToEndId, TxId, InstrId ou UETR.
Installez Python 3.10 ou une version ultérieure ainsi que les modules de la bibliothèque standard utilisés par le script, notamment pathlib, xml.etree.ElementTree, csv, datetime, decimal et collections. L'implémentation de référence ne nécessite aucun package externe. Vérifiez que le compte d'exécution peut lire l'archive XML et écrire le fichier de sortie ProcessMind.
Configurez le répertoire d'entrée, le fichier de sortie, les dates de début et de fin, le fuseau horaire ainsi que les filtres propres à votre entreprise dans la section de configuration du script. Remplacez uniquement les espaces réservés documentés. Ne supposez pas qu'un nom de fichier ou qu'un élément XML contient l'identifiant de dossier ProcessMind tant que la correspondance n'a pas été validée sur des fichiers représentatifs.
Examinez des fichiers pacs.008 et pacs.002 représentatifs correspondant à des transactions réussies, rejetées, échouées, corrigées et réglées. Confirmez les espaces de noms XML et identifiez les éléments contenant l'identifiant de transaction, le montant, la devise, la date d'exécution demandée, la date de règlement, le code de statut, le code motif, l'horodatage de l'événement, l'utilisateur de traitement ou l'agent système, le type de paiement et l'unité opérationnelle. Mettez à jour les expressions XPath candidates si l'implémentation FIS utilise d'autres chemins.
Exécutez d'abord le script sur une période limitée. L'analyseur lit chaque fichier XML, extrait les données au niveau du message et de la transaction, associe les codes de statut et de motif ISO 20022 à des activités explicites, puis écrit une ligne d'événement pour chaque activité extraite. Le script crée également les lignes Payment Error Identified et Payment Error Resolved à partir d'indicateurs explicites d'erreur ou de correction, et ne crée Late Payment Identified que lorsque le règlement a eu lieu après la date d'échéance.
Examinez le fichier CSV généré et le rapport de validation. Vérifiez que PaymentTransactionId, ActivityName et EventTimestamp sont renseignés pour chaque ligne, que les 13 noms d'activités requis peuvent apparaître et que les horodatages sont normalisés de manière cohérente. Analysez les transactions dont les identifiants sont absents, les codes de statut non pris en charge, les événements en double ou les dates contradictoires avant d'élargir la période d'extraction.
Rapprochez le nombre d'événements avec l'archive source et, lorsque ces éléments sont disponibles, avec les rapports opérationnels ou les extractions d'audit FIS. Validez un échantillon de transactions de bout en bout, notamment l'approbation, le rejet, l'autorisation, l'envoi de l'instruction, l'accusé de réception du réseau, le règlement, la gestion des erreurs, le rapprochement et la logique des paiements en retard. Si la traçabilité opérationnelle est requise, conservez le nom du fichier source ainsi que la référence de ligne ou de message dans la sortie d'audit.
Planifiez l'exécution du script une fois l'archive source complète pour la période sélectionnée, ou exécutez-le progressivement avec une fenêtre de chevauchement contrôlée afin de capturer les messages pacs.002 reçus tardivement. Dédupliquez à l'aide de PaymentTransactionId, ActivityName, EventTimestamp et de l'identité du message source, tout en conservant les répétitions légitimes lorsque la source enregistre plusieurs occurrences d'une même activité.
Exportez le journal d'événements final au format CSV UTF-8, avec une ligne par événement et les colonnes PaymentTransactionId, ActivityName, EventTimestamp, ProcessingUser, PaymentAmount, CurrencyCode, PaymentType, PaymentDueDate, ActualSettlementDate et BusinessUnit. Importez le fichier dans ProcessMind et configurez PaymentTransactionId comme identifiant de dossier, ActivityName comme activité et EventTimestamp comme horodatage de l'événement. ProcessMind lit le journal d'événements tel quel et ne déduit pas les activités manquantes.

Configuration

Chemin de l'archive d'entrée : configurez le répertoire contenant les fichiers XML ISO 20022 bruts. Incluez tous les sous-répertoires pertinents si l'archive est partitionnée par date, entreprise, type de message ou statut de traitement.
Types de messages : incluez pacs.008 pour les instructions de paiement et pacs.002 pour les rapports de statut de paiement. N'ajoutez d'autres types de messages qu'après avoir validé leurs identifiants et la signification de leurs statuts dans l'implémentation FIS.
Correspondance des identifiants : configurez les expressions XPath candidates qui permettent de retrouver le Payment Transaction ID. Privilégiez l'identifiant utilisé de manière cohérente dans l'enregistrement de transaction FIS et dans tous les messages ISO 20022 associés. Ne combinez pas des identifiants sans lien sans règle de corrélation documentée.
Correspondance des activités : configurez les correspondances entre les codes de statut et de motif et les activités de création, validation, soumission pour approbation, approbation, rejet, autorisation, envoi de l'instruction, confirmation, règlement, identification de l'erreur, résolution de l'erreur et rapprochement. Le script fourni utilise des correspondances configurables et des indicateurs source explicites, plutôt que de déduire les événements ordinaires du cycle de vie à partir d'enregistrements manquants.
Période : commencez par 3 à 6 mois de données. Utilisez une période plus courte pour les tests initiaux ou les archives volumineuses, et prévoyez une période de chevauchement lorsque les messages de statut peuvent parvenir après la date initiale du paiement.
Filtres de date : configurez les dates de début et de fin à partir de l'horodatage de l'événement source lorsqu'il est disponible. Si un message ne comporte pas d'horodatage d'événement, le script peut utiliser l'horodatage de modification du fichier uniquement si cette option est explicitement activée. Ce choix doit être documenté, car il ne s'agit pas d'un horodatage d'événement métier.
Filtres d'entreprise et d'organisation : configurez les filtres relatifs à l'entreprise, à l'unité opérationnelle, à l'entité juridique, au produit de paiement ou au type de document uniquement lorsque les éléments XML correspondants sont présents et que leurs valeurs ont été validées. Utilisez [Configure based on your system] pour les filtres propres à l'implémentation.
Fuseau horaire : définissez le fuseau horaire du système source ou la règle de normalisation en UTC. Appliquez la même règle à tous les messages afin de garantir un ordre fiable des événements.
Indicateurs d'erreur et de correction : configurez les codes de statut, les codes motif ainsi que les marqueurs explicites de correction ou d'exception représentant Payment Error Identified et Payment Error Resolved. Ne classez pas chaque rejet comme une erreur, sauf si cette définition métier a été approuvée.
Indicateurs de rapprochement : configurez le statut explicite de rapprochement, le message de rapprochement, le marqueur de correspondance comptable ou le résultat de lot utilisé par l'implémentation FIS. Si le rapprochement est stocké en dehors de l'archive XML, indiquez une source approuvée et une règle de corrélation distincte.
Performances : traitez les fichiers de manière itérative plutôt que de charger toute l'archive en mémoire. Répartissez les traitements volumineux par date ou par répertoire, écrivez des résultats intermédiaires et utilisez une zone de préparation locale disposant de suffisamment d'espace disque. Pour les archives très volumineuses, parallélisez le traitement par partitions de répertoires indépendantes uniquement après avoir vérifié que l'ordre des résultats et la déduplication restent maîtrisés.
Prérequis : accès en lecture à l'archive XML, accès en écriture à l'emplacement de sortie, autorisation d'exécuter Python, accès approuvé aux données de paiement et correspondance validée des identifiants et codes de statut FIS. Cette méthode basée sur des fichiers ne suppose aucun code de transaction FIS, chemin de menu, point de terminaison API, nom de table ou licence spécifique.

a Exemple de requête python

from __future__ import annotations

import csv
import hashlib
import re
import sys
import xml.etree.ElementTree as ET
from collections import defaultdict
from datetime import date, datetime, timezone
from decimal import Decimal, InvalidOperation
from pathlib import Path
from typing import Dict, Iterable, List, Optional, Tuple

class=class="hl-string">"hl-comment"># Replace only these documented placeholders.
INPUT_DIRECTORY = Path(class="hl-string">"[Your XML archive directory]")
OUTPUT_FILE = Path(class="hl-string">"[Your ProcessMind event log output path].csv")
START_DATE = class="hl-string">"[YYYY-MM-DD]"
END_DATE = class="hl-string">"[YYYY-MM-DD]"
SOURCE_TIMEZONE = timezone.utc
COMPANY_FILTER = class="hl-string">""  class=class="hl-string">"hl-comment"># Leave empty unless a validated company or business-unit value is required.

class=class="hl-string">"hl-comment"># Update these candidates after inspecting representative FIS XML files.
IDENTIFIER_PATHS = [
    class="hl-string">"EndToEndId", class="hl-string">"TxId", class="hl-string">"InstrId", class="hl-string">"UETR", class="hl-string">"PaymentTransactionId",
    class="hl-string">"PaymentId", class="hl-string">"TransactionId"
]
AMOUNT_PATHS = [class="hl-string">"InstdAmt", class="hl-string">"IntrBkSttlmAmt", class="hl-string">"Amt", class="hl-string">"Amount"]
CURRENCY_PATHS = [class="hl-string">"InstdAmt", class="hl-string">"IntrBkSttlmAmt", class="hl-string">"Amt", class="hl-string">"Currency", class="hl-string">"Ccy"]
DUE_DATE_PATHS = [class="hl-string">"ReqdExctnDt", class="hl-string">"ReqdColltnDt", class="hl-string">"DueDate", class="hl-string">"RequestedExecutionDate"]
SETTLEMENT_DATE_PATHS = [class="hl-string">"SttlmDt", class="hl-string">"SettlementDate", class="hl-string">"ActualSettlementDate"]
TIMESTAMP_PATHS = [
    class="hl-string">"CreDtTm", class="hl-string">"AccptncDtTm", class="hl-string">"AccptncDt", class="hl-string">"OrgnlCreDtTm", class="hl-string">"TxDtTm",
    class="hl-string">"SttlmDt", class="hl-string">"SettlementDate", class="hl-string">"EventTimestamp", class="hl-string">"Timestamp"
]
USER_PATHS = [class="hl-string">"UserId", class="hl-string">"UserID", class="hl-string">"Operator", class="hl-string">"Approver", class="hl-string">"ProcessingUser", class="hl-string">"Initiator"]
PAYMENT_TYPE_PATHS = [class="hl-string">"PmtMtd", class="hl-string">"SvcLvl", class="hl-string">"LclInstrm", class="hl-string">"CtgyPurp", class="hl-string">"PaymentType"]
BUSINESS_UNIT_PATHS = [class="hl-string">"BusinessUnit", class="hl-string">"CompanyCode", class="hl-string">"Company", class="hl-string">"OrgUnit", class="hl-string">"LegalEntity"]
STATUS_PATHS = [class="hl-string">"TxSts", class="hl-string">"GrpSts", class="hl-string">"Status", class="hl-string">"PaymentStatus", class="hl-string">"TransactionStatus"]
REASON_PATHS = [class="hl-string">"Cd", class="hl-string">"Rsn", class="hl-string">"ReasonCode", class="hl-string">"StatusReason", class="hl-string">"AddtlInf"]
ERROR_PATHS = [class="hl-string">"Error", class="hl-string">"Exception", class="hl-string">"Failure", class="hl-string">"ErrorCode", class="hl-string">"ExceptionCode"]
REPAIR_PATHS = [class="hl-string">"Repair", class="hl-string">"Resolved", class="hl-string">"Resolution", class="hl-string">"ErrorResolved", class="hl-string">"ExceptionResolved"]
RECONCILIATION_PATHS = [class="hl-string">"Reconciled", class="hl-string">"ReconciliationStatus", class="hl-string">"LedgerMatched", class="hl-string">"BankStatementMatched"]

class=class="hl-string">"hl-comment"># Validate and extend these mappings against the FIS implementation.
STATUS_ACTIVITY_MAP = {
    class="hl-string">"NEW": class="hl-string">"Payment Request Created",
    class="hl-string">"RECEIVED": class="hl-string">"Payment Request Created",
    class="hl-string">"VALIDATED": class="hl-string">"Payment Details Validated",
    class="hl-string">"PENDING_APPROVAL": class="hl-string">"Payment Sent For Approval",
    class="hl-string">"AWAITING_APPROVAL": class="hl-string">"Payment Sent For Approval",
    class="hl-string">"APPROVAL_PENDING": class="hl-string">"Payment Sent For Approval",
    class="hl-string">"APPROVED": class="hl-string">"Payment Approved",
    class="hl-string">"REJECTED": class="hl-string">"Payment Rejected",
    class="hl-string">"AUTHORIZED": class="hl-string">"Payment Authorized",
    class="hl-string">"SENT": class="hl-string">"Payment Instruction Sent",
    class="hl-string">"DISPATCHED": class="hl-string">"Payment Instruction Sent",
    class="hl-string">"ACCP": class="hl-string">"Payment Confirmed",
    class="hl-string">"ACCEPTED": class="hl-string">"Payment Confirmed",
    class="hl-string">"CONFIRMED": class="hl-string">"Payment Confirmed",
    class="hl-string">"SETTLED": class="hl-string">"Payment Settled",
    class="hl-string">"BOOK": class="hl-string">"Payment Settled",
    class="hl-string">"RECONCILED": class="hl-string">"Payment Reconciled",
}
ERROR_STATUS_CODES = {class="hl-string">"RJCT", class="hl-string">"REJECTED", class="hl-string">"FAILED", class="hl-string">"ERROR", class="hl-string">"EXCEPTION", class="hl-string">"CANCELLED"}
RESOLVED_STATUS_CODES = {class="hl-string">"REPAIRED", class="hl-string">"RESOLVED", class="hl-string">"CORRECTED", class="hl-string">"REPROCESSING", class="hl-string">"REPROCESSED"}

OUTPUT_COLUMNS = [
    class="hl-string">"PaymentTransactionId", class="hl-string">"ActivityName", class="hl-string">"EventTimestamp", class="hl-string">"ProcessingUser",
    class="hl-string">"PaymentAmount", class="hl-string">"CurrencyCode", class="hl-string">"PaymentType", class="hl-string">"PaymentDueDate",
    class="hl-string">"ActualSettlementDate", class="hl-string">"BusinessUnit"
]


def local_name(tag: str) -> str:
    return tag.rsplit(class="hl-string">"}", 1)[-1].lower()


def text_values(root: ET.Element, candidates: Iterable[str]) -> List[str]:
    wanted = {candidate.lower() for candidate in candidates}
    values: List[str] = []
    for element in root.iter():
        if local_name(element.tag) in wanted:
            value = (element.text or class="hl-string">"").strip()
            if value:
                values.append(value)
            for key, attribute_value in element.attrib.items():
                if key.rsplit(class="hl-string">"}", 1)[-1].lower() in {class="hl-string">"ccy", class="hl-string">"currency"} and attribute_value.strip():
                    values.append(attribute_value.strip())
    return values


def first_value(root: ET.Element, candidates: Iterable[str]) -> str:
    values = text_values(root, candidates)
    return values[0] if values else class="hl-string">""


def normalize_code(value: str) -> str:
    return re.sub(rclass="hl-string">"[^A-Z0-9_]", class="hl-string">"", value.upper().replace(class="hl-string">"-", class="hl-string">"_"))


def parse_datetime(value: str) -> Optional[datetime]:
    if not value:
        return None
    candidate = value.strip()
    if candidate.endswith(class="hl-string">"Z"):
        candidate = candidate[:-1] + class="hl-string">"+00:00"
    try:
        parsed = datetime.fromisoformat(candidate)
    except ValueError:
        for fmt in (class="hl-string">"%Y-%m-%d %H:%M:%S", class="hl-string">"%Y-%m-%d", class="hl-string">"%Y%m%d%H%M%S", class="hl-string">"%Y%m%d"):
            try:
                parsed = datetime.strptime(value.strip(), fmt)
                break
            except ValueError:
                parsed = None
        if parsed is None:
            return None
    if parsed.tzinfo is None:
        parsed = parsed.replace(tzinfo=SOURCE_TIMEZONE)
    return parsed.astimezone(timezone.utc)


def output_timestamp(value: Optional[datetime]) -> str:
    return value.astimezone(timezone.utc).isoformat().replace(class="hl-string">"+00:00", class="hl-string">"Z") if value else class="hl-string">""


def output_date(value: str) -> str:
    parsed = parse_datetime(value)
    return parsed.date().isoformat() if parsed else (value[:10] if re.match(rclass="hl-string">"^\d{4}-\d{2}-\d{2}", value) else class="hl-string">"")


def normalize_amount(value: str) -> str:
    if not value:
        return class="hl-string">""
    try:
        return format(Decimal(value.replace(class="hl-string">",", class="hl-string">"").strip()), class="hl-string">"f")
    except InvalidOperation:
        return value.strip()


def source_message_id(path: Path, root: ET.Element) -> str:
    raw = path.as_posix() + class="hl-string">"|" + first_value(root, [class="hl-string">"MsgId", class="hl-string">"MessageId", class="hl-string">"BizMsgIdr"])
    return hashlib.sha256(raw.encode(class="hl-string">"utf-8")).hexdigest()


def in_date_range(event_time: Optional[datetime]) -> bool:
    if not event_time:
        return True
    start = datetime.fromisoformat(START_DATE).replace(tzinfo=timezone.utc)
    end = datetime.fromisoformat(END_DATE).replace(tzinfo=timezone.utc)
    return start <= event_time < end.replace(hour=23, minute=59, second=59, microsecond=999999)


def add_event(events: List[Dict[str, str]], seen: set, transaction_id: str, activity: str,
              event_time: Optional[datetime], user: str, amount: str, currency: str,
              payment_type: str, due_date: str, settlement_date: str, business_unit: str,
              message_id: str) -> None:
    if not transaction_id or not event_time or not in_date_range(event_time):
        return
    row = {
        class="hl-string">"PaymentTransactionId": transaction_id,
        class="hl-string">"ActivityName": activity,
        class="hl-string">"EventTimestamp": output_timestamp(event_time),
        class="hl-string">"ProcessingUser": user,
        class="hl-string">"PaymentAmount": amount,
        class="hl-string">"CurrencyCode": currency,
        class="hl-string">"PaymentType": payment_type,
        class="hl-string">"PaymentDueDate": output_date(due_date),
        class="hl-string">"ActualSettlementDate": output_date(settlement_date),
        class="hl-string">"BusinessUnit": business_unit,
    }
    key = (transaction_id, activity, row[class="hl-string">"EventTimestamp"], message_id)
    if key not in seen:
        seen.add(key)
        events.append(row)


def parse_file(path: Path, events: List[Dict[str, str]], seen: set) -> None:
    try:
        root = ET.parse(path).getroot()
    except (ET.ParseError, OSError) as exc:
        print(fclass="hl-string">"Could not parse {path}: {exc}", file=sys.stderr)
        return
    message_id = source_message_id(path, root)
    transaction_id = first_value(root, IDENTIFIER_PATHS)
    if not transaction_id:
        return
    business_unit = first_value(root, BUSINESS_UNIT_PATHS)
    if COMPANY_FILTER and business_unit != COMPANY_FILTER:
        return
    amount = normalize_amount(first_value(root, AMOUNT_PATHS))
    currency = first_value(root, CURRENCY_PATHS)
    if len(currency) != 3 and currency:
        currency = currency.upper()
    due_date = first_value(root, DUE_DATE_PATHS)
    settlement_date = first_value(root, SETTLEMENT_DATE_PATHS)
    user = first_value(root, USER_PATHS)
    payment_type = first_value(root, PAYMENT_TYPE_PATHS)
    status_values = text_values(root, STATUS_PATHS)
    reason_values = text_values(root, REASON_PATHS)
    error_values = text_values(root, ERROR_PATHS)
    repair_values = text_values(root, REPAIR_PATHS)
    reconciliation_values = text_values(root, RECONCILIATION_PATHS)
    event_time = parse_datetime(first_value(root, TIMESTAMP_PATHS))
    if not event_time:
        return

    message_name = next((local_name(element.tag) for element in root.iter() if local_name(element.tag) in {class="hl-string">"pacs.008", class="hl-string">"pacs.002", class="hl-string">"document"}), class="hl-string">"")
    normalized_statuses = [normalize_code(value) for value in status_values + reason_values]
    normalized_text = class="hl-string">" ".join(normalize_code(value) for value in error_values)
    normalized_repairs = class="hl-string">" ".join(normalize_code(value) for value in repair_values)
    normalized_reconciliation = class="hl-string">" ".join(normalize_code(value) for value in reconciliation_values)

    if message_name or status_values:
        add_event(events, seen, transaction_id, class="hl-string">"Payment Request Created", event_time, user, amount, currency, payment_type, due_date, settlement_date, business_unit, message_id) if any(code in {class="hl-string">"NEW", class="hl-string">"RECEIVED"} for code in normalized_statuses) else None
        add_event(events, seen, transaction_id, class="hl-string">"Payment Details Validated", event_time, user, amount, currency, payment_type, due_date, settlement_date, business_unit, message_id) if class="hl-string">"VALIDATED" in normalized_statuses else None
        add_event(events, seen, transaction_id, class="hl-string">"Payment Sent For Approval", event_time, user, amount, currency, payment_type, due_date, settlement_date, business_unit, message_id) if any(code in {class="hl-string">"PENDING_APPROVAL", class="hl-string">"AWAITING_APPROVAL", class="hl-string">"APPROVAL_PENDING"} for code in normalized_statuses) else None
        add_event(events, seen, transaction_id, class="hl-string">"Payment Approved", event_time, user, amount, currency, payment_type, due_date, settlement_date, business_unit, message_id) if class="hl-string">"APPROVED" in normalized_statuses else None
        add_event(events, seen, transaction_id, class="hl-string">"Payment Rejected", event_time, user, amount, currency, payment_type, due_date, settlement_date, business_unit, message_id) if any(code in {class="hl-string">"REJECTED", class="hl-string">"RJCT"} for code in normalized_statuses) else None
        add_event(events, seen, transaction_id, class="hl-string">"Payment Authorized", event_time, user, amount, currency, payment_type, due_date, settlement_date, business_unit, message_id) if class="hl-string">"AUTHORIZED" in normalized_statuses else None
        add_event(events, seen, transaction_id, class="hl-string">"Payment Instruction Sent", event_time, user, amount, currency, payment_type, due_date, settlement_date, business_unit, message_id) if any(code in {class="hl-string">"SENT", class="hl-string">"DISPATCHED"} for code in normalized_statuses) else None
        add_event(events, seen, transaction_id, class="hl-string">"Payment Confirmed", event_time, user, amount, currency, payment_type, due_date, settlement_date, business_unit, message_id) if any(code in {class="hl-string">"ACCP", class="hl-string">"ACCEPTED", class="hl-string">"CONFIRMED"} for code in normalized_statuses) else None
        add_event(events, seen, transaction_id, class="hl-string">"Payment Settled", event_time, user, amount, currency, payment_type, due_date, settlement_date, business_unit, message_id) if any(code in {class="hl-string">"SETTLED", class="hl-string">"BOOK"} for code in normalized_statuses) else None
        add_event(events, seen, transaction_id, class="hl-string">"Payment Reconciled", event_time, user, amount, currency, payment_type, due_date, settlement_date, business_unit, message_id) if class="hl-string">"RECONCILED" in normalized_statuses or any(code in normalized_reconciliation for code in {class="hl-string">"TRUE", class="hl-string">"MATCHED", class="hl-string">"RECONCILED"}) else None

    if any(code in ERROR_STATUS_CODES for code in normalized_statuses) or normalized_text:
        add_event(events, seen, transaction_id, class="hl-string">"Payment Error Identified", event_time, user, amount, currency, payment_type, due_date, settlement_date, business_unit, message_id)
    if any(code in RESOLVED_STATUS_CODES for code in normalized_statuses) or any(code in normalized_repairs for code in {class="hl-string">"TRUE", class="hl-string">"RESOLVED", class="hl-string">"REPAIRED", class="hl-string">"CORRECTED"}):
        add_event(events, seen, transaction_id, class="hl-string">"Payment Error Resolved", event_time, user, amount, currency, payment_type, due_date, settlement_date, business_unit, message_id)

    due = parse_datetime(due_date)
    settled = parse_datetime(settlement_date)
    if due and settled and settled.date() > due.date():
        add_event(events, seen, transaction_id, class="hl-string">"Late Payment Identified", settled, user, amount, currency, payment_type, due_date, settlement_date, business_unit, message_id)


def main() -> None:
    events: List[Dict[str, str]] = []
    seen = set()
    for path in sorted(INPUT_DIRECTORY.rglob(class="hl-string">"*.xml")):
        parse_file(path, events, seen)
    events.sort(key=lambda row: (row[class="hl-string">"PaymentTransactionId"], row[class="hl-string">"EventTimestamp"], row[class="hl-string">"ActivityName"]))
    OUTPUT_FILE.parent.mkdir(parents=True, exist_ok=True)
    with OUTPUT_FILE.open(class="hl-string">"w", newline=class="hl-string">"", encoding=class="hl-string">"utf-8") as handle:
        writer = csv.DictWriter(handle, fieldnames=OUTPUT_COLUMNS)
        writer.writeheader()
        writer.writerows(events)
    print(fclass="hl-string">"Wrote {len(events)} event rows to {OUTPUT_FILE}")


if __name__ == class="hl-string">"__main__":
    main()

Prêt à commencer ?

Utilisez ce modèle pour simplifier la collecte de vos données et commencer votre démarche d’amélioration du traitement des paiements. Identifiez les gains d’efficacité et renforcez le contrôle financier grâce à des analyses précises de vos processus.

Retour au guide d’amélioration Télécharger le modèle

Optimisez dès aujourd'hui le traitement de vos paiements FIS Global

Atteignez 98 % de traitement de bout en bout et éliminez les problèmes de rapprochement.

Démarrer l'essai gratuit maintenant

Aucune carte bancaire requise, commencez en quelques minutes

Votre modèle de données pour le traitement des paiements

Votre modèle de données pour le traitement des paiements

Attributs du traitement des paiements

Activités du traitement des paiements

Guides d'extraction

Analyse Python des fichiers journaux XML ISO 20022

Étapes

Configuration

a Exemple de requête python

Prêt à commencer ?

Optimisez dès aujourd'hui le traitement de vos paiements FIS Global

Nous attachons de l’importance à votre confidentialité