prop · GS0318 · 2004-09-28 00:00:00 — Definitions of identification codes 36.This prescribes the elements of the following identification codes: (a)unit identification code; (b)account identification code; (c)permit identification code; (d)account holder identification code; (e)installation identification code; (f)correlation identification code; (g)transaction identification code; (h)reconciliation identification code; (i)project identification code. The version of the ISO3166 codes shall be set out in the functional and technical specifications for data exchange standards for registry systems under the Kyoto Protocol, elaborated pursuant to Decision 24/CP.8 of the Conference of the Parties to the UNFCCC. Display and reporting of identification codes For the purpose of displaying and reporting the identification codes set out in this , each element of an identification code shall be separated by a dash - and without spaces. Leading zeros in numeric values shall not be displayed. The separating dash - shall not be stored in the elements of the identification code. Table VI1 details the elements of the unit identification code. Each Kyoto unit and allowance shall be assigned a unit identification code. Unit identification codes shall be generated by registries and shall be unique throughout the registries system. A set of units shall be transmitted as a unit block defined by the starting block identifier and the ending block identifier. unit of a unit block shall be identical, except for their unique identifier element. unique identifier element of the units of a unit block shall be consecutive. When necessary to perform a transaction, keep track of, record or otherwise characterise a unit or unit block, registries or transaction logs shall create multiple unit blocks from a single unit block. When transmitting a single unit, the starting block identifier and ending block identifier shall be equal. Multiple unit blocks shall not overlap with respect to their identifier element. Multiple unit blocks in the same message shall appear in the message in ascending order of their starting block identifier. Table VI-1: Unit Identification Code ISO3166 (2 letter code), RMU,CER, = not a Kyoto unit RMU,CER, = CER (not lCER or Blank for Kyoto units RMU, CER, RMU,CER, 999,999,999,999,999 RMU,CER, 999,999,999,999,999 RMU,CER, AAU, CER, assigned by registry for Table VI-2 lists the valid initial unit type and supplementary unit type combinations. An allowance shall have a supplementary unit type regardless of the period for which it was issued and whether it has been converted from an AAU or other Kyoto unit. An AAU or other Kyoto unit that has not been converted into an allowance shall not have a supplementary unit type. On conversion of an AAU into an allowance in accordance with the provisions of this Regulation the supplementary unit type shall be set to 1. On conversion of an allowance into an AAU in accordance with the provisions of this Regulation there shall be no supplementary unit type. Table VI-2: Valid Initial Unit Type Supplementary Unit Type [not applicable] [not applicable] [not applicable] ERU converted from AAU [not applicable] ERU converted from RMU [not applicable] CER (not tCER or lCER) [not applicable] [not applicable] Allowance issued for the 2008-2012 period and subsequent 5-year periods and is converted from an Allowance issued for the 2005-2007 period and not converted from an AAU or other Kyoto unit Table VI3 details the elements of the account identification code. Each account shall be assigned an account identification code. Account identification codes shall be generated by registries and shall be unique throughout the registries system. Account identification codes of accounts that were previously closed shall not be re-used. An operator holding account identification code shall be linked to one installation. An installation shall be linked to one operator holding account identification code. Holding accounts referred to in Article 11(1) and (2) shall not have an applicable commitment period, regardless of the supplementary account type. Table VI-3: Account Identification Code ISO3166 (2 letter code), CDM for the CDM registry, EU for 100 = Party holding account 120 = operator holding account 121 = person holding account The remaining account types are as set out in the functional and technical specifications for data exchange standards for registry systems under the Kyoto Protocol, elaborated pursuant to Decision 24/CP.8 of the Conference of the Parties to the UNFCCC Unique numeric values assigned by a registry from 1 to 0 for holding accounts 0-99 for national retirement and Table VI4 details the elements of the permit identification code. Each permit shall be assigned a permit identification code. Permit identification codes shall be generated by the competent authority and shall be unique throughout the registries system. A permit identification code shall be assigned to one operator. An operator shall be assigned at least one permit identification code. A permit identification code shall be assigned to at least one installation. An installation shall have one permit identification code at any single point in time. Table VI-4: Permit Identification Code ISO3166 (2 letter code), EU for ( [0-9] | [A-Z] |[-]) + Account holder identification code Table VI5 details the elements of the account holder identification code. Each account holder shall be assigned an account holder identification code. Account holder identification codes shall be generated by registries and shall be unique throughout the registries system. Account holder identification codes shall not be re-used for another account holder and shall not change for an account holder throughout their existence. Table VI-5: Account Holder Identification Code ISO3166 2 letter code, EU for ( [0-9] | [A-Z] ) + Table VI6 details the elements of the installation identification code. Each installation shall be assigned an installation identification code. Installation identification codes shall be generated by registries and shall be unique throughout the registries system. The installation identifier shall be an integer assigned as an increasing monotone sequence, starting from 1. Installation identifiers shall not contain gaps. Therefore when generating installation identifier n, a registry shall have generated every identifier in the range 1 to n-1. An installation identification code shall not be re- used for another installation and shall not change for an installation throughout its existence. An installation identification code shall be assigned to one installation. An installation shall be assigned one installation identification code. Table VI6: Installation Identification Code ISO3166 (2 letter code), EU for Unique numeric values assigned by a registry from 1 to Table VI-7 details the correlation identification codes. Each process under be assigned a correlation identification code. Correlation identification codes shall be generated by registries and shall be unique throughout the registries system. Correlation identification codes shall not be re-used. The re-submission of a process concerning an account or verified emissions that was previously terminated or cancelled shall be assigned a new, unique correlation identification code. Table VI7: Correlation Identification Code ISO3166 (2 letter code), EU for Unique numeric values assigned by a registry from 1 to Each process under be assigned a transaction identification code. Transaction identification codes shall be generated by registries and shall be unique throughout the registries system. Transaction identification codes shall not be re-used. The re- submission of a process concerning a transaction that was previously terminated or cancelled shall be assigned a new, unique transaction identification code. The elements of the transaction identification codes are set out in the functional and technical specifications for data exchange standards for registry systems under the Kyoto Protocol, elaborated pursuant to Decision 24/CP.8 of the Conference of the Parties to the UNFCCC. Each process under be assigned a reconciliation identification code. Prior to the communication link between the Community independent transaction log and UNFCCC independent transaction log being established, the Community independent transaction log shall generate the reconciliation identification code when requesting reconciliation information from registries for a specified time and date. Thereafter, registries shall receive the reconciliation identification code from the UNFCCC independent transaction log. The reconciliation identification code shall be unique throughout the registries system, and all messages exchanged through all stages of a reconciliation process for a specified time and date shall use the same reconciliation identification code. The elements of the reconciliation identification codes are set out in the functional and technical specifications for data exchange standards for registry systems under the Kyoto Protocol, elaborated pursuant to Decision 24/CP.8 of the Conference of the Parties to the UNFCCC. Each project shall be assigned a project identification code. Project identification codes shall be generated by the executive board of the CDM for CERs and by the relevant body of the Party or the Article 6 supervisory committee in accordance with Decision 16/CP.7 of the Conference of the Parties to the UNFCCC for ERUs and shall be unique throughout the registries system. The elements of the project identification codes are set out in the functional and technical specifications for data exchange standards for registry systems under the Kyoto Protocol, elaborated pursuant to Decision 24/CP.8 of the Conference of the Parties to the UNFCCC. List of input codes 37.This defines the codes for all elements and code support tables. The version of the ISO3166 codes shall be as set out in the functional and technical specifications for data exchange standards for registry systems under the Kyoto Protocol, elaborated pursuant to Decision 24/CP.8 of the Conference of the Parties to the UNFCCC. Field Name: Activity Type Field Description: Numeric code indicating the activity type of an installation Combustion installations with a rated thermal input exceeding 20 MW Metal ore (including sulphide ore) roasting or sintering installations Installations for the production of pig iron or steel (primary or secondary fusion) Installations for the production of cement clinker in kilns or lime in kilns or in other furnaces Installations for the manufacture of glass including glass fibre Installations for the manufacture of ceramic products by firing, in particular roofing tiles, bricks, refractory bricks, tiles, stoneware or porcelain Industrial plants for the production of (a) pulp from or other fibrous materials (b) paper and board Other activity opted-in pursuant to Article 24 of Directive 2003/87/EC Field Name: Relationship Type Field Description: Numeric code indicating the type of relationship between an account and a person or operator Primary authorised representative of the account holder Secondary authorised representative of the account holder Additional authorised representative of the account holder Authorised representative of the verifier Contact for the installation Field Name: Supplementary Transaction Type Field Description: Numeric code indicating the supplementary type of a transaction Issue of AAUs and RMUs Conversion of AAUs and RMUs to ERUs External transfer (2008-2012 onwards) Cancellation (2008-2012 onwards) Retirement (2008-2012 onwards) Cancellation and replacement of tCERs and lCERs Carry-over of Kyoto units and allowances issued for the 2008-2012 period and subsequent five-year periods Change of expiry date of tCERs and l CERs Allowance issue (2005-2007) Allowance issue (2008-2012 onwards) External transfer (2005-2007) Allowance cancellation (2005-2007) Retirement (2005-2007) Field Name: Supplementary Unit Type Field Description: Numeric code indicating the supplementary type of a unit No supplementary unit type Allowance issued for the 2008-2012 period and subsequent 5-year periods and is converted from an AAU Allowance issued for the 2005-2007 period and not converted from an AAU or other Kyoto unit Field Name: Action Code Field Description: Numeric code indicating the action in the UpdateAccount process Add people to the account or installation The UNFCCC codes are set out in the functional and technical specifications for data exchange standards for registry systems under the Kyoto Protocol, elaborated pursuant to Decision 24/CP.8 of the Conference of the Parties to the UNFCCC. Processes concerning accounts and verified emissions with response codes Requirements for each process 38.The following message sequence for processes concerning an account or verified emissions shall apply: (a)the authorised representative of an account shall submit a request to the registry administrator of that registry; (b)the registry administrator shall assign a unique correlation identification code comprising the elements set out in to the request; (c)prior to the communication link between the Community independent transaction log and the UNFCCC independent transaction log being established, the registry administrator shall call the appropriate operation on the Community independent transaction log account management Web service, thereafter, the registry administrator shall call the appropriate operation on the UNFCCC independent transaction log account management Web service; (d)the Community independent transaction log shall validate the request by calling the appropriate validation function within the Community independent transaction log; (e)if the request is successfully validated and thereby accepted, the Community independent transaction log shall amend the information it holds in accordance with that request; (f)the Community independent transaction log shall call the receiveAccountOperationOutcome operation on the account management Web service of the registry which sent the request, notifying the registry as to whether the request was successfully validated and thereby accepted, or whether the request was found to contain a discrepancy and was thereby rejected; (g)if the request was successfully validated and thereby accepted, the registry administrator which sent the request shall amend the information held in the registry in accordance with that validated request, otherwise, if the request was found to contain a discrepancy and was thereby rejected, the registry administrator which sent the request shall not amend the information held in the registry in accordance with that validated request. Table VIII-1: Message Sequence Diagram for Processes concerning an Account or Verified Emissions account operation() Validate account management operation AccntMgmtWS.account operation() {60 sec} «XML Message returns» {24 hrs} {60 sec} «XML Message returns» An account operation is final is final when a registry, upon receipt of the receiveAccountManagementOperationOutcome containing an "Accepted" status, has updated its records AccountManagement.validate account operation() AccountManagement.account operation() Prior to the communication link between the Community independent transaction log and the UNFCCC independent transaction log being established, a registry administrator sending a request should receive an acknowledgement of receipt from the Community independent transaction log within 60 seconds. Thereafter, a registry administrator sending a request should receive an acknowledgement of receipt from the UNFCCC independent transaction log within 60 seconds. A registry administrator sending a request should receive a notification of validation from the Community independent transaction log within 24 hours. The status of the process during the message sequence shall be as follows: Table VIII-2: Status Diagram for Processes concerning an Account or Verified Emissions [Registry validates the account management operation Registry calls the appropriate account management operation of the CITL] [CITL calls receiveAccountOperationOutcome [CITL calls receiveAccountOperationOutcome on registry with status "rejected"] on registry with status "accepted"] [Registry finalises the account management operation] [Registry didn't receive an outcome notification within 24 hrs] The components and functions which are utilised during the message sequence are shown in table VIII-3 to VIII-18. Functions which are public shall be implemented as specified. Functions which are private are for informational purposes only. The inputs of all functions have been structured to match the format and informational requirements described using web service definitions language, set out in the functional and technical specifications for data exchange standards for registry systems under the Kyoto Protocol, elaborated pursuant to Decision 24/CP.8 of the Conference of the Parties to the UNFCCC. An asterisk (*) has been used to denote the fact that an element can appear multiple times as an input. Table VIII-3: Components and Functions for Processes concerning an Account or Verified Emissions The purpose of this component is to handle web service requests for the management of accounts and verified emissions. Handles the account creation requests Handles the account update requests Handles account closure requests Handles verified emissions of an installation Receives an account operation (creation, update, ) outcome (accepted or rejected) Community independent transaction log (for all functions) and registry (for the ReceiveAccountOperationOutcome function only) Table VIII-5: MgmtOfAccountWS.CreateAccount() function This function receives an account creation request. The Community independent transaction log authenticates the initiating registry by calling the AuthenticateMessage() function and checks the version of the initiating registry by calling CheckVersion() function. If authentication and version checks pass, a 1 result identifier is returned without any response codes, the contents of the request are written to a file by calling the WriteToFile() function and the request is put in a queue. If authentication and version checks fail, a 0 result identifier is returned together with a single response code indicating the error cause. If the person is not a natural person its name must be put in the LastName parameter. The PersonIdentifier means the account holder identification code comprising the elements set out in . The IdentifierInRegistry means the alphanumeric identifier for the account as specified by the account holder pursuant to Annexes III and IV. Account (*) ContactPeople (see People) People (*) Not applicable (called as a web service). Table VIII-6: MgmtOfAccountWS.UpdateAccount() function This function receives an account update request. The Community independent transaction log authenticates the initiating registry by calling the AuthenticateMessage() function and checks the version of the initiating registry by calling CheckVersion() function. If authentication and version checks pass, a 1 result identifier is returned without any response codes, the contents of the request are written to a file by calling the WriteToFile() function and the request is put in a queue. If authentication and version checks fail, a 0 result identifier is returned together with a single response code indicating the error cause. If the person is not a natural person its name must be put in the LastName parameter. The PersonIdentifier means the account holder identification code comprising the elements set out in . The IdentifierInRegistry means the alphanumeric identifier for the account as specified by the account holder pursuant to Annexes III and IV. Account (*) ContactPeople (see People) People (*) Not applicable (called as a web service). Table VIII-7: MgmtOfAccountWS.CloseAccount() function This function receives an account closure request. The Community independent transaction log authenticates the initiating registry by calling the AuthenticateMessage() function and checks the version of the initiating registry by calling CheckVersion() function. If authentication and version checks pass, a 1 result identifier is returned without any response codes, the contents of the request are written to a file by calling the WriteToFile() function and the request is put in a queue. If authentication and version checks fail, a 0 result identifier is returned together with a single response code indicating the error cause. Account (*) Not applicable (called as a web service). Table VIII-8: MgmtOfAccountWS.UpdateVerifiedEmissions() function This function receives a verified emissions update request. The Community independent transaction log authenticates the initiating registry by calling the AuthenticateMessage() function and checks the version of the initiating registry by calling CheckVersion() function. If authentication and version checks pass, a 1 result identifier is returned without any response codes, the contents of the request are written to a file by calling the WriteToFile() function and the request is put in a queue. If authentication and version checks fail, a 0 result identifier is returned together with a single response code indicating the error cause. VerifiedEmissions (*) Installations (*) Not applicable (called as a web service). Table VIII-9: MgmtOfAccountWS.ReceiveAccountOperationOutcome() This function receives an account management operation outcome. The initiating registry authenticates the UNFCCC independent transaction log (or Community independent transaction log prior to the link between the Community independent transaction log and UNFCCC independent transaction log being established) by calling the AuthenticateMessage() function and checks the version of the transaction log by calling CheckVersion() function. If authentication and version checks pass, a 1 result identifier is returned without any response codes, the contents of the request are written to a file by calling the WriteToFile() function and the request is put in a queue. If authentication and version checks fail, a 0 result identifier is returned together with a single response code indicating the error cause. The response code list is populated with couples (account/installation-response codes) if the outcome is 0. Not applicable (called as a web service). The purpose of this component is to provide the validating and update functions for the management of accounts and verified emissions. Validates an account creation Validates an account update Validates an account closure Validates a verified emissions update. Updates verified emissions for installations Transaction log (all functions), registry (for information only) Table VIII-11: ManagementOfAccount.ValidateAccountCreation() function This function validates an account creation request. If a validation test fails, the account identifier and response code are added to the response list. Account (*) ContactPeople (see People) People (*) Range 7101 to 7110; range 7122 to 7160. Table VIII-12: ManagementOfAccount.CreateAccount() function This function creates accounts. For each account: Create the account and its details Create all people and their details linked to the account if they did not already exist Update all information linked to people that already existed and that are linked to the account Create the installation and installation details if an installation is linked to the account Create all people linked to the installation (currently the contact) if they didnt already exist Update all information linked to people that already existed and that are linked to the installation Account (*) ContactPeople (see People) People (*) Not applicable (called as a webservice).