PORTING-MO-001 Porting Attuali Servizi - V.00.07.09

Il contenuto del presente documento costituisce materiale riservato. Ogni violazione sarà punita ai sensi di legge.

Nuova Architettura CBI Porting degli attuali Servizi CBI nella Nuova Architettura

Riferimenti

Oggetto: Porting degli attuali Servizi CBI nella Nuova Architettura

Modello Documento: CBI.doc

Nome File: PORTING-MO-001 Porting attuali Servizi - v.00.07.09.doc

Versione: 00.07.09 – Pagine 59

Ultimo aggiornamento: 22/07/2010 11.35.36

Data creazione: 22/12/2004

Autore: Segreteria Tecnica CBI

Revisore: GdL Architettura – GdL standard

Titolo:

Nuova Architettura CBI

Codice

PORTING-MO-001 Versione

00.07.09

Tipologia Documento:

Porting degli attuali Servizi CBI nella Nuova Architettura

Data

09-07-2010

Pagina

2/59

Revisioni

Data Ver. Presentato

a

In vigore dal Aggiornamenti

01-06-2005 00.01 Primo rilascio

30-01-2006 00.02 Par. 2.3.2 - Inserimento di chiarimenti specifici e di esempi sui criteri di omogeneità nella creazione del file

Par. 2.3.3 - Chiarimento sulle modalità di composizione Header di Servizio

Par. 2.4 - Precisazioni sulla modalità di compilazione dei blocchi “Info File” e “Info Supporto” contenuti nel messaggio di stato avanzamento

Par. 2.4 - Inserimento di chiarimenti specifici su criteri e regole di composizione msg di avanzamento e aggiornamento codici d’errore previsti nei messaggi d’avanzamento

Par. 2.5 - Inserimento chiarimenti specifici sull’invio del supporto logico “CN”

Par. 2.6 - Chiarimento sulle modalità di invocazione del servizio “PORTING-A4”

Cap. 4 - Aggiornamento Regole di Governance, con l’inserimento di casi particolari di errore

Cap. 5 - Aggiornamento dei servizi esposti nel Directory con l’inserimento del servizio “PORTING-I4”

Cap. 5 - Inserimento modalità di indirizzamento dei flussi nel caso di Marketplace

Par. 8.3.2 - Aggiornamento stati di avanzamento dei supporti logici

Par. 8.3.2.3.1 – Aggiornamento campi del Body del msg XML di richiesta di servizio accompagnatorio del file

Par. 8.3.2.3.2 - Aggiornamento campi del Body del msg XML di stato avanzamento

Par. 8.4 – Inserimento esempi di XML in Allegato D con inserimento dei namespace in cui i vari blocchi di informazione sono definiti

02-05-2006 00.03 Par. 8.3.2.3.2 - Inserimento rimando al documento CBI-STD-001

Par. 2.6 – Inserimento appositi chiarimenti Cap. 8 – Allegato D – Aggiornamento esempi di

XML inserendo esempi specifici di 1° e 2° messaggio di avanzamento

Par. 2.4 – Inserimento chiarimenti specifici sulle modalità di correlazione tra messaggio di richiesta e messaggi di avanzamento

Par. 2.4.1 – Inserimenti chiarimenti sulle modalitàdi costruzione del messaggio 17 in caso di errore sul controllo di corrispondenza tra messaggio XML e file

Titolo:


Codice


00.07.09



Data

09-07-2010

Pagina

3/59

Cap. 5 – Differenziazione tra supporti logici di tipo “SL” inviati da Banca e supporti logici di tipo “SL” inviati dal Cliente

Par. 2.3.2 – Indicazione della riduzione del limite temporale sul controllo di univocità dei supporti logici da 13 mesi a 6 mesi

Par. 2.4.1 – Inserimento ulteriore codice d’errore sul messaggio 17 (PSL4): firma digitale come criterio di omogeneità

Par. 2.4.1 – Inserimento nota relativamente ad errori di parsing

Par. 2.2 – Eliminazione dell’attività di “Invio CN” da sequence e activity diagram per il servizio Porting

Par. 2.4.1 - Inserimento ulteriore controllo in ricezione relativo al Codice ABI e al CUC della Banca Passiva e ulteriore codice d’errore sul messaggio 17 (PSL6)

Cap. 5 – Inserimento chiarimento su controlli da effettuare su campi del Directory per indirizzamento flussi Porting

07-06-2006 00.04 Par 2.4.1 – Inserimento codice d’errore “PSL4” (Supporto logico non omogeneo per destinatario)

Allegato D – Modifica dell’esempio XML relativo al 1° messaggio di avanzamento (eliminando i blocchi “Info supporto” per ricezione OK)

Par. 2.4.1 e Par. 4.4.4 – Inserimento chiarimento specifico sulle modalità di segnalazione dell’errore in caso di incoerenza di informazioni nel solo messaggio XML

Par. 8.3.2.3.1 – Aggiornamento tipo dato del campo “Firma”, contenente la Busta PKCS#7

Cap. 6 – Inserimento durata “Giornata Applicativa” Par. 8.3.2.3.2 – Aggiornamento tipo dato associato

al campo “Numero disposizione” Par. 3.3 - chiarimenti su cosa si intende per

“controlli applicativi” Par. 4 – eliminazione refuso nota 4 a piè di pagina Par. 2.6 – eliminata la caratteristica di

“temporaneità” della soluzione prevista per la modalità di veicolazione dei flussi I4

09-06-2006 00.05 Par. 2.5 – Modifica modalità di invio supporti logici “A4”

17-07-2006 00.06 In vigore a partire dal

21-07-2006 per

l’effettuazione dei test

Par. 2.6 – Modifica modalità di trattamento dei flussi “I4”

Cap. 5 - Inserimento chiarimento sulle modalità di indirizzamento degli stati di avanzamento e degli esiti per richieste provenienti da Marketplace

Par. 2.4.1 – Inserimento chiarimento sui controlli da effettuare dalla Banca Destinataria per predisporre il 1° messaggio di avanzamento

20-12-2006 00.07 In vigore a partire

dall’attivazione della

totalità dei servizi

Porting

Par. 8.3.2.3.1 – Modifica descrizione campo “Riferimento temporale” all’interno del blocco “Firma”

Par. 2.6 – Inserimento apposito paragrafo per la gestione dei supporti logici “Q4” e “A4”

Par. 4.5 – Inserimento paragrafo per la gestione del recupero flussi in caso di errore

Par. 4.5.2 – Inserimento chiarimento specifico su modalità di rinvio dei flussi da parte del Mittente

Titolo:


Codice


00.07.09



Data

09-07-2010

Pagina

4/59

Par. 2.5 – Inserimento chiarimento specifico su invio supporti logici “A4” e “Q4”

Cap. 5 - Inserimento precisazione su dove reperire il codice marketplace necessario per l’indirizzamento degli esiti delle disposizioni di pagamento

Par. 8.3.2.3.1 – Eliminazione refuso “XML Signature” come possibile valore del campo “Tipo firma”

Par. 2.4 – Variazione nei controlli da effettuare in merito all’omogeneità dei flussi per destinatario logico

Par. 2.3.2 – Variazione della nota 1 in merito ai criteri di omogeneità

18-04-2007 00.07.04 In vigore a partire

dalla data di

attivazione del primo

set di Nuovi Servizi

CBI

Par 8.3.2.3.1 – Modificata la struttura del blocco firma che viene reso facoltativo

Par. 7 – Descrizione delle modalità di scarto in caso di errori correlati alla verifica della firma digitale

Par. 2.4.1 e Par 2.4.2 – Aggiunti i riferimenti al paragrafo 7 per la trattazione dei temi relativi alla gestione della firma digitale

05-07-2007 00.07.05 In vigore a partire

dalla data di

attivazione del primo

set di Nuovi Servizi

CBI

Nessuna modifica al presente documento. Sono stati rimossi dalla documentazione specifica dei Servizi Porting i file di schema relativi alla definizione degli header di tratta e di servizio e del blocco firma. Per tali file si deve fare riferimento a quelli contenuti nella documentazione PARTE GENERALE

31-10-2007 00.07.06 In vigore a partire dal

25 Febbraio 2008

Par. 8.3.2.3.1 – Inserita precisazione circa l’utilizzo del campo <CreDt>, il quale non deve contenere il dettaglio relativo al Time Zone

Par. 8.3.2.3.2 – Inserita precisazione circa l’utilizzo del campo <CreDt>, il quale non deve contenere il dettaglio relativo al Time Zone

18-02-2008 00.07.07 Novembre 2008 Par. 8.5: inserito elenco dei qualificatori tipo messaggio da utilizzare per la strutturazione degli identificativi di file e messaggi, in accordo a quanto specificato nel documento Parte Generale

10-10-2008 00.07.08 In vigore a partire dalla data di attivazione della firma digitale sui flussi dispositivi di Porting

Par. 2.4.1: meglio dettagliato la verifica di coerenza tra i supporti logici referenziati nel messaggio XML e quelli contenuti nel file

Par. 4.4.6: aggiunta precisazione in merito alle modalità di composizione dei messaggi 20 (ordine nel quale sono referenziati i supporti originari)

Par. 4.5.1: modifica della procedura di recupero dei flussi a seguito di un errore effettuato dal ricevente

Par 2.4.2: inserimento chiarimento circa le modalità di scarto in caso di codice SIA non censito

Par. 2.1: inserimento chiarimento circa la differenza tra supporti logici informativi e dispositivi

Par. 2.4.1: aggiunta tipologia di scarto dei flussi firmati provenienti da mittenti fisici non autorizzati

Par. 7: inserito apposito paragrafo che descrive le modalità di scarto di flussi firmati provenienti da mittenti fisici non autorizzati

Par. 8.3.2.3.2: modificata descrizione relativa al

Titolo:


Codice


00.07.09



Data

09-07-2010

Pagina

5/59

codice di errore PF5 Par. 5: inserito chiarimento circa modalità di

indirizzamento degli esiti di pagamento verso MarketPlace

09-07-2010 00.07.09 30 agosto 2010 Par. 2.2.1.1: eliminato riferimento ai flussi “CN” non previsti dalla attuale architettura di Rete

Par 2.3.2: aggiunta precisazione circa i criteri di aggregazione dei supporti logici nel file e circa la dimensione massima dei file. Aggiunta precisazione in merito alla data e il periodo di riferimento per effettuare il controllo di univocità dei supporti logici

Par. 2.4.1 aggiunta verifica omogeneità dei supporti logici relativamente all’utilizzo della firma digitale e alla tipologia di firma utilizzataall’interno di uno stesso flusso

Par. 7: aggiornati i riferimenti tecnici per la gestione della firma digitale a norma (cfr. deliberazione CNIPA n°45 del 21 maggio 2009 in vigore dal 30 agosto 2010)

Par. 7.3: inserite precisazioni circa i controlli relativi alla firma digitale. Ordine dei controlli e “leggibilità” della busta

Allegato C: modificata descrizione dei campi relativi al blocco di informazioni sulla firma

24-05-2010 00.07.09 1 Novembre 2010 Par. 6 Definizione e determinazione dei tempi di attraversamento sistema CBI

Titolo:


Codice


00.07.09



Data

09-07-2010

Pagina

6/59

Riservatezza e divulgazione

Il “Consorzio Customer to Business Interaction” – di seguito definito Consorzio CBI – in qualità di titolare dei marchi CBI fornisce queste informazioni prevedendo che siano mantenuti i livelli di correttezza e, se indicati, di riservatezza sui relativi contenuti. Il documento potrà pertanto essere fotocopiato o riprodotto in tutto o in parte ed i contenuti potranno essere divulgati a terzi, anche consulenti, purché siano rispettate le disposizioni di cui alla Intellectual Property Rights disponibile sul sito web consortile.

Titolo:


Codice


00.07.09



Data

09-07-2010

Pagina

7/59

Indice dei Contenuti 1 Obiettivi del documento................................................................................9

1.1 Struttura del documento....................................................................................9

2 Il Servizio “PORTING ATTUALI TRACCIATI” ...............................................10

2.1 Introduzione................................................................................................... 10

2.2 Porting degli attuali tracciati: caso d’uso ........................................................... 10 2.2.1 Ipotesi di base ed attori identificati ............................................................ 10

2.3 Invocazione di Servizio .................................................................................... 15 2.3.1 Regole per la creazione del supporto logico ................................................ 17 2.3.2 Regole per la creazione del file .................................................................. 17 2.3.3 Regole per la creazione del messaggio ....................................................... 19

2.4 Stati di avanzamento....................................................................................... 20 2.4.1 Controlli e regole di composizione del 1° messaggio di avanzamento ............ 21 2.4.2 Controlli e regole di composizione del 2° messaggio di avanzamento ............ 23

2.5 Considerazioni su invio supporti logici “F4”, “R4”................................................ 24

2.6 Considerazioni su invio supporti logici “Q4”, “A4” ............................................... 25

2.7 Considerazioni su invio supporti logici “I4”......................................................... 26

3 Diagnostica .................................................................................................27

3.1 Diagnostica sul messaggio ............................................................................... 27

3.2 Diagnostica sul file .......................................................................................... 27

3.3 Diagnostica sul supporto logico ........................................................................ 27

4 Regole di governance..................................................................................28

4.1 Mancato rispetto delle tempistiche di invio dei messaggi di avanzamento............. 28

4.2 Mancato rispetto della sequenza di invio dei messaggi di avanzamento................ 29

4.3 Casi specifici di errore...................................................................................... 29 4.3.1 File non trovato ........................................................................................ 29 4.3.2 Non omogeneità dei supporti logici ............................................................ 29 4.3.3 Supporti logici non referenziati .................................................................. 29 4.3.4 Errori di diagnostica applicativa su alcuni supporti logici............................... 30

4.4 Casi generali di errore ..................................................................................... 30 4.4.1 Non univocità della correlazione file-messaggio ........................................... 30 4.4.2 Messaggio ricevuto illeggibile..................................................................... 30 4.4.3 Supporti logici duplicati ............................................................................. 30 4.4.4 Incoerenza “Nome servizio” e “Tipologia flusso” nel messaggio XML ............. 31 4.4.5 Mancata corrispondenza nel 1° messaggio di avanzamento.......................... 31

Titolo:


Codice


00.07.09



Data

09-07-2010

Pagina

8/59

4.4.6 Mancata corrispondenza nel 2° messaggio di avanzamento.......................... 31

4.5 Recupero dei flussi in caso di errore ................................................................. 31 4.5.1 Errore imputabile al soggetto ricevente ...................................................... 31 4.5.2 Errore imputabile al soggetto mittente........................................................ 32 4.5.3 Gestione delle contestazioni ...................................................................... 32

5 Individuazione indirizzo di erogazione del Servizio Porting .......................33

6 Livelli di servizio..........................................................................................34

7 Firma digitale ..............................................................................................39

7.1 Controllo del mittente fisico dei flussi firmati...................................................... 39

7.2 Controllo di omogeneità per apposizione della firma digitale ............................... 39

7.3 Verifica della firma sui singoli supporti logici ...................................................... 41

8 Allegati ........................................................................................................43

8.1 Allegato A – Criteri di identificazione univoca di messaggio e file ......................... 43

8.2 Allegato B - Popolamento del Directory a fini di “porting” ................................... 43

8.3 Allegato C – Struttura dei Messaggi XML d’invio file/stato d’avanzamento ............ 43 8.3.1 Considerazioni generali ............................................................................. 43 8.3.2 Struttura.................................................................................................. 43

8.4 Allegato D – Esempi di XML ............................................................................. 55

8.5 Allegato E – strutturazione degli identificativi univoci e qualificatori di tipo messaggio ............................................................................................................ 59

Titolo:


Codice


00.07.09



Data

09-07-2010

Pagina

9/59

1 Obiettivi del documento Il presente documento ha l'obiettivo di definire i criteri e le modalità con i quali deve essere realizzato il “porting” degli attuali Servizi CBI sulla Nuova Architettura, nonché evidenziare le attività che, propedeuticamente, devono essere svolte per rendere possibile tale “porting”. Il documento richiama definizioni, concetti e criteri già espressi nella documentazione attinente sia all’attuale, sia alla Nuova Architettura CBI. In particolare è presa come riferimento la seguente documentazione: gli standard tecnici dell’attuale architettura, identificati dal Codice Classificazione “CBI-XXX-NNN”, ove:

- CBI: è il codice di progetto assegnato dalla Segreteria Tecnica dell’Associazione per il CBI per la documentazione relativa all’attuale architettura:

- XXX: è la tipologia di documento (ad esempio BON, AEA, F24, etc.); - NNN: è il codice progressivo del documento nell’ambito della tipologia XXX.

