Emcs Feasibility Study En

7/29/2019 Emcs Feasibility Study En

http://slidepdf.com/reader/full/emcs-feasibility-study-en 1/163

OGC Department Final report Version Number Page

© Alcatel TITN Answare 2000 3AT 05006 AAAA DTZZA 02 1

No part of this document may be reproduced in any form or by any means without permission of Alcatel TITN Answare

EUROPEAN COMMISSION

Directorate General for Taxation and the Customs Union

EMCS Feasibility Study

FINAL REPORT

Approved

Originator:Michel Bonnet

Consultant

Alcatel

Visa and Date:19/11/99

Appraisal Authority:Michèle Pérolat

Project Officer

Visa and Date:

Appraisal Authority:Marie-AgnèsHasbrouck

Visa and Date:19/11/99

Appraisal Authority:Donato Raponi

Head of Unit C4

Visa and Date:



European Commission – DG Taxation and Customs Union Excise movement and control system feasibility study



VERSION HISTORY

Pages

Version Date Originator Modification modified added deleted

00

01

02

17/11/99

05/01/00

28/01/00

M Bonnet

L-M Ratouis

L-M Ratouis

Created

Updated according toremarks of TAXUD

Updated according toremarks of TAXUD

All

3, 14, 17,27, 28, 30,45, 49, A-1

to A-11,

C-3,E-1 to E-7,

G-1 toG-4

All






EXECUTIVE SUMMARY

This report is the summary of the Feasibility Study made for the Directorate General for

Taxation and the Customs Union and for the associated Member StatesAdministrations (MSA) to propose a computerised Excise Movement and ControlSystem.

It is the final result of a study that lasted around ten months and was made with theco-operation of all Administrations involved (the European Commission and theMember States Administrations) and with the European professional organisations ofeconomic operators.

It is important to remember that the Final Report cannot be completely understoodand evaluated without reading the preceding documents of the study, in particular the Summary Report of phase 1 (collection of requirements) and the ConsolidatedReport produced by phase 2. In several points, the details of the proposed solution

have slightly changed; in such cases, the Final Report is considered as more relevant.

The goal of the proposed system is to replace the current paper based AdministrativeAccompanying Document (AAD) used for the movements of goods under excise

duty suspension, by an electronic record. To do so, it consists in the computerisationand mutual exchange of information concerning:

the products subject to excise duties;

the concerned offices of various Administrations;

the economic operators authorised to exchange goods under excise dutysuspension, and the movement guarantees they provide;

the movements of goods under excise duty suspension.

To respect the applicable legislation, the economic operators must be activepartners of the system; in particular the consignor has to give the relevant informationon the movements and the possible updates, and the consignee has to make areport of receipt of goods. This implies that the almost 80,000 registered operators

should be connected to the computerised system.

The proposed solution is an interconnection of the concerned traders via the Member States Administrations. The MSAs are interconnected through the CCN/CSI

infrastructure, while each MSA manages the communication with economicoperators of its own country. An application server is installed in each Member Stateto serve economic operators and the other MSAs.

The necessary functionality has been subdivided into three Groups that can beimplemented in that order:

Group I consists in maintaining all registers required for the follow-up of movementsof excise goods;

Group II is the management of the electronic AAD itself; Group III contains a series of other functions that MSAs could find useful and that

exploit data produced by the two first Groups.






Three accompanying programmes are provided to help in the development anddeployment of the proposed system:

an information programme, to help all partners in understanding the goal of the

system, the approach and the daily usage of the system;

a training programme to help users in better using the system and its applications;

a support programme to help users in the difficulties encountered in their work.

The working programme is shared by the European Commission and the Member States according to the following principles:

the European Commission co-ordinates the work of all partners and the

accompanying programmes, it controls the global system specification and thedevelopment of common utilities; it provides the partners with an Application

Centre for monitoring of operations and assessment of components; each Member State Administration creates a computer node, develops its own

application and opens it to the economic operators; it participates in the

accompanying programmes for the part that happens in its country.

Each partner will probably have to contract part of its duties; the present reportproposes a contractual organisation for the European Commission and gives

recommendations to the Member States Administrations.






TABLE OF CONTENTS

1. INTRODUCTION................................................................................................... 82. REFERENCE AND APPLICABLE DOCUMENTS.................................................... 10

2.1. Reference documents..............................................................................................102.2. Applicable documents .............................................................................................10

3. TERMINOLOGY.................................................................................................. 113.1. Abbreviations and acronyms ..................................................................................113.2. Definitions ....................................................................................................................11

4. PRESENTATION OF THE PROJECT...................................................................... 124.1. General presentation................................................................................................124.2. Description of phase 3 ..............................................................................................124.3. Necessary complements..........................................................................................12

5. SUMMARY OF THE PROJECT............................................................................. 135.1. Origin of the project ..................................................................................................135.2. Phase 1 ........................................................................................................................135.3. Phase 2, step 1............................................................................................................14

5.4. Phase 2, step 2............................................................................................................155.5. Phase 2, step 3............................................................................................................165.6. Phase 3 ........................................................................................................................17

6. SUMMARY OF THE RECOMMENDED SOLUTION .............................................. 18

6.1. Goals of the EMCS.....................................................................................................186.2. Prerequisites ................................................................................................................196.3. Circuit of information ................................................................................................196.4. Technical architecture..............................................................................................20

6.5. Proposed functionality..............................................................................................216.6. Security ........................................................................................................................246.7. Information..................................................................................................................246.8. Training.........................................................................................................................25

6.9. Support ........................................................................................................................25

7. RISK ASSESSMENT.............................................................................................. 27

8. TASKS TO BE UNDERTAKEN ............................................................................... 328.1. Directorate General for Taxation and the Customs Union.................................32

8.2. Member States Administrations...............................................................................518.3. Economic operators..................................................................................................64

9. CONCLUSION ................................................................................................... 67

APPENDIX A – COMMON ELEMENTS OF SPECIFICATION ....................................... 1A.1. Formalism of the presentation ...................................................................................1A.2. Consultation of historical data ..................................................................................4A.3. Exception and error processing ................................................................................5

A.4. Recommendations on the use of CCN/CSI............................................................7

A.5. Allocation of specification and development tasks .............................................8

APPENDIX B - SPECIFICATION OF GROUP I ............................................................. 1






B.1. Management and dissemination of lists of reference ..........................................1

B.2. Consultation of MSA offices.......................................................................................9B.3. Management and consultation of registered operators .....................................9B.4. Management of guarantees...................................................................................15

B.5. Management and consultation of duty rates......................................................18B.6. Consultation of VAT information .............................................................................20B.7. Reports.........................................................................................................................20

APPENDIX C - SPECIFICATION OF GROUP II ........................................................... 1C.1. Management of the certificates of guarantee .....................................................1C.2. Submission and registration of AAD..........................................................................5C.3. Warning from the consignee...................................................................................13C.4. Update of the AAD during the movement...........................................................14C.5. Receipt and discharge of AAD...............................................................................18

C.6. Export of goods ..........................................................................................................22C.7. Claims on losses..........................................................................................................23C.8. Consultation and retrieval of movement data....................................................26C.9. Automatic recalls.......................................................................................................30

C.10. Reports.........................................................................................................................31

APPENDIX D - SPECIFICATION OF GROUP III .......................................................... 1D.1. Road controls ...............................................................................................................1D.2. Risk assessment.............................................................................................................3

D.3. Management of alerts ................................................................................................6D.4. Automatic recalls.........................................................................................................6D.5. Collection of statistics .................................................................................................7D.6. Movement Verification and Mutual Assistance.....................................................8

APPENDIX E - SPECIFICATION OF UTILITIES.............................................................. 1E.1. Appointment of user names and of access rights.................................................1E.2. Management of passwords .......................................................................................2E.3. Monitoring of connections.........................................................................................3

E.4. Consolidation of statistics ...........................................................................................5E.5. Consultation of information by support agents .....................................................6E.6. Correction and patching by support agents .........................................................6E.7. Free format messages.................................................................................................7

APPENDIX F – NECESSARY INFRASTRUCTURE........................................................... 1F.1. National nodes.............................................................................................................1

F.2. Connection of officials................................................................................................1F.3. Connection of economic operators........................................................................2F.4. Interconnection of Member States Administrations ..............................................2F.5. Application Centre......................................................................................................2

APPENDIX G – AVAILABILITY, PERFORMANCES AND SECURITY ............................. 1G.1. Estimation of traffic and volumes .............................................................................1G.2. Availability requirements ............................................................................................2G.3. Performance requirements ........................................................................................3G.4. Security requirements..................................................................................................4

APPENDIX H – ESTIMATION OF COSTS ..................................................................... 1H.1. Introduction ..................................................................................................................1H.2. Directorate General for Taxation and the Customs Union...................................1






H.3. Member States Administrations.................................................................................3

H.4. Economic operators....................................................................................................5






1. INTRODUCTION

This report is the result of the feasibility study to the computerisation of the ExciseMovement and Control System. It contains a summary of the study and the

proposed solution to computerise the system.

It is mainly based on the Consolidated Report presented to the Excise Committeeand to the SCAC at end of October 1999. More precisely, it is based on thearchitecture Option A proposed in the Consolidated Report. It is intended to be

used as the Terms of Reference for the Invitations to Tender to be launched, inparticular by the Directorate General for Taxation and the Customs Union.

Chapter 1 is the present introduction.

Chapter 2 contains a list of the applicable documents and of the major reference

documents.

Chapter 3 contains a list of the acronyms used and some definitions of terms usedwith their exact meaning within the scope of the report.

Chapter 4 is a short reminder of the goal of the Feasibility Study and more

particularly of phase 3.

Chapter 5 reports the progress of the study and reminds the steps that led to theproposed system.

Chapter 6 contains a summary of the proposed solution that is more detailed inAppendices A to E.

Chapter 7 is an initial risk assessment of the computerisation project.

Chapter 8 describes the tasks to be undertaken by each activity involved in thecomputerisation of the EMCS. For the activities under the responsibility of theDirectorate General for Taxation and the Customs Union, an organisation is

proposed for the various Invitations to Tender that should be launched. For theactivities under the responsibility of the Member States Administrations, the tasksare just listed and described.

Chapter 9 is a general conclusion of the Feasibility Study.

In addition:

Appendix A contains common elements applying to the three Groups of

functionality and to the common utility functions.

Appendix B describes the functional modules composing Group I of functionality.

Appendix C describes the functional modules composing Group II of functionality.

Appendix D describes the functional modules composing Group III of functionality.






Appendix E describes common utility functions that are not specifically part of theapplication but are necessary for the good functioning of the system.

Appendix F summarises the requirements in terms of infrastructure.

Appendix G summarises the requirements for availability, performances andsecurity.

Appendix H gives an estimation of the cost of the whole computerisation project,for the European Commission and for the Member States.






2. REFERENCE AND APPLICABLE DOCUMENTS

2.1. Reference documents

[RD1] Summary Report of phase 1 – Ref. 3AT 05006 AAAA SRZZA[RD2] Discussion Document – Ref. 3AT 05006 AAAA DDZZA[RD3] Consolidated Report – Ref. 3AT 05006 AAAA CRZZA[RD4] Strategy Plan – Ref. 3AT 05006 AAAA SPZZA

2.2. Applicable documents

[AD1] Call for Tender – Ref. XXI/98/CB-5003[AD2] Alcatel Proposal – Ref. DC/SXP/PRP/98/005[AD3] Contract – Ref. XXI/98/124[AD4] Quality Plan – Ref. 3AT 05006 AAAA UQZZA

[AD5] Council Directive 92/12/EEC[AD6] Council Directive 77/799/EEC[AD7] Council Directive 76/308/EEC[AD8] Commission Regulation (EEC) No. 2719/92

[AD9] Commission Regulation (EEC) No. 2238/93






3. TERMINOLOGY

3.1. Abbreviations and acronyms

AAD Administrative Accompanying DocumentAFIS Anti Fraud Information SystemCCN/CSI Common Communication Network / Common System InterfaceCIUG Common Interest User Groupcsv comma separated values

DBMS Data Base Management SystemDDNTA Design Document for National Design ApplicationsEC European CommissionEDIFACT Electronic Data Interchange For Administration, Commerce and

Transport (UNO standard for the exchange commercial messages)

ELO Excise Liaison OfficeEMCS Excise Movement and Control SystemEU European UnionFMS File Management System

IS Information SystemITT Invitation To Tender KEuro Thousands of EuroMS Member State

MSA Member State AdministrationNCTS New Computerised Transit SystemOLAF Office de Lutte Anti-Fraude (former UCLAF)SAD Single Administrative Document (customs document)

SCAC Standing Committee for Administrative Co-operation in the field ofIndirect Taxation

STTA Single Transit Testing ApplicationTTA Transit Testing ApplicationVAT Value Added Tax

VIES VAT Information Exchange SystemXML Extended Markup Language

3.2. Definitions

The system When used alone, stands for "the future computerised EMCS".

The Directive When used alone, stands for "the Directive 92/12/EEC, asamended by Directives 92/108/EEC, 94/74/EC and 96/99/EC"

Registered operator That expression covers the three profiles of economicoperators that may be registered by Excise Administrations,

namely authorised warehouse keepers, registered tradersand tax representatives. Do not confuse with the "registeredtrader" defined by Article 4(d) of the Directive.

DG XXI Former name of the Directorate General for Taxation and the

Customs Union, used to refer to previous steps of the study.The DG When used alone, stands for "Directorate General for Taxation

and the Customs Union"

TAXUD When used alone, stands for "Directorate General for Taxationand the Customs Union"






4. PRESENTATION OF THE PROJECT

4.1. General presentation

The aim of the future computerised Excise Movement and Control System is toprovide the national Administrations of the Member States with efficient meansto follow-up the movement of goods subject to harmonised Excise duties,namely alcohol and alcoholic beverages, manufactured tobacco and mineraloils.

To do so, the Administrative Accompanying Document should be implementedin an electronic form, to allow on-line verification of data and automaticfollow-up of the movements; preventive investigation should be possible, toallow exchange of raw information, early advises, analyses, real-time controls,

etc.

The present project is the Feasibility Study of the planned system that includes:

• the collection and formalisation of the business requirements as seen by bothMember States Administrations and economic actors;

• the detection of environmental, legal and technical constraints;

• the definition of an organisational, operational and technical architecture to

fulfil these requirements;

• the definition of a harmonised solution to be proposed as the initialspecification of the system, which is gradually developed and thus containsall the required potentialities.

4.2. Description of phase 3

Phase 3 covers the end of bullet 4 above. After a solution has been chosen bythe Excise Committee and the SCAC, and approved by the General-Directorsfor Customs and for Taxation, it consists in studying the next steps of the

computerisation, and in particular in better defining the tasks to be performedand the contracts that should be awarded for implementation of the EMCS.

4.3. Necessary complements

During the Feasibility Study, it has been established that the case of mineral oils

should be further considered; some proposed features, that have been addedfollowing remarks coming from that sector, need to be proposed to theconcerned operators and, if found useful, updated according to their remarks.Other functions could prove necessary as well.

The corresponding requirements should be agreed and taken into accountbefore the end of the System Specification phase.






5. SUMMARY OF THE PROJECT

5.1. Origin of the project

Developing a computerised Excise Movement and Control System was initiallysuggested as the major conclusion of the High Level Group on fraud in thetobacco and alcohol sectors. The initial idea was that better knowing themovements of excise goods under suspension arrangement, and in particular having that information as early as possible, could help the Member States

Administrations in their control of these movements, therefore improving theefficiency of these controls.

Based on that requirement, DG XXI issued an Invitation to Tender for a FeasibilityStudy aimed at defining the details of necessary function and organisation, and

to propose plans and budgets for its implementation. That contract wasawarded to Alcatel.

The study began end of January 1999 and is supposed to be completed with the

delivery of the present report. Its general organisation, its proposed steps andproducts were presented to the Excise Committee and to the SCAC end of April1999.

5.2. Phase 1

5.2.1. Tasks performed

Phase 1 consisted mostly in meeting the partners involved in the future systemto collect their requirements and constraints. Alcatel met:

• fifteen Member States Administrations,

• four groups of professional organisations, grouped per sector (alcohol and

alcoholic beverages, tobacco, mineral oils, and transport and storage).

• five Units of the European Commission (DGXXI/B/1, DGXXI/B/2, DGXXI/B/3,DGXXI/C/3, and UCLAF).

Specific questionnaires were prepared and sent to the Member StatesAdministrations and to the economic operators, to help them in preparing the

meetings. Meetings with European Commission services had a more openagenda.

Based on the results of these meetings, as well as taking into consideration thedocuments provided by DG XXI or collected from other sources, a generalsummary was produced and written down into a report.

The Summary Report of phase 1 has been presented to the Excise Committeeand to the SCAC at beginning of July 1999.

5.2.2. Results

The results collected were:






• the assurance that most Member States Administrations, as well as most

economic operators, felt really concerned by the proposed system;

• a global support of the proposed system, although not general;

• several strong requirements expressed by interlocutors (in particular high

availability of the system, speeding up of procedures, respect of nationallegislation);

• a hierarchy of functional requirements, expressed in terms of urgency.

5.2.3. Products

The Summary Report of phase 1 contains a summary of the requirements andconstraints expressed by all interlocutors met; it contains in particular:

• a summary of the legal and regulatory framework of excise movementsunder suspension arrangement;

• a description of actor profiles and of their roles and duties;

• a description of the data entities to be managed in the system;• a description of required business procedures;

• a summary of technical constraints in each Member State;

• a list of additional open issues.

The Summary Report of phase 1 was delivered in English, French and German.

The reports of the meetings with the Member States Administrations and withthe professional organisations of economic operators are attached to theSummary Report.

5.3. Phase 2, step 1


During step 1, a so-called Discussion Document was built proposing varioussolutions able to support the required functionality, respecting the constraintsand providing the users with the requested availability. The DiscussionDocument, accompanied by a separate note describing an additional

architecture proposed for the system, was submitted both to Member StatesAdministrations and to the professional organisations of economic operators.

5.3.2. Results

The result of step 1 was a general description of the system proposed, with aseries of so-called domains of investigation, where interlocutors were invitedto give their preference concerning each domain.

5.3.3. Products

The Discussion Document contains a narrative description of the proposedsolution, each domain of investigation being presented in the course of the

description. The major points addressed are:

• the general architecture of the system, with three possible scenarios (afourth scenario was presented in a separated note – see below);

• security requirements and possible solutions;






• the underlying structure of users and of data;

• the detailed description of the business process, with possible variants;most generally, variants rely on the level of involvement of the variousprofiles of users;

• the description of plans to implement or accompany the deployment ofthe system (strategies for development, for deployment to economicoperators, for information of users, for training and for support);

• a series of first elements for planning and estimation of costs.

A separate note attached to the Discussion Document presented anadditional scenario for the general architecture of the system, involving aunique contractor, the "intermediate operator", to perform the part of thetechnical service that is directly related to economic operators.

The Discussion Document was delivered in English, French and German.



During step 2, the project team met all Member States Administrations again,and had seven meetings with professional organisations. Specific

questionnaires were prepared and sent to the Member States Administrationsand to the economic operators, to help them in preparing the meetings.More open meetings were organised with Units B3 and D3 of DG XXI, withOLAF and with DG VI.

In these meetings, the Discussion Document was reviewed, and theinterlocutors had the opportunity to give their preference among theproposed solutions, for each domain of investigation. In some cases, theysuggested other alternatives and added complementary requirements. All

answers and remarks were summarised and confronted with the proposedscenarios, and a global solution compliant with most requirements was built.The solution retained for each domain of investigation is generally the mostpreferred, but, in some cases, acceptability and compliance with particular

constraints have been the decisive factor, the aim being to reach a solutionacceptable for all partners.

The result of step 2 was a Consolidated Report proposing one functionalsolution with two implementation options.

The Consolidated Report was presented to the Excise Committee and to theSCAC at the end of October 1999. The choice of the preferred option shouldbe confirmed at the beginning of February 2000.

5.4.2. Results

Step 2 allowed defining and presenting possible solutions for the

implementation of the System. In most cases, there was a convergent view of

most Administrations on a given domain of investigation, but it was not alwaysthe case. The result is therefore a compromise that does not always reflect ademocratic vote but preserves internal coherence and compatibility with the






particular constraints of partners. The only choice left open, on explicit

request of DG XXI, is between two general architectures of the new system.

These two architectures are:

• an architecture similar to that of the NCTS, with direct interconnectionbetween Member States Administrations, each economic operator beingconnected to the MSA that registers him;

• an alternative solution where a unique operator is in charge of the

workflow part of the system, while MSAs remain in charge of theregistration of operators and of their guarantees, and of all downstreamfunctions such as recording of road controls, risk assessment, MovementVerification and possibly Mutual Assistance.

5.4.3. Products

The Consolidated Report is an evolution of the Discussion Document built as acomparison of the two options.

It contains in particular:

• a summary of the proposed solution, including both options;

• a series of prerequisites for the development of the system;

• a description of security requirements and a pre-view of security policies;

• the description of the two concurrent options, both organisational andtechnical;

• the description of the functionality retained, distributed into three Groupsthat may and must be implemented one after the other;

• more detailed description of the plans proposed in the DiscussionDocument, i.e. development, information, training, support and

deployment;

• an estimation of the cost of the system in both options.

The Consolidated Report was delivered in English, French and German.

The reports of the meetings with the Member States Administrations and withthe professional organisations of economic operators are attached to theConsolidated Report.



In step 3, the Consolidated Report was summarised in a Strategy Plan

intended to be presented to the joint meeting of General-Directors for Customs and for Taxation.

5.5.2. Results

Step 3 did not produce new results compared to step 2; the only task of thatstep was to write down the Strategy Plan based on the Consolidated Reportand on the choice of the Excise Committee and the SCAC.






5.5.3. Products

The Strategy Plan is a short document summarising the Consolidated Reportand based on the option most likely to be selected by the Member States,

namely the classical architecture where all messages are transferred through

the Member States Administrations. It insists in particular on the commitmentof each partner, on the organisation, on the various programmes necessaryto efficiently set-up the EMCS, and on the cost of the system.

The Strategy Plan was delivered in the eleven official languages of theEuropean Union.

5.6. Phase 3


Phase 3 is another writing task, aiming at producing the Final Report of thestudy.

5.6.2. Results

Phase 3 insists and gives more details on the contents of the various tasks to

be undertaken, in particular during the first steps of the computerisation, by allpartners, but in particular by the DG.

5.6.3. Products

The present report is the unique product of phase 3; it contains a short

summary of the study, a reminder of the proposed functionality, and aproposed breakdown of the tasks into several Lots for Invitations to Tender.






6. SUMMARY OF THE RECOMMENDED SOLUTION

6.1. Goals of the EMCS

The goals of the Excise Movement and Control System are:

• to protect Member States' financial resources by reducing the presentevasion of excise duties and of the associated VAT thanks to a better knowledge of the movement of goods and through better targeted controls;

• to preserve trade freedom within the framework of the applicable legislationand regulation, by allowing communication between economic operatorswithout the Member States Administrations being allowed to stop it;

• to give Member States Administrations and, possibly, the registeredeconomic operators access to up-to-date information on registers and

authorisations;

• to enable Member States Administrations to follow up the on-goingmovements better and in real time, thereby helping them to carry out risk evaluations and to organise the relevant controls;

• to give Member States Administrations a better overview of trans-Europeanmovements, since electronic records of all movements will be kept for statistical analyses;

• to favour the harmonisation of rules and practice among Member States, by

providing common computerised procedures;

• to fight against fraud and recover the evaded duties as much as possiblethrough better targeted controls;

• to help honest traders in their daily work by reducing unlawful competition,

and by providing them with a quick return of the discharge of their responsibility in terms of completed movements.

The Feasibility Study concluded that:

• the current Administrative Accompanying Document (AAD) defined inCommission Regulation (EEC) Nr. 2719/92 should be replaced with anelectronic record;

• to ensure that Member State Administrations and economic operators have

exactly the same information at the same time, the electronic AAD and all

relevant administrative information should pass through theseAdministrations' information systems when being exchanged betweeneconomic operators;

• all economic operators dealing on a regular basis with excisable goodsunder suspension arrangement, namely authorised warehouse keepers (andtheir warehouses), registered traders, and tax representatives of warehousekeepers, should be connected to the proposed system, irrespective of their

size;

• economic operators must remain responsible for the exchanged information;

• in return for the effort made by economic operators to provide theAdministrations with quick information, the Administrations must undertake to

transfer the said information automatically to the intended recipient as soonas they received it; moreover, they must help them to obtain quick dischargeof lawful movements;






• legal measures would be necessary to make the use of the electronic AAD

mandatory, to support certain recommended functions such as theconsultation of VAT registers via the VIES system, and to allow the extension ofthe excise movement procedures making it possible to inform the MSAs

earliest during the movement;• the Member States Administrations should take advantage of the technical

infrastructure to exchange information on traders and on on-goingmovements, in accordance with Directives 92/12/EEC and 77/799/EEC.

6.2. Prerequisites

Before the EMCS being put into operation, some tasks must be achieved by therelevant authorities, either the European Commission (TAXUD), or the MSAs,possibly together in the framework of the Excise Committee or of the SCAC:

• detect and propose the necessary legal arrangements;

• harmonise the rules for appointing excise numbers and for allowing access tothe computerised EMCS;

• improve the understanding of some rules and usage on movements under

excise duty suspension among Member States;

• define the level of integration with the Mutual Assistance systems;

• confirm the exact structure of excise products;

• agree on the values of the various codes to be used by the computerisedsystem (see the list of these codes in Appendix B).

6.3. Circuit of information

