Documentazione sul sistema Passar per sviluppatori di software

(1)

Documentazione sul sistema Passar

per sviluppatori di software

(2)

Indice

2.1 Basi legali ... 4

2.2 Il processo di base nel traffico delle merci ... 4

2.2.1 Informazione e Consultazione ... 4

2.2.2 Registrazione e Permessi ... 4

2.2.3 Dichiarazione doganale ... 5

2.2.4 Attivazione ... 5

2.2.5 Selezione ... 6

2.2.6 Intervenzione ... 6

2.2.7 Fatturazione ... 6

2.2.8 Accorgimenti a posteriori (per esempio ricorsi o controlli a posteriori) ... 6

2.2.9 Trattamento successivo ... 6

2.3 Il modello dei ruoli ... 7

2.3.1 Introduzione ... 7

2.3.2 Terminologia ... 7

2.3.3 Modello ... 8

2.3.4 Processo di richiesta ... 8

2.4 Possibilità di interazione ... 8

2.4.1 Canali ... 8

2.5 Destinazioni delle merci ... 9

2.6 Imposizioni speciali ... 9

2.7 Procedura d’emergenza ... 9

3.1 Processi tecnici ... 10

3.1.1 Processo d'importazione ... 10

3.1.2 Processo d'esportazione ... 10

3.1.3 Processo di transito... 10

3.1.4 Processo di esportazione e transito ... 13

3.1.5 Processo di transito e importazione ... 13

3.2 Descrizioni delle interfacce e regole di plausibilità ... 13

3.2.1 Panoramica ... 13

3.2.2 Informazioni di base ... 13

3.2.3 Specifiche tecniche per il transito ... 21

3.2.4 Specifiche tecniche per l’esportazione ... 25

3.2.5 Specifiche tecniche per l’importazione ... 25

3.2.6 Specifiche tecniche per l’esportazione e il transito ... 25

3.2.7 Specifiche tecniche per il transito e l’esportazione ... 25

3.2.8 Specifiche tecniche per la dichiarazione del trasporto ... 25

3.3 Implementazione tecnica dell’attivazione ... 25

3.3.1 Traffico stradale ... 25

3.3.2 Traffico ferroviario ... 25

3.3.3 Traffico aereo ... 25

3.3.4 Traffico per via d’acqua ... 25

3.4 Test ... 25

3.5 Presentazione di documenti ... 25

3.6 Rilascio di documenti ... 25

4.1 Ambienti di sistema e test ... 26

4.2 Organizzazione strutturale e procedurale ... 26

4.3 Fase di introduzione ed esercizio parallelo ... 26

4.3.1 Spettro dell’offerta per ciascun canale ... 26

4.3.2 Esercizio parallelo esportazione ... 26

4.3.3 Esercizio parallelo transito ... 26

4.3.4 Esercizio parallelo importazione ... 26

4.4 Piano delle scadenze ... 26

(3)

1 Introduzione

Con il nuovo sistema per il traffico delle merci Passar, l’Ufficio federale della dogana e della sicurezza dei confini (UDSC, l’organizzazione che succederà all’AFD dal 2022) intende semplificare, armonizzare e digitalizzare interamente i processi per la riscossione di dazi e tributi. L’obiettivo è accelerare il traffico transfrontaliero delle merci e l’imposizione in Svizzera, aumentando allo stesso tempo la sicurezza per la popolazione, l’economia e lo Stato.

La presente documentazione serve alle imprese che sviluppano programmi informatici per sé o per terzi come base per la creazione di software per l’imposizione e di interfacce con Passar.

La documentazione viene elaborata e ampliata con una procedura iterativa all’interno del gruppo di lavoro DaziT che si occupa dello sviluppo di software. Alcuni aspetti, come la terminologia o i dettagli dei sottoprocessi, potranno ancora essere modificati o ulteriormente elaborati nel quadro della revisione totale della legge sulle dogane e dei progetti di

digitalizzazione in corso (programma DaziT). Alcuni dei termini impiegati corrispondono già alla prevista terminologia della nuova legislazione doganale.

