Mini-1SS - System design - Registration Process

Transcription

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 /09/2011 Rudy Kech Initial version (SfR) /11/2011 Mathieu Triquoit Implementation of DG TAXUD s comments Submitted for Acceptance (SfA) /03/2012 Tibor Sutoris Version Submitted for Review (SfR) Add issuedby attribute to NationalTaxReference /03/2012 Peter Macfarlane Add CompanyName to VAT Identification of in Other MS Add Bank Account information to registration messages Other minor changes following quality review Implement KEL /05/2012 Peter Macfarlane Implement MS Comments from third workshop Update for latest version of the legal base Reviews Version Review Date Reviewer Position /09/2011 Mathieu Triquoit Quality Reviewer /11/2011 Hubert Legros Administrative Project Manager /03/2012 Hubert Legros Administrative Project Manager /03/2012 Hubert Legros Administrative Project Manager /05/2012 Tibor Sutoris Quality Reviewer FITSDEV2-SC12-SDRP-Mini1SS-v1.03 Page 2 of 59

3 Table of Contents 1 Introduction Objective of this Document Intended Audience Structure of this Document Document Conventions Related Documents Reference Documents Terminology Abbreviations and Acronyms Definitions Executive summary Overview Business objective of the process Actors Domains Registration Process Structure Registration Process - High-level BPM makes requests to the MSID MSID excludes a registered Other MS requests information Process Application Sub-Process Process Registration Update Sub-Process Process Exclusion request Sub-Process Voluntary Exclusion Identification in a New MSID Storage XML schema Versioning FiscalisMessage Detail of the header Detail of the body Registration Registration and Exclusion Information Registration Exclusion Request for Information... 3 FITSDEV2-SC12-SDRP-Mini1SS-v1.03 Page 3 of 59

4 6.5.3 Response to Request for Information Example of Error message Common Elements Address Name Conceptual Database schema Textual description Differences between the present and the new VoeS System architecture Overall architecture Logical architecture Exchange of messages Registration process messages queues Security services Annexes Guidelines BPMN Flow Objects Connecting Objects Swimlanes Artefacts Business Process Model and Notation version 2.0 Level Flow objects Tools used Data Model notations Notations used in the data model diagrams... 3 FITSDEV2-SC12-SDRP-Mini1SS-v1.03 Page 4 of 59

5 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: requests... 3 Table 7: MSID - 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 FITSDEV2-SC12-SDRP-Mini1SS-v1.03 Page 5 of 59

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 FITSDEV2-SC12-SDRP-Mini1SS-v1.03 Page 6 of 59

7 1 INTRODUCTION 1.1 OBJECTIVE OF THIS DOCUMENT 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 INTENDED AUDIENCE The intended audience of this document is: DG TAXUD/R4; DG TAXUD/C1; DG TAXUD/C4; Member States Administrations (MSAs); FITSDEV STRUCTURE OF THIS DOCUMENT Chapter 1 Chapter 2 Chapter 3 Chapter 4 Chapter 5 Chapter 6 Chapter 7 Chapter 8 Chapter 9 Introduction: introduces the purpose and the structure of this document; Related Documents: defines the documents the current document is referring to and the documents applicable to the current document; Terminology: describes the acronyms and the definitions used in this document; Executive summary: provides a summary of the main aspects of this document; 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; XML schema: defines the messages exchanged with the Member States; Conceptual Database schema: proposes a database schema that could be used by the MSID; System architecture: provides an overall picture of the architecture of the system; Annexes: contains the annexes of the SD. FITSDEV2-SC12-SDRP-Mini1SS-v1.03 Page 7 of 59

8 1.4 DOCUMENT CONVENTIONS 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 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. FITSDEV2-SC12-SDRP-Mini1SS-v1.03 Page 8 of 59

9 2 RELATED DOCUMENTS 2.1 REFERENCE DOCUMENTS Ref. Title Reference Version Date R01 VAT Refund Technical Specifications FITSDEV-TS-VAT Refund /07/2010 R02 VAT on e-services -Technical Specifications VAT on e-services - TS_v5.2.doc /05/2005 R03 Draft Commission Implementing Regulation COMMISSION IMPLEMENTING REGULATION N/A 15/05/ R04 Draft Council regulation Draft Council regulation amending Implementing Regulation (EU) No 282/2011 N/A 15/05/ DIR0 8/8 DIR0 6/112 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/ o?uri=oj:l:2008:044:0011:0022:en:pd F 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/ o?uri=consleg:2006l0112: :EN:PDF Any reference to this Directive means, this directive as amended by Directive Council Directive 2008/8/EC L0008 N/A 20/02/ L0112 M1 01/01/ Date of reception from DG TAXUD. 2 Date of reception from DG TAXUD. FITSDEV2-SC12-SDRP-Mini1SS-v1.03 Page 9 of 59

10 Ref. Title Reference Version Date REG1 0/904 REG2 82/11 [ISO_ 3166] 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/ o?uri=oj:l:2010:268:0001:0018:en:pd F 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/ o?uri=oj:l:2011:077:0001:0022:en:pd F ISO : Codes for the representation of names of countries and their subdivisions Part 1: Country codes s_explained/index.php/tutorial:country _codes_and_protocol_order 32010R0904 N/A 07/10/ R0282 N/A 15/03/2011 N/A N/A N/A Table 1: Reference documents FITSDEV2-SC12-SDRP-Mini1SS-v1.03 Page 10 of 59

11 3 TERMINOLOGY 3.1 ABBREVIATIONS AND ACRONYMS Definition Meaning Art. BIC BPM BPMN CCN CIR CSI DG TAXUD E EU EU FIS FITS FITSDEV2 GW IBAN ID IP ISO M M1SS MS MSA MSCON MSEST MSID N/A NA Non-EU Article Business Identifier Code Business Process Modelling Business Process Modelling Notation Common Communication Network Commission Implementing Regulation Common System Interface Directorate-General Taxation and Customs Union Event European Union not established in the Member State of consumption but established in the Community FISCALIS Information Systems FISCALIS Information Technology Services FITS Development Gateway International Bank Account Number Identification Internet Protocol International Organization for Standardization Mandatory Mini One Stop Shop Member State MS Administration MS of Consumption MS of Establishment MS of Identification Not Applicable National Application Non-Established Taxable Person not established within the Community FITSDEV2-SC12-SDRP-Mini1SS-v1.03 Page 11 of 59

