frs

Document Sample
frs Powered By Docstoc
					OWNER                ISSUE DATE                 VERSION

DG TAXUD              06/04/2009                3.08-EN



           TAXATION AND CUSTOMS UNION DG
           EMCS COMPUTERISATION PROJECT
                      PHASE 2

                      SUBJECT:



        Framework Contract: TAXUD/2004/CC/077


Fallback and Recovery Specification (FRS)


              ECP2-EMCSDEV-SC02-FRS
 DG TAXUD – EXCISE COMPUTERISATION PROJECT                           REF: ECP2-EMCSDEV-SC02-FRS
 TAXATION AND CUSTOMS UNION DG. EMCS                                 VERSION: 3.08-EN
 COMPUTERISATION PROJECT. PHASE 2




                                [This page has been left intentionally blank.]




eeefa4a8-461a-4fbe-8c25-47e3e01209bc.doc                                                Page 2 of 52
 DG TAXUD – EXCISE COMPUTERISATION PROJECT                            REF: ECP2-EMCSDEV-SC02-FRS
 TAXATION AND CUSTOMS UNION DG. EMCS                                  VERSION: 3.08-EN
 COMPUTERISATION PROJECT. PHASE 2
 DOCUMENT HISTORY



                                               Document History

Edi.     Rev.      Date               Description                      Action (*)   Pages
0        00        08/05/2004         Create                           I            All

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

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

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

                                      Updated after SEVE quality
0        04        01/10/2004                                          U            All
                                      review, SfR

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

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

                                      Updated after SEVE quality
0        07        21/01/2005                                          U            All
                                      review, SfR

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

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

1        02        29/04/2005         SfA verification                 U            All

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

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

1        05        27/03/2006         SfR                              U            All

2        00        04/05/2006         SfA                              U            All

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

3        00        30/07/2007         SfA                              U            All

                                      Incorporating changes imposed
                                      by the Trigger Nb #159.
                                                                                    As
3        01        18/01/2008                                          U
                                      Submitted for review to                       Required
                                      Taxation and Customs Union
                                      DG.




eeefa4a8-461a-4fbe-8c25-47e3e01209bc.doc                                                    Page 3 of 52
 DG TAXUD – EXCISE COMPUTERISATION PROJECT                              REF: ECP2-EMCSDEV-SC02-FRS
 TAXATION AND CUSTOMS UNION DG. EMCS                                    VERSION: 3.08-EN
 COMPUTERISATION PROJECT. PHASE 2
 DOCUMENT HISTORY


                                      Submitted for Acceptance to
                                                                                    As
3        02        25/02/2008         Taxation and Customs Union         U
                                                                                    Required
                                      DG.

                                      Re-Submitted for Acceptance
                                                                                    As
3        03        07/03/2008         to Taxation and Customs            U
                                                                                    Required
                                      Union DG.

                                      Incorporating changes imposed
                                      by the RFA Nb #178.
                                                                                    As
3        04        28/05/2008                                            U
                                      Submitted for review to                       Required
                                      Taxation and Customs Union
                                      DG.

                                      Submitted for Acceptance to
                                                                                    As
3        05        25/06/2008         Taxation and Customs Union         U
                                                                                    Required
                                      DG.

                                      Incorporating changes imposed
                                      by the RFA Nb #234. More
                                      specifically:

                                              Implementing FRS
                                               v3.05 WDs.

                                              Performing alignment
                                               with revised MAP                     As
3        06        25/02/2009                                            I, U
                                               (CED 529).                           Required

                                              Performing alignment
                                               with revised Directive
                                               (2008/118/EC).

                                      Submitted for review to
                                      Taxation and Customs Union
                                      DG.

                                      Incorporating Reviewers
                                      Comments.
                                                                                    As
3        07        02/04/2009                                            U
                                      Submitted for Acceptance to                   Required
                                      Taxation and Customs Union
                                      DG.




eeefa4a8-461a-4fbe-8c25-47e3e01209bc.doc                                                   Page 4 of 52
 DG TAXUD – EXCISE COMPUTERISATION PROJECT                           REF: ECP2-EMCSDEV-SC02-FRS
 TAXATION AND CUSTOMS UNION DG. EMCS                                 VERSION: 3.08-EN
 COMPUTERISATION PROJECT. PHASE 2
 DOCUMENT HISTORY


                                      Incorporating DG TAXUD's
                                      verification comments.                     As
3        08        06/04/2009                                         U
                                                                                 Required
                                      Submitted for information to
                                      DG TAXUD.
(*) Action: I = Insert, R = Replace, U = Update, D = Delete




eeefa4a8-461a-4fbe-8c25-47e3e01209bc.doc                                                Page 5 of 52
    DG TAXUD – EXCISE COMPUTERISATION PROJECT                                                             REF: ECP2-EMCSDEV-SC02-FRS
    TAXATION AND CUSTOMS UNION DG. EMCS                                                                   VERSION: 3.08-EN
    COMPUTERISATION PROJECT. PHASE 2
    TABLE OF contents


                                                               Table of contents


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

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

1      INTRODUCTION ......................................................................................................................................... 9
    1.1     PURPOSE OF THE DOCUMENT.................................................................................................................... 9
    1.2     FIELD OF APPLICATION ............................................................................................................................. 9
    1.3     INTENDED READERSHIP .......................................................................................................................... 10
    1.4     STRUCTURE OF THE DOCUMENT ............................................................................................................. 10
    1.5     APPLICABLE AND REFERENCE DOCUMENTS............................................................................................ 11
       1.5.1    Applicable Documents................................................................................................................... 11
       1.5.2    Reference Documents .................................................................................................................... 11
    1.6     SPECIFIC GLOSSARY ............................................................................................................................... 12
    1.7     ASSUMPTIONS ........................................................................................................................................ 12
2      HOW TO READ THIS DOCUMENT ? ................................................................................................... 13
    2.1       WHAT AN EXCEPTION MEANS................................................................................................................. 13
    2.2       DISCOVERING AND CHARACTERIZING EXCEPTIONS ................................................................................ 13
    2.3       PROPOSING BUSINESS RESPONSES TO EXCEPTIONS ................................................................................. 15
3      EXCEPTIONS TYPOLOGY ..................................................................................................................... 19
    3.1     INFORMATION EXCHANGE EXCEPTIONS ................................................................................................. 19
       3.1.1    Exceptions at physical level .......................................................................................................... 19
       3.1.2    Exceptions at semantic level.......................................................................................................... 20
    3.2     PROCESS EXCEPTIONS ............................................................................................................................ 21
       3.2.1    Exceptions at physical level .......................................................................................................... 21
       3.2.2    Exceptions at semantic level.......................................................................................................... 22
4      MANAGEMENT OF DATA ...................................................................................................................... 23
    4.1     OWNERSHIP AND HOLDING OF DATA ...................................................................................................... 23
    4.2     RECTIFICATION OF DATA........................................................................................................................ 23
       4.2.1    Rectification at entry level............................................................................................................. 24
       4.2.2    Rectification at application level ................................................................................................... 24
       4.2.3    Control of rectifications ................................................................................................................ 25
5      SOLUTION ELEMENTS .......................................................................................................................... 26
    5.1     PREVENTION OF EXCEPTIONS ................................................................................................................. 26
       5.1.1    PR01: Pre-validation of entered information................................................................................ 27
       5.1.2    PR02: Ensure permanent availability of EMCS applications ....................................................... 27
       5.1.3    PR03: Atomicity of EBP processing .............................................................................................. 27
       5.1.4    PR04: Use of timers ...................................................................................................................... 27
       5.1.5    PR05: Enqueue message for further automatic recovery .............................................................. 28
       5.1.6    PR06: Business acknowledgement ................................................................................................ 28
       5.1.7    PR07: Follow-up ‘open’ information ............................................................................................ 29
    5.2     ADMINISTRATIVE PROCEDURES ............................................................................................................. 29
       5.2.1    AP01: Enquire on information ...................................................................................................... 30
       5.2.2    AP04: Broadcast information on unavailability ........................................................................... 30
       5.2.3    AP05: Perform internal controls ................................................................................................... 30
       5.2.4    AP06: Take a business decision .................................................................................................... 31
       5.2.5    AP07: Transfer issue to support .................................................................................................... 31
       5.2.6    AP08: Exchange information outside EMCS ................................................................................ 32
    5.3     FALLBACK SOLUTION ELEMENTS ........................................................................................................... 32
       5.3.1    FB01: Use alternate communication medium ............................................................................... 33


eeefa4a8-461a-4fbe-8c25-47e3e01209bc.doc                                                                                                            Page 6 of 52
    DG TAXUD – EXCISE COMPUTERISATION PROJECT                                                               REF: ECP2-EMCSDEV-SC02-FRS
    TAXATION AND CUSTOMS UNION DG. EMCS                                                                     VERSION: 3.08-EN
    COMPUTERISATION PROJECT. PHASE 2
    TABLE OF contents

       5.3.2    FB02: Revert to manual without subsequent input ....................................................................... 34
       5.3.3    FB03: Revert to manual with subsequent input ............................................................................ 34
       5.3.4    FB04: No intervention – wait ........................................................................................................ 34
       5.3.5    FB06: Notify administration ......................................................................................................... 35
       5.3.6    FB08: Notify economic operator ................................................................................................... 36
    5.4     RECOVERY SOLUTION ELEMENTS ........................................................................................................... 36
       5.4.1    RC03: Restart or replace technical component ............................................................................ 36
       5.4.2    RC04: Enter data using the normal procedure ............................................................................. 37
       5.4.3    RC05: No intervention – accept exception .................................................................................... 37
       5.4.4    RC06: Collate electronic record with the fallback form ............................................................... 37
       5.4.5    RC07: Replay information exchange ............................................................................................ 38
       5.4.6    RC10: Re-apply undone changes .................................................................................................. 38
6      PAPER FALLBACK SYSTEM ................................................................................................................. 39
    6.1     OVERVIEW ............................................................................................................................................. 39
    6.2     ROLES AND RESPONSIBILITIES ................................................................................................................ 39
       6.2.1    Unavailability at consignor’s (location A) .................................................................................... 40
       6.2.2    Unavailability at MSA of dispatch (location B) ............................................................................ 40
       6.2.3    Unavailability at MSA of destination (location C) ........................................................................ 40
       6.2.4    Unavailability at consignee’s (location D) ................................................................................... 41
    6.3     FALLBACK PAPER FORMS ....................................................................................................................... 41
    6.4     FALLBACK COMMUNICATION MEDIA ...................................................................................................... 41
    6.5     MAIN BUSINESS CASES FALLBACK PROCEDURES .................................................................................... 42
       6.5.1    Submission of AAD ........................................................................................................................ 42
       6.5.2    Cancellation of AAD ..................................................................................................................... 43
       6.5.3    Report of receipt ............................................................................................................................ 43
       6.5.4    Change of destination.................................................................................................................... 44
       6.5.5    Splitting ......................................................................................................................................... 45
       6.5.6    Interruption ................................................................................................................................... 46
       6.5.7    Control .......................................................................................................................................... 46
       6.5.8    Administrative cooperation ........................................................................................................... 47
    6.6     RECOVERY FROM PAPER FALLBACK PROCEDURES ................................................................................. 47
       6.6.1    Means to recover ........................................................................................................................... 47
       6.6.2    Deferred mode ............................................................................................................................... 48
       6.6.3    Summary of intermediate operations ............................................................................................ 48
7      UNAVAILABILITY OF SEED INFORMATION ................................................................................... 49

8      SPECIFIC PROVISIONS DURING THE ROLLOUT OF EMCS ........................................................ 50
    8.1     FALLBACK AND RECOVERY DURING MIGRATION PERIOD 1 ................................................................... 50
       8.1.1    Unavailability of the automatic triggering of risk assessment ...................................................... 50
       8.1.2    Exportation of goods in an MSA different from the MSA of dispatch ........................................... 50
       8.1.3    Unavailability of the control report .............................................................................................. 51
       8.1.4    Unavailability of the event report ................................................................................................. 51
       8.1.5    Interruption of a movement ........................................................................................................... 52




