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

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

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

Ce modèle fournit une approche structurée pour préparer vos données de traitement des paiements en vue de l'analyse. Il décrit les attributs essentiels à collecter, les activités critiques à suivre et des conseils pratiques pour extraire ces informations de votre système. En suivant ces recommandations, vous pouvez assurer une base solide pour identifier les inefficacités et optimiser vos opérations financières.
  • Attributs recommandés à collecter
  • Activités clés à suivre
  • Guide d'extraction pour ACI Worldwide
Vous découvrez les journaux d'événements ? Apprenez comment créer un journal d'événements Process Mining.

Attributs de traitement des paiements

Ce sont les champs de données recommandés à inclure dans votre journal d'événements pour une analyse complète du traitement des paiements.
3 Obligatoire 9 Recommandé 7 Facultatif
Nom Descriptionn
Horodatage de l'événement
EventTimestamp
La date et l'heure spécifiques auxquelles l'activité s'est produite.
Descriptionn

Cet attribut enregistre le moment exact où un événement a eu lieu dans l'environnement ACI. Il est utilisé pour calculer toutes les métriques temporelles, y compris les temps de cycle, les durées d'approbation et les débit de traitement. Une haute précision (millisecondes) est préférée pour séquencer avec précision les étapes automatisées rapides.

Pourquoi est-ce important ? :

Primordial pour l'ordonnancement des événements et le calcul des durées de performance.

Source des données :

Consultez les colonnes 'Date de création' ou 'Date de mise à jour' 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
ID de transaction de paiement
PaymentTransactionId
L'identifiant unique pour l'instruction de paiement spécifique à travers le système ACI.
Descriptionn

Cet attribut sert de clé centrale pour l'analyse de Process Mining, liant tous les événements liés à une seule demande de paiement. Dans les systèmes ACI Worldwide (tels que MTS ou UPP), cela correspond au numéro de référence unique attribué à une transaction lors de son entrée. Il permet la reconstruction du parcours de paiement complet, de la demande initiale à la validation, l'approbation et le règlement final.

Pourquoi est-ce important ? :

C'est l'ID de cas principal requis pour regrouper les événements discrets en instances de processus.

Source des données :

Vérifiez les tables d'en-tête de transaction, souvent étiquetées TRN_REF, REFERENCE_NUM ou UUID dans le journal de transaction principal.

Exemples
TRX-2023-899102ACI-99281-AAPAY-0019283420231025-9981
Nom de l'activité
ActivityName
L'étape spécifique ou le changement de statut qui s'est produit dans le cycle de vie du paiement.
Descriptionn

Cet attribut définit le nœud d'événement dans la carte de processus, tel que « Demande de paiement créée » ou « Fonds transférés ». Dans les systèmes ACI, cela est souvent dérivé des codes de statut, des types d'opérations de journal d'audit ou des changements d'état du workflow. Une cartographie précise de ces états techniques vers des activités métier lisibles est indispensablele pour une visualisation significative.

Pourquoi est-ce important ? :

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

Source des données :

Dérivé des codes de statut (par exemple, 100=Créé, 200=Validé) ou des colonnes d'action du journal d'audit.

Exemples
Demande de paiement crééePaiement autoriséPaiement régléPaiement échoué
Canal de traitement
ProcessingChannel
Le canal par lequel le paiement a été initié.
Descriptionn

Indique le point d'entrée du paiement, tel que Mobile, Portail Web, API ou Téléchargement de fichier. Ceci aide dans l''Analyse des variantes de processus de paiement' pour voir si certains canaux sont plus sujets aux erreurs ou aux retards que d'autres.

Pourquoi est-ce important ? :

Segmente la performance par méthode de saisie.

Source des données :

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

Exemples
SWIFTServices bancaires en ligneApplication mobileTéléchargement de fichier
Code d'erreur
ErrorCode
Le code généré lorsqu'un paiement échoue ou nécessite une réparation.
Descriptionn

