Gestion Electronique et Sécurisation du Fret International ... · schema global du projet delta Le système DELTA ( Dédouannement en Ligne par Transactions Automatisées) est constitué

1

Guide d’implémentation technique LIV2MS3GIT_ADM_1

et Guide méthodologique LIV2MS3GM

Date du fichier 10 Mars 2008

Nom du fichier LIV2MS3_ADM_1_GESFIM_Guid-Impl_V4.doc

Version du Fichier V4

Nom du responsable VANKEMMEL

Liste de distribution :

Direction Générale des Entreprises

Partenaires Soutien Technique

Mme Sonia GENINI Mme Anne SANDRETTO (TLF) M. Marc MOREAU M. Vincent GROULT (TLF)

M. Arnaud MARTIN (ELIT) M. Bernard PLAINFOSSE M. Olivier VERHAEGHE (CRCI)

M. Jean-Marc DUFOUR (EDIFRANCE)

Historique des versions :

Nom Responsable Partenaire N° Version Date

VANKEMMEL AD’MISSIONS 1 10 Mars 2008

Gestion Electronique et Sécurisation du Fret

International Multimodal

2

Guide d’implémentation

SOMMAIRE

1. Préambule : pourquoi un Guide Utilisateur - Obje ctif recherché

2. Suivi des modifications 3. Vue d’ensemble du système DELTA des Douanes et d e son architecture 4. Généralités sur les flux d’échanges et la constr uction des messages

5. Messages XML échangés en amont entre Opérateurs Economiques et

GESFIM des projets A, B et C a. Interface système douanier DELTA Chain b. Autres flux Transport/Logistique

6. Formulaires de gestion du Transport (GESFIM B) 7. Tables de correspondance entre les données DELTA et les données/

codes normalisés (Core Components UN/CEFACT, UNeDoc s) 8. Listes de codes 9. Références Normatives

3

1. Préambule : pourquoi un Guide Utilisateur – Obje ctif recherché Ce guide d'utilisation concrète du système GESFIM n'est pas un ouvrage de vulgarisation. Ses rédacteurs se sont efforcés de le rendre accessible à diverses catégories de lecteurs, ils l'ont fait dans l'hypothèse que ces lecteurs disposaient d'un minimum de connaissance, tant des procédures douanières et opérationnelles du transport de fret et de la logistique liées au Commerce International, que des échanges électroniques d’information y afférents utilisant différents moyens (EDI, XML, Standards….). Ce guide doit aider concrètement les entreprises et utilisateurs à s’approprier les concepts et les méthodes de mise en œuvre des interfaces applicatives normalisées permettant d’intégrer et d’extraire les informations des messages échangés dans leurs propres systèmes. Ce guide fait référence au Référentiel général e-Business du projet GESFIM qui définit les processus et les flux d’informations échangés entre les différents partenaires d’une transaction internationale. S'il peut aider à la compréhension du processus de construction d'un message électronique transport/logistique/douane à partir de la documentation, il a plutôt l'ambition d'aider très concrètement à la mise en œuvre d’un système d’échanges basé sur les standards internationaux et de faciliter le dialogue entre les partenaires s'engageant dans des relations EDI. Dans ce contexte, ce guide a donc vocation à compléter un ensemble normatif qui peut paraître lourd et complexe (modèles de données ebXML de l’UN/CEFACT, modèles des scénarios d’échanges, messages XML….), afin d'éviter la prolifération dommageable de dispositions bilatérales entre les divers acteurs impliqués dans une transaction internationale (donneurs d'ordres, commissionnaires de transport, douanes….) contraires au principe même de l'interopérabilité… L’objectif à atteindre doit être positionné dans un champ d'application qui aura été, préalablement, très précisément délimité. De fait, un ensemble de règles concrètes d'application des messages standards transport/logistique/douanes relativement génériques, ne peuvent être conçues qu'à partir d'un scénario concret défini dans le Référentiel e-Business de GESFIM. Il faut préciser que ces guides utilisateurs respectent les recommandations internationales du comité UN/CEFACT Transport TBG3 ITIGG - International Transport Implementation Guidelines Group ( http://www.smdg.org/itigg ) . Enfin, les utilisateurs de ce guide peuvent également, à l'aide du formulaire figurant en annexe à la fin de ce guide, exprimer des demandes d'information ou émettre des besoins de modification, à toutes fins utiles.

2. Suivi des modifications Chaque version du présent ouvrage est référencée selon une méthodologie stricte définie pour tous les documents et livrables du projet GESFIM que les partenaires sont tenus de respecter. Elle indique le nom sous un format structuré, la date, le numéro de version et l’historique des versions. Ces informations figurent en tête du Guide d’implémentation. Celui-ci a le statut de document de standardisation ouvert mis à disposition de la Direction Générale des Entreprises et des Utilisateurs dans le cadre du programme d’action TIC PME

4

2010. Il pourra faire l’objet de mises à jour ultérieures en fonction de l’évolution des standards.

3. Vue d’ensemble du système DELTA des Douanes et d e son architecture Ce chapitre brosse un panorama du nouveau système douanier DELTA, son architecture générale, ses modes d’accès sécurisés et ses principales fonctionalités et les flux d’échanges correspondant. Pour plus de détails, on pourra se référer au portail PRODOU@NE https://pro.douane.gouv.fr/ qui contient les spécifications techniques, ainsi qu’au Référentiel e-Business de GESFIM qui a été produit en phase 1 du projet GESFIM.

SCHEMA GLOBAL DU PROJET DELTA

