Emplacement : Documentation ICS2 > Interface Control Document

ENROLMENT AND OPERATION

This chapter presents the prerequisites and procedures the different actors need to fulfil to be able to deliver/receive an ENS Filing (or other relevant) message via the STI/NTI.

Establishing an Access Point by Trade

An Access Point is a technical gateway used for the exchange of messages with an ICS2 Trader Interface (TI).

In order to be able to establish an Access Point to exchange messages with a TI the EO or IT Service Provider17 should:

Implement the Access Point according to HTI specifications and the use of the specified eDelivery AS4 profile (both described in this document);
Obtain a TLS certificate from a trusted CA to be used at the transport layer (https) for identifying itself following the 2-way TLS security mechanisms. A Trusted CA in the TLS context can be a commercial CA trusted by DG TAXUD. The CA used needs to be notified to DG TAXUD, but the certificate does not require registration;
Obtain a certificate from a trusted CA to be used for sealing at message layer (according to the AS4 specifications). A Trusted CA in the context of message sealing is any CA trusted by the Customs Authorities of any Member State. Any certificate in the LOTL lists18 can be used. Exceptionally, additional certificate authorities might be accepted for registration on certain MS;
Register with the Customs Authorities as a system actor of ICS2, as documented in the UUM&DS registration guidelines ([R15]) for centrally managed identities. For non- centrally managed identities, the National Customs Helpdesk should be contacted. The process includes the upload of the public key of the certificate that will be used for message sealing (to be later accessed for authorisation purposes) and the need of conformance test environment certificates;
Inform the TES helpdesk on the intention to implement a given access point to exchange ENS messages with the STI and each NTI and specify the physical address (URL) except when using the One-Way/Pull MEP for the reception of notifications, the partyID (including the EORI), the CA to be used for TLS encryption certificate and the desired mode of communication (Pull or Push). In a later release this will be implemented as a self- registration mechanism in the STI/NTI preferences section. To perform this step the trader is authenticated using UUM&DS;
Pass the connectivity and conformance test of the Access Point for compliance with the HTI specifications. The specific steps are provided in the conformance test documentation [R14].

Any given economic operator can implement and use as many Access Points as necessary. It is allowed to have multiple partyID's defined. This allows for the party to have/use multiple AS4 Access Points depending on the business domain or geographical region.

Considering that the registration of each EO System certificate is done in the corresponding National UUM&DS application, the successful certificate registration may only be verified by the EO itself. Nevertheless, the successful certificate registration is a precondition for the execution of all EO functional test cases. This means that, in case that the certificate was not correctly registered, ICS2 will return the EBMS:0004 exception with subcode: A001 to the EO and will not allow any further EO message exchange.

Preparing and sending a Message by Trade

Having determined the Access Point through which the message will be sent,

The ENS filing (or other) functional message is formed according to ICS2 message specifications ([R06]);
This functional message is then embedded as a payload in the AS4 message which on its own complies with the ICS2 HTI Technical Specifications as described in this section;
The AS4 message is then sealed at the message layer using the appropriate certificate19;
Subsequently, this sealed and encrypted AS4 message is sent to the TI via https using the 2-way TLS (at transport layer).

SELECTING AN ICS2 TRADER INTERFACE

Each Member State has a Trader interface (TI). This can be a national operated National Trader Interface (NTI) or the Shared Trader Interface (STI). When sending an ICS2 message, a trader must select the correct MSH protocol address (URL) of the TI of the addressed Member State according to the IT technical rules defined in section https://mgi-team.atlassian.net/wiki/spaces/DOCI5/pages/3307536393/3.+Functional+information+exchange+specifications#Selection-of-ICS2-Trader-Interface .

The list of MSH protocol addresses per ICS2 trader interfaces (STI and NTIs) and their public keys of the certificate that will be used for message sealing will be defined here in a later version of this document.

PREFERENCES FOR NOTIFICATIONS

Optionally a trader can register his notification preferences by contacting the TES helpdesk.20 The types of preferences are:

The PartyId of the default access point (see section https://mgi-team.atlassian.net/wiki/spaces/DOCI5/pages/3347120133/4.+TECHNICAL+INFORMATION+EXCHANGE+SPECIFICATIONS#MESSAGE-ROUTING on routing);
The request to receive some type of notifications (see the ICS2 Business Process Description [R02] for more information), for instance a Person filing can request to receive 'ENS not complete' notification messages IE3N02.

REFERENCE DATA

The code lists needed to create the ICS2 messages, as well as the customs office codes, together with other reference data used for semantic validation, will be published on the Europa web pages. The following are the different reference data domains for which publications are provided.

CS/RD2 IT application

Non-confidential ICS2 code lists to be used by the traders will be published on the Europa website (DDS2).

CRS IT application

The EORI data used by the ICS2 system is published on the DDS2 EORI module. It is accessible to traders both

using a web UI: http://ec.europa.eu/taxation_customs/dds2/eos/eori_validation.jsp;
using a web interface for S2S interaction: Its WSDL file can be obtained here: http://ec.europa.eu/taxation_customs/dds2/eos/validation/services/validation?wsdl.

TARIC3 IT application

The TARIC data used by the ICS2 system is published on the DDS2 TARIC UI module. It is accessible to traders both:

using a web UI: http://ec.europa.eu/taxation_customs/dds2/taric/taric_consultation.jsp ;
downloading monthly updates in Excel format on the CIRCABC website. Traders can subscribe ad hoc to changes by a mail to TAXUD-dds-TARIC@ec.europa.eu.

ECICS2 IT application

The CUS data used by the ICS2 system is published on the DDS2 ECICS UI module. It is accessible to traders:

using a web UI: http://ec.europa.eu/taxation_customs/dds2/ecics/chemicalsubstance_consultation.jsp

TESTING

The organisation of the trader conformance testing can be found in the Conformance Test Organization for EO document ([R16]).

OPERATIONAL SERVICE LEVEL

The ICS2 TI will be available 24 hours per day, 365 days per year (24x365). In case of a system failure a fall-back procedure will need to be defined according to Art. 6 (3) (b) UCC. This fall- back procedure will be specified in the ICS2 business continuity plan which will provide the different measures to be taken for business continuity for the ICS2 overall system and for the ICS2 TI in particular.

Downtime due to maintenance activities and the deployment of a new application version will be avoided to the maximal extent possible by following the zero-downtime principle. Any other maintenance activity where this principle cannot be achieved will take place in an allocated service window of maximum 1 hour per week and will be planned and announced sufficiently in advance.

Outside the maintenance window, the target availability of the ICS2 TI will be of 99,25% for STI Release 1 and 99.45% from STI Release 2 onwards.

TES helpdesk support information will be provided in TES helpdesk related documentation.

CHANGE MANAGEMENT

The ICS2 TI will be able to support two versions of an ENS filing and of ENS notifications, the most recent and a previous version. A reporting party may only use one version. The ability to support two versions of a declaration is needed to ensure a smooth transition by a change in a declaration.

The version of the messages used is defined in the eb:AgreementRef.

The first version is EU-ICS2-TI-V1.0 implementing the corresponding message specifications as defined in [R04] and [R06] for Release 1.
The second version is EU-ICS2-TI-V2.0 implementing the corresponding message specifications as defined in [R04] and [R06] for Release 2 and Release 3.

Notes

17 In the case of IT Service Providers, the registration in Customs imply also obtaining an EORI number. Although ITSPs are not EOs obliged to obtain an EORI number, the use of this code for system authorisation purposes was considered the most pragmatic and simple solution (as was confirmed in the context of the STI project Group).
18 List of trusted lists as can be found here: https://webgate.ec.europa.eu/tl-browser/#/.
19 Pull requests must also be sealed to ensure the party authorization to request the messages pull.
20 In a later release the trader will be able to manage its notification preferences by a web user interface (STI/NTI UI).

Source : https://mgi-team.atlassian.net/wiki/spaces/DOCI5/pages/3347873845

5. OPERATIONAL