> 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 de traitement des paiements(13) Guides d’extraction(1)

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

Ce modèle présente les attributs de données et les activités de processus nécessaires à l’analyse du traitement des paiements. Il explique également comment extraire ces informations de vos systèmes. Utilisez cette ressource pour réunir les données requises à une analyse Process Mining fiable.

Attributs recommandés à collecter
Activités clés à suivre
Guide d’extraction

Vous découvrez les journaux d’événements ? Découvrez comment créer 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 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é a eu lieu.
Description Cet attribut fournit le contexte temporel de chaque événement du processus de paiement. Il consigne le moment exact où une action a été enregistrée par le système, ce qui permet de remettre les activités dans l’ordre chronologique. L’analyse s’en sert pour calculer les délais entre les étapes, les temps de cycle totaux et les taux de traitement. Elle permet de repérer les goulots d’étranglement en mettant en évidence les retards entre certaines étapes du processus. Pourquoi est-ce important ? Sans ce champ, l’analyse temporelle est impossible : il sert au calcul de tous les indicateurs de performance et d’efficacité. Où trouver ces données 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 de paiement ou de la transaction concernée.
Description Cet attribut sert de clé centrale pour 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, en passant par la validation et l’approbation, jusqu’au règlement final ou au rapprochement. 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 à tous les indicateurs calculés par dossier, comme le temps de cycle et les boucles de reprise. Pourquoi est-ce important ? Il constitue le lien fondamental du Process Mining et permet de reconstituer un parcours cohérent à partir d’activités disparates. Où trouver ces données 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 ou de l’événement précis du processus qui a eu lieu.
Description Ce champ consigne l’action 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 s’appuient sur cet attribut pour comprendre l’ordre 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 répétées. Pourquoi est-ce important ? Il définit le « quoi » du processus et permet de visualiser les cartographies de processus et d’analyser les variantes. Où trouver ces données Consulter la documentation de FIS Global Exemples Payment Request CreatedPayment Details ValidatedPayment ApprovedPaiement réglé
	Code de devise CurrencyCode	Code ISO à trois lettres indiquant 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 des flux de paiements internationaux. L’analyse de ce champ permet de comparer les performances des processus selon la devise, souvent liée à des systèmes de compensation et à des réglementations différents. Elle aide à expliquer les écarts de délai de règlement entre les paiements transfrontaliers et nationaux. Pourquoi est-ce important ? Indispensable dans les environnements multidevises pour interpréter correctement les volumes financiers. Où trouver ces données 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 indique l’échéance du paiement, fixée par le demandeur ou définie dans les conditions de facturation. Il sert de référence pour mesurer le respect des délais. Ce champ est essentiel au Dashboard de respect des échéances de paiement. En comparant cette date à la date réelle de règlement, les analystes peuvent repérer les retards, calculer les pénalités éventuelles et vérifier le respect des accords conclus avec les fournisseurs. Pourquoi est-ce important ? Il sert de référence pour mesurer le respect des niveaux de service et des délais. Où trouver ces données 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 indique la date effective du transfert des fonds ou celle à laquelle la transaction a été considérée comme terminée. Contrairement à l’horodatage de traitement, il correspond à la date de valeur. L’analyse le combine à la date d’échéance pour calculer le taux de paiements effectués à temps. Il déclenche également la phase de rapprochement et est donc essentiel à l’analyse du temps de cycle de rapprochement des paiements. Pourquoi est-ce important ? Il marque la finalisation financière du paiement et joue un rôle clé dans l’analyse des flux de trésorerie. Où trouver ces données 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 le principal indicateur pour analyser les volumes financiers et les risques. Les analystes s’en servent pour segmenter les processus selon le montant des paiements, car les paiements de montant élevé et ceux de faible montant suivent souvent des circuits d’approbation différents. Il alimente le Dashboard des volumes de paiements et aide à déterminer si les paiements importants ont des temps de cycle plus longs en raison de contrôles plus stricts. Pourquoi est-ce important ? Il apporte une dimension financière au Process Mining et permet de définir les priorités en fonction des montants. Où trouver ces données 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 les paiements par type, par exemple virement bancaire, ACH, SEPA, paiement en temps réel (RTP) ou chèque. Chaque type de paiement suit des règles de traitement et des SLA qui lui sont propres. Les analystes s’en servent pour comparer le temps de cycle de rapprochement des paiements entre les différents circuits. Cela permet de comprendre pourquoi certains paiements sont réglés immédiatement tandis que d’autres prennent plusieurs jours, et de mesurer les performances par rapport au bon référentiel. Pourquoi est-ce important ? Il s’agit de la principale dimension pour segmenter les flux de processus, car chaque type présente des caractéristiques de routage et de délai qui lui sont propres. Où trouver ces données Consulter la documentation de FIS Global Exemples Virement bancaireVirement ACHVirement instantané SEPAChèque
	Unité opérationnelle BusinessUnit	Division ou service interne à l’origine du paiement.
