menu di navigazione del network

RPT Elementi_Delucidazioni


(Michele) #1

Buonasera,
avrei necessità di chiarimenti in merito ai seguenti campi della Ricevuta di Pagamento Telematica - RPT:

  1. versioneOggetto: in quanto ‘versione che identifica l’oggetto scambiato’, è un valore che l’EC può impostare liberamente? O si riferisce alla versione della RPT attuale, che infuturo potrebbe essere modificata e valida in una nuova versione?

  2. tipoVersamento: essendo stata deprecata la primitiva di interrogazione del ‘Catalogo Dati informativi’ del Nodo ed essendo previsti sei valori del parametro che prevedono dunque una scelta, è da prevedere, in fase di pagamento del carrello, una scelta tra queste sei opzioni da parte dell’utente per le modalità di pagamento prima della redirezione sul WISP? In quanto altrimenti come si può impostare quel valore (obbligatorio) prima di inviare al nodo il carrello?

  3. datiSpecificiRiscossione: si possono avere chiarimenti/esempi su cosa rappresenta dettagliatamente questo dato?

  4. identificativoMessaggioRichiesta: è corretto interpretare questa informazione come l’identificativo delola transazione di invio al nodo?

Grazie mille per le risposte :slight_smile:


(Lorenzo Nardi) #2

Ciao Michele,

no, indica la versione della specifica utilizzata. il valore da inserire per la versione corrente e’ 6.2.0 e potrebbe cambiare in future revisioni.

Le specifiche indicano che il valore da inserire nella RPT universale per il tipoVersamento e’ BBT

spiacente, ma su questo non so aiutarti

Il modo piu’ corretto per identificare la transazione di pagamento e tutti i tracciati che la determinano (verifica, attiva, rpt, rt) e’ utilizzare la tupla idDominio, identificativoUnivocoVersamento e CodiceContestoPagamento, mentre il campo identificativoMessaggioRichiesta identifica la sola RPT.

Ciao,
Lorenzo


(Lorenzo Nardi) #3

Ripensando alla domanda credo di aver centrato per meta’ la risposta :slight_smile: . Il valore del campo identificativoMessaggioRichiesta viene determinato al momento della creazione dell’RPT. In caso di rispedizione della medesima RPT al Nodo, ad esempo a fronte di errori di rete, non credo sia opportuno il suo aggionamento. Credo quindi che possa essere un valido identificativo dell’RPT se opportunamente costruito, ma non della transazione di invio intesa come la sua comunicazione.


(Michele) #4

Ciao Lorenzo,
intanto grazie mille per le delucidazioni.
In merito al campo _identificativoMessaggioRichiesta_ dunque che valore si dovrebbe inserire? Va costruito liberamente dall’ente per identificare la RPT creata (ad esempio un id numerico crescente)? Oppure va creato ad hoc con un ‘algoritmo’ specifico?

Grazie ancora,
Michele


(Lorenzo Nardi) #5

Le specifiche non impongono una sintassi particolare quindi sei libero di valorizzarlo a tuo piacimento.


(Michele) #6

Grazie mille :slight_smile:


(Michele) #7

Vorrei aggiungere all’elenco anche un altro dato che non risulta chiaro:

  • codiceContestoPagamento : nella documentazione viene specificato che “Nel caso in cui il processo di pagamento sia attivato presso l’Ente Creditore, il dato
    _codiceContestoPagament_o è impostato dall’Ente Creditore stesso.
    Per tutte le tipologie di pagamenti che non prevedono la generazione di un avviso di pagamento
    si raccomanda di utilizzare il valore “n/a” (già indicato nelle versioni precedenti delle presenti
    specifiche).” . Pertanto per i pagamenti attivati presso l’EC si può scegliere liberamente la struttura con cui generare questo valore o ci sono delle linee consigliate da seguire?

(Lorenzo Nardi) #8

L’unica indicazione che mi risulta dalle specifiche e’ una nota a pie’ pagina che suggerisce l’uso di un GUID.

Questo renderebbe remota la possibilita’ di conflitti tra CCP generati tra PSP e EC per uno stesso IUV.


(Michele) #9

Ma il CCP va associato alla singola RPT o nel caso di un carrello di RPT è uguale per tutte le RPT pagate insieme?


(Lorenzo Nardi) #10

A tua discrezione. Basta sia sempre garantita l’univocita all’interno della coppia idDominio/IUV.