Fallback and Recovery Specification (FRS)

OWNER 

DG TAXUD 

ISSUE DATE 

01/12/2009 

TAXATION AND CUSTOMS UNION DG 

EMCS COMPUTERISATION PROJECT 

PHASE 2 

SUBJECT: 

Framework Contract: TAXUD/2008/CC/095 

VERSION 

3.11-EN 

Fallback and Recovery Specification (FRS) 

ECP2-FITSDEV2-SC03-FRS

DG TAXUD – EXCISE COMPUTERISATION PROJECT REF: ECP2-FITSDEV2-SC03-FRS 

FALLBACK AND RECOVERY SPECIFICATION (FRS) VERSION: 3.11-EN 

[This page has been left intentionally blank.] 

ECP2-FITSDEV2-SC03-FRSv3.11.doc Page 2 of 53



DOCUMENT HISTORY 

Document History 

Edi. Rev. Date Description Action (*) Pages 

0 00 08/05/2004 Create I All 

0 01 20/08/2004 Corrected Chapter 6 U 34 + 

0 02 20/08/2004 Added paragraph 7.1 U 36+ 

0 03 22/08/2004 Added paragraph 7.1.2 U 36+ 

0 04 01/10/2004 

Updated after SEVE quality 

review, SfR 

U All 

0 05 10/11/2004 SfR visibility check point U All 

0 06 30/11/2004 SfR visibility check point U All 

0 07 21/01/2005 

Updated after SEVE quality 

review, SfR 

U All 

1 00 21/03/2005 Updated for SfA U All 

1 01 18/04/2005 SfA v 1.b U All 

1 02 29/04/2005 SfA verification U All 

1 03 17/03/2006 Updated for internal review U All 

1 04 20/03/2006 Updated after MS comments U All 

1 05 27/03/2006 SfR U All 

2 00 04/05/2006 SfA U All 

2 11 02/07/2007 Internal review, SfR U All 

3 00 30/07/2007 SfA U All 

3 01 18/01/2008 

Incorporating changes imposed 

by the Trigger Nb #159. 

Submitted for review to 

Taxation and Customs Union 

DG. 

ECP2-FITSDEV2-SC03-FRSv3.11.doc Page 3 of 53 

U 

As 

Required




3 02 25/02/2008 

3 03 07/03/2008 

3 04 28/05/2008 

3 05 25/06/2008 

3 06 25/02/2009 

3 07 02/04/2009 

Submitted for Acceptance to 


DG. 

Re-Submitted for Acceptance 

to Taxation and Customs 

Union DG. 


by the RFA Nb #178. 



DG. 



DG. 


by the RFA Nb #234. More 

specifically: 

� Implementing FRS 

v3.05 WDs. 

� Performing alignment 

with revised MAP 

(CED 529). 

� Performing alignment 

with revised Directive 

(2008/118/EC). 



DG. 

Incorporating Reviewers 

Comments. 



DG. 


U 

U 

U 

U 

I, U 

U 

As 

Required 

As 

Required 

As 

Required 

As 

Required 

As 

Required 

As 

Required




3 08 06/04/2009 

3 09 04/11/2009 

3 10 20/11/2009 

3 11 01/12/2009 

Incorporating DG TAXUD's 

verification comments. 

Submitted for information to 

DG TAXUD. 

Updated after MS comments. 



DG. 

Incorporating Reviewers 

Comments. 



DG. 

Incorporating DG TAXUD's 

verification comments. 

Submitted for information to 

DG TAXUD. 

(*) Action: I = Insert, R = Replace, U = Update, D = Delete 


U 

U 

U 

U 

As 

Required 

As 

Required 

As 

Required 

As 

Required



TABLE OF contents 

Table of contents 

DOCUMENT HISTORY ..................................................................................................................................... 3 

TABLE OF CONTENTS ...................................................................................................................................... 6 

1 INTRODUCTION ......................................................................................................................................... 9 

1.1 PURPOSE OF THE DOCUMENT.................................................................................................................... 9 

1.2 FIELD OF APPLICATION ............................................................................................................................. 9 

1.3 INTENDED READERSHIP .......................................................................................................................... 10 

1.4 STRUCTURE OF THE DOCUMENT ............................................................................................................. 10 

1.5 APPLICABLE AND REFERENCE DOCUMENTS............................................................................................ 11 

1.5.1 Applicable Documents................................................................................................................... 11 

1.5.2 Reference Documents .................................................................................................................... 11 

1.6 SPECIFIC GLOSSARY ............................................................................................................................... 12 

1.7 ASSUMPTIONS ........................................................................................................................................ 13 

2 HOW TO READ THIS DOCUMENT ? ................................................................................................... 14 

2.1 WHAT AN EXCEPTION MEANS................................................................................................................. 14 

2.2 DISCOVERING AND CHARACTERIZING EXCEPTIONS ................................................................................ 14 

2.3 PROPOSING BUSINESS RESPONSES TO EXCEPTIONS ................................................................................. 16 

3 EXCEPTIONS TYPOLOGY ..................................................................................................................... 20 

3.1 INFORMATION EXCHANGE EXCEPTIONS ................................................................................................. 20 

3.1.1 Exceptions at physical level .......................................................................................................... 20 

3.1.2 Exceptions at semantic level.......................................................................................................... 21 

3.2 PROCESS EXCEPTIONS ............................................................................................................................ 22 

3.2.1 Exceptions at physical level .......................................................................................................... 22 

3.2.2 Exceptions at semantic level.......................................................................................................... 23 

4 MANAGEMENT OF DATA ...................................................................................................................... 24 

4.1 OWNERSHIP AND HOLDING OF DATA ...................................................................................................... 24 

4.2 RECTIFICATION OF DATA........................................................................................................................ 24 

4.2.1 Rectification at entry level ............................................................................................................. 25 

4.2.2 Rectification at application level ................................................................................................... 25 

4.2.3 Control of rectifications ................................................................................................................ 26 

5 SOLUTION ELEMENTS .......................................................................................................................... 27 

5.1 PREVENTION OF EXCEPTIONS ................................................................................................................. 27 

5.1.1 PR01: Pre-validation of entered information ................................................................................ 28 

5.1.2 PR02: Ensure permanent availability of EMCS applications ....................................................... 28 

5.1.3 PR03: Atomicity of EBP processing .............................................................................................. 28 

5.1.4 PR04: Use of timers ...................................................................................................................... 28 

5.1.5 PR05: Enqueue message for further automatic recovery .............................................................. 29 

5.1.6 PR06: Business acknowledgement ................................................................................................ 29 

5.1.7 PR07: Follow-up ‘open’ information ............................................................................................ 30 

5.2 ADMINISTRATIVE PROCEDURES ............................................................................................................. 30 

5.2.1 AP01: Enquire on information ...................................................................................................... 31 

5.2.2 AP04: Broadcast information on unavailability ........................................................................... 31 

5.2.3 AP05: Perform internal controls ................................................................................................... 31 

5.2.4 AP06: Take a business decision .................................................................................................... 32 

5.2.5 AP07: Transfer issue to support .................................................................................................... 32 

5.2.6 AP08: Exchange information outside EMCS ................................................................................ 33 

5.3 FALLBACK SOLUTION ELEMENTS ........................................................................................................... 33 

5.3.1 FB01: Use alternate communication medium ............................................................................... 34 




TABLE OF contents 

5.3.2 FB02: Revert to manual without subsequent input ....................................................................... 35 

5.3.3 FB03: Revert to manual with subsequent input ............................................................................ 35 

5.3.4 FB04: No intervention – wait ........................................................................................................ 35 

5.3.5 FB06: Notify administration ......................................................................................................... 36 

5.3.6 FB08: Notify economic operator ................................................................................................... 37 

5.4 RECOVERY SOLUTION ELEMENTS ........................................................................................................... 37 

5.4.1 RC03: Restart or replace technical component ............................................................................ 37 

5.4.2 RC04: Enter data using the normal procedure ............................................................................. 38 

5.4.3 RC05: No intervention – accept exception .................................................................................... 38 

5.4.4 RC06: Collate electronic record with the fallback form ............................................................... 38 

5.4.5 RC07: Replay information exchange ............................................................................................ 39 

5.4.6 RC10: Re-apply undone changes .................................................................................................. 39 

6 PAPER FALLBACK SYSTEM ................................................................................................................. 40 

6.1 OVERVIEW ............................................................................................................................................. 40 

6.2 ROLES AND RESPONSIBILITIES ................................................................................................................ 40 

6.2.1 Unavailability at consignor’s premises (location A) ..................................................................... 41 

6.2.2 Unavailability at MSA of dispatch (location B) ............................................................................ 41 

6.2.3 Unavailability at MSA of destination (location C) ........................................................................ 41 

6.2.4 Unavailability at consignee’s premises (location D) .................................................................... 42 

6.3 FALLBACK PAPER FORMS ....................................................................................................................... 42 

6.4 FALLBACK COMMUNICATION MEDIA ...................................................................................................... 42 

6.5 MAIN BUSINESS CASES FALLBACK PROCEDURES .................................................................................... 43 

6.5.1 Submission of AAD ........................................................................................................................ 43 

6.5.2 Cancellation of AAD ..................................................................................................................... 44 

6.5.3 Report of receipt ............................................................................................................................ 44 

6.5.4 Change of destination.................................................................................................................... 45 

6.5.5 Splitting ......................................................................................................................................... 46 

6.5.6 Interruption ................................................................................................................................... 47 

6.5.7 Control .......................................................................................................................................... 47 

6.5.8 Administrative cooperation ........................................................................................................... 48 

6.6 RECOVERY FROM PAPER FALLBACK PROCEDURES ................................................................................. 48 

6.6.1 Means to recover ........................................................................................................................... 48 

6.6.2 Deferred mode ............................................................................................................................... 49 

6.6.3 Summary of intermediate operations ............................................................................................ 49 

7 UNAVAILABILITY OF SEED INFORMATION ................................................................................... 50 

8 SPECIFIC PROVISIONS DURING THE ROLLOUT OF EMCS ........................................................ 51 

8.1 FALLBACK AND RECOVERY DURING MIGRATION PERIOD 1 ................................................................... 51 

8.1.1 Unavailability of the automatic triggering of risk assessment ...................................................... 51 

8.1.2 Exportation of goods in an MSA different from the MSA of dispatch ........................................... 51 

8.1.3 Unavailability of the control report .............................................................................................. 52 

8.1.4 Unavailability of the event report ................................................................................................. 52 

8.1.5 Interruption of a movement ........................................................................................................... 53 




