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

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

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

Ce modèle propose une méthode structurée pour préparer vos données de traitement des paiements à l’analyse. Il présente les attributs essentiels à collecter, les activités importantes à suivre et des conseils pratiques pour extraire ces informations de votre système. En suivant ces recommandations, vous disposerez d’une base fiable pour identifier les inefficacités et optimiser vos opérations financières.
  • Attributs recommandés à collecter
  • Activités clés à suivre
  • Recommandations d'extraction pour ACI Worldwide
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.

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 9 Recommandé 7 Facultatif
Nom Description
Horodatage de l’événement
EventTimestamp
Date et heure précises auxquelles l'activité a eu lieu.
Description

Cet attribut enregistre le moment exact où un événement s'est produit dans l'environnement ACI. Il sert à calculer toutes les métriques temporelles, notamment les temps de cycle, les durées d'approbation et les taux de traitement. Une précision élevée, à la milliseconde, est préférable pour ordonner correctement les étapes automatisées qui se succèdent rapidement.

Pourquoi c’est important

Essentiel pour ordonner les événements et calculer les durées de performance.

Où les obtenir

Consultez les colonnes « Created Date » ou « Update Date » dans l'historique des transactions ou les tables d'audit.

Exemples
2023-10-25T08:30:15.000Z2023-10-25T08:30:22.500Z2023-10-26T14:10:00.000Z
Identifiant de la transaction de paiement
PaymentTransactionId
Identifiant unique de l'instruction de paiement concernée dans l'ensemble du système ACI.
Description

Cet attribut constitue la clé centrale de l'analyse de Process Mining. Il relie tous les événements associés à une même demande de paiement. Dans les systèmes ACI Worldwide, tels que MTS ou UPP, il correspond au numéro de référence unique attribué à une transaction lors de sa saisie. Il permet de reconstituer le parcours complet du paiement, depuis la demande initiale jusqu'à la validation, l'approbation et le règlement final.

Pourquoi c’est important

Il s'agit du Case ID fondamental requis pour regrouper des événements distincts en instances de processus.

Où les obtenir

Consultez les tables d'en-tête des transactions, souvent identifiées par TRN_REF, REFERENCE_NUM ou UUID dans le journal principal des transactions.

Exemples
TRX-2023-899102ACI-99281-AAPAY-0019283420231025-9981
Nom de l’activité
ActivityName
Étape précise ou changement d'état intervenu au cours du cycle de vie du paiement.
Description

Cet attribut définit le nœud d’événement dans la carte du processus, par exemple « Payment Request Created » ou « Funds Transferred ». Dans les systèmes ACI, il est souvent déduit des codes d’état, des types d’opérations du journal d’audit ou des changements d’état du flux de travail. L’association précise de ces états techniques avec des activités métier compréhensibles est essentielle pour obtenir une visualisation pertinente.

Pourquoi c’est important

Il définit le flux du processus et est nécessaire pour visualiser la séquence des opérations.

Où les obtenir

Dérivé des codes d'état, par exemple 100=Created et 200=Validated, ou des colonnes d'action du journal d'audit.

Exemples
Demande de paiement crééePaiement autoriséPaiement régléÉchec du paiement
Canal de traitement
ProcessingChannel
Canal par lequel le paiement a été initié.
Description

Indique le point d'entrée du paiement, par exemple Mobile, Web Portal, API ou File Upload. Cet attribut permet d'analyser les variantes du processus de paiement afin de déterminer si certains canaux sont davantage sujets aux erreurs ou aux retards.

Pourquoi c’est important

Segmente la performance selon la méthode de saisie.

Où les obtenir

En-tête de transaction, souvent dans des colonnes nommées CHANNEL, SOURCE_TYPE ou INPUT_METHOD.

Exemples
SWIFTBanque en ligneApplication mobileTéléversement de fichier
Code d’erreur
ErrorCode
Code généré lorsqu'un paiement échoue ou nécessite une correction.
Description

Enregistre la raison précise d'un événement « Payment Failed » ou « Payment Error Identified ». Le regroupement selon cet attribut dans le Dashboard « Payment Failure and Rework Analysis » permet à l'entreprise d'identifier les causes profondes les plus fréquentes des échecs, par exemple « Insufficient Funds » ou « Invalid Account ».

Pourquoi c’est important

Essentiel pour l'analyse des causes profondes des défaillances du processus.

