SECTION V: SYSTEM ADMINISTRATION...ECP1-ESS-FESSv3.91-5-SECTION V SYSTEM ADMINISTRATION Page 4 of 30 3 42 05/01/2012 Evolutive Maintenance incorporating RFCs FESS- …

DG TAXUD – EXCISE COMPUTERISATION PROJECT REF: ECP1-ESS-FESS-S.V

FESS - SECTION V - SYSTEM ADMINISTRATION VERSION: 3.91-EN

ECP1-ESS-FESSv3.91-5-SECTION V SYSTEM ADMINISTRATION Page 1 of 30

SECTION V: SYSTEM ADMINISTRATION



DOCUMENT HISTORY


Document History

Edi. Rev. Date Description Action (*) Sections

0 01 26/08/2004 Creation I All

0 02 13/08/2004 Updated after internal review U All

0 03 20/09/2004 Updated after feedback DG TAXUD U All

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

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

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

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

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

1 02 29/04/2005 SfA verification U All

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

1 04 27/03/2006 SfR U All

2 00 04/05/2006 SfA U All

2 01 25/08/2006 Corrective Maintenance following DG TAXUD

request with MS comments received on 4/07/2006

U All

2 02 30/03/2007 Internal review U All

2 02a 19/04/2007 Updated for internal review U All

2 03 27/04/2007 SfR U All

2 10 01/06/2007 SfA U All

2 11 17/09/2007 Incorporating FESS v2.10 Workshop Decisions

(ECWP 31).

Submitted for review to DG TAXUD.

U All

2 12 28/09/2007 Incorporating DG TAXUD comments.

Submitted for acceptance to DG TAXUD.

U All

2 13 03/10/2007 Implementing verification comments.

Re-submitted for acceptance to DG TAXUD.

U All

2 14 22/10/2007 Submitted for review to DG TAXUD. U All

2 15 05/11/2007 Submitted for acceptance to DG TAXUD. U All

3 00 08/11/2007 Submitted for publication to DG TAXUD. U All

3 01 26/03/2008 Implementing ECWP#35 WDs and FESS Known

Issues version 1.10. Submitted for review to DG

TAXUD.

U All


3 03 18/04/2008 Re-submitted for acceptance to DG TAXUD. U All



DOCUMENT HISTORY


3 10 05/10/2009 Evolutive Maintenance incorporating RFCs FESS-

001, FESS-002-REV1, FESS-004, FESS-005,

FESS-007, FESS-010, FESS-011-REV1, FESS-

013, FESS-015, FESS-016, FESS-017, FESS-018,

FESS-020, FESS-022, FESS-023, FESS-024,

FESS-026-REV1, FESS-027, FESS-028, FESS-

029, FESS-030, FESS-031, FESS-032-REV1,

FESS-033, FESS-034, FESS-035-REV1, FESS-

037-REV1, FESS-040 and FESS-041.


U All

3 11 02/11/2009 Implementing DG TAXUD comments and RFC

FESS-014.


U All

3 12 04/11/2009 Submitted for information to DG TAXUD. U All






FESS-052, FESS-053 and FESS-054.


U All

3 21 29/03/2010 Implementing DG TAXUD comments.


U All


003-REV2, FESS-050, FESS-051, FESS-055,



FESS-067 and FESS-068.


U All



U All


3 31 29/09/2010 Evolutive Maintenance incorporating RFC FESS-

070.


U All

3 32 04/10/2010 Submitted for acceptance to DG TAXUD. - -




FESS-083, and FESS-084.


U All



U All


3 41 04/02/2011 Removal of implementation of RFC FESS-080.

Re-submitted for information to DG TAXUD.

U All



DOCUMENT HISTORY



085, FESS-086, FESS-089 and FESS-095.


U All














U All



3 61 24/09/2012 Incorporating internal review comments and MS

verification comments:

• Update of Rule025 (Appendix D) to add the

items ‘37 = Movement verification request