eeefa4a8-461a-4fbe-8c25-47e3e01209bc.doc                                                                                                               Page 7 of 52
 DG TAXUD – EXCISE COMPUTERISATION PROJECT                                                         REF: ECP2-EMCSDEV-SC02-FRS
 TAXATION AND CUSTOMS UNION DG. EMCS                                                               VERSION: 3.08-EN
 COMPUTERISATION PROJECT. PHASE 2
 TABLE OF figures



                                                         Table of figures

       FIGURE 1        APPENDIX A - EXCEPTIONS ................................................................................................... 17
       FIGURE 2        E-AAD MANAGEMENT INFORMATION FLOWS ....................................................................... 39
       FIGURE 3        SUBMISSION OF AAD – FALLBACK ADMINISTRATIVE CIRCUIT .............................................. 42
       FIGURE 4        CANCELLATION OF AAD – FALLBACK ADMINISTRATIVE CIRCUIT......................................... 43
       FIGURE 5        REPORT OF RECEIPT – FALLBACK ADMINISTRATIVE CIRCUIT................................................. 43
       FIGURE 6        CHANGE OF DESTINATION – FALLBACK ADMINISTRATIVE CIRCUIT ....................................... 44
       FIGURE 7        SPLITTING – FALLBACK ADMINISTRATIVE CIRCUIT ............................................................... 45
       FIGURE 8        INTERRUPTION – FALLBACK ADMINISTRATIVE CIRCUIT ........................................................ 46
       FIGURE 9        CONTROL – FALLBACK ADMINISTRATIVE CIRCUIT ................................................................ 46
       FIGURE 10       ADMINISTRATIVE COOPERATION – REQUEST FOR ASSISTANCE .............................................. 47
       FIGURE 11       ADMINISTRATIVE COOPERATION – SPONTANEOUS INFORMATION AND REPLY TO A REQUEST
                       FOR ASSISTANCE ................................................................................................................... 47



                                                          Table of tables

       TABLE 1         APPLICABLE DOCUMENTS ...................................................................................................... 11
       TABLE 2         REFERENCE DOCUMENTS ....................................................................................................... 12




eeefa4a8-461a-4fbe-8c25-47e3e01209bc.doc                                                                                                     Page 8 of 52
 DG TAXUD – EXCISE COMPUTERISATION PROJECT                     REF: ECP2-EMCSDEV-SC02-FRS
 TAXATION AND CUSTOMS UNION DG. EMCS                           VERSION: 3.08-EN
 COMPUTERISATION PROJECT. PHASE 2
 Introduction


1      Introduction

1.1 Purpose of the document
       The purpose of this document is to provide the necessary information to correctly take
       charge of the continuity and integrity of EMCS business where unexpected circumstances
       arise, but also to consider related functional, organisational, procedural and security
       requirements.
       It is a part of the Functional EMCS System Specification [R6]. It aims to identify
       exceptions, i.e. conditions that may make it impossible to use EMCS in its customary
       way, and to determine how the business must react to these conditions.
       From the analysis of individual exceptions, the document identifies the business
       responses that must be given to these exceptions.
       Only international business responses given in this FRS are imperative; national and/or
       local business responses are to be considered as suggestions.
       To that end, the FRS considers:
        preventing exceptions from happening through detection and prevention measures and
         preparing the system for complementary solutions;
        falling back from normal working processes to downgraded operations so as to ensure
         continuity of business while acquiring the information necessary for a safe recovery;
         in particular, manual fallback solutions are suggested in case of EMCS unavailability
         (to be started after a certain time depending on the case), and related paper based
         procedures are described;
        recovering the follow-up information to re-construct the exact history of a movement,
         at least the useful part of it, into electronic records.
       The analysis of FRS exceptions also leads to identify a series of requirements, on which
       could depend the implementation of the identified business responses.
       Additional procedures required to cope with exceptions are identified also.
       Even though the approach is business oriented, one cannot underestimate the fact that
       most processes that make up EMCS will be automated, and that one of the main sources
       of exception will be the unavailability of these automated processes.
       Even in that case, the FRS only considers the functional consequences of such
       exceptions, and how they are handled by the business. It never addresses the technical
       implications of an exception. However, the FRS identifies a series of requirements on
       which depends the implementation of the identified business responses.


1.2 Field of application
       The field of application of the FRS is the whole scope of the FESS; the FRS must be
       understood as a full part of the FESS with explicit requirements.
       As stated in the previous section, the FRS:



eeefa4a8-461a-4fbe-8c25-47e3e01209bc.doc                                             Page 9 of 52
 DG TAXUD – EXCISE COMPUTERISATION PROJECT                   REF: ECP2-EMCSDEV-SC02-FRS
 TAXATION AND CUSTOMS UNION DG. EMCS                         VERSION: 3.08-EN
 COMPUTERISATION PROJECT. PHASE 2
 Introduction

        only identifies fallback solutions for a target system in which all MSAs use the EMCS
         application;
        addresses some cases of migration period 1 (defined in the Phasing and Scope
         Specification (PSS) [R3]), where some Member States and/or economic operators will
         not be equipped yet with the computerised EMCS while other ones will already be
         operational. It shall be noted that no specific provisions apply to the fallback and
         recovery procedures of EMCS during the operations of Phase 3, since according to the
         updated Master Plan [R7], there will be no co-existence of FS1 and FS2 (all MSAs
         will enter the EMCS Phase 3 operations at milestone Mc).


1.3 Intended readership
       The intended readership for this document is the same as for the FESS; it includes:
        any person/service involved in the functional and technical specification or
         implementation of EMCS (including as well Member States representatives and
         software design teams or development teams, …);
        any person/service in charge of defining the procedures and handbooks that will apply
         to the operation of the EMCS systems, both in the Common Domain and in the
         National Domains;
        any other authorised body concerned with EMCS including the Excise Committee, the
         ECWP, the ECP Steering Committee, and the professional organisations of economic
         operators.


1.4 Structure of the document
       This document contains the following chapters:
        Chapter 1 "Introduction" is the present general introduction;
        Chapter 2 "How to read this document ?" highlights the way of using this document
         by describing the concepts and the way they are implemented;
        Chapter 3 "Exceptions typology" gives a general description of the categories of
         exceptions identified for EMCS;
        Chapter 4 "Management of data" highlights the notions of ownership and holding of
         data and their impact on rectification and further controls;
        Chapter 5 "Solution elements" presents the generic solution elements involved in the
         construction of business responses to EMCS exceptions;
        Chapter 6 "Paper fallback system" explains roles, responsibilities and fallback means
         to be used for some specific exceptions. In that context, main business cases and
         electronic recovery are presented;
        Chapter 7 "Unavailability of SEED information" presents fallback and recovery
         solution for this reference data base;
        Chapter 8 "Specific provisions during the rollout of EMCS" is focused on Migration
         Period 1 and 2 as defined in the PSS [R3].


       This document is further completed with a series of Appendices:


