Future SANP 2.4.0 - Nuovo modello 3

Da quello che leggo sull’attuale versione della Monografia Processo di pagamento presso il PSP con Ente multi-beneficiario

I requisiti descritti nel presente documento saranno recepiti nelle nuova versione delle SANP (2.4.0), e disponibili in ambiente di test entro Marzo 2021.

L’adeguamento alle nuove interfacce, secondo SANP 2.4.0, di un PSP potrà avvenire senza particolari vincoli o modifiche della configurazione, purché avvenga entro il termine ultimo fissato al 01/05/2021.

ne deduco che

  • dati i tempi indicati a brevissimo usciranno le SANP 2.4.0 che deprecheranno le 2.3.0
  • verra’ introdotto il nuovo modello 3 lasciando comunque attivo l’attuale fino a fine anno 2021 (termine ultimo per l’adeguamento degli EC)
  • il nuovo modello 3 sarà in test entro marzo (non è specificata una data esatta)
  • i PSP devono obbligatoriamente implementare il nuovo modello 3 entro il primo maggio

e quindi propongo alcune mie osservazioni, vedendo le cose lato PSP

Retrocompatibilità
Qual’è il senso della frase “Le interfacce saranno retrocompatibili con quelle attuali (rif SANP 2.3.0)” ?
Ci sara’ un periodo di duality, da maggio fino a, immagino, fine anno in cui verranno usate le intefacce vecchie e nuove.
I dati saranno sempre quelli naturalmente, ma in formato diverso (niente piu’ strutture RPT ed RT). Sparisce il CCP creato dal PSP e in maniera simile lo sostituisce il token creato dallla PA. C’è la novità del timeout e dell’idempotenza.
Quindi non capisco in cosa consista questa retrocompatibilità.
Oppure, ma è un pensiero ardito, il Nodo si propone come adattatore tra le nuove e le vecchie interfacce. Cioè un PSP potrebbe da maggio usare per il modello 3 solo le nuove interfacce e il Nodo pensa ad adattarle alle vecchie nel colloquio con la PA.
Però la vedo molto dura, quantomeno per la sparizione dell’asincrona pspInviaRPT sostituita (finalmente) dalla response della activatePaymentNotice

Ex Aux Digit 4
La prima versione della monografia diceva:

Affinché un PSP possa, a fronte della presentazione di un Avviso di Pagamento, discriminare quale processo di pagamento attuare, gli avvisi di pagamento emessi dagli Enti che saranno identificati da un aux-digit pari a 4 (rif. SACI).

nella versione attuale l’aux digit 4 e’ sparito e credo che la sua funzionalità sia stata sostituita dal parametro version:

Per l’adeguamento alle nuove interfacce di un EC è necessaria una modifica della propria configurazione che deve avvenire entro il termine ultimo fissato al 31/12/2021, decorso tale termine le vecchie interfacce (secondo SANP 2.3.0) saranno dismesse dalla piattaforma pagoPA per tutti gli EC.
La modifica della configurazione è attuata tramite ulteriori funzioni della sezione stazione del PdA che consentono di gestire i seguenti ulteriori parametri:
version (n.n.n) - indica la versione delle interfacce esposte dalla stazione: deve corrispondere al parametro version indicato nei WSDL paForNode.wsdl.
broadcast (true/false) - il valore true caratterizza una stazione come adeguata a ricevere le RT in qualità di Ente beneficiario gestite da EC terzi (rif. UC-EC-040 nel presente documento).
I parametri in parola saranno assegnati alle stazioni attualmente esistenti con opportuno valori di default.

Come si dovrà quindi fare per determinare se un EC supporta le nuove interfacce o meno ? Questi dati saranno presenti nella lista PA e dovranno essere ricercati ogni volta che si inizia un pagamento modello 3 ?

Idempotenza verifica
Per la nuova primitiva verifyPaymentNotice e’ scritto che

In caso di timeout, la funzione può essere nuovamente invocata.

Vorrei la conferma che in ogni caso, cioè indipendentemente da timeout, la verifyPaymentNotice possa essere ripetutamente invocata.
Ma quello che più mi interessa è sapere cosa risponde la verifyPaymentNotice qualora la posizione sia già stata “attivata” da un altro PSP ma non ancora confermata come pagata da una sendPaymentOutcome positiva.
Io vorrei che fosse anche in questo caso idempotente e che poi l’attivazione fosse bloccata con un KO sulla activatePaymentNotice
O meglio, non esattamente idempotente, cioè è giusto che la verifica mostri sempre i dati più aggiornati della posizione, se potenziamente ancora pagabile. Ma non vorrei che, com’è ora, la verifica restituisca un errore se semplicemente e’ attivata (ma non ancora pagata) da un altro PSP.
Riformulo usando gli stati della richiesta di pagamento proposti: la verifica deve funzionare allo stesso modo sia che il pagamento sia in “valid” che in “paying” mentre tornerà un errore se è in “paid” o altro stato.
La logica è che sia molto improbabile che una posizione venga pagata contemporaneamente da due parti.