reasons’ and ‘38 = Movement verification

actions’;

• Implementation of FESS CPs #4 and #8.

Submitted for information to DG TAXUD.

U All





U All



U All






FESS-153 and FESS-154.


U All





FESS-174, FESS-175, FESS-178 and FESS-180.


U All



199, FESS-203 and FESS-204.


U All



DOCUMENT HISTORY










FESS-196, FESS-197, FESS-198.


U All


3 81 19/12/2016 Submitted for Information under corrective

maintenance to DG TAXUD.

U All

3 82 24/03/2017 Corrective Maintenance incorporating RFCs FESS-


FESS-209.

Submitted for Information to DG TAXUD.

U All










FESS-242, FESS-243.


U All


3 91 13/12/2018 Incorporating MS verification comments.


U All

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



TABLE OF CONTENTS


Table of contents

1 ......... Introduction ......................................................................................................... 8

2 ......... System administration use cases ........................................................................ 9

2.1 Management of user accounts of officials (UC0.01) ....................................................... 9 2.2 Management of user accounts of economic operators (UC0.02) ................................. 11 2.3 Management of access rights of officials (UC0.03) ....................................................... 15 2.4 Management of access rights of economic operators (UC0.04) ................................... 19 2.5 Manage unavailability (UC0.07) .................................................................................... 20 2.6 Configuration management and version control (UC0.22) .......................................... 24 2.7 Data management (UC0.23)............................................................................................ 25 2.8 Fallback procedures (UC0.24) ........................................................................................ 26 2.9 Problem tracking (UC0.26) ............................................................................................. 27 2.10 Audit trail (UC0.25)......................................................................................................... 27

3 ......... Index of EBPs .................................................................................................... 29



TABLE OF FIGURES


Table of figures

FIGURE 1 PARTICIPANTS OF <UC0.01> MANAGEMENT OF USER ACCOUNTS OF OFFICIALS .................. 9 FIGURE 2 MANAGEMENT OF USER ACCOUNTS OF OFFICIALS – PROCESS FLOW DIAGRAM .................. 10 FIGURE 3 PARTICIPANTS OF <UC0.02> MANAGEMENT OF USER ACCOUNTS OF ECONOMIC

OPERATORS ........................................................................................................................ 12 FIGURE 4 MANAGEMENT OF USER ACCOUNTS OF ECONOMIC OPERATORS – PROCESS FLOW

DIAGRAM ............................................................................................................................ 13 FIGURE 5 PARTICIPANTS OF <UC0.03> MANAGEMENT OF ACCESS RIGHTS OF OFFICIALS ................. 15 FIGURE 6 MANAGEMENT OF ACCESS RIGHTS OF OFFICIALS – PROCESS FLOW DIAGRAM ................... 16 FIGURE 7 PARTICIPANTS OF <UC0.07> MANAGE UNAVAILABILITY .................................................. 20 FIGURE 8 MANAGE UNAVAILABILITY– PROCESS FLOW DIAGRAM ..................................................... 21



INTRODUCTION


1 Introduction

Section V of the FESS addresses the ancillary tasks in EMCS which can be grouped as

following:

• the first group of functionality covers user account names and access rights: In

particular, each Administration, i.e. the Commission and all MSAs, is responsible for

the management of user accounts and access rights, each for its own Domain. This

responsibility covers not only officials but economic operators as well. Identified

users are either persons, services, companies or external organisations;

• the second group of functionality covers the daily functioning of the system, in

particular availability of services and operations statistics;

• other functions at stake here are dealing with management of configuration, data and

exceptions.

Chapter 1 is the present Introduction.

Chapter 2 contains the System administration use cases covering:

• the management of user accounts and of access rights;

• the monitoring of the availability of services;

• general functions that are required for the support of the EMCS operations. The

related paragraphs (from 2.6 to 2.10 included) should be considered as

recommendations for the Member States.