12 Definition Meaning P PI SC SD T TP UC UTC VAT VoeS XML Process Primary Identifier Specific Contract System Design Task Taxable Person Use Case Coordinated Universal Time Value Added Tax VAT-on-e-Services Extensible Mark-up Language Table 2: Abbreviations and Acronyms 3.2 DEFINITIONS Definition Meaning Actor Completeness Correctness ISO numeric 3 country code Non-Union scheme Primary key Union scheme An actor is someone or something outside the system that interacts with the system. The completeness is the fact that the data provided correspond to the data structure and that all mandatory data elements are present. The correctness is the matching between the format of the data provided and the data structure. 3 digits integer ISO country code as defined in [ISO_3166]. 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. The primary key of a relational table uniquely identifies each record in the table. 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 FITSDEV2-SC12-SDRP-Mini1SS-v1.03 Page 12 of 59

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 (s), 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. FITSDEV2-SC12-SDRP-Mini1SS-v1.03 Page 13 of 59

14 5 OVERVIEW The overview describes the actors and the processes involved in the Registration Process. 5.1 BUSINESS 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 ACTORS The actors section describes the different actors involved in the Registration Process. Non-Established Taxable Person (); 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 There are two types of : 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 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 is used in this document to refer to this actor. MSCON MSEST 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 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. FITSDEV2-SC12-SDRP-Mini1SS-v1.03 Page 14 of 59

15 Actors Definition from the legal base For an 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. MSID For an 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 DOMAINS 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 FITSDEV2-SC12-SDRP-Mini1SS-v1.03 Page 15 of 59

16 Domain Common domain National domain External domain Definition The Common domain is the environment that allows the various Member State Administrations to intercommunicate and falls under the responsibility of the Commission. 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. The External domain is the environment between the s applications and the NA. The network with the Economic Operators differs from one country to another. Table 5: Domains 5.4 REGISTRATION PROCESS STRUCTURE The structure of the processes, concentrating on the Registration process, is depicted in Figure 2. Mini-1SS main processes Registration Process VAT Return Process Payment Process Registration main processes Process 's registration Process Registration information request Process 's exclusion Registration sub-processes Process Application Process Registration update Process Exclusion Figure 2: Registration process structure The Registration process covers the following processes: Process s registration the Registration request received from the 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 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 s registration data; FITSDEV2-SC12-SDRP-Mini1SS-v1.03 Page 16 of 59

17 Process s exclusion the MSID processes 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. FITSDEV2-SC12-SDRP-Mini1SS-v1.03 Page 17 of 59

18 5.5 REGISTRATION PROCESS - HIGH-LEVEL BPM The high-level BPM shows the collaborations between actors and the sequence between the tasks (T) involved in the process. 3 Other MS MSID Figure 3: Registration Process - High-level BPM The Registration Process groups the tasks related to three sub-processes: 1. The 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 as described in [DIR06/112], Art. 363 and 369e; 3. An MS requests registration information of a given from an MSID, as mentioned in [REG10/904], Art The notation used is the BPMN 2.0 described in section 9.1 Guidelines BPMN. FITSDEV2-SC12-SDRP-Mini1SS-v1.03 Page 18 of 59

19 5.5.1 MAKES REQUESTS TO THE MSID The process starts when the sends a request to the MSID. Regarding changes to the registration information, the 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 can be of three different types: Request registration; Request to update the registration information; Request Exclusion 4. Table 6 shows the relevant steps from Figure 3 to handle the different types. The related XML message structure is described in section ID Activity Name Description Input Output 1 E1 Request The process starts when the MSID receives a request from the. request request Three options to the : 2 GW1 Or gateway Request registration step 3; Update registration information step 4; request option Exclusion step 6. 3 T1 Process Application s request to be registered in M1SS or VoeS schemes is processed by the MSID. The detailed process is available in section 5.6. option MSID reply 4 T2 Process Registration Update The MSID processes the s requests to update the registration information. The detailed process is available in section 5.7. option MSID reply 5 GW2 Merge gateway It merges the paths coming from the request for exclusion and the request from the MSID. On this particular case, it is only relevant when the requests for exclusion. option option 6 T3 Process Exclusion requests to be excluded or to be identified in a new MSID. The detailed process is available in section 5.8. option MSID reply 7 GW3 Merge gateway It merges the different paths coming from the subprocesses T1, T2 and T3. MSID reply MSID reply Two parallel actions are executed simultaneously: 8 GW4 And gateway Notify ; MSID reply MSID reply Transmit registration information. 9 T4 Notify (Registration) MSID sends a notification to the (request accepted or rejected). MSID reply notification 4 Comparable to the cancellation in VoeS, but also encompassing the change of MSID in the Union Scheme. FITSDEV2-SC12-SDRP-Mini1SS-v1.03 Page 19 of 59

