A Common Identification System for The Electricity Industry. The ETSO Identification Coding Scheme EIC

Transcription

1 A Common Identification System for The Electricity Industry The ETSO Identification Coding Scheme EIC Version: 2 Release: 1 Version: 2 Release: 1 10 November 2002 Page : 1/24

2 REVISION HISTORY Version Release Date Paragraphs Comments Initial publication Correction to remove the use of the asterisk character (*) in the code since the code could be used in a filename General revision to incorporate all the facilities and requirements of an issuing office. Copyright ETSO 2002, all rights reserved. Copyright notice: Copyright ETSO All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, by, for example, removing the copyright notice or references to ETSO. It may be changed, however, as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by ETSO or its successors. This document and the information contained herein is provided on an "as is" basis. ETSO DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Version: 2 Release: 1 10 November 2002 Page : 2/24

3 Contents 1. Introduction General requirements for the administration of EIC ETSO Identification Coding scheme - EIC INTRODUCTION ADMINISTRATIVE ORGANIZATION IDENTIFICATION CODE EIC CODE VALIDATION ISSUING OFFICES SERVICES MAINTENANCE AND ORGANISATION COSTS ETSO Steering Committee position Annex 1: The ETSO Check Character algorithm Annex 2: Metering point coding scheme example Annex 3: XML message structure for issuing office applications Annex 4: XML message structure for EIC code allocations Version: 2 Release: 1 10 November 2002 Page : 3/24

4 PAGE INTENTIONALY LEFT BLANK Version: 2 Release: 1 10 November 2002 Page : 4/24

5 1. Introduction Electronic Data Interchange in the European Electricity Market needs common identification schemes to be effective. Market Agents (Traders, producers, and qualified consumers) have the possibility to act in different TSO areas and TSOs have to exchange information among themselves concerning the market players in question. In order to do this a reliable identification scheme is necessary. The primary objects concerning scheduling that need to be identified are: A. Parties: TSOs, traders, producers, big consumers, power exchanges, grid operators, suppliers, agents and service providers B. Areas: Local grids where metering points are situated, balance areas consisting of a number of local grids and control areas C. Metering Points: For production units, consumers cross border connections, etc. The ETSO Task Force 14 "EDI between Market Participants" has investigated the current use of identification schemes in the member countries. The results of this study showed that for points A and B most countries are using an existing national identification scheme and that the rest have just introduced an international identification scheme from the international EAN organisation. For point C, Metering Points, some countries are using an existing national identification scheme whereas others, who do not have a national standard, are now in the process of introducing either a national identification scheme or an international identification scheme based on EAN numbers. The task force has discussed the possibility to make one of the national identification schemes to a European standard. The conclusion is that the most widespread identification scheme the German DVG scheme - is designed for manual data interchange and the traditional organisation of the industry. It also lacks possibility to identify metering points. In its present form it is therefore unfortunately unsuitable for future high-level electronic data interchange. The task force has looked into the use of several international identification schemes and has established that some of the schemes could be used. In particular, the task force looked into the possibility of using the EAN identification scheme and has determined that its use is feasible but it provides no associated services. EAN does require, however, the payment for the allocation of codes and a yearly fee for their use. At a meeting in Madrid on 29 October 2001 it showed that the ETSO countries that need a new identification system are not in favour of paying EAN for the system. The German TSO association has recognised the need for administrative services within its national identification scheme. TF14 in its analysis of the situation established that such administrative services are a prerequisite to a reliable identification scheme. In conclusion, TF14 considers that it would probably be better to establish a new electricity identification code that combines the optimisation of the allocation costs and provides the required services for the electricity market. Version: 2 Release: 1 10 November 2002 Page : 5/24

6 TF14 therefore proposes an identification scheme, which provides an easy migration path for the existing German DVG scheme, in a format that makes it suitable for general electronic data interchange. This new ETSO Identification Coding scheme - EIC - is described in the rest of this paper. The ETSO Steering Committee approved the ETSO Identification Coding scheme at their meeting on 14 May 2002 stating that EIC and EAN coding schemes shall be the preferred schemes for data interchange. Each TSO shall define: 1. the use of the EIC, 2. or the use of EAN, 3. or the use of both the EIC and EAN scheme, except where bilateral agreements exist on the use of an alternative coding scheme. Version: 2 Release: 1 10 November 2002 Page : 6/24