“STPG-MO-001 Nuovi Servizi – Parte Generale”; “FIRMA-MO-001 Introduzione alla Firma Digitale: aspetti tecnici e generalità”. Dato il livello di approfondimento dei temi trattati, il Documento si configura come Manuale Operativo e destinato a quanti sono chiamati ad effettuare le implementazioni necessarie al Porting.

1.1 STRUTTURA DEL DOCUMENTO Il documento è strutturato nelle seguenti sezioni:

- Definizione del Servizio “Porting Attuali Tracciati”; - Regole di governance; - Diagnostica; - Individuazione dell’indirizzo di erogazione del Servizio; - Livelli di servizio; - Firma digitale applicata al Porting; - Criteri di identificazione univoca di messaggio e file (Allegato A); - Popolamento del Directory ai fini del Porting (Allegato B); - Struttura dei messaggi XML (Allegato C); - Esempi di messaggi XML (Allegato D).

Titolo:


Codice


00.07.09



Data

09-07-2010

Pagina

10/59

2 Il Servizio “PORTING ATTUALI TRACCIATI”

2.1 INTRODUZIONE I supporti logici in uso nell’attuale architettura sono veicolati nella Nuova Architettura mediante l’invocazione, da parte della Banca Mittente, di un Servizio “PORTING ATTUALI TRACCIATI”, strutturato come segue: - invio verso la Banca Destinataria di un “file di supporti logici” (veicolato tramite file transfer); - invio verso la Banca Destinataria di un “messaggio XML” (veicolato tramite message switching)

contenente i riferimenti del file e le informazioni riepilogative sui supporti logici in esso contenuti. A tale invocazione di servizio, la Banca Destinataria risponde inviando verso la Banca Mittente uno o più messaggi XML di stato avanzamento/segnalazione errori rilevati. In deroga a quanto definito nel documento CBI-STD-001, nel presente documento per supporti logici informativi si intendono i supporti aventi come destinatario finale una azienda (es. RH, esiti RiBa) mentre vengono indicati come dispositivi i supporti logici aventi come destinatario finale una banca (es. PC, RiBa). Il Servizio “PORTING ATTUALI TRACCIATI” è un “unicum”, con un’unica invocazione, ancorché sia composto da due parti logicamente correlate – l’invio di un file e l’invio del relativo messaggio - che devono risultare altresì sincronizzate tra loro. In linea con tale principio, i capitoli che seguono sono stati redatti in accordo ai seguenti “criteri base”: - la funzionalità di sincronizzazione, in invio e ricezione, di “file+messaggio” è fornita da un apposito

modulo applicativo, realizzato e messo a disposizione delle Banche della Comunità CBI. Tale funzionalità, pertanto, non è a carico delle Applicazioni Bancarie;

- tutti i flussi (supporti logici, file di supporti logici e messaggi) devono essere sottoposti a diagnostica prima del loro invio sulla Rete Logica; tale diagnostica deve essere effettuata tramite un diagnostico certificato (in accordo ai requisiti definiti da ACBI);

- la responsabilità delle attività di diagnostica è in capo alla Banca, fermo restando la facoltà di quest’ultima di delegare tale attività ad un soggetto terzo (Gestore del Punto d’Accesso, STD etc.).

2.2 PORTING DEGLI ATTUALI TRACCIATI: CASO D’USO Al fine di descrivere le funzionalità e le caratteristiche tecnologiche offerte dalla Nuova Architettura rispetto alla veicolazione dei supporti logici, è stato identificato un “caso d’uso” descrittivo dell’invocazione della richiesta di servizio da parte della Banca Mittente e delle relative risposte inviate dalla Banca Destinataria. Il “caso d’uso” prende in considerazione l’invocazione del Servizio ed i relativi stati di avanzamento/segnalazioni d’errore – ed è stato sviluppato costruendo un modello UML rappresentato da: sequence diagram: descrive le interazioni tra i vari soggetti/attori in funzione dello scorrere del tempo,

rappresentato dall’asse verticale del diagramma; activity diagram: descrive il flusso delle attività svolte dai diversi attori evidenziandone i possibili

parallelismi.

2.2.1 Ipotesi di base ed attori identificati Al fine di garantire la generalità del modello, questo è stato costruito in accordo alle seguenti “ipotesi di base”:

Titolo:


Codice


00.07.09



Data

09-07-2010

Pagina

11/59

le attività potenzialmente delegabili ad una STD sono state assegnate alla Banca; il che comporta che nel modello i due attori sono coincidenti. A ciascuna Banca è lasciata la valutazione se tali attività debbano essere svolte in proprio o, sotto la propria responsabilità, tramite STD;

le modalità di accesso alla Nuova Architettura (NA) dipendono dal contesto tecnologico/architetturale di riferimento esistente presso ciascuna Banca (es. Punto di Accesso NA presso la STD della Banca). Per questo motivo il “Gestore del Punto di Accesso” non è identificato come attore autonomo, ma coincide con la Banca. A ciascuna Banca è lasciata la valutazione se tali attività debbano essere svolte in proprio o, sotto la propria responsabilità, tramite STD oppure un Gestore del Punto di Accesso;

l’invio del file/messaggio avviene direttamente tra Banca Mittente e Banca Destinataria; non è considerato in questo modello l’utilizzo di repository esterni residenti presso Terze Parti;

l’invio/ricezione del “file+messaggio” è a carico di una apposita funzione di sincronizzazione fornita da un modulo di sistema.

Il modello logico di interconnessione utilizzato per la modellazione del caso d’uso è riportato nella figura seguente

Punto diAccesso

NA

BancaDestinataria

Punto diAccesso

NA

Banca MittenteDirectory

Le modalità di interconnessione Banca - Punto di Accesso NA potranno esseredifferenti per ciascuna banca (es. Punto di Accesso NA presso la Banca/STD)

Aziendacliente

Aziendacliente

Figura 1 – Modello logico d’interconnessione

Alla luce di quanto sopra, gli attori utilizzati per la costruzione del “caso d’uso” sono: Banca Mittente Banca Destinataria Directory Si evidenzia inoltre che l’esecuzione delle attività di seguito descritte (Cfr. sequence e activity diagram) presuppone l’implementazione, da parte di ciascuna Banca, di uno specifico workflow applicativo, necessario all’effettivo svolgimento delle attività riportate. Le modalità di implementazione di tale workflow dipenderanno dal contesto tecnologico di riferimento di ciascuna Banca, in funzione del quale le attività descritte potranno essere svolte direttamente dalla Banca, dalla relativa STD o da un soggetto terzo (Centro Servizi, Gestore punto di accesso Nuova Architettura etc.). Fermo restando che la tratta “Azienda – Banca” è funzionalmente di pertinenza della Banca stessa, l’obiettivo del caso d’uso è quello di evidenziare le principali attività in carico ai vari attori bancari e di fornire una visione complessiva del workflow applicativo da implementare. 2.2.1.1 Sequence diagram La seguente Figura riporta il sequence diagram del caso d’uso, unitamente ad una descrizione sintetica delle attività svolte; la descrizione di dettaglio di ciascuna attività è riportata nel seguito del paragrafo.

Titolo:


Codice


00.07.09



Data

09-07-2010

Pagina

12/59

Banca DestinatariaBanca Mittente Directory

8: Invio query di indirizzamento sul Directory

(opzionale)

File

9: Esecuzione query10: Invio “indirizzo” Banca Destinataria

XML

13: Ricezione messaggio+file

12: Invio file+messaggio

XML FileXML File

18: Diagnostica applicativa supporti logici (diagnostica attuale formale)20: Invio messaggio stato

avanzamento(OK)/ errori rilevati(KO)

XML

16: Predisposizione messaggio di avanzamento / di errore

19: Predisposizione stato avanzamento/ errori rilevati

XML

1: Predisposizione supporti logici

7: Verifica informazioni di indirizzamento disponibili

11: Ricezione indirizzo Banca Destinataria

2: Diagnostica applicativa supporti logici(attuale diagnostica formale)

4: Predisposizione messaggio XML associato al file

3: Predisposizione e diagnostica file

5. Diagnostica coerenza file-messaggio

6. Diagnostica messaggio XML

17: Invio messaggio stato avanzamento (OK) / errori rilevati (KO)

14: Diagnostica messaggio XML (vedi 6)

15: Verifica omogeneitàfile e coerenza file-messaggio (vedi 3 e 5)

Figura 2 – Sequence diagram

Descrizione delle attività: 1 - 2: La Banca Mittente predispone e diagnostica i supporti logici da inviare (attuale diagnostica formale dei

supporti logici).

3 - 6: Predisposti i supporti logici, la Banca Mittente provvede alla predisposizione ed alla diagnostica del file fisico e, quindi, alla creazione del messaggio XML con le informazioni sui supporti logici contenuti nel file. La Banca Mittente diagnostica il messaggio XML predisposto e verifica la coerenza tra file e messaggio, in termini di puntatori e referenze messaggio-file.

7-11: La Banca Mittente verifica la completezza delle informazioni di indirizzamento a propria disposizione. In caso di verifica positiva, provvede all’invio del “file+messaggio” (Cfr. punto 12). Nel caso in cui le informazioni di indirizzamento non siano già disponibili alla Banca Mittente, quest’ultima provvede all’invio al directory di una query specifica di indirizzamento; Tale query viene elaborata dal Directory e la relativa risposta viene quindi restituita alla Banca Mittente (indirizzo di Rete Logica della Banca Destinataria corrispondente al Servizio di porting).

12: Ottenute tutte le informazioni necessarie all’indirizzamento, la Banca Mittente invoca la primitiva “send file+messaggio” per l’invio del file e del messaggio associato verso il Destinatario.

13 - 17: Ricevuto file e messaggio, la Banca Destinataria provvede ad eseguire la diagnostica del messaggio XML e la verifica di congruenza dei riferimenti messaggio – file. Nel caso di errori, invia un messaggio XML verso la Banca Mittente contente la descrizione degli errori rilevati (KO), sospendendo l’elaborazione del messaggio XML e del relativo file. Nel caso in cui non vi siano errori la Banca Mittente predispone ed invia un messaggio XML di stato d’avanzamento (OK).

Titolo:


Codice


00.07.09



Data

09-07-2010

Pagina

13/59

18 - 20: Eseguita l’attuale diagnostica formale sui supporti logici, la Banca Destinataria predispone un messaggio XML di stato di avanzamento (OK)/notifica errori rilevati (KO) e lo invia verso la Banca Mittente.

2.2.1.2 Activity Diagram Le figure seguenti riportano, in accordo alle attività previste dal sequence diagram, l’activity diagram relativo al caso d’uso descritto, unitamente alla descrizione delle attività rappresentate sul diagramma.

Banca Destinataria

Banca Destinataria

Banca MittenteBanca MittenteDirectory

1.Predisposizione supporti logici


9.Esecuzione query

10.Invio indirizzo Banca Destinataria

2.Diagnostica applicativa supporti logici (attuale diagnostica formale)

2.Diagnostica applicativa supporti logici (attuale diagnostica formale)



4: Predisposizione messaggio XML associato

al file

4: Predisposizione messaggio XML associato

al file

7: Verifica informazioni di indirizzamento disponibili7: Verifica informazioni di indirizzamento disponibili

8: Invio query di indirizzamento sul

Directory

8: Invio query di indirizzamento sul

Directory



12: Invio file+messaggio12: Invio file+messaggio

Info disponibili

NO

SI

5: Diagnostica coerenza file-messaggio

5: Diagnostica coerenza file-messaggio

6: Diagnostica messaggio XML


Figura 3 – Activity diagram – Parte 1 La Banca Mittente predispone i supporti logici da inviare, eseguendo i relativi controlli diagnostici (attuale diagnostica formale).

Titolo:


Codice


00.07.09



Data

09-07-2010

Pagina

14/59

Completata tale attività, la Banca Mittente predispone il file fisico ed il messaggio XML associato, verifica la completezza delle informazioni di indirizzamento disponibili e, in caso di verifica positiva, provvede ad avviare la fase di invio di file+messaggio. Nel caso in cui le informazioni d’indirizzamento non fossero complete, la Banca Mittente provvede ad inviare al Directory una query di indirizzamento al fine di ottenere tali informazioni; elaborata tale richiesta, il Directory provvede ad inviare l’indirizzo della Banca Destinataria verso la Banca Mittente. Ottenute le informazioni per l’indirizzamento, la Banca Mittente provvede quindi all’invio del file+messaggio.

Banca Destinataria

Banca Destinataria

Banca MittenteBanca MittenteDirectory

13: Ricezione messaggio+file13: Ricezione

messaggio+file



13: Verifica omogeneitàfile e coerenza file-

messaggio (vedi 3 e 5)

Errori rilevati

14: Predisposizione e invio messaggio di

errore

SI

NO

16: Diagnostica applicativa supporti

logici (attuale diagnostica formale)

16: Diagnostica applicativa supporti

logici (attuale diagnostica formale)

17: Predisposizione stato avanzamento/

errori rilevati

17: Predisposizione stato avanzamento/

errori rilevati

18: Invio messaggio stato avanzamento/

errori rilevati


errori rilevati

15: Invio messaggio stato avanzamento15: Invio messaggio stato avanzamento

Figura 4 – Activity diagram - Parte 2

La Banca Destinataria, ricevuti file e messaggio, provvede ad eseguire la diagnostica del messaggio XML e la verifica di congruenza rispetto al contenuto del file. Nel caso di errori, invia un messaggio XML verso la Banca Mittente contenente la descrizione degli errori rilevati, sospendendo l’elaborazione del messaggio XML e del relativo file (Cfr. Par. successivi per le regole di comportamento). Nel caso in cui non vi siano errori la Banca Destinataria predispone ed invia un messaggio XML di stato d’avanzamento.

Titolo:


Codice


00.07.09



Data

09-07-2010

Pagina

15/59

La Banca Destinataria esegue la diagnostica dei supporti logici e invia un messaggio XML di stato di avanzamento/errori rilevati verso la Banca Mittente. 2.2.1.3 Considerazioni su Sequence e Activity diagram Al fine di completare la descrizione del Servizio “PORTING ATTUALI TRACCIATI” rappresentata dal sequence e dall’activity diagram, e ricordando quanto già espresso precedentemente al Capitolo 2.1 - ovvero che la responsabilità delle attività di diagnostica è in capo alla Banca, fermo restando la facoltà di quest’ultima di delegare tale ad un soggetto terzo (Gestore del Punto d’Accesso, STD etc.) - deve essere comunque evidenziato che: - ogni Banca Mittente ha l’obbligo di garantire alla Banca Destinataria la rispondenza di quanto inviato agli

standard in uso tramite un diagnostico certificato (in accordo ai requisiti definiti da ACBI) ed evidenziando nel messaggio le informazioni relative a tale diagnostico

- la Banca Destinataria ha il diritto di ricevere flussi conformi agli standard in uso e diagnosticati tramite un diagnostico certificato (in accordo ai requisiti definiti dal Consorzio CBI)

2.3 INVOCAZIONE DI SERVIZIO Facendo riferimento al caso d’uso sopra descritto, in estrema sintesi - rispetto alle procedure oggi in essere - la Banca Mittente dovrà prevedere:

nuovi criteri di omogeneità dei flussi creazione e gestione del messaggio XML predisposizione e gestione di workflow per il Servizio diagnostica del messaggio XML

In particolare il processo seguirà i seguenti passi:

Titolo:


Codice


00.07.09



Data

09-07-2010

Pagina

16/59

3a.Predisposizione e diagnostica file



2.Diagnostica supporti logici (attuale diagnostica formale)

3b.Costruzione del messaggio XML (contiene i riferimenti applicativi al file)

5.Spedizione file+messaggio

6.Ricezione dalla rete di ok di trasmissione file+messaggio

3c.Diagnostica messaggio XML

7.Attesa risposta applicativa stato avanzamento/errori rilevati

4.Verifica coerenza file-messaggio


Figura 5 – Processo invio “messaggio + file” Rispetto alle procedure oggi in essere, la Banca Destinataria dovrà gestire un processo con i seguenti passi:

Titolo:


Codice


00.07.09



Data

09-07-2010

Pagina

17/59





3: Verifica omogeneità file e coerenza file-messaggio

Errori rilevati4: Invio messaggio di errore4: Invio messaggio di erroreSI

NO

6: Diagnostica supporti logici (diagnostica attuale formale)


7: Predisposizione stato avanzamento/ errori

rilevati


rilevati


errori rilevati


errori rilevati


Figura 6 – Processo ricezione “messaggio + file” 2.3.1 Regole per la creazione del supporto logico Gli standard previsti per la creazione del supporto logico sono quelli già in essere per gli attuali Servizi CBI. In particolare si confermano i criteri di omogeneità definiti per la creazione del supporto. 2.3.2 Regole per la creazione del file All’interno di un file fisico la Banca può1, discrezionalmente, inserire uno o più supporti logici. I supporti logici devono essere omogenei per:

1 Per lo scambio di flussi informativi tra Banche si raccomanda la minimizzazione del numero di file fisici (per ragioni legate alla performance). In particolare, per quanto riguarda i flussi informativi destinati alla Clientela la Banca Passiva è tenuta ad operare con criteri di omogeneità per Banca Proponente/Destinataria.

Titolo:


Codice


00.07.09



Data

09-07-2010

Pagina

18/59

- tipo supporto (es. “PC”, “RH”); - destinatario “logico” (es. Banca Passiva per i flussi “PC”, Banca Proponente per i flussi “RH”); - soggetto di riferimento del destinatario “logico” (es. STD, GPA); - indirizzo di Rete Logica del soggetto di riferimento; - applicazione della firma digitale. Per i file contenenti supporti logici non firmati, il numero massimo di supporti logici da includere nel file “fisico” è fissato a 1500. Tale limite garantisce che i successivi messaggi di stato avanzamento abbiano una dimensione massima di 1 MB. Per i file contenenti supporti logici firmati, il numero massimo degli stessi (comunque non superiore a 1500) non è definito a priori ma è in funzione del rispetto della dimensione di 1 MB del messaggio di accompagnamento del file dove i supporti logici sono referenziati e dove è presente – codificata in base64 – la busta contenente la firma digitale. Si osserva che, alla data, la rete logica CBI non consente la veicolazione di file la cui dimensione superi 2GB (cfr. specifiche del fornitore di rete), pertanto l’aggregazione dei supporti logici nei file deve essere effettuata tenendo in considerazione anche tale limite. Si evidenzia come, in funzione delle informazioni di indirizzamento disponibili a ciascuna Banca, le attività di predisposizione del file potranno prevedere uno o più accessi al Directory al fine di verificare il rispetto dei criteri di omogeneità definiti. Per semplicità di rappresentazione tali accessi non sono riportati sui diagrammi ma possono essere derivati direttamente da quanto su di essi riportato (cfr. Punti 8-9-10 del sequence diagram o punti 8-9-10-11 dell’activity diagram). Al fine di semplificare la verifica d’integrità del file, l’ordine dei supporti logici che lo costituiscono dovrà essere lo stesso di quello riportato nel messaggio XML (Cfr. Par. 2.3.3.2 per i dettagli) e la corrispondenza tra i campi “Nome supporto” nel messaggio XML e nel file dovrà essere di tipo 1:1. In particolare, il file dovrà iniziare con il record di testa del primo supporto logico referenziato dal messaggio XML e terminare con il record di coda dell’ultimo (Cfr. Standard Tecnici attuali servizi CBI per le regole di composizione dei record di testa/coda). L’assegnazione del “Nome supporto” dovrà inoltre rispettare i criteri di univocità definiti (univocità per “Nome supporto”, “Tipologia flusso”, “Data creazione”, “Mittente” e “Destinatario”) con un periodo di “storico” pari a 180 giorni di calendario. In considerazione del fatto che non esiste alcuna correlazione tra la data di creazione del supporto logico e la data in cui lo stesso è effettivamente inviato alla controparte, la verifica di univocità deve essere effettuata nell’ambito dei 180 giorni di calendario precedenti alla data in cui il controllo stesso è effettuato dalla banca e/o soggetto tecnico delegato e non alla data di creazione del supporto logico. Sebbene il periodo entro il quale si deve effettuare il controllo di univocità delle chiavi identificative sia di 180 giorni di calendario, si raccomanda di garantire l’univocità dei supporti logici per un periodo più ampio al fine di facilitare eventuali attività di storicizzazione e riconciliazione degli stessi anche a lungo termine.

Titolo:


Codice


00.07.09



Data

09-07-2010

Pagina

19/59

2.3.2.1 Esempi sui criteri di omogeneità Di seguito vengono mostrati alcuni esempi sull’applicazione dei criteri di omogeneità sui supporti logici. Esempio

Scenario File da predisporre

Flusso SL1 da Banca Passiva BS1 ad Azienda AZ1 AZ1 ha come Banca Proponente BR2 BR2 si avvale dei servizi della STD STD1 per erogare i servizi ad AZ1

File 1

Flusso SL2 da Banca Passiva BS1 ad Azienda AZ2 AZ2 ha come Banca Proponente BR2 BR2 si avvale dei servizi della STD STD2 per erogare i servizi ad AZ2

File 2

Nel caso in cui BS1 produca un unico file fisico contenente i supporti logici SL1 ed SL2, uno dei due sarebbe recapitato al destinatario fisico errato, anche se la Banca Proponente indicata è la stessa. 2.3.3 Regole per la creazione del messaggio La Banca deve creare il messaggio XML secondo i criteri e gli standard già previsti per i nuovi Servizi CBI. Si faccia riferimento alla relativa documentazione per le specifiche di dettaglio (cfr. “STPG-MO-001 Nuovi Servizi - Parte Generale”); nel seguito del paragrafo vengono riportate le considerazioni specifiche per il servizio “Porting”. 2.3.3.1 Creazione “Header di E2E di Servizio” In linea con quanto già descritto nel documento “STPG-MO-001 - Nuovi Servizi Parte Generale”, le regole di composizione dell’Header E2E di Servizio per il servizio Porting prevedono che il destinatario “logico” di un flusso Banca/Cliente sia la Banca Proponente dell’Azienda, la quale provvederà poi a disaggregare i flussi in base al Codice SIA dell’Azienda. In modo analogo, il mittente “logico” previsto nella tratta Cliente/Banca è la Banca Proponente dell’Azienda, che provvederà in questo caso ad aggregare i flussi diretti verso la stessa Banca Passiva. Di seguito vengono mostrati alcuni scenari esemplificativi, in cui: AZ1 è un Cliente CBI della Banca Proponente BR1 BR1 accede alla NACBI mediante un GPA GPA1 (in alternativa si può prevedere una STD STD1) BS1 è una Banca Passiva ed accede alla NACBI mediante un GPA GPA2 (in alternativa si può prevedere

una STD STD2)

Scenario Hdr Campi Richiesta di Servizio

Mittente Fisico CUC GPA1 Header di Tratta Destinatario Fisico CUC GPA2

Mittente Logico CUC BR1 Tipo SdR Mittente GPA Id SdR Mitt CUC GPA1 Destinatario Logico CUC BS1 Tipo SdR Destinatario GPA

Flussi diretti da Azienda AZ1 a Banca Passiva BS1

Header E2E

Id SdR Dest CUC GPA2

Titolo:


Codice


00.07.09



Data

09-07-2010

Pagina

20/59

Scenario Hdr Campi Richiesta di Servizio

Mittente Fisico CUC GPA2 Header di Tratta Destinatario Fisico CUC GPA1

Mittente Logico CUC BS1 Tipo SdR Mittente GPA Id SdR Mitt CUC GPA2 Destinatario Logico CUC BR1 Tipo SdR Destinatario GPA

Flussi diretti da Banca Passiva BS1 ad Azienda AZ1

Header E2E

Id SdR Dest CUC GPA1 2.3.3.2 Creazione “Body di Servizio” In Allegato C sono riportate le specifiche per la strutturazione del “Body di servizio“ unitamente alla descrizione dello schema XML. Nella costruzione del messaggio, l’ordine dei supporti logici referenziati (campo “Nome supporto”) dovrà essere lo stesso di quello riportato nel file. Si evidenzia inoltre come ad ogni messaggio debba corrispondere uno ed un solo file fisico.

2.4 STATI DI AVANZAMENTO Il sequence diagram relativo al “Caso d’uso” descrive i messaggi XML scambiati tra Banca Mittente e Banca Destinataria durante l’esecuzione di una richiesta di Servizio. La Banca Mittente (es. Banca Proponente nel caso di “PORTING-PC”, Banca Passiva nel caso di “PORTING-RH”) invia un messaggio XML + file verso la Banca Destinataria (es. Banca Passiva nel caso di “PORTING-PC”, Banca Proponente nel caso di “PORTING-RH” – cfr. punto 12 sequence diagram) che provvede a: - eseguire la diagnostica del messaggio XML; - verificare l’omogeneità del file e la coerenza file-messaggio. Dopodiché, la Banca Mittente predispone e invia un primo messaggio di avanzamento/errori rilevati (cfr. punto 17) verso la Banca Mittente. Nel caso in cui il file sia stato ricevuto correttamente e l’associazione tra i supporti logici dichiarati nel messaggio XML e quelli contenuti nel file sia corretta, la Banca Destinataria esegue la diagnostica applicativa dei supporti logici (attuale diagnostica formale) e invia successivamente un secondo messaggio di avanzamento verso la Banca Mittente (cfr. punto 20). L’identificazione e la correlazione dei vari messaggi (richiesta di servizio più i 2 messaggi di stato avanzamento) necessaria per l’espletamento del servizio avviene attraverso il campo “Nome file” all’interno del blocco “Info file” (presente sia nel messaggio XML di richiesta di servizio sia nei messaggi XML di stato avanzamento), riportati nel “body di servizio” (Cfr. Allegato C per i dettagli). Si evidenzia altresì come ogni messaggio XML scambiato avrà sempre un proprio IDE2E univoco e distinto; in considerazione del fatto che l’IDT è legato all’IDE2E, ogni messaggio avrà un proprio IDT univoco e distinto. In particolare l'Header E2E del messaggio di risposta dovrà essere rigenerato in coerenza con il nuovo Header di Tratta, prevedendo un identificativo diverso, data diversa, soggetto mittente e ricevente invertiti rispetto al messaggio originario.

Titolo:


Codice


00.07.09



Data

09-07-2010

Pagina

21/59

Si faccia riferimento all’Allegato C per le specifiche di strutturazione del messaggio di “richiesta di servizio” e del relativo messaggio di “stato d’avanzamento”/“errori rilevati”. Nei seguenti paragrafi vengono descritti, in dettaglio, i controlli da eseguire per l’invio dei 2 messaggi di avanzamento, unitamente alle regole da seguire per la loro composizione. 2.4.1 Controlli e regole di composizione del 1° messaggio di avanzamento Ricevuto il file + messaggio XML dalla Banca Mittente, la Banca Destinataria dovrà eseguire i seguenti controlli: Diagnostica messaggio XML (parsing)2 Verifica coerenza messaggio/file:

- verifica congruenza e omogeneità dei supporti logici in base a quanto dichiarato nel messaggio XML: o coerenza tag “Nome servizio” (cfr. Header di Tratta e Header di Servizio – es. “PORTING-

PC”) e tag “Tipologia flusso” (es. “PC”); in questo caso l’errore riguarda una incoerenza all’interno del messaggio XML e verrà segnalato attraverso il messaggio d’errore “general purpose” (cfr. Par. 4.4.4);

o coerenza dei tag “Nome servizio”, “Tipologia flusso” (presenti nel messaggio XML) e dei campi “tipo record” riportati nel record di testa di tutti i supporti logici contenuti nel file

- verifica di coerenza tra i supporti logici referenziati nel messaggio XML e quelli contenuti nel file, mediante confronto tra campi secondo quanto riportato nella seguente tabella:

Flussi da Banca Proponente a Banca Passiva

Messaggio XML Record di testa del supporto logico <SIACd> mittente (pos. 4-8) <ABICd> ricevente (pos. 9-13) <CreDt> data creazione (pos. 14-19) <SppNm> nome supporto (pos. 20-39)

Flussi da Banca Passiva a Banca Proponente Messaggio XML Record di testa del supporto logico <SIACd> ricevente (pos. 9-13) <ABICd> mittente (pos. 4-8) <CreDt> data creazione (pos. 14-19) <SppNm> nome supporto (pos. 20-39)

Per i soli flussi dispositivi, verifica coerenza tra Codice ABI della Banca (Banca Passiva) contenuto in ogni blocco “Info supporto” del messaggio XML e CUC della Banca Destinataria (Banca Passiva) riportato nell’Header di Servizio3. Si fa notare come tale controllo garantisca l’omogeneità dei supporti logici relativamente al destinatario “logico” cui gli stessi sono indirizzati (Banca Passiva)

Verifica omogeneità dei supporti logici per “soggetto di riferimento” del destinatario logico (STD/GPA) Verifica omogeneità dei supporti logici relativamente all’utilizzo della firma digitale e alla tipologia di

firma utilizzata (valore del tag <SngTyp>). (cfr. paragrafo 7.2)

2 Ad eccezione di casi particolari di errore (segnalati attraverso il primo messaggio di stato avanzamento), a fronte del riscontro di errori di parsing nel messaggio XML, viene inviato un messaggio di errore “general purpose” descritto nel documento “Nuovi Standard Tecnici – Parte generale”. In caso di errori non previsti dal workflow del servizio (es. errori di accesso al messaggio XML, etc.), l’errore dovrà essere comunque segnalato utilizzando il messaggio “general purpose” descritto nel documento “Nuovi Standard Tecnici – Parte generale”. 3 Tale controllo non è previsto nel caso di ricezione di flussi informativi nell’ambito della tratta Banca Passiva – Cliente.

Titolo:


Codice


00.07.09



Data

09-07-2010

Pagina

22/59

Per i soli flussi firmati digitalmente, controllo del mittente fisico per accertarsi che lo stesso risulti abilitato dal CBI all’immissione in rete di supporti logici firmati con la specifica tipologia di firma (cfr. paragrafo 7.1)

Nel caso di esito positivo dei suddetti controlli (ossia supporti logici referenziati dal messaggio XML in corrispondenza 1:1 con quelli presenti nel file, il quale termina dopo l’ultimo supporto logico referenziato nel messaggio XML), le regole di composizione del messaggio 17 prevedono l’invio verso la Banca Mittente di un messaggio contenente solo il blocco di informazioni “Info file” con stato “Ricevuto” (Cfr. Appendice C per i dettagli). In caso di esito negativo di tali verifiche, il file viene scartato e il workflow della Banca Destinataria si chiude con l’invio del messaggio 17 costruito come segue: In caso di errori rilevati sul file:

- blocco “Info file” presente, con stato “Errori rilevati” (+ codice d’errore specifico); - blocco “Info supporto” assente

In caso di errori rilevati sul supporto logico: - blocco “Info file” presente, con stato “Errori rilevati” (+ codice d’errore specifico); - blocco “Info supporto” presente, con stato “Errori rilevati” (+ codice d’errore specifico)

Relativamente alle regole di costruzione del messaggio 17, si evidenzia che: In caso di disallineamento tra messaggio XML e file, si fa riferimento a quanto riportato nel messaggio

XML per la rilevazione e la segnalazione degli errori In caso di errore sul singolo supporto logico, dovrà essere segnalato solo il 1° errore rilevato (una sola

occorrenza del blocco “SendSts” nel messaggio 17) Il sequence diagram che segue mette in evidenza i possibili stati d’avanzamento del file e dei supporti logici inclusi nel messaggio 17 di risposta.



12: Invio file+messaggio

XML FileXML File

16: Predisposizione messaggio di avanzamento / di errore

XML


17: Invio messaggio stato avanzamento (OK) / errori rilevati (KO)

14: Diagnostica messaggio XML (vedi 6)15: Verifica omogeneitàfile e coerenza file-messaggio (vedi 3 e 5)

1°

me

ss

agg

io

Stato avanzamento file

Ricevuto Errori rilevati

- Errore diagnostica msg XML- File non trovato- File inutilizzabile- Limite massimo supporti logici superato- Supporti non omogenei, non corrisp. o

inutilizzabili

Stato avanzamento supporti logici

Errori rilevati- Supporto non omogeneo per “tipologia

flusso”- Supporto non omogeneo per “destinatario”- Supporto non omogeneo per “applicazione

firma digitale”- Supporto non presente nel file- Supporto non presente nel msg XML- Supporto logico inutilizzabile- ABI e CUC Banca Passiva non coerenti

Se disponibili le informazioni sui supporti logici

La tabella riportata di seguito mostra, per ogni stato d’avanzamento relativo al file, i possibili stati di avanzamento inerenti i supporti logici.

Titolo:


Codice


00.07.09



Data

09-07-2010

Pagina

23/59

Stato avanzamento file Stato avanzamento singoli supporti logici (Cfr. blocco “Info supporto”)

Ricevuto BLOCCO DI INFORMAZIONE ASSENTE Errori rilevati

- Errore diagnostica msg XML - File non trovato - File inutilizzabile - Limite massimo supporti logici

superato

BLOCCO DI INFORMAZIONE ASSENTE

Errori rilevati - Supporti non omogenei, non

corrispondenti o inutilizzabili

Errori rilevati - Supporto non omogeneo per “tipologia

