Ciao.
Siope+ da quello che ho capito serve a certificare i pagamenti della PA verso il resto del mondo esportandoli in formato OPI per importarli nel sistema SIOPE+.
Tale sistema aiuta a certificare i pagamenti della PA, a ridurre il backlog di pagamenti e a prendere meno multe dalla UE. Quindi mi sembra un flusso da PA verso SIOPE+ verso Tesoreria e non viceversa.
In che modo può essere usato per la riconciliazione in PagoPA (cosa che peraltro sarebbe fantastica) ?
Andrea
Andrea,
SIOPE non e’ legato a pagoPA.
Stiamo ragionando con RGS su come integrare la piattaforma pagoPA con SIOPe+
Ti abbraccio
@Giuseppe_Virgone Buongiorno, volevo sapere se ci sono novità in merito.
Dovremmo gestire il sistema di Tesoreria della PA di riferimento ed integrarlo con PagoPA.
Ci chiedevamo se dovevamo prendere in considerazione le Linee Guida di SIOPE+ o se invece è slegato dal processo di riconciliazione e rendicontazione su PagoPA.
Nel caso in cui SIOPE+ non fosse relativo a tali processi, c’è della documentazione da consultare per gestire l’interazione tra Tesoreria e PagoPA?
Grazie,
Michele Calvani
Non ho novità. Ci stiamo lavorando. Prendete in considerazione le Linee Guida di SIOPE+ che è compliant con pagoPA per la riconciliazione dei flussi di rendicontazione
Se non sbaglio, il tema posto dovrebbe trovare risposta qui
l’attivazione dovrebbe essere per il 1/7/2019
Ciao @Andrea_Tironi1,
riprendo questo thread per individuare una modalita’ di riconciliazione dei pagamenti pagoPA tramite SIOPE+ che, da altri tuoi messaggi, sembra tu abbia gia’ realizzato con successo.
La riconciliazione si dovrebbe perfezionare acquisendo dai servizi SIOPE+ il giornale di cassa. Da questo e’ necessario individuare le seguenti informazioni per le operazioni minime richieste da pagoPA:
Facendo riferimento alle linee guida ed alle regole tecniche OPI (e non avendo tracciati di esempio su cui verificare) faccio le seguenti ipotesi:
Identificare i movimenti di entrata:
Ogni flusso_giornale_di_cassa/informazioni_conto_evidenza/movimento_conto_evidenza che presenta il dato tipo_movimento=ENTRATA.
I campi tipo_documento e tipo_operazione sono ininfluenti?
Identificare i movimenti di entrata pagoPA
Credo che l’unico modo sia dall’analisi della causale, verificando che presenti una delle stringhe:
Estrarre la causale
Campo flusso_giornale_di_cassa/informazioni_conto_evidenza/movimento_conto_evidenza/causale
Estrarre l’importo
Campo flusso_giornale_di_cassa/informazioni_conto_evidenza/movimento_conto_evidenza/importo
Estrarre l’identificativo SCT
Questo non mi e’ chiaro… forse il codice_riferimento_operazione definito come:
Nel caso in cui l’accredito sia pervenuto a mezzo di bonifico “SEPA CREDIT TRANFER”, deve
riportare l’informazione contenuta nell’attributo AT-43 “Originator Bank’s Reference” (c.d. TRN)
Ti trovi in questa analisi? Hai qualche contributo in merito?
tipo_documento mi pare sia ininfluente
tipo_operazione non mi ricordo bene, forse e’ utile nei casi in cui la reversale del giornale di cassa sia chiusa parzialmente: leggerei meglio la documentazione
SCT non saprei
io ho dato le indicazioni di massima alla sw house e l’idea, su come procedere,
poi ci siamo confrontati varie volte ma il codice l’hanno scritto loro, quindi davo feedback
sul risultato ma non conosco con precisione il parsing fatto
Condivido brevemente l’esperienza fatta quando ero al Comune di Piacenza in cui nel 2017, a seguito di alcune analisi dei processi operativi della ragioneria, ho inserito in un bando di gara la richiesta espressa di incrociare i dati presenti sulla piattaforma dei pagamenti, sul circuito PagoPA con i dati scaricati giornalmente dal circuito SIOPE+. Individuando le stringhe /PUR/LPGE si ricava il numero di provvisorio , l’importo e L’ID_Flusso ; L’ID_Flusso è la chiave per l’incrocio dei dati sulle varie piattaforme permette di riconciliare automaticamente i pagamenti e fornire alla ragioneria le informazioni utili per la generazione della reversale di incasso. La soluzione è operativa da tempo ed ha permesso di agevolare il lavoro della ragioneria.
Buonasera a tutti.
Come fornitore, abbiamo attivato una importante Pubblica Amministrazione centrale verso pagoPA. Nell’ambito di tale progetto, abbiamo fatto in modo che le righe del Giornale di Cassa (prima OIL, ora OPI) siano acquisite automaticamente dal sistema e utilizzate nell’ambito del processo di riconciliazione.
In particolare, nel nostro sistema sono importati i movimenti di entrata del Giornale di Cassa che abbiano le seguenti caratteristiche:
Grazie @Marco_Pernazza per il prezioso contributo!
mi risulta sconosciuta questa causale perchè l’unico purpose previsto dalle specifiche pagoPA è LGPE-RIVERSAMENTO. Hai informazioni aggiuntive per questa casistica?
Ciao e grazie
Ciao @nardil, si tratta di una strategia di gestione delle anomalie legate ad un errato riversamento SCT (importo in difetto).
Puoi fare riferimento a questo link:
Cerco di riassumere e di integrare con alcune osservazioni per verificare se riusciamo a giungere ad un’analisi condivisa del processo.
Il flusso “finanziario” arriva con il Giornale di Cassa SIOPE+. Ormai tutte le PA dovrebbero ricevere i dati solo tramite l’infrastruttura SIOPE+.
All’interno del flusso è possibile identificare i sospesi di entrata pagoPA mediante i campi:
In funzione delle regole di generazione dello IUV con i vari modelli e tenendo come vincolo la necessità per un ente di supportare più intermediari/partner tecnologici i formati ammessi per la causale di versamento nel caso di bonifici singoli dovrebbero essere del tipo (gli schemi indicati sono quelli di generazione IUV):
Ovvero, in caso di integrazione di un precedente bonifico con importo errato in difetto o in eccesso
Da notare che la stringa /TXT/Integrazione è opzionale, inoltre mi domando se sia possibile un bonifico di integrazione negativo nel caso di importo in eccesso o se rappresenta solo una notifica da gestire fuori pagoPA. Inoltre come distinguo una revoca da un’integrazione visto che potrei avere una causale identica (con solo /RFB/< IUV > ) nei due casi?
Inoltre bisogna notare che il bonifico sembra essere riferito alla singola voce (datiSingoloPagamento) di una RT, in quanto legato ad un IBAN e potendo specificare un IBAN diverso per ogni voce (datiSingoloVersamento) di una RPT. Anche la causale di versamento è riferita alla singola voce, non essendoci una causale associata all’intero IUV. Considerato che la descrizione della causale è opzionale (l’importo è cmq recuperabile dal movimento del Giornale di Cassa) potrebbe esserci qualche difficoltà ad individuare la voce di RT corretta.
Recuperare la RT è necessario perché contiene per ogni voce il codice contabile di riconciliazione (capitolo di entrata, numero di accertamento, …), pagoPA mette a disposizione un’API per recuperare una RT, quindi un qualsiasi intermediario/partner tecnologico dovrebbe essere in grado di recuperare l’RT per un ente di cui è intermediario/partner anche nel caso in cui il pagamento sia stato eseguito mediante l’infrastruttura tecnologica di un altro intermediario/partner.
Nel caso di revoca dovrei accedere all’esito di revoca ed individuare la voce corrispondente, ma per gli esiti di revoca non mi risulta che pagoPA metta a disposizione una modalità pull per recuperare un esito (viene fornito in modalità push all’intermediario che gestisce il pagamento)
Nel caso di bonifici cumulativi invece avremo:
/PUR/LGPE-RIVERSAMENTO/URI/< idFlusso >
Se l’importo del bonifico indicato nel Giornale di Cassa non coincide con l’importoTotalePagamenti indicato nel flusso il PSP emetterà ad integrazione del precedente bonifico con importo errato in difetto o in eccesso un nuovo bonifico con causale:
/PUR/LGPE-INTEGRAZIONE/URI/< idFlusso >
La distinzione per voci all’interno del flusso in questo caso è documentata abbastanza chiaramente nelle specifiche.
I flussi di rendicontazione sono disponibili a tutti gli intermediari/partner tecnologici e contengono al loro interno il dettaglio della singola voce di pagamento/revoca.
Le specifiche pagoPA prevedono che le richieste di revoca possano essere accettate entro un giorno dal pagamento, ma non specificano entro quanto tempo deve essere inviato il messaggio con l’esito di revoca.
Sia la richiesta di revoca che l’esito poi potrebbero essere parziali.
La rendicontazione di una revoca quindi potrebbe arrivare in un flusso diverso da quello che rendiconta il pagamento e in ogni caso potrebbero esserci più flussi di rendicontazione per uno stesso IUV (nel caso le voci usino IBAN diversi).
A complicare ulteriormente le cose potrebbero esserci anche nel flusso degli item che indicano (esito = 9) un pagamento avvenuto con pagoPA in assenza di RPT e per cui quindi non è disponibile neanche la RT: ci sarà un unico importo non suddiviso in voci e non associato a codici contabili di incasso.
L’intermediario/partner che ha gestito il pagamento potrebbe disporre lo stesso delle informazioni necessarie alla riconciliazione (memorizzate nell’APA da lui gestito), ma in questo caso non sarebbero disponibili per gli altri intermediari/partner (a meno che non cooperino in modo concordato).
Vi chiedo gentilmente conferma delle affermazioni fatte, per giungere a tali conclusioni ho dovuto rileggere più volte i vari documenti di specifica e quanto presente nel forum e mi piacerebbe avere da voi un feedback sulla loro correttezza.
Si hanno informazioni su quante RPT/RT veicolino le informazioni contabili nell’elemento (non obbligatorio) “datiSpecificiRiscossione”?
Nelle SANP 2.1 era un dato obbligatorio, poi magari nel testo uno può scriverci quello che vuole, ma comunque è un’informazione che passa su PagoPA senza modifiche o controlli, quindi se un ente vuole usarla per riconciliare basta che la usi.
Pienamente d’accordo.
Mi chiedevo appunto quanti EC la usano.
E quanti PT consentono di usarla.
[Sembra strano, ma di fatto le amministrazioni fanno cio’ che le SWH consentono di fare, è raro il caso opposto]
Riconciliare integrando i dati dei FR con quelli delle RT invece che con quelli presenti nel sistema locale “delle posizioni in attesa” consentirebbe anche di superare le problematiche che incontrano gli enti plurintermediati (sempre che uno dei PT/intermediari accetti di prelevare tutte le RT e i FR).
EDIT: ho detto una fesseria, e’ ancora obbligatorio. chiedo scusa. Il dubbio di quanti EC lo usino o siano in grado di usarlo effettivamente resta.
Sì, in effetti l’idea è quella di fornire agli enti un servizio di riconciliazione che funzioni per tutti i servizi di pagamento indipendentemente dal partner/intermediario usato per un particolare servizio. Per le revoche purtroppo non c’è la possibilità di farsi dare da PagoPA l’esito della revoca e neanche di sapere se è stata fatta una richiesta di revoca, ma visto che una richiesta può essere accettata solo entro un tempo limitato dopo il pagamento (un giorno mi pare) giocando con dei timer si dovrebbe riuscire a riconciliare tutto.