search

pagopa / pagopa-api

Tutti gli schemi XSD e WSDL che seguono release diverse dalle SANP
22 stars 15 forks source link

Multibeneficiario, rendicontazione e codice 9 #214

Closed emis44 closed 1 year ago

emis44 commented 3 years ago

Se con il nuovo modello 3 si potranno verificare ancora casi di pagamenti in assenza di RPT/Receipt, non avremmo Receipt per fare il match con lo IUR del flusso ed essere certi che si tratti proprio di quello IUV.

Mi spiego, per un flusso di uno IUV dell'ente secondario Città Metropolitana di Firenze, potremmo trovare cercando per IUV:

Tari Firenze - Tefa Città Metro. Fi. (cod.segreg. 00 su stazione1) Tari Bagno a Ripoli - Tefa Città Metro Fi. (cod. segreg. 00 su stazione 2)

Potremmo, così, trovare più pagamenti di enti diversi. Se però tali pagamenti sono multibeneficiari con il medesimo ente secondario, potremmo non capire di quale iuv si tratta.

Come possiamo fare per evitare tali casistiche? Occorre evitare di dare lo stesso codice segregazione a servizi con gli stessi enti secondari su stazioni diverse?

Un saluto e grazie per l'assistenza

ghost commented 3 years ago

Ciao, perdonami ma penso di non aver capito a fondo la domanda, provo però a risolvere alcuni dubbi.

Definendo:

Il numero avviso (che contiene lo IUV) per un pagamento “nuovo modello 3” resta unico, ed è definito e gestito dal solo ente primario. Non esistono nell'ambito della piattaforma pagoPA - in questo momento - regole di comunicazione tra ente primario ed ente secondario a monte dell'emissione dell'avviso di pagamento.

In mancanza di tale comunicazione è ovviamente possibile che l'ente secondario veda arrivare dei pagamenti in suo favore di cui non ha contezza. Tuttavia può riuscire a comprendere il tipo di tributo dal campo transferCategory ( https://github.com/pagopa/pagopa-api/blob/master/ec/paForNode.xsd#L352 ) che contiene la tassonomia del servizio.

Lascio aperta issue in caso di ulteriori commenti. Se invece ritieni la risposta esaustiva ti chiedo un feedback in modo da poterla chiudere.

Grazie

nardil commented 3 years ago

In mancanza di tale comunicazione è ovviamente possibile che l'ente secondario veda arrivare dei pagamenti in suo favore di cui non ha contezza. Tuttavia può riuscire a comprendere il tipo di tributo dal campo transferCategory ( https://github.com/pagopa/pagopa-api/blob/master/ec/paForNode.xsd#L352 ) che contiene la tassonomia del servizio.

Credo che @emis44 si preoccupasse proprio di questo: nell'eventualita' che il sistema pagoPA preveda la possibilita' che un pagamento possa essere gestito "senza RPT", l'Ente secondario potrebbe non avere nessuna informazione per capire chi ha pagato e cosa e' stato pagato.

La questione principale quindi mi sembra sia: il nuovo modello 3 consente ancora i pagamenti senza RPT?

E comunque: quali sono le policy di retry del Nodo per l'invio della receipt? Ci sono procedure di recuperto in caso di mancata consegna della receipt (ex nodoChiediCopiaRT)?

lucagargiulo commented 3 years ago

La questione principale quindi mi sembra sia: il nuovo modello 3 consente ancora i pagamenti senza RPT?

Da quello che ho capito, sì, quando il PSP non riesce a comunicare l'esito positivo del pagamento al nodo entro l'expirationTime del paymentToken, il PSP ha il dovere di ritentare la sendPaymentOutCome, ma se dopo l'expirationTime e prima della notifica dell'esito viene effettuato un altro pagamento, il pagamento verrà rendicontato con esito 9 nel flusso di rendicontazione, e il nodo non invierà nessuna ricevuta per il primo pagamento. In teoria dovrebbero essere casi molto rari, ma in tali casi l'ente troverà nel flusso un item con codice 9 che non lo potrà associare a nessuna receipt. Nel flusso peraltro non c'è nessuna informazione esplicita che mi dica chi ha effettuato il pagamento e da ente è stato gestito. Nel campo identificativoUnivocoRiscossione dovrebbe esserci il paymentToken: ricordo di aver letto nelle fasi iniziali delle nuove SANP che veniva generato a partire dal codice fiscale dell'ente creditore, ma nella documentazione ufficiale non se ne parla per cui credo che non ci si possa fare conto, quindi di fatto nel flusso posso trovare elementi che non posso associare a nessun debitore e a nessun ente creditore. Peraltro in questi casi la ricevuta non viene proprio nè generata nè inviata dal nodo, quindi anche un'eventuale primitiva di recupero ricevuta tipo nodoChiediCopiaRT sarebbe inutile.

