> Miglioramento continuo dei processi > Elaborazione dei pagamenti > FIS Global > Template dei dati

Il Suo template dei dati per l’elaborazione dei pagamenti

FIS Global

Attributi dell’elaborazione dei pagamenti (19) Attività di elaborazione dei pagamenti (13) Guide all’estrazione (1)

Il Suo template dei dati per l’elaborazione dei pagamenti

Questo template offre indicazioni complete sugli attributi dei dati e sulle attività di processo essenziali per analizzare efficacemente l’elaborazione dei pagamenti. Include inoltre suggerimenti pratici per estrarre queste informazioni dai Suoi sistemi. Utilizzi questa risorsa per raccogliere tutti i dati necessari a un’iniziativa di Process Mining solida.

Attributi consigliati da raccogliere
Attività principali da monitorare
Indicazioni per l’estrazione

Non conosce ancora gli Event Log? Scopra come creare un Event Log per il Process Mining.

Scarica il template

Attributi dell’elaborazione dei pagamenti

Questi sono i campi dati consigliati da includere nell’Event Log per analizzare in modo completo l’elaborazione dei pagamenti.

3 Obbligatorio 7 Consigliato 9 Facoltativo

	Nome	Descrizione
	ID transazione di pagamento PaymentTransactionId	Identificativo univoco della specifica istruzione di pagamento o transazione.
Descrizione Questo attributo è la chiave centrale per collegare tutti gli eventi del ciclo di vita di un singolo pagamento. Consente agli analisti di seguire il pagamento dalla richiesta iniziale fino alla convalida, all’approvazione e al regolamento o alla riconciliazione finale. Nell’analisi, questo ID è essenziale per raggruppare gli eventi distinti in istanze di processo. Consente di visualizzare il flusso end-to-end ed è alla base di tutte le metriche a livello di caso, come il tempo di ciclo e i cicli di rilavorazione. Perché è importante È il collegamento fondamentale per il Process Mining: permette di ricostruire attività diverse in un percorso coerente. Dove reperirli Consultare la documentazione di FIS Global Esempi TRX-2023-899102PAY-US-99281ACH-7721-X99WIRE-2210-001
	Nome dell’attività ActivityName	Nome della specifica fase di processo o dell’evento che si è verificato.
Descrizione Questo campo registra l’azione specifica eseguita in un determinato momento, ad esempio «Richiesta di pagamento creata» o «Pagamento regolato». Definisce i nodi nella mappa del processo e determina la struttura del flusso di processo. Gli analisti utilizzano questo attributo per comprendere la sequenza delle operazioni. È fondamentale per individuare le deviazioni dal percorso ottimale, rilevare i passaggi ignorati o identificare attività ridondanti, come i cicli di approvazione ripetuti. Perché è importante Definisce il «che cosa» del processo e consente di visualizzare le mappe di processo e analizzare le varianti. Dove reperirli Consultare la documentazione di FIS Global Esempi Richiesta di pagamento creataDettagli del pagamento convalidatiPagamento approvatoPagamento regolato
	Timestamp dell’evento EventTimestamp	Data e ora esatte in cui si è verificata l’attività.
Descrizione Questo attributo fornisce il contesto temporale di ogni evento nel processo di pagamento. Registra il momento esatto in cui il sistema ha acquisito un’azione e consente di ordinare cronologicamente le attività. Nell’analisi, viene utilizzato per calcolare la durata tra le fasi, i tempi di ciclo complessivi e i tassi di elaborazione. Consente di individuare i colli di bottiglia mettendo in evidenza i ritardi tra specifiche fasi del processo. Perché è importante Senza questo campo non è possibile svolgere analisi basate sul tempo: da esso dipendono tutti i KPI relativi a prestazioni ed efficienza. Dove reperirli Consultare la documentazione di FIS Global Esempi 2023-10-12T08:30:15Z2023-10-12T09:45:00Z2023-10-13T14:20:10Z
	Codice valuta CurrencyCode	Codice ISO di tre lettere che indica la valuta del pagamento.
Descrizione Questo attributo specifica la valuta dell’importo del pagamento (ad esempio, USD, EUR, GBP). È essenziale per normalizzare i dati finanziari quando si analizzano flussi di pagamento globali. Nell’analisi, consente di segmentare le prestazioni del processo in base alla valuta, spesso correlata a diversi sistemi di compensazione e normative. Aiuta a spiegare le differenze nei tempi di regolamento tra pagamenti transfrontalieri e nazionali. Perché è importante Essenziale negli ambienti multivaluta per interpretare correttamente i volumi finanziari. Dove reperirli Consultare la documentazione di FIS Global Esempi USDEURGBPJPY
	Data di scadenza del pagamento PaymentDueDate	Data entro la quale si prevede che il pagamento venga regolato.
Descrizione Questo attributo registra la scadenza del pagamento richiesta da chi lo ha disposto o definita dalle condizioni della fattura. Costituisce il valore di riferimento per misurare la puntualità. Il campo è fondamentale per la Dashboard «Rispetto delle scadenze di pagamento». Confrontando questa data con la data effettiva di «Pagamento regolato», gli analisti possono individuare i pagamenti in ritardo, calcolare le eventuali penali e valutare il rispetto degli accordi con i fornitori. Perché è importante Fornisce la base di riferimento per misurare il rispetto dei livelli di servizio e la puntualità. Dove reperirli Consultare la documentazione di FIS Global Esempi 2023-11-012023-11-15
	Data effettiva di regolamento ActualSettlementDate	Data in cui il pagamento è stato effettivamente finalizzato e regolato.
Descrizione Questo attributo registra la data effettiva del trasferimento dei fondi o del completamento della transazione. A differenza del timestamp di elaborazione, riflette la data valuta. Nell’analisi, viene utilizzato insieme alla data di scadenza per calcolare la «Percentuale di pagamenti puntuali». Segna inoltre l’inizio della fase di riconciliazione ed è quindi fondamentale per analizzare il «Tempo di ciclo della riconciliazione dei pagamenti». Perché è importante Rappresenta la conclusione finanziaria del pagamento ed è fondamentale per l’analisi dei flussi di cassa. Dove reperirli Consultare la documentazione di FIS Global Esempi 2023-11-022023-11-14
	Importo del pagamento PaymentAmount	Valore monetario della transazione di pagamento.
Descrizione Questo attributo rappresenta il valore finanziario associato alla richiesta di pagamento. È la metrica principale per analizzare i volumi finanziari elaborati e il rischio. Gli analisti utilizzano questo campo per suddividere i processi in base all’importo, distinguendo i pagamenti di valore elevato da quelli di valore ridotto, che spesso seguono percorsi di approvazione diversi. Il campo alimenta la Dashboard «Volumi dei pagamenti» e aiuta a individuare se i pagamenti di importo elevato richiedono tempi di ciclo più lunghi a causa di controlli più rigorosi. Perché è importante Aggiunge la dimensione finanziaria al Process Mining e consente di stabilire le priorità in base al valore. Dove reperirli Consultare la documentazione di FIS Global Esempi 1500.00250.501000000.0045.99
	Tipo di pagamento PaymentType	Classificazione del metodo o dello strumento di pagamento.