Où les obtenir

Journaux d'erreurs ou colonnes indiquant le motif de l'état, souvent REASON_CODE ou RETURN_CODE.

Exemples
R01AM04BE05TECH_ERR_001
Date d’échéance du paiement
PaymentDueDate
Date à laquelle le paiement doit être réglé pour être considéré comme effectué dans les délais.
Description

Enregistre la date d'exécution contractuelle ou demandée. Cette date est comparée à la date réelle de règlement afin de calculer le KPI « On-Time Payment Rate » et d'alimenter le Dashboard « Payment Due Date Compliance ».

Pourquoi c’est important

Référence pour mesurer la conformité aux SLA et le respect des délais.

Où les obtenir

Instructions de transaction, généralement VALUE_DATE, EXECUTION_DATE ou DUE_DATE.

Exemples
2023-11-012023-11-05
Devise du paiement
PaymentCurrency
Code monétaire ISO du montant du paiement.
Description

Précise la devise dans laquelle le PaymentAmount est exprimé, par exemple USD, EUR ou GBP. Cet attribut est essentiel pour normaliser les données dans les Dashboards qui agrègent les volumes de plusieurs régions. Il aide à comprendre les difficultés propres aux paiements transfrontaliers.

Pourquoi c’est important

Nécessaire pour interpréter correctement le Payment Amount.

Où les obtenir

Tables de détail des transactions, généralement avec des champs tels que CCY, CURRENCY_CODE ou ISO_CODE.

Exemples
USDEURGBPJPY
Est une reprise
IsRework
Indicateur précisant si le paiement a fait l'objet d'activités répétées.
Description

Indicateur booléen calculé lors du traitement des données. Il prend la valeur true lorsque des activités telles que « Payment Details Validated » se produisent plusieurs fois ou lorsqu'une boucle d'erreur est détectée. Il alimente le KPI « Payment Rework Rate ».

Pourquoi c’est important

Identifie rapidement les cas inefficaces sans requêtes de processus complexes.

Où les obtenir

Calculé dans le pipeline de données en recherchant les activités en double pour chaque cas.

Exemples
truefalse
Montant du paiement
PaymentAmount
Valeur monétaire de la transaction de paiement.
Description

Indique la valeur financière transférée. Il s'agit d'un champ de contexte important pour analyser le « Payments Throughput » et hiérarchiser les goulots d'étranglement. Les paiements de montant élevé suivent souvent des circuits d'approbation plus rigoureux, avec une analyse des variantes, que les flux automatisés de faible montant.

Pourquoi c’est important

Permet de segmenter les paiements par valeur et de calculer le volume total traité.

Où les obtenir

Tables de détail des transactions, généralement avec des champs tels que AMT, TRANS_AMOUNT ou PRINCIPAL_AMOUNT.

Exemples
1500.00250000.5050.001000000.00
Service
Department
Service interne responsable de l'activité en cours.
Description

Associe EventUser ou la file d'attente à une unité organisationnelle plus large, par exemple « Payment Operations », « Compliance » ou « Treasury ». Cela permet, dans l'analyse des goulots d'étranglement par activité, de voir quelles équipes ralentissent le processus.

Pourquoi c’est important

Agrège la performance par fonction métier.

Où les obtenir

Dérivé des tables utilisateurs ou de la mise en correspondance avec la hiérarchie organisationnelle.

Exemples
OpérationsComplianceTrésorerieSupport informatique
Type de paiement
PaymentType
Classification de l'instrument de paiement.
Description

Catégorise le paiement, par exemple Wire, ACH, SEPA ou RTGS. Les différents types de paiement présentent souvent des SLA et des flux de processus très différents. Cet attribut constitue une dimension principale pour filtrer le Dashboard « End-to-End Payment Cycle Time ».

Pourquoi c’est important

Essentiel pour distinguer les flux de paiement rapides des flux traités par lots.

Où les obtenir

En-tête de transaction, avec des champs tels que PMT_TYPE, INSTRUMENT_TYPE ou SERVICE_ID.

Exemples
Virement nationalVirement internationalCrédit ACHPaiement instantané
Utilisateur de l’événement
EventUser
Identifiant de l'utilisateur ou de l'agent système responsable de l'activité.
Description

