Registry Functional Specification Version 11.6D

Transcription

1 Registry Functional Specification Version 11.6D

2 Contents Revision History Introduction Background This document Version 9 Part 10 Review enhancement to include additional metering information Transition Plan Concepts Terminology Code Rules references Attributes of an ICP Types of ICP Events Event types Event type responsibilities Event processing Acknowledgements Notifications to responsible participants...34 Filtering-up of historical changes...35 Notification parameters Switching protocol...37 Switching parameters...43 Switching file naming standard ICP status lifecycle...44 ICP lifecycle...44 Standard ICP business rules...44 Standard ICP Status transitions...46 Distributor-only ICP business rules...48 Distributor-only ICP Status transitions

3 4.13 Participants and Registry roles...49 Distributors...49 TradersRetailers...50 Meter equipment providers...51 Electricity Authority...52 Reconciliation manager...52 Clearing manager and system operator...53 Approved Test House...53 Other approved parties...53 Registry operator User interfaces...54 Online interface...54 Batch interface...54 File naming convention...54 Batch file headers...54 Batch selection criteria...55 Back-office systems...55 Errors Security Process maps...57 Process map ICP event Distributor and Trader Retailer maintenance...57 Process map switching...58 Process map reporting, parameters, notifications and queries...59 Process map maintaining static data and access security Sub-processes ICP event maintenance Distributor...61 DC-010 Create an ICP...61 DC-020 Make a new ICP ready...65 DC-030 Make a new ICP Distributor...67 DM-010 Change initial ICP creation date...69 DM-020 Add additional Distributor information...71 DM-030 Correct Distributor information...75 DM-040 Reverse Distributor information ICP event maintenance Trader Retailer initial assignment...79 RA-010 Make initial Trader retailer assignment ICP event maintenance MEP maintains MEP asset information..82 MM-010 Add new MEP asset information...82 MM-020 Correct MEP asset information...88 MM-030 Reverse MEP asset information ICP event maintenance TraderRetailer maintenance...92 RM-010 Reverse initial assignment...92 RM-020 Add new TraderRetailer information...93 RM-030 Correct TraderRetailer information...96 RM-040 Reverse TraderRetailer information Switching

4 RS-010 Make switch request (NT) RS-020 Acknowledge switch request (AN) RS-030 Complete non-half-hour switch (TN) RS-040 Complete half-hour switch (TT) RW-010 Make withdrawal request (NW) RW-020 Acknowledges withdrawal request (AW) RC-010 Request switch read change (NC) RC-020 Acknowledge switch read change (AC) DS-010 Switch ICPs between Distributors EP-010 Acknowledge MEP switch nomination (EP) Reporting PR-010 Produce ICP list (on demand) PR-020 Produce monthly TraderRetailer ICP lists PR-030 Produce ICP event detail report PR-040 Produce TraderRetailer switch compliance reports PR-050 Produce ICP days report PR-060 Produce audit log PR-070 Produce monthly statistics PR-080 Produce monthly HHR ICP list PR-090 Produce active NSPs report PR-100 Produce loss factors report PR-110 Produce maintenance compliance report PR-120 Produce NSP mapping table report PR-130 Produce monthly activity and status summary report PR-140 Produce monthly switch completion report PR-150 Produce MEP asset list User parameters MP-010 Set switching message receipt times parameters MP-020 Set notify parameters Notifications NP-010 Acknowledge event change NP-020 Send TraderRetailer switch messages NP-030 Notify of event change NP-040 Re-send switching messages NP-050 Re-send notifications NP-060 Alert Certification Expiring Online queries QU-010 Search for address to find ICP QU-020 View ICP information QU-030 View static table information Maintaining static data SD-010 Maintain NSP data SD-020 Maintain static data SD-030 Maintain loss factor codes SD-040 Maintain price category codes SD-050 Maintain Meter Price Category Codes Security SU-010 Supervisor adds new user SU-020 Disables user SU-030 Supervisor resets user password SU-040 Assign agent

5 PW-010 Change user password Appendix 1 Password standards

6 Revision History Version Release Date 1.0 September 2006 Description Final Version released 2.0 May 2007 The following changes have been made as a result of vendor and participant queries: Section 3 Paragraph 3 removed as it relates to the tender. Section 4.4 Global Global Global Section 4.14 Global Section 4.11 Switching Protocol Section 4, RA-010, RM- 020, RS-040, PR-010, PR- 030, NP-030 RM-020, RS- 040 RS-030 and RC-010 RC-010 and RC-020 RC-010 Replaced attribute name "unmetered load quantity" with "Daily Unmetered kwh". Global change made to format of Price Category to Char 50 which will allow for the input of multiple codes (each a maximum 5 characters in length) separated by a space. Corrected where necessary that all Physical Address Property Name fields have a format of Char 75 in all instances. Corrected where necessary that all User Reference fields have a format of Char 32. Paragraph added about error processing. Global changes made to any remaining references to 'RC' transaction to 'NC' transaction. 3 rd paragraph. Distributors and meter owners to also receive NC transactions. New attribute "Advanced Metering Infrastructure" added to Metering Event with valid options Y/N. Default is N. The Mandatory/optional attributes have been reviewed and updated. Length of Meter identifier is to be further increased to Char 15. Under Data inputs, the description against 'Number of Registers' now states "This is a count of the number of non half hour meter registers only. A register for this file is defined as one that returns cumulative non half hour meter readings used by participants in the preparation of submission files." In the Description section "the most recently completed switch for an ICP" has been replaced with "any completed switch that has not been, or is not in the process of being withdraw". In the Business requirements section point 2: "must always relate to the most recently completed switch" has been replaced with "must only be applied to any completed switch that has not been, or is not in the process of being withdrawn". Also two additional Business requirement have

7 Version Release Date 3.0 August 2007 RC-020 RS-020, SD- 020 RS-040 PR-010, PR- 030 and PR- 110 Description been added: "A subsequent NC relating to a particular switch cannot be sent if there is an existing NC awaiting an associated AC for this switch." and "Only the 'new trader retailer' of the switch in question can input an NC request." An additional mandatory attribute "Actual Transfer Date" has been added to the Data Inputs section. Additional Response Code added AD advanced metering. Under Data inputs, the description against Meter Register Count now states "This is the number of half hour meters that are used in the settlement process". Also, further details added for clarification. Physical Address Region field added prior to Physical Address Street. In PR-030 region also added to the NT transaction. PR-010 Physical address unit format changed to Char 20. Also, the format of Status Reason corrected to Numeric 2. PR-010, PR- 070 PR-010 and PR-030 PR-030 PR-120 NP-050 SU-020 PR-110 PR-130 Global RS-030 and RC-010 Selection Criteria added 'Distributor' as a valid option for the Status attribute. Added to the Business requirements section, "Selection criteria and ICP lists can be submitted online or via file". The Audit Number attribute format corrected to Char 15. Network Connection Status attribute included in the attribute list under Business requirements section. Status Flag in the Data outputs section renamed Network Connection Status. 'Connection type' renamed "Network Type". Meter Owners included as valid participants that can request the re-sending of notifications. Business Requirement 3 added. Once a logon has expired users are allowed 2 grace logon attempts. Data outputs of NSP Mapping attributes updated. New Report - Monthly Activity and Status Summary added. Rename "GIP/GXP" or "GXP/GIP" to "POC" (for point of connection). To more accurately reflect the rule definition. a) Extra clarification for the Meter multiplier field: Addition of the following sentence under the description column against the Meter multiplier "If the metering event Meter Multiplier Flag is