flusso” - Supporto non omogeneo per “destinatario” - Supporto non omogeneo per “applicazione

firma digitale” - Supporto non presente nel file - Supporto non presente nel msg XML - Supporto logico inutilizzabile - ABI e CUC Banca Passiva non coerenti

Come specificato, in caso di disallineamento tra messaggio XML e file, si deve fare riferimento al messaggio XML. In caso di errore sul controllo di corrispondenza si possono verificare 2 casi: se il supporto logico è presente nel messaggio XML ma non è presente nel file, nel blocco "Info supporto"

del messaggio 17 si indica il "nome supporto" riportato nell'XML, specificando il codice d'errore "Supporto non presente nel file"

se il supporto logico è presente nel file ma non è presente nel messaggio XML, nel blocco "Info supporto" del messaggio 17 si indica il "nome supporto" riportato nel file, specificando il codice d'errore "Supporto non presente nel msg XML".

2.4.2 Controlli e regole di composizione del 2° messaggio di avanzamento

In caso di esito positivo di tutti i controlli previsti per il messaggio 17, la Banca Destinataria esegue la diagnostica applicativa dei supporti logici (attuale diagnostica formale e verifica della firma digitale4 se presente) e invia il relativo messaggio di avanzamento (cfr. punto 20 del sequence diagram), costruito come segue: Blocco “Info file” presente, con stato “Ricevuto” Una occorrenza del blocco “Info supporto” per ogni supporto logico rilevato nel file, con stato

“Diagnostica supporto logico OK”/”Errori rilevati (+ dettagli errore) Per i soli flussi informativi non indirizzati verso Market Place5, in aggiunta alla diagnostica applicativa e ai fini della generazione del 2° messaggio di avanzamento, la Banca Destinataria deve, per ogni supporto logico, effettuare il controllo di congruenza tra la Banca Proponente (ricavata dal codice SIA destinatario) e il destinatario logico (Banca Proponente) dichiarato nell’apposito campo presente nell’Header di Servizio del messaggio XML. I soli supporti per i quali tale controllo restituisce esito negativo devono essere scartati utilizzando l’apposito codice di errore 058 (Banca Proponente non coerente con anagrafica clienti) .

4 Si rimanda al paragrafo 7 per dettagli sulle modalità di composizione del 2° messaggio di stato avanzamento in caso di errore nella verifica della firma 5 Si rammenta che i flussi indirizzati verso Market Place sono riconoscibili da specifici valori presenti in appositi campi contenuti nel record di testa dei supporti logici

Titolo:


Codice


00.07.09



Data

09-07-2010

Pagina

24/59

I soli supporti per i quali il codice SIA destinatario non risulti censito nell’anagrafica di riferimento (nodo cliente assente sul Directory) devono essere scartati utilizzando l’apposito codice di errore 042 (soggetto non aderente)6. In caso di errori rilevati, dovranno essere segnalati da 1 a 3 errori (+ dettagli errore) per ciascun supporto logico. Il sequence diagram che segue mette in evidenza i possibili stati d’avanzamento del file e dei supporti logici inclusi nel messaggio 20 di risposta.


18: Diagnostica applicativa supporti logici (diagnostica attuale formale)20: Invio messaggio stato

avanzamento(OK)/ errori rilevati(KO)19: Predisposizione stato avanzamento/ errori rilevati

Ricevuto Diagnostica supporto logico ok Errori rilevati

- Errori su supporto logico (+ Dettagli errore)2°m

essa

gg

io

Per quanto riguarda invece il messaggio sullo stato d’avanzamento al punto 20 del sequence diagram, lo stato di avanzamento file sarà sempre “Ricevuto”, come riportato di seguito.

Stato avanzamento file Stato avanzamento supporti logici

Ricevuto Diagnostica supporto logico ok Errori rilevati

- Errori su supporto logico (+ dettagli errore)

2.5 CONSIDERAZIONI SU INVIO SUPPORTI LOGICI “F4”, “R4” A seguito della ricezione di un flusso F4 o di un flusso R4, la Banca Destinataria (Banca Passiva) dovrà comportarsi come segue:

predisporre ed inviare il messaggio 20 (Cfr. sequence diagram) dopo aver eseguito i controlli attualmente in carico ai Soggetti Veicolatori (messaggio obbligatorio); in funzione del risultato di tali controlli, potrà verificarsi uno dei tre scenari riportati:

1. Nessun errore riscontrato a fronte dei controlli attualmente in carico ai Soggetti Veicolatori e nessun

errore riscontrato dalla Banca Passiva a seguito dei propri controlli applicativi su tutti i campi dei supporti logici:

la Banca Destinataria invia il messaggio 20 dove non si segnala alcun errore; la Banca Destinataria esegue gli attuali controlli “Banca Passiva” e predispone il flusso A4, in

accordo alle attuali regole, senza segnalare alcun errore; la Banca Destinataria invia il flusso A4 attraverso il servizio “PORTING-A4”, inclusi i messaggi

di stato d’avanzamento previsti

6 Per la lista completa dei codici di errore disponibili si faccia riferimento al documento CBI-STD-001

Titolo:


Codice


00.07.09



Data

09-07-2010

Pagina

25/59

2. Nessun errore riscontrato a fronte dei controlli attualmente in carico ai Soggetti Veicolatori ed errori

riscontrati dalla Banca Passiva a seguito degli attuali controlli “Banca Passiva”: la Banca Destinataria invia il messaggio 20 dove non si segnala alcun errore; a seguito di errori riscontrati a fronte dei controlli “Banca Passiva” predispone il flusso A4, in

accordo alle attuali regole, con la segnalazione degli errori; la Banca Destinataria invia il flusso A4 attraverso il servizio “PORTING-A4”, inclusi i messaggi

di stato d’avanzamento previsti

3. Riscontro di errori a fronte dei controlli attualmente in carico ai Soggetti Veicolatori:

gli attuali controlli in carico ai Soggetti Veicolatori passano in carico alla Banca Destinataria; la Banca Destinataria invia sempre un messaggio 20 con “esito positivo” e prosegue con le

elaborazioni successive (Cfr. Par. 6.3 documento CBI-F24-001); solo in caso di supporti logici duplicati o incongruenze tra tipo record di testa e tipo record di coda, la Banca Destinataria dovrà generare un messaggio 20 con la segnalazione dell’errore senza proseguire con le elaborazioni successive;

la Banca Destinataria, tranne che in caso di supporti logici duplicati, dovrà sempre generare un flusso “A4”, attraverso il servizio “PORTING-A4”, sia in caso di esito positivo che in presenza di errori.

2.6 CONSIDERAZIONI SU INVIO SUPPORTI LOGICI “Q4”, “A4” A seguito della ricezione di un flusso Q4 o A4, la Banca Destinataria (Banca Proponente) dovrà comportarsi come segue:

predisporre ed inviare il messaggio 20 (Cfr. sequence diagram) dopo aver eseguito i controlli attualmente in carico ai Soggetti Veicolatori (messaggio obbligatorio)7; in funzione del risultato di tali controlli, potrà verificarsi uno dei tre scenari riportati:

1. Nessun errore riscontrato a fronte dei controlli attualmente in carico ai Soggetti Veicolatori e nessun

errore riscontrato dalla Banca Proponente a seguito dei propri controlli applicativi su tutti i campi dei supporti logici:

la Banca Destinataria invia il messaggio 20 dove non si segnala alcun errore

2. Nessun errore riscontrato a fronte dei controlli attualmente in carico ai Soggetti Veicolatori ed errori riscontrati dalla Banca Ricevente a seguito degli attuali controlli “Banca Proponente”:

la Banca Destinataria invia il messaggio 20 dove non si segnala alcun errore; a seguito di errori riscontrati a fronte dei controlli “Banca Proponente” la banca segnala

l’errore attraverso il Tavolo Operativo.

3. Riscontro di errori a fronte dei controlli attualmente in carico ai Soggetti Veicolatori: gli attuali controlli in carico ai Soggetti Veicolatori passano in carico alla Banca Destinataria; la Banca Destinataria invia un messaggio 20 con la segnalazione dell’errore senza proseguire

con le elaborazioni successive.

7 Se il flusso risulta illeggibile, si invia un apposito messaggio di errore “general pur pose”

Titolo:


Codice


00.07.09



Data

09-07-2010

Pagina

26/59

2.7 CONSIDERAZIONI SU INVIO SUPPORTI LOGICI “I4” La veicolazione dei flussi “I4” (pagamento di deleghe F24 Internet) sulla Nuova Architettura CBI avviene secondo le stesse regole previste per gli altri servizi “Porting” (cfr. sequence diagram Par. 2.2.1.1). Come illustrato nel sequence diagram di riferimento, il 2° messaggio di stato avanzamento (20) viene predisposto in seguito alla diagnostica applicativa. Tuttavia, a differenza degli altri servizi “Porting”, nel caso dei flussi “I4”, al fine di predisporre il 2° messaggio di stato avanzamento (20), la Banca Destinataria (Passiva) dovrà effettuare unicamente i controlli previsti per il “record di testa”; in caso di esito negativo degli stessi, la Banca Destinataria (Passiva) segnalerà gli errori attraverso il messaggio 20.

Titolo:


Codice


00.07.09



Data

09-07-2010

Pagina

27/59

3 Diagnostica Al fine di garantire la correttezza dei flussi (messaggi e file/supporti) veicolati, ciascuna Banca dovrà implementare un processo di diagnostica per la verifica di file e messaggi. La segnalazione di eventuali problemi/errori riscontrati dovrà avvenire attraverso il messaggio XML “Stato di avanzamento” (cfr. Capitolo 2.4), come illustrato dal sequence diagram del servizio. Le segnalazioni di errore non previste dal workflow di servizio dovranno essere effettuate utilizzando il messaggio standard di “segnalazioni errori” descritto nel documento “STPG-MO-001 - Nuovi Servizi Parte Generale”.

3.1 DIAGNOSTICA SUL MESSAGGIO Relativamente ai controlli sul messaggio, la Banca deve effettuare i controlli sulla strutturazione del messaggio XML e quelli sui singoli tag del messaggio stesso secondo i criteri e gli standard già previsti per i nuovi Servizi CBI (Cfr. Allegato STAA-ST-00Y per i dettagli sui controlli da effettuare).

3.2 DIAGNOSTICA SUL FILE I controlli da effettuare riguardano il rispetto delle regole di creazione del file descritte al Par. 2.3.1.2 (es. criteri di omogeneità).

3.3 DIAGNOSTICA SUL SUPPORTO LOGICO I controlli da effettuare sul supporto logico (diagnostica applicativa) sono quelli previsti dagli attuali standard tecnici CBI che prevedono controlli di tipo “V” (validità) e di tipo “F” (formali), per la definizione dei quali si rimanda al documento CBI-STD-001 in vigore alla data.

Titolo:


Codice


00.07.09



Data

09-07-2010

Pagina

28/59

4 Regole di governance Al momento della ricezione del file + messaggio XML, deve essere fatto oggetto di controllo: - l’univoca correlazione tra messaggio e file fisico (corretto puntamento tra messaggio e file); - l’omogeneità dei supporti logici all’interno del file fisico8; - la corrispondenza 1:1 tra i supporti logici contenuti nel file e quelli contenuti nel messaggio XML (l’ordine

dei supporti logici riportato nel file deve essere lo stesso di quello riportato nel messaggio XML – Cfr. Par. 2.3.2).

Nel caso in cui vengano segnalati degli errori nella prima fase delle verifiche (diagnostica messaggio XML e coerenza file-messaggio) segnalati con il 1° messaggio di avanzamento (cfr. punto 17 sequence diagram), l’elaborazione sul ricevente si interrompe ed il 2° messaggio di stato di avanzamento non viene generato. In particolare, nel caso in cui il 1° messaggio di avanzamento riporti un errore (AdvSts diverso da RCVD), il file si intende rifiutato dal ricevente e nessuno dei supporti logici in esso contenuto sarà oggetto di ulteriore processing da parte del ricevente stesso; solo nel caso in cui il 1° messaggio di stato di avanzamento riporti un esito di ricezione positiva del file (AdvSts pari a RCVD), il file si intende ricevuto da parte del destinatario, il quale procederà alla esecuzione del diagnostico attuale sui supporti logici contenuti. Durante l'esecuzione della diagnostica applicativa il 2° messaggio di avanzamento riporterà sempre il medesimo stato di ricevuto per il file (AdvSts pari a RCVD); relativamente ai supporti logici, quelli rifiutati (AdvSts pari a ERRR con la codifica del codice dell’errore rilevato) non subiranno alcun ulteriore processing da parte del ricevente mentre i supporti logici accettati (AdvSts pari a RCVD) verranno sottoposti all'esecuzione dell'opportuno processo elaborativo.

4.1 MANCATO RISPETTO DELLE TEMPISTICHE DI INVIO DEI MESSAGGI DI AVANZAMENTO Relativamente alle tempistiche di invio dei messaggi di avanzamento (Cfr. Capitolo 6 per i dettagli sugli SLA), si assume che: - la ricezione di ACK19 rappresenta per il mittente una garanzia sulla consegna da parte della Rete - l’orologio di riferimento per la misura degli SLA è rappresentato dalla giornata applicativa In particolare, nel caso in cui non si riceva uno dei messaggi di avanzamento previsti (cfr. punto 17/20 del sequence diagram) all'interno degli SLA definiti per il servizio, il Mittente deve intraprendere le seguenti azioni:

segnalazione al Performance Management invio notifica al Tavolo Operativo che dovrà attivare le segnalazioni necessarie (es. una per ogni

Destinatario, al termine della giornata applicativa, comprendente la descrizione delle anomalie) la richiesta di servizio sarà considerata inoltrata e ad esecuzione ritardata. A riguardo viene

effettuata un'ulteriore segnalazione al Performance Management il mittente dovrà essere in grado di gestire eventuali messaggi inviati in ritardo per almeno 5 giorni

lavorativi; oltre tale limite il workflow di servizio potrà essere considerato chiuso e il mittente non sarà obbligato a gestire ulteriori messaggi ricevuti

non sarà necessario il rinvio dei flussi per la risoluzione dei problemi, il mittente potrà attivarsi con SIA in caso di mancata ricezione di

ACK210, e con la Banca in caso di ricezione di ACK2.

8 Cfr. paragrafo 2.3.2. 9 Conferma di presa in carico del messaggio XML + file, inviata alla Banca Mittente dal proprio nodo (Cfr. documentazione SIA per i dettagli) 10 Notifica di recapito di messaggio XML + file, inviata dal nodo della Banca Destinataria alla Banca Mittente (Cfr. documentazione SIA per i dettagli)

Titolo:


Codice


00.07.09



Data

09-07-2010

Pagina

29/59

4.2 MANCATO RISPETTO DELLA SEQUENZA DI INVIO DEI MESSAGGI DI AVANZAMENTO Nel caso di mancato rispetto, da parte della Banca Destinataria, della sequenza d’invio dei messaggi di avanzamento (cfr. punti 17 e 20 sequence diagram), la Banca Mittente dovrà:

chiudere il workflow applicativo in base alle informazioni contenute nel messaggio 20 ignorare il messaggio 17 ricevuto fuori sequenza (o in ritardo, anche se all’interno degli SLA) segnalare il mancato rispetto della sequenza di invio o la mancata ricezione del messaggio 17 al

Performance Management

4.3 CASI SPECIFICI DI ERRORE 4.3.1 File non trovato Nel caso in cui la Banca Destinataria non riesca a recuperare il file referenziato dal messaggio, dovrà:

Inviare una segnalazione alla Banca Mittente utilizzando il messaggio di avanzamento previsto (Cfr. Punto 17 del sequence diagram)

Eseguire una segnalazione al Performance Management

In caso di evidenza di errori derivanti dall’utilizzo del sincronizzatore, la Banca Destinataria dovrà inoltre provvedere a contattare la SIA per definire le modalità di risoluzione del problema. 4.3.2 Non omogeneità dei supporti logici Nel caso in cui la Banca Destinataria rilevi supporti logici non omogenei, la richiesta di Servizio deve essere considerata come non completa. La Banca Destinataria dovrà inviare un messaggio di stato d’avanzamento (cfr. punto 17 sequence diagram) riportante l’errore “Supporti non omogenei”. Oltre a ciò, obbligatorio, il Tavolo Operativo della Banca Destinataria potrà mettersi in comunicazione – tramite canali alternativi – con il Tavolo Operativo della Banca Mittente per la gestione dell’evento. A fronte del messaggio riportante l’errore, la Banca Mittente dovrà inviare nuovamente la richiesta di servizio. 4.3.3 Supporti logici non referenziati Nel caso in cui si rilevino incongruenze tra le referenze all’interno del messaggio ed i supporti logici contenuti nel file fisico (o viceversa), la richiesta di Servizio deve essere considerata dalla Banca Destinataria come non completa. In accordo alle regole di composizione del messaggio di avanzamento 17 (cfr. Par. 2.4.1), la Banca Destinataria dovrà inviare un messaggio di stato d’avanzamento (cfr. punto 17 sequence diagram) riportante l’errore/i: - “Supporto logico non presente nel file” unitamente all’indicazione del supporto logico referenziato

