The Energy Identification Coding Scheme (EIC) Reference Manual
The Energy Identification Coding Scheme (EIC) Reference Manual
2011-01-20
VERSION 4.4
2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43
Table of Contents 1 2 3
3.1 3.2 3.3 3.3.1 3.3.2 3.3.3 3.3.3.1 3.3.3.2 3.3.3.3 3.3.3.4 3.3.3.5 3.3.3.6 3.4 3.5 3.5.1 3.5.2 3.5.2.1 3.5.2.2 3.6
INTRODUCTION ........................................................................................................ 8 GENERAL REQUIREMENTS FOR THE ADMINISTRATION OF EIC ..................................... 9 ENERGY IDENTIFICATION CODING SCHEME - EIC ....................................................... 9
INTRODUCTION ............................................................................................................................... 9 ADMINISTRATIVE ORGANIZATION .................................................................................................... 10 THE ENERGY IDENTIFICATION CODE - EIC ...................................................................................... 11 PERMITTED CHARACTERS .............................................................................................................. 11 OVERALL STRUCTURE ................................................................................................................... 11 OBJECT TYPES ............................................................................................................................. 11 PARTY (EIC OBJECT TYPE X): ........................................................................................................ 11 AREA (EIC OBJECT TYPE Y):.......................................................................................................... 12 MEASUREMENT POINT (EIC OBJECT TYPE Z): .................................................................................. 12 RESOURCE OBJECT (EIC OBJECT TYPE W): .................................................................................... 12 TIE-LINE (EIC OBJECT TYPE T):...................................................................................................... 12 LOCATION (EIC OBJECT TYPE V): ................................................................................................... 12 EIC CODE VALIDATION................................................................................................................... 12 ISSUING OFFICES .......................................................................................................................... 13 CENTRAL ISSUING OFFICE ............................................................................................................. 13 LOCAL ISSUING OFFICES ............................................................................................................... 15 MANAGEMENT OF INTERNATIONAL EIC CODES ................................................................................ 16 MANAGEMENT OF NATIONAL EIC CODES ......................................................................................... 17 LOCAL ISSUING OFFICE CREATION .................................................................................................. 17
4 5
5.1
EIC CREATION, DEACTIVATION OR MODIFICATION WORKFLOW ................................. 18 MAINTENANCE AND ORGANISATION ........................................................................ 20
REGISTRY COSTS ......................................................................................................................... 20
6
6.1 6.2
7 8
8.1 8.2 8.3 8.4 8.5 8.6 8.7 8.8
ANNEX 2: METERING POINT CODING SCHEME EXAMPLE............................................ 24 ANNEX 3: XML DOCUMENT STRUCTURE FOR EIC CODE ALLOCATIONS. .................... 25
XML SCHEMA STRUCTURE ............................................................................................................ 25 ELEMENT DEFINITIONS................................................................................................................... 26 XML SCHEMA .............................................................................................................................. 30 BASIC GROUND RULES................................................................................................................... 32 HOW TO VERIFY AN EIC CODE REQUEST ......................................................................................... 32 CIO OUTPUT TO THE ISSUING OFFICES ........................................................................................... 32 COMPLETING EIC INFORMATION FOR TRANSMISSION TO THE CIO ..................................................... 34 ETSO WEBSITE CONTENT ............................................................................................................. 35
9 10
ANNEX 4: USE OF THE EIC PARENT ........................................................................ 36 ANNEX 5: USE OF THE EIC RESPONSIBLE PARTY .................................................... 37
Page 2 of 38
44 45 46 47 48 49 50 51 52 53
Table of figures
FIGURE 1: THE EIC PROCESS WORKFLOW ......................................................................... 18 FIGURE 2: THE XML SCHEMA MODEL ................................................................................ 25 FIGURE 3: THE ISSUING OFFICE ANALYSIS HTML FORM ....................................................... 33 FIGURE 4: THE ISSUING OFFICE EIC INTERROGATION FORM ................................................ 33 FIGURE 5: THE ISSUING OFFICE EIC DATA CAPTURE FORM.................................................. 34 FIGURE 6:EIC PARENT USE .............................................................................................. 36 FIGURE 7: EIC RESPONSIBLE PARTY USE .......................................................................... 37 FIGURE 8: EIC RESPONSIBLE PARTY FOR LOCATIONS ........................................................ 38
Page 3 of 38
54 55 56 57 58 59 60 61 62 63 64 65 66 67
Copyright notice:
Copyright ENTSO-E. All Rights Reserved. This document and its whole translations 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, except for literal and whole translation into languages other than English and under all circumstances, the copyright notice or references to ENTSO-E may not be removed. This document and the information contained herein is provided on an "as is" basis. ENTSO-E 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.
68 69 70
Maintenance notice:
THIS DOCUMENT IS MAINTAINED BY THE ENTSO-E WG EDI. COMMENTS OR REMARKS ARE TO BE PROVIDED AT [email protected]
Page 4 of 38
71
REVISION HISTORY
Version Release 1 2 0 0
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. Suppress the use of the asterisk in section 3.3 and clarify the use of the hyphen character in Annex 1. Correct page numbering. Add correct XML document structure for the transmission of EIC codes in addition to providing more descriptive information about the information to be supplied to ETSO. Update of the introduction section to bring it into line with the current situation to define the new type code W for units. Specify more responsibilities for the central issuing offices and additional responsibilities for the local issuing offices. Modify the DTD to incorporate the EIC responsible party and to provide explanatory text. Explanation of the use of the EIC parent.
2002-11-10
2003-02-05
2004-09-30 Section 1
Section 3
Annex 4
Annex 5
Page 5 of 38
Version Release
Date
Paragraphs Annex 6
Comments Explanation of the use of the EIC responsible party. General revamping of the document to incorporate the extension of the coding system to the Energy market, to permit the code to be used locally as well as nationally and to detail the use of the balance group object type. Editorial + addition of new type Editorial + clarification Editorial + new type (tie line) Editorial Editorial + clarification Editorial + clarification New (old 3.5.2.1) Clarification Editorial + Clarification New Workflow deleted and integrated into previous chapters Editorial Clarification (old 4.1 deleted) modified schema representation (old 4.2) (old 4.3) added specific Function possibilities New -XML Schema Ensured that the explanation of the Display name always referred to uniqueness by category. Corrected the workflow Definition of authorized Local Issuing Office.
2005-05-11
2008-02-04 1 2 3.3.3 3.4 3.5.1 3.5.2 3.5.2.1 3.5.2.2 3.6 3.7 Old 3.7 3.8 Annex 2 Annex 4.1 4.2 4.3
2008-04-22 General
3.7
2009-06-08 3.5
Page 6 of 38
Version Release 4 4
Date 2010-12-17
Paragraphs
Comments Addition of the EIC Type V, Location. Updated the Reference Manual to reflect the changeover to ENTSOE. Approved 2011-01-20 by ENTSO-E Market Committee the
Page 7 of 38
72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109
1 INTRODUCTION
Electronic Data Interchange in the European Energy Market requires a common identification scheme to be effective. All Market Participants (traders, producers, qualified consumers, etc.) have the possibility to act in different market areas. System Operators have to exchange information amongst themselves concerning the market participants in question as well as with the market participants. In Addition there are many other objects that require identification for information interchange to be successful (tie lines, resource objects, etc.). In order to do this a reliable identification scheme is a necessity. The primary, but not exhaustive, list of objects that need to be identified are: A. Parties: System Operators, traders, producers, consumers, power exchanges, grid operators, suppliers, agents, service providers, etc. B. Areas: Local grids where metering points are situated, market balance areas consisting of a number of local grids, control areas, etc. C. Measurement Points: cross border connections, settlement or accounting points, etc. D. Resource objects: The objects that generate, or consume energy. E. Tie-lines: The physical lines that connect two Market Balance Areas. F. Locations: The physical or logical places where a party or the IT system of a party is or could be located. In 2002, the ETSO Task Force EDI "Electronic Data Interchange" investigated the use of identification schemes in the member countries. The results of this study showed that most countries were using national identification schemes that were unsuitable for use at a European level. The ETSO Task Force EDI (TF EDI) envisaged the possibility of making one of the national identification schemes a European standard. However, the candidate schemes were deemed unsuitable for widespread use as they did not provide the necessary guarantees to be a robust coding scheme. TF EDI also looked into the use of several international identification schemes that could eventually be used for the energy market. The schemes in question, however, contained specific constraints for their use that prevented their adoption at a European level. In conclusion, TF EDI considered that it would be better to establish a new energy identification scheme that combines the optimization of allocation costs and provides all the services that are felt needed for the energy market. TF EDI therefore introduced an identification scheme, which provides an easy migration path for existing national schemes, in a format that makes it suitable for general electronic data interchange. This new Energy Identification Coding scheme - EIC - is described in the rest of this paper. The ETSO Steering Committee approved the Energy Identification Coding scheme on the 14th of May 2002.
Page 8 of 38
110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129
130 131 132 133 134 135 136 137 138 139
Page 9 of 38
140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168
The most important use of EIC is for party coding. With different market rules and practices in the national markets today's use of EIC will vary slightly from country to country. However the objective of EIC is to end up with a harmonized way of identifying parties for data interchange in the Internal Energy Market. This harmonization process is carried out at meetings with all the local issuing offices. The ENTSO-E vision for party identification is that an international party uses the same EIC code in all markets for his wholesale activities. This is especially important for his energy flows between the different national areas, as this will facilitate the validation of these flows between the System Operators. Validation of cross border flows is a prerequisite for keeping the European network stable. For retail market data interchange a more detailed approach will generally be needed and national subsidiaries of the international companies will need to be identified. In this way an international group may end up with many party codes for its activities in different parts of the market.
Page 10 of 38
169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200
One Character identifying the object type that the code represents. 12 digits, uppercase characters or minus signs allocated by the issuing office in compliance with general and local rules to identify the object in question (party, measurement point, area, etc.). 1 check character based on the 15 previous characters used to ensure the validity of the code.
Page 11 of 38
201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232
For international trading groups it is recommended to use a single unique EIC code for identifying the party for cross border flows in all countries. If the legal party in the contract is a local subsidiary this party should be seen as an invoice party with its own EIC code with regard to electronic data interchange.
Page 12 of 38
233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261
For international EIC codes, the Central Issuing Office list to be found on the Central Issuing Office web page;
For local EIC codes, the Local Issuing Office list. These lists can be accessed through the list of the authorized Local Issuing Offices. Any other code, which is not listed within those recognised EIC codes lists, is not an EIC code in the sense of the present document. Such a code is used under the sole responsibility of the organisation that has issued it.
Once an EIC code is published in the Central Issuing Office list there is no additional requirement for confirmation of the validity of the aforesaid EIC code.
Page 13 of 38
262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279
The Central Issuing Office shall provide minimum checks to ensure that codes proposed by the Local Issuing Offices are not in conflict with codes already existing in the code list or that the code format does not infringe the rules for the allocation of codes. Explicitly, the Central Issuing Office shall ensure that:
The EIC code is unique within the central Registry; The display name is unique within the central Registry for each category of code; The display name respects the naming rules and only uses the permitted characters; The last request date is modified with each EIC code evolution; The business function is present; All mandatory fields are present;
EIC parent or EIC Responsible Party codes, if assigned, exist in the central Registry. If one of these codes is made inactive, it shall ensure that all EIC parent or EIC Responsible party codes are replaced accordingly. The central Registry shall contain the list of all internationally recognised EIC codes provided by the Local Issuing Offices. The following basic information will be provided on the ETSO website: EIC name The official name assigned to the EIC code. For a Party code it shall identify the name of the party. For an Area code it shall identify the name of the area, etc. A short name to be used for display on screen and verbal communication. Within each category (Party, area, metering point, etc.) the Display name shall be unique. In case of a subsidiary or a sub-area, the EIC code of the owner. The GS1 code used by the party in markets using GS1 Global Location Number (GLN-13) instead of the EIC. This shall only be provided for EIC party codes. The VAT code of the company. This code shall only be assigned to Party EIC codes. The functional use of the code, e.g. "Balance Responsible Party", "Balance Group", etc.
Display name
VAT code
Function
Page 14 of 38
280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316
For organisations: A code shall be allocated to identify an organisation. A code defines explicitly the organisation in question. The organisation should be reflected in the text describing the company and it may be indicated in the name. Consequently, if the organisation 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. It is the responsibility of each Local Issuing Office to ensure that the codes under its responsibility remain current and respect the rules laid down in this document. This means that errors found by the Central Issuing Office or other Local Issuing Offices must be corrected.
A Local Issuing Office must also ensure to the best of its ability that the parties, to whom it has allocated codes, will inform it of any changes in the registration. Each Local Issuing Office shall take all the measures possible to correct any anomaly reported to it and shall ensure that the anomaly is rectified in the shortest possible delay. The following minimum services must be provided:
A web page shall be developed to provide the necessary services including the download of the list of locally used EIC codes in compliance with the ENTSO-E 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 verification in the central Registry that a code has not already been allocated for the party in question. 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. All Local Issuing Offices shall send any updates of participant information provided by the parties.
Page 15 of 38
317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354
Each Local Issuing Office might also require that their participants send a copy of their application request in an XML format validated through an appropriate XML Schema. The services must also include information about the unique GS1 code for the parties that are active in TSO areas using the GS1-GLN-13 coding scheme. The management of the code lists:
Inquiry about a code, Suspension of a code, Modification of company information concerning a code.
For the creation of an international EIC code, to supply the central Registry with all allocated international EIC codes and the standard information. Each Local Issuing Office shall send all internationally assigned codes to the Central Issuing Office containing the standard information and their 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 supplied with the Central Issuing Office EIC codelist download package. These messages will be validated through the appropriate XML Schema (XML Schemas are defined in Annex 4: XML message structure for EIC Code allocation). The uploaded information will be integrated into the central Registry once a week. Before an international EIC code may be deactivated, the Local Issuing Office in question shall send a deactivation request to the Central Issuing Office. The code in question will be published with the Central Issuing Office download to the Local Issuing Offices for a period of two months prior to its deactivation. If during that time a request is made for it not to be deactivated the code in question will be removed from the deactivation list. The Local Issuing Office in question will be informed of its removal. If, after the two month period no requests have been received the codes will be deactivated by the Central Issuing Office.
Reactivation of an already deactivated EIC code. Where an EIC code identifying an object has been deactivated and a request is made to reactivate it for the same object, the Local Issuing Office may request its reactivation after it has ensured that the code in question is identifying the same object. The request for reactivation is sent to the Central Issuing Office who shall reactivate the code immediately. It is the responsibility of each Issuing Office to ensure the correctness of the information supplied.
Page 16 of 38
355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384
Local Issuing Offices may assign EIC codes to local entities for national purposes that generally do not have an international interest. In this case the EIC code assigned shall not be submitted to the Central Issuing Office for publication in the central Registry. It must be remembered that a party that only participates in the local market may at some later date wish to participate in the international market. All the Local Issuing Office has to do in such a case is to transmit the EIC code information to the Central Issuing Office. Display names in the central Registry are required to be unique by category. This uniqueness check by category also applies to locally assigned codes. In order to ensure that a locally assigned EIC code has a display name that is guaranteed to be unique it shall begin with the two character international country code of the country in question. For example a local EIC code assigned in Switzerland shall have display name such as CH-NAME. When a locally assigned EIC code is given international status, the Local Issuing Office may modify the Display name accordingly but it must ensure that the Display name is unique within the central Registry for the category of the EIC code in question. Deactivation/reactivation of a national EIC code is under the sole responsibility of the Local Issuing Office.
Page 17 of 38
385 386
The EIC workflow process is divided into three distinct phases: The submission by the Market Participant; The validation, and allocation of an EIC code by the Local Issuing Office in its local Registry; In the case of an international EIC code, the verification and integration of the EIC code into the central Registry by the Central Issuing Office.
Page 18 of 38
395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433
1. Submission by the Market Participant. A Market Participant may request an EIC code from a Local Issuing office. It is also possible to request that the information associated with the EIC code be modified or that an EIC code may be deactivated. If the request is not acceptable for any reason (code already exists, incorrect Display name, etc.) the Market Participant is informed by the Local Issuing Office and may, if necessary, make a new request. 2. Validation and allocation by the Local Issuing Office. On reception of a Request for the creation of an EIC code the Local Issuing Office will initially validate the credentials of the requesting Market Participant. If there is any problem the Market Participant will be informed of the problem. In a second phase the Local Issuing Office shall verify in the local and central Registry to ensure that a code doesnt already exist. If a code already exists there are two possibilities: a. The code exists in the local Registry; the Market Participant could be making a request for the code to become an international code. If this is the case then the process continues. However, if this is not the case then the Market Participant is informed of the existing code.
b. The code exists in the central Registry in which case the Market Participant is informed of the codes existence. Where a new code is required, the Local Issuing Office shall assign a Display Name if one has not already been proposed by the Market Participant. The Local Issuing Office then verifies that the Display Name does not already exist either in the local Registry or in the central Registry within the category of the EIC code. In the case where it already exists, the Local Issuing Office either reassigns a new Display Name or requests a new name from the Market Participant. For modification or deactivation requests the Local Issuing Office simply verifies that the Display name is not duplicated. Once these steps are successfully passed the Local Issuing Office informs the Central Issuing Office of the international EIC code requests. 3. Verification and integration by the Central Issuing Office of an international EIC code. On reception of an EIC code request, the Central Issuing Office verifies that all the required information is present and that there are no duplicate EIC codes nor are there duplicate Display Names. In the case of duplicate EIC codes the request is ignored and the Local Issuing Office is informed of the rejection. In the case of duplicate Display Names the request is accepted and the Local Issuing Offices are informed of the duplication. This requires immediate action by the Local Issuing Office. Once the verifications successfully carried out the central Registry is updated accordingly. The CIO also ensures that the Requested Date is superior to the Requested date in the central Registry. If not the date is changed to the current date and the LIO is informed of the change.
Page 19 of 38
434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450
Page 20 of 38
451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476
6.1 INTRODUCTION
This document outlines the algorithm for verifying the accuracy and validity of the Energy Identification Code. The Energy 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 Energy 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.
Step 1:
The first 15 characters of the code are individualised as follows 1 1 X R W E N E T 1 2 3 4 5 -
Page 21 of 38
Step 2:
Where alphabetic characters are present, they are replaced by a numeric value as extracted from the following table: CODE VALUE 0 0 1 1 2 2 3 3 4 4 5 5 6 6 7 7 8 8 9 9
480 CODE VALUE 481 CODE VALUE 482 as follows : 1 1 33 27 32 14 23 14 29 1 2 483 484 485 3 4 5 36 S 28 T U V W X 33 Y Z A B C D E F G H I J K L M N O P Q R
10 11 12 13 14 15 16 17 18
19 20
21 22 23 24 25 26 27
29 30 31 32
34 35 36
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. 1 1 33 27 3 2 1 4 2 3 1 4 2 9 1 2 3 4 5 3 6
486 16 15 14 13 12 11 487 Step 4: 1 1 488 16 15 14 13 12 11 489 Each digit is multiplied by its position weight 16 490 Step 5: 15 462 351 384 154 230 126 232 7 12 15 16 15 72 10 9 8 7 6 5 4 3 2 33 27 32 14 23 14 29 1 2 3 4 5 36 10 9 8 7 6 5 4 3 2
Page 22 of 38
16 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506
15
12
15
16
15
72
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: 11XRWENET12345-2. If the check character generated is the - character (result of the calculation equal to 36), one of the characters in the proposed code shall be 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 10Z317973010277Q 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.
Page 23 of 38
507 508 509 510 511 512 513 514 515 516
Page 24 of 38
520 521
FIGURE 2: THE XML SCHEMA MODEL
Page 25 of 38
522
16 characters fixed This element must have a valid check length character 1 character The following coded values are permitted: C = Creation U = Update (The information about a code is to be modified. In this context the previous XML entry is entirely replaced by the current entry.) D = Make inactive (The information concerning this code is marked inactive. It is not possible to reallocate the same code to another object). R = Reactivate. An already deactivated EIC code is to be reactivated. Two codes exist for the complete file: A = Active, the code is active and valid I = Inactive, the code is inactive and may not be reissued.
Status
EicType
The one character The EIC type may be: type of the EIC Code Y = area identification X = party identification Z = metering point identification W = Resource Object identification T = Tie-line identification V = Location
Page 26 of 38
Size
Comments
A date in the format : The last request date represents the date of yyyy-mm-dd the addition, last modification or deletion to the code. This date shall be modified each time an EIC code is modified or made inactive. Fixed length 13 The GS1 GLN-13 code, if present, must numeric characters consist of 13 numeric characters. The GS1 code shall only be provided for EIC X codes. Variable length 14 The VAT code generally consists of the 2 alpha-numeric character country code followed by a variable characters length code of 12 alpha-numeric characters. All blanks, or presentation separators should be stripped from the code. The VAT code shall only be provided for EIC X codes. 2 characters The central issuing office may only assign this code. The element shall always be blank for Local Issuing Office transmissions.
EanCode
VatCode
OfficeCode
EicParent
16 character fixed This code is a valid EIC code that must exist length in the code list. It represents the root identification of a series of dependant EIC codes. 16 character fixed This code is a valid EIC code that must exist length in the code list. It represents the party that is responsible for a domain (for example, a TSO is responsible for a balance area). This is mandatory for type V Location codes.
EicResponsibleP arty
EicName
70 characters The name of the party, area or metering variable length point. Special language specific characters alpha-numeric should be avoided if standard Latin characters can be used.
Page 27 of 38
Size
Comments
16 character The permitted letters are the uppercase variable length characters A to Z, the minus sign -, the alpha-numeric field plus sign +, the underscore sign _ or the numeric values 0 to 9. Each Display name assigned must be unique within each EIC code category (T W, X, Y and Z, etc.) Each address line is variable length 70 alpha-numeric characters Variable length 10 alpha-numeric characters Variable length 35 alpha-numeric characters 2 uppercase The 2 character code shall respect ISO 3166 alphabetic 2 character code identifications characters Variable length 70 alpha-numeric characters Variable length 35 numeric characters Variable length 35 numeric characters Variable length 70 alpha-numeric characters
PostalCode
City
CountryCode
Telephone
Fax
Page 28 of 38
Size Extract one or several values from the list provided. Each function shall be separated by a comma (,).
Comments
Role name
Balance group Balance responsible party Balance supplier Capacity trader Consumer Consumption responsible party Coordinating Scheduler Grid access provider Grid operator Imbalance settlement responsible Information Provider Interconnection trade responsible Market operator Meter administrator Meter operator Metered data aggregator Metered data collector Metered data responsible Metering point administrator Nomination Validator Party connected to grid Producer Production responsible party Profile maintenance party Resource Provider System operator Trade responsible party Transmission capacity allocator
523
Page 29 of 38
524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592
Page 30 of 38
593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663
<xsd:documentation/> </xsd:annotation> </xsd:element> <xsd:element name="City" type="ecc:TextType" minOccurs="0"> <xsd:annotation> <xsd:documentation/> </xsd:annotation> </xsd:element> <xsd:element name="CountryCode" type="ecc:CodeType" minOccurs="0"> <xsd:annotation> <xsd:documentation/> </xsd:annotation> </xsd:element> </xsd:sequence> </xsd:complexType> <xsd:complexType name="ContactInformation_Type"> <xsd:annotation> <xsd:documentation/> </xsd:annotation> <xsd:sequence> <xsd:element name="ContactPerson" type="ecc:TextType"> <xsd:annotation> <xsd:documentation/> </xsd:annotation> </xsd:element> <xsd:element name="Telephone" type="ecc:TextType" minOccurs="0"> <xsd:annotation> <xsd:documentation/> </xsd:annotation> </xsd:element> <xsd:element name="Fax" type="ecc:TextType" minOccurs="0"> <xsd:annotation> <xsd:documentation/> </xsd:annotation> </xsd:element> <xsd:element name="EMail" type="ecc:TextType"> <xsd:annotation> <xsd:documentation/> </xsd:annotation> </xsd:element> </xsd:sequence> </xsd:complexType> <xsd:complexType name="EicCodeIdentification_Type"> <xsd:annotation> <xsd:documentation/> </xsd:annotation> <xsd:sequence> <xsd:element name="EicCode" type="ecc:IdentificationType"> <xsd:annotation> <xsd:documentation/> </xsd:annotation> </xsd:element> <xsd:element name="Status" type="ecc:EicStatusType"> <xsd:annotation> <xsd:documentation/> </xsd:annotation> </xsd:element> <xsd:element name="EicType" type="ecc:EicType"> <xsd:annotation> <xsd:documentation/> </xsd:annotation> </xsd:element> <xsd:element name="LastRequestDate" type="ecc:MessageDateTimeType"> <xsd:annotation> <xsd:documentation/> </xsd:annotation> </xsd:element> <xsd:element name="EanCode" type="ecc:IdentificationType" minOccurs="0"> <xsd:annotation> <xsd:documentation/> </xsd:annotation>
Page 31 of 38
664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706
</xsd:element> <xsd:element name="VatCode" type="ecc:IdentificationType" minOccurs="0"> <xsd:annotation> <xsd:documentation/> </xsd:annotation> </xsd:element> <xsd:element name="OfficeCode" type="ecc:IdentificationType" minOccurs="0"> <xsd:annotation> <xsd:documentation/> </xsd:annotation> </xsd:element> <xsd:element name="EicParent" type="ecc:IdentificationType" minOccurs="0"> <xsd:annotation> <xsd:documentation/> </xsd:annotation> </xsd:element> <xsd:element name="EicResponsibleParty" type="ecc:IdentificationType" minOccurs="0"> <xsd:annotation> <xsd:documentation/> </xsd:annotation> </xsd:element> </xsd:sequence> </xsd:complexType> </xsd:schema>
Page 32 of 38
eic-approved-codes-xsd.xml the XML file in compliance with the Schema of all approved EIC codes. Issuing-office.html the base starter file that enables the EIC code list tools to be used (See figure 3).
711 712 713 714 715 Figure 3: The Issuing Office Analysis html form eic-approved-code-interrogation.htm an Interrogation tool of the XML file enabling an interrogation by EIC, EAN, VAT, Parent EIC or EIC Responsible Party(see figure 4).
Figure 4: The Issuing Office EIC interrogation form allocate-eic-code.htm a tool to permit the controlled capture of an EIC code. The form enables an XML compliant file to be sent to the CIO. (See figure 5).
Page 33 of 38
720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 Figure 5: The Issuing Office EIC data capture form Each Issuing Office will have a complete copy of the approved EIC codes. This includes all the information relative to the address and contact information. Such detailed information will not be provided on the website. It is up to each Issuing Office to correctly manage this information.
742 743 744 745 746 747 748 749 750 751 752 753 754 755
Page 35 of 38
761 762
FIGURE 6:EIC PARENT USE
Page 36 of 38
In the case of Location (V) codes it is required to enter the identification of the organization that is responsible for the Location in the EIC Responsible Party field. Figure 8 shows an example of its use.
Page 37 of 38
774 775
FIGURE 8: EIC RESPONSIBLE PARTY FOR LOCATIONS
Page 38 of 38