[Funzionalità Broadcast] Non riceviamo nessuna RT

[argomauro]

Salve, vi scrivo perchè dopo aver configurato su alcuni enti la funzionalità di Broadcast sulla stazione non riceviamo nessuna RT proveniente da altri PT.
Il comportamento atteso era quello descritto in https://docs.pagopa.it/sanp/ente-creditore/modalita-dintegrazione/integrazione-tramite-api-asincrone#ricezione-sincrona-della-ricevuta dove la paSendRT viene inoltrata alle stazioni di tutti gli Enti Creditori configurate come broadcast.
Riporto il caso anomalo perchè invece nel caso della Provincia di Potenza che è interessato da pagamenti Multibeneficiario TARI-TEFA riceviamo correttamente le RT che provengono dagli altri EC della provincia, ovviamente dopo aver attivato il broadcast.
In virtù di questa "anomalia" di comportamento ho anche aperto un ticket all'assistenza e la risposta la riporto qui per completezza:

Vengo quindi a chiedere quale comportamento dobbiamo aspettarci dopo la configurazione del broadcast?

[nardil]

Il comportamento del servizio Broadcast descritto da @argomauro era già stato segnalato nella issue #890 . In tale issue, era stata confermata la correttezza delle specifiche SANP, chiarendo che un comportamento differente andrebbe segnalato come bug.

Quanto riportato invece dall'assistenza PagoPA risulta in conflitto con il chiarimento fornito da @aferracci nella issue e con la descrizione del servizio nelle SANP.

Colgo l'occasione per sottolineare l'importanza della funzionalità di broadcast come indicato nelle SANP: la paSendRT versione 2 viene inoltrata alle stazioni di tutti gli Enti Creditori configurate come broadcast. Questo comportamento è fondamentale per realizzare una piattaforma di riconciliazione efficiente, consentendo di ricevere le RT direttamente da pagoPA, senza la necessità di recuperarle singolarmente dai vari Partner/Intermediari.

[cristianosticca-pagopa]

Buongiorno @argomauro
cerco di fare chiarezza sul tema.
Il concetto di broadcast delle ricevute funziona diversamente a seconda della versione delle primitive utilizzate.

1. paSendRT v1 -> in questo caso la ricevuta viene inviata all'ente secondario nel caso di pagamenti in modalità multi-beneficiario. (risposta dell'assistenza)
2. paSendRT v2 -> in questo caso la ricevuta viene inviata a tutte le stazioni configurate in "Broadcast", indipendentemente da chi è intermediario della stazione

Quindi, nel caso specifico, se lei si trova nel caso 2 e non riceve le ricevute si tratta come correttamente indicato da @nardil di un malfunzionamento che va indagato. In tal caso le preghiamo di riaprire un ticket verso l'assistenza citando anche questa issue.

Grazie mille per la collaborazione.
Saluti

[nardil]

Ciao @cristianosticca-pagopa ,

grazie per il chiarimento.

Il comportamento descritto purtroppo limita molto i benefici del servizio broadcast dal momento che se la stazione di broadcast non riceve tutte le ricevute, la riconciliazione resta parziale e pertanto non risolve il problema.

Vi invitiamo a valutare la possibilita' di estendere la logica del servizio broadcast a tutte le Ricevute, anche a quelle v1.

[argomauro]

Grazie @cristianosticca-pagopa per la tua risposta ma collegandomi a quanto commentato da @nardil devo evidenziare i forti limiti di questa scelta progettuale.
Il tema della riconciliazione contabile è cruciale per le amministrazioni pubbliche: non disporre di strumenti efficaci per acquisire le evidenze dei pagamenti mette queste ultime in seria difficoltà. Considerando che le V1 non sono ancora deprecate e non esiste un piano di dismissione, la strategia attuale del broadcast risulta inefficace per la riconciliazione, poiché non consente di acquisire con certezza il 100% delle ricevute.

Questo implica che l'ente non può sapere con quale versione di API vengono gestiti i pagamenti e non ha la possibilità di imporre l'adozione di una versione specifica ai partner. Venendo meno l’utilità di questa funzionalità di broadcast, quale strategia possiamo adottare per consentire agli enti di raggiungere l'obiettivo della riconciliazione?

[cristianosticca-pagopa]

