3.2 Descrizioni delle interfacce e regole di plausibilità
3.2.2 Informazioni di base
La presente documentazione descrive l’interazione tra l’UDSC e l’impresa (B2B) per tutti i messaggi relativi al regime comune di transito (PTC). Non si fa distinzione in base al tipo di comunicazione – B2B-Gateway o B2B light (upload XML) – poiché a livello di contenuti non ci sono differenze.
I processi standard prendono come riferimento il traffico stradale. Le differenze rispetto agli altri generi di traffico sono adeguatamente segnalate.
3.2.2.1 Definizioni per l’attuazione tecnica Regole
(Rxxxx)
Un’istruzione che indica (dal punto di vista funzionale e tecnico) come un dato o un gruppo di dati deve essere compilato e che limita il contenuto. Può essere calcolabile e può essere testata.
Condizioni (Cxxxx)
Un’istruzione che indica (dal punto di vista funzionale e tecnico) se un dato o un gruppo di dati è obbligatorio oppure opzionale o non può essere utilizzato. Definisce solo se i dati devono essere compilati o meno, senza limitare il contenuto in sé. È sempre calcolabile e può essere eseguita e testata.
Regole tecniche (Txxxx)
Un’istruzione supplementare dal punto di vista tecnico informatico, che principalmente aggiunge o chiarisce regole di funzionamento e
condizioni.
Regole di business per la trasmissione (B1xxx
& B2xxx)
Business Rule for Transition (BRT)
Con le BRT si garantisce che singole regole e condizioni non siano applicabili (B1xxx) durante la fase di transizione (da NCTS-P4 a NCTS-P5), ma solo dopo. In alternativa, definiscono la struttura finale dopo la fase di transizione (B2xxx).
ꞏ Una BRT-1 (B1xxx) comporta una validazione di regole e condizioni prima della fine della fase di transizione (TP) ed è
applicabile per ogni movimento aperto durante la fase di transizione.
La BRT-1 può essere applicata solo se la data decisiva (Decisive date) è precedente alla fine della fase di transizione o coincidente con essa.
ꞏ Una BRT-2 applica un paio di requisiti di dati UCC e definisce la struttura finale di un movimento accettato dopo la fine della fase di transizione. La BRT-2 è applicabile quando la data decisiva è successiva alla fase di transizione.
Regola di sequenziamento (Sxxxx)
Determina la sequenza di condizioni, regole tecniche per la trasmissione, regole tecniche e regole ove questa si scosti dalla sequenza standard.
Sequenza standard: validazione formato (XSD), liste di codici, BRT/TRT, condizioni, regole, regole tecniche
Guideline (linee guida) (Gxxxx)
Istruzione su come devono essere compilati i gruppi di dati o i campi di dati. Le linee guida non sono pensate per un test automatico.
Regole tecniche per la trasmissione
(Exxxx)
Technical Rule for Transition (TRT).
Una limitazione che rende necessaria una più rigida struttura dei messaggi prima della fine della fase di transizione (TP). Il suo scopo è garantire la compatibilità dei messaggi con i sistemi NCTS-P4 e NCTS-P5 durante la fase di transizione.
Nella fase 5, la lunghezza del campo di singoli dati viene aumentata (p. es. l’indirizzo passa da 35 a 70 caratteri, i campi di testo libero da 240 a 512). I vecchi sistemi non sono in grado di elaborare il maggior numero di caratteri e pertanto un convertitore taglia quelli eccedenti.
Ci sono tuttavia campi per i quali questa procedura produce errori; è qui che intervengono le TRT, che rendono disponibile la piena funzionalità solo nella fase 5.
3.2.2.2 Modello dati dei messaggi tecnici
Il precedente modello dati della fase 4 era composto da due gruppi di dati: i dati di intestazione (riferiti al trasporto) e i dati di posizione (riferiti alle merci). Con la fase 5 viene introdotto un nuovo modello dati con cinque diversi gruppi di dati, come riportato nella seguente figura della direzione generale Fiscalità e unione doganale (TAXUD).
3.2.2.3 Specifiche di dettaglio della validazione 3.2.2.3.1 Campo di dati (Data Item)
A ogni campo di dati è assegnato un tipo tra: numerico, alfanumerico, decimale, ora, data, data/ora. In singoli casi il valore è predefinito. Questi valori predefiniti sono stabiliti nella lista di codici (CL) corrispondente. I campi sono indipendenti dalla lingua poiché sono codificati in UTF-8.
3.2.2.3.2 Gruppi di dati (Data Group)
I gruppi di dati contengono diversi campi di dati o ulteriori gruppi. I nomi dei gruppi non sono univoci e possono ricorrere in diversi messaggi. Il loro contenuto può variare da messaggio a messaggio e non deve necessariamente coincidere.
3.2.2.3.3 Descrizione della struttura
TRT e BRT sono strutturate in maniera tale da poter scadere senza modifica del software di UCC NCA. La loro validità dipende dalla data. Per le TRT vale il seguente principio:
Per le BRT si distinguono due categorie:
Prima della fase di transizione: validazione di regole e condizioni
Dopo la fase di transizione: imposizione di una rigida struttura dei messaggi
«Data decisiva» (Decisive Date) per BRT/TRT
Tipo Messaggi interessati (IE) Data decisiva (Decisive Date) Condizione temporale per la verifica
TRT Applicabile a tutti i messaggi IE
in cui sono presenti TRT Submission date/Reception date of IE by NCA
(system date and time)
Decisive Date ≤ end date of TP
BRT-1 IE015 Reception date of IE by NCA
(system date and time)
Decisive Date ≤ end date of TP Applicabile a tutti i messaggi IE
in cui sono presenti BRT-1 a esclusione di IE015
Declaration acceptance date (declarationAcceptanceDate)
BRT-2 IE015 Reception date of IE by NCA
(system date and time)
Decisive Date >
end date of TP Applicabile a tutti i messaggi IE
in cui sono presenti BRT-2 a esclusione di IE015
Declaration acceptance date (declarationAcceptanceDate)
La struttura tecnica dei dati comprende due aspetti: la descrizione dei messaggi e il layout complessivo. Nella descrizione, per i gruppi di dati sono indicati la sequenza, la gerarchia, le ripetizioni massime, le regole e le condizioni nonché se si tratta o meno di un gruppo
obbligatorio. Per quanto riguarda l’indicazione dell’obbligatorietà sono previste le seguenti possibilità:
il gruppo di dati:
o deve essere indicato sempre (R = required);
o è opzionale (O = optional). Se sono disponibili dei dati, per completezza questi devono essere forniti;
o può essere entrambe le cose (D = dependent) a seconda delle condizioni.
Quando si compila un gruppo di dati subordinato, occorre indicare il relativo gruppo di livello superiore.
Nel layout complessivo (parte 2 della struttura del messaggio) vengono affrontati i singoli campi di dati. Vengono indicati la sequenza, le regole e le condizioni, nonché se si tratta o meno di un campo obbligatorio. I dati obbligatori sono analoghi a quelli del gruppo di dati.
3.2.2.3.4 Definizione di regola, T, TRT, BRT o condizione
Regole, T, TRT, BRT devono essere validate dal mittente e/o dal destinatario. Questa informazione è riportata direttamente nella relativa descrizione.
I gruppi o i campi di dati con caratteristica D cambiano stato verso R, O oppure N (non applicabile). Se non sono applicabili, non è possibile utilizzare il valore ZERO, spazi vuoti o campi vuoti. In questi casi il gruppo di dati o il campo di dati deve essere completamente rimosso dal file XML.
Vengono impiegati i seguenti puntatori:
<Full path> verso gruppi/campi
o <MESSAGE-HEADER.Declaration type >
<Context specific> verso gruppi/campi all’interno dei messaggi IE da validare o <Applied Element>
xPath
o /*/Consignment/HouseConsignment/ConsignmentItem/Commodity/descriptionO fGoods
3.2.2.3.5 Elaborazione di regole, T, TRT, BRT o condizioni
La sequenza di validazione dei messaggi segue il seguente schema:
validazione formato (XSD)
liste di codici
BRT/TRT
condizioni
regole
regole tecniche
A volte capita che questa sequenza venga specificata. Ciò avviene con la regola di sequenza (S).
3.2.2.4 Set di caratteri e valori predefiniti dei campi di dati
Come standard, i documenti XML devono essere codificati in UTF-8.
3.2.2.4.1 Indicazione della lunghezza per tipo
L’indicazione della lunghezza in base al tipo può contenere in mezzo due punti. Ciò significa che il numero di caratteri è flessibile, ma il massimo non può essere superato. Una virgola nell’indicazione della lunghezza segnala quanti caratteri sono ammessi prima e dopo la virgola (se necessario). Anche questa informazione va combinata con il numero flessibile (se sono presenti due punti) e il massimo. La seguente panoramica mira a fare ancora maggiore chiarezza:
a1 1 lettera, lunghezza fissa
n2 2 cifre, lunghezza fissa
an3 3 caratteri alfanumerici, lunghezza fissa
a..4 fino a 4 lettere
n..5 fino a 5 cifre
an..6 fino a 6 caratteri alfanumerici
n..7,2 fino a 7 cifre in totale di cui fino a 2 dopo la virgola
3.2.2.4.2 Campi numerici
I campi sono numeri interi positivi o numeri decimali positivi, sempre che le liste di codici o una regola non forniscano ulteriori specifiche. Come separatore decimale va utilizzato il punto (.).
Non sono consentiti altri caratteri. Ai numeri interi non può essere anteposto uno zero (0).
I numeri decimali devono essere utilizzati solo quando la precisazione è necessaria. Prima e dopo il punto deve essere indicata almeno una cifra.
Esempio per l’indicazione n..11,3:
123 input valido
123456789.123 input non valido: troppi caratteri prima del punto e in totale
12345678.1234 input non valido: troppi caratteri dopo il punto e in totale
0123 input non valido: non è consentito anteporre lo zero
+123 input non valido: il segno più non è consentito
-123 input non valido: il segno meno non è consentito
1,234 input non valido: la virgola non è consentita
.3 input non valido: nessun carattere prima del punto
12345. input non valido: nessun carattere dopo il punto
3 input valido
3E1 input non valido: sono consentiti solo cifre e punto decimale
12345678901 input valido: 11 cifre al massimo, di cui 3 consentite dopo il punto
3.2.2.4.3 Campi di testo
Non è consentito aggiungere spazi vuoti prima o dopo. Le tabulazioni non devono essere impiegate. A causa del formato XML, determinati caratteri non sono consentiti poiché
potrebbero causare errori. Essi devono essere sostituiti come indicato nella seguente tabella:
Carattere Entità Nota
& & DEVE necessariamente essere convertito
> > deve essere convertito
< < DEVE necessariamente essere convertito
" " deve essere convertito ' ' deve essere convertito
Nota: & non conta come 5 caratteri ma come 1 solo. Ciò vale anche per gli altri casi.
3.2.2.4.4 Campi di data e ora
Per i campi DateTime e Time deve essere impiegato il fuso orario UTC. La data deve essere indicata secondo l’orario UTC, come nel seguente esempio:
ora in Svizzera: 8 marzo 2020 7:48 (UTC+1)
deve essere trasmesso il seguente orario: 8 marzo 2020 6:48 (UTC) Tipo di campo Espressione
Date YYYY ‘-‘ MM ‘-‘ DD
\d{4}-\d{2}-\d{2}
Time hh ‘:’ mm ‘:’ ss
\d{2}:\d{2}:\d{2}
Date/Time YYYY ‘-‘ MM ‘-‘ DD ‘T’ hh ‘:’ mm ‘:’ ss
\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}
Il separatore T segnala che la data è seguita da un’indicazione oraria. Il secondo intero è la più piccola unità consentita.
Esempio di limitazione XSD per il dato relativo all’ora (Time):
3.2.2.5 Messaggi e codici di errore 3.2.2.5.1 Messaggi di errore
3.2.2.5.2 Codici di errore 3.2.2.6 Messaggi XML
I messaggi XML devono essere codificati in UTF-8.
3.2.2.6.1 Convenzione di denominazione dei tag
Ai tag XML si applica la seguente convenzione di denominazione:
Dato XSD Convenzione di
3.2.2.6.2 Message Header
I seguenti capitoli definiscono come deve essere indicata la parte Message dei singoli messaggi.
3.2.2.6.2.1 Message Sender and Message Recipient
Per il mittente dei messaggi deve essere indicato l’ID del partner commerciale (n10). Come destinatario va inserito il valore PASSAR.CH.
Se i messaggi vengono inviati dall’UDSC il destinatario è l’ID del partner commerciale e il mittente PASSAR.CH.
3.2.2.6.2.2 Message Type
Il tipo è definito secondo questo schema: CC<IE numero del messaggio>C. Ossia per esempio:
CC015C o CC013C.
3.2.2.6.2.3 Message Timestamp
Deve essere compilato secondo il capitolo sui campi di testo. Bisogna necessariamente utilizzare il fuso orario UTC.
3.2.2.6.2.4 Message Identification
Ogni messaggio ha bisogno di un ID casuale. Ciò riguarda anche i messaggi che vengono spediti due volte. Se il Message-ID è già presente presso l’UDSC, il nuovo messaggio viene respinto. A tale scopo devono essere utilizzate le specifiche UUID versione 4.
3.2.2.6.2.5 Correlation Identifier
In caso di messaggio di errore o di risposta, l’ID del messaggio originario deve essere inserito nel campo Correlation Identifier per consentire una corretta associazione.
3.2.2.6.3 Principi XSD 3.2.2.6.3.1 Convenzioni XSD
Gli schemi XSD possono essere associati a due diversi gruppi: da un lato gli XSD condivisi, dall’altro gli XSD specifici. Gli schemi condivisi contengono definizioni di tipi semplici (campi di dati) e complessi (gruppi di dati) che ricorrono in diversi messaggi. Gli schemi specifici
consistono nella definizione strutturale di singoli messaggi. I messaggi specifici fanno riferimento a quelli condivisi, affinché questi possano essere utilizzati.
3.2.2.6.3.2 Struttura dei dati XSD
La seguente figura mostra i rapporti di dipendenza dei singoli schemi, illustrati di seguito nel dettaglio.
Simple Types XSD (stypes.xsd) – Campi di dati: contiene la definizione di tipo, formato e definizione modello.
Common Complex Types XSD (ctypes.xsd) – Gruppi di dati: contiene la definizione dei gruppi di dati. I gruppi di dati che sono presenti in diversi messaggi vengono riportati in un’unica definizione. In entrambi i casi ci sono informazioni su quali campi di dati sono contenuti e indicazioni su campi obbligatori, ripetizioni massime, regole, condizioni e liste di codici.
Header types (htypes.xsd): contiene le definizioni dei campi di dati e dei gruppi di dati per l’intestazione tecnica e ricorre in tutti i messaggi.
Message_specifix XSD (CCxxxV.xsd) – Struttura del singolo messaggio: i campi di dati e i gruppi di dati, compreso il tipo, sono definiti, così come le indicazioni su campi
obbligatori e ripetizioni massime.
Technical Codelist XSD (tcl.xsd): indica il tipo di campi di dati, con un elenco dei possibili valori.
Per collegare fra loro gli schemi viene utilizzato l’elemento XML <include>.
La documentazione (doc.xsd) viene riportata qui per completezza. Deve contenere la
definizione dei modelli degli elementi della documentazione (regole, condizioni, liste di codici e descrizioni) ulteriormente specificati negli XSD generali o specifici per un messaggio. Il file può essere utilizzato solo a scopi di documentazione e i suoi elementi non possono svolgere alcuna validazione di liste di codici, regole o condizioni.
(Vedi allegati)