The recommended solution is based on the general architecture presented inthe Consolidated Report considering the architecture option A, where each

Member State Administration is responsible for the processing of all electronicexchanges inside its country and exchanges information with other MSAs.

B MSA of

dispatch

C MSA of

destination

A Consignor D Consignee

1 Commercial information

2 Electronic AAD

3 Electronic dischar ge

4 Cross-consultation

In this diagram, the plain arrows indicate exchanges of data that are part of theEMCS, whereas the dotted arrows indicate exchanges happening outside theEMCS.

To allow normal business operations, the system must meet very high securityrequirements. In particular, it must guarantee absolute confidentiality of thetransmitted information and must be permanently available, 24 hours a day and

365 days a year, with a very short service-restoration time in case of failure.






6.4. Technical architecture

As a consequence of the conclusions of the Feasibility Study and of the generalcircuit of information chosen, the following principles govern the proposedsolution:

• all registered operators (authorised warehouse keepers and their taxwarehouses, registered traders and tax representatives of warehousekeepers) must be connected to the system;

• all information transferred between connected economic operators transits

through at least one Member State Administration;

• other economic operators, in particular non-registered traders (occasionalconsignees), do not have direct access to the system; in that case, someinformation should transit directly between economic operators;

• if any information transits directly between economic operators, it isintroduced into the system under the responsibility of one, and only one,economic operator, usually the consignor;

• registered operators are responsible for provision of all information on

movements of goods, in particular for the submission and possible update ofmovement information (electronic AAD), and for sending back thedischarge message;

• all administrative information other than movement information is directly

transferred between Member States Administrations; it never transits througheconomic operators;

• public information may be open to consultation on a publicly accessibleInformation Centre;

• in the scope of the EMCS, a given economic operator communicates

directly only with the competent MSA.

Usage of the CCN/CSI infrastructure that is presently running to interconnect theMember States Administrations, has been recognised as an asset for the

proposed system. For a temporary period, the AFIS infrastructure is proposed tosupport Movement Verification and Mutual Assistance exchanges, as well ascomplementary utility exchanges.

This results in the following technical architecture:






COM

COM

CCN

CCNCCN

CCN

CCN/CSI

TAXUD OLAF

EMCS

EMCS AC

ECOP

ECOP

ECOP

ECOP

MSAECOP

MSA

AFIS

Each Member State Administration has an application server (EMCS) to processmessages issued either by their officials or by economic operators; each server isconnected to the CCN/CSI network through a CCN gateway; the work stationsof officials (MSA) are connected to the EMCS server through the internal network

of the MSA. In addition, various support centres and help desks are connectedto the EMCS server and/or to the CCN gateway (not shown on the drawing).

The economic operators (ECOP) are connected to the competent MSA through

a communication front-end (COM) that is actually replicated so that in case of

failure of one of them, the other ones are able to continue ensuring availabilityof the site. In most cases, economic operators just use a workstation or astand-alone PC, but larger ones will have their own server and network.

The offices of the European Commission (TAXUD and OLAF) are directlyconnected to a CCN gateway; the AFIS server is connected to the samegateway.

The Application Centre (AC) is connected through its own CCN gateway.

Each Member State Administration is in charge of the whole functionality

happening inside its Local Domain.

6.5. Proposed functionality

6.5.1. Functional breakdown

To allow scaled development and deployment, the system has been brokendown into three groups of functionality:

Group I prerequisite for the circuit of the electronic AAD, mostly information

of reference that is the object of particular Articles of the Directive

with mutual commitments to exchange of information; VIES accessmay be assimilated to that group;






Group II the circuit of the electronic AAD itself, including registration of

certificate of guarantee for non-registered traders;Group III modules for which the electronic AAD (Group II) is a prerequisite.

The functional modules composing the Groups are shown below with their order of dependence; plain arrows show that the referring module cannot runif the referred module is not operational, while dotted arrows show where thereferred module may be temporary omitted, although desirable. Greyedmodules have been quoted priority by the Administrations and by the

economic operators.

To improve readability, all transitive links have not been shown.

2 Registration of

MSA offices

1 Management of

lists of reference

3 Registration of

operators

4 Registration of

guarantees

5 Registration of

certificate

6 Submission of

AAD

8 Management of

duty claims

7 Receipt of AAD9 Change of AAD

10 Management of

criteria

11 Risk assessment

12 Management of

alerts

15 Mutual

Assistance

13 Road controls

16 Registration of

duty rates

17 Statistics

GROUP I

GROUP II

GROUP III

18 Reports

14 Movement

Verification

The following paragraphs give a brief summary of the sub-systems composing

each Group.

6.5.2. Group I

This group includes the prerequisite functions to operate the whole system,namely:

• management and dissemination of lists of reference;

• management and consultation of MSA offices;

• management and consultation of registered operators;

• management of guarantees;

•

management and consultation of duty rates;• consultation of VAT information;

• associated reports.






Technical description is provided in Appendix B.

6.5.3. Group II

This group is composed of the functions supporting the management of theelectronic AAD, these are:

• management of the certificates of guarantee;

• submission and registration of AAD;

• update and splitting of the AAD during movement;

• receipt and discharge of the AAD;

• connection with Customs procedures on export of goods;

• claims on losses;

• consultation and retrieve of movement data;

• automatic recalls;

• associated reports.

Technical description is provided in Appendix C.

6.5.4. Group III

This group includes the downstream functions:

• recording of reports of road controls;

• risk assessment;

• management of alerts;

•

automatic recalls;• statistics;

• Movement Verification and Mutual Assistance;

• exchange of free format utility messages.

Technical description is provided in Appendix D.

6.5.5. Utilities

In addition to the application functions listed above, complementarydevelopments should be made to create:

• appointment of user names;• change of passwords;

• monitoring of connections;

• consolidation of statistics;

• consultation of information by support agents;

• correction and patching by support agents.

Technical description is provided in Appendix E.






6.6. Security

The security requirements expressed during the Feasibility Study were rather highly quoted for confidentiality, authentication and integrity of messages;therefore, security has been identified as a specific domain of the

implementation of the system.

A draft agreement between partners of the future computerised EMCS hasbeen proposed, containing:

• a first evaluation of security requirements;

• a proposed list of security objectives of the EMCS;

• a series of security principles to meet the identified objectives;

• a list of mutual commitments that should be taken by each category of

partners.

During the implementation of the EMCS, the proposed draft agreement must beassessed, confirmed or amended, explicitly approved by partners, and the

relevant security policies must be published and enforced by each partner.

The following security policies will have to be created:

• an overall EMCS security policy, under the control of the EuropeanCommission; that policy must include the existing CCN/CSI security policy;

• a security policy for each Member State Administration, compatible with anyexisting national security policy and with the overall EMCS security policy;

• as far as possible, a security policy for each economic operator; at least,

economic operators should be made aware and trained on the securityissues of the system and commit to a minimum set of rules imposed by thesecurity policies of the MSAs.

After implementation of the EMCS, the actual enforcement of the securitypolicies must be regularly audited.

6.7. Information

Although not directly implemented as computerised functions, the Information

programme is an integral part of services provided to the users of the EMCS.

It includes:

• dissemination of information in "push" mode, under the form of publications(booklets, newsletters, etc.);

• dissemination of information in "pull" mode, under the form of questions andanswers, of an Information Centre open through the world wide web to all

users of the system, etc.;

• dissemination of information under a more interactive form, by periodicworkshops targeted on various audiences.

Information should be given to all partners involved in the EMCS, including alleconomic operators; therefore, a two-level organisation is proposed:






• at European level, general messages are defined;

• at national level, the general messages are adapted to local constraints anddisseminated to all officials and to the economic operators.

Professional organisations, at both levels, should be active parts of theInformation programme.

6.8. Training

Although not directly implemented as computerised functions, the Trainingprogramme is an integral part of services provided to the users of the EMCS.

It includes:

• formal training of officials, of developers / maintainers and of support agents;

• formal training open to economic operators: managers, end users;

• self-training material, such as CD-ROMs, training on web sites, etc. intendedfor other economic operators.

Training should be given to all partners involved in the EMCS, including alleconomic operators; therefore, a two-level organisation is proposed:

• at European level, general outlines of training courses are defined;

• at national level, the courses are adapted to local constraints and

disseminated to all officials and to the economic operators.

6.9. Support

Although not directly implemented as computerised functions, the Support

infrastructure is an integral part of services provided to the users of the EMCS.

It includes:

• a help desk to receive all requests and complaints; each user must have a

unique entry point to the support infrastructure;

• several support centres dealing either with technical issues (functioning ofcomputers and of connections) or with processing issues (unexpectedbehaviour of the application, no answer in sensible delay...), both in each

MSA and at common level.

The help desk is the unique entry point of each user to the support infrastructure.It is organised under the responsibility of each MSA, which can determine its

internal organisation, for instance whether the same physical unit is directed toeconomic operators and to officials, or whether there should be two separateunits, etc. In that domain, the only constraint is that a given user has a uniqueinterlocutor who both receives questions and complaints and reports thesolution.

As a whole, the Support infrastructure must be able to solve quickly and

efficiently all issues arising during the operation of the EMCS. The systemspecification should include precise requirements on the availability of the

support interface and on the time to solve problems.






Permanent availability of the support infrastructure (24 hours a day, 365 days ayear) has been requested by the professional organisations. This means at leastavailability of the help desk, possibly of all support centres.






7. RISK ASSESSMENT

The activities proposed in this document are believed to include the necessarymeasures to fight against the major risks of the computerisation process. This is more

detailed in the following tables.

Identified risks have been distributed onto four domains, with unequal importance:

• cost: although the overall cost of the system is high, there are many and

important arguments favouring quick implementation;

• organisation: the complex organisation involving many partners and manyproviders necessitates careful co-ordination and monitoring;

• usage: understanding and good operation of the system necessitate careful

preparation of the awareness of all potential partners;

• technical: consequences of organisational choices must be carefully estimated

and the convenient verifications implemented.

Domain: Cost Risk: Low Consequences: Medium

Title: Over-estimation of costs

Description:

The total estimated cost of the system was felt very high by Member StatesAdministrations

Potential impact:

It could be difficult to convince budgetary authorities, resulting either in a rejectionof the system or in additional delaysMSAs could require an extension of the overall planning

Extra costs due to additional delays

Measures suggested:

Re-use as much existing resources as possibleInsist on the expected savings in terms of evaded duties

Domain: Cost Risk: Medium Consequences: Medium

Title: Under-estimation of costs

Description:

Budget estimation of a Member State Administration could be underestimated.

Potential impact:

The concerned MSA could not keep its commitments.

Additional delays resulting in extra costs.Measures suggested:

Assess estimation of each MSA compared to other ones and to the figuresestimated by the DG, in particular the items concerning common work such asparticipation in the system specification and in the system validation.

Insist on the expected savings in terms of evaded duties






Domain: Organisation Risk: High Consequences: Medium

Title: Co-ordination

Description:

Many tasks necessitate contributions of the DG and of the MSAs

Potential impact:De-synchronisation of contributions resulting in additional delaysExtra costs due to additional delays

Measures suggested:

Precise initial planningObtain explicit commitment of all Member States AdministrationsSeveral persons of the Central Project Office to be devoted to relationship withMSAs

Regular exchange of planning data with MSAs

Domain: Organisation Risk: Medium Consequences: Low

Title: Planning

Description:

Partners, in particular economic operators, could underestimate the tasks to be

undertaken before deployment of the system.

Potential impact:

Delays in the deploymentExtra costs due to additional delays

Measures suggested:

Information programme starting as soon as possible in the overall planning

Domain: Organisation Risk: Medium Consequences: Low

Title: De-synchronisation of a Member State

Description:A MSA could not be ready in due time to open the service

Potential impact:

The service could not be open at the same time in all Member States.The economic operators would have to use both the paper system and thecomputerised system at the same time.

Measures suggested:

Precise commitments on the delays.Careful follow-up of the progress in each Member State by the Central Project

Office.

Domain: Usage Risk: Medium Consequences: Medium

Title: Understanding of the system

Description:

Partners, in particular economic operators, could have a wrong view of the system

and misuse it.

Potential impact:

Delays in the deploymentMisuse of the system by beginningAdditional training necessary to palliate lack of understanding

Measures suggested:

To be taken into account in the first communication actions of the Informationprogramme






Domain: Usage Risk: Medium Consequences: Medium

Title: Operation

Description:

Usage of the end user interfaces could prove difficult (both for understanding the

contents of each message and for operation of user interfaces)Potential impact:

Rejection of the system by officials and by economic operatorsAbuse of calls to the support infrastructure

Measures suggested:

Training programmeQualification of the proposed user interfaces with potential end users, in nationalapplication specification phases – modelling or prototyping could prove useful.

Domain: Usage Risk: Medium Consequences: Low

Title: Acceptation by users

Description:

The proposed system implies change of usage of officials and of economicoperators

Potential impact:

Gap between the specified system and interpretation of messages by users (both

by officials and by economic operators)

Measures suggested:

Deeply involve MSAs and professional organisations in the system specificationphaseInformation programme

Domain: Technical Risk: Low Consequences: HighTitle: Change of architecture or of major specification choice during thedevelopment process

Description:

The choice of an architecture option cannot be easily changed, as well as themajor choices recommended by the Feasibility Study

Potential impact:

If found necessary, change of architecture or of basic specification would requireresuming the development from Phase 3 of the Feasibility Study (re-define andre-launch ITTs) or from some point of the system specification.This would result in an additional delay depending on the time where the decision

would be taken, and in the dead loss of the cost of tasks already performed – almost nothing could be rescued.The consequences become more important as the decision is taken later.

Measures suggested:

State very precisely and from the very beginning of the computerisation projectthe reasons to choose an architecture and the major specification choices (to bedone in co-operation with the Member States).

Re-assess these choices in particular at the end of the System specification.






Domain: Technical Risk: Medium Consequences: Medium

Title: Efficiency and reliability

Description:

The architecture proposed is believed to have some weakness in efficiency and

reliability.Potential impact:

Could result in bad performances and in numerous errors and failures, and possiblyrejection by users.

Measures suggested:

Testing of performance and robustness included in the certification process of allapplications

Domain: Technical Risk: High Consequences: Medium

Title: Development

Description:

The proposed solution includes the development of fifteen applications by fifteenMSAs

Potential impact:

Cost of co-ordinationDelays.

Measures suggested:

System specification focused on interfaces and completely approved by MSAs

Creation of CIUGsCareful procedure of certification for all applications

Domain: Technical Risk: Low Consequences: High

Title: Dependence on CCN/CSI

Description:The inter-MS communication of the EMCS depends on the CCN/CSI infrastructure

Potential impact:

The present availability requirements of CCN/CSI are lower than those of theEMCS, therefore in case of breakdown of one CCN connection, the EMCS sitecould not recover in the required delay.

Measures suggested:

Estimate the cost to upgrade CCN/CSI to the required level.Specify and estimate a fallback solution involving other links.

Domain: Technical Risk: Low Consequences: Medium

Title: Dependence on national network

Description:

The intra-MS communication of the EMCS depends on the nationalcommunication providers. Each economic operator should have the ability to

choose his own communication provider.

Potential impact:

Some providers are less reliable than others are, potentially resulting inunavailability of the operator's connection.Same risk on the connection of MSA offices through the internal network of theMSA.

Measures suggested:

Select professional-level service providers and recommend economic operators

to use their services rather than cheaper ones.Re-assess reliability of the internal network.






Domain: Technical Risk: Low Consequences: Low

Title: Dependence on common tables with the NCTS

Description:

Part of the reference data are extracted from the same table as the

corresponding data from the NCTS, and managed using common tools.Potential impact:

The common tool could become unavailable, resulting in delays in the update ofreference data.

Measures suggested:

Define a fallback solution with tables maintained using simple office tools.

Domain: Technical Risk: Low Consequences: High

Title: Fallback procedures

Description:

If the system is stopped for a long time (several days), it is not possible to wait for operations to come back to operational state

Potential impact:

Blocking of economic life of some operator or of a Member State – unacceptable

Measures suggested:

Backup configuration to be regularly verifiedExplicit procedures to be created by the Member States Administrations for fallback on paper solution and return to computerised procedure






8. TASKS TO BE UNDERTAKEN

8.1. Directorate General for Taxation and the Customs Union

8.1.1. Introduction

Referring to the trans-European development policy, the EMCS should bedeveloped in three phases in accordance with the classical "V" development

cycle proposed by the MaXXIme methodology. The main activities identifiedunder the responsibility of the DG are:

• Central Project Office, including the co-ordination of the supportprogramme and the monitoring of deployments;

• central quality management;

•

central security;• system specification;

• development of validation tools;

• development of common application tools;

• Application Centre;

• central information programme;

• central training programme.

The following paragraphs summarise each activity fulfilling these duties, under the following outline:

• list of tasks: split the activity into individual tasks according to profile and

responsibility;

• documentation: the documentation used as input of the activity;

• products: products delivered as output of the activity, such as documents,software, hardware …

• contractual approach: typical contracting relationship that could be setup to perform the activity;

• profiles: for assistance and general activities, a short description of therequired competencies;

• constraints: particular constraints (delay, relationship, profile, …).

These descriptions are intended to be used by the DG as terms of referencefor invitations to tender. They should be completed by other documents

produced by the Feasibility Study, in particular the Consolidated Report.

A summary of the recommended organisation of ITTs is presented inparagraph 8.1.13.

To improve efficiency of relationship, it is recommended that partners agreeon a common working language, for instance English. Intermediatedocuments submitted to comments of the Member States Administrationsshould be produced at least in the three working languages of the European

Commission (English, French and German). Final documents (in particular those that should be re-used as input by the MSAs) would have to bepublished in all languages of the European Union.






8.1.2. Central Project Office

The main purpose of this activity is to supervise the realisation of the wholecomputerisation of the EMCS, in particular to co-ordinate the work carried out

both under the responsibility of the DG and under the responsibility of MSAs.

Input documentation:

• documentation produced during the EMCS Feasibility Study;

• MaXXIme methodology.

Description of the tasks:

Tasks Contents

Organisation Set up the organisation dedicated to follow up the

whole computerisation (as described in the

Consolidated Report).Produce the Project Management Plan defining:

• roles, responsibilities and obligations;

• overall work breakdown structure of thecomputerisation project with the associatedresponsibilities (hardware, functional specification,technical specification, detailed specification,

coding, validation, integration, acceptance,warranty, etc.)

• description of activities;

• objectives and expectation of the project;

• overall environment of the project;• general constraints of the project;

• obligations of each partner;

• sequences of tasks and initial planning;

• etc.






Tasks Contents

Planning andprogress monitoring

Set up the initial Project Time Plan defining the mainmilestones, including part of responsibility of the MSAs:

• Work Breakdown Structure (WBS);

• chaining of tasks (PERT chart);• start and end dates of each activity (GANTT chart);

• deadlines for awarding contracts;

• dates for approval documentation;

• dates of validation, acceptance, implementation;

• etc.Define exchange formats between the variousplanning tools to be used by partners.

Update the Project Time Plan, at least monthly; to doso, define when and how the Central Project Officegets information on each activity, and how that

information is used to update the Project Time Plan.Establish and disseminate progress reports.Anticipate and assess possible difficulties due toslippage of some activities, and consequences onother activities; propose corrective actions to remedythe situation.

Co-ordination Co-ordinate activities of all MSAs and other partners:

• organise and chair the various Committees andworking groups;

• disseminate documentation produced by theproviders of the DG, either for examination and

comments, or for application;• permanently monitor the progress of MSAs;

• assist MSAs in understanding and organising their contribution to the computerisation project;

• collect reporting and contributions of MSAs,summarise, disseminate summaries;

• propose additional activity programmes;

• control the progress of contractors.

Contracting Prepare and publish Invitations to Tender.Select providers.

Set up the Service Level Agreement (SLA) of each

common provider, in particular of the operator of theApplication Centre.Follow up the contractual relationship with each

contractor.

Technical authority Approve the documentation produced by the

providers of the DG.Approve the technical documentation submitted bythe MSAs (for the part of each application thatconcerns the inter-MSA exchanges).

As necessary, audit developments in MSAs.As necessary, organise and chair technical meetingson particular points.






Tasks Contents

Acceptance Define the general acceptance procedure:

• responsibility of participants;

• categories of products (deliverables, intermediate

delivery, …);• type of deliverable (document, hardware,

software, training, others services, …);

• time allowed for comments;

• type of approval (full, partial, with reserves, …);

• notification of acceptance, in particular whenlinked with a payment;

• etc.

Define the Project final acceptance necessary toauthorise the global deployment of the EMCS.Chair the acceptance process of software developed

under the responsibility of the DG.If accepted by the MSA, witness acceptance ofsoftware developed under the responsibility of eachMSA.Chair final formal certification of the softwaredeveloped by each MSA.

Deployment policy Establish a common Deployment Strategy Plan

Co-ordination of

deployments

Audits on the actual progress of the deployment in

each Member State:

• co-operation with the MSAs;

• relationship with professional organisations.

Risk management Set up a Risk Management Plan:• for each step of the project, identify the type and

level of risks that could be encountered;

• define measures to prevent consequences of risks;

• inform partners (contractors and MSAs);

• etc.Update risk assessment according to the progress ofthe implementation.

Support Define the support organisation.

Define support policy.Define agreements and procedures of co-operation.Define circuits of communication.Define profiles and competence of national support

centres.Define necessary training for support agents.Monitor support activities of MSAs.Co-ordinate of the activities of national support

centres.

Output documentation:

• Project Management Plan;

• Project Time Plan (initial and updates);• progress reports;






• Invitations to Tender for common providers;

• contracts and Service Level Agreements of common contractors;

• general acceptance procedure;

• common Deployment Strategy plan;

• Risk Management Plan (initial and updates);• support policy;

• procedures of collaboration;

• results of audits

Contractual approach:

The tasks of the Central Project Office must be carried out under the directresponsibility of the senior Project Officer, which is mandatory an official of the

DG. In any case, a group of officials must participate in the Central ProjectOffice.

Therefore, it is recommended to organise the Central Project Office with three

categories of members:

• responsible officials to take the responsibility of the computerisationproject and to perform tasks that certainly cannot be delegated(preparation of budgets, launching of ITTs, selection of providers, reporting

to the hierarchy, formal relationship with other services of the EuropeanCommission, with the MSAs and with the contractors...)

• "intra-muros" consultants to carry on the day-to-day work as assistants tothe officials (preparation of work, secretarial work, co-ordination...);

• a contract awarded to an external team, which can perform

better-defined tasks such as follow-up of planning, reporting, technicalevaluation, etc.

The distribution of tasks among the three categories should be doneaccording to the ability of TAXUD to create positions for officials and for intra-muros consultants.

Profiles:

Profile Dates

Senior Project Manager (official) From T0-6 to T0+54 monthsDeputy Project Manager (official) From T0-6 to T0+54 months

Excise experts dealing with legal and

regulatory aspects of thedocumentation produced (at leastone official plus possible non officials)

From T0 to T0+30 months

Technical experts to monitor acceptance of all technical

deliveries (documents, hardware,software) (do not need to beofficials)

From T0+6 to T0+30 months






Profile Dates

Assistants to monitor the activities ofthe MSAs, deployment of the EMCS,the support, etc. (do not need to be

officials).


Constraints:

The Senior Project Manager and the Deputy Project Manager should be

appointed as soon as possible, so that they can co-ordinate the preparationof the whole computerisation.

The main part of the team should be set up for the beginning of the

computerisation, therefore the ITTs for consultants and a possible externalteam should be issued very first in the project, at the same time as the ITT for

system specification (see below).

8.1.3. Central quality management

The purpose of this activity is to set up the overall quality policy of the systemand to control that all partners (the DG, the MSAs and their providers, and theeconomic operators) conform to that policy.


• documentation produced during the EMCS Feasibility Study

• MaXXIme methodology

• trans-European development policy• outline of the Project Management Plan


Tasks Contents

Quality Plan Referring to the Project Management Plan, producethe global Quality Plan describing the common rulesand procedures to manage the computerisationincluding:

• common rules to be respected by all partners;

• roles and responsibilities, including contractualrelationship;

• common procedures and procedures for central

activities (communication, quality, archiving,configuration management).;

Each provider should produce its own Quality Planconforming to the global Quality Plan.

The Quality Plan must conform to the model providedby the MaXXIme methodology.

Quality assurance Supervise the implementation of the qualityprocedures by partners.

Ensure that all actions defined in the Quality Plan areactually performed in due time, and that results are

properly registered.






Tasks Contents

Quality control Systematic control of deliveries made by the providersof the DG.Control of conformance of the specifications

submitted by the MSAs.Record traceability, in particular where specificdecisions are taken.Periodic quality audits.

Publish results of audits.


• Quality Management Plan

• quality procedures

• quality records

• traceability records• audit procedures

• results of quality audits


The DG might perform quality assurance and quality control by their ownmeans, but it is rather recommended to launch an Invitation to Tender toselect a contractor able to perform the tasks described.

The contractor of quality assurance may be the same as for the assistance to

the Central Project Office.

Profiles:

Profile Dates

Quality experts to establish quality plan

and procedures and for qualityassurance


Quality controllers From T0 to T0+48 months

Constraints:

Same as for the Central Project Office.

8.1.4. Central security

The DG must define the EMCS security policy based on the mutualcommitments taken by each Member State based on security principles.



• Project Management Plan

•

Quality Management Plan• CCN/CSI Security Policy







Tasks Contents

Security agreement Produce the EMCS Security Policy, including:

• collection of security requirements from all MS;• security objectives;

• security principles;

• mutual commitments on security to be taken byeach category of partners (refer to theConsolidated Report)

• etc.

