SANP 3.7.0: Supporto Stand In

[nardil]

Necessità:

La roadmap pagoPA introduce la funzionalità "Stand In" che consiste nell'utilizzare le informazioni dell'ACA per consentire ai PSP di procedere al pagamento degli Avvisi anche in caso di indisponibilità dei servizi dell'Ente.

Questa funzione introduce i seguenti use case:

• Si riceva una Receipt senza che sia stata effettuata alcuna Verifica o Attivazione
• L'importo delle Receipt non sia allineato a quanto effettivamente dovuto

Soluzione:

Replicare lo scenario nella testsuite e verificare che siano gestiti correttamente.

Analizzare se siano necessarie modifiche alle API di integrazione per esporre tutte le informazioni utili all'ente per gestire il caso di pagamento parziale (o comunque difforme dal dovuto)

[pintorig]

@nardil sono stati aggiunti i due test richiesti, ecco i risultati:

• Si riceva una Receipt senza che sia stata effettuata alcuna Verifica o Attivazione:

L'acquisizione termina con errore:

Ricevuta richiesta paSendRT [12345678901][340781064222459]
Acquisizione RT Dominio[12345678901], IUV[340781064222459], ReceiptID [1697810642225] in corso
Rifiutata PaSendRT con Fault La RPT risulta sconosciuta.

• L'importo delle Receipt non sia allineato a quanto effettivamente dovuto:

La ricevuta viene correttamente acquisita, la pendenza viene spostata in stato ANOMALA:

[nardil]

Ok, dobbiamo quindi gestire il caso in cui la RPT non esista, creandone una al volo.

[pintorig]

@nardil alcune questioni prima di procedere con lo sviluppo:

• e' il caso di prevedere una proprieta' per gestire questo nuovo comportamento (o continuare a restituire _PAA_RPTSCONOSCIUTA) ?
• La vecchia paaInviaRT deve essere abilitata allo Stand-In?
• Il messaggio di richiesta viene ricostruito a partire dalla RT ricevuta, oppure lo lasciamo vuoto? In questo caso c'e' da rivedere i campi obbligatori della tabella RPT.
• Salviamo da qualche parte e come l'informazione che si tratta di una RT acquisita per una transazione iniziata al di fuori di GovPay (Es. ESEGUITO_SENZA_RPT)?

[nardil]

e' il caso di prevedere una proprieta' per gestire questo nuovo comportamento (o continuare a restituire _PAA_RPTSCONOSCIUTA) ?

No: la RT deve essere acquisita in ogni caso

La vecchia paaInviaRT deve essere abilitata allo Stand-In?

No: e' usata solo per il modello 1 (il modello 3 v1 e' in dismissione) ed in quel caso e' impossibile che la RPT non esista in sistema.

Il messaggio di richiesta viene ricostruito a partire dalla RT ricevuta, oppure lo lasciamo vuoto? In questo caso c'e' da rivedere i campi obbligatori della tabella RPT.

Il messaggio di richiesta (xml_rpt) dovrebbe restare vuoto. Gli altri campi, se obbligatrori dovremmo ricostruirli.

Salviamo da qualche parte e come l'informazione che si tratta di una RT acquisita per una transazione iniziata al di fuori di GovPay (Es. ESEGUITO_SENZA_RPT)?

No. Non mi sembra ci siano scenari che lo richiedono, ma e' comunque l'unico casi in cui la RPT sia vuota, pertanto e' un'informazione eventualmente deducibile.

[pintorig]

@nardil

Una volta rilassato il vincolo di obbligatorieta' del messaggio di richiesta ecco il mapping da effettuare per ricostruire i campi obbligatori della tabella RPT a partire dalla Receipt:

• codDominio <- receipt.fiscalCode
• iuv <- receipt.creditorReferenceId
• ccp <- receipt.receiptID
• codStazione <- dominio.codStazione
• dataMsgRichiesta <- dataCorrente
• dataUltimoAggiornamento <- dataCorrente
• codMsgRichiesta <- receipt.receiptID
• versione <- decisa in base all'API chiamata
• stato <- RPT_ACCETTATA_NODO
• idversamento <- id della pendenza ricercata per la coppia codDominio/IUV

Per quanto riguarda il salvataggio e' meglio inserire la RPT finta e poi fare come ora l'aggiornamento oppure inserire tutte le informazioni in una sola volta cosi che se va male qualche controllo non rimangano RPT finte nel db?

Attualmente il controllo di presenza di una RPT viene fatto utilizzando come filtro di ricerca (codDominio,IUV,versioneRPT) come gestiamo il possibile disallineamento tra versioni discusso nella issue #625 ?

[pintorig]

@nardil

• Dopo l'aggiornamento alla versione 3.6.0 delle API SANP, si utiizzera' il campo standIn==true delle primitive paSendRTReq e paSendRTV2Request per capire quando si deve acquisire una RT ricreando la RPT non presente.
• Nel caso in cui standIn == null || standIn == false GovPay deve garantire il supporto alla acquisizione delle ricevute che possono essere state pagate tramite APA: in questo caso infatti l'attivazione avviene all'interno del GPD percio' non ci saranno RPT su GovPay.

[nardil]

Verificare la gestione dei pagamenti rendicontati con codice esito 4: https://docs.pagopa.it/sanp/specifiche-attuative-del-nodo-dei-pagamenti-spc/funzionamento-generale/stand-in#rendicontazione-dei-pagamenti-gestiti-in-stand-in

I pagamenti che vengono elaborati con successo mediante il processo di Stand In sono successivamente riversati sull'IBAN dell'EC precedentemente configurato, inoltre, questi pagamenti sono riportati nel flusso di rendicontazione con il codice esito 4.