Le système DELTA ( Dédouannement en Ligne par Transactions Automatisées) est constitué d'un ensemble de sous systèmes qui couvrent les différentes procédures douanières. Il remplace soit des procédures dites 'papier' (PDD, Manifestes), soit des procédures informatisées (SOFI, NSTI). L'objectif est pour la Douane d'avoir un meilleur contrôle des flux de marchandises conformément aux directives européennes.

5

Le CID (Centre Informatique Douanier) est le système central avec lequel les opérateurs économiques doivent dialoguer. Le réseau PASTEUR est le nom donné à la liaison spécialisée établie avec la douane via un prestataire désigné par la douane (ATOS Origine jusqu'en automne 2006). MAREVA est un mode de communication par message SMTP utilisant le réseau PASTEUR. Chaque message est sécurisé par une signature à l'aide d'un certificat. A charge au destinataire de vérifier que le message a bien été envoyé par le propriétaire du certificat. DELTA-P correspond à la procédure de "Prise en charge" qui informatise les manifestes. Elle concerne les compagnies aériennes. Ces dernières doivent envoyer à la douane le contenu de chaque vol à l'arrivée sur le sol français. DELTA-D correspond à la procédure de "dédouanement à domicile" qui informatise les avis d'arrivée, les pré-avis de chargement, les avis de placement et les DCG. Elle concerne tous les détenteurs de procédure PDD qui sont surtout des chargeurs. Cependant, des commissionnaires peuvent avoir à gérer des PDD pour le compte de chargeurs. DELTA-C correspond à la procédure de "droit commun" qui remplace le SOFI. Elle concerne tous les commissionnaires. DELTA-X correspond à la procédure dite "express" qui remplace les manifestes et la DCG et qui remplace aussi les transferts EDI. Elle concerne les "expressistes". DELTA-T correspond à la procédure "Transit" qui remplace le transit sur NSTI. Elle concerne aussi bien les commissionnaires que les chargeurs. Le Workflow est constitué d'un ensemble de services qui scrute les fichiers qui sont à transmettre à la douane et les fichiers en réception de la douane. Il alimente la table des événements, met en place les alertes, envoi les mails d'informations ou les mails d'alerte. Le WebService est l'interface SOAP publiée sur internet qui permet à des utilisateurs de se connecter au service et d'utiliser toutes les librairies nécessaires à l'application cliente. La base de données BDD Oracle est constituée de plusieurs bases de données Oracle contenant l'ensemble des informations du client (historiques, événements, alertes, liste des utilisateurs) et aussi l'ensemble des tables de références imposées par la douane (listes des bureaux européens, liste des pays, …). Le BackOffice HelpDesk est constitué d'une interface utilisateur qui permet de créer des incidents directement dans la base de données BDD de la maintenance du système Il permet aussi de suivre les incidents. Le BackOffice Software est constitué d'une interface utilisateur qui permet de mettre à jour facilement la version de la partie cliente des logiciels. Il comporte aussi une boîte à idée que les utilisateurs sont invités à alimenter. Il comporte aussi un système de messagerie qui permet d'afficher des fenêtres d'information sur l'application client. Le Référentiel Op.Eco comprend l'ensemble des Opérateurs Economiques stockés société/agence. Il peut s'agir de clients, fournisseurs, déclarants. Le Référentiel Douane comprend l'ensemble des données de base servant à la saisie et au contrôle des déclarations. Il contient par exemple la liste des bureaux de douane européens, la liste des incoterms, des listes des pays, … Il contient en fait l'ensemble des codifications

6

imposées par le Code de Douane Communautaire. Ce référentiel de données fait l’objet d’une table de correspondance avec les données / codes des normes UN/CEFACT. Le Référentiel TARIC / RITA est un module qui permet de consulter le TARIC via une application de type Nomenclature Douanière. Il sera mis à jour quotidiennement lorsque le téléchargement de RITA sera actif. Il contient l'ensemble des codifications des marchandises, l'ensemble des règles d'importation et d'exportation avec les droits et taxes associés. Le service Archivage permet de stocker les messages originaux envoyés par le déclarant ainsi que les réponses reçues de la douane accompagnées de leur signature. Le service Suivis des crédits permet de gérer par dossier vos crédits douaniers (Crédit d'enlèvement, crédit d'opérations diverses, Suivis des AI2). Le service Suivis des D48 permet de gérer par dossier l'ensemble des soumissions D48 et d'alerter lorsque le délai s'approche ou est dépassé. Le service Calcul Tarifaire permet de calculer la liquidation d'une marchandise en fonction de la réglementation contenue dans le TARIC. La Gestion PDD comprend une saisie de dossier d'expédition ou de réception ainsi qu'une interface permettant la récupération automatique ou manuelle des informations issues d'un système informatique de chargeur. Elle comprend l'ensemble des éditions d'états réglementaires (avis, préavis, comptabilités matières, DCG). Elle permet de gérer tout ce qui a trait à la Procédure de Dédouanement à Domicile. Elle alimente le module DELTA-D et récupère les informations fournies par la douane en retour.

MODE DE COMMUNICATION AVEC LE CENTRE INFORMATQUE DO UANIER

Le mode de transmission est par mail sécurisé avec des fichiers de type XML réalisé avec une plate-forme d'envoi et de réception de message via MAREVA et le réseau PASTEUR.

a. PASTEUR

La liaison PASTEUR sert à router les messages XML du DELTA-P via le système de messagerie MAREVA. En cas de secours, il utilise une liaison de backup.

7

8

b. La sécurité : MAREVA

Acronyme de Messagerie Applicative en REseau à Valeur Ajoutée.

MAREVA est le système de messagerie qui permet de poster des messages SMTP à la douane via la liaison PASTEUR. Les messages SMTP sont signés à l'aide de la clé privée de l'emetteur (certificat du prestataire ou certificat de la douane selon le sens). Ils sont vérifiés à destination avec la clé publique de l'émetteur. Le système en réception doit envoyer un accusé de réception. S'il n'envoie pas l'accusé, le système de la douane renvoie au maximum 3 fois le message à 1/2 heure d'intervalle. Passé ce délai, la douane envoi un message de blocage. Pour reprendre la communication, il faut envoyer un message de déblocage. Tous les messages qui n'ont pas fait l'objet d'un accusé de réception seront alors renvoyés suite au déblocage. Un accusé de réception MAREVA peut être négatif en cas d'erreur ou positif si tout va bien. S'il est positif, cela signifie que le message sera transmis au module DELTA concerné afin que celui-ci réponde par un ou plusieurs messages fonctionnels.

9

MODE DE COMMUNICATION AVEC LES OPERATEURS ECONOMIQU ES

La liaison INTERNET

La liaison privilégiée est de type IP de préférence à haut débit (ADSL) pour utiliser confortablement les modules de la gamme DELTA. Il peut être envisagé par mesure de sécurité, une liaison spécialisée de type VPN pour les utilisateurs qui le souhaitent. Les frais de la liaison, des routeurs et de cartes réseaux supplémentaires étant à la charge du client.

Le mode de transmission

Les divers modules DELTA pourront utiliser une ou plusieurs des composantes suivantes : FTP, WebService SOAP 1.2 ou Mail

FTP : échanges de fichiers EDI

Ce moyen est intéressant lorsque le client possède en amont un système de gestion douanière performant et qu'il souhaite continuer à utiliser avec DELTA et GESFIM qui fournit la passerelle de communication. Pour les retours, le mode 'PULL' est utilisé, c'est à dire que les fichiers sont mis à disposition dans un autre répertoire avec le même login FTP que l’utilisateur peut venir rechercher à sa convenance. Cependant, il est possible de faire du mode 'PUSH' pour les retours FTP.

WEB SERVICES

Deux types de WEB SERVICES sont possibles.

Les WEB Services "métiers" : Ils correspondent aux WEB SERVICES utilisés par la partie cliente des modules DELTA.

Les WEB Services "connecteurs" :

Ils correspondent aux WEB Services permettant le transfert de fichiers et sont une alternative à la communication FTP. Pour les réponses, il est à remarquer que le mode 'PUSH' n'est pas possible car il obligerait le client à créer son propre serveur de WEB Services.

Les mails

Les systèmes de WorkFlow du système utilisent les messages mails pour : • Avertir du changement de statut d'une déclaration ; • Envoyer un document officiel ; • Informer d'un message officiel de la douane ; • Alerter lorsqu'un délai arrive à expiration. Le Back Office Software utilise les messages mails pour : • Diffuser les alertes ou bulletins officiels de la douane ; • Diffuser les alertes officieuses sur l'état d'un service ;

.

10

4. Généralités sur les flux d’échanges et la constr uction des messages Ce chapitre fait un bref rappel des schémas de flux décrits dans le Référentiel e-Business produit sous la référence LIV1MS3RB_ADM_1_V3, ceci afin de positionner le guide de mise en œuvre dans le contexte général.

a. Cinématique des échanges entre le système DELTA et les Opérateurs Economiques

Schéma simplifié

11

Diagramme d’activités déclaration en Douanes DELTA

Le diagramme d’activités représente l’enchaînement des différentes opérations administratives et réglementaires d’une transaction internationale d’Import / Export décomposées en processus et décrit les flux d’informations entre ces activités au sein d’un même système. En d’autres termes, ceci permet de représenter le déroulement d’une procédure ou d’une fonction. Ce modèle inclut les activités et les flux d’information échangés entre d’une part les Opérateurs Economiques : commissionnaires de transport, transitaires, agents de fret, transporteurs de tous modes et d’autre part l’Administration des Douanes.

12 Flux

13

b. Diagrammes d’Activités des fonctions et flux Tra nsport/Logistique

Le diagramme d’activités représente l’enchaînement des différentes opérations d’une chaîne Transport/Logistique décomposées en processus et décrit les flux d’informations entre ces activités au sein d’un même système. Ce modèle inclut les fonctions des commissionnaires, des transporteurs de tous modes et des Douanes. Il est décomposé en quatre grands processus :

1. réservation de transport, d’espace à bord d’un moyen de transport (exemple avion cargo, emplacement de conteneurs à bord d’un navire)

2. commande et instructions de transport pour l’acheminement du fret 3. déroulement du transport jusqu’à la livraison des marchandises au destinataire final 4. remontée d’information (rapports de statut transport...)

auxquels peuvent s’ajouter des opérations de groupage et dégroupage du fret, procédures de dédouanement / transit et application des règlements et directives relatives à la sûreté du fret. Projet A

14

Réservation de transport

15

Instructions de Transport

16

Déroulement du transport

17

Statut de transport (remontée d’informations)

Projet C : Traçabilité Produits

18

Commande Client –Mise en production

Donneur d’ordres Commercial Achat-Stock Production Livraison Après vente Prestataire etFournisseurs

Administrations

Commandede

Produits

Réception de la Commandede Produits

Stockdisponible?Délais de

Réalisation de Commande

Délais deRéalisation des Produits

Confirmation de

Commande

DélaiAcceptable?

Enregistrement de Commande

oui non

oui

non

Matières etComposantsdisponibles?

AcceptabilitéCommandede Produits

CommandeMatières oucomposants

non

oui

Étapes defabrication

En cours defabrication

Stock deMatières et

composants

Contrôlesqualité

Qualitésuffisante?

oui non RecyclageDes

produits

Entrée en stock

PlanningDe

Livraison

PréparationDes lotsÀ livrerStock

disponible?

oui

non3

4

1

3

19

Livrison – facturation – garantie

Donneur d’ordres Commercial Achat-Stock Production Livraison Après vente Prestataire etFournisseurs

Administrations

Préavis de

Livraison

Réception de des Produits

Garantievalide?

Ordrede

Transport

oui

non

ProduitsÀ remplacer

?

ouinon

0

4

Commande de

Transport

PréparationDes lotsÀ livrer

Planningexpédition

ConfirmationDe

livraison Facturation

FormalitésContrôles


Défauts ou anomalies

des Produits

InterventionMaintenance

3

5

5

Demande d’informations sur les Produits

FournitureD’informations

traçabilité


traçabilité

5Demande

d’élimination des Produits


traçabilité Élimination


20

Généralité sur les messages

ENVELOPPES DES MESSAGES : DIAGRAMMES GENERAUX

ENVELOPPE CONNEXION

Dans la balise EnveloppeConnexion de tous les messages, la balise applicationId est renseignée

21

ENVELOPPE MESSAGE

La balise EnveloppeMessage de tous les messages est renseignée au maximum pour préparer les futurs double-signatures.

• schemaID : Nom du message. Exemple : MessageCDecImp, MessageCDecExp, MessageCOD

• schemaVersion : constante pré-définie • partyId : N° SIRET de l’agence • transactionId : N° unique par déclaration (unicité pour applicationId et partyId) • numseq : doit commencer à zéro puis une série continue sans « trou » dans le

séquencement des messages pour une transactionId.

PRESTATAIRE

La balise Prestataire dans MessageOperateur sert à alimenter des zones : • UserID contient l’identifiant unique de l’utilisateur • Modif si la déclaration a déjà fait l’objet d’un envoi à DELTA.

22

Schéma MessageCDecImp

Message utilisé pour envoyer les déclarations d’importation en DELTA-C.

GESTION DU CONTENU EN FONCTION DU CODE ACTION

Code action : Obligatoire

Il indique l'état de la déclaration. Celle-ci peut être anticipée, jusqu'à 10 jours avant l'arrivée des marchandises validée. La validation correspond au dépôt électronique de la déclaration au bureau de dédouanement. 1 Création avec demande d'anticipation 2 Création avec demande de validation Déclaration complétée 3 Modification avec demande d'anticipation 4 Demande d’annulation 5 Demande de validation d’une déclaration anticipée 6 Demande de validation d’une déclaration en attente de validation 7 Demande d’invalidation 8 Demande de changement du mode de paiement Si le code action est à 1 ou 3, alors le code procédure 2ème subdivision est forcément égal à D pour l’application Delta-C. Si le code action est à 2 ou 5, alors le code procédure 2ème subdivision est forcément égal à A pour l’application Delta-C. Code action

Nœuds obligatoires Nœuds inutiles ou facultatifs

1 DatasDec.Entete DatasDec.Gen DatasDec.Articles

Liquidations


Liquidations


Liquidations

4 DatasDec.Entete

DatasDec.Gen DatasDec.Articles Liquidations

5 DatasDec.Entete Liquidations

DatasDec.Gen DatasDec.Articles

6 DatasDec.Entete Liquidations

DatasDec.Gen DatasDec.Articles

7 DatasDec.Entete DatasDec.Gen DatasDec.Articles Liquidations

8 DatasDec.Entete DatasDec.Gen DatasDec.Articles Liquidations

23

Schéma MessageCDecExp

24

Message utilisé pour envoyer les déclarations d’exportation en DELTA-C ainsi que la réponse des Douanes.

GESTION DU CONTENU EN FONCTION DU CODE ACTION

Identique à l’import.

25

Message d’erreur retournés par la plate-forme DELTA CHAIN / GESFIM

1.1. REPONSE AU CONTROLE FONCTIONNEL DES MESSAGES

<?xml version="1.0" encoding="iso-8859-1" ?> - <ReponseCtrl>

- <EnveloppeConnexion>

<connexionId />

<interchangeAgreementId />

<numEnveloppe>66</numEnveloppe>

- <DateTime>

<date>10/04/07</date>

<time>15:37:34</time>

</DateTime>

<applicationId>Delta-Dcertif</applicationId>

</EnveloppeConnexion>

- <Erreur>

<erreurCode>XSD0000</erreurCode>

<erreurDescription>XmlSchemaValidationException:L'élément 'MessageOperateur' a un

élément enfant non valide 'Messages'. Liste d'éléments possibles attendue : 'EnveloppeConnexion'.</erreurDescription>

<erreurXPath />

</Erreur>

- <Erreur>

<erreurCode>INT0253B</erreurCode>

<erreurDescription>Le mode de représentation saisi n est pas valide à la date de la

déclaration .</erreurDescription>

<erreurXPath>/MessageOperateur/Messages/Message[0]/Declaration/DSI/Gen/Operateur/modrep</erreurXPath>

</Erreur>

- <Erreur>

<erreurCode>INT1033B</erreurCode>

<erreurDescription>Le code nomenclature saisi n est pas valide à la date de la

déclaration</erreurDescription>

<erreurXPath>/MessageOperateur/Messages/Message[0]/Declaration/DSI/Articles/Article[0]/nomenc</erreurXPath>

</Erreur>

- <Erreur>

<erreurCode>COR1103B</erreurCode>

<erreurDescription>Le code pays d'origine saisi n'est plus valide à la date de la


<erreurXPath>/MessageOperateur/Messages/Message[0]/Declaration/DSI/Articles/Article[0]/ori</erreurXPath>

</Erreur>

- <Erreur>

<erreurCode>COR1113B</erreurCode>

<erreurDescription>Le code pays de provenance saisi n'est plus valide à la date de la


<erreurXPath>/MessageOperateur/Messages/Message[0]/Declaration/DSI/Articles/Article[0]/pro</erreurXPath>

</Erreur>

</ReponseCtrl>

1.2. MESSAGE DE REPONSE MAREVA SUR ERREUR DE STRUCTURE

<ReponseMAREVA>

26

<EnveloppeConnexion> <connexionId>38045116100034</connexionId> <interchangeAgreementId>00000002</interchangeAgreementId> <numEnveloppe>5871</numEnveloppe> <DateTime> <date>24/11/06</date> <time>14:29:56</time> </DateTime> <applicationId>Diagnostic</applicationId> </EnveloppeConnexion> <ReponseErreur> <erreurCode>ERR_PARSE_XSD</erreurCode> <erreurDescription>L'élément 'Entete' a un élément enfant non valide 'refdec'. Liste d'éléments possibles attendue : 'Motivation, refdos'.</erreurDescription> <numEnveloppe>DIMP-200611091648</numEnveloppe> </ReponseErreur> </ReponseMAREVA>

1.3. MESSAGE D’ALERTE MAREVA DE TIMEOUT

<ReponseMAREVA> <EnveloppeConnexion> <connexionId>38045116100034</connexionId> <interchangeAgreementId>00000002</interchangeAgreementId> <numEnveloppe>5869</numEnveloppe> <DateTime> <date>24/11/06</date> <time>14:21:52</time> </DateTime> <applicationId>Diagnostic</applicationId> </EnveloppeConnexion> <ReponseErreur> <erreurCode>TIMEOUT</erreurCode> <erreurDescription>Aucun événement soldeur reçu de Delta-Dcertif dans un délai de 99 minutes. Vous pouvez choisir de patienter ou de ré-émettre le message.</erreurDescription> <numEnveloppe>DIMP200611231700</numEnveloppe> </ReponseErreur> </ReponseMAREVA> Echanges douaniers relatifs au système ECS ( Export Contol System) Les scénarii d’échanges entre les bureaux de Douane et les Opérateurs économiques sont décrits dans le Référentiel eBusiness dont une version complétée (Rev 2) a été fournie. Les messages supportant les différents flux des scénarii sont explicités ci-après : - Echanges au bureau de sortie Les informations communiquées par le système douanier à l’opérateur sont fonctionnellement de trois types : 1. Messages d’erreur;

27

2. Communication d’informations en suite directe du traitement d’un message opérateur. 3. Notification d’état/événement ne suivant pas directement la réception d’un message opérateur ; Tout message opérateur fait l’objet d’un accusé de réception fonctionnel. Les messages opérateurs, échangés avec le système ECS bureau de sortie (hors détournements ou anomalies affectant les échanges) se déclinent en :

o La notification d’arrivée (IE507): Les marchandises pouvant ne pas être reçues dans un même temps, le système opérateur doit envoyer la notification d’arrivée (message IE507) une unique fois : quand toutes les marchandises associées à un mouvement identifié par un MRN (une déclaration) sont reçues. La transmission du message EDI est assurée par l’opérateur titulaire d’un agrément technique (prestataire ou opérateur dont la solution logicielle EDI est certifiée pour ECS) conformément aux principes généraux adoptés par l’administration. Le message IE507 de notification d’arrivée contient l’identifiant de l’opérateur, son agrément (au sens « autorisé à utiliser la procédure ECS »), le code du bureau de sortie et un lieu de stockage (lié à l’agrément dans la relation).Après réception de l’avis d’arrivée (IE507) et son enregistrement dans le système douanier, les marchandises peuvent ou non être contrôlées par la douane : cela correspond à l’étape « contrôles douaniers » de l’application ECS. Le système douanier renvoie au système opérateur un accusé de réception fonctionnel ou un message d’erreur ( message ReponseIE507). L’accusé de réception contient, outre le statut du mouvement, les données de l’IE501. Si le message est valide les états retournés sont : Retour d’un état ARRIVE DEST - Retour d’un état SOUS CONTROLE DEST - Retour d’un état STOCKE . Le système opérateur doit attendre la notification d’un état STOCKE pour effectuer la notification de sortie.

o La notification de sortie (IE618) : Le système douanier est en attente de l’avis de sortie définitif (message IE618). Le système opérateur émet le message de notification de sortie (IE618) quand toutes les opérations de sortie sont considérées comme terminées. Cette constatation de sortie peut être effectuée sans différence ou avec différences constatées. Dans le cas où des différences (sur les quantités ou poids des marchandises) sont constatées, ces différences sont mentionnées dans le message IE618. Le système ECS se comporte comme quand, en mode DTI, il a reçu de la part de l’opérateur une annonce de sortie définitive (état STOCKE avec demande de sortie).

Les messages opérateurs, dans les cas particuliers, sont traités de la manière suivante : si, lors du traitement de l’IE507, le système douanier détecte que le mouvement ECS n’est pas connu du système, il communique au système opérateur un accusé de réception avec l’état AER DEMANDE. Le système douanier communique une demande d’avis anticipé d’arrivée au bureau d’exportation. Deux cas sont alors envisageables :

o Il n’y a pas de réponse de la part du bureau d’exportation pour cause d’anomalie (rejet du message ou erreur de transmission par exemple) ou le mouvement est déjà sorti dans un autre bureau. Le système douanier renvoie alors l’un des états suivants :MRN INCONNU - MOUVEMENT SORTI AUTRE EM. Ces deux états sont des états finaux.

o ECS reçoit de la part du bureau d’exportation une réponse positive, c’est un détournement international. Le mouvement est enregistré dans le système douanier qui communique au système opérateur l’un des états suivants : SOUS CONTROLE DEST - STOCKE. L’état SOUS CONTROLE DEST est transitoire ; il est normalement suivi de l’état STOCKE.

28

Normalement le système opérateur EDI doit attendre la notification d’un état STOCKE pour entreprendre la phase de sortie. Pour les cas de figure où, après que la notification d’arrivée ait été enregistrée dans le système douanier, celui-ci reste en état AER DEMANDE il n’est alors pas possible de traiter automatiquement la notification de sortie. Cela se produit aussi avec les mouvements pour lesquels le système douanier communique un des états MRN INCONNU ou MOUVEMENT SORTI AUTRE EM ou en cas d’anomalie technique. D’une manière générale lorsque l’état STOCKE n’est jamais communiqué au système opérateur, le cas sera traité manuellement.

Les messages ECS élaborés pour l’application DELT@ sont listés ci-dessous. Leurs structures détaillées figurent dans le fichier des schémas xsd en annexe LIV2MS3GIT_ADM_4_ECS - Message IE 507 Le message IE507 est envoyé par l’opérateur en création seulement. Il ne comporte qu’un profil d’utilisation. Le code action possède la valeur 1 par défaut. - Message IE 618 Le message IE618 permet de véhiculer deux types d’information: il possède deux profils d’utilisation, caractérisés par le code action mentionné dans le message: Valeur du code action 1 : demande de sortie définitive sans constatation de différences Valeur du code action 2 : demande de sortie définitive avec constatation de différences Il existe au moins un article présent et l’article est valorisé avec les données constatées par l’opérateur - Message ReponseIE507 Ce message véhicule trois types d’information : erreur, notification d’état, notification d’état + données de l’IE501. - Message ReponseIE618 Ce message véhicule deux types d’information : erreur et notification d’état. - Message NotificationEtat Les états communiqués sont décrits dans les spécifications techniques détaillées des Douanes Construction des messages / schémas XML Les spécifications des processus et des informations échangées ont été définies dans les modèles conceptuels du projet, elles sont indépendantes des techniques et des syntaxes utilisées pour la mise en oeuvre.

La méthode proposée par l’UN/CEFACT pour créer des schémas XML interopérables s’appuie sur le standard NDR (Naming and Design Rule) élaboré par l’ATG (Applied Technologies Group) de l’UN/CEFACT qui peut être téléchargé à l’adresse suivante : http://webster.disa.org/cefact-groups/atg/downloads/XML%20Naming%20And%20Design%20Rules%20V2.0.pdf

La méthode XML NDR

29

La Spécification Technique NDR (XML Naming and Design Rule) de l’UN/CEFACT est une méthode de création de schémas et de documents XML interopérables. Ces schémas sont les dérivés en XML des composants indépendants de la syntaxe répertoriés dans les librairies de composants (CCL Core Components Library) de l’UN/CEFACT qui sont eux-mêmes développés conformément à la norme ISO 15000-5 CCTS. NDR propose un profil d’implémentation pour la Recommandation du W3C portant sur le langage de Définition des Schémas XML (XSD). Les règles garantissant que les composants conformes CCTS sont exprimés de manière cohérente en XML, indépendamment des contextes et des relations d’affaires, sont précisées. La spécification présente un ensemble de règles portant sur les extensions et les restrictions, la gestion des versions, la conception et l’exécution. Elle s’attache à garantir que les composants restent pleinement interopérables. Les déclinaisons en XML des composants CCTS doivent être utilisées pour représenter les structures de données internes, pour définir les flux de données internes et les échanges de données externes des messages métier. Elles doivent pouvoir être utilisées par tous les composants des infrastructures XML, comme par exemple les Web services. Production des schémas XML La génération des schémas XML à partir des composants élémentaires (Core Components) peut être faite aisément avec des outils logiciels appropriés tel que celui utilisé par les groupes de travail de l’UN/CEFACT. Cette méthode s’appuie sur la base de données UneDocs (United Nations electronic Documents) dans laquelle ont été définis des structures génériques pour les divers domaines d’activités de la chaîne Transport/Logistique internationale, dénommés BIM – Business Information Masters. Ceci est comparable au standard traditionnel EDIFACT pour lequel la communauté Transport avait défini une matrice cadre générique IFTM – International Forwarding and Transport Messages à partir de laquelle ont été dérivés des messages EDI aux fonctionnalités spécifiques.

5. Messages XML échangés en amont entre Opérateurs Economiques et GESFIM des sous projets A, B et C couvrant l’interface avec le système douanier DELTA Chain et les autres flux Transport/Logistique

La méthodologie du BIM (Business Information Master) est utilisée pour créer de manière cohérente des messages XML dérivés de la base normalisée UNeDocs (United Nations electronic Documents) de l’UN/CEFACT. Dans la normalisation des échanges, on distingue désormais trois grandes étapes dans le processus de la transaction eBusiness internationale, elles sont dénommées : BUY – SHIP – PAY. Le projet GESFIM s’appuie sur la structure du SHIP BIM qui couvre toutes les activités et les flux Transport/Logistique/Douanes. Il concerne les informations sur les différentes phases du mouvement du transport, les moyens de transport, les expéditions/consignations du fret transporté qui peuvent être répétés autant de fois que nécessaire pour refléter un chargement complet. Dans le cas d’un message pour une seule consignation (par exemple réservation ou contrat Bill of Lading) uniquement les informations concernant cette consignation sont échangées, mais sont toujours dérivées du même BIM. Des profils (subsets) particularisés peuvent être dérivés pour des fonctions spécifiques Transport ou Douanes. Le SHIP BIM a déjà été utilisé pour construire le message pour la SAD (DAU) sur la même base cohérente. Business Information Master (BIM) Le BIM est neutre par rapport à la syntaxe de construction des messages et est utilisé pour décrire les informations eBusiness au plus haut niveau si bien que tout message (document

30

ou transaction) peut en être facilement dérivé par « héritage ». En terme d’objets CCTS ( Core Components Technical Specifications), chaque BIM est un message composé d’une entité (Message Assembly Business Information Entity –ASMA ) sous laquelle les composants appropriés associés à haut niveau (Associated Business Infromation Entities - ASBIEs) sont structurés de telle façon que l’Utilisateur n’aura pas de difficulté à le reconnaître. Une telle structure permet la « réutilisation » et assure l’intéropérabilité entre les messages. Les BIMs font partie de la base de travail UNeDocs, qui est bâtie à partir des composants élémentaires de la librairie des composants élémentaires « UN/CEFACT Core Component Library -CCL ». Le diagramme ci-dessous indique comment un BIM est créé. Une famille de documents UNeDocs Une famille de documents UNeDocs est un jeu de structures de documents qui ont été dérivés comme des sous-ensembles hiérarchiques d’un BIM. Chaque membre de la famille hérite en conséquence de la structure eBusiness de son parent, mais peut affiner et particulariser l’information dans son propre contexte de façon à créer un profil de message spécifique. Celui-ci peut soit être un document complet soit un « snippet » pour les WebServices. Le processus d’héritage permettant la réutilisation, il assure donc l’intéropérabilité entre les messages échangés dans des domaines eBusiness différents. L’approche alternative partant du document (document-centric) plus ancienne, n’offre pas la possibilité de réutilisation et n’assure pas l’interopérabilité. Les possibilités d’utiliser le SHIP BIM pour nombre de fonctions Transport et Douanes sont illustrées ci-dessous.

Créé depuis

Créé depuis Créé depuis

Basé sur

Unqualified Data Types (UDTs)

Core Components

(CCs)

Qualified Data Types

(qDTs)

Business Information Entities (BIEs)

UN/CEFACT Core Component Library (CCL)

Business Information Entities (BIEs)

UNeDocs Workbase

Business Information Masters (BIMs)

31

UNeDocsShip BIM

Export/Import Goods

Declarations

Conveyance Reports

Customs Reporting (TBG4)

Import/Export Cargo Reports

1 StepProcedure

2 StepProcedure

UNeDocs Document Families

1 StepProcedure

2 StepProcedure

Space Booking

Air(IATA …)

Road(IRU,

FIATA ...)

Consignment Booking

Transport

Order/Shipping

Instructions

Waybill

MarineInsurance(TBG8)

TransportContract(TBG3)

Rail(UIC …)

Sea(IMO …)

Status Reporting

Arrival Notice

Customs Document Families

Transport Contractual Document Family

Insurance Document

Family

Avec le logiciel utilisé par les groupes de travail de l’UN/CEFACT, les profils de BIM pour les fonctions/flux spécifiques peuvent être définis en parfaite cohérence avec la base normalisée. De plus, les schémas XML correspondants peuvent être produits automatiquement. L’annexe contient le maximum des schémas XSD’s pour le SHIP BIM répartis dans 3 fichiers : les données, les codes et les identifiants. • Les données (data) : le SHIP BIM même et les XSD’s base (re-usable, data type etc.) • Les ‘’codes’, un XSD pour chaque list de codage • Les indentifiants « identifiers » un XSD pour chaque liste d’ identifiants Le SHIP BIM couvre le total des données possible. Pour chaque implémentation, il faut se limiter aux données qui sont nécessaires pour ce contexte. Ces schémas XSD peuvent également être ouverts et visualisés sous forme de diagrammes avec le logiciel libre (freeware) Liquid XML qui est fournit avec ce livrable de GESFIM. Il permet également d’exporter les données pour des applications internes compatibles XML. 6. Formulaires de gestion du transport (GESFIM B)

Des formulaires informatisés ont été définis pour l’application légère qui sera mise à disposition des opérateurs.

32

Les formulaires de gestion du transport sont différents selon qu’il s’agit: - du donneur d’ordre du transport qui rédige un ordre de transport complet pouvant être

décomposé en plusieurs missions par le transporteur. - du transporteur qui organise les missions, contrôle leur exécution et rend compte de

l’exécution de l’ordre de transport, - du chauffeur routier dont le message sera allégé pour être traduit sous forme de SMS sur

un téléphone portable, - de l’expéditeur de la marchandise, après avoir reçu le préavis d’enlèvement d’un ordre

de transport, doit confirmer la date et heure de rendez-vous d’enlèvement de la marchandise.

- du destinataire de la marchandise qui, après avoir reçu le préavis de livraison d’un ordre de transport, doit confirmer la date et heure de rendez-vous de réception de la marchandise.

Chaque formulaire est dédié à un des acteurs et génère un message EDI identique ou différent des autres formulaires. Formulaires du Donneur d’Ordres Ils sont constitués de: - le formulaire d’ordre de transport sur lequel il va décrire l’ensemble des informations permettant au transporteur d’organiser les missions, pour générer un message équivalent EDIFACT IFCSUM - le formulaire de compte rendu d’ordre de transport qui va afficher les données du message IFCSUM pour rendre compte notamment des horaires de réalisation des missions et des observations relevées. Formulaires du Transporteur On considère que le transporteur dispose d’un P.C ou équivalent pouvant recevoir des courriels et des messages EDI et les traiter. Les outils de traduction et d’automatisation de tâches ainsi que la solution de traitement de listes sont fournis par le projet. Les formulaires du transporteur sont :

- le formulaire d’ordre de transport sur lequel il va recevoir l’ensemble des informations lui permettant de décomposer et d’enregistrer les missions,

- le formulaire d’ordre de mission pour générer des messages équivalent EDIFACT IFTMIN qui seront envoyés à l’expéditeur et au destinataire pour confirmation de rendez vous. Le même formulaire permet de constater la réalisation de la mission et également le signalement d’un incident en cours de mission.

- Le formulaire de préavis d’enlèvement/réception qui permet d’afficher les messages d’avis d’expédition confirmés ou infirmés par l’expéditeur, ou par le destinataire.

-

Formulaire de l’Expéditeur

Le formulaire de l’expéditeur est un préavis d’enlèvement de marchandises qui couvre une mission déterminée par le transporteur, correspondant au message équivalent EDIFACT IFTMIN , sur lequel il doit confirmer ou modifier la date et l’heure de l’enlèvement des marchandises et éventuellement apporter des précisions. Formulaire du Destinataire Le formulaire du destinataire est un préavis de livraison de la marchandise qui couvre une mission déterminée par le transporteur, correspondant au message équivalent EDIFACT

33

IFTMIN , sur lequel il doit confirmer ou modifier la date et l’heure de l’enlèvement des marchandises et éventuellement apporter des précisions. Les schémas ci-dessous donnent les principaux types d’écran de l’application, qui sont développés par ailleurs dans les spécifications techniques du système.

34

35

7. Tables de correspondance entre les données DELTA et les données/

codes normalisés (Core Components UN/CEFACT, UNeDoc s) Ces tables de correspondance (mapping) sont un complément au guide d’implémentation devant faciliter la vie des Utilisateurs. Elles donnent la relation au niveau unitaire de chaque donnée/code du système GESFIM, entre les données du système DELTA telles que définies dans les spécifications des Douanes et le dictionnaire des données normalisés dénommé « Core Components » du CEFACT (CCL - Core Components Library) et les listes de codes EDIFACT associées. La version CCL 07.B de l’UN/CEFACT complétée par les soumissions récemment approuvées du TBG3 Transport / TBG2 UNeDocs (environ 500 éléments relatifs au Transport/Logistique) constituera la version CCL 08.A qui sera publiée en Avril 2008. C’est sur cette base des plus récents développements normatifs que sont définies les tables de correspondance de façon que les Utilisateurs puissent mettre en œuvre des solutions pérennes. Ces tables indiquent également les schémas/documents XML spécifiques dans lesquels les données et codes sont utilisés. Cette approche a été préférée à une définition exhaustive de chaque schéma XML correspondant aux nombreux flux définis dans DELTA (jusqu’à plus de 5 flux pour chaque transaction unitaire), ce qui aurait abouti à un guide d’implémentation trop volumineux voire confus pour les PME’s et difficile voire impossible à maintenir. Il faut préciser que ces tables de correspondance ne sont pas strictement nécessaires à qui veut utiliser la méthode décrite dans les paragraphes précédents à partir de la base normalisée BIM (Business Information Master) pour définir les schémas XML nécessaires à sa mise en œuvre. Mais elles constituent une référence supplémentaire pour ceux qui préféreraient créer leurs propres schémas XML normalisés de manière plus « archaïque». Ces tables seront néanmoins très utiles aux services des Douanes pour la maintenance du système DELTA et sa migration éventuelle future vers un système totalement normalisé. Ces tables figurent dans les annexes du présent livrable GESFIM.

36

7. Listes de codes Les différentes listes de codes normalisés : recommandations des Nations-Unies, normes ISO et/ou listes EDIFACT figurent en Annexes dans le SHIP BIM au format XML ainsi que leur équivalence avec les codes propriétaires utilisés dans le système DELTA. 8. Références Normatives

1. Unified Modelling Language (UML version 1.4)

2. UN/CEFACT Modelling Methodology UMM (CEFACT/TMG/N090R10, November 2001)

et Technical Specifications 2006-10-06

3. UN/CEFACT Modelling Methodology User Guide (CEFACT/TMG/N093)

4. UN/CEFACT –ebXML Core Components Technical Specifications version 2.01 – ISO

1500-5

5. UN/CEFACT Business Requirements Specification version 1.5 (CEFACT/ICG/005)

6. UN/CEFACT Requirements Specification Mapping version 0.5 (CEFACT/ICG/006)

7. UN/CEFACT Core Components Library CCL version 0.7B – Mars 2008 complété par les

soumissions du TBG3/TBG2 approuvées des éléments Transport pour former le CCL

08A

8. eb-XML TR-Naming Convention for Core Components version 1.04(10 May 2001)

9. UN/CEFACT Registry Specification V1.0 – Draft June 30, 2006

10. TDED Trade Data Element Directory – ISO 7372 - January 2005

11. UN/CEFACT NDR - XML Naming and Design Rules – Version 2.0 – 2006-02-17 -

12. UN/CEFACT BPAWG Reference Model of the International Supply Chain V1.0 March

2003. (UN/CEFACT/BPA/PB044)

13. ITIGG / TBG3 IFTM Principles and Rules 2000 UN/CEFACT

14. CRBDM (Cross Border Reference Data Model) UNeDocs Workbase 2.0 United

Nations electronic Documents version 2.0

15. United Nations Layout Key (UNLK) ISO 6422 UN/CEFACT

16. Portail PRODOU@NE https://pro.douane.gouv.fr/