20 ID Activity Name Description Input Output 10 GW5 11 GW6 12 T5 Question gateway Question gateway Transmit Registration Information 13 GW7 Merge gateway Was the s request eligible during T1? Yes step 11; No step 13. Is the transmission of information required (in case of new registration and exclusion only)? Yes step 12; No step 13. MSID must transmit the 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). It merges the paths coming from GW5, GW6 and T5. MSID reply MSID reply 14 GW8 Merge gateway It merges the paths from T4 and GW7. N/A N/A 15 E3 End of process 16 E9 17 T9 18 E10 Registration information received Process Registration Information Registration information processed This process ends on MSID when the s request is processed. The event is triggered when the Other MS receives the registration information from the MSID. The Other MS processes the registration information submitted by the MSID and if needed the information can be stored. Yes N/A N/A registration information registration information Yes or No Yes or No registration information N/A N/A registration information N/A End of the process on Other MS. N/A N/A Table 6: requests The tasks performed when the MSID receives a request from the are described further as subprocesses: 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 in all cases (if the request is accepted or not). In case of new registration in the non-union scheme, and only if the is eligible to register for the special scheme, the VAT identification number allocated 5 by the MSID is also notified to the as described in [DIR06/112], Art 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», [REG10/904], Art It allows the grouping of all registration information in one single message 5 In the case of a Non-EU, the VAT identification number is allocated by the MSID during the registration process. In case of an EU, it is assumed that the is already identified for VAT purposes in the MSID and has a VAT identification number. FITSDEV2-SC12-SDRP-Mini1SS-v1.03 Page 20 of 59

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 is notified and, if applicable, the MSID has transmitted the registration or exclusion to all Other MS MSID EXCLUDES A REGISTERED The process starts when the MSID decides to exclude a registered. Table 7 describes the steps involved in the process. The related XML message structure is described in section ID Activity Name Description Input Output 1 E2 Exclude The starting point of the process is when MSID decides to exclude a registered. MSID decision MSID decision 2 GW2 Merge gateway It merges the paths coming from the request for exclusion and the request from the MSID. In this particular case, only the request from the MSID is relevant. MSID decision MSID decision 3 T3 Process Exclusion MSID excludes the from the M1SS or VoeS scheme. MSID decision excluded Table 7: MSID - 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. 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 has been notified OTHER MS REQUESTS INFORMATION The process starts when another MS requests registration information from the MSID. Table 8 describes the flow. ID Activity Name Description Input Output 1 E4 Start Process The starting point of the process is when the Other MS requests registration information from the MSID. Other MS request 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 Registration information request Registration information request 4 T7 Transmit requested registration information The MSID prepares an answer to the requested registration information and transmits it to the Other MS. Registration information request MSID answer FITSDEV2-SC12-SDRP-Mini1SS-v1.03 Page 21 of 59

22 ID Activity Name Description Input Output 5 E6 Requested registration information received The Other MS receives an answer to the requested registration information sent by MSID. MSID answer 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 registration information. The process ends when the request is processed by the MSID and the information is received by the Other MS. FITSDEV2-SC12-SDRP-Mini1SS-v1.03 Page 22 of 59

23 5.6 PROCESS APPLICATION SUB-PROCESS 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 MSID Figure 4: Process Application sub-process The sub-process starts when the registration request is received by the MSID. ID Activity Name Description Input Output 1 E1.1 Registration request This sub-process starts when the MSID receives a registration request from the. request request The MSID checks if the information from the s request are complete. 2 T1.1 Check information and eligibility The MSID verifies also the previous registrations and exclusions. An 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. request information Is the registration request accepted? 3 GW1.1 Question gateway If Yes step 5; If No step 4. information Yes or No 4 E1.3 Request rejected This process ends when the request is rejected. No MSID reply Is it EU? 5 GW1.2 Question gateway 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. Yes information 7 T1.3 Allocate a new VoeS number The MSID allocates a new identification number in case of Non-EU. If the Non-EU was registered in the VoeS system before with the same MSID, his existing VoeS number will be used instead. When a Non-EU registers in another MSID, this one cannot re-allocate the VAT ID of the other MSID. No information FITSDEV2-SC12-SDRP-Mini1SS-v1.03 Page 23 of 59

24 ID Activity Name Description Input Output 8 GW1.3 Merge gateway The gateway merges the flows from the allocation of the VAT identification number. information information 9 T1.4 Store registration information The MSID stores the information received from the and the identification number in the national database. The timer represents that the storage of information must be executed without delay. information MSID reply 10 E1.2 Request accepted This process ends when the 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. The MSID checks also if the is currently excluded from the special schemes ([DIR06/112], Art. 369a and Art. 369c) and if the is eligible to apply for the special scheme. If the request is accepted, in the case of a Non-EU, the MSID must allocate an identification number to the. 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 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 from the scheme. In turn, MSID1 can decide whether to exclude the from the scheme in MSID1. In addition, the is obliged to inform the MSID about its previous registrations. The 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 and Commission Implementing Regulation, Art. 2 The minimum set of data for the registration is further defined in the [R03]: FITSDEV2-SC12-SDRP-Mini1SS-v1.03 Page 24 of 59

25 ID The Non-Union scheme 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 6 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 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 The trading name(s) of the company if different from the company name 5 The full postal address 7 The full postal address 7 6 The country in which the has his place of business The country in which the has his place of business if not in the Union 7 The address of the The address of the 8 The website(s) of the where available The website(s) of the where available 9 Contact name Contact name 10 Telephone number Telephone number 11 IBAN or OBAN number IBAN number 12 BIC number BIC number Electronic declaration that the is not registered for VAT within the EU 11 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) 8 other than in the MSID Full postal address(es) and trading name(s) of fixed establishments 9 other than in the Member State of identification VAT identification number(s) allocated by Member State(s) as a Date of commencement of using the scheme 12 Date of commencement of using the scheme Date of request to be registered under the scheme by the Date of request to be registered under the scheme by the 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. 10 Where 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 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. FITSDEV2-SC12-SDRP-Mini1SS-v1.03 Page 25 of 59

26 ID The Non-Union scheme The Union scheme 19 Date of registration decision by the MSID Date of registration decision by the MSID 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. Indicator of whether the is a VAT group 13 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 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 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 triggered the request. An always has a unique identifier. Its format has been defined in the VAT on e-services Technical Specifications [R02] 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. This means that if an is excluded from the scheme, the identifier cannot be re-used for another taxable person. However, it the excluded is accepted again in the scheme, its previous identifier must be allocated to him again and all the history preserved. When the Non-EU 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 d. It is important to note that there is no central registration repository. Each national database contains different data that relates to those s, 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 FITSDEV2-SC12-SDRP-Mini1SS-v1.03 Page 26 of 59

