DDUEA VER: 1.2

ISSUE DATE:24/09/18

VERSION:1.2

DESIGN DOCUMENT FOR THE UK EXCISE APPLICATION

(DDUEA)

Page 1 of 30

DDUEA VER: 1.2

Document History

Version Date Description

0.1 13/08/18 First Draft

0.2 15/08/18 Internal review of v0.1

0.3 30/08/18 Updated to v1.0

1.1 04/09/2018 Internal review of v1.0

1.2 07/09/2018 Addition of Section IV

Page 2 of 30

DDUEA VER: 1.2

Table of Contents

Document History.....................................................................................................................2Table of Contents.....................................................................................................................3

Section I: General Information.................................................................................................5I.I.1 Background...................................................................................................................5

I.I.2 Design Document for the UK Excise Application (DDUEA)..........................................5I.I.3 Terminology...................................................................................................................6

I.I.4 Acronyms and Abbreviations.........................................................................................6Section II: Scope of Changes...................................................................................................9

II.I.1 Summary of changes:...................................................................................................9Section III: Technical Message Structure...............................................................................14

III.I.1 Introduction................................................................................................................14III.I.2 Data Items.................................................................................................................14

III.I.3 Data Groups..............................................................................................................14III.I.4 Codelists....................................................................................................................14

III.I.5 Technical Message Structure....................................................................................15III.I.6 Common Message Header........................................................................................16

Section IV: Core Business Scenarios....................................................................................18Sub-Section IV.I Central Circuit Scenarios.........................................................................18

IV.I.1 Submission and Registration of an e-AD...............................................................18IV.I.2 Alert or Rejection of an e-AD.................................................................................18

IV.I.3 Cancellation of an e-AD by the Consignor............................................................19IV.I.4 Submission of Report of Receipt...........................................................................20

IV.I.5 Change of Destination...........................................................................................21IV.I.6 Reminder at expiry of time limit for Report of Receipt...........................................23

IV.I.7 Reminder at expiry time for Change of Destination...............................................24IV.I.8 Post-delivery processing.......................................................................................24

Sub-Section IV.II Export Scenarios....................................................................................25IV.II.1 Export Operation at Office of Export.....................................................................25

IV.II.2 Export Operation at Office of Export followed by Export Confirmation of Exit......26IV.II.3 Export Operation at Office of Export followed by Export Cancellation of Exit......26

IV.II.4 Export Operation at Office of Export followed by Export Declaration Cancellation and Change of Destination.............................................................................................27

Appendix A: Business Rule Catalogue..................................................................................28Appendix B: Technical Codelists............................................................................................28

Appendix C: Business Codelists............................................................................................28

Page 3 of 30

DDUEA VER: 1.2

Appendix D: Technical Message Structure............................................................................28

Appendix E: XML Mapping.....................................................................................................28Appendix F: Directory with XML Schemas (XSDs)................................................................28

Page 4 of 30

DDUEA VER: 1.2

Section I: General Information

I.I.1 Background

On 29th March 2019 the United Kingdom will leave the European Union. The Government has set out its proposals to establish a new relationship with the European Union which will form the basis of negotiations with the EU.

The government is confident that we can agree a deep and special partnership with the EU, however a responsible Government also needs to prepare for a range of outcomes from these negotiations, including the unlikely scenario of a no-deal EU exit. The Government has therefore made preparations to ensure the United Kingdom can operate an effective excise regime if we leave the EU without a deal.

The existing EU excise regime already controls the movements of goods to and from non-EU countries. It is the intention to apply these ‘third country’ arrangements to trade with the European Union. To this end, the attached technical documents set out the system changes required to remove all EU functionality, but retain the procedures that will manage all international trade.

The Excise Movement Control System (EMCS) will therefore control movements within the territory of the United Kingdom, for example:

From one UK excise warehouse to another From a place of importation in the UK to a UK excise warehouse From a UK excise warehouse to a place where the goods will leave the UK

When goods arrive at the UK border from the EU, they will be controlled through the customs import declaration process and by an excise registered consignor. When goods are dispatched from a UK excise warehouse to the EU, the Customs export declaration will form the basis of the record of receipt.

I.I.2 Design Document for the UK Excise Application (DDUEA)

To support software developers in delivering the required changes for a no deal scenario HMRC have produced this Design Document for the UK Excise Application (DDUEA). This new document is based on the format of the existing EU Design Document for National Excise Applications (DDNEA) and the Functional Excise System Specification (FESS). To simplify the format and to take into account the specific information required for this change, the DDNEA and the FESS have been merged into this single DDUEA.

The original EU commission documents are still available on the GOV.UK website to provide further background and information:

https://www.gov.uk/government/publications/emcs-functional-stage-31-fs31-technical-specifications

Page 5 of 30

DDUEA VER: 1.2

Page 6 of 30

DDUEA VER: 1.2

I.I.3 Terminology

A number of terms are used with a very specific meaning in this document:

Name DescriptionCodelist A set of discrete values. Some Data Items can only contain a

value chosen from a set of discrete values, in which case they will have an associated Codelist.

Data Group A Data Group is a part of the Technical Message Structure; it groups Data Items related to the same subject and it is denoted by a Data Group name.

Data Item A Data Item is an elementary (atomic) piece of information; part of a Data Group.

