link-it
SANP 3.7.0: Supporto Stand In
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)
@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:
Ok, dobbiamo quindi gestire il caso in cui la RPT non esista, creandone una al volo.
@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_RPT_SCONOSCIUTA) ?
- 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)?
e' il caso di prevedere una proprieta' per gestire questo nuovo comportamento (o continuare a restituire PAA_RPT_SCONOSCIUTA) ?
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.
@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 ?
@nardil
- Dopo l'aggiornamento alla versione 3.6.0 delle API SANP, si utiizzera' il campo
standIn==truedelle primitivepaSendRTReqepaSendRTV2Requestper capire quando si deve acquisire una RT ricreando la RPT non presente. - Nel caso in cui
standIn == null || standIn == falseGovPay deve garantire il supporto alla acquisizione delle ricevute che possono essere state pagate tramite APA: in questo caso infatti l'attivazione avviene all'interno delGPDpercio' non ci saranno RPT su GovPay.
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.
Intervento di gestione dei nuovi codici di esito per i pagamenti rendicontati:
- ESEGUITO_STANDIN(4)
- ESEGUITO_STANDIN_SENZA_RPT(8)
e' stato realizzado dopo l'aggiornamento degli schemi SANP 3.8.1 nel branch #753.