Indique qui a effectué l'action, qu'il s'agisse d'un utilisateur humain, par exemple pour les approbations, ou d'un compte système, par exemple pour le règlement automatisé. Cet attribut est essentiel pour l'analyse des goulots d'étranglement, car il permet d'identifier les utilisateurs ou les files d'attente surchargés.

Pourquoi c’est important

Permet d'analyser les ressources et de contrôler la séparation des tâches.

Où les obtenir

Journaux d'audit ou colonnes « UpdatedBy » dans les tables de transactions.

Exemples
SYSTEM_AGENT_01j.doeapprover_group_aBATCH_PROCESS
Dernière mise à jour des données
LastDataUpdate
Horodatage de la dernière extraction ou mise à jour de l'enregistrement dans le modèle de données.
Description

Suit l'actualité des données utilisées dans l'analyse. Il ne représente pas l'heure d'un événement de processus, mais le moment technique de l'ingestion des données. Il permet aux analystes de savoir s'ils consultent des données en temps réel ou des instantanés historiques.

Pourquoi c’est important

Garantit l'actualité des données et aide à repérer les données obsolètes dans les Dashboards.

Où les obtenir

Heure système au moment de l'exécution du script ETL.

Exemples
2023-10-27T00:00:00.000Z2023-10-27T12:00:00.000Z
Durée du cycle d’approbation
ApprovalCycleTime
Durée passée dans la phase d'approbation.
Description

Calcule le délai entre « Payment Sent For Approval » et « Payment Approved » ou « Rejected ». Cette métrique alimente le Dashboard « Payment Approval Cycle Time Analysis » et met en évidence les retards dans les étapes nécessitant une décision humaine.

Pourquoi c’est important

Isole la partie du processus qui dépend d'une intervention humaine.

Où les obtenir

Calcul : Timestamp(Payment Approved) - Timestamp(Payment Sent For Approval).

Exemples
4 heures15 minutes
Identifiant du rapprochement
ReconciliationId
Identifiant reliant le paiement au grand livre général ou à l'enregistrement de rapprochement.
Description

Cet identifiant est renseigné lorsque l'activité « Payment Reconciled » se produit. Il garantit la correspondance entre le paiement dans le moteur de traitement et l'écriture dans le système comptable. L'absence de cet identifiant pour des paiements réglés indique des échecs de rapprochement.

Pourquoi c’est important

Essentiel pour le Dashboard « Payment Reconciliation Efficiency ».

Où les obtenir

Tables de rapprochement ou champs spécifiques tels que RECON_REF ou GL_REF.

Exemples
REC-9921GL-Entry-2023-11
Nom du bénéficiaire
BeneficiaryName
Nom de l'entité qui reçoit le paiement.
Description

Identifie la contrepartie de la transaction. L'analyse de ce champ peut aider à repérer les fournisseurs ou les clients associés à des taux élevés de reprise ou à des retards, et à alimenter l'analyse des échecs et des reprises de paiement.

Pourquoi c’est important

Identifie le destinataire du paiement, ce qui est utile pour une analyse centrée sur le client.

Où les obtenir

Lignes de détail du paiement, avec des champs tels que CREDITOR_NAME, BENE_NAME ou PAYEE.

Exemples
Acme CorpGlobal Supplies LtdJohn Smith
Paiement en retard
IsPaymentLate
Indicateur précisant si le paiement a été réglé après la date d'échéance.
Description

Indicateur booléen qui compare la date réelle de règlement à PaymentDueDate. Il sert à calculer les métriques du Dashboard « Payment Due Date Compliance » et à identifier les dépassements de SLA.

Pourquoi c’est important

Simplifie les rapports de conformité.

Où les obtenir

Calcul : SettlementDate > PaymentDueDate.

Exemples
truefalse
Région d’origine
OriginatingRegion
Région géographique à l'origine de la demande de paiement.
Description

Indique l'emplacement physique ou logique du demandeur. Cet attribut est utile pour analyser les variantes du processus de paiement et déterminer si certaines régions suivent des parcours non standard ou présentent des taux de rejet plus élevés.

Pourquoi c’est important

Fournit un contexte géographique pour évaluer la performance du processus.

Où les obtenir

En-tête de transaction, souvent dérivé du code agence ou du code pays.

Exemples
Amérique du NordEMEAAPAC
Système source
SourceSystem
Nom du système à l'origine des données d'événement.
Description