all’interno del messaggio, ma non presente nel file fisico; - “Supporto logico non presente nel messaggio XML” unitamente all’indicazione del supporto logico

presente nel file fisico, ma non referenziato all’interno del messaggio XML.

Titolo:


Codice


00.07.09



Data

09-07-2010

Pagina

30/59

Oltre a questa modalità, obbligatoria, il Tavolo Operativo del Destinatario potrà mettersi in comunicazione – tramite canali alternativi – con il Tavolo Operativo del Mittente per la gestione dell’evento. A fronte del messaggio riportante l’errore, la Banca Mittente dovrà inviare nuovamente la richiesta di servizio. 4.3.4 Errori di diagnostica applicativa su alcuni supporti logici Nel caso in cui si rilevino errori su alcuni supporti logici contenuti nel file fisico durante la fase di diagnostica applicativa dei supporti logici (cfr. punto 18 sequence diagram), la richiesta di Servizio verrà comunque processata dalla Banca Destinataria. In particolare, la Banca Destinataria proseguirà l’elaborazione per i supporti logici corretti, segnalando quelli diagnosticati correttamente e quelli su cui sono stati rilevati errori (+ dettagli sull’errore – Cfr. struttura messaggio d’avanzamento).

4.4 CASI GENERALI DI ERRORE 4.4.1 Non univocità della correlazione file-messaggio Nel caso di correlazione file-messaggio non univoca (es. duplicazione IUF), la richiesta di Servizio deve essere considerata dalla Banca Destinataria come non completa. La Banca Destinataria dovrà inviare un messaggio d’errore “general purpose” prevedendo un codice d’errore specifico “Correlazione file-messaggio non univoca”. Oltre a ciò, obbligatorio, il Tavolo Operativo della Banca Destinataria potrà mettersi in comunicazione – tramite canali alternativi – con il Tavolo Operativo della Banca Mittente per la gestione dell’evento. A fronte del messaggio riportante l’errore, la Banca Mittente dovrà inviare nuovamente la richiesta di servizio. 4.4.2 Messaggio ricevuto illeggibile Nel caso in cui il messaggio ricevuto risultasse illeggibile, la Banca Destinataria dovrà generare un messaggio d’errore “general purpose” (Cfr. Doc. “STPG-MO-001 Nuovi Servizi Parte Generale” per la descrizione della struttura del messaggio) prevedendo un codice d’errore specifico e inserendo le informazioni ricavabili dalla Rete Logica: - mittente fisico - destinatario fisico - UDR (User Data Remote) 4.4.3 Supporti logici duplicati Nel caso in cui la Banca Destinataria rilevi un supporto logico duplicato (secondo la chiave di univocità costituita dai campi: nome supporto, tipo supporto, data creazione, mittente e destinatario), dovrà trattare il primo e scartare il secondo, indipendentemente dal fatto siano contenuti in file fisici differenti.

Titolo:


Codice


00.07.09



Data

09-07-2010

Pagina

31/59

4.4.4 Incoerenza “Nome servizio” e “Tipologia flusso” nel messaggio XML Nel caso di incoerenza tra tag “Nome servizio” (cfr. Header di Tratta e Header di Servizio – es. “PORTING-PC”) e tag “Tipologia flusso” (es. “PC”) all’interno del “Body di Servizio”, la Banca Destinataria dovrà generare un messaggio d’errore “general purpose” prevedendo un codice d’errore specifico “Incoerenza tra le informazioni presenti nel messaggio XML”. A fronte del messaggio riportante l’errore, la Banca Mittente dovrà inviare nuovamente la richiesta di servizio. 4.4.5 Mancata corrispondenza nel 1° messaggio di avanzamento Nel caso in cui le informazioni riportate nel messaggio 17 (cfr. sequence diagram) non corrispondano con quelle indicati nel messaggio di richiesta (es. campo “Nome file” errato, “Tipologia flusso” non corrispondente - cfr. punto 12 sequence diagram), la Banca Mittente (cfr. par. 2.2.1 – “Attori identificati”) dovrà:

scartare il messaggio 17 inviato dalla Banca Destinataria inviare una segnalazione specifica al Tavolo Operativo attendere il messaggio 17 corretto (nel caso in cui il messaggio 17 corretto non venga inviato, ma

venga inviato il messaggio 20 corretto, il workflow viene comunque chiuso in base alle informazioni contenute nel messaggio 20 – cfr. Par. 4.2).

4.4.6 Mancata corrispondenza nel 2° messaggio di avanzamento Nel caso in cui i supporti logici referenziati nel messaggio 20 (cfr. sequence diagram) non siano in corrispondenza 1:1 con quelli indicati nel messaggio di richiesta (cfr. punto 12 sequence diagram), la Banca Mittente (cfr. par. 2.2.1 – “Attori identificati”) dovrà:

scartare il messaggio 20 inviato dalla Banca Destinataria inviare una segnalazione specifica al Tavolo Operativo attendere il messaggio 20 corretto per la chiusura del workflow applicativo (nel caso in cui il

messaggio 20 corretto non venga inviato, il workflow viene comunque chiuso dopo 5 giorni lavorativi)

Si precisa che nel messaggio 20 i supporti logici referenziati possono essere inseriti in un ordine differente rispetto a quello seguito nella richiesta di servizio corrispondente.

4.5 RECUPERO DEI FLUSSI IN CASO DI ERRORE 4.5.1 Errore imputabile al soggetto ricevente Nel caso in cui il Soggetto destinatario di una richiesta di servizio, a fronte della ricezione di un flusso corretto, lo considera errato a causa di un proprio errore applicativo, possono aversi tre scenari nei quali il ricevente:

1. chiude il workflow tramite l'invio di un messaggio di errore “general purpose” 2. risponde con un primo messaggio di stato avanzamento (msg 17) KO 3. risponde con un secondo messaggio di stato avanzamento (msg 20) KO per un errore di anagrafica

o diagnostica I tre diversi scenari sono accomunati dal fatto che il ricevente ha in ogni caso a disposizione il flusso corretto e può pertanto procedere al suo recupero.

Titolo:


Codice


00.07.09



Data

09-07-2010

Pagina

32/59

In questi casi il recupero dei supporti logici rimane in carico, salvo diverso accordo tra le parti, al ricevente, ovvero all'attore che ha commesso l'errore. Il recupero deve comunque essere frutto di una azione congiunta tra le parti secondo le modalità operative di seguito illustrate in dipendenza del soggetto che per primo rileva l'errore. Nel caso in cui l’anomalia venga inizialmente rilevata dal ricevente, lo stesso è tenuto ad informare la controparte, tramite l'invio di una mail al Tavolo Operativo ed in tempi compatibili con i livelli di servizio associati all'erogazione del servizio oggetto di errore. In ogni caso il processo di gestione (recupero/rispedizione/blocco definitivo del flusso) dei dati deve essere preliminarmente concordato con il mittente. Qualora il ricevente, in accordo con la controparte, proceda al recupero del flusso, deve informare il mittente (mediante apposita mail inviata al Tavolo Operativo) circa i tempi necessari per modificare le proprie applicazioni e sanare l'anomalia. Se, di contro, è il mittente che per primo rileva l’errore, lo stesso deve informare via mail la controparte dell'errore riscontrato e, salvo contestazioni, può considerare che il destinatario provvederà con celerità al recupero dei dati e alla modifica delle applicazioni. La gestione del recupero dei flussi nella tratta tra Banca e Cliente, non rientrando nella sfera di competenza di ACBI, non può essere normata in sede associativa. 4.5.2 Errore imputabile al soggetto mittente In caso in cui un workflow si chiuda con un errore imputabile al mittente, è quest’ultimo che deve procedere al reinvio della richiesta di servizio tramite l’inoltro di una nuova richiesta che comporta obbligatoriamante: - la sistemazione delle cause di scarto - la generazione di nuovi identificativi univoci per la richiesta di servizio. Si precisa che il Mittente non è obbligato, nella rispedizione dei supporti logici corretti, a generare nuovi identificativi univoci per i supporti logici11. 4.5.3 Gestione delle contestazioni Nel caso in cui a seguito dell'interazione tra mittente e destinatario non si pervenga alla definizione delle responsabilità, le controparti devono attivare un processo di innalzamento della contesa che porti al coinvolgimento di ACBI. La Segreteria Tecnica, previa analisi dell’errore riscontrato, si farà carico della definizione delle responsabilità decidendo se l’errore sia imputabile al mittente o al ricevente. Il responsabile sarà quindi tenuto ad attivare il processo di recupero previsto.

11 Il controllo di univocità degli identificativi dei supporti logici è effettuato dal Ricevente solo a valle della generazione del 2° messaggio di avanzamento (20), riportante esito positivo della diagnostica. Pertanto, un supporto logico può essere scartato per “duplicato” solo a seguito della generazione del 2° messaggio di avanzamento (20), riportante esito positivo della diagnostica

Titolo:


Codice


00.07.09



Data

09-07-2010

Pagina

33/59

5 Individuazione indirizzo di erogazione del Servizio Porting Le modalità di indirizzamento dei messaggi/file sulla Nuova Architettura sono descritte nel documento “DIRECTORY-MO-001 Requisiti Directory”. Con riferimento alla struttura del Directory, si evidenzia come, esclusivamente per l’indirizzamento dei flussi Porting, gli attributi “Operatività CBI” e “Gestione eccezioni” del nodo Cliente non debbano essere controllati. Nel seguito del paragrafo vengono tuttavia riportate considerazioni specifiche relative alle modalità/regole di indirizzamento per la veicolazione degli attuali tracciati sulla Nuova Architettura (“Porting”). A riguardo, ciascuna Banca dovrà esporre nel Directory i servizi “porting” nello spazio dei nomi registrati da ACBI in appositi nodi di quarto livello, come di seguito indicato: Per i servizi esposti nel ruolo di Banca Passiva

i nodi relativi ai servizi esposti sono riportati sotto il nodo di terzo livello “ou=servizi non profilati”; i nomi dei Servizi da utilizzare (Cfr. blocco “Info sul servizio” dell’Header E2E) sono definiti in base

alla tipologia di supporto logico veicolato, come indicato nella tabella seguente:

Nome Servizio “cn=..” Descrizione PORTING-IR R.I.D. PORTING-IM M.AV PORTING-IB Ri.Ba PORTING-AL Allineamento Elettronico Archivi R.I.D. PORTING-PC Pagamento Italia PORTING-PE Bonifico Estero PORTING-AP Pagamento Effetti PORTING-AI Avviso Impagati PORTING-AB Pagamento Bollettino Bancario

PORTING-SL-D Struttura Libera da Utente (Dispositiva) PORTING-F4 Pagamento Deleghe F24 PORTING-I4 Pagamento Deleghe F24 Internet PORTING-R4 Revoca Deleghe F24

Per i servizi esposti nel ruolo di Banca Proponente

i nodi relativi ai servizi esposti sono riportati sotto i nodi di terzo livello relativi ai "servizi profilati", con i nomi dei profili definiti ed associati ai singoli nodi Azienda;

i nomi dei Servizi da utilizzare (Cfr. blocco “Info sul servizio” dell’Header E2E) sono definiti in base alla tipologia di supporto logico veicolato, come indicato nella tabella seguente:

Nome Servizio “cn=..” Descrizione PORTING-EIR Esito R.I.D. PORTING-EIM Esito M.AV PORTING-EIB Esito Ri.Ba PORTING-EAL Esito Allineamento Elettronico Archivi R.I.D. PORTING-BB Bollettino Bancario PORTING-EP Esito di pagamento PORTING-AV Avvisatura Effetti

Titolo:


Codice


00.07.09



Data

09-07-2010

Pagina

34/59

PORTING-RH Rendicontazione saldi e movimenti di c/c PORTING-RA Rendicontazione conti anticipi PORTING-EC Estratto conto periodico PORTING-DT Dossier Titoli PORTING-RP Rendicontazione di Portafoglio

PORTING-SL-I Struttura Libera da Banca (Informativa) PORTING-A4 Accettazione/Rifiuti Deleghe F24 PORTING-Q4 Quietanza Deleghe F24

Si evidenzia come, nel caso di flussi in cui sia presente il “qualificatore Marketplace”, l’indirizzamento si differenzia a seconda che le disposizioni originarie siano di pagamento o di incasso. In particolare:

esito disposizioni di pagamento (es. “PORTING-EP”): la Banca Passiva invia l’esito verso la Banca Gateway e l’indirizzo di Rete Logica a cui inviare l’esito viene trovato consultando il Directory nel ramo dei servizi della Banca Gateway, sotto il profilo specifico identificato dal Codice del Marketplace e presente nell’apposito campo contenuto nei supporti logici con le disposizioni di pagamento originarie. Tale codice è altresì presente all’interno dei supporti logici di esito (record 10, pos. 109-113). Ogni Banca Gateway ha infatti l’obbligo di esporre sul Directory uno specifico profilo per ogni marketplace servito, indicando nel nome del profilo il codice assegnato al marketplace stesso. La stringa identificativa del profilo servizio è fatta nel seguente modo: PROFILO MARKETPLACE XXXXX dove XXXXX rappresenta il codice assegnato al MP12 (cfr doc DIRECTORY-PO-001).

esito disposizioni di incasso (es. “PORTING-EIR”): la Banca Passiva invia l’esito verso la

Banca Proponente e l’indirizzamento del flusso di esito viene risolto consultando il Directory nel ramo dei servizi della Banca Proponente.

Si evidenzia come le modalità di indirizzamento sopra descritte si riferiscano soltanto agli “esiti” delle richieste provenienti da Marketplace; per l’indirizzamento dei messaggi di stato avanzamento si utilizza il campo “Return Address” indicato nell’Header di Tratta (cfr. Par. 4.1.1 documento “STPG-MO-001 - Nuovi Servizi Parte Generale”).

6 Livelli di servizio La veicolazione dei flussi dispositivi è soggetta ad un termine massimo generale di 30 minuti primi, avendo a riferimento la tratta Banca Mittente (“Banca Proponente”) – Banca Destinataria (“Banca Passiva”). Tale termine (attuativo del comma 10.2.5 delle Norme del Servizio) è calcolato avendo a riferimento i due momenti temporali di cui ai commi 10.2.6 e 10.2.7 delle Norme del Servizio. Si precisa al riguardo quanto segue:

1) Si definisce “ricezione” ai sensi del comma 10.2.6 l’istante in cui si verificano entrambe le condizioni seguenti: - il flusso inviato dal cliente è a completa disposizione della Banca Proponente; - il cliente ha autorizzato l’inoltro del flusso verso la Banca Passiva. Si osserva che la Banca Proponente è tenuta a comunicare l’istante di effettiva disponibilità dei flussi autorizzati all’invio, prima che sugli stessi vengano effettuate eventuali elaborazioni.

2) La “messa a disposizione” della Banca Passiva di cui al comma 10.2.7 prescinde dall’utilizzo della Rete CBI per la veicolazione dei flussi tra le due banche Mittente e Destinataria, per cui la previsione generale di tale comma è valida anche nel caso di flussi destinati ad una Banca Passiva attestata sul

12 Si precisa che non è consentito definire codici marketplace contenenti uno o più caratteri pari a “blank”.

ATTENZIONE: quanto evidenziato in giallo in questo paragrafo entra in vigore il 1° novembre 2010 (cfr. tabella delle revisioni)

Titolo:


Codice


00.07.09



Data

09-07-2010

Pagina

35/59

medesimo soggetto tecnico di cui si avvale la Banca Proponente e nel caso di coincidenza tra Banca Proponente e Banca Passiva.

3) Il termine temporale massimo è altresì calcolato avendo a riguardo l’effettiva disponibilità del Servizio, ovvero al netto degli orari ufficiali di chiusura e/o di eventi eccezionali e/o cause di forza maggiore.

La giornata applicativa per il servizio Porting rappresenta l’orologio di riferimento per la misura degli SLA: la trasmissione e la ricezione dei flussi va dal Lunedì al Sabato dalle ore 01:00 alle ore 23:00, eccetto festività nazionali previste. I livelli di servizio per il Servizio Porting sono stati definiti partendo dalla individuazione dei punti di rilevazione delimitanti l’inizio e/o fine di un intervallo temporale soggetto a controllo. Si precisa come tali punti di rilevazione coincidano solo con un sottoinsieme di quanto richiesto alle Banche, in termini di logging, a supporto del performance management e della governance. La figura seguente - a partire dalla sequenza di attività in carico alla Banca Destinataria ed esposta al Capitolo 2.3 del presente documento - evidenzia i punti di rilevazione identificati.







