Documentazione sul sistema Passar per sviluppatori di software - Bozza 16.11.2020
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
Documentazione sul sistema Passar per sviluppatori di software Bozza 16.11.2020
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
2
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.
3
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
4
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.
5
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
6
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 Un partner commerciale è una persona fisica o Esempio SA
commerciale giuridica di diritto pubblico o privato che –
(PC) volontariamente o per necessità – usufruisce di una Test Sagl
prestazione di un ufficio dell’Amministrazione federale Gianni
oppure offre una prestazione. Bernasconi
Spedizioni
Utente Un utente è un utilizzatore autorizzato di un software o Un account utente
di un dispositivo elettronico dell’UDSC. creato tramite
CH-LOGIN
Un utente FED
tramite smartcard
Ruolo del Il ruolo di un partner commerciale definisce la relazione Passar
partner d’affari tra un partner e l’UDSC. Questa relazione
commerciale comporta diritti e obblighi. Transportcockpit
(ruolo PC) La definizione deriva da: Birra
ꞏ tema/contenuto della relazione d’affari TTPCP
ꞏ motivazione della relazione
ꞏ diritti e obblighi
ꞏ attività dell’interlocutore
ꞏ responsabilità definita per legge
Profilo utente Un profilo utente riassume un gran numero di singoli Amministratore
diritti che disciplinano l’interazione con software e tecnico
sistemi operativi. I profili utente vengono impiegati per
non dover stabilire singolarmente nel dettaglio i diritti Dichiarante
specifici di ciascun utente. Un utente può avere vari Esperto Finanze
profili: in tal caso i suoi diritti sono il risultato dell’unione
dei diritti di tutti i profili.
Ruolo Un ruolo applicativo è l’autorizzazione a utilizzare una Dichiarare una
applicativo funzione di un software e ad accedere a determinati merce
dati.
7
Termine Definizione Esempi
Dichiarare
l’imposta sulla
birra
Dichiarare la
TTPCP
Applicazione Un’applicazione specialistica risponde, sotto forma di Passar
specialistica software, alle esigenze dell’utente finale rispetto a un
determinato argomento specialistico. 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
8
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
9
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.
10La 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.
113.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:
12 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 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
(Rxxxx)
contenuto. Può essere calcolabile e può essere testata.
Condizioni 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ò
(Cxxxx)
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.
13Regole tecniche Un’istruzione supplementare dal punto di vista tecnico informatico, che
principalmente aggiunge o chiarisce regole di funzionamento e
(Txxxx)
condizioni.
Regole di business per Business Rule for Transition (BRT)
la trasmissione (B1xxx
Con le BRT si garantisce che singole regole e condizioni non siano
& B2xxx)
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 Determina la sequenza di condizioni, regole tecniche per la
sequenziamento trasmissione, regole tecniche e regole ove questa si scosti dalla
sequenza standard.
(Sxxxx)
Sequenza standard: validazione formato (XSD), liste di codici,
BRT/TRT, condizioni, regole, regole tecniche
Guideline (linee guida) 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.
(Gxxxx)
Regole tecniche per la Technical Rule for Transition (TRT).
trasmissione
Una limitazione che rende necessaria una più rigida struttura dei
(Exxxx) 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).
1415
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 Submission date/Reception date Decisive Date ≤
in cui sono presenti TRT of IE by NCA
end date of TP
(system date and time)
BRT- IE015 Reception date of IE by NCA Decisive Date ≤
1
(system date and time) end date of TP
Applicabile a tutti i messaggi IE Declaration acceptance date
in cui sono presenti BRT-1 a
(declarationAcceptanceDate)
esclusione di IE015
BRT- IE015 Reception date of IE by NCA Decisive Date >
2
(system date and time) end date of TP
Applicabile a tutti i messaggi IE Declaration acceptance date
in cui sono presenti BRT-2 a
(declarationAcceptanceDate)
esclusione di IE015
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
16obbligatorio. 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:
verso gruppi/campi
o
verso gruppi/campi all’interno dei messaggi IE da validare
o
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.
173.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
183.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
193.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 Esempi
denominazione
Dato Tag XML
Campo Semplice Se si tratta di un MRN MRN
di dati (Simple) acronimo, tutto in
maiuscolo, Declaration declarationDate
(Data date
altrimenti in
Item)
formato
Presentation presentationNotificationRejectionDate
camelCase.
notification
rejection date
Gruppo Complesso Se si tratta di un GNSS GNSS
di dati (Complex) acronimo, tutto in
maiuscolo, GOODS GoodsShipment
(Data SHIPMENT
altrimenti in
Group)
formato
TRANSPORT TransportEquipment
PascalCase.
EQUIPMENT
ADDITIONAL AdditionalSupplyChainActor
SUPPLY
CHAIN
ACTOR
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: CCC. 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.
203.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 .
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.
213.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 Business Use Case Descrizione breve
comunicazione
IE004 Inviato da UDSC Completamento della Il completamento viene
dichiarazione delle merci accettato
IE009 Inviato da UDSC Annullamento della Conferma di annullamento
dichiarazione delle merci
IE013 Ricevuto da UDSC Completamento della Aggiungere ulteriori merci a
dichiarazione delle merci una dichiarazione esistente
IE014 Ricevuto da UDSC Annullamento della Annullare la dichiarazione
dichiarazione delle merci 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, La procedura di transito è
procedure di ricerca e di regolarmente
riscossione dei tributi 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
223.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
vedi Excel "IE-Meldungen-V1.0" & ZIP "IE-XSD-Schema-V1.0"
3.2.3.2.4 IE013
vedi Excel "IE-Meldungen-V1.0" & ZIP "IE-XSD-Schema-V1.0"
3.2.3.2.5 IE014
vedi Excel "IE-Meldungen-V1.0" & ZIP "IE-XSD-Schema-V1.0"
3.2.3.2.6 IE015
vedi Excel "IE-Meldungen-V1.0" & ZIP "IE-XSD-Schema-V1.0"
3.2.3.2.7 IE019
vedi Excel "IE-Meldungen-V1.0" & ZIP "IE-XSD-Schema-V1.0"
3.2.3.2.8 IE028
vedi Excel "IE-Meldungen-V1.0" & ZIP "IE-XSD-Schema-V1.0"
3.2.3.2.9 IE029
vedi Excel "IE-Meldungen-V1.0" & ZIP "IE-XSD-Schema-V1.0"
3.2.3.2.10 IE035
segue
3.2.3.2.11 IE045
vedi Excel "IE-Meldungen-V1.0" & ZIP "IE-XSD-Schema-V1.0"
3.2.3.2.12 IE051
vedi Excel "IE-Meldungen-V1.0" & ZIP "IE-XSD-Schema-V1.0"
3.2.3.2.13 IE060
vedi Excel "IE-Meldungen-V1.0" & ZIP "IE-XSD-Schema-V1.0"
233.2.3.2.14 IE140
vedi Excel "IE-Meldungen-V1.0" & ZIP "IE-XSD-Schema-V1.0"
3.2.3.2.15 IE141
vedi Excel "IE-Meldungen-V1.0" & ZIP "IE-XSD-Schema-V1.0"
3.2.3.2.16 IE182
vedi Excel "IE-Meldungen-V1.0" & ZIP "IE-XSD-Schema-V1.0"
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
243.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
254 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 App Transportcockpit Strada Ferrovia Acqua Aria
utente
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 x x x x
(attivo o passivo)
Ammissione x x x x
temporanea
Deposito doganale x x x
Traffico agricolo x x
Periodic x
Presentazione di x x x x x x
documenti
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
265 FAQ
276 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
28Termine Definizione
PTC Regime comune di transito
AAR ANTICIPATED ARRIVAL RECORD
ATR ANTICIPATED TRANSIT RECORD
AXR ANTICIPATED EXIT RECORD
297 Elenco delle abbreviazioni
Abbreviazione Significato Traduzione in Osservazioni aggiuntive
italiano (se
necessario)
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 Applicazione
Application 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 Prescrizioni e procedure dell’unione
dell’Unione doganale
UDSC Ufficio federale della
dogana e della
sicurezza dei confini
30Puoi anche leggere
