6. Back-office

6.1. Riconciliazione

All’interno di questo paragrafo vengono descritti i casi d’uso che descrivono il processo contabile operato dall’Ente Creditore al fine di riconciliare i pagamenti effettuati dall’Utilizzatore finale.

6.1.1. Attori del processo di Riconciliazione Contabile e casi d’uso

Gli attori coinvolti nel processo di riconciliazione sono i seguenti:

• Ente Creditore: rappresenta una Pubblica Amministrazione che ha ricevuto i pagamenti effettuati dall’Utilizzatore finale e necessita di riconciliare i pagamenti a suo favore
• PSP: rappresenta un Prestatore di Servizi di Pagamento che ha accreditato il conto di un EC con le somme incassate nella giornata operativa
• Banca Tesoriera/ Cassiera: rappresenta il Prestatore di Servizi di Pagamento che gestisce il conto di incasso di un EC. E’ il destinatario del flusso di riversamento SCT e notifica all’EC l’avvenuto incasso su sistemi esterni a pagoPA.

6.1.2. Worflow di Riconciliazione

Il processo di riconciliazione comporta il seguente workflow dove saranno utilizzati i seguenti termini:

• Giorno D: giorno lavorativo in cui è stato eseguito il pagamento
• Giorno D+1: giorno lavorativo successivo al giorno D
• Giorno D+2: giorno lavorativo successivo al giorno D+1
• Cut-off: orario di termine della giornata operativa. (NB la giornata operativa pagoPA termina alle ore 13)

P re-C o ndiz ione	L’EC ha ricevuto dei pagamenti su un conto destinato all’incasso tramite pagoPA Entro D+1 il PSP accredita (con uno o più SCT) il conto dell’EC per l’importo delle somme relative a RPT con valore del tag dataOraMessaggioRichiesta antecedente al cut-off della giornata operativa pagoPA del giorno D. Per ogni SCT cumulativo di più pagamenti, il PSP genera un flusso di rendicontazione, contenente la distinta dei pagamenti cumulati. Entro D+2 il PSP sottomette al NodoSPC il flusso di rendicontazione di cui al punto precedente. Il Nodo valida la richiesta e archivia il flusso rendendolo disponibile per l’EC.
T rigg er	L’EC riconcilia gli accrediti SCT ricevuti sul conto indicato nelle RPT
D escr i zion e	L’EC richiede la lista dei flussi disponibili sul Nodo relativa ai pagamenti da riconciliare. L’EC richiede il flusso di interesse, lo riceve e procede alla riconciliazione dei pagamenti.
P ost- C ondi z ione	Il pagamento transisce allo stato Pagamento Rendicontato

Tabella 7: Worflow di Riconciliazione

L’evoluzione temporale è la seguente:

Figura 5: Diagramma di sequenza del processo di riconciliazione contabile

1. il PSP genera il flusso di rendicontazione componendo il file XML di rendicontazione codificato in base64;
2. il PSP accredita con SCT il conto di un EC. L’importo dello SCT può essere pari all’importo di un singolo pagamento ovvero pari all’importo cumulativo di più pagamenti, purché tali pagamenti siano stati incassati a favore del medesimo EC nella medesima giornata operativa pagoPA.

Nel caso di riversamento cumulativo, l’SCT dovrà riportare all’interno dell’attributo AT-05 (Unstructured Remittance Information) il valore:

/PUR/LGPE-RIVERSAMENTO/URI/<identificativoFlusso>,

dove identificativoFlusso specifica il dato relativo all’informazione di rendicontazione inviata al NodoSPC.

Nel caso di riversamento singolo, l’SCT dovrà riportare all’interno dell’attributo AT-05 (Unstructured Remittance Information) il valore della causale di versamento indicato nella RPT.