Répertorie la raison spécifique d'un événement 'Paiement échoué' ou 'Erreur de paiement identifiée'. Le regroupement par cet attribut dans le tableau de bord 'Analyse des échecs de paiement et du reprises' permet à l'entreprise d'identifier les causes profondes les plus courantes d'échec (par exemple, 'Fonds insuffisants', 'Compte invalide').

Pourquoi est-ce important ? :

Primordial pour l'analyse des causes profondes des échecs de processus.

Source des données :

Journaux d'erreurs ou colonnes de motif de statut, souvent REASON_CODE ou RETURN_CODE.

Exemples
R01AM04BE05TECH_ERR_001
Date d'échéance du paiement
PaymentDueDate
La date à laquelle le paiement doit être réglé pour être considéré comme à temps.
Descriptionn

Stocke la date d'exécution contractuelle ou demandée. Cette date est comparée à la date de règlement réelle pour calculer le KPI du « Taux de paiement ponctuel » et prendre en charge le tableau de bord de « Conformité aux dates d'échéance des paiements ».

Pourquoi est-ce important ? :

Le repère pour mesurer la conformité SLA et la respect des délais.

Source des données :

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

Exemples
2023-11-012023-11-05
Département
Department
Le service interne responsable de l'activité en cours.
Descriptionn

Mappe l'EventUser ou la file d'attente à une unité organisationnelle plus large (par exemple, 'Opérations de paiement', 'Conformité', 'Trésorerie'). Ceci aide dans l''Analyse des points de blocage par activité' pour voir quelles équipes ralentissent le processus.

Pourquoi est-ce important ? :

Aggrège les performances par fonction commerciale.

Source des données :

Dérivé des tables d'utilisateurs ou du mappage de la hiérarchie organisationnelle.

Exemples
OpérationsComplianceTrésorerieSupport IT
Devise de paiement
PaymentCurrency
Le code de devise ISO pour le montant du paiement.
Descriptionn

Spécifie la devise dans laquelle le PaymentAmount est libellé (par exemple, USD, EUR, GBP). Ceci est indispensable pour la normalisation des données dans les dashboards qui agrègent les volumes sur différentes régions. Cela aide à comprendre les complexités des paiements transfrontaliers.

Pourquoi est-ce important ? :

Nécessaire pour interpréter correctement le montant du paiement.

Source des données :

Tables de détail des transactions, typiquement des champs comme CCY, CURRENCY_CODE ou ISO_CODE.

Exemples
USDEURGBPJPY
Est un reprises
IsRework
Indicateur si le paiement a subi des activités répétitives.
Descriptionn

Un indicateur booléen calculé lors du traitement des données. Il est défini sur vrai si des activités comme 'Détails du paiement validés' se produisent plus d'une fois ou si une boucle d'erreur est détectée. Cela alimente le KPI 'Taux de reprises des paiements'.

Pourquoi est-ce important ? :

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

Source des données :

Calculé dans le pipeline de données en vérifiant les activités en double par cas.

Exemples
truefaux
Event User
EventUser
L'ID utilisateur ou l'agent système responsable de l'activité.
Descriptionn

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 indispensable à l''Analyse des points de blocage' afin d'identifier si des utilisateurs ou des files d'attente spécifiques sont surchargés.

Pourquoi est-ce important ? :

Permet l'analyse des ressources et l'audit de la ségrégation des tâches.

Source des données :

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

Exemples
SYSTEM_AGENT_01j.doeapprover_group_aBATCH_PROCESS
Montant du paiement
PaymentAmount
La valeur monétaire de la transaction de paiement.
Descriptionn

Indique la valeur financière transférée. C'est un champ de contexte critique pour l'analyse du 'Débit des paiements' et la priorisation des points de blocage. Les paiements de grande valeur suivent souvent des chemins d'approbation plus rigoureux (analyse des variantes) par rapport aux flux automatisés de faible valeur.

Pourquoi est-ce important ? :

Permet la segmentation par valeur et le calcul du volume total traité.

Source des données :

