Votre modèle de données de traitement des paiements
Votre modèle de données de traitement des paiements
- Attributs recommandés à collecter
- Activités clés à suivre
- Guide d'extraction pour ACI Worldwide
Attributs de traitement des paiements
| 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' 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 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 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 | |||
Activités de traitement des paiements
| 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 | |||
Guides d'extraction
Étapes
Accédez à l'environnement de la base de données : Connectez-vous à l'instance SQL Server hébergeant la base de données ACI Postilion Realtime en utilisant SQL Server Management Studio (SSMS) ou un client compatible.
Identifiez les tables principales : Localisez les tables
post_tran(journal des transactions) etpost_tran_cust(extension de données personnalisées). Assurez-vous d'avoir les permissionsSELECTsur ces objets.Déterminez l'identifiant de cas : Cette extraction utilise le
retrieval_reference_nrcommePaymentTransactionId. Si votre implémentation utilise une clé unique différente (commesystem_trace_audit_nrcombiné avectransmission_date_time), ajustez la sélection de la requête en conséquence.Configurez les paramètres de filtre : Ouvrez la requête fournie ci-dessous. Localisez les variables
@StartDateet@EndDateen haut du script. Définissez-les sur votre fenêtre d'extraction souhaitée (par exemple, les 30 à 90 derniers jours) pour optimiser les performances.Révisez la logique d'activité : La requête mappe les types de messages ISO 8583 (par exemple, 0200, 0210) et les codes de réponse aux 14 activités de Process Mining requises. Révisez les instructions
CASEpour vous assurer qu'elles correspondent à vos configurations d'interface ACI spécifiques.Exécutez la requête : Exécutez le script complet. La requête utilise
UNION ALLpour normaliser différents états de transaction en un seul format de journal d'événements.Vérifiez la sortie des données : Vérifiez les résultats pour les colonnes requises :
PaymentTransactionId,(ActivityName)etEventHorodatage. Assurez-vous qu'aucun champ critique ne contient de valeursNULLde manière inattendue.Exportez les données : Faites un clic droit sur la grille de résultats dans SSMS et enregistrez la sortie en tant que fichier CSV (par exemple,
ACI_Payments_EventLog.csv).Formatez pour ProcessMind : Ouvrez le fichier CSV et vérifiez que l'
EventHorodatageest dans un format standard (AAAA-MM-JJ HH:MM:SS) et quePaymentAmountcontient uniquement des valeurs numériques.Téléchargement : Importez le fichier CSV vérifié dans ProcessMind, en mappant les colonnes à l'ID de cas, à l'activité et à l'horodatage respectivement.
Configuration
- Plage de dates : Les tables
post_trand'ACI augmentent très rapidement. Il est fortement recommandé de limiter l'extraction à une fenêtre glissante de 3 mois ou d'utiliser le basculement de partition si disponible. - Codes de réponse : La requête suppose que
rsp_code = '00'indique le succès. Si votre institution utilise des codes différents pour l'approbation/le succès (par exemple, '08' ou '10'), mettez à jour les filtres. - Types de messages (ISO 8583) : Le script s'appuie sur des types de messages standards (0100/0200 pour les Requêtes, 0210 pour les Réponses). Les types de messages personnalisés définis dans votre configuration
source_node_namepeuvent nécessiter des ajustements. - Performances du système : Cette requête utilise des indications
NOLOCKpour éviter de bloquer le traitement des transactions en direct. Ne supprimez pas ces indications dans un environnement de production. - Devises : Les montants sont extraits sous forme de chiffres bruts. Assurez-vous que
tran_currency_codeest utilisé si une normalisation multi-devises est requise 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;