ciao @nardil @argomauro , cerco di chiarire in quanto forse sono stato poco chiaro o compreso non benissimo la necessità.
Indipendentemente dalle versioni delle primitive utilizzate (v1 o v2) laddove viene usata la paSendRT quest'ultima permette a tutti di ricevere le receipt.
Infatti, in caso di v1 l'ente primario riceve ovviamente la receipt che potrebbero ricevere anche gli enti secondari laddove questi ultimi siano associati alla stazione di broadcast. Nel caso di v2 come già detto non si intravedono criticità.
Se anche dopo questa precisazione non fosse chiaro potete indicarci proprio un esempio del caso d'uso problematico?
Grazie

[nardil]

Gli Enti Creditori fanno gestire le proprie riscossioni ad un certo numero di Intermediari/Partner, ciascuno dei quali detiene le ricevute dei pagamenti da lui gestiti. A questi si aggiungono i pagamenti effettuati da altri Enti di cui sono beneficiari.

Per procedere all'attivita' di riconciliazione, il software deputato deve recuperare:

• Il Giornale di Cassa
• I flussi di rendicontazione
• Le ricevute di pagamento

Il primo elemento e' fuori dal perimetro di pagoPA, mentre i Flussi di Rendicontazione sono gia' disponibili nella loro totalita' a tutte le stazioni associate all'ente.

Il problema sono le ricevute: attualmente chi effettua la riconciliazione deve recuperarle da ogni singolo intermediario nelle modalita' piu' disparate (servizi, csv via mail, zip di xml, ...) rendendo il procedimento complesso e costoso. La funzionalita' di broadcast potrebbe semplificare enormemente il processo, ma da quanto fin qua presentato il servizio consente di ricevere tutte le RT v2 e le RT v1 di cui l'ente e' beneficiario, ma non le RT v1 di cui l'ente e' creditore che ci risultano la maggior parte.

Quanto rappresentato risulta corretto?

[cristianosticca-pagopa]

Buongiorno,
La differenza è sulle broadcast dell'ente primario. L'ente primario riceve le ricevute di broadcast solo sulle broadcast V2 e solo per i pagamenti in cui la stazione principale è V2. Per gli enti secondari non ci sono differenze.

Ad esempio, nel caso di TARI/TEFA:
v2 -> ente primario se non è configurato sulla broadcast riceve la ricevuta una volta (quella della stazione principale)
v1 -> ente primario riceve la ricevuta solo sulla stazione principale, se anche fosse inserito in una stazione di broadcast non la riceverebbe
Gli enti secondari che sono inseriti nelle broadcast le ricevono sempre, sia v1 che v2.

Saluti

[nardil]

Grazie del chiarimento Cristiano, quindi lo scenario che abbiamo segnalato e' confermato e l'attuale logica del servizio Broadcast non consente ad un intermediario (o Ente aderente diretto) di effettuare una riconciliazione completa dei pagamenti se non mantenendo integrazione con gli altri intermediari per veicolare le informazioni necessarie.

Le attuali logiche del servizio broadcast possono essere riviste per superare le attuali limitazioni?

[andreapasuch]

Buongiorno Lorenzo
forse non stiamo comprendendo il tuo ragionamento, ma la tua conclusione non ci torna.
Nel caso di attivazione delle primitive V2 qualsiasi EC può gestire la riconciliazione completa su tutte le sue stazioni.

[nardil]

Ciao Andrea,

nella precedente risposta, @cristianosticca-pagopa ha indicato che:

v1 -> ente primario riceve la ricevuta solo sulla stazione principale, se anche fosse inserito in una stazione di broadcast non la riceverebbe

quindi un Intermediario con stazione in broadcast con api v2 non riceve le RT gestite da altri intermediari su API v1. Ho capito male?

[nardil]

Nel caso di attivazione delle primitive V2 qualsiasi EC può gestire la riconciliazione completa su tutte le sue stazioni.

Se si intende che "nel caso che tutti gli intermediari dell'EC utilizzino le V2 allora si ricevono tutte le RT", allora e' una condizione che nei fatti non si realizza ed e' difficilmente traguardabile: la versione delle primitive in uso sono a discrezione degli intermediari, non dell'EC, e la normativa non impone una versione specifica, quindi l'intermediario e' libero di utilizzare quella che ritiene piu' appropriata.

[andreapasuch]

Sicuramente il PT/IT può usare la versione che vuole, ma la trovo una cosa naturale che una versione più recente abbia funzionalità nuove e più adeguate alle richieste dei fruitori.
Una di queste richieste è stata la ricezione della receipt sulle stazioni di broadcast anche per l'EC "primario", che abbiamo inserito nelle V2, quindi è necessario adeguarsi per poterne fruire.

