Le mouvement de transit, du départ à la destination,
en un seul flux et conforme aux règles.
Application nationale de transit conforme à NCTS Phase 6.
CustomsFlow est l'application nationale du système de transit commun (NCTS) destinée aux administrations douanières. Elle a été construite selon le document de conception des applications nationales de transit NCTS Phase 6 publié par la Commission européenne : les rôles de bureau de départ, de passage et de destination fonctionnent avec leurs propres machines à états, chaque message est validé selon des règles définies et écrit dans un journal immuable, et les systèmes douaniers existants sont raccordés via un adaptateur.
Document de conception NCTS Phase 6568 règles, catalogue versionnéAdaptateur vers les systèmes existantsMoniteur d’intégration en direct
24Activé hareket
3Sous contrôle
11Transitte
6À destination
1En procédure de recherche
| MRN | Itinéraire | Son mesaj | Statut |
|---|---|---|---|
| 26XX00000000001042 | Départ A → Passage B → Destination C | CC029C | Mainlevée pour le transit |
| 26XX00000000001043 | Départ A → Destination D | CC060C | Sous contrôle |
| 26XX00000000001038 | Départ E → Passage B → Destination A | CD118C | Arrivée acceptée |
| 26XX00000000001021 | Départ A → Destination F | CC045C | Mouvement clôturé |
| 26XX00000000000997 | Départ C → Destination A | Minuteur | Recherche |
DÉPARTBureau de départ AMainlevée pour le transit
PASSAGEBureau de passage BPassage en attente
DESTINATIONBureau de destination CArrivée attendue
IE015Déclaration de l’opérateur reçue ; contrôles de schéma, de listes de codes et de règles réussis09:12CC028CMRN attribué, utilisation de la garantie enregistrée09:12CC060CScore de risque au-dessus du seuil : décision de contrôle notifiée09:13CC029CMainlevée pour le transit avec l’accord de l’agent09:41CD050CAvis anticipé envoyé au bureau de passage09:41
Tableau de bord opérationnel · Accueil par rôle : mouvements ouverts, statuts et derniers messagesÉcrans CustomsFlow · données fictives
Le parcours d’un mouvementLe véhicule passe trois bureaux,
Le véhicule passe trois bureaux,
le journal ne s’interrompt jamais.
À chaque bureau de douane traversé, du départ à la destination, des messages sont produits et la garantie est bloquée puis libérée. Chaque bureau voit le statut du mouvement à partir du même enregistrement.
Transit hareketi · 26XX00000000001042Exemple hareket · kurgusal veri Déclaration reçue
IE015Déclaration de l’opérateur reçue ; elle a passé les contrôles de schéma, de listes de codes et de règles.Garantie bloquéeGarantie libéréeBarrière fermée
IE015Bureau de départLa déclaration est reçue, un MRN est attribué et la garantie est bloquée ; après contrôle, le mouvement obtient la mainlevée pour le transit.
CD050CBureau de passageReçoit l’avis anticipé ; à la présentation du véhicule, il autorise le passage et notifie le franchissement de la frontière.
CD006CBureau de destinationAccepte l’arrivée et communique le résultat du contrôle au bureau de départ.
CC045CClôtureLe mouvement est clôturé, la garantie libérée ; chaque étape reste enregistrée.
ProblèmeLes règles du transit évoluent,
Les règles du transit évoluent,
les systèmes ne suivent pas.
La nouvelle phase du système de transit commun apporte des centaines de règles de messages, des dizaines de types de messages, des minuteries métier et des échanges de messages avec les administrations des pays partenaires. L’intégrer dans les systèmes douaniers existants prend du temps et exige un nouveau développement à chaque changement de règle.
Des règles enfouies dans le code
Lorsque les règles et les listes de codes se trouvent dans l’application, chaque changement devient un projet logiciel.
De nombreux systèmes externes
Déclaration, risque, garantie, exportation et administrations partenaires : chacun implique une connexion distincte et un format d’erreur distinct.
Un trafic de messages invisible
Pour savoir quel message bloque un mouvement et pourquoi, il faut remonter la piste dans plusieurs systèmes.
Comment cela fonctionne-t-il ?De la déclaration à la clôture
De la déclaration à la clôture
en quatre étapes.
Chaque étape, de la déclaration de l’opérateur à la clôture du mouvement, suit les définitions de messages et d’états du document de conception ; les minuteries métier sont gérées comme des données, et un mouvement dont le délai expire passe automatiquement en procédure de recherche.
- 1
Déclaration reçue
Le message de l’opérateur passe les contrôles de schéma, de listes de codes et de règles ; s’il est valide, un MRN est attribué et l’utilisation de la garantie est enregistrée, sinon il est rejeté avec la règle enfreinte.
- 2
Risque et contrôle
Si le score du moteur de risque dépasse le seuil, une décision de contrôle est notifiée ; l’agent du bureau de départ prend sa décision depuis son propre écran.
- 3
Passage et destination
Le mouvement obtient la mainlevée pour le transit ; les bureaux de passage et de destination sont informés par des messages du domaine commun et prennent leurs propres décisions.
- 4
Clôture
Le résultat de l’arrivée revient au bureau de départ, la garantie est libérée et le mouvement est clôturé. Un mouvement dont le délai expire passe en procédure de recherche.
Ofis rolleri30 états, 18 décisions,
Bureau de départ
Transit ofisi
Bureau de destination
30 états, 18 décisions,
un seul enregistrement de mouvement.
Lorsqu’un mouvement de transit traverse les bureaux de départ, de passage et de destination, chaque bureau inscrit son état et sa décision dans le même enregistrement. Les états et les transitions ont été construits à partir des diagrammes officiels du document de conception ; ce qui est en attente dans chaque bureau est visible à tout moment.
3Rôles de bureauDépart, passage et destination, chacun avec sa propre machine à états.
30États officielsL’état du mouvement dans chaque bureau, sous le nom donné par le document.
18Décision migrationiDes décisions visibles uniquement sur l’écran de l’agent habilité.
15Minuteries métierÀ l’expiration du délai, le mouvement passe automatiquement en procédure de recherche.
15
resmi durumles états du mouvement dans ce bureau
6
karar migrationidécisions que l’agent peut prendre
Le bureau où la déclaration est déposée
Acceptation de la déclaration, contrôle du risque et de la garantie, décision de contrôle, mainlevée pour le transit, annulation et procédure de recherche.
BénéficeDécision de contrôle, garantie et mainlevée pour le transit sur un seul écran ; une déclaration rejetée revient à l’opérateur avec le numéro de la règle enfreinte.
9
resmi durumles états du mouvement dans ce bureau
7
karar migrationidécisions que l’agent peut prendre
Le bureau où la frontière est franchie
Réception de l’avis anticipé, présentation du véhicule, autorisation ou refus du passage.
BénéficeL’avis anticipé parvient au bureau avant l’arrivée du véhicule ; la décision de passage de l’agent des douanes est notifiée au bureau de départ par un message du domaine commun.
6
resmi durumles états du mouvement dans ce bureau
5
karar migrationidécisions que l’agent peut prendre
Le bureau où le mouvement prend fin
Acceptation de l’arrivée, résultat du contrôle, mainlevée des marchandises et notification au bureau de départ.
BénéficeL’arrivée et le résultat du contrôle reviennent au bureau de départ par message ; le mouvement est clôturé et la garantie libérée.
Validation des messagesChaque message franchit huit portes,
Chaque message franchit huit portes,
les messages erronés reviennent avec leur règle.
Chaque message provenant de l’opérateur ou du domaine commun est validé dans l’ordre défini par le document de conception. Les règles ne se trouvent pas dans le code de l’application, mais dans un catalogue de règles versionné : 568 règles et conditions ; lorsqu’elles changent, c’est le catalogue qui est mis à jour, pas le code.
IE015Déclaration de l’opérateur · LRN DEMO-0042✓1SchémaStructure XSD
✓2Kod listesiOrtak referans veri
✓3SContrôle de séquence
✓4BRTRègles de la période de transition
✓5CConditionlar
✓6RRègles
✓7TTeknik kurallar
✓8GLignes directrices
…
Validation du messageHuit contrôles s’exécutent dans l’ordre ; la validation s’arrête à la première erreur.
Message acceptéLe mouvement passe à l’état suivant et un message de réponse est généré ; par exemple, un MRN est attribué à la déclaration (CC028C).
Message rejetéUn message de rejet (CC056C) indiquant la règle enfreinte est renvoyé à l’opérateur ; l’état du mouvement ne change pas.
Enregistré dans les deux casLe XML du message et son résultat sont écrits dans le journal immuable et apparaissent sur la fiche mouvement.
IntégrationVos systèmes existants
✓ Aucun n’est modifié
Vos systèmes existants
restent en place.
CustomsFlow se connecte aux systèmes en service de l’administration douanière via une couche d’adaptation, sans exiger de modification de ces systèmes. Huit points d’intégration partagent le même contrat, et chaque appel est enregistré.
Vos systèmes existants
Beyan sistemi
Risk motoru
Gestion des garanties
Système d’exportation
Réseau du domaine commun
Canal opérateur
Referans veri
Disponibilité
CustomsFlowSUR BUTTERFLY
- Moteur de transit · rôles, états, minuteries
- Catalogue de règles · 568 règles et conditions
- Journal immuable · chaque message et chaque appel
200risk · skor 78 · kontrol
0 modification des systèmes existants1 contrat d’appel, 8 pointsChaque appel enregistré avec sa requête et sa réponse complètesMoniteur en direct : dans les écrans ci-dessus
Retours d’expériencePour une administration douanière nationale,
Pour une administration douanière nationale,
un prototype de bout en bout en une journée.
Pour une administration douanière nationale, une application nationale de transit NCTS Phase 6 a été construite sous forme de prototype sur Butterfly. Toutes les données étaient fictives ; les scénarios de test ont été exécutés de bout en bout via le navigateur et l’API.
- 1 jourDe bout en bout kurulumL’ensemble du flux, du départ au passage et de l’arrivée à la clôture du mouvement, a été construit et exécuté en une journée.
- 568Règles et conditionsLes règles et conditions du document de conception ont été chargées sous forme de catalogue versionné, avec 5 517 entrées de listes de codes issues des données de référence communes.
- 8Points d’intégrationDéclaration, risque, garantie, exportation, domaine commun, canal opérateur, données de référence et disponibilité ; un contrat, un moniteur en direct.
- 19 / 20Scénarios de test réussisY compris erreurs de garantie, violations de règles, refus de passage, annulation et procédure de recherche. Le scénario restant est un flux de rejet volontairement simplifié.
CapacitésPour le transit national,
Pour le transit national,
tout ce qu'il faut.
Machines à états par rôleDes machines à états distinctes pour le départ, le passage et la destination ; les états portent les noms officiels du document de conception.
Catalogue de règles versionnéLes règles et conditions sont lues dans le catalogue, et non dans le code ; les listes de codes proviennent des données de référence communes.
Journal immuable des messagesChaque message est conservé avec son XML ; la chaîne de messages et leur contenu s'ouvrent depuis la fiche mouvement.
Des minuteries sous forme de donnéesLes minuteries métier sont gérées comme des enregistrements ; un mouvement dont le délai expire passe en procédure de recherche.
Intégration par adaptateurUn contrat d’appel unique ; lors du passage au système réel, seul l’adaptateur change, le moteur et les écrans restent identiques.
Droits d’accès par rôleAdministration, agents des bureaux de départ, de passage et de destination, et opérateur ; chacun ne voit que son propre écran et ses propres décisions.
Pour quelles équipes ?Les équipes qui pilotent le transit
Les équipes qui pilotent le transit
de bout en bout.
Agents de l’administration douanière
Bureaux de départ, de passage et de destinationPourquoi ? ↻Pourquoi ?
Remonter la piste dans plusieurs systèmes pour comprendre pourquoi un mouvement est en attente allonge le délai de décision.
À quoi sert-ilVoir l’état du mouvement, la chaîne de messages et leur propre décision sur un seul écran.
Bureaux de départ, de passage et de destinationOpérateurs et commissionnaires en douane
Beyan sahipleri, lojistik ekipleriPourquoi ? ↻Pourquoi ?
Un rejet sans motif conduit à renvoyer la même déclaration par essais et erreurs.
À quoi sert-ilVoir pourquoi une déclaration a été rejetée, avec le numéro de la règle, et savoir où se trouve le mouvement.
Beyan sahipleri, lojistik ekipleriÉquipes informatiques et d’intégration des douanes
Gestion des systèmes et de l’intégrationPourquoi ? ↻Pourquoi ?
Si la règle est dans le code, chaque changement de phase implique un nouveau projet logiciel.
À quoi sert-ilSuivre en temps réel les appels aux systèmes externes et mettre en service de nouveaux jeux de règles sans écrire de code.
Gestion des systèmes et de l’intégration
Confiance et contrôleLes systèmes existants restent inchangés,
Les systèmes existants restent inchangés,
chaque étape est enregistrée.
CustomsFlow n’a pas été conçu pour remplacer les systèmes en service de l’administration douanière, mais pour les connecter au système de transit commun. Chaque message et chaque appel externe sont enregistrés ; les décisions appartiennent à l’agent habilité.
Contrôle
- Chaque message dans un journal immuable, avec son XML
- Chaque appel externe enregistré avec sa requête et sa réponse complètes
- Les décisions uniquement sur l’écran de l’agent habilité
- Heures stockées en UTC, affichées en heure locale
Platform
- Se connecte aux systèmes douaniers existants via un adaptateur
- Démarre en mode Opt-Out, prêt pour Opt-In
- Interface multilingue
- Peut être installé sur site
Test des besoins
CustomsFlow et votre processus de transit : quelle adéquation ?
8 questions, deux minutes. Découvrez ensuite le bilan d’adéquation de CustomsFlow à votre processus de transit et ses raisons.
- Périmètre transit
- Règle et message
- Intégration
- Audit
Questions fréquentesÀ propos de CustomsFlow
À propos de CustomsFlow
en quelques réponses.
CustomsFlow nedir?
C’est l’application nationale de transit NCTS Phase 6 du système de transit commun (NCTS) destinée aux administrations douanières. Elle réunit les rôles de bureau de départ, de passage et de destination, la validation des messages, les minuteries métier et les intégrations aux systèmes externes dans une seule application sur la plateforme Butterfly.
Sur quel document repose-t-elle ?
Elle a été construite selon le document de conception des applications nationales de transit NCTS Phase 6 (DDNTA, version 6.4.1) publié par la Commission européenne. Les états, les transitions et les types de messages suivent les définitions officielles de ce document.
Devons-nous modifier nos systèmes douaniers existants ?
Non. Vos systèmes de déclaration, de risque, de garantie, d’export et de données de référence sont reliés par des adaptateurs. Tous les points d’intégration utilisent le même contrat ; lors du passage au système réel, seul l’adaptateur change.
Que se passe-t-il lorsque les règles changent ?
Les règles et conditions ne se trouvent pas dans le code de l’application, mais dans un catalogue de règles versionné. Un nouveau jeu de règles est mis en service par une mise à jour du catalogue.
Prend-elle en charge les modes Opt-Out et Opt-In ?
L'application a été configurée pour démarrer en mode Opt-Out et conçue pour être prête au passage à Opt-In.
Est-il utilisé en production ?
CustomsFlow a été construit et testé sous forme de prototype avec des données fictives pour une administration douanière nationale. La mise en production nécessite le raccordement aux propres systèmes de l’administration et des tests de conformité officiels.
Peut-il être déployé sur site ?
Oui. CustomsFlow fonctionne sur la plateforme Butterfly et peut être installé sur l’infrastructure propre de l’administration douanière ; l’accès est accordé selon des droits basés sur les rôles.