Functional Message Structure (FMS)

Logical data structure of an Information Exchange, as defined in this DDUEA.

Information Exchange A logical exchange of information between two locations. An Information Exchange is the conceptual exchange of information between two organisations, independent of its physical means.

Location A place where the excise business is performed. Message formatting Representation (of a Technical Message Structure) in or

mapping to exchange syntax (e.g. XML).Message transport The sending (and reception) of a formatted message across a

communications platform Organisation An organisation is a number of individuals acting in a concerned

way towards a common business purpose with allocated roles and responsibilities. An organisation can have one or more roles of a specific type.

Reference Data A collection of discrete data, maintained by the SEED application and that can be sent to a NEA as an IE734. Although this term is sometimes used in order to denote any data maintained by SEED, DDUEA will use it in the narrow sense defined above.

Technical Message Structure (TMS)

The data structure of the Information Exchange as it needs to be implemented. A TMS is a structure (and hierarchy) of Data Groups.

I.I.4 Acronyms and Abbreviations

The following acronyms and Abbreviations are used in this document:

Acronym Description

AD Administrative Document

API Application Programming Interface

Page 7 of 30

DDUEA VER: 1.2

Acronym Description

ARC Administrative Reference Code

BCC Business Communication Channels

CoA Confirm on Arrival

CoD Confirm on Delivery

CONTRL Syntax and service report XML message

CTA Conformance Testing Application

DDNEA Design Document for National Excise Applications

DDUEA Design Document for the United Kingdom Excise Application

DTD Document Type Definition

ECP Excise Computerisation Project

ELO Excise Liaison Office

EMCS Excise Movement and Control System

EXC Exception Report

EXP Expiration Report

FESS Functional Excise System Specification

FMS Functional Message Structure

FRS Fallback and Recovery Specification

FS Functional Stage

GLT Glossary of Terms

GMT Greenwich Mean Time

GSS Generic Security Services

GUI Graphical User Interface

HTML HyperText Markup Language

HTTP HyperText Transfer Protocol

HTTPS HTTP over SSL

IE Information Exchange

ISO International Standards Organisation

IT Information Technology

KEL Known Error List

LRN Local Reference Number

LSO Local Security Officer

MD5 Message Digest 5

MIME Multipurpose Internet Mail Extensions

NCTS New Computerised Transit System

Page 8 of 30

DDUEA VER: 1.2

Acronym Description

NDEA Nationally Developed Excise Application

NEA National Excise Application

PRO Permanent Registered Operator

PSS Phasing and Scope Specification

QoS Quality of Service

RD Reference Data

RoR Report of Receipt

SAM Single Administrative Message

SD Scope Document

SEED System for Exchange of Excise Data

SEP Security Policy

SESS Security Excise System Specification

SGML Standard Generalised Markup Language

SMTP Simple Mail Transfer Protocol

SRO System Requirements Overview

SSL Secure Socket Layer

STD State Transition Diagram

TA Test Application

TC Technical Centre

TCP/IP Transmission Control Protocol / Internet Protocol

TESS Technical Excise System Specification

TMS Technical Message Structure

TSD Time Sequence Diagram

UC Use Case

UML Unified Modelling Language

URI Universal Resource Identifier

UTF UCS Transformation Format

VAT Value Added Tax

WS Web Service

WWW World Wide Web

XML Extensible Markup Language

XSD XML Schema Definition

Page 9 of 30

DDUEA VER: 1.2

Section II: Scope of Changes

This section provides an overview of the scope of changes to UK EMCS.

Following EU-exit it will be necessary to make a number of changes to the way in which excise suspense movements are managed in the UK EMCS. One of the primary drivers when scoping these changes has been to minimise the degree of change to traders and their systems.

At a high level the changes to EMCS will be as follows:

No overall increase or decrease in the number of excise suspense movements in-volving the UK is anticipated following EU-exit

Excise suspense movements between authorised locations in the UK will continue to be managed in EMCS as they are today

Imports and exports of the excise suspense goods, between the UK and non-EU countries will continue to be managed in EMCS as they are today

The management of excise suspense movements between authorised excise loca-tions in the UK and those in the EU using EMCS will cease. These movements will instead be managed by EMCS in the same way as imports from or exports to non-EU countries

Splitting functionality is no longer required for UK EMCS

The overall architecture of EMCS remains the same, however, these changes will necessitate a number of revisions to the EMCS reference data, business rules and message types, which will result in amendments to existing message validations in EMCS.

II.I.1 Summary of changes:

Name Description of change

Movement Type The only allowable values for ‘Movement Type’ will be:

UK to UK

Imports for UK

Export with customs declaration lodged in the UK

Import for export with customs declaration lodged in the UK

Destination Type The only allowable values for ‘Destination Type Code’ will be:

1 = Destination - Tax warehouse

Page 10 of 30

DDUEA VER: 1.2

6 = Destination - Export

Guarantor Type The only allowable values of ‘Guarantor Type Code’ will be:

0 = Guarantor not required (qualifying UK to UK movements)

1 = Consignor

2 = Transporter

3 = Owner of the Excise products

4 = Consignee

Member State Code The only allowable value for ‘Member State Code’ will be "GB"