7 2. General requirements for the administration of EIC A successful identification scheme requires that the allocated codes are stable over time. This implies that the significance of a code should always remain constant. EIC Issuing Offices shall assure: 1. Issued codes shall be globally unique 2. Once a code is allocated to identify an organisation or organisational function or entity, it shall only change if the organisation s status changes. Consequently, if the organisation merely changes its name, its code will not be modified. 3. Only TSOs and regulators are allowed to request new area identifications. Areas used in inter TSO data interchange should be named centrally. An identification scheme also requires a certain number of services. These services should include, for example: 1. The correct allocation of codes 2. The management of the code lists (inquiry, deletion and modification) 3. Information on the significance of codes 4. Contact details about the designated organisations 5. Communication parameters ( , http, network address, etc ) 3. ETSO Identification Coding scheme - EIC 3.1 Introduction The code will be under the responsibility of the ETSO organisation but with all the work to assign and manage codes carried out by other organisations according to the agreed rules. These organisations will be authorised by ETSO. Such organisations will typically be the national electricity organisations. They can then assign codes to their members and to others on a previously agreed basis. ETSO Organization through ETSO TF 14 has defined a coding system and the administrative organization to manage and maintain them. 3.2 Administrative Organization The administrative organization will be a two level structure: Level 1: Central Issuing Office The Central Issuing Office is under the direct responsibility of ETSO Organization. Task Force 14, on behalf of ETSO Organization will perform the functions of the Central Issuing Office as long as the group remains in existence. When Task Force 14 terminates, a common neutral body will be set up to continue these functions. Version: 2 Release: 1 10 November 2002 Page : 7/24

8 Level 2: Local Issuing Offices The Local Issuing Offices act as agents of Central Issuing Office. Each ETSO participating country or European association, which directly or indirectly is a part of the European internal market for energy, can have a Local Issuing Office (EIC issuing office). The Local Issuing Office can either be a separate legal body or a part of an existing body. In order to qualify as a Local Issuing Office the applicant must apply to the ETSO secretary general. 3.3 Identification code The identification scheme is based on fixed length alphanumeric codes. The codes will contain information about the issuing office in addition to information on the object identified. Permitted characters are numbers (0 to 9), capital letters (A to Z, English alphabet) and the sign minus (-). To avoid confusion, the check character shall use numbers (0 to 9), capital letters (A to Z) and the character asterisk (*). Currently two natures of object have been identified in the coding scheme: A. Party (EIC-X): 16-character code consisting of: 2-character number for issuing office assigned by ETSO the letter "X" to identify the fact that this is a party code 12 digits or uppercase characters allocated by the issuing office in compliance with general and local rules. Each party should have the possibility to chose the code to their like, be it characters or numbers in respect to these rules. 1 check character Example: 11XRWENET A party is allowed to have only one EIC code for a given organisational function or entity within the European internal energy market. This is required in order to ensure that for all inter-tso exchanges the identification of a party in its correct capacity will remain consistent. B. Area (EIC-Y): 16 character code consisting of: 2-character number for issuing office assigned by ETSO the letter "Y" to identify the fact that this is a area code 12 digits or uppercase characters allocated by the issuing office in compliance with general and local rules 1 check character Examples: 10YDK-BALANCE-WM for the western balance area in Denmark. Version: 2 Release: 1 10 November 2002 Page : 8/24

9 All areas involved in inter TSO data interchange must be identified on a central basis. 3.4 EIC code validation The identification code may be simply be validated by applying a weighting to each of the 16 characters going from a weighting of 16 for the leftmost character to 1 for the rightmost character (which is in itself the check character) and applying the formula R= MOD( weighted value, 37) where to be valid R must equal 0. (See Annex 1 for details) 3.5 Issuing offices Central Issuing Office The Central Issuing Office shall be responsible for providing the 2-character EIC code that identifies the Local Issuing Offices. It shall also be responsible for providing the 16-character EIC codes to any recognised TSO or area (used in inter-tso data interchange). Areas used in inter-tso data interchange shall be named directly by the Central Issuing Office. Only system operators and imbalance settlement responsible organisations may request new area EIC identification codes. ETSO will maintain a list of all issuing offices and allocated EIC codes in a centralised database. The Central Issuing Office may occasionally allocate EIC codes for parties not having a Local Issuing Office. In this context, as in the case where it allocates TSO or area EIC codes, it shall respect the requirements that have been set forth for Local Issuing Offices. Local Issuing Offices The Local Issuing Offices are authorised by ETSO to supply EIC codes to any recognised energy organisation providing that they respect the minimum requirements set forth in this document. A Local Issuing Office is responsible for the allocation and maintenance of the codes it issues and it shall maintain a list of all issued codes and standard data about the market participant identified by the code in its local database. It must ensure that: 1. The allocated codes are stable over time. This implies that the significance of a code should always remain constant, For organisations: A code shall be allocated to identify an organisation or a specific part of an organisation. Only one code may be assigned to an organisational function or entity. A code defines explicitly the organisational function or entity. The functional entity or or- Version: 2 Release: 1 10 November 2002 Page : 9/24