NO




rilevati


rilevati


errori rilevati


errori rilevati


1

2

3

Figura 7 – Punti di rilevazione – Banca Destinataria

In maggior dettaglio, i punti di rilevazione sono così definiti:

1) Completamento, con esito positivo, della chiamata “receive” alla Rete Logica per la ricezione di un file+messaggio;

Titolo:


Codice


00.07.09



Data

09-07-2010

Pagina

36/59

2) Presa in carico, con esito positivo, da parte della Rete Logica della chiamata “send” per l’invio di un messaggio;

3) Presa in carico, con esito positivo, da parte della Rete Logica della chiamata “send” per l’invio di un messaggio.

Le figura seguente mostra - a partire dalla sequenza di attività in carico alla Banca Destinataria ed esposta al Capitolo 2.3 del presente documento - gli intervalli significativi per le rilevazioni temporali e la denominazione ad essi associata.







NO




rilevati


rilevati


errori rilevati


errori rilevati


ΔT1 ΔT2

Figura 8 – Intervalli temporali soggetti a SLA – Banca Destinataria Per ciò che riguarda i flussi di carattere dispositivo inviati alla Banca Destinataria si è fissato il seguente intervallo massimo:

- T2 = entro 1 ora. Similmente, per quanto riguarda i flussi informativi, si sono definiti i seguenti intervalli temporali massimi:

- T1 = entro 1 ora; - T2 = entro 2 ore.

Gli intervalli sopra definiti hanno validità fino alla fine del Periodo di Transizione13, in seguito potranno essere ricalibrati subendo riduzioni.

13 Cfr. Circolare CBI 4/2005 del 16 giugno 2005.

Titolo:


Codice


00.07.09



Data

09-07-2010

Pagina

37/59

La figura seguente - a partire dalla sequenza di attività in carico alla Banca Mittente ed esposta al Capitolo 2.3 del presente documento - evidenzia i punti di rilevazione identificati.







NO




rilevati


rilevati


errori rilevati


errori rilevati


4

5

6

Figura 9 – Punti di rilevazione – Banca Mittente In maggior dettaglio, i punti di rilevazione sono così definiti:

4) Ricezione della “notify” di Rete Logica a seguito di richiesta di “send”, con esito positivo, di file+messaggio;

5) Completamento, con esito positivo, della “receive” di Rete Logica per la ricezione di un messaggio;

6) Completamento, con esito positivo, della “receive” di Rete Logica per la ricezione di un messaggio.

La figura seguente mostra - a partire dalla sequenza di attività in carico alla Banca Mittente ed esposta al Capitolo 2.3 del presente documento - gli intervalli significativi per le rilevazioni temporali e la denominazione ad essi associata.

Titolo:


Codice


00.07.09



Data

09-07-2010

Pagina

38/59

3a.Predisposizione e diagnostica file



2.Diagnostica supporti logici (attuale diagnostica formale)

3b.Costruzione del messaggio XML (contiene i riferimenti applicativi al file)

5.Spedizione file+messaggio

6.Ricezione dalla rete di ok di trasmissione file+messaggio

3c.Diagnostica messaggio XML


4.Verifica coerenza file-messaggio


ΔT4 ΔT5

T4

Figura 10 – Intervalli temporali soggetti a SLA – Banca Mittente Per ciò che riguarda i flussi di carattere dispositivo inviati dalla Banca Mittente si sono fissati i seguenti intervalli massimi:

- T5 = T2 (a meno di tolleranze dovute ai tempi di trasporto sulla Rete Logica). Similmente, per quanto riguarda i flussi informativi, si sono definiti i seguenti intervalli temporali massimi:

- T4 = entro le ore 05:00 (GMT+1) presso il Cliente; - T4 = T1 (a meno di tolleranze dovute ai tempi di trasporto sulla Rete Logica); - T5 = T2 (a meno di tolleranze dovute ai tempi di trasporto sulla Rete Logica).

Gli intervalli sopra definiti hanno validità fino alla fine del Periodo di Transizione, in seguito verranno ricalibrati subendo riduzioni.

Titolo:


Codice


00.07.09



Data

09-07-2010

Pagina

39/59

7 Firma digitale Per le specifiche tecniche da adottare per l’utilizzo della Firma digitale si faccia riferimento al documento tecnico FIRMA-MO-001.

7.1 CONTROLLO DEL MITTENTE FISICO DEI FLUSSI FIRMATI L’immissione sulla Rete dei flussi firmati è consentita ai soli mittenti fisici autorizzati dal CBI (cfr. doc. FIRMA-MO-001). In fase di ricezione di un flusso firmato deve pertanto essere effettuato il controllo del mittente fisico, producendo apposito scarto se il CUC dello stesso non rientra nella lista dei soggetti abilitati all’utilizzo della tipologia di firma rilevata. L’eventuale scarto deve essere effettuato dalla Banca destinataria a livello di intero flusso utilizzando il primo messaggio di stato avanzamento (messaggio 17). Il body di servizio di tale messaggio deve essere strutturato così come illustrato nella figura seguente:

Info file

• Tipologia supporti logici• Nome file

(0..n)Info supporto

Stato invio• Stato avanzamento• Codice d’errore

Body di servizio: statoavanzamento

Info su diagnostico

• Banca utente• Versione diagnostico utilizzata• Soggetto verificatore• Data e ora diagnostica

• Tipo messaggio

ERRR

Blocco assente

1

PF5

Le regole di composizione del primo messaggio di stato avanzamento sono le seguenti:

- Campo “Tipo messaggio” posto al valore 1 (primo messaggio di stato avanzamento) - Campo “Stato avanzamento” (presente nel blocco “Stato invio”) valorizzato con “ERRR” - Campo “Codice di errore” presente e posto al valore PF5 (supporti logici firmati digitalmente inviati

da un mittente fisico non autorizzato) - Blocco “Info supporto” assente

7.2 CONTROLLO DI OMOGENEITÀ PER APPOSIZIONE DELLA FIRMA DIGITALE Coerentemente a quanto definito nel paragrafo 2.4.1 del presente documento, l’apposizione della firma digitale e la tipologia di firma utilizzata rappresentano criteri di omogeneità per la composizione di tutti i messaggi di richiesta di servizio. Per ogni richiesta caratterizzata da più supporti logici, il riferimento per la verifica di omogeneità è rappresentato dal primo supporto logico: se è firmato lo devono essere tutti i successivi con la stessa tipologia di firma, se non è firmato la firma non può essere apposta su alcun supporto logico seguente.

Titolo:


Codice


00.07.09



Data

09-07-2010

Pagina

40/59

Qualora il criterio di omogeneità non venga rispettato lo scarto deve essere effettuato dalla Banca destinataria a livello di intero flusso utilizzando il primo messaggio di stato avanzamento (messaggio 17) il cui body di servizio deve essere strutturato così come illustrato nella figura seguente:

Info file


(0..n)Info supporto

• Codice SIA Azienda di riferimento• ABI Banca di riferimento• Data creazione• Nome supporto

Stato invio

• Stato avanzamento• Codice d’errore

Stato invio



Body di servizio: stato avanzamento

Info su diagnostico


Dettagli errore (0..3)

• Tipo messaggio

ERRR

ERRR

PSL5

1

PF5

Blocco assente

Titolo:


Codice


00.07.09



Data

09-07-2010

Pagina

41/59

Si precisa come il blocco “Info supporto” debba essere valorizzato solo per il primo supporto logico che viola il criterio di omogeneità dettato dal primo supporto logico contenuto nel file. Le regole di composizione del primo messaggio di stato avanzamento possono pertanto essere sintetizzate nel modo seguente:

- Campo “Tipo messaggio” posto al valore 1 (primo messaggio di stato avanzamento) - Campo “Stato avanzamento” (presente nel blocco “Stato invio”) valorizzato con “ERRR” - Campo “Codice di errore” presente e posto al valore PF5 (supporti logici non omogenei) - Blocco “Info supporto” riferito al primo supporto logico non omogeneo valorizzato seguente modo:

- Campo “Stato avanzamento” (presente nel blocco “Stato invio”) pari a “ERRR” - Campo “Codice di errore” presente e posto al valore PSL5 - Blocco “Dettagli errore” assente

7.3 VERIFICA DELLA FIRMA SUI SINGOLI SUPPORTI LOGICI Per ogni supporto logico firmato la Banca destinataria è tenuta ad effettuare i due seguenti controlli, aggiuntivi rispetto ai diagnostica applicata su tutti i flussi: - verifica che la modalità di apposizione firma dichiarata nel campo “Tipo di firma” sia ammessa per i

Servizi Porting (cfr. doc. FIRMA-MO-001). - verifica che la modalità di apposizione firma dichiarata nel campo “Tipo di firma” sia la stessa utilizzata

nella busta di pertinenza). - verifica di correttezza di ogni busta di firma. Il campo <Sgnt> codificato in base64 deve rappresentare

una busta “leggibile”, ovvero conforme alle specifiche del tipo di firma utilizzata - verifica della firma secondo le modalità previste (cfr. documento FIRMA-MO-001).

Si osserva che non è fissata alcuna sequenza predefinita tra controlli di diagnostica ordinari e controlli sulla firma digitale. I controlli sulla firma possono pertanto essere preposti o posposti a quelli di diagnostica dei supporti logici. Qualora almeno uno di tali controlli fallisca, lo scarto del singolo supporto logico deve essere effettuato utilizzando l’apposito codice di errore disponibile nell’appendice C del documento CBI-STD-001. Con riferimento al secondo messaggio di stato avanzamento, le regole di composizione del blocco “Info supporto”, in corrispondenza ad ogni supporto per il quale viene rilevato un errore di verifica della firma digitale possono pertanto essere sintetizzate come segue:

- Campo “Stato avanzamento” (presente nel blocco “Stato invio”) valorizzato con “ERRR” - Campo “Codice di errore” presente e posto al valore PSL8 - Una occorrenza del blocco “Dettagli errore” con i campi valorizzati nel modo seguente:

- Campo “Numero disposizione” posto al valore “0” (errore generalizzato su tutto il supporto) - Campo “Tipo record” pari alla tipologia del supporto riportata nel record di testa (es. PC) - Campo “Posizione inizio” posta a 1 - Campo “Posizione fine” posta a 120 - Campo “Codice di errore” pari al valore 100 (cfr. doc. CBI-STD-001, Appendice C)

Possono essere presenti eventuali altre occorrenza del blocco “Dettagli errore” qualora si rilevino anche errori legati alla diagnostica del supporto logico. Quanto appena espresso viene illustrato nella figura seguente:

Titolo:


Codice


00.07.09



Data

09-07-2010

Pagina

42/59

N.B. La valorizzazione indicata è da intendersi in corrispondenza ad ogni supporto per il quale viene rilevato l’errore sulla firma. Possono inoltre essere presenti altre occorrenza del blocco “Dettagli errore” qualora si rilevino anche errori legati alla diagnostica del supporto logico.

Info file


(0..n)Info supporto


Stato invio


Stato invio



Body di servizio: statoavanzamento

Info su diagnostico


Dettagli errore

• Numero disposizione/rendicontazione• Tipo record• Posizione inizio• Posizione fine• Codice d’errore

(0..3)

• Tipo messaggio

RCVD

0

Record di testa

1

120

100

ERRR

PSL8

2

Valori riferiti ai dettagli errore su

firma digitale

Titolo:


Codice


00.07.09



Data

09-07-2010

Pagina

43/59

8 Allegati

8.1 ALLEGATO A – CRITERI DI IDENTIFICAZIONE UNIVOCA DI MESSAGGIO E FILE

I criteri per l’identificazione univoca del file e del relativo messaggio sono quelli descritti nel documento “STPG-MO-001 Nuovi Servizi - Parte Generale”.

8.2 ALLEGATO B - POPOLAMENTO DEL DIRECTORY A FINI DI “PORTING” Al fine di consentire l’effettiva attivazione del servizio “Porting”, le Banche dovranno completare le procedure operative e propedeutiche all’assegnazione dell’Identificativo Univoco CBI (CUC), unitamente a fornire gli elenchi relativi ai Codici Azienda (Codice SIA) censite in CBI e delle relative Banche Proponenti. Il dettaglio di tali procedure (attori coinvolti, attività, tempistiche) è descritto nel documento “CBI–Assegnazione CUC – attività propedeutiche”, cui si rimanda per approfondimenti.

8.3 ALLEGATO C – STRUTTURA DEI MESSAGGI XML D’INVIO FILE/STATO D’AVANZAMENTO

8.3.1 Considerazioni generali La messaggistica XML a supporto della funzione di Porting è sviluppata in accordo con le linee guida utilizzate per la costruzione della messaggistica per le nuove funzioni CBI. Sono pertanto previsti i seguenti blocchi di informazione principali: - Header di tratta; - Header E2E di Servizio; - Body di servizio. Per i dettagli sulla struttura dell’Header di tratta e dell’Header E2E di Servizio, si faccia riferimento agli Excel “STPG-ST-001 Controlli Header di tratta” e “STPG-ST-002 Controllo Header E2E” e agli Schemi XSD “CBIHdrTrt” e “CBIHdrSrv”, contenuti nella Parte Generale. Per i dettagli sulla struttura del Body di servizio, si faccia invece riferimento agli Excel “STAA-ST-001 Invio file” e “STAA-ST-002 stato avanzam” e agli Schemi XSD “CBIPrtAdvSts” e “CBIPrtSrvRq”, rispettivamente per il messaggio XML accompagnatorio del file di richiesta e per il messaggio di stato avanzamento (cfr. punti 17 e 20 sequence diagram). 8.3.2 Struttura 8.3.2.1 Header di tratta Per le specifiche del blocco d’informazioni “Header di tratta” si faccia riferimento al documento “STPG-MO-001 Nuovi Servizi - Parte Generale”. 8.3.2.2 Header di Servizio Per le specifiche del blocco d’informazioni “Header di Servizio” si faccia riferimento al documento “STPG-MO-001 Nuovi Servizi - Parte Generale”. Ai fini del Servizio “PORTING ATTUALI TRACCIATI”, nei blocchi “Mittente” e “Destinatario” dell’Header E2E di Servizio devono essere indicati solo gli Identificativi CBI della Banca Mittente e di quella Destinataria (tag “Identificativo univoco Mittente/Destinatario”).

Titolo:


Codice


00.07.09



Data

09-07-2010

Pagina

44/59

8.3.2.3 Body di Servizio 8.3.2.3.1 Struttura del messaggio XML di “Richiesta di servizio” La struttura logica del “body di servizio” del messaggio di “Richiesta di servizio” (ossia del messaggio XML di accompagnamento all’invio del file) è caratterizzata da quattro blocchi principali: Blocco “Info file”: contiene le informazioni identificative del file, incluso il nome file; Blocco “Info diagnostico”: contiene le informazioni sul diagnostico utilizzato per la verifica del flusso; Blocco “Info supporto”: contiene il dettaglio delle informazioni sui supporti logici contenuti all’interno

del file; Blocco “Firma”: se presente contiene le informazioni sulla firma digitale apposta sul singolo supporto

logico.

Header E2E di servizio

Header di tratta

Messaggio XML

Info file


(1..n)Info supporto


Info su diagnostico


Body di servizio

Firma supporto

• Tipo firma• Piattaforma di riferimento• Riferimento temporale• Firma

(0..10)

Descrizione dello schema XML a) Info file <FleInfo>

Presenza: [1..1] Definizione: Blocco obbligatorio contenente le informazioni generali sul file associato al messaggio. Tipo: FileInformation

Titolo:


Codice


00.07.09



Data

09-07-2010

Pagina

45/59

Il blocco Info file è composto dai seguenti elementi:

a.1. Tipologia flusso a.2. Nome file

a.1. Tipologia flusso <FlwTyp>

Presenza: [1..1] Definizione: Descrizione della tipologia di supporti logici inviati così come classificati negli attuali standard tecnici CBI (es. PC, RH, etc.) Tipo: FlowType (Max35Text)

a.2. Nome file <FleNm>

Presenza: [1..1] Definizione: Contiene l’identificativo univoco del file inviato – IUF (fare riferimento al documento “STPG-MO-001 Nuovi Servizi - Parte Generale”) Tipo: FileIdentifier

b) Info su diagnostica <DiagInfo>