Office Reference Number The only allowable values for ‘Office Reference Number’ in the Customs Office List (COL) will be those offices located in the UK

Status Type The only allowable values of ‘Status Type Code’ will be:

X01 = Accepted

X02 = Cancelled

X03 = Delivered

X04 = Diverted

X05 = Rejected

X07 = e-AD Manually Closed

X08 = Refused

X09 = None

X10 = Partially Refused

X11 = Exporting

X12 = Accepted for Export

X13 = Stopped

Trader Type The only allowable value of ‘Trader Type

Page 11 of 30

DDUEA VER: 1.2

Value’ will be:

UK Record

Transport Mode Code The only allowable values of ‘Transport Mode Code’ will be:

0 = Other

1 = Sea Transport

2 = Rail Transport

3 = Road Transport

4 = Air Transport

5 = Postal Consignment

8 = Inland Waterway Transport

Transport Unit Code The only allowable values of ‘Transport Unit Code’ will be:

1 = Container

2 = Vehicle

3 =Trailer

4 = Tractor

Notification Type The only allowable values of ‘Notification Type Code’ will be:

1 = Change of destination

Changed Destination Type The only allowable values of ‘Changed Destination Type Code’ will be:

1 = Destination - Tax warehouse

6 = Destination – Export

Messages Types The only relevant Message Types will be:

IE704 - Generic Refusal Message

IE717 - Control Report

IE734 - Operations On The Reference Database

Page 12 of 30

DDUEA VER: 1.2

IE801 - E-AD

IE802 - Reminder Message For Excise Movement

IE803 - Notification Of Diverted E-AD

IE807 - Interruption Of Movement

IE810 - Cancellation Of An E-AD

IE813 - Change Of Destination

IE815 - Submitted Draft Of E-AD

IE818 - Accepted Or Rejected Report Of Receipt/Export

IE819 - Alert Or Rejection Of An E-AD

IE829 - Notification Of Accepted Export

IE837 - Explanation On Delay For Delivery

IE839 - Customs Rejection Of E-AD

IE840 - Event Report

IE871 - Explanation On Reason For Shortage

IE905 - Status Response (only used for manual closure)

Degree Plato The field of ‘Degree Plato’, whilst maintained in the XML structure, has been prohibited and is not to be used

tcl.xml The following changes have been made to the tcl.xml file:

1) Values for Guarantor Type Code are restricted to: 0 (UK specific); 1; 2; 3; 4

2) Values for Destination Type Code are restricted to 1 and 6

3) Values for Changed Destination Type Code are restricted to 1 and 6

Page 13 of 30

DDUEA VER: 1.2

Page 14 of 30

DDUEA VER: 1.2

Section III: Technical Message Structure

III.I.1 Introduction

In this section the basic elements of the EMCS Technical Message Structure, namely Data Groups, Data Items and Codelists, are described.

III.I.2 Data Items

Every Data Item is identified by a unique name and has an associated type (as defined in DDNEA v1.92 Section Error: Reference source not found Error: Reference source notfound). In some cases a Data Item can have only discrete values, in which case the Data Item is said to have an associated Codelist.

III.I.3 Data Groups

Every Data Group consists of a number of Data Items in a particular order. Every message is composed of a certain number of Data Groups in a particular hierarchy. Every Data Group is identified by a name. To be noted is that group names are not unique. It may thus very well happen that the same group name is found in different messages. Moreover, Data Groups with the same name do not always include the same Data Items. Hence, when a Data Group is used in more than one place including different Data Items each time, then this Data Group should be assigned to all of these Data Items even if not all of the Data Items are used in every instance.

Later on, with the message definition, the Data Items which are to be included for a particular group or not are specified.

Every Data Item within a group also has a unique identifier. The unique identifiers have been chosen more or less arbitrarily.

To be noted is that some Data Groups may not always have the same Data Item sequence in different messages.

Later on, with the message definition, the exact sequence of data elements in a particular group is specified.

III.I.4 Codelists

A Codelist is a set of discrete values, with an associated meaning.

A name and a number identify Codelists.

There are a number of Technical Codelists for which the values are predefined and fixed. These values are not maintained within the common Reference Data. These Codelists are marked as Technical Codelists in Error: Reference source not found.

Page 15 of 30

DDUEA VER: 1.2

To maintain backwards compatibility with the tcl.xml, a number of Technical Codelists which relate to decommissioned message types have been retained. These Codelists are not to be used, and the details of which are in Appendix B.

In addition, there are a number of Codelists for which the values are business dependent, hence mutable. These Codelists are known as Business Codelists. The values of the Business Codelists can be found in Appendix C.

To maintain backwards compatibility with the IE734 message, a number of Business Codelists which relate to decommissioned message types have been retained. These Codelists are not to be used, and the details of which are in Appendix C.

III.I.5 Technical Message Structure

The structure and format of the different Information Exchanges are included in the corresponding Error: Reference source not found. These appendices contain a message format description for every Information Exchange that is part of the particular system.

The technical message description is supplied in two parts.

The first part is the overall message description. This description contains the overall layout of the messages. It defines the different Data Groups that are part of the message, the sequence of the groups, the level of hierarchy of the Data Groups, the optionality of the Data Group, the possible repeat count, and associated rules and conditions. Concerning the optionality, it should be noted that the following rules apply:

If a Data Group is always required, it is marked as “R”;

If there exist one or more conditions related to the presence of the Data Group, it is marked as ‘D’. When a condition indicates that a dependent Data Group “does not apply” in a specified case then the specific Data Group must not be present in the message structure;

If a Data Group is not always required and there are no conditions related to its presence, it is marked as ‘O’, meaning that the Data Group may either be present in the message structure or not. However, if information is available it is recommended to be included in the message despite the fact that this Data Group is characterised as Optional.

In order to go down one level in the hierarchy, the Data Group at the higher level in the hierarchy needs to be present. The second part of the TMS contains the description of the different Data Items. This description includes the sequence of the data elements in the group, the optionality, and the associated rules and conditions.

Concerning the optionality of the Data Items, the following rules apply:

If a Data Item is always required, it is marked as “R”;

Page 16 of 30

DDUEA VER: 1.2

If there exist one or more conditions related to the presence of the Data Item, it is marked as ‘D’. When a condition indicates that a dependent Data Item “does not apply” in a specified case, then the specific Data Item must not be present in the message structure. It shall be noted that a Data Item set to “NULL” (empty valued) is still present in the message structure. Hence, when a Data Item is marked as “does not apply” in a specific case, the generated messages shall not include it with a “NULL” value. Subsequently, when all Data Items of a Data Group are set to “NULL”, the Data Group is still present in the message structure. Hence, when a Data Group is marked as “does not apply” in a specific case, it shall not be present in the generated messages with all of its Data Items set to “NULL”.

If there are no conditions related to the presence of a particular Data Item, it is marked as ‘O’, meaning that the Data Group may either be present in the message structure or not. However, if information is available it is recommended to be included in the message despite the fact that this Data Group is characterised as optional.

The message description part of this document consists of message hierarchies and correlation tables in order to map the Information Exchanges to those hierarchies (XML).

The optionality codes used for the Data Groups and Data Items in the DDUEA is shown below:

Status description Status codeRequired/mandatory ROptional ODependent D

The abbreviations stand for Required, Optional, Conditional/Dependent. The DDUEA optionality codes are used in the TMS of Error: Reference source not found.

III.I.6 Common Message Header

Each message is an envelope encapsulating a “Common Message Header” and a “Body” component.

The “Common Message Header" is commonly defined for all the messages and consists of the following Data Items:

Message sender and Message recipient: The Data Items "Message sender" and "Message recipient" are both “Required” and should contain, respectively, the address of the sender and recipient, defined as:

<Application Name>.<Member State Code>, where:

<Application Name> equals the value “NDEA”;

<Member State Code> equals the value “GB”

Page 17 of 30

DDUEA VER: 1.2

Date of preparation: This is a “Required” Data Item used for the date that the Information Exchange was put into XML representation (generation of the XML message);

Time of preparation: This is a “Required” Data Item used for the exact time that the Information Exchange was put into XML representation (generation of the XML message);

Message identifier: This is a “Required” Data Item generated by the sending application to uniquely identify the information exchange;

Correlation identifier: This is a “Dependent” Data Item, since it is only “Required” for correlating the response and refusal messages. It does not apply for requests and one-way messages.

The “Body” contains the actual business message. It is separately defined for each of the messages and consists of the rest of the elements comprising the business content of the messages.

Page 18 of 30

DDUEA VER: 1.2

Section IV: Core Business Scenarios

The following section contains a detailed specification of the message exchange protocols to be foreseen for the EMCS Core Business area in EMCS. All the scenarios described below assume successful validation of messages submitted to the EMCS application.

In the case of validation failure(s) please refer to Core UK EMCS and ChRIS UK EMCS Error Message Catalogues.

Sub-Section IV.I Central Circuit Scenarios

This section aims to specify the most important message exchange protocols for EMCS. All scenarios begin essentially with the consignor submitting a draft e-AD (IE815: N_EAD_SUB) to the EMCS application. It should be noted that although the submission occurs before the actual dispatch of goods, if the e-AD is submitted in deferred mode, then the actual dispatch of goods would have preceded the draft e-AD submission.

Within the context of the EMCS, the e-AD is a message containing information about the consignment; namely the origin, the destination, the Economic Operators that are involved in the movement and the product codes along with their quantities being moved.

The consignment can only initiate from a tax warehouse or from a place of import. The destination type of an e-AD may be outside the UK, in which case the scenarios for the exportation of goods are described in Sub-Section IV.II Export Scenarios.

IV.I.1 Submission and Registration of an e-AD

According to this scenario, the Consignor submits a draft e-AD (IE815: N_EAD_SUB) to the EMCS application. The origin of the movement is either a tax warehouse or place of import and the destination of the movement is known (i.e. the destination is not unknown nor it is for export).

The EMCS application, upon receiving the draft e-AD performs the relevant validations, which pass successfully, assigns an ARC to the e-AD (the structure of ARC and the Check Digit algorithm are defined in DDUEA Appendix C), creates a validated e-AD (IE801: C_EAD_VAL) with sequence number “1” and makes it available to both the Consignor and Consignee.

Finally, the movement is created on the EMCS application, the status is set to “Accepted” and the timer TIM_EAD is initiated to expire at the expected end of movement (i.e. date of dispatch plus journey time).