27 5.7 PROCESS REGISTRATION UPDATE SUB-PROCESS 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 requests an update of its registration information. ID Activity Name Description Input Output 1 E2.1 Request for Update Received This sub-process starts when the MSID receives updated registration information from the. request request 2 T2.1 Check Registration Information Complete The MSID checks the message completeness and correctness. The MSID verifies also if the is registered and not excluded. request information Is the update request accepted? 3 GW2.1 Question gateway If Yes step 5; If No step 4. information Yes or No 4 E2.3 Request rejected This process ends when the request is rejected. No MSID reply 5 T2.2 Store Registration Information The MSID stores the received information from the 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 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. The MSID checks also if the is registered and not excluded. FITSDEV2-SC12-SDRP-Mini1SS-v1.03 Page 27 of 59

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 is not complete). The storage in the national database is described in [REG10/904], Art 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 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 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). FITSDEV2-SC12-SDRP-Mini1SS-v1.03 Page 28 of 59

29 5.8 PROCESS EXCLUSION REQUEST SUB-PROCESS The Process Exclusion request sub-process details the T3 process (Figure 3) from the high-level BPM. MSID Figure 6: Process Exclusion sub-process The sub-process starts when the requests exclusion, which can arise either through voluntary withdrawal from the special scheme or due to a change of MSID. ID Activity Name Description Input Output 1 E3.1 Exclusion request or change of MSID notification Starting point of the sub-process. request request 2 T3.1 Check Exclusion Information The MSID checks the message completeness and correctness. The MSID verifies also if the is registered and not excluded. request information Is the exclusion request accepted? 3 GW3.1 Question gateway If Yes step 6; If No step 5. information Yes or No 5 E3.3 Request rejected This sub-process ends when the request is rejected. No MSID reply 6 T3.2 Store Exclusion Information The MSID stores the information received from the 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 registration is updated with the exclusion information. MSID reply MSID reply Table 12: Process Exclusion sub-process FITSDEV2-SC12-SDRP-Mini1SS-v1.03 Page 29 of 59

30 The first action from the MSID is to check the information provided by the, mainly its identification number in the scheme. The MSID checks also if the 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 VOLUNTARY EXCLUSION The minimum duration of the 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 IDENTIFICATION IN A NEW MSID This exclusion type applies only in the Union scheme. It concerns two scenarios: 1. The has not established his business in the Union but has more than one fixed establishment there. The chooses one of the MS in which he has a fixed establishment as the MSID. The 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 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 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 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 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 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 ; however, where the exclusion is caused by a change in the taxable persons business structure with the effect that the FITSDEV2-SC12-SDRP-Mini1SS-v1.03 Page 30 of 59

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 ceases to have a fixed establishment in the MS previously indicated as the MSID or changes the place where his business is established STORAGE The storage in the national database is described in [REG10/904], Art 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 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 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). FITSDEV2-SC12-SDRP-Mini1SS-v1.03 Page 31 of 59

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 VERSIONING 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 FISCALISMESSAGE 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 FITSDEV2-SC12-SDRP-Mini1SS-v1.03 Page 32 of 59

33 6.3 DETAIL OF THE HEADER The usual header is reused, as depicted on the following figure. The Header contains the following elements: Figure 8: XML Schema definition - Header 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 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; 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 o o YYYY the year, MM the month and DD the day; hh represents the hour, mm the minute, and ss the second (fractions of a second are optional); 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; FITSDEV2-SC12-SDRP-Mini1SS-v1.03 Page 33 of 59

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 DETAIL 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 Union Scheme Non-Union Scheme applicationid M1SS 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 REGISTRATION Figure 10 depicts the RegistrationsInformation element, which provides the concrete message body for the FiscalisMessage for all exchanges of registration information. FITSDEV2-SC12-SDRP-Mini1SS-v1.03 Page 34 of 59

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 identified in the Registrations or Exclusions elements are unique REGISTRATION AND EXCLUSION INFORMATION 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 describes Registration and section describes Exclusion. FITSDEV2-SC12-SDRP-Mini1SS-v1.03 Page 35 of 59

36 REGISTRATION Figure 11 depicts the Registration_Type, which provides the structure for information about the registration of an in a special scheme. The business process of the registration is described in section Figure 11: XML Schema Definition Registration_Type The TraderID part uniquely identifies the. This information cannot change during the lifetime of the system. Section further expands this part. The RegistrationDetail part contains information about the and its involvement in the special scheme. Section further expands this part TraderID Figure 12 depicts the TraderID_Type. This data structure uniquely identifies an. It consists of a choice from two parts the EUTraderId, defining an EU, and the VoesNumber, defining a Non-EU. 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 must be identified, for example in requests for registration information. FITSDEV2-SC12-SDRP-Mini1SS-v1.03 Page 36 of 59

37 Figure 12: XML Schema Definition TraderID_Type Element or Attribute VATNumber VoesNumber issuedby Description Individual VAT identification number allocated by the MS in accordance with [DIR06/112, Art. 369d] The individual VAT identification number allocated by the MSID, in accordance with [DIR06/112, Art. 362]. 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 FITSDEV2-SC12-SDRP-Mini1SS-v1.03 Page 37 of 59

38 RegistrationDetail Figure 13 depicts the RegistrationDetail_Type. This data structure provides the registration information for the. 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 the RegistrationDecisionDate; TraderDetails provides descriptive and contact information about the refer to Table 15; SchemeDetails provides the dates related to the involvement of the 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 in Member States other than the MSID refer to Table 18; OtherMS 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 if it has previously used the special scheme refer to section FITSDEV2-SC12-SDRP-Mini1SS-v1.03 Page 38 of 59

39 Figure 13: XML Schema Definition RegistrationDetail_Type Element or Attribute CompanyName Address TelephoneNumber Address WebSites ContactName TradingNames PlaceOfBusiness Description The company name. The postal address. Telephone number. The address of the Non-established taxable person. The website(s) of the Non-established taxable person where available. The contact name. Optional list of trading name of the company, if different from CompanyName. The country in which the EU has its place of business if not in the Community or the country in which the Non-EU has its place of business. The field is mandatory in the Non-Union scheme and optional in the Union scheme. FITSDEV2-SC12-SDRP-Mini1SS-v1.03 Page 39 of 59