Description Cet attribut associe le paiement à une unité organisationnelle précise, par exemple « Banque de détail », « Financement commercial » ou « Trésorerie ». Il sert à agréger par service des indicateurs tels que le volume de paiements et le temps de cycle moyen des paiements. La direction peut ainsi comparer les performances des différentes divisions et répartir les ressources de manière adaptée. Pourquoi est-ce important ? Il permet de comparer les performances en interne et de déterminer les responsabilités en matière de performance des processus. Où trouver ces données Consulter la documentation de FIS Global Exemples TrésorerieComptes fournisseursOpérations de banque de détailGestion de patrimoine
	Utilisateur chargé du traitement ProcessingUser	Identifiant ou nom de l’utilisateur ou de l’agent système qui effectue 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 liés aux interventions manuelles et à vérifier la séparation des tâches. Elles permettent de calculer le taux d’utilisation des utilisateurs chargés du traitement et de distinguer les tâches manuelles des tâches automatisées. Pourquoi est-ce important ? Indispensable à l’analyse des ressources, au calcul des taux d’automatisation et aux audits de conformité. Où trouver ces données Consulter la documentation de FIS Global Exemples jsmithSYSTEM_AUTOBOTmdoe_approverAPI_GATEWAY
	Autorité d’approbation ApprovalAuthority	Rôle, groupe ou personne chargé d’autoriser le paiement.
Description Cet attribut indique le niveau d’autorité ou le groupe d’utilisateurs requis pour approuver le paiement, souvent en fonction du montant. Il permet de suivre le circuit d’approbation. Les analystes s’en servent pour alimenter le Dashboard des goulots d’étranglement dans l’autorisation des paiements. Ils peuvent ainsi comparer les délais d’approbation selon le niveau d’autorité et déterminer si certains échelons de direction sont à l’origine de retards. Pourquoi est-ce important ? Il permet d’analyser la hiérarchie des approbations et de repérer les goulots d’étranglement. Où trouver ces données Consulter la documentation de FIS Global Exemples Responsable de niveau 1CFOÉquipe de 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 par quel canal la transaction a été saisie. Les analystes s’en servent pour comparer l’efficacité du traitement selon les canaux. Ils peuvent, par exemple, vérifier si les paiements initiés par API présentent moins d’erreurs que ceux saisis manuellement en agence. Pourquoi est-ce important ? Il aide à optimiser les canaux et à mieux comprendre le comportement des clients. Où trouver ces données Consulter la documentation de FIS Global Exemples Banque en ligneApplication mobilePasserelle d’entrepriseGuichet d’agence
	Code d’erreur de validation ValidationErrorCode	Code ou motif indiquant pourquoi la validation du paiement a échoué.
Description Cet attribut est renseigné lorsque le paiement passe à l’activité « Erreur de paiement détectée ». Il contient des précisions sur l’échec, par exemple « IBAN invalide », « Fonds insuffisants » ou « Adresse du bénéficiaire manquante ». Ce champ alimente le Dashboard des taux d’erreur de validation des données de paiement. Le regroupement des résultats par attribut révèle les causes les plus fréquentes de reprise et permet de corriger les problèmes de saisie en amont ou de configuration du système. Pourquoi est-ce important ? Il permet d’identifier les causes profondes des difficultés du processus et des boucles de reprise. Où trouver ces données Consulter la documentation de FIS Global Exemples ERR-001 : Compte invalideERR-055 : Correspondance avec une liste de sanctionsERR-009 : Transaction en double
	Compte débité SenderAccount	Numéro du compte sur lequel les fonds sont prélevés.