8 Version Release Date August 2007 RC-010 Description 'Y' then at least one of the Meter multipliers for this premise must have a value other then unity i.e. not 1." b) Correction against Number of registers : Reinstatement of the first paragraph in the description column previously crossed out i.e. " Number of registers " etc. Correction. In the Description section, the last sentence should have been crossed out to match with the previous correction made to Business Requirement point 2. PR-010 Addition to Business Requirement point 5. Add final sentence "Ownership restrictions also do not apply to Distributor only ICPs. All participants should be able to extract information for Distributor only ICPs when selection criteria of Status includes 'Distributor' and/or the selection criteria of Reconciliation Type includes 'LE' or 'SI'." PR-100, SD- 030, SD-040 SD-010 SU-020 SD-030 Corrections PR-010 Global change to balancing area field format PR-050, PR- 080, PR-100, SD-040 SD-030, PR- 100 Additional field added to the report layout - Date and time of last change. Correction. To match with the changes made to PR-120 with respect to the renaming of 'connection type' to 'network type' and the insertion of the 'network connection status'. Change number of grace logons from two to three which is what is currently implemented. Additional sentence in description section: 'Distributors' include grid owners, local network owners, embedded network owners and gridconnected generators. DM-020. Distributors can only input decommissioned Status events. PR-010. All participants to be able to extract SI Distributor ICPs (not SB). PR-040. Withdrawal cycle resolution. "an AW acceptance must be delivered within 23 business days of the initial NW." not the NT. Addition of Installation Type as a selection parameter - required by the reconciliation manager for verification purposes. Inclusion of reconciliation manager as being able to request this report. Reconciliation manager to have same ability as the Commission to view all participants' information particularly Distributor only ICPs. (Work request being raised. A future enhancement only) Change from char 8 to char 12. Required by the reconciliation manager for the transition period when each NSP will be its own balancing area. The balancing area code will consist of the POC, Network Owner and Network Type codes concatenated together. Provide ability to request the reports on demand via ftp. (Work request being raised. A future enhancement only) Clarification and correction. PR-100 Correction: Deletion of comment against End trading period. SD-030 Clarification. Loss factors must apply to

9 Version Release Date October December February February June 2008 PR-110 RS-030 and RC-010 SD-030 and SD-040 SD-040 and section 4.3 Section 4.13 Section 4.3 Section 4.12 RC-020 Description the whole month but there can be two records applicable to the month for different sets of trading periods i.e. day and night. Included additional file layouts for reconciliation, pricing, status and metering event breaches. Format of Meter Owner field changed from Char 6 to Char 4. The Meter Owner must be validated and therefore can only be char 4. (This has always been the case) Validation suspension. Temporary removal of the restriction that only changes can be made if the Start Date is in the future. For the maintenance of Loss Factors, the restriction removal applies only to any maintenance performed via FTP - online functionality is as originally specified. Pricing Category Code format changed from Char 5 to Char 15 which is the current system length. Correction. List of participant roles, responsibilities and facilities updated to more accurately reflect requirements in process maps. Format of Shared ICP List changed to have a space separator not an ampersand. Makes this consistent with other list fields. Correction. Proposed trader retailer added to list of required attributes for ICP to become Ready. Matches up with requirement detailed in DC-010 and DC-020. Corrected Date format of Actual transfer date to DD/MM/YYYY. PR-090 Added an additional recipient of the report - reconciliation manager (on demand) - to accurately reflect the rules. PR-020 RC-010 SD-020 PR-040 RW-010 RS-030 and RC-010 RW-020 Section 4.3 Clarification. Added sentence "There is no filtering on ICP status however if the ICP has been decommissioned prior to the period covered by the report then it should not be listed." Correction. Business Requirements Point 3 should have been deleted at the same time that point 11 was inserted. Meter Location Code OMSB is too long and has been reduced to OMB. New Register Content Code of EG added. Switch compliance report corrections to comply with rules. Added new breach type - NW breach. Global replacement of 'working day' to 'business day'. Addition of MG as a temporary withdrawal code to the NW codes for the registry moratorium. Change to the validation rule to say "...the total number of registers for an ICP to be greater than or equal to the Meter Register Count of the metering event applicable on the actual transfer date". Clarification of resolution of switch requests. Reconciliation Types clarified

10 Version Release Date July November 2009 Description SD-030 Loss factors changed from 3 decimal places to 4 decimal places PR-080 Added NSP to data outputs SD-020 MP-010 DS-010 PR-140 Register Content Codes updated Meter equipment owners and Distributor added to the participant circulation list. Added DS-010 Distributor Switching section Added PR June 2010 Global Underlines and strikethroughs removed. Appendix 1 and 2 separated out into another document Changes made to the document regarding the Part D enhancement to add MEP asset information to the Registry (see section 3.1 for a summary of the changes) August D 6 September 2011 Global Fifth consultation for proposed Part 10 amendments 1. Jade conversion of the document so that: the data inputs and outputs are the actual file formats. Removes the need for participants to use two documents. This standardisation process includes the capitalisation of attribute names, roles and event names. 2. Main detail of the transition plan has been moved to a separate document. 3. Additional validation added to the Submission Type HHR attribute to check the Installation Certification Status on the MEP Asset event. 4. Additional MEP asset event validation of the Meter Category attribute. Must be 1 or 2 for Metering Types of NHH and PP. 5. Status Reason codes. Change of values related to the inactive status. (See section 4.3). 6. TN. There now is a format change due to the requirements around AMI re-programming. 7. Meter Asset event. There has been a rearrangement of the attributes in the Channel level (level 4) of the Meter Asset Event and an addition of 2 new attribute = Register Start Period and Register End Period. 8. There is a new global switching parameter for traders that indicates whether they require their TN and NC files to contain information for all nonremoved registers or only those required for reconciliation (Settlement Indicator = Y). Updated for fifth consultation