Tables de détail des transactions, typiquement des champs comme AMT, TRANS_AMOUNT ou PRINCIPAL_AMOUNT.

Exemples
1500.00250000.5050.001000000.00
Type de paiement
PaymentType
La classification de l'instrument de paiement.
Descriptionn

Catégorise le paiement (par exemple, Virement, ACH, SEPA, RTGS). Différents types de paiement ont souvent des SLA et des flux de processus très différents. Cet attribut est une dimension primaire pour filtrer le tableau de bord 'Temps de cycle de paiement complet'.

Pourquoi est-ce important ? :

Primordial pour distinguer les flux de paiement à grande vitesse et par lots.

Source des données :

En-tête de transaction, champs comme PMT_TYPE, INSTRUMENT_TYPE ou SERVICE_ID.

Exemples
Virement nationalVirement internationalACH CreditPaiement instantané
Dernière mise à jour des données
LastDataUpdate
Heure de la dernière extraction ou mise à jour de l'enregistrement dans le modèle de données.
Descriptionn

Suit la la réactualisation des données utilisées dans l'analyse. Cela ne représente pas un temps d'événement de processus, mais plutôt le temps technique d'ingestion des données. Cela garantit que les analystes savent s'ils consultent des instantanés en temps réel ou historiques.

Pourquoi est-ce important ? :

Assure la réactualisation des données et aide à identifier les données obsolètes dans les dashboards.

Source des données :

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.
Descriptionn

Calcule le temps entre 'Paiement envoyé pour approbation' et 'Paiement approuvé' (ou rejeté). Cette métrique spécifique alimente le tableau de bord 'Analyse du temps de cycle d'approbation des paiements', mettant en évidence les retards dans les étapes de décision humaines.

Pourquoi est-ce important ? :

Isole la partie du processus dépendante de l'humain.

Source des données :

Calculé : Horodatage (Paiement approuvé) - Horodatage (Paiement envoyé pour approbation).

Exemples
4 heures15 minutes
ID de rapprochement
ReconciliationId
Identifiant liant le paiement au grand livre ou à l'enregistrement de réconciliation.
Descriptionn

Cet ID est renseigné lorsque l'activité « Paiement rapproché » se produit. Il garantit que le paiement dans le moteur de traitement correspond à l'entrée dans le système comptable. L'absence de cet ID sur les paiements réglés indique des échecs de rapprochement.

Pourquoi est-ce important ? :

Primordial pour le tableau de bord 'Efficacité de la réconciliation des paiements'.

Source des données :

Tables de rapprochement ou champs spécifiques comme RECON_REF ou GL_REF.

Exemples
REC-9921GL-Entry-2023-11
Le paiement est-il en retard ?
IsPaymentLate
Indicateur si le paiement a été réglé après la date d'échéance.
Descriptionn

Un indicateur booléen qui compare la date de règlement réelle avec la PaymentDueDate. Utilisé pour calculer les métriques du tableau de bord 'Conformité aux dates d'échéance des paiements' et identifier les violations de SLA.

Pourquoi est-ce important ? :

Simplifie les rapports de conformité.

Source des données :

Calculé : SettlementDate > PaymentDueDate.

Exemples
truefaux
Nom du bénéficiaire
BeneficiaryName
Le nom de l'entité recevant le paiement.
Descriptionn

Identifie la contrepartie dans la transaction. L'analyse de ce champ peut aider à identifier les fournisseurs ou clients spécifiques associés à des taux de reprise ou des retards élevés, supportant l''Analyse des échecs de paiement et du reprises'.

Pourquoi est-ce important ? :

Identifie la cible du paiement, utile pour une analyse orientée client.

Source des données :

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

Exemples
Acme CorpGlobal Supplies LtdJohn Smith
Région d'origine
OriginatingRegion
La région géographique d'où provient la demande de paiement.
Descriptionn

Indique l'emplacement physique ou logique du demandeur. Ceci est utile pour l''Analyse des variantes de processus de paiement' pour voir si des régions spécifiques suivent des chemins non standards ou connaissent des taux de rejet plus élevés.