eeefa4a8-461a-4fbe-8c25-47e3e01209bc.doc                                           Page 10 of 52
 DG TAXUD – EXCISE COMPUTERISATION PROJECT                                        REF: ECP2-EMCSDEV-SC02-FRS
 TAXATION AND CUSTOMS UNION DG. EMCS                                              VERSION: 3.08-EN
 COMPUTERISATION PROJECT. PHASE 2
 Introduction

        Appendix A, entitled "Exceptions and Solution elements", contains the detailed list of
         all individual exceptions that have been qualified worth a processing during the
         analysis, and the scenario of solution elements assigned to each exception;
        Appendix B, entitled "Information exchanges to be acknowledged", lists the EMCS
         Information Exchanges that must be explicitly acknowledged, according to the
         prevention solution element “PR06 - business acknowledgement”;
        Appendix C, entitled "Summary of Solution elements", lists the solution elements that
         contribute to solve the issues raised by the exceptions and gives the links with the
         complementary requirements resulting from the analysis;
        Appendix D, entitled "Summary of Requirements", gives the list and contents of all
         the requirements resulting from the analysis of the FRS (in addition of those of the
         FESS [R6] with the links to the solution elements described in the present document.


1.5 Applicable and reference documents

1.5.1 Applicable Documents
     Ref.     Identifier                   Title                              Version           Issued
     A1       TAXUD/2004/CC                Framework Contract                                   15/12/2004
              /077
     A2       SC02                         Specific Agreement n° 02                             22/12/2005
                                           (SC02)
     A3       DIRECTIVE                    Directive 2008/118/EC                                16/12/2008
                                           concerning the general
                                           arrangements for excise duty
                                           and repealing Directive
                                           92/12/EEC.
                                                   Table 1 applicable documents


1.5.2 Reference Documents
     Ref.      Identifier                   Title                                 Version       Issued
     R1        ECP1-ESS-SEP                 Security Policy (SEP)                 2.02          13/12/2004
     R2        ECP1-ESS-GLT                 Glossary of Terms                     1.01-EN       14/11/2004
     R3        ECP1-ESS-PSS                 Phasing and Scope                     2.12          28/09/2007
                                            Specification (PSS)
     R4        ECP1-ESS-SESS                Security Excise System                2.00          02/10/2006
                                            Specification (SESS)
     R5        ECP2-EMCS-                   Design Document for                   2.19          05/02/2009
               DDNEA                        National Excise Applications
     R6        ECP1-ESS-FESS                Functional Excise System              3.00          08/11/2007
                                            Specification (FESS)



eeefa4a8-461a-4fbe-8c25-47e3e01209bc.doc                                                             Page 11 of 52
 DG TAXUD – EXCISE COMPUTERISATION PROJECT                                      REF: ECP2-EMCSDEV-SC02-FRS
 TAXATION AND CUSTOMS UNION DG. EMCS                                            VERSION: 3.08-EN
 COMPUTERISATION PROJECT. PHASE 2
 Introduction


     Ref.      Identifier                   Title                               Version                 Issued
     R7        MP                           Master Plan                         2.891                   13/10/2008
                                               Table 2 reference documents



1.6 Specific glossary
       Refer to [R2]


1.7 Assumptions
       This Fallback and Recovery Specification is written according to the following
       assumptions:
       1. legal and regulatory provisions are respected by all involved parties; irregularities and
           infringements pertain to the processing of inquiries;
       2. roles and responsibilities never change; if, for some reason, an intermediate acts by
           delegation of a partner (for instance, an excise officer enters a report of receipt on
           behalf of the consignee), the responsibility rests with the delegating actor;
       3. if the normal communication medium between an economic operator and its MSA
           fails, alternate communication media (fax, floppy disks or paper) will always be
           available.




1 Please note that the aforementioned version is the version submitted to the MSAs for review, therefore the version number
 differs from the final approved version.


eeefa4a8-461a-4fbe-8c25-47e3e01209bc.doc                                                                       Page 12 of 52
 DG TAXUD – EXCISE COMPUTERISATION PROJECT                     REF: ECP2-EMCSDEV-SC02-FRS
 TAXATION AND CUSTOMS UNION DG. EMCS                           VERSION: 3.08-EN
 COMPUTERISATION PROJECT. PHASE 2
 How to read this document ?


2      How to read this document ?
       Apart from your role in the EMCS project (business actor, software designer or
       developer, software test team member…), you need to know how to exploit the richness
       of this document.


2.1 What an exception means
       Any condition that may make it impossible to use EMCS in its customary way, is called
       here “exception”. The purpose of this document is to determine how the business must
       react to these exceptions.
       An analytical approach is used to detect as many potential exceptions as possible and to
       define the responses to these exceptions.
       All exceptions identified during the analysis phase have been studied in order to derive a
       number of generic responses.
       The use of specific responses will then be limited to the few cases where no generic
       response is applicable.


2.2 Discovering and characterizing exceptions
       Exceptions identification and qualification is done by systematically exploring the flows
       described in the use cases defined in the FESS and by identifying the situations that
       would make it impossible to follow the expected path until the end of the flow (including
       the effect of a failure of resources); this allows to explore separately each information
       exchange, once from the point of view of the sender and once from the point of view of
       the receiver;
       For each identified exception, the following points are examined:
        Plausibility;
        Business impact;
        Security impact;
        Time constraints.
       Qualification of exceptions against plausibility, business impact, security impact and time
       constraints results in a decision whether the exception is worth a processing.
       Plausibility
       The plausibility of each identified exception is first questioned to determine whether the
       exception is worth identifying a business response. This is done by examining whether,
       from a business point of view, this exception could really happen. The level of
       plausibility is not considered. In other words, an exception is either considered plausible
       (even if its level of plausibility is low) or non plausible. Non plausible exceptions are
       kept for documentation purposes but are not further analysed.




eeefa4a8-461a-4fbe-8c25-47e3e01209bc.doc                                               Page 13 of 52
 DG TAXUD – EXCISE COMPUTERISATION PROJECT                       REF: ECP2-EMCSDEV-SC02-FRS
 TAXATION AND CUSTOMS UNION DG. EMCS                             VERSION: 3.08-EN
 COMPUTERISATION PROJECT. PHASE 2
 How to read this document ?



       Business impact
       By impact, one must understand not only the impact of the exception itself on the
       business but also the impact of any solution element that any partner has to carry out
       following the exception.
       The business impact is an evaluation of the geographical scope of the possible impact of
       the exception on the business of EMCS. It is evaluated for each exception found
       plausible. There are three possible classes of impact:
        international business impact, if the occurrence of this exception affects the EMCS
          business in at least two Member States;
        national business impact, if the occurrence of this exception affects the EMCS only in
          the country where this exception has occurred;
        local business impact, if the occurrence of this exception only affects the business of
          the excise office where this exception has occurred, and/or the business of an
          economic operator;
        no business impact.
       If there is a business impact at several levels (e.g. an international and a national business
       impact), only the widest one is considered..
       The objective is not to define the relative importance of an exception for the business
       (national business impact on economic operators may be more important than
       international impact), but to identify the maximum scope (international or national)
       applicable for the handling of this exception.
       In turn, each MSA should define its own exceptions (at national level).
       Security impact
       The impact of each plausible exception on the security of the business is evaluated. It
       results from one among several situations:
        the exception itself creates a breach of security;
        the business response to the exception itself may create a breach of security;
        the exception results from an attempt at fraud.
       A “security breach” area is qualified according to whether it affects one of the following:
        availability of the system;
        data confidentiality;
        data integrity;
        risk of fraud.
       It is possible that the same exception impacts several security areas. Only that estimated
       the most important is displayed; in particular a risk of fraud always prevails on the other
       area.
       For more information about security related aspects, please refer to the SEP [R1] and to
       the SESS [R4].




eeefa4a8-461a-4fbe-8c25-47e3e01209bc.doc                                                 Page 14 of 52
 DG TAXUD – EXCISE COMPUTERISATION PROJECT                       REF: ECP2-EMCSDEV-SC02-FRS
 TAXATION AND CUSTOMS UNION DG. EMCS                             VERSION: 3.08-EN
 COMPUTERISATION PROJECT. PHASE 2
 How to read this document ?




       Time constraint
       Where an exception is qualified worth a processing, it is considered whether it must be
       satisfactorily dealt with within a limited period of time, and this time limit is identified as
       far as possible.
       For each exception, in particular, response times classes (interactive, asynchronous,
       scheduled, up to MSA, asynchronous/scheduled or N/A) and response times classes that
       have been introduced in FRS (none, business limit, national limit, national provisions),
       the constraint takes into account performance requirements defined in Appendix A of the
       FESS [R6].


2.3 Proposing business responses to exceptions
       Following the exceptions identification and qualification phase exposed above, the
       possible business responses were studied for all individual exceptions that were found
       plausible.
       If exceptions have an international business impact, the business responses must take into
       account international business constraints shared by all MSAs. It is therefore expected
       that these responses will be considered as standard responses, to be used by all
       participants to EMCS.
       In order to cover the global scope of the FESS, the same approach is applied to
       exceptions with a national impact.
       In this case, however, business responses are only suggested, and will have to be adjusted
       by each MSA, based on their own legal, contractual or organisational requirements.
       The business response to an exception is either generic or specific:
        A generic response is a standard response that relates to a whole series of exceptions.
         Whenever one of these exceptions is encountered, the related generic response applies,
         regardless of the specific aspects of the exception;
        A specific response relates to a single exception, and is designed to be used only
         when this specific exception is encountered.
       As much as possible, business responses found for each business exception should be
       made generic, i.e. reusable by other exceptions.
       Business responses are defined as a set of identified and chronologically ordered solution
       elements.
       Main solution elements categories are:
        Prevention measures systematically applied in the course of a normal activity flow
         with the aim of preventing or at least reducing the occurrence of an exception, or
         preparing elements that would later help in applying further (post exception)
         measures;
        Administrative procedures, which are used in order to further document an
         exception; for example, the possibility for querying on missing information or taking a
         business decision;


eeefa4a8-461a-4fbe-8c25-47e3e01209bc.doc                                                  Page 15 of 52
 DG TAXUD – EXCISE COMPUTERISATION PROJECT                     REF: ECP2-EMCSDEV-SC02-FRS
 TAXATION AND CUSTOMS UNION DG. EMCS                           VERSION: 3.08-EN
 COMPUTERISATION PROJECT. PHASE 2
 How to read this document ?

        Fallback solution elements, which are used in order to ensure the continuation of the
         business when an exception is encountered; the objective is to avoid delaying urgent
         excise business; they include, for example, the switch to a manual procedure when an
         automated process becomes unavailable;
        Recovery solution elements, which are used to correct defective data resulting from
         errors that have occurred in the system, from mistakes made by users, or from the
         application of fallback solutions; they include, for example, the introduction of results
         in the system after an automated job has been temporarily replaced by a manual
         procedure, or complete replay of the manual procedure to obtain the actual business
         result.
       Most generally, the convenient response to a given exception is a combination of
       individual business responses. While identifying appropriate business responses to
       exceptions, several situations may be encountered:
        the current exception is satisfactorily processed by starting a normal business use
          case; the use case becomes the normal response for the current exception;
        the current exception is satisfactorily processed by an existing generic business
          response; the generic business response becomes the normal response for the current
          exception; if several generic business responses apply, they are compared and the most
          appropriate one is selected;
        the current exception is satisfactorily processed by an existing specific business
          response defined for another exception; the specific solution then becomes a new
          generic business response with two particular applications;
        the current exception solution is almost satisfactorily processed by an existing generic
          business response; the question whether a variant of the generic business response
          must be created has to be considered;
        there is no satisfactory business response, neither generic nor specific, to deal with the
          current exception; a specific business response is defined with the view to make it
          generic in the future, i.e. by avoiding specific features.
       In addition, the detailed implementation of the same business response widely depends on
       the circumstances and on the context. This procedure has been followed to define the
       solutions presented in this document. It must be re-used in the future in the case new
       exceptions have to be analysed.
       Chapter 3 „Exceptions typology‟ describes generic exceptions that occur during
       information exchanges or during business processes. This gives a typology of individual
       exceptions listed in Appendix A, and presented as below:




eeefa4a8-461a-4fbe-8c25-47e3e01209bc.doc                                                Page 16 of 52
 DG TAXUD – EXCISE COMPUTERISATION PROJECT                         REF: ECP2-EMCSDEV-SC02-FRS
 TAXATION AND CUSTOMS UNION DG. EMCS                               VERSION: 3.08-EN
 COMPUTERISATION PROJECT. PHASE 2
 How to read this document ?




                                       Figure 1 Appendix A - Exceptions

       In Appendix A, each identified exception is:
        presented regarding a specific use case ();
        identified per EBP () and per actor/location ();
        uniquely identified (), and labelled with a short description text ();
        qualified against plausibility, business and security impacts, and time constraint ();
        followed by a set of clearly identified and chronologically ordered solution elements
          (- note that alternatives are also identified) forming together the business response to
          the exception, including most of the time a specific note regarding the concerned
          exception;
        if relevant, a label indicates that the exception is specific to “Migration period 1”.




eeefa4a8-461a-4fbe-8c25-47e3e01209bc.doc                                                Page 17 of 52
 DG TAXUD – EXCISE COMPUTERISATION PROJECT                      REF: ECP2-EMCSDEV-SC02-FRS
 TAXATION AND CUSTOMS UNION DG. EMCS                            VERSION: 3.08-EN
 COMPUTERISATION PROJECT. PHASE 2
 How to read this document ?


                           In Appendix A, the exceptions are grouped by use cases.
                       The use cases are presented in the same order as in the FESS :
       Section II : UC2.01, UC2.10, UC2.06, UC2.07, UC2.33, UC2.17, UC2.12, UC2.13,
       UC2.34, UC2.05, UC2.36, UC2.51, UC2.52, UC2.44, UC 2.43, UC2.46.
       Section III : UC1.14, UC1.15, UC1.16, UC1.30, UC1.11, UC1.04, UC1.05, UC1.06,
       UC1.13, UC3.16.
       Section IV : UC3.24, UC3.03, UC3.05, UC2.14, UC3.01, UC3.07, UC 3.09, UC3.29,
       UC3.14.
       Section V : UC0.07.


       The business responses are described in detail in Chapter 5 “Solution elements”; they are
       summarised in Appendix C and associated to individual exceptions in Appendix A.
       Note that the numbers contained in the identification of solution elements (e.g. FB06) are
       not related to any chronological order when used in a business response.
       Only the sequential numbering of solution elements in Appendix A indicates a
       chronological order of appliance.




eeefa4a8-461a-4fbe-8c25-47e3e01209bc.doc                                                Page 18 of 52
 DG TAXUD – EXCISE COMPUTERISATION PROJECT                    REF: ECP2-EMCSDEV-SC02-FRS
 TAXATION AND CUSTOMS UNION DG. EMCS                          VERSION: 3.08-EN
 COMPUTERISATION PROJECT. PHASE 2
 Exceptions typology


3      Exceptions typology
       This chapter contains a general description of the categories of exceptions and of the
       common characteristics of these categories. This categorisation has been the main
       guideline to discover exceptions throughout the analysis of the process flows. These
       exceptions are listed in Appendix A where they are presented along with the response
       scenarios that eventually allow restoring the good functioning of the system.
       The main categories are based on the origin and place of occurrence of these exceptions,
       namely:
        Information Exchange; or
        Processing.
       Although useful to systematically analyse the process flows to detect exceptions, these
       categories have not been found relevant in deeper analysis.


3.1 Information Exchange exceptions
       All information exchanges are subject to the same types of exception, regardless of the
       business context in which information has to be exchanged.
       Regardless of the scope (national or international) of an information exchange, or of the
       communication medium used (message exchanged through a communication network,
       paper based, phone, fax, E-mail...) exceptions happen at two levels:
        Physical: failure of the communication medium itself, or loss of the information to be
         exchanged;
        Semantic: the content of the information exchange does not have any business
         signification to the receiver.
       Whatever its level, an exception will have the same functional result: a failure of the
       information exchange.
       Note that most possible exceptions listed in this section are actually detected by the
       business process that receives and verifies information, in particular paragraph 3.1.2
       „Exceptions at semantic level‟. However, as they apply to the information itself, we
       preferred keeping them in this section.

3.1.1 Exceptions at physical level

3.1.1.1 Unavailability of the communication medium

       Most generally, if the normal communication medium fails, information cannot be
       exchanged through normal EMCS procedures.
       However, for some exchanges, it has been found important to define alternate
       communication channels, either because the normal channel is felt particularly fragile or
       because the permanence of the exchange is essential for the good functioning of EMCS.




eeefa4a8-461a-4fbe-8c25-47e3e01209bc.doc                                             Page 19 of 52
 DG TAXUD – EXCISE COMPUTERISATION PROJECT                       REF: ECP2-EMCSDEV-SC02-FRS
 TAXATION AND CUSTOMS UNION DG. EMCS                             VERSION: 3.08-EN
 COMPUTERISATION PROJECT. PHASE 2
 Exceptions typology

3.1.1.2 Loss of information to be exchanged

       For some reason, the addressee never receives the contents of an information exchange. If
       this is the case, different situations must be considered:
       1. The lost information was expected.
           The addressee expects to receive certain information within a given time limit, and this
           information is lost: this is typically the case if information is exchanged in response to
           another information exchange.
          For example, if the report of receipt of an e-AAD does not arrive in due time. Most
          generally, but not always, such missing information is automatically detected through
          a timer or equivalent mechanism.
       2. A response to the lost information was expected.
           If the lost information was not expected from the addressee, but the sender expects to
           receive a specific response to this information exchange within a certain delay. This
           situation is similar to the situation described in the example above, except that, in this
           case, it is the initial information exchange that is lost (in this example: the e-AAD
           never reached the consignee), instead of its response; that is to say that the e-AAD
           itself is lost.
          The result will be the same: the consignor will not receive the expected report of
          receipt.
       3. The lost information was not expected.
           If the lost information was not expected from the addressee, and the sender does not
           expect to receive a specific response to this information exchange, the exception
           remains undetected until the lost information becomes needed.

3.1.2 Exceptions at semantic level

       Several defects are capable of making it impossible for the receiver of an information
       exchange to understand the business signification of the received information; typically:
        the message refers to an object that is not known to the receiver;
        the content of the received information is not consistent with already known
          information (e.g. a report of receipt is received from an economic operator who is not
          the consignee of the e-AAD).

3.1.2.1 Unknown object

       The typical case of unknown object is where a received information exchange refers to an
       ARC that is not known to the receiver. This results from a preceding error (the e-AAD
       did not reach the receiver), from a mistake (wrong ARC has been input) or from a fraud
       (use of a forged ARC).
       Similar cases are where a complementary submission of a control report or of an event
       report refers to a non-existent report identifier or where a response to a request refers to a
       non-existent correlation id.



eeefa4a8-461a-4fbe-8c25-47e3e01209bc.doc                                                 Page 20 of 52
 DG TAXUD – EXCISE COMPUTERISATION PROJECT                     REF: ECP2-EMCSDEV-SC02-FRS
 TAXATION AND CUSTOMS UNION DG. EMCS                           VERSION: 3.08-EN
 COMPUTERISATION PROJECT. PHASE 2
 Exceptions typology

       In most cases, the incoming information exchange must simply be rejected, and the
       sender has to be notified (through a NACK message) about this rejection and its motives.
       The further handling of the exception depends on the nature of the defect. However, some
       particular situations may necessitate a more complex processing.


3.1.2.2 Inconsistent data

       Data sent in an information exchange will not be consistent with data already available to
       the receiver in the following cases:
       1. the information exchange contains data based on a version of registration or reference
           data different from the version used by the receiver;
       2. the information exchange contains fixed data on an EMCS movement that do not
           correspond to the equivalent data already known by the receiver on this exchange.


3.2 Process exceptions
       Being generally automated, there are many reasons for business processes to fail similarly
       to information exchanges.

3.2.1 Exceptions at physical level

3.2.1.1 Unavailability of a component

       If some component that makes up the business process fails, processing of information
       becomes impossible.
       This includes the availability of necessary information as well. For instance, if the
       consultation of SEED information by the application is currently impossible, basic
       processes such as the submission of an e-AAD or of a change of destination become
       impossible.

3.2.1.2 Corruption of information

       This situation happens when, for any reason, the automatic processing does not properly
       process information and hence output of a use case does not conform to the expected
       result. It is the case, for instance, where a component encounters a random error.
       This should not happen, and detection of such cases is considered difficult.
       If the processing carries on despite the error, this latter is propagated throughout the
       whole history of the movement, possibly corrupting other movements. In many cases, the
       error will be detected a posteriori, possibly after several operations will have been
       completed on the same movement.




eeefa4a8-461a-4fbe-8c25-47e3e01209bc.doc                                              Page 21 of 52
 DG TAXUD – EXCISE COMPUTERISATION PROJECT                      REF: ECP2-EMCSDEV-SC02-FRS
 TAXATION AND CUSTOMS UNION DG. EMCS                            VERSION: 3.08-EN
 COMPUTERISATION PROJECT. PHASE 2
 Exceptions typology

3.2.2 Exceptions at semantic level

3.2.2.1 Non conformance of the implemented processing

       Non conformance of the implemented processing with the functional specification is
       supposed to be prevented, if not completely expelled by a careful certification of each
       application before leaving it entering into operation. However, particular situations lead
       to discover cases that escape the described functionality. This is detected in a further step
       of the same process or in a further process, possibly in a later use case.
       The resolution process should be:
       1. immediately solve the current exception (incident) by any available means;
       2. define a workaround to avoid further occurrences of the exception and issue the
          relevant use recommendations;
       3. report the incident to the relevant authority (national support or common domain
          support);
       4. design a stable and definitive solution and include it in a further release of the
          software (or hardware).
       Such incidents being unexpected by nature, they are not identified in the FRS.

3.2.2.2 Disparity between the functional specification and the actual business need

       This case comes under maintenance of the specification, either corrective (for instance
       giving a more precise description of the expected functionality and adding test cases to
       the certification tools), or evolutive (defining new particular cases and the way they have
       to be processed).




eeefa4a8-461a-4fbe-8c25-47e3e01209bc.doc                                                 Page 22 of 52
 DG TAXUD – EXCISE COMPUTERISATION PROJECT                     REF: ECP2-EMCSDEV-SC02-FRS
 TAXATION AND CUSTOMS UNION DG. EMCS                           VERSION: 3.08-EN
 COMPUTERISATION PROJECT. PHASE 2
 Management of data


4      Management of data

4.1 Ownership and holding of data
       In EMCS, each piece of information has:
        an owner, i.e. the user who submitted the information; most times, it is an economic
          operator, either registered, and in that case he enters the information himself, or non-
          registered, and in that case another user, possibly an official, enters it on his behalf;
        a holder, i.e. the MSA that is responsible for keeping the reference version of
          information and for transferring it to any authorised partner whenever required; in
          principle it is the MSA that initially validated it, also called initiating MSA.
       The general principles that govern management of data are the following:
        the owner is responsible for the accuracy of the submitted information;
        only the owner of a data item is authorised to submit any update to that item, if
         updating is allowed;
        if the case arises, the person (in particular, the official) who enters data on behalf of
         the owner is not responsible for the given information but only for entering exactly
         what the owner requested;
        the holder MSA is responsible for formally validating submitted information and to
         report errors to the owner;
        the holder MSA is not entitled to change anything to the information held, unless he is
         the owner as well;
        the holder MSA is responsible for keeping information correct.
       Example:
       Upon submission of an e-AAD, the MSA of dispatch formally validates the submitted
       information and returns back the errors to the consignor, if any.
       The consignor (owner of the e-AAD) is responsible for correcting errors and re-
       submitting the e-AAD.
       If no errors are found, the MSA of dispatch becomes the holder of the e-AAD. In
       addition, the MSA of dispatch allocates an ARC to the e-AAD; the MSA of dispatch is
       therefore the owner of the ARC.
       This example shows how the same data group may be built from data items with different
       owners.


4.2 Rectification of data
       If, as a result of errors or mistakes, the information entered into EMCS needs to be
       rectified, the general business principle is that rectification information can only be
       cancelled or amended by its owner and that the rectification is validated by the holder of
       data. For convenience, it may be acceptable that the holder updates the information on
       behalf of the owner, but only with his explicit agreement.



eeefa4a8-461a-4fbe-8c25-47e3e01209bc.doc                                                Page 23 of 52
 DG TAXUD – EXCISE COMPUTERISATION PROJECT                      REF: ECP2-EMCSDEV-SC02-FRS
 TAXATION AND CUSTOMS UNION DG. EMCS                            VERSION: 3.08-EN
 COMPUTERISATION PROJECT. PHASE 2
 Management of data

       Invalid or outdated information is never deleted but marked for history purpose, including
       where it results from mistakes. Necessary rectification of information is limited to a part
       of information and is changed only through well identified ways.
       Rectification is required at two levels:
        at entry level: when information is submitted but not yet approved and stored;
        at application level: when information has been entered into EMCS and, in most cases,
         immediately and automatically disseminated to all concerned partners, either
         economic operators or MSAs.

4.2.1 Rectification at entry level

       No information should be accepted and recorded within EMCS unless it has been
       submitted to a formal validation. The rules of formal validation are detailed in the
       description of each concerned use case.
       This applies both where information is submitted by an economic operator and where it is
       submitted by an official.
       MSA may find it useful to locally store a part of information they are preparing to send to
       their partners (for instance administrative cooperation messages); details of rectification
       depend on the organisation of each MSA and will have to be defined at the national level.
       MSA are never allowed to rectify information of which they are not the owner; if they
       detect any anomaly that justifies a rectification, the MSA requires the owner of
       information, usually an economic operator, to perform the relevant rectification
       operation.

4.2.2 Rectification at application level

       Once information has been recorded in EMCS, it should only be corrected by using
       defined use cases.
       The System specification offers a range of functions that result in the ability to update a
       part of information. However, some information can only be rectified by cancellation and
       possible replacement of an e-AAD.
       Example 1:
       If, at submission time, an e-AAD is validated based on erroneous information, it is
       possible for the consignor to immediately cancel it (UC2.10) and re-submit the correct
       information (UC2.01). A new ARC is then allocated.
       This is possible only where the goods have not yet left the place of dispatch.
       Example 2:
       If at submission time, the consignor made a mistake when typing the excise number of
       the consignee, which could not be prevented by the initial checking, he may immediately
       issue a change of destination (UC2.05).




eeefa4a8-461a-4fbe-8c25-47e3e01209bc.doc                                                Page 24 of 52
 DG TAXUD – EXCISE COMPUTERISATION PROJECT                       REF: ECP2-EMCSDEV-SC02-FRS
 TAXATION AND CUSTOMS UNION DG. EMCS                             VERSION: 3.08-EN
 COMPUTERISATION PROJECT. PHASE 2
 Management of data

4.2.3 Control of rectifications

       All cases that support rectification should be specifically monitored by the MSA.
       Successive states of any entity involved in EMCS are systematically kept for history by
       the initiating MSA. This includes all rectifications performed during the life cycle of that
       entity. Information is communicated to concerned partners according to the general
       process of the use cases used for rectification.
       In addition, all operations are logged for audit and statistics purpose.




eeefa4a8-461a-4fbe-8c25-47e3e01209bc.doc                                                Page 25 of 52
 DG TAXUD – EXCISE COMPUTERISATION PROJECT                      REF: ECP2-EMCSDEV-SC02-FRS
 TAXATION AND CUSTOMS UNION DG. EMCS                            VERSION: 3.08-EN
 COMPUTERISATION PROJECT. PHASE 2
 Solution elements


5      Solution elements
       Solution elements are the basic components of the overall business responses that relate
       to the identified exceptions. Whenever one of these exceptions is encountered, the related
       generic responses apply, regardless of the specific aspects of the exception.
       This chapter presents generic solution elements to build the business responses to EMCS
       exceptions.


5.1 Prevention of exceptions
       PR01          Pre-validation of entered information
       PR02          Ensure permanent availability of EMCS applications
       PR03          Atomicity of EBP processing
       PR04          Use of timers
       PR05          Enqueue message for further automatic recovery
       PR06          Business acknowledgement
       PR07          Follow-up „open‟ information
       As a general rule, it is easier to prevent an exception from happening than to try to solve
       it after it has occurred. Therefore, when there are indications that some means exist to
       prevent an exception or reduce its consequences, these means are to be identified and
       become a part of the solution.
       A prevention solution element is characterised by:
        a place of prevention that identifies the responsibility of the measure; prevention
         should be performed as close as possible to the source of the cause and to the possible
         point of correction;
        a type of prevention such as assistance and control of input at user interface, integrity
         control at receipt of a message, control of internal consistency before sending a
         message, etc.
       A major characteristic of EMCS is that it mainly consists of automatic sequences of
       processes entrusted to different IT systems and that are automatically chained.
       Consequently, there is generally no intermediate actor enabled to verify and correct
       movement information during the processing of a use case.
       At the end of a use case, the new information must be known and consistent amongst all
       involved locations throughout the whole system.
       Consequently, there must be general mechanisms to:
        ensure that only correct data are entered into the system;
        ensure that the normal sequence of states is respected.




eeefa4a8-461a-4fbe-8c25-47e3e01209bc.doc                                               Page 26 of 52
 DG TAXUD – EXCISE COMPUTERISATION PROJECT                     REF: ECP2-EMCSDEV-SC02-FRS
 TAXATION AND CUSTOMS UNION DG. EMCS                           VERSION: 3.08-EN
 COMPUTERISATION PROJECT. PHASE 2
 Solution elements

5.1.1 PR01: Pre-validation of entered information

       Any capture of data must be submitted to formal validation at time of keying in, i.e.
       before any further validation by the system. This is a major requirement of the system.
       Example:
       Upon submission of an e-AAD, the application of the consignor includes as many
       controls as possible to ensure semantic validity of each field (e.g. conformance to
       business rules) and consistency among fields, possibly by reference to available data
       bases.

5.1.2 PR02: Ensure permanent availability of EMCS applications

       EMCS is characterised by very strong availability requirements. Some functions such as
       the submission of an e-AAD have been quoted with a "permanent" availability
       requirement where a given interruption of the service should not last more than 15
       minutes and many other ones with a "high" availability requirement where a given
       interruption cannot last more than one hour.

5.1.3 PR03: Atomicity of EBP processing

       Most EBPs described in the FESS are thought as business transactions, i.e. a set of
       actions that must be either completed or aborted together. The mechanism is defined at
       business level, i.e. there is no assumption on the way it shall be implemented.
       This response does not address specific exceptions but it is a prerequisite that has been
       used in the discovery of exceptions. Its role is to avoid considering in detail the possible
       exceptions that arise inside the process and to concentrate on the interconnection of each
       elementary process with the other ones: incoming and outgoing information exchanges,
       access to external information, functioning of timers.

5.1.4 PR04: Use of timers

       Timers are introduced to ensure that a reminder is issued when a specific event has not
       arisen in due time.
       The mechanism is defined at business level, i.e. there is no assumption on the way it shall
       be implemented.
       This response does not address specific exceptions but it is a prerequisite for some other
       solution elements. A few major cases are described in the FESS itself, because they
       include coordination mechanisms including international information exchanges.
       Conversely, a range of deadlines are to be defined at national level such as the maximum
       duration of the storage of a message in a waiting queue when that response is being used
       (PR05 - enqueue message for further automatic recovery).
       Example:
       The storage of a message submitted to business acknowledgement is linked to a
       maximum waiting time. This waiting time should be associated with a timer to awake the


eeefa4a8-461a-4fbe-8c25-47e3e01209bc.doc                                                Page 27 of 52
 DG TAXUD – EXCISE COMPUTERISATION PROJECT                       REF: ECP2-EMCSDEV-SC02-FRS
 TAXATION AND CUSTOMS UNION DG. EMCS                             VERSION: 3.08-EN
 COMPUTERISATION PROJECT. PHASE 2
 Solution elements

       suspended processing (FB04 - no intervention - wait) and take complementary steps
       whenever the expected event has not arisen (in that case, return of the business
       acknowledgement).

5.1.5 PR05: Enqueue message for further automatic recovery

       A safe storage of information may help in preparing further recovery where it has reached
       an identified level such as:
        arrival of an information exchange regarding a checking failure into a given location;
        positive checking of a submitted message; or
        just before sending an information exchange.
       In each case, if the following processing fails, it will be possible to restart from the point
       of storage to resume the process.
       This solution element is a prerequisite for the business acknowledgement processing
       described below (PR06 - business acknowledgement).
       Example 1:
       When a submitted draft e-AAD arrives in the MSA of dispatch, it is convenient to
       securely store it before starting its formal checking; therefore, in case of breakdown
       during the checking (e.g. sudden unavailability of resources), the checking can be
       resumed when the failure is corrected.
       Example 2:
       When a submitted e-AAD has been found valid but before allocating the ARC, it is
       convenient to securely store it before starting the allocation of the ARC and performing
       the related actions; therefore, in case of breakdown during these actions (e.g. sudden
       unavailability of resources), they can be resumed when the failure is corrected.
       Example 3:
       When a valid e-AAD is ready to be sent to the MSA of destination, and in connection
       with the required business acknowledgement, it is convenient to securely store it before
       sending it and until the business acknowledgement arrives. This makes it possible to
       replay the information exchange if neither positive nor negative acknowledgement has
       been received in a given time limit.

5.1.6 PR06: Business acknowledgement

       It is important for the EMCS business to ensure that an Information Exchange will not be
       lost between two MSAs because of a failure or of a too long transmission delay. This is
       particularly uneasy to discover.
       It is therefore essential, at least for the essential Information Exchanges, that the sending
       MSA has a confirmation that the recipient MSA has correctly received and processed that
       exchange.
       The solution element, named business acknowledgement, consists in a positive
       acknowledgement message (ACK) sent back to the issuing MSA. This message
       acknowledges that:


eeefa4a8-461a-4fbe-8c25-47e3e01209bc.doc                                                 Page 28 of 52
 DG TAXUD – EXCISE COMPUTERISATION PROJECT                     REF: ECP2-EMCSDEV-SC02-FRS
 TAXATION AND CUSTOMS UNION DG. EMCS                           VERSION: 3.08-EN
 COMPUTERISATION PROJECT. PHASE 2
 Solution elements

        the recipient MSA has correctly received the sent Information Exchange;
        it has already completed the actions pursuant to it or it commits itself to complete
         these actions.
       This response has the drawback to add a part of traffic into the Common Domain
       network. Therefore it has not been made systematic and is reserved to very essential
       business processes. Appendix B gives the list of the Information Exchanges to be covered
       by a business acknowledgement.
       Example:
       If a report of receipt is sent by the MSA of destination to the MSA of dispatch. This is of
       high importance for the economic operators and deserves a specific detection mechanism.
       So, an MSA of dispatch receiving a validated report of receipt should acknowledge the
       receipt of the report of receipt as soon as it has received and identified it.

5.1.7 PR07: Follow-up ‘open’ information

       If a business process is not completed in due time, a movement may remain in an
       unsolved state (that is to say, it will never reach a final state such as delivered,
       cancelled…). To reduce the risk that a movement remains indefinitely open, detection of
       such cases is necessary.
       The FESS provides for some mechanisms to be implemented at international level; it is
       highly recommended that Member States complete them at national level.
       Example:
       If a report of receipt is not submitted by the expected date of delivery, the MSA of
       dispatch sends a signal to the consignor and to the MSA of destination so that they
       undertake relevant actions, to establish where and in which state the goods are and to
       remind the relevant actor that recovery actions are necessary.


5.2 Administrative procedures
       AP01          Enquire on information
       AP04          Broadcast information on unavailability
       AP05          Perform internal controls
       AP06          Take a business decision
       AP07          Transfer issue to support
       AP08          Exchange information outside EMCS
       Administrative procedures serve the following purposes:
        further document an exception after it has been detected;
        refer to any procedure which leads to a decision about how to proceed further: asking
         for more information, asking for a correction; this includes enquiries (if more
         information is needed) or sharing of information (if other concerned parties must be
         informed).


eeefa4a8-461a-4fbe-8c25-47e3e01209bc.doc                                               Page 29 of 52
 DG TAXUD – EXCISE COMPUTERISATION PROJECT                     REF: ECP2-EMCSDEV-SC02-FRS
 TAXATION AND CUSTOMS UNION DG. EMCS                           VERSION: 3.08-EN
 COMPUTERISATION PROJECT. PHASE 2
 Solution elements

       In general, when an exception is fully documented, this normally leads to a business
       decision resulting in the application of a fallback and/or a recovery solution.

5.2.1 AP01: Enquire on information

       If expected information is not received by an organisation at a specific location, this
       organisation will enquire on the whereabouts of the missing information. By organisation,
       one must understand any MSA or any economic operator.
       This may be achieved, where possible, by using the standard functionality of EMCS such
       as remote consultation of movement data (UC2.51, UC2.52) or administrative
       cooperation (UC3.07), but getting information may have to be achieved outside EMCS.
       Example:
       If, upon validation of an e-AAD, the excise number of an economic operator is found not
       existing, it is the responsibility of the consignor to query his partner to get the correct
       information.

5.2.2 AP04: Broadcast information on unavailability

       Whenever an actor is unable to communicate with other actors or to perform some
       functions, that actor should notify that unavailability to its partners, preferably
       announcing the anticipated time to recover.
       This allows, in particular, planning interruption of services for maintenance purpose.
       For what concerns the communication over the Common Domain, this is achieved
       through a particular use case (UC0.07).
       It is recommended that each MSA provides for administrative procedures to manage the
       planned unavailability of economic operators.
       Example 1:
       If a given MSA plans an interruption of a part of EMCS functions, it must notify the
       other Administrations through UC0.07; consequently, the other MSAs have then to take
       the relevant fallback provisions such as enqueue all messages they would have to send
       and adapt the management of deadlines consequently.
       Example 2:
       A given MSA may provide that, whenever an economic operator observes that he will not
       be in a position to submit nor receive electronic messages for a given period, he must
       notify this to the MSA so that it can take the relevant provisions.
       This may be a prerequisite for an economic operator using the fallback forms without
       prior attempt of electronic submission (which does not exempt him from further
       electronic recovery).

5.2.3 AP05: Perform internal controls

       Each MSA applies administrative procedures to analyse exceptions after they have
       occurred, and to determine their cause.


eeefa4a8-461a-4fbe-8c25-47e3e01209bc.doc                                               Page 30 of 52
 DG TAXUD – EXCISE COMPUTERISATION PROJECT                    REF: ECP2-EMCSDEV-SC02-FRS
 TAXATION AND CUSTOMS UNION DG. EMCS                          VERSION: 3.08-EN
 COMPUTERISATION PROJECT. PHASE 2
 Solution elements

       These procedures aim at ensuring a posteriori that an exception does not result from fraud
       or fraud attempt.
       They should be applied at least in all the cases where an exception is assumed to be a
       result of a (possible) human mistake/error, and any time they are deemed necessary by
       the administration in charge.
       Example:
       If a change of destination is issued by the consignor for an e-AAD that has already been
       discharged, the business process is rejected. It is then up to the MSA of dispatch to
       examine the case and to enquire on the actual situation, whether it is an error or an
       attempt of fraud.

5.2.4 AP06: Take a business decision

       In EMCS, when processing of a movement encounters an exceptional situation that
       prevents it from running its business in the expected way, a decision on the course of
       action judged best adapted to this situation will first have to be taken.
       This decision will be based on the available information. This may comprise, but is not
       limited to:
        the causes of the exception, and how long it is expected to last;
        the nature of the movement;
        the quality of the business relationship with the trader;
        the time constraints;
        the availability of fallback solution(s).
       Example:
       If the consignee did not issue a report of receipt and, after enquiry, the consignor
       observes that the goods are still moving far from the place of delivery, he decides to
       change the destination, possibly to return goods at the place of dispatch.

5.2.5 AP07: Transfer issue to support

       Upon any event such as negative result of the validation of received data against existing
       information, an MSA application may find it impossible to continue the processing and
       reports the error to the persons in charge of the operation of the system, either economic
       operators or officials.
       The causes may be obscure for these persons, in particular in case of de-synchronisation
       between the IT systems of economic operators and/or the MSA application data bases.
       Some times, the actual error is the result from previous undetected errors, which makes it
       necessary to undertake real enquiries inside the system.
       In such cases, and after having verified the consistency of the data at his disposal, the
       concerned person is entitled to warn the National Service Desk, so that the latter
       investigates and determines appropriate actions to be undertaken to solve the issue.




eeefa4a8-461a-4fbe-8c25-47e3e01209bc.doc                                              Page 31 of 52
 DG TAXUD – EXCISE COMPUTERISATION PROJECT                       REF: ECP2-EMCSDEV-SC02-FRS
 TAXATION AND CUSTOMS UNION DG. EMCS                             VERSION: 3.08-EN
 COMPUTERISATION PROJECT. PHASE 2
 Solution elements

       Example:
       At validation of an e-AAD, a given data item is found incorrect by the MSA of dispatch,
       whereas the consignor did fill the corresponding fields correctly according the reference
       information he knows.
       The MSA of dispatch rejects the draft e-AAD on the basis of its current reference data
       and sends an error message to the consignor.
       The latter should first verify that he has given the correct information then report the
       issue to the support of his national service desk.

5.2.6 AP08: Exchange information outside EMCS

       This solution element is to be used each time that an economic operator needs to transfer
       information that another economic operator may provide and either the transmission
       channel through the economic operators does not work or there is no need to bother the
       MSAs with such data flows.
       The transmission channel is completely defined by bilateral agreement between economic
       operators.
       Example:
       If, upon request of explanation on a delay in the submission of the report of receipt, a
       consignor is unable to send the relevant message explaining the delay to the MSA of
       dispatch, he can send the information directly to the consignee who can then send them to
       the MSA of destination, if found relevant.


5.3 Fallback solution elements
       FB01          Use alternate communication medium
       FB02          Revert to manual without subsequent input
       FB03          Revert to manual with subsequent input
       FB04          No intervention – wait
       FB06          Notify administration
       FB08          Notify economic operator
       Fallback solution elements are required to allow the continuation of operations when an
       exception is encountered, and to avoid delaying urgent excise business.
       If it is judged that the business can wait until full restoration of the normal working
       conditions, a „No intervention – Wait‟ response is also available.
       Depending on the nature of the fallback solution, it has or does not have to be followed
       by a recovery procedure. If it is the case, this is explicitly mentioned in the description of
       the solution.




eeefa4a8-461a-4fbe-8c25-47e3e01209bc.doc                                                 Page 32 of 52
 DG TAXUD – EXCISE COMPUTERISATION PROJECT                      REF: ECP2-EMCSDEV-SC02-FRS
 TAXATION AND CUSTOMS UNION DG. EMCS                            VERSION: 3.08-EN
 COMPUTERISATION PROJECT. PHASE 2
 Solution elements

5.3.1 FB01: Use alternate communication medium

       If the communication medium normally used for an information exchange becomes
       unavailable, another communication medium may be used to complete this information
       exchange.
       A communication medium, able to bear structured electronic information (such as an
       electronic form transferred through e-mail, or a web interface), will be used as a part of
       the normal electronic processing. The security aspects of the information exchanges (both
       normal and fallback, including e-mails) shall be catered at national level.


       This covers exclusively communication channels that support interconnection with the
       normal EMCS processing. Other communication means such as a fax are excluded from
       that solution element. Successful use of another communication medium exempts the
       economic operator from any recovery actions.
       Note: Optical Character Recognition (OCR) may be considered as a possible solution to
       extract information from images, but not reliable enough to be entered into the EMCS
       application. However, the extracted information might be used by an MSA as input to
       preliminary automated risk assessment.
       In contrast, any set of information that can be considered structured enough to be inserted
       into the EMCS application must be regarded as an alternative communication means and
       does not belong to the paper fallback system; this is in particular the case of electronic
       forms.
       This solution element must be preferred to fallback to paper each time that it is possible.
       This response does not apply to normal CCN/CSI communication, except for the
       management and dissemination of SEED data that is felt important enough to justify
       redundancy of communication media.


       Example 1:
       If the normal communication medium used between a consignor and his MSA is a file
       attached to an e-mail, an alternative solution, among other possibilities, is a web site
       where the consignor directly enters data into a form.
       Example 2:
       Each MSA may have a preferred channel to - in particular - receive the SEED updates;
       however, it should be ready to revert to another solution in case of (long lasting)
       unavailability of that channel.




eeefa4a8-461a-4fbe-8c25-47e3e01209bc.doc                                                Page 33 of 52
 DG TAXUD – EXCISE COMPUTERISATION PROJECT                    REF: ECP2-EMCSDEV-SC02-FRS
 TAXATION AND CUSTOMS UNION DG. EMCS                          VERSION: 3.08-EN
 COMPUTERISATION PROJECT. PHASE 2
 Solution elements




5.3.2 FB02: Revert to manual without subsequent input

       If an automated business process becomes unavailable, it is possible to carry out
       manually the equivalent operations. No subsequent data input is then required (no
       recovery needed). This is the case if the faulty process does not normally result in an
       update of the e-AAD, or if the lack of update is judged acceptable, from a business point
       of view.
       Example:
       If automatic risk assessment is unavailable, instead of waiting for the resources to
       recover, it is more efficient to exercise it manually.

5.3.3 FB03: Revert to manual with subsequent input

       If an automated business process becomes unavailable (e.g. due to a software or a
       hardware failure or in case of scheduled unavailability for maintenance), the equivalent
       operations are first carried out manually.
       This is in particular the object of the paper fallback procedures described in Chapter 6.
       To ensure completeness of the EMCS processing, the standard electronic operations have
       then to be completed in deferred mode.
       Technically, the only difference between the normal submission and the deferred
       submission is the initial submission of an e-AAD.. In all other cases, normal mode and
       deferred mode are identical.
       Example:
       If submission of an e-AAD proves unavailable (although its availability requirement is
       permanent), the consignor ought to delay the electronic submission as much as possible.
       However, business constraints make that the actual dispatch of goods cannot be delayed.
       Consequently, the goods will have to leave before a valid e-AAD exists. A fallback AAD
       has then to be made to allow the goods moving under the cover of the Excise Number of
       the consignor plus the Local Reference Number of the consignment.
       It becomes then mandatory to submit the corresponding e-AAD as soon as the function
       becomes available again.

5.3.4 FB04: No intervention – wait

       When an exception impacts business processes that are not critically time-dependent and
       when the anticipated delay does not exceed the acceptable limit for the related functions,
       the normal response is to wait until the cause of the exception has been suppressed, and
       the normal procedure can be used.
       The economic operator chooses to use this response any time the expected delay is
       judged acceptable, or if, for business reasons, regular EMCS procedures are preferred to
       fallback procedures.


eeefa4a8-461a-4fbe-8c25-47e3e01209bc.doc                                              Page 34 of 52
 DG TAXUD – EXCISE COMPUTERISATION PROJECT                     REF: ECP2-EMCSDEV-SC02-FRS
 TAXATION AND CUSTOMS UNION DG. EMCS                           VERSION: 3.08-EN
 COMPUTERISATION PROJECT. PHASE 2
 Solution elements

       No recovery is then needed.
       Note: at dispatch, if the expected delay exceeds up to a few hours, this being not judged
       acceptable by the trader, the latter has to use an alternate way to communicate the
       movement information to the excise office (see FB01) before departure of the goods.
       Example:
       If submission of the report of receipt is temporarily unavailable, the consignee, based on
       the rules established by its Administration, may consider it acceptable to wait a few hours
       (or even up to one to two days before considering reverting to fallback paper procedures)
       before submitting it. This would have little impact on the excise business.

5.3.5 FB06: Notify administration

       This response exclusively addresses the communication between an economic operator
       and his national Administration. Consequently, its detailed definition depends on national
       provisions.
       The transmission channel may be any solution found relevant by the MSA, such as:
        access to a support Web portal;
        e-mail;
        fax;
        phone call to a help desk;
        SMS to a dedicated number;
        etc.
       This amounts to an anticipated announcement that, during the indicated period, the
       economic operator could directly use alternate solutions (typically, fall back to paper)
       without trying the standard solution.
       Example:
       In case of a long-lasting unavailability of the IT system of an economic operator, this
       latter impacts business processes that are critically time-dependent.
       The economic operator may be required to inform the competent Administration of the
       nature and conditions of the exception.
       This information should contain at least:
        list of the unavailable functions;
        expected time to recover.
       Typically, during that period, a consignor may be allowed to directly use the fallback
       AAD without trying an electronic submission that will surely fail.
       Conversely, as the time constraint for the submission of a report of receipt is not very
       stringent, the consignee should preferably wait for the electronic system to recover to
       submit a report of receipt.




eeefa4a8-461a-4fbe-8c25-47e3e01209bc.doc                                               Page 35 of 52
 DG TAXUD – EXCISE COMPUTERISATION PROJECT                         REF: ECP2-EMCSDEV-SC02-FRS
 TAXATION AND CUSTOMS UNION DG. EMCS                               VERSION: 3.08-EN
 COMPUTERISATION PROJECT. PHASE 2
 Solution elements

5.3.6 FB08: Notify economic operator

       That response exclusively addresses the communication between an Administration and
       an economic operator of its Member State. Consequently, its detailed definition depends
       on national provisions.
       In all cases where a severe exception arises that necessitates the collaboration of an
       economic operator, the competent Administration contacts that operator to establish the
       relevant actions.
       The transmission channel may be any solution found relevant by the MSA, such as:
        e-mail;
        fax;
        SMS to a registered number;
        etc.
       Example: The application of the MSA of dispatch starts a timer (for example,
       TIM_CHS) to expire in a given time limit by which the consignor is expected to issue
       either a change of destination or a splitting. If no such operation has been submitted
       within the time limit, the MSA shall issue a reminder notification to the consignor. If this
       reminder is not electronically implemented by the NEA then the MSA can send the
       reminder outside the system via any of the above mentioned means (such as, email, fax,
       or SMS to a registered number, etc).



5.4 Recovery solution elements
       RC03            Restart or replace technical component
       RC04            Enter data using the normal procedure
       RC05            No intervention - accept exception
       RC06            Collate electronic record with the fallback form
       RC07            Replay information exchange
       RC10            Re-apply undone changes
       Recovery solution elements are used to correct defective information or to complete
       missing information resulting from errors that have occurred in the system, from mistakes
       made by users, or from the application of fallback solutions.
       If it is considered that the business impact of an exception is acceptable, a „No
       intervention – accept exception‟ solution is also available.

5.4.1 RC03: Restart or replace technical component

       If some component necessary to complete a business process is found unavailable or
       faulty, processing cannot carry on any more. The failing component must be restarted or
       replaced as soon as possible.



eeefa4a8-461a-4fbe-8c25-47e3e01209bc.doc                                                Page 36 of 52
 DG TAXUD – EXCISE COMPUTERISATION PROJECT                     REF: ECP2-EMCSDEV-SC02-FRS
 TAXATION AND CUSTOMS UNION DG. EMCS                           VERSION: 3.08-EN
 COMPUTERISATION PROJECT. PHASE 2
 Solution elements

       Example:
       If the processing of information includes access to a data base that is currently locked or
       has fallen out, the business process becomes unavailable. The data base, possibly a
       backup copy, must be restarted as soon as possible.

5.4.2 RC04: Enter data using the normal procedure

       After fallback solution has been used, enter missing data in EMCS using a standard use
       case.
       This is in particular, but not exclusively, the normal recovery solution each time a
       fallback form has been used.
       From the point of view of the functioning of EMCS, this solution element must be
       considered the best one as it restores a completely normal situation.
       This solution must be applied as soon as possible to complete the EMCS processing.
       Example:
       Following the issuance of a fallback AAD, the consignor is committed to submit the e-
       AAD itself in deferred mode, as soon as this becomes technically possible.

5.4.3 RC05: No intervention – accept exception

       In several cases, an exception is simply accepted without any direct attempt to correct it.
       This will happen in the following situations:
       1. the business impact of the exception is not critical and can be accepted;
       2. the EMCS movement has reached an irreversible state and the exception cannot be
           corrected.
       Example:
       If a consignee repeatedly fails in trying to submit an alert with or without rejection, he
       may choose to give up with that use case and not even inform the consignor of what
       finally appears minor or becomes unnecessary, for instance if the consignor has
       spontaneously changed the destination in the meantime.

5.4.4 RC06: Collate electronic record with the fallback form

       In some cases, it is necessary to use a fallback form. With a very few exceptions, the
       operations covered by fallback forms have to be electronically recovered as soon as
       possible when the incident that caused the fallback is closed.
       The MSA of the economic operator who submitted the fallback form is entitled to
       compare the electronic record with the information contained in the fallback form to
       verify their consistency.
       In case where differences are found, the discrepancies fall under national provisions of
       the MSA of the concerned economic operator. The processing of EMCS continues with
       the electronic information.



eeefa4a8-461a-4fbe-8c25-47e3e01209bc.doc                                               Page 37 of 52
 DG TAXUD – EXCISE COMPUTERISATION PROJECT                    REF: ECP2-EMCSDEV-SC02-FRS
 TAXATION AND CUSTOMS UNION DG. EMCS                          VERSION: 3.08-EN
 COMPUTERISATION PROJECT. PHASE 2
 Solution elements

       Examples:
       If a fallback AAD has been submitted by a consignor, this latter is required to submit the
       e-AAD in deferred mode as soon as the failing resources have recovered. Upon receipt of
       an e-AAD submitted in deferred mode, an excise officer of the MSA of dispatch may (1)
       verify that the consignor has actually submitted a fallback AAD form and (2) compare
       the contents of the e-AAD with the contents of the fallback.

5.4.5 RC07: Replay information exchange

       In cases where a message seems lost between an economic operator and his MSA or
       between two MSAs, a part of recovery may be to send again the (possibly) lost message.
       This can be done several times depending on an acceptable limit to be defined by the
       concerned Member State(s). As far as possible, this limit should be an updatable technical
       parameter allowing to adapt the number of retries to the current situation, for instance a
       network overload should be mitigated by reducing the number of retries.

5.4.6 RC10: Re-apply undone changes

       This response follows a prior undo preceding operation (FB09) followed by
       rectifications; this consists in restoring the local state of the concerned object.
       Unless explicitly described, no rectifying Information Exchange has to be sent to other
       partners.




eeefa4a8-461a-4fbe-8c25-47e3e01209bc.doc                                              Page 38 of 52
 DG TAXUD – EXCISE COMPUTERISATION PROJECT                          REF: ECP2-EMCSDEV-SC02-FRS
 TAXATION AND CUSTOMS UNION DG. EMCS                                VERSION: 3.08-EN
 COMPUTERISATION PROJECT. PHASE 2
 Paper fallback system


6      Paper fallback system

6.1 Overview
       By paper fallback system, one must understand:
        a set of fallback forms that, depending on the case, are not necessarily printed on
         paper; and
        a series of procedures for the use of these forms.
       Each partner, and in particular the consignor, should as much as possible avoid making a
       fallback form; this implies:
        using electronic alternate communication means each time that it is possible,
           preferably to the paper fallback system, as described in FB01 - Use alternate
           communication medium;
        waiting until the extreme time limit before issuing a fallback form; This applies not
           only to the submission of the e-AAD but to all other main business cases described in
           point 6.5 as well; consequently, and given the acceptable delays in each case, only the
           fallback AAD and the fallback interruption notification are considered really likely to
           be submitted (and the fallback cancellation where no recovery is necessary).
       This chapter describes the administrative circuits of the paper fallback system applicable
       when EMCS may become unavailable, corresponding to fallback solution elements,
       mainly FB03 - Revert to manual with subsequent input and secondarily FB02 -
       Revert to manual without subsequent input.
       It lists roles and responsibilities, depending on the location of occurring exceptions, and
       depicts the associated relevant procedures.
       It considers next how to recover from the forms to the computerised procedures.


6.2 Roles and responsibilities
       The figure below represents the summary of an EMCS information flow between a
       consignor and a consignee.


                                 A                B                  C             D
                     consignor                                                         consignee




                                           MSA of dispatch    MSA of destination
                                           (Excise officer)    (Excise officer)

                              Figure 2 e-AAD management information flows

       Exceptions related to EMCS unavailability can occur in the following locations:
        consignor‟s premises (A);
        MSA of dispatch (B);


eeefa4a8-461a-4fbe-8c25-47e3e01209bc.doc                                                       Page 39 of 52
 DG TAXUD – EXCISE COMPUTERISATION PROJECT                     REF: ECP2-EMCSDEV-SC02-FRS
 TAXATION AND CUSTOMS UNION DG. EMCS                           VERSION: 3.08-EN
 COMPUTERISATION PROJECT. PHASE 2
 Paper fallback system

        MSA of destination (C);
        consignee‟s premises (D).
       According to the use case and to the location, occurrences of such exceptions have very
       different impacts on EMCS business.
       The paper fallback procedures are described considering that EMCS may become
       unavailable in any of the locations depicted above.

6.2.1 Unavailability at consignor’s (location A)

       Unavailability of EMCS at consignor‟s premises must not prevent the sending of the
       consignment.
       On the other hand, any dispatch of goods under excise suspension must be communicated
       to the MSA of dispatch.
       Therefore, it will be the responsibility of the consignor to inform the MSA of dispatch
       before the beginning of the movement of the unavailability of EMCS and use the relevant
       fallback administrative circuit depicted below for submission of the AAD and any other
       business purpose, and to re-issue as soon as the application is available again the
       equivalent electronic operations. The MSA of dispatch may also require a copy of the
       fallback AAD and appropriate information on the reasons for the unavailability before the
       beginning of the movement.

6.2.2 Unavailability at MSA of dispatch (location B)

       Unavailability of EMCS at MSA of dispatch should not prevent the sending of the
       consignment by the consignor. On the other hand, any dispatch of goods under excise
       suspension must be communicated to the MSA of dispatch before the beginning of the
       movement. The MSA of dispatch may also require a copy of the fallback AAD before the
       beginning of the movement.
       Therefore, economic operators will have to follow paper procedures directly with their
       excise office (procedures to be started after a certain time depending on the case and to be
       decided by the MSA).

6.2.3 Unavailability at MSA of destination (location C)

       The excise office at destination receives movement related fallback form from MSA of
       dispatch (in case of unavailability of EMCS at MSA of dispatch).
       In case of unavailability of EMCS at MSA of destination, the paper circuit should not
       prevent receiving the consignment by the consignee. On the other hand, any receipt of
       goods under excise suspension must be communicated to the MSA of destination, except
       in duly justified circumstances, using a paper document containing the same data as the
       report of receipt.
       Therefore, in case of EMCS unavailability at MSA of destination, economic operators
       will have to follow fallback procedures directly with their excise office (procedures to be
       started after a certain time depending on the case and to be decided by the MSA).


eeefa4a8-461a-4fbe-8c25-47e3e01209bc.doc                                                Page 40 of 52
 DG TAXUD – EXCISE COMPUTERISATION PROJECT                     REF: ECP2-EMCSDEV-SC02-FRS
 TAXATION AND CUSTOMS UNION DG. EMCS                           VERSION: 3.08-EN
 COMPUTERISATION PROJECT. PHASE 2
 Paper fallback system

6.2.4 Unavailability at consignee’s (location D)

       The consignee must communicate any receipt of goods under excise suspension to the
       MSA of destination, except in duly justified cases, using a paper document containing the
       same data as the report of receipt. Whether the consignee is entitled to simply wait for the
       IT system becoming available and the length of the waiting period itself will thus depend
       on the general instructions of its MSA on how to react to the situation.


6.3 Fallback paper forms
       The current AAD described in the Commission Regulation 2719/92 on the accompanying
       administrative document for the movement under duty-suspension arrangements of
       products subject to excise duty shall become obsolete with the entry into operation of
       EMCS (Functional Stage 1) by all the Member States. It will be replaced by the
       electronic records.
       To support the fallback system, a set of paper documents containing the same data as the
       corresponding EMCS messages will have to be used. These data shall be displayed in the
       form of data elements, expressed in the same manner as in the corresponding electronic
       messages. All the data elements, as well as the data groups and data subgroups to which
       they belong, shall be identified by means of the numbers and letters in column A and
       column B of Table 1 of Annex I to the Commission Regulation implementing Council
       Directive 2008/118/EC on the general arrangements for excise duty with regard to the
       computerised procedures for the movement of excise goods under a duty suspension
       arrangement, which is under preparation.


6.4 Fallback communication media
       The fallback forms are exclusively reserved to cases where the information has to be
       carried by paper-like supports such as (by decreasing order of preference):
        free text e-mail;
        fax;
        paper (sent by regular mail, or handed directly to the person).
       However, according to ESS Security policy [R1], proper means must be put in place to
       ensure confidentiality of data exchanged between partners (traders, MSAs).
       On the other hand, where fax would be preferred to e-mail as a medium, this requires the
       management of up-to-date fax directories.
       In any case, when a paper fallback takes place, the information should then be re-entered
       in the system, as soon as it becomes available again.




eeefa4a8-461a-4fbe-8c25-47e3e01209bc.doc                                                Page 41 of 52
 DG TAXUD – EXCISE COMPUTERISATION PROJECT                                           REF: ECP2-EMCSDEV-SC02-FRS
 TAXATION AND CUSTOMS UNION DG. EMCS                                                 VERSION: 3.08-EN
 COMPUTERISATION PROJECT. PHASE 2
 Paper fallback system


6.5 Main business cases fallback procedures

6.5.1 Submission of AAD

                                                                                 (mail/fax)
                                                AAD                       
                                                form
                                                                                 AAD
                                                                                   form
                            (original)                        MSA of dispatch                 MSA of destination
                                                              (Excise officer)                 (Excise officer)
                              AAD
                              form
                                                   (mail/fax)
                                   consignor          AAD
                                                      form
                                     (copy)
                                         AAD
                                         form
                                                                   consignee




                     Figure 3 Submission of AAD – fallback administrative circuit

       The procedure associated with the circuit above is as follows:
       1. the consignor fills in relevant fields of the fallback AAD form (cf. UC2.01–
          submission and registration of e-AAD); in particular, he assigns a Local Reference
          Number (LRN), being a serial number, to the AAD to serve as reference as long as
          there is no ARC assigned by the IT system;
       2. the consignor informs the MSA of dispatch or, if required by that MSA, sends it a
          copy of the fallback AAD form prior to dispatch of the goods or, in case of
          unavailability of means of communication, as soon as they become available again. If
          the consignor is responsible for the unavailability, the MSA of dispatch may also
          require appropriate information on the reasons for the unavailability before the
          beginning of the movement;
       3. as far as possible, the MSA of dispatch may apply risk assessment and if required
          submits a request for assistance to the MSA of destination;
       4. it is up to the consignor to judge whether he sends a copy of the AAD form to the
          consignee;
       5. if considered useful, the MSA of dispatch sends a notification to the MSA of
          destination;
       6. as the fallback AAD has to accompany the goods, the consignor gives a paper copy of
          it to the accompanying person.




eeefa4a8-461a-4fbe-8c25-47e3e01209bc.doc                                                                           Page 42 of 52
 DG TAXUD – EXCISE COMPUTERISATION PROJECT                                               REF: ECP2-EMCSDEV-SC02-FRS
 TAXATION AND CUSTOMS UNION DG. EMCS                                                     VERSION: 3.08-EN
 COMPUTERISATION PROJECT. PHASE 2
 Paper fallback system

6.5.2 Cancellation of AAD


                                                    CAN
                                                                                    (mail/fax)
                                                    form
                                                                                      AAD
                                                                                       form
                            (original)                            MSA of dispatch                 MSA of destination
                                                                  (Excise officer)                 (Excise officer)
                              CAN
                              form
                                                     (mail/fax)
                                   consignor               AAD
                                                           form
                                                                  

                                                                       consignee


                     Figure 4 Cancellation of AAD – fallback administrative circuit

       The procedure associated with the circuit above is as follows:
       1. the consignor fills in the fallback cancellation notification form;
       2. the consignor sends a copy of the form to the MSA of dispatch; the goods must not
          have left the place of dispatch;
       3. it is up to the consignor to judge whether he sends a copy of the form to the
          consignee;
       4. if considered useful, the MSA of dispatch sends a copy of the form to the MSA of
          destination.

6.5.3 Report of receipt

                                                                                     (mail/fax)
                                                                                       RoR
                                                  (mail/fax)                            
                             (original)
                                                    RoR           MSA of destination              MSA of dispatch
                                RoR                                (Excise officer)               (Excise officer)
                                                     
                                 
                                                       (mail/fax)
                                      consignee            RoR

                                                            

                                                                         consignor

                        Figure 5 Report of receipt – fallback administrative circuit

       The procedure associated with the circuit above is as follows:
       1. the consignee fills in relevant fields of the fallback report of receipt form
          (cf. UC2.06–submission of report of receipt);
       2. the consignee sends a copy of the form to the MSA of destination;
       3. except where the report of receipt can be submitted promptly, or in duly justified
          cases, the MSA of destination sends a copy of the form to the MSA of dispatch;
       4. the MSA of dispatch shall forward a copy of the form to the consignor or keep it
          available for him;


eeefa4a8-461a-4fbe-8c25-47e3e01209bc.doc                                                                               Page 43 of 52
 DG TAXUD – EXCISE COMPUTERISATION PROJECT                                              REF: ECP2-EMCSDEV-SC02-FRS
 TAXATION AND CUSTOMS UNION DG. EMCS                                                    VERSION: 3.08-EN
 COMPUTERISATION PROJECT. PHASE 2
 Paper fallback system

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

6.5.4 Change of destination


                                                                                         (mail/fax)
                                                                                             CoD
                               (mail/fax)                                                                 (former)
                                                                                                     MSA of destination
                                                      CoD       updated
                                   CoD                                                                 (Excise officer)
                                                               AAD
                                                                form          
                                                                                       (mail/fax)
                        (former)          consignor                       MSA of dispatch     AAD
                       consignee
                                                (mail/fax)              (Excise officer)    form
                                   (copy)
                                                      AAD
                                   AAD                form
                                   form                                                               MSA of destination
                                                                                                       (Excise officer)




                                                               (new)
                                                             consignee

                    Figure 6 Change of destination – fallback administrative circuit

       The procedure associated with the circuit above is as follows:
       1. the consignor fill in relevant fields of the CoD form (cf. UC2.05-Change of
          destination) and sends it to the MSA of Dispatch;
       2. if possible the MSA of dispatch may apply risk assessment on the fallback updated
          AAD form and if required submits a request for assistance to the new or former MSA
          of Destination;
       3. it is up to the consignor to judge whether he sends a copy of the CoD form to the
          former consignee;
       4. it is up to the consignor to judge whether he sends a copy of the updated AAD form
          to the (new) consignee;
       5. if considered useful, the MSA of dispatch sends the CoD form to the (former) MSA
          of destination and the AAD form to the new MSA of destination;
       6. the consignor informs the carrier of the new destination (the latter may annotate the
          new destination information on the document that mentions the ARC of the e-AAD or
          on the fallback AAD).




eeefa4a8-461a-4fbe-8c25-47e3e01209bc.doc                                                                                   Page 44 of 52
 DG TAXUD – EXCISE COMPUTERISATION PROJECT                                     REF: ECP2-EMCSDEV-SC02-FRS
 TAXATION AND CUSTOMS UNION DG. EMCS                                           VERSION: 3.08-EN
 COMPUTERISATION PROJECT. PHASE 2
 Paper fallback system

6.5.5 Splitting

                                                                        MSA of dispatch        CoD
                                                                        (Excise officer)
                                                                                        AAD
                                                                                      AAD
                                                                                     AADform
                                                                                      form
                                                                                    form      
                                                              AAD
                                                                 AAD       
                                                       CoD   AAD form
                                                               form                        All MSAs of destination
                                                             form
                                                                                               (Excise officer)



                                          consignor
                                                         (mail/fax)
                            (mail/fax
                               )                           AAD
                                                          AAD
                                                         AADform
                                CoD         (copy)        form
                                               AAD
                                                         form      
                                             AAD
                                            AADform
                                             form
                                            form
                                                                          (new)
                                                                        consignees

                    (former)
                   consignee


                               Figure 7 Splitting – fallback administrative circuit

       The procedure associated with splitting is as follows:
       1. the consignor sends to the MSA of Dispatch:
           a series of new fallback AAD forms with relevant fields filled in (cf. UC2.01 –
             submission and registration of e-AAD); in particular, each of these new AADs has
             its own (and new) LRN;
           if the (former) consignee is not the consignee of any new part, a CoD form as well;
       2. if possible the MSA of dispatch may apply risk assessment to the splitting operation
           considered as a whole and if required submits a request for assistance to be sent to
           part or all of the new or former MSAs of destination;
       3. if the (former) consignee is not the consignee of any new part, it is up to the
           consignor to judge whether he sends a copy of the CoD form to him;
       4. for each new AAD form created from the split AAD, it is up to the consignor to judge
           whether he sends its copy to the intended (new) consignee;
       5. if considered useful, the MSA of dispatch sends a copy of the CoD form to the former
           MSA of destination and copies of the new AAD forms to each new MSA (of
           destination);
       6. the consignor informs each involved carrier of the new destinations (the carriers may
           annotate the new destination information on the document that mentions the ARC of
           the e-AAD or on the fallback AAD).




eeefa4a8-461a-4fbe-8c25-47e3e01209bc.doc                                                                       Page 45 of 52
 DG TAXUD – EXCISE COMPUTERISATION PROJECT                                           REF: ECP2-EMCSDEV-SC02-FRS
 TAXATION AND CUSTOMS UNION DG. EMCS                                                 VERSION: 3.08-EN
 COMPUTERISATION PROJECT. PHASE 2
 Paper fallback system

6.5.6 Interruption


                                                           (mail/fax)
                                                                 Int.
                                                                CoD         MSA of dispatch
                                                                           (Excise officer)

                                                              (mail/fax)
                                                                 Int.
                                           Interrupting MSA      CoD
                                            (Excise officer)


                                                                         MSA of destination
                                                                          (Excise officer)

                           Figure 8 Interruption – fallback administrative circuit

       The procedure associated with interruption is as follows:
       1. the interrupting MSA prepares a specific form, with “movement interrupted” clearly
           mentioned on it; in addition, this form bears on it:
           the ARC of the movement to be interrupted;
           the reference of the event or control report if any;
       2. the interrupting MSA sends this form to the MSA of dispatch and to the MSA of
           destination (no interested MSAs informed).

6.5.7 Control


                                                           (mail/fax)
                                                                 Int.
                                                                Cntrl       MSA of dispatch
                                                                           (Excise officer)

                                                              (mail/fax)
                                                                 Int.
                                           Interrupting MSA      Cntrl
                                            (Excise officer)


                                                                         MSA of destination
                                                                          (Excise officer)

                              Figure 9 Control – fallback administrative circuit

       The procedure associated with a control is as follows:
       1. the MSA of control fills in the relevant fields of a control form, including:
           the ARC of the controlled movement; or
           the excise number of the consignor plus the LRN, if the e-AAD has not been
             created yet;
       2. the MSA of control sends this control form to the MSA of dispatch and to the MSA of
           destination (no interested MSAs informed).



eeefa4a8-461a-4fbe-8c25-47e3e01209bc.doc                                                               Page 46 of 52
 DG TAXUD – EXCISE COMPUTERISATION PROJECT                           REF: ECP2-EMCSDEV-SC02-FRS
 TAXATION AND CUSTOMS UNION DG. EMCS                                 VERSION: 3.08-EN
 COMPUTERISATION PROJECT. PHASE 2
 Paper fallback system

6.5.8 Administrative cooperation

                                                       (mail/fax)
                                                         RfA .


                                Requesting MSA                          Requested MSA
                                (Excise officer)                        (Excise officer)


                      Figure 10 Administrative cooperation – request for assistance

       The procedure associated with a request for assistance is as follows:
       1. the requesting MSA fills in the relevant fields of a RfA, including:
           the ARC of the movement; or
           the excise number of the consignor plus the LRN, if the ARC is unknown.
       2. the requesting MSA sends the RfA form to the requested MSA.
                                                       (mail/fax)
                                                         Res .



                                 Requested MSA                          Requesting MSA
                                 or issuing MSA                        or addressed MSA
                                 (Excise officer)                        (Excise officer)

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

       The common procedure associated with the reply to a request for assistance or with
       spontaneous information is as follows:
       1. the Requested MSA (or issuing MSA) fills in the relevant fields of a results form;
       2. the Requested MSA (or issuing MSA) sends the results form to the requesting MSA
          or to the addressed MSA.


6.6 Recovery from paper fallback procedures

6.6.1 Means to recover

       After a paper fallback form has been sent for any function, electronic recovery is
       mandatory and has to be achieved, as much as possible, through the relevant standard use
       cases, namely:
        submission of the e-AAD (UC2.01);
        cancellation of an e-AAD (UC2.10);
        submission of the report of receipt (UC2.06);
        change of destination (UC2.05);
        splitting (UC2.36);
        exportation of goods (UC2.44, UC2.43) and exit of exported goods (UC2.46);
        interruption of a movement (UC3.05);
        submission of a control report (UC3.03);



eeefa4a8-461a-4fbe-8c25-47e3e01209bc.doc                                                    Page 47 of 52
 DG TAXUD – EXCISE COMPUTERISATION PROJECT                      REF: ECP2-EMCSDEV-SC02-FRS
 TAXATION AND CUSTOMS UNION DG. EMCS                            VERSION: 3.08-EN
 COMPUTERISATION PROJECT. PHASE 2
 Paper fallback system

        issuance of a spontaneous information (UC3.01);
        request for assistance (UC3.07).
       There is however one exception: at cancellation, if a fallback AAD has been made and
       provided that the e-AAD has not been submitted in the meantime, the fallback
       cancellation is considered sufficient to inform the MSA of dispatch that the movement
       will not take place and electronic recovery is unnecessary.

6.6.2 Deferred mode

       Recovery through electronic input is said to be achieved in deferred mode. More
       specifically, the term “deferred mode” is used when the business event precedes the
       electronic operation (the submission of an e-AAD). In that case, the fact that the
       electronic operation (the submission of an e-AAD) is made in deferred mode must be
       made explicit so that the application, when checking the submitted e-AAD, relaxes the
       verification that the date of dispatch of goods announced in the e-AAD follows the actual
       date and time of submission. This has to be expressly specified at submission as follows:
        the consignor inserts an explicit indicator "deferred submission" at submission of the
          e-AAD (message IE815);
        if the indicator is set, the time of dispatch of the goods is mandatory (in addition to the
          date of dispatch) instead of being optional as it is the case in the normal submission;
        if the indicator is set, the date and time of dispatch of the goods are not compared with
          the date and time of submission (i.e. the date and time of receipt of the message).
       All other electronic operations come under the second context; in that case, no specific
       technical provisions are necessary, the submission is totally identical in both modes.

6.6.3 Summary of intermediate operations

       After a series of operations has been achieved through the fallback system, and
       depending on the scenario, it is possible for the consignor to summarise the movement at
       recovery by submitting only the latest state of the e-AAD.
       Typically, a fallback AAD of which destination has changed in fallback mode may be
       recovered directly by submitting the e-AAD with the final destination, without having to
       recover all intermediate business steps. This is true including where the first consignee
       has rejected the fallback AAD or refused the delivery before the change of destination.
       The only exception is where the first consignee has partially refused the delivery; in that
       case, the electronic recovery must be achieved in such a way that both partial and final
       reports of receipt are registered, namely:
        the consignor submits the e-AAD with the first destination where the partial refusal
          has been done;
        the consignee submits a report of receipt with partial refusal;
        the consignor changes the destination with the second destination.




eeefa4a8-461a-4fbe-8c25-47e3e01209bc.doc                                                Page 48 of 52
 DG TAXUD – EXCISE COMPUTERISATION PROJECT                    REF: ECP2-EMCSDEV-SC02-FRS
 TAXATION AND CUSTOMS UNION DG. EMCS                          VERSION: 3.08-EN
 COMPUTERISATION PROJECT. PHASE 2
 Unavailability of SEED information


7      Unavailability of SEED information
       SEED data are used in the MSAs for validation purpose (e.g. for draft e-AAD validation).
       They are:
        partially managed and defined in each MSA ;
        partially managed and defined in the Common Domain central services;
        regularly updated from the Common Domain central services.
       Exceptions due to the unavailability of SEED information and of its dissemination
       channels may result in de-synchronisation of the data bases among the Member States
       and could cause an abnormal number of calls to the support of the considered MSA.
       This may be mitigated by strong provisions:
        reinforce the communication means between the Common Domain central services
         and each MSA, in both directions but more particularly from the Common Domain to
         the MSAs;
        ensure simultaneous enforcement of the updates of SEED in the Member States, at
         logical level;
        define the relevant by-pass procedures in the view of long lasting unavailability of the
         update of SEED (e.g. for one week); this includes being ready to handle an increased
         number of support calls;
        define the conditions of a possible reversion to the paper fallback system during the
         same long lasting unavailability period; this should be driven by the very business
         need, each operation with weak time constraints such as the submission of a report of
         receipt should be delayed as much as possible.
       In addition, MSAs should put in place proper means to prevent locally unavailability of
       update services of SEED data.




eeefa4a8-461a-4fbe-8c25-47e3e01209bc.doc                                              Page 49 of 52
 DG TAXUD – EXCISE COMPUTERISATION PROJECT                     REF: ECP2-EMCSDEV-SC02-FRS
 TAXATION AND CUSTOMS UNION DG. EMCS                           VERSION: 3.08-EN
 COMPUTERISATION PROJECT. PHASE 2
 Specific provisions during the rollout of EMCS


8      Specific provisions during the rollout of EMCS
       This chapter describes the specific provisions to be applied to the fallback and recovery
       procedures of EMCS during Migration Period 1 defined in the PSS [R3] namely:
       FS0/FS1 coexistence during Migration Period 1 (rollout of the FS1 functionality).
       This analysis is essentially based on the General Process Threads and Support Threads
       described in the Appendix A of the Phasing and Scope Specification (PSS).
       The exceptions and the related scenarios are described in the Appendix A of the PSS
       where they are explicitly addressed. These exceptions or scenarios are either specific to
       the migration periods or extended from the unavailability exceptions of the target system.
       It shall be noted that no specific provisions apply to the fallback and recovery procedures
       of EMCS during the operations of Phase 3, since according to the updated Master Plan
       [R7] there will be no co-existence of FS1 and FS2 (all MSAs will enter the EMCS Phase
       3 operations at milestone Mc).


8.1 Fallback and recovery during Migration Period 1
       Most generally, the design of FS0/FS1 is intended to provide a full service to all
       movements that can be electronically submitted in a Member State in FS1, FS0 being
       exactly tailored to ensure the destination functionality.
       Therefore:
        the fallback and recovery provisions that are defined in the FRS concerning the use
         cases included in FS1 are adequate to respond to the exceptions arising during the
         coexistence of FS0 and FS1; note in particular that the management of SEED and of
         reference data being a prerequisite to the migration milestone ma, the related use cases
         are to be considered a part of FS0;
        all complementary requirements attached to these exceptions must be considered an
         integral part of FS0 or of FS1, according to the EBP where the exception arises.
       In addition, a few particular cases deserve setting up temporary responses.

8.1.1 Unavailability of the automatic triggering of risk assessment

       The automatic connection with the risk assessment functionality is not included in FS1;
       until the concerned MSA is in FS2, it is replaced by a manually triggered fallback risk
       assessment that may result in fallback administrative cooperation exchanges.
       This is not really an exception; however it has been explicitly mentioned in the Appendix
       A for all application points of risk assessment in all use cases of the FESS that belong to
       FS1.

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

       The exportation functionality is supported through three use cases, all of which are
       assigned to FS1 (no EBP has been included in FS0).



eeefa4a8-461a-4fbe-8c25-47e3e01209bc.doc                                               Page 50 of 52
 DG TAXUD – EXCISE COMPUTERISATION PROJECT                     REF: ECP2-EMCSDEV-SC02-FRS
 TAXATION AND CUSTOMS UNION DG. EMCS                           VERSION: 3.08-EN
 COMPUTERISATION PROJECT. PHASE 2
 Specific provisions during the rollout of EMCS

       There are two possible combinations:
        a simple sequence of use cases UC2.44 and UC2.46, both being in the same Member
         State of dispatch/export; for what concerns the Migration Period 1, either the
         consignor is in FS0 and the current paper AAD continues being used, or he is in FS1,
         hence the MSA is in FS1 and the whole process may be completed electronically;
        a more complex sequence involving UC2.01 in the MSA of dispatch and UC2.43 and
         UC2.46 in the MSA of export; these two MSAs are most frequently the same one, but
         they can be different as well; so, the following concerns exclusively the case where the
         MSA of export is different from the MSA of dispatch.
       When the MSA of dispatch is in FS1 then an e-AAD is likely to be electronically
       submitted, however the MSA of export may be still in FS0 hence unable to achieve the
       electronic exportation use case.
       Such a combination must then be prevented.
       This may be detected at validation either of the submitted e-AAD, or of a change of
       destination. A guideline of the PSS (GP 5) provides that each MSA must be permanently
       informed in which Functional Stage each other MSA is.
       So, a temporary checking is to be inserted in the validation process of UC2.01 and of
       UC2.05, to reject any destination at export of which Functional Stage is FS0. The
       rejection is then sent back to the consignor who, possibly with the assistance of his
       national support, may find another Member State where export may be completed,
       normally the MSA of dispatch itself.

8.1.3 Unavailability of the control report

       Currently, the results of a control are to be registered in box A of the AAD document.
       That AAD is planned to disappear as soon as there is an e-AAD, i.e. as soon as the
       consignor is able to submit it (FS1). However, the electronic control report is not
       included in FS1 but only in FS2.
       This makes that, from the time where the consignor may submit an e-AAD (FS1) to the
       time where all Member States are in FS2, there will be situations where a control officer
       is unable to register the results.
       Consequently, a temporary fallback scenario is proposed, based on the fallback control
       form of the paper fallback system.

8.1.4 Unavailability of the event report

       The registration of an event report is not included in FS1 but only in FS2. Contrary to the
       control report, the event report is a new feature of EMCS and its registration may be
       delayed until the involved MSAs are in FS2. Temporary fallback solutions are however
       described for the cases where only a part of these MSAs are in FS2.




eeefa4a8-461a-4fbe-8c25-47e3e01209bc.doc                                               Page 51 of 52
 DG TAXUD – EXCISE COMPUTERISATION PROJECT                    REF: ECP2-EMCSDEV-SC02-FRS
 TAXATION AND CUSTOMS UNION DG. EMCS                          VERSION: 3.08-EN
 COMPUTERISATION PROJECT. PHASE 2
 Specific provisions during the rollout of EMCS

8.1.5 Interruption of a movement

       The interruption of a movement is not included in FS1 but only in FS2. However the
       business need exists both at business level and at technical level where there is no
       business way to close a movement.
       A specific exception addressing the permanent unavailability of the interruption use case
       is therefore defined.




eeefa4a8-461a-4fbe-8c25-47e3e01209bc.doc                                             Page 52 of 52

				
DOCUMENT INFO
Shared By:
Categories:
Stats:
views:23
posted:7/12/2011
language:English
pages:52