11 Registry functional specification 1 Introduction The Registry is a national database that contains information on every point of connection on the national network from which electricity is supplied. These points of connection are referred to as installation control points (ICPs). Each ICP has a unique identifier. The Registry is the electricity industry s database of record of all ICPs. Through the use of ICPs, the Registry helps manage both the customer switching and reconciliation processes. Part 11 of the Electricity Industry Participation Code (Code) Part E of the Electricity Governance Rules 2003 (Rules) provides for the management of information held by the Registry and outlines the process for switching customers between TradersRetailers. Part 10 describes provisions for accurate recording of meter asset data. 2 Background The first Registry was implemented in April 1999 and was further enhanced in The original requirement for that Registry was to provide a low-cost system to enable end-use customers to switch energy TradersRetailers and was concerned with the recording of basic ownership, status and profile information about an ICP. The enhancement in 2002 expanded the amount of information recorded about an ICP to include an address, metering installation details and Distributor pricing. It also made the Registry the database of record by requiring that the Registry be used as the primary mechanism for processing switches the assignment of an ICP from one TraderRetailer to another. Version 11 of this document contains details of changes required to the Registry as a result of the Part D and Part 10 Review (2009 /2010) concerning the requirement to include additional metering information in the Registry. 3 This document This document describes the business functional requirements of the Registry only for activities of switching ICPs between TradersRetailers. This document should be read in conjunction with the associated Registry Operational Requirements

12 It is important to note that the Registry system currently exists and, whilst considerable effort has been made to restrict the document to business requirements, some existing design concepts have had to be included where they have become fundamental to users' operations. This document does not contain any screen layouts or file interface specifications of the current Registry system; however, their information content and processing details are provided. The following reference documents, that had previously been included as appendices, can be found on the EA website - EA Registry Address Population Guidelines; and - EA Registry checksum algorithm. 3.1 Version 9 Part 10 Review enhancement to include additional metering information Summary of enhancement changes This enhancement adds new MEP asset information to the existing Registry. This document details the additional attributes and the new structures, roles and processes required to implement the new RulesCode whilst endeavouring to minimise the disruption to participant s systems with respect to the processing of both future and historical information. The Part 10 enhancement involves the following changes: 1. Renaming the role of primary meter contact and meter owner to Meter Equipment Provider (MEP) and retailer to Trader. 2. MEPs will have the responsibility of maintaining asset information instead of Traders, as at present. 3. Traders will retain the responsibility for nominating the meter provider (MEP) by inputting the participant identifier for the MEP, and additional processes are provided for the MEP to accept a nomination and to maintain the asset records. 4. A process for switching the MEP responsibility from a losing MEP to a gaining MEP is also included. 5. There will be additional asset information to be maintained in the Registry by MEPs that will include additional attributes relating to installation locations, individual components (meters and control devices) and their channels/registers. A new structure has been designed under the current metering installation event to hold these attributes (see diagram below). This enhanced meter information structure is now termed the MEP Asset event or MEP asset information in this document. Access to this information will be available from search screens and new files. 6. Traders will no longer have the responsibility of maintaining meter information; however, they will retain the responsibility of maintaining all information relating to unmetered load and assigning the Nominated MEP. This information has been split from the MEP asset information and placed under the Trader event

13 7. The reconciliation event has been renamed the Trader event. 8. There will be a distinction made between the physical installation Metering Types and the Submission Metering Types used in the reconciliation process. Under the Trader event there are 2 additional attributes Submission Type HHR and Submission Type NHH to indicate the type of submissions required for the ICP. This will be the information source for the ICP Days, HHR ICP List, ICP Listing and Monthly ICP reports i.e. not from the Metering Types recorded under the MEP Asset event. 9. In the Trader initial assignment process, Traders will not be able to make the status active until the MEP has input some asset information or some information is recorded about any unmetered load. 10. There will be additional Status Reason codes required relating to the inactive status. 11. As a result of recording additional MEP asset information in the Registry, some of the information currently input by Traders in the TN and NC switch transactions will be redundant. In order to provide accurate information via the TN and NC to the new Trader, the system will populate the relevant MEP asset information and ignore any values input by the old Trader. 12. Unmetered load information will be added to the TN and NC switch messages by the system to provide new Traders with more complete information. 13. The TN and NC messages will be able to be input via the browser i.e. online, in addition to the current facility of being input via FTP. Full details, not partial as at present, will also be viewable online but only by the owning participants. 14. There will be additional roles and validation (static data) files: Meter price category will be a new (optional) attribute, recorded in the MEP Asset event that will be validated using reference data maintained by MEPs. Approved Test House will be a new attribute, recorded in the MEP Asset event that will be validated using reference data maintained by the Registry operator. 15. The Trader maintenance FTP file formats will need to change to: remove the meter installation event, and add the new submission types, unmetered load information and Nominated MEP attribute to the Trader event 16. The formats of most of the existing reports will remain unchanged except for the : Event Detail which requires changes to the Trader and the existing metering events as well as TN and NC messages, and the Compliance Report which requires additional MEP asset compliance rules. 17. An additional maintenance facility will be provided for MEPs to manage their asset information

14 18. An additional report, MEP Asset Information, will be made available to all participants to request on demand. 19. An additional report, Certification Alert, will be generated overnight and provided to the owning parties. 20. The format of the overnight current notification file will not change; however, some information that now resides in the MEP Asset event will be missing (null). An additional notification file will be provided that deals solely with the MEP Asset event changes due to its complex structure. 21. The online address search screen will have an additional attribute to search on: Component Identifier. 22. The TT transaction presently allows for the optional input of Trader, Status and Metering Installation events. In order to preserve the format, Meter Installation event information will be ignored and assumed to be null and there will only be 2 events able to be input: Trader (now mandatory) and Status (still optional). 23. The format of the TN and NC messages have been re-arranged and some attributes added, in order to facilitate the requirements relating to AMI re-programming. 24. Traders will be able to indicate, via a new switching parameter, whether they will require information for all registers of a ICP in their TN and NC files or only those required for reconciliation (indicated by the Settlement Indicator against each register in the MEP Asset event). The TN and NC validation has been changed accordingly. 25. The new event structure of an ICP will be as follows:

15 Current ICP Structure (* There are no format changes to events or messages marked with *) ICP Network Event* Distributor Pricing Event* Address Event* Status Event* Reconciliation Event Metering Installation Event Switch Messages -Event Date -Trader -Profiles -User reference -Event Date -Primary metering contact -Highest Meter Cat -Metering Type HHR -Metering Type NHH -Metering Type UNM -Metering Type PP -AMI Type -Daily Unmetered kwh -Unmetered load details trader -Meter Register Count -Meter multiplier Flag -User Reference -NT -AN* -TN*/TT* -NC -AC* -NW* -AW* New ICP Structure ICP Changed Events Network Event* Distributor Pricing Event* Address Event* Status Event* Trader event MEP Asset Metering Installation Event Switch Messages New attributes Data moved from old Metering Installation Event -Event Date -Trader -Profiles -Submission Type HHR -Submission Type NHH -Nominated MEP -UNM flag -Daily Unmetered kwh -Unmetered load details trader -User reference -Event Date -MEP -Highest Meter Cat -Metering Type HHR -Metering Type NHH -Metering Type PP -AMI Type -Meter Register Count -Meter Multiplier Flag -User Reference Installation information -NT -AN* -TN*/TT* -NC -AC* -NW* -AW* -EP Component information Channel information

16 3.2 Transition Plan As with previous Registry enhancements, there will be a transition period between the old and new Code Rules that will progress through the following stages: Stage 1: Preparation and clean-up of production data Stage 2 : User Acceptance Testing Stage 3 : Market Trial Stage 4: Production Migration and MEP Asset population Further details of the transition and migration plan can be found in the document Registry Part 10 Enhancement Transition Plan

17 4 Concepts The Registry is a repository of all ICP information. The main processes of the Registry are: the maintenance and validation of ICP information, both current and historical, via online and batch functions; a notification facility that advises all affected participants of changes made to ICP information; a delivery mechanism for the switching protocols; the provision of ICP lookup facilities to authorised participants, both online and in batch (file) mode; the provision of reconciliation reporting; the provision of compliance reporting; and the management of discrepancies between participant back-office systems and the Registry. The Rules Code defines which participant is responsible for specific ICP attributes and the timeframes within which the maintenance should be completed. The management of the maintenance timeframes is a passive process by the provision of 'after the fact' compliance reports. Diagram: Registry participants and its major functions Trader Meter equipment providers

18 4.1 Terminology Due to terminology changes over time, the following terms are equivalent and interchangeable in this document: Daily Unmetered kwh = unmetered load capacity; Distributor = network = line company; TraderRetailer is a class that includes direct purchasers and embedded generators that sell electricity directly to the clearing manager; Trader and retailer are synonymous, however Trader is now used in this document; market administrator = Electricity Authority = Board = EA; Meter Equipment Provider = meter owner = primary metering contact = MEP; Proposed TraderRetailer = first TraderRetailer = first requesting TraderRetailer; Reconciliation Type = connection type; replacement = update; and reversal = cancellation. And the following acronyms have the following meanings: Code = Electricity Industry Participation Code 2010 Rules = Electricity Governance Rules; GXP = grid exit point; GIP = grid injection point; NSP = network supply point; and POC - point of connection. 4.2 Code Rules references The Code rules referenceds in this document are contained in the following sections of the Code Rules: Part 11part E. A copy of the Code Rules can be downloaded from If there are any conflicts between this document and the Code Rules, the Code Rules takes precedence

19 4.3 Attributes of an ICP The main function of the Registry is to be the database of record for ICP information. An ICP has a number of possible attributes, the values of which may change over time. The Code Rules requires that certain attributes must only be maintained by specific types of participant, e.g. Distributors or TradersRetailers, and within specified time limits. These time limits, however, are used only in compliance reporting and do not restrict when the values of attributes may actually be changed. There are different types of ICP and each has different attributes. The full set of possible attributes for ICPs is as follows: Accumulator Type char 1 A single character code assigned to a register. Valid values are C for cumulative and A for absolute. Address An address consists of the following parts: Physical Address Unit - char 20 Physical Address Property Name - char 75 Physical Address Number/RAPID Number - char 25 Physical Address Street - char 30 Physical Address Suburb - char 30 Physical Address Town - char 30 Physical Address Region - char 20 and Physical Address Post code - numeric The completion and maintenance of an address in the Registry is the responsibility of the Distributor. The industry has developed guidelines for the consistent population of addresses. These guidelines are contained in a separate document. The minimum information required for a valid address is: Physical Address Property name or Physical Address Street; Physical Address Town or Physical Address Suburb; and Physical Address Region. Advanced Metering Infrastructure - char 1 A single-character value (Y/N) that indicates the presence of an advanced meter. Default is N. Approved Test House - char 4 A four-character code that identifies an Approved Test House for an installation location at an ICP. A value must be one of those in the list of valid Approved Test House identifiers held in the Registry

20 Certification Date - date Earliest Certification Date of all components at the installation location. Certification Expiry Date - date Earliest Certification Expiry Date of all components at the installation location. Certification Includes Control Device char 1 An indicator (Y/N) that the certification details includes the control device or not. Certification Variations char 32 Additional details on the certification status of the installation location. Certification Variations Expiry Date - date Earliest Certification Variations Expiry Date of all meters at the installation location. Channel Number - numeric A sequential number that uniquely identifies the channel or register of a component within the installation location of an ICP. Chargeable Capacity numeric 7.2 A numeric value (decimal with two decimal places) that is used to facilitate the communication of additional line charging information between Distributors and TradersRetailers. Component Details char 32 Free format optional description of the component. Component Identifier char 15 A 15 character code that as far as possible uniquely identifies the component (such as a serial number) within the ICP. Component Type char 2 A 2 character indicator of the type of component: M meter, CD control device, CT CT, VT VT. Daily Unmetered kwh char 6 If the Metering Type is unmetered or the meter count is 0 then an estimated daily quantity of unmetered load is required to be input. The value can be either the daily average kwh (decimal up to three decimal places) or the code ENG to indicate that the load is profiled using an engineering profile. There is no checking that the ICP has an associated engineering profile. Dedicated NSP char 1 A single character that indicates whether the ICP must be connected to one specific NSP and cannot be changed except under exceptional circumstances. The permitted values are:

21 Y yes; and N no (default). Distributor Installation Details char 30 A general-purpose alphanumeric value. Energy Flow Direction char 1 Valid values are 'L' for load and 'G' for generation. Highest Metering Category - Numeric A numerical code (from 01 to 65) indicating the maximum permitted error associated with any of the meters at the site. For ICPs with more than one meter only the highest number is recorded.. ICP Number - char 15 Each ICP has a unique identifier of the form: YYYYYYYYYYXXCCC where: YYYYYYYYYY is a 10-digit numeric code; XX is any two alphabetic characters as long as the resulting ICP Number is unique within the Registry; and CCC is a three-digit checksum. The algorithm for calculating the checksum is detailed in a separate document available on the EA website. Installation Number - numeric A sequential number that uniquely identifies an installation location within an ICP. Installation Certification Type char 3 HHR or NHH or INT (interim), indicates the type of certification assigned to the installation location at an ICP by the Approved Test House. Installation Type char 1 A single-character code that can take one of the following three possible values: L load; G generation; or B both. Loss Category char 7 A general-purpose alphanumeric code that identifies the algorithm used to calculate line losses for the ICP. Each Distributor has their own set of loss categories which they maintain themselves in the Registry, and against which the value of the attribute is validated. Maximum Interrogation Cycle - numeric The maximum number of days between actual meter reads for the installation location at the ICP