Define the level of security and availability for eachpart of the EMCS.Define an overall contingency plan in case of generalbreakdown of the system, in particular in case of long

lasting unavailability of CCN/CSI.Security control Specifically verify that the security commitments are

properly taken into account in all plans, specifications,procedures, etc. produced by each provider and byeach MSA.

Verify that the MSAs have and apply procedures tofulfil all the commitments they took.Summarise and publish the results of the periodicsecurity audits made in the Member States.Report to Central Project Office.


• EMCS Security Policy

• procedures to apply the EMCS security policy

• overall contingency plan

• audit procedures

• results and published summary of security audits


The DG might perform security definition and control by their own means, but

it is rather recommended to launch an Invitation to Tender to select acontractor able to perform the tasks described.

The contractor for the central security may be the same as for the assistanceto the Central Project Office.

Profiles:

Profile Dates

Security experts to establish securitypolicy and procedures – should remain

available afterwards for maintenance ofprocedures


Security auditors From T0+12 to T0+54 months






Constraints:

Same as for the Central Project Office.

8.1.5. System Functional and Technical SpecificationsThe purpose of this activity is to define the functional and technicalspecifications of the EMCS, including complementary functions such as

utilities, testing tools, etc.





• Project Time Plan (initial and updated)

• EMCS Security Policy; note that the Security Policy will be developingduring the system specification, therefore this link is rather a co-ordinationwith the central security management activity

• CCN/CSI documentation


Tasks Contents

System functionalspecification

Description of the functionality of the EMCS in terms offunctional modules and of interfaces, including thecommon application modules to be developed

under the responsibility of the DG (management ofreference data, message builder and messageviewer, technical monitoring, consolidation ofstatistics...)

System technicalspecification

Description of the breakdown of the EMCS intomodules, and of their interfaces.

Must be so precise that it can be used by all MSAs asimperative requirements for their own development(refer to the DDNTA of the NCTS)

Test plans Define the Test Plan for the software productsdeveloped under the responsibility of the DG:

• technical environment required;• necessary tools;

• description of the tests to be carried out on theproduct delivery and expected results;

• formal verification of the documentation linked to

the delivery;etc.

Acceptance Plan Define the objects to be validated for acceptance ofa national application at European levelDescribe environments, roles and responsibilities,

objects to be assessed (documentation, software,

procedures, etc.)Must be made of two parts: technical (compliance ofinterfaces) and functional (compliance of semantics)






Tasks Contents

Specification ofvalidation scenarios

Define a series of operational scenarios (including themajor cases of error) that must be applied for validation of national applications:

initial state of the data base of the TTA-similar tool; sequence of operations;

expected final result.Complementary, tests for robustness and

performances should be defined.

Technical training Technical training of developers of nationalapplications.Must cover both CCN/CSI aspects and EMCS aspects.


• System Functional Specification• System Technical Specification

• External Interface Specification

• Glossary of Terms

• EDI Mapping Specification

• Test Plans of the common applications

• validation scenarios

• System Functional Acceptance Plan

• System Technical Acceptance Plan

After approval by the Central Project Office, these documents must be

distributed to all Member States Administrations and to the EuropeanFederations of professional organisations for explicit agreement before being

used as mandatory reference for their own developments.


To guarantee the homogeneity of the system defined and avoid problems atthe boundary of roles, the whole system specification must be awarded to asingle company.

Alternatively, the DG is considering an in-house specification involving the

participation of persons delegated by the various MSAs; such an organisationshould be agreed by the MSAs and must anyway be controlled by technicalpersons. This does not relieve MSAs from explicitly validating the specification.

Constraints:

The System Specification must be contracted separately from the three

preceding contracts (Assistance to Central Project Office, Quality andSecurity).

8.1.6. Development of validation tools

The purpose of this activity is to specify and develop validation tools used byMSAs and the DG for acceptance tests.









•

Functional Specification• Technical Specification






• TTA and STTA tools of the NCTS.


Tasks ContentsSpecification ofvalidation tools

Description of the tools proposed to the MSAs for validation and certification of their applications.Must cover all inter-MSA interfaces of the EMCS.

Two tools to be described:

• stand-alone tool to be proposed to the MSAs tohelp them in local pre-acceptance (similar to theSTTA application of the NCTS);

• central tool to support certification of applications(similar to the TTA application of the NCTS).

Development of

validation tools

A STTA-like tool to be provided to the MSAs if they wish

so, to perform tests on their own developments.A TTA-like tool to be installed in the Application Centrefor validation and certification of applications

Output products:

• specification of validation tools

• software validation tools


Three strategies may be proposed, in order of preference:

• have an agreement with the NCTS team to have these tools developedby their present holder (normally, the NCTS Application Centre);

• let the new EMCS Application Centre develop them;

• launch a specific ITT.

Constraints:

If the company selected to carry out this development does not haveknowledge of the existing test applications, it should be necessary to providethem with training and assistance by the NCTS.






8.1.7. Development of application tools

The purpose of this activity is to develop common applications.




• Work Breakdown Structure



• System Functional Specification

• System Technical Specification




• System Functional Acceptance plan• System Technical Acceptance plan

• CCN/CSI documentation

• NCTS system documentation

• AFIS documentation


Tasks Contents

Development ofapplication tools

These tools are:

• management and dissemination of tables of

reference; as far as possible common tools with theNCTS (in particular for the lists of codes and for thelist of offices);

• extraction of duty rates by consultation of Member

States for information of the economic operators;

• message builder and message viewer to beinterfaced with the AFIS client, but designed in away that would allow to easily create a further interface with the EMCS;

• monitoring tools to allow the Application Centre tomeasure the availability of the EMCS sites and the

performances they provide through specificCCN/CSI exchanges;

• particular tools to consolidate the statisticscommunicated by the MSAs to the ApplicationCentre.

Output products:

• management tool of lists of codes;

• management tool of list of offices;

• management tool of structure of excise products;

• management tool of the thesaurus of terms;• extraction utilities to produce various formats of files ready for

downloading from the Information Centre;






• message builder and message viewer integrated with the thesaurus of

terms and with the AFIS client;

• monitoring tools of the Application Centre.


The Invitation to Tender for these developments should be organised intoseparate Lots that could be awarded to different contractors; in each case,good knowledge of the context would be an important criterion to award the

contract.

Constraints:

If the company selected to carry out some of these developments does nothave the required knowledge of the context, in particular for themanagement of some reference data (common with the NCTS) and for themessage builder and the message viewer (to be integrated with AFIS), it

should be necessary to provide them with training and assistance.

8.1.8. Application Centre

An Application Centre must be created by the DG to monitor functioning ofthe system and to be the central support authority of the system. It wouldhave a CCN/CSI access. In addition, it should be responsible for themanagement of the lists of reference, and participate in the information

programme by providing dissemination facilities (Information Centre).

Input products:



• Work Breakdown Structure





• System External Interface Specification


•

EDI Mapping Specification• System Functional Acceptance Plan



• software application tools


There are two types of tasks:

• infrastructure tasks: supply the technical infrastructure of the Application

Centre;• operating tasks: operate the Application Centre.






Type Tasks Contents

Infrastructure Hardware andsoftwareplatform

The Application Centre should beequipped with a server connected tolocal work stations and to a CCN

gateway.Firewall interfaces should be provided toprotect the Application Centre againstunauthorised access.

In addition, one or two separate webservers must be provided for theInformation Centre.

Installation Install and check the applicationsdeveloped for the Application Centre:

• management of reference data, as

far as relevant;

• monitoring;• consolidation of statistics.

Internet website

For the information of economicoperators, the Application Centre should

operate a web site freely accessiblethrough the Internet, providing:

• general information on the system,from web pages provided by theInformation programme;

• consultation and downloading of thetables of reference, except the

thesaurus of terms that should beaccessible only by the MSAs;

• consultation and downloading of theexcise duty rates.

Intranet website

For the information of the MSAs and ofthe support agents, another web siteshould be accessed through the

CCN/CSI web facility, with the benefit ofthe CCN access control lists:

• consultation and downloading of alltables of reference;

• share of experience on the usage ofthe system (frequently askedquestions), provided by theInformation programme and by theSupport programme.

Note that this could result in re-evaluatingthe necessary CCN/CSI resources.

Training Developers Training for developers of nationalapplications, concerning:

• CCN/CSI (with the help of theCCN/CSI Technical Centre)

• validation tools and procedures






Type Tasks Contents

Support agents Training for technical support agents andagents of the help desks concerning theusage of common support tools.

Operation Start intooperation

Prepare and open the ApplicationCentre

Information

Centre

Operate the web site(s)

Install and check the web pages issuedby the information programme, trainingprogramme, support programme …Get questions asked on the web site(s)

and transmit to the central informationprogrammeInstall new lists of reference and tables ofexcise duty rates.

MonitoringCentre

Operate the monitoring tools andanalyse the results.

Develop and maintain necessary tools.Detect non-conformance to thecommitments for availability and time ofresponse.

Report, possibly with the concerned MSA.Propose corrective actions.

Support Centre Monitor the support activities.If necessary, when several MSAs areinvolved in a functional/procedural

problem or technical incident, act as anarbitrator on behalf of the DG.Collect know-how on the usage of thesystem and summarise it on theInformation Centre.

Certification

Centre

Certification of the national applications

developed by the Member States, usingthe common validation tools (similar tothe TTA tool of the NCTS).

The Application Centre does not need to be available 24 hours a day and 365days a year. The suggested availability is to cover opening hours of all

Member States, resulting in extended daily hours, six days per week. In theInvitation to Tender, an option should be requested to quote permanentavailability.

Output products:

• operating Application Centre

• training of technical agents

• reports on activity, statistics, etc.

• on-request developments.







A particular ITT should be launched for the Application Centre, possibly

including some other parts (in particular development of specific tools).

Profiles:

It is the responsibility of the tenderers to determine the exact profiles of thepersons composing the team of the Application Centre; versatile profileswould certainly be useful. The following skills should be provided:

Profile Dates

Management and planning From T0+6

Technical trainers From T0+6

Operators From T0+18

Support agents From T0+18Developers From T0+18

Persons to validate applications From T0+18

At least one webmaster From T0+18

Note that the dates given do not take into account the development of

validation tools and of common application tools; if these tasks would beawarded to the same provider, the team should begin working earlier.

Constraints:

The Application Centre should be able to handle calls at least in the threeworking languages of the European Commission, and preferably in alllanguages of the European Union.

8.1.9. Information programme

This programme concerns all exchanges of information related to the EMCS.

This should be the major way to communicate the information policy and thestrategic priorities for the implementation and usage of the system. The DGdefines all general orientations, including editorial contents of the informationprogramme and basic material, but MSAs produce, from that basis, their ownpublications and communication actions.

Input products:












Tasks Contents

Information policy Define targets and basic contents

Strategic prioritiesPlanning and co-ordination of plans

Produce common information planCo-ordinate with the Central Project Office (reporting,agreement of plans)

Public relations Assist the Central Project Office in their relationshipwith external partners (such as the press)

Publications Produce periodic publications of newslettersProduce institutional booklets at the European levelDisseminate publications through the Internet web site

of the Information Centre

Questions andanswers

Maintain Frequently Asked Questions (FAQ)documents to be published on the Internet web site ofthe Information Centre.Collect questions asked either on the Information

Centre or transmitted by Member StatesAdministrations, possibly by the European federationsof professional organisations.As relevant, forward questions to the competentauthority, in particular to national information

programmes.Make answers to general questions and send back to

the requestor.Select general interest questions and add to the FAQ.

Meetings and

workshops

Organise European-level meetings and workshops

Disseminate results of meetings and workshops,possibly through the Internet web site of theInformation Centre

System evolution Collect requirements about potential evolutionPropose evolution of the systemDefine and plan evolution of the system

Output products:

• common Information Plan

• publications

• basic material for national publications

• web information pages

• forwarding of questions and dissemination of answers

• common know-how on the EMCS

• results of meetings and workshops

• reporting


A specific ITT should be launched for the central information programme.






The contract may be awarded to the same provider as the central training

programme, but this is not mandatory as missions are clearly separate.

Profiles:

Profile Duration

Co-ordinator From T0 to T0+54 months

Communication experts and assistantsfor preparation of publications and for

organisation of workshops


Technical experts From T0 to T0+54 months

Excise experts From T0 to T0+54 months

8.1.10. Training programme

The success of the system depends in a large extent of the training

programme that must cover all profiles of users of the system. The DG definesthe contents of each course and produces basic material to help Member

States in building courses adapted to national context. Self-training material isproduced at national level, from sources elaborated at common level.

Input products:





• System Functional Specification• System Technical Specification


Tasks Contents

Training policy Define training policy.Define profiles and contents of courses.Define training modules.Planning and co-ordination of plans.

Co-ordinate with the Central Project Office (reporting,

agreement of plans).Training tools Develop basic material

Develop standard self-training courses.Disseminate to MSAs

Supervision Co-ordination of training programmes of the MSAs.

Output products:

• training policy

• definition of training modules

• basic training tools and basic material for development of courses

• basic material for self-training• reporting







A specific ITT should be launched for the central training programme. Note

that the technical training (for developers and technical support agents)

should be provided by the Application Centre.

The contract may be awarded to the same provider as the centralinformation programme, but this is not mandatory as missions are clearly

separate.

Profiles:

Profile Duration

Co-ordinator From T0+6 to T0+54 months

Training methodologists From T0+6 to T0+48 months

Technical experts From T0+6 to T0+48 monthsExcise experts From T0+6 to T0+48 months

Training developers for self-trainingmaterial (not IT specialists)


8.1.11. Support programme

There are no specific activities directly attached under that title.

Monitoring of the support programme to be included in the activities of theCentral Project Office.

Daily operation of central support entrusted to the Application Centre.

8.1.12. Deployment

Deployment in the European Commission should be made by the own meansof the concerned Directorates, possibly with the assistance of the ApplicationCentre:

• TAXUD-D/3 for the Directorate General for Taxation and the CustomsUnion;

• OLAF for their own connection (TAXUD-D/3 and the Informatics

Directorate should participate to open network connections).

Monitoring of deployments in the Member States is a part of the activities ofthe Central Project Office.

8.1.13. Summary of ITTs

The following table summarises the ITTs that should be launched by the DGduring the process; preparation of each ITT should begin between four and sixmonths before the expected beginning of work.

Lot Description Beginnin

g of work

Comments

1A Assistance to Central ProjectOffice

T0






Lot Description Beginning of work

Comments

1B Central quality management T0

1C Central security T0

2 System specification T03 Development of validation tools T0+6 Consider entrusting to a

team common with theNCTS

4A Development of applicationtools – reference data

T0+6 Consider entrusting, atleast for a part, to a

team common with theNCTS

4B Development of applicationtools – message builder andmessage viewer

T0+6 Consider entrusting tothe AFIS technical team(agreement with OLAF)

4C Development of applicationtools – monitoring

T0+6

4D Development of application

tools – consolidation of statistics

T0+6

5 Application Centre T0+12

6 Information programme T0

7 Training programme T0+6

There is a table of compatibility between proposed Lots:

• a N denotes that the Lots should not be awarded together;

• a C denotes a compatibility with significant synergy; awarding these Lotstogether should be considered but is not mandatory;

• a P denotes compatibility without significant synergy; it is possible to

award these Lots together but this would not bring a really significantbenefit..

1B 1C 2 3 4A 4B 4C 4D 5 6 7

1A C C N N N N N N N N N

1B C N N N N N N N N N

1C N N N N N N N N N

2 C C P P P P P P3 P P P P C P P

4A P P P C P P

4B P P P P P

4C P C P P

4D C P P

5 C C

6 C

8.2. Member States Administrations

The Member State Administrations have to develop and implement their ownEMCS application conforming to the functional and technical specificationsprovided by the DG.






All MSAs are free to select tools, technical environment, hardware, etc. inaccordance with their internal requirements. They may develop their application based on an existing platform, however the resulting system must be

fully compliant with the specifications provided by the DG, in particular theintra-EU interfaces must be strictly compatible, both in form and in semantics,with the systems developed by other Member States.

To help MSAs in verifying compatibility and in preparing the validation

(certification) of their system, the DG will provide the MSAs with validation tools.

The activities under the responsibility of MSAs are:

• National Project Office

• quality management

• security policy and management• development of Group I applications

• acceptance of Group I applications

• development of Group II applications

• acceptance of Group II applications

• development of Group III applications

• acceptance of Group III applications

• information programme

• training programme

• support programme

• deployment

Many of these tasks will be based on documents or basis materials put by the DGat the disposal of each Member State.

The following paragraphs summarise each activity by describing them asfollows:

• list of tasks: split the activity into individual task to be performed with aparticular profile and responsibility;

• documentation: the documentation used as input of the activity;

• products: products delivered as output of the activity, such as documents,

software, hardware, …;• constraints: particular constraints (delay, relationship, profile, …).

As the organisation of each Member State may differ significantly from eachother, no lists of profiles are given, except for the National Project Office; mostgenerally, the required skills are the same as described for the corresponding

tasks of the European Commission. Each MSA has to determine how they willbring these skills together, through internal or external resources, with full-time or part-time persons, etc.

Each Member State Administration is free to determine which part of these tasks

can or must be contracted and should launch its own Invitations to Tender.






The following presentation of each activity is deliberately more generic than for

the DG, so that it can be adapted according to the own requirements of eachMember State. Actually, activities are decomposed into unitary tasks with a listof input documents and tools provided either by the DG or by preceding tasks.

According to their own constraints and requirements, each Member State mayextract and adapt a subset of tasks that they consider necessary, group theminto Lots for an ITT, etc. In particular, national quality assurance and the NationalProject Office and/or national security could be grouped, or specification and

development, etc.

8.2.1. National Project Office

The main purpose of this activity is to supervise all activities of thecomputerisation of the EMCS in the Member State.

Input documentation provided by the DG:





• mutual commitments on security

• Service Level Agreements

• general acceptance procedure

• Test Plans

• Acceptance Plan

• Risk Management Plan


Tasks Contents

Organisation Set up the organisation dedicated to follow up the

part of the process that depends on the MSA.Produce a Project Management Plan; if nationalquality assurance is grouped with the National ProjectOffice, a unique Project Quality and Management

Plan may replace both the Management Plan and

the Quality Plan.Co-ordinate activities of all contractors

Planning andprogress monitoring

Define a planning in accordance with Project TimePlan provided by the DG.Update the Project Time Plan.

Report changes of the planning to the Central ProjectOffice.Establish and disseminate progress reports.Anticipate and assess possible difficulties due to

slippage of some activities, and consequences onother activities; propose corrective actions to remedy

the situation.Inform Central Project Office of any problems that

impact the global planning.






Tasks Contents

Co-ordination Participate in the common meetings or workshopsorganised by the DG.Comment documentation produced by the DG or its

providers.Report to the DG any information that might impactthe overall progress.Control the progress of contractors.

Contracting Prepare and publish Invitations to Tender.

Select contractors.Set up the Service Level Agreements (SLA) of eachprovider, in particular of service providers (operators,support infrastructure...).Follow-up the contractual relationship with each

contractor.

Technical authority Comment and accept the common technicaldocumentation provided by the DG.Approve the technical documentation submitted bythe various providers contractor.

Disseminate the external specification to theeconomic operators that want to develop their ownapplication.Periodic technical audits on the work of providers.Participate in technical meetings organised by the

DG.As necessary, organise and chair technical meetings

on particular points.Acceptance Define the acceptance procedures.

Define the application final acceptance of the

national EMCS.Chair the acceptance process of software developedunder the responsibility of the MSA.Submit national EMCS to the certification process

made by the Application Centre under the control ofthe DG.

Deployment Define the national deployment policy conforming tothe common deployment policy.Supervise co-ordination with professionalorganisations and with the economic operators.

Follow up the planning of deployment for each sector.






Tasks Contents

Risk management Set up a Risk Management Plan to:

• for each step of the process, identify the type andlevel of risks that could be encountered;

• define measures to prevent consequences of risks;• inform partners (contractors, the DG, other MSAs

and economic operators);

• etc.

This plan must conform to the common risk management plan established by the DG.Follow-up the implementation of preventingmeasures.

Update risk assessment according to the progress.

Support Define the support organisation.

Define support policy.

Accept agreements proposed by the DG.Supervise the activities of the help desk and of thetechnical and functional national support centres.



• Project Time Plan (initial and updates)

• contracts and Service Level Agreements with contractors

• acceptance procedures

• Deployment Strategy Plan

• risk management plan (initial and updates)• support policy

• results of audits

Required skills:

As for the European Commission, a Senior Project Manager and a DeputyProject Manager must be designated as soon as possible, both must beofficials.

Beside these two persons, and as much as necessary, other persons should

cover the following skills:

• planning and budgetary prevision;

• co-ordination and management of providers;

• technical assessment, in particular participation in the systemspecification phase;

• relationship with national professional organisations of economic

operators;

• risk management.

8.2.2. National quality assurance

The purpose of this activity is to set up the national quality policy and tocontrol that contractors conform to that policy.







• overall Project Management Plan

• overall Quality Plan

•

audit procedures• results of quality audits

Tasks Contents

Quality Plan Referring to the Project Management Plan and to theoverall Quality Management Plan, produce thenational quality Plan describing the common rules

and procedures to manage the project. If qualityassurance is grouped with the National Project Office,a unique Project Quality and Management Plan mayreplace both the Management Plan and the Quality

Plan.Each provider should produce its own quality planconforming to the national quality plan.

Quality assurance Supervise the implementation of the qualityprocedures by partners, in particular by providers.

Ensure that all actions defined in the Quality Plan areactually performed in due time, and that results areproperly registered.

Quality control Systematic control of deliveries made by theproviders.Record traceability.

Periodic quality audits.Publish results of audits.



• quality procedures

• quality records

• traceability records


• results of quality audits

Required skills:

Quality experts for plans and procedures, and quality controllers.

8.2.3. National security

Each MSA must define a security policy based on the EMCS Security Policyand on the mutual commitments taken by each Member State based onsecurity principles.



• audit procedures defined by the DG







Tasks Contents

Security policy Produce the national Security Policy, including:

• security requirements;• security objectives (the same as for the overall

security policy);

• security principles;

• lists of quality procedures;

• etc.Define the level of security and availability for each

part of the EMCS.Define security procedures, in particular backupproceduresDefine national contingency plan

Security control Specifically verify that the security commitments areproperly taken into account in all plans, specifications,procedures, etc. produced by each provider.Implement and control application of the securityprocedures.Verify that the providers have and apply procedures

to satisfy all the commitments they took.Validate backup procedures and test them inoperational configuration (to be done after application validation and regularly repeated)

Validate the contingency plan and test it in

operational configuration (to be done after application validation and regularly repeated)Report to the DG.


• National Security Policy

• procedures to apply the security policy

• contingency plan


• results of security audits

Required skills:

Security experts for plans and procedures, and security auditors for controls.

8.2.4. Specification, development and validation of applications

This activity groups all development activities that start from the commonspecification provided by the DG and end with the certification of thenational application by the Application Centre under the control of the

Central Project Office.

Member States Administrations may create Common User Interest Groups todevelop in common a part or the whole of the necessary applications.






A specific table in Appendix A summarises the specification and

development tasks to be made by each MSA, compared to the tasks to bemade by the EC.












The following tasks are given as typical tasks to be carried out for anydevelopment of application.

The DG and the MSAs are committed to implement all functionality of Group Iand of Group II; each MSA may choose to implement, or not, functionality ofGroup III, provided that this does not disturb other MSAs.

Type Tasks Contents

Specification Applicationfunctional

specification

Complements to the system functionalspecification, to support national

specificityMust absolutely conform to the systemfunctional specification

Applicationtechnical

specification

Complements to the system technicalspecification, to support nationalspecificity

Must absolutely conform to the systemtechnical specification

Specification of

testing tools

If necessary, develop or adapt the

testing tools necessary for thedevelopment and integration process.

Testing plans Produce integration and validation plansProduce integration and validation

scenarios

Deployment Specify the principles of validating each

end user interface (to be implementedby the deployment team)






Type Tasks Contents

Infrastructure Hardware andsoftwareplatform

Purchase the necessary hardwareequipment, both in the computingcentres and in support centres.

Purchase the necessary basic software.Purchase or upgrade user work stations.A firewall interface should be provided toprotect the computing Centre against

unauthorised access.

Installation Install and check the computers andtheir connections.

Developmentof application

Design Produce detailed design of the nationalEMCS applicationThat task should be undertakenseparately and successively for each

Group of functionalityCoding and

unit testing

Produce software modules and test them

with unit testing tools

Integration Progressively integrate developedmodules according to the integrationplan

Applicationacceptance

Technicalacceptance

Validate the integrated application usingthe local testing tools

Functionalacceptance

Validate the application using the localvalidation tools (STTA-like) provided by

the DG (or using an equivalent testingequipment).

Applicationcertification

Submit the validated application tocertification by the Application Centre,using the TTA-like tool.

Output documentation and products:

• Application Functional Specification

• Application Technical Specification

• validation principles for connection of end users

• testing and validation tools, including for economic operators

• operational computing platform• certified application software

Contractual approach and constraints:

The various groups of tasks described above may be contracted to severalcontractors, however, it is rather recommended to entrust all of them to aunique provider.

Required skills:

Classical development team(s).







From the information policy defined by the DG and from the basic material itprovides, each MSA produces and disseminates their own publications and

communication actions.


• Information policy

• publications

• basic material

• web information pages accessible on the Information Centre


Tasks Contents

Information policy Adapt common information policy to specifics of theMember State.Produce information plan

Follow-up information actionsConsolidate and assess user feedback.

Publications Translate and adapt, if necessary, publicationspublished by the DG.Create and disseminate national specific publicationsImplement if necessary a web information site to