Description Cet attribut identifie le compte source de la transaction. Il permet d’analyser plus précisément les paiements effectués à partir de comptes internes spécifiques. L’analyse aide à déterminer si certains comptes de financement sont plus sujets aux erreurs, par exemple en cas de fonds insuffisants, ou aux retards. Cet attribut facilite également le rapprochement en permettant d’associer les écritures du grand livre aux activités du processus. Pourquoi est-ce important ? Il est indispensable au rapprochement financier et à la résolution des problèmes liés aux comptes. Où trouver ces données 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 si les données utilisées dans l’analyse sont à jour. Il aide les utilisateurs à savoir s’ils consultent des données en temps réel ou un instantané d’une période antérieure. Dans un Dashboard, ce champ sert souvent à afficher la date de mise à jour des données. Il permet de prendre des décisions à partir des informations les plus récentes disponibles et facilite la gestion des chargements incrémentiels de données. Pourquoi est-ce important ? Il indique l’actualité des données et renforce la confiance dans la fraîcheur des rapports. Où trouver ces données 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 manuelle.
Description Cet attribut booléen signale les activités ou les dossiers qui ont nécessité une intervention humaine, comme la résolution d’une erreur de paiement ou une approbation manuelle, par opposition au traitement entièrement automatisé (STP). Il est essentiel au Dashboard du taux d’intervention manuelle dans les paiements. Il permet de mesurer la part des paiements qui ne sont pas entièrement automatisés et de repérer les possibilités de transformation numérique. Pourquoi est-ce important ? Il distingue les volumes traités automatiquement du travail manuel et aide à calculer le retour sur investissement de l’automatisation. Où trouver ces données 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 Cet attribut booléen calculé renvoie « vrai » si la date de règlement du paiement est postérieure à sa date d’échéance. Il alimente directement l’indicateur de taux de paiements effectués à temps. Il simplifie la création de Dashboards : les utilisateurs peuvent filtrer rapidement les dossiers problématiques sans avoir à définir de logique complexe sur les dates dans la couche de visualisation. Pourquoi est-ce important ? Il simplifie le suivi des exceptions et l’analyse de la conformité. Où trouver ces données Dérivé de PaymentDueDate et ActualSettlementDate Exemples truefalse
	Pays du bénéficiaire BeneficiaryCountry	Code du pays du destinataire du paiement.
Description Cet attribut indique le pays de destination des fonds. Il permet de 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 d’autres intermédiaires, contrôles de conformité et délais de traitement. L’analyse des performances par pays permet donc d’isoler ces facteurs. Pourquoi est-ce important ? Il constitue une dimension importante pour l’analyse géographique et l’évaluation des risques de conformité. Où trouver ces données Consulter la documentation de FIS Global Exemples États-UnisAllemagneChineRoyaume-Uni
	Système source SourceSystem	Nom du système d’où proviennent les données de l’événement.
Description Cet attribut identifie le composant logiciel ou la base de données d’où l’enregistrement a été extrait, par exemple le système bancaire central, la passerelle de paiement ou l’outil de filtrage des sanctions. Il est essentiel pour assurer la traçabilité des données et les valider. Lors de l’analyse de flux de bout en bout couvrant plusieurs plateformes, ce champ permet de déterminer où les activités ont eu lieu et facilite le diagnostic des problèmes de qualité des données. Pourquoi est-ce important ? Il garantit la traçabilité et fournit le contexte nécessaire, notamment dans les environnements complexes où plusieurs moteurs de paiement sont intégrés. Où trouver ces données Consulter la documentation de FIS Global Exemples FIS OPFTraxPaymentHub_01SanctionsScreeningDB

Obligatoire Recommandé Facultatif

Activités de traitement des paiements

Voici les principales étapes et les jalons à enregistrer dans votre journal d’événements pour découvrir et optimiser le processus avec précision.

6 Recommandé 7 Facultatif

	Activité	Description
	Paiement rapproché	Il s’agit de la dernière activité comptable : 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 est-ce important ? Cette activité marque la fin du cycle de vie du paiement. L’analyse du temps de cycle de rapprochement des paiements est essentielle pour comprendre l’efficacité des processus de clôture financière. Où trouver ces données Souvent déduit du renseignement du champ « reconciliation_date » ou du passage du statut final à « Rapproché » dans un module financier ou comptable relié au système de paiement. Données à recueillir Identifié par le renseignement d’une date de rapprochement ou par un changement de statut à « Rapproché ». Type d’événement inferred
	Paiement réglé	Cette activité marque la fin du transfert de fonds : la transaction est alors considérée comme réglée sur le plan financier. Elle est généralement enregistrée à la réception de la confirmation définitive du réseau de paiement ou de la chambre de compensation.
