Il template dei dati per l’elaborazione dei pagamenti
Il template dei dati per l’elaborazione dei pagamenti
- Attributi consigliati da raccogliere
- Attività principali da monitorare
- Indicazioni per l’estrazione dei dati da ACI Worldwide
Attributi dell’elaborazione dei pagamenti
| Nome | Descrizione | ||
|---|---|---|---|
| Data e ora dell’evento EventTimestamp | La data e l’ora esatte in cui si è verificata l’attività. | ||
| Descrizione Questo attributo registra il momento esatto in cui si è verificato un evento nell’ambiente ACI. Viene utilizzato per calcolare tutte le metriche basate sul tempo, inclusi i tempi di ciclo, la durata delle approvazioni e i tassi di elaborazione. Per ordinare correttamente le fasi automatizzate che si susseguono rapidamente, è preferibile una precisione elevata, al millisecondo. Perché è importante È essenziale per ordinare gli eventi e calcolare la durata delle prestazioni. Dove reperirli Consulti le colonne 'Data di creazione' o 'Data di aggiornamento' nella cronologia delle transazioni o nelle tabelle del registro di controllo. Esempi 2023-10-25T08:30:15.000Z2023-10-25T08:30:22.500Z2023-10-26T14:10:00.000Z | |||
| ID della transazione di pagamento PaymentTransactionId | Identificativo univoco della specifica istruzione di pagamento all’interno del sistema ACI. | ||
| Descrizione Questo attributo funge da chiave centrale per l’analisi di Process Mining e collega tutti gli eventi relativi a una singola richiesta di pagamento. Nei sistemi ACI Worldwide, come MTS o UPP, corrisponde al numero di riferimento univoco assegnato alla transazione al momento dell’inserimento. Consente di ricostruire l’intero percorso del pagamento, dalla richiesta iniziale fino alla convalida, all’approvazione e al regolamento finale. Perché è importante È l’ID del caso fondamentale necessario per raggruppare gli eventi distinti in istanze di processo. Dove reperirli Consulti le tabelle di intestazione delle transazioni, in cui i campi sono spesso denominati TRN_REF, REFERENCE_NUM o UUID nel registro principale delle transazioni. Esempi TRX-2023-899102ACI-99281-AAPAY-0019283420231025-9981 | |||
| Nome dell’attività ActivityName | La specifica fase o modifica di stato che si è verificata nel ciclo di vita del pagamento. | ||
| Descrizione Questo attributo definisce il nodo dell’evento nella mappa del processo, ad esempio 'Richiesta di pagamento creata' o 'Fondi trasferiti'. Nei sistemi ACI, spesso deriva dai codici di stato, dai tipi di operazione del registro di controllo o dalle modifiche dello stato del flusso di lavoro. Per ottenere una visualizzazione significativa, è fondamentale associare correttamente questi stati tecnici ad attività aziendali comprensibili. Perché è importante Definisce il flusso del processo ed è necessario per visualizzare la sequenza delle operazioni. Dove reperirli Derivato dai codici di stato (ad es. 100=Creato, 200=Convalidato) o dalle colonne delle azioni del registro di controllo. Esempi Richiesta di pagamento creataPagamento autorizzatoPagamento saldatoPagamento non riuscito | |||
| Canale di elaborazione ProcessingChannel | Il canale attraverso il quale è stato avviato il pagamento. | ||
| Descrizione Indica il punto di ingresso del pagamento, ad esempio app mobile, portale web, API o caricamento di file. Nell’analisi delle varianti del processo di pagamento, consente di verificare se alcuni canali sono più soggetti di altri a errori o ritardi. Perché è importante Consente di segmentare le prestazioni in base al metodo di inserimento. Dove reperirli Intestazione della transazione, spesso con colonne denominate CHANNEL, SOURCE_TYPE o INPUT_METHOD. Esempi SWIFTServizi bancari via InternetApp mobileCaricamento di file | |||
| Codice di errore ErrorCode | Il codice generato quando un pagamento non riesce o deve essere corretto. | ||
| Descrizione Registra la causa specifica di un evento 'Pagamento non riuscito' o 'Errore di pagamento rilevato'. Raggruppando i dati per questo attributo nella Dashboard 'Analisi dei pagamenti non riusciti e delle rilavorazioni', l’azienda può individuare le cause profonde più frequenti dei mancati pagamenti, ad esempio 'Fondi insufficienti' o 'Conto non valido'. Perché è importante È essenziale per analizzare le cause profonde dei problemi di processo. Dove reperirli Registri degli errori o colonne con il motivo dello stato, spesso denominate REASON_CODE o RETURN_CODE. Esempi R01AM04BE05TECH_ERR_001 | |||
| Data di scadenza del pagamento PaymentDueDate | La data entro cui il pagamento deve essere regolato per essere considerato puntuale. | ||
| Descrizione Memorizza la data di esecuzione contrattuale o richiesta. Questa data viene confrontata con quella effettiva del regolamento per calcolare il KPI 'Tasso di pagamenti puntuali' e alimentare la Dashboard 'Conformità alle scadenze dei pagamenti'. Perché è importante Il valore di riferimento per misurare la conformità agli SLA e la puntualità dei pagamenti. Dove reperirli Istruzioni di transazione, in genere VALUE_DATE, EXECUTION_DATE o DUE_DATE. Esempi 2023-11-012023-11-05 | |||
| È una rilavorazione IsRework | Indicatore che segnala se il pagamento ha comportato la ripetizione di attività. | ||
| Descrizione Indicatore booleano calcolato durante l’elaborazione dei dati. Viene impostato su true se attività come 'Dati del pagamento convalidati' si verificano più di una volta o se viene rilevato un ciclo di errore. Alimenta il KPI 'Tasso di rilavorazione dei pagamenti'. Perché è importante Consente di individuare rapidamente i casi inefficienti senza ricorrere a query di processo complesse. Dove reperirli 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. È un dato di contesto fondamentale per analizzare il volume dei pagamenti e stabilire le priorità degli interventi sui colli di bottiglia. I pagamenti di importo elevato seguono spesso percorsi di approvazione più rigorosi, analizzabili tramite le varianti, rispetto ai flussi automatizzati di importo ridotto. Perché è importante Consente di segmentare i pagamenti per importo e di calcolare il volume totale elaborato. Dove reperirli Tabelle di dettaglio delle transazioni, in genere con campi come AMT, TRANS_AMOUNT o PRINCIPAL_AMOUNT. Esempi 1500.00250000.5050.001000000.00 | |||
| Reparto Department | Il reparto interno responsabile dell’attività corrente. | ||
| Descrizione Associa Perché è importante Aggrega le prestazioni per funzione aziendale. Dove reperirli Ricavato dalle tabelle degli utenti o dalla mappatura della gerarchia organizzativa. Esempi OperazioniComplianceTesoreriaAssistenza IT | |||
| Tipo di pagamento PaymentType | La classificazione dello strumento di pagamento. | ||
| Descrizione Classifica il pagamento, ad esempio come bonifico, ACH, SEPA o RTGS. I diversi tipi di pagamento hanno spesso SLA e flussi di processo molto diversi. Questo attributo è una dimensione principale per filtrare la Dashboard 'Analisi del tempo di ciclo end-to-end dei pagamenti'. Perché è importante È fondamentale per distinguere i flussi di pagamento rapidi da quelli elaborati in lotti. Dove reperirli Intestazione della transazione, con campi come PMT_TYPE, INSTRUMENT_TYPE o SERVICE_ID. Esempi Bonifico nazionaleBonifico internazionaleAccredito ACHPagamento istantaneo | |||
| Utente dell’evento EventUser | L’ID utente o dell’agente di sistema responsabile dell’attività. | ||
| Descrizione Registra chi ha eseguito l’azione, che si tratti di un utente (ad es. per le approvazioni) o di un account di sistema (ad es. per il regolamento automatizzato). Questo attributo è fondamentale per l’Analisi dei colli di bottiglia, che consente di individuare utenti o code sovraccarichi. Perché è importante Consente di analizzare le risorse e verificare la separazione dei compiti. Dove reperirli Registri di controllo o colonne 'UpdatedBy' nelle tabelle delle transazioni. Esempi SYSTEM_AGENT_01j.doeapprover_group_aBATCH_PROCESS | |||
| Valuta del pagamento PaymentCurrency | Il codice ISO della valuta dell’importo del pagamento. | ||
| Descrizione Specifica la valuta in cui è espresso Perché è importante È necessario per interpretare correttamente l’importo del pagamento. Dove reperirli Tabelle di dettaglio delle transazioni, in genere con campi come CCY, CURRENCY_CODE o ISO_CODE. Esempi USDEURGBPJPY | |||
| Area di origine OriginatingRegion | L’area geografica da cui ha avuto origine la richiesta di pagamento. | ||
| Descrizione Indica la sede fisica o logica del richiedente. Nell’analisi delle varianti del processo di pagamento, consente di verificare se alcune aree seguono percorsi non standard o registrano tassi di rifiuto più elevati. Perché è importante Fornisce il contesto geografico per analizzare le prestazioni del processo. Dove reperirli Intestazione della transazione, spesso ricavata dal codice della filiale o dal codice del Paese. Esempi Nord AmericaEuropa, Medio Oriente e AfricaAsia-Pacifico | |||
| ID di riconciliazione ReconciliationId | Identificativo che collega il pagamento al libro mastro generale o al record di riconciliazione. | ||
| Descrizione Questo ID viene valorizzato quando si verifica l’attività 'Pagamento riconciliato'. Verifica che il pagamento nel motore di elaborazione corrisponda alla registrazione nel sistema contabile. Se manca per pagamenti già regolati, può indicare problemi di riconciliazione. Perché è importante È fondamentale per la Dashboard 'Efficienza della riconciliazione dei pagamenti'. Dove reperirli Tabelle di riconciliazione o campi specifici come RECON_REF o GL_REF. Esempi REC-9921GL-Entry-2023-11 | |||
| Nome del beneficiario BeneficiaryName | Il nome dell’entità che riceve il pagamento. | ||
| Descrizione Identifica la controparte della transazione. L’analisi di questo campo può aiutare a individuare fornitori o clienti specifici associati a tassi elevati di rilavorazione o a ritardi, a supporto dell’analisi dei pagamenti non riusciti e delle rilavorazioni. Perché è importante Identifica il destinatario del pagamento ed è utile per le analisi incentrate sul cliente. Dove reperirli Righe di dettaglio del pagamento, con campi come CREDITOR_NAME, BENE_NAME o PAYEE. Esempi Acme CorpGlobal Supplies LtdJohn Smith | |||
| Pagamento in ritardo IsPaymentLate | Indicatore che segnala se il pagamento è stato regolato dopo la data di scadenza. | ||
| Descrizione Indicatore booleano che confronta la data effettiva del regolamento con Perché è importante Semplifica la rendicontazione sulla conformità. Dove reperirli Calcolato come: SettlementDate > PaymentDueDate. Esempi truefalse | |||
| Sistema di origine SourceSystem | Il nome del sistema da cui provengono i dati dell’evento. | ||
| Descrizione Identifica l’applicazione o il modulo specifico nell’ecosistema ACI Worldwide, ad esempio ACI MTS o ACI UPF, oppure i sistemi esterni coinvolti nel flusso. È particolarmente importante quando si integrano dati provenienti da più libri mastri o quando il pagamento coinvolge sistemi esterni di compensazione. Perché è importante Indica il contesto di origine dei dati estratti ed è utile per individuare problemi nella loro provenienza. Dove reperirli Impostato durante l’estrazione o ricavato da una colonna SystemID se sono presenti più istanze. Esempi ACI MTSACI UPPSAP GLSwift Gateway | |||
| Tempo di ciclo dell’approvazione ApprovalCycleTime | Tempo trascorso nella fase di approvazione. | ||
| Descrizione Calcola il tempo che intercorre tra 'Pagamento inviato per l’approvazione' e 'Pagamento approvato' (o rifiutato). Questa metrica alimenta la Dashboard 'Analisi del tempo di ciclo dell’approvazione dei pagamenti' e mette in evidenza i ritardi nelle fasi che richiedono una decisione umana. Perché è importante Isola la parte del processo che dipende dall’intervento umano. Dove reperirli Calcolato come: Timestamp(Payment Approved) - Timestamp(Payment Sent For Approval). Esempi 4 ore15 minuti | |||
| Ultimo aggiornamento dei dati LastDataUpdate | Data e ora dell’ultima estrazione o dell’ultimo aggiornamento del record nel modello di dati. | ||
| Descrizione Indica quanto sono aggiornati i dati utilizzati nell’analisi. Non rappresenta l’ora di un evento di processo, bensì il momento tecnico in cui i dati sono stati acquisiti. Consente agli analisti di sapere se stanno consultando dati in tempo reale o una fotografia storica. Perché è importante Consente di verificare l’attualità dei dati e di individuare quelli non aggiornati nelle Dashboard. Dove reperirli Ora di sistema al momento dell’esecuzione dello script ETL. Esempi 2023-10-27T00:00:00.000Z2023-10-27T12:00:00.000Z | |||
Attività di elaborazione dei pagamenti
| Attività | Descrizione | ||
|---|---|---|---|
| Errore di pagamento rilevato | Indica che il sistema ha rilevato un problema con il pagamento in una delle fasi del processo, ad esempio dati non validi o un avviso di conformità. In genere, l’evento viene registrato esplicitamente insieme al codice di errore corrispondente. | ||
| Perché è importante Questa attività è il punto di partenza per tutte le analisi delle rilavorazioni e della gestione delle eccezioni. È essenziale per le Dashboard 'Analisi dei pagamenti non riusciti e delle rilavorazioni' e 'Tempo di ciclo della risoluzione degli errori'. Dove reperirli Cerchi voci esplicite in una tabella del registro degli errori oppure una modifica dello stato a 'Errore' o 'Richiede correzione' nella tabella delle transazioni. Questi eventi devono essere associati all’ID della transazione di pagamento. Acquisizione Viene registrato un evento esplicito quando il motore di convalida o di elaborazione del sistema segnala un errore. Tipo di evento explicit | |||
| Fondi trasferiti | Indica che la rete di pagamento ha confermato l’addebito dei fondi sul conto del pagatore. In genere, la conferma viene acquisita da un messaggio di stato in entrata dalla rete. | ||
| Perché è importante Conferma che la rete esterna ha eseguito correttamente il pagamento. Segna l’inizio del periodo di regolamento ed è un dato fondamentale per il KPI «Tempo medio di regolamento dei pagamenti». Dove reperirli È un evento esplicito generato da un messaggio in entrata di aggiornamento dello stato, ad esempio un MT103 da SWIFT o una conferma ACH, che aggiorna il record del pagamento. Acquisizione Registrato alla ricezione di un messaggio di conferma esterno dalla rete di compensazione. Tipo di evento explicit | |||
| Pagamento approvato | È una tappa fondamentale: un utente autorizzato approva il pagamento, consentendone l’esecuzione. Di solito viene registrata come evento esplicito quando l’approvatore interviene nell’interfaccia utente del sistema. | ||
| Perché è importante Questa attività è un passaggio di controllo importante e spesso rappresenta un collo di bottiglia significativo. Analizzare i tempi di attesa prima di questa fase e la durata del ciclo di approvazione aiuta a individuare le opportunità per accelerare i pagamenti. Dove reperirli Cerchi un evento esplicito in una tabella del log delle approvazioni oppure una variazione di stato a «Approvato» nella tabella principale delle transazioni, associata all’azione di un utente specifico e alla relativa marca temporale. Acquisizione Registrato quando un utente autorizzato completa l’approvazione nel sistema. Tipo di evento explicit | |||
| Pagamento autorizzato | Indica l’autorizzazione del pagamento a livello di sistema dopo l’approvazione umana, con la verifica dei fondi o il controllo delle regole antifrode. Può essere registrata come voce esplicita nel log oppure dedotta da una variazione di stato che indica che il pagamento è pronto per l’esecuzione. | ||
| Perché è importante È un punto di controllo fondamentale prima che venga impartito l’ordine di trasferimento dei fondi. I ritardi in questa fase possono indicare problemi di prestazioni del sistema o difficoltà nei sottosistemi di conformità e controllo delle frodi. Dove reperirli Verifichi la presenza di una voce esplicita nel log di elaborazione del sistema o nel log di sicurezza. In alternativa, può dedurla dall’aggiornamento dello stato da «Approvato» a «Autorizzato per il pagamento». Acquisizione Registrato dal motore di pagamento del sistema dopo il superamento dei controlli interni finali. Tipo di evento explicit | |||
| Pagamento saldato | È la conferma finale che il processo di pagamento è terminato e che i fondi sono stati accreditati al beneficiario, concludendo la transazione. È un evento fondamentale, che segna il completamento del ciclo di vita del pagamento. | ||
| Perché è importante È il principale evento finale che indica il completamento corretto del processo. Serve a calcolare il tempo di ciclo complessivo e il volume delle operazioni ed è essenziale per quasi tutte le Dashboard sulle prestazioni end-to-end. Dove reperirli In genere è un evento esplicito registrato alla ricezione del messaggio di conferma del regolamento finale dalla rete o all’aggiornamento della contabilità interna per indicare il completamento della transazione. Acquisizione Registrato alla ricezione di un file o messaggio di regolamento definitivo, con aggiornamento dello stato a 'Regolato'. Tipo di evento explicit | |||
| Richiesta di pagamento creata | Questa attività segna l’avvio di una nuova transazione di pagamento nel sistema ACI Worldwide. In genere, corrisponde a un evento 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 È l’evento iniziale principale del processo di pagamento. Analizzare il tempo che intercorre tra questa attività e il completamento permette di calcolare il tempo di ciclo end-to-end, un indicatore essenziale per misurare l’efficienza complessiva del processo. Dove reperirli Probabilmente si tratta di un evento esplicito registrato nella tabella principale delle transazioni o in un Event Log dedicato di ACI. Cerchi una marca temporale di creazione associata all’ID transazione di pagamento. Acquisizione Individuabile nel record di creazione o in un evento esplicito «Crea» nel log delle transazioni. Tipo di evento explicit | |||
| Dettagli del pagamento convalidati | Indica il completamento dei controlli automatici o manuali che verificano la correttezza dei dettagli del pagamento, come le informazioni sul beneficiario e i codici bancari. Spesso si deduce dal passaggio dello stato della transazione da «Nuovo» a «Convalidato» o «In attesa di approvazione». | ||
| Perché è importante Misura l’efficienza delle fasi iniziali di convalida dei dati. Eventuali ritardi in questa fase possono creare colli di bottiglia a monte e aumentare il rischio di errori di pagamento nelle fasi successive. Dove reperirli Si deduce dai campi relativi alle variazioni di stato nella tabella principale delle transazioni di pagamento. Confronti le marche temporali dello stato «Creato» con quelle di uno stato successivo, come «Convalidato». Acquisizione Si deduce da una variazione del campo relativo allo stato del pagamento, ad esempio da «Inserito» a «Convalidato». Tipo di evento inferred | |||
| Errore di pagamento risolto | Indica il momento in cui un utente corregge un errore rilevato in precedenza e il pagamento viene inviato nuovamente per l’elaborazione. Spesso si deduce dalla modifica dello stato del pagamento, che passa da uno stato di errore a uno stato normale di elaborazione. | ||
| Perché è importante Questa attività chiude il ciclo di gestione dell’eccezione. Il tempo che intercorre tra 'Errore di pagamento rilevato' e questo evento corrisponde al tempo di ciclo della risoluzione degli errori, un indicatore chiave dell’efficienza operativa. Dove reperirli Dedotto dal passaggio dallo stato 'Errore' a uno stato di elaborazione, come 'In attesa di approvazione' o 'Convalidato'. Può anche corrispondere a una registrazione esplicita dell’azione dell’utente. Acquisizione Dedotto dal passaggio a uno stato diverso da quello di errore, che indica l’avvenuta correzione. Tipo di evento inferred | |||
| Istruzione di pagamento inviata | Segna il momento in cui l’istruzione di pagamento viene preparata e trasmessa a una rete di pagamento esterna, come SWIFT, ACH o SEPA. I sistemi ACI registrano esplicitamente questo passaggio per finalità di audit e tracciamento. | ||
| Perché è importante Per molti tipi di pagamento, questo è il momento oltre il quale non è più possibile tornare indietro. Monitorarlo aiuta a misurare il tempo di elaborazione interno prima che subentrino dipendenze esterne. Dove reperirli Quasi sempre si tratta di un evento esplicito registrato nei log delle transazioni o dei messaggi di ACI, spesso con un numero di riferimento specifico della rete. Acquisizione Quando il messaggio di pagamento viene inviato alla rete esterna, viene creata una voce esplicita nel log. Tipo di evento explicit | |||
| Pagamento confermato | Indica la conferma interna che il pagamento è stato elaborato correttamente e che è stata ricevuta una conferma. Spesso attiva la notifica al beneficiario o ad altri sistemi interni. | ||
| Perché è importante Questa tappa è fondamentale per misurare il rispetto delle scadenze e il tasso di pagamenti puntuali. Fornisce una marca temporale precisa del momento in cui l’organizzazione considera il pagamento eseguito correttamente. Dove reperirli In genere si deduce da una variazione dello stato nella tabella delle transazioni di pagamento a «Confermato» o «Completato», dopo la ricezione della conferma dalla rete esterna. Acquisizione Si deduce da una variazione di stato a «Confermato» o «Elaborato». Tipo di evento inferred | |||
| Pagamento inviato per l’approvazione | Indica che il pagamento ha superato la convalida iniziale ed è stato inoltrato per la necessaria approvazione manageriale o finanziaria. In genere, viene registrato tramite una variazione di stato nel flusso di lavoro del pagamento. | ||
| Perché è importante Segna l’inizio del sottoprocesso di approvazione. Misurare il tempo che intercorre da questo momento a «Pagamento approvato» è fondamentale per la Dashboard «Analisi del tempo di ciclo di approvazione dei pagamenti». Dove reperirli Si ricava da una variazione del campo relativo allo stato del pagamento nei dati della transazione, ad esempio il passaggio a «In attesa di approvazione». Acquisizione Si deduce da una variazione di stato a «In attesa di approvazione» o simile, insieme alla marca temporale corrispondente. Tipo di evento inferred | |||
| Pagamento non riuscito | Stato terminale che indica che il pagamento non può essere completato a causa di un problema irreversibile. Si distingue da un errore risolvibile e rappresenta uno stato finale di mancato completamento definitivo. | ||
| Perché è importante Il monitoraggio di questo evento finale è fondamentale per calcolare il tasso complessivo di pagamenti non riusciti. Analizzare le cause del mancato completamento può contribuire a migliorare la qualità dei dati e le regole di processo. Dove reperirli Dedotto da uno stato finale, ad esempio 'Non riuscito', 'Annullato' o 'Rifiutato dalla banca', presente nei dati della transazione e che non subisce ulteriori modifiche. Acquisizione Dedotto da uno stato terminale di mancato completamento nel record del pagamento. Tipo di evento inferred | |||
| Pagamento riconciliato | Rappresenta la fase contabile finale, in cui la transazione di pagamento registrata in ACI viene confrontata con gli estratti conto bancari o le registrazioni contabili. Può corrispondere a un evento esplicito generato da un modulo di riconciliazione oppure essere dedotto da una modifica dello stato. | ||
| Perché è importante Questa attività misura l’efficienza del processo di riconciliazione del back office. Eventuali ritardi possono compromettere l’accuratezza della rendicontazione finanziaria e nascondere problemi relativi a pagamenti non ancora regolati. Dove reperirli Queste informazioni possono provenire da un modulo di riconciliazione dedicato all’interno di ACI o da un sistema ERP esterno. Vengono acquisite tramite l’aggiornamento dello stato del pagamento a 'Riconciliato'. Acquisizione Dedotto da un aggiornamento finale dello stato a 'Riconciliato' oppure da dati di riconciliazione associati tramite l’ID pagamento. Tipo di evento inferred | |||
| Pagamento rifiutato | Si verifica quando un approvatore respinge la richiesta di pagamento, che spesso deve essere corretta e inviata di nuovo. È un evento esplicito che interrompe l’avanzamento del pagamento e avvia un ciclo di rilavorazione. | ||
| Perché è importante Consente di individuare rilavorazioni e inefficienze di processo. Monitorare la frequenza dei rifiuti aiuta a diagnosticare problemi nella qualità iniziale dei dati o nelle procedure di invio e supporta l’analisi della rilavorazione. Dove reperirli Registrato come evento esplicito nel log delle approvazioni o come variazione di stato a «Rifiutato» nella tabella delle transazioni. L’evento può includere un codice che indica il motivo del rifiuto. Acquisizione Registrato quando un approvatore completa il rifiuto nel sistema. Tipo di evento explicit | |||
Guide all’estrazione
Passaggi
Accedere all’ambiente del database: acceda all’istanza di SQL Server che ospita il database ACI Postilion Realtime tramite SQL Server Management Studio (SSMS) o un client compatibile.
Individuare le tabelle principali: individui le tabelle
post_tran(log delle transazioni) epost_tran_cust(estensione dei dati personalizzati). Verifichi di disporre delle autorizzazioniSELECTsu questi oggetti.Determinare l’identificativo del caso: questa estrazione utilizza
retrieval_reference_nrcomePaymentTransactionId. Se l’implementazione usa una chiave univoca diversa, ad esempiosystem_trace_audit_nrinsieme atransmission_date_time, modifichi di conseguenza la selezione nella query.Configurare i parametri del filtro: apra la query riportata di seguito. Individui le variabili
@StartDatee@EndDateall’inizio dello script e imposti l’intervallo di estrazione desiderato, ad esempio gli ultimi 30-90 giorni, per ottimizzare le prestazioni.Rivedere la logica delle attività: la query associa i tipi di messaggio ISO 8583 (ad esempio 0200, 0210) e i codici di risposta alle 14 attività di Process Mining richieste. Riveda le istruzioni
CASEper verificare che siano coerenti con la configurazione specifica 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 Event Log.Verificare i dati in output: controlli che siano presenti le colonne richieste:
PaymentTransactionId,ActivityNameeEventTimestamp. Verifichi che i campi essenziali non contengano valoriNULLinattesi.Esportare i dati: faccia clic con il pulsante destro del mouse sulla griglia dei risultati in SSMS e salvi i dati in un file CSV, ad esempio
ACI_Payments_EventLog.csv.Preparare il file 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 i dati: importi il CSV verificato in ProcessMind, associando rispettivamente le colonne a ID del caso, Attività e Timestamp.
Configurazione
- Intervallo di date: le tabelle ACI
post_trancrescono molto rapidamente. Si consiglia vivamente di limitare l’estrazione a una finestra mobile di 3 mesi o di utilizzare il cambio di partizione, se disponibile. - Codici di risposta: la query presuppone che
rsp_code = '00'indichi un esito positivo. Se l’istituto utilizza codici diversi per l’approvazione o l’esito positivo, ad esempio '08' o '10', aggiorni i filtri. - Tipi di messaggio (ISO 8583): lo script si basa sui tipi di messaggio standard (0100/0200 per le richieste, 0210 per le risposte). Potrebbe essere necessario apportare modifiche per i tipi di messaggio personalizzati definiti nella configurazione
source_node_name. - Prestazioni del sistema: la query utilizza suggerimenti
NOLOCKper evitare blocchi durante l’elaborazione delle transazioni in tempo reale. Non rimuova questi suggerimenti in un ambiente di produzione. - Valute: gli importi vengono estratti come valori grezzi. Se durante l’analisi è necessario uniformare più valute, verifichi che venga utilizzato
tran_currency_code.
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;È pronto a iniziare?
Utilizzi questo template come guida per iniziare a estrarre i dati relativi all’elaborazione dei pagamenti. Ottenga informazioni utili e migliori l’efficienza dei flussi di lavoro finanziari.
Renda più efficiente l’elaborazione dei pagamenti: inizi subito la prova gratuita
Elimini le eccezioni nei pagamenti e raggiunga il 98% di elaborazione senza interventi manuali.
Non è richiesta una carta di credito; la configurazione richiede pochi minuti