Faccio riferimento alla descrizione e alle primitive per la “gestione delle posizioni debitorie” (centralizzata su un servizio/db di PagoPA spa) che si trova qui: Posizioni Debitorie | SANP 3.7.0 | SANP
Cerco un confronto per capire anche come muoversi quando ci sarà da scegliere che tipo di gestione scegliere (centralizzata GPD o con replica degli avvisi sull’ACA - Archivio Centralizzato degli Avvisi) e come comportarsi quando si e’ plurintermediati. Poi, vabbe’, ci sarebbe anche da mangiarsi le mani per gli investimenti fatti anche di recente anche sugli avvisi PNRR che potrebbero adesso essere da rivedere… ma questa e’ un’altra storia…
Io intendo che l’intermediario, con tutte le sue scelte “proprietarie” di logiche funzionali e interfacce applicative, continua a essere necessario:
intanto perché è nominato proprio in premssa;
PagoPA spa si fa carico di tenere in memoria le posizioni, di gestire il pagamento senza contattare l’EC;
però, per esempio, l’EC deve comuqnue tenersi un suo archivio per la rendicontazione: GPD restituisce i flussi di riversamento e le ricevute, ma non veicola dati contabili, che quindi vanno recuperati internamente al sistema informativo dell’EC;
inoltre, non genera gli avvisi analogici PDF, quindi serve un software per crearli dove necessari;
GPD non espone, mi pare, un’interfaccia web per tenere la situazione sotto controllo ma solo le API;
In definitiva mi pare piu’ una facilitazione per i PT che per gli EC: se anche un software crea una posizione direttamente (e potrebbe farlo, e’ facile, stile app IO) poi gli manca tutto il resto…Quindi deve comunque interfacciarsi con un gateway interno all’EC (messo a disposizione dal Partner Tecnologico) con nessuna speranza di standardizzare il dialogo fra software e mondo pagoPA… (se anche uno il gateway se lo fa da solo cambia poco).
Detto che sono impressioni di una prima lettura del paragafo, cosa ne pensate?
Altro dubbio: c’e’ un’autenticazione con APIKEY (stile App IO) e una (alternativa? aggiuntiva?) con token JWT “dopo login su Azure”: ma la PDND?
Ciao Francesco, l’argomento merita più di qualche considerazione! Partiamo da quello che c’era una volta: paForNode.wsdl, l’API “sincrona” che deve implementare un ente che si connette direttamente al nodo dei pagamenti pagoPA, o un broker (Partner Tecnologico o Intermediario Tecnologico) che fornisce all’ente la connessione al nodo, che è il caso più comune. Quindi è responsabilità del broker esporre verso pagoPA un servizio che implementa paForNode.wsdl, mentre è responsabilità dell’ente rendere disponibile un Archivio dei Pagamenti in Attesa (APA) che il broker può interrogare per implementare la paForNode. Spesso l’ente delega ad un broker anche la gestione dell’APA (o di una sua parte). In tal caso ovviamente il broker dovrà fornire ai backoffice degli enti intermediati delle modalità per alimentare l’APA, di solito ciò viene fatto esponendo un’API “asincrona” che consente di aggiungere un pagamento, di modificarlo, annullarlo o cancellarlo e di eseguire query sull’APA per estrarre liste di pagamenti con certe caratteristiche o il dettaglio di uno specifico pagamento. Il dettaglio normalmente comprende anche lo stato del pagamento, che viene aggiornato durante il ciclo di vita del pagamento.
Non è l’unica modalità di integrazione possibile, l’APA è un entità logica, fisicamente può essere distribuito come si vuole, teoricamente ogni gestionale potrebbe mantenere la sua parte di APA. In tal caso il broker agisce come broker appunto, gestendo le richieste che arrivano dal nodo in funzione dello specifico pagamento e interagendo con la specifica porzione di APA che mantiene i dati per quel pagamento.
Nella pluralità dei casi comunque l’APA viene gestito da uno o più broker, ognuno per la parte di tipi di pagamento che gli sono stati conferiti. Fattori di differenziazione possono essere il tipo di API esposta verso i backoffice/gestionali (tecnologia usata, livello di astrazione dell’API, pattern di comunicazione sincrono/asincrono), il livello di granularità degli item dell’APA (singoli pagamenti, intera posizione debitoria), livello di supporto alle SANP, integrazione con altre piattaforme (vedi Send), ecc.
GPD di PagoPA di fatto consente la gestione tecnica di un archivio di posizioni debitorie (e delle possibile opzioni di pagamento) tramite un’API Rest “asincrona” esposta verso l’ente e implementando l’API SOAP “sincrona” paForNode verso il nodo dei pagamenti.
Quindi un ente o un broker che adottano GPD dispongono di un’infrastruttura gestita da PagoPA per la gestione dell’APA e l’esposizione di questo verso il nodo con diversi vantaggi:
modifiche alla paForNode ed in genere alla SANP verranno normalmente assorbite dall’implementazione di GPD
il rispetto degli SLA è a carico dell’implementazione di GPD
la scalabilità è un problema di PagoPA
la disponibilità del sistema alle richieste di pagamento è un problema di PagoPA (e infatti non è necessario alimentare l’Archivio Centralizzato degli Avvisi di pagamento o ACA) azzerando il rischio di dover pagare penali
consente di automatizzare l’interazione con Send gestendo il costo delle notifiche
in futuro PagoPA potrà aumentare il set di funzionalità aggiuntive offerte
Perchè PagoPA ha creato GPD? perchè diversi enti/broker esibiscono una scarsa capacità di rispettare gli SLA, talvolta persino di garantire la disponibilità dei sistemi, hanno difficoltà a mantenere i sistemi allineati con le nuove specifiche (SACI, SANP), limitando di fatto l’evoluzione della piattaforma pagoPA.
GPD non è perfetto, ma sta migliorando, la versione più recente ad esempio supporta un paio di feature richieste a gran voce dagli enti:
il caricamento massivo di posizioni debitorie
la possibilità di veicolare le informazioni contabili, con il supporto dei metadata associati al singolo transfert (era uno dei punti che segnalavi)
Una cosa essenziale che ancora manca è la possibilità di gestire al momento del pagamento l’attualizzazione dell’importo (a parte il costo della notifica richiesta tramite Send): la buona notizia è che il problema è all’attenzione di PagoPA e che intendono fornire una soluzione.
Un altro aspetto un pò carente riguarda le interrogazioni che possono essere fatte.
Gli avvisi analogici saranno a breve generabili invocando un altro servizio esposto via API da PagoPA.
Alcuni aspetti del ciclo di vita del pagamento/posizione debitoria non verranno invece intenzionalmente gestiti, fra questi la riconciliazione contabile: GPD fornisce la rendicontazione, ma non si occupa di interfacciarsi con i sistemi contabili per trasmettere i dati contabili associati ai pagamenti.
Lo stato di pagamento di una posizione debitoria viene gestito, ma è compito dell’ente richiedere il dettaglio di una posizione per capire se è stata pagata, completamente o parzialmente.
Per sintetizzare lo scopo di GPD non è fornire un sostituto di un broker, ma fornire una soluzione ai problemi più critici rilevati.
Sicuramente se lo avessero fatto 7-8 anno fa sarebbe più utile e avrebbe contribuito ad evitare investimenti che ora rischiano di diventare inutili, ma a quel tempo PagoPA manco esisteva e comunque meglio tardi che mai!
In ogni caso è in corso un’iniziativa degli intermediari regionali insieme a PagoPA per definire una piattaforma unitaria, con una suddivisione precisa dei compiti fra PagoPA e broker, finalizzata sia ad evitare dannose sovrapposizioni di ambito che a uniformare le interfacce esposte verso i gestionali. Il gruppo SPAC (myPay) inoltre estenderà il supporto alla piattaforma unitaria fornendo anche strumenti di gestione configurabili come un backoffice generalizzato per caricare posizioni debitorie, un motore di rendicontazione/riconciliazione per alimentare i sistemi contabili, strumenti di reporting ed analisi avanzati.
Gli strumenti di base per la gestione dell’innesco di pagamenti dovuti o spontanei invece sarà tendenzialmente gestita direttamente da PagoPA, anche per consentire una gestione unitaria dello stato dei pagamenti in carico ad un debitore, indipendentemente dal broker che ha gestito il pagamento.
Queste in quale parte del “messaggio” di creazione della posizione vanno?
Che tu sappia, quando PagoPA spa discute delle modifiche, gli enti da chi sono rappresentati? Come avanzano le loro istanze? Gli altri N.mila enti come fanno a capire l’aria che tira?
Passando invece a cose pratiche.
Sembra di capire che la soluzione GPD sia quella a cui tendere, cosi’ da abbandonare gli APA distrbuiti fra i vari PT dei vari enti.
Ma nell’immediato? Come gestire la transizione?
Conviene restare come si è (e replicare nell’ACA) in attesa che ci siano tutte le funzioni previste? Oppure come si salvaguardano le automazioni messe faticosamente in piedi per la rendicontazione e la riconciliazione?
E poi ancora, tornando nel teorico: come dovrebbe essere il flusso di interazione da software (o processo gestito extra software) a GPD a nodo a PSP e ritorno? Dove si colloca il PT? Che cosa deve mettere a disposizione?
In linea teorica il software potrebbe anche caricare le posizioni su GPD senza passare dal PT (la chiamata REST si fa). In teoria, se ci mette anche i dati contabili e questi finiscono nelle RT, la contabilizzazione dei pagamenti la fai incrociando flussi e RT che il software di contaiblità puo’ recuperarsi (anche via SFTP, almeno qualcosa, o tramite API). Mancherebbe la riconciliazione (cioe’ sapere che un certo debito e’ stato pagato). E la visione di insieme.
Pero’, per esempio, l’area personale del cittadino dove vedere tutti i pagamenti fatti e da fare la puo’ a questo punto realizzare chiunque, semplicemente interrogando PD tramite le sue API.
per come la interpreto io: il GPD e’ un’implementazione dell’APA ed in caso di integrazione asincrona, GPD non e’ nel dominio del soggetto aderente a differenza di quanto avviene in caso di integrazione sincrona. Che GPD sia quindi la soluzione a cui tendere e’ una scelta, non un obbligo, e dipende fortemente dalle esigenze del soggetto che si integra, sia questo un EC o un PT.
Quando crei una posizione debitoria devi specificare anche le opzioni di pagamento previste: ogni opzione contiene da 1 a 5 versamenti e in ogni versamento puoi specificare i metadata necessari che ritroverai poi nella ricevuta associati ai singoli transfer.
PagoPA ha interlocuzioni con ANCI, con l’Itd delle Regioni, con i broker e con gli enti connessi direttamente a pagoPA.
Io ad esempio, come RT di Regione FVG e degli enti da essa intermediati, ho contatti con PagoPA.
Un altro canale a disposizione di tutti è GitHub, dove oltre alle specifiche di interoperabilità c’è una sezione issues su cui chiunque può scrivere. PagoPA monitora la sezione e fornisce risposte (con frequenza non sempre ottimale, ma lo fa): personalmente posso dire che diverse problematiche esposte su github hanno trovato riscontro, anche con modifiche alle SANP.
Per le richieste puntuali c’è il canale di assistenza sul backoffice (Area Riservata) PagoPA, attivabile via mail o su Jira.
Da qualche mese hanno anche attivato dei webinar a tema dal developer portale.
Purtroppo PagoPA non è più presente su questo forum, una volta intervenivano anche qui, ma sono anni che non li vedo partecipare, peccato.
La scelta API sincrona o asincrona in realtà non la fa l’ente intermediato, ma il broker (o l’ente connesso direttamente).
Per quanto riguarda la riconciliazione, le specifiche attuali consentono di delegarla ad un unico broker, basta che gli altri broker compilino correttamente i metadata con i dati contabili come da SANP.
L’ente usa le API che il broker rende disponibili (possono essere anche quelle di GPD, ma di solito quelle del broker hanno un livello di astrazione superiore), il broker usa GPD per pubblicare le richieste dell’ente su GPD e crea un avviso di pagamento.
L’utente usa uno strumento di pagamento (dell’ente, del broker, di pagoPA o di un psp) che usa l’API di checkout pe richiedere (il Wisp è ormai stato dichiarato deprecato): checkout alla fine usa la paGetPayment di paForNode (V2 se voglio i metadata del singolo transfer) per attivare il pagamento (modello unico di pagamento).
Se il pagamento va a buon fine il nodo invia una ricevuta con la paSendRT (V2).
Il broker di riconciliazione riceve tutte le ricevute di competenza dell’ente, accede ai flussi di competenza e ai giornali di cassa dell’ente (recuperati di solito da un gateway SIOPE+, archiviati localmente ed esposti via API, almeno per quanto riguarda i bonifici pagoPA) e può eseguire la rendicontazione e la riconciliazione. Questa fase è indipendente dall’uso di GPD, che potrebbe essere usato anche solo per alcune tipologie di pagamento.
Questo è vero solo se tutti usano GPD. Però nella ripartizione di responsabilità fra PagoPA e broker sta prendendo corpo la visione in cui la parte di pagamento e di area personale del cittadino viene tendenzialmente delegata a PagoPA con tool più evoluti di quelli attuali. Essendo le funzionalità comunque esposte via API, alcune funzionalità o anche tutte possono essere integrate anche su portali dell’ente, ma forse non ha molto senso conviene eventualmente mettere un link al portale pagoPA.
Ai comuni servirebbero indicazioni perentorie (non dipende da voi, sia chiaro). Fin qui la posizione di PagoPA spa quando si tratta di questioni che riguardano riconciliazione, contabilità, avvio di pagamenti, aree personali ecc. è stata: “è fuori dal nostro perimetro”. Speriamo che prima o poi qualcuno esca dal perimetro.
Un punto fermo sembra che le paGetPayment di paForNode debba essere usata nella versione 2 da tutti e contenere i dati contabili. Se non si fa così riconciliazione e rendicontazione non hanno alcuna possibilità di essere condotte in modo non dico standard ma almeno uniforme.
La realtà dei fatti è che sono scelte su cui un singolo ente non ha capacità di intervento, non c’è che confidare nelle scelte dei propri PT e incrociare le dita che siano compatibili fra loro.
Chiedo perdono… allora…
Su GPD la posizione la creo con Operazioni disponibili | SANP 3.7.0 | SANP . Qui non vedo i “metadata” ne’ altro tag deputato a ospitare capitolo e accertamento:
I “metadata” da usare secondo SANP per la riconciliazione contabile (Riconciliazione contabile | SANP 3.7.0 | SANP - che io chiamavo rendicontazione ma basta capirsi) sono nella paGetPaymentV2.
Se si usa la GPD, si è detto, la paGetPaymentV2 la produce GPD con i dati a disposizione. Da dove può prenderli?
Sì certo è una scelta che deve fare ogni singolo broker, e non è una decisione facile da prendere, dopo tutti gli investimenti già fatti, anche perchè, come detto, l’attualizzazione degli importi al momento del pagamento non è possibile.
Ma la mia impressione è che primo o poi deprecheranno l’API sincrona, in realtà in una call di qualche mese fa gli è anche sfuggita l’affermazione. I tempi però potrebbero essere abbastanza lunghi da giustificare un ulteriore investimento su API sincrona. Se poi la piattaforma unitaria di cui si parla avrà un seguito e verrà definita un’API lato EC standard, GPD potrebbe diventare un mero dettaglio interno di implementazione.
Beh. giusto due giorni fa un primario PT mi ha detto, in call, che i 5 PT più grandi hanno già concordato API standard lato EC.
Un collega mi ha confermato che lo stesso dice un altro PT degli altri 5.
Ahinoi, per gli standard non vale “due gusti is meglio che uan”…
Non so a quali aggregazioni di PT ti riferisci. Sono a conoscenza di un’iniziativa degli IT regionali, che insieme a PagoPA intendono arrivare alla definizione di una piattaforma unitaria, che verrà sicuramente realizzata dal gruppo SPAC (myPay) a cui fanno capo diverse regioni ed altri enti.
Lunedì e martedì prossimi ci sarà un convegno su tale tema a Venezia.
Può essere che PagoPA stia proponendo la stessa iniziativa anche ai maggiori PT, e sarebbe auspicabile.
Non so, se @nardil ha notizie in proposito e può/vuole condividerle sarebbe interessante.
Noi come IT Regione FVG, valuteremo se confluire in SPAC o aderire alle specifiche di piattaforma unitaria in funzione dell’effort richiesto per adeguare la nostra infrastruttura e i diversi gestionali già integrati via API.
Sul tema GPD, segnalo che proprio domani venerdì 12 Aprile 2024 alle ore 11:00, sul Developer Portal di PagoPA, si terrà un webinar “Esplorando pagoPA: Gestione Posizioni Debitorie” tenuto dal team di PagoPA. Durante il webinar di solito è possibile porre dei quesiti al team.
Continuo a condividere qualche dubbio, per capire dove spendere i soldi. Purtroppo non essendo uno sviluppatore, ma solo uno che fa acquisti di cose sviluppate da altri, non mi azzardo a chiedere nei canali ufficiali.
Assumiamo che la scelta fra GPD e ACA di fatto è a discrezione del PT. Un EC non può fare altro che scegliere prodotti e servizi che gli consentano, da un lato, di fare ciò che gli serve adesso (tipo: riscuotere la TARI con pagoPA multibeneficiario e rendicontarla, per esempio) e, dall’altro, di non dover rifare tutto da principio fra pochi mesi, quando i PT avranno scelto cosa fare.
In uno scenario prossimo venturo in cui un EC avrà N partner e un misto di posizione gestite su GPD e sugli APA dei PT replicati in ACA, la rendicontazione contabile potrebbe diventare un guazzabuglio di integrazioni della contabilità con gli N partner. Quindi:
possiamo pensare che davvero prenda piede come “standard” la rendicontazione basata sul solo incrocio di Flussi di riversamento e RT? In tal caso basterebbe inviare RT e Flussi verso la stazione broadcast e dare accesso al programma di contabilità: nome e cf del debitore, capitolo e accertamento (dove possibile) e una causale significativa dovrebbero bastare;
tuttavia, occorre anche minimizzare il trattamento di dati personali, in fin dei conti al PSP non serve sapere il nome del bambino che mangia alla mensa (o l’ambulatorio in cui qualcuno ha fatto una visita): visto che la RT è comunque mediata dal nodo, io ho provato a seguire (qui) la sorte dei dati che si inviano con le varie primitive quando si scatena il pagamento ma non sono riuscito a capire cosa va a finire dove (cosa va su avviso analogico, cosa su causale mostrata su checkout, cosa sul servizio del PSP, cosa nel suo DB ecc., cosa sulle varie remittanceInformation)…
Pagamenti pull: quando? Questo consentirà di superare il concetto di “area personale” del sito comunale (o della p.a.) in genere in cui mostrare tutte le posizioni debitorie del cittadino autenticato? Di nuovo, con N PT e un misto di ACA e APA e GPD, comporre quella paginetta potrebbe richiedere lo sviluppo e la manutenzione di un tot di collegamenti…
Ci sarà mai un front-end via web per vedere le posizioni dell’EC presenti su GPD? Questo consentirebbe di collegare direttamente software “facili” alla GPD senza impelagarsi negli standard proprietari dei PT (e quindi pensare di poter acquistare un software con funzionalità pagoPA di default, senza necessità di personalizzazioni)