Pourquoi est-ce important ? Il s’agit du point de fin principal pour mesurer le temps de cycle du paiement et le taux de paiements effectués à temps. Il marque la réussite de l’exécution du processus de paiement. Où trouver ces données Déduit d’un changement de statut final de l’enregistrement du paiement, qui passe à « Réglé », « Terminé » ou « Comptabilisé ». Ce changement est déclenché par des fichiers de règlement par lots ou des messages en temps réel du système de compensation. Données à recueillir Changement du statut de la transaction de paiement à « Réglé » ou à un statut équivalent. Type d’événement inferred
	Payment Approved	Cette étape clé correspond à l’approbation du paiement par un utilisateur habilité, qui peut alors passer à l’étape suivante. Il s’agit presque toujours d’un événement explicite enregistré avec l’identifiant de l’approbateur et l’horodatage de son intervention dans le système.
Pourquoi est-ce important ? Ce point de contrôle est essentiel pour mesurer les temps de cycle d’approbation et vérifier le respect des contrôles financiers. Les retards à cette étape peuvent nuire considérablement au respect des échéances de paiement. Où trouver ces données L’événement est enregistré dans une table de journal des approbations ou explicitement dans l’historique principal des transactions. Le journal d’événements associe le Payment Transaction ID, l’identifiant de l’approbateur et l’horodatage de l’approbation. Données à recueillir Événement enregistré lorsqu’un utilisateur disposant des droits d’approbation approuve un paiement. Type d’événement explicit
	Payment Authorized	Cette activité correspond à une étape finale d’autorisation, souvent requise pour les paiements de montant élevé ou par une autre autorité après l’approbation initiale. Elle est enregistrée explicitement lorsqu’un utilisateur disposant des droits d’autorisation confirme le paiement.
Pourquoi est-ce important ? Cette activité est essentielle au Dashboard « Payment Authorization Bottlenecks ». La distinguer de « Payment Approved » permet de repérer les retards dans les processus d’approbation à plusieurs niveaux. Où trouver ces données L’événement est enregistré dans un journal d’audit ou de transactions. Il est déclenché lorsqu’un utilisateur disposant de droits d’autorisation spécifiques intervient sur le paiement, ce qui crée un enregistrement avec son identifiant et un horodatage. Données à recueillir Une entrée explicite est créée dans le journal lorsqu’un utilisateur effectue l’autorisation finale. Type d’événement explicit
	Payment Instruction Sent	Cette activité marque le moment où le système FIS envoie l’instruction de paiement finalisée au réseau de paiement concerné, comme ACH, Fedwire ou SWIFT. Il s’agit d’un événement système essentiel.
Pourquoi est-ce important ? Cette étape importante 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ù trouver ces données L’événement est enregistré dans un journal des transactions ou des messages qui suit les communications avec les réseaux de paiement externes. Recherchez un enregistrement indiquant l’envoi réussi d’un message sortant, avec son horodatage. Données à recueillir É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
	Payment Request Created	Il s’agit du premier événement du cycle de vie du paiement : une nouvelle transaction est lancé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 demande de paiement.
Pourquoi est-ce important ? Cette activité marque le début du processus. Elle est indispensable pour mesurer le temps de cycle de bout en bout et analyser le volume global de paiements ainsi que la capacité de traitement. Où trouver ces données L’événement est enregistré dans une table centrale des transactions. Il est identifié par l’horodatage de création associé au Payment Transaction ID. Recherchez des tables telles que 'Payment_Transactions' ou 'Payment_Requests' et des champs comme 'creation_date' ou 'entry_date'. Données à recueillir Événement enregistré lors de la création d’une nouvelle transaction de paiement. Type d’événement explicit
	Erreur de paiement détectée	Indique qu’une erreur a été détectée après la validation initiale, par exemple un rejet de la banque destinataire ou une alerte interne de conformité. Il s’agit souvent d’un événement explicite enregistré lors du signalement d’une exception.
Pourquoi est-ce important ? Cette activité marque le début de toutes les reprises et boucles de traitement des exceptions. Elle est essentielle au calcul des indicateurs de taux d’intervention manuelle et de délai de résolution des erreurs de paiement. Où trouver ces données Enregistré dans un module de gestion des exceptions ou dans un journal des transactions. L’événement peut être déclenché automatiquement par une règle système ou manuellement lorsqu’un utilisateur signale un problème. Un code d’erreur et un horodatage sont alors consignés. Données à recueillir Une exception ou un code d’erreur est associé à la transaction de paiement dans le journal. Type d’événement explicit
	Erreur de paiement résolue	Marque la résolution d’une erreur de paiement précédemment détectée, ce qui permet de retraiter ou d’annuler le paiement. Un utilisateur effectue explicitement cette action pour lever le statut d’exception.