quindi un Intermediario con stazione in broadcast con api v2 non riceve le RT gestite da altri intermediari su API v1. Ho capito male?

Se l'intermediario/partner che gestisce il pagamento per l'EC è sulle V1, la receipt non sarà inviata alle stazioni di broadcast dell'EC "primario", verrà comunque inviata alle stazioni di broadcast degli EC "secondari".
Se l'intermediario/partner che gestisce il pagamento per l'EC è sulle V2, la receipt sarà inviata a tutte le stazioni di broadcast, comprese quelle dell'EC "primario".

[nardil]

Ciao Andrea,
la scelta della versione delle API da utilizzare spetta al PT/IT, che valuta in base alle proprie esigenze e ai servizi che intende offrire. Tuttavia, adottare una nuova versione delle API implica un investimento in termini di costi e risorse, motivo per cui tale adeguamento viene generalmente intrapreso solo se strettamente necessario.

Detto ciò, come evidenziato da @argomauro, attivando la funzionalità di broadcast si rileva che le RT notificate rappresentano solo una porzione del totale. La possibile soluzione al problema consisterebbe nel richiedere a tutti gli intermediari di adottare le nuove API ma e' una strada a dir poco ardua e sarebbe certamente piu' agevole se l'intervento fosse fatto centralmente.

[argomauro]

Ciao @andreapasuch,

mi ricollego a quanto detto da @nardil per sottolineare l'aspetto critico che evidenziava: la necessità di far adottare a tutti i PT di un ente la versione v2 dei servizi per permettere all'ente di ricevere tutte le RT.

Sebbene questa scelta sia comprensibile dal punto di vista dell'aggiornamento delle funzionalità e delle possibilità offerte dalle nuove API, non garantisce il raggiungimento dell'obiettivo primario dell'ente, ovvero la riconciliazione automatica delle entrate in contabilità. Ciò è dovuto al fatto che le dinamiche contrattuali tra i PT e gli enti spesso rendono complesso e poco immediato modificare soluzioni già implementate e operative.

La presenza di elementi discrezionali, come la possibilità di adottare o meno le specifiche v2, appare poco compatibile con l’esigenza primaria dell’ente, che non dispone di strumenti alternativi per garantire la riconciliazione automatica.

Per questo motivo, considero essenziale che sia sempre possibile ricevere le RT, nel caso in cui il broadcast sia attivo, o in alternativa attraverso altri metodi, API o strategie. Questa soluzione risulta cruciale in una fase in cui gli enti hanno effettuato ingenti investimenti in pagoPA, anche grazie ai finanziamenti del PNRR.

[andreapasuch]

Ciao @nardil e @argomauro
mi sembra che state partendo dal presupposto che l'estensione della funzionalità dell'invio della receipt a tutte le stazioni dell'EC "primario" alle V1 sia a costo 0 per tutti i PT/IT, in realtà non è così, abbiamo effettuato delle verifiche in passato.

L'effort dovrebbe essere dedicato al passaggio alle V2, che si porta dietro anche altri nuovi servizi (es. metadata nei transfer -> riconciliazione contabile).

[argomauro]

Ciao @andreapasuch grazie per il chiarimento e mi ricollego a quanto da te sostenuto per rimarcare, a mio avviso, la necessità di disporre di una soluzione che consenta ad un EC di riconciliare le proprie entrate indipendentemente dal passaggio di un suo PT alla versione aggiornata delle API (a meno che non ci sia un piano per deprecare e dismettere la v1).
Ho aperto questa Issue perchè lavoro costantemente con le PA locali e ti posso garantire che il processo di far convergere ,a volte anche più di tre PT con contratti e situazioni tra le più disparate, verso una nuova versione di API non è un processo ne semplice ,ne veloce. Per questo motivo auspicavo che, in mancanza dell'opportunità del Broadcast alle condizioni sopra discusse, si potesse immaginare o pensare anche ad altre soluzioni ma mi pare di capire che non ci sia margine di discussione visto la "prematura" chiusura della Issue da parte di @cristianosticca-pagopa.
Grazie comunque per la disponibilità e spero che la situazione da me rappresentata non diventi con il tempo un problema più esteso di quello che ho provato a rappresentare qui.