Sistema PAGO – Piattaforma multi canale e multi ente dei pagamenti.

Presentazione sul tema: "Sistema PAGO – Piattaforma multi canale e multi ente dei pagamenti."— Transcript della presentazione:

1 Sistema PAGO – Piattaforma multi canale e multi ente dei pagamenti

2 3 Introduzione Agenda: _ Modello di dominio – architettura _ PAGO – Architettura _ PAGO - funzionalità e integrazioni con altri sistemi _ Integrazione modulo MIP People _ Gateway dei pagamenti _ Cruscotto di rendicontazione

3 3 ARCHITETTURA ANALITICA ELISA ELICAT-ELIFIS-FEDFIS

4 3 Sistema PAGO Modello di interazione in FED_FIS Sistema PAGO Sistema PAGO RISCO Portale Territoriale Portale Territoriale Sistemi d’Area Canali di Pagamento

5 3  A cosa serve ? Consente una gestione unificata del processo di pagamento, applicabile a diversi enti, canali e tipi di debito, che vada dalla transazione, alla registrazione dei dati fino alla rendicontazione; Permette ai cittadini di effettuare pagamenti a vario titolo (p.e. tributi ed altri oneri) usando canali on-line (p.e WEB, ATM, etc…); Funge da mediatore tra i diversi attori del processo di pagamento; Costituisce un archivio unificato ed interrogabile per l’ente di tutti i pagamenti effettuati on-line (o, opzionalmente, per canali classici). Sistema PAGO Funzionalità del sistema

6 3  Elenco delle principali funzionalità e integrazioni di PAGO Gestione di diversi enti creditori su una singola installazione. Con il requisito della separazione e personalizzazione della presentazione e della configurazione (il cittadino vede l’applicazione come proprietaria di un singolo ente). Pagamento di un insieme estendibile di crediti p.e. Contravvenzioni, Servizi scolastici, COSAP, ICP, ICI, VIOLAZIONI ICI, ALTRE VIOLAZIONI ICI, Bollo Virtuale, Certificati Anagrafici, SUAP, Concessioni Edilizie, … ; Pagamenti attraverso diversi canali: p.e. WEB, Totem, reti bancarie (ATM e Home Banking), rete SISAL, e altre reti commerciali (Tabaccai e GDO) ; Estensione delle funzioni Web di pagamento alle applicazioni pubblicate dai Sistemi d’Area (modalità ‘Bridge’) ; Sistema PAGO Funzionalità del sistema – elenco funzionalità (1/2)