IV.I.2 Alert or Rejection of an e-AD

Page 19 of 30

DDUEA VER: 1.2

The Consignee may submit an alert or rejection (IE819: C_REJ_DAT) before the goods arrive at the destination to notify the involved actors. Both the scenarios of this section require the state of the concerned e-AD to be in the “Accepted” state.

The successful completion of the scenarios in this section cause state transition for the concerned e-AD to remain as “Accepted” when the Consignee submits an alert, or “Rejected” when the Consignee rejects the e-AD.

IV.I.2.1 e-AD Alerted

According to this scenario, the Consignee submits an alert (IE819: C_REJ_DAT) to the EMCS application, providing the ARC and the last sequence number of the movement that they alert, which is in the “Accepted” state.

The EMCS application upon receiving the alert (IE819: C_REJ_DAT) performs the relevant validations, which pass successfully, stores the message and makes it available to the Consignor and to the submitting Consignee as a confirmation.

The EMCS application does not alter the state of the concerned e-AD.

IV.I.2.2 e-AD Rejected

According to this scenario, the Consignee submits a rejection (IE819: C_REJ_DAT) to the EMCS application, providing the ARC of the movement and the last sequence number that they reject, which is in the “Accepted” state.

The EMCS application upon receiving the rejection (IE819: C_REJ_DAT) performs the relevant validations, which pass successfully, stores the message, makes it available to the Consignor and to the submitting Consignee as a confirmation, and sets the state of the e-AD to “Rejected”.

Please note that the “Rejected” state is not a final state: the Consignor is expected to change the e-AD destination or cancel the e-AD as a response to the rejection (as long as the consignment has NOT left the Place of Dispatch). The EMCS application initiates the TIM_CHS timer, which once elapsed, will send a reminder to the Consignor.

The expected actions from the Consignor and the timer TIM_CHS expiration are described in Section IV.I.7 Reminder at expiry time for Change of Destination.

IV.I.3 Cancellation of an e-AD by the Consignor

If a consignment has NOT left the Place of Dispatch, the Consignor may submit an e-AD cancellation. A consignment is considered to have left the Place of Dispatch in the following cases:

The Consignor has issued at least one change of destination (IE813) for the e-AD;

The e-AD has been submitted in deferred mode; electronic recovery of fallback AD may only occur after the physical dispatch of the goods;

Page 20 of 30

DDUEA VER: 1.2

The e-AD is in the “Exporting” state and the export operations has taken place at the Office of Export.

Any time before the actual dispatch of goods, the Consignor may send a cancellation message (IE810: C_CAN_DAT) to the EMCS application concerning an e-AD in the “Accepted” or “Rejected” or “Exporting” state.

The EMCS application receives the draft e-AD cancellation (IE810: C_CAN_DAT). Upon successful validation of the incoming message, the EMCS application stores the message, updates the state of the e-AD to “Cancelled”, and makes the message available to the Consignee and to the submitting Consignor as a confirmation.

Finally, if the TIM_EAD timer has not expired, the EMCS application stops it.

IV.I.4 Submission of Report of Receipt

When the goods arrive at their destination, the Consignee acknowledges the receipt of goods by submitting a Report of Receipt (RoR) (IE818: C_DEL_DAT) to notify the involved actors. The Consignee includes in the draft Report of Receipt (IE818: C_DEL_DAT) the ARC and the last sequence number of the e-AD. The successful completion of the scenarios in this section cause state transition for the concerned e-AD to “Delivered”, “Refused”, or “Partially Refused”.

The scenarios of this section require the state of the concerned e-AD to be in the “Accepted” state or, in the case of export scenarios, the receipt of goods may occur when the e-AD is in the “Exporting” state. In which case, the scenarios for the exportation of goods apply described in Sub-Section IV.II Export Scenarios.

The different scenarios of this section are determined by the following value categories of the RoR conclusion:

Delivery Accepted (IV.I.4.1 Delivery Accepted);

Delivery Refused (IV.I.4.2 Delivery Refused);

Delivery Partially Refused (IV.I.4.3 Delivery Partially Refused).

Two additional value categories of the RoR conclusion are possible pertaining to the scenarios for the exportation of goods. These scenarios are not included in this section and are described in Sub-Section IV.II Export Scenarios.

IV.I.4.1 Delivery Accepted

According to this scenario, the Consignee submits a draft Report of Receipt (IE818: C_DEL_DAT) indicating delivery acceptance to the EMCS application. The EMCS application, upon receiving the Report of Receipt (IE818: C_DEL_DAT), performs the relevant validations, which pass successfully, stores the message, makes it available to the Consignor and to the submitting Consignee as a confirmation and changes the state of the e-AD to “Delivered”, which is a final state.

Finally, if the TIM_EAD timer has not expired, the EMCS application stops it.

Page 21 of 30

DDUEA VER: 1.2

IV.I.4.2 Delivery Refused

According to this scenario, the Consignee submits a draft Report of Receipt (IE818: C_DEL_DAT) indicating refusal of delivery to the EMCS application. The EMCS application, upon the reception of the refusal of delivery notification message (IE818: C_DEL_DAT), performs the relevant validations, which pass successfully, stores the message, makes it available to the Consignor and to the submitting Consignee as a confirmation, and changes the state of the e-AD to “Refused”.