10 ganisation should be reflected in the text describing the company and it may be indicated in the name. Consequently, if the organisational function or entity merely changes its name, its code will not be modified. All allocated codes must respect the rules for establishing EIC codes as described in this document. 2. The following minimum services are provided: The verification in the central database under responsibility of the Central Issuing Office that a code has not already been allocated for the party in question. Only one EIC code may be allocated to an organisational function or entity. If a code has already been allocated, the requestor of the code shall be informed of the code in question. The supply, to a request from an energy partner, of all the standard details concerning a party The supply to the central database under responsibility of the Central Issuing Office of all allocated codes and the standard information. This information shall be sent to the Central Issuing Office by the local Issuing Office using either the standard XML mechanism or the web based forms on the ETSO EDI. The XML Message structure, is defined in Annex 4. The uploaded information will be integrated into the central database by the next working day after reception. The management of the code lists (inquiry about a code, suspension of a code and modification of company information concerning a code). The ETSO Organization, or the Central Issuing Office on his behalf, will publish and maintain in its website database the information as received from the Local Issuing Offices. It is the responsibility of each Issuing Office to ensure the correctness of the information supplied. To qualify as a Local Issuing Office the applicant must issue an application to the ETSO Secretary General describing: Name and address of the legal body Documentation of EIC being required either according to the national legislation or market rules or by a majority of the market participants The ETSO Secretary General will supply the successful applicant by post with a certificate acknowledging his Local Issuing Office status. An example of the issuing office application form can be found in section 6. However, an electronic copy may be obtained on the ETSO Internet web-site Version: 2 Release: 1 10 November 2002 Page : 10/24

11 A XML message containing the same information might also be sent to the Central Issuing Office These messages will be validated though appropriated DTD. (See, Annex 3: XML message structure for Issuing Office application). 3.6 Services All authorised issuing offices will have to provide the services approved by ETSO (refer to chapter 2). For the initial implementation a web page shall be developed to provide the necessary services including the download of the list of EIC assigned codes in compliance with the ETSO XML schema. At a later stage more advanced data interchange can be introduced to automate the transmission of general information and of communications parameters to the participating parties. The services must also include information about the unique EAN code for the parties that are active in TSO areas using the EAN coding scheme. Each Local Issuing Office might also require that their participants send a copy of their application request in an XML format validated through the appropriate DTD. Each Local Issuing Office shall send to the Central Issuing Office containing the standard participant information and allocated EIC codes. This information shall be sent to the Central Issuing Office by the local Issuing Office using either the standard XML message or the web based form on the ETSO EDI web page. These messages will be validated through the appropriate DTD. (DTDs are defined in Annex 4: XML message structure for EIC Code allocation) 3.7 Maintenance and organisation Any coding scheme needs a body to maintain it to ensure that it satisfies market requirements. For the moment ETSO Task Force 14 will maintain the code s structural definition as long as the group remains in existence. ETSO will provide a central database containing all the approved EIC codes provided by the issuing offices. All new information provided by the issuing offices will be integrated into the database within the next working day after reception. All issuing offices will be invited to participate in the maintenance process. Any proposed changes to the coding scheme must have the consensus of all participating bodies. When Task Force 14 terminates a common neutral body will be set up to continue this maintenance. 3.8 Costs Task Force 14 is prepared to draft the contractual framework for the new ETSO Identification Coding scheme in co-operation with the General Secretary of ETSO. The General Secretary s responsibility will be to maintain a registry of the authorised issuing offices that have signed the standard contract with ETSO. Version: 2 Release: 1 10 November 2002 Page : 11/24

