过境运输从启运到抵达，
一个流程，合规运行。
符合 NCTS 第 6 阶段要求的国家过境应用。
CustomsFlow 是面向海关管理部门的共同过境系统（NCTS）国家应用。它依据欧盟委员会发布的 NCTS 第 6 阶段国家过境应用设计文档构建：启运地、过境和目的地海关角色各自通过状态机运行，每条消息都按既定规则验证并写入不可篡改的记录，并通过适配器连接现有海关系统。
NCTS 第 6 阶段设计文档568 条规则，版本化目录通过适配器连接现有系统实时集成监控
24开启 hareket
3查验中
11Transitte
6已抵达
1查询中
| MRN | 路线 | Son mesaj | 状态 |
|---|---|---|---|
| 26XX00000000001042 | 启运 A → 过境 B → 目的地 C | CC029C | 已放行过境 |
| 26XX00000000001043 | 启运 A → 目的地 D | CC060C | 查验中 |
| 26XX00000000001038 | 启运 E → 过境 B → 目的地 A | CD118C | 已受理抵达 |
| 26XX00000000001021 | 启运 A → 目的地 F | CC045C | 运输已关闭 |
| 26XX00000000000997 | 启运 C → 目的地 A | 计时器 | 查询 |
启运启运地海关 A已放行过境
过境过境海关 B等待过境
目的地目的地海关 C预计抵达
IE015已接收贸易商申报；模式、代码表和规则校验通过09:12CC028C已签发 MRN，已记录担保使用09:12CC060C风险评分超过阈值：已通知查验决定09:13CC029C经海关官员批准放行过境09:41CD050C已向过境海关发送预先通知09:41
运营看板 · 按角色打开：未结运输、状态和最新消息CustomsFlow 界面 · 虚构数据
一次运输的旅程车辆经过三个 海关,
车辆经过三个 海关,
记录从不中断。
车辆从出发地到目的地经过每个海关时都会生成报文,担保被锁定并随后释放。每个海关都能从同一条记录中看到运输状态。
Transit hareketi · 26XX00000000001042示例 hareket · kurgusal veri 已接收申报
IE015已接收贸易商申报，并通过模式、代码表和规则校验。担保已锁定担保已释放道闸关闭
IE015启运地海关接收申报，签发 MRN，锁定担保；查验后放行过境。
CD050C过境海关接收预先记录；车辆提交后准许通过，并通报越境情况。
CD006C目的地海关受理抵达，并将查验结果通知启运地海关。
CC045C收尾运输关闭，担保释放；每一步都保留在记录中。
问题过境规则不断变化，
过境规则不断变化，
系统却跟不上。
共同过境系统的新阶段带来了数百条消息规则、数十种消息类型、业务计时器，以及与伙伴国海关之间的双向消息交换。把这些写进现有海关系统既耗时，又意味着每次规则变更都要重新开发。
嵌入代码的规则
当规则和代码表存放在应用内部时，每一次变更都会变成一个软件项目。
众多外部系统
申报、风险、担保、出口以及伙伴国海关；每一个都意味着单独的连接和单独的错误格式。
不可见的消息流量
要查明运输因哪条消息、为何受阻，需要在多个系统之间逐一追查。
如何运作？从申报到关闭
从申报到关闭
只需四步。
从贸易商申报到运输关闭，每一步都遵循设计文档中的消息和状态定义；业务计时器以数据形式保存，期限届满的运输自动转入查询程序。
- 1
接收申报
贸易商消息经过模式、代码表和规则校验；通过则签发 MRN 并记录担保使用，未通过则连同所违反的规则一并退回拒绝消息。
- 2
风险与查验
若风险引擎评分超过阈值，即通知查验决定；启运地海关官员在自己的界面上作出决定。
- 3
过境与抵达
运输放行过境后，过境海关和目的地海关通过公共域消息获知情况，并各自作出决定。
- 4
收尾
抵达结果返回启运地海关，担保释放，运输关闭。期限届满的运输转入查询程序。
Ofis rolleri30 个状态，18 项决策，
启运地海关
Transit ofisi
目的地海关
30 个状态，18 项决策，
一条运输记录。
过境运输途经启运地、过境和目的地海关时，每个海关都将自己的状态和决定写入同一条记录。状态和流转依据设计文档中的官方图表构建；哪个海关有哪些待办事项，随时一目了然。
3海关角色启运、过境和目的地，各自拥有独立的状态机。
30官方状态运输在每个海关的状态，沿用文档中的名称。
18决策 迁移i仅在授权海关官员界面上显示的决策。
15业务计时器期限届满后，运输自动转入查询程序。
15
resmi durum该运输在此海关的状态
6
karar 迁移i海关官员可作出的决策
接收申报的海关
受理申报、风险与担保检查、查验决定、放行过境、取消和查询。
收益查验决定、担保和放行过境集中在同一界面；被拒绝的申报连同所违反的规则编号退回贸易商。
9
resmi durum该运输在此海关的状态
7
karar 迁移i海关官员可作出的决策
越境时经过的海关
接收预先记录、提交车辆、准许或拒绝通过。
收益预先记录在车辆抵达前即送达海关；海关官员的通过决定通过公共域消息通知启运地海关。
6
resmi durum该运输在此海关的状态
5
karar 迁移i海关官员可作出的决策
运输终结的海关
受理抵达、查验结果、放行货物并通知启运地海关。
收益抵达和查验结果通过消息返回启运地海关；运输关闭，担保释放。
消息验证每条消息都要经过八道关口，
每条消息都要经过八道关口，
出错的消息连同所违反的规则一并退回。
来自贸易商或公共域的每条消息，都按设计文档规定的顺序进行验证。规则不在应用代码中，而在版本化规则目录里：共 568 条规则与条件，变更时更新的是目录，而不是代码。
IE015贸易商申报 · LRN DEMO-0042✓1模式XSD 结构
✓2Kod listesiOrtak referans veri
✓3S顺序检查
✓4BRT过渡期规则
✓5C条件lar
✓6R规则
✓7TTeknik kurallar
✓8G指南
…
正在验证消息八项检查依次运行；遇到第一个错误即停止。
已接受的消息运输进入下一状态并生成响应消息；例如为申报签发 MRN（CC028C）。
被拒绝的消息向贸易商退回拒绝消息（CC056C），指明违反了哪条规则；运输状态不变。
两种情况均有记录消息的 XML 及结果写入不可篡改的记录，并显示在运输卡片上。
集成您现有的系统
✓ 均不做更改
您现有的系统
保持不变。
CustomsFlow 通过适配器层连接海关管理部门正在运行的系统，无需改动这些系统。八个集成点使用同一契约通信，每次调用都会被记录。
您现有的系统
Beyan sistemi
Risk motoru
担保管理
出口系统
公共域网络
贸易商通道
Referans veri
可用性
CustomsFlow基于 BUTTERFLY
- 过境引擎 · 角色、状态、计时器
- 规则目录 · 568 条规则与条件
- 不可篡改的记录 · 每条消息和每次调用
200risk · skor 78 · kontrol
0 处现有系统改动1 份调用契约，8 个接入点每次调用均完整记录请求与响应实时监控：见上方界面
实践案例为一个国家海关管理部门
为一个国家海关管理部门
一天完成端到端原型。
我们为一个国家海关管理部门在 Butterfly 上构建了 NCTS 第 6 阶段国家过境应用原型。所有数据均为虚构；测试场景通过浏览器和 API 从头到尾完整运行。
- 1 天端到端 kurulum从启运到过境、从抵达到运输关闭，整个流程在一天内完成搭建并运行。
- 568规则与条件设计文档中的规则与条件已作为版本化目录导入；另从公共参考数据导入 5,517 条代码表记录。
- 8个集成点申报、风险、担保、出口、公共域、贸易商通道、参考数据和可用性；统一契约，实时监控。
- 19 / 20测试场景通过涵盖担保错误、违反规则、拒绝通过、取消和查询。剩余一项是有意简化的拒绝流程。
能力国家过境所需的
国家过境所需的
一切。
基于角色的状态机启运、过境和目的地各有独立的状态机；状态采用设计文档中的官方名称。
版本化规则目录规则与条件从目录而非代码中读取；代码表来自公共参考数据。
不可篡改的消息记录每条消息连同其 XML 一并保存；可从运输卡片打开消息链和内容。
以数据形式管理的计时器业务计时器以记录形式保存；期限届满的运输转入查询程序。
通过适配器集成统一的调用契约；切换到真实系统时只需更换适配器，引擎和界面保持不变。
基于角色的权限管理员，启运地、过境和目的地海关官员，以及贸易商；每个人只能看到自己的界面和决策。
适用于哪些团队？端到端管理
端到端管理
过境运输的团队。
海关管理部门官员
启运地、过境和目的地海关为什么？ ↻为什么？
为了弄清运输为何停滞而在多个系统中追查，会延长决策时间。
主要用途在同一界面查看运输状态、消息链和自己的决策。
启运地、过境和目的地海关贸易商和报关代理
Beyan sahipleri, lojistik ekipleri为什么？ ↻为什么？
没有理由的拒绝会导致同一申报被反复试错重新提交。
主要用途通过规则编号了解申报被拒原因，并掌握运输所在位置。
Beyan sahipleri, lojistik ekipleri海关 IT 与集成团队
系统与集成管理为什么？ ↻为什么？
如果规则写在代码里，每次阶段变更都意味着一个新的软件项目。
主要用途实时监控外部系统调用，无需编写代码即可启用新的规则集。
系统与集成管理
信任与控制现有系统保持不变，
现有系统保持不变，
每一步都有记录。
CustomsFlow 的设计初衷不是取代海关管理部门正在运行的系统，而是将它们连接到共同过境系统。每条消息和每次外部调用都有记录；决策权在授权海关官员手中。
控制
- 每条消息连同 XML 存入不可篡改的记录
- 每次外部调用均完整记录请求与响应
- 决策仅在授权海关官员的界面上进行
- 时间以 UTC 存储，界面显示本地时间
Platform
- 通过适配器连接现有海关系统
- 以 Opt-Out 模式启动，随时可切换至 Opt-In
- 多语言界面
- 支持本地部署
需求测试
CustomsFlow 与您过境流程的 契合度如何？
8 个问题，两分钟。最后查看 CustomsFlow 与您过境流程的适配评分卡及其原因。
- 过境覆盖范围
- 规则与报文
- 集成
- 审计
常见问题关于 CustomsFlow
关于 CustomsFlow
简要解答。
CustomsFlow nedir?
它是面向海关管理部门的共同过境系统（NCTS）第 6 阶段国家过境应用，在 Butterfly 平台上将启运地、过境和目的地海关角色、消息验证、业务计时器以及外部系统集成整合到同一个应用中。
依据哪份文档构建？
依据欧盟委员会发布的 NCTS 第 6 阶段国家过境应用设计文档（DDNTA，6.4.1 版）构建。状态、流转和消息类型均遵循该文档中的官方定义。
我们需要改动现有海关系统吗？
不会。您的申报、风险、担保、出口和参考数据系统通过适配器连接。所有集成点使用同一契约通信;切换到真实系统时只需更换适配器。
规则变化时会怎样？
规则与条件不在应用代码中，而在版本化规则目录中。新的规则集通过更新目录即可启用。
是否支持 Opt-Out 和 Opt-In 模式？
该应用按 Opt-Out 模式启动构建，并已为切换至 Opt-In 做好设计准备。
是否已投入实际使用?
CustomsFlow 已为一个国家海关管理部门使用虚构数据构建原型并完成测试。正式上线需要连接该部门自身的系统，并通过官方一致性测试。
可以本地部署吗？
是的。CustomsFlow 运行在 Butterfly 平台上，可部署在海关管理部门自己的基础设施中；访问通过基于角色的权限授予。