Identifie l'application ou le module précis de l'écosystème ACI Worldwide, par exemple ACI MTS ou ACI UPF, ainsi que les systèmes externes intervenant dans le flux. Cet attribut est particulièrement important lorsque les données de plusieurs grands livres doivent être assemblées ou lorsque le paiement passe par des chambres de compensation externes.

Pourquoi c’est important

Fournit le contexte sur l'origine de l'extraction des données, ce qui facilite le débogage de leur traçabilité.

Où les obtenir

Renseigné en dur lors de l'extraction ou dérivé d'une colonne SystemID lorsque plusieurs instances existent.

Exemples
ACI MTSACI UPPSAP GLSwift Gateway
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 de traitement des paiements.
6 Recommandé 8 Facultatif
Activité Description
Demande de paiement créée
Cette activité marque le lancement d'une nouvelle transaction de paiement dans le système ACI Worldwide. Il s'agit généralement d'un événement explicite enregistré lorsqu'un utilisateur ou un système en amont soumet une demande de paiement, ce qui crée un nouvel enregistrement de transaction doté d'un identifiant unique.
Pourquoi c’est important

Il s'agit de l'événement de début principal du processus de paiement. L'analyse du délai entre cette activité et l'achèvement du processus fournit le temps de cycle de bout en bout, essentiel pour mesurer l'efficacité globale du processus.

Où les obtenir

Il s'agit probablement d'un événement explicite enregistré dans la table principale des transactions ou dans un journal d'événements dédié d'ACI. Recherchez un horodatage de création associé au Payment Transaction ID.

Collecte

Identifié par l'enregistrement de création ou par un événement explicite « Create » dans le journal des transactions.

Type d’événement explicit
Erreur de paiement identifiée
Indique que le système a détecté un problème avec le paiement à une étape donnée, par exemple des données non valides ou une alerte de conformité. Cet événement est généralement enregistré explicitement avec un code d'erreur associé.
Pourquoi c’est important

Cette activité constitue le point de départ de toutes les analyses de reprise et de gestion des exceptions. Elle est essentielle aux Dashboards « Payment Failure and Rework Analysis » et « Error Resolution Cycle Time ».

Où les obtenir

Recherchez des entrées explicites dans une table de journal des erreurs ou un changement de statut vers « Error » ou « Requires Correction » dans la table des transactions. Ces événements doivent être associés au Payment Transaction ID.

Collecte

Un événement explicite est enregistré lorsque le moteur de validation ou de traitement du système signale une erreur.

Type d’événement explicit
Fonds transférés
Indique que le réseau de paiement a confirmé que les fonds ont bien été débités du compte du payeur. Cette étape est généralement enregistrée à partir d'un message de statut entrant envoyé par le réseau.
Pourquoi c’est important

Confirme l'exécution réussie du paiement par le réseau externe. Cette étape marque le début de la période de règlement et constitue une donnée essentielle pour le KPI « Average Payment Settlement Time ».

Où les obtenir

Il s'agit d'un événement explicite déclenché par un message entrant de mise à jour du statut, par exemple un MT103 de SWIFT ou une confirmation ACH, qui met à jour l'enregistrement du paiement.

Collecte

Enregistré à la réception d'un message de confirmation externe provenant du réseau de compensation.

Type d’événement explicit
Paiement approuvé
Il s'agit d'une étape clé au cours de laquelle un utilisateur habilité approuve le paiement, ce qui permet de poursuivre son exécution. Elle est généralement enregistrée comme un événement explicite lorsque l'approbateur intervient dans l'interface utilisateur du système.
Pourquoi c’est important

Cette activité constitue un point de contrôle majeur et représente souvent un goulot d'étranglement important. L'analyse des temps d'attente avant cette étape et de la durée du cycle d'approbation permet d'identifier les possibilités d'accélérer les paiements.

Où les obtenir

Recherchez un événement explicite dans une table de journal des approbations ou un changement de statut vers « Approved » dans la table principale des transactions, associé à l'action et à l'horodatage d'un utilisateur précis.

Collecte

Enregistré lorsqu'un utilisateur habilité termine l'action d'approbation dans le système.

Type d’événement explicit
Paiement autorisé
Cette étape représente l'autorisation du paiement au niveau du système après l'approbation humaine. Elle consiste à vérifier la disponibilité des fonds ou à appliquer les règles de détection de la fraude. Elle peut être enregistrée explicitement dans un journal ou déduite d'un changement de statut indiquant que le paiement est prêt à être exécuté.
Pourquoi c’est important