12 The ETSO Task force 14 (office number 10) will issue the needed common codes at no cost. Local issuing offices may install a cost based fee depending on their market requirements. This fee shall not exceed the EAN fee for similar codes. Version: 2 Release: 1 10 November 2002 Page : 12/24

13 4. ETSO Steering Committee position The ETSO Steering committee recommends the use of EIC and EAN schemes and published the following recommendation in this respect on the 24 th of May 2002: "To facilitate electronic data interchange in the open Internal Electricity Market the ETSO Steering Committee recommends the use of the EAN identification code or the ETSO Identification Code EIC for parties and balance areas in countries which need a new coding scheme. The EIC is specified by Task Force 14 "Electronic Data Interchange between Market Participants". Task force 14 together with the ETSO Secretary General will assist countries in the contractual implementation of registration offices for the EIC. ETSO strongly recommends that any issuing fee is based only on the actual costs. Task Force 14 will provide the initial registration agency codes for all current ETSO members and will provide the EIC codes for balance areas and a list of all permitted coding schemes to be used within the ETSO Scheduling System (ESS). As long as Task Force 14 is active they will maintain the definition of the EIC. After that ETSO will ensure that a common neutral body is set up to maintain the code structure according to user needs. The actual coding scheme used for data interchange between TSOs will have to be agreed on a bilateral basis." Within the national context it is suggested that an existing identification scheme as well as the new coding scheme (EIC or EAN) may be used during a transition period. It is recommended that this transition period be as short as is reasonably possible in order to avoid the extended use of multiple identification schemes. It should be noted that the ETSO Scheduling System - ESS, which is also developed by Task Force 14, will be able to cater for multiple coding schemes, i.e. the EIC, the EAN or national schemes. All TSO IT systems should be able to cater for these different coding schemes. Version: 2 Release: 1 10 November 2002 Page : 13/24

14 PAGE INTENTIONALY LEFT BLANK Version: 2 Release: 1 10 November 2002 Page : 14/24

15 Annex 1: The ETSO Check Character algorithm Introduction This document outlines the algorithm for verifying the accuracy and validity of the ETSO identification code. The ETSO identification code is encoded with a "Check Character". A check character is a character added to the end of the code that validates the authenticity of the code. A simple algorithm is applied to the other digits or letters of the code which yields the check character. By running the algorithm, and comparing the check character you obtain with the check character encoded in the ETSO identification code, it is possible to verify that the complete identification code has been correctly read and that they make a valid combination. Possible uses for this information: When a user has keyed in an identification code (or scanned it) and you want to validate it before sending it out in a schedule, for example. When issuing codes. The ETSO Identification code The ETSO identification code will be based on fixed length alphanumeric codes. The codes will contain information about the issuing office as well as information of what kind of object is identified. Parties and areas will be identified with a 16 character alphanumeric code. The last character of the coding scheme represents the check character that is calculated from the other characters using the ETSO algorithm. An example of a party code is 11XRWENET and an area is 11Y The last character of each of these codes (2, and 3) represents the check characters of the numbers in question. Calculation of the check character, General algorithm for all codes Step 1: The first 15 characters of the code are individualised as follows 1 1 X R W E N E T Version: 2 Release: 1 10 November 2002 Page : 15/24

16 Step 2: Where alphabetic characters are present, they are replaced by a numeric value as extracted from the following table: CODE VALUE CODE A B C D E F G H I J K L M N O P Q R VALUE CODE S T U V W X Y Z - VALUE as follows : Step 3: Then, the positions are again weighted, beginning with the greatest value to the left and ending with a one at the far right Step 4: Each digit is multiplied by its position weight Step 5: The products are then summed to give a total value: 2107 Version: 2 Release: 1 10 November 2002 Page : 16/24

17 Step 6: Apply a modulo 37 (which corresponds to the total number of characters available) to the value 2107 with the formula (36 MOD((2107-1),37)) The result is 2 that, since it is inferior to 10, the check character for the code is the same. Had it been superior to 9 it would have to be converted to a letter using the same mechanism as in Step 2.Thus the code is: 11XRWENET It is recommended that if the check character generated is the - character (result of the calculation equal to 36), one of the characters in the proposed code is changed in order to obtain a result which does not give a value of 36. Strengths Like any consecutive weighting system, this scheme detects 100% of all single digit errors and all transposition errors. Thus the system would detect that the code 10Z Q was incorrect. The proposed algorithm is very beneficial insofar as it enables the use of the alphabet that significantly expands the potential limit of numbers available for use. Version: 2 Release: 1 10 November 2002 Page : 17/24