Infine: la verifica sarà obbligatoria o facoltativa ?

Pagamento rateale
Secondo la monografia

Un avviso di pagamento può essere associato a diverse richieste di pagamento (Service), per ognuna delle quali sarà disponibile al più una ricevuta di pagamento (ServiceReceipt).

e io ci vedo per esempio l’avviso analogico dove infatti si possono mettere più rate con eventualmente anche il pagamento in un’unica soluzione. Ed ogni rata però ha il suo proprio IUV come un’ulteriore IUV differente è attribuito all’eventuale unica soluzione.
Più avanti però si dice che

Un Avviso di pagamento è composto da :

  • un identificativo univoco per l’Ente Creditore (Numero Avviso)
  • un flag “pagamento rateale” che identifica se si tratta di una rata di un piano di pagamento e quindi informa che lo stesso avviso potrebbe essere stato utilizzato in passato.

Quindi vorrei capire cos’è quel “identificativo univoco per l’Ente Creditore (Numero Avviso)”. E’ per esempio l’unico Numero Avviso presente nel caso di singolo pagamento oppure quello dell’unica soluzione nel caso di pagamento rateale con questa opzione ?
Oppure è qualcosa di diverso, più simile ad un identificativo di carrello come per i pagamenti modello 1 ?

7 Mi Piace

Penso di aver letto ormai almeno una decina di volte la nuova monografia e ormai mi sono reso conto che rispetto al passato è cambiato tutto, non solo rispetto al vecchio modello ma anche rispetto alla prima versione della monografia.
La prima monografia è stata in consultazione per un mese, io personalmente non ho segnalato nulla a PagoPA perché le modifiche introdotte erano condivisibili e non costituivano cambiamenti particolarmente impattanti, introdotti invece dalla versione 2, su cui però non è stata aperta nessuna consultazione. Peraltro, a mio avviso, le consultazioni dovrebbe essere realmente pubbliche, nel senso che la discussione dovrebbe essere accessibile pubblicamente (al limite previa registrazione degli interessati) con la possibilità di discutere le varie proposte.
Di seguito evidenzio alcuni dei principali aspetti che meritano attenzione.
Terminologia: tutto in inglese, ma non è sempre una traduzione dei vecchi nomi in italiano, che comunque non vengono mantenuti neanche quando sarebbe stato possibile.
Colloquio fra i diversi attori: prima la gestione della comunicazione era separata dalla semantica del contenuto, venivano scambiati dati contenuti in messaggi tecnici (RPT, RT ecc) che venivano trasportati via SOAP ma risolti dai vari attori, adesso la semantica è inclusa nel messaggio SOAP stesso.
Quindi RPT ed RT non ci sono più nel modello 3, ma rimangono nel modello 1 per il momento e anche questo ha un impatto: ora i diversi attori si scambiano messaggi diversi in modo diverso a seconda di come un utente sceglie di pagare una posizione debitoria, è ancora possibile pagare la stessa posizione debitoria usando indifferentemente un modello o l’altro? Ad esempio per una posizione rateizzata, posso pagare una rata dal portale dell’ente creditore ed un’altra presso un PSP? Il pagamento multi-beneficiario funziona con il modello 1? A mio avviso no, servono nuove API per il modello 1, ma la possibilità per un soggetto di scegliere come pagare non era uno degli aspetti distintivi di pagoPA?
Pattern di comunicazione: prima era tendenzialmente asincrono, ora è sincrono, con diverso impatto sugli SLA da rispettare.
Gestione delle rate: prima pagoPA non sapeva della presenza di piani rateali, una rata era un pagamento pagoPA come gli altri e non era correlato alle altre rate o ad una posizione debitoria pagabile in un’unica soluzione o a rate a seconda delle scelte dell’utente. Era l’ente che a livello di singolo gestionale o di intermediario tecnologico si occupava della gestione delle rate.
Ora però sembra che ad un avviso (e quindi ad uno IUV) possano essere collegate tutte le rate, quindi ad uno IUV verrebbero associati più pagamenti. Per me questo è decisamente un breaking change con impatto sostanziale e con aspetti che servirà analizzare in modo accurato per capire se e come il tutto può funzionare.
Ruolo dello IUV: prima era l’elemento unificante che identificava un pagamento in tutto il suo ciclo di vita, ora forse rimane più qualcosa che identifica l’intera posizione debitoria nei confronti dell’utente. Se analizziamo in dettaglio il contenuto dei messaggi SOAP possiamo notare che lo IUV non viene usato per correlare la response della paGetPayment e la request della paSentRT o meglio, i due messaggi sono ora correlati internamente dal nodo: può farlo perchè ora tutti i messaggi sono sincroni, quindi non è più necessario sincronizzare la comunicazioni con un correlation-token specifico. Il token di correlazione vien invece spostato sulle singole voci di pagamento (idTransfer) perchè serve per gestire la riconciliazione delle singole voci di pagamento (disponibili presso attori diversi nel caso dei pagamenti multi-iban). Anche nel colloquio con i PSP pagoPA usa un payment-token e non lo IUV per correlare richiesta ed esito del pagamento oltre che per gestire richieste concorrenti.