Chapter 3 is an Index of EBPs (Elementary Business Processes) that compose the

functionality; in that Chapter, the Use cases and their EBPs are presented in numeric

order.



SYSTEM ADMINISTRATION USE CASES


2 System administration use cases

2.1 Management of user accounts of officials (UC0.01)

2.1.1 Overview

A user account is assigned to each official involved in EMCS, either in a MSA or in the

Common Domain services. Therefore, the MSAs and the Common Domain manage,

each for its Domain, user names and profiles for its officials including assimilated staff

such as agents of providers or support agents.

The details of processing completely depend on the own rules of the concerned Domain;

hence, the following description is provided as a guideline only.

2.1.2 Participants, motivations and commitments

MSA or CS

user account manager UC0.01-Management

of user accounts of officials

keeps the register of access authorisations up-to-date

Figure 1 Participants of <UC0.01> Management of user accounts of officials

Main actor

• the MSA or CS user account manager

▪ is responsible for managing officials' account information

Other actors

• none

2.1.3 General conditions

Trigger

• new users are to be registered or users are to be removed from the list of authorised

use

• credentials need to be changed;

Pre–conditions

• the MSA or CS user account manager is entitled to access the register of access

authorisations

Post–conditions

• the register of access authorisations is up-to-date





2.1.4 Process flow diagram

MSA or CS

user account manager

UC-001-110

Manage user accounts of officials

E_ user account manager starts accounts maintenance

R_ user account reference up-to-date

Figure 2 Management of user accounts of officials – Process flow diagram

2.1.5 Major events

E_User account manager starts accounts maintenance

Actor: MSA or CS user account manager

Location: Premises of the (MSA or Common Domain) central services

The decision depends on several criteria:

• new users are to be registered or users are to be removed from the list of authorised users;

• credentials need to be changed.

2.1.6 Minor events

None.





2.1.7 Processes

Manage user accounts of officials Process: UC-001-110



Processing mode: Up to MSA

Conditions: none

Description:

A user account is assigned to each official involved in EMCS; the Administration must maintain a particular list

of authorisations for EMCS, preferably integrated in their general access control lists (SSO system (Single Sign

ON system)...).

A user name is attached better to a person than to a service. For security reasons, service user accounts

potentially shared by several persons are not encouraged.

MSAs and the Commission enforce the convenient controls to ensure that the credentials of users are duly

protected.

For instance:

• if the credentials are passwords, enforce syntax rules and change rules;

• if the credentials are an electronic key pair, provide the relevant revocation and renewal support of public

key certificates.

Recommendations should be made to the administrative units where credentials are shared among several

persons, for additional protection measures while remaining able to recover if necessary.

Final situation:

• The register of access authorisations is up-to-date

2.1.8 Major result

R_user account reference up-to-date




• accounts created are available

• modified credentials take effect

2.1.9 Minor results

• None.

2.1.10 Messages

• None.

2.2 Management of user accounts of economic operators (UC0.02)

2.2.1 Overview

At least one user account is assigned to each registered economic operator at his first





registration.

In addition, if Member States accept it:

• each economic operator gets additional user accounts from his Member State (for

example to dispatch them to his staff);

• a tax warehouse gets a user account associated to its Excise number.

The user account is communicated to the operator along with his confidential

credentials (initial password, electronic key pair or equivalent).

These credentials are transferred through a particular secure procedure outside EMCS

application.

Management of user accounts of economic operators encompasses the revocation of

these credentials.

The details of processing completely depend on the own rules of the MSA; hence, the

following description is provided as a guideline only.


MSA user

account manager

UC0.02-Management of user

accounts of economic operators

keeps the register of access

authorisations up-to-date

Figure 3 Participants of <UC0.02> Management of user accounts of economic operators

Main actor

• the MSA user accounts manager

▪ keeps the economic operators register of access authorisations up-to-date

▪ is responsible for managing economic operators account information

Other actors

• none


Trigger