22 Metering Category - numeric A numerical code (from 01 to 65) indicating the voltage, current, measuring transformers and maximum permitted error associated with a meter. Primary Metering Contact Equipment Provider (MEP) Identifier char 4 Identifies the Meter Equipment Provider that is responsible for maintaining the MEP asset information for the ICP. Meter Equipment Provider codes are assigned by the reconciliation manager. NB: In practice, Distributors and TradersRetailers can themselves be Meter Equipment Providers and use the same code in all cases. There are additional processing requirements with respect to notifications (see the section 6.6 on Notifications). Meter Location Code char 3 Identifies the location of the meter installation at the ICP. A value must be one of those in the list of valid Meter Location Codes held in the Registry. Metering Type char 1 An indicator of the type of metering installed (physical). There are three different types: half hourly, non-half hourly and pre-paid. and unmetered (ie no meter installed) The single Metering Type (HHR, NHH and PP) is recorded against each meter. It is possible to have different types of meters (including unmetered) at an ICP. Meter Multiplier Flag char 1 A single-character value (Y/N) that indicates the presence of a Ratio Compensation not equal to 1 for at least one of the non-removed meter components at an ICP. Meter Price Category Code char 15 Indicates the price category the Meter Equipment Provider (MEP) has assigned to the components at an installation location (optional). Must be a valid code of the MEP found in the list of Meter Price Category Codes maintained by MEPs. Meter Register Count - numeric A numerical value representing the total number of registers, of nonremoved meter components, that have a Settlement Indicator of Y at an ICP. Network Identifier char 4 Indicates the Distributor responsible for a connection point. This value does not change on a day-to-day basis but may change over time, for example if Distributor providers merge. Network IDs are assigned by the reconciliation manager. Nominated Meter Equipment Provider (MEP) char

23 A participant identifier that the Trader nominates as the Meter Equipment Provider responsible for maintaining the meter asset information of the ICP. NSP Code char 11 A composite code made up of the Distributor identifier and the POC Identifier. All valid NSP Code combinations are maintained by the reconciliation manager in the Registry. Distributors can only use the NSP Codes where they are recorded as being the owner in the NSP mapping table. Owner char 6 A code that identifies the owner of an asset component. If four characters are input they are validated to be valid market participant codes otherwise they are not checked. Period of Availability - numeric A number <= 24 and is recorded against a register of a meter. It indicates the minimum service hours per day. It is mandatory if a register has a Register Content Code that is controlled (CN) or inclusive load (IN), otherwise it is optional. Price Category char 15 A general-purpose alphanumeric code (up to 15 characters) for identifying the line charges (there can be multiple charge categories associated with an ICP) to be applied by the Distributor to the TraderRetailer of the ICP. Each Distributor has their own set of pricing categories which they maintain themselves in the Registry, and against which the value of the attribute is validated. Profile char 3 A code that identifies the profile type(s) that has been assigned to the ICP. There can be multiple profiles associated with an ICP. Profiles are used in the reconciliation process to allocate energy consumption. TradersRetailers can only use profile codes approved for their individual use and only during a specific period. Profile codes are approved by the EA. POC Identifier char 7 A code that indicates the point of connection to which the ICP is connected. This information rarely changes but can do so if GXP boundaries change. POC Identifiers are assigned by the reconciliation manager and maintained in the NSP mapping table. Proposed TraderRetailer char 4 A participant code that identifies a valid TraderRetailer. During the pre-commissioning phase a Distributor can choose to record who they believe will be the initial TraderRetailer for an ICP. Notifications of all changes made to that ICP in the pre-commissioning phase are then required to be sent to this Proposed TraderRetailer. However, the actual initial TraderRetailer can be different from the one proposed

24 Ratio Compensation numeric 3.3 The Ratio Compensation (multiplication) factor is required to be recorded (decimal to 3 decimal places) against each meter. Reconciliation Type char 2 Indicates how the ICP consumption is reconciled. Values can be one of: GN GD GG EN SB LE SI grid connected network; direct consumer; grid connected generator; embedded network; embedded network residual load; embedded network gateway; or shared unmetered load. Register Content Code char 6 A value must be one of those in the list of valid Register Content Codes held in the Registry. E.g. D daytime only, N night- time only. Register Dials - numeric Number of dials/digits on the meter s registers. Valid values are between 4 and 12. Note that this applies only to non half hour registers. Register End Period char 5 End time of the register on the day type indicated in the Register Content Code. It is either a time in the format hh:mm, using the 24 hour clock, or the fixed time interval of the interval meter. For example, for half-hour meters this would be 00:30. Default is 00:00 but is mandatory input for AMI meters and must be less than or equal to 1 hour. If both the Register Start and End Times are 00:00 this denotes that there are no applicable start and end times. Register Start Period char 5 Start time of a register on the day type indicated in the Register Content Code. It is either a time in the format hh:mm, using the 24 hour clock, or the text FIXED. Default is 00:00 but is mandatory input for AMI meters. Register Unit of Measurement char 6 A code indicating the unit of measurement for the register. A value must be one of those in the list of valid register unit codes held in the Registry. E.g. kwh, kw, kva, kvarh. Removal Date - date The date the component was removed from the ICP. A valid date in the past. Removal Reason char

25 Free format text. Initial/Removal Meter Reading - numeric A meter register reading value recorded at the time of installation and at removal of each meter register. Settlement Indicator char 1 A single character value Y/N that indicates whether a register reading is required to be provided when the ICP switches Trader and for settlement purposes. Shared ICP List list (max 50 entries) A list value maintained by Distributors. For shared unmetered ICPs this will contain a list of ICP Numbers separated by a space. For Standard ICPs with a relationship to a shared unmetered ICP, this will contain the ICP Number of the shared unmetered ICP. Status numeric 3 A numeric code that has two roles. First it shows the stage the ICP has reached, such as new or ready during the pre-commissioning phase and decommissioned if it is no longer used. Second, once the ICP is commissioned, ie assigned to a TraderRetailer, it indicates whether the ICP is active or inactive, ie consuming energy or not. (Only those ICPs that are active during a reconciliation period are included in the reconciliation process.) The Status of an ICP can therefore be either: 999 new; 888 Distributor; 000 ready; 001 inactive; 002 active; or 003 decommissioned. Status Reason numeric 2 A 2- part two-character numeric code, required when the Status is inactive or decommissioned, that indicates the reason why the ICP has been given the Status. The current reasons associated with a decommissioned Status are: 01 setup in error; 02 installation dismantled; and 03 ICP amalgamation. The reasons associated with an inactive Status are: 04 de-energised vacant property; 05 reconciled elsewhere; 06 de-energised ready for decommissioning; 07 de-energised at AMI meter; 08 de-energised at pole fuse;

