Utilizzo del codice IUV per Enti pluri-intermediati

Transcript

UTILIZZO DEL CODICE IUV PER ENTI
PLURI-INTERMEDIATI
Documento monografico
Versione 1.1 - giugno 2016
Utilizzo del codice IUV per enti pluri-intermediati
STATO DEL DOCUMENTO
revisione
1.0
1.1
data
15 aprile 2016
20 giugno 2016
note
Documento Base
Recepimento indicazioni degli stakeholders
Sintesi dei cambiamenti
lista dei principali cambiamenti rispetto la revisione precedente:
Modificato § 2.3.4 per utilizzo codice di segregazione da parte di soggetti mono intermediati o non intermediati.
Redazione del documento
Alberto Carletti
versione 1.1 - giugno 2016
Verifica del documento
Maria Pia Giovannini
Pag. 2 di 13
Indice dei contenuti
STATO DEL DOCUMENTO ................................................................................................ 2
DEFINIZIONI E ACRONIMI ................................................................................................. 4
INTRODUZIONE ................................................................................................................. 6
1.
IL CODICE IUV ........................................................................................................... 7
1.1
Regole di generazione del codice IUV ................................................................................................................. 7
2.
SEGREGAZIONE DEL CODICE IUV ......................................................................... 7
2.1
Attribuzione del Codice Segregazione................................................................................................................. 7
2.1.1
Erogatori di servizi centralizzati ..................................................................................................................... 8
2.1.2
Intermediari dell’Ente Creditore ..................................................................................................................... 8
2.2
Codice IUV nel caso del Modello 1 e 2 ................................................................................................................ 9
2.3
Numero avviso e codice IUV nel caso del Modello 3 .......................................................................................... 9
2.3.1
Valore 0 della componente <Aux Digit> ...................................................................................................... 10
2.3.2
2.3.3
2.3.4
2.4
Indirizzamento dell’Archivio dei Pagamenti in attesa..................................................................................... 11
2.5
Modifiche applicative ......................................................................................................................................... 12
Pag. 3 di 13
DEFINIZIONI E ACRONIMI
Definizione / Acronimo
AgID
Agenzia per l’Italia
Digitale
APA
Archivio dei Pagamenti
in Attesa
Descrizione
Ente istituito ai sensi del decreto legge n. 83 del 22 giugno 2012 convertito con legge
n. 134 del 7 agosto 2012 (già DigitPA).
Gestore del Nodo dei Pagamenti-SPC.
L’Archivio dei Pagamenti in Attesa è rappresentato dall’insieme di uno più archivi
fisici o logici, eventualmente ripartito secondo le necessità dell’Ente Creditore (cfr. §
7.4.1 delle SANP).
Codice IUV
Sinonimo rafforzativo di IUV. È definito al paragrafo 7.1 delle Linee guida.
CAD
Codice dell'amministrazione digitale: decreto legislativo 7 marzo 2005, n. 82
aggiornato con le modifiche e integrazioni successivamente introdotte.
Intermediario tecnologico
PA o PSP aderente a pagoPA che gestisce le attività di interconnessione al NodoSPC
per conto di altri soggetti aderenti a pagoPA (PA o PSP), ai sensi del § 8.3.3 delle Linee
guida.
IUV
Acronimo di Identificativo Univoco Versamento.
Linee guida
Il documento “Linee guida per l'effettuazione dei pagamenti a favore delle pubbliche
amministrazioni e dei gestori di pubblici servizi”.
Nodo dei Pagamenti-SPC
Piattaforma tecnologica per l’interconnessione e l’interoperabilità tra le Pubbliche
Amministrazioni e i Prestatori di Servizi di Pagamento di cui all’art. 81, comma 2-bis
del CAD.
Partner tecnologico
Soggetto che gestisce le attività di interconnessione al NodoSPC per conto di una PA,
nel rispetto delle specifiche tecniche contenute nelle Linee guida.
pagoPA®
Il sistema dei pagamenti a favore delle pubbliche amministrazioni e dei gestori di
pubblici servizi.
PSP
Prestatore di Servizi di Pagamento.
Ricevuta Telematica
Oggetto informatico inviato dal PSP all’ente creditore attraverso il Nodo dei
Pagamenti-SPC in risposta ad una Richiesta di Pagamento Telematico effettuata da un
ente creditore.
Richiesta di Pagamento
Telematico
Oggetto informatico inviato dall’ente creditore al PSP attraverso il Nodo dei
Pagamenti-SPC al fine di richiedere l’esecuzione di un pagamento.
RPT
Richiesta di Pagamento Telematico.
RT
Ricevuta Telematica.
SACI
Specifiche attuative dei codici identificativi di versamento, riversamento e
rendicontazione, Allegato A alle Linee guida.
SANP
Specifiche attuative del Nodo dei Pagamenti-SPC, Allegato B alle Linee guida.
Pag. 4 di 13
Definizione / Acronimo
Descrizione
Servizi di Nodo
Funzionalità rese disponibili dal Nodo dei Pagamenti-SPC ai soggetti appartenenti al
Dominio.
Servizio
L’insieme delle funzione e delle strutture tecniche, organizzative e di governo
finalizzate all’interconnessione e all’interoperabilità tra gli enti creditori ed i PSP
aderenti, ai sensi dell’articolo 81, comma 2-bis, del CAD.
SPC
Sistema Pubblico di Connettività.
SPCoop
Sistema Pubblico di Connettività e cooperazione.
Utilizzatore finale
Cittadini, figure professionali o imprese, nonché pubbliche amministrazioni che
effettuano pagamenti elettronici a favore di un ente creditore.
Pag. 5 di 13
INTRODUZIONE
La diffusione del sistema pagoPA® con l'adesione di molteplici soggetti che offrono servizi di
interconnessione al Nodo dei Pagamenti-SPC, i cosiddetti intermediari e partner tecnologici, ha dato
luogo alla possibilità che un Ente Creditore utilizzi soggetti diversi per consentire ai cittadini di
effettuare pagamenti elettronici.
È questo il caso, ad esempio, dei comuni che si servono di Unioncamere per erogare i servizi
SUAP e che parimenti utilizzano anche l'intermediazione della Regione di appartenenza per
consentire i pagamenti elettronici previsti dalle Linee guida.
Altro caso cui fare riferimento è quello legato al nuovo servizio di emissione della Carta di Identità
Elettronica, per il quale il Ministero degli Interni è intermediario tecnologico di tutti i comuni italiani.
Tutto ciò premesso, scopo della presente monografia è quello di analizzare e definire le regole
attraverso le quali l'Ente Creditore deve generare il codice IUV nel caso in cui si trovi appunto nella
situazione precedentemente indicata: cioè utilizzi più di un soggetto intermediario per consentire ai
propri utenti di poter effettuare pagamenti in modalità elettronica.
Il documento è di riferimento per gli Enti Creditori ed i Prestatori di servizi di pagamento.
Pag. 6 di 13
1.
IL CODICE IUV
Secondo quanto definito nel paragrafo 7.1 delle Linee guida per i pagamenti elettronici, « ...,
ciascun Ente Creditore attribuisce ad ogni operazione di incasso un codice identificativo denominato
“Identificativo Univoco di Versamento” (IUV) che non può essere associato nel tempo ad alcun altro
incasso emesso dal medesimo Ente Creditore .....».
Il codice IUV assume una rilevanza fondamentale « ... al fine di consentire le attività di
riconciliazione del pagamento da parte degli Enti Creditori e quelle di riversamento a cura dei
Prestatori di servizi di pagamento... » rappresentando pertanto uno degli elementi essenziali sui quali
si base il sistema pagoPA®.
Lo stesso paragrafo 7.1 delle Linee guida concede agli Enti Creditori la possibilità di « ....
demandare ad un soggetto terzo, in tutto o in parte, la generazione dell’Identificativo Univoco di
Versamento, curando che ne sia mantenuta l’univocità nel tempo».
La generazione di codice IUV univoco nel corso del tempo è quindi una precisa responsabilità
dell'Ente Creditore: vedremo nei capitoli successivi le regole attraverso le quali è possibile demandare
tale compito ad altri soggetti, rispettando altresì il requisito di univocità temporale.
1.1
Regole di generazione del codice IUV
Le specifiche attuative SACI e SANP, rispettivamente allegato A e B alle Linee guida, definiscono
le regole di generazione del codice IUV. In particolare, le SANP disciplinano in modo diverso la
generazione del codice IUV in funzione del modello di pagamento, dando cioè regole più cogenti nel
caso in cui il pagamento possa essere eseguito presso le strutture dei PSP, in virtù della pre-esistenza
di regole consolidate presso i PSP.
La presente monografia modifica quanto definito al capitolo 2 delle SACI e sostituisce la specifica
di cui al paragrafo 7.4.1 delle SANP.
2.
CONDIVISIONE DEL CODICE IUV
Nel caso in cui un Ente Creditore utilizzi più di un intermediario o di un partner tecnologico, è
possibile che la generazione dello IUV avvenga autonomamente presso più soggetti, ovvero i “punti
di generazione” del codice IUV sono tra loro diversi e non coordinati dall’Ente Creditore.
A tal fine è necessario segregare i domini di applicazione dello IUV, cioè attribuire ad ogni
soggetto che lo genera un apposito identificativo denominato Codice Segregazione.
2.1
Attribuzione del Codice Segregazione
L'Agenzia per l'Italia Digitale attribuisce il Codice Segregazione in funzione del soggetto che
svolge il ruolo di intermediario o partner tecnologico, secondo la seguente classificazione:
[a] Erogatori di servizi centralizzati: intermediari tecnologici riconosciuti da AgID che
erogano servizi in modalità accentrata a livello nazionale;
[b] Intermediari dell’Ente Creditore: qualsiasi intermediario o partner tecnologico che non
rientra nella classificazione precedente.
Uno schema delle modalità di attribuzione del Codice Segregazione è riportata in Figura 1.
Pag. 7 di 13
Figura 1 - Attribuzione del codice segregazione
2.1.1 Erogatori di servizi centralizzati
Sono quei soggetti, censiti a livello generale, che erogano servizi centralizzati per una comunità di
Enti Creditori con riferimento a procedure specifiche: quali, ad esempio, il SUAP, l'emissione online della Carta di Identità Elettronica, l'emissione dei certificati anagrafici tramite ANPR, ecc.
L'attribuzione della qualifica erogatore di servizi centralizzati deve essere richiesta all'AgID che
provvederà ad aggiornare l'elenco riportato in Tabella 1.
Tabella 1 - Elenco servizi centralizzati
codice
segregazione
Soggetto che eroga il servizio
Servizio
99
Ministero dell'Interno
Emissione on-line CIE
98
Ministero dell'Interno
Emissione certificati da ANPR
97
Unioncamere
SUAP
In alcuni casi - come ad esempio quello legato all’emissione on-line della CIE o dei certificati
anagrafici, compresa la componente legata al pagamento del servizio - l’utilizzo della procedura
centralizzata sarà obbligatorio per tutti i comuni italiani.
2.1.2 Intermediari dell’Ente Creditore
AgID attribuirà uno o più codici segregazione (progressivamente a salire: da 00 a 49) ad ognuno
degli intermediari/partner tecnologici secondo quanto richiesto dall'Ente Creditore.
Se un Ente Creditore genera in proprio il codice IUV e si avvale contemporaneamente di un
intermediario o di un partner tecnologico, l'Ente Creditore dovrà essere censito alla stregua di
intermediario dello stesso ente.
Pag. 8 di 13
2.2
Codice IUV nel caso del Modello 1 e 2
Nel caso in cui presso un Ente Creditore siano presenti “punti di generazione” del codice IUV tra
loro diversi e non coordinati, il codice IUV, generato per essere usato nell'ambito dei pagamenti
attivati presso l'ente (modelli 1 e 2), sarà composto secondo il seguente schema:
<codice segregazione (2n)><codice alfanumerico (max 33)>
(A)
Lo schema si applica anche nel caso in cui il codice IUV sia codificato secondo lo standard ISO
11649; in tale ipotesi dovrà essere conforme al seguente schema:
RF <check digit (2n)><codice segregazione (2n)><codice alfanumerico (max 19)>
(B)
Gli schemi sopra (A) e (B) indicati modificano quanto definito al capitolo 2 delle SACI
versione 1.2.
2.3
Numero avviso e codice IUV nel caso del Modello 3
Nel caso dei pagamenti attivati presso il PSP, l'introduzione della possibilità di utilizzare più
intermediari per lo stesso Ente Creditore, nonché nuovi requisiti raccolti presso gli enti che stanno
attivando il sistema pagoPA, hanno reso necessario rivedere la struttura del Numero Avviso, che,
secondo quanto indicato nel paragrafo 7.4.1 delle SANP, è attualmente così composto:
<aux digit (1n)><application code (2n)><IUV base (max 13n)><IUV check digit (2n)>
(C)
Nello schema (C) il codice IUV è rappresentato dalla concatenazione delle componenti <IUV base>
e <IUV check digit>, dove quest'ultima si calcola come resto della divisione per 93 del numero ottenuto
concatenando le componenti <aux digit>, <application code> e <IUV base>.
La revisione, legata alla necessità di gestire l’emissione del codice IUV presso più “punti di
generazione”, avviene attraverso l’assegnazione di valori diversi alla componente <aux digit> del
Numero Avviso, cosi come indicato nello schema (D)1.
<aux digit (1n)>[<application code (2n)>|<Codice segregazione>]<IUV base (max 17n)>[<IUV check digit (2n)>]
(D)
I valori assegnati alla componente <aux digit> determinano sia la presenza, sia la lunghezza delle
altre componenti del codice IUV e del Numero Avviso, così come riepilogato in Tabella 2.
Tabella 2 - Composizione del codice avviso in funzione dei punti di generazione dello IUV
Punti
generazione
IUV
1
<aux digit> <application code>
<codice
segregazione>
Lunghezza
<IUV base>
<IUV check digit>
Lunghezza
codice IUV
0
si
no
13
si
15
1
1
no
no
17
no
17
≥1
2
no
no
15
si
17
>1
3
no
si
13
si
17
1
Le componenti all'interno delle parentesi quadre possono non essere presenti, mentre il carattere “|” indica la presenza
in alternativa delle componenti.
Pag. 9 di 13
Come si vede da un'analisi della Tabella 2, nei nuovi casi previsti (<aux digit> diverso da 0) la
lunghezza del codice IUV diviene di 17 posizioni a scapito della componente <application code> che
viene abolita e sostituita in alcuni casi dalla componente <codice segregazione> (cfr. § 2.1).
Lo schema (D) e la Tabella 2 sostituiscono la specifica di cui al paragrafo 7.4.1 delle SANP
versione 1.7.
2.3.1 Valore 0 della componente <Aux Digit>
Si tratta dello schema per la composizione del numero avviso previsto dalla versione 1.7 delle
SANP, utilizzabile solamente se il "punto di generazione del codice IUV" sia unico. Lo schema
(NAV.0) evidenzia la composizione da utilizzare per il numero avviso:
0<application code (2n)><IUV base (max 13n)><IUV check digit (2n)>
(NAV.0)
L'Ente creditore può prevedere più porzioni dell’Archivio dei Pagamenti in Attesa (APA), mentre
la composizione del codice IUV è definita dallo schema (IUV.0) sotto evidenziato:
<IUV base (max 13n)><IUV check digit (2n)>
(IUV.0)
dove la componente <IUV check digit> si calcola come resto della divisione per 93 del numero ottenuto
concatenando le componenti <aux digit>, <application code> e <IUV base>.
Si tratta di uno schema previsto per tutelare particolari situazioni pre-esistenti alla emanazione
delle Linee guida2; tale schema è utilizzabile solamente se il "punto di generazione del codice IUV"
sia unico. Lo schema (NAV.1) evidenzia la composizione da utilizzare per il numero avviso:
1<IUV base (max 17n)>
(NAV.1)
Il codice IUV è formato dalla componente <IUV base>, manca la componente <IUV check digit >.
L'Ente Creditore ha un archivio APA non partizionato oppure gestisce in proprio la segregazione
tra le varie procedure aziendali.
La componente <application code> non è presente nel parametro codiceIdRPT delle primitive
previste dal protocollo di colloquio con i PSP (cfr. § 9.3.2 delle SANP): il NodoSPC configura in
questo caso un unico indirizzo al quale inviare le primitive previste dal protocollo di colloquio verso
gli Enti Creditori.
Si tratta di uno schema previsto per gestire Enti Creditori di grandi dimensioni, che però utilizzano
un archivio APA non partizionato oppure che gestiscono in proprio la segregazione tra le varie
procedure aziendali.
Lo schema è utilizzabile se il "punto di generazione del codice IUV" è unico oppure se, nella
generazione dello IUV, ha cura che i primi due caratteri a sinistra della componente <IUV base> siano
2
È il caso, ad esempio, dell'Ente Creditore Equitalia che identifica le proprie cartelle con un codice denominato RAV,
che ha le stesse caratteristiche di lunghezza e formato del codice IUV, ma utilizza regole diverse di generazione.
Pag. 10 di 13
diversi dai tutti i valori presenti nella colonna “codice segregazione” di Tabella 1 relativa agli
erogatori di servizi centralizzati.
Lo schema (NAV.2) evidenzia la composizione da utilizzare per il numero avviso:
2<IUV base (max 15n)><IUV check digit (2n)>
(NAV.2)
La composizione del codice IUV è definita dallo schema (IUV.2) sotto evidenziato:
<IUV base (max 15n)><IUV check digit (2n)>
(IUV.2)
concatenando le componenti <aux digit> e <IUV base>.
previste dal protocollo di colloquio con i PSP (cfr. § 9.3.2 delle SANP): il NodoSPC configura in
questo caso un unico indirizzo al quale inviare le primitive previste dal protocollo di colloquio verso
gli Enti Creditori. In questo caso l’Ente Creditore è responsabile di indirizzare correttamente al suo
interno l’accesso al proprio archivio APA.
Si tratta di uno schema previsto per gestire gli enti che hanno più di un intermediario, cioè enti per
i quali il "punto di generazione del codice IUV" non è unico; lo schema (NAV.3) evidenzia la
composizione da utilizzare per il numero avviso:
3<codice segregazione (2n)><IUV base (max 13n)><IUV check digit (2n)>
(NAV.3)
La composizione del codice IUV è definita dallo schema (IUV.3) sotto evidenziato:
<codice segregazione (2n)><IUV base (max 13n)><IUV check digit (2n)>
(IUV.3)
concatenando le componenti <aux digit>, <codice segregazione > e <IUV base>.
Il codice IUV deve essere fornito al NodoSPC nella concatenazione sopra indicata della lunghezza
massima di 17 caratteri numerici.
previste dal protocollo di colloquio con i PSP (cfr. § 9.3.2 delle SANP): il NodoSPC individua la
destinazione delle primitive previste dal protocollo di colloquio verso gli Enti Creditori in funzione
della componente <codice segregazione > del codice IUV.
A completamento di quanto sopra indicato, si sottolinea che anche gli Enti Creditori non
intermediati o intermediati da un unico soggetto possono adottare - di concerto con il proprio
intermediario, se presente - gli schemi di generazione dello IUV proposti in questo paragrafo, senza
richiedere all’Agenzia l’assegnazione di uno più specifici codici segregazione.
2.4
Indirizzamento dell’Archivio dei Pagamenti in attesa
Secondo quanto definito nel paragrafo 7.4.1 delle SANP, l’Archivio dei Pagamenti in Attesa
(APA) è rappresentato dall’insieme di uno più archivi fisici o logici, eventualmente ripartito secondo
le necessità dell’Ente Creditore (ad esempio: diverse sedi anche presso diversi intermediari,
applicazioni dedicate, ecc.).
Pag. 11 di 13
L’indirizzamento delle varie sezioni logiche e fisiche dell’archivio APA deve essere comunicata
al gestore del Nodo dei Pagamenti-SPC in modo che le varie sezioni siano fisicamente connesse al
soggetto che gestisce quella porzione di APA. Pertanto, il motore di gestione del NodoSPC attiverà i
vari canali indicati dall’Ente Creditore in funzione del contenuto presente all’interno del Numero
dell’Avviso di pagamento indicato dal PSP, e quindi in funzione della componente <aux digit>, così
come indicato in Tabella 2 a pagina 9.
In Figura 2 è riportata una esemplificazione puramente indicativa dell’indirizzamento APA nel
caso del pagamento attivato presso i PSP in funzione della componente <aux digit> del Numero
Avviso.
Figura 2 – Indirizzamento dell’archivio APA nel modello 3
È responsabilità dell’Ente Creditore indicare nei vari casi il corretto indirizzamento dell’archivio
APA.
2.5
Modifiche applicative
Al fine di gestire la diversa lunghezza del codice IUV, saranno opportunamente modificati gli
schemi XSD associati al parametro codificaInfrastrutturaPSP delle primitive utilizzate dai PSP per
attivare i pagamenti attraverso il modello 3 (cfr. § 17.6 delle SANP).
Tabella 3 - Valori del parametro codificaInfrastrutturaPSP e XSD da utilizzare
supporto in input
Parametro codificaInfrastrutturaPSP
Schema XSD da utilizzare
QR-Code o input da terminale3
QR-CODE
IdRPT_QR_Code_<versione>.xsd
Barcode GS1-128
BARCODE-GS1-128
IdRPT_GS1_128_<versione>.xsd
Barcode 128 AIM USS-128 tipo C
BARCODE-128-AIM
IdRPT_128_AIM_<versione>.xsd
Si precisa che, in tutti e tre gli schemi XSD riportati in Tabella 3, il Numero Avviso è segmentato
a seconda dei vari casi previsti al precedente § 2.3, nei quali sarà necessario associare l’elemento
3
Il terminale può essere un ATM, quello dell'operatore del PSP ovvero quello dell'utilizzatore finale che utilizza le
funzioni di home banking messe disposizione dal PSP.
Pag. 12 di 13
<application code> al tag CodStazPA solo nel caso in cui la componente <aux digit> assuma il valore
0.
Sarà cura dei singoli PSP che consentono i pagamenti attraverso il modello 3 gestire nel modo
corretto il codice IUV in funzione della componente <aux digit> del Numero Avviso.
La componente applicativa del Nodo dei Pagamenti-SPC che gestisce i pagamenti attivati presso
i PSP si farà carico di trattare, in funzione della componente <aux digit> del Numero Avviso (secondo
le diverse modalità previste nei vari casi di cui al precedente § 2.3), le richieste provenienti dai PSP,
avendo cura di individuare correttamente la componente <codice segregazione> all’interno del codice
IUV (primi 2 caratteri a sinistra).
FINE DOCUMENTO
Pag. 13 di 13

Utilizzo del codice IUV per Enti pluri-intermediati

Transcript

Documenti analoghi

CALCIATURA IN POLIMERI ATI PER FUCILI MAUSER K98

Il K98 - Tiropratico.com

piemonte fondi strutturali europei 2014-2020

Foglio informativo n. 323/001. Solution PA. Partner Tecnologico

Comune di Cavallino Treporti

apri

QUI - Asec Trade