• new users are to be registered or users are to be removed from the list of authorised

use

• credentials need to be changed

Pre–conditions

• the MSA user accounts manager is entitled to access the register of access

authorisations

Post–conditions

• the register of access authorisations is up-to-date, according to the data managed by





the MSA user accounts manager


MSA user accounts manager

UC-002-110

Manage economic operators user accounts

E_ user accounts manager starts user accounts maintenance

R_ user accounts reference is up-to-date

Figure 4 Management of user accounts of economic operators – Process flow diagram

2.2.5 Major events

E_MSA user accounts manager starts user accounts maintenance

Actor: MSA user accounts manager

Location: MSA's premises

The decision depends on the following criteria:

• new economic operators are registered or economic operators are no longer registered.

2.2.6 Minor events

None.





2.2.7 Processes

Manage economic operator user accounts Process: UC-002-110



Processing mode: External

Event: the MSA user accounts manager wants to manage economic operators user accounts

Conditions: none.

Description:

A user account name is assigned to each registered economic operator at his first registration. It is

communicated to him along with his confidential credentials (initial password, electronic key pair or

equivalent). These credentials are transferred through a particular secure procedure outside EMCS application.

If the MSA accepts it and a registered economic operator needs it, he requests additional user accounts name(s).

There is no difference in access rights of the various user names assigned to the same economic operator

(Excise number).

If the MSA accepts it, each tax warehouse with a separate Excise number receives one user account name as

well.

The scope of a user name is limited to the national domain; in particular, it cannot be used for connection to the

application of another Member State.

MSAs enforce the convenient controls to ensure that the credentials of users are duly protected. This depends on

the solution chosen for the Member State.

For instance:

• if the credentials are passwords, enforce syntax rules and change rules;

• if the credentials are an electronic key pair, provide the relevant revocation and renewal support of public

key certificates.

Recommendations should be made to the economic operators where credentials are shared among several

persons, for additional protection measures while remaining able to recover if necessary.

Final situation:

• the register of access authorisations is up-to-date.

2.2.8 Major result

R_user accounts reference is up-to-date




• user accounts created are available

2.2.9 Minor results

None.

2.2.10 Messages

None.





2.3 Management of access rights of officials (UC0.03)

2.3.1 Overview

The MSAs and the Common Domain, each for its Domain, determine how access rights

are assigned to officials and which functions they have the right to access.

The following proposes the classical user/profile mechanism that is used by NCTS, i.e.:

• a user accounts manager creates user identities and, where necessary, user

credentials; this is the object of use case 0.01;

• an access control right manager maintains user profiles, i.e. lists of functionalities

that will be allowed to users, and registers each user under one or several profiles;

this is the object of the present use case.

The details of processing completely depend on the own rules of the concerned Domain;

hence, the following description is provided as a guideline only.


MSA or CS

access control manager

UC0.03-Management

of access rights of officials

keeps the credentials register up-to-date

Figure 5 Participants of <UC0.03> Management of access rights of officials

Main actor

• the MSA or CS access control manager

▪ is responsible for managing officials' access rights information

Other actors

• none


Trigger

• the access rights of already registered users (officials) are to be changed.

Pre–conditions

• the MSA or CS access control manager is entitled to access the register of

authorisations

Post–conditions

• user profiles and assignment of profiles to users are up-to-date






MSA or CS access control manager

UC-003-110

Manage user profiles of officials

E_Access control manager has to manage profiles

R_User profiles up to date

UC-003-120

Manage enrolment of officials into profiles

E_Access control manager has to assign profiles

R_Access rights up-to-date

Figure 6 Management of access rights of officials – Process flow Diagram

2.3.5 Major events

E_access control manager has to manage profiles

Actor: MSA or CS access control manager


• the functionality has to be re-organised according to a new sharing of tasks.

E_access control has to assign profiles



• the access rights of some users (new or not) have to change;

• new users need to have a user profile assigned.

