Destinazioni delle merci - Documentazione sul sistema Passar per sviluppatori di software

2.7 Procedura d’emergenza

3 Basi tecniche

3.1 Processi tecnici

I seguenti modelli BPMN illustrano lo scambio dei diversi messaggi.

Nel caso in cui il modello non sia direttamente applicabile per uno o più generi di traffico, viene indicato il capitolo con le specifiche corrispondenti.

I modelli BPMN si concentrano sul flusso di messaggi tra l’UDSC e i responsabili delle merci, i responsabili dei dati e i responsabili del trasporto.

3.1.1 Processo d'importazione 3.1.2 Processo d'esportazione 3.1.3 Processo di transito

3.1.3.1 Transito diretto

3.1.3.1.1 Dichiarazione del trasporto 3.1.3.2 Transito con apertura in Svizzera 3.1.3.2.1 Dichiarazione delle merci

Con la dichiarazione delle merci (IE015) l’UDSC viene informato dell’intenzione di aprire un regime di transito. Se la dichiarazione non presenta errori, viene confermata con il

messaggio IE028. Quest’ultimo comprende tra l’altro l’MRN, che funge da identificativo univoco della procedura. Se l’attivazione non avviene entro il termine previsto, il regime di transito viene dichiarato non valido (NC909). Dopo l’attivazione (giuridicamente vincolante) possono essere effettuati controlli, che vengono comunicati con il messaggio IE060. Nel caso in cui non fosse possibile l’assegnazione al regime di transito, ciò viene comunicato con il messaggio IE051. Se tutto è a posto, il regime di transito viene aperto (messaggio IE029). Un evento durante il viaggio (p. es. trasbordo) viene segnalato al dichiarante del transito o al titolare del regime con il messaggio IE182. Se l’ufficio doganale di destinazione rileva discrepanze nei risultati del controllo, il titolare del regime viene informato con il messaggio IE019. Fino al chiarimento delle discrepanze, l’importo garantito non viene liberato. Se tutto si è svolto regolarmente, la chiusura del regime è confermata con il messaggio IE045.

La seguente figura rappresenta il processo di dichiarazione delle merci suddiviso secondo il processo di base.

3.1.3.2.2 Completamento della dichiarazione delle merci

Fino al momento dell’attivazione, la dichiarazione delle merci può essere corretta/completata ogni volta che lo si desidera. Se la correzione della dichiarazione delle merci non è più

accettata, ciò viene comunicato con il messaggio NC909. In caso contrario, l’accettazione viene confermata con il messaggio IE004.

3.1.3.2.3 Annullamento della dichiarazione delle merci

Una dichiarazione delle merci può essere annullata con una richiesta di annullamento (IE014). Quest’ultima può essere accettata o respinta dall’UDSC. La decisione viene comunicata con il messaggio IE009.

Il messaggio IE009 segnala se la richiesta di annullamento è accolta o respinta (Decisions:

1=Yes, 0=No). La decisione in merito compete in ogni caso all’UDSC.

Nei seguenti casi il rifiuto è automatico e un annullamento attraverso il sistema non è più possibile:

 quando il titolare del regime è stato informato di un controllo (IE060);

 quando è stata effettuata l’attivazione;

 quando è avvenuta la liberazione del transito.

Una volta che è stata impartita la liberazione del transito, una richiesta di annullamento esterna al sistema può essere presentata solo nella seguente circostanza:

 le merci sono state erroneamente dichiarate in più di una dichiarazione delle merci in transito.

Se l’UDSC accetta il messaggio IE014 (richiesta di annullamento), il regime di transito viene interrotto e annullato. Non sono più possibili ulteriori azioni.

3.1.3.2.4 Dichiarazione del trasporto

3.1.3.3 Transito con conclusione in Svizzera 3.1.3.3.1 Dichiarazione del trasporto

3.1.3.4 Procedura di ricerca

3.1.3.5 Procedura di riscossione dei tributi 3.1.3.6 Notifiche dello stato

3.1.4 Processo di esportazione e transito 3.1.5 Processo di transito e importazione

3.2 Descrizioni delle interfacce e regole di plausibilità

3.2.1 Panoramica

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)

3.2.3 Specifiche tecniche per il transito

I seguenti sottocapitoli contengono le strutture di tutti i messaggi necessari secondo i diagrammi di processo.

Si tratta di versioni non definitive e soggette a modifiche dinamiche.

3.2.3.1 Panoramica di tutti i messaggi

La seguente panoramica illustra quali messaggi devono essere realizzati. La relativa struttura è reperibile nel capitolo seguente.

Messaggi internazionali

Denominazione Percorso di

comunicazione Business Use Case Descrizione breve IE004 Inviato da UDSC Completamento della

dichiarazione delle merci Il completamento viene accettato

IE009 Inviato da UDSC Annullamento della

dichiarazione delle merci Conferma di annullamento IE013 Ricevuto da UDSC Completamento della

dichiarazione delle merci Aggiungere ulteriori merci a una dichiarazione esistente IE014 Ricevuto da UDSC Annullamento della

dichiarazione delle merci Annullare la dichiarazione delle merci

IE015 Ricevuto da UDSC Dichiarazione delle merci La dichiarazione delle merci viene spedita

IE019 Inviato da UDSC Dichiarazione delle merci Informazione: i risultati del controllo evidenziano discrepanze

IE028 Inviato da UDSC Dichiarazione delle merci La ricezione della dichiarazione viene confermata

IE029 Inviato da UDSC Dichiarazione delle merci Informazione: è stata effettuata la liberazione del transito

IE045 Inviato da UDSC Dichiarazione delle merci, procedure di ricerca e di riscossione dei tributi

La procedura di transito è regolarmente

conclusa/terminata IE051 Inviato da UDSC Dichiarazione delle merci Informazione: non avviene

l’assegnazione al regime di transito

IE060 Inviato da UDSC Dichiarazione delle merci Informazione: svolgimento di un controllo

IE140 Inviato da UDSC Procedura di ricerca Vengono richieste informazioni sul regime di transito

IE141 Ricevuto da UDSC Procedura di ricerca Risposta alla richiesta di informazioni sul regime di transito

IE182 Inviato da UDSC Dichiarazione delle merci Informazioni su un evento durante il viaggio

Messaggi nazionali

3.2.3.2

In questo capitolo sono riportate le strutture tecniche con il rimando a regole e condizioni di ogni singolo messaggio. Viene operata una distinzione tra messaggi inviati o ricevuti dall’UDSC. Per i messaggi dell’UDSC, per semplificare si rinuncia a regole e condizioni. Queste sono tuttavia previste per i messaggi all’UDSC, visto che una verifica da parte del mittente è assolutamente necessaria.

Nota: nella prima versione/pubblicazione i dati sono messi a disposizione solo in formato Excel.

Legenda

Arancione: ancora in fase di chiarimento; il campo/gruppo deve essere sempre rappresentato in XML; i chiarimenti riguardano regole/condizioni e contenuto.

Rosso: non è applicabile per la Svizzera; il campo/gruppo deve comunque essere in XML, ma può essere lasciato vuoto oppure la regola/condizione non deve essere applicata.

3.2.3.2.1 Allegato IE-Meldungen-V1.0.xlsx IE-XSD-Schema-V1.0.zip 3.2.3.2.2 IE004