Descrizione Questo attributo classifica i pagamenti in base al tipo, ad esempio bonifico, ACH, SEPA, pagamento in tempo reale (RTP) o assegno. Ogni tipo di pagamento segue regole di elaborazione e SLA specifici. Gli analisti utilizzano questo campo per confrontare il «Tempo di ciclo della riconciliazione dei pagamenti» tra i diversi circuiti di pagamento. Aiuta a spiegare perché alcuni pagamenti vengono regolati immediatamente e altri richiedono giorni, assicurando che le prestazioni siano confrontate con il valore di riferimento corretto. Perché è importante È la dimensione principale per segmentare i flussi di processo, poiché ogni tipo presenta caratteristiche specifiche di instradamento e tempistiche. Dove reperirli Consultare la documentazione di FIS Global Esempi Bonifico bancarioBonifico ACH in entrataSEPA istantaneoAssegno
	Unità aziendale BusinessUnit	Divisione o reparto interno da cui ha origine il pagamento.
Descrizione Questo attributo associa il pagamento a una specifica unità organizzativa, ad esempio «Servizi bancari al dettaglio», «Finanziamenti alle imprese» o «Tesoreria». Viene utilizzato per aggregare per reparto KPI come «Volumi dei pagamenti» e «Tempo medio di ciclo del pagamento». Aiuta la direzione a confrontare le prestazioni delle diverse divisioni e ad allocare le risorse in modo efficace. Perché è importante Consente di confrontare le prestazioni interne e di definire responsabilità chiare per i risultati del processo. Dove reperirli Consultare la documentazione di FIS Global Esempi TesoreriaDebiti verso fornitoriOperazioni bancarie al dettaglioGestione patrimoniale
	Utente che ha eseguito l’elaborazione ProcessingUser	Identificativo o nome dell’utente o dell’agente di sistema che esegue l’attività.
Descrizione Questo attributo registra chi o che cosa ha eseguito la fase del processo. Permette di distinguere gli operatori umani (ad esempio, «M.Rossi») dagli account di sistema automatizzati (ad esempio, «SYSTEM_BATCH»). Questi dati servono ad analizzare l’utilizzo delle risorse, individuare i colli di bottiglia dovuti ad attività manuali e verificare la separazione dei compiti. Aiutano a calcolare il «Tasso di utilizzo degli utenti addetti all’elaborazione» e a distinguere le attività manuali da quelle automatizzate. Perché è importante Essenziale per l’analisi delle risorse, i tassi di automazione e gli audit di conformità. Dove reperirli Consultare la documentazione di FIS Global Esempi jsmithSYSTEM_AUTOBOTmdoe_approverAPI_GATEWAY
	Autorità di approvazione ApprovalAuthority	Ruolo, gruppo o persona responsabile dell’autorizzazione del pagamento.
Descrizione Questo attributo indica il livello di autorità o il gruppo di utenti specifico necessario per approvare il pagamento, spesso in base alla soglia di importo. Aiuta a ricostruire l’instradamento del flusso di approvazione. Gli analisti lo utilizzano per alimentare la Dashboard «Colli di bottiglia nell’autorizzazione dei pagamenti». Consente di suddividere i tempi di approvazione per livello di autorità e verificare se determinati livelli dirigenziali causano ritardi. Perché è importante Consente di analizzare la gerarchia delle approvazioni e individuare i colli di bottiglia. Dove reperirli Consultare la documentazione di FIS Global Esempi Responsabile di livello 1CFOTeam conformitàSistema di approvazione automatica
	Canale di pagamento PaymentChannel	Canale attraverso il quale è stata avviata la richiesta di pagamento.
Descrizione Questo attributo descrive l’origine dell’istruzione di pagamento, ad esempio l’Internet banking, l’app mobile, un’API o una filiale. Aiuta a comprendere da quale canale proviene la transazione. Gli analisti lo utilizzano per confrontare l’efficienza di elaborazione dei diversi canali. Ad esempio, consente di verificare se i pagamenti avviati tramite API presentano tassi di errore inferiori rispetto a quelli inseriti manualmente in filiale. Perché è importante Aiuta a ottimizzare i canali e a comprendere il comportamento dei clienti. Dove reperirli Consultare la documentazione di FIS Global Esempi Internet bankingApp mobileGateway aziendaleOperatore di filiale
	Codice di errore di convalida ValidationErrorCode	Codice o motivo che indica perché un pagamento non ha superato la convalida.
Descrizione Questo attributo viene compilato quando il pagamento raggiunge l’attività «Errore di pagamento rilevato». Contiene dettagli specifici sull’errore, ad esempio «IBAN non valido», «Fondi insufficienti» o «Indirizzo del beneficiario mancante». Questo campo alimenta la Dashboard «Tassi di errore nella convalida dei dati di pagamento». Raggruppando i dati per questo attributo, è possibile individuare le cause più frequenti di rilavorazione e intervenire in modo mirato sull’inserimento dei dati nelle fasi precedenti o sulla configurazione del sistema. Perché è importante Individua le cause profonde degli ostacoli nel processo e dei cicli di rilavorazione. Dove reperirli Consultare la documentazione di FIS Global Esempi ERR-001: Conto non validoERR-055: Corrispondenza con elenco sanzioniERR-009: Transazione duplicata
	Conto mittente SenderAccount	Numero del conto da cui vengono addebitati i fondi.
Descrizione Questo attributo identifica il conto di origine della transazione. Consente di analizzare nel dettaglio i pagamenti provenienti da specifici conti interni. Nell’analisi, aiuta a individuare se determinati conti di finanziamento sono soggetti a errori (ad esempio, fondi insufficienti) o ritardi. Supporta la riconciliazione, consentendo di abbinare le registrazioni contabili alle attività del processo. Perché è importante È fondamentale per la riconciliazione finanziaria e l’analisi dei problemi a livello di conto. Dove reperirli Consultare la documentazione di FIS Global Esempi 123456789987654321ACC-TREASURY-01
	Intervento manuale IsManualIntervention	Indicatore che segnala se l’attività ha richiesto un intervento manuale.
Descrizione Questo attributo booleano contrassegna le attività o i casi che hanno richiesto l’intervento di una persona, ad esempio «Errore di pagamento risolto» o un’approvazione manuale, anziché un’elaborazione interamente automatizzata (STP). È essenziale per la Dashboard «Percentuale di interventi manuali sui pagamenti». Aiuta a quantificare la percentuale di pagamenti non completamente automatizzati e a individuare opportunità di trasformazione digitale. Perché è importante Distingue i volumi elaborati automaticamente dal lavoro manuale e orienta il calcolo del ritorno sugli investimenti in automazione. Dove reperirli Derivato da ActivityName o ProcessingUser Esempi truefalse
	Paese del beneficiario BeneficiaryCountry	Codice del paese del destinatario del pagamento.