Tutti questi cambiamenti modificano sostanzialmente la gestione del pagamento con un impatto che andrà attentamente analizzato sotto diversi aspetti.
Purtroppo la monografia non è abbastanza dettagliata per chiarire tutti i dubbi e gli asset informatici disponibili che descrivono la nuova API (wsdl e xsd) forniscono dettagli ulteriori, ma lasciano spazio ad interpretazioni non essendo documentati in modo puntuale.
Visti i tempi previsti per portare in produzione il nuovo modello l’esigenza di disporre di informazioni tecniche precise è abbastanza pressante. L’auspicio è che le nuove SANP 2.4 chiariscano tutti i dubbi, soprattutto che siano molto chiari gli scenari d’uso da supportare visto che in passato AGID ha spesso introdotto nelle specifiche funzionalità che non sono mai state realizzate (gestione delle revoche e degli avvisi telematici, ma anche pagamenti modello 3 con più voci non hanno mai visto la luce).
Mi riprometto di approfondire su questo post i vari aspetti man mano che riesco ad ottenere una visione più chiara sui singoli punti, e ringrazio fin d’ora chiunque possa fornire il suo contributo in tal senso.

3 Mi Piace

Concordo con le tue perplessità, si spera che in sede di specifiche tecniche si possa chiarire i punti oscuri e magari cogliere l’occasione per semplificare anche il modello di avviso PagoPa (togliendo p.es. la sezione del bollettino postale, e rendendolo più leggibile). Non ho mai capito il perché dell’esistenza stessa della differenza tra il modello 1 e il modello 3, quando si sarebbe potuto rendere trasparente all’utente il tutto: il fatto che i due modelli non solo non vengano riallineati ma si differenzino ulteriormente nel loro substrato tecnico mi preoccupa, come mi lascia perplessa la coesistenza per così tanto tempo di due SANP diverse e il fatto che lo IUV perda la sua centralità e reale univocità. Mi auguro che lo scenario applicativo non peggiori…

1 Mi Piace