26 09 de-energised at meter box; 10 de-energised at meter box fuse; and 11 de-energised at meter box switch. There are 2 parts to the inactive Status Reason. The first part, indicated by the value of the first character, gives the reason for the inactive status and the second character indicates the location of the disconnection as follows: 1x - de-energised vacant property; 2x - reconciled elsewhere; 3x - de-energised ready for decommissioning; 4x - de-energised for any other reason. x0 - reconciled elsewhere x1 - de-energised at main switch; x2 - de-energised remotely by AMI meter; x3 - de-energised at meter box; x4 - de-energised at pole fuse; The above list of codes may change, but only very infrequently. Submission Type HHR char 1 A single character value (Y/N) indicating that an HHR submission will be submitted to the reconciliation process for this ICP. The value can only be set to Y if any of the Installation Certification Types of the ICP are HHR. Submission Type NHH char 1 A single character value (Y/N) indicating that a NHH submission will be submitted to the reconciliation process for this ICP. TraderRetailer Identifier char 4 A participant code that identifies the TraderRetailer responsible for supplying electricity to the ICP. This value can only be changed as a result of a switch. TraderRetailer Identifier codes are assigned by the reconciliation manager. It must be noted that TraderRetailer is a role within the Registry which is assigned to a class of participants such as embedded generators and direct purchasers who are not TradersRetailers as strictly defined in the Code Rules. Unmetered Load Details Distributor char 50 A general-purpose alphanumeric value used by the Distributor to record the type of unmetered load and its capacity and to notify the TraderRetailer. Unmetered Load Details TraderRetailer char 50 A general-purpose alphanumeric value used by the TraderRetailer to record supporting information about the type of unmetered load. UNM Flag char 1 A single character value (Y/N) indicating that the ICP contains unmetered load (formerly called Metering Type UNM)

27 4.4 Types of ICP The Code Rules describes two types of ICP: 1. Standard ICPs which are the majority of ICPs. These follow the standard lifecycle whereby they are created by Distributors, assigned to TradersRetailers and then able to be switched. Their information is managed by both Distributors, and TradersRetailers and MEPs; and 2. Distributor-Only ICPs these ICPs are not assigned to TradersRetailers. Their information is managed solely by their Distributor. They are used for two purposes: to record information about the point of connection between an embedded network, local network and its parent network (maintained by the parent network Distributor); and to record information about an ICP that represents a shared unmetered load installation, such as a sewerage pump or under-veranda lighting whose consumption is shared amongst other ICPs. (This ICP records which ICPs share the unmetered load.) The type of ICP is dictated by the Reconciliation Type. ICPs created with Reconciliation Types of LE and SI are Distributor-Only ICPs. The remaining Reconciliation Types are for Standard ICPs. Standard ICPs contain the following attributes: ICP Number; all possible attributes; Distributor-only embedded network metering installation ICPs ICP Number; Address; Distributor code; POC Identifier; Reconciliation Type; Dedicated NSP; Installation Type; Loss Category; and Status. Distributor-only shared unmetered ICPs ICP Number; Address; Distributor code; POC Identifier; Reconciliation Type;

28 Dedicated NSP; Installation type; Unmetered Load Details Distributor; Shared ICP List; Loss Category; and Status. 4.5 Events Events are the primary mechanism for handling changes to attributes in the current system. In the first version of the Registry, released in 1999, there was only one type of ICP and it only had seven attributes: date; TraderRetailer; data administrator; profile type; status; event reason; and NSP Code. Whenever an attribute was changed, a new record was created with a new date. The new value of the attribute was inserted and the values of the other attributes were copied unchanged into the new record from the one preceding it. In effect, each ICP was represented by a straightforward time-series. When the enhanced system was introduced in 2002 and new attributes were added, it was decided that it would not be practical to use the above approach; instead, the ICP attributes were partitioned into separate groups and the concept of events was introduced. In addition to its attributes, each event has an Event Date and a User Reference. The Event Date defines the date from which the attribute values of the event should apply. There is no end date. The state defined by the attribute values of an event for an ICP continues until a new event of the same type supersedes it. By convention, all events are deemed to occur at 0:00:00 on the day of the Event Date and to end at 23:59:59 on the day before the Event Date of the next event of the same type. The User Reference is general-purpose alphanumeric value available for recording any extra information the user deems appropriate. NB: The use of events is central to the current Registry system and it is a business requirement that their use must be incorporated into the new system. Information about ICPs must be structured as events, and events must be the user interface construct through which data is entered into the system and through which it is maintained. 4.6 Event types It should be noted that not all ICPs will have a full complement of events of each of the possible types shown below. For example, Distributor- Only ICPs will lack TraderRetailer and MEP Asset events. Event type Network This event type groups together the attributes relating to network connection details and the network owner (Distributor): Event Date; Network Identifier (Distributor responsible); POC Identifier;

29 Reconciliation Type; Dedicated NSP; Installation Type; Proposed TraderRetailer; Unmetered Load Details Distributor; Shared ICP List; and User Reference Event type Distributor Pricing This event type groups together the attributes relating to Distributor line charges and loss factors: Event Date; Loss Category; Price Category; Chargeable Capacity; Distributor Installation Details; and User Reference. Event type Address Refer to the attribute section for details on the minimum requirements of a valid address. The full Address event has the following attributes: Event Date; Physical Address Unit; Physical Address Property name; Physical Address Number; Physical Address Street; Physical Address Suburb; Physical Address Town; Physical Address Region; Physical Address Post Code; and User Reference. Event type reconciliation Trader This event type groups together the attributes used for reconciliation and for identifying the current TraderRetailer: Event Date; TraderRetailer; profile(s); Submission Type HHR; Submission Type NHH; Nominated Meter Equipment Provider; UNM Flag; Daily Unmetered kwh; Unmetered Load Details Trader; and

