Open nardil opened 1 year ago
@nardil sono stati aggiunti i due test richiesti, ecco i risultati:
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.
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_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.
@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:
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
standIn==true
delle primitive paSendRTReq
e paSendRTV2Request
per capire quando si deve acquisire una RT ricreando la RPT non presente.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. 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.
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:
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)