ghost commented 2 years ago

Ciao.

La questione principale quindi mi sembra sia: il nuovo modello 3 consente ancora i pagamenti senza RPT?

Confermo quanto dice Luca. La casistica per cui possono avvenire pagamenti "senza RPT" (formalmente errato, direi più senza ricevuta) è se:

  1. il PSP va lungo con il recapito dell'esito
  2. il nodo sblocca
  3. avviene un altro pagamento nel frattempo
  4. Il PSP del punto 1 comunica l'esito

Sono casi, in teoria molto rari.

quali sono le policy di retry del Nodo per l'invio della receipt? Ci sono procedure di recupero in caso di mancata consegna della receipt (ex nodoChiediCopiaRT)

Non esiste, in questo momento, una simil nodoChiediCopiaRT. Razionale: a differenza delle RT che erano sempre dovute all'EC (sia + che -), ora le ricevute vengono consegnate solo in caso di pagamento effettuato.

Il nodo ha una policy di retry configurabile lato piattaforma. In caso di mancato recapito di una ricevuta prova x volte ogni y minuto.

Qualora fosse raggiunto il numero massimo di retry è possibile (in questo momento tramite assistenza) richiedere un reset del contatore.

Lascio aperto per eventuali controdomande.

nardil commented 2 years ago

Credo che sarebbe molto utile un servizio per la condivisione delle receipt non consegnate al termine della policy di retry in modo da consentirne l'acquisizione in autonomia, piuttosto che richiederlo (procedura fastidiosa sia per l'EC che per l'HelpDesk). Questo servizio potrebbe anche essere offline, ad esempio tramite mail al RT dell'intermediario/partner.

La cosa importante sarebbe concordare e formalizzare la modalità ed il formato di scambio in modo da poter realizzare gli opportuni servizi di acquisizione da Tavolo Operativo dell'intermediario/partner. Ad oggi le RT di rettifica ad esempio arrivano per mail nei formati più disparati (come testo, in un docx compresso con password, etc..) rendendone l'acquisizione più laboriosa del necessario.

emis44 commented 2 years ago

Salve, la problematica alla quale mi riferivo è proprio questa:

In mancanza di tale comunicazione è ovviamente possibile che l'ente secondario veda arrivare dei pagamenti in suo favore di cui non ha contezza

I pagamenti in assenza di RPT rendono difficile l'analisi dei flussi di rendicontazione dell'ente secondario, proprio per la difficoltà di capire la 'natura' dello IUV in mancanza di receipt.

Concordo con @nardil che potrebbe essere utile poter chiamare un metodo analogo all'attuale nodoChiediCopiaRT per avere un 'paracadute' da attivare in queste casistiche rare, ma possibili.

ghost commented 2 years ago

Rendo la issue enhancement per la richiesta di un servizio di recupero ricevute

lucagargiulo commented 2 years ago

Essenzialmente ci sono due situazioni distinte:

  1. il pagamento è andato a buon fine, pagoPA ha cercato di inviare più volte la ricevuta (positiva), ma non ci è riuscito: l'EC troverà nel flusso di rendicontazione un esito 0 (pagato); in questo caso la richiesta di copia della ricevuta andrà a buon fine e l'EC verrà in possesso della ricevuta
  2. il pagamento è andato a buon fine, ma il PSP non ha comunicato in tempo l'esito al nodo che nel frattempo ha concesso l'esecuzione di un'altra operazione di pagamento che può o meno aver avuto successo: l'ente troverà un esito 9 nel flusso di rendicontazione, ma pagoPA non ha mai nè generato nè tantomento cercato di inviare la ricevuta all'EC; in questo caso pagoPA cosa restituisce quando gli viene chiesta la copia?
ghost commented 2 years ago

Ciao Luca.

Premessa: Il problema del recapito delle ricevute e i codici nelle rendicontazioni è il medesimo per il vecchio modello. Mi spiego: L'invio degli esiti da parte del PSP (RT "a vecchio", outcome "a nuovo") è disaccoppiato dall'invio delle ricevute all'EC (RT "a vecchio", receipt "a nuovo"). Con questo voglio dire che la casistica