TABLE OF figures 

Table of figures 

FIGURE 1 APPENDIX A - EXCEPTIONS ................................................................................................... 18 

FIGURE 2 E-AAD MANAGEMENT INFORMATION FLOWS ....................................................................... 40 

FIGURE 3 SUBMISSION OF AAD – FALLBACK ADMINISTRATIVE CIRCUIT .............................................. 43 

FIGURE 4 CANCELLATION OF AAD – FALLBACK ADMINISTRATIVE CIRCUIT......................................... 44 

FIGURE 5 REPORT OF RECEIPT – FALLBACK ADMINISTRATIVE CIRCUIT ................................................. 44 

FIGURE 6 CHANGE OF DESTINATION – FALLBACK ADMINISTRATIVE CIRCUIT ....................................... 45 

FIGURE 7 SPLITTING – FALLBACK ADMINISTRATIVE CIRCUIT ............................................................... 46 

FIGURE 8 INTERRUPTION – FALLBACK ADMINISTRATIVE CIRCUIT ........................................................ 47 

FIGURE 9 CONTROL – FALLBACK ADMINISTRATIVE CIRCUIT ................................................................ 47 

FIGURE 10 ADMINISTRATIVE COOPERATION – REQUEST FOR ASSISTANCE .............................................. 48 

FIGURE 11 ADMINISTRATIVE COOPERATION – SPONTANEOUS INFORMATION AND REPLY TO A REQUEST 

FOR ASSISTANCE ................................................................................................................... 48 

Table of tables 

TABLE 1 APPLICABLE DOCUMENTS ...................................................................................................... 11 

TABLE 2 REFERENCE DOCUMENTS ....................................................................................................... 12 

TABLE 3 SPECIFIC GLOSSARY OF ACRONYMS USED IN THE FRS .......................................................... 13 




Introduction 

1 Introduction 

1.1 Purpose of the document 

The purpose of this document is to provide the necessary information to correctly take 

charge of the continuity and integrity of EMCS business where unexpected circumstances 

arise, but also to consider related functional, organisational, procedural and security 

requirements. 

It is a part of the Functional Excise System Specification [R6]. It aims to identify 

exceptions, i.e. conditions that may make it impossible to use EMCS in its customary 

way, and to determine how the business must react to these conditions. 

From the analysis of individual exceptions, the document identifies the business 

responses that must be given to these exceptions. 

Only international business responses given in this FRS are imperative; national and/or 

local business responses are to be considered as suggestions. 

To that end, the FRS considers: 

� preventing exceptions from happening through detection and prevention measures and 

preparing the system for complementary solutions; 

� falling back from normal working processes to downgraded operations so as to ensure 

continuity of business while acquiring the information necessary for a safe recovery; 

in particular, manual fallback solutions are suggested in case of EMCS unavailability 

(to be started after a certain time depending on the case), and related paper based 

procedures are described; 

� recovering the follow-up information to reconstruct the exact history of a movement, 

at least the useful part of it, into electronic records. 

The analysis of FRS exceptions also leads to identify a series of requirements, on which 

could depend the implementation of the identified business responses. 

Additional procedures required to cope with exceptions are identified also. 

Even though the approach is business oriented, one cannot underestimate the fact that 

most EMCS processes will be automated, and that one of the main sources of exception 

will be the unavailability of these automated processes. 

Even in that case, the FRS only considers the functional consequences of such 

exceptions, and how they are handled by the business. It never addresses the technical 

implications of an exception. However, the FRS identifies a series of requirements on 

which depends the implementation of the identified business responses. 

1.2 Field of application 

The field of application of the FRS is the whole scope of the FESS [R6]; the FRS must be 

understood as a full part of the FESS [R6] with explicit requirements. 

As stated in the previous section, the FRS: 




Introduction 

� only identifies fallback solutions for a target system in which all MSAs use the EMCS 

application; 

� addresses some cases of migration period 1 (defined in the Phasing and Scope 

Specification (PSS) [R3]), where some Member States and/or economic operators will 

not be equipped yet with the computerised EMCS while other ones will already be 

operational. It shall be noted that no specific provisions (as defined in Chapter 8) 

apply to the fallback and recovery procedures of EMCS during the rollout of EMCS 

Phase 3, since according to the updated Master Plan [R7], there will be no coexistence 

of FS1 and FS2 (all MSAs will enter the EMCS Phase 3 operations at 

milestone Mc). 

1.3 Intended readership 

The intended readership for this document is the same as for the FESS [R6]; it includes: 

� any person/service involved in the functional and technical specification or 

implementation of EMCS (including as well Member States representatives and 

software design teams or development teams, …); 

� any person/service in charge of defining the procedures and handbooks that will apply 

to the operation of the EMCS systems, both in the Common Domain and in the 

National Domains; 

� any other authorised body concerned with EMCS including the Excise Committee, the 

ECWP, the ECP Steering Committee, and the professional organisations of economic 

operators. 

1.4 Structure of the document 

This document contains the following chapters: 

� Chapter 1 "Introduction" is the present general introduction; 

� Chapter 2 "How to read this document ?" highlights the way of using this document 

by describing the concepts and the way they are implemented; 

� Chapter 3 "Exceptions typology" gives a general description of the categories of 

exceptions identified for EMCS; 

� Chapter 4 "Management of data" highlights the notions of ownership and holding of 

data and their impact on rectification and further controls; 

� Chapter 5 "Solution elements" presents the generic solution elements involved in the 

construction of business responses to EMCS exceptions; 

� Chapter 6 "Paper fallback system" explains roles, responsibilities and fallback means 

to be used for some specific exceptions. In that context, main business cases and 

electronic recovery are presented; 

� Chapter 7 "Unavailability of SEED information" presents fallback and recovery 

solution for this reference database; 

� Chapter 8 "Specific provisions during the rollout of EMCS" is focused on Migration 

Period 1 and FS2 as defined in the PSS [R3]. 




Introduction 

This document is further completed with a series of Appendices: 

� Appendix A, entitled "Exceptions and Solution elements", contains the detailed list of 

all individual exceptions that have been qualified worth a processing during the 

analysis, and the scenario of solution elements assigned to each exception; 

� Appendix B, entitled "Information exchanges to be acknowledged", lists the EMCS 

Information Exchanges that must be explicitly acknowledged, according to the 

prevention solution element “PR06 - business acknowledgement”; 

� Appendix C, entitled "Summary of Solution elements", lists the solution elements that 

contribute to solve the issues raised by the exceptions and gives the links with the 

complementary requirements resulting from the analysis; 

� Appendix D, entitled "Summary of Requirements", gives the list and contents of all 