Presenza: [1..1] Definizione: Blocco obbligatorio che contiene le informazioni sul diagnostico e sulla diagnostica eseguita. Tipo: DiagnosticFileInformation Il blocco è composto dai seguenti elementi:

b.1. Banca utente b.2. Versione diagnostico utilizzata b.3. Soggetto verificatore b.4. Data diagnostica

b.1. Banca utente <UsrBnk>

Presenza: [0..1] Definizione: CUC della Banca “owner” della diagnostica Tipo: CBIIdentifier

b.2. Versione diagnostico utilizzata <DiagVers> Presenza: [1..1] Definizione: Versione del kit di certificazione pubblicato da ACBI per cui il diagnostico ha effettuato la certificazione Tipo: Max35Text

b.3. Soggetto verificatore <ChkSbj> Presenza: [1..1] Definizione: CUC del soggetto che effettua la diagnostica (es. Banca, STD o GPA) Tipo: CBIIdentifier

b.4. Data diagnostica <ChkDt> Presenza: [1..1] Definizione: Data in cui è stata effettuata la diagnostica Tipo: ISODate

c) Info supporto <SppInfo>

Titolo:


Codice


00.07.09



Data

09-07-2010

Pagina

46/59

Presenza: [1..n] Definizione: Blocco obbligatorio contenente le informazioni sui supporti logici contenuti nel file inviato. Tipo: SupportInformation Il blocco Info supporto è composto dai seguenti elementi:

c.1. Codice SIA Azienda di riferimento c.2. ABI Banca di riferimento c.3. Data creazione c.4. Nome supporto c.5. Firma supporto

c.1. Codice SIA Azienda di riferimento <SIACd>

Presenza: [1..1] Definizione: Campo che identifica il Codice SIA dell’azienda cliente di riferimento mittente della disposizione nel caso di flussi dispositivi o destinataria nel caso di flussi di esito o informativi; è quello riportato nel “Record di testa” del supporto logico. Tipo: SIAIdentifier (Alfanumerico)

c.2. ABI Banca di riferimento <ABICd >

Presenza: [1..1] Definizione: Codice ABI della Banca di riferimento destinataria del supporto logico nel caso di flussi dispositivi; mittente nel caso di flussi informativi o di esito; è quello riportato nel “Record di testa” del supporto logico. Tipo: ABIIdentifier (Numerico)

c.3. Data creazione <CreDt>

Presenza: [1..1] Definizione: Data di creazione del supporto logico. Tipo: ISODate Note: É ottenuto dal corrispondente campo nel record di testa/record di coda attraverso una conversione di tipo applicativo. Nonostante le specifiche W3C consentano di indicare anche il Time Zone, si precisa che tale dettaglio non deve essere inserito. Infatti, poiché tale campo viene utilizzato quale chiave di correlazione tra supporti referenziati nelle richieste di servizio e relativi stati di avanzamento, l’eventuale presenza del Time Zone potrebbe creare problemi di gestione del workflow in corrispondenza del cambio di orario (solare legale).

c.4. Nome supporto <SppNm>

Presenza: [1..1] Definizione: Nome del supporto logico. Tipo: Max20Text

c.5. Firma supporto <SgnInfo>

Presenza: [0..10] Definizione: Blocco facoltativo che contiene le informazioni sull’eventuale firma digitale applicata al supporto. Il blocco <SgnInfo> è composto dai seguenti elementi:

c.5.1. Tipo firma c.5.2. Piattaforma di riferimento c.5.4. Riferimento temporale c.5.5. Firma

Titolo:


Codice


00.07.09



Data

09-07-2010

Pagina

47/59

c.5.1. Tipo firma <SgnTyp>

Presenza: [1..1] Definizione: Valore codificato che descrive il tipo di firma applicata al supporto. Può assumere i seguenti valori definiti nel documento FIRMA –MO-001. Tipo: SignatureType

c.5.2. Piattaforma di riferimento <RefPlt> Presenza: [1..1] Definizione: Descrizione della piattaforma utilizzata per la generazione della firma. Può assumere i valori definiti nel documento FIRMA–MO-001. Tipo: ReferencePlatform

c.5.3. Riferimento temporale <DtRef>

Presenza: [1..1] Definizione: Istante temporale in cui sono state completate le verifiche sulla firma e sul certificato utilizzato per la firma da parte della Banca Proponente (cfr. “FIRMA-MO-001”). Tipo: ISODateTime

c.5.4. Firma <Sgnt>

Presenza: [1..1] Definizione: Tag che contiene la firma (costruita in accordo a quanto specificato dal tag “Tipo firma”). Tipo: P7M. Nota: In questo tag dovrà essere inserita, codificata in Base64, la busta generata dal processo di firma. Il tipo dato riportato nello schema XML per il tipo di dato “P7M” è “xs:base64Binary” .

Controlli Per il dettaglio su Facoltatività/Obbligatorietà e sui controlli (Formali, Validità etc.) da applicare al messaggio XML si rimanda al documento Excel “STAA-ST-001”. 8.3.2.3.2 Struttura del messaggio Stato d’avanzamento La struttura logica del “body di servizio” del messaggio di stato d’avanzamento è caratterizzata da cinque blocchi principali: Blocco “Info file”: contiene le informazioni identificative del file, ed il relativo “stato di avanzamento”

(o eventuali codici d’errore); Blocco “Info diagnostico”: contiene le informazioni sul diagnostico utilizzato per la verifica del

messaggio e del contenuto applicativo del file; Blocco “Info supporto”: contiene il dettaglio delle informazioni sui supporti logici contenuti all’interno

del file ed i relativi “stati di avanzamento” (o eventuali codici d’errore); Blocco “Stato invio”: contiene le informazioni sullo stato di avanzamento e/o errori rilevati; Blocco “Dettagli errore”: contiene i dettagli degli errori rilevati sul supporto logico.

Titolo:


Codice


00.07.09



Data

09-07-2010

Pagina

48/59

Info file


(0..n)Info supporto


Header E2E di servizio

Header di tratta

Messaggio XML

Stato invio


Stato invio



Body di servizio: stato avanzamento

Info su diagnostico


Dettagli errore

• Numero disposizione/rendicontazione• Tipo record• Posizione inizio• Posizione fine• Codice d’errore

(0..3)

• Tipo messaggio

Descrizione dello schema XML a) Tipo messaggio <MsgTyp>

Presenza: [1..1] Definizione: Flag che indica se si tratta del 1° o del 2° messaggio di avanzamento Tipo: MsgTypFlg1 Può assumere i seguenti valori

Valore Descrizione 1 1° messaggio d’avanzamento 2 2° messaggio d’avanzamento

b) Info file <FleInfo> Presenza: [1..1] Definizione: Blocco obbligatorio contenente le informazioni generali sul file cui il messaggio di avanzamento si riferisce. Contiene le stesse informazioni del messaggio originario accompagnatorio del file. Tipo: FileInformation Il blocco Info file è composto dai seguenti elementi:

Titolo:


Codice


00.07.09



Data

09-07-2010

Pagina

49/59

b.1. Tipologia supporti logici b.2. Nome file b.3. Stato invio

b.1. Tipologia supporti logici <FlwTyp>

Presenza: [1..1] Definizione: Descrizione della tipologia di supporti logici inviati così come classificati negli attuali standard tecnici CBI (es. PC, RH, etc.) Tipo: FlowType

b.2. Nome file <FleNm>

Presenza: [1..1] Definizione: Contiene l’identificativo univoco del file inviato – IUF (fare riferimento al documento “STPG-MO-001 Nuovi Servizi - Parte Generale”) Tipo: FileIdentifier

b.3. Stato invio <SendSts>

Presenza:[1..1] Definizione: Blocco obbligatorio che contiene le informazioni sullo stato di avanzamento dell’invio del file. Tipo: SendingInformation1 Il blocco è composto dai seguenti elementi:

b.4.1. Stato avanzamento b.4.2. Codice d’errore

b.4.1. Stato avanzamento <AdvSts>

Presenza: [1..1] Definizione: Stato di avanzamento dell’invio del file. Tipo: AdvancingStatusType Può assumere i seguenti valori: Valore Descrizione Dettagli RCVD Received Il file ed il messaggio XML associato sono

stati ricevuti correttamente ERRR Errori rilevati Sono stati rilevati errori sul file o sul

messaggio XML associato (Cfr. campo successivo per i dettagli)

… <ulteriori codifiche da valutare>

b.4.2. Codice d’errore <FleErrCd>

Presenza: [0..1] (diventa obbligatorio se rilevati errori) Definizione: Codice errore durante l’invio del messaggio XML e del file. Tipo: FileErrorCode1 Può assumere i seguenti valori:

Cod. Err.

Descrizione Dettagli 1° msg (Cfr. punto 17 sequenc

2° msg (Cfr. punto 20 sequenc

Titolo:


Codice


00.07.09



Data

09-07-2010

Pagina

50/59

e diagram)

e diagram)

PF1 Errore msg XML Processo di validazione del messaggio XML non completato; codice da utilizzare per errori relativi a lunghezza o formato dei campi (tag)

X

PF2 File non trovato Messaggio XML ricevuto correttamente ma file non trovato, oppure nome file errato

X

PF3 File inutilizzabile Messaggio XML ricevuto correttamente ma file inutilizzabile (corrotto, illeggibile, etc.)

X

PF4 Limite massimo supporti logici superato

Numero di supporti logici inclusi nel file e presenti nel messaggio di richiesta superiore al limite definito

X

PF5 Supporti logici non omogenei, non corrispondenti, inutilizzabili o invio non autorizzato

Errore sui supporti logici: non corrispondenti a quelli indicati nel msg XML, non omogenei o inutilizzabili (incompleto, corrotto, illeggibile, etc.). Supporti logici firmati digitalmente inviati da un mittente fisico non autorizzato

X

…. … <ulteriori codifiche da valutare>

Note: Un supporto logico è definito come la sequenza di record che vanno dal record di testa (compreso) fino al relativo record di coda (compreso). Un supporto logico così individuato è definito come un supporto logico integro presente nel file. Il file deve contenere solo supporti logici integri, senza alcun record "estraneo" tra un supporto logico e l'altro; questo significa che dopo il record di coda di un supporto logico integro deve essere presente il record di testa del successivo supporto logico integro oppure la fine del file. Se durante la fase di individuazione di un supporto logico viene incontrata la fine del file e non il record di coda del supporto logico stesso, il supporto logico non è integro. Il file si considera integro se inizia con un supporto logico integro (il primo record del file deve essere il record di testa del primo supporto logico) e termina con un supporto logico integro (l'ultimo record del file deve essere il record di coda dell'ultimo supporto logico).

c) Info su diagnostica <DiagInfo>

Presenza: [1..1] Definizione: Blocco obbligatorio che contiene le informazioni sul diagnostico e sulla diagnostica eseguita Tipo: DiagnosticInformation

Titolo:


Codice


00.07.09



Data

09-07-2010

Pagina

51/59

Il blocco è composto dai seguenti elementi:

c.1. Banca utente c.2. Versione diagnostico utilizzata c.3. Soggetto verificatore c.4. Data diagnostica

c.1. Banca utente <UsrBnk>

Presenza: [0..1] Definizione: CUC della Banca “owner” della diagnostica Tipo: CBIIdentifier

c.2. Versione diagnostico utilizzata <DiagVers>

Presenza: [1..1] Definizione: Versione del kit di certificazione pubblicato da ACBI per cui il diagnostico ha effettuato la certificazione Tipo: Max35Text

c.3. Soggetto verificatore <ChkSbj>

Presenza: [1..1] Definizione: CUC del soggetto che effettua la diagnostica del messaggio e del contenuto applicativo del file (es. Banca, STD o GPA) Tipo: CBIIdentifier

c.4. Data diagnostica <ChkDt>

Presenza: [1..1] Definizione: Data in cui è stata effettuata la diagnostica Tipo: ISODate

d) Info supporto <SppInfo>

Presenza: [0..n] Definizione: Blocco contenente le informazioni sul singolo supporto logico ottenute a valle del controllo di congruenza tra file ricevuto e messaggio accompagnatorio o a valle della diagnostica applicativa dei supporti logici Tipo: SupportInformation Note: Il blocco diventa obbligatorio nel caso in cui siano disponibili le informazioni relative ai supporti logici Il blocco Info supporto è composto dai seguenti elementi:

d.1. Codice SIA Azienda di riferimento d.2. ABI Banca di riferimento d.3. Data creazione d.4. Nome supporto d.5. Stato invio

d.1. Codice SIA Azienda di riferimento <SIACd>

Presenza: [1..1] Definizione: Campo che identifica il Codice SIA dell’azienda di riferimento; è quello riportato nel “Record di testa” del supporto logico cui il messaggio di avanzamento si riferisce.

Titolo:


Codice


00.07.09



Data

09-07-2010

Pagina

52/59

Tipo: SIAIdentifier (Alfanumerico)

d.2. ABI Banca di riferimento <ABICd> Presenza: [1..1] Definizione: Codice ABI della Banca di riferimento; è quello riportato nel “Record di testa” del supporto logico cui il messaggio di avanzamento si riferisce. Tipo: ABIIdentifier (Numeric)

d.3. Data creazione <CreDt>

Presenza: [1..1] Definizione: Data di creazione del supporto logico cui il messaggio di avanzamento si riferisce. Note: Nonostante le specifiche W3C consentano di indicare anche il Time Zone, si precisa che tale dettaglio non deve essere inserito. Infatti, poiché tale campo viene utilizzato quale chiave di correlazione tra supporti referenziati nelle richieste di servizio e relativi stati di avanzamento, l’eventuale presenza del Time Zone potrebbe creare problemi di gestione del workflow in corrispondenza del cambio di orario (solare legale). Tipo: ISODate

d.4. Nome supporto <SppNm>

Presenza: [1..1] Definizione: Nome del supporto logico cui il messaggio di avanzamento si riferisce. Tipo: Max20Text

d.5. Stato invio <SendSts>

Presenza: [1..1] Definizione: Blocco obbligatorio che contiene le informazioni sullo stato di avanzamento del singolo supporto logico cui il messaggio di avanzamento si riferisce. Tipo: SendingInformation2 Il blocco è composto dai seguenti elementi:

d.5.1. Stato avanzamento d.5.2. Codice d’errore d.5.3. Dettagli errore

d.5.1. Stato avanzamento <AdvSts>

Presenza: [1..1] Definizione: Stato di avanzamento dell’invio del singolo supporto logico cui il messaggio di avanzamento si riferisce. Tipo: AdvancingStatusType

Può assumere i seguenti valori:

Valore Descrizione Dettagli ACTC AcceptedTechnica

lValidation Diagnostica supporto logico ok

ERRR Errori rilevati Sono stati rilevati errori sul supporto logico (Cfr. campo successivo per i dettagli)

… <ulteriori codifiche da valutare>

Titolo:


Codice


00.07.09



Data

09-07-2010

Pagina

53/59

d.5.2. Codice d’errore <LgSpErrCd> Presenza: [0..1] (diventa obbligatorio se rilevati errori) Definizione: Codice errore durante l’invio del supporto logico. Tipo: FileErrorCode2 Può assumere i seguenti valori: Cod. Err. Descrizione Dettagli 1° msg

(Cfr. punto 17 sequence diagram)

2° msg (Cfr. punto 20 sequence diagram)

PSL1 Supporto non presente nel messaggio XML

Supporto logico presente nel file fisico ma non dichiarato nel messaggio XML

X

PSL2 Supporto non presente nel file

Supporto logico dichiarato nel messaggio XML ma non presente nel file fisico associato

X

PSL3 Supporto logico non omogeneo per “tipologia flusso”

Tipo supporto logico non coerente con il tipo di flusso

X

PSL4 Supporto logico non omogeneo per per “destinatario”

Supporto logico non indirizzato al destinatario corretto

X

PSL5 Supporto logico non omogeneo per “applicazione firma digitale”

Supporto logico non omogeneo per applicazione della firma digitale

X

PSL6 Supporto logico inutilizzabile

Supporto logico inutilizzabile (incompleto, corrotto, illeggibile, etc.)

X

PSL7 ABI e CUC Banca Passiva non coerenti

Codice ABI B. Passiva in “Info supporto” e CUC B. Passiva nell’HE2E non coerenti

X

PSL8 Errori su supporto logico

Errori sul singolo supporto logico

X

…. … <ulteriori codifiche da valutare>

d.5.3. Dettagli errore <ErrDtl>

Presenza: [0..3] (diventa obbligatorio se rilevati errori applicativi sul singolo supporto logico) Definizione: Dettaglio degli errori applicativi e di diagnostica rilevati sul singolo supporto logico. Tipo: ErrorDetailsInformation Il blocco dettagli errore è composto dai seguenti elementi:

Titolo:


Codice


00.07.09



Data

09-07-2010

