3. Functional information exchange specifications
Emplacement : Documentation ICS2 > Interface Control Document
FUNCTIONAL INFORMATION EXCHANGE SPECIFICATIONS
INFORMATION EXCHANGES
In this section, the asynchronous S2S interaction between the ICS2 TI and the access point used by an EO is described with the help of high-level sequence diagrams as a set of prescribed information exchanges. These sequence diagrams focus on showing the correlation between services, related message exchanges and system operations which support business processes defined in ICS2 Business Process Description document [R02]. Therefore, they cover functionalities and actions which are initiated by or require the response of the IT system through which the EO is connected to the TI.
In the sequence diagrams provided below, the mapping of services to system operations (actions) is provided to the reader using the “service_name (ACTION)” convention. The action names used to invoke each operation are aligned with the corresponding message ID of the BPM L4 functional specifications and related ICS2 Information Exchange Message Specifications document [R04]. The list of ICS2 services and the correlation to messages and actions are detailed further below in Annex 1.
To assure completeness of information flow and accuracy of high-level description of the system, the high-level sequence diagrams include the ICS2 Common Repository system and the Responsible Member State NES systems, even though there is no direct interaction between access point used by an EO and those systems for the purpose of ICS2.
General Context
In the context of the communication between the EO system and the ICS2 TI, there are four categories of business interaction between the Person filing or if different the Carrier and the ICS2 system:
- Lodge (full or partial)/amend/invalidate an ENS filing;
- Lodge an arrival notification for the means of transport (in case of air and maritime transport);
- Respond to request for additional information from National Customs Authorities;
- Receive information or error notifications relevant to the submitted lodgings.
The Person filing, or if different the Carrier, can be an actor in three of the four categories of business interaction above. A Person filing is responsible for registering a full or partial ENS filing, completing all necessary details according to the type of ENS filing. The types of ENS filing are divided into the following main categories:
- ‘sea and inland waterways’;
- ‘air cargo’;
- ‘express consignments’;
- ‘postal consignments’;
- ‘road mode of transport’;
- ‘rail mode of transport’.
More information can be found in Annex 1.
The Person filing can submit a request to amend or invalidate a previously registered ENS filing.
The carrier that is the operator of the vessel or aircraft entering the EU from a foreign origin must lodge an arrival notification to the customs office of first entry except where such information is available to the customs authorities (Article 133 UCC).
The Person filing can receive a request to provide additional information and consequently respond to this request. There are two types of request:
- a request to provide additional information;
- a request to perform a HRCM screening (aviation only).
The Person filing can receive information or error notifications relevant to previously submitted ENS filing(s), e.g. notification of an ENS filing for which the ENS is deemed not complete.
Some notifications can be also sent by the TI to the Carrier if different from the filer, when under certain circumstances a Carrier must be notified about an action performed on the system by a Person filing. The carrier is to be notified when:
- The carrier is different from the Person filing and has expressed the preference to also receive the notifications concerning these filings;
- A Do Not Load (message) is issued for cargo transported by that carrier;
- One or more of the parties that the Carrier has indicated as obliged to lodge ENS filings, have not yet filed;
- The carrier is connected to the TI.
Furthermore, there is one notification (in particular, a notification of an ENS filing for which the ENS is deemed not complete) sent by the TI to the ‘Person not yet filed’, a role which is also defined in the ICS2 Business Process Model [R02]. The Person that has not yet filed is to be notified when:
- This person was indicated in an ENS filing (master or house level) as a person that has an obligation to file a lower level ENS filing;
- The person is connected to the TI.
As mentioned above, the IT system connectivity to the TIs can be implemented by the trader (a Person filing or if different a Carrier) themselves or it can be provided as a service by a contracted IT Service Provider (ITSP). Such ITSP assumes responsibility as system owner of the connecting system (system actor) which must be registered and authorised by Customs; this of course on top of its contractual responsibilities towards the trader as his client.
In the case a trader contracts the use of ITSP services, it will not release him from his responsibility towards Customs Authorities (as Person filing or Carrier).
The access point operated by an ITSP is delivering messages on behalf of a Person filing or if different the Carrier. From a system perspective this is just the intermediary for sending messages containing ENS Filings and receiving/dispatching replies and notifications.
In all cases, in order to be able to send or receive messages from a TI, a party (either an ITSP or the trader himself) must be registered and authorised by the Customs Authorities and registered in the TI to establish system connectivity to ICS2 Trader Interfaces and act as system actor.
The high-level sequence diagrams in the following paragraphs correspond to the following scenarios:
- Register ENS filing (Person filing and Carrier);
- Amend ENS filing (Person filing);
- Invalidate ENS filing (Person filing);
- Submit arrival notification (Person filing);
- Additional information response (Person filing and Carrier);
- HRCM screening response (Person filing and Carrier);
- Notifications received from TI (Person filing, Person not yet filed and Carrier).
ENS filing (IE3Fxx)
A Person filing is responsible for lodging a full or partial ENS filing, providing all necessary details according to the type of ENS filing. The types of ENS filing are divided into the following main categories:
- ‘sea and inland waterways’;
- ‘air cargo’;
- ‘express consignments’;
- ‘postal consignments’;
- ‘road mode of transport’;
- ‘rail mode of transport’.
The types of ENS filing are distinguished using a Specific Circumstance Indicator which can take a code value of the type FXX, where XX are two numeric digits, e.g. ‘F10’. The mapping of the code values to the types of ENS filing can be found in Annex 1.
Figure 2: ‘Register ENS filing’ information exchange In Figure 2, the reader can see actions which include the FXX code value, i.e. IE3FXX. The sequence diagram in the current section represents the message exchange pattern for the submission of any type of ENS filing.
After the submission of an ENS filing via the access point of the Person filing, the Person filing will receive a single reply with an MRN via this same access point.
ENS filing amendment (IE3Axx)
A Person filing may request to amend a full or partial ENS filing, by submitting a new data-set, according to the type of ENS filing. The updated data-set submitted by this amendment completely replaces the data-set previously associated with the MRN and submitted in a previous ENS filing or amendment. The types of ENS filing amendment are distinguished by their message ID which can take a code value of the type IE3AXX, where XX are two numerical digits, e.g. ‘IE3A10’. The mapping of the code values to the types of ENS filing amendment can be found in
Figure 3: ‘Amend ENS filing’ information exchange After the submission of an amendment to an ENS filing from the filer’s access point and successful semantic, syntactical and lifecycle validation, the Person filing will receive a single reply via this access point. Alternatively, an error message will be received by the person filing giving the reason for the message rejection.
Invalidation request (IE3Q04)
A Person filing can submit an electronic request to invalidate an ENS filing. The following sequence diagram describes how the system enables the Person filing to electronically request the invalidation of an ENS filing. After the submission of an invalidation request for an ENS filing via the access point of the Person filing, the Person filing will receive a single reply via this same access point.
Figure 4: ‘Invalidate ENS filing’ information exchange
Arrival notification (IE3N06)
In case of air and maritime transport, an arrival notification for the means of transport can be lodged, either via TI or a national arrival system, by a Person filing (a carrier operating the means of transport). The arrival notification identifies the Member State of Actual First Entry and triggers controls on goods which were identified being a risk requiring a control at the first point of entry in the EU (i.e. security and safety threat of such nature that immediate action is required upon arrival).
The following sequence diagram describes how an arrival notification can be lodged via the EO system.
Figure 5: 'Submit arrival notification' information exchange
Additional information request (IE3Q02)
Under certain circumstances, the Person filing may be requested to provide additional information regarding one or more already submitted ENS filing(s). The following sequence diagram describes where the request for additional information originates from and how it reaches the Person filing, who in turn responds to the request. The Carrier may also request to be notified about the request to provide additional information when it is not the Person filing.
Figure 6: ‘Additional information response’ information exchange
High Risk Cargo & Mail screening request (IE3Q03)
Under certain circumstances, the Person filing may be requested to execute HRCM screening during the air cargo pre-loading phase. The following sequence diagram describes where the request for HRCM screening execution originates from and how it reaches the Person filing, who in turn responds with the HRCM screening outcome. The Carrier if different may be also notified that the Person filing was requested to provide HRCM screening outcome.
Figure 7: ‘HRCM screening response’ information exchange
Notifications received from ICS2 TI
The “Person filing”, the “Person having not yet filed” and the “Carrier” may receive notifications from ICS2 TI, in the following cases:
- (AEOS) Control Notification (IE3N09) - The Authorised Economic Operator will be notified about the controls that will be performed on the goods that are under his responsibility. The ICS2 TI sends an (AEOS) Control Notification with ID IE3N09 to the Person filing. This notification may be also communicated to the Carrier whenever applicable;
- ENS Not Complete Notification (IE3N02) - An ENS is marked as not complete after: either the timer for ENS completion has expired or completeness did not derive from the "Relate ENS filings" sub process. The ICS2 TI sends the ENS Not Complete Notification with ID IE3N02 to the Person filing. This notification may be also communicated to the Carrier whenever applicable;
- Do Not Load Request (IE3Q01) - The risk assessment of an ENS filing is complete. The Economic Operator will be requested to not load a part of his initially declared consignment. The ICS2 TI sends the Do Not Load Request with ID IE3Q01 to the Person filing. This notification must be also communicated to the Carrier when the Carrier is different from the Person filing. The specific parts that are not to be loaded will be indicated through the message;
- Assessment Complete Notification (IE3N03) - The risk assessment of an ENS filing is complete. The ICS2 TI sends the Assessment Complete Notification with ID IE3N03 to the Person filing when that person has requested to be informed. This notification may be also communicated to the Carrier when it has requested to be informed and is different from the person filing; and
- ENS Pending Notification (IE3N11) - The Person that has not yet filed is informed that he is obliged to file an ENS filing. The ICS2 TI sends the ENS Pending Notification with ID IE3N11 to the Person that has not yet filed.
The Person filing's system and the Carrier's system to be notified are identified as defined in the technical rule on routing in section “Response and notification routing”.
The following sequence diagram describes how the above notifications reach the Person filing and if different the Carrier.
Figure 8: ‘Notifications received from ICS2 TI’ information exchange
Consult ENS (IE3Q05)
The “Person filing” may request information about a specific ENS filing identified by a provided MRN, Master level transport document or House level transport document, and/or an ENS that this filing concerns. The information that will be provided will depend on the access rights that each requesting party has.
Figure 9: ‘Consultation request’ information exchange The “Person filing” will receive the list of the entities related to the provided MRN, Master level transport document or House level transport document, and related notifications (if available):
- When an MRN is provided in the ENS Consultation the ICS2 system will identify the ENS Filing to which the MRN was generated, and include the relevant notifications to the MRN (and the related ENS entities) for which the EO making the ENS Consultation request;
- When a Master level or House level Transport document reference number is provided in the ENS Consultation the ICS2 system will identify the ENS Filing via which the Transport document was registered, and include the relevant notifications to the MRN (and the related ENS entities) for which the EO making the ENS Consultation request.
The access rights on the consultation request are based on the general rule that the sender of the ENS consultation request will receive in the reply only information already earlier exchanged with this sender (in addition to the status of this information as known by the Common Repository). This means a consultation request for a specified identifier (MRN, Master or House identifier) will only return any result if the original message exchange was done by the sender of the request. If notifications are requested, only notifications previously already exchanged with this sender are considered.
When the consultation is for a House consignment, the notifications (and the related ENS entities) only related to the House consignment will be retrieved and forwarded (not the notifications in general related to the ENS to which this House consignments belongs).
When the consultation is for a Master consignment, the notifications (and the related ENS entities) only related to the Master ENS Filing are retrieved and forwarded (not the notifications related to the linked House consignments nor the related ENS entities).
Only related notifications of the last 30 days will be provided.
Error handling
In the case of asynchronous interaction as described above, validation of a received message can result in errors being detected. In that case an error message is sent to the sender. This message is defined as IE3N99 for a general validation error, and as IE3N01 in case of a lifecycle validation error.
Attachments
Some messages contain binary attachments of files, which must be treated in a particular way. The following messages contain possibly such files:
- ENS filings and amendments: IE3F32, IE3F28, IE3F26, IE3F24, IE3F23, IE3F20, IE3A32, IE3A28, IE3A26, IE3A24, IE3A23, IE3A20;
- Additional information response and High Risk Cargo & Mail screening response: IE3R02, IE3R03.
The files must be sent as attachments using the features of AS4 protocol and referred to in the IE3xx message using an identification element.
RULES AND CONDITIONS
The messages must conform to several rules and conditions, and to IT technical rules.
Message validation
All messages will be validated syntactically and semantically. The format of the messages and the rules and conditions to which the messages must conform to are defined in the ICS2 Information Exchange Specifications [R04].
IT Technical rules
Single message payload
It is not allowed to send bulk messages containing multiple information exchange messages as defined above. One message will include a single message payload, sent by a single Person filing (e.g. in the case of filing messages each message can only contain one ENS Filing).
Single message interface
All operations on an ENS filing must be sent over the same message channel (system-to-system or web user interface). This means it is not possible to send an ENS filing registration over the system-to-system interface and amend it over the web user interface.
An exception to this rule is the query of messages, a functionality provided in the web user interface as explained in 3.4.
Response and notification routing
The routing mechanism of replies and notifications to traders regarding a particular ENS submission (filing, amendment, invalidation or arrival notification) must identify the AS4 endpoint (Access Point of destination) and the channel (NTI, STI or UI) to be used.
The rules below will apply by order of priority:
- If the message is the initial reply to an ENS Filing or Arrival Notification, it will be addressed to the access point used by the person that submitted this ENS Filing or Arrival Notification following the channel of reception of the initial submission;
- If the message, having an MRN as subject, is addressed to the person that obtained the given MRN via a TI in a previous filing (ENS Filing or Arrival Notification), it will be addressed to the access point used by this person for that previous filing following the channel of the message attributing the MRN;
-
If the message, having a given MRN in its content, is addressed to EOs other than the person filing (to which the given MRN is attributed) and:
- If this economic operator has recorded a preference in the TI system (channel) used for the incoming messages, the notification is sent to the access point registered in the preference;
- If the EO has not recorded a preference, he is considered as not connected to the system and hence the notification is not sent.
Independent of the above routing rules, some messages will also be shown in the EUCTP dashboard for information only, even if the routing rules will send the messages to the correct access point for further processing. The EUCTP is the EU customs trader portal and is a user interface which contains a generic notification list relative to several customs procedures and authorisations, including ICS2 procedures. In this notification list the following messages will be shown for information only:
- IE3Q01 (Do Not Load request);
- IE3Q02 (Additional information request);
- IE3Q03 (High Risk Cargo & Mail screening request).
Selection of ICS2 Trader Interface
Each Member State has a single associated ICS2 Trader Interface. Either this is the ICS2 Shared Trader Interface (STI) or the National Trader Interface (NTI) of this Member State. For each filing delivered by a Sender access point used by the EO, the trader interface of the Member State that is addressed in the filing must be used.
This Sender access point must connect to the relevant Trader Interface system (National or Shared) according to the location of the Customs Office of First Entry (COFE) or (if unknown) to the Member State to which the ENS Filing will be addressed.
Support for multiple message versions
A Trader Interface (TI) must support two distinct versions of any specified message. This in order to guarantee the flexible evolution of the TI and the specified messages in particular (section
Priority messages
EO systems, DG TAXUD and Member States will size their infrastructure to meet the performance requirements of ICS2 operations. It might happen though that messages start to be buffered in exceptional circumstances such as:
- unexpectedly high peak of messages;
- unexpected downtime of a given service (either the EO system or the ICS2 TI).
In such circumstances, an internal mechanism to prioritise messages is implemented by ICS2 in order to handle specific messages with higher priority according to their message type. It is recommended that a similar operational mechanism may also be implemented by EO systems, at least by those impacted by larger volumes.
The messages in ICS2 have been categorised in three different categories taking into account the mode of transport, the state which a given business process has obtained and its urgency of information exchanges with regard to the potential process disruption and the consequent practical damage this may have for traders and administration. The categories are defined as follows:
- Category A – high priority: messages required to ensure the timely application of measures already decided by the customs authorities. Messages to trade to avoid business damage are also in this category;
- Category B – normal priority: messages required for a proper execution of the given business process regarding the process' time sequence and constraints;
- Category C – low priority: messages which are notifications for information and transparency reasons only.
This table defines the category for all ICS2 messages. The messages IE3R03 (HRCM) and IE3N06 (Arrival notification) are high priority messages sent by the EO systems. In case of temporary system unavailability, it is recommended that those messages are sent prior to other messages.
- IE3Q01 Do Not Load Request — Category A : X
- IE3Q03 High Risk Cargo & Mail screening request — Category A : X
- IE3R03 High Risk Cargo & Mail screening response — Category A : X
- IE3N03 Assessment Complete notification — Category A : X
- IE3N06 Arrival Notification — Category A : X
- IE3N08 Control notification — Category A : X
- IE3Fxx ENS Filing — Category B : X
- IE3Axx Amend ENS — Category B : X
- IE3Q02 Additional Information request — Category B : X
- IE3R01 ENS Registration Response — Category B : X
- IE3R02 Additional Information Response — Category B : X
- IE3R04 Arrival Registration Response — Category B : X
- IE3R08 ENS Consultation results — Category B : X
- IE3N01 ENS lifecycle validation error notification — Category B : X
- IE3N99 Notify Error — Category B : X
- IE3Q04 Invalidation Request — Category C : X
- IE3Q05 Consult ENS — Category C : X
- IE3R07 Invalidation Acceptance Response — Category C : X
- IE3N02 ENS Not complete notification — Category C : X
- IE3N04 Additional Information Request notification — Category C : X
- IE3N05 High Risk Cargo & Mail screening request notification — Category C : X
- IE3N07 ENS In Incorrect State notification — Category C : X
- IE3N09 AEO Control notification — Category C : X
- IE3N10 Amendment notification — Category C : X
Table 7: Message prioritisation
TRADER PORTAL INTERACTION
The current document describes the system to system interaction between economic operator systems and the ICS2 system. Next to this a trader portal module is being developed as part of ICS2 release 2 that provides a web user interface for the economic operator users inside the EU Customs Trader Portal (EUCTP).
An Economic Operator (be it a declarant or customs representative) can log into to EUCTP portal and search for any message exchanged between himself and the ICS2 STI. In addition, he can optionally receive Do Not Load, Additional Information Requests and High Risk Cargo & Screening Request notifications in the EUCTP notification panel8.
IT Service Providers will not be able to use the above functionality in name of its clients.
Source : https://mgi-team.atlassian.net/wiki/spaces/DOCI5/pages/3307536393