Mini-1SS - System design - Registration Process

(1)

OWNER:

DG TAXUD

ISSUE DATE:

18/05/2012

VERSION:

1.03

Taxation and Customs Union DG FITSDEV2 Project

Specifications, Development, Maintenance and Support of European IT Services in the area of taxation and excise

Subject:

Mini-1SS - System design - Registration Process (FITSDEV2-SC12-SDRP-Mini-1SS)

Framework Contract TAXUD/2008/CC/095 Specific contract Nr 12

(2)

Document History

Version Release Date Author Description

0.01 29/09/2011 Rudy Kech Initial version (SfR)

1.00 03/11/2011 Mathieu Triquoit Implementation of DG TAXUD’s comments Submitted for Acceptance (SfA)

1.01 06/03/2012 Tibor Sutoris Version Submitted for Review (SfR)

1.02 25/03/2012 Peter Macfarlane

Add issuedBy attribute to NationalTaxReference

Add CompanyName to VAT Identification of NETP in Other MS

Add Bank Account information to registration messages

Other minor changes following quality review

1.03 18/05/2012 Peter Macfarlane

Implement KEL

Implement MS Comments from third workshop Update for latest version of the legal base

Reviews

Version Review Date Reviewer Position

0.01 29/09/2011 Mathieu Triquoit Quality Reviewer

1.00 03/11/2011 Hubert Legros Administrative Project Manager 1.01 06/03/2012 Hubert Legros Administrative Project Manager 1.02 25/03/2012 Hubert Legros Administrative Project Manager

1.03 18/05/2012 Tibor Sutoris Quality Reviewer

(3)

List of Tables

Table 1: Reference documents ... 3

Table 2: Abbreviations and Acronyms... 3

Table 3: Definitions... 3

Table 4: Actors ... 3

Table 5: Domains ... 3

Table 6: NETP requests ... 3

Table 7: MSID - NETP exclusion... 3

Table 8: Other MS – Request information from MSID ... 3

Table 9: Process Application sub-process ... 3

Table 10: CIR – Registration ... 3

Table 11: Process Registration Update sub-process ... 3

Table 12: Process Exclusion sub-process ... 3

Table 13: XML Schema Definition – valid values of applicationId per special scheme ... 3

Table 14: XML Schema Definition – Attributes and Elements in the TraderID_Type... 3

Table 15: XML Schema Definition – Attributes and Elements in the BaseTrader_Type... 3

Table 16: XML Schema Definition – Attributes and Elements in the SchemeDetails_Type... 3

Table 17: XML Schema Definition – Exclusion Codes... 3

Table 18: XML Schema Definition – Attributes and Elements in the FixedEstablishment_Type... 3

Table 19: XML Schema Definition – Attributes and Elements in the EUTraderIDType_Type... 3

Table 20: Elements and content of the error message ... 3

Table 21: Technical errors... 3

Table 22: XML Schema Definition – Elements of an address... 3

Table 23: XML Schema Definition – Elements of a name... 3

Table 24: Differences between the present and the new VoeS ... 3

Table 25: Guidelines BPMN: Flow objects ... 3

Table 26: Guidelines BPMN: Connecting objects ... 3

Table 27: Guidelines BPMN: Swimlanes... 3

Table 28: Guidelines BPMN: Artefacts... 3

Table 29: BPMN 2.0 Level 2 Flow objects ... 3

Table 30: Data Model notations ... 3

(6)

List of Figures

Figure 1: Mini-1SS domains... 3

Figure 2: Registration process structure ... 3

Figure 3: Registration Process - High-level BPM... 3

Figure 4: Process Application sub-process... 3

Figure 5: Process Registration Update sub-process ... 3

Figure 6: Process Exclusion sub-process... 3

Figure 7: XML Schema definition - FiscalisMessage... 3

Figure 8: XML Schema definition - Header... 3

Figure 9: XML Schema definition - Body... 3

Figure 10: XML Schema Definition – RegistrationsInformation... 3

Figure 11: XML Schema Definition – Registration_Type... 3

Figure 12: XML Schema Definition – TraderID_Type... 3

Figure 13: XML Schema Definition – RegistrationDetail_Type... 3

Figure 14: XML Schema Definition – Exclusion_Type... 3

Figure 15: XML Schema Definition – RegistrationDetailsRequest_Type... 3

Figure 16: XML Schema Definition – RequestedRegistrationDetails_Type... 3

Figure 17: Error message ... 3

Figure 18: XML Schema Definition – AddressFreeOrStruct_Type... 3

Figure 19: XML Schema Definition – NameStruct_Type... 3

Figure 20: Conceptual database schema ... 3

Figure 21: Overall architecture... 3

Figure 22: Logical architecture... 3

Figure 23: Store-and-forward technique ... 3

Figure 24: Applications communication using dedicated queues ... 3

(7)

1 INTRODUCTION

1.1 O BJECTIVE OF THIS D OCUMENT

The System Design (SD) document describes the Registration Process of Mini One-Stop-Shop (M1SS) special scheme and makes a link between the different elements of the system to ease the global understanding. It is process driven and contains Business Process Modelling (BPM) models.

The technical solution will be described in more detail in the Functional and Technical specifications.

1.2 I NTENDED A UDIENCE

The intended audience of this document is:

• DG TAXUD/R4;

• DG TAXUD/C1;

• DG TAXUD/C4;

• Member States Administrations (MSAs);

• FITSDEV2.

1.3 S TRUCTURE OF THIS D OCUMENT

Chapter 1 Introduction: introduces the purpose and the structure of this document;

Chapter 2 Related Documents: defines the documents the current document is referring to and the documents applicable to the current document;

Chapter 3 Terminology: describes the acronyms and the definitions used in this document;

Chapter 4 Executive summary: provides a summary of the main aspects of this document;

Chapter 5 Overview: provides an overall picture of the system. It describes the sub-processes, the triggers to start the process, the conditions applicable between sub-process and the constraints;

Chapter 6 XML schema: defines the messages exchanged with the Member States;

Chapter 7 Conceptual Database schema: proposes a database schema that could be used by the MSID;

Chapter 8 System architecture: provides an overall picture of the architecture of the system;

Chapter 9 Annexes: contains the annexes of the SD.

(8)

1.4 D OCUMENT C ONVENTIONS

Reference documents are shown in square brackets [].

Excerpts from the legislation are identified by brackets “” and by Italic font. A reference is followed by its exact reference in bold, as in:

“Member States shall permit any taxable person not established within the Community supplying telecommunications, broadcasting or electronic services to a non-taxable person who is established in a Member State or has his permanent address or usually resides in a Member State, to use this special scheme. This scheme applies to all those services supplied within the Community.”

[DIR06/112], Art. 359.

The notation used to describe the processes is the Business Process Model and Notation (BPMN) 2.0 of Microsoft Visio and is described in section 9.1 Guidelines BPMN.

(9)

2 RELATED DOCUMENTS

2.1 R EFERENCE D OCUMENTS

Ref. Title Reference Version Date

R01 VAT Refund – Technical Specifications FITSDEV-TS-VAT Refund 1.07 30/07/2010 R02 VAT on e-Services -Technical

Specifications

VAT on e-Services -

TS_v5.2.doc 5.2 03/05/2005

R03

Draft Commission Implementing Regulation

COMMISSION IMPLEMENTING REGULATION

N/A 15/05/2012¹

R04 Draft Council regulation Draft Council regulation amending Implementing Regulation (EU) No 282/2011

N/A 15/05/2011²

DIR0 8/8

Council Directive 2008/8/EC of 12 February 2008 amending Directive 2006/112/EC as regards the place of supply of services

Official Journal L 44, p 11, 20/02/2008 http://eur-

lex.europa.eu/LexUriServ/LexUriServ.d o?uri=OJ:L:2008:044:0011:0022:EN:PD F

32008L0008 N/A 20/02/2008

DIR0 6/112

Council Directive 2006/112/EC of 28 November 2006 on the common system of value added tax

Official Journal L 347, 11/12/2006 Including amendments up to 01/01/2007

http://eur-

lex.europa.eu/LexUriServ/LexUriServ.d o?uri=CONSLEG:2006L0112:20070101 :EN:PDF

Any reference to this Directive means, this directive as amended by Directive Council Directive 2008/8/EC.

32006L0112 M1 01/01/2007

1 Date of reception from DG TAXUD.

2 Date of reception from DG TAXUD.

(10)

Ref. Title Reference Version Date REG1

0/904

COUNCIL REGULATION (EU) No 904/2010 of 7 October 2010 on administrative cooperation and combating fraud in the field of value added tax (recast)

Official Journal L 268, 07/10/2010 http://eur-

32010R0904 N/A 07/10/2010

REG2 82/11

COUNCIL IMPLEMENTING

REGULATION (EU) No 282/2011 of 15 March 2011 laying down implementing measures for Directive 2006/112/EC on the common system of value added tax (recast)

Official Journal L 77, p 1, 15/03/2011 http://eur-

32011R0282 N/A 15/03/2011

[ISO_

3166]

ISO 3166-1: Codes for the

representation of names of countries and their subdivisions – Part 1: Country codes

http://epp.eurostat.ec.europa.eu/statistic s_explained/index.php/Tutorial:Country _codes_and_protocol_order

N/A N/A N/A

Table 1: Reference documents

(11)

3 TERMINOLOGY

3.1 A BBREVIATIONS AND A CRONYMS

Definition Meaning

Art. Article

BIC Business Identifier Code

BPM Business Process Modelling

BPMN Business Process Modelling Notation

CCN Common Communication Network

CIR Commission Implementing Regulation

CSI Common System Interface

DG TAXUD Directorate-General Taxation and Customs Union

E Event

EU European Union

EU NETP NETP not established in the Member State of consumption but established in the Community

FIS FISCALIS Information Systems

FITS FISCALIS Information Technology Services

FITSDEV2 FITS Development

GW Gateway

IBAN International Bank Account Number

ID Identification

IP Internet Protocol

ISO International Organization for Standardization

M Mandatory

M1SS Mini One Stop Shop

MS Member State

MSA MS Administration

MSCON MS of Consumption

MSEST MS of Establishment

MSID MS of Identification

N/A Not Applicable

NA National Application

NETP Non-Established Taxable Person

Non-EU NETP NETP not established within the Community

(12)

P Process

PI Primary Identifier

SC Specific Contract

SD System Design

T Task

TP Taxable Person

UC Use Case

UTC Coordinated Universal Time

VAT Value Added Tax

VoeS VAT-on-e-Services

XML Extensible Mark-up Language

Table 2: Abbreviations and Acronyms

3.2 D EFINITIONS

Actor An actor is someone or something outside the system that interacts with the system.

Completeness The completeness is the fact that the data provided correspond to the data structure and that all mandatory data elements are present.

Correctness The correctness is the matching between the format of the data provided and the data structure.

ISO numeric 3 country code 3 digits integer ISO country code as defined in [ISO_3166].

Non-Union scheme Non-Union scheme means the special scheme for telecommunications services, broadcasting services or electronic services supplied by taxable persons not established within the Community provided for in Section 2 of Chapter 6 of Title XII of Directive 2006/112/EC.

Primary key The primary key of a relational table uniquely identifies each record in the table.

Union scheme Union scheme means the special scheme for telecommunications services, broadcasting services or electronic services supplied by taxable persons established within the Community but not in the Member State of consumption provided for in Section 3 of Chapter 6 of Title XII of Directive 2006/112/EC.

Table 3: Definitions

(13)

4 EXECUTIVE SUMMARY

The Mini-One-Stop-Shop (M1SS) System Design is a series of three documents describing the main processes of the system, namely Registration, VAT Return and Payments. The present document looks at the Registration process. Note that the supporting legislation for the specifications is still under discussion. This document reflects the current thinking and it will be updated if necessary as the legal framework evolves.

It is not the aim of the document to specify the processes at national level or the way the Member States communicate with the taxable persons. Nevertheless, this document may have impact of the Non-Established Taxable Persons (NETPs), e.g. as regards to the data that they have to provide.

This proposal defines the exchange of data between MSs via two different mechanisms:

• A mechanism to broadcast all new registrations and exclusions to all Member States;

• A query mechanism to access the national databases (DBs). This allows an efficient exchange of information between MSs.

The data elements to be exchanged are mainly issued from the SCAC587 document. Nevertheless, some technical information had to be added to ensure the proper functioning of the system.

The proposed exchange communication channel is CCN/CSI. A chapter proposes typical solutions that can be put in place by MSs.

(14)

5 OVERVIEW

The overview describes the actors and the processes involved in the Registration Process.

5.1 B USINESS OBJECTIVE OF THE PROCESS

