Documentation Passar pour développeurs de logiciels

Documentation Passar pour développeurs de logiciels

Projet du 16.11.2020

2

Table des matières

2.1 Bases légales ..................................................................................................................... 4 2.2 Processus de base de la circulation des marchandises .................................................... 4 2.2.1 Information et conseil .................................................................................................................... 4 2.2.2 Enregistrement et autorisation ...................................................................................................... 4 2.2.3 Déclaration .................................................................................................................................... 5 2.2.4 Activation ...................................................................................................................................... 5 2.2.5 Sélection ....................................................................................................................................... 6 2.2.6 Intervention ................................................................................................................................... 6 2.2.7 Décision ........................................................................................................................................ 6 2.2.8 Surveillance des marchandises et du respect des délais .............................................................. 6 2.2.9 Traitement ultérieur ....................................................................................................................... 6 2.3 Modèle de rôles .................................................................................................................. 7 2.3.1 Introduction ................................................................................................................................... 7 2.3.2 Terminologie ................................................................................................................................. 7 2.3.3 Modèle .......................................................................................................................................... 8 2.3.4 Processus de demande ................................................................................................................ 8 2.4 Possibilités d’interaction ..................................................................................................... 8 2.4.1 Canaux .......................................................................................................................................... 9 2.5 Destinations des marchandises ......................................................................................... 9 2.6 Dédouanements spéciaux .................................................................................................. 9 2.7 Procédure d’urgence .......................................................................................................... 9 3.1 Processus techniques ...................................................................................................... 10 3.1.1 Processus d’importation .............................................................................................................. 10 3.1.2 Processus d’exportation .............................................................................................................. 10 3.1.3 Processus de transit.................................................................................................................... 10 3.1.4 Processus d’exportation + transit ................................................................................................ 13 3.1.5 Processus de transit+ importation ............................................................................................... 13 3.2 Description des interfaces et règles de plausibilité .......................................................... 13 3.2.1 Aperçu ......................................................................................................................................... 13 3.2.2 Informations de base ................................................................................................................... 13 3.2.3 Spécifications techniques du transit ............................................................................................ 22 3.2.4 Spécifications techniques de l’exportation .................................................................................. 25 3.2.5 Spécifications techniques de l’importation .................................................................................. 25 3.2.6 Spécifications techniques de l’exportation + transit ..................................................................... 25 3.2.7 Spécifications techniques du transit + exportation ...................................................................... 25 3.2.8 Spécifications techniques de la déclaration de transport ............................................................ 25 3.3 Mise en œuvre technique de l’activation .......................................................................... 25 3.3.1 Route .......................................................................................................................................... 25 3.3.2 Rail .............................................................................................................................................. 25 3.3.3 Trafic aérien ................................................................................................................................ 25 3.3.4 Bateau ......................................................................................................................................... 25 3.4 Tests ................................................................................................................................. 25 3.5 Production de documents (inputmanagement) ................................................................ 25 3.6 Émission de documents (outputmanagement) ................................................................. 25 4.1 Environnements système et tests .................................................................................... 26 4.2 Organisation des structures et processus ........................................................................ 26 4.3 Phase d’introduction et exploitation parallèle ................................................................... 26 4.3.1 Spectre de l’offre, par canal ........................................................................................................ 26 4.3.2 Exploitation en parallèle dans l’exportation ................................................................................. 26 4.3.3 Exploitation en parallèle dans le transit ....................................................................................... 26 4.3.4 Exploitation en parallèle dans l’importation ................................................................................. 26 4.4 Calendrier ......................................................................................................................... 26

3

1 Introduction

L’Office fédéral de la douane et de la sécurité des frontières (OFDF, organisation appelée à succéder à l’AFD dès 2022) a mis au point Passar, nouveau système de gestion du trafic des marchandises, dans le but de simplifier, d’harmoniser et de numériser de bout en bout les processus de perception des droits de douane et des redevances. Il convient d’accélérer la circulation transfrontalière des marchandises et leur imposition sur le territoire suisse, tout en renforçant la sécurité de la population, de l’économie et de l’État.

La présente documentation servira de base aux entreprises qui développent des logiciels à leur propre usage ou pour des tiers, pour leur permettre de créer des logiciels de dédouanement ou des interfaces avec Passar.

Le groupe de travail Développement logiciel de DaziT a conçu cette documentation, complétée selon un procédé itératif. Certains aspects, à l’instar des termes utilisés ou des détails des sous-processus, sont susceptibles d’être encore adaptés ou développés, dans le cadre de l’actuelle refonte totale de la loi sur les douanes ou des projets de numérisation en cours (programme DaziT). Plusieurs termes employés correspondent déjà à la terminologie probable de la nouvelle législation sur les douanes.

Le contenu de la présente documentation doit être considéré comme non contraignant, jusqu’à la publication de sa version finale.

Cette documentation ne confère aucun droit à ses utilisateurs.

4

2 Bases techniques

2.1 Bases légales

2.2 Processus de base de la circulation des marchandises