disseminate information.

Questions and

answers

Maintain Frequently Asked Questions (FAQ)

documents concerning national specific points.Collect questions either asked by users or transmittedby the central Information programme.

As relevant, forward questions to the competentauthority, in particular to the central Informationprogramme.Make answers to questions and send back to therequestor.

Select general interest questions and add to the FAQ,possibly submit to the central information programme.

Meetings and

workshops

Organise meetings and workshops with the national

organisations concerned by the EMCS.Collect user feedback.

Disseminate results of meeting and workshops, possiblythrough the web information site of the MSA or through the web site of the Information Centre (iffound useful by the central Information programme)

System evolution Collect requirements about potential evolution, inparticular from professional organisations of economic

operators.Propose evolution of the system.

Output products:

• Information Plan






• publications

• exchanged questions and answers

• published national know-how

• web Information pages

• results of meetings and workshops

Required skills:

Communication experts, excise experts, and technical experts.

8.2.6. Training programme

From the general training policy, from the contents orientations and basic

material provided by the DG, each MSA produces the training courses andthe self-training tools.


• Training Policy

• training modules

• basic training tools and material for courses

• self-training material


Tasks Contents

Training policy Define profiles and contents of courses.

Define training modules.Control localisation of courses.Assess and acquire required resources.

Training tools Produce training support.Produce training guides.Train trainers.Develop self-training materials for instance accessible

through a web site.

Training Register trainees.Courses for officials.Courses for support agents.

Courses for economic operators.Supervision Supervise training centres.

Consolidate feedback on courses.

Output products:

• Courses

• Self-training tools

• Assessment of courses

Contractual approach

Outsourcing of the training is recommended for economic operators.






Training of officials may be made internally, but contractors could help in the

preparation of courses.

Required skills:

Training experts, excise experts, developers for the supports, and trainers.

8.2.7. Support programme

The aim of the support programme is to provide all partners with help in their daily work to solve appearing issues. Each user should have a unique accesspoint to the support structure, this means that whatever the problem is, heshould have a unique phone number, or e-mail address, to submit the

question. That access point is called help desk. It is then the responsibility ofthe agent of the help desk, either to pre-analyse an easy point and giveimmediately the answer, or submit the question to another support team

(back office), functional or technical persons of the MSA, or the CCN/CSITechnical Centre, etc.

The various support centres, including the help desks, should be provided withthe sufficient tools to enquire on the submitted cases and to solve pendingproblems; these tools should provide the support agents with a wide ability to

consult the various data bases and to monitor the functioning of applicationsand telecommunications, and, reserved to a few number of highly skilledpersons, to take physical actions such as stopping/restarting a component,clearing off a blocked case, etc.

Input products provided by the DG:

• Support Policy

• procedures of collaboration

• support information (know-how, solutions found to fix an incident, etc.)disseminated in particular through the web site of the Information Centre.


Tasks Contents

Organisation Define the organisation of support.

Define support policy.Define the training necessary for support agents.Organise functional and technical support centres.

Organise help desk.

Support tools Select or develop, and install the necessary supporttools.






Tasks Contents

Help desk As a part of the support, receive requests andquestions from the end users (both officials andeconomic operators)

Pre-analyse the request and, if the answer is known,give it back immediatelyElse, register the request, call the convenient supportcentre and follow-up the case until it is satisfactorily

solvedGuarantee full availability of the access to support

Support On request transmitted by a help desk, or fromanother support centre, enquire on outstandingproblemsFind out solutions and take necessary actions

Report incidents and their solution to supervisors

Supervision Collect know-how, solution to fix incidents, etc. andconsolidate.As necessary, forward feedback information to theApplication Centre

Report activity to the Central Project Office

Output products:

• support collaboration procedures

• support management procedure (follow-up of calls)

• day-to-day fixing of incidents

• collection of know-how• technical solution to fix incidents

• operational help desk to receive questions and complaints

• operational support centre(s) to solve outstanding problems

• feed back of know-how to the Application Centre

• report to the Central Project Office (as responsible for the central supportactivity).

Contractual approach

Outsourcing of the help desk – at least for economic operators – is highly

recommended.

Functional and support centres may be either contracted or made by theown personnel of the MSA.

The help desk must be permanently available. Contrary, back office supportcentres do not need to be open 24/24 hours, provided that urgent operationsmay be performed. However, the MSAs should evaluate the cost of fullavailability of these support centres, either based on internal resources, or by

requesting a quotation in the tenders.






Required skills:

Help desk agents and help desk supervisors, excise operational experts for

functional advising, technical experts and administrators.

8.2.8. Deployment


• Deployment Strategy Plan

• validation principles for end users


Tasks Contents

Planning Establish planning of deployment for each group offunctionality; for Group II, take into account the

common Deployment Strategy Plan set-up by the DG.Define acceptance procedures and validationscenarios for the various types of connection.

Installation Install the necessary hardware and software.Create testing environment of the connections.Install the application in the convenient offices of the

MSA.Disseminate the software developed for theeconomic operators (if any).

Co-ordinate with each official and with eacheconomic operator to validate the connection:

• appoint user name;

• check connection;

• run validation scenarios;

• activate connection.

Start into operation.

Output products:

• validation procedures for each type of connection

•

user name appointed to each user, either • EMCS available at each operator's and in all concerned offices of all

MSAs.

8.3. Economic operators

8.3.1. Participation in the system specification and in the applicationspecification

To ensure that the system actually meets their requirements, the professionalorganisations of economic operators, in particular European Federations,must participate in the acceptance of the system specification. This consists inreading proposed drafts of the specification documents and in giving back their remarks and comments, exactly in the same way as MSAs have to do.






To do so, each European Federation should delegate one person or a groupof persons to participate in the review process of the system specification;these persons should be nominally designated at the beginning of the

specification phase, and directly discuss with the Central Project Office for the organisation of the reviews.

MSAs are invited to consider whether they want to adopt the sameorganisation at national level.

8.3.2. Development

The economic operators which plan to use the standard interface offered by

the MSA do not have to develop anything; the following tasks concern onlythe companies which want to develop their own application.

Input products:

• system specification (provided by the DG);

• application specification, in particular design of the interfaces (providedby the MSA);

• testing and validation tools for economic operators (provided by the

MSA).


select the convenient way of connection offered by the competent MSA,

most likely EDIFACT messages exchanged through e-mail; acquire or adapt the existing Information System to create and exploit the

EDIFACT messages;

validate the functions created against the tools provided by the MSA(through the communication mean selected).

Output products:

• user documentation;

• validated EMCS application of the economic operator, ready for deployment.


The professional organisations, both European and national, must participate

in the information programme by disseminating the information supportprovided by European Commission and by the MSAs, by giving their ownunderstanding of the system, and by summarising and giving back the feelingof their members.

The economic operators must use the various tools of the informationprogramme to get all necessary information and to give back their remarksand comments.

In particular, both professional organisations and economic operators shouldparticipate in the various workshops organised by the European and national






Administrations. Workshops are considered as a very efficient way to

exchange opinions, views and understanding and to imagine creativesolutions.

8.3.4. Training programmeThe professional organisations, both European and national, must:

collect the training requirements of their members;

assess the proposed training programmes to ensure that they meet therequirements;

disseminate training programmes and issue recommendations to their members;

help their members in their relationship with the MSAs;

possibly, collect and synthesise comments back from the training.

Each economic operator must:

examine the proposed training and determine which solution is the mostadequate for each profile;

commit to a minimum training of each person involved in the EMCS;

guarantee that the convenient courses are attended by the designated

persons, or actually used if self-training is chosen.

8.3.5. Deployment

Possibly after validation of their software, economic operators must:

request and receive a user name from the competent MSA;

using that user name, validate their connection according to the

procedures defined by the MSA, even when using a full standard solution.






9. CONCLUSION

The Feasibility Study was led with the positive co-operation of all partners met; it isobvious that there is a real need for a better management of the excise

movements under excise duty suspension arrangements.

For the economic operators, the expectation is both to fight against unfair competition by enforcing better and more systematic controls of theaccompanying document and of the goods, and to obtain a quicker return of the

discharge of the movement guarantees; they expect that it would convince MSAsto be less demanding on the requested level of guarantee.

Member States Administrations will have a better view of ongoing movements by

having the relevant information significantly earlier than presently, and through the- highly recommended - semi-automatic risk assessment exercised on all electronic

AADs submitted. This should allow them better targeting their controls and limitingthe sources of fraud, in particular frauds on falsified documents (false stamps, false

signatures, re-use of the same document for several movements...). Moreover, theywill have credible basic data to analyse the trade and possibly anticipate itsevolution.

The European Commission will be able to collect common information in order toget a better co-ordination of Member States; the structure set up for theco-operation in the computerisation project should result in closer habits ofcommon work among MSAs. In addition, the proposed formal relationship witheconomic operators should remain after operational start up of the EMCS.

So, expectations of all profiles of potential partners are very high and they shouldnot be disappointed. The total cost of the proposed solution, including allaccompanying measures, which are more than the half of the total amount, fits to

the extent of the stakes. The development and deployment of the EMCS may bethe opportunity to re-organise all relationship of partners in the domain of exciseduties.

For all these reasons, and although the overall cost of the proposed system isevaluated high, the deployment of a new computerised Excise Movement andControl System is highly recommended, and all measures should be taken to

implement it in a time schedule as short as possible.





© Alcatel TITN Answare 2000 3AT 05006 AAAA DTZZA 02 A-1

APPENDIX A – COMMON ELEMENTS OF SPECIFICATION

A.1. Formalism of the presentation

The following paragraphs describe the UML subset used to present the proposedfunctionality of the EMCS; they refer to the paragraphs with the same name inAppendices B to E.

A.1.a Structure of data

These paragraphs contain a sub-model of data concerning a part ofapplication, using a simplified UML class diagram.

Each class is represented by a rectangle containing only its name (attributes

are described in the Data records paragraph).

A solid line (the path) connecting the class symbols denotes an associationbetween classes. Reflexive associations are possible. An optional name

(usually a verb) may be given to an association; it is then shown next to thepath.

The end of an association where it connects to a class is called an association

role. The properties attached to a role may be optionally specified; they are:

role name a text string near the end of the path attached to theconsidered class;

multiplicity a text string near the end of the path attached to theconsidered class, expressing the possible number of objects ofthe considered class that may be connected through theassociation to one object of the other class.

Class 1 Class 2Role 1 Role 2

Association.. ..

More precisely, the syntax used for multiplicity is:

0..* or * denoting that there may be zero, one or several associations

(default);1..* denoting that there may be one or several associations;0..1 denoting that there may be zero or one association;1 denoting that there is always one and only one association.

Constraints may be put on associations, in particular the or-constraint thatindicates a situation in which only one of several potential associations maybe simultaneously instantiated for one single object. This is shown as a dashedline connecting two or more associations, all of which must have a class in

common, with the constraint string ''or'' labelling the dashed line:






Class 1

Class 2

Class 3

or

A particular association, called aggregation, expresses that a class may beconsidered as a subclass of another class rather than an autonomous class; it

is denoted by a diamond attached to the path at the end next to the mainclass. It implies a multiplicity of 1 at that end (there is one and only oneaggregation association for each object of the sub-class) and usually adefault multiplicity (zero to many) at the other end.

Class Sub-class

A.1.b Data records

These paragraphs contain the detailed description of the object classes

defined in the preceding paragraph; the attributes (fields) are describedreferring to the following data element definitions; no operations have beenattached to the classes described.

Data element Definition

Code A short string of characters

String A longer string of characters (maximum length to be defined inspecification phase depending on each case)

Text A series of pairs (identity of language, text)Texts with a minimum formatting (in particular separation ofparagraphs)

Address A group made of several strings:- one to four lines;- a postal code;- name of a city.The country is implied by the context; else it must be addedseparately.

Economic

operator

A group made of several fields:

- excise number (from register of operators, mandatory ifregistered operator);

- VAT number (optional if excise number is given; mandatory ifnon-registered operator, must exist in VIES if given)

- name;- acronym;- an address, as above.The country is implied by the context; else it must be added

separately.

Captions A series of Strings describing the same object in all Europeanlanguages

Number A numeric value that it is possible to use in calculations (number

of decimal positions according to each case)Other numbers would be better stored under the form of a string

Date and time May be reduced to a simple date if time is not significant.






It should be possible to write names, addresses and texts using all Europeancharacter sets including Eastern European countries. Usage of Unicode isrecommended, subject to compatibility with the EDI tools of the various

partners.

Most generally, to support archiving of historical data, permanent datarecords have one begin date and one end date of validity, sometimescompleted by a status. At a given time, only one version of each logical

information is valid, while other ones are marked either as "cancelled" or as"replaced". The valid record may have a blank end date, that denotes thatend of validity is not known yet. In other cases, the end date should be later than the begin date (possibly except in cancelled records).

Cancelled records are previous erroneous records, that are kept because

they could have been used at some time during the processing, even if theywere actually erroneous at that time.

Replaced records are previous records that have been updated to give anew applicable record.

As keeping all older records in the operational tables could result in bad

performances, it is recommended that the development teams consider storing cancelled and replaced records in physically separate tables. Theway of archiving older records is left to decisions of each MSA, provided thathistory of data is kept available for a period of at least three years (national

legislation may require more).

A.1.c Processing

These paragraphs contain a sub-model of processing concerning the samepart of application as the preceding paragraphs, using a simplified UMLactivity diagram.

Each actor is denoted by a column (swimlane) where the activitiesconcerning that actor are summarised; the vertical axis represents the time,from the beginning (higher part) to the end (lower part).

Several drawings denote either a human action (display screen), or a storage

of data (disk symbol), or an automatic processing (rectangle) or a simplestore-and-forward (black circle); a rhomboid denotes an alternative withlabelled outputs. Simple arrows accompanied by the name of thecorresponding message denote message exchanges.






Actor 1

Store and

process

Message 1Input

Message 2

Store

Message 3

Message 2

Actor 2 Actor 3 Actor 4

Forward

StoreConsult

Message 4

Message 1

Message 1

???

Input

Yes

No

A.1.d Messages

These paragraphs contain a description of the contents of the messages usedin the concerned part of application.

The messages are described either as reference to data records or bydescribing the fields of each message, using the same types of data elementsas for data records. These descriptions do not contain the necessary commonfields such as identity of sender and of recipient (user names), correlationidentifiers, etc. that could prove necessary at detailed specification time.

A.2. Consultation of historical data

To cover all consultations involving history of data, a general set of fields of thequery message is proposed, composed of a date plus an indicator.

According to the value of the date and of the indicator, the following data may

be requested:

• presently applicable data;

• history of data since the given date, excluding archived data;

• history of data since the given date, including archived data;

• complete history of data, excluding archived data;

• complete history of data, including archived data.

Including archived data gives more information but may require a humanoperation and therefore a longer time of response. Contrary, in particular whenthe queried MSA has off-line archives, excluding archived data gives a quicker

answer.






This applies to all consultations of registered information including history,

namely:

• register of operators;

• guarantees;• duty rates;

• movements (electronic AADs).

A.3. Exception and error processing

A.3.a Principles

The description of business processes in Appendices B to E does not detail thegeneral processing of errors and exceptions.

To support errors, each application module should be able to create, send,receive and process error messages containing:

• a correlation identity of the message which caused the error;

• one main return code completed by complementary return codes toidentify the faulty function, the identified cause of error, etc.

The cause of error or exception should be identified as much precisely as

possible; for instance, if the value of a field is incorrect, the diagnostic mustidentify the exact field of the message and the exact cause of error, for instance "code does not exist" versus "this code cannot be given in the

context", etc. A caption in each European language should be associatedwith each error code.

In addition to the common codes defined in the system specification, eachnational application may have complementary local codes. It can be useful

that such national codes be carried by the error messages transferredbetween the Information Systems of the Member States, to be used bysupport agents when enquiring on particular cases. These local codes do notneed to be interpreted in all languages, the national support agents being

the only ones able to exploit them.

A.3.b Prior verificationsTo reduce network overload and to improve performances, it can beconsidered performing formal verifications as close as possible to the sourceof the message, i.e. by the application module that prepares the message,provided that the necessary information is locally available. This means, for instance, verifying that a code (e.g. an excise number) conforms to a

construction rule before sending the message through the CCN network.

This is subject to the following conditions:

• each Member State Administration must precisely describe their rules for

building the considered values and communicate them to other MSAs;• if the rule has to change after it has been published and implemented, a

mandatory change process must be carefully followed, including:






1. publication of the new rule by the considered Member StateAdministration; that rule must be fully compliant with the older one, i.e.older codes must be accepted by the new rule;

2. development of the new verification algorithm by each other Member State Administration;

3. full validation of the new verification module developed by eachother Member State against a set of codes provided by the updatingMember State; as certification authority of the whole EMCS, the

Application Centre is in charge of that validation;4. installation of the updated application onto the nodes of all MSAs;5. after the new application is operational on all nodes, the updating

MSA may begin appointing codes according to the new rule.

Any deviation to the change process may have important consequences. In

particular, if the updating Member State Administration starts appointing newcodes before a full green light is given by all other MSAs, a valid number canbe unduly refused by the system, resulting in complaints from economic

operators which could claim that it is an obstacle to free trade.

Therefore, each proposed prior verification should be carefully considered,balancing the expected savings in terms of network traffic (reminding that

CCN/CSI traffic has a comprehensive fixed cost that changes only if upgradeof equipment becomes necessary), against potential malfunctioning of thesystem, possibly involving the responsibility of the MSAs.

This does not relieve the receiving application module from performing thesame verifications, plus possible other ones as relevant.

A.3.c Message

A general-purpose format is proposed:

Message Description and contents From To

M_GEN_ERR General error message Any computer Any computer

Identity of place of error

Correlation identity of the original message (if applicable)

Main return code

Zero, one or several complementary common codes (according tothe case)

Zero, one or several complementary national codes (according tothe case)

Comments

Date and time of the issuing computer

For correlation with the originating message, use of the CCN/CSI correlationmeans may be considered, either the synchronous transaction handle, or theCorrelId field of asynchronous queuing messages, completed by

identification of the issuing place.






A.3.d Error codes

The possible errors and the corresponding return codes must be defined in thesystem specification.

First list of proposed return codes:

• remote site unavailable;

• function unavailable;

• incorrect query data (with field identifier and precise description of theerror such as unknown code, invalid identity, etc.);

• data not found;

• user not allowed to call the function;

• user not allowed to access the data;

• time-out expired;

• (to be completed in the detailed system specification).

A.4. Recommendations on the use of CCN/CSI

A.4.a Interaction modes

CCN/CSI offers two major interaction modes, namely:

• synchronous call of distant services, with two variants: either blocking call(call) or non-blocking call (acall/getrply) where the calling process mayperform other tasks before coming back to get the reply;

• asynchronous queuing of messages, where a process sends messages

without waiting for the answer, and another process gets and processesincoming messages.

Most generally, synchronous interactions require more computing resourcesthan asynchronous ones and therefore they should be avoided; the standardtime of response of message queuing is acceptable enough to allow using itin the normal processing of workflow. Synchronous interactions should be

reserved to direct consultations where a person is waiting for the answer.

A.4.b User profiles

CCN/CSI provides the users with an access control mechanism composed oftwo parts:

• a list of user profiles, centrally managed, that are associated with a list ofsynchronous services that the users can call and message queues that the

users can read and/or write;

• user identities, each of them indicating either a person or a process; eachuser identity is registered by the MSA into one or several user profiles.

CCN user profiles must be used each time that a user identity (person or process) s allowed to directly access a CCN service or a message queue.

In the case of the EMCS, this amounts to the following:






• each EMCS application of a Member State has its own user identity that is

used when opening the CSI link with the CCN gateway; there should be aunique user profile where all EMCS applications of all MSAs are registered;that profile should be allowed to access all callable services and message

queues participating in the EMCS workflow;• some officials may receive a CCN user identity and be allowed to directly

access part or all cross-consultation transactions, provided that theviewing application is running on behalf of that identity; one or severaluser profiles would allow to control access to these consultations; an

alternative may be to have a second application with a separate user identity belonging to another user profile, specialised in callingcross-consultation transactions;

• AFIS users must follow the AFIS identification rules for CCN/CSI; as far as

possible, if the same persons need to access cross-consultation, the sameuser identity should be used with different user profiles;

• the Application Centre should have one or several particular user identities and a dedicated user profile for monitoring purpose;

• in addition, the Application Centre, and possibly support agents needing

to directly consult the Information Systems of other Member States shouldbe registered in particular user profiles.

A.5. Allocation of specification and development tasks

The following tables give the leading responsibility of each partner in the

specification and development of the various parts of the system; note that, withvery few exceptions, when some part of application may be developed by aneconomic operator, there must always be a variant developed by the MSA.

A.5.a Common modules

Functional unit System

specification

Application

specification

Develop-me

nt

Identification and authentication of users

Officials No MSA MSA

Economic operators No MSA / ECOP MSA / ECOP

Archiving of history data

Archiving of registration and

guarantee data

No MSA MSA

Archiving of duty rates No MSA MSA

Archiving of movement data No MSA MSA

Consultation / retrieval of archived

registration and guarantee data

No MSA MSA

Consultation / retrieval of archivedduty rates

No MSA MSA

Consultation / retrieval of archived

movement data

No MSA MSA

Storage and use of certificates ofregistration (optional)

No No ECOP

Error processingDefinition of data TAXUD

Processing Included in each processing






A.5.b Group I


specification

Application

specification

Develop-me

nt

Lists of reference

Definition of data TAXUD

Management of lists of codes TAXUD TAXUD TAXUD

Management of list of MSA offices TAXUD MSA / TAXUD MSA / TAXUD

Management of structure of excisegoods

TAXUD TAXUD TAXUD

Management of the thesaurus ofterms

TAXUD TAXUD TAXUD

Collection and preparation of data TAXUD TAXUD TAXUD

Dissemination to MSAs andinstallation

TAXUD MSA MSA

Dissemination to economicoperators

TAXUD TAXUD TAXUD

Installation at economic operator's ECOP ECOP ECOP

MSA offices

Local consultation by MSA No MSA MSA

Local consultation by economicoperator

No ECOP ECOP

Registered operators


Management of registered

operators (local)

No MSA MSA

Consultation of registration data(client and server)

TAXUD MSA MSA

Retrieval of registered operators

(client and server)

TAXUD MSA MSA

Consultation by economicoperators (optional)

No MSA MSA

Guarantees


Management of guarantee data(local)

No MSA MSA

Consultation of guarantee data(client and server)

TAXUD MSA MSA

Duty rates


Management of duty rates (local) No MSA MSA

Consultation of duty rates (clientand server)

TAXUD MSA MSA

VAT information

Definition of data (VIES)

Management of data (VIES) (VIES) (VIES)

Consultation of data (clientinterface)

TAXUD MSA MSA







specification

Application

specification

Develop-me

nt

Reports

Reports defined by the MSA No MSA MSA

A.5.c Group II


specification

Application

specification

Develop-me

nt

Certificates of guarantee


Registration of certificate ofguarantee (local)

No MSA MSA

Consultation of certificate ofguarantee (client and server)

TAXUD MSA MSA

Submission and registration of electronic AADDefinition of data TAXUD

Submission of proposed AAD TAXUD MSA / ECOP MSA / ECOP

Validation of AAD TAXUD MSA MSA

Forwarding of acceptance / refusalexchanges

TAXUD MSA MSA

Acceptance by the consignee TAXUD MSA / ECOP MSA / ECOP

Registration and dissemination ofAAD

TAXUD MSA MSA

Forwarding of registered AAD TAXUD MSA MSA

Receipt of registered AAD (or oferror messages) TAXUD MSA MSA / ECOP

Printing of AAD TAXUD MSA / ECOP MSA / ECOP

Warning from the consignee

Issuing of warning TAXUD MSA / ECOP MSA / ECOP

Forwarding of warning TAXUD MSA MSA

Receipt and registration of warning TAXUD MSA / ECOP MSA / ECOP

Update during the movement (specific part)

Submission of proposed change TAXUD MSA / ECOP MSA / ECOP

Validation of change TAXUD MSA MSA

Registration and dissemination ofupdate

TAXUD MSA MSA

Forwarding of updated AAD TAXUD MSA MSA

Receipt of update (or of error

messages)

TAXUD MSA / ECOP MSA / ECOP

Receipt of new version of the AAD TAXUD MSA / ECOP MSA / ECOP







specification

Application

specification

Develop-me

nt

Receipt and discharge of AAD


Issuing of statement of arrival TAXUD MSA / ECOP MSA / ECOPProcessing and forwarding ofstatement of arrival

TAXUD MSA MSA

Receipt of statement of arrival and

processing


Issuing of cancellation of receipt TAXUD MSA / ECOP MSA / ECOP

Processing and forwarding ofcancellation of receipt

TAXUD MSA MSA

Receipt of cancellation of receipt

and processing


Issuing of report of receipt TAXUD MSA / ECOP MSA / ECOPRegistration and forwarding ofreport of receipt

TAXUD MSA MSA

Receipt of report of receipt andprocessing


Export of goods

Export procedure and forwarding of

export message

TAXUD MSA MSA

Receipt and processing of exportmessage


Discharge procedure and

forwarding of discharge message

TAXUD MSA MSA

Receipt and processing ofdischarge message


Claims on losses


Issuing of claim TAXUD MSA MSA

Forwarding of claim TAXUD MSA MSA

Receipt of claim TAXUD MSA / ECOP MSA / ECOP

Issuing of contest TAXUD MSA / ECOP MSA / ECOP

Forwarding of contest TAXUD MSA MSA