The objective of the Registration Process is to allow any taxable person (TP) not established in the European Union (EU) or not established in the MS of Consumption (MSCON) and supplying telecommunication services, broadcasting services or electronic services to register to the special scheme covered by the M1SS and VAT-on-e-Services (VoeS), as far as all the conditions are met.

5.2 A CTORS

The actors section describes the different actors involved in the Registration Process.

• Non-Established Taxable Person (NETP);

• Member State of Consumption (MSCON);

• Member State of Establishment (MSEST);

• Member State of Identification (MSID);

• Other Member States.

The table below provides the definition of the actors according to the Directive [DIR06/112]. Actors Definition from the legal base

NETP

There are two types of NETP:

1) “ taxable person not established within the Community means a taxable person who has not established his business in the territory of the Community and who has no fixed establishment there and who is not otherwise required to be identified for VAT purposes;”, [DIR06/112], Art.

358a

The acronym Non-EU NETP is used in this document to refer to this actor.

2) “ taxable person not established in the Member State of consumption means a taxable person who has established his business in the territory of the Community or has a fixed establishment there but has not established his business and has no fixed establishment within the territory of the Member State of consumption;”, [DIR06/112], Art. 369a

The acronym EU NETP is used in this document to refer to this actor.

MSCON

“ Member State of consumption means the Member State in which the supply of the

telecommunications, broadcasting or electronic services is deemed to take place according to Article 58;”, [DIR06/112], Art. 358

MSEST

“Where a taxable person has not established his business in the Community, but has more than one fixed establishment therein, the Member State of identification shall be the Member State with a fixed establishment where that taxable person indicates that he will make use of this special scheme. The taxable person shall be bound by this decision for the calendar year concerned and the two calendar years following.

A Member State of Establishment is therefore a Member State where the taxable person has a fixed establishment but which is not his Member State of Identification.”, [DIR06/112], Art. 369a.

(15)

Actors Definition from the legal base

MSID

For an NETP in the sense of [DIR06/112], Art. 358a.

“Member State of identification” means the Member State which the taxable person not established within the Community chooses to contact to state when his activity as a taxable person within the territory of the Community commences in accordance with the provisions of this Section.”, [DIR06/112], Art. 358a.

For an NETP in the sense of [DIR06/112], Art. 369a.

“Member State of identification” means the Member State in the territory of which the taxable person has established his business or, if he has not established his business in the Community, where he has a fixed establishment.”, [DIR06/112], Art. 369a.

“A taxable person with more than one fixed establishment in the Community may indicate any of the Member States in which he is established as the Member State of identification pursuant to the second paragraph of Article 369a of Directive 2006/112/EC.” [R04], Art. 57d.

Other MS All MS except MSID.

Table 4: Actors

5.3 D OMAINS

As depicted on Figure 1, the main Mini-1SS domain is divided into three particular domains:

• Common domain;

• National domain;

• External domain.

These domains are described in Table 5.

Figure 1: Mini-1SS domains

(16)

Domain Definition

Common domain The Common domain is the environment that allows the various Member State Administrations to intercommunicate and falls under the responsibility of the Commission.

National domain

The National domain is located in the Member State Administration Environment. The National domain operates on the one hand as national network, which allows the national stakeholders to communicate to each other. On the other hand, it provides the national application (nationally or centrally developed), which allows the MSA to exchange information with the NAs in all other countries, and with the Commission if applicable.

External domain The External domain is the environment between the NETP’s applications and the NA. The network with the Economic Operators differs from one country to another.

Table 5: Domains

5.4 R EGISTRATION P ROCESS S TRUCTURE

The structure of the processes, concentrating on the Registration process, is depicted in Figure 2.

Process Registration information request

Process NETP's exclusion

Process Application

Process Registration

update

Process Exclusion Registration

main processes

VAT Return Process

Registration sub-processes

Registration Process

Payment Process Mini-1SS main

processes

Process NETP's registration

Figure 2: Registration process structure

The Registration process covers the following processes:

• Process NETP’s registration – the Registration request received from the NETP is processed by the MSID and subsequently transmitted to the Other MS. The process also covers the activities related to update of the registration information or exclusion of the NETP from the special scheme;

• Process Registration information request – the MSID processes the information request received from the Other MS. The information request relates to the NETP’s registration data;

(17)

• Process NETP’s exclusion – the MSID processes NETP’s voluntary request to cease using the special scheme or to change MSID while still fulfilling all criteria to be registered for the special scheme.

(18)

5.5 R EGISTRATION P ROCESS - H IGH - LEVEL BPM

The high-level BPM shows the collaborations between actors and the sequence between the tasks (T) involved in the process.³

Other MSNETPMSID

Figure 3: Registration Process - High-level BPM

The Registration Process groups the tasks related to three sub-processes:

1. The NETP makes a request for registration, for voluntary exclusion or for update of its registration information to the MSID or notifies the MSID that it has changed his MSID;

2. The MSID decides to exclude an NETP as described in [DIR06/112], Art. 363 and 369e;

3. An MS requests registration information of a given NETP from an MSID, as mentioned in [REG10/904], Art.17.

3 The notation used is the BPMN 2.0 described in section 9.1 Guidelines BPMN.

(19)

5.5.1 NETP

MAKES REQUESTS TO THE

MSID

The process starts when the NETP sends a request to the MSID. Regarding changes to the registration information, the NETP’s obligation is defined in [CIR11/282], Art. 57f as follows:

“The taxable person shall communicate electronically to the Member State of identification where he ceases his activities covered by the special scheme or where he changes those activities in such a way that he no longer meets the conditions necessary for using this special scheme as well as any change of the information provided to the Member State of identification no later than the tenth day of the month following cessation or change.”

The requests from the NETP can be of three different types:

• Request registration;

• Request to update the registration information;

• Request Exclusion⁴.

Table 6 shows the relevant steps from Figure 3 to handle the different types. The related XML message structure is described in section 6.5.1.1.

ID Activity Name Description Input Output

1 E1 Request The process starts when the MSID receives a request from the NETP.

NETP request

2 GW1 Or gateway

Three options to the NETP:

• Request registration step 3;

• Update registration information step 4;

• Exclusion step 6.

NETP request

NETP option

3 T1 Process Application

NETP’s request to be registered in M1SS or VoeS schemes is processed by the MSID. The detailed process is available in section 5.6.

NETP

option MSID reply

4 T2

Process Registration Update

The MSID processes the NETP’s requests to update the registration information. The detailed process is available in section 5.7.

NETP

option MSID reply