2.3.6 Minor events

None.





2.3.7 Processes

Manage user profiles of officials Process: UC-003-110




Conditions: none

Description:

Each Administration freely determines the definition of user profiles by giving to each profile a name and a list

of basic functionality that will be granted to that profile.

A profile is composed of a series of basic functions composing the EMCS application; these are not only

functions defined in the FESS but complementary functions specific to the concerned Domain as well.

A generic list of profiles (FESS functionality only) is proposed in Appendix E.

Final situation:

• the user profiles are up-to-date

Manage enrolment of officials into profiles Process: UC-003-120




Conditions: the concerned user identities and user profiles pre-exist

Description:

Each Administration freely determines which user will belong to which profile. By a combination of several

profiles, it is possible to restrict the user rights of each agent to the only functions that he has to perform.

Final situation:

• the access rights register is up-to-date

2.3.8 Major results

R_User profiles up to date



• the list of user profiles for officials is up-to-date





R_Access rights up to date



• the appointment of access rights to the authorised officials is up-to-date

• modified access rights take effect

2.3.9 Minor results

None.

2.3.10 Messages

None.





2.4 Management of access rights of economic operators (UC0.04)

2.4.1 Overview

A list of user profiles and related functions for economic operators is given in

Appendix E.

The user profiles of economic operators are pre-built as shown in the second part of

Appendix E and depend on a set of attributes of the SEED register (authorised

warehouse keeper, registered consignee, temporary registered consignee, registered

consignor).

The access rights of the operator depend on that profile and only on that profile.

So, the only useful link is the relationship between Excise number and account name

and each economic operator has access to the exact range of functions (use cases) that

corresponds to his profile.

There is therefore no specific function for the management of access rights of economic

operators.





2.5 Manage unavailability (UC0.07)

2.5.1 Overview

The role of this use case is to enable a MSA to announce the unavailability of

application services, so that the other Member States are informed in order to take the

necessary actions in their own system to cope with that situation. In such cases, the

MSAs may refer to the FRS [R7] that handles business exceptions and related

responses.

This is achieved by each MSA sending its unavailability to the Common Domain

central services (CS/MISE); In turn, the CS/MISE disseminates the information to each

MSA.

Three possible types of business process unavailability are defined:

• Scheduled: An unavailability planned in advance by an NEA for any

implemented and open business service having specific begin and end date and

time;

• Unscheduled: An unplanned unavailability by an NEA for any implemented and

open business service having specific begin date and time and optionally end

date and time;

• Non-Implemented: An unavailability that reports the non-implementation of a

particular business service.


UC0.07 – manage scheduled unavailability

Informs central services on

unavailability

Disseminates

information Common domain central

service

MSA central

services

MSA application

Receives and stores

information

Figure 7 Participants of <UC0.07> Manage unavailability

Main actor

• the MSA central services

▪ prepares and submits the unavailability for the national application

Other actors

• the Common Domain central service

▪ receives and disseminates unavailability.

• the MSA application

▪ receives and stores information on unavailability






Trigger

• a MSA wants to inform the other MSA of anticipated unavailability of functional

services

Pre–conditions

• none

Post–conditions

• all MSAs are informed of the unavailability


N_TAU_REF Common Domain central

service

MSA central services MSA application

UC-007-110

Prepare and send unavailability information

UC-007-310

Receive and disseminate

unavailability information

(IE770:C_AVA_DAT)

E_Manage Unavailability Registration

For each Member State

UC-007-210

Receive unavailability information

R_MSA informed of unavailability

(IE770:C_AVA_DAT)

Figure 8 Manage unavailability– Process flow diagram





2.5.5 Major event

E_Manage Unavailability Registration

Actor: MSA Central Services

Location: premises of the MSA

Unavailability of one or several of the MSA business services is registered by the System Administrator (e.g. for

system administration or maintenance purposes)

2.5.6 Minor events

None

2.5.7 Processes