Il tema sta tutto nei mezzi che ha l'EC per recuperare la ricevuta e capisco che la mancanza di una "chiediCopia" limiti le possibiltà. Per questo motivo questa issue è diventata un enhancement: stiamo cercando di capire come aiutare gli Enti a recuperare in autonomia le ricevute.

Smarcato il tema del "trasporto della RT" rispondo ai 2 punti

Situazione 1

Per la situazione 1, potenzialmente noi potremmo anche riprovare per 2 giorni (48 volte a distanza di 1 ora come politica di retry). Se l'Ente Creditore risolve i problemi in questo intervallo di retry avrà la ricevuta.

Situazione 2

La situazione 2 è leggermente diversa ed è necessario distinguere Ente Creditore "a nuovo" e "a vecchio"

Con l'ente a vecchio:

  1. alla scadenza del token viene fatta una RT - (retrocompatibilità)
  2. alla ricezione di un pagamento a token scaduto il nodo controlla se c'è stato un pagamento (o è in corso una sessione di pagamento).
    • se esiste -> si dice al PSP che il pagamento è duplicato (PPT_PAGAMENTO_DUPLICATO)
    • se non esiste -> si accetta il pagamento (PPT_TOKEN_SCADUTO)
  3. nel caso in cui si accetta il pagamento il nodo procede con una nuova attivazione ( con ricezione RPT e generazione RT)

(Come si può ben capire il punto 3 è particolarmente critico, in quanto la successiva attivazione potrebbe non andare a buon fine per qualsiasi motivo. Per questo motivo in via "prudenziale" è stato chiesto ai PSP di fare codice 9 per i token scaduti.)

Con l'ente a nuovo:

  1. alla scadenza del token non viene fatta alcuna ricevuta
  2. alla ricezione di un pagamento a token scaduto il nodo controlla se c'è stato un pagamento (o è in corso una sessione di pagamento).
    • se esiste -> si dice al PSP che il pagamento è duplicato (PPT_PAGAMENTO_DUPLICATO)
    • se non esiste -> si accetta il pagamento (PPT_TOKEN_SCADUTO)
  3. nel caso in cui si accetta il pagamento il nodo procede con l'invio della ricevuta.

Per rispondere puntualmente alla tua domanda: Se il pagamento è a tutti gli effetti duplicato dipenderà fortemente dal PSP.

E' anche per questo motivo che stiamo capendo come agire sulla "chiediCopia" dato che a differenza del passato non è più "dovuta" all' Ente in determinati casi.

Ovviamente il nostro obiettivo è non avere token scaduti ( e pagamenti duplicati) e speriamo che sia un caso residuale. Abbiamo attivi dei monitoraggi sui comportamenti dei PSP.

nardil commented 2 years ago

Dico la mia dal punto di vista dell'EC.

Propendo per un servizio che consenta il recupero delle receipt, che sia a fronte di una perdita di dati o di un disservizio. E' sufficiente un servizio per acquisire le receiptId con opportuni filtri ed uno per l'acquisizione della receipt a fronte di una receiptId.

Per quanto riguarda l'eventualita' che il PSP non abbia consegnato una receipt ritengo sia una casistica che pagoPA debba gestire (anche offline) dal momento che l'EC ne ha necessita' per la riconciliazione. Al solito l'importante e' che queste modalita' siano definite formalmente e condivise per dar modo di gestirle opportunamente.

ghost commented 2 years ago

Ciao Lorenzo.

Per quanto riguarda il recupero delle receipt stiamo ragionando proprio su un eventuale servizio di questo tipo (lista + dettaglio)

Per quanto riguarda invece il secondo punto, è sempre obbligo per il PSP fornire esiti del pagamento (soprattutto se positivi). Per questo motivo abbiamo vari tavoli aperti con i PSP per gestire la questione. Aggiungo che per noi è importante non solo che l'esito venga fornito, ma anche che venga fornito all'interno dell'intervallo di durata del token.

andreapasuch commented 1 year ago

Buongiorno a tutti come è possibile vedere in https://docs.pagopa.it/sanp/ente-creditore/modalita-dintegrazione/integrazione-tramite-api-sincrone#recupero-receipt-per-enti-creditori è stato implementato un servizio di recupero delle receipt "smarrite" dall'EC.