Receipt of contest TAXUD MSA MSAConsultation and retrieval of movement data

Consultation of movement data(client and server)

TAXUD MSA MSA

Retrieval of movement data(clientand server)

TAXUD MSA MSA

Consultation by economic

operators (optional)

No MSA MSA

Automatic recalls

Recall for acceptance TAXUD MSA MSA

Recall for receipt TAXUD MSA MSA

Issue reply to recall TAXUD MSA / ECOP MSA / ECOP







specification

Application

specification

Develop-me

nt

Reports

Reports defined by the MSA No MSA MSA

A.5.d Group III


specification

Application

specification

Develop-me

nt

Road controls


Recording and forwarding of reportof control

TAXUD MSA MSA

Receipt and registration of report ofcontrol

TAXUD MSA MSA

Risk assessmentDefinition of data No MSA

Recording of criteria No MSA MSA

Risk assessment No MSA MSA

Management of alerts

Issuing and assessment of alert No MSA MSA

Definition and creation of messages (thesaurus of terms and message builder)

Forwarding and receipt ofmessages

(AFIS)

Processing of messages (message viewer)

Automatic recallsIssuing and assessment of recall No MSA MSA



(AFIS)


Collection of statistics

Definition of statistics TAXUD

Extraction of operating statistics

and national consolidation

TAXUD TAXUD / MSA TAXUD / MSA

Extraction of application statisticsand national consolidation

No MSA MSA

Extraction of business statistics andnational consolidation


Movement verification and Mutual Assistance



(AFIS)







A.5.e Utilities


specification

Application

specification

Develop-me

nt

Management of users

Definition of data No MSA

Management of user identities No MSA MSA

Management of access rights No MSA MSA

Management of user credentials, inparticular update of passwords

No MSA / ECOP MSA / ECOP

Monitoring of connections

Monitoring of availability TAXUD TAXUD / MSA TAXUD /MSA

Monitoring of synchronousresponses

TAXUD TAXUD / MSA TAXUD /MSA

Monitoring of asynchronous

responses


Consolidation of statistics

Forwarding of statistics TAXUD MSA MSA

Receipt and consolidation TAXUD TAXUD TAXUD

Reporting TAXUD TAXUD TAXUD

Consultation by support agents

Consultation of application data TAXUD / MSA (use standard transactions)

Consultation of CCN/CSIinformation

TAXUD (through CCN/CSI TC)

Consultation of technical data MSA (through system tools)

User interface for support agents TAXUD / MSAPatching by support agents

Update of technical configurationdata

TAXUD / MSA

Update of application data MSA (through system tools)

Exchange of free format messages

Definition of messages TAXUD (thesaurus of terms)

Message builder TAXUD

Message viewer TAXUD





© Alcatel TITN Answare 2000 3AT 05006 AAAA DTZZA 02 B-1

APPENDIX B - SPECIFICATION OF GROUP I

B.1. Management and dissemination of lists of reference

B.1.a Description

There are four categories of reference data:

• the lists of codes, i.e. the values that may be used in some particular fields ofthe messages and records of the system; as far as possible, that list should beshared with the NCTS;

• the list of MSA offices involved in the EMCS; as far as possible, that list shouldbe shared with the NCTS;

• the structure of excise products, organised in categories and sub-categories,

to be completed by each Member State Administration with the ratesapplicable in the country;

• the thesaurus of terms, made of a series of terms that can be used in

Movement Verification and Mutual Assistance messages; by definition, theitems of the lists of codes are an integral part of the thesaurus.

Lists of reference should be periodically extracted and disseminated to all

concerned partners, namely:

• all Member States Administrations;

• functional support centres;

• all economic operators which use them in their own applications.

B.1.b Structure of data

List of

codes

Code

item

MSA

office

Categoryof goods

Sub-categoryof goods

Product

or

Term of

thesaurus

*

*

* *






B.1.c Data records

Record / Field Description /type Constraints

List of codes Each list of codes

Identity of list Code Unique

Description of list Captions

Comments Text

Code item Each item of lists of codes

Identity of list Code From list of lists

Value of code Code Unique inside the list

Description of value Captions

MSA office Each office involved in the EMCS

Member State MS of the office From list of codes

Office number String Unique inside the Member State

Type of office Series of codes From list of codes

A given office may haveseveral types at the sametime

Name of office String

Address of office Address

Telephone number String

Fax number String

e-mail address String

Category of goods Each category of goods of the structure of excise products

Category Code Unique (and not used by asub-category)

Name of category CaptionsSub-category of

goods

Each sub-category of goods of the structure of excise

products

Sub-category Code Unique (and not used by acategory)

Category Code From the list of categories

Name ofsub-category

Captions

Product Each excise product

Product code Code Unique

Category or

sub-category

Code From the list of categories or

of sub-categories

Product name Captions

Unit Captions

Comments Text







Term of thesaurus Item of information to be used in the Movement Verification

or Mutual Assistance messages

Term code Code Unique

Description of term CaptionsType of data String Possible values:

String, encoded, date,time, date and time, textNumeric values are storedas simple strings

Code of list Code If encoded data: code ofthe list of codes

Comments Text

Notes:

• it could be considered giving a multi-level tree structure to categories andsub-categories of goods;

• for ease of explanation, categories and sub-categories of goods arepresented here separately; however, it could be found useful to

implement a unique object to group them;

• the proposed structure of excise products does not provide sub-ratecodes to support reduced rates: in such a case (for instance when thereare reduced rates according to the size of a producer, etc.) there should

be separate product codes for each case.

B.1.d Initial lists of codes

There is the list of lists of codes that may be extracted from the presentdefinition of data; the list of lists should be more precisely defined during thesystem specification.

There are three categories of lists of codes:

the first category corresponds to a precise processing in the system;neither the list of lists nor the contents can be changed unless a newrelease of the application, including functional changes, is deployed;

the second category corresponds to indications provided in the messages

but not specifically used for processing: the list of lists cannot change butthe contents can;

the third category is actually a part of the thesaurus of terms; both the list

of lists and the contents may change at any time.

List of codes Description

Language ISO code of the language.

Member State ISO code of the MS; the code "EU" should be added torepresent the European Union

Type of MSA office TAXUD, OLAF, registration office, Excise office, investigationoffice, guarantee office, Excise liaison office, customs office,

other as necessary







Type of calculation Identity of one algorithm to calculate excise duties. Thetypes presently identified are:• rate per quantity;•

rate per quantity and per degree Plato;• rate per quantity and per alcoholic degree;• rate per hectolitre of pure alcohol;• percentage of the value of goods;• combination of a rate per quantity and a percentage.

Type of guarantee Exemption, bank guarantee, deposit, other as necessary

Type ofauthorisation(type of operator)

Authorised warehouse keeper, tax warehouse, registeredtrader, tax representative

Provider of

guarantee

Consignor, consignee, other as necessary

Type of owner of

goods

Consignor, consignee, explicitly given

Export indication "export" or "under customs procedure"

Type of transport air, sea, road, train, pipeline, other as necessary

Transport unit Vehicle, container, other as necessary

Status of consigneesub-record

active, replaced, cancelled

Status of transporter sub-record


Status of transportdetails sub-record


Status of routedetails sub-record


Status of owner ofgoods sub-record


Status of AAD bodyrecord


Weight unit kilograms, tons, other as necessary

Kind of packages package, pallet, other as necessary

Wine growing zone A, B, CIa, CIb, etc. see Commission Regulation (EEC) 2238/93

Wine manipulation Number. see Commission Regulation (EEC) 2238/93

Reason of refusal ofsubmission or of

change of AAD

refused by consignee, invalid consignor information, invalidconsignee information, non-authorised category of goods,

more detailed as possible

Reason of warningfrom the consignee

consignment not expected, wrong description, other asnecessary

Type of change ofAAD

consignee, transporters, transport details, route details,owner of goods

Status of receipt ongoing, cancelled, completed

Result of receipt satisfactory, losses ascertained, other as necessary

Reason for cancellation ofreceipt

goods not conform to description, other as necessary

Type of claim Irregularity, shortage, other as necessary

Reason for contesting claim

Contest irregularity, shortage happened in another Member State, other as necessary

Reason for recalling Acceptance requested, waiting for report of receipt, other as necessary







Return code torecall

Goods not yet arrived, other as necessary

Type of control Document checking, physical checking, other as necessary

Conclusion ofcontrol Positive, negative (several reasons), other as necessary

Status of certificate

of guarantee

Active, discharged, cancelled

Type of AADconsultation

History of consignees, history of transporters, history oftransport details, history of route details, history of owner ofgoods, history of splitting

Type of MovementVerification or Mutual Assistancemessage

Spontaneous message, request, acknowledgement, reply,reminder, other as necessary

Action requested in

MovementVerification or Mutual Assistance

acknowledgement, reply, physical checking, other as

necessary

Status of availability Satisfactory, unavailable, backup mode, other as necessary

Requestedmonitoring function

to be defined in system specification

Type of action instatistics

Consultation of register, consultation of guarantees,consultation of duty rates, creation of AAD, update of AAD,splitting of AAD, statement of arrival, report of receipt, etc.

B.1.e Thesaurus of terms

The thesaurus of terms is intended to be used in building MovementVerification and Mutual Assistance messages, as well as general-purposeinformation messages. As these exchanges may contain potentially anyinformation, and plain text raises multilingual problems, the thesaurus of terms

aims at creating a repository of terms each of whom is associated withcaptions and formats adapted to each country and each language. Thisallows a user to build a message in his own language, and another one toread it in a different language.

As described above, each item of the thesaurus is identified by a code and isassociated with:

a caption expressed in all languages to describe the item (for instance:

weight in kilograms, poids en kilos, Gewicht in Kilogramm, etc.);

the type of data that can be one of: string, date, time, date and time or text;

additional comments possibly expressed in several languages.

The lists of codes (of the three categories) are an integral part of the thesaurusof terms. More precisely, each list of codes is understood as one item of thethesaurus and the type of data is the list of possible values of the code.






B.1.f Processing

Collection and preparation of data

The DG updates reference data after consultation of the Excise Committee.Input of data is made from various sources of information that may includeelectronic exchanges, in particular when information comes from the MSAs;

these exchanges are considered outside the EMCS (however the MutualAssistance infrastructure could be used).

The lists of codes and the list of offices should be managed together with the

NCTS and, as necessary, extracted from the common NCTS/EMCS data base.Therefore, the question of where they will be managed still has to be solved(Application Centre of the EMCS or of the NCTS, inside the DG...).

The structure of excise products and the thesaurus of terms should bemanaged using specific tools operated either by the Application Centre or by the DG.

Wherever they are produced, the lists of reference are collected by theApplication Centre where they are formatted into downloadable sets of data(files of various formats).

TAXUD (or other Centre)

Application

Centre

Update lists of

reference

R_REF_LST

Transfer to

Application Centre

Update lists of

reference

Install on

Information Centre

R_REF_LST

Dissemination – common aspects

The lists of reference should be disseminated to Member StatesAdministrations and to registered economic operators. The proposed solution,at least at the beginning, is to put them at the disposal of the considered

partners for downloading from an Information Centre accessible through theInternet, under the form of files with several possible formats (EDIFACT, XML,csv, common data base or spreadsheet formats, etc.).

Therefore, coming from various origins, lists of reference are concentrated in

the Information Centre and, upon request of the DG, open to free accessthrough the Internet.






Preparation of downloadable sets of data is under the responsibility of TAXUD.

Dissemination to Member States Administrations

A particular procedure is necessary to co-ordinate downloading by all MSAsat the same time, but the ELO may keep the ability to reload the lists ifnecessary.