40 Element or Attribute VATGroup NationalTaxReference BankAccount Description Indicator of whether the EU 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. The national tax number of the Non-EU, if any. This element must only be present in the Non-Union scheme. The account holder name, IBAN or OBAN and BIC of the bank account Table 15: XML Schema Definition Attributes and Elements in the BaseTrader_Type Element or Attribute RequestDate DateOfCommencement Description Date of the request to use the special scheme. Date of commencement of using the special scheme. It is: The 1st day of the quarter following the registration request of the 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 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. ExclusionDetails/Reason Codified reason for the exclusion. Refer to Table 17. ExclusionDetails/Exclus Date the MSID took the decision to exclude the from the special iondecisiondate scheme. ExclusionDetails/Exclus Date from which the exclusion is effective. ioneffectivedate 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 The trading name of the Fixed Establishment in the country that issued the TradingName EUTraderID Address The postal address. Refer to section Table 18: XML Schema Definition Attributes and Elements in the FixedEstablishment_Type FITSDEV2-SC12-SDRP-Mini1SS-v1.03 Page 40 of 59

41 Element or Attribute VATIdentificationNum ber TaxReferenceNumber issuedby Description The VAT identification number of the Fixed Establishment A tax reference number (used only if the VAT identification number is not available) The two letter country code of the Member State that issued the VATIdentificationNumber or TaxReferenceNumber. Table 19: XML Schema Definition Attributes and Elements in the EUTraderIDType_Type EXCLUSION Figure 14 depicts the Exclusion_Type. The business process of the exclusion is described in section This data structure provides the information concerning the exclusion of an from a special scheme. It comprises the following parts: TraderID uniquely identifies the refer to Section ; ExclusionDetail provides reason and associated dates of the exclusion refer to Table 16. Figure 14: XML Schema Definition Exclusion_Type REQUEST FOR INFORMATION Figure 15 depicts the data structure of a request for registration information. The business process of the Request for information is described in section Figure 15: XML Schema Definition RegistrationDetailsRequest_Type The structure contains a TraderID element that uniquely identifies the. Refer to section FITSDEV2-SC12-SDRP-Mini1SS-v1.03 Page 41 of 59

42 The TradeDate element can optionally be provided. When provided, the requester asks only for the registration information valid on this date. When the TraderID element is absent, the requester asks for a list of TraderID RESPONSE TO REQUEST FOR INFORMATION Figure 16 depicts the data structure of a response to a request for registration information. Figure 16: XML Schema Definition RequestedRegistrationDetails_Type The RegistrationDetailsRequest exactly echoes the request. Refer to section The RegistrationDetails element is present when the request included a TraderID. It contains the history of changes to the registration information as a list of RegistrationDetail. Refer to section for the content of a RegistrationDetail. Note that if the request does not specify a TradeDate, this must contain only the latest RegistrationDetail (if any) valid on the TradeDate, otherwise the list contains the full history of changes made on or after the TradeDate. The TraderIDs element is present when the request did not include a TraderID. It contains a list of TraderID. If the TradeDate was present in the request, the list is limited to TraderID for which there has been some change in registration data on or after the TradeDate; otherwise, the list contains all TraderID in the MSID database. The response contains only that information that is stored locally by the MSID. If the is registered also in another MSID, the response will not contain this information. If the s identifier is not found in the MSID s store, no related information will be returned (only the information that the with the requested identifier does not exist in the MSID s store). FITSDEV2-SC12-SDRP-Mini1SS-v1.03 Page 42 of 59

43 An error message is a formal representation of an error indication. This message is used to indicate an error in the communication of information between Member States applications. The graphical representation of the error message is depicted at Figure 17. Figure 17: Error message Element Name Code Detail TraderID VATReturnReference PaymentReference Element Content This element contains error code associated to the problem identified. This element contains some free text associated to the problem identified This element provides a reference to the associated to the problem identified This element provides a reference to the VAT Return associated to the problem identified This element provides a reference to the Payment associated to the problem identified Table 20: Elements and content of the error message EXAMPLE OF ERROR MESSAGE The following example expresses the technical errors. The first error expresses incorrectly encoded XML message and the second one expresses validation error. Code Mnemonic Description NOT_WELL-FORMED The message is not well formed and cannot be decoded NOT_COMPLIANT The message cannot be validated against the XML schema. Table 21: Technical errors FITSDEV2-SC12-SDRP-Mini1SS-v1.03 Page 43 of 59

44 6.6 COMMON ELEMENTS This section describes common elements of the XML schema definition ADDRESS An address can be given either in free format, structured format, or in both. Figure 18 depicts the structure of the address and Table 22 describes the elements. Figure 18: XML Schema Definition AddressFreeOrStruct_Type Element Description AddressFree The address in free format. This must include the postcode if available. Street The street name. BuildingIdentifier The identifier of the building on the street, typically a number. SuiteIdentifier The identifier of an office or similar part of a building. FloorIdentifier The identifier of a floor within a building. DistrictName The name of the district of the address. POB The post office box. PostCode The postal code. This must be provided if available. City The city is the only mandatory part of a structured address. CountrySubentity OtherLocalId Country A geographic area of the country larger than district or city, for example a county, department, Land, canton. Some other component of the address. The two letter country code of the address. Table 22: XML Schema Definition Elements of an address FITSDEV2-SC12-SDRP-Mini1SS-v1.03 Page 44 of 59

45 Where possible, MS should use the structured format of the address. If it is not possible to use the structured format, the lines of the address must be separated by carriage return characters such that the address appears as it should on an envelope NAME Figure 19 depicts the structure of a personal name and Table 23 describes the elements. A name can be given in free format, structured format or both. Figure 19: XML Schema Definition NameStruct_Type Element nametype NameFree PrecedingTitle Description The type of the name, from a fixed list of codes (this attribute is not relevant in the current system and must be omitted) The name in free format. Preceding title for example Her Excellency. FITSDEV2-SC12-SDRP-Mini1SS-v1.03 Page 45 of 59