Pourquoi est-ce important ? :

Fournit un contexte géographique à la performance du processus.

Source des données :

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

Exemples
Amérique du NordEMEAAPAC
Système source
SourceSystem
Le nom du système où les données d'événement ont été générées.
Descriptionn

Identifie l'application ou le module spécifique dans l'écosystème ACI Worldwide (par exemple, ACI MTS, ACI UPF) ou les systèmes externes impliqués dans le flux. Ceci est particulièrement important lors de l'assemblage de données provenant de plusieurs grands livres ou lorsque le paiement touche des chambres de compensation externes.

Pourquoi est-ce important ? :

Fournit un contexte sur l'endroit où les données ont été extraites, utile pour le débogage de la traçabilité des données.

Source des données :

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

Exemples
ACI MTSACI UPPSAP GLPasserelle Swift
Obligatoire Recommandé Facultatif

Activités de traitement des paiements

Ce sont les étapes clés du processus et les jalons à capturer dans votre journal d'événements pour une découverte précise du processus de traitement des paiements.
6 Recommandé 8 Facultatif
Activité Descriptionn
Demande de paiement créée
Cette activité marque l'initiation d'une nouvelle transaction de paiement au sein du 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, créant un nouvel enregistrement de transaction avec un ID unique.
Pourquoi est-ce important ? :

C'est l'événement de démarrage principal du processus de paiement. L'analyse du temps entre cette activité et son achèvement fournit le temps de cycle complet, ce qui est indispensable pour mesurer l'efficacité globale du processus.

Source des données :

Il s'agit probablement d'un événement explicite enregistré dans la table de transactions principale ou un journal d'événements dédié dans ACI. Recherchez un horodatage de création associé à l'ID de transaction de paiement.

Capture

Identifié par l'enregistrement de création ou un événement 'Créer' explicite dans le journal de 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 à un certain stade, tel que des données invalides ou une alerte de conformité. Cet événement est généralement enregistré explicitement avec un code d'erreur associé.
Pourquoi est-ce important ? :

Cette activité est le point de départ de toutes les analyses de reprise et de gestion des exceptions. Elle est indispensablele pour les dashboards d'« Analyse des échecs de paiement et des reprises » et de « Temps de cycle de résolution des erreurs ».

Source des données :

Recherchez des entrées explicites dans une table de journal d'erreurs ou un changement de statut à 'Erreur' ou 'Nécessite une correction' dans la table des transactions. Ces événements doivent être liés à l'ID de transaction de paiement.

Capture

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 qu'une confirmation a été reçue du réseau de paiement que les fonds ont été débités avec succès du compte du payeur. Ceci est généralement capturé à partir d'un message de statut entrant du réseau.
Pourquoi est-ce important ? :

Confirme l'exécution réussie du paiement par le réseau externe. Il marque le début de la période de règlement et est une entrée clé pour le KPI 'Temps moyen de règlement des paiements'.

Source des données :

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

Capture

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

Type d'événement explicit
Paiement approuvé
Une étape clé où un utilisateur autorisé approuve le paiement, lui permettant de passer à l'exécution. Ceci est généralement capturé comme un événement explicite lorsque l'approbateur agit dans l'interface utilisateur du système.
Pourquoi est-ce important ? :

Cette activité est un point de contrôle majeur et souvent un goulot d'étranglement significatif. L'analyse des temps d'attente avant cette étape et de la durée du cycle d'approbation aide à identifier les opportunités d'accélérer les paiements.

Source des données :

Recherchez un événement explicite dans une table de journal d'approbation ou un changement de statut à 'Approuvé' dans la table de transaction principale qui est lié à une action utilisateur spécifique et à un horodatage.

Capture

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

Type d'événement explicit
Paiement autorisé
Représente l'autorisation du paiement au niveau du système après approbation humaine, vérifiant les fonds ou effectuant des contrôles par rapport aux règles de fraude. Cela peut être une entrée de journal explicite ou inféré d'un changement de statut indiquant la préparation à l'exécution.
Pourquoi est-ce important ? :

