Votre modèle de données pour le traitement des paiements
Votre modèle de données pour le traitement des paiements
- Attributs recommandés à collecter
- Activités clés à suivre
- Recommandations d'extraction pour ACI Worldwide
Attributs du traitement des paiements
| 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 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 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 à 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 | |||
Activités du traitement des paiements
| 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 | |||
Guides d'extraction
Étapes
Accéder à l'environnement de base de données : connectez-vous à l'instance SQL Server qui héberge la base de données ACI Postilion Realtime à l'aide de SQL Server Management Studio (SSMS) ou d'un client compatible.
Identifier les tables principales : repérez les tables
post_tran(journal des transactions) etpost_tran_cust(extension des données personnalisées). Vérifiez que vous disposez des autorisationsSELECTsur ces objets.Déterminer l'identifiant du dossier : cette extraction utilise
retrieval_reference_nrcommePaymentTransactionId. Si votre implémentation utilise une autre clé unique, par exemplesystem_trace_audit_nrcombiné àtransmission_date_time, adaptez la sélection de la requête en conséquence.Configurer les paramètres de filtrage : ouvrez la requête fournie ci-dessous. Repérez les variables
@StartDateet@EndDateen haut du script. Définissez la période d'extraction souhaitée, par exemple les 30 à 90 derniers jours, afin d'optimiser les performances.Vérifier la logique des activités : la requête associe les types de messages ISO 8583, par exemple 0200 et 0210, ainsi que les codes de réponse aux 14 activités requises pour le Process Mining. Examinez les instructions
CASEpour vérifier qu'elles correspondent à vos configurations d'interface ACI.Exécuter la requête : exécutez le script complet. La requête utilise
UNION ALLpour normaliser les différents états des transactions dans un format unique de journal d'événements.Vérifier les résultats : contrôlez la présence des colonnes requises :
PaymentTransactionId,ActivityNameetEventTimestamp. Vérifiez qu'aucun champ essentiel ne contient de valeurNULLinattendue.Exporter les données : cliquez avec le bouton droit sur la grille de résultats dans SSMS et enregistrez les résultats au format CSV, par exemple
ACI_Payments_EventLog.csv.Préparer les données pour ProcessMind : ouvrez le fichier CSV et vérifiez que
EventTimestamputilise un format standard (YYYY-MM-DD HH:MM:SS) et quePaymentAmountcontient uniquement des valeurs numériques.Charger les données : importez le fichier CSV vérifié dans ProcessMind et associez respectivement les colonnes à Case ID, Activity et Timestamp.
Configuration
- Date Range : les tables ACI
post_tranaugmentent très rapidement. Il est vivement recommandé de limiter l'extraction à une période glissante de 3 mois ou d'utiliser le partition switching s'il est disponible. - Response Codes : la requête suppose que
rsp_code = '00'indique une réussite. Si votre établissement utilise d'autres codes d'approbation ou de réussite, par exemple '08' ou '10', mettez à jour les filtres. - Message Types (ISO 8583) : le script s'appuie sur les types de messages standard, 0100/0200 pour les demandes et 0210 pour les réponses. Les types de messages personnalisés définis dans votre configuration
source_node_namepeuvent nécessiter des ajustements. - System Performance : cette requête utilise des indications
NOLOCKpour éviter de bloquer le traitement des transactions en production. Ne supprimez pas ces indications dans un environnement de production. - Currencies : les montants sont extraits sous forme de valeurs brutes. Vérifiez que
tran_currency_codeest utilisé si une normalisation multidevise est nécessaire pendant l'analyse.
a Exemple de requête sql
DECLARE @StartDate DATETIME = '2023-01-01 00:00:00';
DECLARE @EndDate DATETIME = '2023-01-31 23:59:59';
/* 1. Payment Request Created: Initial transaction request received */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Request Created' AS ActivityName,
t.datetime_req AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'System' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'Origination' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.message_type IN ('0100', '0200') -- Authorization/Financial Request
UNION ALL
/* 2. Payment Details Validated: Inferred after request but before routing */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Details Validated' AS ActivityName,
DATEADD(second, 1, t.datetime_req) AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'System' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'Compliance' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.message_type IN ('0100', '0200')
AND t.rsp_code = '00' -- Implies validation passed
UNION ALL
/* 3. Payment Sent For Approval: Routing to internal authorization */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Sent For Approval' AS ActivityName,
DATEADD(second, 2, t.datetime_req) AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'System' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'Risk Management' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.message_type IN ('0100', '0200')
AND t.tran_amount_req > 1000 -- Example threshold for approval logic
UNION ALL
/* 4. Payment Approved: Successful response code logic */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Approved' AS ActivityName,
t.datetime_rsp AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'Approver' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'Risk Management' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.rsp_code = '00'
AND t.message_type IN ('0110', '0210')
UNION ALL
/* 5. Payment Rejected: Specific rejection codes */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Rejected' AS ActivityName,
t.datetime_rsp AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'System' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
t.rsp_code AS ErrorCode,
1 AS IsRework,
NULL AS EndToEndCycleTime,
'Risk Management' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.rsp_code IN ('51', '05', '61') -- Insufficient funds, Do not honor, etc.
UNION ALL
/* 6. Payment Authorized: Successful authorization completion */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Authorized' AS ActivityName,
DATEADD(millisecond, 500, t.datetime_rsp) AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'System' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'Operations' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.rsp_code = '00'
AND t.message_type = '0110' -- Authorization Response
UNION ALL
/* 7. Payment Instruction Sent: Handoff to Sink Node */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Instruction Sent' AS ActivityName,
DATEADD(second, 1, t.datetime_req) AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
t.sink_node_name AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'Network Operations' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.sink_node_name IS NOT NULL
AND t.message_type IN ('0200', '0100')
UNION ALL
/* 8. Funds Transferred: External network confirmation */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Funds Transferred' AS ActivityName,
t.datetime_rsp AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
t.sink_node_name AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'Treasury' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.rsp_code = '00'
AND t.message_type = '0210' -- Financial Response
UNION ALL
/* 9. Payment Confirmed: Final acknowledgment */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Confirmed' AS ActivityName,
DATEADD(second, 5, t.datetime_rsp) AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'System' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'Customer Service' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.rsp_code = '00'
AND t.message_type = '0210'
UNION ALL
/* 10. Payment Settled: Settlement/Reconciliation message */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Settled' AS ActivityName,
ISNULL(t.settle_date, t.datetime_rsp) AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'Settlement Engine' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'Accounting' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.message_type = '0500' -- Reconciliation
AND t.rsp_code = '00'
UNION ALL
/* 11. Payment Failed: System Errors */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Failed' AS ActivityName,
t.datetime_rsp AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'System' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
t.rsp_code AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'IT Operations' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.rsp_code IN ('91', '96', '06') -- Issuer down, System malfunction
UNION ALL
/* 12. Payment Error Identified: General Error */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Error Identified' AS ActivityName,
t.datetime_rsp AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'System' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
t.rsp_code AS ErrorCode,
1 AS IsRework,
NULL AS EndToEndCycleTime,
'Compliance' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.rsp_code NOT IN ('00')
AND t.message_type IN ('0210', '0110')
UNION ALL
/* 13. Payment Error Resolved: Reversal or Correction followed by Success */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Error Resolved' AS ActivityName,
t.datetime_req AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'System' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
1 AS IsRework,
NULL AS EndToEndCycleTime,
'Operations' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.message_type IN ('0400', '0420') -- Reversal/Advice
UNION ALL
/* 14. Payment Reconciled: Batch processing flag from Custom Table */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Reconciled' AS ActivityName,
ISNULL(c.recon_date, DATEADD(hour, 24, t.datetime_req)) AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'Recon Module' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'Finance' AS Department
FROM post_tran t WITH (NOLOCK)
JOIN post_tran_cust c WITH (NOLOCK) ON t.post_tran_cust_id = c.post_tran_cust_id
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.rsp_code = '00'
AND t.message_type = '0210'
AND c.recon_date IS NOT NULL; 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.
Aucune carte bancaire requise, configuration en quelques minutes