Descrizione Questo attributo identifica il paese di destinazione dei fondi e consente di distinguere i pagamenti nazionali da quelli internazionali. Questo contesto è fondamentale per il «Monitoraggio della conformità dei pagamenti» e per l’analisi dell’instradamento. I pagamenti internazionali coinvolgono spesso intermediari diversi, controlli di conformità e tempi di ciclo più lunghi; analizzare le prestazioni per paese aiuta quindi a isolare queste variabili. Perché è importante È una dimensione fondamentale per l’analisi geografica e la valutazione del rischio di conformità. Dove reperirli Consultare la documentazione di FIS Global Esempi USDECNGB
	Pagamento in ritardo IsLatePayment	Indicatore che segnala se il pagamento è stato regolato dopo la data di scadenza.
Descrizione È un attributo booleano calcolato. Restituisce true se la data di «Pagamento regolato» è successiva alla «Data di scadenza del pagamento». Questo attributo determina direttamente il KPI «Percentuale di pagamenti puntuali». Semplifica la creazione delle Dashboard, consentendo di filtrare rapidamente i casi problematici senza dover impostare logiche complesse sulle date nel livello di visualizzazione. Perché è importante Semplifica la reportistica sulle eccezioni e l’analisi della conformità. Dove reperirli Derivato da PaymentDueDate e ActualSettlementDate Esempi truefalse
	Sistema di origine SourceSystem	Nome del sistema da cui provengono i dati dell’evento.
Descrizione Questo attributo identifica il componente software o il database specifico da cui è stato estratto il record, ad esempio il sistema bancario centrale, il gateway di pagamento o lo strumento di verifica delle sanzioni. È fondamentale per la tracciabilità dei dati e la convalida. Quando si analizzano flussi end-to-end che coinvolgono più piattaforme, questo campo aiuta a distinguere dove si sono svolte le singole attività e a individuare i problemi di qualità dei dati. Perché è importante Garantisce tracciabilità e contesto, soprattutto in ambienti complessi con più motori di pagamento integrati. Dove reperirli Consultare la documentazione di FIS Global Esempi FIS OPFTraxPaymentHub_01SanctionsScreeningDB
	Ultimo aggiornamento dei dati LastDataUpdate	Timestamp dell’ultima estrazione o aggiornamento del record.
Descrizione Questo attributo indica quanto sono aggiornati i dati utilizzati nell’analisi. Aiuta a capire se si stanno consultando dati in tempo reale o un’istantanea relativa a un periodo precedente. Nelle Dashboard, questo campo viene spesso utilizzato per mostrare l’indicazione «Dati aggiornati al». Aiuta a prendere decisioni sulla base delle informazioni più pertinenti disponibili e a gestire i caricamenti incrementali dei dati. Perché è importante Indica l’attualità dei dati e rafforza la fiducia nella tempestività dei report. Dove reperirli Metadati del processo ETL Esempi 2023-10-14T00:00:00Z2023-10-15T06:00:00Z

Obbligatorio Consigliato Facoltativo

Attività di elaborazione dei pagamenti

Questi sono i passaggi e le tappe principali del processo da registrare nell’Event Log per individuare e ottimizzare il processo con precisione.

6 Consigliato 7 Facoltativo

	Attività	Descrizione
	Istruzione di pagamento inviata	Questa attività segna il momento in cui il sistema FIS invia l’istruzione di pagamento definitiva alla rete di pagamento pertinente, ad esempio ACH, Fedwire o SWIFT. È un evento di sistema fondamentale.
Perché è importante È una tappa importante, che indica che il pagamento ha lasciato l’ambiente di elaborazione interno. È fondamentale per analizzare l’efficienza dell’instradamento e i tempi di elaborazione esterna. Dove reperirli Registrato in un registro delle transazioni o dei messaggi che tiene traccia delle comunicazioni con le reti di pagamento esterne. Cerchi una registrazione che indichi l’invio riuscito di un messaggio in uscita, con il relativo timestamp. Acquisizione Evento generato dal sistema quando il messaggio di pagamento viene inviato alla rete di compensazione. Tipo di evento explicit
	Pagamento approvato	Una tappa fondamentale in cui un utente autorizzato approva il pagamento, consentendogli di passare alla fase successiva. Quasi sempre si tratta di un evento esplicito, registrato con l’ID dell’approvatore e un timestamp al momento dell’azione nel sistema.
Perché è importante È un punto di controllo fondamentale per misurare i tempi di ciclo delle approvazioni e verificare il rispetto dei controlli finanziari. I ritardi in questa fase possono incidere sensibilmente sulla puntualità dei pagamenti. Dove reperirli Registrato in una tabella del registro delle approvazioni o come evento esplicito nella cronologia principale delle transazioni. L’Event Log collega l’ID della transazione di pagamento, l’ID utente dell’approvatore e il timestamp dell’approvazione. Acquisizione Registrato quando un utente con i diritti di approvazione seleziona l’azione 'approve' per un pagamento. Tipo di evento explicit
	Pagamento autorizzato	Indica una fase finale di autorizzazione, spesso richiesta per i pagamenti di importo elevato o da un’autorità diversa dopo l’approvazione iniziale. L’azione viene registrata come evento esplicito quando un utente con le credenziali di autorizzazione conferma il pagamento.
Perché è importante Questa attività è fondamentale per la Dashboard «Colli di bottiglia nell’autorizzazione dei pagamenti». Tenerla distinta da «Pagamento approvato» aiuta a individuare i ritardi nei processi di approvazione a più livelli. Dove reperirli Registrato in un registro di audit o delle transazioni. L’evento viene generato quando un utente con autorizzazioni specifiche interviene sul pagamento; la registrazione include il suo ID e un timestamp. Acquisizione Viene creata una registrazione esplicita quando un utente esegue l’azione di autorizzazione finale. Tipo di evento explicit
	Pagamento regolato	Questa attività segna il completamento del trasferimento dei fondi, quando la transazione si considera regolata dal punto di vista finanziario. In genere viene registrata alla ricezione della conferma definitiva di regolamento dalla rete di pagamento o dalla stanza di compensazione.
Perché è importante È il principale punto di arrivo per misurare il tempo di ciclo del pagamento e la percentuale di pagamenti puntuali. Segna il completamento corretto dell’esecuzione del pagamento. Dove reperirli Dedotto da una modifica dello stato finale del pagamento in «Regolato», «Completato» o «Contabilizzato». La modifica può essere determinata da file di regolamento elaborati in batch o da messaggi in tempo reale del sistema di compensazione. Acquisizione Modifica dello stato della transazione di pagamento in «Regolato» o in uno stato equivalente. Tipo di evento inferred
	Pagamento riconciliato	È l’ultima attività contabile, durante la quale la transazione di pagamento viene confrontata con un estratto conto bancario o una registrazione nel libro mastro interno. Può trattarsi di un processo automatizzato in batch o di un’azione manuale dell’utente.