Le nouveau processus de base vise à simplifier, harmoniser et numériser de bout en bout la perception des droits de douane et des redevances. Il convient d’accélérer la circulation transfrontalière des marchandises et leur imposition sur le territoire suisse, tout en renforçant la sécurité de la population, de l’économie et de l’État.

2.2.1 Information et conseil L’interlocuteur (qui peut être une entreprise ou un particulier) transmet sa requête via l’ePortal. Cette plateforme donne accès à toutes les informations ou prestations de services de l’OFDF. Les informations y sont fournies de façon claire et uniforme. Là où cela est possible et judicieux, un assistant numérique (par ex. chatbot ou agent conversationnel) répondra aux questions simples et récurrentes.

Aperçu des informations

Premier contact standardisé via l’ePortal

Coordination des requêtes par l’assistant numérique

Amélioration constante des informations

2.2.2 Enregistrement et autorisation L’enregistrement s’effectue sur l’ePortal, tout comme les demandes d’autorisation. Le client peut s’y enregistrer pour la première fois en tant que partenaire commercial, ou alors modifier

5

les données de son profil. En outre, l’ePortal permet de solliciter les autorisations qui relèvent de la compétence de l’OFDF. Chaque client reçoit, lors de son premier enregistrement, une identité unique de partenaire commercial (ID partenaire).

2.2.2.1 Processus d’enregistrement

2.2.2.2 Autorisations

2.2.3 Déclaration Le partenaire commercial déclare les marchandises avant le passage de la frontière dans le système de gestion du trafic des marchandises Passar. Après le transfert des données, Passar les valide et en contrôle la plausibilité. La déclaration des marchandises reçoit un identifiant unique. Les données déjà saisies et transmises peuvent être modifiées en tout temps jusqu’à l’activation de la déclaration des marchandises.

Validation et contrôle de la plausibilité

Passar procède automatiquement à la validation et au contrôle de la plausibilité de toutes les données transmises (première transmission ou adaptations). Les données saisies non valides font l’objet d’une contestation. Le partenaire commercial est informé et pour que Passar accepte la déclaration des marchandises, il lui faut effectuer la correction requise et transmettre une seconde fois sa déclaration.

2.2.3.1 Documents d’accompagnement

2.2.3.1.1 Mention des certificats de circulation des marchandises (CCM)

2.2.3.1.2 Certificats

2.2.3.2 BorderTicket Une solution numérique, appelée «BorderTicket», est envisagée avec les pays voisins pour qu’à l’avenir, dans les installations douanières communes du trafic routier, il ne soit plus nécessaire de se rendre au guichet du bureau de contrôle national juxtaposé. Il s’agit de remplacer l’actuelle fiche de transmission sur papier.

2.2.3.3 Délais

2.2.3.4 Référencement Dans la circulation transfrontalière des marchandises, les déclarations des marchandises doivent être reliées au moyen de transport correspondant (= référencement).

La déclaration des marchandises et le référencement peuvent être modifiés en tout temps (correction, suppression des données) jusqu’à l’activation du moyen de transport.

2.2.4 Activation Le moyen de transport et la ou les déclarations des marchandises référencées sont automatiquement activés au passage de la frontière. À partir de ce moment, la déclaration devient juridiquement contraignante et il n’est plus possible de la modifier. Une éventuelle demande de correction devra être faite dans le cadre de la procédure d’opposition.

6

2.2.4.1 Route

2.2.4.2 Rail

2.2.4.3 Trafic aérien

2.2.4.4 Bateau

2.2.4.5 Conduites installées à demeure (conduites de gaz)

2.2.4.6 Allégements pour certains participants à la procédure

2.2.5 Sélection Après l’activation, la déclaration des marchandises est soumise à un nouveau contrôle de plausibilité et à une analyse approfondie des risques. Le résultat de la sélection est communiqué tant au responsable du transport qu’à la personne ayant transmis la déclaration des marchandises.

2.2.6 Intervention L’intervention peut avoir lieu directement à la frontière ou à d’autres endroits définis par l’OFDF. Le contrôle effectué à cette occasion peut porter à la fois sur les personnes, les marchandises et le moyen de transport.

Des interventions, en particulier des contrôles approfondis de marchandises et des examens détaillés, peuvent avoir lieu en tout temps – y compris a posteriori – sur tout le territoire douanier, par exemple au domicile du destinataire des marchandises.

2.2.7 Décision Après l’activation ou à l’issue d’une éventuelle intervention, l’OFDF rend une décision de taxation. Le montant des redevances est calculé sur la base de la déclaration des marchandises. Les décisions sont délivrées par voie électronique.

2.2.8 Surveillance des marchandises et du respect des délais

2.2.9 Traitement ultérieur Les processus en aval comprennent différentes activités pouvant intervenir après la notification de la décision de taxation.

Exemples:

traitement des oppositions;

activités de contrôle a posteriori par l’OFDF: contrôles comptables ultérieurs de marchandises déjà taxées et contrôles ultérieurs de redevances perçues ou remboursées sur le territoire suisse.

7

2.2.9.1 Oppositions et recours

2.2.9.2 Contrôle a posteriori

2.3 Modèle de rôles

