menu di navigazione del network

Siope+ e PagoPA

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

2 Likes

Mi sono informato a @Giuseppe_Virgone.
Siope+ non ha relazione con PAGOPA.

Andrea,

SIOPE non e’ legato a pagoPA.
Stiamo ragionando con RGS su come integrare la piattaforma pagoPA con SIOPe+

Ti abbraccio

2 Likes

@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

3 Likes

Se non sbaglio, il tema posto dovrebbe trovare risposta qui
l’attivazione dovrebbe essere per il 1/7/2019

1 Like

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:

  • Identificare i movimenti di entrata
  • Identificare se e’ un riversamento pagoPA
  • Per ciascun movimento:
    • Estrarre la causale
    • Estrarre l’importo
    • Estrarre l’identificativo SCT

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:

  • /PUR/LGPE-RIVERSAMENTO/URI
  • /RFB/
  • /RFS/

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?

1 Like

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.

1 Like

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:

  • tipo_movimento = “ENTRATA”
  • tipo_documento = “SOSPESO ENTRATA”
  • tipo_operazione = “ESEGUITO”.
    Tra questi movimenti, sono riconosciuti come derivanti da transazioni di pagamento pagoPA (e quindi presi in esame per la riconciliazione) quelli che contengono nella causale i pattern:
    “/RFB/”
    “/PUR/LGPE-RIVERSAMENTO/URI/”
    “/PUR/LGPE-INTEGRAZIONE/URI/”
    Dalla causale, per tali movimenti, sono ricavati lo IUV o l’Identificativo del Flusso di Rendicontazione.
3 Likes

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:

1 Like

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:

  • tipo_movimento = “ENTRATA”
  • tipo_documento = “SOSPESO ENTRATA”
  • tipo_operazione = “ESEGUITO” (da verificare se possibile anche STORNATO)
  • tipo_esecuzione= “SEPA CREDIT TRANSFER” (i trasferimenti di fondi da PSP a BT avvengono solo con SCT)

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):

  • /RFS/< IUV >/< importo >[/TXT/< descrizione >] Schema (F)
  • /RFB/< IUV >[/< importo >][/TXT/< descrizione >] Schemi (B), (E)

Ovvero, in caso di integrazione di un precedente bonifico con importo errato in difetto o in eccesso

  • /RFS/< IUV >/< importo >[/TXT/Integrazione] Schema (F)
  • /RFB/< IUV >[/< importo >][/TXT/Integrazione] Schemi (B), (E)

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.

4 Likes