Perché è importante Questa attività segna la conclusione effettiva del ciclo di vita del pagamento. Analizzare il tempo di ciclo della riconciliazione dei pagamenti è fondamentale per comprendere l’efficienza dei processi di chiusura contabile. Dove reperirli Spesso dedotto dalla compilazione del campo «reconciliation_date» o dalla modifica dello stato finale in «Riconciliato» in un modulo finanziario o contabile collegato al sistema di pagamento. Acquisizione Identificato dalla compilazione della data di riconciliazione o dalla modifica dello stato in «Riconciliato». Tipo di evento inferred
	Richiesta di pagamento creata	È il primo evento del ciclo di vita del pagamento e corrisponde al momento in cui viene avviata una nuova transazione nel sistema FIS. In genere, viene registrato esplicitamente in una tabella del registro delle transazioni quando un utente o un sistema automatico invia una nuova richiesta di pagamento.
Perché è importante Questa attività segna l’inizio effettivo del processo. È essenziale per misurare il tempo di ciclo complessivo del pagamento e analizzare il volume e la produttività complessivi. Dove reperirli Registrato in una tabella centrale delle transazioni, con il timestamp di creazione associato all’ID della transazione di pagamento. Cerchi tabelle come 'Payment_Transactions' o 'Payment_Requests' e campi come 'creation_date' o 'entry_date'. Acquisizione Evento registrato alla creazione di una nuova transazione di pagamento. Tipo di evento explicit
	Dettagli del pagamento convalidati	Questa attività indica che i dati del pagamento hanno superato i controlli automatici iniziali di formato, completezza e correttezza. Spesso si deduce da una modifica dello stato della registrazione del pagamento, ad esempio da 'New' a 'Validated' o 'Pending Approval'.
Perché è importante Monitorare questa attività aiuta a individuare la frequenza e i punti in cui si verificano errori di inserimento dei dati. È un prerequisito per analizzare l’indicatore del tasso di errore nella convalida dei dati di pagamento e comprendere le cause delle rilavorazioni. Dove reperirli Si deduce da una modifica del campo relativo allo stato o alla condizione nella tabella delle transazioni di pagamento. Il passaggio dallo stato iniziale a 'validated', insieme al timestamp corrispondente, segna questo evento. Acquisizione Individuato dalla modifica del campo dello stato del pagamento in 'Validated' o in un valore equivalente. Tipo di evento inferred
	Errore di pagamento rilevato	Indica che, dopo la convalida iniziale, è stato rilevato un errore in una fase del processo, ad esempio un rifiuto da parte della banca ricevente o un avviso interno relativo alla conformità. Spesso viene registrato come evento esplicito quando si verifica un’eccezione.
Perché è importante Questa attività segna l’inizio di tutti i cicli di rilavorazione e gestione delle eccezioni. È essenziale per calcolare i KPI relativi alla percentuale di interventi manuali e al tempo di risoluzione degli errori di pagamento. Dove reperirli Registrato in un modulo per la gestione delle eccezioni o nel registro delle transazioni. Può essere attivato automaticamente da una regola di sistema oppure manualmente da un utente che segnala un problema; in entrambi i casi viene creato un record con il codice di errore e l’ora. Acquisizione Alla transazione di pagamento viene associato un codice di eccezione o di errore. Tipo di evento explicit
	Errore di pagamento risolto	Segna la risoluzione di un errore di pagamento rilevato in precedenza, consentendo di elaborare nuovamente il pagamento o di annullarlo. Si tratta di un’azione esplicita eseguita da un utente per rimuovere lo stato di eccezione.
Perché è importante Questa attività chiude il ciclo di gestione dell’eccezione. Il tempo tra «Errore rilevato» e questo evento è un indicatore importante dell’efficienza operativa nella gestione delle eccezioni. Dove reperirli Registrato quando un utente rimuove un contrassegno di errore o sposta la transazione fuori da una coda delle eccezioni. L’azione viene acquisita con l’ora in una traccia di controllo o nella cronologia delle transazioni. Acquisizione Un’azione dell’utente rimuove lo stato di errore e viene registrata in un registro di controllo. Tipo di evento explicit
	Pagamento confermato	Indica la ricezione di una conferma da parte della rete di pagamento o della banca beneficiaria, che attesta l’avvenuta ricezione del pagamento. L’evento viene attivato da un messaggio di sistema in entrata o da un aggiornamento di stato.
Perché è importante La conferma attesta che il pagamento è arrivato a destinazione. Il tempo che intercorre tra «Istruzione inviata» e «Confermato» misura la latenza della rete esterna e i tempi di elaborazione. Dove reperirli Generato analizzando i messaggi di conferma in entrata dalle reti di pagamento. Il sistema aggiorna lo stato del pagamento e registra l’ora della conferma. Acquisizione Un messaggio in entrata dalla rete di compensazione aggiorna lo stato del pagamento a «Confermato». Tipo di evento explicit
	Pagamento in ritardo rilevato	Evento derivato che indica che il pagamento è stato regolato dopo la data di scadenza prevista. Questa attività non viene registrata esplicitamente, ma calcolata confrontando due campi data.
Perché è importante Questa attività calcolata contribuisce direttamente al KPI «Percentuale di pagamenti puntuali» e alla Dashboard «Rispetto delle scadenze di pagamento». Aiuta a quantificare l’impatto dei ritardi di processo sui rapporti con i fornitori e sulle eventuali penali per ritardato pagamento. Dove reperirli Non viene estratto direttamente. Viene calcolato durante la trasformazione dei dati confrontando il timestamp «Data di regolamento» con il campo «Data di scadenza del pagamento». Se la data di regolamento è successiva alla scadenza, viene generato questo evento. Acquisizione Calcolato se «Data di regolamento» > «Data di scadenza del pagamento». Tipo di evento calculated
	Pagamento inviato per l’approvazione	Indica il momento in cui un pagamento convalidato viene inviato al flusso di lavoro di approvazione. In genere, è registrato da una modifica dello stato che indica che il pagamento è in attesa dell’intervento di un approvatore.
Perché è importante Questa attività segna l’inizio del sottoprocesso di approvazione. Analizzare il tempo che intercorre tra questa attività e «Pagamento approvato» è fondamentale per comprendere i colli di bottiglia nelle approvazioni. Dove reperirli Si deduce dalla modifica del campo dello stato del pagamento in 'Pending Approval', 'Submitted for Approval' o uno stato equivalente nel flusso di lavoro o nel registro degli stati delle transazioni. Acquisizione Modifica dello stato della transazione di pagamento da 'Validated' a 'Pending Approval'. Tipo di evento inferred
	Pagamento rifiutato	Questa attività si verifica quando un approvatore rifiuta una richiesta di pagamento, che in genere deve essere corretta e inviata di nuovo oppure annullata. L’azione esplicita dell’utente viene registrata a fini di audit.