Fino alla pubblicazione della versione finale, il contenuto della documentazione va inteso come bozza non vincolante.

Dalla documentazione non può essere desunto alcun diritto.

(4)

2 Basi tecniche

2.1 Basi legali

2.2 Il processo di base nel traffico delle merci

Il nuovo processo di base mira a semplificare, armonizzare e digitalizzare interamente la riscossione di dazi e tributi. L’obiettivo è accelerare il traffico transfrontaliero delle merci e l’imposizione in Svizzera, aumentando allo stesso tempo la sicurezza per la popolazione, l’economia e lo Stato.

2.2.1 Informazione e Consultazione

Le richieste degli interlocutori (ditte e privati) vengono presentate tramite l’ePortal. Su questa piattaforma è possibile accedere anche a tutte le informazioni e a tutti i servizi dell’UDSC. Le informazioni sono messe a disposizione in forma chiara e uniforme. Nei casi in cui è possibile e utile, un assistente digitale (p. es. un chatbot) risponde a domande semplici e ricorrenti.

 Informazioni chiare

 Primo contatto uniforme tramite l’ePortal

 Coordinamento delle richieste mediante chatbot

 Continuo miglioramento delle informazioni

2.2.2 Registrazione e Permessi

La registrazione e la richiesta delle autorizzazioni avvengono tramite l’ePortal. Il cliente può effettuare la prima registrazione come partner commerciale oppure modificare i dati del proprio profilo. Attraverso l’ePortal, inoltre, è possibile richiedere autorizzazioni nel campo di

(5)

competenza dell’UDSC. Alla prima registrazione, ogni cliente riceve un identificativo univoco di partner commerciale (ID PC).

2.2.2.1 Processo di registrazione 2.2.2.2 Autorizzazioni

2.2.3 Dichiarazione doganale

Il partner commerciale dichiara le merci nel sistema per il traffico delle merci Passar prima di passare il confine. Dopo la trasmissione dei dati, Passar esegue una validazione e una verifica della plausibilità. Alla dichiarazione delle merci viene assegnato un ID univoco. I dati delle dichiarazioni delle merci già registrate e trasmesse possono essere modificati in qualsiasi momento fino all’attivazione della dichiarazione.

Validazione e verifica della plausibilità

Passar effettua automaticamente la validazione e la verifica della plausibilità di ogni trasmissione di dati (prima trasmissione e modifiche). I dati non validi vengono contestati. Il partner commerciale riceve un riscontro in tal senso. Affinché Passar accetti la dichiarazione delle merci, è necessario correggere i punti contestati e trasmettere nuovamente la

dichiarazione.

2.2.3.1 Documenti di scorta

2.2.3.1.1 Certificato di circolazione delle merci (CCM) 2.2.3.1.2 Certificati

2.2.3.2 BorderTicket

Affinché in caso di impianti doganali a controlli nazionali abbinati in futuro non sia più

necessario recarsi allo sportello anche presso l’ufficio doganale estero, si intende adottare con i Paesi confinanti una soluzione digitale, un cosiddetto BorderTicket, in sostituzione dell’attuale foglio di circolazione cartaceo.

2.2.3.3 Termini

2.2.3.4 Indicazione del riferimento

Nel traffico transfrontaliero, le dichiarazioni delle merci devono essere collegate al rispettivo mezzo di trasporto (= indicazione del riferimento).

La dichiarazione delle merci e l’indicazione del riferimento possono essere modificate (corrette, cancellate) in qualsiasi momento fino all’attivazione del mezzo di trasporto.

2.2.4 Attivazione

Il mezzo di trasporto e la dichiarazione delle merci ad esso collegata vengono attivati

automaticamente al passaggio del confine. Da questo momento la dichiarazione delle merci è giuridicamente vincolante e non può più essere modificata. Un’eventuale richiesta di correzione deve essere presentata nel quadro della procedura d’opposizione.

(6)

2.2.4.1 Strada 2.2.4.2 Ferrovia 2.2.4.3 Aria 2.2.4.4 Acqua

2.2.4.5 Condotte fisse (gasdotti)

