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 | Description | ||
|---|---|---|---|
| ID de transaction de paiement PaymentTransactionId | L'identifiant unique pour l'instruction de paiement spécifique à travers le système ACI. | ||
| Description 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 de bout en bout, de la demande initiale à la validation, l'approbation et le règlement final. Pourquoi c'est important C'est l'ID de cas fondamental requis pour regrouper les événements discrets en instances de processus. Où obtenir 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. | ||
| Description 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 cruciale pour une visualisation significative. Pourquoi c'est important Il définit le flux de processus et est nécessaire pour visualiser la séquence des opérations. Où obtenir 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é | |||
| Timestamp de l'événement EventTimestamp | La date et l'heure spécifiques auxquelles l'activité s'est produite. | ||
| Description 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 basées sur le temps, y compris les temps de cycle, les durées d'approbation et les taux de rendement. Une haute précision (millisecondes) est préférée pour séquencer avec précision les étapes automatisées rapides. Pourquoi c'est important Essentiel pour l'ordonnancement des événements et le calcul des durées de performance. Où obtenir 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 | |||
| Canal de traitement ProcessingChannel | Le canal par lequel le paiement a été initié. | ||
| Description 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 c'est important Segmente la performance par méthode de saisie. Où obtenir En-tête de transaction, souvent dans des colonnes nommées CHANNEL, SOURCE_TYPE ou INPUT_METHOD. Exemples SWIFTServices bancaires en ligneMobile AppTéléchargement de fichier | |||
| Code d'erreur ErrorCode | Le code généré lorsqu'un paiement échoue ou nécessite une réparation. | ||
| Description Capture 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 retravail' permet à l'entreprise d'identifier les causes profondes les plus courantes d'échec (par exemple, 'Fonds insuffisants', 'Compte invalide'). Pourquoi c'est important Essentiel pour l'analyse des causes profondes des échecs de processus. Où obtenir 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. | ||
| Description 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 à temps » et prendre en charge le dashboard de « Conformité aux dates d'échéance des paiements ». Pourquoi c'est important Le repère pour mesurer la conformité SLA et la performance à temps. Où obtenir 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. | ||
| Description Mappe l' Pourquoi c'est important Aggrège les performances par fonction commerciale. Où obtenir 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. | ||
| Description Spécifie la devise dans laquelle le Pourquoi c'est important Nécessaire pour interpréter correctement le montant du paiement. Où obtenir Tables de détail des transactions, typiquement des champs comme CCY, CURRENCY_CODE ou ISO_CODE. Exemples USDEURGBPJPY | |||
| Est un retravail IsRework | Indicateur si le paiement a subi des activités répétitives. | ||
| Description 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 retravail des paiements'. Pourquoi c'est important Identifie rapidement les cas inefficaces sans requêtes de processus complexes. Où obtenir 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é. | ||
| Description Capture 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 vital pour l''Analyse des goulots d'étranglement' afin d'identifier si des utilisateurs ou des files d'attente spécifiques sont surchargés. Pourquoi c'est important Permet l'analyse des ressources et l'audit de la ségrégation des tâches. Où obtenir 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. | ||
| Description 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 goulots d'étranglement. 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 c'est important Permet la segmentation par valeur et le calcul du volume total traité. Où obtenir Tables de détail des transactions, typiquement des champs comme AMT, TRANS_AMOUNT ou PRINCIPAL_AMOUNT. Exemples 1500.00250000.5050.001000000.00 | |||
| Temps de cycle de bout en bout EndToEndCycleTime | La durée totale de la création de la demande au règlement. | ||
| Description Calcule la différence de temps entre 'Demande de paiement créée' et 'Paiement réglé'. Ceci sert de métrique principale pour le KPI 'Temps de cycle moyen des transactions de paiement' et l'analyse globale de l'efficacité. Pourquoi c'est important La métrique de haut niveau pour la vitesse du processus. Où obtenir Calculé : Horodatage (Paiement réglé) - Horodatage (Demande de paiement créée). Exemples 2 jours 4 heures45 minutes12 secondes | |||
| Type de paiement PaymentType | La classification de l'instrument de paiement. | ||
| Description 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 de bout en bout'. Pourquoi c'est important Essentiel pour distinguer les flux de paiement à grande vitesse et par lots. Où obtenir En-tête de transaction, champs comme PMT_TYPE, INSTRUMENT_TYPE ou SERVICE_ID. Exemples Virement domestiqueVirement internationalACH CreditPaiement instantané | |||
| Dernière mise à jour des données LastDataUpdate | L'horodatage de la dernière extraction ou mise à jour de l'enregistrement dans le modèle de données. | ||
| Description Suit la fraîcheur 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 c'est important Assure l'actualité des données et aide à identifier les données obsolètes dans les tableaux de bord. Où 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 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 c'est important Isole la partie du processus dépendante de l'humain. Où obtenir 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. | ||
| Description 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 c'est important Essentiel pour le tableau de bord 'Efficacité de la réconciliation des paiements'. Où obtenir 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. | ||
| Description Un indicateur booléen qui compare la date de règlement réelle avec la Pourquoi c'est important Simplifie les rapports de conformité. Où obtenir Calculé : SettlementDate > PaymentDueDate. Exemples truefaux | |||
| Nom du bénéficiaire BeneficiaryName | Le nom de l'entité recevant le paiement. | ||
| Description 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 retravail ou des retards élevés, supportant l''Analyse des échecs de paiement et du retravail'. Pourquoi c'est important Identifie la cible du paiement, utile pour une analyse centrée sur le client. Où obtenir 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. | ||
| Description 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 c'est important Fournit un contexte géographique à la performance du processus. Où obtenir 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. | ||
| Description Identifie l'application ou le module spécifique au sein de 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 c'est important Fournit un contexte sur l'endroit où les données ont été extraites, utile pour le débogage de la lignée des données. Où obtenir 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é | Description | ||
|---|---|---|---|
| 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 c'est 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 de bout en bout, ce qui est essentiel pour mesurer l'efficacité globale du processus. Où obtenir 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 c'est important Cette activité est le point de départ de toutes les analyses de reprise et de gestion des exceptions. Elle est essentielle pour les dashboards d'« Analyse des échecs de paiement et des reprises » et de « Temps de cycle de résolution des erreurs ». Où obtenir 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 c'est 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'. Où obtenir 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 Enregistré à 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 c'est 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. Où obtenir 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 Enregistré 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 c'est 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. Où obtenir 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 Enregistré 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 c'est 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 essentiel pour presque tous les dashboards de performance de bout en bout. Où obtenir 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 Enregistré à 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 c'est important Suit l'efficacité des étapes initiales de validation des données. Les retards ici peuvent créer des goulots d'étranglement en amont et augmenter la probabilité d'erreurs de paiement plus tard dans le processus. Où obtenir 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 c'est 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. Où obtenir 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 c'est 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. Où obtenir 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 c'est important Ce jalon est crucial 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. Où obtenir 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 c'est important Le suivi de cet événement final est crucial pour calculer le taux 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. Où obtenir 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 c'est important Cela marque le début du sous-processus d'approbation. Mesurer le temps entre ce point et le « Paiement approuvé » est essentiel pour le dashboard d'« Analyse du temps de cycle d'approbation des paiements ». Où obtenir 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 c'est 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. Où obtenir 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 retravail. | ||
| Pourquoi c'est important Identifie le retravail 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 retravail. Où obtenir 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 Enregistré 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,ActivityNameetEventTimestamp. 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'
EventTimestampest 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;