Perché è importante Monitorare i rifiuti aiuta a individuare le cause più comuni dei problemi nei pagamenti, le deviazioni dal processo e i cicli di rilavorazione. Fa emergere problemi nella qualità iniziale dei dati o nella conformità. Dove reperirli Registrato come evento esplicito nella cronologia delle approvazioni o delle transazioni quando un approvatore seleziona l’opzione 'reject'. La registrazione include di solito un timestamp, l’ID utente e spesso un codice che indica il motivo. Acquisizione Evento registrato quando un utente seleziona l’azione 'reject' per un pagamento. Tipo di evento explicit

Consigliato Facoltativo

Guide all’estrazione

Come ottenere i dati da FIS Global

Passaggi

Verifichi che il motore di pagamento FIS Global archivi i messaggi XML ISO 20022 originali, inclusi gli ordini di pagamento pacs.008 e i report sullo stato dei pagamenti pacs.002, in una posizione accessibile nel file system. Si procuri il percorso dell’archivio, la convenzione di denominazione dei file, la configurazione degli spazi dei nomi, il periodo di conservazione e la mappatura tra Payment Transaction ID e identificativi ISO 20022 quali EndToEndId, TxId, InstrId o UETR.
Installi Python 3.10 o versione successiva e verifichi la disponibilità dei moduli della libreria standard utilizzati dallo script, tra cui pathlib, xml.etree.ElementTree, csv, datetime, decimal e collections. L’implementazione di riferimento non richiede pacchetti esterni. Verifichi che l’account di esecuzione possa leggere l’archivio XML e scrivere il file di output di ProcessMind.
Configuri la directory di input, il file di output, la data iniziale, la data finale, il fuso orario e gli eventuali filtri specifici dell’azienda nella sezione di configurazione dello script. Sostituisca solo i segnaposto documentati. Non presuma che il nome di un file o un elemento XML contenga l’identificativo del caso di ProcessMind finché la mappatura degli identificativi non è stata convalidata su file rappresentativi.
Esamini file pacs.008 e pacs.002 rappresentativi relativi a transazioni riuscite, rifiutate, non riuscite, corrette e regolate. Verifichi gli spazi dei nomi XML e individui gli elementi che contengono l’identificativo della transazione, l’importo, la valuta, la data di esecuzione richiesta, la data di regolamento, il codice di stato, il codice causale, il timestamp dell’evento, l’utente o l’agente di sistema che ha elaborato il pagamento, il tipo di pagamento e l’unità aziendale. Aggiorni i percorsi XPath configurati se l’implementazione FIS utilizza percorsi diversi.
Esegua inizialmente lo script su un intervallo di date limitato. Il parser legge ogni file XML, estrae i dati a livello di messaggio e di transazione, associa i codici di stato e causali ISO 20022 ad attività esplicite e scrive una riga per ogni attività estratta. Lo script crea inoltre le righe Payment Error Identified e Payment Error Resolved a partire da indicatori espliciti di errore o correzione e genera Late Payment Identified solo se il regolamento è avvenuto dopo la scadenza.
Esamini il CSV generato e il report di convalida. Verifichi che PaymentTransactionId, ActivityName ed EventTimestamp siano valorizzati in ogni riga, che possano essere presenti tutti i 13 nomi di attività richiesti e che i timestamp siano normalizzati in modo uniforme. Prima di ampliare l’intervallo di estrazione, analizzi le transazioni con identificativi mancanti, codici di stato non supportati, eventi duplicati o date in conflitto.
Confronti il numero di eventi con quello dei file nell’archivio di origine e, se disponibili, con i report operativi FIS o le estrazioni di audit. Convalidi un campione di transazioni dall’inizio alla fine, includendo approvazione, rifiuto, autorizzazione, invio dell’ordine, conferma della rete, regolamento, gestione degli errori, riconciliazione e logica dei pagamenti in ritardo. Se è necessaria la tracciabilità operativa, conservi nell’output di audit il nome del file di origine e il riferimento alla riga o al messaggio.
Pianifichi l’esecuzione dello script dopo che l’archivio di origine è completo per il periodo selezionato oppure lo esegua in modo incrementale, con una finestra di sovrapposizione controllata per acquisire i messaggi pacs.002 arrivati in ritardo. Rimuova i duplicati utilizzando PaymentTransactionId, ActivityName, EventTimestamp e l’identificativo del messaggio di origine, mantenendo le ripetizioni legittime delle attività quando la fonte registra più occorrenze.
Esporti l’Event Log finale in formato CSV UTF-8, con una riga per evento e le colonne PaymentTransactionId, ActivityName, EventTimestamp, ProcessingUser, PaymentAmount, CurrencyCode, PaymentType, PaymentDueDate, ActualSettlementDate e BusinessUnit. Carichi il file in ProcessMind e configuri PaymentTransactionId come identificativo del caso, ActivityName come attività ed EventTimestamp come timestamp dell’evento. ProcessMind legge l’Event Log così com’è e non deduce le attività mancanti.

Configurazione

Percorso dell’archivio di input: configuri la directory che contiene i file XML ISO 20022 originali. Includa tutte le sottodirectory pertinenti se l’archivio è suddiviso per data, azienda, tipo di messaggio o stato di elaborazione.
Tipi di messaggio: includa pacs.008 per gli ordini di pagamento e pacs.002 per i report sullo stato dei pagamenti. Aggiunga altri tipi di messaggio solo dopo averne convalidato gli identificativi e il significato degli stati nell’implementazione FIS.
Mappatura degli identificativi: configuri i percorsi XPath candidati per individuare il Payment Transaction ID. Preferisca l’identificativo utilizzato in modo uniforme nel record della transazione FIS e in tutti i messaggi ISO 20022 correlati. Non combini identificativi non correlati senza una regola di correlazione documentata.
Mappatura delle attività: configuri la mappatura dei codici di stato e causali per creazione, invio per approvazione, approvazione, rifiuto, autorizzazione, invio dell’ordine, conferma, regolamento, identificazione dell’errore, risoluzione dell’errore e riconciliazione. Lo script fornito utilizza mappature configurabili e indicatori espliciti della fonte, anziché dedurre le normali fasi del ciclo di vita dall’assenza di record.
Intervallo di date: inizi con 3-6 mesi di dati. Per i test iniziali o gli archivi con volumi elevati, utilizzi un intervallo più breve e includa un periodo di sovrapposizione se i messaggi di stato possono arrivare dopo la data del pagamento originale.
Filtri per data: configuri le date iniziale e finale utilizzando, ove disponibile, il timestamp dell’evento di origine. Se un messaggio non contiene un timestamp dell’evento, lo script può utilizzare il timestamp di modifica del file solo se questa opzione è abilitata esplicitamente. Tale ripiego va documentato, poiché non corrisponde al timestamp di un evento aziendale.
Filtri aziendali e organizzativi: configuri filtri per azienda, unità aziendale, entità giuridica, prodotto di pagamento o tipo di documento solo se gli elementi XML corrispondenti sono presenti e i relativi valori sono stati convalidati. Per i filtri specifici dell’implementazione, utilizzi [Configure based on your system].
Fuso orario: imposti il fuso orario del sistema di origine o la regola di normalizzazione in UTC. Applichi la stessa regola a tutti i messaggi per garantire un ordinamento affidabile degli eventi.
Indicatori di errore e correzione: configuri i codici di stato e causali, nonché gli indicatori espliciti di correzione o eccezione che rappresentano Payment Error Identified e Payment Error Resolved. Non classifichi ogni rifiuto come errore, a meno che questa non sia la definizione aziendale approvata.
Indicatori di riconciliazione: configuri lo stato di riconciliazione esplicito, il messaggio di riconciliazione, l’indicatore di corrispondenza contabile o il risultato del lotto utilizzato nell’implementazione FIS. Se la riconciliazione è archiviata al di fuori dell’archivio XML, fornisca una fonte separata approvata e una regola di correlazione.
Prestazioni: elabori i file in modo iterativo, anziché caricare l’intero archivio in memoria. Suddivida le esecuzioni di grandi dimensioni per data o directory, scriva risultati intermedi e utilizzi un’area di staging locale con spazio su disco sufficiente. Per archivi molto grandi, parallelizzi l’elaborazione per directory indipendenti solo dopo aver verificato che l’ordinamento dell’output e la rimozione dei duplicati restino sotto controllo.
Prerequisiti: accesso in lettura all’archivio XML, accesso in scrittura alla posizione di output, autorizzazione a eseguire Python, accesso approvato ai dati di pagamento e mappatura convalidata degli identificativi e dei codici di stato FIS. Questo metodo basato su file non presuppone codici di transazione, percorsi di menu, endpoint API, nomi di tabelle o licenze FIS specifici.