TAXUD (or

other Centre

InformationCentre

(intranet web)

IS of theMSA

ELO

M_ REF_UPD

Order downloading of

reference data

Activate new

lists of reference

M_ REF_ACK

M_REF_INF

Inform ELOs

M_REF_REQ

Return lists of

reference

Confirm

downloadingR_REF_LST

M_REF_REQ

Or der

installation of

reference data

Dissemination to economic operators

Economic operators should periodically consult the Information Centre tocheck whether they have to refresh the lists of reference.






Information CentreInternet web Economic

O erator

M_REF_REQ

R_REF_LST

Return lists of

reference

Request lists of

reference

B.1.g Messages


M_REF_INF Information : new set ofreference data(transmitted outside EMCS,for instance by telephone or e-mail)

TAXUD ELO

Type(s) of list(s) to installOne or several of:• lists of codes;• list of offices;• structure of excise products;• thesaurus of terms.

Date and time where the installation must be performed

R_REF_LST List of reference data TAXUDInformationCentreInformationCentre

InformationCentreIS of the MSAEconomicoperator

According to the case, a series of records from the types listed inparagraph B.1.c under Data records, namely:• lists of codes;•

list of offices;• structure of excise products;• thesaurus of terms.

When given, each series must be complete, i.e. that it is not possibleto transfer only a part of one series.

M_REF_REQ Request to downloadreference data

ELOIS of the MSA

Economicoperator

IS of the MSAInformation

CentreInformationCentre

Type(s) of requested lists

M_REF_ACK Confirmation: download

completed

IS of the MSA ELO







M_REF_UPD Command: activate new list

of reference

ELO IS of the MSA

Type(s) of requested lists

B.2. Consultation of MSA offices

Each MSA has a complete list of MSA offices and may consult it locally. That list isdownloaded from the intranet web site of the Information Centre as describedin the preceding paragraph.

Likewise, each economic operator has the ability to download the list of MSAoffices from the Internet web site of the Information Centre.

B.3. Management and consultation of registered operators

B.3.a Description

Each MSA defines its own way of maintaining the list of registered operators.

There are three possible levels of consultation: full consultation, limitedconsultation and restricted consultation; MSAs have access to the three levelsof cross-consultation; each MSA may open consultation of registers to

economic operators at one of these levels, depending on their ownlegislation and preferences. In addition, a general query is provided toretrieve an operator whose excise number is not known by the requestor.


Economic

operator

Tax

warehouse

representstax

representative

authorised

warehouse keeper

* *

*






B.3.c Data records


Registered operator Any registered economic operator involved in Excisemovements under suspension

Member State Code From list of codes

Excise authorisationnumber

String

Type of

authorisation

Code From list of codes (except

tax warehouse ifimplemented separately)

VAT number String

Name String

Acronym String

telephone number String

fax number String

e-mail address StringCategories andsub-categories ofgoods authorised

Series of codes From structure of exciseproducts

Excise number of

representedwarehouse keepers

Series of strings (possibly code

of the Member State plusexcise number)

From register of operators

(must be authorisedwarehouse keepers).The referencing recordmust be a taxrepresentative.

Competent Exciseoffice

Code From list of MSA offices

Competentregistration office


Competentguarantee office


Authorised to issuecertificates of originof wines

Yes or No Only if authorisedwarehouse keeper for wine

Office that allowedissuing certificates

String Only if authorised to issuecertificates of origin ofwines

Does not need to be aregistered MSA office

Login user name String

Begin of validity Date

End of validity Date







Tax warehouse


Excise authorisation

number

String Unique

Authorisedwarehouse keeper

String From list of registeredoperators (must be anauthorised warehousekeeper)

Name String

Acronym String

telephone number String

fax number String

e-mail address String

Categories and

sub-categories of

goods authorised

Series of codes From structure of excise

products

Competent Exciseoffice


Competentregistration office


Competentguarantee office


Login user name String



Notes:

• for ease of explanation, tax warehouses are presented here separatelyfrom other forms of registered operator; however, it could be found usefulto implement a unique object to group them;

• as history of registration data should be kept at least for three years, each

record has a begin date and an end date of validity; periods of validitycannot overlap;

• tax representatives of an authorised warehouse keeper receive an Excisenumber so that they can have a user name to connect to the system;

• for the Member States that do not distinguish warehouse keeper and

warehouse, there should be only warehouse keepers.

B.3.d Processing

Management of registered operators

Each MSA maintains separately its own register of excise economic operators.

There are four categories of registered operators (in the sense of theregistration tables):

• authorised warehouse keepers;• tax warehouses;

• registered traders;






• tax representatives of warehouse keepers.

Each of them receives a particular Excise number used to identify theoperator.

To support further investigations, history of registration data must be kept andaccessible during at least three years.

Before being activated, the data concerning a given economic operator

must be submitted to his agreement; that submission concerns only theinformation given by the economic operator (exact name and acronym,address, etc.) and may take the form of a certificate of registration(described below).

Each Member State Administration is free to organise electronic dialogues

with the economic operators for validation and update of registration data.

Consultation of registration data

There is a unique request to consult the register of operators, but, accordingto the type of the requested consultation, the consultation may return one ofthree types of records:

• full consultation: the data returned are the whole registration informationfor the queried operator;

• limited consultation: the data returned are the certificate of registration,

i.e. an abstract of the register showing only the data necessary to fill-in the"consignee" fields on a electronic AAD;

• restricted consultation: the data returned are just a list of the categories ofgoods that the queried operator is allowed to receive.

Request for an economico erator

M_REG_REQ Get data

R_REG_VAL

R_CER_REG

M_REG_REP

ApplyingMSA

Requested

MSA

Consultation of

registration data

In all cases, it can be found useful to perform a prior validation of complianceof the query data with the relevant construction rules before sending the

request.

The requestor may be either an automatic process such as the verification ofan AAD, or an end user in a MSA office.






The choice of request either the synchronous mode or the asynchronousmode may be systematically fixed by the MSA, or left to the initiative of theuser. But a MSA may choose not to implement a synchronous variant; in that

case, downgraded mode is systematically enforced (downgraded mode inthe sense of VIES).

If the request concerns historical data, it may happen, according to thesolution actually implemented by the requested MSA, that data are not

immediately available and that re-loading of support is necessary; in thatcase, and if the synchronous mode of request was used, downgraded modeis enforced.

Consultation of registers is open to cross-consultation by other MSAs at alllevels (restricted by the profile of each user).

Among the possible replies, the certificate of registration is worth a particular attention: MSAs are encouraged to open the limited consultation, which

produces that record, to each economic operator, restricted to his ownregistration data. So, he can have an exact electronic copy of his ownregistration data and communicate it to his partner operators (potentialconsignors) which in turn can re-use that information when preparing an AAD.

Retrieval of registered operators

That request aims at retrieving an economic operator whose Excise number is

not known by the applicant, but only some of his characteristics.

The user builds the request under the form of a query by example, by givingdata concerning one or several of the fields describing the registration details

of operators. In some fields, wildcard characters are possible.

The query returns a list of operators; if that list exceeds a given (andupdateable) number, an error may be returned and the requesting user has

to refine the query.

Query to retrieve economico erators

M_REG_SRC Get data

M_REG_LST

ApplyingMSA

Requested

MSA

Consultation of

retrieved list






To avoid possible abuse of usage for commercial exploration, that function

should be strictly reserved to Member States Administrations.

As the time of response may become long if the query is complex, it is

recommended to use only the asynchronous mode for that consultation.

If the request concerns historical data, it may happen, according to thesolution actually implemented by the requested MSA, that data are notimmediately available and that re-loading of support is necessary; in that

case, and if the synchronous mode of request was used, downgraded modeis enforced.

B.3.e Messages


M_REG_REQ Request: consultation of

operator

Applying MSA

Economicoperator

Requested MSA

Requested MSA

Applying Member State

Applying office

Requested Member State

Excise number of queried operator

Type of consultation (full, limited, restricted)

Date of queried information (for consultation of history data)

Consult archives: yes or no

R_REG_VAL Reply to full consultation Requested MSARequested MSA

Applying MSAEconomic

operator One record of type registered operator (several in case ofconsultation of history), possibly completed by a series of records oftype tax warehouse (describing all warehouses of the warehousekeeper)or

One record of type tax warehouse (several in case of consultationof history), completed by one record of type registered operator (several in case of consultation of history), describing thewarehouse keeper of the warehouse

R_CER_REG Reply to limited consultation:

certificate of registration

Requested MSA

Requested MSA

Applying MSA

Economic

operator Member State

Excise number

Type of economic operator

If relevant, excise number of the warehouse keeper managing thetax warehouse

Acronym

Name

Address

List of categories or sub-categories of goods

Name of excise office exercising on operator

Address of excise office exercising on operator If relevant, list of excise numbers of the tax warehouses managedby the warehouse keeper







M_REG_REP Reply to restricted

consultation

Requested MSA

Requested MSA

Applying MSA

Economicoperator

Member StateExcise number

List of categories or sub-categories of goods

M_REG_SRC Query to retrieve economicoperators on a series ofcriteria

Applying MSA Requested MSA

According to the criteria, one or several of the following data may

be given

Member State

Type of economic operator

Acronym (approximate)

Name (possibly wildcard characters)

Address (possibly wildcard characters)

List of categories or sub-categories of goods (from structure ofexcise products)

Indicator categories of goods: any or all

Code of competent excise office

Code of competent registration office

Code of competent guarantee office



M_REG_LST List of retrieved operators Requested MSA Applying MSA

One or several records composed of the following fields

Member StateExcise number

Type of operator

Name

Acronym

Address

B.4. Management of guarantees

B.4.a Description

Each MSA defines its own way of maintaining the register of movementguarantees.

The register of guarantees is open to cross-consultation of MSAs. Economicoperators are not allowed to consult guarantee information.

Although the guarantees may be understood as an extent to the register ofoperators, it is highly recommended to maintain them separately, to allowfurther extensions and connection with other financial data concerning theoperators.







Registered

operator

Guarantee

information

*1

B.4.c Data records


Guarantee

information

Information on movement guarantees provided byeconomic operators


Excise authorisationnumber

String Must be a registeredoperator not a taxwarehouse

Number of

guaranteeagreement

String Appointed by the MSA

Type of guarantee Code From list of codes

Maximum amount String may be unlimited

VAT number of thefinancial institution

String

Name of financialinstitution

String

Address of financialinstitution

String



B.4.d Processing

Management of guarantee data

Each MSA maintains separately its own register of movement guarantees.

Movement guarantees are requested from authorised warehouse keepers.Registered traders and possibly tax representatives may provide movement

guarantees. There are no movement guarantees directly attached to tax

warehouses.

To support further investigations, history of guarantees must be kept andaccessible during at least three years.

As for registration data, guarantee data concerning a given economicoperator must be submitted to his agreement before being activated; thatsubmission concerns only the information given by the economic operator

(name and address of the financial institution).

Each Member State Administration is free to organise electronic dialogues

with the economic operators for validation and update of guarantee data.






Consultation of guarantee data

There is only one type of consultation of guarantee data; the information

returned is the whole guarantee information of the economic operator.

Each economic operator must have the ability to consult all his guaranteeinformation, if not on-line, at least by written exchange with the MSA.

Request for guarantee data

M_GUA_REQ Get data

R_GUA_VAL

ApplyingMSA

Requested

MSA

Consultation of

guarantee data

It can be found useful to perform a prior validation of compliance of thequery data with the relevant construction rules before sending the request.

The requestor may be either an automatic process such as the verification of

an AAD, or an end user in a MSA office.

The choice of request either the synchronous mode or the asynchronousmode may be systematically fixed by the MSA, or left to the initiative of the

user. But a MSA may choose not to implement a synchronous variant; in thatcase, downgraded mode is systematically enforced (downgraded mode inthe sense of VIES).

If the request concerns historical data, it may happen, according to thesolution actually implemented by the requested MSA, that data are notimmediately available and that re-loading of support is necessary; in that

case, and if the synchronous mode of request was used, downgraded modeis enforced.

Consultation of guarantees is open to cross-consultation by other MSAs(restricted by the profile of each user).

B.4.e Messages








M_GUA_REQ Request: guarantee data Applying MSA Requested MSA


Applying office

Requested Member StateExcise number of queried operator

Type of consultation (full, limited, restricted)



R_GUA_VAL Reply: guarantee data Requested MSA Applying MSA

One record of type guarantee information (several in case ofconsultation of history)

B.5. Management and consultation of duty rates

B.5.a Description

Each MSA defines its own way of maintaining the table of applicable dutyrates.

The table of duty rates is open to cross-consultation of MSAs and of the

European Commission (TAXUD and Application Centre). Economic operatorsshould consult rates on the Information Centre.


Product Duty rate*

B.5.c Data records


Duty rate Excise duty rate applicable to a given product (with or without particular conditions)


Product Code From structure of exciseproducts

Type of calculation Code From list of codesRate in nationalcurrency

Number

Rate in Euro Number

Rate in percentage Number

VAT rate(percentage)

Number

Additional rate

(value)

Number National taxes

Additional rate(percentage)

Number National taxes








B.5.d Processing

Management of duty rates

Each Member State Administration defines the way of update of duty rates, inthe strict framework of the structure of excise products recorded in thereference data.

Each Member State Administration must provide at least one duty rate for each product. Each rate is associated with dates of application.

For information purpose, the rates of VAT and of additional national taxesshould be given as well.

To support further investigations, history of duty rates must be kept and

accessible.

Consultation of duty rates

Cross-consultation of duty rates is open to MSAs, to the DG and to theApplication Centre (to allow extraction for preparation of Excise Duty Tables).

Query to retrieve duty rates

M_XDR_REQ Get data

M_XDR_REP

ApplyingMSA

Requested

MSA

Consultation of

duty rates

It can be found useful to perform a prior validation of compliance of the

query data with the relevant construction rules (in particular with the structureof excise products) before sending the request.

The choice of request either the synchronous mode or the asynchronous

mode may be systematically fixed by the MSA, or left to the initiative of theuser. But a MSA may choose not to implement a synchronous variant; in thatcase, downgraded mode is systematically enforced (downgraded mode inthe sense of VIES).

Consultation of duty rates is not open to registered economic operators;instead, they have the ability to get that information from the InformationCentre. The Application Centre is in charge of periodically extracting the duty

rates from the records of the MSAs and to publish them on the Information






Centre. The published tables do not include the history of rates but only

presently applicable ones.

B.5.e Messages


M_XDR_REQ Request: duty rate Applying MSATAXUDInformationCentre

Requested MSARequested MSARequested MSA


Queried product



R_XDR_VAL Reply: duty rate Requested MSARequested MSA

Requested MSA

Applying MSATAXUD

InformationCentre

One record of type duty rate (several in case of consultation of

history)

B.6. Consultation of VAT information

B.6.a Processing

VAT information is obtained from the VIES application, through the standardVATR transaction.

It must be highlighted here that VAT information is never used by the EMCS for taxation purpose but only to have a convenient and universal identity oftraders when not registered as Excise operators.

The Member States Administrations should open VAT data to consultation ofthe registered operators, if not on-line, at least by written exchange or phoneservice with the MSA.

B.6.b Messages


M_VAT_REQ Request: VAT information Applying MSA Requested MSARefer to the VIES R_VATR request

R_REG_VAT Reply: VAT information Requested MSA Applying MSA

Refer to the VIES D_VATR message

B.7. Reports

Printout of each type of reference data should be created to help officials intheir work; these reports may concern either the information presentlyapplicable or history of that information. Each Member State Administration maydefine reports according to their own requirements.

As a suggestion, the following lists might be developed:






• list of lists of codes (to be inserted in handbooks);

• list of offices of the MSA and of the other MSAs;

• structure of excise products, with the most precise definition of goods, either with or without duty rates;

• register of operators, with more or less details, including possible guaranteeinformation.





© Alcatel TITN Answare 2000 3AT 05006 AAAA DTZZA 02 C-1

APPENDIX C - SPECIFICATION OF GROUP II

C.1. Management of the certificates of guarantee

C.1.a Description

The certificate of guarantee is a particular record used in the circuit of theelectronic AAD to cover the case where the consignee is a non-registered

trader.

In that case, the Directive provides that the consignee must pay in advanceto the MSA of destination a deposit equivalent to the expected amount ofexcise duties. That deposit is for guarantee of the payment of the duties due

and will be exchanged for the actual payment of duties at delivery.

Upon that payment, the MSA of destination delivers a certificate ofguarantee, a copy of which must be transmitted to the consignor. The goods

cannot be dispatched without a copy of the certificate of guaranteeattached to the AAD.

C.1.b Structure of data

Certificate of

guarantee AAD

0..1 0..1






C.1.c Data records


Certificate of

guarantee

Certificate of deposit established by the MSA ofdestination

Member State ofdestination

Code From list of codes

Excise office which

established thecertificate

Code From list of offices

Name of excise office String Should be automaticallycopied from list of offices

Address of excise office Address Should be automaticallycopied from list of offices

Reference ofcertificate

String Appointed by the MSA ofdestination

Consignee Economic operator Always non-registeredoperator, therefore

identified by VAT number

Member State ofdispatch


Consignor Economic operator From register of operators

Reference of the AAD String Appointed by theconsignor – this is NOT theAAD number appointed bythe MSA of dispatch

Status of the certificate

of guarantee


Date of certificate DateDate of discharge Date

C.1.d Processing

Registration of certificates of guarantee

Each Member State Administration defines the way of management of thecertificates of guarantee, for registration, for possible cancellation, and for discharge.

Upon registration of the certificate of guarantee, the consignee(non-registered trader) receives back a paper copy of the certificate, that hehas to send to the consignor, a fax copy is acceptable solution. In all cases,he must keep the original copy, that he will have to present when declaring

receipt of goods (or to cancel the deposit).

At receipt of goods, the trader comes to pay duties; the Excise office thenregisters a discharge (and the date) into the EMCS (that operation is a part of

Receipt and discharge of AAD below).

The non-registered trader has the ability to cancel the deposit of guarantee if

no consignment has been finally received.






To support further investigations, history of certificates of guarantee must be

kept during at least three years; the certificate may be understood as anannex of each AAD.

M_GUA_REQ

Consignee MSA of

destination

Register certificate of

guarantee

Provide guarantee

Register Cancel guarantee

Consultation of certificates of guarantee

As the certificate of guarantee is an integral part of the movement dataattached to a given AAD number, that consultation is intended for the periodwhere the certificate is not attached to an AAD yet.

The request contains only the Member State and the number of thecertificate of guarantee (or the Excise number of the consignor plus theinternal reference of the AAD given by the consignor).

Request for certificate of

guarantee

M_CER_REQ Get data

R_CER_GUA

ApplyingMSA

Requested

MSA

Consultation of

certificate of guarantee

It can be found useful to perform a prior validation of compliance of thequery data with the relevant construction rules before sending the request.

The choice of request either the synchronous mode or the asynchronousmode may be systematically fixed by the MSA, or left to the initiative of the

user. But a MSA may choose not to implement a synchronous variant; in thatcase, downgraded mode is systematically enforced (downgraded mode in

the sense of VIES).






On-line consultation of certificates of guarantee is not open to economicoperators.

C.1.e MessagesMessage Description and contents From To

M_CER_REQ Request: guarantee data Applying MSA Requested MSA



Member State of dispatch (usually identical to applying MS, butmay be different)

AAD number (optional – may be replaced by the two followingfields)

Excise number of the consignor (if AAD number not known)

Internal reference appointed by the consignor (if AAD number not

known)R_CER_GUA Reply: certificate of

guaranteeRequested MSA Applying MSA

One record of type certificate of guarantee






C.2. Submission and registration of AAD

C.2.a Description

The procedure of submission of an electronic AAD involves the following

steps:

• consignor: submit the AAD;

• MSA of dispatch: verify formal validity of the submitted AAD (including

consultation of registers of the MSA of destination), appoint AAD number and send back registered copy to the consignor; forward copies to theconcerned MSAs;

• MSA of destination: if acceptation required from the consignee, forward

acceptation or refusal back to the MSA of dispatch; register copy of the

AAD; forward copy to the consignee;• consignee: if required, accept AAD;

• MSA of transit: register copy of the AAD.


AAD

description

AAD body

record

Transporter

Transport

details

Route details

Consignee

Owner of

goods

1..*

*

*

*

*

*






C.2.c Data records


AAD description Header of the description of an AAD

AAD number String Appointed by the MS of

dispatchUnique within the system

Reference String Appointed by the

consignor (to be used aslong as an AAD number isnot appointed by the MSA)



Consignor Economic operator From register of operators

Excise office atdispatch

Code From list of offices

Name of Exciseoffice at dispatch String

Address of Exciseoffice at dispatch

Address

Place of dispatch Economic operator If different from theconsignor

Certificate ofguarantee

String Reference appointed bythe MSA of destination -from register of certificatesof guaranteeIf the consignee is a

non-registered trader



Consignees See record Consignee below One or several

Export indication Code From list of codes – only ifconsignment intended for export

Customs office ofexport

Code From list of offices– only ifconsignment intended for

export

Name of Customsoffice of export

String Only in case of export

Address of Customs

office of export

Address Only in case of export

SAD number String Only in case of export

Date of export Date Only in case of export

Provider ofguarantee


Number of theguarantee

agreement

String From register of guarantees

Name of thefinancial institution

String

Invoice number String

Date of invoice Date







Owner of goods See record Owner of goods

below

If unique for the whole

consignmentSeveral sub-records are

possible to keep historyDate of dispatch Date

Journey time Number Expected duration in days

Transporters See record Transporter below Zero, one or several

Type of transport Code From list of codes

Transport details See record Transport details

belowZero, one or several

Route details See record Route details

belowZero, one or several

Consignee Sub-record describing a consignee of the movement

Member State of

destination


Description ofconsignee

Economic operator

Place of delivery Economic operator If different from consignee

Tax representative

at destination

Economic operator Optional

Status of consignee Code From list of codes



Transporter Sub-record describing a transporter of the movement

Identity oftransporter

Economic operator

Status of transporter Code From list of codesBegin of validity Date


Transport details Sub-record describing a means of transportation (vehicle,container, etc.)

Type of transportunit


Identity of transportunit

String

Status of transport

details




Route details Sub-record describing a point of expected transit

Member State oftransit


Expected place of

transit

String may be the code of an

office, or any textualindication

Expected time oftransit

Date and time

Status of routedetails


Begin of validity DateEnd of validity Date







Owner of goods Sub-record describing a trader

Type of owner ofgoods


Owner of goods Economic operator Status of owner ofgoods










AAD body record Sub-record describing a part of the consignment

Identifier Number Sequential number ofrecord

Status of bodyrecord




Original AAD String If AAD created by splitting

Original bodyrecord

Number If AAD created by splitting

Product Code From structure of exciseproducts

Quantity Number Unit depends on product – see structure of excise

products

Gross weight Number Net weight Number

Weight unit Code From list of codes

Fiscal mark or package number

String

Number ofpackages

Number

Kind of packages Code From list of codes

Commercialdescription

Text

Brand name of

product

String

Estimated value ofgoods

Number Taxes not included

Owner of goods See record Owner of goods

belowOwner of the goodsdescribed in the record

Alcoholic strength Number For alcohol and alcoholicbeverages: alcoholicstrength (for beer, only ifrequested by MS of

dispatch or by MS ofdestination)

Degree Plato Number For beer (if requested by MS

of dispatch or by MS ofdestination)

Wine-growing zone Code From list of codesFor wine: wine-growingzone

Wine manipulations Code From list of codes

for wine: operations whichproduct has undergone;several codes are possible

Designation of origin String For wine and spirits:designation of origin (ifapplicable)

Size of producer String For beer and ethyl alcohol:size of producer in

hectolitres (if applicable)







Density Number for mineral oils: density

Notes:

• the Excise number is mandatory for the consignor;• the fields describing the consignee may be left empty if the category of

goods is mineral oil, if the transport is either sea of inland waterway, and ifan authorisation number is given by the MSA of dispatch;

• except for this latter case, if the Excise number is omitted for the consignee,

this latter is implicitly a non-registered trader, and the number of thecertificate of guarantee must be given;

• the status of a body record is normally active; it may become replacedafter an operation of splitting of the AAD;

• to allow keeping history of changes, all sub-records have a status and aredated for their validity period;

• if the wine or spirit transported has a particular designation of origin, themention is not sufficient and a certificate of origin duly signed by acompetent authority must accompany the goods; DG VI is considering

the question and should lay down convenient provisions so that theelectronic AAD could be considered as a certificate of origin(qualification of economic operators, tracing of origin, etc.);

• for small brewers or distillers, the mention of the size of the producer may

not be sufficient; a certificate duly signed by the consignor could have toaccompany the goods – this must be considered;

• although implied by the product code, the size of the producer must beseparately given as explicit statement from the consignor;

• many interlocutors expressed the opinion that most of the informationlisted here, either is useless, or cannot be known from the consignor; aprecise list of mandatory and optional fields will have to be set up atsystem specification time.

C.2.d Processing

Formal validation of an AAD includes the following verifications:

Excise number of the consignor and its valid link with the login name of thesubmitter;

Excise number of the consignee, or VAT number if non-registered trader; name or acronym (or both) of the consignor in accordance with the

Excise number;

name or acronym (or both) of the consignee in accordance with theExcise number, if the consignee is a registered operator;

if given, VAT number of transporters and of owners of goods;

categories of declared goods compared to categories authorised for theconsignee (if registered);

data of the certificate of guarantee (if the consignee is a non-registeredtrader);

validity of the prior authorisation not to fill in consignee information, if

Article 15(6) of the Directive applies (may be replaced by an explicitauthorisation given at time of submission);






validity of the guarantee provided by the consignor, or by the consignee,

or by any other operator if implemented (according to the indicator contained in the AAD).

These verifications use the consultation functions offered by the system, inparticular:

• local and remote consultation of registration data including authorisedcategories of goods for the consignee (using the limited consultation

transaction);

• consultation of guarantee data, either local or remote (this latter if theconsignee is providing the guarantee);

• consultation of certificate of guarantee (if relevant);

• consultation of VAT data (as relevant).

No other controls than formal acceptability of the AAD are accepted beforedispatch of goods; in particular, no human control may be performed onsubmitted AADs. Conversely, as soon as the AAD is registered, each MSA may

submit its contents to a risk evaluation and possibly trigger controls, includingat dispatch of goods.

For a better management of consultation requests, it is recommended that

automatic validation use the asynchronous mode for cross-consultation.

In the case where the consignee is a non-registered trader, the consigneecannot be informed; he is supposed to have already accepted the

consignment when paying the guarantee of payment. The AAD is only sent tothe MSA of destination.

In the case where the goods are intended for export or to be placed under

customs procedures, there is no consignee in the sense of the EMCS, andtherefore a copy of the AAD is just sent to the IS of the MSA of intended exit.Risk assessment evaluation may result in a request for a control at office of exit(request transmitted through Movement Verification).

In some cases of mineral oils, where the consignee is not known at dispatch ofgoods (to cover Article 15(6) of the Directive), pre-acceptance is required

from the Member State of dispatch, under the form of an explicitauthorisation recorded in the AAD. MSAs are free to implement that

mechanism either under the form of a particular table of authorisation or byan explicit authorisation at time of submission, provided that a reference isgiven in the AAD.

In all cases, a paper copy of the AAD is printed out to be handed to theperson accompanying the goods.






Consignor MSA of

dispatch

MSA of

destination ConsigneeMSA of

transit

Create proposedAAD

Validate

AAD

AppointAAD

number

Accepted ??

Accept or

refuse

Print

M_AAD_SUB

M_AAD_SUBM_AAD_SUB

M_AAD_REF

M_AAD_REF

M_AAD_ACC

R_AAD_VALR_AAD_VAL

R_AAD_VAL

M_REG_REQM_VA2_REQ

M_GUA_REQ

Registered

consignee ?

Validation

ok ? NoYes

Acceptance

required ?

M_AAD_REF

M_AAD_ACC

M_AAD_REF No

Yes

Yes

R_CER_REGM_VA2_REP

R_GUA_VAL

Yes

No

In the case where goods would be separated during the journey into two or several parts, the paper copy should be duplicated, and each copy

annotated showing which part of goods is carried along with it.

C.2.e Messages


M_AAD_SUB Submitted AAD Consignor

MSA of dispatchMSA ofdestination

MSA of dispatch

MSA ofdestinationConsignee

One record of type AAD description plus one record of typeConsignee, plus possible records of type Transporter, Transport,Route Details and/or Owner of goods , plus one or several records oftype AAD body record

The AAD number is not yet given, therefore the AAD is identified by

the Member State of dispatch, the excise number of the consignor

and the internal reference appointed by the consignor.







M_AAD_REF Refusal of AAD Consignee

MSA ofdestination

MSA of dispatch

MSA of

destinationMSA of dispatch

Consignor Member State of dispatch

Excise number of the consignor

Internal reference appointed by the consignor

Reason of refusal (from list of codes)

M_AAD_AC

C

Acceptance of AAD Consignee

MSA ofdestination

MSA of


Member State of dispatch



R_AAD_VAL Recorded AAD MSA of dispatchMSA of dispatchMSA ofdestinationMSA of dispatch

Consignor MSA ofdestinationConsigneeMSA of transit

One record of type AAD description plus one record of typeConsignee, plus possible records of type Transporter, Transportdetails and/or Route details, plus one or several records of type AAD

body record

C.3. Warning from the consignee

C.3.a Description

Ability is given to the declared consignee to warn Member StatesAdministrations that the AAD does not match his vision of the movement,possibly that he is not awaiting it.

This mechanism works only if the consignee is a registered operator. Anon-registered operator is supposed to have accepted the consignment bypaying the guarantee for the duty at delivery.

C.3.b Data

Same as above under Submission and registration of AAD

C.3.c Processing

The consignee sends a message to the MSA of destination, which forwards itto all other concerned MSAs; the MSA of dispatch forwards the warning to the

consignor.






Consignor MSA of

dis atch

MSA of

destinationConsignee MSA of

transit

Issue warning

M_AAD_WRN

M_AAD_WRN

M_AAD_WRNM_AAD_WRN

C.3.d Messages

Message Description and contents From ToM_AAD_WRN Warning on AAD Consignee

MSA of

destinationMSA of dispatchMSA ofdestination

MSA ofdestination

MSA of dispatchConsignor MSA of transit

Member State of destination

Excise number of the consignee



AAD number

Reason of warning (from list of codes)

C.4. Update of the AAD during the movement

C.4.a Description

The consignor, owner of the AAD, is the only authorised to update theelectronic AAD.

No update of the electronic AAD may imply change of guarantor for the

movement; presently, this means only that if the guarantee is provided by the

consignee, this latter cannot be changed. If in the future, other partners suchas the transporter or the owner of goods provide the guarantee, it will not bepossible to change them either.

History of all changes should be kept under the form of older sub-recordsdescribing the consignee, the transporters, the transport details, the owners ofgoods, etc.

C.4.b Data







C.4.c Processing

Change of consignee

Article 15(5) of the Directive states that the consignor of a consignment mayissue a request to change the consignee, but only if the new consignee is aregistered operator. The older consignee is informed of that change.

In addition, in particular case of the mineral oils, if the consignee fields havebeen left blank, Article 15(6) of the Directive states that the consignor mustgive the identity of the consignee before delivery of goods. In that case, there

is obviously no forward of information to the older consignee.

The consignor, the older MSA of destination and the older consignee receive just the part of the electronic AAD that changed. The new MSA of destination

and the new consignee receive a copy of the whole AAD. As the route mightchange at the same time, the MSAs of transit receive a full copy of the AADas well.

Consignor MSA of

dispatch

MSAs of (new)

destination

(New)

Consignee

MSA of (old)

destination

Modification of

AAD

Validate

modification

Re-print

M_CHG_SUB

M_CHG_REF

R_AAD_VAL

R_AAD_UPD

Validation

ok ? No

Yes

(Older)

Consignee

MSAs of

transit

R_ AAD_UPDR_AAD_VAL

M_REG_REQ

R_CER_REG

R_ AAD_UPDR_AAD_VAL

Notes:

the process presented supposes that only the changed records(R_AAD_UPD) are transferred to the partners which have already a copyof the electronic AAD; it could prove more efficient to systematically

re-forward the whole electronic AAD (R_AAD_VAL) instead;

after having been informed of the change of consignee, the older consignee does not have to be informed of any further change;

as the movement is already ongoing, requesting explicit acceptance of

the consignee before change is meaningless. If the consignee does notaccept the consignment, he has to send a warning that he is not awaitingthe goods, as described above under Warning from the consignee.






Splitting of AAD

Economic operators requested explicitly that a given AAD could be split into

two or several parts to authorise delivery to two or more different consignees.

The Directive does not presently provide this function; change of legislationmay prove necessary.

This operation consists in an update of the contents (body records) of the AAD

and in the creation of one or several new AADs.

The general processing is the same as for a change of consignee, with thedifference that several new consignees may be involved in the change.

Consignor MSA of

dispatch

MSA(s) of (new)

destination

(New)

Consignee(s)

MSA of (old)

destination

Splitting of

AAD

Validate

modification

AppointAAD

number(s)

Re-print

M_SPL_SUB

M_CHG_REF

R_AAD_VAL

R_AAD_UPD

Validation

ok ? No

Yes

(Older)

Consignee

MSAs of

transit

R_ AAD_UPDR_AAD_VAL

M_REG_REQ

R_CER_REG

R_AAD_ UPDR_AAD_VAL

the goods that remain attached to the initial AAD must be completely

described in the submitted splitting message;

new body records are related to older ones by specific fields referring to

the original AAD and to the original AAD body record;

the total quantity for all body records coming from the same original bodyrecord must be equal to the original quantity;

in the AAD body records, only the fields that attach them to the AAD(updated older one or new) and the quantity are mandatory. If omitted,

other fields are automatically inherited from the original record (except for the place of delivery: if it is omitted, it is supposed to be identical to theaddress of the consignee),

after having been informed of the splitting of the movement, the older

consignee must be informed only of changes concerning the part ofgoods that remains intended to him.

Other changes

The other changes concern:

change of route; change of transporter;

change of transport details; and






change of owner of goods.

For these changes, no cross-consultation are necessary, but possibly the VATregister to check the identity of transporters or other traders according to their

VAT number.Consignor MSA of

dis atch

MSAs of

destinationConsignee

Modification of

AAD

Validatemodification

Re-print

M_CHG_SUB

M_CHG_REF

R_AAD_UPD

Validationok ? No

Yes

MSAs of

transit

R_AAD_UPD

R_AAD_VALR_AAD_UPD

M_VA2_REQ

M_VA2_REP

C.4.d Messages


M_CHG_SUB Submitted change Consignor MSA of dispatch



AAD number

Internal reference of change appointed by the consignor

Types of changes one or several codes from list of codes

If change of consignee, one record of type Consignee

If relevant, new value of journey time

If change of transporter(s), one or several records of typeTransporter describing all the new information

If change of transport details, one or several records of typeTransport details describing all the new information

If change of owner of all goods, one record of type Owner of goods

If change of owner of part of goods (each change concerning awhole body record), one or several records of type Owner of goods,each associated with the reference of the body record







M_SPL_SUB Submitted splitting Consignor MSA of dispatch



AAD number Internal reference of splitting appointed by the consignor

For each new AAD to be created, one record of type AAD

description with possible records of type Transporter, Transport,Route Details and/or Owner of goods

Several records of type AAD body record, each of whomassociated with one of the proposed AADs (through the internalreference appointed to the proposed AAD by the consignor) andwith one AAD body record of the older AAD

M_CHG_REF Refusal of change MSA of dispatch Consignor




Reason of refusal (from list of codes)

R_AAD_VAL Recorded AAD MSA of dispatchMSA of


MSA ofdestination

ConsigneeMSA of transit

Forwarded to partners which do not already have a copy of the

AAD

See above under Submission and registration of AAD

R_AAD_UPD Recorded update of AAD MSA of dispatchMSA of dispatch

MSA ofdestination

Consignor

MSA of

destinationConsignee

Forwarded to partners which already have a copy of the AAD



AAD number

All sub-records that were included in the submitted changeM_CHG_SUB

C.5. Receipt and discharge of AAD

C.5.a Description

There are two possible procedures to register delivery of goods:

most of the times, for a simple movement, the report of receipt is directlyrecorded;

in some cases, when the delivery may take a longer time, or if part of

goods did not arrive yet, a two-step procedure may be used, that allowsto block the AAD until final report of receipt.

In all cases, when the consignor receives the report of receipt, he mayconsider his movement guarantee as discharged, subject to duties due on

declared losses and to further enquiries made by any concerned MSA.







AAD

description

AAD body

record

Report of

receipt

Report

record0..11

0..11

1..* *

C.5.c Data records


Report of receipt Header of the report of receipt

Member State ofdispatch Code From list of codes

AAD number String From list of AADs



Type of consignee Code From list of codes

Consignee Economic operator

Place of receipt Economic operator If different from theconsignee

Arrival of goods Date and time

Report of receipt Date and time

Status of receipt Code From list of codes

Result of receipt Code From list of codes – global

result

Export indication Code From list of codes

Member State ofexit


Customs office ofexit

Code From list of offices– only incase of export

Name of Customsoffice of exit

String Only in case of export

Address of Customsoffice of exit

Address Only in case of export

Date of exit Date Only in case of exportType of transport onexport








Report record Record of shortage or excessSuch records should be created only for referenced records

of the AAD where an anomaly, excess or shortage is

ascertainedAAD body record String Reference to an activeAAD body record

Result of receipt Code From list of codes – applicable to the AAD

body record only

Excess or shortage Number Applicable to the AADbody record – given in theunit associated to theconcerned product

Notes:

• it is not possible to make a report record concerning a cancelled or

replaced AAD body record;

• if there is no report record concerning an active AAD body record, thismeans that there is neither excess nor shortage concerning that bodyrecord.

C.5.d Processing

The receipt process is the following:

1. when the first packages arrive at destination, the consignee optionally may issue a statement of arrival that gives a special status "ongoingdelivery" to the AAD;

2. when the consignment is considered as completely received and

inventoried, the consignee mandatory makes a report of receipt.

• when the AAD is under ongoing delivery, it cannot be changed any moreunless the delivery is cancelled;

• when the AAD is under ongoing delivery, the consignee may issue acancellation of the receipt; the movement is then considered as stillongoing;

•

both when a statement of arrival has been made and when themovement is ongoing, the consignee may make the report of receipt;

• after the report of receipt has been issued, the delivery cannot becancelled any more;

An optional report of excess and shortage is included in the report of receipt.

If the consignee is a non-registered trader, there is no statement of arrival; thereport of receipt is registered by the Excise office where the consignee comesto pay duties (normally, the office which registered the certificate of

guarantee); the certificate of guarantee is discharged at the same time.






Consignor MSA of

dispatch

MSA of

destinationConsignee MSA of

transit

Statement of

arrival

M_DEL_BEG

Cancellation of

receipt

M_DEL_CAN

Report of receipt

M_DEL_BEG

M_DEL_BEG

M_DEL_BEG

M_DEL_CANM_DEL_CAN

M_DEL_CAN

M_DEL_END

R_DEL_VAL

R_DEL_VAL

Register

beginning of

receipt

R_DEL_VAL

Register repor t

of recei t

C.5.e Messages


M_DEL_BEG Statement of arrival ConsigneeMSA ofdestination

MSA of dispatchMSA of

destination

MSA ofdestinationMSA of dispatch

Consignor MSA of transit


AAD number


Type of consignee

Consignee

Place of receipt

Date of arrival of goods







M_DEL_CAN Cancellation of receipt Consignee

MSA ofdestination

MSA of dispatchMSA ofdestination

MSA of


Consignor MSA of transit


AAD number


Type of consignee

Consignee

Reason for cancellation (from list of codes)

M_DEL_END Report of receipt Consignee MSA ofdestination

One record of type Report of receipt (except export specific fields),

plus possible records of type Report Record

R_DEL_VAL Recorded report of receipt MSA ofdestinationMSA of dispatchMSA of

destination

MSA of dispatchConsignor MSA of transit

Identical to the preceding message

C.6. Export of goods

C.6.a Description

Export procedure is a particular case of receipt of goods, using particular variants of the statement of arrival (export message) and of the report ofreceipt (exit message).

The export message is created at the customs office of export, where, inparticular, the number of the export Single Administrative Document isregistered into the electronic AAD. The exit message is created at the customsoffice of exit, where the goods leave the territory of the Union, and constitutesthe discharge of the movement guarantee.

C.6.b DataSame as above under Receipt and discharge of AAD.

C.6.c Processing

Submission and registration

See above under Submission and registration of AAD.

Export procedure

The two steps of the full procedure of receipt are used:






1. at office of export (normally in the Member State of dispatch), the number

of the customs SAD is registered into the electronic AAD;2. at office of exit where the goods actually leave the Union, the movement

is discharged.

Consignor MSA of

export/dispatchMSA of exit MSA of

transit

M_EXP_BEG

M_EXP_BEG

M_EXP_BEG Discharge

procedure

R_EXP_VAL

R_EXP_VAL

R_EXP_VAL

Export procedure

C.6.d Messages


M_EXP_BEG Export message MSA of export(Customs office

of export)

MSA of dispatchMSA of dispatch

MSA of dispatch

MSA of dispatch(if different from

MSA of export)

Consignor MSA of exit

MSA of transit


AAD number

Member State of export

Customs office of export (code, name, address)

Export indicator

SAD number

Date of export procedure

R_EXP_VAL Exit message MSA of exit

MSA of dispatch

MSA of dispatch

Consignor

One record of type Report of receipt (including export specific

fields), plus possible records of type Report Record

C.7. Claims on losses

C.7.a Description

This optional mechanism is provided to have an initial handshake betweenMember states Administrations and economic operators when anomaliesarisen during a movement may result in payment under the cover of themovement guarantee.

That mechanism is made of two messages: the first one to issue a claim fromthe requesting Member State to the provider of the guarantee, and thesecond to allow the guarantor contesting the claim.






Further exchanges are supposed to directly happen between the claimingMSA and the economic operator, anyway outside the EMCS.


AAD

description

Claim on

lossesContest

0..111 *

C.7.c Data records


Claim on losses Claim for duties due on declared losses

Member State ofclaim


Excise office ofclaim

String From list of MSA offices

Reference of claim String Appointed by the MSA ofclaim

Member State ofguarantor


Excise office

exercising on theguarantor


Guarantor Economic operator Must exist in the register Usually the consignor

AAD number String From list of AADsType of claim Code From list of codes

Claim Text Free description of theclaim

Amount of claim innational currency of

the Member Stateof claim

String

Amount of claim inEuro

String

Date of claim Date and time







Contest Contest of claim

Member State ofguarantor


Excise officeexercising on theguarantor


Guarantor Economic operator Must exist in the register Usually the consignor


Member State ofclaim


Excise office ofclaim

String From list of MSA offices

Reference of claim String Internal referenceappointed by the MSA of

claimReason of contest Code From list of codes

Contest Text Free description of thecontest

Date of contest Date and time

C.7.d Processing

Any Member State Administration involved in a movement may issue a claim

concerning duties due to anomalies or losses happened during a movement;the claim is sent to the guarantor (usually the consignor) under the form of aspecific message. The MSA of the guarantor may register a copy of the claimwhen this latter transits through its Information System to be forwarded to the

guarantor. The guarantor may answer to the claim by a contest message.

Consignor MSA of

guarantor

MSA of

claim

M_REQ_ CLM

Issue claim

on losses

M_CTS_CLM

Contest claim on

losses

M_REQ_CLM

M_CTS_CLM






C.7.e Messages


M_REQ_CLM Claim on losses MSA of claimMSA of guarantor

MSA of guarantor Guarantor

One record of type Claim on losses

M_CTS_CLM Contest of claim Guarantor MSA of guarantor

MSA of guarantor MSA of claim

One record of type Contest of claim

C.8. Consultation and retrieval of movement data

C.8.a Description

There are several possible combinations for consultation of AADs, according

to the wishes of the user expressed as a parameter of the request.

MSAs have access to cross-consultation without restriction; each MSA mayopen consultation of AADs to economic operators for the movements where

they are involved.

In addition, a general query is provided to retrieve a movement whose AADnumber is not known by the requestor.

C.8.b Data


C.8.c Processing

Consultation of movement data

There is a unique request to consult the movement data, but, according tothe parameters of the request, the consultation may return different parts ofrecords.

Consultation of AADs is open to cross-consultation by other MSAs (restrictedby the profile of each user). If agreed by the MSA, each economic operator

can consult only movements where he is or was involved as consignor or asconsignee (including older consignees after change of destination).






Request for AAD

M_AAD_REQ Get data

M_AAD_REP

Applying

MSA

Requested

MSA

Consultation of

movement data

The requestor may be either an automatic process such as the verification ofan AAD, or an end user in a MSA office.

The choice of request either the synchronous mode or the asynchronousmode may be systematically fixed by the MSA, or left to the initiative of theuser. But a MSA may choose not to implement a synchronous variant; in thatcase, downgraded mode is systematically enforced (downgraded mode in

the sense of VIES).

If the request concerns historical data, it may happen, according to thesolution actually implemented by the requested MSA, that data are not

immediately available and that re-loading of support is necessary; in thatcase, and if the synchronous mode of request was used, downgraded modeis enforced.

Retrieval of movements

That request aims at retrieving a movement whose AAD number is not knownby the applicant, but only some of his characteristics.

The user builds the request under the form of a query by example, by givingdata concerning one or several of the fields describing the movement. In

some fields, wildcard characters are possible.

The query returns a list of movements; if that list exceeds a given (andupdateable) number, an error may be returned and the requesting user hasto refine the query.






Query to retrieve AADs

M_AAD_SRC Get data

M_AAD_LST

Applying

MSA

Requested

MSA

Consultation of

retrieved list

If open to the economic operators, that function should be filtered so thatonly movements where the operator is involved are returned.

As the time of response may become long if the query is complex, it isrecommended to use only the asynchronous mode for that consultation.

If the request concerns historical data, it may happen, according to the

solution actually implemented by the requested MSA, that data are notimmediately available and that re-loading of support is necessary; in thatcase, and if the synchronous mode of request was used, downgraded modeis enforced.

C.8.d Messages


M_AAD_REQ Request: consultation ofmovement

Applying MSAEconomicoperator

Requested MSARequested MSA


AAD number

Type of consultation : a series of codes from the list of codes









M_AAD_REP Reply: movement data Requested MSA

Requested MSA

Applying MSA

Economicoperator

One record of type AAD description (several in case of consultationof history)

One record of type Consignee (several in case of consultation ofhistory)

One or several records of type Transporter (exact list depends onrequested data)

One or several records of type Transport details (exact list dependson requested data)

One or several records of type Route details (exact list depends onrequested data)

One or several records of type Owner of goods (exact list depends

on requested data)

One or several records of type AAD body record (exact list dependson requested data)

M_AAD_SRC Query to retrieve movementson a series of criteria

Applying MSEconomicoperator

Requested MSARequested MSA

According to the criteria, one or several of the following data may

be given


Excise number of consignor

Acronym of consignor (approximate)

Name of consignor (possibly wildcard characters)

Address of consignor (possibly wildcard characters)Name of excise office exercising on consignor (possibly wildcardcharacters)

Address of excise office exercising on consignor (possibly wildcardcharacters)


Excise number of consignee

VAT number of consignee (non-registered trader)

Acronym of consignee (approximate)

Name of consignee (possibly wildcard characters)

Address of consignee (possibly wildcard characters)

Name of excise office exercising on consignee (possibly wildcardcharacters)

Address of excise office exercising on consignee (possibly wildcardcharacters)

List of MSAs of transit (will success if any is found)

List of requested categories or sub-categories of goods (fromstructure of excise products)

Indicator on categories of goods: any or all









M_AAD_LST List of retrieved movements Requested MSA

Requested MSA

Applying MSA

Economicoperator

One or several records composed of the following fieldsMember State


Name of the consignor

Excise number or VAT number of the consignee

Name of the consignee

List of categories of goods carried by the movement

Date of dispatch

Date of receipt (if known)

C.9. Automatic recalls

C.9.a Description

In the circuit of AAD, some steps where human intervention is required maycause delays; these delays could be reduced if the faulty office or operator would be recalled that an action is expected; the following reminders should

be implemented.

• in the case where the consignee must explicitly accept a movement, amessage should be sent to the consignee each time that the message of

acceptance or of refusal was not sent in a given (updateable) delay fromthe submission of the AAD; answer to that reminder is either acceptanceor refusal of the movement;

• upon receipt, a message should be sent to the consignee if report ofreceipt or statement of arrival was not done in a given (updateable)

delay from the expected time of arrival (date and time of dispatch plus journey time); answer to that reminder is either a statement of arrival, or areport of receipt, or an information message stating that goods did notarrive yet;

• if the consignee is a non-registered trader, the same message should besent to the Excise office which made the certificate of guarantee toinform them that the consignee should have made the report of receipt;the excise office is then required to ask the consignee whether goods

arrived or not; answer to that reminder is either a report of receipt, or aninformation message stating that goods did not arrive yet;

• if a statement of arrival was sent, a message should be sent to theconsignee if the report of receipt was not sent in a given (updateable)

delay from the receipt of the statement of arrival; answer to that reminder is either a report of receipt, or a cancellation of receipt, or an informationmessage stating that inventory is not completed yet, in particular thatpackages are still being awaited;

• if the recalled party does not answer in due time, escalation procedures

must be used involving other means than the EMCS (phone call, e-mail,

fax, etc.)






C.9.b Data

No particular data are attached to the mechanism.

C.9.c Processing

Automatic recall

M_REC_REQAnswer

M_REC _REP

IS of the MSA Requested party

(consignee or excise office)

Consult answer M_AAD_ACC

M_AAD_REF

M_DEL_BEG

M_DEL_END

Part of therelevant

business processProcess

Yes

No Ready ?

C.9.d Messages


M_REC_REQ Recall message IS of the MSAIS of the MSA

ConsigneeExcise office

Applying MSA

Excise number of consignee or code of the excise office

AAD number

Expected date of action

Reference of recall message (for correlation with reply)

Reason for recalling (from list of codes)

M_REC_REP Reply to recall Consignee

Excise office

Applying MSA

Applying MSA

Excise number of consignee or code of the excise office

Applying MSA

AAD number Reference of recall message (for correlation)

Return code to recall (from list of codes)

C.10. Reports

Creation of reports for the day-to-day use of the EMCS is closely linked to themethods of work of each Administration. The following suggestions should be

adapted to the particular context of the Member State.

Detailed definition of reports must be made at specification time of each

application.






C.10.a Reports of activity

• list of AADs created: a summary of all AADs submitted by warehouse keepersand accepted by the Administration: daily or weekly lists, edited for a given

excise office; each record should contain identification of consignor and of

consignee, categories of goods, and estimated value of duties, possiblyother characteristics as defined by the MSA;

• list of AADs announced: the same list of submitted AADs, but selected per

excise office of destination;

• list of AADs received: the report of losses with estimated value ofcorresponding duties should be added; the list concerns both excise office ofdispatch and excise office of destination;

• list of AADs received by registered traders, with the amount of duties thatshould be paid;

• list of movements per economic operator (two parts: sent and received);

• lists of controls made by operator, by transporter, by reason, by results;

• lists of usage of guarantee per operator, per type.

C.10.b Reports of anomalies

• list of AADs submitted and rejected, with reason of rejection;

• list of AADs refused by consignee;

• list of changes of destination;

• list of movements expected but not arrived, and/or list of ongoing inventories(according to the procedure of delivery chosen);

• list of claims per operator, per sector, per period, contested or not contested.





© Alcatel TITN Answare 2000 3AT 05006 AAAA DTZZA 02 D-1

APPENDIX D - SPECIFICATION OF GROUP III

D.1. Road controls

D.1.a Description

The term road control covers here all types of physical controls that may beperformed during the movement, from dispatch of goods to end of delivery. It

may be performed at dispatch, during the movement or at arrival. The placemay be an office of a MSA or any point of the journey (roadside, port, airport,rail station, inside a train, etc.).

D.1.b Structure of data

AADdescription

AAD body

record

Report of control

Control

record

1

*

*

**

D.1.c Data records


Report of control Header of the report of control




Member State of

the office requestor of control

Code If applicable

From list of codes

Office requestor ofcontrol

String If applicableFrom list of MSA offices

Member State ofthe office of control


Office of control String From list of MSA officesController String

Name of place ofcontrol

String

Address of place ofcontrol

Address

Date of control Date

Type of control Code From list of codes

Global conclusionof the control

One or several codes From list of codes

Comments Text







Control record Record of ascertained anomalySuch records should be created only for referenced records

of the AAD where an anomaly, excess or shortage is

ascertainedAAD body record String Reference to an activeAAD body record

Confidentiality Indicator: Yes or No If Yes, the record is visibleonly to officials

Excess or shortage Number Applicable to the AAD

body record – given in theunit associated to theconcerned product

Conclusion of thecontrol

One or several codes From list of codes – applicable to thereferenced record

Consultation of reports of control should be available to the concernedeconomic operators along with the rest of movement information. Therefore,a confidentiality indicator is given to the control officer to indicate whether a

particular body record must be hidden to economic operators.

D.1.d Processing

If the control team has a connected terminal on the place of control, thecontrol should be based on the electronic AAD read on the terminal.

If the control team does not have a connected terminal available on the

place of control and if the control is planned in advance, it is recommendedto have a paper copy of the AAD printed before the control.

If the control team does not have a connected terminal available on the

place of control and if the control is not planned in advance, the controlshould be made based on the paper copy of the AAD that accompanies thegoods.

In all cases, the control officer records the results of the control and the MSA

of control automatically dispatches it to the concerned MSAs.






Control

officer

MSA of

control

MSA of

dispach

MSA of

destination

Request for

AAD

Get data

M_AAD_REQ

R_CTL_REP

MSAs of transit

R_ CTL_REP

M_AAD_REQ

Consultation of

movement data R_AAD_VAL

R_AAD_VAL

Report control

R_CTL_REP

Register control

Print

D.1.e MessagesMessage Description and contents From To

R_CTL_REP Report of control MSA of controlMSA of controlMSA of control

MSA of dispatchMSA ofdestinationMSA of transit

One record of type Report of control, possibly completed by a seriesof records of type Control record

D.2. Risk assessment

D.2.a Description

Each MSA is committed to implement risk assessment on movements of goods

under excise duty suspension. There is no obligation to do it by computerisedmeans, but it would certainly be convenient and efficient to systematicallyand automatically pre-assess the risk on each AAD where the MSA is involved,either as Member State of dispatch, or as Member State of destination, or

even as Member State of transit.

Therefore, it is proposed to branch an automatic risk assessment on the datareceived from the circuit of the electronic AAD.

D.2.b Criteria

There are two categories of sets of criteria:






• first, criteria defined in common, as it is actually the case for theform-based excise Early Warning System: MSAs are required to apply thesecriteria;

• second, nationally defined criteria.

Risk assessment criteria are all elements of the AAD and of associated recordsthat may be used to retrieve a given AAD. There is a proposal for thesecriteria:

Criterion Tested against

AAD number (including Member State ofdispatch)

Predefined list

Reference number initially given by theconsignor

Predefined list

Member State of dispatch Predefined listMember State of destination Predefined list

Date of invoice Exact date or interval

Number of invoice Exact value

Excise number of consignor or Excise

number of the warehouse keeper managing the tax warehouse ofdispatch

Predefined list

VAT number of the consignor Predefined list

Excise number of consignee (including ofolder consignee if changed) or Excisenumber of the warehouse keeper

managing the tax warehouse ofdestination

Predefined list

VAT number of the consignee Predefined list

Name of consignor Predefined list of names with or withoutwildcard characters

Name of consignee (including of older consignee if changed)

Predefined list of names with or withoutwildcard characters

Acronym of consignor Predefined list of acronyms;approximation should be possible

Acronym of consignee (including ofolder consignee if changed)

Predefined list of acronyms;approximation should be possible

Postal code of consignor Predefined list of codes with or withoutwildcard characters

Postal code of consignee (including ofolder consignee if changed)

Predefined list of codes with or withoutwildcard characters

City of consignor Predefined list of names with or withoutwildcard characters

City of consignee (including of older consignee if changed)


Categories of goods of the movement Predefined list

Quantity of goods (see note below) Interval (usually minimum value)Value associated to the consignor

Value of Excise duties of the

consignment (calculated from localrates, or from rates of another MS)

Interval (usually minimum value)

Value associated to the consignor






Criterion Tested against

VAT number of transporter(including of

older transporter if changed)

Predefined list

Name of transporter (including of older

transporter if changed)

Predefined list of names with or without

wildcard charactersAcronym of transporter (including ofolder transporter if changed)


Postal code of transporter (including ofolder transporter if changed)


City of transporter(including of older transporter if changed)


VAT number of owner of the

goods(including of older owner ifchanged)

Predefined list

Name of owner of the goods (includingof older owner if changed)


Acronym of owner of the goods(including of older owner if changed)


Postal code of owner of the goods(including of older owner if changed)


City of owner of the goods (including ofolder owner if changed)


City of owner of the goods(including ofolder owner if changed)


Journey time Interval (usually maximum value)

Brand name of product Predefined list of names with or withoutwildcard characters

Commodity number of products Predefined listType of transport Predefined list

Change of consignee Yes or no

Change of transporter Yes or no

Change of owner of goods Yes or no

Change of route The MSA is a new MS of transit

This list can be completed by each MSA either with less or with more criteria.

More complex analyses have been suggested. MSAs are free to do so, if they

wish, but it must be highlighted that too much automation may become

harmful for the efficiency of the processing.

D.2.c Processing

A pattern of suspicion is a combination of criteria taken from the proposed list(possibly amended by the MSA) with, for each of them, the tested values; theexamined movement is selected if, and only if, it meets all criteria composing

the set.

The proposed processing is the following:

1. using risk analysis techniques, and based on their own priorities, a

dedicated team of the central investigation office of each Member StateAdministration defines several sets of patterns of suspicion; other sets of






patterns of suspicion are created from common requirements agreed by

MSAs;2. after each submission (more precisely, after the AAD has been registered

and sent back to the consignor), the AAD with its associated records is

compared to each pattern of a first set;3. after each update (more precisely, after the update has been registered

and sent back to the consignor), the AAD with its associated records iscompared to each pattern of a second set;

4. after each delivery, the AAD with its associated records is compared to

each pattern of a third set;5. daily, all AADs created, and/or updated, and/or received, are compared

to each pattern of a fourth set;6. if the movement is found matching one of these patterns, an alert is sent

to an investigation officer.

Risk assessment criteria are managed off-line, i.e. that the centralinvestigation office prepares patterns that are not active and, when thewhole set is satisfactory, it is activated in place of the precedent set, by a

specific command.

All concerned MSAs (the MSA of dispatch, the MSA of destination and allMSAs of transit) are supposed to have a copy of the AAD. If common sets of

criteria are defined at European level to be mandatory applied by allMember States, a given AAD is supposed to raise alerts in all concernedMember States. Therefore, such alerts, triggered by common criteria, shouldnot be forwarded between Member States, but should only result in national

actions. Obviously, MSAs are free to organise common or co-ordinatedcontrols on a particular movement signalled by that mechanism, and arecommitted to inform other concerned MSAs if a national enquiry detectedsome fraud or irregularity.

D.3. Management of alerts

Upon receipt of an alert issued by the risk assessment, or upon initiative of anyofficial, the suspect movement falls under the responsibility of an investigationofficer who may decide either to ignore the alert, or to request complementary

controls at national level, or to request controls in other MSAs under the form ofMovement Verification (possibly Mutual Assistance) messages.

Internal circulation of alerts between officials is completely defined by eachMSA.

It is recommended that each MSA create an environment for the follow-up ofalerts, grouping in particular all messages exchanged concerning the samemovement.

D.4. Automatic recalls

A mechanism of reminders is described in the present Movement Verification

system; it is proposed to integrate it as an automatic mechanism of theMovement Verification and Mutual Assistance sub-systems of the EMCS.






Recall messages should be sent:

• to the intended recipient of a message, if no acknowledgement was sent ina given (updateable) delay from its date of issue;

• to the recipient of a message (sender of the acknowledgement), if the replywas not sent in the agreed delay (either the date for reply integrated in therequest, or the updated date for reply given if the acknowledgement);

• if the addressee did not read a message in a given (updateable) time, itshould be forwarded to another address (escalation authority);

• if the recalled party, or the escalation authority, does not answer in due time,escalation procedures involving other means than the EMCS must be used(phone call, e-mail, fax, etc.)

Acknowledgements and reminders are particular types of MovementVerification or Mutual Assistance messages.

Integrating such automatic mechanisms with the AFIS application might proveunpractical; in that case, the implementation of automatic recalls in Movement

Verification and Mutual Assistance would be delayed until these functions aremigrated to the EMCS infrastructure.

D.5. Collection of statistics

D.5.a Operating level

It is recommended that each Member State Administration creates its own

statistics on the usage of the application, in particular on traffic and on thetimes of response, so that they can plan improvements of their nationalapplication, re-evaluate their hardware and software, etc.

At the same time, the same kind of information should be extracted from

CCN/CSI statistics to help the DG in re-evaluating the infrastructure.

The monitoring exercised by the Application Centre might help both MSAsand the DG in planning technical improvement of the EMCS.

Detailed definition must be made both in system specification phase and in

each national application specification phase.

D.5.b Application level

It is recommended that each Member State Administration creates its ownstatistics on the usage of each function, in particular on errors made by theusers, to improve training, documentation and possibly external specification

of user interfaces.

Detailed definition must be made in each national application specificationphase.






D.5.c Business level

Statistics on the activity of the system must be created. Contrary to other statistics, which may be specific to each Member State or extracted from

CCN/CSI statistics, a minimum harmonisation should be defined, so that

information may be consolidated between Member States at European level.Appendix E contains proposals for such statistics.

Detailed definition must be made in system specification phase.

D.6. Movement Verification and Mutual Assistance

D.6.a Description

Movement Verification concerns particular exchanges of informationbetween Member States concerning a particular movement; the request

may concern documents, but physical controls as well. Presently, MovementVerification is often used to exchange copies of AADs; that function willbeneficially be replaced by direct consultation of electronic data (see aboveunder Consultation and retrieval of movement data); however other requestsfor deeper verifications remain necessary.

Conversely, the Member States are committed to exchange other information under the cover of Mutual Assistance (under Council Directive77/799/EEC).

For these two modules, the solution suggested is to use the existing AFIS

infrastructure, at least for the beginning. As the contents of a MovementVerification message (and still more of a Mutual Assistance message) arepartially unpredictable, a utility application to produce customised message

bodies is proposed.

That utility, called message builder, must be developed under theresponsibility of the Directorate General for Taxation and the Customs Union,

to be integrated with the AFIS client application. It is based on the thesaurusof terms. An associated utility, named message viewer, would allow users toconsult and print these messages.

In a further step, Movement Verification and Mutual Assistance could bemigrated to the EMCS instead of AFIS. This should require:

the overall agreement of all Member States, as a mixed infrastructure isnot considered sensible:

adaptation of the message builder and of the message viewer to eachnational application;

development of complementary storage and management functions ineach national application.






D.6.b Messages


M_MVE_MAS Common message for Movement Verification and

for Mutual Assistance

Applying MSA Requested MSA

Message identifier appointed by the applying MSA


Applying office (by default, ELO)


Requested office (by default, ELO)

Message identifier of a previous message

Subject (text with possible summaries in other languages)

Date of message

Type of message (from list of codes)

List of actions requested (from list of codes)

Optional body created using the message builder

D.6.c Message builder and message viewer

As they are proposed to support other exchanges than MovementVerification and Mutual Assistance, the message builder and the message

viewer should be developed in the Utilities Group.





© Alcatel TITN Answare 2000 3AT 05006 AAAA DTZZA 02 E-1

APPENDIX E - SPECIFICATION OF UTILITIES

Unless specified, development of the utilities is under the responsibility of eachMember State.

E.1. Appointment of user names and of access rights

The administrators of the MSA should be provided with convenient tools tocreate new user identities, manage access rights, etc.

These tools can be standard tools of the basic software, standard utilities of theComputing Centre of the MSA, or specifically developed utilities.

E.1.a Officials

A user name should be appointed to each official involved in the EMCS; the

MSA must maintain a particular register of authorisation, preferably integratedin their general access control lists. As far as possible, access should berestricted to the functions that each agent has to perform.

For the access to the EMCS application, officials of the Member States mustreceive a user identity managed at national level.

For accessing some EMCS functions (in particular the consultations madeavailable to them), officials of the EC might receive CCN user namesregistered in a specific user profile.

E.1.b Economic operatorsA user name should be associated with each registered operator or taxwarehouse. That name should be automatically appointed after the firstregistration of the operator, and communicated to him along with his

confidential credentials (initial password, private certificate or equivalent). A particular procedure outside the EMCS should be set up for a secure

communication way of these credentials.

For the access to the EMCS application, economic operators must receive auser identity managed at national level.

E.1.c Support agents

A user name should be appointed to each agent of the national supportcentres, and a common user name appointed to each other support centre

and to the central Application Centre. MSAs are free to define whether it isuseful or not to give several profiles to their support agents, for instance restrictto some of them the ability to patch the data bases and registers. The agentsof other support centres should have a wide access to the information and toits history, but not be allowed to update anything in the tables or logs.

Subject to decision of each Member State, a support agent might by

identified either as a privileged user of the national EMCS application, or as aCCN user, possibly both. Specific user profiles should be created for that

purpose.






E.1.d AFIS users

Separately from his possible access to the EMCS, each user allowed to use theAFIS infrastructure must receive a particular CCN user name; the AFIS rules for

definition of CCN user profiles must be respected.

E.2. Management of passwords

E.2.a Description

If the solution chosen by the MSA for identification and authentication of usersinvolves a password recorded in the Information System, the convenientsoftware modules must be provided to each profile of user to change that

password so that the user is the only person knowing it.

Recommendations should be made to the economic operators where the

password must be shared among several persons, to keep a sensible level ofconfidentiality of the password while being able to retrieve it if necessary(securely stored sealed envelope of equivalent).

It is recommended that the user changes his password as soon as he receivesthe initial value and then at regular intervals, for instance monthly or quarterly.

E.2.b Processing

Change of password is an interactive synchronous transaction.

Request change

M_PSW_CHG

Change

password

M_PSW_CNF

User IS of the MSA

Receive

acknowledgement

E.2.c Messages


M_PSW_CHG Request to change thepassword

User IS of the MSA

Code of the MSA

User name

Older password (encrypted by itself)

New password (encrypted by older password)







M_PSW_CNF Reply after change IS of the MSA User

Code of the MSA

User name

Return code of the change functionNew password (encrypted by itself)

E.3. Monitoring of connections

E.3.a Description

To guarantee users that all EMCS nodes are available according to thesystem requirements, and to anticipate and plan necessary upgrades of theinfrastructure, particular utilities should be developed and installed

Two categories of information should be monitored:

• availability of the site: interactive request to be periodically sent by the

Application Centre to each national node, requesting an answer provingthat this node is presently operational;

• performances: both interactive and asynchronous requests to beperiodically sent by the Application Centre to each national node,

related with the time where the reply is received.

E.3.b Processing

Three specific transactions should be created:

• a synchronous request (CCN/CSI call mode) for availability, where theserver (MSA side) just returns an acknowledgement;

• a synchronous request (CCN/CSI call mode) for synchronous performance,

where the server (MSA side) performs a function returning an estimation ofthe present load of the server;

• an asynchronous request (CCN/CSI put/get mode) for asynchronousperformances, where the server (MSA side) makes longer queries.

There may be several functions intended to measure the performancesconcerning several parts of the system, for instance:

• consultation of registers (retrieval of a conventional operator reserved for that purpose);

• retrieval of a list of operators (conventional operators reserved for thatpurpose, so that the size of the returned message is always the same);

• consultation of AADs (retrieval of a conventional AAD reserved for thatpurpose);

• retrieval of a list of AADs (conventional AADs reserved for that purpose, sothat the size of the returned message is always the same);

• update of AAD (may be the same conventional AAD).






Query

M_AVA_REQ

Answering

function

M_AVA_REP

Application

Centre

Requested

MSA

Measure

Query

M_PER_REQ

Requested

function

M_PER_REP

Application

Centre

Requested

MSA

Measure

A specific application of the Application Centre collects the results and

analyses them. In case of unavailability, or if performances are under a givenlimit, an alert is raised to an operator of the Application Centre so that he canask for more information from the national support. Separately, consolidatedstatistics are built from the results of monitoring and periodically published.

Development of the called functions is under the responsibility of each MSA;development of the central monitoring tool is under the responsibility ofTAXUD.

E.3.c Messages

Message Description and contents From ToM_AVA_REQ Query (availability) ApplicationCentre

IS of the MSA

Queried Member State (from list of codes)

M_AVA_REP Reply (availability) IS of the MSA Application

Centre


Status of availability (from list of codes)

Time of receipt of the query

Time of issue of the reply

M_PER_REQ Query (performances) ApplicationCentre

IS of the MSA


Requested function (from list of codes)

M_PER_REP Reply (performances) IS of the MSA ApplicationCentre


Requested function (from list of codes)

Return code of the function performed

Time of receipt of the query

Time of issue of the reply






E.4. Consolidation of statistics

E.4.a Description

Excise statistics should be extracted from all convenient transactions to betransferred to the Application Centre for consolidation.

The Application Centre should be provided with the convenient analysis toolto produce periodic reports.

The statistics proposed below have not been validated by the Member States,and they should be more precisely defined in the system specification phase.The following proposal is believed to be a sensible approach of the necessary

business statistics.

E.4.b ProcessingAll relevant data items should be recorded in a particular log during thetransactions. These records should then be grouped into one of the messagesdescribed below and periodically transferred to the Application Centre whenthe system has a low activity. Each MSA is free to determine whether "low

activity" means during the night or possibly during the day.

Prepare statistics

M_STA_ACT

M_STA_INC

Collect statistics

IS of the MSA Application Centre

Analyse statistics

Development of the function that prepares and sends statistics is under theresponsibility of each MSA. Development of collection and analysis is under

the responsibility of TAXUD.






E.4.c Messages


M_STA_ACT Statistics on activity IS of the MSA ApplicationCentre

A series of records containing the following fields

Type of action (from list of codes)

Member State of origin

Excise number of consignor

Type of consignor


Excise number of consignee

Type of consignee

Category of goods

Estimated value of excise duties in the MS of dispatch

Estimated value of excise duties in the MS of destination

Date of dispatchDate of receipt

M_STA_INC Statistics on incidents IS of the MSA ApplicationCentre

A series of records containing the following fields

Type of incident (from list of odes)

Member State of the concerned economic operator

Excise number of the economic operator

Estimated value of consignment in the MS of the economicoperator

Date of incident

E.5. Consultation of information by support agents

The agents of functional support teams should have access to all consultationtransactions of the application, both in local mode and in cross-consultation ofother MSAs. In addition, technical support teams should be provided with alltechnical monitoring tools necessary to detect sources of malfunctioning.

Help desk agents should have access to all consultation transactions of theapplication, for their Member State. If complementary information is necessaryfrom another Member State, they have to request it from the support centres of

that Member State.

E.6. Correction and patching by support agents

A very limited number of support agents should receive the right to directlychange information in the data tables and log files of the system.

Such patches should be submitted to a very precise and mandatory procedureinvolving at least two persons, and carefully logged. The standard administrationtools of the basic software (DBMS, FMS, network administration) should be

sufficient for such changes.

During the night, some rights to patch information might be delegated to other agents, but subject to very careful conditions, in particular on traceability of

operations.






E.7. Free format messages

E.7.a General information messages

It will certainly be necessary for the users of the EMCS, in particular usersinvolved in the functioning of the system (operators, supervisors, supportagents, etc.) to have the ability to exchange messages different from theapplication messages.

Such messages can have potentially any contents, concerning for instancethe functioning of applications (announcement for a maintenance break,etc.), support actions (requirement for a given operation), or exchange ofinformation that cannot be classified under any standard category.

The proposed solution is to extend the mechanism proposed for Movement

Verification and Mutual Assistance, namely to exchange messages createdusing the message builder through the AFIS infrastructure.

E.7.b Messages


M_GEN_INF Multi-purpose message Applying MSA Requested MSA

Message identifier appointed by the applying MSA

Applying Member State or 'EU' for the European Commission

Applying office or agent


Requested office or agent

Message identifier of a previous messageSubject (text with possible summaries in other languages)

Date of message

Type of message (from list of codes)

Gravity of message (from list of codes)

Body created using the message builder

E.7.c Message builder and message viewer

Message bodies to be exchanged will be composed using the message

builder utility put at the disposal of AFIS users interested in Excise movements,

according to national decision of the MSA.

It consists in freely assembling items of the thesaurus of terms in a messagearea. The user (computer operator, support agent, investigation officer, ELO,etc.) selects the convenient items from a palette made of all items of the

thesaurus, adds free texts, possibly with summaries in foreign languages, etc.

It should be possible to give the message body a tree structure of segments,themselves made of data items or of other segments. The message builder

must be able to store definitions of standard segments and of standardmessages to be re-used as useful. It is recommended that the MSAco-ordinates the management of standard segments and messages, for instance by granting their definition to the ELO.






The result is an EDIFACT message body that is attached to the Movement

Verification or Mutual Assistance message, or to the free format message.

A second utility, named message viewer, integrated with the AFIS client as

well, allows to display and print the message.

If found convenient, each Member State may define its own variant of themessage builder and of the message viewer, provided that the results arecompliant with the definition of messages produced by the standard utilities.

As long as the AFIS infrastructure is used, creating variants is notrecommended.

Development of the message builder and of the message viewer to be used

under AFIS is under the responsibility of TAXUD.





© Alcatel TITN Answare 2000 3AT 05006 AAAA DTZZA 02 F-1

APPENDIX F – NECESSARY INFRASTRUCTURE

F.1. National nodes

The computing Centre of each MSA must be provided with the necessaryequipment to fulfil its duties, namely:

• at least two application servers: the operational application platform and abackup system; the MSA may choose to have a third server for development

and testing, or to use the backup configuration when backup is notactivated

• a series of workstations for operation of the systems;

• a Local Area Network to interconnect all platforms of the computing Centre;

• an access to the CCN/CSI network;

• a security firewall (or equivalent) to protect the CCN/CSI infrastructureagainst intrusions;

• a connection with the internal network of the Administration, for access ofthe officials;

• a Telecommunication Centre to provide access of economic operators; thataccess must be secured so that at least one access point is always available,for instance by replicating front-ends;

• a security firewall (or equivalent) to protect the computing Centre against

intrusions;

• a connection with the help desk (that is supposed to be external) andpossibly with other national support centres;

• a security firewall (or equivalent) to protect the computing Centre against

intrusions coming from outside.

CCN

gateway FirewallFirewall

Access of

support(firewall)

Internal network of the MSA

Internal network of the computing Centre Application servers

Telecom

Centre

Firewall

The Member State Administration is free to re-use existing equipment such as the

Telecommunication Centre, but they should re-evaluate the required resourcesand plan necessary upgrades.

F.2. Connection of officials

The concerned offices are connected to the system through the internal

network of the MSA.

Normally, the application should run on general purpose workstations, i.e. theymay share it with other applications.






It is recommended that, as far as possible, the subsystem for identification and

authentication of official users is integrated into the general identification andauthentication system, if any is implemented in the MSA.

F.3. Connection of economic operatorsEach MSA is free to define the way of connection of the economic operators.

It is recommended to propose at least two solutions:

• one using EDIFACT messages exchanged through e-mail with larger

operators;

• one using a widely used standard interface such as the world wide web.

Many variants and additional solutions may be proposed; it is the responsibility of

the MSA to discuss those issues with professional organisations and to find

agreements.

For the case of EDI communication, as it often concerns large multinational

companies with subsidiaries in several Member States, it is proposed that thedefinition of EDIFACT messages be made and agreed at European level, with anoverall agreement of the MSAs and of representatives of those large companies.To do so, the DG should organise a particular working group open toprofessional organisations.

Conversely, the definition of the communication protocols and the integrationof EDIFACT messages in these protocols remain under the full responsibility ofeach MSA.

F.4. Interconnection of Member States Administrations

MSAs communicate directly between themselves, and with the services of theEuropean Commission (including the Application Centre), through the CCN/CSIinfrastructure.

Two interaction modes may be used, according to the case:

• synchronous calls, using the call or acall/getrply verbs of the CSI;

• asynchronous, using the put/get verbs of the CSI.

In general, the asynchronous mode should be preferred for intra-EUcommunications, but the synchronous mode may be used for consultations

where the time of response must be short.

Application messages exchanges use the EDIFACT format. The applicationmessages and associated interaction modes must be specified in the systemspecification made under the responsibility of the DG, and MSAs must strictly

conform to the specification of these interfaces.

F.5. Application CentreThe Application Centre must be provided with the necessary equipment to fulfil

its duties, namely:






• at least one application server to support:

• the certification platform;

• maintenance of tables of reference (even if these tables are produced

elsewhere);• collection and analysis of statistics.

• a series of workstations for support agents and for operation of the systems;

• a separated server for the web site of the Information Centre, with possibleaccess through the Internet;

• optionally, a second web server for access through the CCN/CSI webaccess;

• a Local Area Network to interconnect all platforms;

• an access to the CCN/CSI network;

• a security firewall to protect the CCN/CSI infrastructure against intrusions;

• a security firewall to protect the Application Centre against intrusions coming

from the web site;• a security firewall to protect the web server against intrusions from the

Internet.

CCN

gateway

Firewall

Internet

access

(firewall)

Firewall

Web server

Web server

(optional)





© Alcatel TITN Answare 2000 3AT 05006 AAAA DTZZA 02 G-1

APPENDIX G – AVAILABILITY, PERFORMANCES AND SECURITY

G.1. Estimation of traffic and volumes

The actual volume of the movements of goods under excise duty suspension isnot really well known and most generally underestimated. Therefore, rather thanextrapolating the partial statistics provided by the Member StatesAdministrations, we started from the number of registered operators, that ispresently around 80000 in Europe.

According to the country, operators may have very various sizes; most of themare small producers which send few trans-European movements per year. Other ones may send or receive tenths of movements per week, possibly per day insome periods of the year.

Based on an average of one movement sent or received per working day andper economic operator, this gives 8 million trans-European movements per year,in other terms 16 million operations (creation or discharge) per year throughout

Europe.

The average size of an electronic AAD may be estimated around 2 kilobytes, nottaking into account the technical overhead necessary for encoding or for

storage of data. In most cases, this size will be significantly smaller. Theassociated messages (consultation for verification, discharge message andreports of receipt, reports of control, etc.) may be estimated between 40% and100%, an average estimate being 60% if we consider that the Member States of

transit will be seldom involved.

To summarise, this gives between 2.8 and 4 kilobytes per movement crossingEurope, or 25.6 gigabytes per year.

The total traffic for a Member State may be from 1% to 25% of the total volume,resulting in traffic of 256 megabytes to 6.4 gigabytes per Member State and per year.

These figures should be considered when evaluating the necessary storage

capacity and the traffic between MSAs; the exchanges between economicoperators and the Information System of each MSA should be around 20% higher,taking into account the fact that some exchanges happen only between MSAs

but that the whole AAD is transferred between the consignor and the MSA inboth directions.

To evaluate the capacity of lines, we took the assumption that the whole traffic

happens during working days and working hours, and peak periods with a tripletraffic.

This gives the following summary figures, taking into account only "useful" data

and not the technical overhead due to formatting and to communicationprotocols:






Small Member State

LargeMember State

Storage capacity (megabytes - 3 years) 800 20000

Yearly trans-European traffic (megabytes) 256 6400

Traffic with the economic operators(megabytes)

300 7500

With other MSAs (CCN/CSI) (kilobytes per second)

0.133 3.3

With economic operators (kilobytes per second)

0.156 3.9

The figures given in the preceding table do not take into account intra-nationalmovements; it is up to each MSA to decide whether they want to use the EMCSfor national movements and to estimate the consequences on their equipment.There should be no consequences on the trans-European traffic, in particular no

data concerning these movements should transit on the CCN gateway.

G.2. Availability requirements

G.2.a Application

The requirement of availability of the system expressed by economicoperators is 365 days per year, 24 hours per day, with one hour programmedinterruption per month for maintenance.

In case of system breakdown, the maximum time to recover the full

functionality of the EMCS application node is one hour. The interface toeconomic operators (in particular the synchronous connection) shouldrecover in one quarter of hour.

G.2.b Data

Archived information on economic operators, on duty rates and on

movements must be available for a period of at least three years, more ifMember States agree so.

G.2.c Support

The help desk must be available 365 days per year, 24 hours per day. The helpdesk should answer each call not after the fourth ring of the telephone.

If the answer cannot be given immediately by the help desk operator a

reference number must be given to the user for further follow-up of the call; asupport agent should then call back the user to qualify the call within onehour during working hours and within two hours outside working hours.

Support centres do not mandatory have to be open permanently, providedthat urgent services are still available. A specific organisation could beproposed, involving support persons on call, or partial delegation of current

support tasks to the help desk. Permanent availability should be quoted.






G.3. Performance requirements

G.3.a Application

Standards of performance should be defined during the system specificationphase and set up according to each Member State.

Throughputs should be expressed by specifying the number of times eachmajor transaction must be processed in a given time; average performances

and peak performances should be specified according to the followingtable:

Transaction Average number oftransactions per hour

Peak number oftransactions per

minute

Consultation of operator Retrieval of 15 operators

Submission of AAD

Modification of AAD

etc.

In the same way, average and maximum times of response should be givenfor each major transaction in synchronous mode and in asynchronous mode(from MSA offices only); seen from the economic operator's, figures are not

significant in asynchronous mode as performances depend on externalproviders.

Transaction Averageresponse

time(synchronou

s mode)

Maximumresponse

time(synchronou

s mode)

Averageresponse

time(asynchrono

us mode)

Maximumresponse

time(asynchrono

us mode)

Consultation ofoperator

Retrieval of 15operators

Submission of AAD

Modification ofAAD

etc.

To give a rough estimate, the overall response time of a simple consultationbased on a precise identity should be between 5 and 10 seconds in

synchronous mode.

G.3.b Data

Access to archived information must be provided with an acceptable delay

that should not excess one full working day. If human action is necessary, theoperators must be provided with the convenient tools and procedures toidentify the archive supports to be re-loaded.






G.3.c Support

Standards of performance of the support infrastructure should be set-upduring the system specification phase.

For instance:

• 60% of calls to be solved in a delay of one hour;

• 80% of calls to be solved in a delay of four hours;

• 90% of calls to be solved in a delay of one day;

• 99% of calls to be solved in a delay of one week.

In all cases where the problem prevents new operations, a by-pass solutionshould be found.

G.4. Security requirements

In addition to the availability requirements described above, other security

requirements must be met by the system and all its components:

• ensure that only duly authorised users can access EMCS services, and thateach user accesses only those EMCS services for which he is authorised; in

particular, in compliance with each national applicable legislation on theprotection of data, ensure that only authorised persons access confidentialinformation;

• protect information exchanged through the EMCS against eavesdroppingand corruption during transfer (from trader to trader);

• protect EMCS information against eavesdropping and corruption when

stored;

• protect the partner Administrations and economic operators againstintrusion into their information systems via the EMCS communications;

• protect the EMCS server sites against intrusion via external communicationlinks;

• guarantee a given user that security measures taken by his partners do notcompromise his own security;

• keep all partners aware of their mutual security commitments.

Each partner must take the convenient measures, and prove that these

measures are actually and efficiently enforced.





© Alcatel TITN Answare 2000 3AT 05006 AAAA DTZZA 02 H-1

APPENDIX H – ESTIMATION OF COSTS

H.1. Introduction

The following estimations are based on assumptions that could prove notapplicable in each case; in particular, re-use of existing resources, such ashardware, software or organisations, has not been taken into account.

Therefore, each partner: European Commission, Member State, professional

organisation or economic operator, must re-assess these figures and adapt it toits own case.

As a general opinion, we think that the total amount of money for the wholeimplementation of the proposed system and for its yearly operation should not

exceed the presented figures.

To help the various partners in preparing their budgetary plans, we allocatedseparate amounts to each Group of functionality, where it could be done.

H.2. Directorate General for Taxation and the Customs Union

Cost

Costs in KEuro Investment Yearly cost

Management 4,000 300

Quality management 4,000 150

Co-ordination with Member States 2,700 100

Equipment (Application Centre) 1,000 150

System specification 3,600 200

Detailed design of interfaces 3,600 100

Developments (testing tools, commonapplication modules, on-demand developments

in operational phase)

2,000 600

Deployment, including monitoring and support 2,300 600

Information 4,000 450

Training 1,900 100

Operation (network and monitoring of the

system)

1,000 600

Provision for translations 1,000 100

Contingency 15% 4,000 500

Total 35,100 3,950






Profiles during the implementation

Central Project Office

Project officer 2 officials from T0-6 to T0+54

Assistant 1 assistant from T0 to T0+54

Excise specialists 2 officials from T0-6 to T0+54, possibly parttime after T0+30

Technical experts 2 to 5 persons from T0 to T0+54, accordingto the time

Quality Officer and deputy 2 persons from T0 to T0+54

Quality controllers According to the period, up to 10 personsduring the validation of specifications

Acceptance of applications Up to 6 persons to examine and validatethe products of the MSAs (entrusted to the

Application Centre)

Security experts 2 persons from T0 to T0+12, possibly parttime after T0+12

Security auditors up to 4 persons from T0+12 to T0+54,according to the time

Supervisor of co-ordination 1 person from T0 to T0+54

Specialised co-ordinators(development and deployment)

up to 6 persons from T0+6 to T0+64

System specification including detailed interface specification (in the casewhere made with in-house resources)

Central team 6 persons from T0 to T0+30

Assistants (modelling, writing,

review)

10 persons from T0 to T0+30

Experts delegated by the MSAs 20 persons from T0 to T0+12 then 10persons from T0+12 to T0+24

Development

Development teams According to the breakdown of Lots, from

one to five development teams, each ofthem from 3 to 10 persons, from T0+6 toT0+48

Deployment, monitoring and support

Central co-ordinators 2 persons from T0+18 to T0+54

Co-ordination assistants 2 more persons from T0+24 to T0+54Central support and operationduring the development andvalidation

4 to 6 persons from T0+24 to T0+54(entrusted to the Application Centre)

Information

Central co-ordinator 1 official from T0 to T0+54

Assistants 3 persons from T0 to T0+54

Training

Central co-ordinator 1 person from T0+6 to T0+54

Assistants 2 persons from T0+6 to T0+48

Technical trainers 2 to 4 persons from T0 to T0+24 (entrusted

to the Application Centre)






H.3. Member States Administrations

Cost

The relative weight of Groups I (plus utilities), II and III are considered equal to(respectively) 35, 45 and 20.

The deployment in MSA offices is affected half to Group I and half to Group II,while the whole deployment at economic operators' is affected to Group II,

resulting in relative weights of 10% and 90%. The whole deployment inoperational phase (change of location of offices, new economic operators) ispresented with Group II.

Costs in KEuro Investmentminimum

Yearly costminimum

Investmentmaximum

Yearly costmaximum

Management

including participationin the validation of the

system specification

1350 150 5100 300

Equipment 210 30 1,040 155

Development (GroupI)

717.50 105 1,123.50 150.50

Development (Group

II)

922.50 135 1,444.50 193.50

Development (GroupIII)

410 60 642 86

Deployment (Group I) 65 5 1,040 100

Deployment (Group II) 585 45 9,360 900Deployment (Group

III)

0 0 0 0

Information 655 275 4,350 950

Training 535 105 9,440 1,450

Support 1,300 575 8,600 4,150

Operation 200 250 2,600 1,250

Total 6,950 1,735 44,740 9,685

Profiles during the implementation

In the case where the system specification would be made by a in-house teamof the European Commission with the participation of the Member StatesAdministrations, each MSA should provide one to three persons, possibly part

time, during the system specification and the following months, from T0 to T0+12,and approximately the half of that manpower from T0+12 to T0+24.






Project Office, quality and co-ordination

Project officer 2 officials from T0-6 to T0+54, possibly parttime

Assistant possibly,1 assistant from T0 to T0+54

Excise specialists 1 or 2 officials from T0-6 to T0+54, possiblypart time

Technical experts 2 to 5 persons from T0 to T0+54, accordingto the time, in particular for:

• participation in the system

specification (validation);

• validation of the applicationspecification;

• national acceptance;

• presentation to the EC (systemacceptance).

Security specialists 1 or 2 persons from T0 + T0 to T0+30,possibly part time

Quality Officer and deputy 2 persons from T0 to T0+54, possibly part

time

Quality controllers According to the period

Development

Development teams According to the internal organisation,one or several development teams, from

T0+6 to T0+48

Deployment, monitoring and support

Central deployment for co-ordination

2 persons from T0+18 to T0+54, possiblypart time

Co-ordination assistants Possibly, 1 to 5 more persons from T0+24 to

T0+54

Deployers From 1 to 10 persons according to theMember State, from T0+24 to T0+54

Support and operation during thedevelopment and validation

From 2 to 10 persons during thedeployment period, possibly part time.

Information

Information co-ordinator 1 person from T0 to T0+54, possibly parttime

Assistants Possibly, up to 3 persons from T0 to T0+54Training

Training co-ordinator 1 person from T0+6 to T0+54, possibly parttime

Assistants Possibly, up to 2 persons from T0+6 toT0+48






H.4. Economic operators

The minimum figures describe the case of a small company already equippedwith a PC and an Internet access provider.

The maximum figures correspond to the case of a large company that developsa full application with integrated interface with the existing information system,and, to do so, acquires all necessary hardware and software.

Prices in KEuro Investment

(minimum)

Yearly cost

(minimum)

Investment

(maximum)

Yearly cost

(maximum)

Management According to size and solution – estimated between 10% and20% of other tasks

Systemspecification(participation)

Between 5 and 10 days per professional organisation.

Equipment 0 0 40 5

Development 0 0 100 10

Deployment 1 man*day Not significant 10 man*days 1 man*day

Information According to the size of the professional organisation –

estimated between 25 and 100 days per year and per organisationAccording to the size of the company – estimated between 2and 10 days per year and per person

Training According to the size of the professional organisation

According to the solution chosen – estimated between 2 and10 days per person.

Support Included in operation.

Operation Computerised operation should globally be less expensivethan the present paper-based procedures.




End of the document

Documents

Emcs Feasibility Study En