12. Back-office¶
12.1. Revoca e storno¶
Il NodoSPC mette a disposizione servizi di interscambio che i soggetti aderenti possono utilizzare per realizzare indifferentemente processi di storno e/o revoca di pagamento, purché siano intesi come funzionalità di supporto del sistema pagoPA a cui ricorrere unicamente per sanare situazioni di eccezione. Ogni soggetto aderente rileva la disponibilità della controparte ad avviare tali processi mediante dati di configurazione.
Come specificato nella figura successiva, tali funzionalità sono istanziate per scopi di business ben definiti; ad esempio per il rientro da situazioni anomale o di incoerenza nei documenti prodotti durante il ciclo di vita del pagamento, rispetto allo stato di fatto del pagamento stesso. Al variare del soggetto istanziante e delle motivazioni che innescano l’esecuzione del processo, possono verificarsi le situazioni mostrate nella figura seguente.
Figura 1: Attori coinvolti nell’innesco dei processi di revoca e storno di una RT
Processo | Innesco |
---|---|
RevocaRT | Avviato dal PSP |
Storno | Avviato dall’EC |
Tabella 1: Soggetti che istanziano i processi di Revoca e Storno di un pagamento
Il processo di revoca può essere a sua volta diversificato sulla base delle motivazioni che ne determinano l’innesco, come da tabella successiva:
Processo | Tipologia | Descrizione |
---|---|---|
RevocaRT | Annullo Tecnico | Innescato dal PSP quando, in casi assolutamente eccezionali, lo stato effettivo del pagamento non è coerente con i documenti in possesso dell’Utilizzatore finale:
Si fa presente che è fatto obbligo per il PSP di implementare le funzionalità di annullo tecnico e per EC di predisporre le opportune soluzioni tecniche per la gestione di tali richieste. |
charge-back Utente | Innescato dal PSP nel caso in cui l’Utilizzatore finale chieda il riaccredito delle somme versate per un pagamento conclusosi con esito positivo | |
Storno | Storno | L’Utilizzatore finale richiede all’EC lo storno delle somme precedentemente pagate al PSP. Si fa presente che non è fatto obbligo al PSP implementare tale funzionalità |
Tabella 2: Descrizione sintetica delle motivazioni per l’innesco dei processi di revoca e storno
12.1.1. Processo di Revoca per Annullo Tecnico¶
Il processo di revoca di una ricevuta telematica per Annullo Tecnico consente il rientro da situazioni anomale o di incoerenza nello stato di fatto del pagamento rispetto a quanto rappresentato dalla RT generata dal PSP attestante il pagamento. Il caso d’uso nominale è rappresentato nella tabella successiva.
Pre-Condizione |
|
Trigger | Il PSP ha evidenza di una squadratura puntuale fra incasso e relativa RT . |
Descrizione |
|
Post-Condizione |
|
Tabella 3: Caso d’uso del processo di revoca per annullo tecnico
L’evoluzione temporale del processo di revoca è il seguente:
Figura 2: Diagramma di sequenza del processo di revoca di una RT per Annullo Tecnico
- il PSP compone il documento XML per la richiesta di revoca e lo sottomette all’EC attraverso il NodoSPC mediante la primitiva nodoInviaRichiestaRevoca;
- In questo caso il valore del campo tipoRevoca all’interno della struttura datiRevoca sarà pari ad 1;
- il NodoSPC valida la richiesta inviata dal PSP;
- il NodoSPC inoltra la richiesta di revoca all’EC mediante la primitiva paaInviaRichiestaRevoca;
- l’EC replica al PSP fornendo esito positivo mediante response alla primitiva precedente;
- il NodoSPC inoltra la replica dell’EC al PSP fornendo response positiva alla primitiva di cui al punto 1.
- l’EC esegue il rollback del sistema relativamente alla posizione debitoria interessata e predispone il documento informativo XML ER attestante l’esito della revoca;
- l’EC invia il documento ER al PSP mediante il Nodo attraverso la primitiva nodoInviaRispostaRevoca;
- il NodoSPC valida il documento ER ricevuto;
- il NodoSPC inoltra il documento ER al PSP mediante la primitiva pspInviaRispostaRevoca;
- il PSP conferma la ricezione del messaggio di esito della revoca fornendo response OK alla primitiva precedente;
- il NodoSPC conferma all’EC la ricezione dell’esito della revoca da parte del PSP fornendo response OK alla primitiva di cui al punto 7.
Il workflow si conclude con l’invio da parte del PSP della RT che andrà a sovrascrivere quella revocata. In questo caso il parametro Forzacontrollosegno nella SOAP request nodoInviaRT deve essere impostato a 1.
12.1.2. Processo di Revoca di una Ricevuta Telematica per charge-back¶
Il processo di revoca per charge-back di una RT è innescato dal PSP solo verso l’EC che aderisce al servizio e sarà realizzabile solo per i pagamenti effettivamente revocabili (sono esclusi tutti i pagamenti a fronte di servizi già erogati al momento della richiesta di charge-back) purché la posizione debitoria dell’utilizzatore finale risulti pagata. Il caso d’uso nominale è così descritto:
Pre-Condizione |
|
Trigger | L’Utilizzatore finale avanza la richiesta di revoca al PSP con cui ha effettuato il pagamento |
Descrizione |
|
Post-Condizione |
|
Tabella 4: Scenario d’uso del processo di revoca di una RT per charge-back
Al pari dei casi d’uso riportati nei capitoli precedenti, l’evoluzione temporale e le primitive coinvolte nel processo di revoca sono riportate nella figura successiva, avendo cura di notare che il caso d’uso rappresenta lo scenario in cui le cui invocazioni SOAP si concludono con esito positivo (esito: OK come parametro di output).
Figura 3: Diagramma di sequenza del processo di revoca per charge-back
- l’Utilizzatore finale richiede al PSP attestante il pagamento la revoca della RT per charge-back;
- il PSP compone il documento informativo XML Richiesta di Revoca (RR) e la invia al NodoSPC mediante la primitiva SOAP nodoInviaRichiestaRevoca;
- il NodoSPC valida la richiesta di revoca;
- il NodoSPC invia la richiesta di revoca all’EC mediante la primitiva paaInviaRichiestaRevoca;
- l’Ente Creditore, accettata la RR, replica al PSP attraverso il NodoSPC fornendo response OK;
- il NodoSPC inoltra al PSP la replica positiva dell’EC fornendo response OK alla primitiva di cui al punto 2.
- l’EC, dopo aver verificato positivamente la possibilità di revoca della RT, riporta la Posizione Debitoria allo stato precedente al pagamento e procede alla generazione del documento informativo XML Esito Revoca (ER);
- l’EC invia il documento ER al PSP mediante il Nodo attraverso la primitiva nodoInviaRispostaRevoca;
- il NodoSPC valida il documento ER ricevuto;
- il NodoSPC inoltra il documento ER al PSP mediante la primitiva pspInviaRispostaRevoca;
- il PSP conferma la ricezione del messaggio di esito della revoca fornendo response OK alla primitiva precedente;
- il NodoSPC conferma all’EC la ricezione dell’esito della revoca da parte del PSP fornendo response OK alla primitiva di cui al punto 8;
- il PSP notifica l’Utilizzatore finale circa l’esito positivo della procedura di revoca della ricevuta telematica.
12.1.3. Processo di Storno di un pagamento¶
Il processo di storno di un pagamento, attivato dall’EC, è innescato quando l’Utilizzatore finale richieda a vario titolo la cancellazione di un pagamento precedentemente avvenuto. Il caso d’uso nominale e l’evoluzione temporale sono mostrate nella figura successiva.
Pre-Condizione |
|
Trigger | L’utilizzatore richiede lo storno di un pagamento precedentemente avvenuto |
Descrizione |
|
Post-Condizione |
|
Tabella 5: Caso d’uso del processo di storno di un pagamento
Figura 4: Evoluzione temporale del processo di storno di un pagamento
- l’Utilizzatore finale richiede lo storno di un pagamento effettuato all’EC;
- l’EC genera il documento XML RR;
- mediante la primitiva nodoInviaRichiestaStorno l’EC invia al NodoSPC il documento RR;
- il NodoSPC valida il documento RR ricevuto;
- il NodoSPC inoltra al PSP la RR generata dall’EC mediante la primitiva pspInviaRichiestaStorno;
- il PSP replica positivamente alla primitiva precedente fornendo Esito OK;
- il NodoSPC inoltra la replica precedente all’EC fornendo response OK alla primitiva di cui al punto 3;
- il PSP predispone il documento Esito Revoca – RR;
- il PSP inoltra all’EC mediante il NodoSPC l’esito della revoca attraverso la primitiva nodoInviaEsitoStorno;
- il NodoSPC valida il documento ER;
- il NodoSPC inoltra all’Ente Creditore il documento ER mediante la primitiva paaInviaEsitoStorno;
- l’EC replica positivamente al PSP mediante il NodoSPC fornendo response OK alla primitiva di cui al punto 11;
- il NodoSPC inoltra la replica precedente al PSP fornendo response OK mediante la primitiva nodoInviaEsitoStorno;
- l’EC informa l’Utilizzatore finale in merito all’esito delle operazioni di storno.
12.2. 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.
12.2.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.
12.2.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)
Pre-Condizione |
|
Trigger | L’EC riconcilia gli accrediti SCT ricevuti sul conto indicato nelle RPT |
Descrizione |
|
Post-Condizione | 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
- il PSP genera il flusso di rendicontazione componendo il file XML di rendicontazione codificato in base64;
- 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.
- 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.
Eseguito uno dei due scenari alternativi, il flusso procede come segue:
- il NodoSPC verifica il file XML di rendicontazione;
- il NodoSPC elabora il file XML di rendicontazione;
- il NodoSPC esegue l’archiviazione del flusso di rendicontazione sulle proprie basi di dati;
- il NodoSPC replica fornendo esito OK alla primitiva nodoInviaFlussoRendicontazione;
Il workflow prosegue descrivendo le operazioni lato EC. Il consumo delle interfacce esposte dal NodoSPC avviene in modalità pull.
- l’EC, mediante la primitiva nodoChiediElencoFlussiRendicontazione, richiede al NodoSPC la lista dei flussi di rendicontazione disponibili;
- il NodoSPC elabora la richiesta;
- 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;
- 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;
- il NodoSPC elabora la richiesta.
Il workflow prosegue con i seguenti scenari alternativi:
Flusso mediante response SOAP
- il Nodo invia all’Ente Creditore il flusso richiesto mediante response positiva alla primitiva di cui al punto 11.
- l’EC elabora il flusso di rendicontazione veicolandolo verso i propri sistemi di riconciliazione;
- 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;
- L’EC, sulla base dell’identificativo flusso ricevuto nel file XML di rendicontazione e delle RT archiviate, effettua la riconciliazione contabile.
12.2.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 codiceEsitoSingoloPagamento 9 nel caso di riversamento cumulativo. | A chiusura della giornata operativa il PSP, controlla la quadratura degli incassi eseguiti per l’EC determinando:
Determina inoltre gli importi dello SCT Cumulativo e degli SCT singoli da eseguire. |
|
Ricezione SCT | nel giorno D+1, la Banca Cassiera/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 identificativoFlusso, indicando:
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 Cassiera/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:
|
Tabella 8: Motore di Riconciliazione
12.2.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.
12.2.4.1. Passo3: Quadratura FDR¶
- FDR non quadra
Nella eventualità in cui l’EC non riuscisse ad operare la quadratura del FDR, ad esempio per valori errati di qualsiasi elemento all’interno del flusso stesso; l’EC, mediante il ricorso al tavolo operativo provvederà a richiedere la ri-emissione del FDR per procedere nuovamente all’esecuzione del Passo3.
12.2.4.2. Passo4: Quadratura riversamenti SCT¶
- Riversamento in difetto
Nel presente scenario l’EC riscontra condizioni di squadratura in difetto tra gli SCT riversati dai PSP sulla propria Banca Tesoriera/Cassiera e le somme specificate dalle singole RTs o dal FDR nel caso di riversamento singolo o cumulativo, rispettivamente. In tale circostanza il PSP interessato il quale dovrà procedere alla generazione di un nuovo SCT, riportante causale:
- 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]
Oppure
- /RFB/<IUV>[/<importo>][/TXT/Integrazione]
Dove il valore dal tag IUV fa riferimento alla RTs per la quale è stato riversato un SCTin difetto
- 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.
12.3. Gestione degli errori¶
12.3.1. Gestione degli errori di revoca¶
Il paragrafo mostra i casi di errore che si possono verificare durante il processo di richiesta di revoca di una Ricevuta Telematica, sia nel caso di revoca per Annullo Tecnico che per Charge-Back. Con assoluta generalità si documentano nei paragrafi successivi le tipologie di errori che afferiscono alle categorie “Errori Controparte” ed “Errori Validazione”; come specificato nel paragrafo Architettura Funzionale. Nell’analisi degli scenari si assume l’ulteriore semplificazione che l’interazione applicativa tra il NodoSPC ed i soggetti fruitori dei servizi esposti dal Nodo stesso non sia soggetta a fenomeni di timeout o congestione di rete. Si fa presente che nella gestione del ciclo di vita del pagamento tutti i casi riportati in seguito comportano la mancata ricezione del documento ER attestante l’esito positivo o meno del processo di revoca del pagamento.
RR Rifiutata dal NodoSPC
Pre-condizione | Il PSP sottomette all’EC una Richiesta di Revoca di una RT |
Descrizione | Il NodoSPC esegue la validazione del documento RR replicando esito KO all’invocazione di invio richiesta revoca da parte del PSP. |
Post-condizione | Lo stato del pagamento è in Revoca Rifiutata |
Tabella 9: RR Rifiutata dal NodoSPC
Figura 6: Diagramma di sequenza nel caso di RR rifiutata dal Nodo
L’evoluzione temporale è la seguente:
- l’utilizzatore finale richiede la revoca di una RT [1];
- il PSP sottomette al NodoSPC il documento RR mediante la primitiva nodoInviaRichiestaRevoca;
- il NodoSPC valida la richiesta;
- il NodoSPC emana response KO emanando un faultBean il cui faultBean.faultCode è rappresentativo dell’errore riscontrato; in particolare:
- PPT_SINTASSI EXTRAXSD: in caso di errori nella SOAP request
- PPT_SINTASSI_XSD: in caso di errori nel documento XML RR
- PPT_RR_DUPLICATA: in caso di sottomissione di una richiesta di revoca precedentemente sottomessa
- PPT_OPER_NON_REVOCABILE: nel caso non sussistano le condizioni per poter fruire del servizio di revoca (vedi caso d’uso nominale)
- PPT_SEMANTICA: nel caso di errori semantici
- il PSP comunica all’Utilizzatore Finale l’impossibilità di procedere nell’operazione di revoca [2].
Le azioni di controllo suggerite sono riportate nella Tabella successiva
Strategia di risoluzione | Tipologia Errore | Azione di Controllo Suggerita |
PPT_OPER_NON_REVOCABILE | Verificare la revocabilità dell’operazione | |
PPT_RR_DUPLICATA | Verificare la composizione del documento XML RR e della SOAP request (vedi documento “Elenco Controlli Primitive NodoSPC” per la relativa primitiva/FAULT_CODE) | |
PPT_SINTASSI_EXTRAXSD | ||
PPT_SINTASSI_XSD | ||
PPT_SEMANTICA | Verificare la composizione del documento XML RR (vedi documento “Elenco Controlli Primitive NodoSPC” per la relativa primitiva/FAULT_CODE) |
Tabella 10: Strategie di risoluzione nel caso di RR rifiutata dal Nodo
RR rifiutata dall’EC
Pre-condizione | Il PSP sottomette all’EC una Richiesta di Revoca di una RT |
Descrizione | Il NodoSPC valida positivamente il documento informativo RR:
|
Post-condizione | Lo stato del pagamento è in Revoca Rifiutata |
Figura 7: Diagramma di sequenza per il caso di errore di RR rifiutata dall’EC
L’evoluzione temporale del caso d’uso è la seguente (dal punto 4):
- il Nodo invia all’EC la Richiesta di Revoca mediante la primitiva paaInviaRichiestaRevoca;
- l’EC fornisce esito KO nella response emanando un faultBean il cui faultBean.faultCode è rappresentativo dell’errore riscontrato; in particolare:
- PAA_RR_DUPLICATA nel caso il PSP sottomette una richiesta di revoca precedentemente gestita
- PAA_OPER_NON_REVOCABILE
- il NodoSPC inoltra l’errore emesso dall’EC fornendo response KO alla primitiva di cui al punto 1 dello scenario precedente.
La Tabella successiva mostra le azioni di controllo suggerite per la risoluzione dell’anomalia.
Strategia di risoluzione | Tipologia Errore | Azione di Controllo Suggerita |
PPT_ERRORE_EMESSO_DA_PAA | Attivazione del Tavolo Operativo |
Tabella 11: Strategia di risoluzione dello scenario RR rifiutata dall’EC
ER Rifiutata dal NodoSPC
Pre-condizione | L’EC ha verificato la revocabilità di una RT a seguito di una richiesta di revoca |
Descrizione |
|
Post-condizione | Lo stato del pagamento è in Esito Revoca Rifiutata |
Figura 8: Diagramma di sequenza per lo scenario di ER rifiutata dal Nodo
L’evoluzione temporale dello scenario è il seguente:
- l’EC predispone il documento ER;
- l’EC invia al NodoSPC il documento ER mediante la primitiva nodoInviaRispostaRevoca;
- il NodoSPC valida negativamente il documento ER;
- Il Nodo fornisce esito KO nella response della primitiva di cui al punto 2 dove il valore del parametro faultBean.faultCode è rappresentativo dell’errore riscontrato; in particolare:
- PPT_ER_DUPLICATA nel caso di sottomissione di una ER già inoltrata
- PPT_RR_SCONOSCIUTA nel caso in cui rispetto all’ER inviato non risultasse alcuna RR precedentemente gestita
La Tabella successiva mostra le azioni di controllo suggerite per la risoluzione delle anomalie
Strategia di risoluzione | Tipologia di Errore | Azione di Controllo Suggerita |
PPT_OPER_NON_REVOCABILE | Verificare la revocabilità dell’operazione | |
PPT_RR_DUPLICATA | Verificare la composizione del documento XML RR (vedi documento “Elenco Controlli Primitive NodoSPC” per la relativa primitiva/FAULT_CODE) e della SOAP request | |
PPT_SINTASSI_EXTRAXSD | ||
PPT_SINTASSI_XSD | ||
PPT_SEMANTICA | Verificare la composizione del documento XML RR |
Tabella 12: Azioni di controllo per la risoluzione dello scenario di ER rifiutata dal Nodo
ER Rifiutata dal PSP
Pre-condizione | Il NodoSPC ha validato il documento ER |
Descrizione | Il PSP replica con esito KO alla invio della Esito della Revoca da parte dell’EC |
Post-condizione | Lo stato del pagamento è in Esito Revoca Rifiutata |
Figura 9: Diagramma di sequenza per il caso ER rifiutata dal PSP
L’evoluzione dello scenario in esame è il seguente (si assume validazione positiva da parte del NodoSPC, punto 3)
- il Nodo sottomette l’ER al PSP mediante la primitiva pspInviaRispostaRevoca;
- il PSP replica negativamente alla primitiva precedente fornendo response KO dove il valore del parametro faultBean.faultCode è rappresentativo dell’errore riscontrato; in particolare:
- CANALE_ER_DUPLICATA nel caso di ricezione di un ER precedentemente sottomessa
- CANALE_RR_SCONOSCIUTA nel caso l’ER sottomesso dal NodoSPC non corrisponda ad una precedente RR.
La Tabella successiva mostra le azioni di controllo suggerite per la risoluzione dell’anomalia
Strategia di risoluzione | Tipologia Errore | Azione di Controllo Suggerita |
---|---|---|
PPT_ERRORE_EMESSO_DA_PAA | Attivazione del Tavolo Operativo |
Tabella 13: Strategia di risoluzione dello scenario RR rifiutata dall’EC
12.3.2. Gestione degli errori di storno¶
Il paragrafo mostra i casi di errore che si possono verificare durante il processo di storno di un pagamento. Con assoluta generalità si documentano le tipologie di errori riportate nei paragrafi successivi che afferiscono alle categorie “Errori Controparte” ed “Errori Validazione”. Nell’analisi degli scenari si assume l’ulteriore semplificazione che l’interazione applicativa tra il NodoSPC ed i soggetti fruitori dei servizi esposti dal Nodo stesso non sia soggetta a fenomeni di timeout o congestione di rete. Si fa presente che nella gestione del ciclo di vita del pagamento tutti i casi riportati in seguito comportano la mancata ricezione del documento ER attestante l’esito positivo o meno del processo di storno del pagamento.
Richiesta Storno rifiutata dal Nodo
Pre-condizione | L’EC esegue una richiesta di storno |
Descrizione | Il Nodo a seguito della validazione replica fornendo esito negativo |
Post-condizione | Il pagamento si trova in stato Storno Rifiutato |
Figura 10: Diagramma di sequenza dello scenario richiesta storno rifiutata dal Nodo
L’evoluzione temporale è la seguente:
- l’Utilizzatore finale richiede all’EC lo storno di un pagamento;
- l’EC genera il documento xml RR;
- l’EC sottomette al NodoSPC il documento RR mediante la primitiva nodoInviaRichiestaStorno;
- il NodoSPC valida il documento RR;
- il NodoSPC replica negativamente alla primitiva precedente fornendo response KO dove il valore del parametro faultBean.faultCode è rappresentativo dell’errore riscontrato; in particolare:
- PPT_OPER_NON_STORNABILE nel caso in cui il PSP con il quale è stato effettuato il pagamento non supporta le funzionalità di storno
- PPT_RT_SCONOSCIUTA nel caso in cui la richiesta di storno non risulti associata ad alcuna RT positiva
La tabella successiva mostra le azioni di controllo suggerite per la risoluzione delle anomalie.
Strategia di risoluzione | Tipologia Errore | Azione di Controllo Suggerita |
---|---|---|
PPT_SINTASSI_EXTRAXSD | Verificare la composizione del documento XML RR (vedi documento “Elenco Controlli Primitive NodoSPC” per la relativa primitiva/FAULT_CODE) e della SOAP request | |
PPT_SINTASSI_XSD | ||
PPT_RT_SCONOSCIUTA | Verificare la composizione del documento XML RR e della SOAP request con particolare riferimento alla congruenza tra dati RR e dati presenti nella RT attestante il pagamento da stornare | |
PPT_OPER_NON_STORNABILE | Verificare la composizione del documento XML RR e della SOAP request; verificare l’adesione del PSP alle funzionalità di storno. | |
PPT_SEMANTICA | Verificare la composizione del documento XML RR (vedi documento “Elenco Controlli Primitive NodoSPC” per la relativa primitiva/FAULT_CODE) |
Tabella 14: Azioni di controllo suggerite per lo scenario Richiesta Storno rifiutata dal Nodo
Richiesta Storno Rifiutata dal PSP
Pre-condizione | Il NodoSPC ha validato la richiesta di storno sottomessa dall’EC |
---|---|
Descrizione | Il PSP valida la richiesta di storno e fornisce esito KO |
Post-condizione | Il pagamento si trova in stato Storno Rifiutato |
Figura 11: Evoluzione temporale dello scenario richiesta storno rifiutata dal PSP
L’evoluzione temporale è la seguente (dal punto 4):
- il NodoSPC valida positivamente la richiesta di storno;
- il NodoSPC sottomette la richiesta di storno mediante la primitiva pspInviaRichiestaStorno;
- il PSP replica con esito KO indicando un fault.bean il cui fault.code specifica l’errore riscontrato; in particolare:
- CANALE_SEMANTICA nel caso di errori nel tracciato XML RR
- CANALE_OPER_NON_STORNABILE nel caso di operazione non stornabile dal PSP
- CANALE_RR_DUPLICATA nel caso in cui l’EC sottomette una richiesta di storno precedentemente inviata
- CANALE_RT_SCONOSCIUTA nel caso in cui non sussista corrispondenza tra la richiesta di storno e la RT attestante il pagamento da stornare
- il NodoSPC emette esito KO alla primitiva nodoInviaRichiestaStorno inoltrando l’errore riscontrato dal PSP emanando un faultBean il cui faultBean.faultCode è rappresentativo dell’errore riscontrato.
- l’EC notifica l’utilizzatore finale dell’esito KO dell’operazione.
La tabella successiva mostra le azioni di controllo suggerite per la risoluzione dell’anomalia.
Strategia di risoluzione | Tipologia Errore | Azione di Controllo Suggerita |
---|---|---|
PPT_CANALE_ERRORE | Attivazione del Tavolo Operativo |
Tabella 15: Azioni di controllo suggerite per lo scenario Richiesta Storno rifiutata dal PSP
Esito Storno Rifiutato dal Nodo
Pre-condizione | Il PSP ha validato una richiesta di storno precedentemente sottomessa dal NodoSPC e procede ad inviare l’esito storno |
Descrizione | Il NodoSPC valida negativamente l’Esito storno |
Post-condizione | Il pagamento si trova in stato Storno Rifiutato |
Figura 12: Scenario Esito Storno rifiutato dal Nodo
L’evoluzione temporale è la seguente:
- il PSP predispone il documento XML ER attestante l’esito delle operazioni di storno;
- il PSP invia al NodoSPC il documento ER mediante la primitiva nodoInviaEsitoStorno;
- il NodoSPC valida negativamente la richiesta precedente;
- il NodoSPC fornisce response negativa mediante esito KO emanando un faultBean il cui faultBean.FaultCode è rappresentativo dell’errore riscontrato; in particolare:
- PPT_ER_DUPLICATA nel caso il PSP sottomette al NodoSPC un esito storno precedentemente inviato
- PPT_RR_SCONOSCIUTA nel caso il PSP sottomette al NodoSPC un documento ER non coerente con la precedente richiesta di storno
- PPT_SEMANTICA nel caso il NodoSPC riscontrasse errori nel tracciato XML ER.
La tabella successiva mostra le azioni di controllo suggerite per la risoluzione delle anomalie.
Strategia di risoluzione | Tipologia Errore | Azione di Controllo Suggerita |
---|---|---|
PPT_SINTASSI_EXTRAXSD | Verificare la composizione del documento XML RR (vedi documento “Elenco Controlli Primitive NodoSPC” per la relativa primitiva/FAULT_CODE) e della SOAP request | |
PPT_SINTASSI_XSD | ||
PPT_ER_DUPLICATA | Verificare la composizione del documento XML RR e della SOAP request con particolare riferimento alla congruenza tra dati RR e dati presenti nella RT attestante il pagamento da stornare | |
PPT_RR_SCONOSCIUTA | ||
PPT_SEMANTICA | Verificare la composizione del documento XML ER Verificare la composizione del documento XML RR (vedi documento “Elenco Controlli Primitive NodoSPC” per la relativa primitiva/FAULT_CODE) |
Tabella 16: Strategie di risoluzione per il caso ER rifiutata dal Nodo
Esito Storno rifiutato dall’EC
Pre-condizione | Il PSP ha validato una richiesta di storno precedentemente sottomessa dal NodoSPC e procede ad inviare l’esito storno |
Descrizione | L’EC valida negativamente l’Esito storno |
Post-condizione | Il pagamento si trova in stato Storno Rifiutato |
Figura 13: Scenario Esito Storno rifiutato da EC
L’evoluzione temporale dello scenario è il seguente (dal punto 4):
- il NodoSPC invia il documento ER all’EC mediante la primitiva paaInviaEsitoStorno;
- l’EC risponde negativamente all’invocazione precedente mediante esito KO emanando un faultBean il cui faultBean.faultCode è rappresentativo dell’errore riscontrato; in particolare:
- PAA_ER_DUPLICATA nel caso l’esito storno risultasse precedentemente inviato
- PAA_RR_SCONOSCIUTA nel caso in cui all’ER sottomessa non corrisponda alcuna RR precedentemente generata
- PAA_SEMANTICA nel caso in cui si riscontrino errori nel tracciato ER
- il NodoSPC propaga l’errore riscontato dall’EC mediante faultBean il cui faultBean.faultCode è pari a PPT_ERRORE_EMESSO_DA_PAA.
La tabella successiva mostra le azioni di controllo suggerite per la risoluzione delle anomalie
Strategia di risoluzione | Tipologia Errore | Azione di Controllo Suggerita |
PPT_ERRORE_EMESSO_DA_PAA | Attivazione del Tavolo Operativo |
Tabella 17: Strategie di risoluzione per il caso ER rifiutata dall’EC
ER Mancante per timeout delle controparti
Gli scenari di errore proposti nei paragrafi precedenti mostrano i possibili casi di ER mancante a causa di errori applicativi rappresentati dall’emanazione da parte degli attori coinvolti di un faultBean contenente un’eccezione applicativa appartenente ad una determinata famiglia di errori. Un ulteriore caso da prendere in esame è rappresentato dall’impossibilità di chiusura del processo di storno nel caso in cui le parti riscontrassero fenomeni di timeout.
Pre-condizione | La posizione debitoria è nello stato Richiesta Storno Inviata |
Descrizione | Il PSP e l’EC riscontrano fenomeni applicativo/infrastrutturali per i quali si manifestano condizioni di timeout nell’invocazione delle primitive e/o nella ricezione delle relative response. |
Post-condizione | Il pagamento permane in stato Richiesta Storno Inviata |
Figura 14: Evoluzione temporale dello scenario Esito Storno mancate per timeout
L’evoluzione temporale è la seguente:
- il PSP predispone il documento XML ER;
A questo punto sono possibili i seguenti scenari:
Timeout PSP in fase di invocazione
- La primitiva nodoInviaEsitoStorno non va a buon fine a causa di fenomeni di congestione imputabili al NodoSPC.
Timeout EC
- il PSP invia il documento ER mediante la primitiva nodoInviaEsitoStorno;
- Il NodoSPC valida positivamente la richiesta.
Alternativamente
- l’EC riscontra condizioni di timeout per le quali fallisce l’invocazione della primitiva paaInviaEsitoStorno;
oppure
- l’EC riscontra condizioni di timeout imputabili al NodoSPC per le quali la response alla primitiva paaInviaEsitoStorno non giunge al PSP.
In ogni caso
- il NodoSPC invia response KO alla primitiva nodoInviaEsitoStorno emanando un faultBean il cui faultCode è pari a PPT_STAZIONE_INT_PA_TIMEOUT.
Timeout PSP in ricezione response
- il PSP invia il documento ER mediante la primitiva nodoInviaEsitoStorno;
- Il NodoSPC valida positivamente la richiesta;
- l’EC riceve l’esito storno mediante la primitiva paaInviaEsitoStorno;
- l’EC emana response (di qualsiasi esito) alla primitiva precedente;
- Il NodoSPC inoltra la response al PSP che fallisce per condizioni di timeout.
Strategia di risoluzione | Tipologia Errore | Azione di Controllo Suggerita |
PPT_STAZIONE_INT_PA_TIMEOUT | Attivazione del Tavolo Operativo | |
Nessuna ricezione response |
Tabella 18: strategia di risoluzione
12.3.3. 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 [3] 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
Pre-condizione | Il PSP ha incassato diversi servizi |
Descrizione | 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. |
Post-condizione | 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-condizione | Il PSP invia al NodoSPC un flusso di rendicontazione |
Descrizione | Il NodoSPC esegue la validazione del flusso fornendo response negativa |
Post-condizione | Lo stato del pagamento permane in RT_PAGATA |
Figura 15: Evoluzione temporale dello scenario flusso rifiutato dal Nodo
L’evoluzione temporale dello scenario è la seguente:
- il PSP genera il flusso di rendicontazione componendo il file XML di rendicontazione codificato in base64;
- 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.
- il NodoSPC verifica il file XML di rendicontazione;
Eseguito uno degli scenari alternativi, il flusso procede come segue:
- 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:
Strategia di risoluzione | Tipologia Errore | Azione di Controllo Suggerita |
PPT_FLUSSO_SCONOSCIUTO | Verificare la composizione della SOAP request nodoInviaFlussoRendicontazione ed il contenuto del file XML di rendicontazione | |
PPT_SEMANTICA | 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-condizione | Il tempo di attesa della response del NodoSPC supera il timeout di cui al documento Livelli di Servizio |
---|---|
Descrizione | Il NodoSPC manifesta condizioni di timeout ed il PSP esegue il relativo processo di gestione |
Post-condizione | Lo stato del pagamento permane in RT_EC |
L’evoluzione temporale è la seguente:
Figura 16: Timeout invio flusso di rendicontazione
- il PSP genera il flusso di rendicontazione componendo il file XML di rendicontazione codificato in base64.
- il PSP accredita con SCT il conto dell’EC per l’importo delle somme incassate (l’SCT contiene l’indicazione del flusso di rendicontazione)
- 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;
- 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;
- Il NodoSPC effettua il controllo sullo stato di elaborazione del flusso inviato;
- 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;
- 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-condizioni | 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 |
---|---|
Descrizione | L’EC non riceve la lista dei flussi di rendicontazione richiesta ed è impossibilitato a procedere alla riconciliazione dei pagamenti |
Post-condizione | Lo stato del pagamento è in RT_EC |
Figura 17: Richiesta lista flussi di rendicontazione rifiutata dal NodoSPC
L’evoluzione temporale dello scenario è la seguente:
- l’EC richiede, mediante la primitiva nodoChiediElencoFlussiRendicontazione, la lista dei flussi di rendicontazione archiviata sul NodoSPC;
- Il NodoSPC valida negativamente la richiesta ed emana response negativa con esito KO e faultBean.FaultCode rappresentativo dell’errore riscontrato.
Strategia di risoluzione | Tipologia Errore | Azione di Controllo Suggerita |
---|---|---|
PPT_SINTASSI_EXTRAXSD | Verificare la composizione della SOAP request (vedi documento “Elenco Controlli Primitive NodoSPC” per la relativa primitiva/FAULT_CODE) | |
PPT_PSP_SCONOSCIUTO | 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-condizione | 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 |
---|---|
Descrizione | L’Ente Creditore non riceve lo specifico flusso richiesto |
Post-condizione | 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:
- l’EC richiede al NodoSPC uno specifico flusso di rendicontazione mediante la primitiva nodoChiediFlussoRendicontazione;
- 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;
Strategia di risoluzione | Tipologia Errore | Azione di Controllo Suggerita |
---|---|---|
PPT_SINTASSI_EXTRAXSD | Verificare la composizione della richiesta SOAP (vedi documento “Elenco Controlli Primitive NodoSPC” per la relativa primitiva/FAULT_CODE) | |
PPT_SEMANTICA | ||
PPT_ID_FLUSSO_SCONOSCIUTO | Verificare il valore del parametro di input IDFLUSSO nella richiesta SOAP | |
PPT_SYSTEM_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] | Attività da considerarsi solo nel caso di Revoca per Charge-Back |
[2] | Attività da considerarsi solo nel caso di Revoca per Charge-Back |
[3] | Per i dettagli del Tavolo Operativo si rimanda alla sezione IV. |