Fallback and Recovery Specification (FRS)
Fallback and Recovery Specification (FRS)
Fallback and Recovery Specification (FRS)
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
OWNER<br />
DG TAXUD<br />
ISSUE DATE<br />
01/12/2009<br />
TAXATION AND CUSTOMS UNION DG<br />
EMCS COMPUTERISATION PROJECT<br />
PHASE 2<br />
SUBJECT:<br />
Framework Contract: TAXUD/2008/CC/095<br />
VERSION<br />
3.11-EN<br />
<strong>Fallback</strong> <strong>and</strong> <strong>Recovery</strong> <strong>Specification</strong> (<strong>FRS</strong>)<br />
ECP2-FITSDEV2-SC03-<strong>FRS</strong>
DG TAXUD – EXCISE COMPUTERISATION PROJECT REF: ECP2-FITSDEV2-SC03-<strong>FRS</strong><br />
FALLBACK AND RECOVERY SPECIFICATION (<strong>FRS</strong>) VERSION: 3.11-EN<br />
[This page has been left intentionally blank.]<br />
ECP2-FITSDEV2-SC03-<strong>FRS</strong>v3.11.doc Page 2 of 53
DG TAXUD – EXCISE COMPUTERISATION PROJECT REF: ECP2-FITSDEV2-SC03-<strong>FRS</strong><br />
FALLBACK AND RECOVERY SPECIFICATION (<strong>FRS</strong>) VERSION: 3.11-EN<br />
DOCUMENT HISTORY<br />
Document History<br />
Edi. Rev. Date Description Action (*) Pages<br />
0 00 08/05/2004 Create I All<br />
0 01 20/08/2004 Corrected Chapter 6 U 34 +<br />
0 02 20/08/2004 Added paragraph 7.1 U 36+<br />
0 03 22/08/2004 Added paragraph 7.1.2 U 36+<br />
0 04 01/10/2004<br />
Updated after SEVE quality<br />
review, SfR<br />
U All<br />
0 05 10/11/2004 SfR visibility check point U All<br />
0 06 30/11/2004 SfR visibility check point U All<br />
0 07 21/01/2005<br />
Updated after SEVE quality<br />
review, SfR<br />
U All<br />
1 00 21/03/2005 Updated for SfA U All<br />
1 01 18/04/2005 SfA v 1.b U All<br />
1 02 29/04/2005 SfA verification U All<br />
1 03 17/03/2006 Updated for internal review U All<br />
1 04 20/03/2006 Updated after MS comments U All<br />
1 05 27/03/2006 SfR U All<br />
2 00 04/05/2006 SfA U All<br />
2 11 02/07/2007 Internal review, SfR U All<br />
3 00 30/07/2007 SfA U All<br />
3 01 18/01/2008<br />
Incorporating changes imposed<br />
by the Trigger Nb #159.<br />
Submitted for review to<br />
Taxation <strong>and</strong> Customs Union<br />
DG.<br />
ECP2-FITSDEV2-SC03-<strong>FRS</strong>v3.11.doc Page 3 of 53<br />
U<br />
As<br />
Required
DG TAXUD – EXCISE COMPUTERISATION PROJECT REF: ECP2-FITSDEV2-SC03-<strong>FRS</strong><br />
FALLBACK AND RECOVERY SPECIFICATION (<strong>FRS</strong>) VERSION: 3.11-EN<br />
DOCUMENT HISTORY<br />
3 02 25/02/2008<br />
3 03 07/03/2008<br />
3 04 28/05/2008<br />
3 05 25/06/2008<br />
3 06 25/02/2009<br />
3 07 02/04/2009<br />
Submitted for Acceptance to<br />
Taxation <strong>and</strong> Customs Union<br />
DG.<br />
Re-Submitted for Acceptance<br />
to Taxation <strong>and</strong> Customs<br />
Union DG.<br />
Incorporating changes imposed<br />
by the RFA Nb #178.<br />
Submitted for review to<br />
Taxation <strong>and</strong> Customs Union<br />
DG.<br />
Submitted for Acceptance to<br />
Taxation <strong>and</strong> Customs Union<br />
DG.<br />
Incorporating changes imposed<br />
by the RFA Nb #234. More<br />
specifically:<br />
� Implementing <strong>FRS</strong><br />
v3.05 WDs.<br />
� Performing alignment<br />
with revised MAP<br />
(CED 529).<br />
� Performing alignment<br />
with revised Directive<br />
(2008/118/EC).<br />
Submitted for review to<br />
Taxation <strong>and</strong> Customs Union<br />
DG.<br />
Incorporating Reviewers<br />
Comments.<br />
Submitted for Acceptance to<br />
Taxation <strong>and</strong> Customs Union<br />
DG.<br />
ECP2-FITSDEV2-SC03-<strong>FRS</strong>v3.11.doc Page 4 of 53<br />
U<br />
U<br />
U<br />
U<br />
I, U<br />
U<br />
As<br />
Required<br />
As<br />
Required<br />
As<br />
Required<br />
As<br />
Required<br />
As<br />
Required<br />
As<br />
Required
DG TAXUD – EXCISE COMPUTERISATION PROJECT REF: ECP2-FITSDEV2-SC03-<strong>FRS</strong><br />
FALLBACK AND RECOVERY SPECIFICATION (<strong>FRS</strong>) VERSION: 3.11-EN<br />
DOCUMENT HISTORY<br />
3 08 06/04/2009<br />
3 09 04/11/2009<br />
3 10 20/11/2009<br />
3 11 01/12/2009<br />
Incorporating DG TAXUD's<br />
verification comments.<br />
Submitted for information to<br />
DG TAXUD.<br />
Updated after MS comments.<br />
Submitted for review to<br />
Taxation <strong>and</strong> Customs Union<br />
DG.<br />
Incorporating Reviewers<br />
Comments.<br />
Submitted for Acceptance to<br />
Taxation <strong>and</strong> Customs Union<br />
DG.<br />
Incorporating DG TAXUD's<br />
verification comments.<br />
Submitted for information to<br />
DG TAXUD.<br />
(*) Action: I = Insert, R = Replace, U = Update, D = Delete<br />
ECP2-FITSDEV2-SC03-<strong>FRS</strong>v3.11.doc Page 5 of 53<br />
U<br />
U<br />
U<br />
U<br />
As<br />
Required<br />
As<br />
Required<br />
As<br />
Required<br />
As<br />
Required
DG TAXUD – EXCISE COMPUTERISATION PROJECT REF: ECP2-FITSDEV2-SC03-<strong>FRS</strong><br />
FALLBACK AND RECOVERY SPECIFICATION (<strong>FRS</strong>) VERSION: 3.11-EN<br />
TABLE OF contents<br />
Table of contents<br />
DOCUMENT HISTORY ..................................................................................................................................... 3<br />
TABLE OF CONTENTS ...................................................................................................................................... 6<br />
1 INTRODUCTION ......................................................................................................................................... 9<br />
1.1 PURPOSE OF THE DOCUMENT.................................................................................................................... 9<br />
1.2 FIELD OF APPLICATION ............................................................................................................................. 9<br />
1.3 INTENDED READERSHIP .......................................................................................................................... 10<br />
1.4 STRUCTURE OF THE DOCUMENT ............................................................................................................. 10<br />
1.5 APPLICABLE AND REFERENCE DOCUMENTS............................................................................................ 11<br />
1.5.1 Applicable Documents................................................................................................................... 11<br />
1.5.2 Reference Documents .................................................................................................................... 11<br />
1.6 SPECIFIC GLOSSARY ............................................................................................................................... 12<br />
1.7 ASSUMPTIONS ........................................................................................................................................ 13<br />
2 HOW TO READ THIS DOCUMENT ? ................................................................................................... 14<br />
2.1 WHAT AN EXCEPTION MEANS................................................................................................................. 14<br />
2.2 DISCOVERING AND CHARACTERIZING EXCEPTIONS ................................................................................ 14<br />
2.3 PROPOSING BUSINESS RESPONSES TO EXCEPTIONS ................................................................................. 16<br />
3 EXCEPTIONS TYPOLOGY ..................................................................................................................... 20<br />
3.1 INFORMATION EXCHANGE EXCEPTIONS ................................................................................................. 20<br />
3.1.1 Exceptions at physical level .......................................................................................................... 20<br />
3.1.2 Exceptions at semantic level.......................................................................................................... 21<br />
3.2 PROCESS EXCEPTIONS ............................................................................................................................ 22<br />
3.2.1 Exceptions at physical level .......................................................................................................... 22<br />
3.2.2 Exceptions at semantic level.......................................................................................................... 23<br />
4 MANAGEMENT OF DATA ...................................................................................................................... 24<br />
4.1 OWNERSHIP AND HOLDING OF DATA ...................................................................................................... 24<br />
4.2 RECTIFICATION OF DATA........................................................................................................................ 24<br />
4.2.1 Rectification at entry level ............................................................................................................. 25<br />
4.2.2 Rectification at application level ................................................................................................... 25<br />
4.2.3 Control of rectifications ................................................................................................................ 26<br />
5 SOLUTION ELEMENTS .......................................................................................................................... 27<br />
5.1 PREVENTION OF EXCEPTIONS ................................................................................................................. 27<br />
5.1.1 PR01: Pre-validation of entered information ................................................................................ 28<br />
5.1.2 PR02: Ensure permanent availability of EMCS applications ....................................................... 28<br />
5.1.3 PR03: Atomicity of EBP processing .............................................................................................. 28<br />
5.1.4 PR04: Use of timers ...................................................................................................................... 28<br />
5.1.5 PR05: Enqueue message for further automatic recovery .............................................................. 29<br />
5.1.6 PR06: Business acknowledgement ................................................................................................ 29<br />
5.1.7 PR07: Follow-up ‘open’ information ............................................................................................ 30<br />
5.2 ADMINISTRATIVE PROCEDURES ............................................................................................................. 30<br />
5.2.1 AP01: Enquire on information ...................................................................................................... 31<br />
5.2.2 AP04: Broadcast information on unavailability ........................................................................... 31<br />
5.2.3 AP05: Perform internal controls ................................................................................................... 31<br />
5.2.4 AP06: Take a business decision .................................................................................................... 32<br />
5.2.5 AP07: Transfer issue to support .................................................................................................... 32<br />
5.2.6 AP08: Exchange information outside EMCS ................................................................................ 33<br />
5.3 FALLBACK SOLUTION ELEMENTS ........................................................................................................... 33<br />
5.3.1 FB01: Use alternate communication medium ............................................................................... 34<br />
ECP2-FITSDEV2-SC03-<strong>FRS</strong>v3.11.doc Page 6 of 53
DG TAXUD – EXCISE COMPUTERISATION PROJECT REF: ECP2-FITSDEV2-SC03-<strong>FRS</strong><br />
FALLBACK AND RECOVERY SPECIFICATION (<strong>FRS</strong>) VERSION: 3.11-EN<br />
TABLE OF contents<br />
5.3.2 FB02: Revert to manual without subsequent input ....................................................................... 35<br />
5.3.3 FB03: Revert to manual with subsequent input ............................................................................ 35<br />
5.3.4 FB04: No intervention – wait ........................................................................................................ 35<br />
5.3.5 FB06: Notify administration ......................................................................................................... 36<br />
5.3.6 FB08: Notify economic operator ................................................................................................... 37<br />
5.4 RECOVERY SOLUTION ELEMENTS ........................................................................................................... 37<br />
5.4.1 RC03: Restart or replace technical component ............................................................................ 37<br />
5.4.2 RC04: Enter data using the normal procedure ............................................................................. 38<br />
5.4.3 RC05: No intervention – accept exception .................................................................................... 38<br />
5.4.4 RC06: Collate electronic record with the fallback form ............................................................... 38<br />
5.4.5 RC07: Replay information exchange ............................................................................................ 39<br />
5.4.6 RC10: Re-apply undone changes .................................................................................................. 39<br />
6 PAPER FALLBACK SYSTEM ................................................................................................................. 40<br />
6.1 OVERVIEW ............................................................................................................................................. 40<br />
6.2 ROLES AND RESPONSIBILITIES ................................................................................................................ 40<br />
6.2.1 Unavailability at consignor’s premises (location A) ..................................................................... 41<br />
6.2.2 Unavailability at MSA of dispatch (location B) ............................................................................ 41<br />
6.2.3 Unavailability at MSA of destination (location C) ........................................................................ 41<br />
6.2.4 Unavailability at consignee’s premises (location D) .................................................................... 42<br />
6.3 FALLBACK PAPER FORMS ....................................................................................................................... 42<br />
6.4 FALLBACK COMMUNICATION MEDIA ...................................................................................................... 42<br />
6.5 MAIN BUSINESS CASES FALLBACK PROCEDURES .................................................................................... 43<br />
6.5.1 Submission of AAD ........................................................................................................................ 43<br />
6.5.2 Cancellation of AAD ..................................................................................................................... 44<br />
6.5.3 Report of receipt ............................................................................................................................ 44<br />
6.5.4 Change of destination.................................................................................................................... 45<br />
6.5.5 Splitting ......................................................................................................................................... 46<br />
6.5.6 Interruption ................................................................................................................................... 47<br />
6.5.7 Control .......................................................................................................................................... 47<br />
6.5.8 Administrative cooperation ........................................................................................................... 48<br />
6.6 RECOVERY FROM PAPER FALLBACK PROCEDURES ................................................................................. 48<br />
6.6.1 Means to recover ........................................................................................................................... 48<br />
6.6.2 Deferred mode ............................................................................................................................... 49<br />
6.6.3 Summary of intermediate operations ............................................................................................ 49<br />
7 UNAVAILABILITY OF SEED INFORMATION ................................................................................... 50<br />
8 SPECIFIC PROVISIONS DURING THE ROLLOUT OF EMCS ........................................................ 51<br />
8.1 FALLBACK AND RECOVERY DURING MIGRATION PERIOD 1 ................................................................... 51<br />
8.1.1 Unavailability of the automatic triggering of risk assessment ...................................................... 51<br />
8.1.2 Exportation of goods in an MSA different from the MSA of dispatch ........................................... 51<br />
8.1.3 Unavailability of the control report .............................................................................................. 52<br />
8.1.4 Unavailability of the event report ................................................................................................. 52<br />
8.1.5 Interruption of a movement ........................................................................................................... 53<br />
ECP2-FITSDEV2-SC03-<strong>FRS</strong>v3.11.doc Page 7 of 53
DG TAXUD – EXCISE COMPUTERISATION PROJECT REF: ECP2-FITSDEV2-SC03-<strong>FRS</strong><br />
FALLBACK AND RECOVERY SPECIFICATION (<strong>FRS</strong>) VERSION: 3.11-EN<br />
TABLE OF figures<br />
Table of figures<br />
FIGURE 1 APPENDIX A - EXCEPTIONS ................................................................................................... 18<br />
FIGURE 2 E-AAD MANAGEMENT INFORMATION FLOWS ....................................................................... 40<br />
FIGURE 3 SUBMISSION OF AAD – FALLBACK ADMINISTRATIVE CIRCUIT .............................................. 43<br />
FIGURE 4 CANCELLATION OF AAD – FALLBACK ADMINISTRATIVE CIRCUIT......................................... 44<br />
FIGURE 5 REPORT OF RECEIPT – FALLBACK ADMINISTRATIVE CIRCUIT ................................................. 44<br />
FIGURE 6 CHANGE OF DESTINATION – FALLBACK ADMINISTRATIVE CIRCUIT ....................................... 45<br />
FIGURE 7 SPLITTING – FALLBACK ADMINISTRATIVE CIRCUIT ............................................................... 46<br />
FIGURE 8 INTERRUPTION – FALLBACK ADMINISTRATIVE CIRCUIT ........................................................ 47<br />
FIGURE 9 CONTROL – FALLBACK ADMINISTRATIVE CIRCUIT ................................................................ 47<br />
FIGURE 10 ADMINISTRATIVE COOPERATION – REQUEST FOR ASSISTANCE .............................................. 48<br />
FIGURE 11 ADMINISTRATIVE COOPERATION – SPONTANEOUS INFORMATION AND REPLY TO A REQUEST<br />
FOR ASSISTANCE ................................................................................................................... 48<br />
Table of tables<br />
TABLE 1 APPLICABLE DOCUMENTS ...................................................................................................... 11<br />
TABLE 2 REFERENCE DOCUMENTS ....................................................................................................... 12<br />
TABLE 3 SPECIFIC GLOSSARY OF ACRONYMS USED IN THE <strong>FRS</strong> .......................................................... 13<br />
ECP2-FITSDEV2-SC03-<strong>FRS</strong>v3.11.doc Page 8 of 53
DG TAXUD – EXCISE COMPUTERISATION PROJECT REF: ECP2-FITSDEV2-SC03-<strong>FRS</strong><br />
FALLBACK AND RECOVERY SPECIFICATION (<strong>FRS</strong>) VERSION: 3.11-EN<br />
Introduction<br />
1 Introduction<br />
1.1 Purpose of the document<br />
The purpose of this document is to provide the necessary information to correctly take<br />
charge of the continuity <strong>and</strong> integrity of EMCS business where unexpected circumstances<br />
arise, but also to consider related functional, organisational, procedural <strong>and</strong> security<br />
requirements.<br />
It is a part of the Functional Excise System <strong>Specification</strong> [R6]. It aims to identify<br />
exceptions, i.e. conditions that may make it impossible to use EMCS in its customary<br />
way, <strong>and</strong> to determine how the business must react to these conditions.<br />
From the analysis of individual exceptions, the document identifies the business<br />
responses that must be given to these exceptions.<br />
Only international business responses given in this <strong>FRS</strong> are imperative; national <strong>and</strong>/or<br />
local business responses are to be considered as suggestions.<br />
To that end, the <strong>FRS</strong> considers:<br />
� preventing exceptions from happening through detection <strong>and</strong> prevention measures <strong>and</strong><br />
preparing the system for complementary solutions;<br />
� falling back from normal working processes to downgraded operations so as to ensure<br />
continuity of business while acquiring the information necessary for a safe recovery;<br />
in particular, manual fallback solutions are suggested in case of EMCS unavailability<br />
(to be started after a certain time depending on the case), <strong>and</strong> related paper based<br />
procedures are described;<br />
� recovering the follow-up information to reconstruct the exact history of a movement,<br />
at least the useful part of it, into electronic records.<br />
The analysis of <strong>FRS</strong> exceptions also leads to identify a series of requirements, on which<br />
could depend the implementation of the identified business responses.<br />
Additional procedures required to cope with exceptions are identified also.<br />
Even though the approach is business oriented, one cannot underestimate the fact that<br />
most EMCS processes will be automated, <strong>and</strong> that one of the main sources of exception<br />
will be the unavailability of these automated processes.<br />
Even in that case, the <strong>FRS</strong> only considers the functional consequences of such<br />
exceptions, <strong>and</strong> how they are h<strong>and</strong>led by the business. It never addresses the technical<br />
implications of an exception. However, the <strong>FRS</strong> identifies a series of requirements on<br />
which depends the implementation of the identified business responses.<br />
1.2 Field of application<br />
The field of application of the <strong>FRS</strong> is the whole scope of the FESS [R6]; the <strong>FRS</strong> must be<br />
understood as a full part of the FESS [R6] with explicit requirements.<br />
As stated in the previous section, the <strong>FRS</strong>:<br />
ECP2-FITSDEV2-SC03-<strong>FRS</strong>v3.11.doc Page 9 of 53
DG TAXUD – EXCISE COMPUTERISATION PROJECT REF: ECP2-FITSDEV2-SC03-<strong>FRS</strong><br />
FALLBACK AND RECOVERY SPECIFICATION (<strong>FRS</strong>) VERSION: 3.11-EN<br />
Introduction<br />
� only identifies fallback solutions for a target system in which all MSAs use the EMCS<br />
application;<br />
� addresses some cases of migration period 1 (defined in the Phasing <strong>and</strong> Scope<br />
<strong>Specification</strong> (PSS) [R3]), where some Member States <strong>and</strong>/or economic operators will<br />
not be equipped yet with the computerised EMCS while other ones will already be<br />
operational. It shall be noted that no specific provisions (as defined in Chapter 8)<br />
apply to the fallback <strong>and</strong> recovery procedures of EMCS during the rollout of EMCS<br />
Phase 3, since according to the updated Master Plan [R7], there will be no coexistence<br />
of FS1 <strong>and</strong> FS2 (all MSAs will enter the EMCS Phase 3 operations at<br />
milestone Mc).<br />
1.3 Intended readership<br />
The intended readership for this document is the same as for the FESS [R6]; it includes:<br />
� any person/service involved in the functional <strong>and</strong> technical specification or<br />
implementation of EMCS (including as well Member States representatives <strong>and</strong><br />
software design teams or development teams, …);<br />
� any person/service in charge of defining the procedures <strong>and</strong> h<strong>and</strong>books that will apply<br />
to the operation of the EMCS systems, both in the Common Domain <strong>and</strong> in the<br />
National Domains;<br />
� any other authorised body concerned with EMCS including the Excise Committee, the<br />
ECWP, the ECP Steering Committee, <strong>and</strong> the professional organisations of economic<br />
operators.<br />
1.4 Structure of the document<br />
This document contains the following chapters:<br />
� Chapter 1 "Introduction" is the present general introduction;<br />
� Chapter 2 "How to read this document ?" highlights the way of using this document<br />
by describing the concepts <strong>and</strong> the way they are implemented;<br />
� Chapter 3 "Exceptions typology" gives a general description of the categories of<br />
exceptions identified for EMCS;<br />
� Chapter 4 "Management of data" highlights the notions of ownership <strong>and</strong> holding of<br />
data <strong>and</strong> their impact on rectification <strong>and</strong> further controls;<br />
� Chapter 5 "Solution elements" presents the generic solution elements involved in the<br />
construction of business responses to EMCS exceptions;<br />
� Chapter 6 "Paper fallback system" explains roles, responsibilities <strong>and</strong> fallback means<br />
to be used for some specific exceptions. In that context, main business cases <strong>and</strong><br />
electronic recovery are presented;<br />
� Chapter 7 "Unavailability of SEED information" presents fallback <strong>and</strong> recovery<br />
solution for this reference database;<br />
� Chapter 8 "Specific provisions during the rollout of EMCS" is focused on Migration<br />
Period 1 <strong>and</strong> FS2 as defined in the PSS [R3].<br />
ECP2-FITSDEV2-SC03-<strong>FRS</strong>v3.11.doc Page 10 of 53
DG TAXUD – EXCISE COMPUTERISATION PROJECT REF: ECP2-FITSDEV2-SC03-<strong>FRS</strong><br />
FALLBACK AND RECOVERY SPECIFICATION (<strong>FRS</strong>) VERSION: 3.11-EN<br />
Introduction<br />
This document is further completed with a series of Appendices:<br />
� Appendix A, entitled "Exceptions <strong>and</strong> Solution elements", contains the detailed list of<br />
all individual exceptions that have been qualified worth a processing during the<br />
analysis, <strong>and</strong> the scenario of solution elements assigned to each exception;<br />
� Appendix B, entitled "Information exchanges to be acknowledged", lists the EMCS<br />
Information Exchanges that must be explicitly acknowledged, according to the<br />
prevention solution element “PR06 - business acknowledgement”;<br />
� Appendix C, entitled "Summary of Solution elements", lists the solution elements that<br />
contribute to solve the issues raised by the exceptions <strong>and</strong> gives the links with the<br />
complementary requirements resulting from the analysis;<br />
� Appendix D, entitled "Summary of Requirements", gives the list <strong>and</strong> contents of all<br />
the requirements resulting from the analysis of the <strong>FRS</strong> (in addition of those of the<br />
FESS [R6] with the links to the solution elements described in the present document.<br />
1.5 Applicable <strong>and</strong> reference documents<br />
1.5.1 Applicable Documents<br />
Ref. Identifier Title Version Issued<br />
A1 TAXUD/2008/CC<br />
/095<br />
A2 TAXUD/2008/DE<br />
/123<br />
Framework Contract 15/09/2008<br />
Specific Agreement n° 03<br />
(SC03) for Lot ESS based on<br />
[A1]<br />
A3 DIRECTIVE Directive 2008/118/EC<br />
concerning the general<br />
arrangements for excise duty<br />
<strong>and</strong> repealing Directive<br />
92/12/EEC.<br />
1.5.2 Reference Documents<br />
Table 1 applicable documents<br />
28/11/2008<br />
16/12/2008<br />
Ref. Identifier Title Version Issued<br />
R1 ECP1-ESS-SEP Security Policy (SEP) 2.02 13/12/2004<br />
R2 ECP1-ESS-GLT Glossary of Terms 1.01-EN 14/11/2004<br />
R3 ECP1-ESS-PSS Phasing <strong>and</strong> Scope<br />
<strong>Specification</strong> (PSS)<br />
R4 ECP1-ESS-SESS Security Excise System<br />
<strong>Specification</strong> (SESS)<br />
R5 ECP2-EMCS-<br />
DDNEA<br />
Design Document for<br />
National Excise Applications<br />
2.12 28/09/2007<br />
2.00 02/10/2006<br />
2.19 05/02/2009<br />
ECP2-FITSDEV2-SC03-<strong>FRS</strong>v3.11.doc Page 11 of 53
DG TAXUD – EXCISE COMPUTERISATION PROJECT REF: ECP2-FITSDEV2-SC03-<strong>FRS</strong><br />
FALLBACK AND RECOVERY SPECIFICATION (<strong>FRS</strong>) VERSION: 3.11-EN<br />
Introduction<br />
Ref. Identifier Title Version Issued<br />
R6 ECP1-ESS-FESS Functional Excise System<br />
<strong>Specification</strong> (FESS)<br />
3.00 08/11/2007<br />
R7 MAP Master Plan 2.9 06/04/2009<br />
1.6 Specific glossary<br />
Table 2 reference documents<br />
Below are listed all acronyms of interest that are used in the <strong>FRS</strong> document, <strong>and</strong> whether<br />
they are referenced in the GLT [R2].<br />
Acronym Translation<br />
Found in<br />
GLT<br />
AAD Administrative Accompanying Document yes<br />
ARC AAD Reference Code yes<br />
CCN/CSI Common Communication Network/Common System Interface yes<br />
ECWP Excise Computerisation Working Party yes<br />
EBP Elementary Business Process yes<br />
ECP Excise Computerisation Project yes<br />
ECS Export Control System no<br />
EEC European Economic Community no<br />
ELO Excise Liaison Office yes<br />
EMCS Excise Movement <strong>and</strong> Control System yes<br />
FESS Functional Excise System <strong>Specification</strong>s yes<br />
FMS Functional Message Structure yes<br />
<strong>FRS</strong> <strong>Fallback</strong> <strong>and</strong> <strong>Recovery</strong> <strong>Specification</strong> yes<br />
GLT Glossary of Terms yes<br />
IE Information Exchange yes<br />
IT Information Technology yes<br />
LRN Local Reference Number no<br />
MRN Movement Reference Number no<br />
MS Member State no<br />
ECP2-FITSDEV2-SC03-<strong>FRS</strong>v3.11.doc Page 12 of 53
DG TAXUD – EXCISE COMPUTERISATION PROJECT REF: ECP2-FITSDEV2-SC03-<strong>FRS</strong><br />
FALLBACK AND RECOVERY SPECIFICATION (<strong>FRS</strong>) VERSION: 3.11-EN<br />
Introduction<br />
Acronym Translation<br />
Found in<br />
GLT<br />
MSA Member State Administration yes<br />
N/A Not Applicable no<br />
NACK Non-ACKnowledgement service message yes<br />
SAD Single Administrative Document no<br />
SEED System for Exchange of Excise Data yes<br />
SEP Security Policy yes<br />
STD State Transition Diagram yes<br />
TAXUD Directorate-General Taxation <strong>and</strong> Customs Union yes<br />
UC Use Case yes<br />
1.7 Assumptions<br />
Table 3 specific glossary of acronyms used in the <strong>FRS</strong><br />
This <strong>Fallback</strong> <strong>and</strong> <strong>Recovery</strong> <strong>Specification</strong> is written according to the following<br />
assumptions:<br />
1. legal <strong>and</strong> regulatory provisions are respected by all involved parties; irregularities <strong>and</strong><br />
infringements pertain to the processing of inquiries;<br />
2. roles <strong>and</strong> responsibilities never change; if, for some reason, an intermediate acts by<br />
delegation of a partner (for instance, an excise officer enters a report of receipt on<br />
behalf of the consignee), the responsibility rests with the delegating actor;<br />
3. if the normal communication medium between an economic operator <strong>and</strong> its MSA<br />
fails, alternate communication media (fax, digital memory medium or paper) will<br />
always be available.<br />
ECP2-FITSDEV2-SC03-<strong>FRS</strong>v3.11.doc Page 13 of 53
DG TAXUD – EXCISE COMPUTERISATION PROJECT REF: ECP2-FITSDEV2-SC03-<strong>FRS</strong><br />
FALLBACK AND RECOVERY SPECIFICATION (<strong>FRS</strong>) VERSION: 3.11-EN<br />
How to read this document ?<br />
2 How to read this document ?<br />
Apart from your role in the EMCS project (business actor, software designer or<br />
developer, software test team member…), you need to know how to exploit the richness<br />
of this document.<br />
2.1 What an exception means<br />
Any condition that may make it impossible to use EMCS in its customary way, is called<br />
here “exception”. The purpose of this document is to determine how the business must<br />
react to these exceptions.<br />
An analytical approach is used to detect as many potential exceptions as possible <strong>and</strong> to<br />
define the responses to these exceptions.<br />
All exceptions identified during the analysis phase have been studied in order to derive a<br />
number of generic responses.<br />
The use of specific responses will then be limited to the few cases where no generic<br />
response is applicable.<br />
2.2 Discovering <strong>and</strong> characterizing exceptions<br />
Exceptions identification <strong>and</strong> qualification is done by systematically exploring the flows<br />
described in the use cases defined in the FESS [R6] <strong>and</strong> by identifying the situations that<br />
would make it impossible to follow the expected path until the end of the flow (including<br />
the effect of a failure of resources); this allows to explore separately each information<br />
exchange, once from the point of view of the sender <strong>and</strong> once from the point of view of<br />
the receiver;<br />
For each identified exception, the following points are examined:<br />
� Plausibility;<br />
� Business impact;<br />
� Security impact;<br />
� Time constraints.<br />
Qualification of exceptions against plausibility, business impact, security impact <strong>and</strong> time<br />
constraints results in a decision whether the exception is worth a processing.<br />
Plausibility<br />
The plausibility of each identified exception is first questioned to determine whether the<br />
exception is worth identifying a business response. This is done by examining whether,<br />
from a business point of view, this exception could really happen. The level of<br />
plausibility is not considered. In other words, an exception is either considered plausible<br />
(even if its level of plausibility is low) or non plausible. Non plausible exceptions are<br />
kept for documentation purposes but are not further analysed.<br />
ECP2-FITSDEV2-SC03-<strong>FRS</strong>v3.11.doc Page 14 of 53
DG TAXUD – EXCISE COMPUTERISATION PROJECT REF: ECP2-FITSDEV2-SC03-<strong>FRS</strong><br />
FALLBACK AND RECOVERY SPECIFICATION (<strong>FRS</strong>) VERSION: 3.11-EN<br />
How to read this document ?<br />
Business impact<br />
By impact, one must underst<strong>and</strong> not only the impact of the exception itself on the<br />
business but also the impact of any solution element that any partner has to carry out<br />
following the exception.<br />
The business impact is an evaluation of the geographical scope of the possible impact of<br />
the exception on the business of EMCS. It is evaluated for each exception found<br />
plausible. There are three possible classes of impact:<br />
� international business impact, if the occurrence of this exception affects the EMCS<br />
business in at least two Member States;<br />
� national business impact, if the occurrence of this exception affects the EMCS only in<br />
the country where this exception has occurred;<br />
� local business impact, if the occurrence of this exception only affects the business of<br />
the excise office where this exception has occurred, <strong>and</strong>/or the business of an<br />
economic operator;<br />
� no business impact.<br />
If there is a business impact at several levels (e.g. an international <strong>and</strong> a national business<br />
impact), only the widest one is considered.<br />
The objective is not to define the relative importance of an exception for the business<br />
(national business impact on economic operators may be more important than<br />
international impact), but to identify the maximum scope (international or national)<br />
applicable for the h<strong>and</strong>ling of this exception.<br />
In turn, each MSA should define its own exceptions (at national level).<br />
Security impact<br />
The impact of each plausible exception on the security of the business is evaluated. It<br />
results from one among several situations:<br />
� the exception itself creates a breach of security;<br />
� the business response to the exception itself may create a breach of security;<br />
� the exception results from an attempt at fraud.<br />
A “security breach” area is qualified according to whether it affects one of the following:<br />
� availability of the system;<br />
� data confidentiality;<br />
� data integrity;<br />
� risk of fraud.<br />
It is possible that the same exception impacts several security areas. Only that estimated<br />
the most important is displayed; in particular a risk of fraud always prevails on the other<br />
area.<br />
For more information about security related aspects, please refer to the SEP [R1] <strong>and</strong> to<br />
the SESS [R4].<br />
ECP2-FITSDEV2-SC03-<strong>FRS</strong>v3.11.doc Page 15 of 53
DG TAXUD – EXCISE COMPUTERISATION PROJECT REF: ECP2-FITSDEV2-SC03-<strong>FRS</strong><br />
FALLBACK AND RECOVERY SPECIFICATION (<strong>FRS</strong>) VERSION: 3.11-EN<br />
How to read this document ?<br />
Time constraint<br />
Where an exception is qualified worth a processing, it is considered whether it must be<br />
satisfactorily dealt with within a limited period of time, <strong>and</strong> this time limit is identified as<br />
far as possible.<br />
For each exception, in particular, response time classes (interactive, asynchronous,<br />
scheduled, up to MSA, asynchronous/scheduled or N/A) <strong>and</strong> response time classes that<br />
have been introduced in <strong>FRS</strong> (none, business limit, national limit, national provisions),<br />
the constraint takes into account performance requirements defined in Appendix A of the<br />
FESS [R6].<br />
2.3 Proposing business responses to exceptions<br />
Following the exceptions identification <strong>and</strong> qualification phase exposed above, the<br />
possible business responses were studied for all individual exceptions that were found<br />
plausible.<br />
If exceptions have an international business impact, the business responses must take into<br />
account international business constraints shared by all MSAs. It is therefore expected<br />
that these responses will be considered as st<strong>and</strong>ard responses, to be used by all<br />
participants to EMCS.<br />
In order to cover the global scope of the FESS [R6], the same approach is applied to<br />
exceptions with a national impact.<br />
In this case, however, business responses are only suggested, <strong>and</strong> will have to be adjusted<br />
by each MSA, based on their own legal, contractual or organisational requirements.<br />
The business response to an exception is either generic or specific:<br />
� A generic response is a st<strong>and</strong>ard response that relates to a whole series of exceptions.<br />
Whenever one of these exceptions is encountered, the related generic response applies,<br />
regardless of the specific aspects of the exception;<br />
� A specific response relates to a single exception, <strong>and</strong> is designed to be used only<br />
when this specific exception is encountered.<br />
As much as possible, business responses found for each business exception should be<br />
made generic, i.e. reusable by other exceptions.<br />
Business responses are defined as a set of identified <strong>and</strong> chronologically ordered solution<br />
elements.<br />
Main solution elements categories are:<br />
� Prevention measures systematically applied in the course of a normal activity flow<br />
with the aim of preventing or at least reducing the occurrence of an exception, or<br />
preparing elements that would later help in applying further (post exception)<br />
measures;<br />
� Administrative procedures, which are used in order to further document an<br />
exception; for example, the possibility for querying on missing information or taking a<br />
business decision;<br />
ECP2-FITSDEV2-SC03-<strong>FRS</strong>v3.11.doc Page 16 of 53
DG TAXUD – EXCISE COMPUTERISATION PROJECT REF: ECP2-FITSDEV2-SC03-<strong>FRS</strong><br />
FALLBACK AND RECOVERY SPECIFICATION (<strong>FRS</strong>) VERSION: 3.11-EN<br />
How to read this document ?<br />
� <strong>Fallback</strong> solution elements, which are used in order to ensure the continuation of the<br />
business when an exception is encountered; the objective is to avoid delaying urgent<br />
excise business; they include, for example, the switch to a manual procedure when an<br />
automated process becomes unavailable;<br />
� <strong>Recovery</strong> solution elements, which are used to correct defective data resulting from<br />
errors that have occurred in the system, from mistakes made by users, or from the<br />
application of fallback solutions; they include, for example, the introduction of results<br />
in the system after an automated job has been temporarily replaced by a manual<br />
procedure, or complete replay of the manual procedure to obtain the actual business<br />
result.<br />
Most generally, the convenient response to a given exception is a combination of<br />
individual business responses. While identifying appropriate business responses to<br />
exceptions, several situations may be encountered:<br />
� the current exception is satisfactorily processed by starting a normal business use<br />
case; the use case becomes the normal response for the current exception;<br />
� the current exception is satisfactorily processed by an existing generic business<br />
response; the generic business response becomes the normal response for the current<br />
exception; if several generic business responses apply, they are compared <strong>and</strong> the most<br />
appropriate one is selected;<br />
� the current exception is satisfactorily processed by an existing specific business<br />
response defined for another exception; the specific solution then becomes a new<br />
generic business response with two particular applications;<br />
� the current exception solution is almost satisfactorily processed by an existing generic<br />
business response; the question whether a variant of the generic business response<br />
must be created has to be considered;<br />
� there is no satisfactory business response, neither generic nor specific, to deal with the<br />
current exception; a specific business response is defined with the view to make it<br />
generic in the future, i.e. by avoiding specific features.<br />
In addition, the detailed implementation of the same business response widely depends on<br />
the circumstances <strong>and</strong> on the context. This procedure has been followed to define the<br />
solutions presented in this document. It must be re-used in the future in the case new<br />
exceptions have to be analysed.<br />
Chapter 3 „Exceptions typology‟ describes generic exceptions that occur during<br />
information exchanges or during business processes. This gives a typology of individual<br />
exceptions listed in Appendix A, <strong>and</strong> presented as below:<br />
ECP2-FITSDEV2-SC03-<strong>FRS</strong>v3.11.doc Page 17 of 53
DG TAXUD – EXCISE COMPUTERISATION PROJECT REF: ECP2-FITSDEV2-SC03-<strong>FRS</strong><br />
FALLBACK AND RECOVERY SPECIFICATION (<strong>FRS</strong>) VERSION: 3.11-EN<br />
How to read this document ?<br />
Figure 1 Appendix A - Exceptions<br />
In Appendix A, each identified exception is:<br />
� presented regarding a specific use case (�);<br />
� identified per EBP (�) <strong>and</strong> per actor/location (�);<br />
� uniquely identified (�), <strong>and</strong> labelled with a short description text (�);<br />
� qualified against plausibility, business <strong>and</strong> security impacts, <strong>and</strong> time constraint (�);<br />
� followed by a set of clearly identified <strong>and</strong> chronologically ordered solution elements<br />
(�- note that alternatives are also identified) forming together the business response to<br />
the exception, including most of the time a specific note regarding the concerned<br />
exception;<br />
� if relevant, a label indicates that the exception is specific to “Migration period 1” (�).<br />
ECP2-FITSDEV2-SC03-<strong>FRS</strong>v3.11.doc Page 18 of 53
DG TAXUD – EXCISE COMPUTERISATION PROJECT REF: ECP2-FITSDEV2-SC03-<strong>FRS</strong><br />
FALLBACK AND RECOVERY SPECIFICATION (<strong>FRS</strong>) VERSION: 3.11-EN<br />
How to read this document ?<br />
In Appendix A, the exceptions are grouped by use cases.<br />
The use cases are presented in the same order as in the FESS [R6] :<br />
Section II : UC2.01, UC2.10, UC2.06, UC2.07, UC2.33, UC2.17, UC2.12, UC2.13,<br />
UC2.34, UC2.05, UC2.36, UC2.51, UC2.52, UC2.44, UC 2.43, UC2.46.<br />
Section III : UC1.14, UC1.15, UC1.16, UC1.30, UC1.11, UC1.04, UC1.05, UC1.06,<br />
UC1.13, UC3.16.<br />
Section IV : UC3.24, UC3.03, UC3.05, UC2.14, UC3.01, UC3.07, UC 3.09, UC3.29,<br />
UC3.14.<br />
Section V : UC0.07.<br />
The business responses are described in detail in Chapter 5 “Solution elements”; they are<br />
summarised in Appendix C <strong>and</strong> associated to individual exceptions in Appendix A.<br />
Note that the numbers contained in the identification of solution elements (e.g. FB06) are<br />
not related to any chronological order when used in a business response.<br />
Only the sequential numbering of solution elements in Appendix A indicates a<br />
chronological order of appliance.<br />
ECP2-FITSDEV2-SC03-<strong>FRS</strong>v3.11.doc Page 19 of 53
DG TAXUD – EXCISE COMPUTERISATION PROJECT REF: ECP2-FITSDEV2-SC03-<strong>FRS</strong><br />
FALLBACK AND RECOVERY SPECIFICATION (<strong>FRS</strong>) VERSION: 3.11-EN<br />
Exceptions typology<br />
3 Exceptions typology<br />
This chapter contains a general description of the categories of exceptions <strong>and</strong> of the<br />
common characteristics of these categories. This categorisation has been the main<br />
guideline to discover exceptions throughout the analysis of the process flows. These<br />
exceptions are listed in Appendix A where they are presented along with the response<br />
scenarios that eventually allow restoring the good functioning of the system.<br />
The main categories are based on the origin <strong>and</strong> place of occurrence of these exceptions,<br />
namely:<br />
� Information Exchange; or<br />
� Processing.<br />
Although useful to systematically analyse the process flows to detect exceptions, these<br />
categories have not been found relevant in deeper analysis.<br />
3.1 Information Exchange exceptions<br />
All information exchanges are subject to the same types of exception, regardless of the<br />
business context in which information has to be exchanged.<br />
Regardless of the scope (national or international) of an information exchange, or of the<br />
communication medium used (message exchanged through a communication network,<br />
paper based, phone, fax, e-mail...) exceptions happen at two levels:<br />
� Physical: failure of the communication medium itself, or loss of the information to be<br />
exchanged;<br />
� Semantic: the content of the information exchange does not have any business<br />
signification to the receiver.<br />
Whatever its level, an exception will have the same functional result: a failure of the<br />
information exchange.<br />
Note that most possible exceptions listed in this section are actually detected by the<br />
business process that receives <strong>and</strong> verifies information, in particular paragraph 3.1.2<br />
„Exceptions at semantic level‟. However, as they apply to the information itself, we<br />
preferred keeping them in this section.<br />
3.1.1 Exceptions at physical level<br />
3.1.1.1 Unavailability of the communication medium<br />
Most generally, if the normal communication medium fails, information cannot be<br />
exchanged through normal EMCS procedures.<br />
However, for some exchanges, it has been found important to define alternate<br />
communication channels, either because the normal channel is felt particularly fragile or<br />
because the permanence of the exchange is essential for the good functioning of EMCS.<br />
ECP2-FITSDEV2-SC03-<strong>FRS</strong>v3.11.doc Page 20 of 53
DG TAXUD – EXCISE COMPUTERISATION PROJECT REF: ECP2-FITSDEV2-SC03-<strong>FRS</strong><br />
FALLBACK AND RECOVERY SPECIFICATION (<strong>FRS</strong>) VERSION: 3.11-EN<br />
Exceptions typology<br />
3.1.1.2 Loss of information to be exchanged<br />
For some reason, the addressee never receives the contents of an information exchange. If<br />
this is the case, different situations must be considered:<br />
1. The lost information was expected.<br />
The addressee expects to receive certain information within a given time limit, <strong>and</strong> this<br />
information is lost: this is typically the case if information is exchanged in response to<br />
another information exchange.<br />
For example, if the report of receipt of an e-AAD does not arrive in due time. Most<br />
generally, but not always, such missing information is automatically detected through<br />
a timer or equivalent mechanism.<br />
2. A response to the lost information was expected.<br />
If the lost information was not expected from the addressee, but the sender expects to<br />
receive a specific response to this information exchange within a certain delay. This<br />
situation is similar to the situation described in the example above, except that, in this<br />
case, it is the initial information exchange that is lost (in this example: the e-AAD<br />
never reached the consignee), instead of its response; that is to say that the e-AAD<br />
itself is lost.<br />
The result will be the same: the consignor will not receive the expected report of<br />
receipt.<br />
3. The lost information was not expected.<br />
If the lost information was not expected from the addressee, <strong>and</strong> the sender does not<br />
expect to receive a specific response to this information exchange, the exception<br />
remains undetected until the lost information becomes needed.<br />
3.1.2 Exceptions at semantic level<br />
Several defects are capable of making it impossible for the receiver of an information<br />
exchange to underst<strong>and</strong> the business signification of the received information; typically:<br />
� the message refers to an object that is not known to the receiver;<br />
� the content of the received information is not consistent with already known<br />
information (e.g. a report of receipt is received from an economic operator who is not<br />
the consignee of the e-AAD).<br />
3.1.2.1 Unknown object<br />
The typical case of unknown object is where a received information exchange refers to an<br />
ARC that is not known to the receiver. This results from a preceding error (the e-AAD<br />
did not reach the receiver), from a mistake (wrong ARC has been input) or from a fraud<br />
(use of a forged ARC).<br />
Similar cases are where a complementary submission of a control report or of an event<br />
report refers to a non-existent report identifier or where a response to a request refers to a<br />
non-existent correlation id.<br />
ECP2-FITSDEV2-SC03-<strong>FRS</strong>v3.11.doc Page 21 of 53
DG TAXUD – EXCISE COMPUTERISATION PROJECT REF: ECP2-FITSDEV2-SC03-<strong>FRS</strong><br />
FALLBACK AND RECOVERY SPECIFICATION (<strong>FRS</strong>) VERSION: 3.11-EN<br />
Exceptions typology<br />
In most cases, the incoming information exchange must simply be rejected, <strong>and</strong> the<br />
sender has to be notified (through a NACK message) about this rejection <strong>and</strong> its motives.<br />
The further h<strong>and</strong>ling of the exception depends on the nature of the defect. However, some<br />
particular situations may necessitate a more complex processing.<br />
3.1.2.2 Inconsistent data<br />
Data sent in an information exchange will not be consistent with data already available to<br />
the receiver in the following cases:<br />
1. the information exchange contains data based on a version of registration or reference<br />
data different from the version used by the receiver;<br />
2. the information exchange contains fixed data on an EMCS movement that does not<br />
correspond to the equivalent data already known by the receiver on this exchange.<br />
3.2 Process exceptions<br />
Being generally automated, there are many reasons for business processes to fail similarly<br />
to information exchanges.<br />
3.2.1 Exceptions at physical level<br />
3.2.1.1 Unavailability of a component<br />
If some component that makes up the business process fails, processing of information<br />
becomes impossible.<br />
This includes the availability of necessary information as well. For instance, if the<br />
consultation of SEED information by the application is currently impossible, basic<br />
processes such as the submission of an e-AAD or of a change of destination becomes<br />
impossible.<br />
3.2.1.2 Corruption of information<br />
This situation happens when, for any reason, the automatic processing does not properly<br />
process information <strong>and</strong> hence output of a use case does not conform to the expected<br />
result. It is the case, for instance, where a component encounters a r<strong>and</strong>om error.<br />
This should not happen, <strong>and</strong> detection of such cases is considered difficult.<br />
If the processing carries on despite the error, this latter is propagated throughout the<br />
whole history of the movement, possibly corrupting other movements. In many cases, the<br />
error will be detected a posteriori, possibly after several operations will have been<br />
completed on the same movement.<br />
ECP2-FITSDEV2-SC03-<strong>FRS</strong>v3.11.doc Page 22 of 53
DG TAXUD – EXCISE COMPUTERISATION PROJECT REF: ECP2-FITSDEV2-SC03-<strong>FRS</strong><br />
FALLBACK AND RECOVERY SPECIFICATION (<strong>FRS</strong>) VERSION: 3.11-EN<br />
Exceptions typology<br />
3.2.2 Exceptions at semantic level<br />
3.2.2.1 Non conformance of the implemented processing<br />
Non conformance of the implemented processing with the functional specification is<br />
supposed to be prevented, if not completely expelled by a careful certification of each<br />
application before leaving it entering into operation. However, particular situations lead<br />
to discover cases that escape the described functionality. This is detected in a further step<br />
of the same process or in a further process, possibly in a later use case.<br />
The resolution process should:<br />
1. immediately solve the current exception (incident) by any available means;<br />
2. define a workaround to avoid further occurrences of the exception <strong>and</strong> issue the<br />
relevant use recommendations;<br />
3. report the incident to the relevant authority (national support or common domain<br />
support);<br />
4. design a stable <strong>and</strong> definitive solution <strong>and</strong> include it in a further release of the<br />
software (or hardware).<br />
Such incidents being unexpected by nature, they are not identified in the <strong>FRS</strong>.<br />
3.2.2.2 Disparity between the functional specification <strong>and</strong> the actual business need<br />
This case comes under maintenance of the specification, either corrective (for instance<br />
giving a more precise description of the expected functionality <strong>and</strong> adding test cases to<br />
the certification tools), or evolutionary (defining new particular cases <strong>and</strong> the way they<br />
have to be processed).<br />
ECP2-FITSDEV2-SC03-<strong>FRS</strong>v3.11.doc Page 23 of 53
DG TAXUD – EXCISE COMPUTERISATION PROJECT REF: ECP2-FITSDEV2-SC03-<strong>FRS</strong><br />
FALLBACK AND RECOVERY SPECIFICATION (<strong>FRS</strong>) VERSION: 3.11-EN<br />
Management of data<br />
4 Management of data<br />
4.1 Ownership <strong>and</strong> holding of data<br />
In EMCS, each piece of information has:<br />
� an owner, i.e. the user who submitted the information; most times, it is an economic<br />
operator, either registered, <strong>and</strong> in that case he enters the information himself, or nonregistered,<br />
<strong>and</strong> in that case another user, possibly an official, enters it on his behalf;<br />
� a holder, i.e. the MSA that is responsible for keeping the reference version of<br />
information <strong>and</strong> for transferring it to any authorised partner whenever required; in<br />
principle it is the MSA that initially validated it, also called initiating MSA.<br />
The general principles that govern management of data are the following:<br />
� the owner is responsible for the accuracy of the submitted information;<br />
� only the owner of a data item is authorised to submit any update to that item, if<br />
updating is allowed;<br />
� if the case arises, the person (in particular, the official) who enters data on behalf of<br />
the owner is not responsible for the given information but only for entering exactly<br />
what the owner requested;<br />
� the holder MSA is responsible for formally validating submitted information <strong>and</strong> to<br />
report errors to the owner;<br />
� the holder MSA is not entitled to change anything to the information held, unless he is<br />
the owner as well;<br />
� the holder MSA is responsible for keeping information correct.<br />
Example:<br />
Upon submission of an e-AAD, the MSA of dispatch formally validates the submitted<br />
information <strong>and</strong> returns back the errors to the consignor, if any.<br />
The consignor (owner of the e-AAD) is responsible for correcting errors <strong>and</strong> resubmitting<br />
the e-AAD.<br />
If no errors are found, the MSA of dispatch becomes the holder of the e-AAD. In<br />
addition, the MSA of dispatch allocates an ARC to the e-AAD; the MSA of dispatch is<br />
therefore the owner of the ARC.<br />
This example shows how the same data group may be built from data items with different<br />
owners.<br />
4.2 Rectification of data<br />
If, as a result of errors or mistakes, the information entered into EMCS needs to be<br />
rectified, the general business principle is that rectification information can only be<br />
cancelled or amended by its owner <strong>and</strong> that the rectification is validated by the holder of<br />
data. For convenience, it may be acceptable that the holder updates the information on<br />
behalf of the owner, but only with his explicit agreement.<br />
ECP2-FITSDEV2-SC03-<strong>FRS</strong>v3.11.doc Page 24 of 53
DG TAXUD – EXCISE COMPUTERISATION PROJECT REF: ECP2-FITSDEV2-SC03-<strong>FRS</strong><br />
FALLBACK AND RECOVERY SPECIFICATION (<strong>FRS</strong>) VERSION: 3.11-EN<br />
Management of data<br />
Invalid or outdated information is never deleted but marked for history purpose, including<br />
where it results from mistakes. Necessary rectification of information is limited to a part<br />
of information <strong>and</strong> is changed only through well identified ways.<br />
Rectification is required at two levels:<br />
� at entry level: when information is submitted but not yet approved <strong>and</strong> stored;<br />
� at application level: when information has been entered into EMCS <strong>and</strong>, in most cases,<br />
immediately <strong>and</strong> automatically disseminated to all concerned partners, either<br />
economic operators or MSAs.<br />
4.2.1 Rectification at entry level<br />
No information should be accepted <strong>and</strong> recorded within EMCS unless it has been<br />
submitted to a formal validation. The rules of formal validation are detailed in the<br />
description of each concerned use case.<br />
This applies both where information is submitted by an economic operator <strong>and</strong> where it is<br />
submitted by an official.<br />
MSA may find it useful to locally store a part of information they are preparing to send to<br />
their partners (for instance administrative cooperation messages); details of rectification<br />
depend on the organisation of each MSA <strong>and</strong> will have to be defined at the national level.<br />
MSAs are never allowed to rectify information of which they are not the owner; if they<br />
detect any anomaly that justifies a rectification, the MSA requires the owner of<br />
information, usually an economic operator, to perform the relevant rectification<br />
operation.<br />
4.2.2 Rectification at application level<br />
Once information has been recorded in EMCS, it should only be corrected by using<br />
defined use cases.<br />
The System specification offers a range of functions that result in the ability to update a<br />
part of information. However, some information can only be rectified by cancellation <strong>and</strong><br />
possible replacement of an e-AAD.<br />
Example 1:<br />
If, at submission time, an e-AAD is validated based on erroneous information, it is<br />
possible for the consignor to immediately cancel it (UC2.10) <strong>and</strong> resubmit the correct<br />
information (UC2.01). A new ARC is then allocated.<br />
This is possible only where the goods have not yet left the place of dispatch.<br />
Example 2:<br />
If at submission time, the consignor made a mistake when typing the excise number of<br />
the consignee, which could not be prevented by the initial checking, he may immediately<br />
issue a change of destination (UC2.05).<br />
ECP2-FITSDEV2-SC03-<strong>FRS</strong>v3.11.doc Page 25 of 53
DG TAXUD – EXCISE COMPUTERISATION PROJECT REF: ECP2-FITSDEV2-SC03-<strong>FRS</strong><br />
FALLBACK AND RECOVERY SPECIFICATION (<strong>FRS</strong>) VERSION: 3.11-EN<br />
Management of data<br />
4.2.3 Control of rectifications<br />
All cases that support rectification should be specifically monitored by the MSA.<br />
Successive states of any entity involved in EMCS are systematically kept for history by<br />
the initiating MSA. This includes all rectifications performed during the life cycle of that<br />
entity. Information is communicated to concerned partners according to the general<br />
process of the use cases used for rectification.<br />
In addition, all operations are logged for audit <strong>and</strong> statistics purpose.<br />
ECP2-FITSDEV2-SC03-<strong>FRS</strong>v3.11.doc Page 26 of 53
DG TAXUD – EXCISE COMPUTERISATION PROJECT REF: ECP2-FITSDEV2-SC03-<strong>FRS</strong><br />
FALLBACK AND RECOVERY SPECIFICATION (<strong>FRS</strong>) VERSION: 3.11-EN<br />
Solution elements<br />
5 Solution elements<br />
Solution elements are the basic components of the overall business responses that relate<br />
to the identified exceptions. Whenever one of these exceptions is encountered, the related<br />
generic responses apply, regardless of the specific aspects of the exception.<br />
This chapter presents generic solution elements to build the business responses to EMCS<br />
exceptions.<br />
5.1 Prevention of exceptions<br />
PR01 Pre-validation of entered information<br />
PR02 Ensure permanent availability of EMCS applications<br />
PR03 Atomicity of EBP processing<br />
PR04 Use of timers<br />
PR05 Enqueue message for further automatic recovery<br />
PR06 Business acknowledgement<br />
PR07 Follow-up „open‟ information<br />
As a general rule, it is easier to prevent an exception from happening than to try to solve<br />
it after it has occurred. Therefore, when there are indications that some means exist to<br />
prevent an exception or reduce its consequences, these means are to be identified <strong>and</strong><br />
become a part of the solution.<br />
A prevention solution element is characterised by:<br />
� a place of prevention that identifies the responsibility of the measure; prevention<br />
should be performed as close as possible to the source of the cause <strong>and</strong> to the possible<br />
point of correction;<br />
� a type of prevention such as assistance <strong>and</strong> control of input at user interface, integrity<br />
control at receipt of a message, control of internal consistency before sending a<br />
message, etc.<br />
A major characteristic of EMCS is that it mainly consists of automatic sequences of<br />
processes entrusted to different IT systems <strong>and</strong> that are automatically chained.<br />
Consequently, there is generally no intermediate actor enabled to verify to correct<br />
movement information during the processing of a use case.<br />
At the end of a use case, the new information must be known <strong>and</strong> consistent amongst all<br />
involved locations throughout the whole system.<br />
Consequently, there must be general mechanisms to:<br />
� ensure that only correct data are entered into the system;<br />
� ensure that the normal sequence of states is respected.<br />
ECP2-FITSDEV2-SC03-<strong>FRS</strong>v3.11.doc Page 27 of 53
DG TAXUD – EXCISE COMPUTERISATION PROJECT REF: ECP2-FITSDEV2-SC03-<strong>FRS</strong><br />
FALLBACK AND RECOVERY SPECIFICATION (<strong>FRS</strong>) VERSION: 3.11-EN<br />
Solution elements<br />
5.1.1 PR01: Pre-validation of entered information<br />
Any capture of data must be submitted to formal validation at time of keying in, i.e.<br />
before any further validation by the system. This is a major requirement of the system.<br />
Example:<br />
Upon submission of an e-AAD, the application of the consignor includes as many<br />
controls as possible to ensure semantic validity of each field (e.g. conformance to<br />
business rules) <strong>and</strong> consistency among fields, possibly by reference to available<br />
databases.<br />
5.1.2 PR02: Ensure permanent availability of EMCS applications<br />
EMCS is characterised by very strong availability requirements. Some functions such as<br />
the submission of an e-AAD have been quoted with a "permanent" availability<br />
requirement where a given interruption of the service should not last more than 15<br />
minutes <strong>and</strong> many other ones with a "high" availability requirement where a given<br />
interruption cannot last more than one hour.<br />
5.1.3 PR03: Atomicity of EBP processing<br />
Most EBPs described in the FESS [R6] are thought as business transactions, i.e. a set of<br />
actions that must be either completed or aborted together. The mechanism is defined at<br />
business level, i.e. there is no assumption on the way it shall be implemented.<br />
This response does not address specific exceptions but it is a prerequisite that has been<br />
used in the discovery of exceptions. Its role is to avoid considering in detail the possible<br />
exceptions that arise inside the process <strong>and</strong> to concentrate on the interconnection of each<br />
elementary process with the other ones: incoming <strong>and</strong> outgoing information exchanges,<br />
access to external information, functioning of timers.<br />
5.1.4 PR04: Use of timers<br />
Timers are introduced to ensure that a reminder is issued when a specific event has not<br />
arisen in due time.<br />
The mechanism is defined at business level, i.e. there is no assumption on the way it shall<br />
be implemented.<br />
This response does not address specific exceptions but it is a prerequisite for some other<br />
solution elements. A few major cases are described in the FESS [R6] itself, because they<br />
include coordination mechanisms including international information exchanges.<br />
Conversely, a range of deadlines are to be defined at national level such as the maximum<br />
duration of the storage of a message in a waiting queue when that response is being used<br />
(PR05 - enqueue message for further automatic recovery).<br />
Example:<br />
The storage of a message submitted to business acknowledgement is linked to a<br />
maximum waiting time. This waiting time should be associated with a timer to awake the<br />
ECP2-FITSDEV2-SC03-<strong>FRS</strong>v3.11.doc Page 28 of 53
DG TAXUD – EXCISE COMPUTERISATION PROJECT REF: ECP2-FITSDEV2-SC03-<strong>FRS</strong><br />
FALLBACK AND RECOVERY SPECIFICATION (<strong>FRS</strong>) VERSION: 3.11-EN<br />
Solution elements<br />
suspended processing (FB04 - no intervention - wait) <strong>and</strong> take complementary steps<br />
whenever the expected event has not arisen (in that case, return of the business<br />
acknowledgement).<br />
5.1.5 PR05: Enqueue message for further automatic recovery<br />
A safe storage of information may help in preparing further recovery where it has reached<br />
an identified level such as:<br />
� arrival of an information exchange regarding a checking failure into a given location;<br />
� positive checking of a submitted message; or<br />
� just before sending an information exchange.<br />
In each case, if the following processing fails, it will be possible to restart from the point<br />
of storage to resume the process.<br />
This solution element is a prerequisite for the business acknowledgement processing<br />
described below (PR06 - business acknowledgement).<br />
Example 1:<br />
When a submitted draft e-AAD arrives in the MSA of dispatch, it is convenient to<br />
securely store it before starting its formal checking; therefore, in case of breakdown<br />
during the checking (e.g. sudden unavailability of resources), the checking can be<br />
resumed when the failure is corrected.<br />
Example 2:<br />
When a submitted e-AAD has been found valid but before allocating the ARC, it is<br />
convenient to securely store it before starting the allocation of the ARC <strong>and</strong> performing<br />
the related actions; therefore, in case of breakdown during these actions (e.g. sudden<br />
unavailability of resources), they can be resumed when the failure is corrected.<br />
Example 3:<br />
When a valid e-AAD is ready to be sent to the MSA of destination, <strong>and</strong> in connection<br />
with the required business acknowledgement, it is convenient to securely store it before<br />
sending it <strong>and</strong> until the business acknowledgement arrives. This makes it possible to<br />
replay the information exchange if neither positive nor negative acknowledgement has<br />
been received in a given time limit.<br />
5.1.6 PR06: Business acknowledgement<br />
It is important for the EMCS business to ensure that an Information Exchange will not be<br />
lost between two MSAs because of a failure or because of a too long transmission delay.<br />
This is particularly uneasy to discover.<br />
It is therefore essential, at least for the essential Information Exchanges, that the sending<br />
MSA has a confirmation that the recipient MSA has correctly received <strong>and</strong> processed that<br />
exchange.<br />
The solution element, named business acknowledgement, consists in a positive<br />
acknowledgement message (ACK) sent back to the issuing MSA. This message<br />
acknowledges that:<br />
ECP2-FITSDEV2-SC03-<strong>FRS</strong>v3.11.doc Page 29 of 53
DG TAXUD – EXCISE COMPUTERISATION PROJECT REF: ECP2-FITSDEV2-SC03-<strong>FRS</strong><br />
FALLBACK AND RECOVERY SPECIFICATION (<strong>FRS</strong>) VERSION: 3.11-EN<br />
Solution elements<br />
� the recipient MSA has correctly received the sent Information Exchange;<br />
� it has already completed the actions pursuant to it or it commits itself to complete<br />
these actions.<br />
This response has the drawback to add a part of traffic into the Common Domain<br />
network. Therefore it has not been made systematic <strong>and</strong> is reserved to very essential<br />
business processes. Appendix B gives the list of the Information Exchanges to be covered<br />
by a business acknowledgement.<br />
Example:<br />
If a report of receipt is sent by the MSA of destination to the MSA of dispatch. This is of<br />
high importance for the economic operators <strong>and</strong> deserves a specific detection mechanism.<br />
So, an MSA of dispatch receiving a validated report of receipt should acknowledge the<br />
receipt of the report of receipt as soon as it has received <strong>and</strong> identified it.<br />
5.1.7 PR07: Follow-up ‘open’ information<br />
If a business process is not completed in due time, a movement may remain in an<br />
unsolved state (that is to say, it will never reach a final state such as delivered,<br />
cancelled…). To reduce the risk that a movement remains indefinitely open, detection of<br />
such cases is necessary.<br />
The FESS [R6] provides for some mechanisms to be implemented at international level;<br />
it is highly recommended that Member States complete them at national level.<br />
Example:<br />
If a report of receipt is not submitted by the expected date of delivery, the MSA of<br />
dispatch sends a signal to the consignor <strong>and</strong> to the MSA of destination so that they<br />
undertake relevant actions, to establish where <strong>and</strong> in which state the goods are <strong>and</strong> to<br />
remind the relevant actor that recovery actions are necessary.<br />
5.2 Administrative procedures<br />
AP01 Enquire on information<br />
AP04 Broadcast information on unavailability<br />
AP05 Perform internal controls<br />
AP06 Take a business decision<br />
AP07 Transfer issue to support<br />
AP08 Exchange information outside EMCS<br />
Administrative procedures serve the following purposes:<br />
� further document an exception after it has been detected;<br />
� refer to any procedure which leads to a decision about how to proceed further: asking<br />
for more information, asking for a correction; this includes enquiries (if more<br />
information is needed) or sharing of information (if other concerned parties must be<br />
informed).<br />
ECP2-FITSDEV2-SC03-<strong>FRS</strong>v3.11.doc Page 30 of 53
DG TAXUD – EXCISE COMPUTERISATION PROJECT REF: ECP2-FITSDEV2-SC03-<strong>FRS</strong><br />
FALLBACK AND RECOVERY SPECIFICATION (<strong>FRS</strong>) VERSION: 3.11-EN<br />
Solution elements<br />
In general, when an exception is fully documented, this normally leads to a business<br />
decision resulting in the application of a fallback <strong>and</strong>/or a recovery solution.<br />
5.2.1 AP01: Enquire on information<br />
If expected information is not received by an organisation at a specific location, this<br />
organisation will enquire on the whereabouts of the missing information. By organisation,<br />
one must underst<strong>and</strong> any MSA or any economic operator.<br />
This may be achieved, where possible, by using the st<strong>and</strong>ard functionality of EMCS such<br />
as remote consultation of movement data (UC2.51, UC2.52) or administrative<br />
cooperation (UC3.07), but getting information may have to be achieved outside EMCS.<br />
Example:<br />
If, upon validation of an e-AAD, the excise number of an economic operator is found not<br />
existing, it is the responsibility of the consignor to query his partner to get the correct<br />
information.<br />
5.2.2 AP04: Broadcast information on unavailability<br />
Whenever an actor is unable to communicate with other actors or to perform some<br />
functions, that actor should notify that unavailability to its partners, preferably<br />
announcing the anticipated time to recover.<br />
This allows, in particular, planning interruption of services for maintenance purpose.<br />
For what concerns the communication over the Common Domain, this is achieved<br />
through a particular use case (UC0.07).<br />
It is recommended that each MSA provides for administrative procedures to manage the<br />
planned unavailability of economic operators.<br />
Example 1:<br />
If a given MSA plans an interruption of a part of EMCS functions, it must notify the<br />
other Administrations through UC0.07; consequently, the other MSAs have then to take<br />
the relevant fallback provisions such as to enqueue all messages they would have to send<br />
<strong>and</strong> adapt the management of deadlines consequently.<br />
Example 2:<br />
A given MSA may provide that, whenever an economic operator observes that he will not<br />
be in a position to submit nor receive electronic messages for a given period, he must<br />
notify this to the MSA so that it can take the relevant provisions.<br />
This may be a prerequisite for an economic operator using the fallback forms without<br />
prior attempt of electronic submission (which does not exempt him from further<br />
electronic recovery).<br />
5.2.3 AP05: Perform internal controls<br />
Each MSA applies administrative procedures to analyse exceptions after they have<br />
occurred, <strong>and</strong> to determine their cause.<br />
ECP2-FITSDEV2-SC03-<strong>FRS</strong>v3.11.doc Page 31 of 53
DG TAXUD – EXCISE COMPUTERISATION PROJECT REF: ECP2-FITSDEV2-SC03-<strong>FRS</strong><br />
FALLBACK AND RECOVERY SPECIFICATION (<strong>FRS</strong>) VERSION: 3.11-EN<br />
Solution elements<br />
These procedures aim at ensuring a posteriori that an exception does not result from fraud<br />
or fraud attempt.<br />
They should be applied at least in all the cases where an exception is assumed to be a<br />
result of a (possible) human mistake/error, <strong>and</strong> any time they are deemed necessary by<br />
the administration in charge.<br />
Example:<br />
If a change of destination is issued by the consignor for an e-AAD that has already been<br />
discharged, the business process is rejected. It is then up to the MSA of dispatch to<br />
examine the case <strong>and</strong> to enquire on the actual situation, whether it is an error or an<br />
attempt of fraud.<br />
5.2.4 AP06: Take a business decision<br />
In EMCS, when processing a movement encounters an exceptional situation that prevents<br />
it from running its business in the expected way, a decision on the course of action judged<br />
best adapted to this situation will first have to be taken.<br />
This decision will be based on the available information. This may comprise, but is not<br />
limited to:<br />
� the causes of the exception, <strong>and</strong> how long it is expected to last;<br />
� the nature of the movement;<br />
� the quality of the business relationship with the trader;<br />
� the time constraints;<br />
� the availability of fallback solution(s).<br />
Example:<br />
If the consignee did not issue a report of receipt <strong>and</strong>, after enquiry, the consignor<br />
observes that the goods are still moving far from the place of delivery, he decides to<br />
change the destination, possibly to return goods at the place of dispatch.<br />
5.2.5 AP07: Transfer issue to support<br />
Upon any event such as negative result of the validation of received data against existing<br />
information, an MSA application may find it impossible to continue the processing <strong>and</strong><br />
reports the error to the persons in charge of the operation of the system, either economic<br />
operators or officials.<br />
The causes may be obscure for these persons, in particular in case of de-synchronisation<br />
between the IT systems of economic operators <strong>and</strong>/or the MSA application databases.<br />
Sometimes, the actual error is the result from previous undetected errors, which makes it<br />
necessary to undertake real enquiries inside the system.<br />
In such cases, <strong>and</strong> after having verified the consistency of the data at his disposal, the<br />
concerned person is entitled to warn the National Service Desk, so that the latter<br />
investigates <strong>and</strong> determines appropriate actions to be undertaken to solve the issue.<br />
ECP2-FITSDEV2-SC03-<strong>FRS</strong>v3.11.doc Page 32 of 53
DG TAXUD – EXCISE COMPUTERISATION PROJECT REF: ECP2-FITSDEV2-SC03-<strong>FRS</strong><br />
FALLBACK AND RECOVERY SPECIFICATION (<strong>FRS</strong>) VERSION: 3.11-EN<br />
Solution elements<br />
Example:<br />
At validation of an e-AAD, a given data item is found incorrect by the MSA of dispatch,<br />
whereas the consignor did fill the corresponding fields correctly according the reference<br />
information he knows.<br />
The MSA of dispatch rejects the draft e-AAD on the basis of its current reference data<br />
<strong>and</strong> sends an error message to the consignor.<br />
The consignor should first verify that he has given the correct information then he should<br />
report the issue to the support of his national service desk.<br />
5.2.6 AP08: Exchange information outside EMCS<br />
This solution element is to be used each time that an economic operator needs to transfer<br />
information that another economic operator may provide <strong>and</strong> either the transmission<br />
channel through the economic operators does not work or there is no need to bother the<br />
MSAs with such data flows.<br />
The transmission channel is completely defined by bilateral agreement between economic<br />
operators.<br />
Example:<br />
If, upon request of explanation on a delay in the submission of the report of receipt, a<br />
consignor is unable to send the relevant message explaining the delay to the MSA of<br />
dispatch, he can send the information directly to the consignee who can then send them to<br />
the MSA of destination, if found relevant.<br />
5.3 <strong>Fallback</strong> solution elements<br />
FB01 Use alternate communication medium<br />
FB02 Revert to manual without subsequent input<br />
FB03 Revert to manual with subsequent input<br />
FB04 No intervention – wait<br />
FB06 Notify administration<br />
FB08 Notify economic operator<br />
<strong>Fallback</strong> solution elements are required to allow the continuation of operations when an<br />
exception is encountered, <strong>and</strong> to avoid delaying urgent excise business.<br />
If it is judged that the business can wait until full restoration of the normal working<br />
conditions, a „No intervention – Wait‟ response is also available.<br />
Depending on the nature of the fallback solution, it has or does not have to be followed<br />
by a recovery procedure. If it is the case, this is explicitly mentioned in the description of<br />
the solution.<br />
ECP2-FITSDEV2-SC03-<strong>FRS</strong>v3.11.doc Page 33 of 53
DG TAXUD – EXCISE COMPUTERISATION PROJECT REF: ECP2-FITSDEV2-SC03-<strong>FRS</strong><br />
FALLBACK AND RECOVERY SPECIFICATION (<strong>FRS</strong>) VERSION: 3.11-EN<br />
Solution elements<br />
5.3.1 FB01: Use alternate communication medium<br />
If the communication medium normally used for an information exchange becomes<br />
unavailable, another communication medium may be used to complete this information<br />
exchange.<br />
A communication medium, able to bear structured electronic information (such as an<br />
electronic form transferred through e-mail, or a web interface), will be used as a part of<br />
the normal electronic processing. The security aspects of the information exchanges (both<br />
normal <strong>and</strong> fallback, including e-mails) shall be catered at national level.<br />
This covers exclusively communication channels that support interconnection with the<br />
normal EMCS processing. Other communication means such as a fax are excluded from<br />
that solution element. Successful use of another communication medium exempts the<br />
economic operator from any recovery actions.<br />
Note: Optical Character Recognition (OCR) may be considered as a possible solution to<br />
extract information from images, but not reliable enough to be entered into the EMCS<br />
application. However, the extracted information might be used by an MSA as input to<br />
preliminary automated risk assessment.<br />
In contrast, any set of information that can be considered structured enough to be inserted<br />
into the EMCS application must be regarded as an alternative communication means <strong>and</strong><br />
does not belong to the paper fallback system; this is in particular the case of electronic<br />
forms.<br />
This solution element must be preferred to fallback to paper each time that it is possible.<br />
This response does not apply to normal CCN/CSI communication, except for the<br />
management <strong>and</strong> dissemination of SEED data that is felt important enough to justify<br />
redundancy of communication media.<br />
Example 1:<br />
If the normal communication medium used between a consignor <strong>and</strong> his MSA is a file<br />
attached to an e-mail, an alternative solution, among other possibilities, is a website<br />
where the consignor directly enters data into a form.<br />
Example 2:<br />
Each MSA may have a preferred channel to - in particular - receive the SEED updates;<br />
however, it should be ready to revert to another solution in case of (long lasting)<br />
unavailability of that channel.<br />
ECP2-FITSDEV2-SC03-<strong>FRS</strong>v3.11.doc Page 34 of 53
DG TAXUD – EXCISE COMPUTERISATION PROJECT REF: ECP2-FITSDEV2-SC03-<strong>FRS</strong><br />
FALLBACK AND RECOVERY SPECIFICATION (<strong>FRS</strong>) VERSION: 3.11-EN<br />
Solution elements<br />
5.3.2 FB02: Revert to manual without subsequent input<br />
If an automated business process becomes unavailable, it is possible to carry out<br />
manually the equivalent operations. No subsequent data input is then required (no<br />
recovery needed). This is the case if the faulty process does not normally result in an<br />
update of the e-AAD, or if the lack of update is judged acceptable, from a business point<br />
of view.<br />
Example:<br />
If automatic risk assessment is unavailable, instead of waiting for the resources to<br />
recover, it is more efficient to exercise it manually.<br />
5.3.3 FB03: Revert to manual with subsequent input<br />
If an automated business process becomes unavailable (e.g. due to a software or a<br />
hardware failure or in case of scheduled unavailability for maintenance), the equivalent<br />
operations are first carried out manually.<br />
This is in particular the object of the paper fallback procedures described in Chapter 6.<br />
To ensure completeness of the EMCS processing, the st<strong>and</strong>ard electronic operations have<br />
then to be completed in deferred mode.<br />
Technically, the only difference between the normal submission <strong>and</strong> the deferred<br />
submission is the initial submission of an e-AAD. In all other cases, normal mode <strong>and</strong><br />
deferred mode are identical.<br />
Example:<br />
If submission of an e-AAD proves unavailable (although its availability requirement is<br />
permanent), the consignor ought to delay the electronic submission as much as possible.<br />
However, business constraints make that the actual dispatch of goods cannot be delayed.<br />
Consequently, the goods will have to leave before a valid e-AAD exists. A fallback AAD<br />
has then to be made to allow the goods moving under the cover of the Excise Number of<br />
the consignor plus the Local Reference Number of the consignment.<br />
It becomes then m<strong>and</strong>atory to submit the corresponding e-AAD as soon as the function<br />
becomes available again.<br />
5.3.4 FB04: No intervention – wait<br />
When an exception impacts business processes that are not critically time-dependent <strong>and</strong><br />
when the anticipated delay does not exceed the acceptable limit for the related functions,<br />
the normal response is to wait until the cause of the exception has been suppressed, <strong>and</strong><br />
the normal procedure can be used.<br />
The economic operator chooses to use this response any time the expected delay is<br />
judged acceptable, or if, for business reasons, regular EMCS procedures are preferred to<br />
fallback procedures.<br />
ECP2-FITSDEV2-SC03-<strong>FRS</strong>v3.11.doc Page 35 of 53
DG TAXUD – EXCISE COMPUTERISATION PROJECT REF: ECP2-FITSDEV2-SC03-<strong>FRS</strong><br />
FALLBACK AND RECOVERY SPECIFICATION (<strong>FRS</strong>) VERSION: 3.11-EN<br />
Solution elements<br />
No recovery is then needed.<br />
Note: at dispatch, if the expected delay exceeds up to a few hours, this being not judged<br />
acceptable by the trader, the latter has to use an alternate way to communicate the<br />
movement information to the excise office (see FB01) before departure of the goods.<br />
Example:<br />
If submission of the report of receipt is temporarily unavailable, the consignee, based on<br />
the rules established by its Administration, may consider it acceptable to wait a few hours<br />
(or even up to one to two days before considering reverting to fallback paper procedures)<br />
before submitting it. This would have little impact on the excise business.<br />
5.3.5 FB06: Notify administration<br />
This response exclusively addresses the communication between an economic operator<br />
<strong>and</strong> his national Administration. Consequently, its detailed definition depends on national<br />
provisions.<br />
The transmission channel may be any solution found relevant by the MSA, such as:<br />
� access to a support Web portal;<br />
� e-mail;<br />
� fax;<br />
� phone call to a help desk;<br />
� SMS to a dedicated number;<br />
� etc.<br />
This amounts to an anticipated announcement that, during the indicated period, the<br />
economic operator could directly use alternate solutions (typically, fall back to paper)<br />
without trying the st<strong>and</strong>ard solution.<br />
Example:<br />
In case of a long-lasting unavailability of the IT system of an economic operator, this<br />
latter impacts business processes that are critically time-dependent.<br />
The economic operator may be required to inform the competent Administration of the<br />
nature <strong>and</strong> conditions of the exception.<br />
This information should contain at least:<br />
� list of the unavailable functions;<br />
� expected time to recover.<br />
Typically, during that period, a consignor may be allowed to directly use the fallback<br />
AAD without trying an electronic submission that will surely fail.<br />
Conversely, as the time constraint for the submission of a report of receipt is not very<br />
stringent, the consignee should preferably wait for the electronic system to recover to<br />
submit a report of receipt.<br />
ECP2-FITSDEV2-SC03-<strong>FRS</strong>v3.11.doc Page 36 of 53
DG TAXUD – EXCISE COMPUTERISATION PROJECT REF: ECP2-FITSDEV2-SC03-<strong>FRS</strong><br />
FALLBACK AND RECOVERY SPECIFICATION (<strong>FRS</strong>) VERSION: 3.11-EN<br />
Solution elements<br />
5.3.6 FB08: Notify economic operator<br />
That response exclusively addresses the communication between an Administration <strong>and</strong><br />
an economic operator of its Member State. Consequently, its detailed definition depends<br />
on national provisions.<br />
In all cases where a severe exception arises that necessitates the collaboration of an<br />
economic operator, the competent Administration contacts that operator to establish the<br />
relevant actions.<br />
The transmission channel may be any solution found relevant by the MSA, such as:<br />
� e-mail;<br />
� fax;<br />
� SMS to a registered number;<br />
� etc.<br />
Example: The application of the MSA of dispatch starts a timer (for example,<br />
TIM_CHS) to expire in a given time limit by which the consignor is expected to issue<br />
either a change of destination or a splitting. If no such operation has been submitted<br />
within the time limit, the MSA shall issue a reminder notification to the consignor. If this<br />
reminder is not electronically implemented by the NEA then the MSA can send the<br />
reminder outside the system via any of the above mentioned means (such as, e-mail, fax,<br />
or SMS to a registered number, etc).<br />
5.4 <strong>Recovery</strong> solution elements<br />
RC03 Restart or replace technical component<br />
RC04 Enter data using the normal procedure<br />
RC05 No intervention - accept exception<br />
RC06 Collate electronic record with the fallback form<br />
RC07 Replay information exchange<br />
RC10 Re-apply undone changes<br />
<strong>Recovery</strong> solution elements are used to correct defective information or to complete<br />
missing information resulting from errors that have occurred in the system, from mistakes<br />
made by users, or from the application of fallback solutions.<br />
If it is considered that the business impact of an exception is acceptable, a „No<br />
intervention – accept exception‟ solution is also available.<br />
5.4.1 RC03: Restart or replace technical component<br />
If some component necessary to complete a business process is found unavailable or<br />
faulty, processing cannot carry on any more. The failing component must be restarted or<br />
replaced as soon as possible.<br />
ECP2-FITSDEV2-SC03-<strong>FRS</strong>v3.11.doc Page 37 of 53
DG TAXUD – EXCISE COMPUTERISATION PROJECT REF: ECP2-FITSDEV2-SC03-<strong>FRS</strong><br />
FALLBACK AND RECOVERY SPECIFICATION (<strong>FRS</strong>) VERSION: 3.11-EN<br />
Solution elements<br />
Example:<br />
If the processing of information includes access to a database that is currently locked or<br />
has fallen out, the business process becomes unavailable. The database, possibly a backup<br />
copy, must be restarted as soon as possible.<br />
5.4.2 RC04: Enter data using the normal procedure<br />
After fallback solution has been used, enter missing data in EMCS using a st<strong>and</strong>ard use<br />
case.<br />
This is in particular, but not exclusively, the normal recovery solution each time a<br />
fallback form has been used.<br />
From the point of view of the functioning of EMCS, this solution element must be<br />
considered the best one as it restores a completely normal situation.<br />
This solution must be applied as soon as possible to complete the EMCS processing.<br />
Example:<br />
Following the issuance of a fallback AAD, the consignor is committed to submit the e-<br />
AAD itself in deferred mode, as soon as this becomes technically possible.<br />
5.4.3 RC05: No intervention – accept exception<br />
In several cases, an exception is simply accepted without any direct attempt to correct it.<br />
This will happen in the following situations:<br />
1. the business impact of the exception is not critical <strong>and</strong> can be accepted;<br />
2. the EMCS movement has reached an irreversible state <strong>and</strong> the exception cannot be<br />
corrected.<br />
Example:<br />
If a consignee repeatedly fails in trying to submit an alert with or without rejection, he<br />
may choose to give up with that use case <strong>and</strong> not even inform the consignor of what<br />
finally appears minor or becomes unnecessary, for instance if the consignor has<br />
spontaneously changed the destination in the meantime.<br />
5.4.4 RC06: Collate electronic record with the fallback form<br />
In some cases, it is necessary to use a fallback form. With a very few exceptions, the<br />
operations covered by fallback forms have to be electronically recovered as soon as<br />
possible when the incident that caused the fallback is closed.<br />
The MSA of the economic operator who submitted the fallback form is entitled to<br />
compare the electronic record with the information contained in the fallback form to<br />
verify their consistency.<br />
In case where differences are found, the discrepancies fall under national provisions of<br />
the MSA of the concerned economic operator. The processing of EMCS continues with<br />
the electronic information.<br />
ECP2-FITSDEV2-SC03-<strong>FRS</strong>v3.11.doc Page 38 of 53
DG TAXUD – EXCISE COMPUTERISATION PROJECT REF: ECP2-FITSDEV2-SC03-<strong>FRS</strong><br />
FALLBACK AND RECOVERY SPECIFICATION (<strong>FRS</strong>) VERSION: 3.11-EN<br />
Solution elements<br />
Examples:<br />
If a fallback AAD has been submitted by a consignor, this latter is required to submit the<br />
e-AAD in deferred mode as soon as the failing resources have recovered. Upon receipt of<br />
an e-AAD submitted in deferred mode, an excise officer of the MSA of dispatch may (1)<br />
verify that the consignor has actually submitted a fallback AAD form <strong>and</strong> (2) compare<br />
the contents of the e-AAD with the contents of the fallback AAD.<br />
5.4.5 RC07: Replay information exchange<br />
In cases where a message seems lost between an economic operator <strong>and</strong> his MSA or<br />
between two MSAs, a part of recovery may be to send again the (possibly) lost message.<br />
This can be done several times depending on an acceptable limit to be defined by the<br />
concerned Member State(s). As far as possible, this limit should be an updatable technical<br />
parameter allowing to adapt the number of retries to the current situation, for instance a<br />
network overload should be mitigated by reducing the number of retries.<br />
5.4.6 RC10: Re-apply undone changes<br />
This response follows a prior undo preceding operation (FB09) followed by<br />
rectifications; this consists in restoring the local state of the concerned object.<br />
Unless explicitly described, no rectifying Information Exchange has to be sent to other<br />
partners.<br />
ECP2-FITSDEV2-SC03-<strong>FRS</strong>v3.11.doc Page 39 of 53
DG TAXUD – EXCISE COMPUTERISATION PROJECT REF: ECP2-FITSDEV2-SC03-<strong>FRS</strong><br />
FALLBACK AND RECOVERY SPECIFICATION (<strong>FRS</strong>) VERSION: 3.11-EN<br />
Paper fallback system<br />
6 Paper fallback system<br />
6.1 Overview<br />
By paper fallback system, one must underst<strong>and</strong>:<br />
� a set of fallback forms that, depending on the case, are not necessarily printed on<br />
paper; <strong>and</strong><br />
� a series of procedures for the use of these forms.<br />
Each partner, <strong>and</strong> in particular the consignor, should as much as possible avoid making a<br />
fallback form; this implies:<br />
� using electronic alternate communication means each time that it is possible,<br />
preferably to the paper fallback system, as described in FB01 - Use alternate<br />
communication medium;<br />
� waiting until the extreme time limit before issuing a fallback form; this applies not<br />
only to the submission of the e-AAD but to all other main business cases described in<br />
point 6.5 as well; consequently, <strong>and</strong> given the acceptable delays in each case, only the<br />
fallback AAD <strong>and</strong> the fallback interruption notification are considered really likely to<br />
be submitted (<strong>and</strong> the fallback cancellation where no recovery is necessary).<br />
This chapter describes the administrative circuits of the paper fallback system applicable<br />
when EMCS may become unavailable, corresponding to fallback solution elements,<br />
mainly FB03 - Revert to manual with subsequent input <strong>and</strong> secondarily FB02 -<br />
Revert to manual without subsequent input.<br />
It lists roles <strong>and</strong> responsibilities, depending on the location of occurring exceptions, <strong>and</strong><br />
depicts the associated relevant procedures.<br />
It considers next how to recover from the forms to the computerised procedures.<br />
6.2 Roles <strong>and</strong> responsibilities<br />
The figure below represents the summary of an EMCS information flow between a<br />
consignor <strong>and</strong> a consignee.<br />
consignor<br />
A<br />
B C D<br />
MSA of dispatch<br />
(Excise officer)<br />
MSA of destination<br />
(Excise officer)<br />
Figure 2 e-AAD management information flows<br />
consignee<br />
Exceptions related to EMCS unavailability can occur in the following locations:<br />
� consignor‟s premises (A);<br />
� MSA of dispatch (B);<br />
ECP2-FITSDEV2-SC03-<strong>FRS</strong>v3.11.doc Page 40 of 53
DG TAXUD – EXCISE COMPUTERISATION PROJECT REF: ECP2-FITSDEV2-SC03-<strong>FRS</strong><br />
FALLBACK AND RECOVERY SPECIFICATION (<strong>FRS</strong>) VERSION: 3.11-EN<br />
Paper fallback system<br />
� MSA of destination (C);<br />
� consignee‟s premises (D).<br />
According to the use case <strong>and</strong> to the location, occurrences of such exceptions have very<br />
different impacts on EMCS business.<br />
The paper fallback procedures are described considering that EMCS may become<br />
unavailable in any of the locations depicted above.<br />
6.2.1 Unavailability at consignor’s premises (location A)<br />
Unavailability of EMCS at consignor‟s premises must not prevent the sending of the<br />
consignment.<br />
On the other h<strong>and</strong>, any dispatch of goods under excise suspension must be communicated<br />
to the MSA of dispatch.<br />
Therefore, it will be the responsibility of the consignor to inform the MSA of dispatch<br />
before the beginning of the movement of the unavailability of EMCS <strong>and</strong> use the relevant<br />
fallback administrative circuit depicted in point 6.5 for submission of the AAD (point<br />
6.5.1) <strong>and</strong> any other business purpose (points 6.5.2, 6.5.4 <strong>and</strong> 6.5.5) <strong>and</strong> to re-issue as<br />
soon as the application is available again the equivalent electronic operations. The MSA<br />
of dispatch may also require a copy of the fallback AAD <strong>and</strong> appropriate information on<br />
the reasons for the unavailability before the beginning of the movement.<br />
6.2.2 Unavailability at MSA of dispatch (location B)<br />
Unavailability of EMCS at MSA of dispatch should not prevent the sending of the<br />
consignment by the consignor. On the other h<strong>and</strong>, any dispatch of goods under excise<br />
suspension must be communicated to the MSA of dispatch before the beginning of the<br />
movement. The MSA of dispatch may also require a copy of the fallback AAD before the<br />
beginning of the movement.<br />
Therefore, economic operators will have to follow paper procedures directly with their<br />
excise office (procedures to be started after a certain time depending on the case <strong>and</strong> to be<br />
decided by the MSA).<br />
6.2.3 Unavailability at MSA of destination (location C)<br />
The excise office at destination receives movement related fallback form from MSA of<br />
dispatch (in case of unavailability of EMCS at MSA of dispatch).<br />
In case of unavailability of EMCS at MSA of destination, the paper circuit should not<br />
prevent receiving the consignment by the consignee. On the other h<strong>and</strong>, any receipt of<br />
goods under excise suspension must be communicated to the MSA of destination, except<br />
in duly justified circumstances, using a paper document containing the same data as the<br />
report of receipt.<br />
Therefore, in case of EMCS unavailability at MSA of destination, economic operators<br />
will have to follow fallback procedures directly with their excise office (procedures to be<br />
started after a certain time depending on the case <strong>and</strong> to be decided by the MSA).<br />
ECP2-FITSDEV2-SC03-<strong>FRS</strong>v3.11.doc Page 41 of 53
DG TAXUD – EXCISE COMPUTERISATION PROJECT REF: ECP2-FITSDEV2-SC03-<strong>FRS</strong><br />
FALLBACK AND RECOVERY SPECIFICATION (<strong>FRS</strong>) VERSION: 3.11-EN<br />
Paper fallback system<br />
6.2.4 Unavailability at consignee’s premises (location D)<br />
The consignee must communicate any receipt of goods under excise suspension to the<br />
MSA of destination, except in duly justified cases, using a paper document containing the<br />
same data as the report of receipt. Whether the consignee is entitled to simply wait for the<br />
IT system becoming available <strong>and</strong> the length of the waiting period itself will thus depend<br />
on the general instructions of its MSA on how to react to the situation.<br />
6.3 <strong>Fallback</strong> paper forms<br />
The current AAD described in the Commission Regulation 2719/92 on the accompanying<br />
administrative document for the movement under duty-suspension arrangements of<br />
products subject to excise duty shall become obsolete with the entry into operation of<br />
EMCS (Functional Stage 1) by all the Member States. It will be replaced by the<br />
electronic records.<br />
To support the fallback system, a set of paper documents containing the same data as the<br />
corresponding EMCS messages will have to be used. These data shall be displayed in the<br />
form of data elements, expressed in the same manner as in the corresponding electronic<br />
messages. All the data elements, as well as the data groups <strong>and</strong> data subgroups to which<br />
they belong, shall be identified by means of the numbers <strong>and</strong> letters in column A <strong>and</strong><br />
column B of Table 1 of Annex I to the Commission Regulation implementing Council<br />
Directive 2008/118/EC on the general arrangements for excise duty with regard to the<br />
computerised procedures for the movement of excise goods under a duty suspension<br />
arrangement, which is under preparation.<br />
6.4 <strong>Fallback</strong> communication media<br />
The fallback forms are exclusively reserved to cases where the information has to be<br />
carried by paper-like supports such as (by decreasing order of preference):<br />
� free text e-mail;<br />
� fax;<br />
� paper (sent by regular mail, or h<strong>and</strong>ed directly to the person).<br />
However, according to ESS Security policy [R1], proper means must be put in place to<br />
ensure confidentiality of data exchanged between partners (traders, MSAs).<br />
On the other h<strong>and</strong>, where fax would be preferred to e-mail as a medium, this requires the<br />
management of up-to-date fax directories.<br />
In any case, when a paper fallback takes place, the information should then be re-entered<br />
in the system, as soon as it becomes available again.<br />
ECP2-FITSDEV2-SC03-<strong>FRS</strong>v3.11.doc Page 42 of 53
DG TAXUD – EXCISE COMPUTERISATION PROJECT REF: ECP2-FITSDEV2-SC03-<strong>FRS</strong><br />
FALLBACK AND RECOVERY SPECIFICATION (<strong>FRS</strong>) VERSION: 3.11-EN<br />
Paper fallback system<br />
6.5 Main business cases fallback procedures<br />
6.5.1 Submission of AAD<br />
(original)<br />
AAD<br />
form<br />
�<br />
consignor<br />
�<br />
(copy)<br />
AAD<br />
form<br />
AAD<br />
form<br />
�<br />
�<br />
(mail/fax)<br />
AAD<br />
form<br />
MSA of dispatch<br />
(Excise officer)<br />
consignee<br />
(mail/fax)<br />
MSA of destination<br />
(Excise officer)<br />
ECP2-FITSDEV2-SC03-<strong>FRS</strong>v3.11.doc Page 43 of 53<br />
�<br />
�<br />
AAD<br />
form<br />
Figure 3 Submission of AAD – fallback administrative circuit<br />
The procedure associated with the circuit above is as follows:<br />
1. the consignor fills in relevant fields of the fallback AAD form (cf. UC2.01–<br />
submission <strong>and</strong> registration of e-AAD); in particular, he assigns a Local Reference<br />
Number (LRN), being a serial number, to the AAD to serve as reference as long as<br />
there is no ARC assigned by the IT system;<br />
2. the consignor informs the MSA of dispatch or, if required by that MSA, sends it a<br />
copy of the fallback AAD form prior to dispatch of the goods or, in case of<br />
unavailability of means of communication, as soon as they become available again. If<br />
the consignor is responsible for the unavailability, the MSA of dispatch may also<br />
require appropriate information on the reasons for the unavailability before the<br />
beginning of the movement;<br />
3. as far as possible, the MSA of dispatch may apply risk assessment <strong>and</strong> if required<br />
submits a request for assistance to the MSA of destination;<br />
4. it is up to the consignor to judge whether he sends a copy of the AAD form to the<br />
consignee;<br />
5. if considered useful, the MSA of dispatch sends a notification to the MSA of<br />
destination;<br />
6. as the fallback AAD has to accompany the goods, the consignor gives a paper copy of<br />
it to the accompanying person.
DG TAXUD – EXCISE COMPUTERISATION PROJECT REF: ECP2-FITSDEV2-SC03-<strong>FRS</strong><br />
FALLBACK AND RECOVERY SPECIFICATION (<strong>FRS</strong>) VERSION: 3.11-EN<br />
Paper fallback system<br />
6.5.2 Cancellation of AAD<br />
(original)<br />
CAN<br />
form<br />
�<br />
consignor<br />
CAN<br />
form<br />
�<br />
(mail/fax)<br />
AAD<br />
form<br />
MSA of dispatch<br />
(Excise officer)<br />
�<br />
consignee<br />
(mail/fax)<br />
MSA of destination<br />
(Excise officer)<br />
ECP2-FITSDEV2-SC03-<strong>FRS</strong>v3.11.doc Page 44 of 53<br />
�<br />
AAD<br />
form<br />
Figure 4 Cancellation of AAD – fallback administrative circuit<br />
The procedure associated with the circuit above is as follows:<br />
1. the consignor fills in the fallback cancellation notification form;<br />
2. the consignor sends a copy of the form to the MSA of dispatch; the goods must not<br />
have left the place of dispatch;<br />
3. it is up to the consignor to judge whether he sends a copy of the form to the<br />
consignee;<br />
4. if considered useful, the MSA of dispatch sends a copy of the form to the MSA of<br />
destination.<br />
6.5.3 Report of receipt<br />
(original)<br />
RoR<br />
form<br />
�<br />
consignee<br />
(mail/fax)<br />
RoR<br />
form<br />
�<br />
(mail/fax)<br />
RoR<br />
form<br />
(mail/fax)<br />
RoR<br />
form<br />
MSA of destination<br />
(Excise officer) MSA of dispatch<br />
(mail/fax) (Excise officer)<br />
�<br />
consignor<br />
�<br />
�<br />
RoR<br />
form<br />
Figure 5 Report of receipt – fallback administrative circuit<br />
The procedure associated with the circuit above is as follows:<br />
1. the consignee fills in relevant fields of the fallback report of receipt form<br />
(cf. UC2.06–submission of report of receipt);<br />
2. the consignee sends a copy of the form to the MSA of destination;<br />
3. except where the report of receipt can be submitted promptly, or in duly justified<br />
cases, the MSA of destination sends a copy of the form to the MSA of dispatch;<br />
4. the MSA of dispatch shall forward a copy of the form to the consignor or keep it<br />
available for him;
DG TAXUD – EXCISE COMPUTERISATION PROJECT REF: ECP2-FITSDEV2-SC03-<strong>FRS</strong><br />
FALLBACK AND RECOVERY SPECIFICATION (<strong>FRS</strong>) VERSION: 3.11-EN<br />
Paper fallback system<br />
5. it is up to the consignee to decide if he will send a copy of the fallback report of<br />
receipt form to the consignor.<br />
6.5.4 Change of destination<br />
(mail/fax)<br />
CoD<br />
form<br />
CoD<br />
form<br />
(former)<br />
�<br />
consignor<br />
consignee �<br />
(copy) � (mail/fax)<br />
AAD<br />
form<br />
AAD<br />
form<br />
updated<br />
AAD<br />
form<br />
� �<br />
(new)<br />
consignee<br />
MSA of dispatch<br />
(Excise officer)<br />
(mail/fax)<br />
(mail/fax)<br />
(former)<br />
MSA of destination<br />
(Excise officer)<br />
MSA of destination<br />
(Excise officer)<br />
ECP2-FITSDEV2-SC03-<strong>FRS</strong>v3.11.doc Page 45 of 53<br />
�<br />
�<br />
CoD<br />
form<br />
AAD<br />
form<br />
Figure 6 Change of destination – fallback administrative circuit<br />
The procedure associated with the circuit above is as follows:<br />
1. the consignor fill in the relevant fields of the CoD form (cf. UC2.05-Change of<br />
destination) <strong>and</strong> sends it to the MSA of Dispatch;<br />
2. if possible the MSA of dispatch may apply risk assessment on the fallback updated<br />
AAD form <strong>and</strong> if required submits a request for assistance to the new or former MSA<br />
of Destination;<br />
3. it is up to the consignor to judge whether he sends a copy of the CoD form to the<br />
former consignee;<br />
4. it is up to the consignor to judge whether he sends a copy of the updated AAD form<br />
to the (new) consignee;<br />
5. if considered useful, the MSA of dispatch sends the CoD form to the (former) MSA<br />
of destination <strong>and</strong> the AAD form to the new MSA of destination;<br />
6. the consignor informs the carrier of the new destination (the latter may annotate the<br />
new destination information on the document that mentions the ARC of the e-AAD or<br />
on the fallback AAD).
DG TAXUD – EXCISE COMPUTERISATION PROJECT REF: ECP2-FITSDEV2-SC03-<strong>FRS</strong><br />
FALLBACK AND RECOVERY SPECIFICATION (<strong>FRS</strong>) VERSION: 3.11-EN<br />
Paper fallback system<br />
6.5.5 Splitting<br />
(former)<br />
consignee<br />
�<br />
(mail/fax<br />
)<br />
CoD<br />
consignor<br />
�<br />
(copy)<br />
AAD<br />
AAD<br />
AAD<br />
form<br />
form<br />
form<br />
�<br />
AAD<br />
AAD<br />
CoD AAD form<br />
form<br />
form<br />
(mail/fax)<br />
AAD<br />
AAD<br />
AAD<br />
form<br />
form<br />
form<br />
MSA of dispatch CoD<br />
(Excise officer)<br />
AAD<br />
AAD<br />
AAD<br />
form<br />
form<br />
form<br />
(new)<br />
consignees<br />
Figure 7 Splitting – fallback administrative circuit<br />
ECP2-FITSDEV2-SC03-<strong>FRS</strong>v3.11.doc Page 46 of 53<br />
�<br />
�<br />
�<br />
All MSAs of destination<br />
(Excise officer)<br />
The procedure associated with splitting is as follows:<br />
1. the consignor sends to the MSA of Dispatch:<br />
� a series of new fallback AAD forms with relevant fields filled in (cf. UC2.01 –<br />
submission <strong>and</strong> registration of e-AAD); in particular, each of these new AADs has<br />
its own (<strong>and</strong> new) LRN;<br />
� if the (former) consignee is not the consignee of any new part, a CoD form as well;<br />
2. if possible the MSA of dispatch may apply risk assessment to the splitting operation<br />
considered as a whole <strong>and</strong> if required submits a request for assistance to be sent to<br />
part or all of the new or former MSAs of destination;<br />
3. if the (former) consignee is not the consignee of any new part, it is up to the<br />
consignor to judge whether he sends a copy of the CoD form to him;<br />
4. for each new AAD form created from the split AAD, it is up to the consignor to judge<br />
whether he sends its copy to the intended (new) consignee;<br />
5. if considered useful, the MSA of dispatch sends a copy of the CoD form to the former<br />
MSA of destination <strong>and</strong> copies of the new AAD forms to each new MSA (of<br />
destination);<br />
6. the consignor informs each involved carrier of the new destinations (the carriers may<br />
annotate the new destination information on the document that mentions the ARC of<br />
the e-AAD or on the fallback AAD).
DG TAXUD – EXCISE COMPUTERISATION PROJECT REF: ECP2-FITSDEV2-SC03-<strong>FRS</strong><br />
FALLBACK AND RECOVERY SPECIFICATION (<strong>FRS</strong>) VERSION: 3.11-EN<br />
Paper fallback system<br />
6.5.6 Interruption<br />
�<br />
�<br />
Interrupting MSA<br />
(Excise officer)<br />
(mail/fax)<br />
MSA of dispatch<br />
(Excise officer)<br />
MSA of destination<br />
(Excise officer)<br />
ECP2-FITSDEV2-SC03-<strong>FRS</strong>v3.11.doc Page 47 of 53<br />
Int.<br />
CoD<br />
(mail/fax)<br />
�<br />
Int.<br />
CoD<br />
Figure 8 Interruption – fallback administrative circuit<br />
The procedure associated with interruption is as follows:<br />
1. the interrupting MSA prepares a specific form, with “movement interrupted” clearly<br />
mentioned on it; in addition, this form bears on it:<br />
� the ARC of the movement to be interrupted;<br />
� the reference of the event or control report if any;<br />
2. the interrupting MSA sends this form to the MSA of dispatch <strong>and</strong> to the MSA of<br />
destination (no interested MSAs informed).<br />
6.5.7 Control<br />
�<br />
�<br />
MSA of Control<br />
(Control officer)<br />
(mail/fax)<br />
Control<br />
Report<br />
form<br />
(mail/fax)<br />
�<br />
Control<br />
Report<br />
form<br />
MSA of dispatch<br />
(Excise officer)<br />
MSA of destination<br />
(Excise officer)<br />
Figure 9 Control – fallback administrative circuit<br />
The procedure associated with a control is as follows:<br />
1. the MSA of control fills in the relevant fields of a control report form, including:<br />
� the ARC of the controlled movement; or<br />
� the excise number of the consignor plus the LRN, if the e-AAD has not been<br />
created yet;<br />
2. the MSA of control sends this control report form to the MSA of dispatch <strong>and</strong> to the<br />
MSA of destination (no interested MSAs informed).
DG TAXUD – EXCISE COMPUTERISATION PROJECT REF: ECP2-FITSDEV2-SC03-<strong>FRS</strong><br />
FALLBACK AND RECOVERY SPECIFICATION (<strong>FRS</strong>) VERSION: 3.11-EN<br />
Paper fallback system<br />
6.5.8 Administrative cooperation<br />
�<br />
Requesting MSA<br />
(Excise officer)<br />
�<br />
(mail/fax)<br />
ACO<br />
Request<br />
form<br />
Requested MSA<br />
(Excise officer)<br />
Figure 10 Administrative cooperation – request for assistance<br />
The procedure associated with an administrative cooperation request for assistance is as<br />
follows:<br />
1. the requesting MSA fills in the relevant fields of an administrative cooperation<br />
request for assistance (ACO Request) form, including:<br />
� the ARC of the movement; or<br />
� the excise number of the consignor plus the LRN, if the ARC is unknown.<br />
2. the requesting MSA sends the administrative cooperation request for assistance (ACO<br />
Request) form to the requested MSA.<br />
�<br />
Requested MSA<br />
or issuing MSA<br />
(Excise officer)<br />
�<br />
(mail/fax)<br />
ACO<br />
Results<br />
form<br />
Requesting MSA<br />
or addressed MSA<br />
(Excise officer)<br />
Figure 11 Administrative cooperation – spontaneous information <strong>and</strong> reply to a request for<br />
assistance<br />
The common procedure associated with the reply to an administrative cooperation request<br />
for assistance or with spontaneous information is as follows:<br />
1. the Requested MSA (or issuing MSA) fills in the relevant fields of an administrative<br />
cooperation results (ACO Results) form;<br />
2. the Requested MSA (or issuing MSA) sends the administrative cooperation results<br />
(ACO Results) form to the requesting MSA or to the addressed MSA.<br />
6.6 <strong>Recovery</strong> from paper fallback procedures<br />
6.6.1 Means to recover<br />
After a paper fallback form has been sent for any function, electronic recovery is<br />
m<strong>and</strong>atory <strong>and</strong> has to be achieved, as much as possible, through the relevant st<strong>and</strong>ard use<br />
cases, namely:<br />
� submission of the e-AAD (UC2.01);<br />
� cancellation of an e-AAD (UC2.10);<br />
� submission of the report of receipt (UC2.06);<br />
� change of destination (UC2.05);<br />
� splitting (UC2.36);<br />
ECP2-FITSDEV2-SC03-<strong>FRS</strong>v3.11.doc Page 48 of 53
DG TAXUD – EXCISE COMPUTERISATION PROJECT REF: ECP2-FITSDEV2-SC03-<strong>FRS</strong><br />
FALLBACK AND RECOVERY SPECIFICATION (<strong>FRS</strong>) VERSION: 3.11-EN<br />
Paper fallback system<br />
� exportation of goods (UC2.44, UC2.43) <strong>and</strong> exit of exported goods (UC2.46);<br />
� interruption of a movement (UC3.05);<br />
� submission of a control report (UC3.03);<br />
� issuance of a spontaneous information (UC3.01);<br />
� request for assistance (UC3.07).<br />
There is however one exception: at cancellation, if a fallback AAD has been made <strong>and</strong><br />
provided that the e-AAD has not been submitted in the meantime, the fallback<br />
cancellation is considered sufficient to inform the MSA of dispatch that the movement<br />
will not take place <strong>and</strong> electronic recovery is unnecessary.<br />
6.6.2 Deferred mode<br />
<strong>Recovery</strong> through electronic input is said to be achieved in deferred mode. More<br />
specifically, the term “deferred mode” is used when the business event precedes the<br />
electronic operation (the submission of an e-AAD). In that case, the fact that the<br />
electronic operation (the submission of an e-AAD) is made in deferred mode must be<br />
made explicit so that the application, when checking the submitted e-AAD, relaxes the<br />
verification that the date of dispatch of goods announced in the e-AAD follows the actual<br />
date <strong>and</strong> time of submission. This has to be expressly specified at submission as follows:<br />
� the consignor inserts an explicit indicator "deferred submission" at submission of the<br />
e-AAD (message IE815);<br />
� if the indicator is set, the date <strong>and</strong> time of dispatch of the goods are not compared with<br />
the date <strong>and</strong> time of submission (i.e. the date <strong>and</strong> time of receipt of the message).<br />
In all other electronic operations no specific technical provisions are necessary.<br />
6.6.3 Summary of intermediate operations<br />
After a series of operations has been achieved through the fallback system, <strong>and</strong><br />
depending on the scenario, it is possible for the consignor to summarise the movement at<br />
recovery by submitting only the latest state of the e-AAD.<br />
Typically, a fallback AAD of which destination has changed in fallback mode may be<br />
recovered directly by submitting the e-AAD with the final destination, without having to<br />
recover all intermediate business steps. This is true including where the first consignee<br />
has rejected the fallback AAD or refused the delivery before the change of destination.<br />
The only exception is where the first consignee has partially refused the delivery; in that<br />
case, the electronic recovery must be achieved in such a way that both partial <strong>and</strong> final<br />
reports of receipt are registered, namely:<br />
� the consignor submits the e-AAD with the first destination where the partial refusal<br />
has been done;<br />
� the consignee submits a report of receipt with partial refusal;<br />
� the consignor changes the destination with the second destination.<br />
ECP2-FITSDEV2-SC03-<strong>FRS</strong>v3.11.doc Page 49 of 53
DG TAXUD – EXCISE COMPUTERISATION PROJECT REF: ECP2-FITSDEV2-SC03-<strong>FRS</strong><br />
FALLBACK AND RECOVERY SPECIFICATION (<strong>FRS</strong>) VERSION: 3.11-EN<br />
Unavailability of SEED information<br />
7 Unavailability of SEED information<br />
SEED data are used in the MSAs for validation purpose (e.g. for draft e-AAD validation).<br />
They are:<br />
� partially managed <strong>and</strong> defined in each MSA ;<br />
� partially managed <strong>and</strong> defined in the Common Domain central services;<br />
� regularly updated from the Common Domain central services.<br />
Exceptions due to the unavailability of SEED information <strong>and</strong> of its dissemination<br />
channels may result in de-synchronisation of the databases among the Member States <strong>and</strong><br />
could cause an abnormal number of calls to the support of the considered MSA.<br />
This may be mitigated by strong provisions:<br />
� reinforce the communication means between the Common Domain central services<br />
<strong>and</strong> each MSA, in both directions but more particularly from the Common Domain to<br />
the MSAs;<br />
� ensure simultaneous enforcement of the updates of SEED in the Member States, at<br />
logical level;<br />
� define the relevant by-pass procedures in the view of long lasting unavailability of the<br />
update of SEED (e.g. for one week); this includes being ready to h<strong>and</strong>le an increased<br />
number of support calls;<br />
� define the conditions of a possible reversion to the paper fallback system during the<br />
same long lasting unavailability period; this should be driven by the very business<br />
need, each operation with weak time constraints such as the submission of a report of<br />
receipt should be delayed as much as possible.<br />
In addition, MSAs should put in place proper means to prevent locally unavailability of<br />
update services of SEED data.<br />
ECP2-FITSDEV2-SC03-<strong>FRS</strong>v3.11.doc Page 50 of 53
DG TAXUD – EXCISE COMPUTERISATION PROJECT REF: ECP2-FITSDEV2-SC03-<strong>FRS</strong><br />
FALLBACK AND RECOVERY SPECIFICATION (<strong>FRS</strong>) VERSION: 3.11-EN<br />
Specific provisions during the rollout of EMCS<br />
8 Specific provisions during the rollout of EMCS<br />
This chapter describes the specific provisions to be applied to the fallback <strong>and</strong> recovery<br />
procedures of EMCS during Migration Period 1 defined in the PSS [R3] namely:<br />
FS0/FS1 coexistence during Migration Period 1 (rollout of the FS1 functionality).<br />
This analysis is essentially based on the General Process Threads <strong>and</strong> Support Threads<br />
described in the Appendix A of the Phasing <strong>and</strong> Scope <strong>Specification</strong> (PSS).<br />
The exceptions <strong>and</strong> the related scenarios are described in the Appendix A of the PSS<br />
where they are explicitly addressed. These exceptions or scenarios are either specific to<br />
the migration periods or extended from the unavailability exceptions of the target system.<br />
It shall be noted that no specific provisions apply to the fallback <strong>and</strong> recovery procedures<br />
of EMCS during the operations of Phase 3, since according to the updated Master Plan<br />
[R7] there will be no co-existence of FS1 <strong>and</strong> FS2 (all MSAs will enter the EMCS Phase<br />
3 operations at milestone Mc).<br />
8.1 <strong>Fallback</strong> <strong>and</strong> recovery during Migration Period 1<br />
Most generally, the design of FS0/FS1 is intended to provide a full service to all<br />
movements that can be electronically submitted in a Member State in FS1, FS0 being<br />
exactly tailored to ensure the destination functionality.<br />
Therefore:<br />
� the fallback <strong>and</strong> recovery provisions that are defined in the <strong>FRS</strong> concerning the use<br />
cases included in FS1 are adequate to respond to the exceptions arising during the<br />
coexistence of FS0 <strong>and</strong> FS1; note in particular that the management of SEED <strong>and</strong> of<br />
reference data being a prerequisite to the migration milestone Ma, the related use cases<br />
are to be considered a part of FS0;<br />
� all complementary requirements attached to these exceptions must be considered an<br />
integral part of FS0 or of FS1, according to the EBP where the exception arises.<br />
In addition, a few particular cases deserve setting up temporary responses.<br />
8.1.1 Unavailability of the automatic triggering of risk assessment<br />
The automatic connection with the risk assessment functionality is not included in FS1;<br />
until the concerned MSA is in FS2, it is replaced by a manually triggered fallback risk<br />
assessment that may result in fallback administrative cooperation exchanges.<br />
This is not really an exception; however it has been explicitly mentioned in the Appendix<br />
A for all application points of risk assessment in all use cases of the FESS [R6] that<br />
belong to FS1.<br />
8.1.2 Exportation of goods in an MSA different from the MSA of dispatch<br />
The exportation functionality is supported through three use cases, all of which are<br />
assigned to FS1 (no EBP has been included in FS0).<br />
ECP2-FITSDEV2-SC03-<strong>FRS</strong>v3.11.doc Page 51 of 53
DG TAXUD – EXCISE COMPUTERISATION PROJECT REF: ECP2-FITSDEV2-SC03-<strong>FRS</strong><br />
FALLBACK AND RECOVERY SPECIFICATION (<strong>FRS</strong>) VERSION: 3.11-EN<br />
Specific provisions during the rollout of EMCS<br />
There are two possible combinations:<br />
� a simple sequence of use cases UC2.44 <strong>and</strong> UC2.46, both being in the same Member<br />
State of dispatch/export; for what concerns the Migration Period 1, either the<br />
consignor is in FS0 <strong>and</strong> the current paper AAD continues being used, or he is in FS1,<br />
hence the MSA is in FS1 <strong>and</strong> the whole process may be completed electronically;<br />
� a more complex sequence involving UC2.01 in the MSA of dispatch <strong>and</strong> UC2.43 <strong>and</strong><br />
UC2.46 in the MSA of export; these two MSAs are most frequently the same one, but<br />
they can be different as well; so, the following concerns exclusively the case where the<br />
MSA of export is different from the MSA of dispatch.<br />
When the MSA of dispatch is in FS1 then an e-AAD is likely to be electronically<br />
submitted, however the MSA of export may be still in FS0 hence unable to achieve the<br />
electronic exportation use case.<br />
Such a combination must then be prevented.<br />
This may be detected at validation either of the submitted e-AAD, or of a change of<br />
destination. A guideline of the PSS (GP 5) provides that each MSA must be permanently<br />
informed in which Functional Stage each other MSA is.<br />
So, a temporary checking is to be inserted in the validation process of UC2.01 <strong>and</strong> of<br />
UC2.05, to reject any destination at export of which Functional Stage is FS0. The<br />
rejection is then sent back to the consignor who, possibly with the assistance of his<br />
national support, may find another Member State where export may be completed,<br />
normally the MSA of dispatch itself.<br />
8.1.3 Unavailability of the control report<br />
Currently, the results of a control are to be registered in box A of the AAD document.<br />
That AAD is planned to disappear as soon as there is an e-AAD, i.e. as soon as the<br />
consignor is able to submit it (FS1). However, the electronic control report is not<br />
included in FS1 but only in FS2.<br />
This makes that, from the time where the consignor may submit an e-AAD (FS1) to the<br />
time where all Member States are in FS2, there will be situations where a control officer<br />
is unable to register the results.<br />
Consequently, a temporary fallback scenario is proposed, based on the fallback control<br />
form of the paper fallback system.<br />
8.1.4 Unavailability of the event report<br />
The registration of an event report is not included in FS1 but only in FS2. Contrary to the<br />
control report, the event report is a new feature of EMCS <strong>and</strong> its registration may be<br />
delayed until the involved MSAs are in FS2. Temporary fallback solutions are however<br />
described for the cases where only a part of these MSAs are in FS2.<br />
ECP2-FITSDEV2-SC03-<strong>FRS</strong>v3.11.doc Page 52 of 53
DG TAXUD – EXCISE COMPUTERISATION PROJECT REF: ECP2-FITSDEV2-SC03-<strong>FRS</strong><br />
FALLBACK AND RECOVERY SPECIFICATION (<strong>FRS</strong>) VERSION: 3.11-EN<br />
Specific provisions during the rollout of EMCS<br />
8.1.5 Interruption of a movement<br />
The interruption of a movement is not included in FS1 but only in FS2. However the<br />
business need exists both at business level <strong>and</strong> at technical level where there is no<br />
business way to close a movement.<br />
A specific exception addressing the permanent unavailability of the interruption use case<br />
is therefore defined.<br />
ECP2-FITSDEV2-SC03-<strong>FRS</strong>v3.11.doc Page 53 of 53