a Query di esempio python

from __future__ import annotations

import csv
import hashlib
import re
import sys
import xml.etree.ElementTree as ET
from collections import defaultdict
from datetime import date, datetime, timezone
from decimal import Decimal, InvalidOperation
from pathlib import Path
from typing import Dict, Iterable, List, Optional, Tuple

class=class="hl-string">"hl-comment"># Replace only these documented placeholders.
INPUT_DIRECTORY = Path(class="hl-string">"[Your XML archive directory]")
OUTPUT_FILE = Path(class="hl-string">"[Your ProcessMind event log output path].csv")
START_DATE = class="hl-string">"[YYYY-MM-DD]"
END_DATE = class="hl-string">"[YYYY-MM-DD]"
SOURCE_TIMEZONE = timezone.utc
COMPANY_FILTER = class="hl-string">""  class=class="hl-string">"hl-comment"># Leave empty unless a validated company or business-unit value is required.

class=class="hl-string">"hl-comment"># Update these candidates after inspecting representative FIS XML files.
IDENTIFIER_PATHS = [
    class="hl-string">"EndToEndId", class="hl-string">"TxId", class="hl-string">"InstrId", class="hl-string">"UETR", class="hl-string">"PaymentTransactionId",
    class="hl-string">"PaymentId", class="hl-string">"TransactionId"
]
AMOUNT_PATHS = [class="hl-string">"InstdAmt", class="hl-string">"IntrBkSttlmAmt", class="hl-string">"Amt", class="hl-string">"Amount"]
CURRENCY_PATHS = [class="hl-string">"InstdAmt", class="hl-string">"IntrBkSttlmAmt", class="hl-string">"Amt", class="hl-string">"Currency", class="hl-string">"Ccy"]
DUE_DATE_PATHS = [class="hl-string">"ReqdExctnDt", class="hl-string">"ReqdColltnDt", class="hl-string">"DueDate", class="hl-string">"RequestedExecutionDate"]
SETTLEMENT_DATE_PATHS = [class="hl-string">"SttlmDt", class="hl-string">"SettlementDate", class="hl-string">"ActualSettlementDate"]
TIMESTAMP_PATHS = [
    class="hl-string">"CreDtTm", class="hl-string">"AccptncDtTm", class="hl-string">"AccptncDt", class="hl-string">"OrgnlCreDtTm", class="hl-string">"TxDtTm",
    class="hl-string">"SttlmDt", class="hl-string">"SettlementDate", class="hl-string">"EventTimestamp", class="hl-string">"Timestamp"
]
USER_PATHS = [class="hl-string">"UserId", class="hl-string">"UserID", class="hl-string">"Operator", class="hl-string">"Approver", class="hl-string">"ProcessingUser", class="hl-string">"Initiator"]
PAYMENT_TYPE_PATHS = [class="hl-string">"PmtMtd", class="hl-string">"SvcLvl", class="hl-string">"LclInstrm", class="hl-string">"CtgyPurp", class="hl-string">"PaymentType"]
BUSINESS_UNIT_PATHS = [class="hl-string">"BusinessUnit", class="hl-string">"CompanyCode", class="hl-string">"Company", class="hl-string">"OrgUnit", class="hl-string">"LegalEntity"]
STATUS_PATHS = [class="hl-string">"TxSts", class="hl-string">"GrpSts", class="hl-string">"Status", class="hl-string">"PaymentStatus", class="hl-string">"TransactionStatus"]
REASON_PATHS = [class="hl-string">"Cd", class="hl-string">"Rsn", class="hl-string">"ReasonCode", class="hl-string">"StatusReason", class="hl-string">"AddtlInf"]
ERROR_PATHS = [class="hl-string">"Error", class="hl-string">"Exception", class="hl-string">"Failure", class="hl-string">"ErrorCode", class="hl-string">"ExceptionCode"]
REPAIR_PATHS = [class="hl-string">"Repair", class="hl-string">"Resolved", class="hl-string">"Resolution", class="hl-string">"ErrorResolved", class="hl-string">"ExceptionResolved"]
RECONCILIATION_PATHS = [class="hl-string">"Reconciled", class="hl-string">"ReconciliationStatus", class="hl-string">"LedgerMatched", class="hl-string">"BankStatementMatched"]

class=class="hl-string">"hl-comment"># Validate and extend these mappings against the FIS implementation.
STATUS_ACTIVITY_MAP = {
    class="hl-string">"NEW": class="hl-string">"Payment Request Created",
    class="hl-string">"RECEIVED": class="hl-string">"Payment Request Created",
    class="hl-string">"VALIDATED": class="hl-string">"Payment Details Validated",
    class="hl-string">"PENDING_APPROVAL": class="hl-string">"Payment Sent For Approval",
    class="hl-string">"AWAITING_APPROVAL": class="hl-string">"Payment Sent For Approval",
    class="hl-string">"APPROVAL_PENDING": class="hl-string">"Payment Sent For Approval",
    class="hl-string">"APPROVED": class="hl-string">"Payment Approved",
    class="hl-string">"REJECTED": class="hl-string">"Payment Rejected",
    class="hl-string">"AUTHORIZED": class="hl-string">"Payment Authorized",
    class="hl-string">"SENT": class="hl-string">"Payment Instruction Sent",
    class="hl-string">"DISPATCHED": class="hl-string">"Payment Instruction Sent",
    class="hl-string">"ACCP": class="hl-string">"Payment Confirmed",
    class="hl-string">"ACCEPTED": class="hl-string">"Payment Confirmed",
    class="hl-string">"CONFIRMED": class="hl-string">"Payment Confirmed",
    class="hl-string">"SETTLED": class="hl-string">"Payment Settled",
    class="hl-string">"BOOK": class="hl-string">"Payment Settled",
    class="hl-string">"RECONCILED": class="hl-string">"Payment Reconciled",
}
ERROR_STATUS_CODES = {class="hl-string">"RJCT", class="hl-string">"REJECTED", class="hl-string">"FAILED", class="hl-string">"ERROR", class="hl-string">"EXCEPTION", class="hl-string">"CANCELLED"}
RESOLVED_STATUS_CODES = {class="hl-string">"REPAIRED", class="hl-string">"RESOLVED", class="hl-string">"CORRECTED", class="hl-string">"REPROCESSING", class="hl-string">"REPROCESSED"}