Ho iniziato a postare un pò di RFC su GitHub, come consigliato nella monografia, e qualche risposta ha iniziato ad arrivare. Appena trovo un pò di tempo cerco di riassumere per argomenti. Per chi fosse interessato questo è il link [https://github.com/pagopa/pagopa-api/issues]

3 Mi Piace

Interessante.
Mentre leggevo (poi leggero’ anche l’ultima monografia, promesso) mi chiedevo quanti investimenti fatti saranno da rifare.
Se per esempio, se ho capito bene, spariscono RPT e RT come oggetti, non solo viene meno la documentazione accurata, trasferibile e opponibile del “ciclo di vita” del pagamento (che aveva gia’ avuto un duro colpo quando la firma di questi oggetti XML e’ stata deprecata) , ma viene meno anche la possibilità di usare le RT a fini rendicontativi. Quanto meno occorre rivedere eventuali meccanismi di cooperazione fra componenti del sistema informativo locale, solitamente implementati a caro prezzo.
Lo stesso per i pagamenti rateizzabili, fin qui gestiti con stratagemmi ideati a livello di singolo EC (o fornitore di software dell’EC).
Se poi si esaspera ancora di piu’ la per me inspiegabile dicotomia fra pagamenti attivati lato EC (sito) e lato PSP (avviso di pagamento) viene meno la versatilità del sistema.

Mi chiedo se valga la pena mettersi di impegno per adeguarsi a un sistema in piena evoluzione e evidentemente ancora poco stabile, nonostante le scadenza perentorie che tanto poi vengono sistematicamente prorogate.

2 Mi Piace

Io credo che essendo il sistema gia’ in piedi si debba anche per forza seguirlo e sostenerlo.
Oggi ho visto che c’e’ stata una sostanziosa commit sul master delle specifiche.
Una cosa su cui sono incappato e’ il capitolo con le potenzialita’ che dovrebbe permettere la ex vituperata nodoVerificaRPT, ora paaVerifyPaymentNotice. Gestione delle rate, opzioni multiple, pignoramenti / acconti.
Se si vogliono implementare tutte queste cose la mia impressione e’ che la prossima sara’ la versione 3.0.0. e non la 2.4.0.
Aspetto a fare le mie domande / RFC perche’ c’e’ veramente molta carne al fuoco e vorrei che si assestino di piu’ le cose. Specialmente aspetto di vedere WSDL/XSD piu’ maturi perche’ al momento quelli che posso vedere sul branch develop mi sembrano ancora abbozzati.

2 Mi Piace

Casomai fosse sfuggito sono state promosse a Release Candidate le 2.4.0

2 Mi Piace

Io stavo guardando queste https://github.com/pagopa/pagopa-specifichepagamenti-docs/tree/nuovo-mod-3 che riportano un 3.0.0-RC… I titoli sembrano gli stessi

Eh, e’ un po’ come “aguzzate la vista” sulla Settimana Enigmistica :slight_smile: Sul branch nuovo-mod-3 sono dette 3.0.0-RC mentre sul branch master sono 2.4.0-RC. Il contenuto sembra lo stesso.
Probabilmente, viste quante modifiche entrano nella nuova versione avranno avuto il dubbio che fosse una major version e non una minor.
Leggendo sulla Codifica alle versioni credo che questa non sia una minor

L’incremento della versione Minor avviene anche nel caso in cui venga introdotta (o segnata come deprecata) una nuova funzionalità, purché non critica e/o opzionale.

e direi che il nuovo modello 3 e’ critico e obbligatorio e si parla esplicitamente del modello 3 attuale come deprecato e a termine per fine anno.
Personalmente l’importante e’ che escano al piu’ presto con specifiche logicamente solide, WSDL/XSD che permettano di implementarle ed ambiente e piano di test pronti.

Mettendo insieme le varie fonti di documentazione il quadro che emerge è di forte rottura rispetto alle specifiche attuali sotto vari aspetti, con alcuni risvolti positivi e altri meno
Sicuramente si tratta di un breaking change: è un’API diversa, (e richiede una major version per la documentazione), ma proprio per questo fatto non capisco la scelta di rimanere ancorati al passato per la gestione del modello 1, richiedendo una gestione molto diversa a seconda della modalità di pagamento scelta dal soggetto pagante che pone non pochi problemi.
Una dei punti di forza di pagoPA era quello di consentire le stesse funzionalità indipendentemente dal metodo di pagamento scelto anche grazie all’uso di RPT ed RT come messaggi scambiati in entrambi i workflow di pagamento.
La scelta di portare il contenuto veicolato da RPT e RT direttamente nel messaggio mi sembra corretta e consente la verifica sintattica e semantica direttamente a livello di infrastruttura di comunicazione, però ad esempio la nuova API non consente di trasportare il pagamento del bollo, che quindi può essere richiesto solo online, da un portale del creditore.
Altro esempio: la soluzione proposta per pagare in modello 1 una posizione debitoria multi-ente prevede la generazione di un carrello di RPT (e quindi di un carrello di commissioni e un carrello di RT) un comportamento diverso rispetto al nuovo modello 3 dove ho un unico pagamento (e una commissione e una ricevuta).
Anche il pagamento delle rate pone dei problemi perchè nel modello precedente non c’era il concetto di rata in pagoPA, una rata era un pagamento (con il suo IUV, univoco per un ente )e non c’è modo di dire che con una certa RPT (o con un certo carrello di RPT) sto pagando l’ultima rata.
A questo punto sarebbe meglio fare il salto completo e mettere in campo una nodoSendPayment dove nella request si specifica il dettaglio del pagamento come si fa nella response della paGetPayment (aggiungendo in entrambe un posticino per il bollo) e ricevendo la ricevuta sempre con la paSendRT.
In ogni caso la documentazione mi sembra in versione pre-alfa, RC per me significa già usabile per produrre un sistema pronto per la produzione con le feature già note e sperimentare le nuove potenzialità più innovative, che non sono poche, come le opzioni di pagamento.
Ho forti dubbi che per il 1 maggio i PSP possano essere in grado di portare in produzione il nuovo modello.

1 Mi Piace

Ho letto con interesse le vostre osservazioni e condivido le perplessità specialmente sui tempi di implementazione. Aggiungo una riflessione relativa allo IUV e alla segregazione che sembrano spariti.

Le nuove specifiche per numero avviso con aux digit 3 prevedono il seguente formato.

3 < station-id > (2n) < position-local-id >(13n) < check-digit >(2n)

station-id: identificativo della stazione all’interno della quale risiede la posizione debitoria.
position-local-id: identificativo univoco della posizione debitoria all’interno della stazione.
check-digit: codice di controllo del numero avviso.

al posto di

3<codice segregazione (2n)><IUVbase (13n)><IUV check digit (2n)> (NAV.3)

La segregazione è sostituita dall’identificativo della stazione. Lo IUV è diventato position-local-id. Ritengo sarebbe più semplice mantenere dizioni ormai entrate nel gergo di chi si occupa del sistema.

4 Mi Piace

Personalmente trovo a dir poco assurdo modificare in peggio layout, strutture dati e modelli di conunicazione, specialmente ora che si sta assistendo ad un’adozione più consistente. Se modifica dovesse essere fatta avrebbe dovuto puntare a semplificazione, unificazione, standardizzazione e maggiore chiarezza, non maggiore confusione e derive… :cry:

1 Mi Piace

sara’ la lotteria dei tag xml…

L’essere passati a una terminologia completamente in inglese per termini che spesso hanno senso solo nel nostro ambito italiano e che, specialmente, sono gia’ in uso da anni, secondo me non ha senso.
Non ha nessun valore aggiunto e costringera’ alla convivenza con i termini in italiano usati finora e, naturalmente, presenti in tutto il codice sorgente e le basi dati di tutti gli attori: PSP, EC e naturalmente il Nodo stesso.
Mi era sfuggito che pure lo IUV fosse stato trasformato nel position-local-id (PLI ?) in alcuni documenti. Naturalmente in altre parti, per esempio WSDL/XSD, ancora si chiama IUV. E naturalmente nell’avviso di pagamento analogico i termini rimarranno in italiano.

3 Mi Piace

c’mon baby, english is the new black! a wonderful mess is coming…

Voglio sperare che si tratti solo di termini usati temporaneamente (si sa, se sei un programmatore che non usa l’inglese per il 99,999% di quel che fa, sei un buono a nulla per default) che poi torneranno in italiano come è doveroso che sia.

2 Mi Piace

mah… questi sono giovani e orientati al risultato, non hanno mica tempo di rileggere, rivedere, limare, correggere…

Non credo, in marzo dovrebbero andare in test, stanno rilasciando la documentazione usando i termini delle specifiche, l’importante è che sia ben documentata la semantica

Ma andra’ in produzione anche il “riposizionamento semantico” di IUV e numero avviso di cui leggo in una preoccupante risposta di Gammaldi ? :confused:

Sono tante le cose che preoccupano, su come procedere al disaccoppiamento fra avviso e iuv ci sono varie possibilità, e credo nessuna indolore per gli intermediari.
Leggi anche questa: https://github.com/pagopa/pagopa-specifichepagamenti-docs/blob/master/sezione3-specifiche-tecniche/3_01_04_multi_beneficiario.md , alla fine introdurre il modello 3 multi-ente sperando di mantenere il vecchio workflow per il modello 1 non risulta possibile, ci sono pesanti ripercussioni anche sul modello 1, i due workflow funzionano con filosofie diverse e per far funzionare lo scenario multi-ente si introducono cose come il carrello multi-ente per pagare parti di pagamento destinate ad enti diversi, che può contenere solo parti della stessa posizione debitoria, quindi è una cosa diversa dal vecchio carrello di posizioni debitorie (che peraltro rimane in piedi con le sue regole).
Però il nuovo carrello non consente il pagamento del bollo! Quindi i pagamenti dei servizi online, (in primis SUAP) che richiedono il pagamento del bollo sull’istanza e a volte su un documento/atto restituito dal servizio non sono possibili. O meglio si deve far pagare il bollo a parte, con aumento delle commissioni e delle difficoltà di interazione.
E poi vorrei capire cosa succede in presenza di rate.

1 Mi Piace