3. il PSP, mediante la primitiva nodoInviaFlussoRendicontazione, invia al NodoSPC il flusso di rendicontazione generato, valorizzando i parametri di input identificativoFlusso con l’identificativo del flusso di rendicontazione da trasmettere e il parametro xmlRendicontazione con il file XML di rendicontazione codificato in base64.
4. il NodoSPC verifica il file XML di rendicontazione;
5. il NodoSPC elabora il file XML di rendicontazione;
6. il NodoSPC esegue l’archiviazione del flusso di rendicontazione sulle proprie basi di dati;
7. il NodoSPC replica fornendo esito OK alla primitiva nodoInviaFlussoRendicontazione;
8. l’EC, mediante la primitiva nodoChiediElencoFlussiRendicontazione, richiede al NodoSPC la lista dei flussi di rendicontazione disponibili;
9. il NodoSPC elabora la richiesta;
10. il NodoSPC, a seguito della validazione della richiesta, replica con response OK fornendo in output la lista completa di tutti i flussi disponibili per l’EC;
11. l’EC richiede al NodoSPC uno specifico flusso di rendicontazione presente nella lista, mediante la primitiva nodoChiediFlussoRendicontazione valorizzando nella request il parametro di input identificativoFlusso con l’identificativo del flusso di rendicontazione richiesto;
12. il NodoSPC elabora la richiesta.
13. il Nodo invia all’Ente Creditore il flusso richiesto mediante response positiva alla primitiva di cui al punto 11.
14. l’EC elabora il flusso di rendicontazione veicolandolo verso i propri sistemi di riconciliazione;
15. l’EC riceve dalla propria Banca di Tesoreria in modalità digitale un flusso contenente i movimenti registrati sul proprio conto; in caso di utilizzo da parte dell’EC di SIOPE+, tale flusso è rappresentato dal Giornale di Cassa nel formato OPI;
16. L’EC, sulla base dell’identificativo flusso ricevuto nel file XML di rendicontazione e delle RT archiviate, effettua la riconciliazione contabile.

6.1.3. Motore di Riconciliazione

L’obiettivo del presente paragrafo è quello di tratteggiare in termini essenziali il modello concettuale di un algoritmo (il Motore di riconciliazione) che consenta al singolo EC di riconciliare i flussi informativi degli incassi messi a disposizioni da pagoPA con quelli finanziari. Nel flusso sono altresì riportate, sempre in ottica del singolo EC, le attività che ci si attende siano compiute dalla singola controparte PSP.

Nell’ipotesi semplificativa in cui la data richiesta per il pagamento coincida con la data di invio della richiesta di pagamento, il processo di riconciliazione opera riproducendo ricorsivamente un ciclo di quattro passi da compiersi nella successione riportata di seguito per ogni PSP aderente al NodoSPC:

Passo	Descrizione	Attività EC	Attività PSP
	Quadratura degli incassi	A chiusura del giorno lavorativo (D), il motore individua le RPT inviate prima del cut-off. Per ognuna di tali RPT il motore seleziona le corrispondenti RT, ne controlla la quadratura e distingue, accantonandole, quelle relative a un incasso (RT+). Ai fini dei successivi passi del processo di rendicontazione sarà altresì necessario individuare gli IUV per i quali, a causa di una eccezione, l’incasso, benché sia stato effettuato non corrisponde a una RT. Tali incassi saranno rendicontati mediante co diceEsitoSingol oPagamento 9 nel caso di riversamento cumulativo.	A chiusura della giornata operativa il PSP, controlla la quadratura degli incassi eseguiti per l’EC determinando: Gli IUV per cui ha emesso RT+ Gli IUV da rendicontare con codice 9 Determina inoltre gli importi dello SCT Cumulativo e degli SCT singoli da eseguire.
	Ricezione SCT	nel giorno D+1, la Banca Cas siera/Tesoriera dell’EC riceve dal PSP, tramite SCT, i flussi finanziari relativi agli incassi del giorno D. In generale, per ogni PSP, l’EC può ricevere un SCT cumulativo e un numero indeterminato di SCT singoli relativi a una sola RT+	Esegue SCT di cui al punto 1
	Quadratura FDR	nel giorno D+2 il motore, interrogando il NodoSPC, può effettuare il downloading del Flusso di Rendicontazione (FDR) relativo al giorno D. Il motore può quindi controllare la quadratura dello FDR, abbinando ad esso, in base allo IUV, le RT+ relative al giorno D, gli ulteriori incassi non corrispondenti a una RT e gli ER (Esito Revoca) eventualmente contenuti nel FDR. In questo ultimo caso il motore esclude gli ER rendicontati dal novero degli ER da controllare. Inoltre il motore, nel processo di quadratura, distingue gli importi a compensazione (in eccesso o difetto) eventualmente contenuti nel FDR. Per ogni PSP, il motore distingue e accantona le RT+ non abbinate a un FDR (RTS)	Il PSP genera il FDR, associandolo allo SCT di cui al punto 2 con il dato ide ntificativoFlus so, indicando: Gli IUV per i quali ha emesso RT+ codiceEsitoSin goloPagamento pari a 0 Gli IUV rendicontati con codiceEsitoSin goloPagamento pari a 9 IUV associati a un Estio Revoca accettato dall’EC (ER+) Infine mette a disposizione dell’EC il FDR relativo al giorno D
	Quadratura riversamenti SCT	A chiusura del giorno lavorativo D+2 il motore elabora tutte le notifiche di incasso relative al giorno D+1 ricevute dalla Banca Cas siera/Tesoriera (nel caso SIOPE+ la notifica è rappresentata dal “Giornale di Cassa” OPI). Per ogni PSP il motore conclude il processo di riconciliazione eseguendo le seguenti elaborazioni: Esegue la quadratura di ogni riversamento singolo in abbinamento con la corrispondente RTS controllando che: L’Identificati vo univoco versamento (IUV) che identifica la singola RTs coincida con la componente “identificativ o univoco versamento” nel dato “*Unstructured Remittanced Information*” di cui al tracciato del SEPA Credit Transfer nel caso di versamento effettuato tramite SCT ovvero nel campo causale nel caso di versamento effettuato tramite bollettino di conto corrente postale. Il valore del tag *importoTotale Pagato* della stessa RTs corrisponda con l’importo effettivamente trasferito. Esegue la quadratura di ogni riversamento cumulativo, in abbinamento con il corrispondente FDR controllando che: L’Identificati vo del FDR coincida con la componente “identificativ o flusso versamento” nel dato “*Unstructured Remittance Information*” di cui al tracciato del SEPA Credit Transfer nel caso di versamento effettuato tramite SCT Il valore del tag *importoTotale Pagamenti* nel FDR corrisponda con l’importo effettivamente trasferito.