Il s'agit d'un point de contrôle essentiel avant l'instruction du transfert des fonds. Les retards à ce stade peuvent révéler des problèmes de performance du système ou des difficultés liées aux sous-systèmes de conformité et de détection de la fraude.

Où les obtenir

Recherchez un enregistrement explicite dans un journal de traitement système ou de sécurité. Cette étape peut également être déduite d'une mise à jour du statut, de « Approved » à « Authorized for Payment ».

Collecte

Enregistré par le moteur de paiement du système après le passage des derniers contrôles internes.

Type d’événement explicit
Paiement réglé
Il s'agit de la confirmation finale indiquant que le processus de paiement est terminé et que les fonds ont été crédités sur le compte du bénéficiaire, ce qui clôt la transaction. Cet événement essentiel marque la fin réussie du cycle de vie du paiement.
Pourquoi c’est important

Il s'agit de l'événement de fin principal indiquant la réussite du processus. Il sert à calculer le temps de cycle global et le débit, et est indispensable à la plupart des Dashboards de performance de bout en bout.

Où les obtenir

Il s'agit généralement d'un événement explicite enregistré à la réception du message de confirmation du règlement final envoyé par le réseau, ou lorsque le grand livre interne est mis à jour pour refléter l'achèvement de la transaction.

Collecte

Enregistré à la réception du fichier ou du message de règlement final, qui met à jour le statut vers « Settled ».

Type d’événement explicit
Détails du paiement validés
Cette activité représente l'achèvement des contrôles automatisés ou manuels visant à vérifier l'exactitude des informations de paiement, comme les coordonnées du bénéficiaire et les codes bancaires. Elle est souvent déduite d'un changement de statut de la transaction, de « New » à « Validated » ou « Pending Approval ».
Pourquoi c’est important

Cette activité permet de suivre l'efficacité des premières étapes de validation des données. Les retards à ce stade peuvent créer des goulots d'étranglement en amont et accroître le risque d'erreurs de paiement par la suite.

Où les obtenir

Déduite des champs de changement de statut de la table principale des transactions de paiement. Comparez les horodatages du statut « Created » et d'un statut ultérieur « Validated » ou équivalent.

Collecte

Déduite d'un changement du champ de statut du paiement, par exemple de « Entered » à « Validated ».

Type d’événement inferred
Échec du paiement
Statut terminal indiquant que le paiement n'a pas pu être effectué en raison d'un problème irrécupérable. Il se distingue d'une erreur pouvant être résolue et représente un état final d'échec définitif.
Pourquoi c’est important

Le suivi de cet événement de fin est essentiel pour calculer le taux global d'échec des paiements. L'analyse des causes d'échec peut contribuer à améliorer la qualité des données et les règles du processus.

Où les obtenir

Déduite d'un statut final et terminal tel que « Failed », « Cancelled » ou « Rejected by Bank » dans les données de transaction, qui ne change plus par la suite.

Collecte

Déduite d'un statut d'échec terminal dans l'enregistrement du paiement.

Type d’événement inferred
Erreur de paiement résolue
Indique le moment où une erreur précédemment identifiée a été corrigée par un utilisateur et où le paiement est soumis à nouveau pour traitement. Cet événement est souvent déduit lorsqu'un paiement passe d'un état d'erreur à un état normal de traitement.
Pourquoi c’est important

Cette activité clôt la boucle de traitement de l'exception. Le délai entre « Payment Error Identified » et cet événement correspond au temps de résolution de l'erreur, un indicateur important de l'efficacité opérationnelle.

Où les obtenir

Déduit d'un changement d'état, passant de « Error » à un état de traitement tel que « Pending Approval » ou « Validated ». Il peut également s'agir d'une entrée explicite dans le journal des actions utilisateur.

Collecte

Déduit d'un changement quittant un état d'erreur, ce qui indique qu'une correction a été effectuée.

Type d’événement inferred
Instruction de paiement envoyée
Cette étape marque le moment où l'instruction de paiement est constituée puis transmise à un réseau de paiement externe tel que SWIFT, ACH ou SEPA. Les systèmes ACI enregistrent explicitement ce transfert à des fins d'audit et de suivi.
Pourquoi c’est important

Il s'agit du « point de non-retour » pour de nombreux types de paiements. Son suivi permet de mesurer le temps de traitement interne avant la prise en charge par des dépendances externes.