Prepare and send unavailability information Process: UC-007-110

Actor: MSA Central Services

Location: premises of the MSA Central Services

Processing mode: Semi-automatic

Constraint: none

Description:

A MSA officer in the Central Services prepares an unavailability message (IE770:C_AVA_DAT) containing:

• the code of the Member State for which unavailability is announced;

• the type of unavailability (i.e. scheduled, unscheduled, or non-implemented);

• the business processes for which an unavailability is registered, among: ▪ Support for All Functionality (i.e. all FESS business process); ▪ Support for EMCS - Central Circuit – External Domain Functionality (i.e., all business processes of UC2.01, UC2.05, UC2.06,

UC2.07, UC2.10, UC2.12, UC2.33, UC2.34, UC2.36, UC2.43, UC2.44 and UC2.46 of Section II of FESS); ▪ Support for EMCS - Central Circuit – Common Domain Functionality (i.e. all business processes of Section II of FESS);

▪ Support for EMCS - Follow-up and Collaboration Functionality (i.e. all business process of Section IV of FESS);

▪ Support for National SEED Functionality (i.e. all business processes of Section III of FESS that are executed by the MSA central

services, i.e. national SEED).

• for each service for which unavailability is registered, begin date and time of unavailability;

• if the unavailability is scheduled, for each service end date and time of unavailability;

• if the unavailability is unscheduled or non-implemented, for each service, optionally, end date and time.

The officer sends the prepared message (IE770:C_AVA_DAT) to the Common Domain Central Services

(CS/MISE).

Final situation:

The Common Domain is in a position to dispatch unavailability information to all MSAs.





Receive and disseminate unavailability information Process: UC-007-310

Actor: Common Domain Central Services

Location: CS/MISE

Processing mode: Automatic

Constraint: none

Description:

The Common Domain central services application receives the unavailability message (IE770:C_AVA_DAT).

It immediately and automatically forwards it to all MSAs (including to the issuing MSA).

Final situation:

• the registered unavailability information has been sent to all MSAs

Receive unavailability information Process: UC-007-210

Actor: MSA application

Location: premises of each MSA

Processing mode: Automatic

Constraint: none

Description:

The MSA application receives the unavailability message (IE770:C_AVA_DAT).

Final situation:

• each MSA is informed of the unavailability of the issuing actor.

2.5.8 Major result

R_MSA informed of unavailability

Actor: MSA application

Location: premises of each MSA

• The MSA is in a position to apply the steps it defined for such a case, e.g. configure its own application to

queue functional requests or refuse applications for the period of unavailability.

2.5.9 Minor results

None

2.5.10 Messages

• IE770:C_AVA_DAT business process unavailability





2.6 Configuration management and version control (UC0.22)

2.6.1 Overview

Main functionality for configuration management & version control includes:

• computer inventory: consists in recording hardware and software configurations of

servers and workstations. The inventory should also provide information about the

system such as available disk space, processor type, operating system, version;

• software management: consists in software distribution and software installation;

commercial off-the-shelf software (COTS), custom software and even simple files.

Software distribution should be based on the inventory information;

• change control management, including software promotion and version control;

• dependencies management.

This kind of functionality is well met by COTS products. The designer of the future

Centrally Developed EMCS Application (CDEA) and of each Nationally Developed

EMCS application will have to propose a technical choice to achieve that

implementation.





2.7 Data management (UC0.23)

2.7.1 Overview

The main functionality for data management includes:

• incremental backup;

• automated backup schedules;

• backup failure alerts;

• data restoring;

• on-line catalogue of archived files and backup versions.

This kind of functionality is well met by COTS. The designer of the future Centrally

Developed EMCS Application (CDEA) and of each Nationally Developed EMCS

application (NDEA) will have to propose a technical choice to achieve that

implementation.





2.8 Fallback procedures (UC0.24)

2.8.1 Overview

Different kinds of failures considered hereafter are:

• the network is faulty or down either in the Common Domain or inside a national