30 User Reference. Event type MEP Asset This event type groups together the attributes relating to the meters and other components at the ICP and to identify the Meter Equipment Provider; Summary information: Event Date; Metering Equipment Provider; Highest Metering Category (derived by the system from lower level information and is the highest category at the ICP); Metering Type HHR (derived by the system from lower level information. Set to Y if the ICP has HHR metering where at least one HHR component does not have a removal date); Metering Type NHH (derived by the system from lower level information. Set to Y if the ICP has NHH metering where at least one NHH component does not have a removal date); Metering Type PP (derived by the system from lower level information. Set to Y if the ICP has PP metering where at least one PP component does not have a removal date); Advanced Metering Infrastructure (derived by the system from lower level information) Set to Y if the ICP has at least one AMI component that does not have a removal date); Meter Register Count (derived by the system from lower level information. Only those registers of meters with a Settlement Indicator of Y and that have not been removed are included in the count); Meter Multiplier Flag (derived by the system from lower level information, set to Y if there is a component of Component Type meter that has not been removed within the MEP asset that has a Ratio Compensation of other than 1); Number Of Installation Location Records; and User Reference. Details per installation location: Metering Installation Number; Highest Metering Category; Metering Installation Location Code; ATH participant identifier; Metering Installation Type; Metering Installation Certification Date;

31 Metering Installation Certification Expiry Date; Control Device certification Certification Variations; Certification Variations Expiry Date; Certification Number; Maximum Interrogation Cycle Meter Price Category Code; Number Of Component Records (number of all component records for this installation regardless of whether removed or not) ; Details per component: Metering Installation Number; Metering Component Type; Metering Component Serial Number; Metering Type (HHR, NHH, PP); Advanced Metering Infrastructure; Metering Category; Compensation Factor; Metering Component Owner; Removal Date of a Metering Component; Reason for Removal of a metering Component; Details per channel: Metering Installation Number; Metering Component Type; Register Number; Number of dials; Register Content Code; Period of Availability; Unit of measurement Energy Flow Direction; Accumulator Type; Settlement indicator; Event Register Reading; Event type Status This event type groups together the attributes relating to the precommissioning stage and energisation status of the ICP (see ICP status lifecycle): Event Date; Status;

32 Status Reason; and User Reference. 4.7 Event type responsibilities Only Distributors may create, update and reverse Network, Pricing, Address and Status events (decommissioning only). Only TradersRetailers may create, update and reverse TraderRetailer and active and inactive Status events. Distributors and TradersRetailers jointly manage the Status event. Distributors are responsible for the Status in the pre-commissioning stage and when decommissioning the ICP. TradersRetailers are responsible for maintaining the energisation Status of the ICP inactive and active. It is important to note that it is, and will continue to be, the Trader who is responsible for maintaining the relationship of an ICP to the Meter Equipment Provider by the fact that they maintain the Nominated Meter Equipment Provider attribute in the Trader event. Meter Equipment Providers (MEPs) are solely responsible for maintaining the MEP Asset event information and will be able to receive notifications of changes to MEP Asset events and Distributor and Trader switches. 4.8 Event processing The following business rules govern the processing of all events. 1. Events must be made explicit to users at the user interface. 2. Users must be able to deal simultaneously with all the different types of event for an ICP for which they are responsible, and each event must be allowed to have a different Event Date unless otherwise stated. 3. Only the participant responsible for the creation of an event may update or reverse it. 4. Whenever a new value of an attribute is assigned, a new event must be created to incorporate the change. 5. There must be no automatic inheritance of attribute values. Whenever the value of an attribute needs to change, a value must be provided for every mandatory attribute of the associated event. 6. Event dates must not be in the future. The legal range for an Event Date is between 1 April 1999 and today s date. An event may be inserted anywhere in this range. 7. If an event of a given type is inserted for an Event Date for which another event already exists, the new event must replace the existing one. 8. There can only be one active event for one Event Date of a particular event type. This means that if one event is updated, and therefore replaced, it is the new event that

33 contains the currently applicable information. The information in the old event is no longer current. 9. When an existing event is reversed, it must only be logically deleted, not physically removed. It must be indicated as reversed. 10. Replaced and reversed events must be retained for history and audit trail purposes. 11. The insertion of a new event can be undone to revert to a prior event by reversing it. However, once an event is replaced or reversed it cannot be re-activated in any way. 12. A complete event history must be recoverable for each ICP, including reversed and replaced events. 13. When a new event is created, the following information must be recorded for audit purposes: the user ID of the person creating the event; the date and time the event was created; the method of creation, ie online or file; and the filename if the method was file. 14. When an existing event is reversed, the following information must be recorded for audit purposes: the user ID of the person reversing the event; the date and time of reversal; the method of reversal, ie online or file; and the filename if the method was file. 15. When an existing event is replaced, the following information must be recorded for audit purposes: the user ID of the person replacing the event; the date and time of the replacement; the identity of the replacement event; the method of replacement, ie online or file; and the filename if the method was file. 16. A user may only insert, update or reverse events during their company s period of responsibility. For example, if an ICP is switched to a TraderRetailer on date d1 and lost to another TraderRetailer on date d2, the TraderRetailer may make changes only on or after d1 and before d There are three possible responsibility relationships for an ICP: Distributor; TraderRetailer; and Meter Equipment Provider. Responsibility changes occur on the date of the event, in which the value of the corresponding attribute changes, ie Network ID, TraderRetailer ID, Meter Equipment Provider. 18. An event that would invalidate other prior events must not be inserted. For example, an ICP Status change to inactive may not be inserted before the initial assignment of a TraderRetailer to the ICP. Also, Reconciliation Types cannot be changed when that change would alter the type of ICP

34 19. An event may not be reversed if that reversal would invalidate a later event. 20. Events must be processed in the order in which they arrive. 21. Every insertion, change and reversal of an event must be acknowledged to the responsible participant. 22. Every participant affected by the insertion, change or reversal of an event must be notified of the fact. 23. System is to prevent the insertion of duplicate events. The processing of events can be thought of in terms of queues. When a new event is created it is placed in the queue for its type at a position determined by its Event Date. If there is already an event in the queue with the same Event Date then the new event is put in front of the existing one. Events are never physically removed from the queue, only logically deleted. The current event is the first non-reversed/nonreplaced event in a queue. The current event defines the attribute values of the given event type which presently apply for the associated ICP. The complete current state of an ICP is defined by the current events from each of its associated event queues. A queue may be empty, particularly during the pre-commissioning phase when events of some event types have yet to happen. 4.9 Acknowledgements The Code Rules requires that each and every change to an ICP attribute is are confirmed by the Registry to the participant making the change within four hours of input of the change (clause part E). For transactions entered online, although an online message of a successful update is sufficient as a confirmation, current automation of back-office systems by clients requires that all acknowledgements must also be provided in a batch file at the end of each day. For batch updates sent in a file, acknowledgements of each update must be provided in a file immediately the process has been completed. If the system rejects a change received in the file, it must indicate the reason as part of the acknowledgement. In both cases, users must be able to see online whether their changes have been confirmed (acknowledged). The details shown must include: date and time stamp; participant (sent to); and file name Notifications to responsible participants The Code Rules requires that, whenever an ICP attribute is changed, the Registry sends notifications of the change to all affected participants on the same day that the change is input (clause part E). The