2.3.1 Introduction Les utilisateurs (partenaires commerciaux) des systèmes de l’OFDF reçoivent, pour chaque application spécialisée dont ils peuvent faire usage, une autorisation explicite précisant les fonctions qu’ils sont en droit d’y exécuter. Les autorisations sont groupées, pour que l’OFDF puisse les accorder à un utilisateur ou les lui retirer de manière simplifiée.

2.3.2 Terminologie La terminologie liée au modèle de rôles est la suivante.

Termes Définitions Exemples

Partenaire commercial (partenaire)

Personne physique ou morale de droit public ou relevant du droit civil qui – spontanément ou par contrainte – recourt à une prestation d’un office de l’administration fédérale ou fournit une telle prestation.

Muster SA

Test Sàrl

Duperrex Frères Transports

Utilisateur Utilisateur habilité à se servir d’un logiciel ou d’un appareil électronique de l’OFDF.

Compte d’utilisateur créé avec la procédure CH-LOGIN

Authentification de l’utilisateur par carte à puce (FED-LOGIN)

Rôle de partenaire commercial

(rôle de partenaire)

Relation commerciale établie entre un partenaire commercial et l’OFDF. Une telle relation comporte des droits et des obligations.

Plusieurs éléments combinés confèrent un tel statut:

ꞏ Thème / teneur de la relation commerciale

ꞏ Raisons motivant une telle relation

ꞏ Droits et obligations

ꞏ Activité de l’interlocuteur

ꞏ Responsabilité juridiquement définie

Passar

Cockpit de transport

Biera

RPLP

Profil d’utilisateur

Ensemble de droits réglant les interactions avec les logiciels et les systèmes d’exploitation. Les profils d’utilisateur évitent de devoir définir individuellement les droits détaillés de chaque utilisateur. Un utilisateur peut disposer de plusieurs profils. Le cas échéant, ses droits découlent du cumul des droits conférés par tous les profils.

Spécialiste

Déclarant

Expert financier

Rôle d’utilisateur

Permission d’utiliser une fonction d’un logiciel et d’accéder à certaines données.

Déclaration d’une marchandise

Déclaration de l’impôt sur la bière

8

Termes Définitions Exemples

Déclaration de la RPLP

Application spécialisée

Application logicielle couvrant un thème de manière exhaustive pour les utilisateurs finaux.

Passar

Biera

2.3.3 Modèle

2.3.4 Processus de demande L’interlocuteur doit être enregistré auprès de l’OFDF avant de pouvoir lui transmettre toute déclaration de marchandises. Ce processus s’effectuant sur l’ePortal fera plus tard l’objet d’une description exhaustive.

2.4 Possibilités d’interaction

En principe, l’interlocuteur peut entrer en contact avec l’OFDF au cours des quatre phases:

enregistrement

remise ou adaptation de la déclaration des marchandises

gestion des flux documentaires

oppositions

1. Enregistrement

L’enregistrement s’effectue sur l’ePortal. Il comprend la demande d’accès (interface utilisateur ou B2B), la gestion des données de base, des rôles nécessaires et des éventuelles autorisations. Il doit précéder la première déclaration des marchandises.

2. Saisie des déclarations des marchandises

Une fois l’enregistrement effectué, l’interlocuteur peut soumettre ses déclarations de marchandises.

3. Gestion des flux documentaires

La gestion des flux documentaires s’effectue également sur les canaux susmentionnés. Elle permet à l’OFDF à la fois de prendre possession des documents d’accompagnement, des déclarations et de remettre des documents au partenaire commercial (décisions, factures).

4. Oppositions

Le partenaire commercial peut faire opposition contre les décisions reçues.

Divers canaux sont proposés, selon les fonctions attribuées.

9

2.4.1 Canaux Les canaux suivants sont proposés pour la communication avec l’OFDF:

Passerelle B2B: échange de documents XML via une interface électronique

B2B light (téléchargement au format XML): échange de documents XML via l’ePortal

ePortal: saisie par l’interlocuteur des données nécessaires dans l’interface utilisateur de l’OFDF

Mobile App (application mobile): saisie des données sur un appareil mobile.

Aperçu des canaux d’interaction

Principes:

L’interlocuteur peut librement choisir quel canal il souhaite utiliser.

L’interlocuteur peut changer de canal dès qu’il a effectué l’enregistrement nécessaire.

D’un point de vue fonctionnel, il n’y a aucune différence entre les canaux (à l’exception des applications mobiles aux fonctions limitées).

Les oppositions peuvent être émises sur l’ePortal.

2.5 Destinations des marchandises

2.6 Dédouanements spéciaux

2.7 Procédure d’urgence

10

3 Bases techniques

3.1 Processus techniques

Les modèles BPMN ci-après illustrent l’échange des divers messages. Si le modèle n’est pas directement utilisable pour un ou plusieurs genres de trafic, le chapitre renfermant les spécifications correspondantes est à chaque fois indiqué. Les modèles BPMN se concentrent sur les flux de messages entre l’OFDF et les responsables des marchandises, des données et du transport.

3.1.1 Processus d’importation

3.1.2 Processus d’exportation

3.1.3 Processus de transit

3.1.3.1 Transit direct

3.1.3.1.1 Déclaration du transport