Pourquoi est-ce important ? Cette activité clôt la boucle de traitement de l’exception. Le délai entre « Erreur détectée » et cet événement est un indicateur important de l’efficacité opérationnelle du traitement des exceptions. Où trouver ces données Enregistré lorsqu’un utilisateur efface un indicateur d’erreur ou retire la transaction d’une file d’exceptions. Cette action est consignée avec un horodatage dans une piste d’audit ou un historique des transactions. Données à recueillir Une action de l’utilisateur efface l’état d’erreur, et cette action est consignée dans un journal d’audit. Type d’événement explicit
	Paiement en retard détecté	É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 : elle est calculée en comparant deux champs de date.
Pourquoi est-ce important ? Cette activité calculée alimente directement l’indicateur de taux de paiements effectués à temps et le Dashboard de respect des échéances de paiement. Elle permet de quantifier les effets des retards de traitement sur les relations avec les fournisseurs et sur les éventuels frais de retard. Où trouver ces données Cet événement n’est pas extrait directement. Il est calculé lors de la transformation des données, en comparant l’horodatage de la date de règlement au champ de date d’échéance du paiement. Si le règlement intervient après l’échéance, l’événement est généré. Données à recueillir Calculé si « Date de règlement » > « Date d’échéance du paiement ». Type d’événement calculated
	Payment Confirmed	Indique la réception d’un accusé de réception du réseau de paiement ou de la banque 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 est-ce important ? La confirmation garantit que le paiement est arrivé à destination. Le délai entre « Instruction envoyée » et « Confirmé » mesure la latence du réseau externe et le temps de traitement. Où trouver ces données Généré à partir de l’analyse des messages de confirmation entrants des réseaux de paiement. Le système met à jour le statut du paiement et enregistre l’horodatage de confirmation. Données à recueillir Un message entrant du réseau de compensation met à jour le statut du paiement et le fait passer à « Confirmé ». Type d’événement explicit
	Payment Details Validated	Cette activité indique que les données de paiement ont passé les premiers contrôles automatisés de format, d’exhaustivité et d’exactitude. Elle est souvent déduite d’un changement de statut de l’enregistrement du paiement, par exemple de 'New' à 'Validated' ou à 'Pending Approval'.
Pourquoi est-ce important ? Le suivi de cette activité permet de repérer la fréquence et l’origine des erreurs de saisie. Il est nécessaire pour analyser le KPI du taux d’erreur de validation des données de paiement et comprendre les causes des reprises. Où trouver ces données L’événement est déduit d’un champ de statut ou d’état dans la table des transactions de paiement. Le passage de l’état initial à l’état 'validated', accompagné de l’horodatage correspondant, marque cet événement. Données à recueillir L’événement est identifié par le passage du champ de statut du paiement à 'Validated' ou à une valeur équivalente. Type d’événement inferred
	Payment Rejected	Cette activité se produit lorsqu’un approbateur refuse une demande de paiement. Celle-ci doit généralement être corrigée puis soumise à nouveau, ou annulée. Cette action explicite de l’utilisateur est enregistrée à des fins d’audit.
Pourquoi est-ce important ? Le suivi des refus permet de repérer les causes fréquentes d’échec des paiements, les écarts de processus et les boucles de reprise. Il met en évidence les problèmes de qualité des données initiales ou de conformité. Où trouver ces données L’événement est enregistré explicitement dans une table d’historique des approbations ou des transactions lorsque l’approbateur sélectionne l’option 'reject'. L’enregistrement comprend généralement un horodatage, l’identifiant de l’utilisateur et, souvent, un code de motif. Données à recueillir Événement enregistré lorsqu’un utilisateur refuse un paiement. Type d’événement explicit
	Payment Sent For Approval	Cette activité correspond à la soumission d’un paiement validé dans le flux de travail d’approbation. Elle est généralement enregistrée par un changement de statut indiquant que le paiement attend désormais l’intervention d’un approbateur.
