View
0
Download
0
Category
Preview:
Citation preview
COMMON TECHNICAL PROCEDURES
(Based on the TS-AEOI DAC2-1.11 EU Document)
Για λόγους διαφάνειας και καλύτερης επικοινωνίας δημοσιεύεται τμήμα των τεχνικών οδηγιών της ΕΕ προς τα κράτη μέλη. Οι οδηγίες αφορούν τη δημιουργία τροποποιητικών αναφορών DAC2/CRS και παραδείγματα τέτοιων υποβολών και εφαρμόζονται κατά την ανταλλαγή στοιχείων μεταξύ των κρατών μελών.
Κατ’ αντιστοιχία και για την ανάγκη απλοποίησης του συστήματος θα ισχύουν και για την υποβολή τροποποιητικών από τα υπόχρεα ελληνικά Χρηματοπιστωτικά Ιδρύματα προς την ΑΑΔΕ. Επειδή οι οδηγίες αφορούν κράτη μέλη σε πολλά σημεία αναφέρεται ως αποστέλλων την αναφορά το SS (Sending Member State). Όσον αφορά τις αναφορές που αποστέλλονται προς την ΑΑΔΕ που SS εννοείται αποστέλλων χρηματοπιστωτικό ίδρυμα. Τα υποδείγματα των αναφορών που αναφέρονται στο συμπιεσμένο αρχείο CorrectionXMLExamples.zip που δημοσιεύεται στον ιστότοπο της ΑΑΔΕ μαζί με το παρών κείμενο.
1 TERMINOLOGY
1.1 ABBREVIATIONS AND ACRONYMS
Definition Meaning
AEOI Automatic Exchange of Information
Art. Article
ASCII American Standard Code for Information Interchange
BOM Byte Order Mark: a Unicode character to signal whether a text file is big or little endian
BR Business Rule
CACT Committee on Administrative Cooperation for Taxation
CCN Common Communication Network
CDE Common Data Element
COA Confirm on Arrival
COD Confirm on Delivery
CRS Common Reporting Standard
CSI Common System Interface
DAC Directive on Administrative Cooperation
DG TAXUD Directorate-General Taxation and Customs Union
DT Data Type
EC European Commission
EU European Union
FA Financial Account
FATCA Foreign Account Tax Compliance Act
FI Financial Institution
FIS FISCALIS Information Systems
FITS FISCALIS Information Technology Services
FITSDEV3 FITS Development
FS Functional Specifications
IBAN International Bank Account Number
ID Identifier
IT Information Technology
ITSM IT Service Management
ISO International Organization for Standardization
LCT Local Client Testing
LDM Logical Data Model
LST Local Server Testing
MB Megabyte
Definition Meaning
MS Member State
MSA MS Administration
MSG Message
N/A Not Applicable
NA National Administration
NFE Non-Financial Entity
OBAN Other Bank Account Number
OECD Organisation for Economic Cooperation and Development
PDM Physical Data Model
PK Primary Key
RCT Remote Conformance Testing
RIT Remote Interoperability Testing
RR Receiving MS - MS receiving a MSG (any type of MSG) whatever the process
SC Specific Contract
SD System Design
SS Sending MS - MS sending a MSG (any type of MSG) whatever the process
TIN Tax Identification Number
ToC Terms of Collaboration
TS Technical Specifications
UTC Coordinated Universal Time
VAT Value Added Tax
VIES VAT Information Exchange System
XML Extensible Mark-up Language
XSD XML Schema Definition
2 COMMON TECHNICAL PROCEDURES
2.1 COMMON APPROACH FOR PASSIVE NFEIn the case of an account held by a Passive NFE that is a reportable Person and that is also identified as having in the same MS, one or more Controlling Persons, that is a reportable person, the SS must report the information related to the Passive NFE and each Controlling Person. The CRS has described two approaches as regards how to report such a situation. The system will accept the two approaches. However in order to improve the communication between MS, and have a common understanding, it is recommended to follow the second approach described in the CRS and also explained in this section.
The approach consists of reporting the account:
as an account held by a passive NFE with one or more controlling person that is a reportable person where the element AcctHolderType of the element AccountHolder (see section Error: Reference source not found) must be set to CRS101;
and also as an account held by a passive NFE that is a reportable person where the element AcctHolderType of the element AccountHolder (see section Error:Reference source not found) must be set to CRS103.
The Table 1 describes all the possible values for the element AcctHolderType for a Passive NFE with one or more controlling persons and the recommended approach is highlighted in light green.
Passive NFE
Is a reportable person Is NOT a reportable person
Con
trol
ling
Pers
on
Is a reportable person
Two records: CRS101; CRS103.
One record: CRS10
1.
One record: CRS101.
Is NOT a reportable person
One record: CRS103.
Not Applicable
Table 1: Account holder type to use for a Passive NFE
2.1.1 EXAMPLE
The example relies on the schema defined in section Error: Reference source not found.
It covers the following scenario:
A Financial Institution in MS A has an account held by a Passive NFE, MS B resident, with three controlling persons: two of them are MS B residents and the third is MS C resident.
The Financial Institution reports to his competent authority this Financial Account information;
In this case the SS sends two Initial messages, one for MS B and another for MS C. The message towards MS C contains one account including the Passive NFE as holder of type CRS101 and the MS C controlling person. The message towards MS B contains two accounts. The first one contains only the Passive NFE as holder of type CRS103 and the second one contains the Passive NFE as holder CRS101 with the two MS B controlling persons. Figure 11 highlights this.
1 The figure omits most of the data, and only highlights the main areas of interest.
<CRS_OECD>
Initial message - MS B
<CrsBody>
<ReportingFI>
<ReportingGroup>
<AccountReport>
<ControllingPerson>
<ControllingPerson>
Initial message - MS C
<ResCountryCode> = MS B
<ResCountryCode> = MS B
<AccountReport>
<AccountHolder>
<Organisation>
<ResCountryCode> = MS B
<AcctHolderType>=CRS103
<AccountHolder>
<Organisation>
<ResCountryCode> = MS B
<AcctHolderType>=CRS101
<CRS_OECD>
<CrsBody>
<ReportingFI>
<ReportingGroup>
<AccountReport>
<ControllingPerson>
<ResCountryCode> = MS C
<AccountHolder>
<Organisation>
<ResCountryCode> = MS B
<AcctHolderType>=CRS101
Figure 1: Re-send all child elements
The following example files, in the order they are presented, provide concrete messages for this scenario:
NFE-Example-Init-MSB.xml NFE-Example-Init-MSC.xml
2.2 MODIFICATIONS TO SENT DATA
In the course of the exchange of messages, the SS may need to amend data previously sent. The section describes how the system should specify these changes through the correction mechanism (section 2.2.1) and how corrections and deletions can be used together (section 2.2.2).
The message is just an envelope, for a specific reporting period, which contains a set of records. The message has no business meaning. Concretely, this means that all the records
of the message concern the same reporting period and the message is accepted or rejected as a unit of work.
2.2.1 CORRECTION MECHANISM
The system supports corrections. This section describes the possible situations and presents how to handle them.
2.2.1.1 REASONS FOR CORRECTION
The following kinds of error may justify the need for a correction:
Invalid syntax: the structure of the received file is not valid. For example, the file is not in XML format, is not well-formed XML or does not match the schema described in this document;
Invalid semantic: the received file contains errors related to business rules that are not checked by the XSD (for example, the format of the Account Number), or related to other unexpressed business rules (for example, a person residing in Valencia, Italy while Valencia is actually in Spain). These rules can further be divided in the following categories:
o The error is picked up automatically by the validation module;o The error is found by a member of the RR MSA after the system has
processed and integrated the message;o The error is found by the SS but not yet by the RR.
If the validation module encounters one or more syntax errors, the RR ignores the received file and returns a status message with the found errors (see section Error: Reference sourcenot found). The SS must then correct its implementation and send back the message. Since the first message was ignored, a correction message is not needed (unless the file was already a correction, in which case the new file remains of the same type). For traceability purposes, the new message must have a different MessageRefId than the rejected one, even if it mostly holds the same content.
If the validation module encounters one or more semantic or technical errors (see section Error: Reference source not found), the RR can decide how it wishes to proceed. If the error is deemed grave enough, it rejects the message, and it and the SS proceeds as if there was a syntax error (i.e. the RR ignores the file and the SS must send a new one). If the errors are not considered as grave, the RR integrates the data in its national system and sends a Status message indicating acceptance of the received message, but mentioning the detected errors. Note that the RR must accept or reject the message as a whole, and cannot integrate only part of the data while indicating an error.
Whenever possible, the RR should reply with as many errors as possible, not stopping at the first one (e.g. two business rule errors would lead to a single Status message with two errors). However, since an error in message syntax compromises the parsing of all data after the location of the error, it may be that only part of the errors can be reported during a first pass through the message. Further errors would then be detected once the first ones have been corrected.
If a semantic error is found after the system has processed and integrated the message into the database, the SS should spontaneously send a correction message as described in the following sections.
2.2.1.2 CORRECTABLE ELEMENTS
Only the top-level element is correctable. In the XSD, there are two top-level elements, the ReportingFI and the AccountReport. The system must consider these two top-level elements separately. The correction of one of the two top-level elements must not impact the other related top-level element.
If a correction targets a previously sent child element of a top-level element, the system must re-send the related parent top-level element and all its children. This is applicable for ReportingFI and AccountReport. This results in a waste of space when the correction concerns only part of the information, but it has the following advantages:
Since the top-level element is self-contained, the validation does not need access to the database in order to check that the correction does not violate business rules;
The SS can generate the correction with only minor changes to the routines already used to generate the Initial messages;
The RR can easily integrate the correction by invalidating separately for each top-level element the previously recorded information, and then call the routines already used to integrate the Initial messages;
This procedure does not require a specific XSD for the sake of corrections.
In order to be able to identify the elements to correct, the definition of these top-level elements includes an element of type Error: Reference source not found, which include elements named DocTypeIndic, DocRefId and CorrDocRefId. For a Correction message, the system allows the following combinations of DocTypeIndic for the correctable elements, taking into account that the AccountReport element is not mandatory:
w/o AccountRepo
rtAccountReport
- OECD1 OECD2 OECD3 OECD0
ReportingFI
OECD1
OECD2 OK OK OK
OECD3 OK OK
OECD0 OK OK
Table 2: Combinations of DocTypeIndic for the correctable elements within a Correction message
When a correction targets only the AccountReport element and there is no modification of the related ReportingFI, the DocTypeIndic “OECD0-Resend Data” is used for the ReportingFI element. This type is only allowed for ReportingFI element.
If the validation module encounters another combinations than these presented above, the RR ignores the received file and returns a status message with the relevant technical error code (see section Error: Reference source not found).
2.2.1.3 STRUCTURE OF A CORRECTION MESSAGE
A correction message has essentially the same structure as an Initial message, as it follows the same schema. There is only a minor difference in the Header: the MessageTypeIndic must be set to CRS702.
There are also three differences in the Body:
A corrected element will have a DocTypeIndic value of OECD2 or OECD3 (OECD1 for Initial messages);
Regarding the ReportingFI, the DocTypeIndic will have for value OECD2/OECD3 if it has been modified/deleted since the previous sending, OECD0 if the ReportingFI was not modified (split of message or late reporting for example);
Its CorrDocRefId references the DocRefId of the element to correct (this element is not specified in Initial messages).
Since the DocRefId is unique in time and space (section Error: Reference source not found), the correcting records must have different DocRefIds than those of the records being corrected.
A correction message can contain either corrections (OECD2) or deletions (OECD3) or both and also resent ReportingFIs (OECD0) but not new data (OECD1).
2.2.2 RELATIONSHIP BETWEEN MESSAGES
This section describes how messages exchanged through the correction mechanism described above interact with one another.
Since messages specify the reporting period for which it relates, a correction message may correct records originating from any previous Initial or Correction messages for the same reporting period.
2.2.2.1 CORRECTION OF AN INITIAL MESSAGE
The correction of an Initial message is the most common situation. The correction is used to correct the elements that was not correct (from a technical point or business point of view), or to delete elements from the Initial message.
A unique MessageRefId is created respecting the format defined in the section Error:Reference source not found.
A new DocRefId is created for each correctable element and should follow the format described in section Error: Reference source not found.
The CorrDocRefId must reference the DocRefId of the elements to be corrected / deleted from the Initial message.
2.2.2.2 CORRECTION OF A CORRECTION MESSAGE
Corrections of corrections are legitimate. In that case, the CorrDocRefId of the second correction of the entity must reference the DocRefId of the first correction.
This is required in order to determine uniquely the order in which the RR system must apply the corrections. Suppose two corrections reference the same entity and, for some technical reason (e.g. infrastructure or architecture constraints), arrive out of order2. The RR system would first integrate the second correction, then the first one, effectively dismissing the second (and most recent) correction.
If the RR receives messages that it considers as probably being out of order, it should – as a best practice – wait for some time before discarding the message, in case the previous messages arrive some time later3. If such a message does not arrive, it should contact the SS using the Send (Technical) Query Operational Procedure defined in the Terms of Collaboration [Error: Reference source not found].
2.2.2.3 ERROR HANDLING
If the SS does not respect any of the above constraints, the RR must reply with a Status message mentioning that the corrected entity is not known or not valid anymore (see section Error: Reference source not found), depending on the available information.
2.2.3 EXAMPLES
The following sections provide examples of concrete correction scenarios, and highlight correction rules applicable to each of them. The examples rely on the schema defined in section Error: Reference source not found.
Each example presents one or more figures to illustrate the situation. These figures omit most of the data, and only highlight the main areas of interest.
Each example is illustrated by one or more XML messages. The Table 3 lists the XML messages annexed to this document, and indicates to which section they relate.
# File Section(s)
1 Correction-Example-Init-2AR1FI.xml 2.2.3.1, 2.2.3.2, 2.2.3.8
2 Correction-Example-Corr-TwoSuc-1.xml 2.2.3.1, 2.2.3.2
3 Correction-Example-Corr-TwoSuc-2.xml 2.2.3.1
4 Correction-Example-Corr-TwoSuc-3.xml 2.2.3.2
5 Correction-Example-Init-MultiCP-1.xml 2.2.3.5
2 CCN, for example, does not offer a guarantee that messages will be delivered in order.3 The actual effort to put in this procedure is left at the appreciation of the MS. Since this event is possible but very unlikely, it is probably not useful to build a complex automated system to resolve this issue.
# File Section(s)
6 Correction-Example-Init-MultiCP-2.xml 2.2.3.5
7 Correction-Example-Corr-MultiCP-1.xml 2.2.3.5
8 Correction-Example-Corr-MultiCP-2.xml 2.2.3.5
9 Correction-Example-Init-1AR1FI.xml 2.2.3.3, 2.2.3.6, 2.2.3.9, 2.2.3.10, Error: Reference source not found
10 Correction-Example-Corr-CorrChild.xml 2.2.3.3
11 Correction-Example-Init-2AR1FI-2.xml 2.2.3.4
12 Correction-Example-Corr-2CorrElement.xml 2.2.3.4
13 Correction-Example-Init-2AR1FI-3.xml 2.2.3.7, Error: Reference source not found
14 Correction-Example-Corr-RemChild-FI.xml 2.2.3.7
15 Correction-Example-Corr-RemTopLevel.xml 2.2.3.8
16 Correction-Example-Corr-AddChild.xml 2.2.3.9
17 Correction-Example-Init-1AR1FI-2.xml 2.2.3.10
Table 3: Annexed XML messages
In the examples below the following convention has been used to highlight the elements that need to be corrected or just resent:
The green colour is used when the ReportingFI has to be resent even if no modifications are required. In this situation, the element is identified with the same DocRefId as the immediately preceding version of the ReportingFI and the code OECD0 is used. It is worth to note that the RR must not persist the information related to the ReportingFI;
The red colour is used to identify the elements that require to be corrected (Initial message) or are corrected (Correction message).
2.2.3.1 TWO SUCCESSIVE CORRECTIONS OF THE SAME ACCOUNT
This example covers the following scenario:
The SS sends an Initial message with one financial institution and two accounts; It then sends a first Correction message correcting the payment amount of the first
account; It finally sends a second Correction message, correcting the account balance yet
again for the first account.
There are four areas of interest here highlighted by Figure 2:
The CorrDocRefId of the account refers to the immediately preceding entity, not to any preceding one (in particular, not systematically to the first one);
The DocTypeIndic of the account is set to OECD1 within an Initial message and to OECD2 within a Correction message;
The SS must always resend the financial institution (according to the XSD, see section Error: Reference source not found) associated to the account being corrected, even though it did not require modifications. The DocTypeIndic is set to OECD0 and the DocRefId is the same as the immediately preceding entity;
The SS must only resend the corrected account. The second one, which does not require corrections, is not part of the Correction message.
Figure 2: Two successive corrections of the same account.
The following example files, in the order they are presented, provide concrete messages for this scenario:
Correction-Example-Init-2AR1FI.xml; Correction-Example-Corr-TwoSuc-1.xml; Correction-Example-Corr-TwoSuc-2.xml.
2.2.3.2 TWO SUCCESSIVE CORRECTIONS OF DATA FROM THE SAME MESSAGE
This example covers the following scenario:
The SS sends an Initial message with one financial institution and two accounts; It then sends a first Correction message correcting the address of the financial
institution; It finally sends a second Correction message, correcting the first account (new
account payment).
Figure 3 highlights the three areas of interest:
The SS must always resend the financial institution (according to the XSD, see section Error: Reference source not found) associated to the account being corrected, even though it did not require modifications. The DocTypeIndic is set to OECD0 and the DocRefId is the same as the immediately preceding entity;
The SS must only resend the corrected account. The other one, which does not require corrections, is not part of the Correction message;
The SS can send the corrected financial institution without the accounts if they do not require corrections.
Figure 3: Two successive corrections of data from the same message
The following example files, in the order they are presented, provide concrete messages for this scenario:
Correction-Example-Init-2AR1FI.xml; Correction-Example-Corr-TwoSuc-3.xml; Correction-Example-Corr-TwoSuc-1.xml.
2.2.3.3 CORRECTION OF A CHILD ELEMENT OF THE ACCOUNTREPORT ELEMENT
This example covers the following scenario:
The SS sends an Initial message with a financial institution, and an account composed of a number, an holder, two controlling persons residing within the same country and a balance;
It then wants to correct the address of the first controlling person.
In this case, the SS must correct the account from the Initial message, and send it back with the corrected controlling person data. It must also include the financial institution since this element is mandatory, as well as the second controlling person, the number, the holder and the balance; even though they did not require modifications (omitting it would lead to confusion with the example from section 2.2.3.4). Figure 4 highlights this.
Figure 4: Re-send all child elements
The following example files, in the order they are presented, provide concrete messages for this scenario:
Correction-Example-Init-1AR1FI.xml; Correction-Example-Corr-CorrChild.xml.
2.2.3.4 CORRECTION OF TWO CORRECTABLE ELEMENTS WITHIN THE SAME MESSAGE
This example covers the following scenario:
The SS sends an Initial message containing two accounts and the associated financial institution. The first account is composed of a number, an holder, a controlling person and a balance. The second account is composed of a number, an holder and a balance. The financial institution is composed of a name and an address;
It then wants to correct the address of the financial institution and the balance of the first account.
In this case, the SS must correct the financial institution and the first account from the Initial message. The financial institution must contain the corrected address as well as the name. The first account must contain the corrected balance, as well as the number, the holder and the controlling person. The second account is not re-sent. Figure 5 highlights this.
Figure 5: Correction of the two correctable elements within the same message
The following example files, in the order they are presented, provide concrete messages for this scenario:
Correction-Example-Init-2AR1FI-2.xml; Correction-Example-Corr-2CorrElement.xml.
2.2.3.5 CORRECTION OF A PERSON CONTROLLING AN ORGANISATION TOGETHER WITH PERSONS FROM OTHERS MSS.
This example covers the following scenario:
The financial institution reports to his competent authority, an account whose holder is a Passive NFE with two controlling persons from different MSs. Both controlling persons are reportable persons;
Then the SS sends two Initial messages, one per country of residence for tax purposes of the controlling persons;
Finally the financial institution reports a corrected controlling person for the account sent initially.
In this case, the SS must correct the account with the corrected controlling person. Since the ControllingPerson is not a correctable element, the system cannot determine directly in the information received if there was a change. Therefore the SS must send the account to all countries who received it initially even if the controlling person does not require modification. The financial institution is also included since this element is mandatory. Figure 6 highlights this.
Figure 6: Controlling Persons from different MSs
The following example files, in the order they are presented, provide concrete messages for this scenario:
Correction-Example-Init-MultiCP-1.xml Correction-Example-Init-MultiCP-2.xml Correction-Example-Corr-MultiCP-1.xml Correction-Example-Corr-MultiCP-2.xml
2.2.3.6 REMOVAL OF A CHILD ELEMENT OF THE ACCOUNTREPORT
This example covers the following scenario:
The SS sends an Initial message with a financial institution, and an account composed of a number, an holder, two controlling persons and a balance;
It then wants to remove the first controlling persons.
In this case, the SS must correct the account from the Initial message, and send it back without the deleted controlling person but with the other controlling person, the number, the holder, the balance and the financial institution since this element is mandatory. Figure 7 highlights this.
Figure 7: AccountReport-Omit removed children
The following example files, in the order they are presented, provide concrete messages for this scenario:
Correction-Example-Init-1AR1FI.xml; Correction-Example-Corr-RemChild.xml.
2.2.3.7 REMOVAL OF A CHILD ELEMENT OF THE REPORTINGFI
This example covers the following scenario:
The SS sends an Initial message with two accounts and the associated financial institution having a name and two addresses;
It then wants to remove the second address of the financial institution.
In this case, the SS must correct the financial institution from the Initial message, and send it back without the deleted address but with the other address, and the name. The accounts are not re-sent. Figure 8 highlights this.
Figure 8: ReportingFI-Omit removed children
The following example files, in the order they are presented, provide concrete messages for this scenario:
Correction-Example-Init-2AR1FI-3.xml; Correction-Example-Corr-RemChild-FI.xml.
2.2.3.8 REMOVAL OF A TOP-LEVEL ELEMENT
This example covers the following scenario:
The SS sends an Initial message with two accounts and the associated financial institution. Each account is composed of a number, an holder and a balance;
It then wants to remove the first account.
In this case, the SS must correct the first account indicating that it must be deleted (DocTypeIndic is set to OECD3), omit the second account since it does not require corrections, and send it back with the child elements of the corrected account as well as the financial institution since this element is mandatory. Figure 9 highlights this.
Figure 9: AccountReport-Removal top-level element
The following example files, in the order they are presented, provide concrete messages for this scenario:
Correction-Example-Init-2AR1FI.xml; Correction-Example-Corr-RemTopLevel.xml.
An exception can occur for the removal of a Top-level element if the correction message removes only the financial institution without the associated accounts. In this case, the system must not allow this operation because it does not make sense to keep the account(s) without the corresponding financial institution. The system must thus answer with a rejection Status message, using the appropriate error code (section Error: Reference source not found).
It is also worth to note that the removal of a financial institution is persisted only if all the associated accounts have been already removed.
2.2.3.9 CREATION OF A CHILD ELEMENT
This example covers the following scenario:
The SS sends an Initial message containing an account and the associated financial institution. The account is composed of a number, an holder and a balance;
It then wants to add a payment to that account.
In this case, the SS must correct the account from the Initial message specifying a new payment and send it back with the number, the holder, the balance and the financial institution since this element is mandatory. Figure 10 highlights this.
Figure 10: Create a child element
The following example files, in the order they are presented, provide concrete messages for this scenario:
Correction-Example-Init-1AR1FI.xml; Correction-Example-Corr-AddChild.xml.
2.2.3.10 CREATION OF A NEW TOP-LEVEL ELEMENT FOR THE ACCOUNTREPORT
This example covers the following scenario:
The SS sends an Initial message with one account and the associated financial institution;
It then wants to send another account.
In this case, the SS creates a new Initial message, with only the new account and the already sent financial institution.. Figure 11 highlights this.
Figure 11: Creation of a new top-level element for the AccountReport
The following example files, in the order they are presented, provide concrete messages for this scenario:
Correction-Example-Init-1AR1FI.xml; Correction-Example-Init-1AR1FI-2.xml.
This scenario does occur only in specific circumstances such as late reporting or in the case of split messages.
Recommended