[RFC] Notifica e redicontazione del pagamento di un avviso multi ente

[nardil]

Describe the request

Chiamiamo con EC1 l'ente che emette un avviso di pagamento multi-ente e con EC2 l'ente intestatario di uno dei conti di accredito di parte dell'importo di tale avviso:

• La nuova specifica introduce delle API SOAP dedicate al pagamento di avvisi pagoPA. Come si inseriscono queste nuove API nei confronti di quelle esistenti? In caso di affiancamento, come viene determinato quali saranno utilizzate?
• Nel paragrafo 2.1 e in UC-EC-040 viene indicato che la notifica di un pagamento multi-ente viene inviata ad ogni EC intestatario dei conti di accredito, quindi anche ad EC2. Nel caso EC2 sia pluri-intermediato, l'RT viene inviata a tutti gli intermediari?
• La monografia non fornisce indicazioni sulle policy di gestione di un eventuale fallimento nella notifica della RT. Questo aspetto risulta particolarmente importante nel caso del pagamento multi ente, poiché EC2 riceverebbe una rendicontazione con esito = 9, ma da pagoPA non avrebbe alcuna ulteriore informazione sull'oggetto del pagamento o dell'Ente che l'ha richiesto. E' possibile avere dei chiarimenti a riguardo?
• La rendicontazione relativa al riversamento dell'importo ad EC2 avrà come tupla identificativa IUV/idRiscossione/indiceDati. Lo IUV però è stato emesso da EC1, ma non sembra che questa informazione sia stata aggiunta alla rendicontazione. Come può l'intermediario riconoscere che lo IUV è stato emesso da un Ente terzo e di quale ente si tratta?

[gammam]

Ciao @nardil , procedo per punti:

1. Introdurremo due attributi all'interno delle stazioni degli enti : version, broadcast . version indicherà la versione della stazione ed in questo modo la piattaforma sarà in grado di contattare opportunamente l'ente a seguito delle chiamate effettuate dal PSP. l'attributo broadcast indicherà invece la stazione ricevente per pagamenti emessi da terzi. Non sarà esclusiva quindi ogni ente potrò avere anche più stazioni con tale parametro per tener conto di molteplici partner tecnologici. Aggiorneremo inizio settimana prossima la monografia per spiegare tale comportamento.
2. Premetto che non esistono più codici con esito=9. Al momento non sono state previste funzioni di recupero delle ricevute, se è necessario predisponiamo apposita funzione che possa recuperare tutte le ricevute di un avviso di pagamento.
3. L'intermediario dell'EC2 riceve sia il flusso di rendicontazione che la ricevuta. All'interno del flusso di rendicontazione lo IUR indicherà l'identificativo univoco della ricevuta. Pertanto ad ogni elemento del flusso è possibile associare la corrispondente ricevuta. Inoltre il campo indiceDatiSingoloPagamento conterrà l'identificativo della quota parte associata all'EC2. All'interno della ricevuta compaiono sia il CF dell'EC1 ( che ha gestito il pagamento ) sia il CF dell'EC2. Abbiamo aggiornato la monografia con un esempio di rendicontazione.

Grazie

[nardil]

Grazie @gammam per le precisazioni, alcuni ulteriori chiarimenti:

Introdurremo due attributi all'interno delle stazioni degli enti : version, broadcast

Se non ho capito male, version è una configurazione della stazione che indica quale API utilizzare per il pagamento degli avvisi, broadcast invece è una configurazione dell'Ente che indica a quali stazioni inoltrare le notifiche di pagamento. Corretto?

2. Premetto che non esistono più codici con esito=9.

questo è valido nello specifico caso dei pagamenti degli avvisi multi-ente oppure in generale? La specifica SACIV ancora prevede questo codice di esito.

L'intermediario dell'EC2 riceve sia il flusso di rendicontazione che la ricevuta.