2.2.4.6 Agevolazioni per determinati partecipanti alla procedura

2.2.5 Selezione

Dopo l’attivazione, la dichiarazione delle merci viene sottoposta a una nuova verifica della plausibilità e a un’analisi dei rischi completa. Il risultato della selezione è comunicato al responsabile del trasporto, così come alla persona che ha trasmesso la dichiarazione delle merci.

2.2.6 Intervenzione

L’intervento può avvenire direttamente al confine oppure in un altro luogo definito dall’UDSC.

Un intervento può comprendere un controllo di persone, merci e mezzi di trasporto.

Gli interventi, in particolare i controlli approfonditi delle merci e i chiarimenti, possono svolgersi in qualsiasi momento, anche successivo, per esempio presso il domicilio del destinatario delle merci.

2.2.7 Fatturazione

Dopo l’attivazione e la conclusione di un eventuale intervento, l’UDSC notifica una decisione d’imposizione. L’ammontare dei tributi è calcolato sulla base della dichiarazione delle merci. Le disposizioni vengono messe a disposizione in formato digitale.

2.2.8 Accorgimenti a posteriori (per esempio ricorsi o controlli a posteriori)

2.2.9 Trattamento successivo

Il trattamento successivo comprende diverse attività che possono rendersi necessarie dopo la notifica della decisione d’imposizione.

Esempi:

 trattamento delle opposizioni

 attività di controllo successive da parte dell’UDSC: controlli contabili successivi relativi a merci già imposte e controlli successivi relativi a tributi riscossi o restituiti in Svizzera

(7)

2.2.9.1 Opposizioni e ricorsi 2.2.9.2 Controllo successivo

2.3 Il modello dei ruoli 2.3.1 Introduzione

Gli utenti (partner commerciali) dei sistemi dell’UDSC vengono autorizzati esplicitamente per ogni applicazione specialistica che hanno diritto di utilizzare. L’autorizzazione si riferisce alle funzioni che l’utente può utilizzare nell’applicazione. Le autorizzazioni vengono raggruppate, in maniera da poter essere assegnate o revocate a un utente senza difficoltà.

2.3.2 Terminologia

Termini relativi al modello dei ruoli.

Termine Definizione Esempi

Partner commerciale (PC)

Un partner commerciale è una persona fisica o giuridica di diritto pubblico o privato che –

volontariamente o per necessità – usufruisce di una prestazione di un ufficio dell’Amministrazione federale oppure offre una prestazione.

 Esempio SA

 Test Sagl

 Gianni Bernasconi Spedizioni Utente Un utente è un utilizzatore autorizzato di un software o

di un dispositivo elettronico dell’UDSC.  Un account utente creato tramite CH-LOGIN

 Un utente FED tramite smartcard Ruolo del

partner commerciale (ruolo PC)

Il ruolo di un partner commerciale definisce la relazione d’affari tra un partner e l’UDSC. Questa relazione comporta diritti e obblighi.

La definizione deriva da:

ꞏ tema/contenuto della relazione d’affari ꞏ motivazione della relazione

ꞏ diritti e obblighi

ꞏ attività dell’interlocutore

ꞏ responsabilità definita per legge

 Passar

 Transportcockpit

 Birra

 TTPCP

Profilo utente Un profilo utente riassume un gran numero di singoli diritti che disciplinano l’interazione con software e sistemi operativi. I profili utente vengono impiegati per non dover stabilire singolarmente nel dettaglio i diritti specifici di ciascun utente. Un utente può avere vari profili: in tal caso i suoi diritti sono il risultato dell’unione dei diritti di tutti i profili.

 Amministratore tecnico

 Dichiarante

 Esperto Finanze

Ruolo applicativo

Un ruolo applicativo è l’autorizzazione a utilizzare una funzione di un software e ad accedere a determinati dati.

 Dichiarare una merce

(8)

Termine Definizione Esempi

 Dichiarare l’imposta sulla birra

 Dichiarare la TTPCP

Applicazione

specialistica Un’applicazione specialistica risponde, sotto forma di software, alle esigenze dell’utente finale rispetto a un determinato argomento specialistico.

 Passar

 Biera