46 Element Title FirstName MiddleName NamePrefix LastName GenerationIdentifier Suffix GeneralSuffix MaidenName Description The list of titles, for example Mr, Frau, Doctor. The first name. The list of middle names. The name prefix for example "von". The last name/family name. The list of generation identifiers, for example Junior, Senior, XIII. The list of suffices, for example, PhD, UOM. A general suffix (for example, "Retired"). A prior surname, for example before marriage. Table 23: XML Schema Definition Elements of a name FITSDEV2-SC12-SDRP-Mini1SS-v1.03 Page 46 of 59

47 7 CONCEPTUAL DATABASE SCHEMA This section proposes a conceptual database to allow the MSID to store the information exchanged with the. The following figure depicts the complete conceptual database schema, including all attributes. In this schema, <pi> identifies the primary key of an entity and <M> identifies the mandatory attributes. Exclusion Registration Previous registration Exclusion code <pi> Exclusion reason Exclusion other Exclusion decision date Exclusion effective date Exclusion code <pi> Short integer Variable characters (256) Characters (256) Date Date <M> <M> <M> <M> Registration decision date Request date Commencement date Change date Status code <pi> Date Date Date Date <M> <M> <M> <M> REGIST-PREVIOUS VAT identification number Variable characters (12) <M> Registration decision date Date <M> WebSiteURL Web site URL <pi> Variable characters (128) <M> WebSiteURL <pi> Contact ID Preceding title Title First name Middle name Name prefix Last name Generation identifier Suffix General suffix Maiden name Contact ID <pi> Contact -URL <pi> Variable characters (20) Variable characters (80) Variable characters (80) Variable characters (80) Variable characters (80) Variable characters (80) Variable characters (80) Variable characters (80) Variable characters (80) Variable characters (80) Variable characters (80) <M> <M> <M> Non-EU_ EXCLUSION- ID type VAT identification number Company name Trading name Telephone number ID <pi> National tax number Variable characters (20) -CONTACT -REGISTRATION <pi> Variable characters (11) Characters (10) Variable characters (12) Variable characters (80) Variable characters (80) Variable characters (20) Variable characters (128) Inheritance EU_ PLACEOFBUSINESS <M> <M> <M> <M> <M> Part of VAT group Boolean Tax reference number Variable characters (20) -FIXEDESTABLISHMENT -ADDRESS Country N2 ISO code Name MS Country N2 ISO code <pi> Fixed establishment ID VAT identification number Tax reference number Part of VAT group Country N3 ISO code Fixed establishment ID <pi> Country <pi> Variable characters (2) <M> Variable characters (128) Boolean COUNTRY-FIXEDESTABLISHMENT FIXEDESTABLISHMENT-ADDRESS Address ID Street Building identifier Suite identifier Floor identifier District name POB Post code City Country subentity Other local Id Address ID <pi> Fixed establishment <pi> Variable characters (20) Variable characters (12) Variable characters (20) Boolean Variable characters (3) Address <M> <M> <M> <pi> Variable characters (20) <M> Variable characters (80) Variable characters (80) Variable characters (80) Variable characters (80) Variable characters (80) Variable characters (80) Variable characters (80) Variable characters (80) <M> Variable characters (80) Variable characters (80) Figure 20: Conceptual database schema 7.1 TEXTUAL DESCRIPTION Most of the attributes are defined in the XML schema. Some entities presented in the conceptual database schema extend the XML schema. The country entity lists all countries. This entity contains following attributes: A ISO alpha-2 code; The name of the country; MS identifies if the country is a MS. The exclusion entity details the exclusion reason. This entity contains following attributes: A reason code; Exclusion reason including Other reason (free text); A textual description of the reason; FITSDEV2-SC12-SDRP-Mini1SS-v1.03 Page 47 of 59

48 Exclusion date; Exclusion decision date. The exclusion reasons are defined in more detail in section 5.8. The previous s registrations are defined in the Previous registration entity. The entity contains the following attributes: VAT identification number; Registration date. The entity has one more attribute type, which defines as EU or Non-EU. 7.2 DIFFERENCES BETWEEN THE PRESENT AND THE NEW VOES Table 24 describes the differences between the present VoeS system and the proposed new VoeS. Difference Present VoeS New VoeS Note Communication Channel CCN Mail CCN/CSI asynchronous message queues Correction Mechanism No automatic support of corrections Supports automatic corrections Direct access to database No Direct access to database Supports direct access to MSID registration and VAT return database via several querying message types. New requirement in Council Regulation 2010/904 XML Schema Harmonisation of systems results in a completely new XSD. However, messages in the existing VoeS schema can easily be transformed to the new XSD - no new mandatory information is included. Extended Business Scope E-Services E-Services, Telecommunications, Broadcasting Services As a result, we expect greater use of the system. Table 24: Differences between the present and the new VoeS FITSDEV2-SC12-SDRP-Mini1SS-v1.03 Page 48 of 59

49 8 SYSTEM ARCHITECTURE To cover the communication needs, the Commission s CCN/CSI infrastructure is used. The Common Communication Network (CCN), the trans-european network itself, is made up of a series of physical gateways located either in the National administrations or in the Commission premises. These gateways are interconnected through their own communication services, and communicate with the national computers. The Common System Interface (CSI) is a set of protocols and application programming interfaces allowing the application to exchange information through the CCN. It ensures the interoperability between the relevant computers belonging to a National Administration and the gateway. The CSI connection itself is made secure using well-proven authentication and cryptographic algorithms. 8.1 OVERALL ARCHITECTURE Every Member States is equipped by communication node, represented by National domain. For the communication between the National domains, the asynchronous protocol is proposed. The overall architecture is depicted at Figure 21. Figure 21: Overall architecture The aforementioned figure displays two different architectures at the national level: Fully separated system represented by Member State X; Fully integrated system represented by Member State Y. Both National domains are connected to CCN backbone through CCN gateways and Encryption boxes. The fully separated system is represented by the existing VoeS system, which remains as it is, and a new Mini-1SS system. Both systems operate separately and for data exchange use their own dedicated queues. On the contrary, the fully integrated system is represented by one common system, which will integrate the existing VoeS system and the new Mini-1SS system. FITSDEV2-SC12-SDRP-Mini1SS-v1.03 Page 49 of 59