Finally, the EMCS application starts the timer TIM_CHS, which once elapsed, will send a reminder to the Consignor.

Please note that the “Refused” state is not a final state, and the Consignor is expected to take actions so that the e-AD will reach a final state. The expected actions from the Consignor and the timer TIM_CHS expiration are described in Section IV.I.7 Reminder atexpiry time for Change of Destination.

IV.I.4.3 Delivery Partially Refused

According to this scenario, the Consignee submits a draft Report of Receipt (IE818: C_DEL_DAT) indicating partial refusal of delivery to the EMCS application. The EMCS application, upon the reception of the refusal of delivery notification message (IE818: C_DEL_DAT), performs the relevant validations, which pass successfully, stores the message, makes it available to the Consignor and to the submitting Consignee as a confirmation, and changes the state of the e-AD to “Partially Refused”.

Finally, the EMCS application starts the timer TIM_CHS, which once elapsed, will send a reminder to the Consignor.

Please note that the “Partially Refused” state is not a final state and the Consignor is expected to take actions so that the e-AD will reach a final state. The expected actions from the Consignor and the timer TIM_CHS expiration are described in Section IV.I.7 Reminder atexpiry time for Change of Destination.

IV.I.5 Change of Destination

The Consignor may change the destination of an e-AD. The successful completion of the scenarios in this section causes state transition for the concerned e-AD to “Accepted”. The new destination can be a tax warehouse or a place of export.

The scenarios below require the state of the concerned e-AD to be in the “Accepted”, “Refused”, “Partially Refused”, or “Rejected” state.

For export scenarios, described in Sub-Section IV.II Export Scenarios, the state of the concerned e-AD is required to be in the “Accepted” or “Exporting” state.

The different scenarios of this section are determined by the combinations of the former destination and the new destination:

Page 22 of 30

DDUEA VER: 1.2

The Consignee (and hence the place of delivery) changes (see Section IV.I.5.1Change of Consignee); or

The Consignee remains unchanged but the place of delivery changes (see Section IV.I.5.2 Change of Place of Delivery only).

Note: a particular case of the first scenario is where the Consignor changes the destination for return of goods, i.e. the new destination is the place of dispatch, which implies that both Consignee and Place of Delivery change.

IV.I.5.1 Change of Consignee

In this scenario, the Consignor initiates the change of destination process to change the Consignee (hence, the Place of Delivery as well) by submitting a draft update (IE813: C_UPD_DAT) to the EMCS application.

The EMCS application, upon receipt of the draft update message (IE813: C_UPD_DAT), performs the relevant validations, which pass successfully, includes the last sequence number of the ARC incremented by 1 (PreviousSeqNo + 1) in the validated update message (IE813: C_UPD_DAT), stores the message and makes it available to the Consignor as an acknowledgement.

Assuming that the draft update is valid, the EMCS application changes the state of the incremented e-AD to “Accepted” and the state of the previous e-AD version to “Diverted”.

In addition, the EMCS application creates an e-AD (IE801: C_EAD_VAL) message, which is made available to a) the new Consignee to notify them that they are the new Consignee of the consignment, and b) the Consignor as a confirmation.

That e-AD (IE801: C_EAD_VAL) message includes:

The ARC of the update message (IE813: C_UPD_DAT)1;

The sequence number of the e-AD which is incremented by 1 (PreviousSeqNo + 1);

The updated destination details (new Consignee and Place of Delivery), as declared in the update message (IE813: C_UPD_DAT).

In case the journey time has changed, the EMCS application updates the TIM_EAD timer if the expected end of the movement is still in the future.

Finally, the EMCS application creates a notification message (IE803: C_EAD_NOT) with the same sequence number as in the update message (IE813: C_UPD_DAT) and makes it available to the former Consignee to inform them that the consignment has changed destination.

IV.I.5.2 Change of Place of Delivery only

In this scenario the Consignor initiates the change of destination process to change the Place of Delivery only by submitting a draft update (IE813: C_UPD_DAT) for validation to the EMCS application.

1 Hence, the ARC is the same as in the original e-AD

Page 23 of 30

DDUEA VER: 1.2

This scenario is the same as describe in Section IV.I.5.1 Change of Consignee with the exception that, as there is no former Consignee, there is no requirement to generate a notification message (IE803: C_EAD_NOT).

IV.I.6 Reminder at expiry of time limit for Report of Receipt

It is expected that the Consignee acknowledges the receipt of goods by submitting a Report of Receipt (RoR) before the TIM_EAD timer expiration. The scenarios of this section require the state of the concerned e-AD to be in the “Accepted” state.

This section describes two sequential scenarios. The first scenario (Section IV.I.6.1Reminder triggered after the TIM_EAD timer expiration) describes the message protocol after the TIM_EAD timer expiration. The second scenario (Section IV.I.6.2 Submission ofexplanations on Delay for Delivery) describes the submission of explanations on delay for delivery, and is optional.

IV.I.6.1 Reminder triggered after the TIM_EAD timer expiration

When the TIM_EAD timer expires, the EMCS application generates a reminder/flagging message (IE802: C_EXC_REM) and makes it available to:

a) The Consignor as a notification of the RoR delay, and;