2.3.3 Modello

2.3.4 Processo di richiesta

Per poter trasmettere dichiarazioni delle merci, l’interlocutore deve essere registrato presso l’UDSC. Questo processo avviene tramite l’ePortal e viene descritto nel dettaglio in seguito.

2.4 Possibilità di interazione

Fondamentalmente, l’interlocutore entra in contatto con l’UDSC durante quattro fasi:

 la registrazione

 al momento della presentazione o della modifica della dichiarazione delle merci

 per la gestione di output e input (documenti in uscita e in entrata)

 in caso di opposizione

1. Registrazione

La registrazione – che comprende la richiesta dell’accesso (tramite UI o B2B) così come la gestione dei dati di base, dei necessari ruoli e di eventuali autorizzazioni – avviene tramite l’ePortal e deve essere effettuata prima di dichiarare per la prima volta delle merci.

2. Presentazione della dichiarazione delle merci

Dopo la corretta registrazione, l’interlocutore può presentare dichiarazioni delle merci.

3. Gestione dei documenti in uscita e in entrata (output e input)

Anche la gestione di output e input può avvenire tramite i canali citati. La gestione degli input dell’UDSC serve a caricare documenti (documenti di scorta). La gestione degli output viene impiegata per recapitare documenti (decisioni, fatture) al partner commerciale.

4. Opposizioni

Il partner commerciale può fare opposizione contro le decisioni.

A seconda delle funzioni richieste sono disponibili diversi canali.

2.4.1 Canali

Per la comunicazione con l’UDSC sono disponibili i seguenti canali:

 Gateway B2B: scambio di documenti in formato XML attraverso un’interfaccia elettronica

(9)

 B2B light (upload XML): scambio di documenti in formato XML attraverso l’ePortal

 ePortal: inserimento dei dati necessari da parte dell’interlocutore tramite l’interfaccia utente dell’UDSC

 App mobile: trasmissione tramite dispositivo mobile

Panoramica dei canali di interazione

Principi:

 L’interlocutore può scegliere liberamente quale canale impiegare.

 Sempre che abbia effettuato la necessaria registrazione, l’interlocutore può passare da un canale all’altro.

 A livello funzionale non ci sono differenze tra i canali (eccezion fatta per le applicazioni mobili con funzioni limitate).

 Le opposizioni possono essere presentate solo tramite l’ePortal.

2.5 Destinazioni delle merci

2.6 Imposizioni speciali

2.7 Procedura d’emergenza

(10)

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.

(11)

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.

(12)

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:

(13)

 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.

(14)

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).

(15)

(16)

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

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

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

(17)

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.

(18)

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

(19)

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

(20)

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

denominazione Esempi

Dato Tag XML

Campo di dati (Data Item)

Semplice (Simple)

Se si tratta di un acronimo, tutto in maiuscolo, altrimenti in formato camelCase.

MRN MRN Declaration

date declarationDate Presentation

notification rejection date

presentationNotificationRejectionDate

Gruppo di dati (Data Group)

Complesso (Complex)

Se si tratta di un acronimo, tutto in maiuscolo, altrimenti in formato PascalCase.

GNSS GNSS GOODS

SHIPMENT GoodsShipment TRANSPORT

EQUIPMENT TransportEquipment ADDITIONAL

SUPPLY CHAIN ACTOR

AdditionalSupplyChainActor

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.

(21)

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)

 hytypes.xsd

 stypes.xsd

 tcl.xsd

 ctypes.xsd

 doc.xsd

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.

(22)

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

(23)

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

vedi Excel "IE-Meldungen-V1.0" & ZIP "IE-XSD-Schema-V1.0"

3.2.3.2.3 IE009

3.2.3.2.4 IE013

3.2.3.2.5 IE014

3.2.3.2.6 IE015

3.2.3.2.7 IE019

3.2.3.2.8 IE028

3.2.3.2.9 IE029

3.2.3.2.10 IE035 segue

3.2.3.2.11 IE045

3.2.3.2.12 IE051

3.2.3.2.13 IE060

(24)