5 GW2 Merge gateway

It merges the paths coming from the NETP request for exclusion and the request from the MSID. On this particular case, it is only relevant when the NETP requests for exclusion.

NETP option

6 T3 Process Exclusion

NETP requests to be excluded or to be identified in a new MSID. The detailed process is available in section 5.8.

NETP

option MSID reply

7 GW3 Merge gateway It merges the different paths coming from the sub-

processes T1, T2 and T3. MSID reply MSID reply

8 GW4 And gateway

Two parallel actions are executed simultaneously:

• Notify NETP;

• Transmit registration information.

MSID reply MSID reply

9 T4 Notify NETP (Registration)

MSID sends a notification to the NETP (request

accepted or rejected). MSID reply NETP

notification

4 Comparable to the cancellation in VoeS, but also encompassing the change of MSID in the Union Scheme.

(20)

10 GW5 Question gateway

Was the NETP’s request eligible during T1?

• Yes step 11;

• No step 13.

MSID reply Yes or No

11 GW6 Question gateway

Is the transmission of information required (in case of new registration and exclusion only)?

• Yes step 12;

• No step 13.

MSID reply Yes or No

12 T5

Transmit Registration Information

MSID must transmit the NETP’s information to Other MS. A timer triggers this transmission

meaning that the information is sent to the Other MS at the latest within ten days from the end of the month in which the information was received; the MSID may transmit the information in a batch (for example, on a monthly basis) or as soon as it is registered (event-driven approach).

Yes

NETP registration information

13 GW7 Merge gateway It merges the paths coming from GW5, GW6 and

T5. N/A N/A

14 GW8 Merge gateway It merges the paths from T4 and GW7. N/A N/A 15 E3 End of process This process ends on MSID when the NETP’s

request is processed. N/A N/A

16 E9

Registration information received

The event is triggered when the Other MS receives the registration information from the MSID.

17 T9

Process Registration Information

The Other MS processes the NETP registration information submitted by the MSID and if needed the information can be stored.

N/A

18 E10

Registration information processed

End of the process on Other MS. N/A N/A

Table 6: NETP requests

The tasks performed when the MSID receives a request from the NETP are described further as sub- processes:

• The Process Application sub-process from [DIR06/112], Art. 359, 369b is detailed in section 5.6;

• The Process Registration Update sub-process from [REG10/904], Art. 19 is detailed in section 5.7;

The Process Exclusion sub-process from [DIR06/112], Art. 360, 369c and [CIR], Art. 57c is detailed in section 5.8.After processing the request, the MSID notifies the NETP in all cases (if the request is accepted or not). In case of new registration in the non-Union scheme, and only if the NETP is eligible to register for the special scheme, the VAT identification number allocated⁵ by the MSID is also notified to the NETP as described in [DIR06/112], Art. 362.

The MSID must transmit the new registration, or exclusion information to the other MS « within 10 days from the end of the month during which the information was received from NETP », [REG10/904], Art. 44.2. It allows the grouping of all registration information in one single message

5 In the case of a Non-EU NETP, the VAT identification number is allocated by the MSID during the registration process. In case of an EU NETP, it is assumed that the NETP is already identified for VAT purposes in the MSID and has a VAT identification number.

(21)

per month, but the MSID can alternatively use an event-driven approach and transmit information as soon as possible. The MSID must not automatically transmit updates of registration information The process ends when the NETP is notified and, if applicable, the MSID has transmitted the registration or exclusion to all Other MS.

5.5.2 MSID

EXCLUDES A REGISTERED

NETP

The process starts when the MSID decides to exclude a registered NETP. Table 7 describes the steps involved in the process. The related XML message structure is described in section 6.5.1.2.

1 E2 Exclude The starting point of the process is when MSID decides to exclude a registered NETP.

MSID decision

2 GW2 Merge gateway

It merges the paths coming from the NETP request for exclusion and the request from the MSID. In this particular case, only the request from the MSID is relevant.

MSID decision

3 T3 Process Exclusion

MSID excludes the NETP from the M1SS or VoeS scheme.

MSID decision

NETP excluded Table 7: MSID - NETP exclusion

The exclusion process defined in [DIR06/112], Art. 360, 369c is detailed in section 5.8. The minimal duration of the exclusion is defined in [CIR11/282], Art. 58b as follows:

“Where a taxable person is excluded from one of the special schemes for persistent failure to comply with the rules relating to that scheme, that taxable person shall remain excluded from using either scheme in any Member State for eight calendar quarters following the calendar quarter during which the taxable person was excluded.”

After processing the exclusion, the MSID notifies the NETP.

In case of exclusion, the information must be sent to the other MSs "without delay" ([REG10/904], Art. 44.3). The information must be submitted within 10 days from the end of the month. This allows the grouping of all registration information in one single message, as it is currently the case for VoeS.

Alternatively, the MSID may use an event-driven approach and transmit the exclusion information as soon as possible.

The process ends when the information has been transmitted to the Other MS and the NETP has been notified.

5.5.3 O

THER

MS

REQUESTS INFORMATION

The process starts when another MS requests registration information from the MSID. Table 8 describes the flow.

1 E4 Start Process

The starting point of the process is when the Other MS requests registration information from the MSID.

Other MS request

2 T6

Request Registration Information

The Other MS prepares and sends a request for registration information to the MSID.

Other MS request

Registration information request

3 E5 Request received

The MSID receives the request for information from the Other MS

4 T7

Transmit requested registration information

The MSID prepares an answer to the requested registration information and transmits it to the Other MS.

MSID answer

(22)

5 E6

Requested registration information received

The Other MS receives an answer to the requested registration information sent by MSID.

MSID answer

6 E7 Information

transmitted The process ends for the MSID. N/A N/A

7 T8

Process Requested Registration Information

Other MS processes the answer received from the MSID.

MSID

answer N/A

8 E8

Requested registration information processed

The process ends on Other MS. N/A N/A

Table 8: Other MS – Request information from MSID

Once the request is received, the MSID looks into its national database in order to find the requested information. The MSID then transmits the requested information to the Other MS.

Since all updates are stored in MSID’s database, the answer can contain multiple "records" with the complete history of changes in the NETP registration information.

The process ends when the request is processed by the MSID and the information is received by the Other MS.

(23)

5.6 P ROCESS A PPLICATION S UB -P ROCESS

The Process Application sub-process details the T1 process (Figure 3) from the high-level BPM. The related XML message structure is described in section 6.5.2.