OUTPUT_COLUMNS = [
    class="hl-string">"PaymentTransactionId", class="hl-string">"ActivityName", class="hl-string">"EventTimestamp", class="hl-string">"ProcessingUser",
    class="hl-string">"PaymentAmount", class="hl-string">"CurrencyCode", class="hl-string">"PaymentType", class="hl-string">"PaymentDueDate",
    class="hl-string">"ActualSettlementDate", class="hl-string">"BusinessUnit"
]


def local_name(tag: str) -> str:
    return tag.rsplit(class="hl-string">"}", 1)[-1].lower()


def text_values(root: ET.Element, candidates: Iterable[str]) -> List[str]:
    wanted = {candidate.lower() for candidate in candidates}
    values: List[str] = []
    for element in root.iter():
        if local_name(element.tag) in wanted:
            value = (element.text or class="hl-string">"").strip()
            if value:
                values.append(value)
            for key, attribute_value in element.attrib.items():
                if key.rsplit(class="hl-string">"}", 1)[-1].lower() in {class="hl-string">"ccy", class="hl-string">"currency"} and attribute_value.strip():
                    values.append(attribute_value.strip())
    return values


def first_value(root: ET.Element, candidates: Iterable[str]) -> str:
    values = text_values(root, candidates)
    return values[0] if values else class="hl-string">""


def normalize_code(value: str) -> str:
    return re.sub(rclass="hl-string">"[^A-Z0-9_]", class="hl-string">"", value.upper().replace(class="hl-string">"-", class="hl-string">"_"))


def parse_datetime(value: str) -> Optional[datetime]:
    if not value:
        return None
    candidate = value.strip()
    if candidate.endswith(class="hl-string">"Z"):
        candidate = candidate[:-1] + class="hl-string">"+00:00"
    try:
        parsed = datetime.fromisoformat(candidate)
    except ValueError:
        for fmt in (class="hl-string">"%Y-%m-%d %H:%M:%S", class="hl-string">"%Y-%m-%d", class="hl-string">"%Y%m%d%H%M%S", class="hl-string">"%Y%m%d"):
            try:
                parsed = datetime.strptime(value.strip(), fmt)
                break
            except ValueError:
                parsed = None
        if parsed is None:
            return None
    if parsed.tzinfo is None:
        parsed = parsed.replace(tzinfo=SOURCE_TIMEZONE)
    return parsed.astimezone(timezone.utc)


def output_timestamp(value: Optional[datetime]) -> str:
    return value.astimezone(timezone.utc).isoformat().replace(class="hl-string">"+00:00", class="hl-string">"Z") if value else class="hl-string">""


def output_date(value: str) -> str:
    parsed = parse_datetime(value)
    return parsed.date().isoformat() if parsed else (value[:10] if re.match(rclass="hl-string">"^\d{4}-\d{2}-\d{2}", value) else class="hl-string">"")


def normalize_amount(value: str) -> str:
    if not value:
        return class="hl-string">""
    try:
        return format(Decimal(value.replace(class="hl-string">",", class="hl-string">"").strip()), class="hl-string">"f")
    except InvalidOperation:
        return value.strip()


def source_message_id(path: Path, root: ET.Element) -> str:
    raw = path.as_posix() + class="hl-string">"|" + first_value(root, [class="hl-string">"MsgId", class="hl-string">"MessageId", class="hl-string">"BizMsgIdr"])
    return hashlib.sha256(raw.encode(class="hl-string">"utf-8")).hexdigest()


def in_date_range(event_time: Optional[datetime]) -> bool:
    if not event_time:
        return True
    start = datetime.fromisoformat(START_DATE).replace(tzinfo=timezone.utc)
    end = datetime.fromisoformat(END_DATE).replace(tzinfo=timezone.utc)
    return start <= event_time < end.replace(hour=23, minute=59, second=59, microsecond=999999)


def add_event(events: List[Dict[str, str]], seen: set, transaction_id: str, activity: str,
              event_time: Optional[datetime], user: str, amount: str, currency: str,
              payment_type: str, due_date: str, settlement_date: str, business_unit: str,
              message_id: str) -> None:
    if not transaction_id or not event_time or not in_date_range(event_time):
        return
    row = {
        class="hl-string">"PaymentTransactionId": transaction_id,
        class="hl-string">"ActivityName": activity,
        class="hl-string">"EventTimestamp": output_timestamp(event_time),
        class="hl-string">"ProcessingUser": user,
        class="hl-string">"PaymentAmount": amount,
        class="hl-string">"CurrencyCode": currency,
        class="hl-string">"PaymentType": payment_type,
        class="hl-string">"PaymentDueDate": output_date(due_date),
        class="hl-string">"ActualSettlementDate": output_date(settlement_date),
        class="hl-string">"BusinessUnit": business_unit,
    }
    key = (transaction_id, activity, row[class="hl-string">"EventTimestamp"], message_id)
    if key not in seen:
        seen.add(key)
        events.append(row)