7 3  Elenco delle principali funzionalità e integrazioni di PAGO Integrazione con diversi intermediari finanziari: ( a Roma attualmente Monte dei Paschi di Siena, Poste Italiane, Sisal ) e strumenti di pagamento (attualmente contante, carta di credito, PagoBancomat, POS Virtuale, RID on-line e POS su postazioni Totem ; Emissione di ricevute on-line: da ATM, WEB e via eMail ; Registrazione delle transazioni di pagamento: consultazione da parte del cittadino e dell’ente; funzioni di navigazione e ristampa/rispedizione ricevute ; Protocollazione del pagamento e delle relative ricevute; Notifica transazioni ai sistemi d’area di competenza: sistemi d’area specifici dei vari tributi e/o sistemi di consolidamento dei crediti (RISCO, SIR, …) ; Invio dati di rendicontazione al «cruscotto della rendicontazione» a disposizione degli uffici bilancio e di ragioneria per la regolarizzazione in bilancio delle entrate; Sistema PAGO Funzionalità del sistema – elenco funzionalità (2/2)

8 3  Debiti strutturati: Debiti conosciuti ed univocamente identificati nei sistemi d’area di un ente precedentemente al momento del pagamento:; Un debito strutturato viene pagato dal cittadino venendo ricercato tramite il solo identificativo (tipicamente ricevuto dall’ente con mezzi classici, quale l’’invio di bollettini) e solitamente non prevede ulteriori data entry: Esempi: contravvenzioni a verbale, Servizi scolastici, COSAP, ICP, VIOLAZIONI ICI, ALTRE VIOLAZIONI ICI, SUAP, Concessioni Edilizie, … ;  Pagamenti spontanei: Debiti non ancora identificati dalla P.A. e che verranno trattati da processi di backoffice successivi alla transazione di pagamento; Il cittadino deve inserire tutti i dati descrittivi del debito attraverso un’interfaccia avanzata; p.e. Contravvenzioni non ancora a verbale, ICI, VIOLAZIONI, …;  Debiti immediati: Debiti non prevedibili in anticipo dalla P.A. e creati contestualmente al pagamento; Solitamente hanno caratteristiche prefissate e non richiedono particolare data entry; Esempi: Bollo Virtuale, Diritti di Segreteria, … Sistema PAGO Funzionalità del sistema – tipi di debito

9 3  Pagamenti singoli: Sono pagamenti effettuati tramite un processo sequenziale ricerca  Visualizzazione  Conferma  Pagamento  Notifica Possono pagare solo un debito strutturato per volta Consentono il pagamento tramite canali a interfaccia limitata (ATM, Tabaccai, GDO, SISAL, Totem classici, …)  Pagamenti a carrello: Consentono di pagare più debiti, anche di tipo diverso, in un’unica transazione ; L’unica restrizione è che deve esistere almeno un modo di pagamento (p.e. conto di destinazione) consentito in comune tra tutti i debiti nel carrello; Richiedono un canale con interfaccia avanzata (WEB, Totem estesi, …)  Pagamenti bridge: Servizio WEB offerto ai Sistemi d’area dotati di interfaccia pubblica verso i cittadini. Consentono, una volta creato un carrello di uno o più debiti da pagare tramite navigazione su un sistema d’area, di transitare in modo trasparente su PagoWEB per effettuare la transazione e ritornare al sistema chiamante; Esempi: ogni debito esposto da un Sistema d’Area oppure oggetti di pagamento quali Certificati Anagrafici, Reversali, etc… Sistema PAGO Funzionalità del sistema – processi di pagamento

10 3  Servizi estensibili: Tutti i servizi, sia esposti che usati da PAGO Middleware, hanno un’interfaccia standardizzata che contiene tutti i dati che possono essere considerati comuni indipendentemente dall’ente, dal tipo di tributo o dal canale di pagamento; Tale interfaccia consente l’inserimento di dati aggiuntivi relativi al canale, al tributo e/o al contribuente per mezzo di chiavi nome/lista di valori; Il controllo di validità effettuati tramite XML Schema sono relativamente laschi, ed è lasciato alle regole di business (customizzabili sulla base di ente, tipo tributo, canale, etc…) i controlli semantici su tali dati aggiuntivi, così come sull’obbligatorietà di alcuni dati fissi che può essere condizionata dal particolare processo in cui i servizi vengono usati;  Dati estensibili: La base dati relazionale utilizza tabelle estensibili di due tipi per limitare interventi strutturali per introdurre nuovi tributi, canali etc: Tabelle valori estesi, che consentono di registrare (ed interrogare) anche i dati aggiuntivi transitati per i vari servizi Tabelle tipologiche generiche, che consentono di associare a un tipo tributo delle strutture di decodifica o di tipo chiave/descrizione, senza dover estendere strutturalmente la base dati; Sistema PAGO Funzionalità del sistema – modello di integrazione 1/2

11 3  Uso esteso di Adaptor: PAGO è strutturato per minimizzare il ricorso a modifiche strutturali quando si devono aggiungere nuovi tipi debito, canali, etc…; L’aggiunta di un nuovo tipo di debito può richiedere campi aggiuntivi nei servizi e nei dati persistenti, maschere ad hoc di data entry e regole di business e di dispatching verso i sistemi d’area; In particolare, nel caso dei servizi (in particolare quelli chiamati), è vincolante per i sistemi d’area o ai canali di adattarsi allo standard di PAGO; In questi casi, le linee guida di integrazione prevedono l’utilizzo di adaptor, intesi come applicazioni esterne che garantiscono al Middleware l’utilizzo di processi e interfacce standard e si occupano in modo non invasivo di mediare con i sistemi da integrare; Funzioni tipiche di un adaptor sono: Trasformazione di formato (da quello proprietario del canale o sistema d’area a quello standard di PAGO e vice-versa); Trasformazione di modello (p.e. quando il canale da integrare prevede servizi asincroni al posto di quelli sincroni previsti da PAGO); Schedulazione di flussi (p.e. quando Middleware prevede un flusso in ingresso ma il Sistema d’Area richiede di essere interrogato con un polling); L’implementazione dell’adaptor e la sua installazione può essere a carico del sistema da integrare o del Sistema PAGO. Sistema PAGO Funzionalità del sistema – modello di integrazione 2/2

12 3 Sistema PAGO Vista Architetturale

13 3 Sistema PAGO Valore aggiunto dell’integrazione con PAGO  Per la P.A.: Unico sistema interlocutore che media con tutti i canali di pagamento; Standard omogenei per diversi enti per la gestione di tutti i tipi di debito; Gestione unificata del ciclo di vita; individuazione debito  pagamento  registrazione  notifica  rendicontazione  Per gli intermediari di pagamento: Possibilità di servire vari enti con un unico sistema interlocutore; Standard omogenei per la gestione di tutti i pagamenti; Alleggerimento dei processi di rendicontazione accessori al pagamento;

14 3  PAGO Middleware (MW) Componente centrale dell’architettura, espone e chiama servizi standard per integrare sistemi d’area e sistemi integrati di riscossione con i più diversi canali di pagamento;  PAGO WEB (PW) Componente integrata con MW che consente il pagamento WEB di tributi e funzioni di interrogazione per il cittadino (opzionale se si utilizzano solo gli altri canali o altri portali WEB di pagamento);  Postazioni TOTEM Un totem è un PC in rack, collegato in rete con PAGO, solitamente dotato di touch- screen, con un POS fisico per effettuare pagamenti; La piattaforma non comprende una versione standard dei TOTEM che devono essere implementati da terze parti basandosi sulle specifiche di servizio; Sono previsti due tipi di postazioni TOTEM: Totem classici: applicazioni stand alone che comunicano con Middleware tramite i servizi standard; Totem avanzati: browser WEB “chiusi”, ovvero limitati nella navigazione verso le sole pagine di PagoWEB; Sistema PAGO Moduli 1/2

15 3  Console di Configurazione Consente di gestire, entro certi limiti senza necessità di interruzione dei servizi, l’introduzione o la modifica di nuovi enti, tributi, canali e regole di business;  Console Operatore Consente di monitorare i log delle operazioni, interrogare i pagamenti effettuati e forzare alcune operazioni (p.e. la spedizione via eMail di una ricevuta);  Gateway dei pagamenti Il gateway media una serie di canali molto diversi tra loro (come ATM, Home Banking, Tabbaccai, GDO, SISAL, …) colloquiando con il Middleware tramite un’interfaccia di servizi ed un processo omogenei; (opzionale se si utilizzano solo gli altri canali);  Cruscotto di rendicontazione Consente interrogazioni e report per individuare la disponibilità di denaro sui diversi conti relativamente alle coordinate di bilancio (opzionale se la funzionalità è coperta da altro componente). Sistema PAGO Moduli 2/2

16 3  Il processo di pagamento tramite gateway presenta le seguenti caratteristiche: Pagamento dei soli debiti strutturati; Pagamento di un solo debito per ogni transazione; Utilizzabilità da canali con interfaccia limitata; Non richiede l’autenticazione dell’utente; Richiede l’uso di un ID univoco di richiesta; Consente l’invio di notifiche “ridotte” da Gateway a Middleware (i dati mancanti nella notifica vengono completati con quelli restituiti precedentemente dalla Ricerca effettuato con lo stesso ID di richiesta) Può essere utilizzato da qualsiasi canale, anche non mediato dal gateway, che rispetti il processo ed il formato dei servizi (p.e. totem di tipo classico). Sistema PAGO - Middleware Funzionalità del sistema – Pagamento da Gateway (o canale compatibile)

17 3  Il processo di pagamento a carrello è un’estensione del precedente e presenta le seguenti caratteristiche: Pagamento di tutti i tipi di debito; Pagamento di uno o più debiti per ogni transazione; Richiede l’uso di canali con GUI avanzate (tipicamente WEB); Sistema PAGO - Middleware Funzionalità del sistema – Pagamento a carrello (WEB)

18 3  Il processo di pagamento in modalità bridge presenta le seguenti caratteristiche: Supporto di “causali” che richiedono il pagamento di uno o più debiti; Compilazione dal sistema d’area chiamante di un carrello non modificabile; Utilizzabile solo con il canale PagoWEB; Sistema PAGO – Middleware e PagoWEB Funzionalità del sistema – Pagamento in modalità bridge

19 3  Una volta registrato il pagamento di un debito, indipendentemente dalla sua sorgente, il Middleware prevede varie possibilità di trattamenti automatici ed asincroni dello stesso. I due processi principali post- pagamento sono: Protocollazione: Chiamata opzionale ad un eventuale servizio di protocollazione gestito dall’ente; Notifica ai Sistemi d’Area: Notifica del pagamento del debito verso il suo sistema d’area o, se presente, il RISCO; Entrambi i processi sono schedulati a grana fine (pochi minuti) e procedono al trattamento di tutti i pagamenti non ancora marcati ed alla loro marcatura (protocollato, notificato); Gli end-point di protocollazione e notifica (così come quello di ricerca) sono configurati sulla base ente/tipo debito. Sistema PAGO – Middleware Funzionalità del sistema – Procedure asincrone post pagamento

20 3  L’alimentazione del cruscotto è un flusso che coinvolge i sistemi della P.A., il Middleware ed il Cruscotto; La P.A. deve prevedere un sistema (p.e. RISCO) owner della divisione degli importi nelle diverse voci di bilancio Oppure, in alternativa, dare la ownership per i vari tipi di debito ai relativi sistemi d’area Sistema PAGO - Middleware Funzionalità del sistema – Alimentazione Cruscotto 1/2

21 3  Il servizio di Notifica esposto dal Middleware verso i Canali di Pagamento supporta l’acquisizione di flussi massivi di pagamenti effettuati tramiti canali non on-line ma censiti (p.e. sportelli postali o bancari); I pagamenti acquisiti per questo flusso sono trattati come quelli on-line: registrati, notificati ai sistemi d’area (e/o a RISCO) ed infine rendicontati al cruscotto; In questo modo il Middleware può alleggerire i Sistemi d’Area e/o il RISCO dall’onere di acquisire i flussi dalle diverse fonti; Secondo le linee guida di integrazione, ove i flussi originali arrivino in formati proprietari (o secondo standard bancari pensati per tecnologie diverse dai WebService), si ricorrerà all’implementazione di appositi adaptor. Sistema PAGO - Middleware Funzionalità del sistema – Acquisizione pagamenti da flussi batch

22 3  Il Middleware è dotato di un’interfaccia WEB dedicata ai gestori del sistema ed agli operatori di back-office, che offre le seguenti funzionalità: Ricerca sui pagamenti Ricerca sui log Re-invio email con ricevuta Forzatura notifica a sistema d’area Forzatura protocollo Schedulazione processi batch Lancio manuale processi batch Sistema PAGO - Middleware Funzionalità del sistema – Funzioni Operatore

23 3  Il Pagamento tramite POS Virtuali delega al sistema di pagamento WEB dell’intermediario l’espletamento dell’effettiva transazione di pagamento previa un interscambio sicuro dei dati del carrello da pagare (Totale, conto di destinazione, descrizione generale, …);  Le macro fasi del pagamento con POS Virtuale sono le seguenti: 1.RomaPagamenti trasferisce i dati del pagamento, tramite un Web Service dell’Intermediario (Inizializzazione) 2.Il cittadino è successivamente indirizzato sulle pagine Web dell’Intermediario 3.Il cittadino inserisce nelle pagine web dell’Intermediario i dati necessari al pagamento: Eventuali credenziali Numero di carta (pagamento con carta di credito) 4.L’Intermediario notifica a RomaPagamenti l’esito della prenotazione 5.Il cittadino è nuovamente indirizzato alle pagine web di RomaPagamenti Sistema PAGO – Pago Web Funzionalità del sistema – Pagamento con POS Virtuali 1/2

24 3 Sistema PAGO – Pago Web Funzionalità del sistema – Pagamento con POS Virtuali 2/2

25 3 Sistema PAGO – Pago Web @POS PayRid - Caratteristiche  Il servizio consente di raccogliere le informazioni necessarie ad attivare la domiciliazione dei pagamenti a favore di un ente;  Le richieste di incasso vengono poi inoltrate da SIASSB attraverso il CBI su richiesta del titolare del conto corrente;

26 3  L’utente autenticato può effettuare ricerche sui pagamenti ed i debiti pagati, indipendentemente dal canale utilizzato, purché acquisiti dal Middleware. I criteri di selezione possibili sono: ID univoco debito; ID quietanza di pagamento; Periodo (data inizio e/o data fine); Tipo Debito; Canale di pagamento; Intermediario; Stato del pagamento (per il RID on-line): Valori di dati specifici di alcuni tipi debito; Ai criteri di selezione inseriti, viene sempre aggiunta automaticamente la restrizione ai soli debiti in cui l’utente è pagante o cittadino debitore; I risultati sono riportati in modo paginato, con un debito pagato per ogni riga; Ogni riga è un link che consente di aprire il dettaglio del debito selezionato; Dal dettaglio di un debito, l’utente può effettuare la ristampa della ricevuta o forzare il re-invio della mail di ricevuta; Sistema PAGO – Pago Web Funzionalità del sistema – Interrogazione pagamenti effettuati

27 3 PagoWEB – Home Page

28 3 PagoWEB – Selezione Tipo Debito

29 3 PagoWEB – Ricerca Debito

30 3 PagoWEB – Debito Trovato

31 3 PagoWEB – Carrello (1/2)

32 3 PagoWEB – Carrello (2/2)

33 3 PagoWEB – Modo di Pagamento

34 3 PagoWEB – Riepilogo Pagamento

35 3 PagoWEB – POS Virtuale

36 3 PagoWEB – Ricevuta Pagamento

37 3  La Console di Configurazione è un’applicazione Eclipse che consente di effettuare la maggior parte delle personalizzazioni e delle localizzazioni su Middleware e PagoWEB minimizzando la necessità di fermi del servizio. Sistema PAGO – Console di Configurazione Funzionalità del sistema – Hot Deployment

38 3  Tramite la console di configurazione possono essere effettuate le seguenti customizzazioni (solitamente senza richiedere fermi servizio): Interfaccia Utente: Ogni ente può avere un layout ed una home page personalizzati; Ogni ente può avere testi e formati personalizzati per le ricevute e le eMail; Ogni tipo tributo può avere una form personalizzata di ricerca/inserimento dati; Ogni Tributo può avere dati proprietari formattati per la ricevuta; Regole di Business: Per ogni combinazione ente/tipo tributo/canale sono personalizzabili le logiche per l’interpretazione ed il completamento dei dati in ricerca e notifica, tra cui la decodifica degli identificativi di debito; Per ogni tipo di debito possono essere aggiunte specifiche tabelle di transcodifica e di tipo chiave/descrizione; Regole di Dispatching: Per ogni ente/tipo tributo sono configurabili gli end point su cui ribaltare i servizi di ricerca e notifica (Sistemi d’Area, RISCO, …); Regole di Pagamento: Per ogni ente/Tipo tributo sono assegnabili restrizioni sulle modalitò di pagamento utilizzabili (canale, intermediario, conto, strumento). Sistema PAGO – Console di Configurazione Funzionalità del sistema – Customizzazione

39 3 Sistema PAGO – Integrazione Modulo MIP PEOPLE Vista Architetturale

40 3  Nell’architettura PAGO il modulo MIP sostituisce funzionalmente il Middleware Pagamenti  Il modulo MIP si integra con il Gateway Alimentazione Cruscotto (GWA) per alimentare il Cruscotto di Ragioneria: fornendo al GWA le informazioni sui pagamenti effettuati fornendo al GWA le voci contabili relative ai pagamenti effettuati (Opzionale)  Il modulo MIP si integra al Gateway Pagamento (GWP): Considerando il GWP una canale di erogazione con una propria interfaccia utente per il pagamenti di tributi “pre-calcolati” Considerando il GWP un sistema di pagamento che gestisce metodi specifici: bancomat, contanti,… Sistema PAGO – Integrazione Modulo MIP PEOPLE Caratteristiche

41 3 Integrazione MIP – Gateway Alimentazione Cruscotto  Estrazione dal LOG Contabile del modulo MIP Pagamenti di tutte le transazioni di pagamento completate e predisposizione del tracciato standard definito nell’ambito del progetto  Per i dati richiesti dal tracciato standard non gestiti dal MIP è possibile configurare i valori inseriti su base tipologia di tributo  Remapping delle voci contabili gestite opzionalmente dal MIP sulle voci di bilancio gestite in PAGO Sistema PAGO – Integrazione Modulo MIP PEOPLE Funzionalità 1/2 Sistema PAGO – Integrazione Modulo MIP PEOPLE Funzionalità 1/2

42 3 Integrazione MIP – Gateway di Pagamento  Il Gateway di Pagamento si integra con MIP Incassi per la gestione dei tributi “pre-calcolati” gestiti dal MIP sia in fase di verifica del tributo sia in fase di notifica di pagamento effettuato  Il Gateway di Pagamento si integra con MIP Pagamenti come un normale sistema fornito dal mondo bancario, i pagamenti effettuati attraverso il gateway sono inseriti nel LOG Contabile come i pagamenti effettuati con altri metodi Sistema PAGO – Integrazione Modulo MIP PEOPLE Funzionalità 2/2

43 3 Gateway Intermediari di pagamento Rete Bancari a Rete Tabacca i Rete Sisal GDO.... Adapter rete Sistema di Pagame nto Alimentazione Cruscotto Cruscotto Sistema Autorizzativo Sistema Pago Rete Interbancaria Le componenti principali del Gateway sono: Il Gateway dei pagamenti (GWP) Il Gateway di alimentazione Cruscotto (GWA) Sistema PAGO – Gateway dei pagamenti Caratteristiche – Architettura

44 3  Il Gateway dei pagamenti: supporta alcuni dei canali di pagamento (quelli che non si interfacciano direttamente con Pago) preservando le modalità ed i formati di comunicazione pre-esistenti o comunque propri del canale; E’ predisposto per l’aggiunta di nuovi canali di pagamento mediante l'implementazione di specifici adattatori; Ribalta le richieste dei canali di pagamento verso Pago utilizzando il formato XML standard con esso concordato;  L’architettura non solo consente un’indipendenza tecnologica degli attori rispetto alle controparti, ma anche una gestione automatica dei processi di quadratura e riconciliazione contabile. Sistema PAGO – Gateway dei pagamenti Caratteristiche – Funzionalità 1/3

45 3  Il Servizio Gateway mette a disposizione di un ente: Piattaforma multicanale: in grado di estendere la rete di accettazione sia verso le reti Bancarie che non Bancarie consentendo sia l’utilizzo di canali fisici tradizionali, quali ATM e POS, o Canali innovativi (HomeBanking, PhoneBanking, Call Center, …);  Per rete non Bancaria si intende per esempio la Grande Distribuzione Organizzata (GDO), e la rete Tabaccai;  Strumenti di pagamento: Gestione di tutti gli strumenti di pagamento utilizzabili e presenti sul mercato in dipendenza delle regole di utilizzo tipiche del canale di accettazione. Sistema PAGO – Gateway dei pagamenti Caratteristiche – Funzionalità 2/3

46 3  Rendicontazione accentrata dell’operatività di Servizio, attraverso la produzione di una rendicontazione giornaliera delle operazioni effettuate che consente: agli istituti emittenti degli strumenti di pagamento di addebitare i propri correntisti; alle Banche pagatrici e tesoriere di gestire i processi contabili; all’ente di effettuare una quadratura tra i pagamenti e gli incassi; ai soggetti (canali) non Bancari, di effettuare gli accrediti alle Banche Tesoriere dell’ente;  Indipendenza Intermediari di pagamento da tributi pagati: Le logiche di integrazione definite consentono di rendere trasparente i sistemi rispetto all’introduzione del pagamento di nuovi tributi;  Collegamento online real-time con Pago: al fine di consentire un allineamento costante e puntuale dei sistemi del comune rispetto ai tributi pagabili e pagati, consentendo inoltre di disaccoppiare tecnologicamente le problematiche attinenti ai diversi canali di utilizzo. Sistema PAGO – Gateway dei pagamenti Caratteristiche – Funzionalità 3/3

47 3  Il pagamento attraverso il Gateway ha le seguenti caratteristiche: Pagamento dei soli debiti strutturati; Pagamento di un solo debito per ogni transazione; Utilizzabilità da canali con interfaccia proprietaria; Non richiede l’autenticazione dell’utente; Richiede l’uso di un ID univoco di richiesta. Sistema PAGO – Gateway dei pagamenti Caratteristiche – Processo di pagamento

48 3  Il Gateway di alimentazione Cruscotto: Espone un'interfaccia di servizi verso PAGO per: ricevere le notifiche inerenti i pagamenti effettuati, indipendentemente dal canale di pagamento utilizzato; ricevere i dati di bilancio dal sistema Pago; Fornisce al cruscotto della ragioneria le informazioni sui debiti pagati. Sistema PAGO – Gateway di Alimentazione Cruscotto Caratteristiche - Funzionalità

49 3  Il Cruscotto “certifica” tutti i flussi finanziari previsionali in attesa di riconciliazione secondo quanto rilevato dai canali di incasso e ad esso notificato, espone anche le informazioni relativi ai codici di bilancio nei quali tali flussi finanziari vengono suddivisi;  Accentra in un unico punto: le informazioni essenziali di un pagamento (tipologia ed importo); le informazioni sulla transazione (canale di pagamento, strumento e valuta); le voci di bilancio dell’amministrazione;  Espone una interfaccia WEB che consente l’analisi e la rendicontazione dei dati di pagamento pervenuti;  Espone un’interfaccia ad hoc per essere alimentato dal Gateway di alimentazione cruscotto. Sistema PAGO – Cruscotto di Rendicontazione Caratteristiche – Funzionalità 1/2

50 3  Il cruscotto prevede anche l’esposizione di dati statistici, quali: Statistiche operatività: riporta il numero e l’importo delle operazioni eseguite con indicazione della specifica tipologia di canale e identificazione del tipo tributo; Previsionale incasso: esposizione delle informazioni relative ad una Macrostruttura e alle specifiche voci di bilancio classificate per tipologia di tributo e valorizzazione degli importi previsionali di incasso per voce di bilancio e valuta; Inquiry pagamenti: interrogazione del singolo pagamento eseguito per tipologia di canale con identificazione del tipo tributo e dello specifico codice identificativo del tributo. Sistema PAGO – Cruscotto di Rendicontazione Caratteristiche – Funzionalità 2/2

51 3 Sistema PAGO – Cruscotto di Rendicontazione Prima fase del progetto, Connessione ad un URL: TSPoint prod - https://www.tspoint.ithttps://www.tspoint.it Successivamente l’accesso sarà consentito direttamente dal Portale del Comune di Roma e non sarà necessario effettuare le operazioni di Login successivamente descritte. Login La acquisizione dati avviene tramite l’invio di una pagina html del tipo: Dove verrà presentata una pagina in cui dovrà digitare la propria Userid e la propria Password

52 3 Sono riportati tutti i pagamenti effettuati dai contribuenti da: Portale WEB, Chioschi, Canale Bancario (ATM, HomeBanking, filiale e call center), più in generale saranno evidenziati gli incassi effettuati sui conti di tesoreria bancari attivati dall’ente. Sistema PAGO – Cruscotto di Rendicontazione

53 3 Funzioni realizzate ad oggi: Statistiche Generali Riportano i pagamenti effettuati dai contribuenti suddivisi per tipologia di tributo e canale di provenienza del pagamento Statistiche Periodiche E videnza sui pagamenti di un determinato periodo. Statistiche di Tesoreria Gli incassi sono esposti in base alla data disponibilità e alla Banca Tesoriera su cui sono state accreditate le somme incassate Statistiche per Macrostruttura Riportano, suddivise per Macrostruttura (Municipio, dipartimento, ecc.) e/o area Tematica (rette scolastiche, asili nido ecc.) gli importi dei pagamenti registrati. Statistiche per Bilancio Riportano, suddivisi per voce di bilancio,gli importi dei pagamenti registrati. Inquiry Consentono la ricerca di uno, o più, pagamenti effettuati attraverso uno dei canali di pagamento sopra evidenziati. Sistema PAGO – Cruscotto di Rendicontazione

54 3 L’accesso alla funzione avviene selezionando dal menù a tendina la relativa voce di menù. Sistema PAGO – Cruscotto di Rendicontazione Statistiche Generali

55 3 Attraverso i tasti Stampa ed Esporta è possibile ottenere la stampa delle informazioni ed esportare i dati su un foglio excel. Sistema PAGO – Cruscotto di Rendicontazione Statistiche Generali

56 3 Utilizzando l’icona posta a fianco della riga del prospetto sopra riportati si ottiene il dettaglio dei dati della giornata come di seguito riportato. Sistema PAGO – Cruscotto di Rendicontazione Statistiche Generali

57 3 Le informazioni riportate in questo report riguardano gli incassi di un determinato periodo suddivisi per canale e tipo tributo; il periodo di riferimento può essere il mese oppure l’anno. Sistema PAGO – Cruscotto di Rendicontazione Statistiche per Periodo

58 3 Cliccando su Esporta, è possibile generare un foglio excel su cui sono riportati i dati estratti con i criteri indicati nella selezione. Utilizzando il tasto “Grafico” si ha la possibilità di creare, stampare e scaricare il grafico con le statistiche dei pagamenti. Sistema PAGO – Cruscotto di Rendicontazione Statistiche per Periodo

59 3 Con questo report si ottengono informazioni relative agli accrediti eseguiti sui conti delle banche tesoriere del comune, gli importi sono suddivisi per Banca Tesoriera e data disponibilità. Sistema PAGO – Cruscotto di Rendicontazione Statistiche per Banca Tesoriera

60 3 Consente la visualizzazione dei dati raggruppati per: Municipio / Dipartimento o Centro di Ricavo, Tipo Tributo e Area di competenza, i dati riportati sono raggruppati per data operazione. Sistema PAGO – Cruscotto di Rendicontazione Statistiche per Macro Struttura

61 3 Utilizzando l’icona posta a destra della riga sarà possibile ottenere le informazioni di dettaglio e successivamente la loro stampa E’ inoltre possibile effettuare la visualizzazione e la successiva stampa dei totali del periodo utilizzando l’icona posta in fianco alla riga “totale”. Sistema PAGO – Cruscotto di Rendicontazione Statistiche per Macro Struttura

62 3 Sistema PAGO – Cruscotto di Rendicontazione Statistiche per Macro Struttura

63 3 Consente la visualizzazione dei dati raggruppati per voce di bilancio e gli importi dei pagamenti registrati. Sistema PAGO – Cruscotto di Rendicontazione Statistiche per Bilancio

64 3 Utilizzando l’icona posta a destra della riga sarà possibile ottenere le informazioni di dettaglio e successivamente la loro stampa Sistema PAGO – Cruscotto di Rendicontazione Statistiche per Bilancio

65 3 Le ricerche sono consentite per: Numero Pagamento Numero Bollettino Data da / Data a Sistema PAGO – Cruscotto di Rendicontazione Interrogazioni