50 8.2 LOGICAL ARCHITECTURE The logical architecture at Figure 22 describes the solution how the CCN/CSI network will be used for the needs of Mini-1SS system. Figure 22: Logical architecture The depicted logical architecture defines the main components and the communication flows between them. The role of the components is as follows: CSI stack - runs on the national computers. It provides access to the CSI services to any applications running on this platform. CSI is an Application Programming Interface supported by more than 10 different operating systems. CCN CSI Communication the component transforms the communication needs of the main components and sends the requests to CSI stack of community domain, or other national domains. The component also receives requests coming from other domains and transposes them to CSI stack. Transmission of information the component retrieves information from a database and prepares the CCN message. Part of the preparation process is also marshalling the XML message. After the marshalling, the message is transmitted to one or more national domains. Request parsing the component processes direct access to database requests received from other national domains. The component provides the following operations on the message: Checking if the message was submitted by the correct application; Validation of the XML message using the XML schema; Unmarshaling of the XML message. FITSDEV2-SC12-SDRP-Mini1SS-v1.03 Page 50 of 59

51 If the message is correct, the component moves the message to the Processing component. If the message is not correct, the component prepares the error message, which is submitted to the originator national domain. Processing the component processes the message, which was successfully parsed in the previous component. The following operations are provided: Validation of the message against the business rules; Extraction of the requested information from the database; Preparation of the response; Marshaling of the message. If the validation indicates any error, the error message is prepared and submitted to the originator national domain. Answer preparation if the message was processed successfully in the previous component, the component prepares the answer. The answer is marshaled into a CCN message and submitted to the national domain, which requested the information. For the message submission and transmission, the quality of services is used. Two types of confirmation are used: Confirm on arrival is generated when the message is placed on the destination queue. Confirm on delivery is generated when the message is retrieved from the destination queue. 8.3 EXCHANGE OF MESSAGES Using the asynchronous protocol, the Member State application can exchange messages among other Member States applications using store-and-forward technique. The store-and-forward technique is depicted at Figure 23. Figure 23: Store-and-forward technique Once the originator application puts the message into the originator gateway, it is stored and forwarded into the recipient s gateway. Then the recipient s application gets the message from the gateway. The asynchronous applications communicate via message queues. In this paradigm, both applications may not be executing concurrently, so that the message is stored in a queue until the recipient application is ready to process it. The interaction between applications using the queues is depicted at Figure 24. FITSDEV2-SC12-SDRP-Mini1SS-v1.03 Page 51 of 59

52 Figure 24: Applications communication using dedicated queues Once the application prepared the message, it puts it into the dedicated queue, in order to allow another application to get and process it. A message queue is a named destination to which messages can be sent. Messages accumulate on queues until they are retrieved by programs that service those queues. Queues reside in, and are managed by a queue manager. Queues and queue manager are physically located on the CCN/CSI gateways. The physical management is the responsibility of the queue manager. In CCN/CSI, all queues are permanent. Applications access their queues only through the CSI interfaces of the queue manager. They can open a queue, put messages on it, get messages from it, and close the queue. 8.4 REGISTRATION PROCESS MESSAGES QUEUES In order to ensure the communication in Mini-1SS, the following list of queues is needed for the registration processes: REGISTRATION: is dedicated for new registration and exclusion information transmitted spontaneously by the MSID to all Other MS; REGISTRATION_REQ: is the request queue to allow other MSs to request the MSID for registration information. REGISTRATION_RES: is the response queue to receive requested information; TECH_ERROR: is the queue dedicated to the technical error messages. The queues will be completely separate for the two schemes: different Mini-1SS and VoeS queues for the Registrations, for the Registration requests, and for the Technical errors. 8.5 SECURITY SERVICES CSI provides Application Program Interfaces (APIs) to perform the following security services in the National Domains: Authentication: 1 way-handshake and 3 way-handshake mechanisms are used to protect CCN/CSI against intrusion between Application Platform and Gateway. CCN/CSI security mechanisms are not symmetrical. The Application always initiates the authentication process, while the Remote API Proxy acts as a security server, accepting the connection. For secure links, a 1-way handshake is used for authentication. For non-secure links, a 3-wayhandshake is used for authentication. During this handshake, application key and user s password are protected from disclosure. FITSDEV2-SC12-SDRP-Mini1SS-v1.03 Page 52 of 59

53 Access Control Lists: Access controls based on users profiles are used to prevent access by nonauthorised users to applications resources (services and queues). Access control is built like filters according to a nothing except mode by which each actor not in the list is rejected. Two types of lists are defined: list of user profiles associated with each user; list of user profiles whose access to a given service (or a given queue) is authorised. First type of lists is managed by the local administrators while second type of list is managed by the central administrator. A user is allowed to access a service or a queue only if it is explicitly registered into an authorised profile. Confidentiality: Encryption mechanisms are used to ascertain non-disclosure of transmitted data. Confidentiality in the Community Domain is systematically ensured by cryptographic devices. On non-secure links, data can be optionally ciphered according to the needs of the application. In case of 3HC authentication mechanism, the algorithm used by CCN/CSI is DES in CBC mode. In case of 3HD authentication mechanism, the algorithm used by CCN/CSI is triple DES in CBC mode. In case of 3HE authentication mechanism, the algorithm used by CCN/CSI is triple DES in CBC mode with MD5. On secure links, confidentiality is implicit. Data is not ciphered by CCN/CSI. Integrity: Sealing mechanisms are used to detect alteration or replay of transmitted data. Integrity is systematically implemented on the CCN network by cryptographic devices. On non-secure links, data is sealed using a combination of hash function (MD5) and ciphering (DES or triple DES). Sequence integrity is provided by attaching a sequence number prior to sealing. On secure links, integrity is implicit. Data is not sealed by CCN/CSI. FITSDEV2-SC12-SDRP-Mini1SS-v1.03 Page 53 of 59