Pagina

54/59

d.5.3.1. Numero disposizione d.5.3.2. Tipo record d.5.3.3. Posizione inizio d.5.3.4. Posizione fine d.5.3.5. Codice d’errore

d.5.3.1. Numero disposizione <NmDsp> Presenza: [1..1] Definizione: Progressivo della disposizione/rendicontazione su cui è stato rilevato l’errore Tipo: NonNegativeIntegerNumber

d.5.3.2. Tipo record <RcTyp>

Presenza: [1..1] Definizione: Tipologia di record su cui è stato rilevato l'errore Tipo: Max2Text (Cfr. tabella attuali standard tecnici CBI)

d.5.3.3. Posizione inizio <PstStrt>

Presenza: [1..1] Definizione: Posizione di inizio su cui è stato rilevato l’errore Tipo: PositiveIntegerNumber

d.5.3.4. Posizione fine <PstNeg>

Presenza: [1..1] Definizione: Posizione di fine su cui è stato rilevato l’errore Tipo: PositiveIntegerNumber

d.5.3.5. Codice d’errore <ErrCd>

Presenza: [1..1] Definizione: Errore rilevato sulla disposizione del supporto logico. Le possibili codifiche sono state definite sulla base delle attuali segnalazioni di errore scambiate tra Centri Applicativi (Cfr. Appendice C del documento CBI-STD-001 per i dettagli). Tipo: ErrorDetailsCode Può assumere i seguenti valori:

Cod. Err. Descrizione errore <Cfr doc. CBI-STD-001> <Cfr doc. CBI-STD-001>

…. <ulteriori codifiche da valutare>

Controlli Per il dettaglio su Facoltatività/Obbligatorietà e sui controlli (Formali, Validità etc.) da applicare al messaggio XML si rimanda al documento Excel “STAA-ST-002”.

Titolo:


Codice


00.07.09



Data

09-07-2010

Pagina

55/59

8.4 ALLEGATO D – ESEMPI DI XML Esempio di messaggio XML (Header di Tratta definito nel namespace “HTRT” + Header di Servizio definito nel namespace “HE2E”+ Body di Servizio definito nel namespace “BODY”) di “accompagnamento file”. <?xml version="1.0" encoding="UTF-8"?>  <CBIPrtSrvRq xmlns="urn:CBI:xsd:CBIPrtSrvRq.001.03" xmlns:BODY="urn:CBI:xsd:CBIBdyPrtSrvRq.001.03" xmlns:HE2E="urn:CBI:xsd:CBIHdrSrv.001.04" xmlns:HTRT="urn:CBI:xsd:CBIHdrTrt.001.04" xmlns:SGNT="urn:CBI:xsd:CBISgnInf.001.02" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:CBI:xsd:CBIPrtSrvRq.001.03"> <CBIHdrTrt> <HTRT:IdCBISndrf>0000012J</HTRT:IdCBISndrf> <HTRT:IdCBIRcvrf>0000007U</HTRT:IdCBIRcvrf> <HTRT:SrvNm>PORTING-RH</HTRT:SrvNm> <HTRT:IdMsgTrt>0000024O0000025S0000024O000000000000000000010000024O123456789</HTRT:IdMsgTrt> <HTRT:XMLCrtDt>2001-12-17T09:32:50-05:00</HTRT:XMLCrtDt> <HTRT:RtrnAddrl>88503NCB01PR</HTRT:RtrnAddrl> </CBIHdrTrt> <CBIHdrSrv> <HE2E:SrvInfo> <HE2E:SrvNm>PORTING-RH</HE2E:SrvNm> <HE2E:IdE2EMsg>0000024O0000025S0000024O00000000000000000001</HE2E:IdE2EMsg> <HE2E:XMLCrtDt>2001-12-17T09:32:50-05:00</HE2E:XMLCrtDt> </HE2E:SrvInfo> <HE2E:Sender> <HE2E:IdCBISend>0000024O</HE2E:IdCBISend> <HE2E:SendTyp>Banca Passiva</HE2E:SendTyp> <HE2E:CBIRefrSend>0000012J</HE2E:CBIRefrSend> </HE2E:Sender> <HE2E:Receiver> <HE2E:IdCBIRecv>0000025S</HE2E:IdCBIRecv> <HE2E:RecvTyp>Banca Proponente</HE2E:RecvTyp> <HE2E:CBIRefrRecv>0000007U</HE2E:CBIRefrRecv> </HE2E:Receiver> <HE2E:DiagInfo> <HE2E:UsrBnk>0000024O</HE2E:UsrBnk> <HE2E:DiagVers>CBI_5.2</HE2E:DiagVers> <HE2E:ChkSbj>0000012J</HE2E:ChkSbj> <HE2E:ChkDt>2001-12-17T09:32:55-05:00</HE2E:ChkDt> </HE2E:DiagInfo> <HE2E:CongrInfo> <HE2E:SrvBdyNb>0001</HE2E:SrvBdyNb> </HE2E:CongrInfo> </CBIHdrSrv> <CBIBdyPrtSrvRq> <BODY:FleInfo> <BODY:FlwTyp>RH</BODY:FlwTyp> <BODY:FleNm>0000012J000000000000000000001</BODY:FleNm> </BODY:FleInfo>

Titolo:


Codice


00.07.09



Data

09-07-2010

Pagina

56/59

<BODY:DiagInfo> <BODY:UsrBnk>0000024O</BODY:UsrBnk> <BODY:DiagVers>CBI_5.2</BODY:DiagVers> <BODY:ChkSbj>0000012J</BODY:ChkSbj> <BODY:ChkDt>2001-12-17</BODY:ChkDt> </BODY:DiagInfo> <BODY:SppInfo> <BODY:SIASndCd>AAAAA</BODY:SIASndCd> <BODY:ABICd>05040</BODY:ABICd> <BODY:CreDt>2001-12-17</BODY:CreDt> <BODY:SppNm>supporto1</BODY:SppNm> <BODY:SgnInfo> <SGNT:SgnTyp>1</SGNT:SgnTyp> <SGNT:RefPlt>A</SGNT:RefPlt> <SGNT:DtRef>2001-12-17T09:30:58-05:00</SGNT:DtRef> <SGNT:Sgnt>String</SGNT:Sgnt> </BODY:SgnInfo> </BODY:SppInfo> <BODY:SppInfo> <BODY:SIASndCd>AAAAA</BODY:SIASndCd> <BODY:ABICd>05040</BODY:ABICd> <BODY:CreDt>2001-12-17</BODY:CreDt> <BODY:SppNm>supporto2</BODY:SppNm> </BODY:SppInfo> </CBIBdyPrtSrvRq> </CBIPrtSrvRq> Esempio di messaggio XML (Header di Tratta definito nel namespace “HTRT” + Header di Servizio definito nel namespace “HE2E”+ Body di Servizio definito nel namespace “BODY”) di “conferma ricezione file/supporto”, corrispondente al 1° messaggio di avanzamento (17) previsto dal workflow “Porting” (Cfr. Par. 2.2.1.1). <?xml version="1.0" encoding="UTF-8"?> <CBIPrtAdvSts xmlns="urn:CBI:xsd:CBIPrtAdvSts.001.03" xmlns:BODY="urn:CBI:xsd:CBIBdyPrtAdvSts.001.03" xmlns:HE2E="urn:CBI:xsd:CBIHdrSrv.001.04" xmlns:HTRT="urn:CBI:xsd:CBIHdrTrt.001.04" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:CBI:xsd:CBIPrtAdvSts.001.03"> <CBIHdrTrt> <HTRT:IdCBISndrf>0000007U</HTRT:IdCBISndrf> <HTRT:IdCBIRcvrf>0000012J</HTRT:IdCBIRcvrf> <HTRT:SrvNm>PORTING-RH</HTRT:SrvNm> <HTRT:IdMsgTrt>0000025S0000024O0000025S000000000000000000020000025S232323234</HTRT:IdMsgTrt> <HTRT:XMLCrtDt>2001-12-18T09:32:50-05:00</HTRT:XMLCrtDt> <HTRT:RtrnAddrl>88503HCB01PR</HTRT:RtrnAddrl> </CBIHdrTrt> <CBIHdrSrv> <HE2E:SrvInfo> <HE2E:SrvNm>PORTING-RH</HE2E:SrvNm> <HE2E:IdE2EMsg>0000025S0000024O0000025S00000000000000000002</HE2E:IdE2EMsg>

Titolo:


Codice


00.07.09



Data

09-07-2010

Pagina

57/59

<HE2E:XMLCrtDt>2001-12-18T09:32:55-05:00</HE2E:XMLCrtDt> </HE2E:SrvInfo> <HE2E:Sender> <HE2E:IdCBISend>0000025S</HE2E:IdCBISend> <HE2E:SendTyp>Banca Proponente</HE2E:SendTyp> <HE2E:CBIRefrSend>0000007U</HE2E:CBIRefrSend> </HE2E:Sender> <HE2E:Receiver> <HE2E:IdCBIRecv>0000024O</HE2E:IdCBIRecv> <HE2E:RecvTyp>Banca Passiva</HE2E:RecvTyp> <HE2E:CBIRefrRecv>0000012J</HE2E:CBIRefrRecv> </HE2E:Receiver> <HE2E:DiagInfo> <HE2E:UsrBnk>0000025S</HE2E:UsrBnk> <HE2E:DiagVers>CBI_5.2</HE2E:DiagVers> <HE2E:ChkSbj>0000007U</HE2E:ChkSbj> <HE2E:ChkDt>2001-12-18T09:32:55-05:00</HE2E:ChkDt> </HE2E:DiagInfo> <HE2E:CongrInfo> <HE2E:SrvBdyNb>0001</HE2E:SrvBdyNb> </HE2E:CongrInfo> </CBIHdrSrv> <CBIBdyPrtAdvSts> <BODY:MsgTyp>1</BODY:MsgTyp> <BODY:FleInfo> <BODY:FlwTyp>RH</BODY:FlwTyp> <BODY:FleNm>0000012J000000000000000000001</BODY:FleNm> <BODY:SendSts> <BODY:AdvSts>RCVD</BODY:AdvSts> </BODY:SendSts> </BODY:FleInfo> <BODY:DiagInfo> <BODY:UsrBnk>0000025S</BODY:UsrBnk> <BODY:DiagVers>CBI_5.2</BODY:DiagVers> <BODY:ChkSbj>0000007U</BODY:ChkSbj> <BODY:ChkDt>2001-12-18</BODY:ChkDt> </BODY:DiagInfo> </CBIBdyPrtAdvSts> </CBIPrtAdvSts> Esempio di messaggio XML (Header di Tratta definito nel namespace “HTRT” + Header di Servizio definito nel namespace “HE2E”+ Body di Servizio definito nel namespace “BODY”) di “conferma ricezione file/supporto”, corrispondente al 2° messaggio di avanzamento (20) previsto dal workflow “Porting” (Cfr. Par. 2.2.1.1). <?xml version="1.0" encoding="UTF-8"?> <CBIPrtAdvSts xmlns="urn:CBI:xsd:CBIPrtAdvSts.001.03" xmlns:BODY="urn:CBI:xsd:CBIBdyPrtAdvSts.001.03" xmlns:HE2E="urn:CBI:xsd:CBIHdrSrv.001.04" xmlns:HTRT="urn:CBI:xsd:CBIHdrTrt.001.04" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:CBI:xsd:CBIPrtAdvSts.001.03"> <CBIHdrTrt> <HTRT:IdCBISndrf>0000007U</HTRT:IdCBISndrf>

Titolo:


Codice


00.07.09



Data

09-07-2010

Pagina

58/59

<HTRT:IdCBIRcvrf>0000012J</HTRT:IdCBIRcvrf> <HTRT:SrvNm>PORTING-RH</HTRT:SrvNm> <HTRT:IdMsgTrt>0000025S0000024O0000025S000000000000000000030000025S345656456</HTRT:IdMsgTrt> <HTRT:XMLCrtDt>2001-12-18T17:32:50-05:00</HTRT:XMLCrtDt> <HTRT:RtrnAddrl>88503HCB01PR</HTRT:RtrnAddrl> </CBIHdrTrt> <CBIHdrSrv> <HE2E:SrvInfo> <HE2E:SrvNm>PORTING-RH</HE2E:SrvNm> <HE2E:IdE2EMsg>0000025S0000024O0000025S00000000000000000003</HE2E:IdE2EMsg> <HE2E:XMLCrtDt>2001-12-18T09:32:50-05:00</HE2E:XMLCrtDt> </HE2E:SrvInfo> <HE2E:Sender> <HE2E:IdCBISend>0000025S</HE2E:IdCBISend> <HE2E:SendTyp>Banca Proponente</HE2E:SendTyp> <HE2E:CBIRefrSend>0000007U</HE2E:CBIRefrSend> </HE2E:Sender> <HE2E:Receiver> <HE2E:IdCBIRecv>0000024O</HE2E:IdCBIRecv> <HE2E:RecvTyp>Banca Passiva</HE2E:RecvTyp> <HE2E:CBIRefrRecv>0000012J</HE2E:CBIRefrRecv> </HE2E:Receiver> <HE2E:DiagInfo> <HE2E:UsrBnk>0000025S</HE2E:UsrBnk> <HE2E:DiagVers>CBI_5.2</HE2E:DiagVers> <HE2E:ChkSbj>0000007U</HE2E:ChkSbj> <HE2E:ChkDt>2001-12-18T17:32:55-05:00</HE2E:ChkDt> </HE2E:DiagInfo> <HE2E:CongrInfo> <HE2E:SrvBdyNb>0001</HE2E:SrvBdyNb> </HE2E:CongrInfo> </CBIHdrSrv> <CBIBdyPrtAdvSts> <BODY:MsgTyp>2</BODY:MsgTyp> <BODY:FleInfo> <BODY:FlwTyp>RH</BODY:FlwTyp> <BODY:FleNm>0000012J000000000000000000001</BODY:FleNm> <BODY:SendSts> <BODY:AdvSts>RCVD</BODY:AdvSts> </BODY:SendSts> </BODY:FleInfo> <BODY:DiagInfo> <BODY:UsrBnk>0000025S</BODY:UsrBnk> <BODY:DiagVers>CBI_5.2</BODY:DiagVers> <BODY:ChkSbj>0000007U</BODY:ChkSbj> <BODY:ChkDt>2001-12-18</BODY:ChkDt> </BODY:DiagInfo> <BODY:SppInfo> <BODY:SIASndCd>AAAAA</BODY:SIASndCd> <BODY:ABICd>05040</BODY:ABICd> <BODY:CreDt>2001-12-17</BODY:CreDt> <BODY:SppNm>supporto1</BODY:SppNm>

Titolo:


Codice


00.07.09



Data

09-07-2010

Pagina

59/59

<BODY:SendSts> <BODY:AdvSts>ACTC</BODY:AdvSts> </BODY:SendSts> </BODY:SppInfo> <BODY:SppInfo> <BODY:SIASndCd>AAAAA</BODY:SIASndCd> <BODY:ABICd>05040</BODY:ABICd> <BODY:CreDt>2001-12-17</BODY:CreDt> <BODY:SppNm>supporto2</BODY:SppNm> <BODY:SendSts> <BODY:AdvSts>ERRR</BODY:AdvSts> <BODY:LgSpErrCd>PSL5</BODY: LgSpErrCd > <BODY:ErrDtl> <BODY:NmDsp>4</BODY:NmDsp> <BODY:RcTyp>61</BODY:RcTyp> <BODY:PstStrt>53</BODY:PstStrt> <BODY:PstEnd>57</BODY:PstEnd> <BODY:ErrCd>012</BODY:ErrCd> </BODY:ErrDtl> </BODY:SendSts> </BODY:SppInfo> </CBIBdyPrtAdvSts> </CBIPrtAdvSts>

8.5 ALLEGATO E – STRUTTURAZIONE DEGLI IDENTIFICATIVI UNIVOCI E QUALIFICATORI DI TIPO MESSAGGIO

Con riferimento alle regole di strutturazione degli identificativi univoci di file e messaggi veicolati sulla rete CBI (cfr. doc. STPG-MO-001 – Nuovi Servizi Parte Generale), viene fornita la lista dei qualificatori tipo messaggio (QTM) da utilizzarsi nell’ambito del workflow che caratterizza l’erogazione dei servizi Porting. Tipo di messaggio fisico Qualificatore Tipo Messaggio (QTM) Richiesta di servizio 01 Primo messaggio di stato avanzamento 17 Secondo messaggio di stato avanzamento 20

Fine del Documento

PORTING-MO-001 Porting Attuali Servizi - V.00.07.09

Documents

Transcript of PORTING-MO-001 Porting Attuali Servizi - V.00.07.09