b) The Consignee as a reminder to take further action.

The scenario may optionally continue with the submission of explanations on delay for delivery by either the Consignor or the Consignee, which is described in Section IV.I.6.2Submission of explanations on Delay for Delivery, or alternatively, one of the following scenarios may follow:

The Consignor submits a late e-AD cancellation provided that the consignment has not left the Place of Dispatch, as described in Section IV.I.3 Cancellation of an e-ADby the ConsignorError: Reference source not found;

The Consignee sends the expected RoR, as described in Section IV.I.4 Submission ofReport of ReceiptError: Reference source not found;

The Consignor submits a change of destination, as described in Section IV.I.5Change of Destination.Error: Reference source not found

IV.I.6.2 Submission of explanations on Delay for Delivery

This scenario complements the previous scenario for sending a reminder message after expiry of the time limit for Report of Receipt (Section IV.I.6.1 Reminder triggered after theTIM_EAD timer expiration). According to the previous scenario, the Consignor, and optionally the Consignee, have been notified that the arrival of a consignment is late.

Page 24 of 30

DDUEA VER: 1.2

The Consignor and/or the Consignee may optionally submit an explanation of delay for delivery (IE837: C_DEL_EXP) to the EMCS application for a consignment having late delivery. Upon successful validation, the EMCS application stores the message and makes it available to both the Consignor and the Consignee. The e-AD status remains unchanged.

It is to be noted that when the Consignee has initiated this scenario the provision of explanations does not relieve the Consignee from their obligation to submit the RoR as soon as possible.

IV.I.7 Reminder at expiry time for Change of Destination

For cases when the delivery of a consignment has been refused or partially refused (as described in IV.I.4.2 Delivery Refused and IV.I.4.3 Delivery Partially Refused, respectively), or when the e-AD has been rejected by the Consignee (as described in IV.I.2.2 e-ADRejected), the EMCS application has already initiated the TIM_CHS timer. In all of the aforementioned cases the Consignor is expected to either:

Initiate the cancellation of an e-AD process as described in Section IV.I.3 Cancellationof an e-AD by the Consignor (as long as the consignment has NOT left the Place of Dispatch); or

Initiate the change of destination process as described in Section IV.I.5 Change ofDestination.

If either of the aforementioned processes are performed by the Consignor, the EMCS application will reset the TIM_CHS timer or stop it as described in the corresponding scenarios. If, however, none of the aforementioned processes are performed by the Consignor, the TIM_CHS timer will expire.

When the TIM_CHS timer expires, the EMCS application generates a reminder/flagging message (IE802: C_EXC_REM) and makes it available to the Consignor. This reminder will include the ARC of the e-AD that has been refused, partially refused or rejected, as well as the identity of the declared Consignee and the limit date by when the Consignor should respond.

IV.I.8 Post-delivery processing

When a consignment reaches its destination, the Consignee submits a Report of Receipt to notify the delivery to the involved actors, as described in Section IV.I.4 Submission of Reportof ReceiptError: Reference source not found. If the Report of Receipt declares shortages or excesses, then the Consignor and/or the Consignee may provide explanations by submitting a complementary explanations (IE871: C_SHR_EXP) message.

The submission of explanations is optional for both the Consignor and the Consignee and may occur several times by the same actors.

This section requires the Consignee having submitted a Report of Receipt describing shortages or excesses. In addition, the Consignor may submit complementary explanations after confirmation of exit of exported goods. At least one of the following scenarios must have been concluded:

Page 25 of 30

DDUEA VER: 1.2

Section Scenario Required StateIV.I.4.1 Delivery Accepted

Delivery AcceptedError: Reference source not found

e-AD status = “Delivered” and RoR Global Conclusion of Receipt = 2 (i.e. ‘Receipt accepted although unsatisfactory’)

IV.I.4.2 Delivery Refused

Delivery RefusedError: Reference source not found

e-AD status = “Refused”

IV.I.4.3 Delivery Partially Refused

Delivery Partially RefusedError: Reference source not found

e-AD status = “Partially Refused”

The Consignor and/or the Consignee submits the complementary explanations (IE871: C_SHR_EXP) message to the EMCS application for an e-AD for which shortages or excesses have been declared.

The EMCS application, upon receipt of the complementary explanations (IE871: C_SHR_EXP) message, performs validation, then if passed successfully, stores the message and makes it available to both the Consignor and the Consignee.

Sub-Section IV.II Export Scenarios

This section aims to specify all possible message exchange protocols involved in the export cases where the Consignor submits the e-AD to the EMCS application and the export declaration is submitted at the Office of Export.

It shall be noted that:

Any communication outside the scope of the EMCS application (such as, the information exchanged between the Consignor or forwarding agent and the Customs Export Application) is not included in this document.

The scenarios in this section are initiated by either:

a) The Consignor who submits a draft e-AD (IE815: N_EAD_SUB) to the EMCS application with the destination type set to export (Destination Type Code is “6 = Destination - Export”). All the IE messages exchanged in the scenarios of this section containing the ARC and sequence number, namely the IE801, IE818, IE829 and IE839 messages, include the sequence number “1”.