3.1.3.2 Transit avec ouverture de procédure en Suisse

3.1.3.2.1 Déclaration des marchandises La déclaration des marchandises (IE015) sert à informer l’OFDF de l’intention d’ouvrir une procédure de transit. Si le message ne renferme pas d’erreur, l’OFDF en accuse réception avec l’avis IE028, qui contient notamment le MRN servant à l’identification univoque de la procédure. En l’absence d’activation dans le délai, la procédure de transit sera déclarée nulle (NC909). Après l’activation (obligation légale), il peut y avoir des contrôles, annoncés par l’avis IE060. Au cas où un placement sous le régime du transit serait impossible, l’avis IE051 le signale. Si tout est en ordre, la procédure de transit est ouverte (IE029). Tout événement survenant pendant le trajet (par ex. transbordement) doit être signalé au moyen de l’avis IE182 au déclarant dans le régime du transit, soit au titulaire du régime. Si le bureau de destination constate des discordances dans les résultats de ses contrôles, le titulaire du régime en est informé par l’avis IE019. Tant que l’incohérence n’est pas tirée au clair, les garanties fournies ne seront pas restituées. Si tout s’est passé normalement, l’avis IE045 confirme que la procédure est terminée.

11

Le schéma ci-dessous figure tout le processus de déclaration des marchandises selon le processus de base.

3.1.3.2.2 Complément à la déclaration des marchandises Il est possible de corriger ou compléter à volonté la déclaration des marchandises jusqu’au moment de son activation. Si la correction n’est plus acceptée, l’avis NC909 le signale. Un avis IE004 doit suivre pour confirmer l’acceptation de la déclaration.

12

3.1.3.2.3 Annulation de la déclaration des marchandises Une déclaration de marchandises peut faire l’objet d’une demande d’annulation (IE014). L’OFDF peut accepter ou refuser une telle demande. Sa décision est communiquée au moyen de l’avis IE009.

L’avis IE009 signale si la demande d’annulation (décisions: 1=Yes, 0=No) a été approuvée ou refusée. La décision est à chaque fois du ressort de l’OFDF. Les cas suivants donnent lieu à un refus automatique. Ainsi, une annulation dans le système n’est plus possible si:

13

le titulaire du régime a été (IE060) informé d’un contrôle;

l’activation a été effectuée;

l’avis de libération a été donné pour le transit.

Si le code de libération a été attribué au transit, il n’est possible de formuler une demande d’annulation en dehors du système que dans les circonstances suivantes:

les mêmes marchandises ont été annoncées par erreur dans plusieurs déclarations transitaires.

Si l’OFDF accepte l’avis IE014 (demande d’annulation), le régime de transit est stoppé et abandonné. Plus aucune action n’est alors possible.


3.1.3.3 Transit avec clôture de procédure en Suisse


3.1.3.4 Procédure de recherche

3.1.3.5 Procédure de perception des redevances

3.1.3.6 Messages de statut

3.1.4 Processus d’exportation + transit

3.1.5 Processus de transit+ importation

3.2 Description des interfaces et règles de plausibilité

3.2.1 Aperçu

3.2.2 Informations de base Cette documentation décrit l’interaction entre l’OFDF et les clients professionnels (B2B) pour tous les messages liés au régime de transit commun (TC). Rien ne change pour le type de communication (passerelle B2B ou B2B light [téléchargement au format XML]), comme il s’agit toujours de la même chose du point de vue matériel.

Les processus standard se basent sur le mode de transport routier. Les différences avec d’autres modes de transport sont dûment signalées.

3.2.2.1 Définitions pour la mise en œuvre technique Règles

(Rxxxx)

Instruction indiquant (d’un point de vue fonctionnel et technique) comment compléter un groupe de données ou un élément de données, tout en limitant le contenu. Elle est prévisible et peut être testée.

Conditions

(Cxxxx)

Instruction indiquant (d’un point de vue fonctionnel et technique) si un groupe de données ou un élément de données est obligatoire, facultatif ou s’il n’est pas permis de l’utiliser. Une telle instruction indique seulement si les données doivent être complétées ou non, et ne porte pas sur le contenu proprement dit. Elle est prévisible et peut être exécutée et testée.

14

Règles techniques

(Txxxx)

Instruction supplémentaire relevant de la technique informatique, qui complète ou clarifie essentiellement les règles de fonctionnement et les conditions.

Règles métier pour la transition (B1xxx et B2xxx)

Business Rule for Transition (BRT).

Les BRT veillent à ce que certaines règles et conditions s’appliquent non pas pendant la phase transitoire (de NCTS-P4 à NCTS-P5), mais seulement après (B1xxx). En outre, elles définissent la structure finale après la phase transitoire (B2xxx).

ꞏ Une règle dite BRT-1 (B1xxx) impose la validation de règles et conditions avant la fin de la phase transitoire (TP) et s’applique à tout mouvement effectué pendant la phase transitoire. Cette BRT-1 ne s’applique que si la «date décisive» (decisive date) tombe avant ou en même temps que la fin de la phase transitoire.