def parse_file(path: Path, events: List[Dict[str, str]], seen: set) -> None:
    try:
        root = ET.parse(path).getroot()
    except (ET.ParseError, OSError) as exc:
        print(fclass="hl-string">"Could not parse {path}: {exc}", file=sys.stderr)
        return
    message_id = source_message_id(path, root)
    transaction_id = first_value(root, IDENTIFIER_PATHS)
    if not transaction_id:
        return
    business_unit = first_value(root, BUSINESS_UNIT_PATHS)
    if COMPANY_FILTER and business_unit != COMPANY_FILTER:
        return
    amount = normalize_amount(first_value(root, AMOUNT_PATHS))
    currency = first_value(root, CURRENCY_PATHS)
    if len(currency) != 3 and currency:
        currency = currency.upper()
    due_date = first_value(root, DUE_DATE_PATHS)
    settlement_date = first_value(root, SETTLEMENT_DATE_PATHS)
    user = first_value(root, USER_PATHS)
    payment_type = first_value(root, PAYMENT_TYPE_PATHS)
    status_values = text_values(root, STATUS_PATHS)
    reason_values = text_values(root, REASON_PATHS)
    error_values = text_values(root, ERROR_PATHS)
    repair_values = text_values(root, REPAIR_PATHS)
    reconciliation_values = text_values(root, RECONCILIATION_PATHS)
    event_time = parse_datetime(first_value(root, TIMESTAMP_PATHS))
    if not event_time:
        return

    message_name = next((local_name(element.tag) for element in root.iter() if local_name(element.tag) in {class="hl-string">"pacs.008", class="hl-string">"pacs.002", class="hl-string">"document"}), class="hl-string">"")
    normalized_statuses = [normalize_code(value) for value in status_values + reason_values]
    normalized_text = class="hl-string">" ".join(normalize_code(value) for value in error_values)
    normalized_repairs = class="hl-string">" ".join(normalize_code(value) for value in repair_values)
    normalized_reconciliation = class="hl-string">" ".join(normalize_code(value) for value in reconciliation_values)

    if message_name or status_values:
        add_event(events, seen, transaction_id, class="hl-string">"Payment Request Created", event_time, user, amount, currency, payment_type, due_date, settlement_date, business_unit, message_id) if any(code in {class="hl-string">"NEW", class="hl-string">"RECEIVED"} for code in normalized_statuses) else None
        add_event(events, seen, transaction_id, class="hl-string">"Payment Details Validated", event_time, user, amount, currency, payment_type, due_date, settlement_date, business_unit, message_id) if class="hl-string">"VALIDATED" in normalized_statuses else None
        add_event(events, seen, transaction_id, class="hl-string">"Payment Sent For Approval", event_time, user, amount, currency, payment_type, due_date, settlement_date, business_unit, message_id) if any(code in {class="hl-string">"PENDING_APPROVAL", class="hl-string">"AWAITING_APPROVAL", class="hl-string">"APPROVAL_PENDING"} for code in normalized_statuses) else None
        add_event(events, seen, transaction_id, class="hl-string">"Payment Approved", event_time, user, amount, currency, payment_type, due_date, settlement_date, business_unit, message_id) if class="hl-string">"APPROVED" in normalized_statuses else None
        add_event(events, seen, transaction_id, class="hl-string">"Payment Rejected", event_time, user, amount, currency, payment_type, due_date, settlement_date, business_unit, message_id) if any(code in {class="hl-string">"REJECTED", class="hl-string">"RJCT"} for code in normalized_statuses) else None
        add_event(events, seen, transaction_id, class="hl-string">"Payment Authorized", event_time, user, amount, currency, payment_type, due_date, settlement_date, business_unit, message_id) if class="hl-string">"AUTHORIZED" in normalized_statuses else None
        add_event(events, seen, transaction_id, class="hl-string">"Payment Instruction Sent", event_time, user, amount, currency, payment_type, due_date, settlement_date, business_unit, message_id) if any(code in {class="hl-string">"SENT", class="hl-string">"DISPATCHED"} for code in normalized_statuses) else None
        add_event(events, seen, transaction_id, class="hl-string">"Payment Confirmed", event_time, user, amount, currency, payment_type, due_date, settlement_date, business_unit, message_id) if any(code in {class="hl-string">"ACCP", class="hl-string">"ACCEPTED", class="hl-string">"CONFIRMED"} for code in normalized_statuses) else None
        add_event(events, seen, transaction_id, class="hl-string">"Payment Settled", event_time, user, amount, currency, payment_type, due_date, settlement_date, business_unit, message_id) if any(code in {class="hl-string">"SETTLED", class="hl-string">"BOOK"} for code in normalized_statuses) else None
        add_event(events, seen, transaction_id, class="hl-string">"Payment Reconciled", event_time, user, amount, currency, payment_type, due_date, settlement_date, business_unit, message_id) if class="hl-string">"RECONCILED" in normalized_statuses or any(code in normalized_reconciliation for code in {class="hl-string">"TRUE", class="hl-string">"MATCHED", class="hl-string">"RECONCILED"}) else None

    if any(code in ERROR_STATUS_CODES for code in normalized_statuses) or normalized_text:
        add_event(events, seen, transaction_id, class="hl-string">"Payment Error Identified", event_time, user, amount, currency, payment_type, due_date, settlement_date, business_unit, message_id)
    if any(code in RESOLVED_STATUS_CODES for code in normalized_statuses) or any(code in normalized_repairs for code in {class="hl-string">"TRUE", class="hl-string">"RESOLVED", class="hl-string">"REPAIRED", class="hl-string">"CORRECTED"}):
        add_event(events, seen, transaction_id, class="hl-string">"Payment Error Resolved", event_time, user, amount, currency, payment_type, due_date, settlement_date, business_unit, message_id)

    due = parse_datetime(due_date)
    settled = parse_datetime(settlement_date)
    if due and settled and settled.date() > due.date():
        add_event(events, seen, transaction_id, class="hl-string">"Late Payment Identified", settled, user, amount, currency, payment_type, due_date, settlement_date, business_unit, message_id)


def main() -> None:
    events: List[Dict[str, str]] = []
    seen = set()
    for path in sorted(INPUT_DIRECTORY.rglob(class="hl-string">"*.xml")):
        parse_file(path, events, seen)
    events.sort(key=lambda row: (row[class="hl-string">"PaymentTransactionId"], row[class="hl-string">"EventTimestamp"], row[class="hl-string">"ActivityName"]))
    OUTPUT_FILE.parent.mkdir(parents=True, exist_ok=True)
    with OUTPUT_FILE.open(class="hl-string">"w", newline=class="hl-string">"", encoding=class="hl-string">"utf-8") as handle:
        writer = csv.DictWriter(handle, fieldnames=OUTPUT_COLUMNS)
        writer.writeheader()
        writer.writerows(events)
    print(fclass="hl-string">"Wrote {len(events)} event rows to {OUTPUT_FILE}")


if __name__ == class="hl-string">"__main__":
    main()

È pronto a iniziare?

Utilizzi questo template per semplificare la raccolta dei dati e avviare il percorso di miglioramento dell’elaborazione dei pagamenti. Individui le opportunità di efficienza e rafforzi il controllo finanziario grazie a informazioni precise sui processi.

Torna alla guida al miglioramento Scarica il template

Ottimizzi oggi l’elaborazione dei pagamenti FIS Global

Raggiunga il 98% di elaborazione automatica senza interventi manuali ed elimini i problemi di riconciliazione.

Inizi ora la prova gratuita.

Non è richiesta alcuna carta di credito. Inizi in pochi minuti.

Il Suo template dei dati per l’elaborazione dei pagamenti

Il Suo template dei dati per l’elaborazione dei pagamenti

Attributi dell’elaborazione dei pagamenti

Attività di elaborazione dei pagamenti

Guide all’estrazione

Analisi con Python dei file di log XML ISO 20022

Passaggi

Configurazione

a Query di esempio python

È pronto a iniziare?

Ottimizzi oggi l’elaborazione dei pagamenti FIS Global

La Sua privacy è importante