35 affected participants are defined to be those responsible for the ICP on the Event Date of the change. Since one or more of the responsible participants may be the subject of a change to an ICP, both current (old) and/or new participants may need to be notified of the change. This means that the evaluation of which participants should receive notifications can be quite complex and results can differ depending on the order in which the processing is done. It should be noted that at present it is Retailers who are responsible for maintaining metering attributes, not the Meter Equipment Providers as might be supposed. However, although Meter Equipment Providers do not have any maintenance rights under the current rules they do have notification rights. All owners need to be informed: when their period of responsibility commences and ceases; and of attributes that change during their period of responsibility. Users must be able to see online whether notifications have been sent about an event change. The details shown must include: date and time stamp; participant (sent to); and file name. Filtering-up of historical changes An historical change is one that occurs before any current event of an ICP. When an historical change occurs, notifications must be generated for all participants that owned the ICP from the Event Date of the new event up to BUT NOT INCLUDING the Event Date of the next event (of the same event type) or up to today s date, whichever is the earliest. For example, if a Status event is inserted with an Event Date of 01/03/2004 before a later Status event of 01/05/2004 then all owners who owned the ICP during the period 01/03/2004 to 30/4/2004, must be notified of the change. The same filter-up logic must be applied to all insertions, updates and deletions and, in the case of updates, the replaced (old) event must be fully processed before the new event is inserted. Notification parameters The Code Rules (rule 26, part E and rule 5.4.4, schedule E2) defines what notifications are required (mandatory) when there are changes to events and to whom they are sent as follows:

36 Event type Distributor TraderRet ailer Meter Equipment Provider Address Mandatory Mandatory Optional ICP Status Mandatory Mandatory Optional Network Mandatory Mandatory Optional MEP Asset Mandatory Mandatory Mandatory Pricing Mandatory Optional Optional Reconciliation Trader Optional Mandatory Optional Switch 1 Mandatory Mandatory Mandatory TN Mandatory Mandatory Mandatory NC Mandatory Mandatory Mandatory MEP nomination 2 n/a n/a Mandatory EP Mandatory Mandatory n/a Certification Expiry 3 Mandatory Mandatory Mandatory Where mandatory is shown, the associated affected participant must be sent an appropriate notification. Where optional is shown, a participant must be able to choose whether to receive notifications of events of that type or not. It should be noted that a participant can have any number of roles, in which case they must be able to indicate what notifications they receive in each role. Duplicate notifications must not be sent to participants with dual roles on a single ICP. 1 The event referred to here is the TraderRetailer event that is generated on the completion of a switch due to the change of TraderRetailer. The system must be able to distinguish between this occurrence of a TraderRetailer event and its other occurrences. 2 The event referred to here is the TraderRetailer event that nominates an MEP. An MEP is sent the TraderRetailer event details with a specific notification type of E indicating it is a nomination. Only MEPs will receive an MEP nomination notification. 3 Notification of Certification Expiry The TraderRetailer, Distributor and MEP will be notified overnight if any of the ICP s installation s Certification or Certification Variations are near (see NP-060) their expiry date. These notifications are sent in a separate file from the standard notifications

37 4.11 Switching protocol The Registry supports 3 switching protocols, these are: 1. Distributor switching 2. Meter Equipment Provider switching 3. Trader switching 1. Distributor switching is performed by the Registry Administrator acting upon approval from the Electricity Authority. A Distributor supplies a file of ICPs to be switched, when the Electricity Authority approves the switch the Registry Administrator processes the file. 2. Meter Equipment Provider switching is via a request and response mechanism. If a Trader changes the Nominated MEP attribute on a Trader event, an MEP nomination is sent to the Nominated MEP via the overnight notification process (see 4.10). The MEP responds to the nomination with an acknowledgement either accepting or declining responsibility for the ICP (via an EP message). MEPs nomination acknowledgments (EP messages) are sent to the current Distributor and Trader, both rejections and acceptances. Code Name Purpose Acknowledgement Accept/decline MEP nomination. EP of MEP switch nomination The basic nomination message exchange between a Trader and MEP is as follows:

38 analysis Business Process Model MEP Process nomination Send notification response Process rejection Registry Reject response Validate MEP Nomination Valid nomination? no yes Create trader event Send nomination notification Validate Nomination response valid response? no yes Create MEP response event Rej ect nomination Send nomination response Trader Nominate MEP Process rejection MEP accepts nomination no yes End nomination An MEP must monitor their overnight notification files. A notification of a Trader event with a notification type E (instead of A ) will indicate an ICP nomination. The Nominated MEP must acknowledge the nomination by sending an EP message to the Registry (EP-010). Only MEPs will receive a notification type of E. If the Trader is also the MEP (i.e. they nominate themselves) then they will receive both the standard notification for the addition of a Trader event and the type E notification. Acceptance of a nomination is not when responsibility commences. The MEP assumes responsibility for an ICP only when they input an MEP Asset event. At that point they will start receiving standard notifications of changes to events. An MEP may enter MEP Asset event data when: They have been nominated by a Trader and They have accepted nomination. The earliest Event Date an MEP may use for an MEP Asset event is the Event Date of the Trader Event that nominated them. If there is a previous MEP who has maintained asset information with an Event Date past the nominating Trader event then the new MEP may either:

39 1. Use an Event Date later than the date on the last asset information entered by the previous MEP, or 2. Request the previous MEP to reverse any asset information after the Trader Event that nominated the new MEP. An MEP must respond to every nomination in ascending Event Date sequence ie. earliest one first. The EP message will contain the Event Date corresponding to the nomination being acknowledged.: An MEP nomination is indicated by a change to the Nominated MEP code in the Trader event. When subsequent Trader events are inserted that do not change the Nominated MEP code, no further nomination notifications are generated as these are not regarded as new nominations: The Registry will send the MEP only nomination notifications to which they must respond. An MEP may send multiple acknowledgements to a nomination thereby changing their acceptance/reject response. Each acknowledgement replaces the previous acknowledgement. A Trader may nominate a new MEP at any time in the ICP s life cycle however a Trader cannot un-nominate an MEP where that MEP has input MEP Asset events. An exception is where the MEP was nominated as part of a switch and the switch is being withdrawn. Any asset events input by the Nominated MEP as part of the switch, or input by another MEP subsequent to the switch, will be reversed