18 PAGE INTENTIONALY LEFT BLANK Version: 2 Release: 1 10 November 2002 Page : 18/24

19 Annex 2: Metering point coding scheme example Task force 14 has concluded that there is not at present an interest in the ETSO countries for a common coding scheme for metering points. If the situation changes an EIC for metering points can be made. It could like the others be a 16 character code. Each grid or metering point administrator would then obtain a series of codes from the national issuing office to be used for identification: 2-character number for a national issuing office assigned by ETSO the letter "Z" to identify the fact that this is a metering point code 12 digits or uppercase characters allocated by the issuing office in compliance with general and local rules. For example the code could be split into a part for the distribution operator the rest identifying the metering point. 1 character check character Example: 20Z E (national metering point code) Version: 2 Release: 1 10 November 2002 Page : 19/24

20 PAGE INTENTIONALY LEFT BLANK Version: 2 Release: 1 10 November 2002 Page : 20/24

21 Annex 3: XML message structure for issuing office applications This message structure may be used by a company requesting issuing agency status. The structure reflects the issuing agency application request, with the exception of the update indication. The AgencyCodeAllocated element shall not be completed. <?xml version="1.0" encoding="utf-8"?> <!--?xml-stylesheet type="text/xsl" href="issuingofficeapplication.xsl"? --> <!--A Common Identification System for the Electricity Industry The ETSO Identification Coding Scheme EIC -- > <!-- ETSO Task Force 14 DTD Version : 2 RELEASE : 1 --> <!ELEMENT IssuingOfficeApplication (UpdateStatus, IssuingOfficeCoordinates, ContactInformation, Company- Identification, CompanyFunction, Requester, RequesterFunction, RequesterDate, Approver, ApproverFunction, ApproverDate, OfficeCodeAllocated?)> <!ATTLIST IssuingOfficeApplication DtdVersion CDATA #REQUIRED DtdRelease CDATA #REQUIRED> <!ELEMENT UpdateStatus EMPTY> <!ATTLIST UpdateStatus v (C U D) #REQUIRED> <!ELEMENT IssuingOfficeCoordinates (OfficeName, DisplayName, AddressLine1, AddressLine2?, AddressLine3?, PostalCode, City, CountryCode)> <!ELEMENT OfficeName EMPTY> <!ATTLIST OfficeName v CDATA #REQUIRED> <!ELEMENT DisplayName EMPTY> <!ATTLIST DisplayName v CDATA #REQUIRED> <!ELEMENT AddressLine1 EMPTY> <!ATTLIST AddressLine1 v CDATA #REQUIRED> <!ELEMENT AddressLine2 EMPTY> <!ATTLIST AddressLine2 v CDATA #REQUIRED> <!ELEMENT AddressLine3 EMPTY> <!ATTLIST AddressLine3 v CDATA #REQUIRED> <!ELEMENT PostalCode EMPTY> <!ATTLIST PostalCode v CDATA #REQUIRED> <!ELEMENT City EMPTY> <!ATTLIST City v CDATA #REQUIRED> <!ELEMENT CountryCode EMPTY> <!ATTLIST CountryCode v CDATA #REQUIRED> <!ELEMENT ContactInformation (ContactPerson, Telephone?, Fax?, )> <!ELEMENT ContactPerson EMPTY> <!ATTLIST ContactPerson v CDATA #REQUIRED> <!ELEMENT Telephone EMPTY> <!ATTLIST Telephone v CDATA #REQUIRED> <!ELEMENT Fax EMPTY> <!ATTLIST Fax v CDATA #REQUIRED> <!ELEMENT EMPTY> <!ATTLIST v CDATA #REQUIRED> Version: 2 Release: 1 10 November 2002 Page : 21/24