54 9 ANNEXES 9.1 GUIDELINES BPMN The following illustrates the BPMN (Business Process Model and Notation) version 2.0 Level 1 symbols used within the process flows in the mini-one Stop Shop, and gives a brief description of each FLOW OBJECTS Object Description Symbol Event An Event is something that happens during the process. These events affect the flow of the process and usually have a cause (trigger) or an impact (result). Three main types of events are defined: Start, Intermediate and End. All events have triggers that define the cause for the event. The empty cells refer to undefined, or unused event types. Event Types Type Description Start Intermediate End General Start Event indicates when a particular process will start. Intermediate Events occur between a Start Event and an End Event. It will affect the flow of the process, but will not start or (directly) terminate the process. End Event indicates when a process will finish. Message A Message arrives from a participant and triggers the Event. This causes process to {start, continue, end} if it was waiting for a message, or changes the flow of exception handling. Timer A Timer event signifies the process is run on some predetermined schedule, either one-time or recurring. N/A FITSDEV2-SC12-SDRP-Mini1SS-v1.03 Page 54 of 59

55 Object Description Symbol Object Description Symbol Activity An Activity is a generic term that describes the kind of work which must be performed. An activity can be atomic (Task) or compound (Subprocess). Used when no Legal Reference exists. Task is labelled with a name plus a noun. When possible, it may includes a Legal Reference. A collapsed subprocess is used to hide or reveal additional levels of business process detail and has its own self-contained start and end events. It is represented with a + symbol at the bottom center. The Loop Activity is a type of Activity that acts as a wrapper for an inner Activity that can be executed multiple times in sequence. The subprocess symbol will be used if the Loop Activity is a collapsed subprocess. Gateway A Gateway is used to split or merge multiple process flows. Thus, it will determine branching, forking, merging and joining of paths. Gateway types Type Description Symbol Exclusive Gateway XOR: exclusive decision and merging (Data-Based) Parallel Gateway AND: parallel forking and joining (synchronization) Table 25: Guidelines BPMN: Flow objects CONNECTING OBJECTS There are two ways of connecting flow objects (Events, Activities, Gateways) to each other or to other information using Sequence Flow and Message Flow. Object Description Symbol Sequence Flow A Sequence Flow is used to show the order that activities will be performed in a Process. It is a solid line connector linking activities, gateways, and events in a single Pool. FITSDEV2-SC12-SDRP-Mini1SS-v1.03 Page 55 of 59

56 Object Description Symbol Message Flow A Message Flow is used to show the flow of messages between two participants (two separate Pools) that are prepared to send and receive them. A Message Flow can never be used to connect activities or events within the same Pool. Table 26: Guidelines BPMN: Connecting objects SWIMLANES Pools and Lanes are used to represent organisations, roles, systems or responsibilities. Examples:, MSID, VIES system, etc. Object Description Symbol Pool A Pool represents a participant (actor, system actor, etc.) in a process. A Pool contains one or more Lanes (like a real swimming pool). Lane Lane is used to organise and categorise activities within a Pool according to function or role, and depicted as a rectangle stretching the width or height of the pool. A Lane contains the flow objects, connecting objects and artefacts. Table 27: Guidelines BPMN: Swimlanes ARTEFACTS Artefacts are used to provide additional information about the process. Examples of data objects: Application, message, XML document, etc. Object Description Symbol Annotation Data Object A text Annotation and assotiation is a mechanism for a modeller to provide additional information for the reader of a Collaboration Diagram. A Data Object provides information about what activities are required to be triggered and/or produce. It is considered as Artefacts because it does not have any direct effect on the Sequence Flow or Message Flow of the process. FITSDEV2-SC12-SDRP-Mini1SS-v1.03 Page 56 of 59

57 Object Description Symbol Group A Group is represented with a roundedcorner rectangle and dashed lines. The group is used to group different activities but does not affect the flow in the diagram. Label A Label is used to number the flow objects within a Collaboration Diagram: E = Event GW = Gateway (a description can be added). Link Event Pair A Link Event Pair stands for a sequence flow Go to and From, typically used as an off-page connector. Table 28: Guidelines BPMN: Artefacts 9.2 BUSINESS PROCESS MODEL AND NOTATION VERSION 2.0 LEVEL 2 The following illustrates the BPMN (Business Process Model and Notation) version 2.0 Level 2 symbols used within the process flows in the mini-one Stop Shop, and gives a brief description of each FLOW OBJECTS Object Description Symbol Event Types Type Description Start Intermediate End Boundary Error Events A boundary event (attached to an Activity boundary) listens for an error signal while the activity is running. If the signal occours, interrupting events abort the activity and exit on the exception flow. N/A N/A Object Description Symbol Activity A User Task is a manual activity. FITSDEV2-SC12-SDRP-Mini1SS-v1.03 Page 57 of 59

58 Object Description Symbol A Business Rule activity evaluates a business rule A Global Activity is a call to a re-usable activity. It uses the same symbol as an Activity but has a thick line. Table 29: BPMN 2.0 Level 2 Flow objects 9.3 TOOLS USED To design BPMN processes, the used tool is Microsoft VISIO. To describe BPMN processes, the used tool is Microsoft WORD. 9.4 DATA MODEL NOTATIONS NOTATIONS USED IN THE DATA MODEL DIAGRAMS The following notations are used throughout the document for the figures. Symbol Explanation Example This symbol means that an element is a sequence of other inner elements. This symbol means that an element is made of one and only one of the inner elements. The element Sequence is composed of two (child) elements: FirstElement and SecondElement. This continuous border indicates a mandatory element or attribute within an instance document. The three lines in the upper left corner indicate that the element has no child element (this notation does not apply to attributes). This dashed border means that the element or attribute is optional within an instance document. The element Choice contains as child element either FirstChoice or SecondChoice. The element MandatoryElement must be present in any XML instance document. The OptionalElement is optional in any XML instance document. FITSDEV2-SC12-SDRP-Mini1SS-v1.03 Page 58 of 59

59 Symbol Explanation Example The figures indicate the cardinality. The element Sequence is made of the following child elements: FirstElement: this element must occur at least one time; The symbol means that an element has an attribute, which provides additional information about element. SecondElement: this element is optional and can occur at most five times. Table 30: Data Model notations The element Element has its attribute defined as ElementAttribute. End of document FITSDEV2-SC12-SDRP-Mini1SS-v1.03 Page 59 of 59