Il Suo Template di Dati per l'Elaborazione Pagamenti
Il Suo Template di Dati per l'Elaborazione Pagamenti
- Attributi consigliati da raccogliere
- Attività chiave da tracciare
- Guida all'estrazione per ACI Worldwide
Attributi di Elaborazione Pagamenti
| Nome | Descrizione | ||
|---|---|---|---|
| ID Transazione di Pagamento PaymentTransactionId | L'identificatore univoco per l'istruzione di pagamento specifica all'interno del sistema ACI. | ||
| Descrizione Questo Perché è importante È l'ID Caso fondamentale richiesto per raggruppare eventi discreti in istanze di processo. Dove trovare Controlli le tabelle di intestazione delle transazioni, spesso etichettate come TRN_REF, REFERENCE_NUM o UUID nel log principale delle transazioni. Esempi TRX-2023-899102ACI-99281-AAPAY-0019283420231025-9981 | |||
| Nome attività ActivityName | La fase specifica o la modifica di stato che si è verificata nel ciclo di vita del pagamento. | ||
| Descrizione Questo Perché è importante Definisce il flusso di processo ed è necessario per visualizzare la sequenza delle operazioni. Dove trovare Derivato dai Codici di Stato (es. 100=Creato, 200=Validato) o dalle colonne Azione del Log di Audit. Esempi Richiesta di Pagamento CreataPagamento AutorizzatoPagamento SaldatoPagamento Fallito | |||
| Timestamp Evento EventTimestamp | La data e l'ora specifiche in cui si è verificata l'attività. | ||
| Descrizione Questo Perché è importante Essenziale per l'ordinamento degli eventi e il calcolo delle durate delle prestazioni. Dove trovare Consulti le colonne 'Data Creazione' o 'Data Aggiornamento' nelle tabelle della cronologia delle transazioni o di audit. Esempi 2023-10-25T08:30:15.000Z2023-10-25T08:30:22.500Z2023-10-26T14:10:00.000Z | |||
| Canale di Elaborazione ProcessingChannel | Il canale tramite cui il pagamento è stato avviato. | ||
| Descrizione Indica il punto di ingresso del pagamento, come Mobile, Portale Web, API o Caricamento File. Questo aiuta nell'analisi delle varianti di processo di pagamento ('Payment Process Variant Analysis') per vedere se determinati canali sono più soggetti a errori o ritardi rispetto ad altri. Perché è importante Segmenta le prestazioni in base al metodo di inserimento. Dove trovare Intestazione transazione, spesso in colonne denominate CHANNEL, SOURCE_TYPE o INPUT_METHOD. Esempi SWIFTInternet BankingApp MobileCaricamento File | |||
| Codice Errore ErrorCode | Il codice generato quando un pagamento fallisce o richiede una riparazione. | ||
| Descrizione Cattura il motivo specifico di un evento 'Pagamento Fallito' o 'Errore di Pagamento Identificato'. Il raggruppamento per questo attributo nel dashboard 'Analisi dei Fallimenti e delle Rilavorazioni dei Pagamenti' consente all'azienda di identificare le cause radice più comuni del fallimento (es. 'Fondi Insufficienti', 'Conto Non Valido'). Perché è importante Essenziale per l'analisi delle cause radice dei fallimenti di processo. Dove trovare Log degli errori o colonne di motivazione dello stato, spesso REASON_CODE o RETURN_CODE. Esempi R01AM04BE05TECH_ERR_001 | |||
| Data Scadenza Pagamento PaymentDueDate | La data entro la quale il pagamento deve essere regolato per essere considerato puntuale. | ||
| Descrizione Memorizza la data di esecuzione contrattuale o richiesta. Questa data viene confrontata con la data di regolamento effettiva per calcolare il Perché è importante Il Dove trovare Istruzioni di transazione, di solito VALUE_DATE, EXECUTION_DATE o DUE_DATE. Esempi 2023-11-012023-11-05 | |||
| Dipartimento Department | Il dipartimento interno responsabile dell'attività corrente. | ||
| Descrizione Mappa l' Perché è importante Aggrega le prestazioni per funzione aziendale. Dove trovare Derivato dalle tabelle Utente o dalla mappatura della Gerarchia Organizzativa. Esempi OperazioniComplianceTesoreríaSupporto IT | |||
| È una Rilavorazione IsRework | Flag che indica se il pagamento è stato soggetto ad attività ripetitive. | ||
| Descrizione Un flag booleano calcolato durante l'elaborazione dei dati. È impostato su 'vero' se attività come 'Dettagli di Pagamento Validati' si verificano più di una volta o se viene rilevato un ciclo di errore. Questo alimenta l'indicatore KPI 'Tasso di Rilavorazione dei Pagamenti'. Perché è importante Identifica rapidamente i casi inefficienti senza complesse Dove trovare Calcolato nella pipeline dei dati verificando la presenza di attività duplicate per ogni caso. Esempi truefalse | |||
| Importo del Pagamento PaymentAmount | Il valore monetario della transazione di pagamento. | ||
| Descrizione Indica il valore finanziario trasferito. Questo è un campo di contesto critico per analizzare il 'Throughput dei Pagamenti' e prioritizzare i colli di bottiglia. I pagamenti di alto valore spesso seguono percorsi di approvazione più rigorosi (analisi delle varianti) rispetto ai flussi automatizzati di basso valore. Perché è importante Consente la segmentazione per valore e il calcolo del volume totale elaborato. Dove trovare Tabelle di dettaglio transazione, tipicamente campi come AMT, TRANS_AMOUNT o PRINCIPAL_AMOUNT. Esempi 1500.00250.000,5050.001.000.000,00 | |||
| Tempo di Ciclo End-to-End EndToEndCycleTime | La durata totale dalla creazione della richiesta al regolamento. | ||
| Descrizione Calcola la differenza di tempo tra 'Richiesta di Pagamento Creata' e 'Pagamento Saldata'. Questa funge da metrica principale per il KPI 'Tempo Medio di Ciclo della Transazione di Pagamento' e per l'analisi complessiva dell'efficienza. Perché è importante La metrica di livello superiore per la velocità del processo. Dove trovare Calcolato: Timestamp(Pagamento Saldata) - Timestamp(Richiesta di Pagamento Creata). Esempi 2 giorni 4 ore45 minuti12 secondi | |||
| Tipo di Pagamento PaymentType | La classificazione dello strumento di pagamento. | ||
| Descrizione Categorizza il pagamento (es. bonifico, ACH, SEPA, RTGS). Diversi tipi di pagamento hanno spesso SLA e flussi di processo molto diversi. Questo attributo è una dimensione primaria per filtrare il dashboard 'Tempo di Ciclo del Pagamento End-to-End'. Perché è importante Critico per distinguere tra flussi di pagamento ad alta velocità e in batch. Dove trovare Intestazione transazione, campi come PMT_TYPE, INSTRUMENT_TYPE o SERVICE_ID. Esempi Bonifico DomesticoBonifico InternazionaleCredito ACHPagamento Istantaneo | |||
| Utente Evento EventUser | L'ID utente o l'agente di sistema responsabile dell'attività. | ||
| Descrizione Cattura chi ha eseguito l'azione, sia un utente umano (es. per le approvazioni) o un account di sistema (es. per il saldo automatico). Questo attributo è vitale per l'analisi dei colli di bottiglia ( Perché è importante Consente l'analisi delle risorse e l'audit della segregazione dei compiti. Dove trovare Log di audit o colonne 'UpdatedBy' nelle tabelle delle transazioni. Esempi SYSTEM_AGENT_01j.doegruppo_approvatore_aBATCH_PROCESS | |||
| Valuta del Pagamento PaymentCurrency | Il codice valuta ISO per l'importo del pagamento. | ||
| Descrizione Specifica la valuta in cui è denominato il Perché è importante Necessario per interpretare correttamente l'Importo del Pagamento. Dove trovare Tabelle di dettaglio transazione, tipicamente campi come CCY, CURRENCY_CODE o ISO_CODE. Esempi USDEURGBPJPY | |||
| ID di Riconciliazione ReconciliationId | Identificatore che collega il pagamento al libro mastro generale o al record di riconciliazione. | ||
| Descrizione Questo ID viene popolato quando si verifica l'attività Perché è importante Critico per il dashboard 'Efficienza di Riconciliazione dei Pagamenti'. Dove trovare Tabelle di riconciliazione o campi specifici come RECON_REF o GL_REF. Esempi REC-9921GL-Entry-2023-11 | |||
| Nome Beneficiario BeneficiaryName | Il nome dell'entità che riceve il pagamento. | ||
| Descrizione Identifica la controparte nella transazione. L'analisi di questo campo può aiutare a individuare fornitori o clienti specifici associati ad alti tassi di rilavorazione o ritardi, supportando l'analisi dei 'Fallimenti e Rilavorazioni dei Pagamenti'. Perché è importante Identifica il destinatario del pagamento, utile per l'analisi incentrata sul cliente. Dove trovare Linee di dettaglio del pagamento, campi come CREDITOR_NAME, BENE_NAME o PAYEE. Esempi Acme CorpGlobal Supplies LtdJohn Smith | |||
| Pagamento in Ritardo IsPaymentLate | Flag che indica se il pagamento è stato saldato dopo la data di scadenza. | ||
| Descrizione Un flag booleano che confronta la data di saldatura effettiva con la Perché è importante Semplifica la rendicontazione della Dove trovare Calcolato: DataSaldatura > DataScadenzaPagamento. Esempi truefalse | |||
| Regione di Origine OriginatingRegion | La regione geografica di origine della richiesta di pagamento. | ||
| Descrizione Indica la posizione fisica o logica del richiedente. Questo è utile per l''Analisi delle Varianti del Processo di Pagamento' per vedere se regioni specifiche seguono percorsi non standard o sperimentano tassi di rifiuto più elevati. Perché è importante Fornisce contesto geografico alle prestazioni del processo. Dove trovare Intestazione transazione, spesso derivata da Codice Filiale o Codice Paese. Esempi Nord AmericaEMEAAPAC | |||
| Sistema di Origine SourceSystem | Il nome del sistema da cui provengono gli `event data`. | ||
| Descrizione Identifica l'applicazione o il modulo specifico all'interno dell'ecosistema ACI Worldwide (es. ACI MTS, ACI UPF) o i sistemi esterni coinvolti nel flusso. Questo è particolarmente importante quando si uniscono dati da più registri o quando il pagamento coinvolge camere di compensazione esterne. Perché è importante Fornisce il contesto su dove sono stati estratti i Dove trovare Hardcoded durante l'estrazione o derivato da una colonna SystemID se esistono più istanze. Esempi ACI MTSACI UPPSAP GLGateway SWIFT | |||
| Tempo del Ciclo di Approvazione ApprovalCycleTime | Durata trascorsa nella fase di approvazione. | ||
| Descrizione Calcola il tempo tra 'Pagamento Inviato per Approvazione' e 'Pagamento Approvato' (o Rifiutato). Questa metrica specifica alimenta il dashboard 'Analisi del Tempo di Ciclo di Approvazione dei Pagamenti', evidenziando i ritardi nelle fasi decisionali umane. Perché è importante Isola la parte del processo dipendente dall'uomo. Dove trovare Calcolato: Timestamp(Pagamento Approvato) - Timestamp(Pagamento Inviato per Approvazione). Esempi 4 ore15 minuti | |||
| Ultimo `Data Update` LastDataUpdate | Il `timestamp` di quando il record è stato estratto o aggiornato l'ultima volta nel `data model`. | ||
| Descrizione Traccia la freschezza dei Perché è importante Garantisce l'attualità dei dati e aiuta a identificare i dati obsoleti nei dashboard. Dove trovare Ora di sistema al momento dell'esecuzione dello Esempi 2023-10-27T00:00:00.000Z2023-10-27T12:00:00.000Z | |||
Attività di Elaborazione Pagamenti
| Activity | Descrizione | ||
|---|---|---|---|
| Errore di Pagamento Identificato | Indica che il sistema ha rilevato un problema con il pagamento in una certa fase, come dati non validi o un avviso di conformità. Questo evento viene tipicamente registrato esplicitamente con un codice di errore associato. | ||
| Perché è importante Questa attività è il punto di partenza per tutte le analisi di rilavorazione e gestione delle eccezioni. È essenziale per le Dove trovare Cerchi voci esplicite in una tabella di log degli errori o un cambiamento di stato a 'Errore' o 'Richiede Correzione' nella tabella delle transazioni. Questi eventi dovrebbero essere collegati all'ID di Transazione di Pagamento. Acquisisci Un evento esplicito viene registrato quando il motore di validazione o elaborazione del sistema segnala un errore. Tipo di evento explicit | |||
| Fondi trasferiti | Indica che è stata ricevuta una conferma dalla rete di pagamento che i fondi sono stati correttamente addebitati dal conto del pagatore. Questo viene solitamente catturato da un messaggio di stato in entrata dalla rete. | ||
| Perché è importante Conferma l'avvenuta esecuzione del pagamento da parte della rete esterna. Segna l'inizio del periodo di saldatura ed è un input chiave per il KPI 'Tempo Medio di Saldatura del Pagamento'. Dove trovare Questo è un Acquisisci Registrato al ricevimento di un messaggio di conferma esterno dalla rete di compensazione. Tipo di evento explicit | |||
| Pagamento Approvato | Un momento chiave in cui un utente autorizzato approva il pagamento, consentendone l'esecuzione. Questo viene solitamente catturato come un evento esplicito quando l'approvatore agisce nell'interfaccia utente del sistema. | ||
| Perché è importante Questa attività è un punto di controllo importante e spesso un Dove trovare Cerchi un evento esplicito in una tabella di log di approvazione o un cambiamento di stato a 'Approvato' nella tabella principale delle transazioni che sia collegato a un'azione utente e a un timestamp specifici. Acquisisci Registrato quando un utente autorizzato completa l'azione di approvazione nel sistema. Tipo di evento explicit | |||
| Pagamento Autorizzato | Rappresenta l'autorizzazione a livello di sistema del pagamento dopo l'approvazione umana, verificando i fondi o controllando le regole antifrode. Questo può essere una voce di `log` esplicita o dedotto da una modifica di stato che indica la prontezza per l'esecuzione. | ||
| Perché è importante Questo è un punto di controllo critico prima che venga istruito lo spostamento dei fondi. I ritardi in questa fase possono indicare problemi di prestazioni del sistema o problemi con i sottosistemi di Dove trovare Verifichi la presenza di un log esplicito in un log di elaborazione di sistema o di sicurezza. In alternativa, può essere dedotto da un aggiornamento di stato da 'Approvato' a 'Autorizzato per il Pagamento'. Acquisisci Registrato dal motore di pagamento del sistema dopo aver superato i controlli interni finali. Tipo di evento explicit | |||
| Pagamento Saldato | La conferma finale che il processo di pagamento è completo e i fondi sono stati accreditati al beneficiario, concludendo la transazione. Questo è un `event` critico, che rappresenta la fine riuscita del ciclo di vita del pagamento. | ||
| Perché è importante Questo è l' Dove trovare Tipicamente un Acquisisci Registrato al ricevimento di un file o messaggio di saldatura finale, aggiornando lo stato a 'Saldato'. Tipo di evento explicit | |||
| Richiesta di Pagamento Creata | Questa attività segna l'avvio di una nuova transazione di pagamento all'interno del sistema ACI Worldwide. È tipicamente un `event` esplicito registrato quando un utente o un sistema a monte invia una richiesta di pagamento, creando un nuovo record di transazione con un ID univoco. | ||
| Perché è importante Questo è l' Dove trovare Questo è probabilmente un Acquisisci Identificato dal record di creazione o da un evento esplicito 'Crea' nel log delle transazioni. Tipo di evento explicit | |||
| Dettagli Pagamento Validati | Rappresenta il completamento di controlli automatici o manuali per garantire che i dettagli di pagamento, come le informazioni sul beneficiario e i codici bancari, siano corretti. Questa attività è spesso dedotta da una modifica dello stato della transazione da | ||
| Perché è importante Traccia l'efficienza dei passaggi iniziali di validazione dei Dove trovare Dedotto dai campi di cambio stato nella tabella principale delle transazioni di pagamento. Confronti i timestamp tra lo stato 'Creato' e uno stato successivo 'Validato' o simile. Acquisisci Dedotto da un cambiamento nel campo dello stato del pagamento, ad esempio, da 'Inserito' a 'Validato'. Tipo di evento inferred | |||
| Errore di Pagamento Risolto | Segna il punto in cui un errore precedentemente identificato è stato corretto da un utente e il pagamento viene nuovamente inviato per l'elaborazione. Ciò si deduce spesso quando lo stato di un pagamento cambia da uno stato di errore a uno stato di elaborazione normale. | ||
| Perché è importante Questa attività chiude il Dove trovare Dedotto da un cambiamento di stato da uno stato di 'Errore' a uno stato di elaborazione come 'In Attesa di Approvazione' o 'Validato'. Può anche essere un log esplicito di azione utente. Acquisisci Dedotto da un cambiamento di stato da uno stato di errore, indicando che è stata apportata una correzione. Tipo di evento inferred | |||
| Istruzione di Pagamento Inviata | Segna il punto in cui l'istruzione di pagamento viene compilata e trasmessa a una rete di pagamento esterna come SWIFT, ACH o SEPA. I sistemi ACI registrano esplicitamente questo passaggio per scopi di audit e tracciamento. | ||
| Perché è importante Questo è il 'punto di non ritorno' per molti tipi di pagamento. Tracciare questo aiuta a misurare il tempo di elaborazione interno prima che le dipendenze esterne subentrino. Dove trovare Questo è quasi sempre un Acquisisci Viene creata una voce di log esplicita quando il messaggio di pagamento viene inviato alla rete esterna. Tipo di evento explicit | |||
| Pagamento confermato | Rappresenta il riconoscimento interno che il pagamento è stato elaborato con successo e che è stata ricevuta una conferma. Questo spesso funge da punto di innesco per notificare il beneficiario o altri sistemi interni. | ||
| Perché è importante Questa pietra miliare è cruciale per misurare la Dove trovare Questo è tipicamente dedotto da un cambiamento di stato nella tabella delle transazioni di pagamento a uno stato 'Confermato' o 'Completato' dopo aver ricevuto la conferma dalla rete esterna. Acquisisci Dedotto da un cambiamento di stato a 'Confermato' o 'Elaborato'. Tipo di evento inferred | |||
| Pagamento Fallito | Uno stato terminale che indica che il pagamento non ha potuto essere completato a causa di un problema irrecuperabile. Questo è distinto da un errore risolvibile e rappresenta uno stato finale di fallimento definitivo. | ||
| Perché è importante Tracciare questo Dove trovare Dedotto da uno stato finale e terminale come 'Fallito', 'Annullato' o 'Rifiutato dalla Banca' nei dati della transazione, che non subisce successive modifiche. Acquisisci Dedotto da uno stato di fallimento terminale nel record di pagamento. Tipo di evento inferred | |||
| Pagamento Inviato per Approvazione | Indica che il pagamento ha superato la validazione iniziale ed è stato instradato per le necessarie approvazioni manageriali o finanziarie. Questo viene tipicamente catturato da un cambiamento di stato all'interno del workflow di pagamento. | ||
| Perché è importante Questo segna l'inizio del sotto-processo di approvazione. Misurare il tempo da questo punto a Dove trovare Derivato da un cambiamento nel campo dello stato del pagamento nei dati di transazione, come il passaggio a 'In Attesa di Approvazione'. Acquisisci Dedotto da un cambiamento di stato a 'In Attesa di Approvazione' o simile, insieme a un timestamp corrispondente. Tipo di evento inferred | |||
| Pagamento Riconciliato | Rappresenta la fase contabile finale in cui la transazione di pagamento registrata in ACI viene abbinata agli estratti conto bancari o alle registrazioni contabili. Questo può essere un `event` esplicito da un modulo di riconciliazione o dedotto da una modifica di stato. | ||
| Perché è importante Questa attività misura l'efficienza del processo di riconciliazione del Dove trovare Queste informazioni potrebbero provenire da un modulo di riconciliazione dedicato all'interno di ACI o da un sistema Acquisisci Dedotto da un aggiornamento di stato finale 'Riconciliato', o da dati di riconciliazione uniti per ID Pagamento. Tipo di evento inferred | |||
| Pagamento Rifiutato | Si verifica quando un approvatore nega la richiesta di pagamento, spesso richiedendo correzione e reinvio. Questo è un evento esplicito che interrompe l'avanzamento del pagamento e avvia un ciclo di rilavorazione. | ||
| Perché è importante Identifica le rilavorazioni e le inefficienze di processo. Monitorare la frequenza dei rifiuti aiuta a diagnosticare i problemi con la qualità dei dati iniziali o le politiche di invio, supportando l'analisi delle rilavorazioni. Dove trovare Catturato come evento esplicito nel log di approvazione o come un cambiamento di stato a 'Rifiutato' nella tabella delle transazioni. L'evento può includere un codice motivo per il rifiuto. Acquisisci Registrato quando un approvatore completa l'azione di rifiuto nel sistema. Tipo di evento explicit | |||
Guide all'Estrazione
Fasi
Accedere all'ambiente del database: Effettui l'accesso all'istanza di SQL Server che ospita il database ACI Postilion Realtime utilizzando SQL Server Management Studio (SSMS) o un client compatibile.
Identificare le tabelle principali: Individui le tabelle
post_tran(log delle transazioni) epost_tran_cust(estensione dati personalizzata). Si assicuri di avere i permessiSELECTsu questi oggetti.Determinare l'identificatore del caso: Questa estrazione utilizza
retrieval_reference_nrcomePaymentTransactionId. Se la Sua implementazione utilizza una chiave univoca diversa (comesystem_trace_audit_nrcombinata contransmission_date_time), adegui di conseguenza la selezione della query.Configurare i parametri di filtro: Apra la query fornita di seguito. Individui le variabili
@StartDatee@EndDateall'inizio dello script. Le imposti per l'intervallo di estrazione desiderato (es. gli ultimi 30 o 90 giorni) per ottimizzare le prestazioni.Rivedere la logica delle attività: La query mappa i tipi di messaggio ISO 8583 (es. 0200, 0210) e i codici di risposta alle 14 attività di Process Mining richieste. Riveda le istruzioni
CASEper assicurarsi che siano allineate alle Sue configurazioni specifiche dell'interfaccia ACI.Eseguire la query: Esegua lo script completo. La query utilizza
UNION ALLper normalizzare i diversi stati delle transazioni in un unico formato di log eventi.Verificare l'output dei dati: Controlli i risultati per le colonne richieste:
PaymentTransactionId,ActivityNameeEventTimestamp. Si assicuri che nessun campo critico contenga valoriNULLinaspettati.Esportare i dati: Faccia clic con il pulsante destro del mouse sulla griglia dei risultati in SSMS e salvi l'output come file CSV (es.
ACI_Payments_EventLog.csv).Formattare per ProcessMind: Apra il CSV e verifichi che
EventTimestampsia in un formato standard (YYYY-MM-DD HH:MM:SS) e chePaymentAmountcontenga solo valori numerici.Caricare: Importi il file CSV verificato in ProcessMind, mappando le colonne rispettivamente a ID Caso, Attività e Timestamp.
Configurazione
- Intervallo di Date: Le tabelle
post_trandi ACI crescono molto rapidamente. È vivamente consigliato limitare l'estrazione a una finestra mobile di 3 mesi o utilizzare il partition switching, se disponibile. - Codici di Risposta: La query presuppone che
rsp_code = '00'indichi il successo. Se la Sua istituzione utilizza codici diversi per approvazione/successo (es. '08' o '10'), aggiorni i filtri. - Tipi di Messaggio (ISO 8583): Lo script si basa su tipi di messaggio standard (0100/0200 per Richieste, 0210 per Risposte). Tipi di messaggio personalizzati definiti nella configurazione del Suo
source_node_namepotrebbero richiedere aggiustamenti. - Prestazioni del Sistema: Questa query utilizza suggerimenti
NOLOCKper prevenire il blocco dell'elaborazione delle transazioni in tempo reale. Non rimuova questi suggerimenti in un ambiente di produzione. - Valute: Gli importi vengono estratti come cifre grezze. Si assicuri che
tran_currency_codesia utilizzato se è richiesta la normalizzazione multi-valuta durante l'analisi.
a Query di Esempio 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;