Pourquoi est-ce important ? Cette activité marque le début du sous-processus d’approbation. L’analyse du temps écoulé entre cette activité et 'Payment Approved' est essentielle pour repérer les goulots d’étranglement liés aux approbations. Où trouver ces données L’événement est déduit du passage du champ de statut du paiement à 'Pending Approval', 'Submitted for Approval' ou à un état similaire dans un flux de travail ou un journal des statuts de transaction. Données à recueillir Changement du statut de la transaction de paiement de 'Validated' à 'Pending Approval'. Type d’événement inferred

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 accessible du système de fichiers. Obtenez le chemin d’archive, la convention de nommage des fichiers, la configuration des espaces de noms, la durée de conservation et la correspondance entre l’ID de transaction de paiement 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 paquet 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 et les filtres propres à votre entreprise dans la section de configuration du script. Remplacez uniquement les valeurs fictives documentées. Ne supposez pas qu’un nom de fichier ou un élément XML contient l’identifiant de cas ProcessMind avant d’avoir validé la correspondance des identifiants sur des fichiers représentatifs.
Examinez des fichiers pacs.008 et pacs.002 représentatifs de transactions réussies, rejetées, échouées, corrigées et réglées. Vérifiez les espaces de noms XML et repérez 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 de motif, l’horodatage de l’événement, l’utilisateur ou l’agent système chargé du traitement, le type de paiement et l’unité opérationnelle. Mettez à jour les chemins XPath configurés 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. Il ne crée Late Payment Identified que si 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é requis peuvent apparaître et que les horodatages sont normalisés de façon cohérente. Examinez les transactions dont les identifiants sont manquants, 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.
Comparez le nombre d’événements à celui de l’archive source et, si possible, aux rapports opérationnels ou aux 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 de retard de paiement. Si la traçabilité opérationnelle l’exige, conservez le nom du fichier source et la référence de ligne ou de message dans les données d’audit.
Planifiez l’exécution du script une fois l’archivage de la période terminé, ou lancez-le de façon incrémentielle avec une période de chevauchement contrôlée pour récupérer les messages pacs.002 arrivés tardivement. Dédupliquez les événements à l’aide de PaymentTransactionId, ActivityName, EventTimestamp et de l’identifiant du message source, tout en conservant les répétitions légitimes lorsque la source enregistre plusieurs occurrences.
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 définissez PaymentTransactionId comme identifiant de cas, 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 répartie par date, entreprise, type de message ou statut de traitement.
Types de message : incluez pacs.008 pour les instructions de paiement et pacs.002 pour les rapports de statut de paiement. N’ajoutez d’autres types de message qu’après avoir validé leurs identifiants et la signification de leurs statuts dans l’implémentation FIS.
Correspondance des identifiants : configurez les chemins XPath candidats permettant de retrouver l’ID de transaction de paiement. Privilégiez l’identifiant utilisé de façon cohérente dans l’enregistrement de transaction FIS et dans tous les messages ISO 20022 associés. Ne combinez pas des identifiants sans lien entre eux sans règle de corrélation documentée.
Association 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, détection d’erreur, résolution d’erreur et rapprochement. Le script fourni utilise des correspondances configurables et des indicateurs explicites de la source, 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. Pour les premiers tests ou les archives volumineuses, choisissez une période plus courte. Prévoyez un chevauchement si des messages de statut peuvent arriver 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 activée explicitement. Documentez ce recours, car il ne s’agit pas de l’horodatage d’un événement métier.
Filtres d’entreprise et d’organisation : configurez des filtres sur l’entreprise, l’unité opérationnelle, l’entité juridique, le produit de paiement ou le type de document uniquement si 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 à votre 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 pour garantir un ordre fiable des événements.
Indicateurs d’erreur et de correction : configurez les codes de statut, les codes de motif et les marqueurs explicites de correction ou d’exception correspondant à Payment Error Identified et Payment Error Resolved. Ne classez pas chaque rejet comme une erreur, sauf si cette définition a été approuvée par l’entreprise.
Indicateurs de rapprochement : configurez le statut de rapprochement explicite, le message de rapprochement, le marqueur de correspondance avec le grand livre ou le résultat de lot utilisé par l’implémentation FIS. Si les données de rapprochement sont stockées hors de l’archive XML, indiquez une autre source approuvée et la règle de corrélation correspondante.
Performances : traitez les fichiers les uns après les autres au lieu 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 prévoyez suffisamment d’espace disque dans une zone de préparation locale. Pour les très grandes archives, répartissez le traitement entre des 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 des codes de statut FIS. Cette méthode fondée sur des fichiers ne suppose aucun code de transaction, chemin de menu, point de terminaison API, nom de table ou licence FIS en particulier.

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 données et lancer l’amélioration de votre processus de traitement des paiements. Repérez les gains d’efficacité possibles et renforcez le contrôle financier grâce à une analyse précise de vos processus.

Retour au guide d’amélioration

Télécharger le modèle