Si, ma anche gli altri intermediari di EC2 ricevono questa rendicontazione e diventa difficile realizzare procedure di quadratura delle riconciliazioni non sapendo che l'EC emittente dello IUV è diverso dall'intestatario del flusso. Sarebbe possibile aggiungere ai dati della rendicontazione il campo opzionale indiceDatiSingoloPagamento.idDominio valorizzato il codice identificativo dell'EC emittente nel caso che questo sia diverso dall'intestatario del flusso?

[gammam]

Ciao @nardil

Stazioni

avranno due attributi version e broadcast . Abbiano aggiornato la monografia con questo dettaglio. Più avanti , quando sarà disponibile la funzione sul PDA sarà più chiaro.

Codici 9

Corretto, è ammesso ma di fatto sarà un'opzione che non sarà più utilizzata nel nuovo processo ( rimane valida per il processo attuale che rimarrà in piedi per i PSP per un tempo congruo per la loro migrazione )

flussi di rendicontazione.

Dato un pagamento multi-beneficiario, il PSP emettera un FdR per EC1 ed un FdR per EC2. EC2 riceve anche tutte le ricevute dei pagamenti emessi da EC1 che contengono se stesso come uno dei beneficiari.

Riprendo il tuo esempio , l'algoritmo che avevamo pensato è il seguente ( premessa che EC2 ha sia la ricevuta che il flusso di riversamento )

• legge il FdR ( quindi vuol dire che c'è stato un versamento all'interno dei propri IBAN )
• per ogni datiSingoloVersamento
  • può risalire alla ricevuta ottenuta per mezzo dell'IndiceUnivocoRiversamento
  • all'interno della ricevuta ottiene il CF dell'EC1, e tramite indiceDatiSingoloPagamento trova la quota parte della ricevuta a cui fa riferimento il versamento descritto all'interno del FdR.

ti torna?

[nardil]

Grazie @gammam per le ulteriori precisazioni. Il processo di riconciliazione non mi sembra presenti problemi, ma piuttosto nella realizzazione delle funzioni di controllo e gestione delle anomalie da parte degli intermediari che non hanno ricevuto la RT.

Faccio un esempio:

• EC2 e' intermediato dai partner X (segregazione 00, configurato in broadcast) e Y (segregazione 01)
• Viene pagato lo IUV 01.12345.12345.12345 emesso da EC1 che contiene un pagamento in favore di EC2.
• L'intermediario X viene notificato del pagamento secondo configurazione broadcast.
• L'intermediario Y riceve un FdR intestato a EC2 con la rendicontazione dello IUV 01.12345.67890.12345.

L'intermediario Y come fa a capire che quella rendicontazione non e' di un pagamento di sua gestione e quindi il fatto che non lo trovi nei propri archivi non e' un'anomalia da segnalare e gestire?

[gammam]

OK, ho colto il punto. Ma questo problema avviene già adesso ,corretto ? Quando Y legge il FdR non è in grado di sapere se quel pagamento è gestito da lui oppure no.

Questo non vuol dire che ci esonera nel trovare cmq una soluzione. :)

[nardil]

Quando Y legge il FdR non è in grado di sapere se quel pagamento è gestito da lui oppure no.

In realta' si, lo iuv per costruzione e' riconducibile all'intermediario che l'ha generato grazie al codice di segregazione (o alla sua assenza)

[gammam]

Ok, provo a ragionare su una possibile soluzione.

[lucagargiulo]