MSID

Figure 4: Process Application sub-process

The sub-process starts when the NETP registration request is received by the MSID.

1 E1.1 Registration request

This sub-process starts when the MSID receives a registration request from the NETP.

NETP request

2 T1.1

Check

information and eligibility

The MSID checks if the information from the NETP’s request are complete.

The MSID verifies also the previous registrations and exclusions. An NETP cannot register if he was excluded within the previous eight calendar quarters or voluntarily withdrew from the special scheme within the previous two calendar quarters.

NETP request

NETP information

3 GW1.1 Question gateway

Is the registration request accepted?

• If Yes step 5;

• If No step 4.

NETP

information Yes or No

4 E1.3 Request rejected

This process ends when the NETP request is

rejected. No MSID reply

Is it EU NETP?

• If Yes step 6;

• If No step 7.

Yes Yes or No

6 T1.2

Use an existing identification number

The MSID uses the existing identification number in

case of EU NETP. Yes NETP

information

7 T1.3 Allocate a new VoeS number

The MSID allocates a new identification number in case of Non-EU NETP. If the Non-EU NETP was registered in the VoeS system before with the same MSID, his existing VoeS number will be used instead. When a Non-EU NETP registers in another MSID, this one cannot re-allocate the VAT ID of the other MSID.

No NETP

information

(24)

8 GW1.3 Merge gateway The gateway merges the flows from the allocation of the VAT identification number.

NETP information

9 T1.4

Store registration information

The MSID stores the information received from the NETP and the identification number in the national database. The timer represents that the storage of information must be executed without delay.

NETP

information MSID reply

10 E1.2 Request accepted

This process ends when the NETP’s request is

accepted. MSID reply MSID reply

Table 9: Process Application sub-process

The first action from the MSID is to check the completeness of the information provided by the NETP.

The MSID checks also if the NETP is currently excluded from the special schemes ([DIR06/112], Art.

369a and Art. 369c) and if the NETP is eligible to apply for the special scheme. If the request is accepted, in the case of a Non-EU NETP, the MSID must allocate an identification number to the NETP. Finally, the MSID stores the registration information in the national database. The sub-process ends when the request is accepted or refused.

A special case could happen when the NETP registers more times consecutively to different MSIDs.

In this case, the following happens (let us assume two MSIDs - MSID1 and MSID2):

• Firstly, MSID2 will have been informed by MSID1 of the original registration - if they have kept this information, they can check against their database;

• Secondly, MSID2 will inform all the other Member States of the registration, including MSID1, who, if they are carrying out the appropriate checks, will see that there is already a registration in MSID1. They then inform MSID2, who makes the decision to exclude the NETP from the scheme. In turn, MSID1 can decide whether to exclude the NETP from the scheme in MSID1.

In addition, the NETP is obliged to inform the MSID about its previous registrations. The NETP does so by entering the previous VAT Identification numbers in the box 21 in Table 10.

As regards the check “Check information and eligibility” (T1.1), the minimum set of data for the registration message is defined in the legal base as follows:

“1. The information which the taxable person not established within the Community must provide to the Member State of identification when he commences a taxable activity shall contain the following details:

a) name;

b) postal address;

c) electronic addresses, including websites;

d) national tax number, if any;

e) a statement that the person is not identified for VAT purposes within the Community.”

[DIR06/112], Art. 361.1 and Commission Implementing Regulation, Art. 2 The minimum set of data for the registration is further defined in the [R03]:

(25)

ID The Non-Unionscheme The Union scheme

1

Individual VAT identification number allocated by the Member State of identification in accordance with Article 362 of Directive 2006/112/EC⁶

Individual VAT identification number allocated by the Member State of identification in accordance with Article 369d of Directive 2006/112/EC, including the country code 2 The national tax number, if any

3 The company name The company name

4 The trading name(s) of the company if different from the company name

The trading name(s) of the company if different from the company name

5 The full postal address⁷ The full postal address⁷ 6 The country in which the NETP has his place

of business

The country in which the NETP has his place of business if not in the Union

7 The email address of the NETP The email address of the NETP

8 The website(s) of the NETP where available The website(s) of the NETP where available

9 Contact name Contact name

10 Telephone number Telephone number

11 IBAN or OBAN number IBAN number

12 BIC number BIC number

13.1

Individual VAT identification number(s) or if not available, tax reference number(s) allocated by the Member State(s) in which the TP has a fixed establishment(s)⁸other than in the MSID

14.1

Full postal address(es) and trading name(s) of fixed establishments⁹other than in the Member State of identification

15 VAT identification number(s) allocated by

Member State(s) as a NETP¹⁰ 16 Electronic declaration that the NETP is not

registered for VAT within the EU¹¹

17 Date of commencement of using the scheme¹² Date of commencement of using the scheme¹¹ 18 Date of request to be registered under the

scheme by the NETP

Date of request to be registered under the scheme by the NETP

6 To follow format currently used for Non-Union scheme: i.e. EUxxxyyyyyz where: xxx is the 3 digit ISO numeric of the MSI;

yyyyy is the 5 digit number assigned by MSI; and z is a check digit.

7 Postcode to be indicated if there is one.

8 Where there is more than one fixed establishment, use box 13a, 13b, etc.

9 Where there is more than one fixed establishment, use box 14a, 14b, etc.

10Where there is more than one VAT identification number allocated by Member State(s) as a non-established taxable person, use box 15.1, 15.2 etc.

11 Electronic declaration that the NETP is not registered for VAT: to be in user interface, not part of the message exchanged between MS.

12 This can be in certain limited cases prior to the date of registration onto the scheme.

(26)

ID The Non-Unionscheme The Union scheme

19 Date of registration decision by the MSID Date of registration decision by the MSID

20 Indicator of whether the NETP is a VAT

group¹³

21

Individual VAT identification number(s) allocated by the MSID in accordance with Articles 362 or 369d of Directive 2006/112/EC if they have previously used either scheme.

Table 10: CIR – Registration

The NETP will be registered within the scheme via a unique identifier that can be:

• Based on [DIR06/112], Art. 369d, the MSID uses an existing VAT number if an EU NETP triggered the request. The VAT number used was already allocated previously;

• Based on [DIR06/112], Art. 362, the MSID allocates a new identification number (VoeS number) if a Non-EU NETP triggered the request. An NETP always has a unique identifier. Its format has been defined in the VAT on e-services – Technical Specifications [R02] 3.3.3.2 Non-established taxable person ID and has the following structure: the “EU” string followed by 9 digits (the MSID ISO numeric 3 country code, the actual ID in 5 digits and one check digit).