Tabella 8: Motore di Riconciliazione

6.1.4. Gestione degli errori

Il paragrafo mostra le strategie di risoluzione per gli errori che possono verificarsi durante l’esecuzione del processo di quadratura mediante il motore di riconciliazione, rispetto ai passi presi in esame nella descrizione dell’MDR stesso.

6.1.4.1. Passo3: Quadratura FDR

• FDR non quadra

6.1.4.2. Passo4: Quadratura riversamenti SCT

• Riversamento in difetto
• SCT ad integrazione di un riversamento Cumulativo in difetto: la Causale del SCT dovrà essere valorizzata come segue: /PUR/LGPE-INTEGRAZIONE/URI/< identificativoFlusso > identificativoFlusso identifica lo FDR per il quale è stato effettuato un riversamento in difetto.
• SCT ad integrazione di un riversamento Singolo: la causale del SCT dovrà essere valorizzata come segue:
  • /RFS/<IUV>/<importo>[/TXT/Integrazione]
• /RFB/<IUV>[/<importo>][/TXT/Integrazione]
• Riversamento in eccesso

Nel presente scenario l’EC riscontra condizioni di squadratura in eccesso tra gli SCT riversati dai PSP e le somme specificate nella RTs o dal FDR nel caso di riversamento singolo o cumulativo, rispettivamente. In tale circostanza la compensazione avviene in modalità manuale da concordare tra le controparti attraverso il tavolo operativo.

6.2. Gestione degli errori

6.2.1. Gestione degli errori di riconciliazione

Il paragrafo descrive la gestione degli errori che possono verificarsi durante l’esercizio del processo di riconciliazione contabile. In particolare sono prese in esame le eccezioni per le quali si riscontra il fallimento delle primitive in gioco oppure l’esito negativo del workflow di riconciliazione; tutte le eccezioni riportate non permettono al pagamento di transire allo stato “Pagamento riconciliato”. I casi di errore descritti prevedono l’attivazione del Tavolo Operativo

[1] nel caso in cui i soggetti erogatori e fruitori dei servizi

applicativi risultassero impossibilitati a procedere in autonomia nella risoluzione delle anomalie oppure l’azione di controllo suggerita non risultasse risolutiva.

SCT singolo in assenza di RPT

P re -c o nd iz io ne	Il PSP ha incassato diversi servizi
D es cr i zi on e	Nell’elaborare un SCT singolo di riversamento relativamente ad un flusso di rendicontazione in assenza di RPT ( codice 9 ), il PSP evidenzia la mancanza di il PSP non evidenzia la mancanza della RPT.
P os t- c on di z io ne	N/A