ꞏ Une règle dite BRT-2 reprend quelques exigences en matière de données du UCC et définit la structure finale d’un mouvement accepté pour après la fin de la phase transitoire. Cette BRT-2 s’applique si la «date décisive» se situe après la phase transitoire.

Règle séquentielle

(Sxxxx)

Définit l’ordre des conditions, des règles techniques pour la transmission, des règles techniques et des règles, si elles s’écartent de l’ordre standard.

Ordre standard: format de validation (XSD), listes de codes, BRT / TRT, conditions, règles, règles techniques

Directives

(Gxxxx)

Instruction (guideline) sur la manière de compléter les groupes de données ou champs de données. Les directives ne sont pas prévues pour des tests automatiques.

Règles techniques pour la transmission

(Exxxx)

Technical Rule for Transition (TRT).

Limitation imposant aux messages une structure plus stricte avant la fin de la TP (phase transitoire). Elle vise à garantir pendant la phase transitoire la compatibilité des données avec les systèmes NCTS-P4 et NCTS-P5.

La longueur du champ de certains éléments de données augmentera lors de la phase 5 (par ex. l’adresse comportera désormais 70 signes au lieu de 35, ou les champs de texte libre 512 au lieu de 240). Comme les anciens systèmes ne peuvent pas traiter un nombre plus élevé de chiffres, un convertisseur écarte les signes excédentaires. Il existe toutefois certains champs où cette solution aboutit à des erreurs, raison pour laquelle les règles TRT ne déploieront toutes les fonctions proposées que dans la phase 5.

3.2.2.2 Modèle de données pour les nouvelles à caractère technique L’ancien modèle de données de la phase 4 comportait deux groupes de données, soit les données de tête (relatives au transport) et les données de position (sur les marchandises). La phase 5 introduit un nouveau modèle de données s’articulant en cinq groupes, selon le schéma ci-après de la Direction générale de la fiscalité et de l’Union douanière (TAXUD).

15

16

3.2.2.3 Spécification détaillée de la validation

3.2.2.3.1 Champ de données (Data Item) Chaque champ de données se voit attribuer un type – données numériques, alphanumériques, décimales, heure, date, heure/date. La valeur est prédéfinie dans quelques cas. De telles exigences seront définies dans la liste de codes (CL). Les champs sont indépendants de la langue, car ils possèdent un codage UTF-8.

3.2.2.3.2 Groupes de données (Data Group) Les groupes de données renferment divers champs de données ou d’autres groupes. Les noms des groupes ne sont pas uniques et peuvent très bien apparaître dans différents messages. Leur contenu peut varier d’un message à l’autre et n’a pas besoin d’être identique.

3.2.2.3.3 Description de la structure Les règles TRT & BRT sont structurées de façon à pouvoir expirer sans modification des applications douanières (CDU ou application nationale). Leur validité dépend de la date. La règle TRT obéit au principe suivant:

Il existe deux catégories de BRT:

Avant la phase transitoire: validation de règles & conditions

Après la phase transitoire: structure exacte des messages imposés

«Date décisive» (decisive date) pour BRT/TRT

Types Messages concernés (IE) «Date décisive» (Decisive Date) Conditions temporellesdu contrôle

TRT Applicable à tous les avis IE où apparaît 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

Applicable à tous les avis IE où apparaît BRT-1, sauf: IE015

Declaration acceptance date

(declarationAcceptanceDate)

BRT-2

IE015 Reception date of IE by NCA


Decisive Date >

end date of TP

Applicable à tous les avis IE où apparaît BRT-2, sauf: IE015

Declaration acceptance date

(declarationAcceptanceDate)

La structure technique des données offre deux types de vue, soit la description du message et sa structure complète. La description signale l’ordre, la hiérarchie, les répétitions maximales, les règles et conditions, et s’il est obligatoire d’indiquer le groupe de données. Les possibilités suivantes sont prévues à cet effet:

17

Le groupe de données

o doit toujours être indiqué (R = required)

o est facultatif (O = optional). Si des données sont disponibles, il convient de les indiquer par souci d’exhaustivité.

o peut être l’un ou l’autre (D = dependent), en fonction des conditions.

Le groupe de données de classe supérieure sera indiqué chaque fois qu’un groupe de données de classe inférieure est complété.

La structure complète (partie 2 de la structure des messages) présente un par un les champs de données. Elle indique l’ordre, les règles & conditions, et s’il s’agit ou non d’un champ obligatoire. Le caractère obligatoire sera signalé comme pour le groupe de données.

3.2.2.3.4 Définition de règle T, TRT, BRT ou d’une condition Les règles T, TRT, BRT doivent être validées par l’expéditeur et le destinataire. La description doit l’indiquer directement à chaque fois.

Les groupes ou champs de données ayant la propriété D passent à l’état R, O ou N (ne s’applique pas). Si aucune de ces valeurs ne convient, il n’est pas permis d’utiliser la valeur «zéro», des espaces ou des champs vides. Le cas échéant, il faut entièrement supprimer le groupe de données ou le champ de données du message XML.

Les pointeurs suivants s’utilisent:

<Full path> pour les groupes / champs

o <MESSAGE-HEADER.Declaration type >

<Context specific> pour les groupes / champs à l’intérieur des avis IE à valider