A unique identifier can be assigned only once to an NETP. This means that if an NETP is excluded from the scheme, the identifier cannot be re-used for another taxable person.

However, it the excluded NETP is accepted again in the scheme, its previous identifier must be allocated to him again and all the history preserved. When the Non-EU NETP registers in another MSID, this one cannot re-allocate the VAT ID of the other MSID.

The storage in the national database is described in [REG10/904], Art. 17.1.d.

It is important to note that there is no central registration repository. Each national database contains different data that relates to those NETPs, which are registered for the respective MSID. The complete history must be kept in the national database for five years from the date of the change, but the actual registration information is kept whilst the taxable person is registered for the scheme (and five years following deregistration).

13 This is a simple yes/no tick box

(27)

5.7 P ROCESS R EGISTRATION U PDATE S UB -P ROCESS

The Process Registration Update sub-process details the T2 process (Figure 3) from the high-level BPM.

Figure 5: Process Registration Update sub-process

The sub-process starts when the NETP requests an update of its registration information.

1 E2.1

Request for Update Received

This sub-process starts when the MSID receives updated registration information from the NETP.

NETP request

2 T2.1

Check Registration Information Complete

The MSID checks the message completeness and correctness.

The MSID verifies also if the NETP is registered and not excluded.

NETP request

NETP information

Is the update request accepted?

• If Yes step 5;

• If No step 4.

NETP

This process ends when the NETP request is

5 T2.2

Store Registration Information

The MSID stores the received information from the NETP in the national database. The timer

represents that the storage of information must be executed without delay.

Yes MSID reply

6 E2.2 Registration Updated

This process ends when the NETP registration

information is updated. MSID reply MSID reply

Table 11: Process Registration Update sub-process

The first action from the MSID is to check the completeness of the information provided by the NETP.

The MSID checks also if the NETP is registered and not excluded.

(28)

The MSID stores the information in the national database. The sub-process ends when the request is accepted or rejected (the request may be refused if the information provided by the NETP is not complete).

The storage in the national database is described in [REG10/904], Art. 17.1.d. The information shall be stored « without delay », [REG10/904], Art. 20.

If the MSID takes the approach of transmitting the registrations to Other MS in a monthly batch, a special case can happen, when the NETP makes an update before the information is transmitted to Other MS. In this case, only the last update is sent. The earlier updates are stored in the database and must be included if the Other MS makes a query.

It is important to note that there is no central registration repository. Each national database contains different data that relates to those NETP’s, which are registered for the respective MSID. The full history should be kept in the database for five years from the date of the change, but the actual registration information is kept whilst the taxable person is registered for the scheme (and five years following deregistration).

(29)

5.8 P ROCESS E XCLUSION REQUEST S UB -P ROCESS

The Process Exclusion request sub-process details the T3 process (Figure 3) from the high-level BPM.

M S ID

Figure 6: Process Exclusion sub-process

The sub-process starts when the NETP requests exclusion, which can arise either through voluntary withdrawal from the special scheme or due to a change of MSID.

1 E3.1

Exclusion request or change of MSID notification

Starting point of the sub-process. NETP request

NETP request

2 T3.1

Check Exclusion Information

The MSID checks the message completeness and correctness.

The MSID verifies also if the NETP is registered and not excluded.

NETP request

NETP information

Is the exclusion request accepted?

• If Yes step 6;

• If No step 5.

NETP

This sub-process ends when the NETP request is

6 T3.2

Store Exclusion Information

The MSID stores the information received from the NETP in the national database. The timer

represents that the store of information must be executed without delay.

Yes MSID reply

7 E3.2 Registration Updated

This sub-process ends when the NETP registration

is updated with the exclusion information. MSID reply MSID reply Table 12: Process Exclusion sub-process

(30)

The first action from the MSID is to check the information provided by the NETP, mainly its identification number in the scheme. The MSID checks also if the NETP is registered and not excluded. Finally, the MSID stores the information in the national database. The sub-process ends when the request is accepted or refused.

The following exclusion reasons relevant for this sub-process are defined in [R03], Annex, Section 1A (the number represents the exclusion code):

5 - The taxable person has requested to voluntarily leave the scheme;

6 – The taxable person has requested to be identified in a new Member State of identification

5.8.1 V

OLUNTARY

E

XCLUSION

The minimum duration of the NETP’s voluntary exclusion is defined in [CIR11/282], Art. 57h as follows:

“Where a taxable person ceases using a special scheme [as a result of voluntarily leaving the scheme], he shall be excluded from using that scheme in any Member State for two calendar quarters from the date of cessation.”

The CIR [R03] defines also the data elements to be exchanged between the MSs:

• The VAT number allocated by the MSID;

• The date of the exclusion;

• A code for the reason for the exclusion, i.e. code 5.

5.8.2 I

DENTIFICATION IN A

N

EW

MSID

This exclusion type applies only in the Union scheme. It concerns two scenarios:

1. The NETP has not established his business in the Union but has more than one fixed establishment there. The NETP chooses one of the MS in which he has a fixed establishment as the MSID. The NETP then ceases to have a fixed establishment in that MS, and to continue to use the special scheme must change his MSID to another MS in which he has a fixed establishment.

2. The NETP has established his business in the Union and moves the place of establishment from one MS to another. To continue to use the special scheme, the NETP must change the MSID.

“The taxable person shall inform both relevant Member States simultaneously of the change of Member State of identification […] no later than the tenth day of the month following the change of establishment.”, [CIR11/282], Art. 57c. Practically, the message used to communicate the exclusion of an NETP from a special scheme shall also be used to communicate the fact that an MSID has changed the MSID. The CIR [R03] defines the data elements to be exchanged between the MSs:

• The VAT number allocated by the MSID;

• The date of the exclusion, which is the date that that the NETP ceases to have a fixed establishment in the MSID or changes its place of business;

• A code for the reason for the exclusion, i.e. code 6

Note that simultaneously with requesting exclusion in the former MSID, the NETP must provide the registration information to the new MSID, following the process described in section 5.6.

The exclusion shall be effective as from the first day of the calendar quarter following the day on which the decision on exclusion is made available by electronic means to the NETP; however, where the exclusion is caused by a change in the taxable persons business structure with the effect that the

(31)

taxable person no longer fulfils the conditions to use the scheme, the exclusion shall apply as from the date of the changed business structure.