3.2.3.2.14 IE140

3.2.3.2.15 IE141

3.2.3.2.16 IE182

3.2.3.2.17 NC909 segue

3.2.3.3 Regole e condizioni

I messaggi che vengono inviati all’UDSC devono essere verificati in base alle regole e alle condizioni assegnate. Per completezza sono riportate tutte le regole e le condizioni dei messaggi IE015, IE013, IE014 e IE141. Nel caso in cui in Svizzera debbano essere osservate in particolare singole regole/condizioni, queste ultime vengono evidenziate con un colore diverso, analogamente a quanto avviene per i messaggi.

Arancione: ancora in fase di chiarimento.

Rosso: non si applica in Svizzera; non deve essere attuato.

Allegato: Regeln und Bedinungen-V1.0.xlsx

(25)

3.2.4 Specifiche tecniche per l’esportazione 3.2.5 Specifiche tecniche per l’importazione

3.2.6 Specifiche tecniche per l’esportazione e il transito 3.2.7 Specifiche tecniche per il transito e l’esportazione 3.2.8 Specifiche tecniche per la dichiarazione del trasporto 3.3 Implementazione tecnica dell’attivazione

3.3.1 Traffico stradale 3.3.2 Traffico ferroviario 3.3.3 Traffico aereo

3.3.4 Traffico per via d’acqua 3.4 Test

3.5 Presentazione di documenti

3.6 Rilascio di documenti

(26)

4 Piano di introduzione di Passar

4.1 Ambienti di sistema e test

4.2 Organizzazione strutturale e procedurale

4.3 Fase di introduzione ed esercizio parallelo 4.3.1 Spettro dell’offerta per ciascun canale

Con poche eccezioni, tutti i canali offrono le stesse funzioni:

Canale Generi di traffico

Procedura doganale B2B Interfaccia

utente App Transportcockpit Strada Ferrovia Acqua Aria

Importazione x x x x x x x

Esportazione x x x x x x x

CCM x x x

Transito x x x x x x x

Perfezionamento

(attivo o passivo) x x x x

Ammissione

temporanea x x x x

Deposito doganale x x x

Traffico agricolo x x

Periodic x

Presentazione di

documenti x x x x x x

Rilascio di documenti x x x x x x

Imposizione di veicoli x x x x x x

Dati di trasporto x x x x

4.3.2 Esercizio parallelo esportazione 4.3.3 Esercizio parallelo transito

4.3.4 Esercizio parallelo importazione

4.4 Piano delle scadenze

(27)

5 FAQ

(28)

6 Definizioni dei termini / Glossario

Termine Definizione

ePortal TP Puntatori UI dichiarazione delle merci UDSC

Modello TAXUD fase 5 Verifica della plausibilità Validazione sintattica Validazione semantica

Attivazione BorderTicket Intervento User Interface (UI)

Gestione di output e input

Interlocutore Transportcockpit Telematica API Applicazione mobile

APP B2B light

Notifica

Passar Decisione Responsabile dei dati

Responsabile delle merci Responsabile del trasporto

UDSC DocBox

Destinazioni delle merci B2B API

MRN

(29)

Termine Definizione

PTC Regime comune di transito

AAR ANTICIPATED ARRIVAL RECORD

ATR ANTICIPATED TRANSIT RECORD

AXR ANTICIPATED EXIT RECORD

(30)

7 Elenco delle abbreviazioni

Abbreviazione Significato Traduzione in italiano (se necessario)

Osservazioni aggiuntive

B2B Business to Business Relazione d’affari fra due imprese/amministrazioni con scambio elettronico di dati

BPMN Business Process

Model and Notation

DDCOM Design Document for Common Operations and Methods

DDNTA Design Document for

National Transit Application NCA National Customs

Application Applicazione doganale nazionale

PC Partner commerciale

TFTP Tassa forfettaria sul traffico pesante

TTPCP Tassa sul traffico pesante commisurata alle prestazioni

UCC Union Customs Code Codice doganale

dell’Unione Prescrizioni e procedure dell’unione doganale

UDSC Ufficio federale della dogana e della sicurezza dei confini