Una possibile soluzione potrebbe essere una funzionalità di richiesta delle ricevute relative ai pagamenti non disponibii direttamente ad un intermediario (non ricevute in modalità push). Supponiamo che E sia un Ente Creditore (che può essere anche Ente Beneficiario per certi tipi di pagamento) intermediato da X ed Y. Supponiamo pure che sia X che Y abbiamo una stazione configurata in Broadcast per cui entrambi ricevono tutte le ricevute in cui EC compare come beneficiario. Inoltre X riceverà le ricevute per cui EC ha ruolo di Ente Creditore (nel senso che ha emesso il pagamento) relative ai pagamenti gestiti tramite X ma non quelle relative a pagamenti gestiti tramite Y. Viceversa Y riceverà le ricevute dei pagamenti che sono passati per la sua infrastruttura ma non quelle dei pagamenti transitati per X. Per i pagamenti gestiti con “vecchio workflow” è disponibile una funzione di recupero delle RT (almeno per un certo periodo di tempo), con il “nuovo workflow” questa funzione non è stata (ancora) prevista. Se ci fosse, un qualsiasi intermediario/partner potrebbe essere configurato da un ente come intermediario di riconciliazione: avrebbe infatti a disposizione tutti i FdR di pertinenza dell’ente e tutte le ricevute referenziate nei FdR (le “sue” ricevute in modalità push, quelle degli “altri” prelevate in modalità pull). Non mi sembra infatti molto fattibile pensare di delegare la riconciliazione a più intermediari ognuno per la propria parte. Un ente riceve bonifici/FdR relativi a pagamenti effettuati tramite un qualsiasi intermediario, ma non ha modo di capire chi ha gestito quale pagamento e quindi non sa a chi chiedere le ricevute che non trova nella propria base dati.

[lucagargiulo]

Come alternativa si potrebbe anche considerare l'invio sulla stazione broadcast di un intermediario di tutte le ricevute di competenza di un ente intermediato, anche qualora i relativi pagamenti fossero stati gestiti da un intermediario diverso. In questo modo l'intermediario può disporre, all'interno del proprio repository, di tutte le ricevute di un ente, senza doverle chiedere esplicitamente al nodo pagoPA.

[gammam]

@lucagargiulo si, questo è già previsto. La ricevuta di pagamento verrà inviata :

1. All'EC che gestisce la posizione debitoria ( ovvero alla stazione alla quale è stata inviata la paGetPayment )
2. a tutte le stazioni broadcast intestate all'EC indicato come uno dei beneficiari ( ovvero di cui è presente la coppia CF/IBAN).

Al momento non abbiamo predisposto vincoli sul numero di stazioni broadcast . Quindi se un EC ha più intermediari potrà inserire una stazione broadcast per ogni suo intermediario, oppure potrebbe predisporre una stazione broacast dedicata dove far coinfluire tutte le ricevute e a cui hanno accesso tutti gli intermediari. Rimane un opzione dell'EC.

[lucagargiulo]

Rimangono però forse escluse le ricevute dei pagamenti dell'EC (Beneficiario in quanto Ente Creditore che gestisce il pagamento) non gestiti da un intermediario. Faccio un es: Servizio di mensa, servizio di pagamento del comune di Udine gestito da intermediario X. I soldi vanno all'EC comune di Udine. Udine ha un altro intermediario Y che gestisce altri pagamenti e a cui Udine ha delegato anche il compito di fare la riconciliazione. Y riceve le ricevute relative ai pagamenti per i servizi che gestisce per conto di Udine e se configura in broadcast una delle stazioni riceve anche le ricevute di tutti i pagamenti gestiti da enti diversi dal Comune di Udine nei quali però il comune risulta uno dei beneficiari. Ma su tale stazione vengono notificate le ricevute relative ai pagamenti del servizio mensa fatte dall'intermediario X? Se la risposta è sì allora Y riceve tutte le ricevute relative ai pagamenti incassati da Udine, altrimenti deve chiedere a pagoPA quelle relative ai pagamenti gestiti da X per il servizio mensa.

[lucagargiulo]

In effetti se un Ente Creditore è considerato comunque anche come Ente Beneficiario la risposta dovrebbe essere sì.

[gammam]

La risposta è NO, in quanto non possiamo sapere come intende organizzarsi l'ente. Dovrebbe essere cura dell'ente gestire i rapporti tra i due suoi intermediari se vuole che uno solo effettui la riconciliazione.

[emis44]

Buongiorno, scusate se riapro questo vecchio thread. Volevo chiedere conferma che nel nuovo modello 3 NON ci saranno mai rendicontazione anomale (il codice 9, in assenza di RPT ed RT). Se ciò è vero potremo rendicontare con sicurezza le Receipt tramite lo IUR. Altrimenti credo saremo in difficoltà nell'avere la certezza che lo IUV sia quello da noi intermediato.