C'est un point de contrôle critique avant que les fonds ne soient instruits de bouger. Les retards à ce stade peuvent indiquer des problèmes de performance système ou des problèmes avec les sous-systèmes de conformité et de contrôle de la fraude.

Source des données :

Vérifiez un journal explicite dans un journal de traitement système ou de sécurité. Alternativement, cela peut être déduit d'une mise à jour de statut de 'Approuvé' à 'Autorisé au paiement'.

Capture

Comptabilisé par le moteur de paiement du système après avoir passé les vérifications internes finales.

Type d'événement explicit
Paiement réglé
La confirmation finale que le processus de paiement est terminé et que les fonds ont été crédités au bénéficiaire, clôturant la transaction. Il s'agit d'un événement critique, représentant la fin réussie du cycle de vie du paiement.
Pourquoi est-ce important ? :

C'est l'événement de fin de succès principal pour le processus. Il est utilisé pour calculer le temps de cycle global et le débit, et est indispensable pour presque tous les dashboards de performance complet.

Source des données :

Typiquement un événement explicite enregistré lorsqu'un message de confirmation de règlement final est reçu du réseau ou lorsque le grand livre interne est mis à jour pour refléter l'achèvement de la transaction.

Capture

Comptabilisé à la réception d'un fichier ou d'un message de règlement final, mettant à jour le statut à 'Réglé'.

Type d'événement explicit
Détails du paiement validés
Représente l'achèvement des contrôles automatisés ou manuels pour s'assurer que les détails de paiement, tels que les informations sur le bénéficiaire et les codes bancaires, sont corrects. Cette activité est souvent déduite d'un changement de statut de la transaction de « Nouveau » à « Validé » ou « En attente d'approbation ».
Pourquoi est-ce important ? :

Suit l'efficacité des étapes initiales de validation des données. Les retards ici peuvent créer des points de blocage en amont et augmenter la probabilité d'erreurs de paiement plus tard dans le processus.

Source des données :

Déduit des champs de changement de statut dans la table principale des transactions de paiement. Comparez les horodatages entre le statut 'Créé' et un statut subséquent 'Validé' ou similaire.

Capture

Déduit d'un changement dans le champ du statut de paiement, par exemple, de 'Saisi' à 'Validé'.

Type d'événement inferred
Erreur de paiement résolue
Marque le point où une erreur précédemment identifiée a été corrigée par un utilisateur et le paiement est soumis à nouveau pour traitement. Ceci est souvent déduit lorsqu'un statut de paiement passe d'un état d'erreur à un état de traitement normal.
Pourquoi est-ce important ? :

Cette activité clôture la boucle d'exception. Le temps entre l'« Erreur de paiement identifiée » et cet événement est le temps de cycle de résolution des erreurs, une mesure clé de l'efficacité opérationnelle.

Source des données :

Déduit d'un changement de statut quittant un état d''Erreur' vers un état de traitement comme 'En attente d'approbation' ou 'Validé'. Il peut aussi s'agir d'un journal d'actions utilisateur explicite.

Capture

Déduit d'un changement de statut sortant d'un état d'erreur, indiquant qu'une correction a été effectuée.

Type d'événement inferred
Instruction de paiement envoyée
Marque le point où l'instruction de paiement est compilée et transmise à un réseau de paiement externe comme SWIFT, ACH ou SEPA. Les systèmes ACI enregistrent explicitement ce transfert à des fins d'audit et de suivi.
Pourquoi est-ce important ? :

C'est le « point de non-retour » pour de nombreux types de paiements. Le suivi de cela aide à mesurer le temps de traitement interne avant que les dépendances externes ne prennent le relais.

Source des données :

C'est presque toujours un événement explicite enregistré dans les journaux de transactions ou de messagerie d'ACI, incluant souvent un numéro de référence spécifique au réseau.

Capture

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