In caso di mancanza di RPT, il PSP non è in grado di valorizzare l’attributo AT-05 con la causale di versamento in quanto tale informazione sarebbe dovuta essere reperibile all’interno della RPT non ricevuta.

Le possibili azioni di controllo sono riportate nella tabella successiva:

Strategia di risoluzione	Tipologia Errore	Azione di Controllo Suggerita
	Flusso codice 9	E’ necessario attivare un TAVOLO OPERATIVO

Invio flusso rifiutato dal NodoSPC

Pre -condizion e	Il PSP invia al NodoSPC un flusso di rendicontazione
D escrizione	Il NodoSPC esegue la validazione del flusso fornendo response negativa
Pos t-condizio ne	Lo stato del pagamento permane in RT_PAGATA

errore flusso rendicontazione

Figura 15: Evoluzione temporale dello scenario flusso rifiutato dal Nodo

L’evoluzione temporale dello scenario è la seguente:

1. il PSP genera il flusso di rendicontazione componendo il file XML di rendicontazione codificato in base64;
2. il PSP, mediante la primitiva nodoInviaFlussoRendicontazione, invia al NodoSPC il flusso di rendicontazione generato, valorizzando i parametri di input identificativoFlusso con l’identificativo del flusso di rendicontazione da trasmettere e il parametro xmlRendicontazione con il file XML di rendicontazione codificato in base64.
3. il NodoSPC verifica il file XML di rendicontazione;

Eseguito uno degli scenari alternativi, il flusso procede come segue:

4. il Nodo replica negativamente alla primitiva precedente fornendo response con esito KO emanando un faultBean il cui faultBean.faultCode rappresenta l’errore riscontrato; in particolare:
   • PPT_FLUSSO_SCONOSCIUTO: il NodoSPC non riscontra alcuna congruenza tra il valore del parametro di input identificativoFlusso della primitiva di richiesta ed il valore del parametro identificativoFlusso nel file XML di rendicontazione;
   • PPT_SEMANTICA nel caso di riscontro di errori nel tracciato xml del file XML di rendicontazione.

Le possibili azioni di controllo sono riportate nella tabella successiva:

Str ategia di ris oluzio ne	Tip ologi a E rrore	Azione di Controllo Suggerita
	PP T_FLU SS O_SCO NOS CIUTO	Verificare la composizione della SOAP request nodoInviaFlussoRendicontazione ed il contenuto del file XML di rendicontazione
	PP T_SEM A NTICA	Verificare la composizione del file XML di rendicontazione (vedi documento “Elenco Controlli Primitive NodoSPC” per la relativa primitiva/FAULT_CODE)

Tabella 19: Strategia di risoluzione dello scenario Flusso rifiutato dal Nodo

Timeout invio flusso di rendicontazione

Il seguente scenario, nel trattare in generale il caso di timeout successivo all’invio del flusso di rendicontazione, si sofferma sulla gestione dei messaggi di errore maggiormente rappresentativi.

Pre -condiz ione	Il tempo di attesa della response del NodoSPC supera il timeout di cui al documento Livelli di Servizio
Des crizion e	Il NodoSPC manifesta condizioni di timeout ed il PSP esegue il relativo processo di gestione
Pos t-condi zione	Lo stato del pagamento permane in RT_EC

L’evoluzione temporale è la seguente:

Timeout FLusso

Figura 16: Timeout invio flusso di rendicontazione

1. il PSP genera il flusso di rendicontazione componendo il file XML di rendicontazione codificato in base64.
2. il PSP accredita con SCT il conto dell’EC per l’importo delle somme incassate (l’SCT contiene l’indicazione del flusso di rendicontazione)
3. il PSP invia al NodoSPC il file XML di rendicontazione da elaborare mediante la primitiva nodoInviaFlussoRendicontazione;

il NodoSPC non risponde manifestando una condizione di timeout;