administration or between a MSA and an economic operator;

• the EMCS application of the common domain, of a MSA or of an economic operator

is partially or totally down;

• inconsistencies between the information concerning the same entity kept by different

parties (in particular by MSAs);

• other irrelevant business situations.

The technical specification of EMCS will recommend specific solutions to prevent most

of the possible cases of failures from arising. It covers such areas as resilience and

hardware redundancy to be incorporated in the design of hardware and software of the

applications.

If however the technical resources break down, the FRS [R7] examines the solution

elements that participate in solving issues for each failing use case.





2.9 Problem tracking (UC0.26)

2.9.1 Overview

To assist the help desk in its task, it is helpful to provide the following:

• a tracking system to record and support the follow up of any detected problem. The

main features of that tool should allow for recording:

▪ date at which the problem appeared;

▪ category of the problem;

▪ priority (urgency);

▪ who has notified the problem;

▪ actions taken;

▪ a problem status (e.g. “pending”);

▪ date at which the action was taken;

▪ date by which the user expects information;

▪ cross reference to related problems;

▪ possible additional comments.

• the system must present this information in a tabular view, so that the help desk has a

picture of the problem tracking history. It must also provide problem report printing

and statistics reporting.

• a communication system with the central help desk to transfer files containing a

description of the problem and/or “trace” files produced by processes.

Both systems are well met by COTS.

Refer to the forthcoming COS (Central Operations Specification) that handles the

problem tracking.

2.10 Audit trail (UC0.25)

2.10.1 Overview

The EMCS includes features for automatic national recording of sensitive data base

transactions carried out within the system. Except when triggered by support agents

who have special rights, all these transactions are completed by a function of the

automated system. The recording of this information must be performed by each

application function. These transactions concern the day to day EMCS business

(submission of movements, changes, receipt, etc.) and general database management.

The system must record, in specific entities, these transactions with the following

information:

• the date;

• the type of transaction;

• the entity identifier (List of Offices, movement history);

• entity keys (ARC, Excise number);

• change of state associated with related key information (new movement state);

• a system filled field depending on the concerned entity and transition (if relevant);





• identification of the actor who initially submitted the concerned use case (economic

operator or official).

To analyse that audit trail, Authorised Persons need a system in order to be able to:

• list all actions in a tabular view with the following columns: action date, action type,

entity identifier, identification of the Officer. Additional features include:

▪ this list sorted by ascending date and descending date;

▪ this list filtered combining the following criteria: date between two given dates,

ARC, actor, type of operation;

▪ print the current selection.

The analysis is performed by a specific application.

This kind of functionality is well met by COTS. The designer of the future Centrally

Developed EMCS Application (CDEA) and of each Nationally Developed EMCS

application will have to propose a technical choice to achieve that implementation.

Refer to the forthcoming SESS (Security Excise System Specification) that handles the

audit trail.



INDEX OF EBPS


3 Index of EBPs

UC0.01 Management of user accounts of officials

UC-001-110 Manage user accounts of officials ................................................................................................ 11

UC0.02 Management of user accounts of economic operators

UC-002-110 Manage economic operator user accounts ................................................................................... 14

UC0.03 Management of access rights of officials

UC-003-110 Manage user profiles of officials .................................................................................................. 17

UC-003-120 Manage enrolment of officials into profiles ................................................................................. 17

UC0.07 Manage unavailability

UC-007-110 Prepare and send unavailability information ................................................................................ 22

UC-007-210 Receive unavailability information .............................................................................................. 23

UC-007-310 Receive and disseminate unavailability information .................................................................... 23



INDEX OF EBPS


[End of section]

Documents

SECTION V: SYSTEM ADMINISTRATION...ECP1-ESS-FESSv3.91-5-SECTION V SYSTEM ADMINISTRATION Page 4 of 30 3 42 05/01/2012 Evolutive Maintenance incorporating RFCs FESS- …