Où les obtenir

Il s'agit presque toujours d'un événement explicite enregistré dans les journaux de transactions ou de messagerie d'ACI, souvent accompagné d'un numéro de référence propre au réseau.

Collecte

Une entrée explicite est créée dans le journal lorsque le message de paiement est envoyé au réseau externe.

Type d’événement explicit
Paiement confirmé
Cette étape représente l'accusé de réception interne confirmant que le paiement a été traité avec succès et qu'une confirmation a été reçue. Elle sert souvent de déclencheur pour informer le bénéficiaire ou d'autres systèmes internes.
Pourquoi c’est important

Cette étape est essentielle pour mesurer le respect des échéances et le taux de paiement dans les délais. Elle fournit un horodatage précis du moment où l'organisation considère que le paiement a été exécuté avec succès.

Où les obtenir

Cette étape est généralement déduite d'un changement de statut dans la table des transactions de paiement vers « Confirmed » ou « Completed », après réception de la confirmation du réseau externe.

Collecte

Déduite d'un changement de statut vers « Confirmed » ou « Processed ».

Type d’événement inferred
Paiement envoyé pour approbation
Indique que le paiement a passé la validation initiale et a été transmis pour obtenir l’approbation nécessaire d’un responsable ou du service financier. Cette étape est généralement enregistrée par un changement d’état dans le flux de travail de paiement.
Pourquoi c’est important

Cette étape marque le début du sous-processus d'approbation. Mesurer le délai entre ce point et « Payment Approved » est essentiel pour le Dashboard « Payment Approval Cycle Time Analysis ».

Où les obtenir

Déduite d'un changement du champ de statut du paiement dans les données de transaction, par exemple lors du passage à « Pending Approval ».

Collecte

Déduite d'un changement de statut vers « Pending Approval » ou un statut similaire, accompagné de l'horodatage correspondant.

Type d’événement inferred
Paiement rapproché
Représente l'étape comptable finale au cours de laquelle la transaction de paiement enregistrée dans ACI est rapprochée des relevés bancaires ou des écritures comptables. Il peut s'agir d'un événement explicite provenant d'un module de rapprochement ou d'un événement déduit d'un changement d'état.
Pourquoi c’est important

Cette activité mesure l'efficacité du processus de rapprochement du back-office. Les retards à cette étape peuvent nuire à l'exactitude des rapports financiers et masquer des problèmes de paiements non réglés.

Où les obtenir

Ces informations peuvent provenir d'un module de rapprochement dédié au sein d'ACI ou d'un système ERP externe. Elles seraient enregistrées au moyen d'une mise à jour de l'état « Reconciled » dans l'enregistrement du paiement.

Collecte

Déduit d'une mise à jour finale de l'état « Reconciled » ou de données de rapprochement jointes à l'aide du Payment ID.

Type d’événement inferred
Paiement rejeté
Cette étape survient lorsqu'un approbateur refuse la demande de paiement, ce qui nécessite souvent une correction et une nouvelle soumission. Il s'agit d'un événement explicite qui interrompt la progression du paiement et déclenche une boucle de reprise.
Pourquoi c’est important

Cette activité permet d'identifier les reprises et les inefficacités du processus. Le suivi de la fréquence des rejets aide à diagnostiquer les problèmes de qualité des données initiales ou des règles de soumission, et contribue à l'analyse des reprises.

Où les obtenir

Enregistrée comme un événement explicite dans le journal des approbations ou comme un changement de statut vers « Rejected » dans la table des transactions. L'événement peut inclure un code indiquant le motif du rejet.

Collecte

Enregistré lorsqu'un approbateur termine l'action de rejet dans le système.

Type d’événement explicit
Recommandé Facultatif

Guides d'extraction

Comment récupérer vos données depuis ACI Worldwide

Prêt à commencer ?

Utilisez ce modèle pour vous guider lors de l’extraction initiale de vos données de traitement des paiements. Obtenez des analyses utiles et améliorez dès aujourd’hui l’efficacité de vos flux de travail financiers.

Optimisez le traitement des paiements : démarrez votre essai gratuit dès maintenant

Éliminez les exceptions de paiement et atteignez 98 % de traitement de bout en bout.

Démarrer l'essai gratuit

Aucune carte bancaire requise, configuration en quelques minutes