4. il PSP richiede lo stato di elaborazione del flusso di rendicontazione inviato mediante la primitiva nodoChiediStatoElaborazioneFlussoRendicontazione valorizzando il parametro di input identificativoFlusso con il valore dell’identificativo flusso di cui richiedere lo stato;
5. Il NodoSPC effettua il controllo sullo stato di elaborazione del flusso inviato;
6. Il NodoSPC replica mediante response OK alla primitiva di cui al punto 8 fornendo lo stato di elaborazione del flusso di rendicontazione; in particolare:
   • FLUSSO_IN_ELABORAZIONE: il NodoSPC deve terminare le operazioni di archiviazione dei flussi sulle proprie basi di dati;
   • FLUSSO_ELABORATO: il NodoSPC ha elaborato il flusso di rendicontazione inviato dal PSP;
7. il PSP gestisce lo stato riscontrato dal NodoSPC eliminando il file XML di rendicontazione nel caso di FLUSSO_ELABORATO oppure attendendo oltre nel caso di FLUSSO_IN_ELABORAZIONE.

Richiesta lista flussi di rendicontazione rifiutata dal NodoSPC

Pre -cond i zioni	La posizione debitoria si trova nello stato PAGATA e lo stato del pagamento è in RT_EC. L’EC richiede la lista dei flussi di rendicontazione
Des crizi one	L’EC non riceve la lista dei flussi di rendicontazione richiesta ed è impossibilitato a procedere alla riconciliazione dei pagamenti
Pos t-con di zione	Lo stato del pagamento è in RT_EC

Figura 17: Richiesta lista flussi di rendicontazione rifiutata dal NodoSPC

L’evoluzione temporale dello scenario è la seguente:

1. l’EC richiede, mediante la primitiva nodoChiediElencoFlussiRendicontazione, la lista dei flussi di rendicontazione archiviata sul NodoSPC;
2. Il NodoSPC valida negativamente la richiesta ed emana response negativa con esito KO e faultBean.FaultCode rappresentativo dell’errore riscontrato.

Str ategia di ris oluzio ne	Tip ologi a E rrore	Azione di Controllo Suggerita
	PP T_SIN TA SSI_E XT RAXSD	Verificare la composizione della SOAP request (vedi documento “Elenco Controlli Primitive NodoSPC” per la relativa primitiva/FAULT_CODE)
	PP T_PSP _S CONOS CIUTO	Verificare il parametro identificativoPSP nella SOAP request

Tabella 20: Strategia di risoluzione dello scenario richiesta lista flussi rifiutata dal Nodo

Richiesta Flusso Rifiutata dal Nodo / Nessun flusso presente

Pre -con diz ione	La posizione debitoria si trova nello stato PAGATA e lo stato del pagamento è in RT_EC e L’EC richiede uno specifico flusso di rendicontazione
Des criz ione	L’Ente Creditore non riceve lo specifico flusso richiesto
Pos t-co ndi zion e	Lo stato del pagamento è in RT_EC

Figura 18: Evoluzione temporale dello scenario richiesta Flusso rifiutata dal Nodo / Flusso mancate

L’evoluzione temporale dello scenario è la seguente:

1. l’EC richiede al NodoSPC uno specifico flusso di rendicontazione mediante la primitiva nodoChiediFlussoRendicontazione;
2. il Nodo replica negativamente alla richiesta fornendo response con esito KO emanando un faultBean il cui faultBean.faultCode rappresenta l’errore riscontrato; in particolare:
   • PPT_SINTASSI_EXTRAXSD: nel caso di errori di invocazione della SOAP request;
   • PPT_ID_FLUSSO_SCONOSCIUTO: nel caso l’EC richieda un flusso il cui identificativoFlusso risulti non registrato nelle basi di dati del NodoSPC;
   • PPT_SYSTEM_ERROR: nel caso in cui il NodoSPC riscontri errori di sistema nell’elaborazione della richiesta;

Str ategia di ris oluzio ne	Ti pologia Errore	Azione di Controllo Suggerita
	PP T_SINTA SS I_EXTRA XSD	Verificare la composizione della richiesta SOAP (vedi documento “Elenco Controlli Primitive NodoSPC” per la relativa primitiva/FAULT_CODE)
	PP T_SEMAN TICA
	P PT_ID_F LU SSO_SCO N OSCIUTO	Verificare il valore del parametro di input IDFLUSSO nella richiesta SOAP
	PP T_SYSTE M_ERROR	Ritentare nuovamente la richiesta del flusso di rendicontazione, altrimenti innescare il Tavolo Operativo

Tabella 21: Richiesta Flusso Rifiutata dal Nodo / Nessun flusso presente

[1]	Per i dettagli del Tavolo Operativo si rimanda alla sezione IV.