The change of MSID shall apply as from the date that the NETP ceases to have a fixed establishment in the MS previously indicated as the MSID or changes the place where his business is established.

5.8.3 S

TORAGE

The storage in the national database is described in [REG10/904], Art. 17.1.d. The information shall be stored « without delay », [REG10/904], Art. 20. The information must be stored in the national database in order to send it to the other MSs.

If the MSID takes the approach of transmitting the registrations to Other MS in a monthly batch, a special case can happen, when the NETP registers and voluntary excludes itself from the scheme within the same month. In this case, the monthly batch will contain both registration and exclusion records.

It is important to note that there is no central registration repository. Each national database contains different data that relates to those NETP’s, which are registered for the respective MSID. The full history should be kept in the database for five years from the date of the change, but the actual registration information is kept whilst the taxable person is registered for the scheme (and five years following deregistration).

(32)

6 XML SCHEMA

The XML schema describes the information exchanged between the MSID and the Other MSs.

The notation used is described in section 9.4 Data Model notations.

6.1 V ERSIONING

The usual versioning mechanism for the XML schema is proposed, which is:

• The root element of the XML schema has its version attribute set to the actual version number of the schema, including its major and minor version numbers. The minor number is incremented whenever a change is made to the schema that is compatible with existing XML documents built with the previous schema version.

• The major version number is modified only when a schema modification is incompatible with XML documents built according to the rules of the previous schema version. As each namespace name includes the major version number of the elements it defines, existing XML instance documents have to be validated against the XML schema used to build these documents while new documents have to be validated against the new release of the schema.

6.2 F ISCALIS M ESSAGE

The overall structure of the message follows the design used in other trans-European systems sponsored by DG TAXUD, for example VAT Refund. Figure 7 depicts the overall structure, which consists of a Header part and a Body part.

Figure 7: XML Schema definition - FiscalisMessage

(33)

6.3 D ETAIL OF THE HEADER

The usual header is reused, as depicted on the following figure.

Figure 8: XML Schema definition - Header The Header contains the following elements:

• The OriginatingCountry element contains the ISO-3166 alpha-2 country code of the sender of the message (except for Greece, which uses “EL”);

• The DestinationCountries element must contain a list of two letter ISO-3166 alpha-2 country codes (except for Greece, which uses “EL”), of the intended recipients of the message. At least one country code must be present:

o For the case of the registration information the sender transmits an identical message to all MS, thus the DestinationCountries element must list all MS codes except the sender;

o All other messages are specific to one recipient and the sender must provide only the recipient MS code.

• The MessageId element contains an identifier for the message. This is limited to a maximum of 64 characters. The following characters are allowed: from a to z, from A to Z, from 0 to 9, minus (-), underscore (_), double point (:), at-sign (@) and the dot (.). The sender must ensure that the MessageId is unique for the lifetime of the system;

• An optional CorrelationId allowing correlating this message with another. This is typically used in the request-response paradigm to relate the response to the request putting the request message ID in the response correlation ID. In the context of the registration process it will be used to implement Article 17 of [REG10/904] to correlate a reply with the associated request;

• A Timestamp for the message that must be set to the time the message was created. The lexical representation of xs:dateTime is YYYY-MM-DDThh:mm:ss, where:

o YYYY the year, MM the month and DD the day;

o hh represents the hour, mm the minute, and ss the second (fractions of a second are optional);

o The letter “T” separates the date and time parts;

o The time is based on a 24-hour period, so hours are represented from 00 to 23;

(34)

o To specify the time zone, a “Z” can be added behind the time to mention that the dateTime is in UTC. An offset from the UTC time can be specified by adding a positive or negative time.

• An optional ResponseRequired. It is an indication about a response delay: a cut-off date for the response can be mentioned. This parameter is not relevant for the current system and must always be omitted;

• An optional Language. It is an indication about the language of the message. This element will not be used in this context as each free text element has a dedicated language code attribute.

6.4 D ETAIL OF THE BODY

The body is abstract: a concrete body must be defined for each implementation of the FiscalisMessage.

Figure 9: XML Schema definition - Body

The mandatory applicationId attribute of the body identifies the system the message belongs to and permits, for example, a generic dispatching application to process the message without parsing the entire message body.

Table 13 defines two values for the applicationId, according to the special scheme.

Scheme applicationID

Union Scheme M1SS

Non-Union Scheme VOES

Table 13: XML Schema Definition – valid values of applicationId per special scheme The direct consequence of this is that a message cannot contain both Union Scheme and Non-Union Scheme information. The message flows must be distinct, allowing the MS to have two distinct implementations at national level.

6.5 R EGISTRATION

Figure 10 depicts the RegistrationsInformation element, which provides the concrete message body for the FiscalisMessage for all exchanges of registration information.

(35)

Figure 10: XML Schema Definition – RegistrationsInformation The body contains a choice of three elements:

• The first choice, a sequence of Registrations and Exclusions, contain the new registrations for and exclusions from the special scheme recorded by the MSID during the period, which must be disseminated to all other MS;

• The second choice, RegistrationDetailsRequest, contains a request for registration information;

• The third choice, RequestedRegistrationDetails, contains the response to a request for registration information.

The constraints ensure that the NETP identified in the Registrations or Exclusions elements are unique.

6.5.1 R

EGISTRATION AND

E

XCLUSION

I

NFORMATION

As depicted in Figure 10, the registration and exclusion information consists of an optional list of Registration and an optional list of Exclusion. It means that the same message can contain information only about new registrations, only about new exclusions, or information about registrations and exclusions.

Section 6.5.1.1 describes Registration and section 6.5.1.2 describes Exclusion.

(36)

6.5.1.1 R

EGISTRATION

Figure 11 depicts the Registration_Type, which provides the structure for information about the registration of an NETP in a special scheme. The business process of the registration is described in section 5.5.1.

Figure 11: XML Schema Definition – Registration_Type

The TraderID part uniquely identifies the NETP. This information cannot change during the lifetime of the system. Section 6.5.1.1.1 further expands this part.

The RegistrationDetail part contains information about the NETP and its involvement in the special scheme. Section 6.5.1.1.2 further expands this part.

6.5.1.1.1 TraderID

Figure 12 depicts the TraderID_Type. This data structure uniquely identifies an NETP. It consists of a choice from two parts – the EUTraderId, defining an EU NETP, and the VoesNumber, defining a Non-EU NETP. Table 14 describes the elements and attributes.