the requirements resulting from the analysis of the FRS (in addition of those of the 

FESS [R6] with the links to the solution elements described in the present document. 

1.5 Applicable and reference documents 

1.5.1 Applicable Documents 

Ref. Identifier Title Version Issued 

A1 TAXUD/2008/CC 

/095 

A2 TAXUD/2008/DE 

/123 

Framework Contract 15/09/2008 

Specific Agreement n° 03 

(SC03) for Lot ESS based on 

[A1] 

A3 DIRECTIVE Directive 2008/118/EC 

concerning the general 

arrangements for excise duty 

and repealing Directive 

92/12/EEC. 

1.5.2 Reference Documents 

Table 1 applicable documents 

28/11/2008 

16/12/2008 


R1 ECP1-ESS-SEP Security Policy (SEP) 2.02 13/12/2004 

R2 ECP1-ESS-GLT Glossary of Terms 1.01-EN 14/11/2004 

R3 ECP1-ESS-PSS Phasing and Scope 

Specification (PSS) 

R4 ECP1-ESS-SESS Security Excise System 

Specification (SESS) 

R5 ECP2-EMCS- 

DDNEA 

Design Document for 

National Excise Applications 

2.12 28/09/2007 

2.00 02/10/2006 

2.19 05/02/2009 




Introduction 


R6 ECP1-ESS-FESS Functional Excise System 

Specification (FESS) 

3.00 08/11/2007 

R7 MAP Master Plan 2.9 06/04/2009 

1.6 Specific glossary 

Table 2 reference documents 

Below are listed all acronyms of interest that are used in the FRS document, and whether 

they are referenced in the GLT [R2]. 

Acronym Translation 

Found in 

GLT 

AAD Administrative Accompanying Document yes 

ARC AAD Reference Code yes 

CCN/CSI Common Communication Network/Common System Interface yes 

ECWP Excise Computerisation Working Party yes 

EBP Elementary Business Process yes 

ECP Excise Computerisation Project yes 

ECS Export Control System no 

EEC European Economic Community no 

ELO Excise Liaison Office yes 

EMCS Excise Movement and Control System yes 

FESS Functional Excise System Specifications yes 

FMS Functional Message Structure yes 

FRS Fallback and Recovery Specification yes 

GLT Glossary of Terms yes 

IE Information Exchange yes 

IT Information Technology yes 

LRN Local Reference Number no 

MRN Movement Reference Number no 

MS Member State no 




Introduction 

Acronym Translation 

Found in 

GLT 

MSA Member State Administration yes 

N/A Not Applicable no 

NACK Non-ACKnowledgement service message yes 

SAD Single Administrative Document no 

SEED System for Exchange of Excise Data yes 

SEP Security Policy yes 

STD State Transition Diagram yes 

TAXUD Directorate-General Taxation and Customs Union yes 

UC Use Case yes 

1.7 Assumptions 

Table 3 specific glossary of acronyms used in the FRS 

This Fallback and Recovery Specification is written according to the following 

assumptions: 

1. legal and regulatory provisions are respected by all involved parties; irregularities and 

infringements pertain to the processing of inquiries; 

2. roles and responsibilities never change; if, for some reason, an intermediate acts by 

delegation of a partner (for instance, an excise officer enters a report of receipt on 

behalf of the consignee), the responsibility rests with the delegating actor; 

3. if the normal communication medium between an economic operator and its MSA 

fails, alternate communication media (fax, digital memory medium or paper) will 

always be available. 




How to read this document ? 

2 How to read this document ? 

Apart from your role in the EMCS project (business actor, software designer or 

developer, software test team member…), you need to know how to exploit the richness 

of this document. 

2.1 What an exception means 

Any condition that may make it impossible to use EMCS in its customary way, is called 

here “exception”. The purpose of this document is to determine how the business must 

react to these exceptions. 

An analytical approach is used to detect as many potential exceptions as possible and to 

define the responses to these exceptions. 

All exceptions identified during the analysis phase have been studied in order to derive a 

number of generic responses. 

The use of specific responses will then be limited to the few cases where no generic 

response is applicable. 

2.2 Discovering and characterizing exceptions 

Exceptions identification and qualification is done by systematically exploring the flows 

described in the use cases defined in the FESS [R6] and by identifying the situations that 

would make it impossible to follow the expected path until the end of the flow (including 

the effect of a failure of resources); this allows to explore separately each information 

exchange, once from the point of view of the sender and once from the point of view of 

the receiver; 

For each identified exception, the following points are examined: 

� Plausibility; 

� Business impact; 

� Security impact; 

� Time constraints. 

Qualification of exceptions against plausibility, business impact, security impact and time 

constraints results in a decision whether the exception is worth a processing. 

Plausibility 

The plausibility of each identified exception is first questioned to determine whether the 

exception is worth identifying a business response. This is done by examining whether, 

from a business point of view, this exception could really happen. The level of 

plausibility is not considered. In other words, an exception is either considered plausible 

(even if its level of plausibility is low) or non plausible. Non plausible exceptions are 

kept for documentation purposes but are not further analysed. 





Business impact 

By impact, one must understand not only the impact of the exception itself on the 

business but also the impact of any solution element that any partner has to carry out 

following the exception. 

The business impact is an evaluation of the geographical scope of the possible impact of 

the exception on the business of EMCS. It is evaluated for each exception found 

plausible. There are three possible classes of impact: 

� international business impact, if the occurrence of this exception affects the EMCS 

business in at least two Member States; 

� national business impact, if the occurrence of this exception affects the EMCS only in 

the country where this exception has occurred; 

� local business impact, if the occurrence of this exception only affects the business of 

the excise office where this exception has occurred, and/or the business of an 

economic operator; 

� no business impact. 

If there is a business impact at several levels (e.g. an international and a national business 

impact), only the widest one is considered. 

The objective is not to define the relative importance of an exception for the business 

(national business impact on economic operators may be more important than 

international impact), but to identify the maximum scope (international or national) 

applicable for the handling of this exception. 

In turn, each MSA should define its own exceptions (at national level). 

Security impact 

The impact of each plausible exception on the security of the business is evaluated. It 

results from one among several situations: 

� the exception itself creates a breach of security; 

� the business response to the exception itself may create a breach of security; 

� the exception results from an attempt at fraud. 

A “security breach” area is qualified according to whether it affects one of the following: 

� availability of the system; 

� data confidentiality; 

� data integrity; 

� risk of fraud. 

It is possible that the same exception impacts several security areas. Only that estimated 

the most important is displayed; in particular a risk of fraud always prevails on the other 

area. 

For more information about security related aspects, please refer to the SEP [R1] and to 

the SESS [R4]. 





Time constraint 

Where an exception is qualified worth a processing, it is considered whether it must be 

satisfactorily dealt with within a limited period of time, and this time limit is identified as 

far as possible. 

For each exception, in particular, response time classes (interactive, asynchronous, 

scheduled, up to MSA, asynchronous/scheduled or N/A) and response time classes that 

have been introduced in FRS (none, business limit, national limit, national provisions), 

the constraint takes into account performance requirements defined in Appendix A of the 

FESS [R6]. 

2.3 Proposing business responses to exceptions 

Following the exceptions identification and qualification phase exposed above, the 

possible business responses were studied for all individual exceptions that were found 

plausible. 

If exceptions have an international business impact, the business responses must take into 

account international business constraints shared by all MSAs. It is therefore expected 

that these responses will be considered as standard responses, to be used by all 

participants to EMCS. 

In order to cover the global scope of the FESS [R6], the same approach is applied to 

exceptions with a national impact. 

In this case, however, business responses are only suggested, and will have to be adjusted 

by each MSA, based on their own legal, contractual or organisational requirements. 

The business response to an exception is either generic or specific: 

� A generic response is a standard response that relates to a whole series of exceptions. 

Whenever one of these exceptions is encountered, the related generic response applies, 

regardless of the specific aspects of the exception; 

� A specific response relates to a single exception, and is designed to be used only 

when this specific exception is encountered. 

As much as possible, business responses found for each business exception should be 

made generic, i.e. reusable by other exceptions. 

Business responses are defined as a set of identified and chronologically ordered solution 

elements. 

Main solution elements categories are: 

� Prevention measures systematically applied in the course of a normal activity flow 

with the aim of preventing or at least reducing the occurrence of an exception, or 

preparing elements that would later help in applying further (post exception) 

measures; 

� Administrative procedures, which are used in order to further document an 

exception; for example, the possibility for querying on missing information or taking a 

business decision; 





� Fallback solution elements, which are used in order to ensure the continuation of the 

business when an exception is encountered; the objective is to avoid delaying urgent 

excise business; they include, for example, the switch to a manual procedure when an 

automated process becomes unavailable; 

� Recovery solution elements, which are used to correct defective data resulting from 

errors that have occurred in the system, from mistakes made by users, or from the 

application of fallback solutions; they include, for example, the introduction of results 

in the system after an automated job has been temporarily replaced by a manual 

procedure, or complete replay of the manual procedure to obtain the actual business 

result. 

Most generally, the convenient response to a given exception is a combination of 

individual business responses. While identifying appropriate business responses to 

exceptions, several situations may be encountered: 

� the current exception is satisfactorily processed by starting a normal business use 

case; the use case becomes the normal response for the current exception; 

� the current exception is satisfactorily processed by an existing generic business 

response; the generic business response becomes the normal response for the current 

exception; if several generic business responses apply, they are compared and the most 

appropriate one is selected; 

� the current exception is satisfactorily processed by an existing specific business 

response defined for another exception; the specific solution then becomes a new 

generic business response with two particular applications; 

� the current exception solution is almost satisfactorily processed by an existing generic 

business response; the question whether a variant of the generic business response 

must be created has to be considered; 

� there is no satisfactory business response, neither generic nor specific, to deal with the 

current exception; a specific business response is defined with the view to make it 

generic in the future, i.e. by avoiding specific features. 

In addition, the detailed implementation of the same business response widely depends on 

the circumstances and on the context. This procedure has been followed to define the 

solutions presented in this document. It must be re-used in the future in the case new 

exceptions have to be analysed. 

Chapter 3 „Exceptions typology‟ describes generic exceptions that occur during 

information exchanges or during business processes. This gives a typology of individual 

exceptions listed in Appendix A, and presented as below: 





Figure 1 Appendix A - Exceptions 

In Appendix A, each identified exception is: 

� presented regarding a specific use case (�); 

� identified per EBP (�) and per actor/location (�); 

� uniquely identified (�), and labelled with a short description text (�); 

� qualified against plausibility, business and security impacts, and time constraint (�); 

� followed by a set of clearly identified and chronologically ordered solution elements 

(�- note that alternatives are also identified) forming together the business response to 

the exception, including most of the time a specific note regarding the concerned 

exception; 

� if relevant, a label indicates that the exception is specific to “Migration period 1” (�). 





In Appendix A, the exceptions are grouped by use cases. 

The use cases are presented in the same order as in the FESS [R6] : 

Section II : UC2.01, UC2.10, UC2.06, UC2.07, UC2.33, UC2.17, UC2.12, UC2.13, 

UC2.34, UC2.05, UC2.36, UC2.51, UC2.52, UC2.44, UC 2.43, UC2.46. 

Section III : UC1.14, UC1.15, UC1.16, UC1.30, UC1.11, UC1.04, UC1.05, UC1.06, 

UC1.13, UC3.16. 

Section IV : UC3.24, UC3.03, UC3.05, UC2.14, UC3.01, UC3.07, UC 3.09, UC3.29, 

UC3.14. 

Section V : UC0.07. 

The business responses are described in detail in Chapter 5 “Solution elements”; they are 

summarised in Appendix C and associated to individual exceptions in Appendix A. 

Note that the numbers contained in the identification of solution elements (e.g. FB06) are 

not related to any chronological order when used in a business response. 

Only the sequential numbering of solution elements in Appendix A indicates a 

chronological order of appliance. 




Exceptions typology 

3 Exceptions typology 

This chapter contains a general description of the categories of exceptions and of the 

common characteristics of these categories. This categorisation has been the main 

guideline to discover exceptions throughout the analysis of the process flows. These 

exceptions are listed in Appendix A where they are presented along with the response 

scenarios that eventually allow restoring the good functioning of the system. 

The main categories are based on the origin and place of occurrence of these exceptions, 

namely: 

� Information Exchange; or 

� Processing. 

Although useful to systematically analyse the process flows to detect exceptions, these 

categories have not been found relevant in deeper analysis. 

3.1 Information Exchange exceptions 

All information exchanges are subject to the same types of exception, regardless of the 

business context in which information has to be exchanged. 

Regardless of the scope (national or international) of an information exchange, or of the 

communication medium used (message exchanged through a communication network, 

paper based, phone, fax, e-mail...) exceptions happen at two levels: 

� Physical: failure of the communication medium itself, or loss of the information to be 

exchanged; 

� Semantic: the content of the information exchange does not have any business 

signification to the receiver. 

Whatever its level, an exception will have the same functional result: a failure of the 

information exchange. 

Note that most possible exceptions listed in this section are actually detected by the 

business process that receives and verifies information, in particular paragraph 3.1.2 

„Exceptions at semantic level‟. However, as they apply to the information itself, we 

preferred keeping them in this section. 

3.1.1 Exceptions at physical level 

3.1.1.1 Unavailability of the communication medium 

Most generally, if the normal communication medium fails, information cannot be 

exchanged through normal EMCS procedures. 

However, for some exchanges, it has been found important to define alternate 

communication channels, either because the normal channel is felt particularly fragile or 

because the permanence of the exchange is essential for the good functioning of EMCS. 





3.1.1.2 Loss of information to be exchanged 

For some reason, the addressee never receives the contents of an information exchange. If 

this is the case, different situations must be considered: 

1. The lost information was expected. 

The addressee expects to receive certain information within a given time limit, and this 

information is lost: this is typically the case if information is exchanged in response to 

another information exchange. 

For example, if the report of receipt of an e-AAD does not arrive in due time. Most 

generally, but not always, such missing information is automatically detected through 

a timer or equivalent mechanism. 

2. A response to the lost information was expected. 

If the lost information was not expected from the addressee, but the sender expects to 

receive a specific response to this information exchange within a certain delay. This 

situation is similar to the situation described in the example above, except that, in this 

case, it is the initial information exchange that is lost (in this example: the e-AAD 

never reached the consignee), instead of its response; that is to say that the e-AAD 

itself is lost. 

The result will be the same: the consignor will not receive the expected report of 

receipt. 

3. The lost information was not expected. 

If the lost information was not expected from the addressee, and the sender does not 

expect to receive a specific response to this information exchange, the exception 

remains undetected until the lost information becomes needed. 

3.1.2 Exceptions at semantic level 

Several defects are capable of making it impossible for the receiver of an information 

exchange to understand the business signification of the received information; typically: 

� the message refers to an object that is not known to the receiver; 

� the content of the received information is not consistent with already known 

information (e.g. a report of receipt is received from an economic operator who is not 

the consignee of the e-AAD). 

3.1.2.1 Unknown object 

The typical case of unknown object is where a received information exchange refers to an 

ARC that is not known to the receiver. This results from a preceding error (the e-AAD 

did not reach the receiver), from a mistake (wrong ARC has been input) or from a fraud 

(use of a forged ARC). 

Similar cases are where a complementary submission of a control report or of an event 

report refers to a non-existent report identifier or where a response to a request refers to a 

non-existent correlation id. 





In most cases, the incoming information exchange must simply be rejected, and the 

sender has to be notified (through a NACK message) about this rejection and its motives. 

The further handling of the exception depends on the nature of the defect. However, some 

particular situations may necessitate a more complex processing. 

3.1.2.2 Inconsistent data 

Data sent in an information exchange will not be consistent with data already available to 

the receiver in the following cases: 

1. the information exchange contains data based on a version of registration or reference 

data different from the version used by the receiver; 

2. the information exchange contains fixed data on an EMCS movement that does not 

correspond to the equivalent data already known by the receiver on this exchange. 

3.2 Process exceptions 

Being generally automated, there are many reasons for business processes to fail similarly 

to information exchanges. 

3.2.1 Exceptions at physical level 

3.2.1.1 Unavailability of a component 

If some component that makes up the business process fails, processing of information 

becomes impossible. 

This includes the availability of necessary information as well. For instance, if the 

consultation of SEED information by the application is currently impossible, basic 

processes such as the submission of an e-AAD or of a change of destination becomes 

impossible. 

3.2.1.2 Corruption of information 

This situation happens when, for any reason, the automatic processing does not properly 

process information and hence output of a use case does not conform to the expected 

result. It is the case, for instance, where a component encounters a random error. 

This should not happen, and detection of such cases is considered difficult. 

If the processing carries on despite the error, this latter is propagated throughout the 

whole history of the movement, possibly corrupting other movements. In many cases, the 

error will be detected a posteriori, possibly after several operations will have been 

completed on the same movement. 





3.2.2 Exceptions at semantic level 

3.2.2.1 Non conformance of the implemented processing 

Non conformance of the implemented processing with the functional specification is 

supposed to be prevented, if not completely expelled by a careful certification of each 

application before leaving it entering into operation. However, particular situations lead 

to discover cases that escape the described functionality. This is detected in a further step 

of the same process or in a further process, possibly in a later use case. 

The resolution process should: 

1. immediately solve the current exception (incident) by any available means; 

2. define a workaround to avoid further occurrences of the exception and issue the 

relevant use recommendations; 

3. report the incident to the relevant authority (national support or common domain 

support); 

4. design a stable and definitive solution and include it in a further release of the 

software (or hardware). 

Such incidents being unexpected by nature, they are not identified in the FRS. 

3.2.2.2 Disparity between the functional specification and the actual business need 

This case comes under maintenance of the specification, either corrective (for instance 

giving a more precise description of the expected functionality and adding test cases to 

the certification tools), or evolutionary (defining new particular cases and the way they 

have to be processed). 




Management of data 

4 Management of data 

4.1 Ownership and holding of data 

In EMCS, each piece of information has: 

� an owner, i.e. the user who submitted the information; most times, it is an economic 

operator, either registered, and in that case he enters the information himself, or nonregistered, 

and in that case another user, possibly an official, enters it on his behalf; 

� a holder, i.e. the MSA that is responsible for keeping the reference version of 

information and for transferring it to any authorised partner whenever required; in 

principle it is the MSA that initially validated it, also called initiating MSA. 

The general principles that govern management of data are the following: 

� the owner is responsible for the accuracy of the submitted information; 

� only the owner of a data item is authorised to submit any update to that item, if 

updating is allowed; 

� if the case arises, the person (in particular, the official) who enters data on behalf of 

the owner is not responsible for the given information but only for entering exactly 

what the owner requested; 

� the holder MSA is responsible for formally validating submitted information and to 

report errors to the owner; 

� the holder MSA is not entitled to change anything to the information held, unless he is 

the owner as well; 

� the holder MSA is responsible for keeping information correct. 

Example: 

Upon submission of an e-AAD, the MSA of dispatch formally validates the submitted 

information and returns back the errors to the consignor, if any. 

The consignor (owner of the e-AAD) is responsible for correcting errors and resubmitting 

the e-AAD. 

If no errors are found, the MSA of dispatch becomes the holder of the e-AAD. In 

addition, the MSA of dispatch allocates an ARC to the e-AAD; the MSA of dispatch is 

therefore the owner of the ARC. 

This example shows how the same data group may be built from data items with different 

owners. 

4.2 Rectification of data 

If, as a result of errors or mistakes, the information entered into EMCS needs to be 

rectified, the general business principle is that rectification information can only be 

cancelled or amended by its owner and that the rectification is validated by the holder of 

data. For convenience, it may be acceptable that the holder updates the information on 

behalf of the owner, but only with his explicit agreement. 





Invalid or outdated information is never deleted but marked for history purpose, including 

where it results from mistakes. Necessary rectification of information is limited to a part 

of information and is changed only through well identified ways. 

Rectification is required at two levels: 

� at entry level: when information is submitted but not yet approved and stored; 

� at application level: when information has been entered into EMCS and, in most cases, 

immediately and automatically disseminated to all concerned partners, either 

economic operators or MSAs. 

4.2.1 Rectification at entry level 

No information should be accepted and recorded within EMCS unless it has been 

submitted to a formal validation. The rules of formal validation are detailed in the 

description of each concerned use case. 

This applies both where information is submitted by an economic operator and where it is 

submitted by an official. 

MSA may find it useful to locally store a part of information they are preparing to send to 

their partners (for instance administrative cooperation messages); details of rectification 

depend on the organisation of each MSA and will have to be defined at the national level. 

MSAs are never allowed to rectify information of which they are not the owner; if they 

detect any anomaly that justifies a rectification, the MSA requires the owner of 

information, usually an economic operator, to perform the relevant rectification 

operation. 

4.2.2 Rectification at application level 

Once information has been recorded in EMCS, it should only be corrected by using 

defined use cases. 

The System specification offers a range of functions that result in the ability to update a 

part of information. However, some information can only be rectified by cancellation and 

possible replacement of an e-AAD. 

Example 1: 

If, at submission time, an e-AAD is validated based on erroneous information, it is 

possible for the consignor to immediately cancel it (UC2.10) and resubmit the correct 

information (UC2.01). A new ARC is then allocated. 

This is possible only where the goods have not yet left the place of dispatch. 

Example 2: 

If at submission time, the consignor made a mistake when typing the excise number of 

the consignee, which could not be prevented by the initial checking, he may immediately 

issue a change of destination (UC2.05). 





4.2.3 Control of rectifications 

All cases that support rectification should be specifically monitored by the MSA. 

Successive states of any entity involved in EMCS are systematically kept for history by 

the initiating MSA. This includes all rectifications performed during the life cycle of that 

entity. Information is communicated to concerned partners according to the general 

process of the use cases used for rectification. 

In addition, all operations are logged for audit and statistics purpose. 




Solution elements 

5 Solution elements 

Solution elements are the basic components of the overall business responses that relate 

to the identified exceptions. Whenever one of these exceptions is encountered, the related 

generic responses apply, regardless of the specific aspects of the exception. 

This chapter presents generic solution elements to build the business responses to EMCS 

exceptions. 

5.1 Prevention of exceptions 

PR01 Pre-validation of entered information 

PR02 Ensure permanent availability of EMCS applications 

PR03 Atomicity of EBP processing 

PR04 Use of timers 

PR05 Enqueue message for further automatic recovery 

PR06 Business acknowledgement 

PR07 Follow-up „open‟ information 

As a general rule, it is easier to prevent an exception from happening than to try to solve 

it after it has occurred. Therefore, when there are indications that some means exist to 

prevent an exception or reduce its consequences, these means are to be identified and 

become a part of the solution. 

A prevention solution element is characterised by: 

� a place of prevention that identifies the responsibility of the measure; prevention 

should be performed as close as possible to the source of the cause and to the possible 

point of correction; 

� a type of prevention such as assistance and control of input at user interface, integrity 

control at receipt of a message, control of internal consistency before sending a 

message, etc. 

A major characteristic of EMCS is that it mainly consists of automatic sequences of 

processes entrusted to different IT systems and that are automatically chained. 

Consequently, there is generally no intermediate actor enabled to verify to correct 

movement information during the processing of a use case. 

At the end of a use case, the new information must be known and consistent amongst all 

involved locations throughout the whole system. 

Consequently, there must be general mechanisms to: 

� ensure that only correct data are entered into the system; 

� ensure that the normal sequence of states is respected. 





5.1.1 PR01: Pre-validation of entered information 

Any capture of data must be submitted to formal validation at time of keying in, i.e. 

before any further validation by the system. This is a major requirement of the system. 

Example: 

Upon submission of an e-AAD, the application of the consignor includes as many 

controls as possible to ensure semantic validity of each field (e.g. conformance to 

business rules) and consistency among fields, possibly by reference to available 

databases. 

5.1.2 PR02: Ensure permanent availability of EMCS applications 

EMCS is characterised by very strong availability requirements. Some functions such as 

the submission of an e-AAD have been quoted with a "permanent" availability 

requirement where a given interruption of the service should not last more than 15 

minutes and many other ones with a "high" availability requirement where a given 

interruption cannot last more than one hour. 

5.1.3 PR03: Atomicity of EBP processing 

Most EBPs described in the FESS [R6] are thought as business transactions, i.e. a set of 

actions that must be either completed or aborted together. The mechanism is defined at 

business level, i.e. there is no assumption on the way it shall be implemented. 

This response does not address specific exceptions but it is a prerequisite that has been 

used in the discovery of exceptions. Its role is to avoid considering in detail the possible 

exceptions that arise inside the process and to concentrate on the interconnection of each 

elementary process with the other ones: incoming and outgoing information exchanges, 

access to external information, functioning of timers. 

5.1.4 PR04: Use of timers 

Timers are introduced to ensure that a reminder is issued when a specific event has not 

arisen in due time. 

The mechanism is defined at business level, i.e. there is no assumption on the way it shall 

be implemented. 

This response does not address specific exceptions but it is a prerequisite for some other 

solution elements. A few major cases are described in the FESS [R6] itself, because they 

include coordination mechanisms including international information exchanges. 

Conversely, a range of deadlines are to be defined at national level such as the maximum 

duration of the storage of a message in a waiting queue when that response is being used 

(PR05 - enqueue message for further automatic recovery). 

Example: 

The storage of a message submitted to business acknowledgement is linked to a 

maximum waiting time. This waiting time should be associated with a timer to awake the 





suspended processing (FB04 - no intervention - wait) and take complementary steps 

whenever the expected event has not arisen (in that case, return of the business 

acknowledgement). 

5.1.5 PR05: Enqueue message for further automatic recovery 

A safe storage of information may help in preparing further recovery where it has reached 

an identified level such as: 

� arrival of an information exchange regarding a checking failure into a given location; 

� positive checking of a submitted message; or 

� just before sending an information exchange. 

In each case, if the following processing fails, it will be possible to restart from the point 

of storage to resume the process. 

This solution element is a prerequisite for the business acknowledgement processing 

described below (PR06 - business acknowledgement). 

Example 1: 

When a submitted draft e-AAD arrives in the MSA of dispatch, it is convenient to 

securely store it before starting its formal checking; therefore, in case of breakdown 

during the checking (e.g. sudden unavailability of resources), the checking can be 

resumed when the failure is corrected. 

Example 2: 

When a submitted e-AAD has been found valid but before allocating the ARC, it is 

convenient to securely store it before starting the allocation of the ARC and performing 

the related actions; therefore, in case of breakdown during these actions (e.g. sudden 

unavailability of resources), they can be resumed when the failure is corrected. 

Example 3: 

When a valid e-AAD is ready to be sent to the MSA of destination, and in connection 

with the required business acknowledgement, it is convenient to securely store it before 

sending it and until the business acknowledgement arrives. This makes it possible to 

replay the information exchange if neither positive nor negative acknowledgement has 

been received in a given time limit. 

5.1.6 PR06: Business acknowledgement 

It is important for the EMCS business to ensure that an Information Exchange will not be 

lost between two MSAs because of a failure or because of a too long transmission delay. 

This is particularly uneasy to discover. 

It is therefore essential, at least for the essential Information Exchanges, that the sending 

MSA has a confirmation that the recipient MSA has correctly received and processed that 

exchange. 

The solution element, named business acknowledgement, consists in a positive 

acknowledgement message (ACK) sent back to the issuing MSA. This message 

acknowledges that: 





� the recipient MSA has correctly received the sent Information Exchange; 

� it has already completed the actions pursuant to it or it commits itself to complete 

these actions. 

This response has the drawback to add a part of traffic into the Common Domain 

network. Therefore it has not been made systematic and is reserved to very essential 

business processes. Appendix B gives the list of the Information Exchanges to be covered 

by a business acknowledgement. 

Example: 

If a report of receipt is sent by the MSA of destination to the MSA of dispatch. This is of 

high importance for the economic operators and deserves a specific detection mechanism. 

So, an MSA of dispatch receiving a validated report of receipt should acknowledge the 

receipt of the report of receipt as soon as it has received and identified it. 

5.1.7 PR07: Follow-up ‘open’ information 

If a business process is not completed in due time, a movement may remain in an 

unsolved state (that is to say, it will never reach a final state such as delivered, 

cancelled…). To reduce the risk that a movement remains indefinitely open, detection of 

such cases is necessary. 

The FESS [R6] provides for some mechanisms to be implemented at international level; 

it is highly recommended that Member States complete them at national level. 

Example: 

If a report of receipt is not submitted by the expected date of delivery, the MSA of 

dispatch sends a signal to the consignor and to the MSA of destination so that they 

undertake relevant actions, to establish where and in which state the goods are and to 

remind the relevant actor that recovery actions are necessary. 

5.2 Administrative procedures 

AP01 Enquire on information 

AP04 Broadcast information on unavailability 

AP05 Perform internal controls 

AP06 Take a business decision 

AP07 Transfer issue to support 

AP08 Exchange information outside EMCS 

Administrative procedures serve the following purposes: 

� further document an exception after it has been detected; 

� refer to any procedure which leads to a decision about how to proceed further: asking 

for more information, asking for a correction; this includes enquiries (if more 

information is needed) or sharing of information (if other concerned parties must be 

informed). 





In general, when an exception is fully documented, this normally leads to a business 

decision resulting in the application of a fallback and/or a recovery solution. 

5.2.1 AP01: Enquire on information 

If expected information is not received by an organisation at a specific location, this 

organisation will enquire on the whereabouts of the missing information. By organisation, 

one must understand any MSA or any economic operator. 

This may be achieved, where possible, by using the standard functionality of EMCS such 

as remote consultation of movement data (UC2.51, UC2.52) or administrative 

cooperation (UC3.07), but getting information may have to be achieved outside EMCS. 

Example: 

If, upon validation of an e-AAD, the excise number of an economic operator is found not 

existing, it is the responsibility of the consignor to query his partner to get the correct 

information. 

5.2.2 AP04: Broadcast information on unavailability 

Whenever an actor is unable to communicate with other actors or to perform some 

functions, that actor should notify that unavailability to its partners, preferably 

announcing the anticipated time to recover. 

This allows, in particular, planning interruption of services for maintenance purpose. 

For what concerns the communication over the Common Domain, this is achieved 

through a particular use case (UC0.07). 

It is recommended that each MSA provides for administrative procedures to manage the 

planned unavailability of economic operators. 

Example 1: 

If a given MSA plans an interruption of a part of EMCS functions, it must notify the 

other Administrations through UC0.07; consequently, the other MSAs have then to take 

the relevant fallback provisions such as to enqueue all messages they would have to send 

and adapt the management of deadlines consequently. 

Example 2: 

A given MSA may provide that, whenever an economic operator observes that he will not 

be in a position to submit nor receive electronic messages for a given period, he must 

notify this to the MSA so that it can take the relevant provisions. 

This may be a prerequisite for an economic operator using the fallback forms without 

prior attempt of electronic submission (which does not exempt him from further 

electronic recovery). 

5.2.3 AP05: Perform internal controls 

Each MSA applies administrative procedures to analyse exceptions after they have 

occurred, and to determine their cause. 





These procedures aim at ensuring a posteriori that an exception does not result from fraud 

or fraud attempt. 

They should be applied at least in all the cases where an exception is assumed to be a 

result of a (possible) human mistake/error, and any time they are deemed necessary by 

the administration in charge. 

Example: 

If a change of destination is issued by the consignor for an e-AAD that has already been 

discharged, the business process is rejected. It is then up to the MSA of dispatch to 

examine the case and to enquire on the actual situation, whether it is an error or an 

attempt of fraud. 

5.2.4 AP06: Take a business decision 

In EMCS, when processing a movement encounters an exceptional situation that prevents 

it from running its business in the expected way, a decision on the course of action judged 

best adapted to this situation will first have to be taken. 

This decision will be based on the available information. This may comprise, but is not 

limited to: 

� the causes of the exception, and how long it is expected to last; 

� the nature of the movement; 

� the quality of the business relationship with the trader; 

� the time constraints; 

� the availability of fallback solution(s). 

Example: 

If the consignee did not issue a report of receipt and, after enquiry, the consignor 

observes that the goods are still moving far from the place of delivery, he decides to 

change the destination, possibly to return goods at the place of dispatch. 

5.2.5 AP07: Transfer issue to support 

Upon any event such as negative result of the validation of received data against existing 

information, an MSA application may find it impossible to continue the processing and 

reports the error to the persons in charge of the operation of the system, either economic 

operators or officials. 

The causes may be obscure for these persons, in particular in case of de-synchronisation 

between the IT systems of economic operators and/or the MSA application databases. 

Sometimes, the actual error is the result from previous undetected errors, which makes it 

necessary to undertake real enquiries inside the system. 

In such cases, and after having verified the consistency of the data at his disposal, the 

concerned person is entitled to warn the National Service Desk, so that the latter 

investigates and determines appropriate actions to be undertaken to solve the issue. 





Example: 

At validation of an e-AAD, a given data item is found incorrect by the MSA of dispatch, 

whereas the consignor did fill the corresponding fields correctly according the reference 

information he knows. 

The MSA of dispatch rejects the draft e-AAD on the basis of its current reference data 

and sends an error message to the consignor. 

The consignor should first verify that he has given the correct information then he should 

report the issue to the support of his national service desk. 

5.2.6 AP08: Exchange information outside EMCS 

This solution element is to be used each time that an economic operator needs to transfer 

information that another economic operator may provide and either the transmission 

channel through the economic operators does not work or there is no need to bother the 

MSAs with such data flows. 

The transmission channel is completely defined by bilateral agreement between economic 

operators. 

Example: 

If, upon request of explanation on a delay in the submission of the report of receipt, a 

consignor is unable to send the relevant message explaining the delay to the MSA of 

dispatch, he can send the information directly to the consignee who can then send them to 

the MSA of destination, if found relevant. 

5.3 Fallback solution elements 

FB01 Use alternate communication medium 

FB02 Revert to manual without subsequent input 

FB03 Revert to manual with subsequent input 

FB04 No intervention – wait 

FB06 Notify administration 

FB08 Notify economic operator 

Fallback solution elements are required to allow the continuation of operations when an 

exception is encountered, and to avoid delaying urgent excise business. 

If it is judged that the business can wait until full restoration of the normal working 

conditions, a „No intervention – Wait‟ response is also available. 

Depending on the nature of the fallback solution, it has or does not have to be followed 

by a recovery procedure. If it is the case, this is explicitly mentioned in the description of 

the solution. 





5.3.1 FB01: Use alternate communication medium 

If the communication medium normally used for an information exchange becomes 

unavailable, another communication medium may be used to complete this information 

exchange. 

A communication medium, able to bear structured electronic information (such as an 

electronic form transferred through e-mail, or a web interface), will be used as a part of 

the normal electronic processing. The security aspects of the information exchanges (both 

normal and fallback, including e-mails) shall be catered at national level. 

This covers exclusively communication channels that support interconnection with the 

normal EMCS processing. Other communication means such as a fax are excluded from 

that solution element. Successful use of another communication medium exempts the 

economic operator from any recovery actions. 

Note: Optical Character Recognition (OCR) may be considered as a possible solution to 

extract information from images, but not reliable enough to be entered into the EMCS 

application. However, the extracted information might be used by an MSA as input to 

preliminary automated risk assessment. 

In contrast, any set of information that can be considered structured enough to be inserted 

into the EMCS application must be regarded as an alternative communication means and 

does not belong to the paper fallback system; this is in particular the case of electronic 

forms. 

This solution element must be preferred to fallback to paper each time that it is possible. 

This response does not apply to normal CCN/CSI communication, except for the 

management and dissemination of SEED data that is felt important enough to justify 

redundancy of communication media. 

Example 1: 

If the normal communication medium used between a consignor and his MSA is a file 

attached to an e-mail, an alternative solution, among other possibilities, is a website 

where the consignor directly enters data into a form. 

Example 2: 

Each MSA may have a preferred channel to - in particular - receive the SEED updates; 

however, it should be ready to revert to another solution in case of (long lasting) 

unavailability of that channel. 





5.3.2 FB02: Revert to manual without subsequent input 

If an automated business process becomes unavailable, it is possible to carry out 

manually the equivalent operations. No subsequent data input is then required (no 

recovery needed). This is the case if the faulty process does not normally result in an 

update of the e-AAD, or if the lack of update is judged acceptable, from a business point 

of view. 

Example: 

If automatic risk assessment is unavailable, instead of waiting for the resources to 

recover, it is more efficient to exercise it manually. 

5.3.3 FB03: Revert to manual with subsequent input 

If an automated business process becomes unavailable (e.g. due to a software or a 

hardware failure or in case of scheduled unavailability for maintenance), the equivalent 

operations are first carried out manually. 

This is in particular the object of the paper fallback procedures described in Chapter 6. 

To ensure completeness of the EMCS processing, the standard electronic operations have 

then to be completed in deferred mode. 

Technically, the only difference between the normal submission and the deferred 

submission is the initial submission of an e-AAD. In all other cases, normal mode and 

deferred mode are identical. 

Example: 

If submission of an e-AAD proves unavailable (although its availability requirement is 

permanent), the consignor ought to delay the electronic submission as much as possible. 

However, business constraints make that the actual dispatch of goods cannot be delayed. 

Consequently, the goods will have to leave before a valid e-AAD exists. A fallback AAD 

has then to be made to allow the goods moving under the cover of the Excise Number of 

the consignor plus the Local Reference Number of the consignment. 

It becomes then mandatory to submit the corresponding e-AAD as soon as the function 

becomes available again. 

5.3.4 FB04: No intervention – wait 

When an exception impacts business processes that are not critically time-dependent and 

when the anticipated delay does not exceed the acceptable limit for the related functions, 

the normal response is to wait until the cause of the exception has been suppressed, and 

the normal procedure can be used. 

The economic operator chooses to use this response any time the expected delay is 

judged acceptable, or if, for business reasons, regular EMCS procedures are preferred to 

fallback procedures. 





No recovery is then needed. 

Note: at dispatch, if the expected delay exceeds up to a few hours, this being not judged 

acceptable by the trader, the latter has to use an alternate way to communicate the 

movement information to the excise office (see FB01) before departure of the goods. 

Example: 

If submission of the report of receipt is temporarily unavailable, the consignee, based on 

the rules established by its Administration, may consider it acceptable to wait a few hours 

(or even up to one to two days before considering reverting to fallback paper procedures) 

before submitting it. This would have little impact on the excise business. 

5.3.5 FB06: Notify administration 

This response exclusively addresses the communication between an economic operator 

and his national Administration. Consequently, its detailed definition depends on national 

provisions. 

The transmission channel may be any solution found relevant by the MSA, such as: 

� access to a support Web portal; 

� e-mail; 

� fax; 

� phone call to a help desk; 

� SMS to a dedicated number; 

� etc. 

This amounts to an anticipated announcement that, during the indicated period, the 

economic operator could directly use alternate solutions (typically, fall back to paper) 

without trying the standard solution. 

Example: 

In case of a long-lasting unavailability of the IT system of an economic operator, this 

latter impacts business processes that are critically time-dependent. 

The economic operator may be required to inform the competent Administration of the 

nature and conditions of the exception. 

This information should contain at least: 

� list of the unavailable functions; 

� expected time to recover. 

Typically, during that period, a consignor may be allowed to directly use the fallback 

AAD without trying an electronic submission that will surely fail. 

Conversely, as the time constraint for the submission of a report of receipt is not very 

stringent, the consignee should preferably wait for the electronic system to recover to 

submit a report of receipt. 





5.3.6 FB08: Notify economic operator 

That response exclusively addresses the communication between an Administration and 

an economic operator of its Member State. Consequently, its detailed definition depends 

on national provisions. 

In all cases where a severe exception arises that necessitates the collaboration of an 

economic operator, the competent Administration contacts that operator to establish the 

relevant actions. 

The transmission channel may be any solution found relevant by the MSA, such as: 

� e-mail; 

� fax; 

� SMS to a registered number; 

� etc. 

Example: The application of the MSA of dispatch starts a timer (for example, 

TIM_CHS) to expire in a given time limit by which the consignor is expected to issue 

either a change of destination or a splitting. If no such operation has been submitted 

within the time limit, the MSA shall issue a reminder notification to the consignor. If this 

reminder is not electronically implemented by the NEA then the MSA can send the 

reminder outside the system via any of the above mentioned means (such as, e-mail, fax, 

or SMS to a registered number, etc). 

5.4 Recovery solution elements 

RC03 Restart or replace technical component 

RC04 Enter data using the normal procedure 

RC05 No intervention - accept exception 

RC06 Collate electronic record with the fallback form 

RC07 Replay information exchange 

RC10 Re-apply undone changes 

Recovery solution elements are used to correct defective information or to complete 

missing information resulting from errors that have occurred in the system, from mistakes 

made by users, or from the application of fallback solutions. 

If it is considered that the business impact of an exception is acceptable, a „No 

intervention – accept exception‟ solution is also available. 

5.4.1 RC03: Restart or replace technical component 

If some component necessary to complete a business process is found unavailable or 

faulty, processing cannot carry on any more. The failing component must be restarted or 

replaced as soon as possible. 





Example: 

If the processing of information includes access to a database that is currently locked or 

has fallen out, the business process becomes unavailable. The database, possibly a backup 

copy, must be restarted as soon as possible. 

5.4.2 RC04: Enter data using the normal procedure 

After fallback solution has been used, enter missing data in EMCS using a standard use 

case. 

This is in particular, but not exclusively, the normal recovery solution each time a 

fallback form has been used. 

From the point of view of the functioning of EMCS, this solution element must be 

considered the best one as it restores a completely normal situation. 

This solution must be applied as soon as possible to complete the EMCS processing. 

Example: 

Following the issuance of a fallback AAD, the consignor is committed to submit the e- 

AAD itself in deferred mode, as soon as this becomes technically possible. 

5.4.3 RC05: No intervention – accept exception 

In several cases, an exception is simply accepted without any direct attempt to correct it. 

This will happen in the following situations: 

1. the business impact of the exception is not critical and can be accepted; 

2. the EMCS movement has reached an irreversible state and the exception cannot be 

corrected. 

Example: 

If a consignee repeatedly fails in trying to submit an alert with or without rejection, he 

may choose to give up with that use case and not even inform the consignor of what 

finally appears minor or becomes unnecessary, for instance if the consignor has 

spontaneously changed the destination in the meantime. 

5.4.4 RC06: Collate electronic record with the fallback form 

In some cases, it is necessary to use a fallback form. With a very few exceptions, the 

operations covered by fallback forms have to be electronically recovered as soon as 

possible when the incident that caused the fallback is closed. 

The MSA of the economic operator who submitted the fallback form is entitled to 

compare the electronic record with the information contained in the fallback form to 

verify their consistency. 

In case where differences are found, the discrepancies fall under national provisions of 

the MSA of the concerned economic operator. The processing of EMCS continues with 

the electronic information. 





Examples: 

If a fallback AAD has been submitted by a consignor, this latter is required to submit the 

e-AAD in deferred mode as soon as the failing resources have recovered. Upon receipt of 

an e-AAD submitted in deferred mode, an excise officer of the MSA of dispatch may (1) 

verify that the consignor has actually submitted a fallback AAD form and (2) compare 

the contents of the e-AAD with the contents of the fallback AAD. 

5.4.5 RC07: Replay information exchange 

In cases where a message seems lost between an economic operator and his MSA or 

between two MSAs, a part of recovery may be to send again the (possibly) lost message. 

This can be done several times depending on an acceptable limit to be defined by the 

concerned Member State(s). As far as possible, this limit should be an updatable technical 

parameter allowing to adapt the number of retries to the current situation, for instance a 

network overload should be mitigated by reducing the number of retries. 

5.4.6 RC10: Re-apply undone changes 

This response follows a prior undo preceding operation (FB09) followed by 

rectifications; this consists in restoring the local state of the concerned object. 

Unless explicitly described, no rectifying Information Exchange has to be sent to other 

partners. 




Paper fallback system 

6 Paper fallback system 

6.1 Overview 

By paper fallback system, one must understand: 

� a set of fallback forms that, depending on the case, are not necessarily printed on 

paper; and 

� a series of procedures for the use of these forms. 

Each partner, and in particular the consignor, should as much as possible avoid making a 

fallback form; this implies: 

� using electronic alternate communication means each time that it is possible, 

preferably to the paper fallback system, as described in FB01 - Use alternate 

communication medium; 

� waiting until the extreme time limit before issuing a fallback form; this applies not 

only to the submission of the e-AAD but to all other main business cases described in 

point 6.5 as well; consequently, and given the acceptable delays in each case, only the 

fallback AAD and the fallback interruption notification are considered really likely to 

be submitted (and the fallback cancellation where no recovery is necessary). 

This chapter describes the administrative circuits of the paper fallback system applicable 

when EMCS may become unavailable, corresponding to fallback solution elements, 

mainly FB03 - Revert to manual with subsequent input and secondarily FB02 - 

Revert to manual without subsequent input. 

It lists roles and responsibilities, depending on the location of occurring exceptions, and 

depicts the associated relevant procedures. 

It considers next how to recover from the forms to the computerised procedures. 

6.2 Roles and responsibilities 

The figure below represents the summary of an EMCS information flow between a 

consignor and a consignee. 

consignor 

A 

B C D 

MSA of dispatch 

(Excise officer) 

MSA of destination 


Figure 2 e-AAD management information flows 

consignee 

Exceptions related to EMCS unavailability can occur in the following locations: 

� consignor‟s premises (A); 

� MSA of dispatch (B); 





� MSA of destination (C); 

� consignee‟s premises (D). 

According to the use case and to the location, occurrences of such exceptions have very 

different impacts on EMCS business. 

The paper fallback procedures are described considering that EMCS may become 

unavailable in any of the locations depicted above. 

6.2.1 Unavailability at consignor’s premises (location A) 

Unavailability of EMCS at consignor‟s premises must not prevent the sending of the 

consignment. 

On the other hand, any dispatch of goods under excise suspension must be communicated 

to the MSA of dispatch. 

Therefore, it will be the responsibility of the consignor to inform the MSA of dispatch 

before the beginning of the movement of the unavailability of EMCS and use the relevant 

fallback administrative circuit depicted in point 6.5 for submission of the AAD (point 

6.5.1) and any other business purpose (points 6.5.2, 6.5.4 and 6.5.5) and to re-issue as 

soon as the application is available again the equivalent electronic operations. The MSA 

of dispatch may also require a copy of the fallback AAD and appropriate information on 

the reasons for the unavailability before the beginning of the movement. 

6.2.2 Unavailability at MSA of dispatch (location B) 

Unavailability of EMCS at MSA of dispatch should not prevent the sending of the 

consignment by the consignor. On the other hand, any dispatch of goods under excise 

suspension must be communicated to the MSA of dispatch before the beginning of the 

movement. The MSA of dispatch may also require a copy of the fallback AAD before the 

beginning of the movement. 

Therefore, economic operators will have to follow paper procedures directly with their 

excise office (procedures to be started after a certain time depending on the case and to be 

decided by the MSA). 

6.2.3 Unavailability at MSA of destination (location C) 

The excise office at destination receives movement related fallback form from MSA of 

dispatch (in case of unavailability of EMCS at MSA of dispatch). 

In case of unavailability of EMCS at MSA of destination, the paper circuit should not 

prevent receiving the consignment by the consignee. On the other hand, any receipt of 

goods under excise suspension must be communicated to the MSA of destination, except 

in duly justified circumstances, using a paper document containing the same data as the 

report of receipt. 

Therefore, in case of EMCS unavailability at MSA of destination, economic operators 

will have to follow fallback procedures directly with their excise office (procedures to be 

started after a certain time depending on the case and to be decided by the MSA). 





6.2.4 Unavailability at consignee’s premises (location D) 

The consignee must communicate any receipt of goods under excise suspension to the 

MSA of destination, except in duly justified cases, using a paper document containing the 

same data as the report of receipt. Whether the consignee is entitled to simply wait for the 

IT system becoming available and the length of the waiting period itself will thus depend 

on the general instructions of its MSA on how to react to the situation. 

6.3 Fallback paper forms 

The current AAD described in the Commission Regulation 2719/92 on the accompanying 

administrative document for the movement under duty-suspension arrangements of 

products subject to excise duty shall become obsolete with the entry into operation of 

EMCS (Functional Stage 1) by all the Member States. It will be replaced by the 

electronic records. 

To support the fallback system, a set of paper documents containing the same data as the 

corresponding EMCS messages will have to be used. These data shall be displayed in the 

form of data elements, expressed in the same manner as in the corresponding electronic 

messages. All the data elements, as well as the data groups and data subgroups to which 

they belong, shall be identified by means of the numbers and letters in column A and 

column B of Table 1 of Annex I to the Commission Regulation implementing Council 

Directive 2008/118/EC on the general arrangements for excise duty with regard to the 

computerised procedures for the movement of excise goods under a duty suspension 

arrangement, which is under preparation. 

6.4 Fallback communication media 

The fallback forms are exclusively reserved to cases where the information has to be 

carried by paper-like supports such as (by decreasing order of preference): 

� free text e-mail; 

� fax; 

� paper (sent by regular mail, or handed directly to the person). 

However, according to ESS Security policy [R1], proper means must be put in place to 

ensure confidentiality of data exchanged between partners (traders, MSAs). 

On the other hand, where fax would be preferred to e-mail as a medium, this requires the 

management of up-to-date fax directories. 

In any case, when a paper fallback takes place, the information should then be re-entered 

in the system, as soon as it becomes available again. 





6.5 Main business cases fallback procedures 

6.5.1 Submission of AAD 

(original) 

AAD 

form 

� 

consignor 

� 

(copy) 

AAD 

form 

AAD 

form 

� 

� 

(mail/fax) 

AAD 

form 



consignee 

(mail/fax) 




� 

� 

AAD 

form 

Figure 3 Submission of AAD – fallback administrative circuit 

The procedure associated with the circuit above is as follows: 

1. the consignor fills in relevant fields of the fallback AAD form (cf. UC2.01– 

submission and registration of e-AAD); in particular, he assigns a Local Reference 

Number (LRN), being a serial number, to the AAD to serve as reference as long as 

there is no ARC assigned by the IT system; 

2. the consignor informs the MSA of dispatch or, if required by that MSA, sends it a 

copy of the fallback AAD form prior to dispatch of the goods or, in case of 

unavailability of means of communication, as soon as they become available again. If 

the consignor is responsible for the unavailability, the MSA of dispatch may also 

require appropriate information on the reasons for the unavailability before the 

beginning of the movement; 

3. as far as possible, the MSA of dispatch may apply risk assessment and if required 

submits a request for assistance to the MSA of destination; 

4. it is up to the consignor to judge whether he sends a copy of the AAD form to the 

consignee; 

5. if considered useful, the MSA of dispatch sends a notification to the MSA of 

destination; 

6. as the fallback AAD has to accompany the goods, the consignor gives a paper copy of 

it to the accompanying person.




6.5.2 Cancellation of AAD 

(original) 

CAN 

form 

� 

consignor 

CAN 

form 

� 

(mail/fax) 

AAD 

form 



� 

consignee 

(mail/fax) 




� 

AAD 

form 

Figure 4 Cancellation of AAD – fallback administrative circuit 


1. the consignor fills in the fallback cancellation notification form; 

2. the consignor sends a copy of the form to the MSA of dispatch; the goods must not 

have left the place of dispatch; 

3. it is up to the consignor to judge whether he sends a copy of the form to the 

consignee; 

4. if considered useful, the MSA of dispatch sends a copy of the form to the MSA of 

destination. 

6.5.3 Report of receipt 

(original) 

RoR 

form 

� 

consignee 

(mail/fax) 

RoR 

form 

� 

(mail/fax) 

RoR 

form 

(mail/fax) 

RoR 

form 


(Excise officer) MSA of dispatch 

(mail/fax) (Excise officer) 

� 

consignor 

� 

� 

RoR 

form 

Figure 5 Report of receipt – fallback administrative circuit 


1. the consignee fills in relevant fields of the fallback report of receipt form 

(cf. UC2.06–submission of report of receipt); 

2. the consignee sends a copy of the form to the MSA of destination; 

3. except where the report of receipt can be submitted promptly, or in duly justified 

cases, the MSA of destination sends a copy of the form to the MSA of dispatch; 

4. the MSA of dispatch shall forward a copy of the form to the consignor or keep it 

available for him;




5. it is up to the consignee to decide if he will send a copy of the fallback report of 

receipt form to the consignor. 

6.5.4 Change of destination 

(mail/fax) 

CoD 

form 

CoD 

form 

(former) 

� 

consignor 

consignee � 

(copy) � (mail/fax) 

AAD 

form 

AAD 

form 

updated 

AAD 

form 

� � 

(new) 

consignee 



(mail/fax) 

(mail/fax) 

(former) 






� 

� 

CoD 

form 

AAD 

form 

Figure 6 Change of destination – fallback administrative circuit 


1. the consignor fill in the relevant fields of the CoD form (cf. UC2.05-Change of 

destination) and sends it to the MSA of Dispatch; 

2. if possible the MSA of dispatch may apply risk assessment on the fallback updated 

AAD form and if required submits a request for assistance to the new or former MSA 

of Destination; 

3. it is up to the consignor to judge whether he sends a copy of the CoD form to the 

former consignee; 

4. it is up to the consignor to judge whether he sends a copy of the updated AAD form 

to the (new) consignee; 

5. if considered useful, the MSA of dispatch sends the CoD form to the (former) MSA 

of destination and the AAD form to the new MSA of destination; 

6. the consignor informs the carrier of the new destination (the latter may annotate the 

new destination information on the document that mentions the ARC of the e-AAD or 

on the fallback AAD).




6.5.5 Splitting 

(former) 

consignee 

� 

(mail/fax 

) 

CoD 

consignor 

� 

(copy) 

AAD 

AAD 

AAD 

form 

form 

form 

� 

AAD 

AAD 

CoD AAD form 

form 

form 

(mail/fax) 

AAD 

AAD 

AAD 

form 

form 

form 

MSA of dispatch CoD 


AAD 

AAD 

AAD 

form 

form 

form 

(new) 

consignees 

Figure 7 Splitting – fallback administrative circuit 


� 

� 

� 

All MSAs of destination 


The procedure associated with splitting is as follows: 

1. the consignor sends to the MSA of Dispatch: 

� a series of new fallback AAD forms with relevant fields filled in (cf. UC2.01 – 

submission and registration of e-AAD); in particular, each of these new AADs has 

its own (and new) LRN; 

� if the (former) consignee is not the consignee of any new part, a CoD form as well; 

2. if possible the MSA of dispatch may apply risk assessment to the splitting operation 

considered as a whole and if required submits a request for assistance to be sent to 

part or all of the new or former MSAs of destination; 

3. if the (former) consignee is not the consignee of any new part, it is up to the 

consignor to judge whether he sends a copy of the CoD form to him; 

4. for each new AAD form created from the split AAD, it is up to the consignor to judge 

whether he sends its copy to the intended (new) consignee; 

5. if considered useful, the MSA of dispatch sends a copy of the CoD form to the former 

MSA of destination and copies of the new AAD forms to each new MSA (of 

destination); 

6. the consignor informs each involved carrier of the new destinations (the carriers may 

annotate the new destination information on the document that mentions the ARC of 

the e-AAD or on the fallback AAD).




6.5.6 Interruption 

� 

� 

Interrupting MSA 


(mail/fax) 






Int. 

CoD 

(mail/fax) 

� 

Int. 

CoD 

Figure 8 Interruption – fallback administrative circuit 

The procedure associated with interruption is as follows: 

1. the interrupting MSA prepares a specific form, with “movement interrupted” clearly 

mentioned on it; in addition, this form bears on it: 

� the ARC of the movement to be interrupted; 

� the reference of the event or control report if any; 

2. the interrupting MSA sends this form to the MSA of dispatch and to the MSA of 

destination (no interested MSAs informed). 

6.5.7 Control 

� 

� 

MSA of Control 

(Control officer) 

(mail/fax) 

Control 

Report 

form 

(mail/fax) 

� 

Control 

Report 

form 





Figure 9 Control – fallback administrative circuit 

The procedure associated with a control is as follows: 

1. the MSA of control fills in the relevant fields of a control report form, including: 

� the ARC of the controlled movement; or 

� the excise number of the consignor plus the LRN, if the e-AAD has not been 

created yet; 

2. the MSA of control sends this control report form to the MSA of dispatch and to the 

MSA of destination (no interested MSAs informed).




6.5.8 Administrative cooperation 

� 

Requesting MSA 


� 

(mail/fax) 

ACO 

Request 

form 

Requested MSA 


Figure 10 Administrative cooperation – request for assistance 

The procedure associated with an administrative cooperation request for assistance is as 

follows: 

1. the requesting MSA fills in the relevant fields of an administrative cooperation 

request for assistance (ACO Request) form, including: 

� the ARC of the movement; or 

� the excise number of the consignor plus the LRN, if the ARC is unknown. 

2. the requesting MSA sends the administrative cooperation request for assistance (ACO 

Request) form to the requested MSA. 

� 

Requested MSA 

or issuing MSA 


� 

(mail/fax) 

ACO 

Results 

form 

Requesting MSA 

or addressed MSA 


Figure 11 Administrative cooperation – spontaneous information and reply to a request for 

assistance 

The common procedure associated with the reply to an administrative cooperation request 

for assistance or with spontaneous information is as follows: 

1. the Requested MSA (or issuing MSA) fills in the relevant fields of an administrative 

cooperation results (ACO Results) form; 

2. the Requested MSA (or issuing MSA) sends the administrative cooperation results 

(ACO Results) form to the requesting MSA or to the addressed MSA. 

6.6 Recovery from paper fallback procedures 

6.6.1 Means to recover 

After a paper fallback form has been sent for any function, electronic recovery is 

mandatory and has to be achieved, as much as possible, through the relevant standard use 

cases, namely: 

� submission of the e-AAD (UC2.01); 

� cancellation of an e-AAD (UC2.10); 

� submission of the report of receipt (UC2.06); 

� change of destination (UC2.05); 

� splitting (UC2.36); 





� exportation of goods (UC2.44, UC2.43) and exit of exported goods (UC2.46); 

� interruption of a movement (UC3.05); 

� submission of a control report (UC3.03); 

� issuance of a spontaneous information (UC3.01); 

� request for assistance (UC3.07). 

There is however one exception: at cancellation, if a fallback AAD has been made and 

provided that the e-AAD has not been submitted in the meantime, the fallback 

cancellation is considered sufficient to inform the MSA of dispatch that the movement 

will not take place and electronic recovery is unnecessary. 

6.6.2 Deferred mode 

Recovery through electronic input is said to be achieved in deferred mode. More 

specifically, the term “deferred mode” is used when the business event precedes the 

electronic operation (the submission of an e-AAD). In that case, the fact that the 

electronic operation (the submission of an e-AAD) is made in deferred mode must be 

made explicit so that the application, when checking the submitted e-AAD, relaxes the 

verification that the date of dispatch of goods announced in the e-AAD follows the actual 

date and time of submission. This has to be expressly specified at submission as follows: 

� the consignor inserts an explicit indicator "deferred submission" at submission of the 

e-AAD (message IE815); 

� if the indicator is set, the date and time of dispatch of the goods are not compared with 

the date and time of submission (i.e. the date and time of receipt of the message). 

In all other electronic operations no specific technical provisions are necessary. 

6.6.3 Summary of intermediate operations 

After a series of operations has been achieved through the fallback system, and 

depending on the scenario, it is possible for the consignor to summarise the movement at 

recovery by submitting only the latest state of the e-AAD. 

Typically, a fallback AAD of which destination has changed in fallback mode may be 

recovered directly by submitting the e-AAD with the final destination, without having to 

recover all intermediate business steps. This is true including where the first consignee 

has rejected the fallback AAD or refused the delivery before the change of destination. 

The only exception is where the first consignee has partially refused the delivery; in that 

case, the electronic recovery must be achieved in such a way that both partial and final 

reports of receipt are registered, namely: 

� the consignor submits the e-AAD with the first destination where the partial refusal 

has been done; 

� the consignee submits a report of receipt with partial refusal; 

� the consignor changes the destination with the second destination. 




Unavailability of SEED information 

7 Unavailability of SEED information 

SEED data are used in the MSAs for validation purpose (e.g. for draft e-AAD validation). 

They are: 

� partially managed and defined in each MSA ; 

� partially managed and defined in the Common Domain central services; 

� regularly updated from the Common Domain central services. 

Exceptions due to the unavailability of SEED information and of its dissemination 

channels may result in de-synchronisation of the databases among the Member States and 

could cause an abnormal number of calls to the support of the considered MSA. 

This may be mitigated by strong provisions: 

� reinforce the communication means between the Common Domain central services 

and each MSA, in both directions but more particularly from the Common Domain to 

the MSAs; 

� ensure simultaneous enforcement of the updates of SEED in the Member States, at 

logical level; 

� define the relevant by-pass procedures in the view of long lasting unavailability of the 

update of SEED (e.g. for one week); this includes being ready to handle an increased 

number of support calls; 

� define the conditions of a possible reversion to the paper fallback system during the 

same long lasting unavailability period; this should be driven by the very business 

need, each operation with weak time constraints such as the submission of a report of 

receipt should be delayed as much as possible. 

In addition, MSAs should put in place proper means to prevent locally unavailability of 

update services of SEED data. 




Specific provisions during the rollout of EMCS 

8 Specific provisions during the rollout of EMCS 

This chapter describes the specific provisions to be applied to the fallback and recovery 

procedures of EMCS during Migration Period 1 defined in the PSS [R3] namely: 

FS0/FS1 coexistence during Migration Period 1 (rollout of the FS1 functionality). 

This analysis is essentially based on the General Process Threads and Support Threads 

described in the Appendix A of the Phasing and Scope Specification (PSS). 

The exceptions and the related scenarios are described in the Appendix A of the PSS 

where they are explicitly addressed. These exceptions or scenarios are either specific to 

the migration periods or extended from the unavailability exceptions of the target system. 

It shall be noted that no specific provisions apply to the fallback and recovery procedures 

of EMCS during the operations of Phase 3, since according to the updated Master Plan 

[R7] there will be no co-existence of FS1 and FS2 (all MSAs will enter the EMCS Phase 

3 operations at milestone Mc). 

8.1 Fallback and recovery during Migration Period 1 

Most generally, the design of FS0/FS1 is intended to provide a full service to all 

movements that can be electronically submitted in a Member State in FS1, FS0 being 

exactly tailored to ensure the destination functionality. 

Therefore: 

� the fallback and recovery provisions that are defined in the FRS concerning the use 

cases included in FS1 are adequate to respond to the exceptions arising during the 

coexistence of FS0 and FS1; note in particular that the management of SEED and of 

reference data being a prerequisite to the migration milestone Ma, the related use cases 

are to be considered a part of FS0; 

� all complementary requirements attached to these exceptions must be considered an 

integral part of FS0 or of FS1, according to the EBP where the exception arises. 

In addition, a few particular cases deserve setting up temporary responses. 

8.1.1 Unavailability of the automatic triggering of risk assessment 

The automatic connection with the risk assessment functionality is not included in FS1; 

until the concerned MSA is in FS2, it is replaced by a manually triggered fallback risk 

assessment that may result in fallback administrative cooperation exchanges. 

This is not really an exception; however it has been explicitly mentioned in the Appendix 

A for all application points of risk assessment in all use cases of the FESS [R6] that 

belong to FS1. 

8.1.2 Exportation of goods in an MSA different from the MSA of dispatch 

The exportation functionality is supported through three use cases, all of which are 

assigned to FS1 (no EBP has been included in FS0). 





There are two possible combinations: 

� a simple sequence of use cases UC2.44 and UC2.46, both being in the same Member 

State of dispatch/export; for what concerns the Migration Period 1, either the 

consignor is in FS0 and the current paper AAD continues being used, or he is in FS1, 

hence the MSA is in FS1 and the whole process may be completed electronically; 

� a more complex sequence involving UC2.01 in the MSA of dispatch and UC2.43 and 

UC2.46 in the MSA of export; these two MSAs are most frequently the same one, but 

they can be different as well; so, the following concerns exclusively the case where the 

MSA of export is different from the MSA of dispatch. 

When the MSA of dispatch is in FS1 then an e-AAD is likely to be electronically 

submitted, however the MSA of export may be still in FS0 hence unable to achieve the 

electronic exportation use case. 

Such a combination must then be prevented. 

This may be detected at validation either of the submitted e-AAD, or of a change of 

destination. A guideline of the PSS (GP 5) provides that each MSA must be permanently 

informed in which Functional Stage each other MSA is. 

So, a temporary checking is to be inserted in the validation process of UC2.01 and of 

UC2.05, to reject any destination at export of which Functional Stage is FS0. The 

rejection is then sent back to the consignor who, possibly with the assistance of his 

national support, may find another Member State where export may be completed, 

normally the MSA of dispatch itself. 

8.1.3 Unavailability of the control report 

Currently, the results of a control are to be registered in box A of the AAD document. 

That AAD is planned to disappear as soon as there is an e-AAD, i.e. as soon as the 

consignor is able to submit it (FS1). However, the electronic control report is not 

included in FS1 but only in FS2. 

This makes that, from the time where the consignor may submit an e-AAD (FS1) to the 

time where all Member States are in FS2, there will be situations where a control officer 

is unable to register the results. 

Consequently, a temporary fallback scenario is proposed, based on the fallback control 

form of the paper fallback system. 

8.1.4 Unavailability of the event report 

The registration of an event report is not included in FS1 but only in FS2. Contrary to the 

control report, the event report is a new feature of EMCS and its registration may be 

delayed until the involved MSAs are in FS2. Temporary fallback solutions are however 

described for the cases where only a part of these MSAs are in FS2. 





8.1.5 Interruption of a movement 

The interruption of a movement is not included in FS1 but only in FS2. However the 

business need exists both at business level and at technical level where there is no 

business way to close a movement. 

A specific exception addressing the permanent unavailability of the interruption use case 

is therefore defined.

Fallback and Recovery Specification (FRS)

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?