o <Applied Element>

xPath

o /*/Consignment/HouseConsignment/ConsignmentItem/Commodity/descriptionOfGoods

3.2.2.3.5 Traitement des règles T, TRT, BRT ou des conditions L’ordre de validation des messages suit le schéma suivant:

Format de validation (XSD)

Listes de codes

BRT / TRT

Conditions

Règles

Règles techniques

Il arrive que cet ordre soit spécifié. La règle séquentielle s’utilise à cet effet (S).

3.2.2.4 Jeux de caractères et exigences pour les champs de données Le schéma de codage par défaut des messages XML est UTF-8.

18

3.2.2.4.1 Indication de longueur, par type L’indication de longueur par type peut inclure deux points (..). Cela signifie qu’une flexibilité est offerte, à concurrence du nombre maximum de signes autorisé. La présence d’un point dans l’indication de longueur signale (le cas échéant) le nombre de signes autorisés après le point en question. Cette indication s’ajoute parfois à un nombre flexible (présence des 2 points) et au maximum de signes autorisés. L’aperçu ci-après illustre ces divers cas de figure.

a1 1 lettre, longueur fixe

n2 2 chiffres, longueur fixe

an3 3 caractères alphanumériques, longueur fixe

a..4 jusqu’à 4 lettres

n..5 jusqu’à 5 chiffres

an..6 jusqu’à 6 caractères alphanumériques

n..7.2 jusqu’à 7 chiffres au total, dont 2 au maximum après le point

3.2.2.4.2 Champs numériques Les champs constituent des nombres entiers positifs, le cas échéant des nombres décimaux positifs, sauf spécification contraire figurant dans les listes de codes ou dans une règle. Le point (.) est obligatoire pour les nombres décimaux. Aucun autre signe n’est autorisé. Les nombres entiers ne peuvent pas être précédés du chiffre zéro (0).

Les nombres décimaux ne seront utilisés que si une telle précision est nécessaire. Le cas échéant, il faut indiquer au moins un chiffre avant et après le point.

Exemples pour l’indication «n..11.3»:

123 valable

123456789.123 non valable – trop de chiffres avant le point et au total

123456789.1234 non valable – trop de chiffres après le point et au total

0123 non valable – le zéro initial n’est pas autorisé

+123 non valable – le signe plus n’est pas autorisé

-123 non valable – le signe moins n’est pas autorisé

1,234 non valable – la virgule n’est pas autorisée

.3 non valable – aucun signe avant le point

12345. non valable – aucun signe après le point

3 valable

3E1 non valable – seuls les chiffres et le point décimal sont autorisés

12345678.901 valable – au maximum 11 chiffres, dont 3 après le point sont admis

19

3.2.2.4.3 Champs de texte Les espaces vides ne sont pas tolérés au début ou à la fin. Les sauts de ligne (tabulateur) sont à éviter. Le format XML ne tolère pas certains signes, qui peuvent provoquer des erreurs. Il convient de les réécrire selon le tableau ci-dessous:

Signes Entités Remarques

& & conversion obligatoire

> > conversion indiquée

< < conversion obligatoire

" " conversion indiquée

' ' conversion indiquée

Remarque: & compte non pas comme cinq chiffres mais comme un seul. Il en va de même pour les autres signes.

3.2.2.4.4 Date & et champs temporels L’heure UTC s’emploie pour les champs DateTime et Time. La date sera indiquée par analogie à l’heure UTC, comme l’illustre l’exemple suivant.

Heure en Suisse: 8 mars 2020 7:48 (UTC+1)

L’heure suivante doit être communiquée: 8 mars 2020 6:48 (UTC)

Types de champ Regular Expression

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}

Le séparateur «T» signale qu’une autre indication temporelle suit encore la date. Les secondes entières constituent la plus petite unité autorisée.

Exemple de limitation XSD pour les données de type temporel (Time):

20

3.2.2.5 Messages et codes d’erreur

3.2.2.5.1 Messages d’erreur

3.2.2.5.2 Codes d’erreur

3.2.2.6 Messages XML Le schéma de codage des messages XML est UTF-8.

3.2.2.6.1 Convention d’appellation des balises La convention d’appellation suivante s’applique aux balises XML.

Éléments de données

XSD Conventions d’appellation

Exemples

Éléments de données

Balises XML

Champ de données

(Data Item)

Simple (simple)

S’il s’agit d’un acronyme tout sera en majuscules, sinon notation camelCase

MRN MRN

Declaration date declarationDate

Presentation notification rejection date

presentationNotificationRejectionDate

Groupe de données

(Data Group)

Complexe (complex)

S’il s’agit d’un acronyme tout sera en majuscules, sinon notation camelCase

GNSS GNSS

GOODS SHIPMENT

GoodsShipment

TRANSPORT EQUIPMENT

TransportEquipment

ADDITIONAL SUPPLY CHAIN ACTOR

AdditionalSupplyChainActor

3.2.2.6.2 En tête (message header) Les chapitres suivants définissent la manière d’indiquer la partie message des communications.

3.2.2.6.2.1 Expéditeur et destinataire du message Pour l’expéditeur des messages, il convient d’indiquer l’ID partenaire (n10). La valeur «PASSAR.CH» sera indiquée pour le destinataire. Si les messages proviennent de l’OFDF, le destinataire sera l’ID partenaire, et l’expéditeur PASSAR.CH.

3.2.2.6.2.2 Type de message Le type est défini selon le schéma: CC<numéro IE du message>C. Soit par exemple CC015C ou CC013C

3.2.2.6.2.3 Message Timestamp Indication conforme au chapitre Champ de texte. Le temps UTC s’emploie ici.

3.2.2.6.2.4 Message Identification Chaque message reçoit un identifiant attribué par hasard. Cela vaut également pour les messages envoyés deux fois. Si l’OFDF est déjà en possession du même identifiant, le

21

nouveau message sera refusé. Il convient en outre d’utiliser les identifiants uniques universels (UUID) dans la version 4.

3.2.2.6.2.5 Correlation Identifier Si la communication est un message d’erreur ou un accusé de réception, il convient d’inscrire l’identifiant du message d’origine dans le champ Correlation Identifier, afin d’en garantir l’attribution univoque.

3.2.2.6.3 Principes XSD

3.2.2.6.3.1 Conventions XSD On peut distinguer deux grands groupes de schémas XSD, selon qu’ils sont partagés ou spécifiques. Les schémas XSD partagés renferment les définitions de types simples (champs de données) ou complexes (groupes de données) récurrents dans plusieurs messages. Les schémas spécifiques donnent la définition structurelle d’un seul message. Les messages spécifiques se référeront toutefois aux messages partagés pour pouvoir être utilisés.

3.2.2.6.3.2 Structure des données XSD La figure ci-après illustre les interdépendances entre les divers schémas, qui seront expliquées en détail plus loin.

Simple Types XSD (stypes.xsd) – champs de données: contient la définition du type, le format et la définition du modèle.

Common Complex Types XSD (ctypes.xsd) – groupes de données: contient la définition des groupes de données. Les groupes de données présents dans plusieurs messages font l’objet d’une seule définition. Dans les deux cas, des informations sont données sur les champs de « données contenus », les champs « obligatoires », les « répétitions maximales autorisées », les « règles & conditions » et les « listes de codes ».

Header types (htypes.xsd): contient les définitions des champs et groupes de données pour l’élément technique générique, et réapparaît dans tous les messages.

Message_specifix XSD (CCxxxV.xsd) – Structure du message individuel: les champs et groupes de données sont définis, avec le type. Les champs obligatoires et les répétitions maximales autorisées sont également précisés.

Technical Codelist XSD (tcl.xsd): indique le type de champ de données, avec une liste des valeurs possibles.

L’élément XML <include> sert à relier les schémas entre eux.

La documentation (doc.xsd) est indiquée ici par souci d’exhaustivité. Elle inclura la définition des modèles servant aux éléments de la documentation (règles, conditions, listes de codes et descriptions), qui à leur tour seront déclarés dans les schémas XSD spécifiques à un message ou génériques. Le fichier n’a qu’une simple fonction de documentation, et ses éléments ne sont pas utilisables à des fins de validation de listes de codes, de règles ou de conditions.

(voir annexes:)

hytypes.xsd

stypes.xsd

tcl.xsd

ctypes.xsd

doc.xsd

22

3.2.3 Spécifications techniques du transit Les sous-chapitres suivants présentent les structures de tous les messages nécessaires selon les diagrammes de processus.

Il ne s’agit toutefois pas encore d’une version définitive. Un processus d’adaptation dynamique est prévu pour de tels messages.

3.2.3.1 Aperçu de tous les messages L’aperçu qui suit indique les messages à réaliser. La structure correspondante est présentée au chapitre suivant.

Messages internationaux

Noms Sens de la communication

Business Use Case Descriptions sommaires

IE004 OFDF: expéditeur Complément à la déclaration Le complément est accepté.

IE009 OFDF: expéditeur Annulation de la déclaration Confirmation de l’annulation

IE013 OFDF: destinataire Complément à la déclaration Compléter la déclaration existante avec une autre marchandise

IE014 OFDF: destinataire Annulation de la déclaration Annuler la déclaration de marchandises

IE015 OFDF: destinataire Déclaration de marchandises La déclaration de marchandises est envoyée.

IE019 OFDF: expéditeur Déclaration de marchandises Information selon laquelle les résultats du contrôle ont révélé des incohérences

IE028 OFDF: expéditeur Déclaration de marchandises Accusé de réception de la marchandise

IE029 OFDF: expéditeur Déclaration de marchandises Information selon laquelle l’avis de libération du transit a été donné

IE045 OFDF: expéditeur Déclaration de marchandises, procédure de recherche et de perception des redevances

La procédure de transit a été normalement clôturée/est terminée

IE051 OFDF: expéditeur Déclaration de marchandises Information sur l’absence de placement sous le régime du transit

IE060 OFDF: expéditeur Déclaration de marchandises Information selon laquelle un contrôle sera effectué

IE140 OFDF: expéditeur Procédure de recherche Demande d’informations sur la procédure de transit

IE141 OFDF: destinataire Procédure de recherche Réponse à la demande d’informations sur la procédure de transit

23

Noms Sens de la communication

Business Use Case Descriptions sommaires

IE182 OFDF: expéditeur Déclaration de marchandises Information concernant la survenance d’un événement pendant le trajet.

Messages nationaux

3.2.3.2 Ce chapitre expose les structures techniques, en renvoyant aux règles et conditions de chaque message. Il convient de distinguer ici entre les messages adressés à l’OFDF ou émanant de lui. Par souci de simplification, les messages émanant de l’OFDF ne comporteront pas de règles et conditions. Ces dernières doivent toutefois apparaître dans les messages adressés à l’OFDF, dont l’expéditeur doit toujours pouvoir effectuer un contrôle.

Remarque: dans la première version/publication, les données ne seront mises à disposition qu’au format Excel.

Légende

Orange: en cours d’examen – le champ/groupe doit toujours figurer en XML – les vérifications concernent les règles/conditions et le contenu.

Rouge: ne s’applique pas à la Suisse – le champ / groupe doit néanmoins être disponible dans XML, mais peut rester vide ou alors il ne faut pas appliquer de règle ou condition.

3.2.3.2.1 Annexe

IE-Meldungen-V1.0.xlsx

IE-XSD-Schema-V1.0.zip

3.2.3.2.2 IE004 voir Excel "IE-Meldungen-V1.0" & ZIP "IE-XSD-Schema-V1.0"








3.2.3.2.10 IE035 suivra

24







3.2.3.2.17 NC909 suivra

3.2.3.3 Règles et conditions Les messages adressés à l’OFDF doivent être vérifiés selon les règles et conditions leur étant attribuées. Par souci d’exhaustivité, elles contiendront toutes les règles et conditions des messages IE015, IE013, IE014 & IE141. Les règles/conditions à prendre spécialement en compte en Suisse seront signalées en couleur. Il convient de procéder de manière analogue dans les messages proprement dits.

Orange: en cours d’examen

Rouge: ne s’applique pas en Suisse – ne pas réaliser

Annexe: règles et conditions -V1.0.xlsx

25

3.2.4 Spécifications techniques de l’exportation

3.2.5 Spécifications techniques de l’importation

3.2.6 Spécifications techniques de l’exportation + transit

3.2.7 Spécifications techniques du transit + exportation

3.2.8 Spécifications techniques de la déclaration de transport

3.3 Mise en œuvre technique de l’activation

3.3.1 Route

3.3.2 Rail

3.3.3 Trafic aérien

3.3.4 Bateau

3.4 Tests

3.5 Production de documents (inputmanagement)

3.6 Émission de documents (outputmanagement)

26

4 Concept d’introduction de Passar

4.1 Environnements système et tests

4.2 Organisation des structures et processus

4.3 Phase d’introduction et exploitation parallèle

4.3.1 Spectre de l’offre, par canal À quelques exceptions près, tous les canaux proposent les mêmes fonctions:

Canaux Genres de trafic

Procédures douanière B2B UI App Cockpit de transport

Route Rail Bateau Trafic aérien

Importation x x x x x x x

Exportation x x x x x x x

CCM x x x

Transit x x x x x x x

Perfectionnement (actif et passif) x x x x

Admission temporaire x x x x

Entrepôt douanier x x x

Transport professionnel de marchandises agricoles

x x

Periodic x

Production de documents x x x x x x

Émission de documents x x x x x x

Dédouanement du véhicule x x x x x x

Données de transport x x x x

4.3.2 Exploitation en parallèle dans l’exportation

4.3.3 Exploitation en parallèle dans le transit

4.3.4 Exploitation en parallèle dans l’importation

4.4 Calendrier

27

5 FAQ

28

6 Terminologie / Glossaire

Notions Définitions

AAR ANTICIPATED ARRIVAL RECORD

Activation

API

APP

Application mobile

ATR ANTICIPATED TRANSIT RECORD

AXR ANTICIPATED EXIT RECORD

B2B API

B2B light

Borderticket

Cockpit de transport

Contrôle de la plausibilité

Décision

Destination des marchandises

DocBox

ePortal

Gestion des flux documentaires

Interface utilisateur (UI)

Interlocuteur

Intervention

Modèle Phase 5 TAXUD

MRN

Notification

OFDF

Passar

Pointeurs

Responsable des données

Responsable des marchandises

Responsable du transport

TC Régime de transit commun

Télématique

29

Notions Définitions

TP

UI Déclaration de marchandises OFDF

Validation sémantique

Validation syntaxique

30

7 Table des abréviations

Acronymes Significations Traductions françaises (si nécessaire)

Remarques additionnelles

B2B Business to Business Relation commerciale entre deux entreprises / administrations échangeant des données sous forme électronique

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

Application douanière nationale

OFDF Office fédéral de la douane et de la sécurité des frontières

Partenaire Partenaire commercial

RPLF Redevance forfaitaire sur le trafic des poids lourds

RPLP Redevance sur le trafic des poids lourds liée aux prestations

UCC Union Customs Code Code douanier de l’Union

Règles et procédures de l’Union douanière