Technically, it is possible for a message in the Union Scheme to contain VoesNumber, and for a message in the Non-Union Scheme to contain EUTraderId but this must not occur.

The XML schema re-uses the TraderID_Type wherever an NETP must be identified, for example in requests for registration information.

(37)

Figure 12: XML Schema Definition – TraderID_Type

Element or Attribute Description

VATNumber Individual VAT identification number allocated by the MS in accordance with [DIR06/112, Art. 369d]

VoesNumber The individual VAT identification number allocated by the MSID, in accordance with [DIR06/112, Art. 362].

issuedBy These attributes contain the two letter code of the MS that issued the

corresponding identification number (i.e. the VATNumber or VoesNumber) Table 14: XML Schema Definition – Attributes and Elements in the TraderID_Type

(38)

6.5.1.1.2 RegistrationDetail

Figure 13 depicts the RegistrationDetail_Type. This data structure provides the registration information for the NETP. It comprises the following parts:

• ChangeDate is the date the registration information becomes effective. For the initial record, it must have the same value as theRegistrationDecisionDate;

• TraderDetails provides descriptive and contact information about the NETP – refer to Table 15;

• SchemeDetails provides the dates related to the involvement of the NETP in the special scheme and also indicates exclusion from the scheme – refer to Table 16;

• FixedEstablishments provides information about the fixed establishments, if any, of the EU NETP in Member States other than the MSID – refer to Table 18;

• OtherMSNETP provides the VAT identification number(s) allocated by Member States(s), together with the corresponding company name, as a Non-established taxable person in another MS – refer to Table 14;

• PreviousRegistrations provide the VAT identification numbers of the NETP if it has previously used the special scheme – refer to section 6.5.1.1.1.

(39)

Figure 13: XML Schema Definition – RegistrationDetail_Type

Element or Attribute Description CompanyName The company name.

Address The postal address.

TelephoneNumber Telephone number.

EmailAddress The email address of the Non-established taxable person.

WebSites The website(s) of the Non-established taxable person where available.

ContactName The contact name.

TradingNames Optional list of trading name of the company, if different from CompanyName.

PlaceOfBusiness

The country in which the EU NETP has its place of business if not in the Community or the country in which the Non-EU NETP has its place of business.

The field is mandatory in the Non-Union scheme and optional in the Union scheme.

(40)

VATGroup

Indicator of whether the EU NETP is a VAT group (value true) or not (value false or attribute is absent). All companies that are part of the group must use the same VAT number.

This element may only be present in the Union scheme.

NationalTaxReference The national tax number of the Non-EU NETP, if any.

This element must only be present in the Non-Union scheme.

BankAccount The account holder name, IBAN or OBAN and BIC of the NETP bank account Table 15: XML Schema Definition – Attributes and Elements in the BaseTrader_Type

RequestDate Date of the NETP request to use the special scheme.

DateOfCommencement

Date of commencement of using the special scheme. It is:

• The 1st day of the quarter following the registration request of the NETP provided that the request is submitted more than 10 days (calendar days) before the end of current quarter. If the request is submitted within the 10 days (calendar days) before end of quarter, the date should be the 1st day of the quarter after the coming quarter;

• Exceptionally, in case the NETP started its supply under the scheme before being registered to its MSID, this date can be prior the registration date but never before the 1st day of the current quarter.

RegistrationDecisionDate Date of request to be registered under the special scheme by the NETP.

ExclusionDetails/Reason Codified reason for the exclusion. Refer to Table 17. ExclusionDetails/Exclus

ionDecisionDate

Date the MSID took the decision to exclude the NETP from the special scheme.

ExclusionDetails/Exclus

ionEffectiveDate Date from which the exclusion is effective.

Table 16: XML Schema Definition – Attributes and Elements in the SchemeDetails_Type

Code Description

1 The taxable person has notified the Member State of identification that he no longer supplies telecommunications, broadcasting or electronic services

2 It is assumed by the Member State of identification that the taxable activities of the taxable person covered by the special scheme have ceased

3 The taxable person no longer meets the conditions necessary for the use of the special scheme 4 The taxable person persistently fails to comply with the rules of the special scheme

5 The taxable person has requested to voluntarily leave the scheme

6 The taxable person has requested to be identified in a new Member State of identification Table 17: XML Schema Definition – Exclusion Codes

Element or Attribute Description EUTraderId Refer to Table 19

TradingName The trading name of the Fixed Establishment in the country that issued the EUTraderID

Address The postal address. Refer to section 6.6.1

Table 18: XML Schema Definition – Attributes and Elements in the FixedEstablishment_Type

Mini-1SS - System design - Registration Process

Taxation and Customs Union DG FITSDEV2 Project

Specifications, Development, Maintenance and Support of European IT Services in the area of taxation and excise

Subject:

Mini-1SS - System design - Registration Process (FITSDEV2-SC12-SDRP-Mini-1SS)

Document History

Reviews

Table of Contents

List of Tables

List of Figures

1 INTRODUCTION

1.1 O BJECTIVE OF THIS D OCUMENT

1.2 I NTENDED A UDIENCE

1.3 S TRUCTURE OF THIS D OCUMENT

1.4 D OCUMENT C ONVENTIONS

2 RELATED DOCUMENTS

2.1 R EFERENCE D OCUMENTS

3 TERMINOLOGY

3.1 A BBREVIATIONS AND A CRONYMS

3.2 D EFINITIONS

4 EXECUTIVE SUMMARY

5 OVERVIEW

5.1 B USINESS OBJECTIVE OF THE PROCESS

5.2 A CTORS

5.3 D OMAINS

5.4 R EGISTRATION P ROCESS S TRUCTURE

5.5 R EGISTRATION P ROCESS - H IGH - LEVEL BPM

5.5.1 NETP

MSID

5.5.2 MSID

NETP

5.5.3 O

MS

5.6 P ROCESS A PPLICATION S UB -P ROCESS

5.7 P ROCESS R EGISTRATION U PDATE S UB -P ROCESS

5.8 P ROCESS E XCLUSION REQUEST S UB -P ROCESS

M S ID

5.8.1 V

E

5.8.2 I

N

MSID

5.8.3 S

6 XML SCHEMA

6.1 V ERSIONING

6.2 F ISCALIS M ESSAGE

6.3 D ETAIL OF THE HEADER

6.4 D ETAIL OF THE BODY

6.5 R EGISTRATION

6.5.1 R

E

I

6.5.1.1 R