b) The Consignor who submits a change of destination message (IE813: C_UPD_DAT) to the EMCS application with destination export (Destination Type Code is “6 = Destination - Export”) either retaining the destination type code of an export movement or changing the destination type code of a movement from non-export to export. The sequence number of the ARC will be the one indicated in the last IE801 or IE813 (whichever is the latest) message created by the EMCS application and shall be incremented by 1.

Page 26 of 30

DDUEA VER: 1.2

IV.II.1 Export Operation at Office of Export

In this scenario, the Consignor submits the e-AD to the EMCS application, whereas the export declaration is submitted by the customs declarant at an Office of Export in the UK.

According to this scenario, the Consignor submits a draft e-AD (IE815: N_EAD_SUB) to the EMCS application specifying export as the destination type (Destination Type Code is “6 = Destination - Export”). The validation of the submitted draft e-AD passes successfully and the EMCS application creates a validated e-AD (IE801: C_EAD_VAL) and makes it available to the Consignor. Finally, the state of the movement at the EMCS application is set to “Accepted” and a timer is initiated to expire at the expected end of movement export.

Note: following the submission of the e-AD it is possible for the Consignor to submit a change of destination before the Export Operation at Office of Export (see Section IV.I.5Change of Destination).

IV.II.2 Export Operation at Office of Export followed by Export Confirmation of Exit

In this scenario, the export declaration is cross-checked successfully against the e-AD, the movement is released by Customs and the exit from the UK is confirmed.

IV.II.2.1 Export Operation at Office of Export

Upon receipt of the export declaration from the Customs Export Application, the EMCS application successfully cross-checks the consistency of the e-AD with the export declaration.

Following, the EMCS application:

Changes the status of the e-AD to “Exporting”;

Builds a notification message (IE829: C_EXP_NOT) and makes available to the Consignor.

The EMCS application is now waiting for the confirmation of the export’s exit from the UK.

IV.II.2.2 Export Confirmation of Exit

The EMCS application receives exit results from the Customs Export Application, notifying of the acceptance of the export for exit. Following cross-checking of the customs notification against the e-AD, the EMCS application builds a Report of Export message (IE818) reporting exit acceptance and makes it available to the Consignor. Moreover, the state of the movement is updated from “Exporting” to “Delivered”. Finally, if the timer has not expired, the EMCS application stops it.

Page 27 of 30

DDUEA VER: 1.2

IV.II.3 Export Operation at Office of Export followed by Export Cancellation of Exit

In this scenario, the export declaration is cross-checked successfully against the e-AD, the movement is released by Customs, but the EMCS application receives no further communication from the Customs Export Application before the timer expires.

IV.II.3.1 Export Operation at Office of Export

The “Export Operation at Office of Export” is exactly the same as in Section IV.II.2.1 ExportOperation at Office of Export. Hence, the e-AD is in the “Exporting” state and the EMCS application is waiting for the discharge to take place when the exit is completed.

In case a declaration of exit is not received from the Customs Export Application before the timer expires, the e-AD in EMCS will remain in the “Exporting” state, and an Export rejection message (IE839: C_CUS_REJ) will be created and made available to the Consignor.

IV.II.4 Export Operation at Office of Export followed by Export Declaration Cancellation and Change of Destination

In this scenario, the Consignor cancels the export declaration on the Customs Export Application and submits a change of destination (Section IV.I.5 Change of Destination) to EMCS.

IV.II.4.1 Export Operation at Office of Export

The “Export Operation at Office of Export” is exactly the same as in Section IV.II.2.1 ExportOperation at Office of Export. Hence, the e-AD is in the “Exporting” state, the timer has been initiated and the EMCS application is waiting for the discharge to take place when the exit from the UK is completed.

IV.II.4.2 Change of Destination

The Consignor submits a change of destination (Section IV.I.5 Change of Destination) while the e-AD is in the “Exporting” state. The change of destination should be performed since the cancellation of the export declaration in the Customs Export Application is not communicated to EMCS.

After the issuance of the change of destination by the Consignor, a new version of the e-AD (IE801: C_EAD_VAL) with sequence number incremented by 1 is created and made available to the Consignor, and the status is set to “Accepted”. As a consequence, the EMCS application changes the state of the previous e-AD version from “Exporting” to “Diverted”.

Page 28 of 30

DDUEA VER: 1.2

In case a change of destination is not submitted by the Consignor after the cancellation of the export declaration, the e-AD in EMCS will remain in the “Exporting” state, the timer will expire, and an export rejection message (IE839: C_CUS_REJ) will be created and made available to the Consignor.

Page 29 of 30

DDUEA VER: 1.2

Appendix A: Business Rule Catalogue

This is an updated version of the DDNEA v1.92 Appendix J Business Rules Catalogue

Appendix B: Technical Codelists

This is an updated version of the DDNEA v1.92 Appendix B Codelists

Appendix C: Business Codelists

This is an updated version of the FESS v3.82 Appendix B Codelists

Appendix D: Technical Message Structure

This is an updated version of the DDNEA v1.92 Appendix D Technical Message Structure

Appendix E: XML Mapping

This is an updated version of the DDNEA v1.92 Appendix E XML Mapping

Appendix F: Directory with XML Schemas (XSDs)

This is an updated version of the DDNEA v1.92 Appendix H Directory with XML Schemas (XSDs)

Page 30 of 30