Type d'événement explicit
Paiement Confirmé
Représente l'accusé de réception interne indiquant que le paiement a été traité avec succès et qu'une confirmation a été reçue. Cela sert souvent de point de déclenchement pour notifier le bénéficiaire ou d'autres systèmes internes.
Pourquoi est-ce important ? :

Ce jalon est impératif pour mesurer la conformité aux dates d'échéance et le taux de paiement à temps. Il fournit un horodatage clair du moment où l'organisation considère le paiement comme exécuté avec succès.

Source des données :

Ceci est généralement déduit d'un changement de statut dans la table des transactions de paiement vers un état « Confirmé » ou « Terminé » après réception de la confirmation du réseau externe.

Capture

Déduit d'un changement de statut à 'Confirmé' ou 'Traité'.

Type d'événement inferred
Paiement échoué
Un statut terminal indiquant que le paiement n'a pas pu être effectué en raison d'un problème irrécupérable. Ceci est distinct d'une erreur résoluble et représente un état final d'échec définitif.
Pourquoi est-ce important ? :

Le suivi de cet événement final est impératif pour calculer le taux d'efficacité.x global d'échec des paiements. L'analyse des raisons de l'échec peut aider à améliorer la qualité des données et les règles de processus.

Source des données :

Déduit d'un statut final, terminal comme 'Échoué', 'Annulé' ou 'Rejeté par la Banque' dans les données de transaction, qui ne change pas par la suite.

Capture

Déduit d'un statut d'échec terminal dans l'enregistrement de paiement.

Type d'événement inferred
Paiement envoyé pour approbation
Indique que le paiement a passé la validation initiale et a été acheminé pour l'approbation managériale ou financière nécessaire. Ceci est généralement capturé par un changement de statut au sein du workflow de paiement.
Pourquoi est-ce important ? :

Cela marque le début du sous-processus d'approbation. Mesurer le temps entre ce point et le « Paiement approuvé » est indispensable pour le tableau de bord d'« Analyse du temps de cycle d'approbation des paiements ».

Source des données :

Dérivé d'un changement dans le champ du statut de paiement dans les données de transaction, tel qu'un passage à 'En attente d'approbation'.

Capture

Déduit d'un changement de statut à 'En attente d'approbation' ou similaire, accompagné d'un horodatage correspondant.

Type d'événement inferred
Paiement rapproché
Représente l'étape comptable finale où la transaction de paiement enregistrée dans ACI est rapprochée des relevés bancaires ou des écritures de grand livre. Cela peut être un événement explicite d'un module de rapprochement ou inféré par un changement de statut.
Pourquoi est-ce important ? :

Cette activité mesure l'efficacité du processus de rapprochement back-office. Les retards ici peuvent impacter la précision des rapports financiers et masquer des problèmes de paiement non réglés.

Source des données :

Cette information peut provenir d'un module de rapprochement dédié au sein d'ACI ou d'un système ERP externe. Elle serait capturée via une mise à jour de statut à « Rapproché » sur l'enregistrement de paiement.

Capture

Déduit d'une mise à jour de statut finale 'Réconcilié', ou à partir de données de réconciliation jointes par l'ID de paiement.

Type d'événement inferred
Paiement rejeté
Se produit lorsqu'un approbateur refuse la demande de paiement, nécessitant souvent une correction et une nouvelle soumission. C'est un événement explicite qui arrête la progression du paiement et initie une boucle de reprises.
Pourquoi est-ce important ? :

Identifie les reprises et les inefficacités de processus. Le suivi de la fréquence des rejets aide à diagnostiquer les problèmes de qualité des données initiales ou de politiques de soumission, supportant l'analyse du reprises.

Source des données :

Capturé comme un événement explicite dans le journal d'approbation ou un changement de statut à 'Rejeté' dans la table des transactions. L'événement peut inclure un code de motif de rejet.

Capture

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

Type d'événement explicit
Recommandé Facultatif

Guides d'extraction

Comment obtenir vos données d'ACI Worldwide