22 <!ELEMENT CompanyIdentification (EanCode?, VatCode?)> <!ELEMENT EanCode EMPTY> <!ATTLIST EanCode v CDATA #REQUIRED> <!ELEMENT VatCode EMPTY> <!ATTLIST VatCode v CDATA #REQUIRED> <!ELEMENT CompanyFunction EMPTY> <!ATTLIST CompanyFunction v CDATA #REQUIRED> <!ELEMENT Requester EMPTY> <!ATTLIST Requester v CDATA #REQUIRED> <!ELEMENT RequesterFunction EMPTY> <!ATTLIST RequesterFunction v CDATA #REQUIRED> <!ELEMENT RequesterDate EMPTY> <!ATTLIST RequesterDate v CDATA #REQUIRED> <!ELEMENT Approver EMPTY> <!ATTLIST Approver v CDATA #REQUIRED> <!ELEMENT ApproverFunction EMPTY> <!ATTLIST ApproverFunction v CDATA #REQUIRED> <!ELEMENT ApproverDate EMPTY> <!ATTLIST ApproverDate v CDATA #REQUIRED> <!ELEMENT OfficeCodeAllocated EMPTY> <!ATTLIST OfficeCodeAllocated v CDATA #REQUIRED> Version: 2 Release: 1 10 November 2002 Page : 22/24

23 Annex 4: XML message structure for EIC code allocations. Central site. The structure reflects the code application request, with the exception of the update indication. <?xml version="1.0" encoding="utf-8"?> <!--?xml-stylesheet type="text/xsl" href="eiccodeapplication.xsl"? --> <!-- ETSO Task Force 14 - DTD Version : 0 RELEASE : 1 --> <!ELEMENT EicCodeApplication (UpdateStatus, CompanyCoordinates, ContactInformation, CompanyIdentification, CompanyFunction, RequestDate, EicCodeAllocated?)> <!ATTLIST EicCodeApplication DtdVersion CDATA #REQUIRED DtdRelease CDATA #REQUIRED> <!ELEMENT UpdateStatus EMPTY> <!ATTLIST UpdateStatus v (C U D) #REQUIRED> <!ELEMENT CompanyCoordinates (OfficeName, DisplayName, AddressLine1, AddressLine2?, AddressLine3?, PostalCode, City, CountryCode)> <!ELEMENT OfficeName EMPTY> <!ATTLIST OfficeName v CDATA #REQUIRED> <!ELEMENT DisplayName EMPTY> <!ATTLIST DisplayName v CDATA #REQUIRED> <!ELEMENT AddressLine1 EMPTY> <!ATTLIST AddressLine1 v CDATA #REQUIRED> <!ELEMENT AddressLine2 EMPTY> <!ATTLIST AddressLine2 v CDATA #REQUIRED> <!ELEMENT AddressLine3 EMPTY> <!ATTLIST AddressLine3 v CDATA #REQUIRED> <!ELEMENT PostalCode EMPTY> <!ATTLIST PostalCode v CDATA #REQUIRED> <!ELEMENT City EMPTY> <!ATTLIST City v CDATA #REQUIRED> <!ELEMENT CountryCode EMPTY> <!ATTLIST CountryCode v CDATA #REQUIRED> <!ELEMENT ContactInformation (ContactPerson, Telephone?, Fax?, )> <!ELEMENT ContactPerson EMPTY> <!ATTLIST ContactPerson v CDATA #REQUIRED> <!ELEMENT Telephone EMPTY> <!ATTLIST Telephone v CDATA #REQUIRED> <!ELEMENT Fax EMPTY> <!ATTLIST Fax v CDATA #REQUIRED> <!ELEMENT EMPTY> <!ATTLIST v CDATA #REQUIRED> <!ELEMENT CompanyIdentification (EanCode?, VatCode?)> <!ELEMENT EanCode EMPTY> <!ATTLIST EanCode v CDATA #REQUIRED> Version: 2 Release: 1 10 November 2002 Page : 23/24

24 <!ELEMENT VatCode EMPTY> <!ATTLIST VatCode v CDATA #REQUIRED> <!ELEMENT CompanyFunction EMPTY> <!ATTLIST CompanyFunction v CDATA #REQUIRED> <!ELEMENT RequestDate EMPTY> <!ATTLIST RequestDate v CDATA #REQUIRED> <!ELEMENT EicCodeAllocated (Agency, EicType, EicIdentification, CheckDigit)> <!ELEMENT Office EMPTY> <!ATTLIST Office v CDATA #REQUIRED> <!ELEMENT EicType EMPTY> <!ATTLIST EicType v CDATA #REQUIRED> <!ELEMENT EicIdentification EMPTY> <!ATTLIST EicIdentification v CDATA #REQUIRED> <!ELEMENT CheckCharacter EMPTY> <!ATTLIST CheckCharacter v CDATA #REQUIRED> Version: 2 Release: 1 10 November 2002 Page : 24/24