Registry Functional Specification v22 24

Electricity Authority Registry
Functional Specification
Version 22.24
01 February 2018
Version control
Version Release Date Section Description
1 to 21. September Pre-Part10 Registry Functional Specifications. Revision

2006 to history retained in the respective versions.
October 2012
19A.8 August 2013 Development version of the Part10 Registry upgrade

containing details of all the changes required to the
Functional Specification and contains the full revision
history.
22 29 August Clean copy of version 19A.8.

2013
Part 10 Registry upgrade.
22.1 4 September Appx. 7 Use of MNON and MREM.

2013
RS-050 BR12 .eda filename clarification
PR-040, Days overdue calculation for irregular event updates

PR-110
BR1 amendment to use the most recent metering event
NP-060 when generating a metering alert
RA-010, Notation added to reference appendix 7 when using

RM-020 participant identifier of MNON and MREM
NP-010 Event date field is optional not mandatory as no date is

returned if an MN is declined
Metering certification date, if entered, cannot be greater

MM-010 than today’s date.
22.2 28 January PR-210 Addition of Missing Metering Data Report

2014
Appendices Formatted to include numbering
2 to 7
PR-220 Addition of Uncertified Metering Installations Report
PR-230 Addition of Energisation Misalignment Report
PR-240 Addition of Profiles Report
NP-060 Alerts Type C applicable to ICPs where the Status is Active
Appendix 4 Appendix 4 updated with PR-210/220/230/240
B
Version 22.24
22.3 18 February Appendix 6 Remove old (pre part 10) switch process diagrams
2014
24 February
2014 MM-030
Correct MM-030 data inputs example
Appendix 6
04 March 2014
Swim lane diagrams left side lane identifier had shrunk to
font size 1. Modify back to 5.
05 March 2014 PR-230
PR-030
07 March 2014
Modifications to business rules used to identify ICP’s being
reported
13 March 2014 PR-210

Expand description of parameter usage when PR-030
PR-240 report submitted by the Authority
09 May 2014
1.14.2,
11 June 2014
RS-010, Correct the example under data outputs
RS-020,
RW-010, Rename Profiles Report to Profiles Misalignment Report
RW-020,
DS-010
22.4 11 June 2014 PR-250, Addition of new reports in the even to of a trader default
PR-270, situation (trader default change requests CR1134/42/44/45)
PR-280,
PR-290,
Batch
interface
cross
reference
Addition of the ability to configure participant roles with start
map
and end dates (change request CR-1132)
C
22.5 25 June 2014 RA-010 Inhibit Traders in Trader Default from acquiring
RS-010 responsibility for ICPs (CR1134)
RS-050
RW-010
RW-020
22.6 21 July 2014 SD-020 Addition of new Register Content Codes
30 July 2014 SU-030 Supervisor ability to disable logons (existing functionality -

documentation update only)
22.7 15 October PR-010 Clarification to End date parameter (document change only)
2014
PR-030 Business rule 8 wording change (document change only)
15 October
2014
17 November RS-050 CR-1157 Manage setting of submission type during a trader

2014 switch using profile codes supplied on the NT
CR-1158 Amendments to the energisation misalignment

17 November PR-230
report rules identifying ICPs not aligned with their Initial
2014
Energisation Date.
22.8 21 December PR-255 CR-1153 Metering installation information report

2015
SD-020 CR-1161 Introduction of switch saves-protection table for
21 December recording participating Trader
2015
22.9 2 February 1.14 CR-1149 Trader Default Exclusions Table

2015 1.19
CR-1150 Complete Switch Activity
MP-020
SD-020 CR-1151 Tender Allocation and Mandatory Assignment
TD-010
CR-1165 Change Retailer Default to Trader Default
TD-020
TD-030
TD-040
TD-050
TD-060
TD-070
TD-080
TD-090
D
Version 22.24
PR-300
PR-310
RS-020
RS-050
RW-010
RW-020
PR-250
PR-270
PR-290
11 March 2015 CR-1167 Add fields to PR-300
PR-300
CR-1168 Exclude ICPs which are inactive and ready for
decommissioning from the Trader Default Tender and
TD-030
Allocation processes
TD-070
13 March 2015
Miscellaneous clarifications and corrections following
TD-010 Trader Default simulation exercise.
TD-040
TD-050
TD-060
TD-080
PR-300
22.10 30 March 2015 PR-300 Correct file example
29 April 2015 CR-1170 NHH meter using H profile

RA-010
RS-010
Section
1.4.7
22.11 05 May 2015 PR-320 CR-1162 switch type codes (CE and CX)
SD-050
16 June 2015 QU-040 CR-1164 Email Addresses
EI-010
MP-020
NP-060
Section
1.19
E
22.12 26 July 2015 1.14 CR-1160 Third Party Provider access to the Registry
EI-010
26 July 2015 PR-330 CR-1172 Annual Levy reports

PR-340
Appendix
4
22.13 07 August PR-010 Documentation - correct example.

2015
Verify the CS actual transfer date is greater than the ICPs
RS-050
initial assignment date
22.14 18 September RS-050 Noted by auditor in review of CR-1176: Remove

2015 meaningless business rule 9. Correct grammar in
processing rule 19
27 September RS-010
2015 Implementation of CR-1176 amending rules where switch
type MI, TR and HH may be used
13 October
2015 EI-010, EI- CR-1178 to allow participants to receive email notices,
030 delivered from the EIEP hub, to an Email group matching
the name of the EIEP file type
13 October
Refer to static data table for latest switch withdrawal codes
2015 RW-020
22.15 21 October Section Documentation change only, EIEP table missing a

2015 1.17 reference to report PR-190
11 December Documentation change only

2015
QU-020
14 December 1.20
Documentation change, expansion of Email Group
2015
functions and recommended practice
F
Version 22.24
22.16 02 March 2016 PR-030 Documentation change only. Correction to PR-030 input file
example.
Clarify when end date may be set on Distributor Price

04 March 2016 SD-040
Category Code
CR-1186 phase 1: metering installation certification type of

01 April 2016 MM-010 interim date limit applied. Interim metering may be used for
and 1.4.1 metering events dated prior 01 April 2016 provided all
interim certified metering components are removed.
01 April 2016 SD-020 Addition of new register Content Codes
05 April 2016 PR-050 CR-1171 – improve accuracy of consumption data

PR-080 interfaced to the RM by performing additional NSP level
validation. Addition of email group to the EMCO participant
SD-050
to report results of NSP level validation
15/04/2016 NP-060 CR-1186 phase 2: report to the Authority, in the monthly

report, where an ICP has a metering event with a Metering
Installation Certification Type of Interim after the effective
end date of the interim certification type.
Spelling errors in Switch Meter Reading Change diagram

15/04/2016 Appx 6
22.17 13/05/2016 NP-060 CR-1189: an alert sent to participants for the same ICP and
situation must be sent to the Authority once in the monthly
alert report
22.18 08/06/2016 DS-010 ER-126: extend shared ICP list to max 500 characters
10/06/2016 CR-1152: provide greater clarity on the type of metering

QU-020
used by an ICP
1.4.14
CR-1193 – include hyphenated street in street name index
10/06/2016
QU-010
14/06/2016
Metering CR-1190 – Derive HHR and NHH flag values from Metering
Attributes Installation Type within any metering installation of the ICP
23/06/2016 1.4.9
23/06/2016 PI-010 Addition of Publish information process and PI-010 sub

process
G
SU-010 Documentation clarifications to Add new user process
22.19 28/06/2016 MM-010 Clarification to business rule 3 a.

QU-010
Clarification to business rule 4
PR-120 Addition of NSP table report request example.
Addition of MM-040 Missing MEP Ownership Historical

MM-040
Insertion.
23/10/2016 Section
1.12.13
Section
1.12.14
Process
Maps figure
3
RM-020
MM-010
DS-010 Clarify DS-010 input files does not require a header line
PI-010 CRCON-1005 Amendments to publish information,

01/06/2017 documents, addition of FAQ and trouble shooting guide
01/06/2017 SU-020 / CRCON-1001 Enhanced auditing and logging
SU-050
02/06/2017 DS-010 Change Optional parameter to Mandatory and clarify the

correct values that must be supplied.
22.20 07/06/2017 RS-050 Correction to CS switch examples
13/06/2917 CR CON-1002 Password Reset

Security
Section
1.16
Fig 6
Process
Map
SU-010
H
Version 22.24
1 SU-020
SU-030
PW-010
PW-020
Appendix
3Various
6/06/2017 Consistency of terminology, Registry Administrator term
now consistent as Registry Manager
Security
CR-1205 User Web Services Access Only
27/07/2017 Section
1.16
Fig 6
Process
SU-010
SU-040
PW-010
PW-020
Appendix 3
22.21 08/08/2017 Security JIRA ER-702

Section
1.16
Appendix A
16/08/2017 ER-646, correct typo in checksum wording
Calculation
of the ICP
checksum
20/09/2017 1.4.13 ER-714/ER-716 revised terminology for energised and de-

SD-020 energised ICP state, including energisation (due to Code
RS-020 amendment)
Appendix 7
PR-230
22.22 14/12/2017 1.11 CR-1202 Smart notifications. Notifications for ATH/MEO.
1.14.18 Notification web service.
1.18
NP-030
NP-070
I
22.23 31/01/2018 1.15.4 CR-1201 Transfer EIEP files to the Authority

1.17
1.20
1.21
1.22
Process
Map – Fig 8
PR-100
EI-030
EI-040
Current
Valid For EIEP File Type codes
Codes
As per Auditor suggestion - Remove FTP references (use

SFTP instead)
Removal of references to ‘Market Administrator’ as it longer

exists in the Code.
22.24 Process ER-390 Addition of Process Map 9 Trader Default

map fig 9
SD-020 Authority adjustments to Register Content Codes (based on

the decisions paper released 20 March 2018)
 new register content codes DIN/NIN, INEM, NB,

NO, SL
 several code combinations grandfathered
 several codes discontinued.
Appendix 5 New appendix 5: supporting information:
 register content codes period of availability
 mapping of customised to generic codes.
J
Version 22.24
Registry functional specification
Introduction
The registry is a national database that contains information on every point of connection on
the national grid from which electricity is supplied. These points of connection are referred to
as installation control points (ICPs). Each ICP has a unique identifier (an ICP 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 2010 (the
Code) provides for the management of information held by the registry and outlines the
process for switching customers between Traders.
Background
The first registry was implemented in April 1999 and was further enhanced in 2002. The
original requirement for that registry was to provide a low-cost system to enable end-use
customers to switch energy Traders and was concerned with the recording of basic
responsibility, 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 switching of the customer trading at an ICP from
one Trader to another.
The enhancement in 2013 expanded the information about an ICP yet again to include
additional metering installation information which is maintained by Metering Equipment
Providers (MEP), a new role, in the Registry.
This document
This document describes the business functional requirements of the registry. This document
should be read in conjunction with the associated registry Operational Requirements.
It is important to note that the registry system currently exists and, while 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.
K
Contents
Version control ............................................................................................. B
Registry functional specification ................................................................. K
1. System Structure ............................................................................... 1

1.1 Concepts ................................................................................................................. 1
1.2 Terminology ............................................................................................................. 3
1.3 Code references ...................................................................................................... 4
1.4 Attributes of an ICP.................................................................................................. 4
1.5 Types of ICP .......................................................................................................... 24
1.6 Events ................................................................................................................... 25
1.7 Event types ............................................................................................................ 26
1.8 Event type responsibilities ..................................................................................... 27
1.9 Event processing ................................................................................................... 27
1.10 Acknowledgements................................................................................................ 30
1.11 Notifications ........................................................................................................... 30
1.12 Switching protocols ................................................................................................ 33
1.13 ICP Status lifecycle ................................................................................................ 38
1.14 Participants and registry roles ................................................................................ 43
1.15 User interfaces....................................................................................................... 52
1.16 Security ................................................................................................................. 54
1.17 EIEP Exchange...................................................................................................... 56
1.18 Web Services ........................................................................................................ 57
1.19 Trader default process ........................................................................................... 57
1.20 Email groups.......................................................................................................... 61
1.21 Transfer to the Authority SFTP Server ................................................................... 63
1.22 Transfer EIEP files to the Authority SFTP Server ................................................... 63
2. Process Maps ................................................................................... 65
3. Sub-processes .................................................................................. 72
3.1 ICP event maintenance – Distributor ............................................... 72

DC-010 Create an ICP ........................................................................................... 72
L
Version 22.24
DC-020 Make a new ICP ready .............................................................................. 78

DC-030 Make a new ICP distributor........................................................................ 80
DM-010 Change initial ICP creation date ................................................................82
DM-020 Add additional Distributor information ........................................................ 84
DM-030 Correct Distributor information................................................................... 91
DM-040 Reverse Distributor information ................................................................. 93
3.2 ICP event maintenance – Trader ...................................................... 95

RA-010 Trader becomes responsible for an ICP – Initial Assignment ..................... 95
RM-010 Trader cancels the initial assignment ...................................................... 100
RM-020 Add new Trader information .................................................................... 101
RM-030 Correct Trader information ...................................................................... 103
RM-040 Reverse Trader information..................................................................... 105
3.3 ICP event maintenance – MEP maintains Metering installation

information ..................................................................................... 107
MM-010 Add new metering information ................................................................ 107
MM-020 Correct metering information .................................................................. 115
MM-030 Reverse metering information ................................................................. 117
MM-040 Missing MEP Ownership Historical Insertion ........................................... 119
3.4 Switching ....................................................................................... 124

RS-010 Make switch request (NT) ........................................................................ 124
RS-020 Acknowledge switch request (AN) ........................................................... 128
RS-030 Complete non-half-hour switch (TN) - Discontinued ................................. 131
RS-040 Complete half-hour switch (TT) – Discontinued ....................................... 136
RS-050 Complete switch or replace switch reading (CS and RR) ......................... 140
RW-010 Make withdrawal request (NW) ............................................................... 149
RW-020 Acknowledges withdrawal request (AW) ................................................. 151
RC-010 Request switch read change (NC) - Discontinued ................................... 154
RC-020 Acknowledge switch read change (AC) ................................................... 158
MN-010 Accept or decline MEP responsibility for ICP (MN) .................................. 160
DS-010 Transfer ICPs between Distributors ......................................................... 164
3.5 Reporting........................................................................................ 168

PR-010 Produce ICP list (on demand) .................................................................. 168
PR-015 Produce current details report .................................................................. 176
PR-020 Produce monthly Trader ICP reports........................................................ 178
PR-030 Produce ICP event detail audit report ...................................................... 179
M
PR-035 Produce ICP Attribute Changes .............................................................. 194

PR-040 Produce switch compliance reports......................................................... 197
PR-050 Produce ICP days report ......................................................................... 206
PR-060 Produce audit log .................................................................................... 210
PR-065 Request file handler status...................................................................... 212
PR-070 Produce monthly statistics ...................................................................... 214
PR-080 Produce monthly HHR ICP list ................................................................ 219
PR-090 Produce active NSPs report .................................................................... 223
PR-100 Produce loss factors report ..................................................................... 225
PR-110 Produce maintenance compliance report ................................................ 227
PR-120 Produce NSP mapping table report......................................................... 235
PR-130 Produce monthly activity and status summary report .............................. 238
PR-140 Produce monthly switch completion report .............................................. 241
PR-145 Produce daily switch report - Discontinued ............................................. 244
PR-160 Produce Automated Trade Notification.................................................... 245
PR-170 Produce Monthly report ........................................................................... 247
PR-180 Produce ICP Switching Trend Report ..................................................... 248
PR-190 Produce EIEP Statistics .......................................................................... 252
PR-210 Missing Metering Data ............................................................................ 254
PR-220 Uncertified Metering Installations ............................................................ 257
PR-230 Electrical Connection Misalignment ........................................................ 260
PR-240 Profiles Misalignment .............................................................................. 263
PR-250 Trader Default General Information......................................................... 267
PR-255 Produce Metering Installation Information ............................................... 270
PR-270 Produce report of Traders in a trader default situation by NSP ............... 276
PR-280 Responsibility outside Participant Role ................................................... 278
PR-290 Produce Trader Default Situation Market Share Report .......................... 281
PR-320 Monitor switch saving protection scheme ................................................ 284
PR-330 Produce Distributor Annual Levy report................................................... 287
PR-340 Produce Trader Annual Levy report ........................................................ 293
3.6 User parameters............................................................................. 297

MP-010 Set switching message receipt times ...................................................... 297
MP-020 Set notify parameters ............................................................................. 299
3.7 Notifications ................................................................................... 301

NP-010 Acknowledge event change .................................................................... 301
NP-020 Send switch messages ........................................................................... 305
NP-030 Notify of event change ............................................................................ 307
N
Version 22.24
NP-040 Re-send switching messages .................................................................. 318

NP-050 Re-send notifications ............................................................................... 319
NP-060 Alert Participants ..................................................................................... 320
NP-070 Web Service notify of event change......................................................... 325
3.8 Online queries ................................................................................ 329

QU-010 Search to find an ICP identifier ................................................................ 329
QU-020 View ICP information ............................................................................... 332
QU-030 View static table information .................................................................... 337
QU-040 View Registry Audit Data ......................................................................... 338
3.9 Maintaining static data .................................................................. 342

SD-010 Maintain NSP data ................................................................................... 342
SD-020 Maintain static data .................................................................................. 344
SD-030 Maintain Distributor Loss Category Codes ............................................... 360
SD-040 Maintain Distributor Price Category Codes .............................................. 364
SD-050 Maintain email groups .............................................................................. 367
3.10 Security .......................................................................................... 373

SU-010 Add and maintain new users.................................................................... 373
SU-020 Disable and re-enable logons .................................................................. 375
SU-030 Reset user password ............................................................................... 377
SU-040 Assign agent ............................................................................................ 379
SU-050 Lockout logons ........................................................................................ 380
PW-010 Change user password ........................................................................... 382
6. The Registry must ensure that a one-time-use password can only be
used once. ............................................................................................................ 384
3.11 EIEP Transfer ................................................................................. 386

EI-010 Configure EIEP Transfer Settings.............................................................. 386
EI-020 Upload and Download EIEP via the browser ............................................. 388
EI-030 Transfer EIEP via SFTP ............................................................................ 390
EI-040 Maintain EIEP Transfer Permissions ......................................................... 393
3.12 Trader Default ................................................................................ 395

TD-010 Complete Switch Activity for Trader in Trader Default .............................. 395
TD-020 Maintain Trader ICP Allocation Exclusion List .......................................... 402
TD-030 Create Tender Blocks .............................................................................. 406
TD-040 Send Tender Documentation ................................................................... 410
O
TD-050 Load Trader Bids .................................................................................... 416

TD-060 View tender bids, tender and mandatory assignment allocation results ... 420
TD-070 Allocate ICPs .......................................................................................... 423
TD-080 Switch Trader Default Trader ICPs.......................................................... 427
TD-090 ICP re-assignment process ..................................................................... 431
PR-300 Report Trader Default tender and mandatory assignment ....................... 434
PR-310 Report Trader Default allocation results .................................................. 439
3.13 Publish Information ........................................................................ 443

PI-010 Publish information ................................................................................... 443
Appendix 1: Calculation of the ICP checksum ......................................... 445
Appendix 2: Address population standards .............................................. 455
Appendix 3: Password standards ............................................................. 469
Appendix 4: Batch file standards and file processing .............................. 471
Appendix 5 – Period of availability and mapping of customised to

generic register content codes ...................................................... 490
Period of availability .................................................................................. 490
Mapping of customised to generic register content codes ...................... 491
Appendix 6 – XML format of PR-030 ICP information ................................ 494
Appendix 7 – Switch Process Flow Diagrams ........................................... 497
Appendix 8 – Use of MNON and MREM ...................................................... 505
P
Version 22.24
Figures
Figure 1: Diagram: Registry participants and its major functions ......................................2

Figure 2: ICP lifecycle ..................................................................................................... 38
Figure 3: Process map – ICP event Distributor, Trader and MEP maintenance .............. 65
Figure 4: Process map – switching (Trader and MEP) .................................................... 66
Figure 5: Process map – reporting, parameters, notifications and queries ...................... 67
Figure 6: Process map – maintaining static data and access security ............................. 68
Figure 7: Process map – publish information .................................................................. 69
Figure 8: Process map – EIEP configuration, upload, download, transfer and report ......70
Figure 9: Process map – Trader Default ......................................................................... 71
Q
Version 22.24
1. System Structure
1.1 Concepts
1.1.1 The registry is a repository of all ICP information.
1.1.2 The main processes and purposes of the registry are:
(a) the maintenance and validation of ICP information, both current and
historical, via online and batch functions;
(b) a notification facility that advises all affected participants of changes
made to ICP information;
(c) a delivery mechanism for the switching protocols and EIEP files;
(d) the provision of ICP lookup facilities to authorised participants, both
online and in batch (file) mode;
(e) the provision of reconciliation reporting;
(f) the provision of compliance reporting; and
(g) the management of discrepancies between participant back-office
systems and the registry.
1.1.3 The Code defines which participant is responsible for providing information
about specific ICP attributes, and the timeframes within which the information
must be provided. The management of the timeframes is a passive process
by the provision of ‘after the fact’ compliance reports.
1
Version 22.24
Figure 1: Diagram: Registry participants and its major functions
2
Version 22.24
1.2 Terminology
1.2.1 Due to terminology changes over time, the following terms are equivalent and
interchangeable in this document:
(a) Daily Unmetered kWh = Unmetered Load Capacity;

(b) Distributor = Network = line company;
(c) Trader = a retailer, direct purchaser, or generator who buys electricity
from or sells electricity directly to the clearing manager, or who enters
into an arrangement with a retailer, direct purchaser, or generator to buy
or sell contracts (or parts of contracts) for electricity;
(d) Electricity Authority = Board = Authority;
(e) Metering Equipment Provider = MEP = Meter Owner;
(f) Proposed Trader = first Trader;
(g) Reconciliation Type = connection type;
(h) replacement = update; and
(i) reversal = cancellation.
(j) Trader Switch in progress = Trader Switch is in Progress. The ICP is
within a process which may result in a change of Trader responsibility
(e.g. NT to CS cycle, NW to AW cycle).
(k) MEP Switch in progress =. The ICP is within a process which may result
in a change of MEP responsibility. This is indicated by, for any particular
Event Date, a mismatch between the Proposed MEP attribute (that is not
null) on the applicable Trader event and either the responsible MEP on
the applicable Metering event or where there are no Metering events.
(l) Trader Default = a situation which arises if a Trader fails to meet a call
for security, or fails to meet their settlement obligations (both of which
are events of default). The Authority notifies the Registry when a Trader
enters this state after which a Trader may not gain ICP responsibility
through switching or Initial Assignment.
1.2.2 And the following acronyms have the following meanings:
(a) Code = Electricity Industry Participation Code 2010;

(b) GXP = grid exit point;
(c) GIP = grid injection point;
(d) NSP = network supply point; and
3
Version 22.24
(e) POC = point of connection.
1.3 Code references

1.3.1 The clauses of the Code referenced in this document are contained in Part 11
of the Code.
1.3.2 A copy of the Code can be downloaded from http://www.ea.govt.nz/act-code-

regs/code-regs/the-code/ .
1.3.3 If there are any conflicts between this document and the Code, the Code takes
precedence.
1.4 Attributes of an ICP

1.4.1 The main function of the registry is to be the database of record for ICP
information. An ICP has a number of possible attributes, which may change
over time. The Code requires that information about certain ICP attributes be
provided and updated by the relevant Distributor, Trader or MEP, within
specified time limits.
1.4.2 There are different types of ICPs and each has different attributes. The full set
of possible attributes for ICPs is listed in the tables below.
1.4.3 ICP Attributes

Attribute Format Description
ICP Identifier Char 15 Each ICP has a unique identifier of the

form: yyyyyyyyyyxxccc where:
yyyyyyyyyy is a 10-digit numerical

sequence provided by the Distributor;
xx is two alphabetic characters

assigned by the Authority to the
Distributor and ensures the resulting
ICP Identifier is unique within the
registry; and
ccc is a three-digit checksum.
The algorithm for calculating the

checksum is detailed in Appendix 1.
4
Version 22.24
1.4.4 Address Attributes

Physical Address Unit Char 20 Address unit
Physical Address Char 75 Address property name

Property Name
Physical Address Char 25 Address number / RAPID number

Number
Physical Address Street Char 30 Address street
Physical Address Char 30 Address suburb

Suburb
Physical Address Town Char 30 Address town
Physical Address Char 20 Address region

Region
Physical Address Post Numeric 4 Address post code

Code
GPS_Easting Numeric 7.3 The easting location. Optional but

required if GPS_Northing is provided.
New Zealand Transverse Mercator 2000

(NZTM2000) coordinates, as defined in
Land Information New Zealand’s
LINZS25002 standard (Standard for New
Zealand Geodetic Datum 2000
Projections).
GPS_Northing Numeric 7.3 The northing location. Optional but
required if GPS_Easting is provided.
New Zealand Transverse Mercator 2000

(NZTM2000) coordinates, as defined in
Land Information New Zealand’s
LINZS25002 standard (Standard for New
Zealand Geodetic Datum 2000
Projections).
(a) The inclusion of the ICP Address of an ICP in the registry is the
responsibility of the Distributor. The industry has developed guidelines
5
Version 22.24
to ensure the consistent population of addresses. These guidelines are

contained in Appendix 2.
(b) The minimum information required for a valid ICP Address is:
(i) Property Name or Street;
(ii) Town or Suburb; and
(iii) Region.
1.4.5 Network Attributes

Network Participant Char 4 A four-character code indicating the

Identifier Distributor/Network owner responsible for
a connection point. This value does not
change on a day-to-day basis but may
change over time, for example if Network
providers merge. Network Participant
Identifiers are assigned by the Authority.
POC Char 7 A seven-character code that indicates the

POC to which the ICP is connected. This
information rarely changes but can do so
if GXP boundaries change. POCs are
assigned by the Reconciliation Manager
as part of the NSP identifier and
maintained in the NSP mapping table.
Reconciliation Type Char 2 A two-character code that indicates how

the ICP consumption is reconciled. Values
can be one of:
GN grid connected network;

EN embedded network;
SB embedded network residual load;
LE embedded network gateway; or
SI shared unmetered load.
Note: LE and SI Reconciliation Types are
Distributor-only ICPs. Further information
on Distributor-only ICPs can be found in
section 1.5.
Dedicated NSP Char 1 If an ICP is located in a balancing area

that has more than 1 NSP located within it,
and the ICP will be supplied only from that
particular NSP, or the ICP is a point of
connection between a network and an
6
Version 22.24
embedded network, the ICP must be

designated as "dedicated".
A single character is used to indicate

whether the ICP is dedicated. The
character must be:
Y—yes (the ICP is dedicated); or
N—no (the ICP is not dedicated). This

is the default character.
The Reconciliation Manager uses the

Dedicated NSP status as a priority order
when moving volumes between NSP’s to
achieve balance.
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.
Proposed Trader Char 4 A four-character code (Participant

Identifier) that identifies a valid Trader.
During the pre-commissioning phase a
Distributor can choose to record who they
believe will be the initial Trader trading at
an ICP. Notifications of all changes made
to that ICP in the pre-commissioning
phase are then required to be sent to that
Trader. However, the actual initial Trader
can be different from the one proposed.
Unmetered Load Details Char 50 A general-purpose alphanumeric value

– Distributor used by the Distributor to record the type
of unmetered load and its capacity and to
notify the Trader.
Shared ICP List List A list maintained by Distributors. For ICPs

across which unmetered load is shared
(Shared Unmetered ICPs see section 1.5),
the list will contain the ICP identifiers of
each ICP separated by a space. For
Standard ICPs with a relationship to
Shared Unmetered ICPs (across which
unmetered load is shared), this will contain
7
Version 22.24
the ICP Identifier of the Shared

Unmetered ICP.
Generation Capacity Numeric 6.2 Generation nameplate capacity in kW.

Only required where the Installation Type
is ‘B’ or ‘G’.
Fuel Type Char 15 A valid Fuel Type. Only required where

the Installation Type is ‘B’ or ‘G’. A list of
valid Fuel Types is stored in the Registry
reference tables. See SD-020.
Initial Electrically Date Date the ICP was first electrically

Connected Date connected. Optional. The Code requires
that distributors populate ICPs that have
an initial electrically connected date of 29
August 2013 or later however the Registry
does not enforce any validation.
Note to distributors: This date should be

>= Event Date of the Ready status as a
Trader cannot insert an initial assignment
prior to the Ready Event Date, however,
the Registry will not validate it to be so.
Direct Billed Status Char 11 Indicates who, out of the Distributor or

Trader, directly bills the customer for the
lines charges. Valid values are: ’Retailer’,
‘Distributor’, ’Neither’, ’Both’, ’TBA’ and
NULL. Optional.
Direct Billed Details Char 60 Contains other information relating to

direct billing arrangements such as
commencement or cessation dates.
Optional. Free text.
(a) The NSP Identifier is a composite code made up of the Network

Participant Identifier and the POC. All valid NSP identifier combinations
are maintained by the Reconciliation Manager in the registry.
Distributors can only use the NSP identifiers where they are recorded as
being the owner in the NSP mapping table.
(b) The NSP Identifier is assigned in the following format: bbbqqqz nnnn.
Where bbbqqqz is the POC and nnnn is the Network Participant
Identifier.
8
Version 22.24
1.4.6 Pricing Attributes

Distributor Price Char 50 A general-purpose alphanumeric code for

Category Code identifying the line charges (there can be
multiple charge categories associated with
an ICP) to be applied by the Distributor to
the Trader trading at an ICP. Each
Distributor has their own set of price
categories which they maintain in the
registry, and against which the value of
the attribute is validated.
Distributor Loss Char 7 A general-purpose alphanumeric code

Category Code that identifies the algorithm used to
calculate line losses for the ICP. Each
Distributor has its own set of loss
categories which it must maintain in the
registry, and against which the value of
the attribute is validated.
Distributor Installation Char 30 A general-purpose alphanumeric value.

Details
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
Traders.
1.4.7 Trader Attributes

Trader Participant Char 4 Identifies the Trader responsible for

Identifier supplying electricity to the ICP. This value
can only be changed if another Trader
accepts responsibility for the ICP.
NB: The Trader ceases to be responsible

for obligations in Part 11 when another
Trader accepts responsibility for the ICP
or the ICP is decommissioned in
accordance with clause 20 of schedule
11.1.
9
Version 22.24
Trader Participant Identifiers are assigned

by the Authority.
Profile Char 25 A list of three-character codes that identify

the profile type(s) that has been assigned
to the ICP, space separated.
There can be multiple Profiles associated

with an ICP. Profiles are used in the
reconciliation process to allocate energy
consumption. Traders can only use
Profile codes approved for their individual
use and only during a specific period.
Profile codes are approved by the market
administrator.
Proposed MEP Char 4 A four character Participant Identifier code

indicating the participant proposed by the
Trader to be the MEP.
UNM Flag Char 1 An indicator that an ICP has some

unmetered load.
Daily Unmetered kWh Char 6 If an ICP is unmetered (ie the metering

UNM Flag is ‘Y’), and the load is profiled
through an engineering profile in
accordance with profile class 2.1, the code
‘ENG’ must be assigned to the ICP to
indicate that the load is profiled using an
engineering profile.
There is no checking that there is an

associated engineering profile in the
Profile attribute.
If the load is not profiled through an

engineering profile, the daily average
unmetered load in kWh at the ICP must be
provided (this is a decimal number up to 3
decimal places).
Unmetered Load Details Char 50 A general-purpose alphanumeric value

– Trader used by the Trader to record supporting
information about the type and capacity of
unmetered load.
10
Version 22.24
Submission Type HHR Char 1 An indicator (Y/N) that half-hourly

submission information will be provided by
the Trader to the Reconciliation Manager
for the ICP.
Can only be set to Y if:
a) there is a metering component of type

HHR at the ICP applicable at the
Event Date; or
b) Where there is no applicable metering

event; or
c) The ICP contains a profile code that is

classified as half hourly (commences
with the letter “H”) except if the sole
half hourly code is “HHR” or “HSL”
Submission Type NHH Char 1 An indicator (Y/N) that non-half-hourly

submission information will be provided by
the Trader to the Reconciliation Manager
for the ICP.
Must be set to Y if Submission Type HHR

= N.
ANZSIC Char 7 A valid code from a list of Australian and

New Zealand Standard Industrial
Classification codes stored in the registry
reference tables with an additional code
“000000” to indicate a residential
consumer. See SD-020.
Not applicable to ICPs with SB

Reconciliation Types.
11
Version 22.24
1.4.8 Metering Attributes

(a) There are 4 levels of metering information: Metering Summary, Metering
Installation Information, Metering Component Information and Channel
Information.
(b) N.B. If the site is totally unmetered then no metering information will be
recorded for the ICP within the Metering event. Information about
unmetered load is maintained in the Trader event only.
1.4.9 Level 1 – Metering Summary Attributes
(a) This top level provides a snapshot of some of the metering attributes
detailed in the lower levels of metering information as well as the
Metering Equipment Provider Identifier of the participant responsible for
maintaining this information in the Registry. These are:
MEP Participant Char 4 This code identifies the Metering

Identifier Equipment Provider who maintains this
ICPs metering installation information in
the Registry. Metering Equipment
Provider Participant Identifiers are
assigned by Authority.
NB: In practice, Distributors and Traders

can be Metering Equipment Providers,
and not necessarily for ICPs they currently
own (i.e. Distributor or Trader Participant
Identifiers may not match the Metering
Equipment Provider Participant Identifier
for an ICP). In the case of a dual role, i.e.
where the Distributor or Trader is
responsible for the ICP in the Registry and
is also the Metering Equipment Provider,
there are additional processing
requirements with respect to notifications
(see section 3.7 on Notifications).
Highest Metering Numeric 1 The highest code of any of the Metering

Category Installation Categories recorded at lower
levels of this event. The Metering
Installation Category is a numerical code
indicating the type of voltage, current,
measuring transformers and maximum
permitted error of a metering component.
12
Version 22.24
The highest category of any of the

metering installation certification reports of
the ICP is recorded here. The code can
be 1 to 5 however a “9” will be assigned
where there are no ‘installed’* metering
components of type = meter. A “9”
indicates that all meters have been
removed however it is possible that other
types of components remain at the ICP.
Derived by the system from the greatest
value of any of the Highest Metering
Category codes recorded in the Level 2
information of this ICP.
HHR Flag Char 1 An indicator (Y/N) of the presence of a

Metering Installation Type of HHR on any
of the metering installations of the ICP.
Derived by the system.
NHH Flag Char 1 An indicator (Y/N) of the presence of a

Metering Installation Type of NHH on any
of the metering installations of the ICP.
PP Flag Char 1 An indicator (Y/N) of the presence of a

pre-pay metering device component
(Meter Type = PP) within any of the
metering installations of the ICP. Derived
by the system.
AMI Flag Char 1 An indicator (Y/N) of the presence of an

advanced infrastructure metering device
component (AMI Flag = Y) within any of
the metering installations of the ICP.
Meter Channel Count Numeric 3 A numerical value representing the total

number of channels, across all the
metering components that have a type =
M (meter), where their Settlement
Indicators are set to ‘Y’ and where the
meter has not been removed, at an ICP.
Meter Multiplier Flag Char 1 An indicator (Y/N) of the presence of a

Compensation Factor not equal to 1 for at
least one of the metering components that
13
Version 22.24
have a Metering Component Type = M

(meter) at an ICP. Derived by the system.
(b) It is possible to have more than one type of metering (NHH, HHR, PP)
installed (although an ICP can be unmetered) at an ICP. At least one
must be recorded against an ICP.
*N.B. Where information is derived from lower levels, components with a
Removal Date are ignored (assumed to be missing).
14
Version 22.24
1.4.10 Level 2 – Metering Installation Information Attributes

(a) An ICP may have multiple sites where metering is located. Each site is
identified by a unique Metering Installation Number.
Metering Installation Numeric 3 A user-input number that is unique to

Number that ICP identifier that identifies the
metering installation. (Sequential
number 1,2 etc)
Highest Metering Numeric 1 Derived by the system from level 3

Category information and is the highest Metering
Installation Category of the installation at
the ICP. 1 to 5 and 9. 9 is assigned
where there are no installed* metering
components of type = meter within the
installation.
Metering Installation Char 50 A 6 character code from the list of codes

Location Code (can be 1 to 6 characters) within the
Registry that identifies the location of the
metering installation and optionally,
concatenated with the New Zealand
Transverse Mercator 2000 (NZTM2000)
GPS co-ordinates of the metering
installation. The format of the GPS co-
ordinates is:
&NZTM:E<easting location>:N<northing
location>
Easting and Northing locations both

have a format of Numeric 7.3 where
leading and trailing zeros are not
mandatory ie can be missing.
Example:SQ&NZTM:E1234567.123:N54
321.95.
Where the GPS co-ordinates are

provided, both the easting and northing
co-ordinates are mandatory. A colon is
used as the field delimiter within the
GPS co-ordinates descriptor and there
must be no spaces or commas. Where
no GPS co-ordinates are provided only
the location code must be present e.g.
SQ.
15
Version 22.24
ATH Participant Char 4 The Participant Identifier of the

Identifier Approved Test House that certified the
metering installation.
Metering Installation Char 3 The certification type of the metering

Type installation, which may be either half
hour (‘HHR’) non -half hour (‘NHH’) or
none (‘NON’) whichever is identified
within the metering installation
certification report. Must be ‘NON’
where the number of components = 0.
Metering Installation Char 1 Type of certification - Interim (‘I) or Full

Certification Type (‘F).
Note: Interim certification can only be

used for an event date prior to 01 April
2016 unless the metering update is for
the removal of all metering components
of all interim certified metering
installations of an ICP.
Metering Installation DD/MM/YYYY The effective certification date identified

Certification Date within the metering installation
certification report.
Metering Installation DD/MM/YYYY The metering installation certification

Certification Expiry Date expiry date, identified within the metering
installation certification report, or the
date that metering installation
certification was cancelled.
Control Device Char 1 A confirmation indicator Y/N on whether

Certification Flag the control device used in the metering
installation is included in the metering
installation certification report.
Certification Variations Char 1 ‘X’ - An exemption under the Act for the
metering installation applies; or
‘A’ - The alternate measuring

transformer certification process is used;
or
‘N’ – None.
16
Version 22.24
Certification Variations DD/MM/YYYY The earliest expiry date of any of the

Expiry Date certification variations.
Certification Number Character 25 The certification number assigned to a

metering installation’s certification.
Maximum Interrogation Numeric 3 The maximum interrogation cycle of the

Cycle metering installation included in the
metering installation certification report,
in days.
Lease Price Code Char 6 If the Metering Equipment Provider

considers it relevant, an identifier that
may be used to indicate the price that
would apply to a lease for the use of the
*N.B. Where information is derived from lower levels, components with a

Removal Date are ignored (assumed to be missing).
17
Version 22.24
1.4.11 Level 3 - Metering Component Information Attributes

(a) At each installation or site within an ICP, information on each metering
component located there is recorded in the registry and each is identified
by the component’s own physical serial number or one assigned by the
MEP that makes it unique within the ICP.
Metering Component Char 25 A number that is unique to that ICP

Serial Number identifier, to identify the metering
component.
Metering Component Char 1 An identifier used to identify the type of

Type metering component selected from the
list of codes within the registry.
(M-meter, C-CT, V-VT, D-Data Storage

Device, L-Control Device).
Meter Type Char 3 An identifier (HHR/NHH/PP – for meters

only) of the type of meter.
AMI Flag Char 1 An indicator (Y/N) that the component

contains an advanced infrastructure
metering device.
Metering Installation Char 1 The metering category for the metering

Category installation included in the metering
installation certification report. (1 to 5).
Compensation Factor Numeric 6.3 Compensation factor for the metering

component. Where the Metering
Components Type is M (meter) the value
must be greater than zero.
Owner Char 6 A free text field to identify the owner of a

metering component which may be a
Participant Identifier if the owner is a
participant. If the Owner is a participant
then their valid 4 character Participant
Identifier is recorded otherwise a value
greater than 4 characters is required.
Removal Date DD/MM/YYYY The date when a metering component

was removed.
18
Version 22.24
1.4.12 Level – 4 Metering Channel Information Attributes

(a) The registry holds details of all channels of each metering component of
an ICP. Each channel is assigned a sequential number by the MEP that
makes it unique within the component.
Channel number Numeric 2 A unique number within the metering

component that identifies each data
channel within the metering component
e.g. 1, 2 etc. User-defined not system
assigned.
Number of Dials Numeric 2 The number of dials or digits that relate

to the data channel. (Between 4 and
12). Dials recording fractions of a unit
are excluded.
Register content code Char 6 A code that identifies the type of

information being recorded by the
channel e.g. winter, triple saver peak
etc. Selected from a list in the registry.
Register content codes are provided in

SD-020.
Period of availability Numeric 2 Minimum service hours per day that

supply is available for. (<=24).
Unit of Measurement Char 6 An identifier for the units recorded in a

channel e.g. kVA. Selected from a list in
the registry.
Energy Flow Direction Char 1 An identifier of whether the channel

records the import (injection from the
ICP into the Network) (“I”), or the export
(extraction from the Network to the ICP)
(“X”).
Accumulator Type Char 1 An identifier for either absolute (“A”) or

cumulative (“C”) recording with the
channel,
Settlement Indicator Char 1 An indicator (Y/N) that the channel must

be included within the Trader’s
submission information.
19
Version 22.24
Event Reading Numeric 12 A read of a meter or data storage

device. Optional, but mandatory if a
Removal Date is present in the
associated (parent) component level
information.
20
Version 22.24
1.4.13 Status Attributes

ICP Status Char 3 This code 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 the ICP is
no longer used. Second, once the ICP is
commissioned and a Trader has accepted
responsibility for the ICP, the Status
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:
999—new;
888—distributor;
000—ready;
001—inactive;
002—active; or
003—decommissioned.
Status Reason A two-character numeric code, required

when the Status is inactive or
decommissioned, which 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 current reasons associated with an

inactive Status are:
04—electrically disconnected vacant

property;
05—reconciled elsewhere;
21
Version 22.24
06— electrically disconnected ready for

decommissioning;
07— electrically disconnected remotely by

AMI meter;
08— electrically disconnected at pole

fuse;
09— electrically disconnected due to

meter disconnected;
10— electrically disconnected at meter

box fuse; and
11— electrically disconnected at meter

box switch;
12 – New connection in progress.
The above list of codes may change, but

only very infrequently.
1.4.14 Derived Information

In addition to the above stored attributes of an ICP, the Registry can display
information derived from a combination of stored attributes or from switch
transactions
C&I TOU Char 1 An indicator (Y/N) signifying the presence

of a metering component that is a
commercial and industrial time of use
meter, in any of the metering installations
of the ICP. This is indicated where a
metering component has:
a. an AMI flag = ‘N’; and
b. a Metering Component Type = ‘M’

or ‘D’; and
c. at least one register of that

metering component has a
Registry Content Code starting
with the number ‘7’ and no other
register of that metering
22
Version 22.24
component has a Register

Content Code starting with an
alpha character.
AMI non comm. Char 1 An indicator (Y/N) signifying the presence

of a metering component that is a non-
communicating AMI meter which is being
treated as a NHH meter, within any of the
metering installations on the ICP. This is
indicated where a metering component
has:
a. a Meter Type = ‘NHH’; and
b. an AMI flag = ‘N’; and
c. a Metering Component Type = ‘M’

or ‘D’; and
at least one register of that metering

component has a Registry Content Code
starting with an alpha character and no
other register of that metering component
has a Registry Content Code starting with
the number ‘7’
AMI comm. Char 1 An indicator (Y/N) signifying the presence

of a metering component that is a
communicating AMI meter within any of
the metering installations on the ICP
where a metering component has:
a. An AMI Flag = “Y” at the summary

level
Serial Numbers Char 100 Concatenation of all Metering Component

Serial Numbers with all their associated
Register Content Codes where applicable.
All values are comma separated.
Trader switch Char 50 Description of the state of a Traderswitch

in progress that identifies the stage of the
switch e.g. “from RETA to RETB, Switch
Withdrawal Request (NW)”.
23
Version 22.24
MEP switch Char 50 Description of the state of an MEP switch

in progress that identifies the stage of the
switch e.g. “META to METB, MEP
accepted nomination, awaiting Meter
Asset data”.
1.5 Types of ICP

1.5.1 The Code describes two types of ICP:
(a) Standard ICPs – the majority of ICPs. These follow the standard
lifecycle whereby a Distributor assigns an ICP Identifier to an ICP, a
Trader accepts responsibility for the ICP, an MEP loads the metering
information and the ICP is then able to be switched. The ICP
information is managed by Distributors, Traders and MEPs; and
(b) Distributor-only ICPs – these ICPs are not assigned to Traders.
Information about Distributor-only ICPs is provided and updated solely
by the Distributor. These ICPs are used for two purposes:
(i) to record information about the point of connection between an
embedded network or local network and its parent network
(maintained by the parent network Distributor); and
(ii) to record information about an ICP across which unmetered load is
shared, such as a sewerage pump or under-veranda lighting.
(This ICP records all ICPs across which the unmetered load is
shared.)
1.5.2 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 assigned to Standard ICPs only.
1.5.3 The following information is required to be provided in respect of each type of

ICP:
Standard ICPs
 ICP Identifier and all possible attributes.
N.B. Refer to the individual formats for the attributes.
24
Version 22.24
Distributor-only – embedded network metering installation

ICPs
 ICP identifier;
 ICP Address Event attributes;
 Network Participant Identifier;
 POC;
 Reconciliation Type Code;
 Dedicated NSP;
 Installation Type;
 Distributor Loss Category code; and
 Status.
Distributor-only – shared unmetered ICPs

 ICP Identifier;
 ICP Address Event attributes;
 Network Participant Identifier;
 POC;
 Reconciliation Type Code;
 Dedicated NSP;
 Unmetered Load Details – Distributor if applicable (and unless the unmetered load
is distributed unmetered load);
 Shared ICP List;
 Distributor Loss Category code; and
 Status.
1.6 Events
1.6.1 Events are the primary mechanism for handling changes to attributes.
1.6.2 In the first version of the registry, released in 1999, there was only one type of
ICP and it only had seven attributes: date; Trader; data administrator; Profile
type; Status; Status Reason; and NSP code. Whenever an attribute was
changed, a new record was created with a new date. The new value of the
25
Version 22.24
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.
1.6.3 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.
1.6.4 The User Reference is a general-purpose alphanumeric value available for

recording any extra information the user deems appropriate.
1.6.5 NB: The use of events is central to the current registry system. Information
about ICPs is structured as events, and events are the user interface construct
through which data is entered into the system and through which it is
maintained.
1.7 Event types

1.7.1 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 Trader and Metering events.
1.7.2 Each event type groups ICP attributes as described earlier in section 1.4
Attributes of an ICP. In addition to their specific attributes, each event also has
the general Event Date and User Reference values.
Event Date DD/MM/YYYY The Event Date defines the date from
which the attribute values of the event
applies.
User Reference Char 32 A general-purpose alphanumeric value

available for recording any extra
information the user deems appropriate
(a) Event type – Network
26
Version 22.24
This event type groups together the attributes relating to network

connection details and the network owner (Distributor).
(b) Event type – Pricing

This event type groups together the attributes relating to Distributor line
charges and loss factors.
(c) Event type – Address

Refer to the attribute section for details on the minimum requirements of
a valid Address.
(d) Event type –Trader

This event type groups together the attributes used for reconciliation and
for identifying the current Trader.
(e) Event type – Metering

This event type groups together the attributes relating to the physical
meters at the ICP site and for identifying the Metering Equipment
Provider.
(f) Event type – Status

This event type groups together the attributes relating to the pre-
commissioning stage and electrically connected Status of the ICP (see
ICP Status lifecycle)
1.8 Event type responsibilities

(a) Only Distributors may create, update and reverse Network, Pricing,
Address and Status events (decommissioning only).
(g) Only Traders may create, update and reverse Trader events.
(h) Distributors and Traders jointly manage the Status event. Distributors
are responsible for the Status in the pre-commissioning stage and when
decommissioning the ICP. Traders are responsible for maintaining the
electrically connected Status of the ICP – inactive and active.
(i) Metering Equipment Providers (MEPS) are solely responsible for
maintaining the Metering events and are able to receive notifications of
the changes to metering information and Trader switches.
1.9 Event processing

1.9.1 The following business rules govern the processing of all events.
27
Version 22.24
(a) Events must be made explicit to users at the user interface.

(b) 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.
(c) Only the participant responsible for the creation of an event may update
or reverse it.
(d) Whenever a new value of an attribute is assigned, a new event must be
created to incorporate the change.
(e) 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.
(f) 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.
(g) 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.
(h) 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 contains the currently applicable
information. The information in the old event is no longer current.
(i) When an existing event is reversed, it must only be logically deleted, not
physically removed. It must be indicated as reversed.
(j) Replaced and reversed events must be retained for history and audit
trail purposes.
(k) 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. A new event must be created.
(l) A complete event history must be recoverable for each ICP, including
reversed and replaced events.
(m) When a new event is created, the following information must be
recorded for audit purposes:
(i) the user ID of the person creating the event;
(ii) the date and time the event was created;
(iii) the method of creation, ie online or file; and
(iv) the filename if the method was ‘file’.
28
Version 22.24
(n) When an existing event is reversed, the following information must be

(i) the user ID of the person reversing the event;
(ii) the date and time of reversal;
(iii) the method of reversal, ie online or file; and
(iv) the filename if the method was ‘file’.
(o) When an existing event is replaced, the following information must be
(i) the user ID of the person replacing the event;
(ii) the date and time of the replacement;
(iii) the identity of the replacement event;
(iv) the method of replacement, ie online or file; and
(v) the filename if the method was ‘file’.
(p) 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 Trader on
date d1 and lost to another Trader on date d2, the Trader may make
changes only on or after d1 and before d2.
(q) There are three possible responsibility relationships for an ICP:
Distributor; Trader; and Metering Equipment Provider. Responsibility
changes occur on the date of the event, in which the value of the
corresponding attribute changes, i.e. Network Participant Identifier,
Trader Participant Identifier or MEP Participant Identifier.
(r) 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 accepting of responsibility for an ICP by a Trader. Also,
Reconciliation Types cannot be changed when that change would alter
the type of ICP.
(s) An event may not be reversed if that reversal would invalidate a later
event.
(t) Events must be processed in the order in which they arrive.
(u) Every insertion, change and reversal of an event must be acknowledged
to the responsible participant.
(v) Every participant affected by the insertion, change or reversal of an
event must be notified of the fact.
(w) System is to prevent the insertion of duplicate events.
29
Version 22.24
1.9.2 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/non-replaced 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.
1.10 Acknowledgements
1.10.1 The Code requires that the registry provide confirmation to a participant when
the registry receives updated information about an ICP within four hours of
input of the change (clause 11.21).
1.10.2 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.
1.10.3 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.
1.10.4 In both cases, users must be able to see online whether their changes have
been confirmed (acknowledged). The details shown must include:
(a) date and time stamp;

(b) participant (sent to); and
(c) file name.
1.11 Notifications
1.11.1 The Code requires that, whenever information about an ICP changes, the
registry must send notifications of the change to all affected parties on the
same day that the information is received (clause 11.29).
1.11.2 Since one or more of the 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
30
Version 22.24
notifications can be quite complex and results can differ depending on the
order in which the processing is done.
1.11.3 In general, the “affected parties” requiring notifications as at an event date are:
(a) the responsible Trader, and
(b) if there is a Trader switch in progress (whether new or a withdrawal), the

other Trader, and
(c) the responsible MEP, and
(d) if there is an MEP switch in progress, the Proposed MEP, and
(e) the responsible Distributor, and
(f) if the ICP is in the pre-commissioning phase, the Proposed Trader, and
(g) for metering events, the Approved Test House (ATH) for each metering
installation, and
(h) for metering events, the Metering Equipment Owner (MEO) of each
metering component where the MEO has a participant identifier.
1.11.4 All “affected parties” need to be informed:
(a) when their period of responsibility commences and ceases; and

(b) of changes (inserts, replacements and reversals) to information about an
ICP during their period of responsibility or during the period they are a
party to a switch (Trader or MEP).
1.11.5 Users must be able to see online whether notifications have been sent about
an event change. The details shown must include:
(a) date and time stamp;

(b) participant (sent to); and
(c) file name.
Filtering-up of historical changes

1.11.6 An historical change is one that occurs before a current ICP event. When an
historical change occurs, notifications must be generated for all participants
that were responsible for 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.
31
Version 22.24
1.11.7 For example, if a Metering event is inserted with an Event Date of 01/03/2004
before a later Metering event on 01/05/2004 then all Traders, Distributors and
Metering Equipment Providers who were responsible for the ICP during the
period 01/03/2004 to 30/4/2004 must be notified of the change.
1.11.8 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
1.11.9 The Code (clauses 11.29 and 22(d) of Schedule 11.3) defines what
notifications are required (mandatory) when there are changes to events or
when messages are required to be transmitted to multiple parties, and, to
whom they are sent as follows:
Event type Distributor Trader Metering Approved Metering

or notice Equipment Test House Equipment
Provider Owner
Address Mandatory Mandatory Optional N/A N/A
ICP Status Mandatory Mandatory Mandatory N/A N/A
Network Mandatory Mandatory Optional N/A N/A
Metering Mandatory Mandatory Mandatory Optional Optional
Pricing Mandatory Optional Optional N/A N/A
Trader Optional Mandatory Mandatory N/A N/A
Switch1 Mandatory Mandatory Mandatory N/A N/A
CS Mandatory Mandatory Mandatory N/A N/A
RR Optional Mandatory Optional N/A N/A
MN Mandatory Mandatory Mandatory N/A N/A
AW Not applicable Mandatory Mandatory N/A N/A

1.11.10 Where mandatory is shown, the associated ‘affected party’ must be sent an
appropriate notification. Where optional is shown, the participant must be able
to choose whether to receive notifications of events of that type or not.
1.11.11 It should be noted that participants may have more than one role (see table
1.14.18 for permitted role combinations), in which case they must be able to
1 The event referred to here is the completion of a customer switch from one Trader to another Trader. The
system must be able to distinguish between this Trader event and its other occurrences.
32
Version 22.24
indicate what notifications they receive in each role. Duplicate notifications

must not be sent to participants with dual roles on a single ICP.
1.12 Switching protocols
Trader switching
1.12.1 Traders use the switching protocol whenever a consumer chooses to change
the participant supplying them with electricity. It consists of a sequence of
messages sent between Traders. The registry co-ordinates switches.
1.12.2 Traders must provide information about a switch to the registry, not directly to
the other Trader. It is the responsibility of the registry to pass that information
to the other Trader and to keep track of the progress of the switch as it passes
through each stage. The registry must acknowledge each message received,
store it against the ICP and, once a switch has been successfully completed, it
must update the ICP by generating the appropriate events, and send the
proper notifications. A Trader event must always be generated to indicate that
the Trader responsible for the ICP has changed, but there may also be a
Metering event and/or a Status event if the attributes of those event types
have been changed as part of the switch.
1.12.3 There is an additional requirement for Distributors and Metering Equipment

Providers to also receive CS and RR switch messages.
1.12.4 The Trader switching messages are:
Code Name Purpose
NT Notification of transfer Initiate switch.
AN Acknowledgement of notice Accept/decline switch. NB: If declined,

this is just a warning message. It does
not reverse the switch.
TN* Completed Switch Transfer Complete switch for non-half-hour

notice non-half-hour metering or unmetered ICPs.
TT* Transfer notice half-hour Complete switch for half-hour metering.
NW Notice of withdrawal Request withdrawal of a switch.

request
AW Acknowledgement of Accept or decline withdrawal request.

withdrawal request
NC* Request switch read Request of a switch read change and

change supply the revised meter readings or
permanent estimates.
33
Version 22.24
Code Name Purpose
AC Acknowledge switch read Accept or decline switch read change.

change
CS Complete Switch Complete switch for all meter types
RR Replacement Reading Replacement readings provided for a

completed switch.
*Discontinued. History is still available to view and report on.
Sequence Message Sender Receiver
1. ICP Trader switch NT Gaining Trader Losing Trader
AN (optional) Losing Trader Gaining Trader
CS Gaining Trader Other Trader

for switch type
of HH,
otherwise
Losing Trader
2. Withdrawal of switch NW Either gaining Other Trader

or losing
Trader
AW Receiver of Sender of the

previous NW previous NW
3. Change switch read RR Gaining Trader Losing Trader
AC Receiver of Sender of the

previous RR previous RR
1.12.5 Once an NT has been sent, either Traders may elect to withdraw the switch at
any time (ie cancel the switch), until the expiry of 2 calendar months after the
Event Date of the switch (clause 17 of Schedule 11.3). When a switch is
withdrawn after the switch is completed, the registry must reverse the Trader
event and any other events that it generated, together with any events that the
losing Trader had inserted, and which now lie within the gaining Trader’s
period of responsibility.
MEP switching
1.12.6 Switching from the current MEP to a new MEP goes through 3 distinct stages:
34
Version 22.24
(a). Proposal – this is when a Trader enters an MEPs participant code in the
Proposed MEP attribute of a Trader event.
(b). Acceptance of an arrangement – this is once an MEP sends an MN acceptance

notice to the Registry. This is the acceptance of the contractual arrangement
referred to in Part 10.22(1)(a)(ii) of the Code.
(c). Assumption of responsibility – this is once the MEP who has accepted the
arrangement for an ICP “assumes” responsibility (ie. becomes responsible) for
the metering installation by inputting their Metering event information into the
Registry (Part 10.21(1) of the Code).
1.12.7 Traders are responsible for notifying the registry of the responsible MEP for an
ICP. This is initiated in the registry by the Trader setting the Proposed MEP
attribute in the Trader event of an ICP for which they are the responsible
Trader.
1.12.8 As part of the normal event change process, a notification is generated to

affected parties, including the Proposed MEP. The notification will appear in
participant’s overnight (standard) notification file. The Switch Status attribute
identifies that an MEP switch is in progress by being set to either an ‘M’ or ‘B’.
An ‘M’ indicates that an MEP switch is in progress. A ‘B’ indicates that both a
Trader Switch and an MEP switch are in progress.
1.12.9 The MEP has then 10 business days in which to accept the proposal by
sending an MN notice to the registry. The MN notice will be delivered by the
registry to the Trader (both Traders where a Trader switch is in progress), the
Distributor and to the old MEP. There is no time limit for the delivery of an MN
decline as this is optional in the Code.
1.12.10 If the MN notice is for a declinature or where an MEP does not respond with
any MN notice, the old MEP retains responsibility. The Trader can then
propose another MEP, at any time except when there is a Trader switch in
progress, by setting the Proposed MEP attribute again which triggers a new
MEP switch cycle.
1.12.11 If the MN notice is for an acceptance, the registry will permit the new MEP to
add Metering events for this ICP for an Event Date on or after the Event Date
of the Trader event that initiated this MEP switch, or in the case of the first
MEP assignment for a new ICP, on or after the Event Date of the earliest
Status event change to the ‘Ready’ state of the ICP.
1.12.12 The MEPs period of responsibility commences from the Event Date of the first
Metering event input by an MEP until another MEP inputs metering event
information, or until the present day.
35
Version 22.24
1.12.13 MEP switching is only permitted for Event Dates on or after the
commencement of the period of responsibility of the current MEP or where
there is no MEP assigned. An MEP switch may only be inserted historically
upon approval from the Authority (refer process MM-040).
1.12.14 An MEP may perform an historical MEP switch provided approval has been
received from the Authority. Once approved the switch process is executed by
the Registry Manager as it is not considered a business as usual occurrence.
It is used only to correct the result of a breach of the Code where an MEP for
an ICP has been unable to provide metering information to the Registry.
Switching parameters
1.12.15 Traders must be able to choose the time intervals and the grouping method for
the receipt of switching messages. They must be able to elect to receive
switch files at specific times during the day, eg 0800, 1100, 1500 and 1800
hours, or choose to have their files delivered as soon as the registry has
processed them.
1.12.16 The system must gather all switch messages of the same type into separate
files and also provide users with the option of further splitting those files by
Trader. For example, all the NT messages relating to ICPs lost to Trader A
would be in one file, and all NT messages relating to ICPs lost to Trader B
would be in another file.
1.12.17 It is sufficient for Distributors and Metering Equipment Providers to receive

their MN, CS and RR switching messages daily in one file overnight.
Switching file naming standard

1.12.18 Filenames should have the form: <File dentifier>CCYYMMDDHHMMSSxxx.txt
format where:
Component Description
<File Identifier> A code identifying the file type (usually the same as the file type
in the file header) and therefore the format, eg NT
CCYYMMDD Century, year, month and day the file was created, eg 20040722
HHMMSS Time of file creation (24-hour clock), eg 192436
xxx An optional number added if required to make the filename

unique.
Filenames must be unique hence the timestamp in the filename.

If still not unique the xxx part is used.
N.B. No spaces must be included in the filename.
36
Version 22.24
Points to note:
 Filenames must be unique hence the timestamp in the filename. If

still not unique the xxx part is used.
 No spaces must be included in the filename.
 See Appendix 4 for details on how the Registry processes files.
 Files input by participants are not validated to conform to the above

file naming standard.
37
Version 22.24
1.13 ICP Status lifecycle

1.13.1 The lifecycle of an ICP is managed by updating the Status attribute of the ICP,
which is part of the Status event type. There is a different lifecycle for the two
types of ICPs (Distributor-only and Standard ICPs).
Figure 2: ICP lifecycle
ICP # issued
New
Ready Distributor
Active Inactive
Decommissione
d
38
Version 22.24
Standard ICP business rules

1.13.2 Standard ICP business rules are listed below:
(a) In order for an ICP to be created, the Event Date, ICP Identifier, Network
Participant Identifier and Address attributes must have values.
(b) The ICP Identifier must be unique.
(c) Once assigned, the Event Date, Network Participant Identifier and
Address attributes cannot be cleared but can be updated.
(d) When an ICP is created with the minimum attributes, it must be given
the Status new by the system.
(e) The ICP can be created in the ready state, without first being in the new
state, provided there is sufficient information available and the
Reconciliation Type is not LE or SI.
(f) Once an ICP is created, the system must allow Distributors and Traders
to update information about the ICP in the registry.
(g) An ICP created in error can be decommissioned by the Distributor who
created it but only if it has the Status new. The Distributor must give a
reason for the decommissioning.
(h) When the electrical installation associated with an ICP is ready for
connecting to the electricity supply, a Distributor has identified the
Trader that has taken responsibility for the ICP, and the ICP has a single
Distributor Price Category Code, the system must change the Status of
the ICP to ready. In the registry, this means that values have been
added for the Network Participant Identifier, POC, Reconciliation Type
(not LE or SI), Installation Type, Dedicated NSP, Proposed Trader),
Distributor Price Category Code and Distributor Loss Category Code.
(i) An ICP can move from ready back to new, on the removal of any
required fields or reversal of the event that made the ICP ready.
(j) If an ICP has the Status of new or ready for 24 calendar months or
more, the Distributor must ask the Trader who intends to trade at the
ICP whether the ICP should continue to have that Status, and the
Distributor must decommission the ICP if the Trader advises the ICP
should not continue to have that Status.
(k) If a Distributor has created an ICP in error, the ICP cannot be deleted.
The ICP Status must be set to decommissioned. The ICP must be in the
new status before it is changed to the decommissioned Status.
(l) A Trader can only accept responsibility for ICPs that are in the ready
state. From this point on, a Trader can designate the Status of the ICP
39
Version 22.24
as active or inactive according to whether the ICP is electrically

connected (ie whether electricity can flow at the ICP).
(m) Having accepted responsibility for an ICP through an initial assignment,
a Trader must provide the registry with the reconciliation, metering,
Status, and other information required by clause 9 of Schedule 11.1 of
the Code.
(n) If a Trader’s acceptance of responsibility for an ICP that was gained
through initial assignment is reversed, the Status of the ICP must be
reset to ready.
(o) Once a Trader has accepted responsibility for an ICP, the Status cannot
be set to new or ready.
(p) A Distributor can only decommission an ICP assigned to a Trader if the
Trader has set the Status to inactive with a Status Reason of electrically
disconnected ready for decommissioning (‘06’). Decommissioning
indicates that that the ICP is permanently removed from future switching
and Trader events. Decommissioning occurs when electrical installations
associated with the ICP are removed, there is a change in the allocation
of electrical loads between ICP with the effect of making the ICP
obsolete, or, in the case of a Distributor-only ICP for an embedded
network, the embedded network no longer exists.
(q) Once created on the registry, an ICP identifier for an ICP cannot be
changed.
Standard ICP Status transitions

1.13.3 The table below details the allowable ICP Status transitions for a Standard
ICP.
Transition Comments
New Status set by system when the Distributor provides the ICP
Identifier, Network Participant Identifier and Address attributes.
Ready Status set by system when the Distributor provides the ICP
Identifier, Network Participant Identifier, Address, POC,
Distributor Price Category Code, Reconciliation Type Code (not
LE or SI), Installation Type, Dedicated NSP, Proposed Trader (if
known) and Distributor Loss Category Code.
New to ready Status set by system when the Distributor adds a POC,
Distributor Price Category Code, Reconciliation Type code (not
LE or SI), Installation Type, Dedicated NSP, Proposed Trader (if
known) and Distributor Loss Category Codes.
40
Version 22.24
Transition Comments
Ready to new Status set by system when the Distributor removes the POC,
Distributor Price Category Code, Reconciliation Type code,
metering Installation Type, Dedicated NSP, Proposed Trader (if
known) or Distributor Loss Category Code from the ICP, or
reverses the event that set the Status from new to ready.
Ready to active Status set by Trader taking responsibility for the ICP at initial
assignment when reconciliation is required for the ICP.
Ready to inactive Status set by the Trader taking responsibility for the ICP at initial
assignment when reconciliation is not yet required for the ICP.
Active | inactive to Status set by system when the initial Trader reverses the initial
ready assignment.
Inactive to active Status set by Trader when reconciliation is required for the ICP.
Active to inactive Status set by the Trader when reconciliation is no longer

required for the ICP.
Inactive to Status set by the Distributor when the ICP has been
decommissioned disconnected from the network. Disallowed unless the Trader
updated the Status Reason to electrically disconnected ready for
decommissioning (‘06’) or if there is a switch in progress for the
ICP.
Decommissioned to Status reversed by the Distributor to correct a decommissioning

inactive error.
New to Status set by the Distributor during the pre-commissioning phase

decommissioned if the ICP was created in error.
Decommissioned to Status reversed by the Distributor during the pre-commissioning

new phase to correct a previous error.
Distributor-only ICP business rules

1.13.4 Distributor-only ICP business rule are listed below:
(a) In order for an ICP to be created, the Event Date, ICP Identifier, Network
Participant Identifier and Address attributes must have values.
(b) The ICP Identifier must be unique.
(c) Once assigned, the Event Date, Network Participant Identifier and
Address attributes cannot be cleared but can be updated.
(d) When an ICP is created with the minimum attributes, it must be given
the Status new by the system.
41
Version 22.24
(e) The ICP can be created in the distributor state, without first being in the
new state, provided there is sufficient information available and the
Reconciliation Type is LE or SI.
(f) Once an ICP is created, the system must allow Distributors to update
information about the ICP in the registry.
(g) The Distributor who creates the ICP can decommission the ICP if the
ICP was created in error. The Distributor must give a reason for the
decommissioning.
(h) When information has been added in respect of the Network Participant
Identifier, POC, Reconciliation Type, Installation Type, Dedicated NSP
and Distributor Loss Category Code, the system must change the Status
of the ICP to distributor.
(i) An ICP can move from distributor back to new Status, on the removal of
any required fields or reversal of the event that made the ICP Distributor-
only.
(j) If the Distributor has created the ICP in error it cannot be deleted. The
ICP Status must be set to decommissioned.
Distributor-only ICP Status transitions

1.13.5 The table below details the allowable Status transitions for a Distributor-only
ICP.
Transition Comments
New Status set by system when the Distributor provides the

ICP Identifier, Network Participant Identifier and Address
Distributor Status set by system when the Distributor provides the

ICP Identifier, Network Participant Identifier, Address,
POC, Reconciliation Type code (LE or SI), Installation
Type, Dedicated NSP, and Distributor Loss Category
Code.
New to distributor Status set by system when the Distributor adds a POC,
Reconciliation Type code (LE or SI), Installation Type,
Dedicated NSP and Distributor Loss Category Code.
Distributor to new Status set by system when the Distributor removes the
POC, Reconciliation Type code, Installation Type,
Dedicated NSP or Distributor Loss Category Code from
the ICP, or reverses the event that set the Status from
new to distributor.
42
Version 22.24
Transition Comments
Distributor to Status set by the Distributor when the ICP has been
decommissioned disconnected from the network
Decommissioned to Status reversed by the Distributor to correct a

distributor decommissioning error
New to decommissioned Status set by the Distributor during the pre-

commissioning phase if the ICP was created in error
Decommissioned to new Status reversed by the Distributor during the pre-

commissioning phase to correct a previous error
1.14 Participants and registry roles

1.14.1 A number of participants require access to the registry to meet their Code
obligations. The Authority
(a) manages the process by which participants are registered
(b) allocates identifiers to Participants and non-participant registry users
(c) allocates access to the registry in accordance with the registry access
policy available at http://www.ea.govt.nz/dmsdocument/16031
1.14.2 The different roles and the individual registry responsibilities and requirements
of each role are listed below.
Participant registry user role configuration

1.14.3 Each Participant registry user role can be assigned for a period defined by a
start date and an end date (or blank indicating an open-ended period).
1.14.4 A Participant may perform the same role for different, non overlapping periods.
1.14.5 It is not possible for a Participant to perform both Distributor and Trader roles
with the same participant identifier, even if the role periods do not overlap. A
Participant however may perform an MEP role in conjunction with either a
Trader or Distributor role.
1.14.6 The start date for a role cannot be changed once a Participant has
responsibility for ICPs.
1.14.7 The end date may only be set to a future date, or to null (open ended)
Non-participant registry user role configuration

1.14.8 Each non-participant registry user can be assigned for a period defined by a
43
Version 22.24
1.14.9 A non-participant registry user can:
(a) carry out searches using the search criteria to locate ICP identifiers
(b) view ICPs and order reports where the ICP identifiers is known.
1.14.10 The start date for a non-participant registry user role cannot be changed
1.14.11 The end date may only be set to a future date, or to null (open ended)
Third Party Provider user role configuration

1.14.12 Each non-participant registry user can be assigned for a period defined by a
1.14.13 A Third Party Provider participant registry user can:
(a) Access the EIEP transfer hub using SFTP
(b) Interact (via the SFTP EIEP transfer hub) with Participants currently or
historically fulfilling the Trader role.
(c) Interact (via the SFTP EIEP transfer hub) with Participants fulfilling the
Distributor or Meter Equipment Provider roles, if authorised by the
Authority.
(d) Access the Registry browser, web services functions and the standard
SFTP interfaces, if authorised by the Authority.
Trader Default start date

1.14.14 On direction from the Authority, a Trader may be placed in a Trader Default
situation by setting of a Trader Default start date.
1.14.15 A Trader Default start date may be changed.
1.14.16 If a Trader Default start date is removed, all ICP Tender Blocks and Trader
tenders for those blocks (if created) are removed.
1.14.17 Between active dates a Participant can:
 Maintain ICP data according to the role
 Gain an ICP via a switch if they are
o fulfilling a Trader role on the switch Transfer date, and
o are not in a Trader Default situation
44
Version 22.24
1.14.18 The following role combinations are permitted:
Network Retailer Neither MEP ATH RM Clearing System Complaint Admin Authority Third Party Metering
(read Manager Operator Commission Provider Equipment
only) Owner
Network n/a N N Y Y N N N N N N N Y
Retailer N n/a N Y Y N N N N N N N Y
Neither N N n/a N N N N N N N N N N
(read only)
MEP Y Y N n/a Y N N N N N N N Y
ATH Y Y N Y n/a N N N N N N N Y
RM N N N N N n/a N N N N N N N
Clearing N N N N N N n/a N N N N N N
Manager
System N N N N N N N n/a N N N N N
Operator
Complaint N N N N N N N N n/a N N N N
Commissi
on
Admin N N N N N N N N N n/a N N N
Authority N N N N N N N N N N n/a N N
Third N N N N N N N N N N N n/a N
Party
Provider
45
Version 22.24
Metering Y Y N Y Y N N N N N N N n/a
Equipment
Owner
46
Version 22.24
Distributors
1.14.19 Distributors are responsible for creating ICP Identifiers for new ICPs and
putting information about the ICP in the registry, managing the pre-
commissioning process, decommissioning ICPs, and updating information
about the ICPs’ Network, Address and Distributor pricing. Distributors use the
registry to keep track of the Traders using their network in order to bill them
correctly. They need to be able to:
(a) create ICP Identifiers for new ICPs;

(b) update network connection information;
(c) update Distributor pricing information;
(d) update Address information;
(e) check metering installation details;
(f) check reconciliation information (current Trader);
(g) check unmetered load information;
(h) check Status information;
(i) locate an ICP using an address search;
(j) record when an ICP has been decommissioned;
(k) check their acknowledgements from the registry confirming whether
information they provided to the registry was processed successfully or
not;
(l) extract details of all ICPs currently recorded as being owned by the
Distributor;
(m) extract details of all ICPs that were owned by the Distributor during a
period which were also owned by a specific Trader. The information is
required to calculate line charges payable by Traders (he calculation is
performed outside the registry);
(n) view and extract a history of changes, including audit details, made to
specific ICPs during a period;
(o) extract details of all metering installation information on their network;
(p) check notifications of changes to ICP information made by Traders;
(q) check notifications of switches indicating a change of Trader;
(r) receive CS and RR switch transaction notifications;
(s) check if they have breached any information requirements specified in
the Code;
47
Version 22.24
(t) check for any meter certification dates that are due to expire with the
next 2 months;
(u) view and download the latest NSP mapping table details;
(v) maintain, download and view their pricing and loss categories; and
(w) manage the logons, access restrictions and passwords of their own
users of the registry.
Traders
1.14.20 Traders are responsible for the maintenance of Trader and Status information.
Traders use the registry to keep track of the ICP for which they have accepted
responsibility and to process switches. Traders need to be able to:
(a) locate an ICP using an address search facility;

(b) update unmetered load details;
(c) update reconciliation information (Profiles);
(d) update Status information;
(e) check metering installation information;
(f) check network connection information;
(g) check Distributor pricing information;
(h) check Address information;
(i) check their acknowledgements from the registry confirming information
they provided to the registry was processed successfully or not;
(j) extract details of all ICPs that they are recorded as having accepted
responsibility for;
(k) extract details of all ICPs that they were responsible for during a period;
(l) extract details of all metering installation information at ICPs where they
are the Trader;
(m) receive monthly reports used for reconciliation purposes – ICP days
report, HHR ICP list and loss factors report;
specific ICPs over a period;
(o) check notifications of changes to ICP information made by Distributors
relating to ICPs they are recorded as having accepted responsibility for;
48
Version 22.24
(p) send and receive switch requests, acknowledgements, transfer notices,

withdrawal requests, withdrawal acknowledgements, switch read
requests and switch read acknowledgements;
(q) check when switching events are due to be sent to the registry for
switches that are yet to be completed;
(r) check if they have breached any information requirements specified in
the Code;
(s) check for any meter certification dates that are due to expire with the
next 2 months;
(t) view and download the latest NSP mapping table details;
(u) view and download pricing and loss categories per Distributor; and
(v) manage the logons, access restrictions and passwords of their own
(w) Check for proposed MEP switches that have not been responded to with
an MN message.
Metering Equipment Providers

1.14.21 Metering Equipment Providers are responsible for maintaining an ICP’s
metering installation information from the Event Date of their first population of
metering event data until the Event Date of the next MEPs first population of
their metering event data, if there is one. MEPs need to be able to:

(b) check and maintain metering installation details online and by file;
(c) check Trader information;
(d) check unmetered load details;
(e) check Status information;
(i) extract details of all ICPs that they are currently recorded as being the
responsible MEP;
(j) extract details of all metering installation information at ICPs where they
are the responsible MEP;
(k) check for any meter certification dates that are due to expire within the
next 2 months;
49
Version 22.24
(l) check if there have been any breaches, by their company, of any
metering maintenance time limits as specified by the Code;
(m) check if there have been any breaches, by their company, of any notice
delivery time limits as specified by the Code;
specific ICPs during a period;
(o) check notifications of changes to ICP information made by Distributors
and Traders to ICPs where they are the responsible MEP;
(p) receive notifications of loss of MEP responsibility;
(q) submit MEP responsibility notices via the registry when a Trader
proposes that they take responsibility for an ICP;
(r) receive CS and RR switch transaction notifications; and
(s) manage the logons, access restrictions and passwords of their own
(t) Check for proposed MEP switches that have not been responded to with
an MN message.
Electricity Authority
1.14.22 The Authority requires access to ICP information to check the accuracy of the
information and participants’ compliance with the Code. It needs to be able to:

(b) check metering installation details;
(c) check unmetered load details;
(d) check Trader information (Trader and Profile information);
(e) check Status information;
(i) check if there have been any breaches of any switching or event
maintenance timeframes set out in the Code. The event maintenance
compliance report is required to be delivered to the market administrator
by 1600 hours on the first business day of each calendar month;
(j) extract details of all ICPs currently recorded as being owned by or the
responsibility of a particular participant;
50
Version 22.24
(k) extract details of all ICPs that were owned by or the responsibility of a
participant during a period;
(l) view and extract a history of changes made to specific ICPs over any
given period;
(m) view and download the latest NSP mapping table details;
(n) check for any meter certification dates that are due to expire with the
next 2 months;
(o) view and download pricing and loss categories per Distributor; and
(p) manage the logons, access restrictions and passwords of its own users
of the registry.
Reconciliation Manager
1.14.23 It is the responsibility of the Reconciliation Manager to obtain information from
the registry for use in the reconciliation process and to maintain and publish
the NSP mapping table used in the registry. It is each Distributor's
responsibility to notify the Reconciliation Manager of changes to its NSPs and
associated information such as balancing areas.
1.14.24 Clause 30(2) of Schedule 11.1 of the Code requires the publication of an
updated schedule of all NSP identifiers and any supporting information within
1 business day of any change being notified to the Reconciliation Manager.
1.14.25 The Reconciliation Manager therefore needs to be able to:
(a) receive monthly reports – ICP days report, HHR ICP list, loss factors
report and the latest NSP mapping table details;
(b) have a facility to receive and update NSP information provided under
Part 11 of the Code;
(c) have an online viewing and download facility of the NSP mapping table
information to be provided by the registry for all registry users;
(d) check if it has breached any requirements specified in the Code; and
(e) view and download pricing and loss categories per Distributor.
Clearing manager, system operator, and Reconciliation

Manager
1.14.26 If requested by the clearing manager, system operator, or Reconciliation
Manager, the registry is required to deliver an active NSPs report to the by
51
Version 22.24
1600 hours on the first business day the calendar month following the
calendar month in which the request was made.
1.14.27 The system operator may request a report setting out every switch made, the
effect of which is that a Trader has commenced trading at an NSP or a Trader
has ceased trading at an NSP.
Registry Manager
1.14.28 The registry manager is required to maintain the static tables that are part of
the registry system, such as the profiles of Traders, Distributors, and Metering
Equipment Providers.
1.15 User interfaces

1.15.1 The registry is an internet-based system with two main user interfaces to the
system: an online interface for single updates; and a batch interface for
multiple updates and reports. The functionality of both interfaces is identical
unless otherwise stated.
1.15.2 There is a new interface mechanism being introduced to provide access to

ICP information via Web Services however the functionality is limited (see
section 1.18.
Current online interface

1.15.3 The current online interface is via a standard web browser or, if preferred by
the participant, by means of a proprietary web client application available from
the present registry supplier.
Current batch interface

1.15.4 Currently, the batch interface consists of CSV formatted files sent to and from
the registry via SFTP. The registry maintains SFTP directories for every
participant from which it receives input files and to which it delivers output
files. It is up to the user to access these files and transfer them to their own
systems.
52
Version 22.24
The Authority maintains its own SFTP server and may request the Registry to transfer a
copy to their SFTP server, any transfers are in addition to delivery to the Registry SFTP
server
1.15.5 The files currently sent to the registry by users are:
(a) ICP event maintenance files;

(b) report requests; and
(c) switching protocol messages.
1.15.6 The files currently received by users from the registry are:
(a) acknowledgements of event updates (as a result of the processing of ICP event
maintenance files and online updates);
(b) notifications of updates;
(c) switching protocol messages; and
(d) reports.
File naming convention

1.15.7 There is a file naming convention employed by users sending report and maintenance
requests to the registry when using the batch interface. The registry uses a file naming
convention when delivering files to users. These conventions are used by users’
automation systems to identify the types of information the files contain and the
processing date/time. Any new file naming convention must ensure files have unique
names and are delivered to the correct party.
Batch file headers

1.15.8 Currently, the first record in every file sent to and received from the registry is a comma
separated ‘header’ record which identifies the type of information the file contains plus
such information as the number of detail records, the sender, the date/time sent and
reference information.
1.15.9 Any Data Input and Data Output formats detailed in this document are for each detail row
of a CSV formatted (batch) file and where each attribute is comma separated. The online
input forms will contain the same business attributes and apply the same validation
however the user interface is different and more user friendly.
1.15.10 Refer to Appendix 4 for batch file Header specification.
53
Version 22.24
Batch selection criteria

1.15.11 The current process used to provide selection criteria for report requests is to
list the selection criteria immediately after the ‘header’ in the report request file
using a specified format.
Back-office systems
1.15.12 It should be noted that currently all the back-office automation systems used
by participants have been developed around the above architecture,
conventions and file structures. There are no direct system-to-system
interfaces at present other than the Web Services facility (see 1.18).
Errors
1.15.13 When errors are reported to users by the system, the information provided is
either sufficiently detailed for users to be able to identify and rectify the
problem easily (online) or an error code is provided (batch). All error codes,
error descriptions are published and kept up to date.
1.16 Security
1.16.1 Access to the registry is restricted to Authority-approved parties. The approval
process is co-ordinated by the Authority and communicated to the registry,
Reconciliation Manager and Clearing Manager. Participants are assigned a
unique Participant Identifier that is communicated to those market operation
service providers for inclusion in their systems.
1.16.1 Participants are required to specify their intended roles as part of the approval
process. The roles that are of interest to the registry are the roles of Trader,
Distributor and Metering Equipment Provider. A participant's role dictates
what registry functions are to be made available to the participant. It is
possible for one participant to have more than one role. The combinations
supported using one Participant Identifier should be:
Primary role Distributor Trader Metering

Equipment
Provider
Distributor Y N Y
Trader N Y Y
Metering Equipment N N Y
Provider
54
Version 22.24
1.16.1 Participants with the Trader role must specify the profiles they will be using.
Participants with the Distributor role must specify the unique two character
code that they will use when creating new ICP Identifiers.
1.16.1 Participants are also required to specify the user interfaces they will be using
which will need to be set up by the Registry Manager. For the browser, access
to the registry is managed by a supervisor designated by the participant.
There must only be one supervisor logon set up for a participant and it cannot
be a web services only logon.
1.16.1 The passwords of the initial participant supervisor and to the private SFTP
folders; as well as the SFTP User Id are sent directly by the Registry Manager
to the participant supervisor in an encrypted form. The initial participant
supervisor password will be a one-time-use password.
1.16.1 . The participant supervisor on behalf of their own organisation is required to:
(a) assign new logons with an initial one-time-use password and record an
associated email address;
(b) identify new or existing logons for accessing the Registry via Web
services only. Logons identified as web services only cannot be used to
access the browser, cannot act as agents and their passwords do not
expire;
(c) assign access rights to logons. Access rights permit users access to
one or more of the following functions:
(i) read-only (online functions);
(ii) submit ICP event information;
(iii) submit particular switching messages; and
(iv) submit particular reports;
(d) reset the passwords of locked-out logons;
(e) disable and re-enable logons; and
(f) assign an agent to act on the participant's behalf.
1.16.1 Other security features are:
(a) The registry can identify individual participant logon identities and log the
identity against updates made online.
(b) A participant may nominate another party to act on its behalf (an agent).
The system must be able to identify the participant an agent is acting for
when evaluating whether that agent is allowed to perform an update.
(c) A single logon supports the role of agent, and the participant’s role.
55
Version 22.24
(d) A single logon allows a participant to perform more than one role, ie if a
participant is both a Distributor and a Metering Equipment Provider then
they able to input/maintain a single ICP at which they have both roles or
just one of those roles.
(e) The system locks-out users after three consecutive invalid attempts. An
alert is sent to the Registry Manager for further investigation when a
user has 5 lockouts within 4 hours.
(f) Locked out users and users that have forgotten their password can
request that the system sends a new one-time-use password to their
previously stored email address.
(g) Users must change their passwords after a set number of days*
(h) Users with a password status of Reset cannot access the Registry via
web services.
* Except for web services only logons.
1.17 EIEP Exchange

1.17.1 The EIEP Transfer is a central secure delivery mechanism for all EIEP formats
using SFTP encrypted transfer. Access is available through the online and
batch interfaces (SFTP only), and is restricted to approved participant
organisations. Authentication relies upon participants’ existing Registry access
credentials.
1.17.2 The following sub-processes are related to the EIEP Exchange.
Sub-Process Description
EI-010 EIEP Transfer Settings Supervisor configuration of optional EIEP

delivery and acknowledgement parameters.
EI-020 Upload and Download Online send and receipt of EIEP files.
EI-030 EIEP Transfer EIEP file delivery from a sender’s SFTP outbox
to a recipient’s inbox
EI-040 Maintain EIEP Transfer Participants agree to share EIEP information

Permissions they send or receive with the Authority.
QU-040 View Registry Audit Data Search and view details of EIEP transfer
receipts, deliveries, acknowledgements and
notifications.
56
Version 22.24
SD-050 Maintain email group Supervisor configuration of email contact

addresses.
PR-190 Produce EIEP statistics Monthly statistics representing the number and
volumes of files sent and received by the EIEP
transfer hub
1.18 Web Services

1.18.1 Access to address search, ICP event history and ICP details enquiries are provided via Web
Services. The facility provides Traders with a more efficient way for their Customer Service
Representatives to access the Registry.
1.18.2 Access to notifications is provided for Traders, Distributors and MEPs. The facility allows
these participants to obtain their ICP notifications in batches from the Registry.
1.19 Trader default process

1.19.1 The objective of the Trader default process in the Registry is to facilitate the transfer of
Trader responsibility for ICPs from a Trader in a Trader Default situation to a non-defaulting
Trader. The transfer of responsibility may be performed using:
(a) The standard customer switching process; or
(b) The trader default process.
Trader default communications
1.14.29 Traders must provide an email contact address list for the Trader Default email group. The
email addresses are used for the delivery of important information and documentation
pertaining to a Trader Default situation including
(a) Tender documentation

(b) Tariff warnings for supplied trader bids
(c) Error alerts for supplied trader bids
(d) Notification when the ICP allocation process has completed
(e) Notification where a traders ICP allocation has been adjusted
The Trader Default email group is maintained using Maintain Email Groups (SD-050).
57
Version 22.24
Terminology used in the Trader default process
1.19.2 The Trader default process uses the following terminology:
(a) Tender Block: is a set of a defaulting Trader’s ICPs that are grouped
together according to shared characteristics at NSPs, to be bid for by
non-defaulting Traders.
(b) Tender Round(s): a period in which non-defaulting Traders may submit

bids for volumes of ICPs from Tender Blocks. At the end of each Tender
Round, all bids are stored for use in the Allocation process. No ICPs are
allocated to a bidder at the end of any Tender Round. Subsequent
Tender Rounds are only to elicit additional bids for unsubscribed or
undersubscribed Tender Blocks.
(c) Mandatory Assignment: the process by which ICPs are assigned by

the Authority during an event of trader default. These ICPs are assigned
in accordance with the Mandatory Assignment rules within the Allocation
Process.
(d) Mandatory Assignment Block: a set of a defaulting Trader’s ICPs that

are grouped together according to shared characteristics for assignment
by the Authority during an event of trader default.
(e) Allocation Process: a single process performed after the final Tender
Round that identifies specific ICPs to be allocated to non-defaulting
Traders. The process involves:
(i) selecting (allocate) individual ICPs to satisfy each non-defaulting
Trader’s bid. Bids from the earliest Tender Round and lowest tariff
will be allocated first. ICPs are allocated randomly by sorting them
on the ICP checksum; then
(ii) performing mandatory assignment (allocation) of ICPs of under-
subscribed Tender Blocks remaining after all bids have been
processes. The mandatory assignment process allocates any
remaining ICPs to non-defaulting Traders in proportion to the
Trader’s market share at the NSP.
This process does not switch (transfer responsibility) for these allocated
ICPs. Switching is performed by the Registry in a separate operation
58
Version 22.24
after the results of the allocation process have been reviewed by all non-
defaulting Traders.
(f) Allocation Identifier: Identifier that indicates whether the ICP has been allocated from
a Tender Round or via mandatory assignment.
(g) Unpublished Tender Round: A Tender Round for which Tender Blocks have been
created, but tender documentation has not yet been sent to Traders.
Tender process
1.19.3 The Registry Manager, on instruction from the Authority, delivers tender information to
Traders. This information includes instructions from the Authority and tender documents that
detail the Tender Blocks available to bid for. Tender information is delivered to non-defaulting
Traders via the EIEP transfer hub.
NOTE: TD-040 delivers Tender Bid Documentation to participants in a comma separated file.
If opened using the Excel spreadsheet application any cells containing integer values longer
than 11 characters will automatically convert to scientific notation. To return these cells to
text:
 select the affected cell

 right click and select “Format Cells…”
 Select either number with zero decimal places, or custom of type 0
This behaviour is not exhibited where a file is opened in text editors or cloud based
spreadsheet applications.
1.19.4 In the tender process there may be a number of Tender Rounds (initially set to 2). Each
Tender Round has an open and close time which is notified to Traders. Open and close
times are notified to the Registry Manager by the Authority. The open time can only be
changed on instruction from the Authority and if no bids have been received. The close time
can be changed prior to the initial close time, but only on instruction from the Authority.
1.19.5 Traders may submit bids against individual Tender Blocks in each Tender Round. Trader’s
bids are for a volume of ICPs not for specific ICPs.
1.19.6 The Tender Blocks in each subsequent Tender Round include:
59
Version 22.24
 The remaining volumes of ICPs from Tender Blocks that received

insufficient bids in previous Tender Rounds. These volumes will be
adjusted for cases where the ICPs have switched away from the
Defaulting Trader, or are currently in the process of being switched
away, or where the ICPs status is no longer Active or Inactive.
 ICPs that were not included in prior Tender Rounds but now qualify
for allocation.
N.B. Volumes already bid on in previous Tender Rounds are not

included in subsequent Tender Blocks.
Allocation process (including Mandatory Assignment)
1.19.7 The allocation process will only be run once, once the final Tender Round has
closed.
1.19.8 On notice from the Authority and prior to the allocation process commencing,
non-defaulting Traders should provide a list of ICP characteristics, at NSP
level, that the non-defaulting Trader cannot accept. See TD-020. If this list is
provided, it will feed into the mandatory assignment process to ensure that a
Trader is assigned ICPs that the Trader can accept (based on the
characteristics of the ICPs). Please note that TD-020 only covers the ICP
characteristics that the Authority considers is acceptable not to be assigned to
a Trader during an event of trader default.
1.19.9 On completion of the allocation process and on instruction from the Authority,
the Registry Manager will provide non-defaulting Traders with the results of
the ICP allocation from tender round(s) and any ICPs that have been allocated
through the mandatory assignment process. Non-defaulting Traders will be
given the opportunity to review the results and advise the Authority on whether
the ICPs assigned through mandatory assignment may pose a serious threat
to the non-defaulting Trader’s financial viability.
60
Version 22.24
1.19.10 Any non-defaulting Traders who consider that the transfer of ICPs through
mandatory assignment may pose a serious threat to the non-defaulting
Trader’s financial viability will enter into discussions with the Authority. As a
result, those ICPs may be re-assigned. However, this will be determined on a
case by case basis.
1.19.11 If ICPs are re-assigned by the Authority, the Authority will contact the non-
defaulting Trader(s) to which the ICPs have been assigned.
1.19.12 Switching of allocated ICPsOn instruction from the Authority, the Registry
Manager will initiate the automatic switch process to change responsibility of
the ICPs to the allocated Traders (Authority assigned and successful bidders
from the tenders) provided the status of the ICP is still Active or Inactive
(excluding ‘Inactive ready for decommissioning’) and the Trader responsibility
still resides with the defaulting Trader.
N.B. The standard switching process will not be inhibited during this period
and customer switching of the defaulting Trader’s ICPs may continue.
However, the Registry will prevent customer switching to the defaulting Trader
and withdrawals that would result in the defaulting Trader regaining an ICP.
1.20 Email groups

Email groups are email distribution lists used by the Registry, Registry Manager or the
Authority for communicating with participants.
Each email group contains a list of email contact addresses per participant. An email group
is used either by:
 A Registry function that requires information to be sent from the Registry to a
number of contacts of a participant, via email. The current Registry functions that
require email notifications to be sent are:
o EIEP delivery acknowledgements and confirmations,
o various Trader Default process notifications, and
o metering alerts
 The Registry Manager or Authority to correspond with Participants. The current
Registry functions that require email notifications are:
o Lockout Alert – specifically for the Registry Manager to be notified
when a User Id is repeatedly locked out in a defined time period
61
Version 22.24
o SFTP Transfer Failure – specifically for the Registry

Manager to be notified when EIEP files cannot be
transferred to the Authority SFTP server
It is recommended that email groups are setup, as a minimum, for the email group
named:
 EIEP – the default email group for notifications by email of the delivery of EIEP
files to a participant’s SFTP EIEP inbox or outbox.
 Trader Default – which is specifically for traders, and is the email group for
notifications of all email communications relating to Trader Defaults.
 Trader Default Network – which is specifically for distributors, and is the email
group for notifications of all email communications relating to Trader Defaults
 Metering Alerts – the email group for email notifications of alerts relating to
metering issues (see NP-060).
 Outages – the email group for notifications sent by the Registry help desk or
the Authority advising of outages to Registry services.
 Saves Protection – the email group for notifications sent by the Registry help
desk or the Authority providing information on the saves protection scheme.
 Lockout Alert – the email group for reporting instances of repeated lockouts.
 SFTP Transfer Failure – the email group for reporting EIEP file transfer failures
to the Authority SFTP server.
Traders and agents specifically use the EIEP13 formats. Participant in this role
who want to receive EIEP notifications of EIEP13A/B/C files to an address other
than the default EIEP address should also set up the following groups:
 EIEP13A and ICPCONS – the default e-mail groups for notifications by e-mail
message of the delivery of EIEP13A files to a participant’s SFTP EIEP inbox or
outbox.
 EIEP13B and ICPSUMM – the default e-mail groups for notifications by e-mail
message of the delivery of EIEP13B files to a participant’s SFTP EIEP inbox or
outbox.
 EIEP13C and REQCONS – the default e-mail groups for notifications by e-mail
message of the delivery of EIEP13C files to a participant’s SFTP EIEP inbox or
outbox.
See SD-050 for further details.
62
Version 22.24
1.21 Transfer to the Authority SFTP Server

Where the Authority is (one of) the intended recipients of a scheduled report, the Authority may request
the resulting batch file is transferred directly to the EA SFTP server, or request an existing transfer is
stopped. Delivery to the Authority’s SFTP server must be in addition to the standard delivery of batch
files to the Authority’s directory on the Registry SFTP server.
If the transfer is unable to complete the Registry must retry the transfer a maximum of 5 times. On the
final failed transfer, the Registry must:
(a). raise an alert to the 24-hour help desk and supply the following information (indicative):
“SFTP transfer failure, <environment name> was unable to complete file transfer using <secure
transfer software name e.g. WinSCP> via SFTP. The process will pause for 30 minutes before
retrying the file transfer. Please refer to SLA support documentation. Exit code: <transfer error
code>”
(b). Pause for 30 minutes before reattempting the transfer.
On request the Registry Manager must be able to manually send or resend files to the Authority’s SFTP
server.
1.22 Transfer EIEP files to the Authority SFTP Server

Where the Authority has gained permission from a participant to access specific EIEP formatted files
from the EIEP hub, the Authority may request the Registry Administrator to transfer the EIEP files to the
Authority’s SFTP server.
The Authority will notify the Registry Administrator to request an EIEP Transfer Permission is created,
notification must include:
 Participant identifier
 EIEP file format
 Indication whether the participant is sharing the information as the EIEP file sender or recipient
(or both).
New Participants, when requesting access to the Registry and EIEP hub, can also provide consent to
allow selected EIEP formats to be automatically transferred to the Authority’s SFTP server.
A Participant, who does not currently supply EIEP files to another Participant or selected Participant,
may provide EIEP files directly to the Authority’s SFTP server by using one of the following options:
(a). Supply an EIEP file with a Recipient of EMCO. This will utilise existing functionality and transfer
the EIEP file to the Authority directory. An EIEP Transfer Permission must exist for the sender;
or
63
Version 22.24
(b). Supply an EIEP file where the recipient is not EMCO. An EIEP Transfer
Permission must exist for one or both participants (sender/receiver). The file must
be placed in the EIEPin folder of the intended recipient and the EIEPin folder of
EMCO. The file name will not be changed, the EMCO EIEPin folder will have files
where EMCO is not the recipient; or
(c). Supply an EIEP file with the Unique ID component of the file name containing
anywhere in the text wording of “SendToEAOnly”. The Recipient will be ignored
and the file transferred instead to the Authority’s EIEP directory. The recipient
section of the file name will be changed to EMCO. There is no need of an EIEP
Transfer Permission for this option.
In all options above, the file must be transferred from the Authority’s EIEP directory
to the Authority’s SFTP server.
64
Version 22.24
2. Process Maps
Figure 3: Process map – ICP event Distributor, Trader and MEP
maintenance
Distributor Distributor Trader makes Trader MEP

creates maintains initial maintains maintains
ICP ICP data assignment ICP data metering
information
DC-010 DM-010 RA-010 RM-010 MM-010

Create an ICP Change initial Make initial Reverse initial Add new
ICP creation assignment to assignment of metering
date ready ICP ICP information
DC-020 DM-020 RM-020 MM-020

Make a new Add new Add new Correct
ICP ready Distributor Trader metering
information information information
DC-030 DM-030 RM-030 MM-030

Make a new Correct Correct Reverse
ICP distributor Distributor Trader metering
information information information
DM-040 RM-040 MM-040

Reverse Reverse MEP Historical
Distributor Trader Insertion
information information
65
Version 22.24
Figure 4: Process map – switching (Trader and MEP)
Traders Trader Trader MEP accepts

switch withdraws changes or declines
ICP switch switch responsibility
read
RS-010 RW-010 RC-010 MN-010

Make switch Make Request Accept /reject
request (NT) withdrawal switch read responsibility
request (NW) change (NC) (MN)
RS-020 RW-020 RC-020

Acknowledge Acknowledge Acknowledge
switch request withdrawal switch read
(AN) request (AW) change (AC)
RS-030
Complete
non-half-hour
switch (TN)
RS-040
Complete
half-hour
switch (TT)
RS-050
Complete switch
or provide
replacement
reading (CS/RR)
66
Version 22.24
Figure 5: Process map – reporting, parameters, notifications and queries
Produce Maintain Notify Make

reports user participants Query
parameters online
PR-010 PR-080 MP-010 NP-010 QU-010

Produce ICP Produce HHR Set switching Acknowledge Search for
list ICP list message event address to
receipt times changes find ICP
PR-020 PR-090 MP-020 NP-020 QU-020

Produce Produce active Set notify Send switch View ICP
monthly NSP list parameters messages information
Traders’ ICP
list
PR-030 PR-100 NP-030 QU-030

Produce ICP Produce loss Notify of View static
event detail factors report event table
report changes information
PR-040 PR-110 NP-040

Produce Produce Re-send
switch maintenance switching
compliance compliance messages
reports report
PR-050 PR-120 NP-050

Produce ICP Produce NSP Re-send
days report mapping table notifications
report
PR-060 PR-130 NP-060

Produce audit Produce Alert
log of files monthly activity certification
sent summary report expiring
PR-070 PR-140 NP-070

Produce Produce Notify of event
monthly monthly switch change by
statistics completion Web Service
report
PR-145 to PR-
190
Additional
reports….
67
Version 22.24
Figure 6: Process map – maintaining static data and access

security
Maintain Supervise Maintain

static own password
data users
SD-010 SU-010 PW-010

Maintain NSP Add and Change user
data maintain password
users
SD-020 SU-020 PW-020

Maintain static Disable and
data re-enable Request new
logons password
SD-030 SU-030
Maintain Loss Reset user
Category password
Codes
SD-040 SU-040
Maintain Assign agent
Distributor Price
Category
Codes
SU-050
Lockout
Logons
68
Version 22.24
Figure 7: Process map – publish information
Publish
information
PI-010
Publish
information
initial ICP
creation date
69
Version 22.24
Figure 8: Process map – EIEP configuration, upload, download, transfer and

report
Exchange
EIEP
messages
EI-010
Configure
EIEP transfer
settings
EI-020
Upload and
download via
browser
EI-030
Transfer EIEP
via SFTP
EI-040
Maintain EIEP
transfer
permissions
70
Version 22.24
Figure 9: Process map – Trader Default
Trader
Default
TD-010 TD-070
Complete Allocate ICPs
Switch Activity
for Trader in
Trader Default
TD-020 TD-080
Maintain Switch Trader
Trader ICP Default Trader
Allocation ICPs
Exclusion List
TD-030 TD-090
Create Tender ICP re-
Blocks assignment
process
TD-040 PR-300
Send Tender Report Trader
Documentation Default tender
and mandatory
assignment
TD-050 PR-310
Load Trader Report Trader
Bids Default
allocation
results
TD-060
View tender
bids, tender
and mandatory
assignment
allocation
results
71
Version 22.24
3. Sub-processes
3.1 ICP event maintenance – Distributor
Sub-process: DC-010 Create an ICP
Process: Distributor creates an ICP Identifier for an ICP and manages the Status
of the ICP
Participants: Distributors
Code references: Clauses 11.3 to 11.9, and clauses 7 and 12 to 20 of Schedule 11.1 of
the Code
Dependencies: DC-020
Description:
A Distributor must create an ICP Identifier for certain points of connection, and provide information
about the ICP to the registry. Depending on how much and what information the Distributor enters,
the system will either set the Status of the ICP to be new or ready or distributor.
Business requirements:
1. Only Distributors or their agents can create ICP Identifiers for ICPs.
2. The system must determine the correct Status and type to assign to the ICP from the
information provided by the Distributor.
3. In order for the ICP to have the new Status, the Distributor must enter values for at least the
ICP Identifier, Network Participant Identifier and Address attributes.
4. In order for a Standard ICP to be created on the system with ready Status, the Distributor must
enter values for at least the ICP identifier, Network Participant Identifier, Address attributes,
POC, Dedicated NSP, Installation Type, Reconciliation Type (not LE or SI), Distributor Price
Category Code, Distributor Loss Category Code and Proposed Trader Participant Identifier. For
Installation Types of ‘B’ or ‘G’ the Generation Capacity and Fuel Type is also required.
5. In order for a Distributor-only ICP to be created on the system with distributor Status, the
Distributor must enter at least the ICP Identifier, Network Participant Identifier, Address
attributes, POC, Dedicated NSP, Installation Type, Reconciliation Type (LE or SI) and
Distributor Loss Category Codes.
6. Network Participant Identifiers must be valid for the Distributor by reference to the NSP mapping
table.
7. Network Participant Identifier and POC combinations must be a valid NSP combination for the
Distributor as the NSP owner.
8. A Network, Address and Status event must be generated and all of them must have the same
Event Date, which will be deemed to be the creation date for the ICP.
72
Version 22.24
9. When a Pricing event is generated for an ICP with a ready or distributor Status, it must have an
Event Date that is on or after the ICP creation date.
10. A Proposed Trader, if known, is an affected party for notification purposes.
Data inputs:
Attributes input Format Mandatory/ Comments

optional
Record Type Char 3 M Must be “DET”
ICP Identifier Char 15 M
Network event:
Network Event Date DD/MM/YYYY M
Network User Reference Char 32 O
Network Char 4 M Valid Participant Identifier for

Distributor.
POC Char 7 O Valid POC for Distributor.
Reconciliation Type Char 2 O Valid Reconciliation Type for

Distributor and ICP type.
Dedicated NSP Char 1 O
Installation Type Char 1 O Valid type [L, G, or B].
Proposed Trader Char 4 O Valid Trader Participant Identifier.
Unmetered Load Details – Char 50 O

Distributor
Shared ICP List List O For ICPs across which unmetered

load is shared (Shared Unmetered
ICPs see section 1.5), the list will
contain the ICP identifiers of each
ICP separated by a space. For
Standard ICPs with a relationship
to Shared Unmetered ICPs (across
which unmetered load is shared),
this will contain the ICP Identifier of
the Shared Unmetered ICP.
Generation Capacity Numeric 6.2 M/O Generation nameplate capacity in

kW. Only required where the
Installation Type is ‘B’ or ‘G’.
73
Version 22.24

optional
Fuel Type Char 15 M/O A valid Fuel Type. Only required

where the Installation Type is ‘B’ or
‘G’. A list of valid Fuel Types is
stored in the Registry reference
tables. See SD-020.
Initial Electrically Connected DD/MM/YYYY O Date the ICP was first electrically
Date connected. Optional. Cannot be a
future date nor can it be prior to the
creation date of the ICP.
Note to distributors: It should be >=
Event Date of the Ready status as
a Trader cannot insert an initial
assignment prior to the Ready
Event Date, however, the Registry
will not validate it to be so.
Direct Billed Status Char 11 O Indicates who, out of the Distributor

or Trader, directly bills the
customer for the lines charges.
Valid values are: ’Retailer’,
‘Distributor’, ’Neither’, ’Both’, ’TBA’
and NULL.
Direct Billed Details Char 60 O Contains other information relating

to direct billing arrangements such
as commencement or cessation
dates. Optional. Free text.
Reversal Indicator - Network Char 1 O Used only in DM-040, R or blank

Event
Pricing event:
Pricing Event Date DD/MM/YYYY M/O Mandatory if any attribute in the

event is input.
Pricing User Reference Char 32 O
Distributor Price Category Char 50 O

Code
Distributor Loss Category Char 7 O

Code
Distributor Installation Char 30 O

Details
Chargeable Capacity Numeric 7.2 O
74
Version 22.24

optional
Reversal Indicator - Pricing Char 1 O Used only in DM-040. R or blank

Event
Address event:
Address Event Date DD/MM/YYYY M
Address User Reference Char 32 O
Physical Address Unit Char 20 O
Physical Address Number/ Char 25 O

RAPID Number
Physical Address Street Char 30 M/O Mandatory if Property Name not

input.
Physical Address Suburb Char 30 M/O Mandatory if Town not input.
Physical Address Town Char 30 M/O Mandatory if Suburb not input.
Physical Address Post Code Numeric 4 O
Physical Address Region Char 20 M
Address Property Name Char 75 M/O Mandatory if Street not input.
GPS_Easting Numeric 7.3 M/O The easting location. Optional but

required if GPS_Northing is
provided
New Zealand Transverse Mercator

2000 (NZTM2000) coordinates, as
defined in Land Information New
Zealand’s LINZS25002 standard
(Standard for New Zealand
Geodetic Datum 2000 Projections).
GPS_Northing Numeric 7.3 M/O The northing location. Optional but

required if GPS_Easting is provided
New Zealand Transverse Mercator

2000 (NZTM2000) coordinates, as
defined in Land Information New
Zealand’s LINZS25002 standard
(Standard for New Zealand
Geodetic Datum 2000 Projections).
Reversal Indicator - Char 1 O Used only in DM-040. R or blank.

Address Event
75
Version 22.24

optional
Example:
HDR,RQNETMAINT,POCO,RGST,9/07/2007,23:57:59,1,update an ICP
DET,99999999999AB123,1/01/2009,NetworkUserRef,NETA,ABCD123,GN,N,B,RETA,UnmeteredD
etail,,B,wind,1/01/2009,Both,OptionalField,,1/01/2009,PricingUserRef,Pcat1,Lcat1,InstallDet,12345
67.12,,1/01/2009,AddressUserRef,Unit1,678,Perkins,Ohau,Tekapo,7797,Canterbury,White
House,1234567.123,57.6,
Processing:
System
1. Validates the attributes and checks their dependencies. The minimum attributes required for
the creation of an ICP with a Status of new are:
 an ICP Identifier;
 an Address; and
 a Network Participant Identifier (part of the NSP identifier) with an associated Event Date.
More attributes than those above may be supplied and the ICP will still be created with a Status
of new but when all of the following attributes (together with their appropriate Event Dates) are
provided, then the ICP will be created with a Status of ready or distributor (depending on the
Reconciliation Type input):
 POC;
 Reconciliation Type;
 Dedicated NSP
 Proposed Trader (not required for Distributor-only ICPs);

 Distributor Price Category Code (not required for Distributor-only ICPs); and
 Distributor Loss Category Code.
 Generation Capacity (not required for Installation Type of L).

 Fuel Type (not required for Installation Type of L)
2. Generates a Network event and an Address event using the attributes supplied.
3. If any pricing information is supplied, generates a Pricing event.

4. Generates a Status event with the appropriate Status and an Event Date that is the same as
the Network event.
5. Completes the audit trail information for each event.

6. Generates notifications to the Distributor and the Proposed Trader (Standard ICPs only).
7. Generates acknowledgements to the Distributor for each event.
76
Version 22.24
Data outputs:
With the minimum attributes, an ICP with a Network event, Address event, Status event and
associated audit trail information.
If more than the minimum attributes are provided, that include any from the Pricing event, then the
ICP will be created with an additional Pricing event.
Notifications.
An acknowledgement for each event.
77
Version 22.24
Sub-process: DC-020 Make a new ICP ready
Process: Distributor updates information about an ICP
Code references: Clauses 11.7 and 11.8, and clauses 7 and 12 to 20 of schedule 11.1 of
the Code
Dependencies:
Description:
A Distributor progressively provides information about an existing Standard ICP in the new state to
the registry until the system has sufficient information to change the Status to ready.
1. Only Distributors or their agents must provide information required by clause 7 of schedule 11.1
of the Code in respect of ICPs.
2. At the pre-commissioning stage, the ICP Status must be a system-assigned attribute and must
not be able to be set by a Distributor.
3. The combination of the values for the Network Participant Identifier and POC must be a valid
combination in the NSP mapping table for the Distributor as the NSP owner.
4. In order for a Standard ICP to be created on the system with ready Status, the Distributor must
enter at least information about the ICP Identifier, Address, Network Participant Identifier, POC,
dedicated ICP, Installation Type, Reconciliation Type (not LE or SI), Distributor Price Category
Code, Distributor Loss Category Code and Proposed Trader. For Installation Types of ‘B’ or ‘G’
the Generation Capacity and Fuel Type is also required.
5. The Pricing event generated must have an Event Date that is on or after the ICP creation date.
6. The Trader proposed as Proposed Trader must be classed as an affected party for notification
purposes.
Data inputs:
Sufficient attributes (note that the Address event is assumed to be present):
 Network Participant Identifier, POC, Installation Type, Dedicated NSP, Reconciliation Type
and Proposed Trader with an associated Event Date; and
 Distributor Price Category Code and Distributor Loss Category Code with an associated
Event Date.
 Optional extra attributes:
 Chargeable Capacity;
 Distributor Installation Details; and
78
Version 22.24
 Unmetered Load Details – Distributor.

 See sub-process DC-010 for minimum input details.
Processing:
System
1. Validates all attributes and checks their dependencies.
2. Generates events of the appropriate types based on the attributes supplied.

3. Generates a Status event with a ready Status and an Event Date the same as that of the
Network event.
5. Generates notifications to the Distributor and the Proposed Trader.

6. Generates an acknowledgement to the Distributor for each event.
Data outputs:
Network, Status and Pricing events and associated audit trail information.
Notifications.
Acknowledgements.
79
Version 22.24
Sub-process: DC-030 Make a new ICP distributor
Code references: Clauses 11.7 and 11.8, and clauses 7 and 12 to 20 of Schedule 11.1 of
the Code
Dependencies:
Description:
A Distributor progressively provides information about an existing Distributor-only ICP in the new
state to the registry until the system has sufficient information to change the Status to distributor.
1. Only Distributors (or their agents) must provide information required by clause 7 of Schedule
11.1 of the Code in respect of ICPs.
2. At the pre-commissioning stage, the ICP Status must be a system-assigned attribute and must
not be able to be set by a Distributor.
3. The combination of the values for the Network Participant Identifier and POC must be a valid
combination in the NSP mapping table for the Distributor as the NSP owner.
4. In order for a Distributor-only ICP to be created on the system with distributor Status, the
Distributor must enter at least information about the ICP Identifier, Address, Network Participant
Identifier, POC, dedicated ICP, Installation Type, Reconciliation Type (LE or SI) and Distributor
Loss Category attributes.
5. The Pricing event generated must have an Event Date that is on or after the ICP creation date.
Data inputs:
Sufficient attributes (note that the Address event is assumed to be present):
 Network Participant Identifier, POC, Installation Type, Dedicated NSP, and Reconciliation Type
with an associated Event Date; and
 Distributor Loss Category Code with an associated Event Date.

Optional extra attributes:
 Chargeable Capacity;
 Distributor Installation Details;

 Unmetered Load Details – Distributor; and
 Shared ICP List.

See sub-process DC-010 for minimum input details.
80
Version 22.24
Processing:
System
2. Generates events of the appropriate types based on the attributes supplied.

3. Generates a Status event with a distributor Status and an Event Date the same as that of the
Network event.
5. Generates notifications to the Distributor.

6. Generates an acknowledgement to the Distributor for each event.
Data outputs:
 Network, Status and Pricing events and associated audit trail information.
 Notifications.
 Acknowledgements.
81
Version 22.24
Sub-process: DM-010 Change initial ICP creation date
the Code
Dependencies:
Description:
The Distributor moves the ICP creation date to an earlier date.
1. The ICP must be in the pre-commissioning stage, ie it must have either a new or ready or
distributor Status.
2. The Distributor must have owned the ICP on creation date.

3. The new creation date must be before the current creation date.
Data inputs:

optional
Event Date DD/MM/YYYY M
User Reference Char 32 O
Example:
HDR,RQDATECHG,CTCT,RGST,01/12/2002,16:44:11,2,Correct Initial Date
DET,9999999999AB123,01/01/2009,Change date user ref
Processing:
System
1. Validates the new Event Date.
2. Checks that this Distributor is allowed to make this change.

3. Generates new ‘creation’ network, Address and Status events and a Pricing event, if present,
using all the attributes from the ‘old’ events but with the earlier Event Date.
4. Completes the audit trail of all new and old events marking the ‘old’ events as replaced.
82
Version 22.24
5. Determines the affected parties (Distributor and Proposed Trader) and generates the
appropriate, requested notifications.
Data outputs:
 New network, Address, Status and possibly Pricing events with the associated audit trail
information.
 Updated, old network, Address, Status and possibly Pricing events with the associated audit trail
information.
 Notifications.
83
Version 22.24
Sub-process: DM-020 Add additional Distributor information
the Code
Dependencies:
Description:
The Distributor adds one or more new events to an ICP. The event(s) may either represent a
change to the current information stored for the ICP, eg a new Distributor Price Category Code, or
may be information that should have been entered previously but was missed (historical insertion).
The event is not for an existing Event Date.
1. Distributors are solely responsible for the network, Address and Pricing information.
2. Distributors may add a Status event setting the Status to decommissioned but only if the
ICP is in the new or distributor states or in the inactive state with the Status Reason set to
electrically disconnected ready for decommissioning (‘06’).
3. There must be no inheritance of attribute values from prior events, and all mandatory
attributes must be provided for any event that is inserted, as a minimum.
4. Distributors must only be allowed to insert events within their period of responsibility.
5. An event must not be inserted if that would invalidate other prior events, eg an ICP Status
event with a Status of decommissioned may not be inserted after a Status event that set
the Status to active. Also, Reconciliation Types that would change the type of ICP cannot
be changed.
6. Events must not be able to be inserted for dates prior to the ICP creation date.
7. The Event Dates of different events inserted by the user at the same time must be allowed
to be different.
8. It must be possible for Distributors to revert ready or distributor ICPs to new by inserting
new events with blank (empty) values in any of the attributes required to make the ICPs’
Status ready or distributor, eg by inserting a Pricing event with a blank Distributor Loss
Category Code. (Note that this function must be able to be performed ‘historically’, i.e.
prior to the latest Event Date.)
9. Once the ICP has been assigned to a Trader, no further notifications must be sent to any
Proposed Trader of the ICP.
84
Version 22.24
Data inputs:
One or more of:
 Network information;
 Pricing information;
 Address information
 Status information.
Each attribute on an input line is comma separated.

The minimum information input for each event is as follows:
Event data Format Mandatory/ Comments

optional

Network event:
Network Event Date DD/MM/YYYY M/O A blank date indicates that the
event is not being input.
Network Participant Identifier Char 4 M Valid participant identifier for

Distributor.
POC Char 7 M Valid POC for Distributor.
Reconciliation Type Char 2 M Valid Reconciliation Type for

Distributor and ICP type.
Dedicated NSP Char 1 M
Installation Type Char 1 M Valid type {L, G, B}.
Proposed Trader Char 4 O Valid Participant Identifier for

Trader.
Unmetered Load Details - Char 50 O

Distributor
Shared ICP List List O
Generation Capacity Numeric 6.2 M/O Generation nameplate capacity

in kW. Only required where the
Installation Type is ‘B’ or ‘G’.
85
Version 22.24

optional
Fuel Type Char 15 M/O A valid Fuel Type. Only

required where the Installation
Type is ‘B’ or ‘G’. A list of valid
Fuel Types is stored in the
Registry reference tables. See
SD-020.
Initial Electrically Connected DD/MM/YYYY O Date the ICP was first

Date electrically connected. Optional.
Cannot be a future date nor can
it be prior to the creation date of
the ICP.
Note to distributors: It should be
>= Event Date of the Ready
status as a Trader cannot insert
an initial assignment prior to the
Ready Event Date, however, the
Registry will not validate it to be
so.
Direct Billed Status Char 11 O Indicates who, out of the

Distributor or Trader, directly
bills the customer for the lines
charges. Valid values are:
’Retailer’, ‘Distributor’, ’Neither’,
’Both’, ’TBA’ and NULL.
Direct Billed Details Char 60 O Contains other information

relating to direct billing
arrangements such as
commencement or cessation
dates. Optional. Free text.
Reversal Indicator - Network Char 1 O Valid for DM-040 only. R or

Event blank
Pricing event:
Pricing Event Date DD/MM/YYYY M/O A blank date indicates that the
Pricing User Reference Char 32 O
Distributor Price Category code Char 50 M
Distributor Loss Category Code Char 7 M
Distributor Installation Details Char 30 O
86
Version 22.24

optional
Reversal Indicator - Pricing Char 1 O Valid for DM-040 only. R or

Event blank
87
Version 22.24

optional
Address event:
Address Event Date DD/MM/YYYY M/O A blank date indicates that the
Physical Address Number/ Char 25 O

RAPID number
Physical Address Street Char 30 M/O Mandatory if Property Name not

input.
Physical Address Suburb Char 30 M/O Mandatory if Town not input.
Physical Address Town Char 30 M/O Mandatory if Suburb not input.
Physical Address Post Code Numeric 4 O
Physical Address Region Char 20 M
Address Property Name Char 75 M/O Mandatory if Street not input.
GPS_Easting Numeric 7.3 M/O The easting location. Optional

but required if GPS_Northing is
provided.
New Zealand Transverse
Mercator 2000 (NZTM2000)
coordinates, as defined in Land
Information New Zealand’s
LINZS25002 standard (Standard
for New Zealand Geodetic
Datum 2000 Projections).
GPS_Northing Numeric 7.3 M/O The northing location. Optional

but required if GPS_Easting is
provided.
New Zealand Transverse
Mercator 2000 (NZTM2000)
coordinates, as defined in Land
Information New Zealand’s
LINZS25002 standard (Standard
for New Zealand Geodetic
Datum 2000 Projections).
Reversal Indicator - Address Char 1 O Valid for DM-040 only. R or

Event blank
88
Version 22.24

optional
Status event: This event can only be input by
a Distributor when an ICP is
being decommissioned.
Event Date DD/MM/YYYY M A blank date indicates that event

is not being input.
ICP Status Char 3 M Only decommissioned Status

events allowed to be input by
Distributors.
Status Reason Numeric 2 M/O Mandatory if ICP Status

decommissioned. Valid Status
Reason codes are 01, 02 or 03.
Reversal Indicator - Status Char 1 O Valid for DM-040 only. R or

Event blank
Example
HDR,RQNETMAINT,POCO,RGST,09/07/2007,23:57:59,1,add 3 events
DET,99999999999AB123,1/01/2009,NetworkUserRef,NETA,ABCD123,GN,N,B,RETA,UnmeteredD
etail,,B,wind,1/01/2009,Both,OptionalField,,1/01/2009,PricingUserRef,Pcat1,Lcat1,InstallDet,12345
67.12,,1/01/2009,AddressUserRef,Unit1,678,Perkins,Ohau,Tekapo,7797,Canterbury,White
House,1234567.123,57.6,,1/01/2009,StatusUSerRef,3,1,
Processing:
System
3. Adds the events supplied by the Distributor.
4. Completes the audit trail information for each event added.

5. Determines the affected parties for each event inserted (Distributor, Proposed Trader if the ICP
is in the pre-commissioned state, Trader if the ICP is in the commissioned state, other Trader if
there is a Trader switch in progress (new or withdrawal), MEP if the ICP is in the commissioned
state, Proposed MEP if there is an MEP switch in progress) and generates notifications for
them, if the settings of their notification parameters indicate they require them.
Data outputs:
89
Version 22.24
 New Network event and/or Address event and/or Status event and/or Pricing event with
the associated audit trail information.
 Notifications.
90
Version 22.24
Sub-process: DM-030 Correct Distributor information
Code references: Clauses 11.2, 11.7 and 11.8, and clauses 7 and 12 to 20 of Schedule
11.1 of the Code
Dependencies:
Description:
The Distributor corrects values of attributes entered incorrectly in one or more existing events
recorded for an ICP.
1. Distributors are solely responsible for maintaining the network, Address and Pricing
information.
2. Corrections may be made to both historical and current events.
3. More than one event can be corrected at the same time.

4. The Distributor may not correct the Status attribute of a Status event for an ICP, other than the
Status Reason of a decommissioned Status event.
5. Distributors may only correct events that were input during their period of responsibility.
6. Whenever a new value of an attribute is assigned, even if it is a correction of an existing
attribute, a new event must be created to show the correct situation. The original event is also
marked as being replaced. The new event then becomes the only active event for that Event
Date. The original replaced event must also identify the new event that replaced it.
7. An event must not be corrected if that would invalidate other prior events. Reconciliation Types
that would change the type of ICP cannot be changed.
8. There must be no automatic inheritance of attribute values. Whenever the value of an attribute
needs to change, a value must be provided, at least for every mandatory attribute of the
associated event.
9. If more than one event is corrected at the same time, the Event Dates of each event may be
different.
10. It must be possible for Distributors to revert ICPs with a Status of ready or distributor to a
Status of new by blanking out required attributes on existing events, eg by updating a Pricing
event with a blank loss category. (Note that this function must be able to be performed
‘historically’, ie prior to the latest Event Date.)
11. Once the ICP has been assigned to a Trader, no further notifications must be sent to any
Trader proposing to trade at the ICP.
91
Version 22.24
Data inputs:
One or more of:
 Network event;
 Pricing event;
 Address event; or
 Status event.
The corrected attributes must be provided by submitting ‘complete’ events, ie with all the other
mandatory attributes for the event. See sub-process DM-020 for details of the mandatory attributes
per event corrected.
Processing:
System
3. Replaces the incorrect events and inserts the corrected ones.

4. Completes the audit trail information for each inserted and each replaced event.
5. Evaluates who the affected parties are for each inserted and replaced event (Distributor,
Proposed Trader if the ICP is in the pre-commissioned state, Trader if the ICP is in the
commissioned state, other Trader if there is a Trader switch in progress (new or withdrawal),
MEP if the ICP is in the commissioned state, Proposed MEP if there is an MEP switch in
progress) and generates notifications to them, if their notification parameters require it.
6. Generates acknowledgements to the Distributor for each event inserted and replaced.
Data outputs:
 New Network event and/or Address event and/or Status event and/or Pricing event with the
associated audit trail information.
 Updated old Network event and/or Address event and/or Status event and/or Pricing event with
the associated audit trail information.
 Notifications.
92
Version 22.24
Sub-process: DM-040 Reverse Distributor information
Code references: Clauses 11.2, 11.7 and 11.8, and clauses 7 and 12 to 20 of Schedule
11.1 of the Code
Dependencies:
Description:
The Distributor reverses one or more existing events that have been input in error.
1. Distributors are solely responsible for maintaining the network, Address and Pricing
information.
2. Both historical and current events may be reversed.

3. Distributors can only reverse a Status event that sets the Status to decommissioned.
4. Distributors can only reverse events that are within their period of responsibility.
5. An event may not be reversed if that would invalidate a later event, e.g. a reversal of a Status
event that set the Status to inactive that immediately precedes a decommissioning (ie Status
event that set the Status to decommissioned) must be prevented.
6. A reversal must mark the reversed event as reversed in the audit information of the event.
7. If more than one event is being reversed, the Event Dates of each event may be different, ie
multiple concurrent reversals for one ICP are allowed.
Data inputs:
Selection of one or more of the following events for reversal:
 Network event;
 Pricing event;
 Address event; or
 Status event.
Processing:
System
1. Validates that the Distributor is permitted to reverse the event(s) selected.
2. Reverses the event(s).
93
Version 22.24
3. Generates a Status event if necessary to maintain the integrity and consistency of the ICP’s
information. For instance, if the ICP was initially created in the ready state and an event was
reversed that would cause the ICP to revert to the new state, eg reversal of a Pricing event,
then the system would need to generate a Status event to reflect this.
4. Completes the audit trail information for each event reversed.

5. Evaluates who the affected parties are for each event reversed (Distributor, Proposed Trader if
the ICP is in the pre-commissioned state, Trader if the ICP is in the commissioned state, other
Trader if there is a Trader switch in progress (new or withdrawal), MEP if the ICP is in the
commissioned state, Proposed MEP if there is an MEP switch in progress) and generates
notifications to them, with reference to the notification parameters.
6. Generates acknowledgements to the Distributor for each event reversed.
Data outputs:
 Updated old Network event and/or Address event and/or Status event and/or Pricing event
with the associated audit trail information.
 Notifications.
94
Version 22.24
3.2 ICP event maintenance – Trader

Sub-process: RA-010 Trader becomes responsible for an ICP – Initial Assignment
Process: Trader becomes responsible for an ICP
Participants: Traders
Code references: Clauses 11.18 and 9 to 20 of Schedule 11.1 of the Code
Dependencies: RM-030
Description:
A Trader becomes responsible for an ICP for the first time by providing Trader and Status Event
information for an ICP, so that the Trader is recorded in the registry as being responsible for the
ICP.
1. A Trader can accept responsibility for an ICP only if the ICP is in the ready state.
2. In order to accept responsibility for an ICP, a Trader must provide the information about an ICP
which includes the Proposed MEP and reconciliation information (in the Trader event) and the
electrically connected status (in the Status event). Each event must have the same Event
Date.
3. The Event Date on which the Trader accepts responsibility must be on or after the Event Date
of the latest ready Status event.
4. A Trader can only accept responsibility for an ICP to itself.

5. A Trader can only accept responsibility if they are not in a Trader Default situation
6. The initial process set out above can only be used the first time a Trader accepts responsibility
for an ICP. All subsequent changes to the Trader who is responsible for an ICP must be
performed via a switch.
7. The Trader may update the initial assignment events. On update all initial assignment
validations are re-applied as well as the business rules that apply when Trader information is
corrected (see RM-030).
8. On initial assignment there will be no metering records therefore a valid (not null) Proposed
MEP will cause the MEP switch in progress status to be set on.
Refer to Appendix 7 for guidance on the MEP participant identifiers of MNON and MREM. These
should not be notified to the registry as a MEP participant identifier by traders
Data inputs:
95
Version 22.24
At least the mandatory attributes of all the three Trader events:
 Trader event;
 Status event.
The mandatory attributes are:
96
Version 22.24

optional
Trader event:
Event Date DD/MM/YYYY M/O Mandatory for an initial assignment.

If this value is missing (null) then no
Trader event information is processed
(even if provided).
Trader Char 4 M Can only be input on the initial Trader

acceptance of responsibility (initial
assignment) and can be input only by
the Trader accepting responsibility.
Profile Char 25 M There may be multiple Profiles at an

ICP each separated by a space. All
must be available to the Trader on the
Event Date.
Submission type HHR Char 1 M Y/N. Can only be set to ‘Y’ if:
a) There is a Metering type of HHR
applicable at the Event Date; or
b) There is no applicable metering
event; or
c) The ICP contains a Profile code
that is classified as half hourly
(commences with the letter “H”)
except if the sole half hourly code
is “HHR” or “HSL”.
Submission type NHH Char 1 M Y/N. Must be set to Y if Submission

Type HHR = N.
ANZSIC Char 7 M/O A valid code from a list of Australian

and New Zealand Standard Industrial
Classification codes stored in the
registry reference tables with an
additional code “000000” to indicate a
residential consumer. See SD-020.
Optional only if ICP has a
Reconciliation Type of ‘SB’.
97
Version 22.24
Proposed MEP Char 4 M/O Valid Participant Identifier.

Participant Identifier Can only be optional/missing on initial
assignment and only if the ICP Status
is inactive, or in general, it can be
missing if the UNM Flag is “Y” and
there have never been any metering
components recorded for this ICP i.e. it
has always been a solely unmetered
ICP.
UNM Flag Char 1 M Y/N.
Daily Unmetered kWh Char 6 O Mandatory if UNM Flag = Y. Value

must be decimal (to three decimal
places) or ‘ENG’ if the load is profiled
accordance with profile class 2.1
Unmetered Load Details Char 50 O

– Trader
Reversal Indicator - Char 1 O Used in RM-010 and RM-040 only. R –

Trader event reverse or null - insert.
Status event:
Event Date DD/MM/YYYY M/O Mandatory for an initial assignment and

must be the same as the Trader
event’s Event Date.
If this value is missing (null) then no
Status Event information is processed
(even if provided).
ICP Status Char 3 M Active or inactive only (code only).

Can only be set to active if there is a
Proposed MEP at the Event Date or the
UNM Flag is “Y” at the Event Date.
Status Reason Numeric 2 M/O Mandatory if ICP Status inactive. Valid

Status Reason codes are 04 to 12.
Reversal Indicator - Char 1 O Used in RM-010 and RM-040 only. R –

Status Event reverse or null - insert.
Example:
HDR,RQRETMAINT,RETA,RGST,08/08/2007,09:19:15,1,initial assign
DET,9999999999AB123,01/01/2009,TraderUserRef,RETA,MXP,N,Y,1234567,META,Y,ENG,Unmtr
LoadDetail,,01/01/2009,StatusUserRef,01,06,
98
Version 22.24
Processing:
System
2. Checks the Trader is not in a Trader Default situation
3. Creates the appropriate events with the attribute values input by the Trader.
4. Completes the audit trail information for each event created.
5. Determines who the affected parties are for each inserted event (Distributor, Trader and
Proposed MEP) and generates notifications to them, with reference to their notification
parameters.
6. Generates acknowledgements to the Trader for each event created.

7. If a valid Proposed MEP Identifier has been submitted, sets the ICPs MEP Switch in progress
status on.
Data outputs:
 A Reconciliation Trader, Metering and Status event each with the associated audit trail
information
 Notifications.
 MEP Switch in progress status.
99
Version 22.24
Sub-process: RM-010 Trader cancels the initial assignment
Process: Trader reverses the initial assignment
Code references: Clauses 11.7, 11.8, 11.18 of the Code
Dependencies: RA-010
Description:
A Trader reverses its initial acceptance of responsibility for an ICP.
1. A Trader may only reverse its own initial assignment for an ICP.
2. The reversal may not occur if there are any non-reversed MEP input events for the ICP or
any additional non-reversed events of other types (including Distributor input events) with
Event Dates after the initial assignment.
3. The reversal may not occur if there is a switch in progress for the ICP.
Data inputs:
Selection of the initial assignment (or its Trader event) or the input of the matching Event Date of
the Trader event with the Trader event’s Reversal Indicator set to “R”. See RA-010 for the format.
Processing:
System
1. Validates that the initial assignment can be reversed by the Trader.
2. Reverses the Trader and Status events of the initial assignment, if a match is found.
3. Completes the audit trail information for each of the reversed events.
4. Determines the affected parties for each reversed event (Distributor, Trader and Proposed
MEP) and generates notifications to those that require them.
5. Generates acknowledgements to the Trader for each of the reversed events.

6. Determines if a valid Proposed MEP Identifier was submitted in the initial assignment and sets
the ICPs MEP Switch in progress status off.
Data outputs:
Reversal of initial assignment events – Trader and Status events each with updated audit trail
information.
Notifications.
Acknowledgements.
MEP Switch in progress status.
100
Version 22.24
Sub-process: RM-020 Add new Trader information
Process: Trader updates information about an ICP
Code references: Clauses 11.7, 11.14, 11.18, and clauses 9 to 20 of Schedule 11.1
Description:
The Trader adds one or more new events to an ICP. The event(s) may either represent a change to
the information stored on the registry in respect of the ICP, e.g. a new MEP, or may be information
that should have been entered previously but was missed. The event is not for an existing Event
Date.
1. Traders are solely responsible for updating Trader event information. They also share the
responsibility of maintaining the Status event with the Distributor.
2. Traders may only insert new Status events with Status values of active or inactive
3. At a minimum, all mandatory attributes of an event must be provided; no attribute values may
be inherited from prior events.
4. Traders may only insert events with Event Dates that are within their period of responsibility.
5. Traders may only insert events with their own Participant Identifier as the value of the Trader
attribute.
6. Events cannot be inserted prior to the date on which the first Trader accepted responsibility for
of the ICP.
7. Events cannot be inserted for Event Dates after the date of decommissioning.
8. An event must not be inserted if that would invalidate other prior events.
9. It must be possible to insert more than one event at the same time.
10. A Trader cannot insert a new Proposed MEP attribute (ie. change it) in a Trader event where
the Event Date is in the period of responsibility of a different MEP that is not the current MEP.
The period of responsibility for an MEP is the period on and between the Event Date of their
first population of Metering Event data until the Event Date of the next MEPs first population of
their Metering event data. However, where there is no ‘next MEP’ then an event with a new
Proposed MEP is permitted provided this Trader event has the latest Event Date (there are no
Trader events with later Event Dates). To clarify, a Trader cannot input a new Proposed MEP
attribute (ie. change it to a different MEP code) in a new Trader event which is not the latest.
11. A Trader cannot submit a new Proposed MEP in a Trader event where its Event Date is on or
before the latest Event Date of any Metering Event; unless approved by the Authority (refer to
Sub-process MM-040).
101
Version 22.24
12. A Trader cannot submit a new Proposed MEP in a Trader event when there is a Trader switch
in progress.
13. If more than one event type is being inserted, the Event Dates of each event type may differ. It
is possible to add information for just one event type ie. either the Trader event or the Status
event.
14. If a new Proposed MEP Identifier has been submitted, the ICPs MEP Switch in progress status
is set on.
Refer to Appendix 7 for guidance on the MEP participant identifiers of MNON and MREM. These
should not be notified to the registry as a MEP participant identifier by traders
Data inputs:
One or more of:
 Trader event; or
 Status event.

See sub-process RA-010 for the format.
Processing:
System
2. Checks that the Trader is allowed to make this change.
3. Adds the events supplied by the Trader.

4. Completes the audit trail information for each event added.
5. Determines the affected parties for each event inserted (Distributor, Trader, other Trader if
there is a Trader switch in progress (new or withdrawal), MEP, Proposed MEP if there is an
MEP switch in progress) and generates notifications for those who require them.
6. Generates acknowledgements to the Trader for each event added.

7. Determines whether a new Proposed MEP Identifier has been submitted and then the ICPs
MEP Switch in progress status is set on.
Data outputs:
 New Trader event and/or Status event with the associated audit trail information.
 Notifications.
102
Version 22.24
Sub-process: RM-030 Correct Trader information
Code references: Clauses 11.2, 11.7, 11.14, 11.18, and 9 to 20 of Schedule 11.1 of the
Code
Description:
The Trader corrects information entered incorrectly in respect of one or more existing events
associated with an ICP.
1. Traders are solely responsible for maintaining the Trader event and active or inactive
status information.
2. Traders may only update Status events to have Status values of active or inactive.
3. It must be possible to correct more than one event type at the same time (Trader and
Status). It is possible to correct information for just one event type ie. either the trader
event or the Status event.
4. At least all mandatory attributes of an event must be provided. No attribute values should
be automatically inherited from prior events.
5. Traders can only correct events that are within the period in which the Trader was
responsible for the ICP.
6. It must be impossible for the Trader to change the Trader attribute of the Trader event to
another Trader’s Participant Identifier.
7. An event must not be corrected if that would invalidate other prior events.
8. A Trader cannot correct the Proposed MEP attribute (ie. change it) in a Trader event where
the Event Date is in the period of responsibility of a different MEP. The period of
responsibility for an MEP is the period on and between the Event Date of their first
population of metering event data until the Event Date of the next MEPs first population of
their metering event data. However where there is no ‘next MEP’ then a correction with a
different Proposed MEP is permitted provided this Trader event has the latest event date.
To clarify, a Trader cannot correct a Proposed MEP attribute (ie. change it’s value) in a
Trader event which is not the latest.
9. A Trader cannot correct a new Proposed MEP in a Trader event where its Event Date is on
or before the latest Event Date of any Metering Event, or in the case of an initial
assignment Trader event, where there are any Metering Events for the ICP.
10. A Trader cannot correct a Proposed MEP attribute (ie. change it) in a Trader event when
there is a Trader switch in progress.
103
Version 22.24
11. The incorrect event must be logically replaced by the correct event and the audit details of
the incorrect event must be updated to identify the correct event.
12. If more than one event type is being corrected, the Event Dates of each event type may be
different.
13. If a new Proposed MEP Identifier has been submitted, sets the ICPs MEP Switch in
progress status on.
Data inputs:
One or more of:
 Trader event with new attribute value(s); or
 Status event with new attribute value(s).

Processing:
System
2. Checks that the Trader is allowed to make this change.

3. Replaces the incorrect events - where there is a matching Event Date - and inserts the
corrected ones.
4. Completes the audit trail information for each inserted and each replaced event (if any).
5. Evaluates who the affected parties are for each inserted and replaced event (Distributor,
Trader, other Trader if there is a Trader switch in progress (new or withdrawal), MEP, Proposed
MEP if there is an MEP switch in progress) and generates notifications to them, if their
notification parameters require it.
6. Generates acknowledgements to the Distributor for each event inserted and replaced.
7. Determines whether a new Proposed MEP Identifier has been submitted and then the ICPs
MEP Switch in progress status is set on.
Data outputs:
 New Trader event and/or Status event with the associated audit trail information.
 Updated old Trader event and/or Status event each with their associated audit trail
information updated correctly, of any replacement.
 Notifications.
104
Version 22.24
Sub-process: RM-040 Reverse Trader information
Code references: Clauses 11.2, 11.7, 11.18, and clauses 9 to 20 of Schedule 11.1
Description:
The Trader reverses one or more existing events that have been input in error.
1. Traders are solely responsible for maintaining the Trader event and the active or inactive
status information.
2. Traders may only reverse Status events that have Status values of active or inactive.
3. Traders may only reverse events that happened within their period of responsibility.
4. An event must not be reversed if that would invalidate other prior events.
5. A Trader cannot reverse a Trader event that had a new Proposed MEP (at the time of the
submission) which effectively commenced an MEP switch that resulted in an acceptance of
responsibility notice being recorded in the system from the MEP (MN) and that resulted in
Metering events being loaded by that new MEP. To clarify, provided there are no
associated metering events then the Trader event that had a new Proposed MEP can be
reversed even though a MN acceptance was submitted.
6. A reversal must mark the reversed event as reversed in the audit information pertaining to
the event.
7. More than one event may be reversed at the same time.
8. Both historical and current events may be reversed.
9. If more than one event is being reversed, the Event Dates of each event may be different.
10. If the reversal cause a mismatch or removes an existing mismatch between the latest
Proposed MEP and the responsible MEP on the applicable Metering event then the MEP
switch in progress status needs to reflect the correct current state.
Data inputs:
Selection, or the matching Event Date input of an existing event but with a Reversal Indicator of the
event set to ‘R, of one or more of:
 Trader event; or
 Status event.
105
Version 22.24
Processing:
System
1. Validates that the Trader is permitted to reverse the event(s).

2. Reverses the event(s) where a match is found on Event Date.
3. Completes the audit trail information for each event reversed.

4. Determines the affected parties for each event reversed (Distributor, Trader, other Trader if
there is a Trader switch in progress (new or withdrawal), MEP, Proposed MEP if there is an
MEP switch in progress) and generates notifications for those who require them.
5. Generates acknowledgements to the Trader for each event reversed.

6. Determines whether the result of the reversal requires the MEP Switch in progress status to
change and sets it accordingly.
Data outputs:
 Reversed Trader event and/or Status event with the associated audit trail information
updated accordingly.
 Notifications.
106
Version 22.24
3.3 ICP event maintenance – MEP maintains

Metering installation information
Sub-process: MM-010 Add new metering information
Process: MEP maintains metering information
Participants: Metering Equipment Providers
Code references: Schedule 11.4
Dependencies:
Description:
The MEP, as indicated in the Trader event, inputs metering installation information for an Event
Date on or after the event date of the Trader event that first nominated them as the Proposed MEP.
1. A new Metering event can only be added to an ICP if the ICP has a Trader assigned (is in the
active or inactive state).
2. The addition of metering information requires the completion of, at least, all the mandatory
attributes in the Metering event for ALL installations, components and channels. No partial
additions of particular installations, components or channels are permitted as no attribute values
are automatically inherited from prior events. N.B. A submission for the same Event Date as an
existing Metering event will overwrite all the existing metering information with the new metering
information.
3. The Event Date of an insertion of metering information must be:
 within the MEPs period of responsibility for that ICP, or,

 on or after either
a. in the case of the first MEP of a new ICP (i.e. there is no active metering event),
the Event Date of the earliest contiguous Status event change to the Ready
state of the ICP preceding initial assignment, otherwise
b. the Event Date of the latest Trader event in which they were first nominated as
the Proposed MEP1 ,
where
 they have also sent an associated acceptance MEP Responsibility Notice (MN) to the
Registry for this ICP since and
 there are no Metering Events for a different MEP on or after the Event Date of their
proposed Metering Event and
 they are the latest Proposed MEP.
107
Version 22.24
(The period of responsibility is the period on and between the Event Date of their first population
of metering event data until the Event Date of the next MEPs first population of their metering
event data).
1It is possible that the Trader has inserted subsequent Trader events with other attribute
changes. The MEP should be permitted to insert metering information for Event Dates on or
after the initial/first Trader event where they were nominated provided the latest Trader event
still has their code as the Proposed MEP and all other conditions above are satisfied. For the
Event Date of an historical insertion see MM-040 Missing MEP Historical Insertion.
4. Maintenance can be undertaken of Metering events of an ICP whilst a Trader switch or an MEP
switch is in progress.
5. Notifications must be generated to all affected parties as at the Event Date (Distributor, Trader,
other Trader if there is a Trader switch in progress (new or withdrawal), MEP, Proposed MEP if
there is an MEP switch in progress).
6. An acknowledgement of the change is sent to the submitting MEP.
8. Audit logs must be recorded for all inserts and changes to Metering events.
9. Arrival of metering records for the Proposed MEP on the latest Trader event switches the MEP
switch in progress status off.
Data Inputs:
At least the mandatory attributes of the Metering event.
The mandatory attributes are:
Header Row:

optional
Record Type Char 1 M ‘H’ for header information for a new ICP
ICP Char 15 M Must be an existing ICP Identifier.
Metering Equipment Provider Char 4 M Must be the same as the Proposed Metering
Identifier Equipment Provider at the Event Date as indicated in
the Trader event of the ICP. Must also match the
Participant Identifier of the submitter.
Event Date DD/MM/YYYY M See Business Requirement 3 above.
User Reference Char 32 O Free text.

Number Of Installations Numeric 2 M There must be this many ‘I’ rows (interspersed with the
associated ‘M’ and ‘R’ rows) following this row for this
ICP in the submission.
108
Version 22.24

optional
For reversals this number will be zero when only the

Header row is required to be input. For all other
submissions this value must be >= 1.
N.B. When recording about metering component
removals ie. the component will be missing, there is
still a requirement to provide at least one ‘I’ row.
Reversal Indicator – Metering Char 1 O Only applies to reversals when this is set to ‘R’. N.B.
Event All lower level information will also be reversed and the
metering information of the prior event will then apply.
109
Version 22.24
Installation Row:

optional
Record Type Char 1 M ‘I’ for installation information.

ICP Char 15 M Must be same as the ICP in the prior ‘H’ record
Metering Installation Number Numeric 3 M A user-defined number identifying the installation
within the ICP. Must be unique within the ICP. Ideally
a sequential number starting from 1.
Metering Installation Location Char 50 M A 6 character code (can be 1 to 6 characters) from the
Code list of codes within the Registry that identifies the
location of the metering installation and, optionally,
concatenated with the New Zealand Transverse
Mercator 2000 (NZTM2000) GPS co-ordinates of the
metering installation. The format of the GPS co-
ordinates is:
&NZTM:E<easting location>:N<northing location>
Easting and Northing locations both have a format of

Numeric 7.3 where leading and trailing zeros are not
mandatory ie can be missing.
Example:SQ&NZTM:E1234567.123:N54321.95.
Where the GPS co-ordinates are provided, both

the easting and northing co-ordinates are
mandatory. A colon is used as the field delimiter
within the GPS co-ordinates descriptor and there
must be no spaces or commas. Where no GPS
co-ordinates are provided only the location code
must be present e.g. SQ.
ATH Participant Identifier Char 4 M/O A valid Participant Identifier and that has a role of
ATH. Mandatory if the Metering Installation
Certification Type is ‘F’.
Metering Installation Type Char 3 M ‘HHR’ or ‘NHH’ or ‘NON’. Must be ‘NON’ where the
Number Of Components = 0.
Metering Installation Char 1 M Interim (‘I) or Full (‘F).
Certification Type Note: Interim certification can only be used for an
event date prior to 01 April 2016 unless the
metering update is for the removal of all metering
components of all interim certified metering
installations of an ICP
Metering Installation DD/MM/YYYY M/O Mandatory if the Metering Installation Certification
Certification Date Type is ‘F’.
If entered cannot be greater than today.
110
Version 22.24

optional
Metering Installation DD/MM/YYYY M

Certification Expiry Date
Control Device Certification Char 1 M Y/N
Flag
Certification Variations Char 1 M ‘X’ - An exemption under the Act for the metering
installation applies; or
‘A’ - The alternate measuring transformer certification
process is used; or
‘N’ – None.
Certification Variations Expiry DD/MM/YYYY M/O Mandatory if Certification Variations is other than ‘N’.
Date
Certification Number Character 25 M/O Mandatory if the Metering Installation Certification
Type is ‘F’.
Maximum Interrogation Cycle Numeric 3 M In days. >= 0.
Lease Price Code Char 6 O Free text.
Number Of Components Numeric 2 M There must be this many ‘M’ rows (interspersed with
the associated ‘R’ rows) following this row for this ICP
in the submission. >=0. If 0 then Metering Installation
Type = ‘NON’ and there will be no Channel rows ie. ‘R’
rows.
111
Version 22.24
Meter/Component Row:

optional
Record Type Char 1 M ‘M’ for meter information

ICP Char 15 M Must be the same as the ICP in the prior ‘I’ record.
Metering Installation Number Numeric 3 M Must be the same as the Metering Installation Number
in the prior ‘I’ record.
Metering Component Serial Char 25 M Identifier of meter. Validated by system to be unique
Number within the ICP.
Metering Component Type Char 1 M M - Meter, C - CT, V - VT, D - Data Storage Device,
L- Control Device
Meter Type Char 3 M/O HHR/NHH/PP. Mandatory where Metering
Component Type = M.
Can only be assigned as:
- NHH if the Metering Installation Category is
1 or 2.
- PP if the Metering Installation Category is 1.
HHR can be assigned for any Metering Installation
Category value.
AMI Flag Char 1 M Y/N
Metering Installation Numeric 1 M/O 1 – 5. Mandatory where Metering Component Type =
Category M. The metering category for the metering
installation that the component is certified in.
Compensation Factor Numeric 6.3 M Maximum value is 999999.999. Where the Metering
Components Type is M (meter) the value must
be greater than zero.
Owner Char 6 O If the Owner is a participant then their valid 4 character
Participant Identifier otherwise free text > 4 characters.
Removal Date DD/MM/YYYY O If input must be the same as the Event Date.
Number of Channels Numeric 3 M Total number of channels on the component. There
must be this many ‘R’ rows immediately following this
row. >= 1 for Metering Component Types of M, D and
L otherwise must be zero ie. no Channel information is
permitted to be input.
Channel Row:

optional
Record Type Char 1 M ‘R’ for meter register/channel information

ICP Char 15 M Must be same as the ICP in the prior ‘M’ record
Metering Installation Number Numeric 3 M Must be same as the Metering Installation Number in
the prior ‘M’ record.
112
Version 22.24

optional
Metering Component Serial Char 25 M Must be same as the Metering Component Serial
Number Number in the prior ‘M’ record.
Channel Number Numeric 2 M Must be a unique number within the metering
component assigned by the MEP.
Number of Dials Numeric 2 M/O Number of dials/digits (not recording fractions of a
unit) on the meter’s registers. Valid values are
between 4 and 12. Mandatory where Metering
Component Type = M.
Register Content Code Char 6 M/O Valid register content code from the static reference
table stored in the registry. Mandatory where
Metering Component Type = M or D.
Period of Availability Numeric 2 M/O <=24. Minimum service hours per day that supply is
available for. Mandatory where Metering Component
Type = M or D.
Unit of Measurement Char 6 M/O Valid register/channel unit code from the static
reference table stored in the registry. Eg. kWh, kW,
kVA, kVArh. Mandatory where Metering Component
Type = M or D.
Energy Flow Direction Char 1 M/O Valid values are 'I' for injection and 'X' for exit.
Mandatory where Metering Component Type = M or
D.
Accumulator Type Char 1 M/O Valid values are ‘C’ for cumulative and ‘A’ for
absolute. Mandatory where Metering Component
Type = M or D.
Settlement Indicator Char 1 M Y/N.
Event Reading Numeric 12 O Must be less than what can be stored with the
Number of Dials. Optional, but mandatory if a
Removal Date is present in the associated
(parent) component level information.
Example:
HDR,RQMEPMAINT,RETA,RGST,08/08/2012,09:19:15,4,MEP load
H,9999999999AB123,META,1/01/2012,Myref,1,
I,9999999999AB123,1,BA,ATH1,NHH,F,3/12/2000,3/12/2015,N,N,,123456B,180,,1
M,9999999999AB123,1,44455Cv,M,NHH,N,1,1,HOwner,,1
R,9999999999AB123,1,44455Cv,1,5,UN,24,kWh,X,C,Y,
Processing:
System
113
Version 22.24
2. Summarises the metering information from the installation, meter/component and

register/channel attributes submitted to derive the metering summary attributes of the new
Metering event.
3. Summarises the Highest Metering Category on the installation level from the metering
component level information – Metering Installation Category attribute - applicable for the
installation.
4. Creates the appropriate events with the attribute values input by the MEP and derived by the
system (Summary level information).
5. Completes the audit trail information for each Metering event created.
6. Determines who the affected parties are (Distributor, Trader, other Trader if there is a Trader
switch in progress (new or withdrawal), MEP, Proposed MEP if there is an MEP switch in
progress) and generates notifications to them, with reference to their notification parameters.
7. Generates acknowledgements to the MEP for each event created.

8. Determines whether to switch off the MEP switch in progress status for the ICP by examining
the submitting MEP against the Proposed MEP on the applicable Trader event.
Data Outputs:
Metering events with the associated audit trail information.
Notifications.
Acknowledgements.
ICP MEP switch in progress status.
114
Version 22.24
Sub-process: MM-020 Correct metering information
Dependencies:
Description:
The MEP, as indicated in the Trader event, corrects metering installation information of attributes
previously submitted.
1. A correction to a Metering event can only be made to an ICP if the ICP has a Trader assigned
(is in the active or inactive state).
2. The correction of metering information requires the completion of, at least, all the mandatory
attributes in the Metering event for ALL installations, components and channels. No partial
corrections of particular installations, components or channels are permitted as no attribute
values are automatically inherited from prior events. N.B. A submission for the same Event
Date as an existing Metering event will overwrite all the existing metering information with the
new metering information.
3. The Event Date of an update of metering information must be within the MEPs period of
responsibility for that ICP. (The period of responsibility is the period on and between the Event
Date of their first population of metering event data until the Event Date of the next MEPs first
population of their metering event data, if one exists) ie. only the MEP that input the event can
change it.
5. Notifications must be generated to all affected parties as at the Event Date. The affected
parties are (Distributor, Trader, other Trader if there is a Trader switch in progress (new or
withdrawal), MEP, Proposed MEP if there is an MEP switch in progress).

8. Audit logs must be recorded for all inserts and changes to Metering events.
Data Inputs:
At least the mandatory attributes of the Metering event. See MM-010 for the format and mandatory
attributes.
Processing:
115
Version 22.24
System

2. Summarises the metering information from the installation, meter/component and
register/channel attributes submitted to derive the metering summary attributes of the changed
Metering event.
3. Summarises the Highest Metering Category on the installation level from the metering
component level information – Metering Installation Category attribute - applicable for the
installation.
4. Creates the appropriate events with the attribute values input by the MEP and derived by the
system (Summary level information).
5. Completes the audit trail information for each changed Metering event, inserted and replaced.
6. Determines who the affected parties are for each inserted and replaced event (Distributor,
Trader, other Trader if there is a Trader switch in progress (new or withdrawal), MEP, Proposed
MEP if there is an MEP switch in progress) and generates notifications to them, with reference
to their notification parameters.
7. Generates acknowledgements to the MEP for each event updated.
Data Outputs:
Metering events with the associated audit trail information – for the new and replaced events.
Notifications.
Acknowledgements.
116
Version 22.24
Sub-process: MM-030 Reverse metering information
Dependencies:
Description:
The MEP, as indicated in the Trader event, reverses ie. removes metering installation information
previously submitted.
1. A reversal of a Metering event can only be made to an ICP if the ICP has a Trader assigned (is
in the active or inactive state).
2. The reversal of metering information requires the completion of only the Header row of the
metering information submission described in MM-010. The reversal is indicated by an ‘R’ in
the Reversal Indicator, if the submission is by file. All lower level information will also be reversed
and the metering information of the prior event will then apply.
3. The Event Date of a reversal of metering information must be within the MEPs period of
responsibility for that ICP and must match the entry recorded in the Metering event (match on
Event Date) ie. only the MEP that input the event can reverse it. (The period of responsibility is
the period on and between the Event Date of their first population of metering event data until
the Event Date of the next MEPs first population of their metering event data, if one exists).
5. Notifications must be generated to all affected parties as at the Event Date (Distributor, Trader,
other Trader if there is a Trader switch in progress (new or withdrawal), MEP, Proposed MEP if
there is an MEP switch in progress).
8. Audit logs must be recorded for all reversals of Metering events.

9. Reversal of metering records may cause a mismatch between Proposed MEP on the latest
Trader event and the responsible MEP in the latest Metering event requiring the setting of the
MEP switch in progress status to on.
Data Inputs:
At least the mandatory attributes of the Metering event relating to reversals ie. only the Header row.
See MM-010 for the format and mandatory attributes.
Example:
117
Version 22.24
HDR, RQMEPMAINT,RETA,RGST,08/08/2012,09:19:15,1,MEP load

H,9999999999AB123,META,1/01/2012,Myref,0,R
Processing:
System
2. Completes the audit trail information for each Metering event reversed.
3. Determines who the affected parties are for each reversed event (Distributor, Trader, other
Trader if there is a Trader switch in progress (new or withdrawal), MEP, Proposed MEP if there
is an MEP switch in progress) and generates notifications to them, with reference to their
notification parameters.
4. Generates acknowledgements to the MEP for each event reversed.
5. Determines whether to set the MEP switch in progress status on for the ICP by examining the
Proposed MEP on the applicable Trader event.
Data Outputs:
Metering event (updated with a reversal indicator) with the associated audit trail information.
Notifications.
Acknowledgements.
ICP MEP switch in progress status.
118
Version 22.24
Sub-process: MM-040 Missing MEP Ownership Historical Insertion

Process: MEP Maintains Metering Information
Participants: Trader, Metering Equipment Provider, Authority
Code References: 11.18A, Schedule 11.4 clauses 1 and 2
Dependencies: RM-020 MN-010 MM-010
Description:
This sub-process requires approval from the Authority before being executed by the Registry
Manager and is not a business as usual occurrence.
It is used only to correct the result of a breach of the Code when an MEP for an ICP has been
unable to provide metering information to the Registry for the following reasons:
 a Trader failed to nominate the MEP before another MEP assumed responsibility; or
 the MEP switch process was not completed before another MEP assumed responsibility; or
 the Event Date of the Trader event that first nominated the MEP was later than the effective
date that the MEP assumed responsibility.
The Trader and the associated MEP provide their information in separate files to the Registry
Manager. The system then validates the information and generates all the appropriate events and
associated acknowledgements, notifications and audit trails as described in sub-processes RM-
020, MN-010 and MM-010.
N.B. This sub-process can only be used to insert an MEP Metering event historically for an Event
Date before the Event Date of the Metering event provided by the next MEP.
1. The MEP must obtain approval from the Trader and the Authority prior to the Registry Manage
processing the Trader and MEP files.
2. The Registry Manager must not process the Trader and MEP files until it has received
authorisation from the Authority to process the files.
3. The Registry Manager must inform the Trader and MEP of the outcome of the processing their
files.
4. The Registry ensure that any insertion maintains the integrity of existing events and must ensure
that an insertion does not:
 overwrite any existing Metering event or MN transaction, or
 change a Trader’s period of responsibility, or
 replace the Trader Event that commenced a completed MEP switch, or
 interrupt any existing MEP’s period of responsibility by inserting between two successive
Metering events for the same MEP.
5. It must be possible for an insertion to be the initial Metering for an ICP
Data inputs:
MEP metering information file:
119
Version 22.24
MM-010 format and validation rules, with the Event Date validation replaced by the following:
Name Type Mandatory Validation

/optional
Event Date DD/MM/YYYY M Event Date of the MEP.

It must be on or between the ICPs
Nomination Date in the Trader nomination
file and prior to the Event Date of the ICPs
next Metering event occurring after the
Nomination Date.
It must not match the Event Date of an
existing Metering event of the ICP.
Trader nomination file:

Name Type Mandatory Validation
/optional
ICP Number Char 15 M Existing ICP number.

There must not be a current Trader switch in
progress for the ICP.
There must be an entry in the MEP metering
information file for this ICP.
Trader Identifier Char 4 M Valid Trader Participant Identifier.

It must be:
 the Trader Participant Identifier of the
Trader that submits the file, and
 the Trader responsible for the ICP as at
the Nomination Date.
Nomination Date DD/MM/YYYY M Nomination Date of the MEP.

It must be between the ICPs Event Date of
another MEP’s final Metering event (the one
immediately prior to it losing responsibility to
another MEP) and before the Event Date of
the Trader event that commenced an MEP
switch which resulted in a change of MEP
responsibility to the next MEP. N.B. The next
MEP can be the same as the MEP being
inserted.
Proposed MEP Char 4 M Valid MEP Participant Identifier.

Identifier It must:
120
Version 22.24
 be the MEP Participant Identifier of the

MEP in the MEP metering information
file for the same ICP, and
 not be the same as the responsible MEP
of the ICP on the Nomination Date.
Example:
HDR,MTRINSERT,RETA,RGST,15/05/2016,11:00:00,3
DET,9999999999AB123,RETA,12/04/2016,META
DET,9999999999AB345,RETA,13/04/2016,META
DET,9999999999AB678,RETA,16,04.2016,META
Note: The information in the Trader nomination and MEP metering information files do not need to
be supplied in ICP identifier order, however, only one entry is permitted per ICP.
Processing:
System:
1) Validates the records in the Trader nomination file.
2) Ensures there is only one record for any ICP in the Trader nomination file.
3) Validates the MEP metering information file using the modified Event Date validation and the
other validations from MM-010.
4) Ensures there is only one record for any ICP in the MEP metering information file.
5) Checks that each record in the Trader nomination file has a matching record for the same ICP
in the MEP metering information file.
6) For each record in the Trader nomination file and its corresponding record in the MEP metering
information file:
a) If there is an existing Trader event for an ICP where its Event Date matches the
Nomination Date, reverses the existing Trader event and creates a new Trader event on
behalf of the Trader who submitted the Trader nomination file, nominating the Proposed
MEP with:
i) the Proposed MEP Identifier from the Trader nomination file, and
ii) the User Reference of “MEP Historical Correction”, and
iii) all the remaining fields taken from the reversed Trader event.
b) If there is no existing Trader event for the ICP matching the Nomination Date, creates, on
behalf of the Trader who submitted the Trader nomination file, a Trader event nominating
the Proposed MEP with:
i) Event Date = Nomination Date supplied in the Trader nomination file,
ii) Proposed MEP Identifier = Proposed MEP supplied in the Trader nomination file,
iii) the User Reference = “MEP Historical Correction”,
iv) all the remaining fields taken from the Trader event applicable as at the Nomination
Date
and inserts the event.
c) Creates an MN acceptance transaction on behalf of the Proposed MEP with:
121
Version 22.24
i) the MEP Identifier = the Proposed MEP,

ii) the Transfer Date = the Nomination Date,
iii) the Responsibility Indicator = “A” (accepted),
iv) the Decline Advisory Code = null,
v) User Reference = “MEP Historical Correction”
and inserts the MN acceptance transaction.
N.B. If there is an existing MN acceptance transaction for the same Event Date, the system
will allow multiple MNs to exist.
d) Inserts a Metering event on behalf of the MEP who submitted the MEP metering
information file using the validated MEP metering information,
7. Generates the standard acknowledgements and notifications to affected participants, as per the
existing notification rules, for all the events and MN transactions created.
N.B. Updates for large files (>1000 ICPs) may require process scheduling by mutual agreement
between the Authority and the Registry Manager.
Registry Manager:
 Sends emails to the Trader and MEP to inform them that the MEP insertion processing has
completed and to advise them of the results of the update. The email address used is the
one specified for the delivery of MEP Historical Correction information.
 Sends emails to Participants affected by filtering-up changes of MEP responsibility
occurring in the Traders periods of responsibility
Data outputs:
 New or reversed Trader events nominating the MEP
 New MN acceptance notifications
 New Metering events
 Audits for each created event
 Notifications
 Acknowledgements
Email examples:
N.B. Suggested wording only
Email 1: Notify nominating Trader and MEP of the results of the insert
Heading: MEP Metering Insertion
Message Text: The processing of the supplied Metering Insertion file is complete and results are in
the attached file. Please carefully review the result of the updates. If you have any questions or
issues please contact the Registry Manager.
Email 2: Notify affected participants that MEP responsibility has been changed during their period
of responsibility
Heading: Change in MEP responsibility due to historical Metering Insertion
122
Version 22.24
Message Text: Processing of a Metering Insertion file has completed, The attached list of ICPs had
a Metering Event inserted which resulted in a change of MEP during your period of responsibility.
Your overnight notification file will include the Metering event attributes that have been changed
If you have any questions or issues please contact the Registry Manager.
123
Version 22.24
3.4 Switching
Sub-process: RS-010 Make switch request (NT)
Process: Traders switch ICP
Code references: Clauses 1 to 16 and 22 of Schedule 11.3 of the Code
Dependencies: MP-020, PR-030
Description:
The gaining Trader initiates a switch by sending a switch request message (NT) to the registry. The
registry then forwards the request on to the losing Trader. Depending on the gaining Trader’s
notification parameter settings, the system can send a snapshot PR-030 report, for every ICP being
switched, showing the current state of each event type of the ICP.
Trader Default Situation
A Trader in a Trader Default situation may not make a Switch Request to the Registry to gain
responsibility for an ICP
1. Only the gaining Trader can send an NT to the registry.

2. The current Status of an ICP as defined by the most recent Status event must be either
inactive or active and must have an associated Metering event or have solely
unmetered load.
3. There must not already be a Trader switch in progress for the ICP.
4. The switch type can be either a MI (move in switch) or TR (standard Trader switch) or a HH
5. Assignment of the switch type in an NT must conform with the following rules:
a) If the latest Metering event (summary level) has an AMI Flag of “Y”:
i. and if the Highest Metering Category is 1, 2 or 9, then the switch type must be MI
or TR.
ii. and if the Highest Metering Category is 3, 4 or 5, then the switch type must be HH.
b) If the latest Metering event (summary level) has an AMI Flag of “N”:
i. and if the Highest Metering Category is 1, 2 or 9 then
 if the Submission Type will not change* then the switch type must be MI or TR.
ii. and if the Highest Metering Category is 3, 4 or 5, then the switch type must be HH.
Any switch type may be submitted for all other combinations of no metering, AMI Flag,
Submission Type change* and Highest Metering Category i.e. that is not covered by a) or b)
above.
124
Version 22.24
*Submission Type will/will not change refers to the assignment of this ICPs attributes -
Submission Type HHR and Submission Type NHH - by the system, once this switch has
completed (as per the processing logic in RS-050).
Submission Type will change when:
Current Submission Types Post CS Submission Types
HHR = Y and NHH = N (HHR = N and NHH = Y) or (HHR = Y and NHH = Y)
HHR = N and NHH = Y (HHR = Y and NHH = N) or (HHR = Y and NHH = Y)
HHR = Y and NHH = Y (HHR = Y and NHH = N) or (HHR = N and NHH = Y)
6. A Proposed Transfer Date must be provided if the switch type is MI or HH. The Proposed
Transfer Date must be after the initial assignment and after any other completed switches
which have not been withdrawn. The Proposed Transfer Date must be within the period that the
gaining Trader has an active role of ‘Trader’. Where the Proposed Transfer Date is not
provided, the gaining Trader must be currently active in the role of ‘Trader’.
7. The Address information provided on an NT must only be used by the losing Trader to confirm
that the new Trader has identified the correct ICP. It must not be used to update the registry.
8. An audit trail and an acknowledgement must be generated for the NT.
9. The NT must be forwarded by the registry to the losing Trader in a file in the same format as
input, and in accordance with their switch notify parameters.
10. An NT must not be corrected or reversed once it has been accepted by the registry; instead it
must be withdrawn.
11. Once the NT has been accepted, all online queries relating to the ICP in question must
highlight that a Trader switch is in progress.
12. As part of the NT message delivery and in accordance with the notification parameter settings
of the gaining Trader, the system may also provide, immediately (and only to) the gaining
Trader, a file containing the events ‘as at’ the Proposed Switch Date (or today’s date where the
Proposed Transfer Date is missing) and any events that have changed since that date for each
ICP. The format of this file is the snapshot version of PR-030 – Event Detail Report. The
report can be requested to be provided in csv or xml format which is a parameter setting within
the notify parameters process (MP-020). The name of this file will be the same as the NT
message with a file extension of “.eda”.
A Trader who is in a Trader Default situation may not submit an NT to the Registry
Data inputs:

NT (notice of transfer) attributes are as follows:
125
Version 22.24
Name Type Mandatory/ Description

optional
Record type Char 1 M Must be “P”
ICP Char 15 M
Requesting Trader Char 4 O New Trader participant identifier. The

Participant Identifier can be derived
by the system.
Confirmation Address Unit Char 20 O
Confirmation Address Char 25 O

Number/ RAPID number
Confirmation Address Street Char 30 O
Confirmation Address Char 30 O

Suburb
Confirmation Address Town Char 30 O
Confirmation Post Code Numeric 4 O
Confirmation Address Char 20 O Address Region must be a valid

Region Region as per Static Data table.
Confirmation Property Name Char 75 O
Proposed Transfer Date DD/MM/YYY M/O Mandatory if the Switch Type is MI or

Y HH.
The gaining Trader must be active in
the role of ‘Trader’ on the Proposed
Transfer Date or, if left blank, ‘as at’
todays date.
Switch Type Char 2 M Must be one of MI or TR or HH.
Proposed Profiles Char 25 M One or more Profiles separated by

spaces. Each one must be valid for
the requesting Trader on the
Proposed Transfer Date.
Proposed ANZSIC Char 7 O Valid consumer’s ANZSIC code,
Example:
HDR,RQSWITCHNT,RETB,RGST,16/07/2007,15:36:20,1,
P,9999999999AB123,RETB,Unit1,127,Peel
Street,Ohau,Twizel,9971,Canterbury,01/01/2009,MI,RPS MXP,A013100,NTSwitchUserRef
Processing:
126
Version 22.24
System

2. Checks that the requesting Trader is allowed to input the NT.
3. Checks the Trader is not in a Trader Default situation
4. Rejects an NT with errors and returns it to the sender with the reason for the rejection.
5. Updates each ICP to indicate that a Trader switch is in progress.
6. Keeps a copy of the NT and completes the audit trail information for it.
7. Delivers the NT to the current Trader either immediately or as part of a later batch in
accordance with that Trader’s switch notify parameters.
8. Deliver a snapshot PR-030 file to the new Trader, in accordance with their notify parameter
settings.
9. Generates an acknowledgement to the gaining Trader.
Data outputs:
 ICP updated to indicate that a Trader switch is in progress and the NT has been received.
 Stored copy of the switch request message and its associated audit trail information.
 NT to forward to the losing Trader.

 Acknowledgement.
127
Version 22.24
Sub-process: RS-020 Acknowledge switch request (AN)
Code references: Clauses 1 to 16 and 22 of Schedule 11.3 and Schedule 11.5 of the
Code.
Dependencies:
Description:
The losing Trader responds to a switch request by sending an acknowledgement notice (AN) to the
registry. The registry then forwards the notice to the gaining Trader.
1. Only the current Trader at an ICP being switched can send an AN message.
2. There must be a Trader switch in progress for the ICP and it must relate to the current Trader.
3. An AN must be sent for HH switch types but is optional for other switch types. A value must be
entered for the Expected Transfer Date for switch types of MI and TR. A transfer date must be
both later than the date the current Trader accepted responsibility for the ICP and any
completed switches that have not been withdrawn. The Expected Transfer Date must be within
the period that the gaining Trader has an active role of ‘Trader’. Where the Expected Transfer
Date is not provided, the gaining Trader must be currently active in the role of ‘Trader’.
4. Industry approved acknowledgement codes must be used in the AN.
5. An audit trail and an acknowledgement must be generated for the AN.

6. The AN must be forwarded by the registry to the gaining Trader in a file and in accordance with
its switch notify parameters.
7. Once accepted by the registry, an AN cannot be corrected or reversed.

8. An AN with an acknowledgement code indicating that the current Trader objects to the switch
does not mean the switch process must be stopped. This can only be done by withdrawing the
switch.
Data inputs:
AN (acknowledgement notice) attributes are:
Name Type Mandatory Description

/optional
Record type Char 1 M Must be “P”
ICP Char 15 M
128
Version 22.24
Trader Char 4 O Current Trader Participant Identifier (losing).

The Participant Identifier can be derived by the
system.
Response Code Char 2 M As defined by the Authority. Current values

are:
AA – acknowledge and accept
CO – contracted customer
MP – metering is pre-paid
MU – unmetered supply
OC – occupied premises
PD – premises electrically disconnected
AD – advanced metering.
TD – Trader Default. This code cannot be
used by Traders.
Expected DD/MM/YYYY M/O If the AN is in response to a switch type of MI

Transfer Date and TR then the Expected Transfer Date is
mandatory, or else optional.
User Reference Char 32 O Free text field.
Example:
HDR,RQSWITCHAN,RETA,RGST,10/07/2007,16:45:01,1
P,9999999999AB123,RETA,AA,01/01/2009,ANUserReference
Processing:
System

2. Checks that the AN was sent by the current Trader at the ICP and that there is an immediately
prior switch request (NT).
3. Rejects an AN with errors and returns it to the sender with the reason for the rejection.
4. Updates the progress of the switch for the ICP.

5. Keeps a copy of the AN.
6. Completes the audit trail information for the AN.

7. Delivers the AN to the gaining Trader either immediately or as part of a later batch in
8. Generates an acknowledgement to the current Trader.
129
Version 22.24
Data outputs:
 ICP updated to indicate what stage the switch process has reached, ie AN received.
 Stored copy of the acknowledgement notice and its associated audit trail information.
 AN to forward to the gaining Trader.
Exceptions:
130
Version 22.24
Sub-process: RS-030 Complete non-half-hour switch (TN) - Discontinued
Dependencies:
Description:
This message type will no longer be available post migration date but historical information
will be available to view and report on. Replaced by new switch transaction (CS). See RS-
050.
The losing Trader sends a transfer notification message (TN) to the registry in order to complete
either a standard non-half-hour switch (S) or a standard non-half-hour move switch (SM). The
registry then forwards the TN on to the gaining Trader. The TN provides the final premises,
metering and meter reading information to the gaining Trader.
1. Only the losing Trader can send a TN message.
2. All TN messages must be sent to the registry in a file; however, the system must also provide
an online view of the basic TN information, ie not all the TN information must be displayed.
3. There must be a prior switch request or acknowledgement notice present for the ICP and it
must relate to the switch.
4. The original switch request must have been for either a standard non-half-hour or standard
non-half-hour move switch (S, SM).
5. The registry must keep a copy of the TN for a minimum of 3 months.
6. An audit trail and an acknowledgement must be generated for the TN.

7. The TN must be forwarded by the registry to the gaining Trader in a file in the same format and
order as input, and in accordance with their switch notify parameters.
8. The TN must also be forwarded to the Distributor and Meter Owner (applicable at the actual
switch transfer date).
9. Once accepted by the registry, a TN cannot be corrected or reversed. The withdrawal sub-
process must be used instead.
131
Version 22.24
Data inputs:

TN (transfer notice) attributes are:

optional
Record type Char 1 M Must be ‘P’ – premises.
ICP Char 15 M ICP Identifier.
Trader Char 4 O Current Trader Participant Identifier (losing).

Derived by the system if left blank.
Actual Transfer DD/MM/YYYY M

Date
Relay Owner Char 6 O Owner of relays on premises.
Number Of Numeric 2 M Number of meters at ICP.

Meters
User Reference Char 32 O Free text field carried to history and audits.
For each meter: There must be exactly <number of meter>
rows of ‘M’ record types for this ICP. They will
be separated by intervening ‘R’ rows.
Record type Char 1 M ‘M’ – meter.
Last Read Date DD/MM/YYYY M Date meter was last physically read, eg
05/05/2002, or the last validated meter reading
if permanent estimate supplied.
Primary Metering Char 4 M Must be a valid Meter Owner.

Contact
Participant
Identifier
Meter Identifier Char 15 M Unique identifier of meter.
Meter Multiplier Numeric 3.3 M Multiplier (up to three decimal places) to

transform readings to actual usage. Checked
against the value of the Meter Multiplier Flag of
the Metering event applicable on the Actual
Transfer Date. If the Metering event Meter
Multiplier Flag is ‘Y’ then at least one of the
meter multipliers for this premise must have a
value other than unity, ie not 1.
132
Version 22.24

optional
Register Dials Numeric 2 M Number of dials/digits on the meter’s registers.

Valid values are between 4 and 12.
Meter Location Char 3 M Value must be one of those in the list of valid
Code meter location codes held by the registry.
Average Daily Numeric 6 M Value indicates average kWh per day for last
Consumption read period.
Key Held Char 1 M ‘Y’/’N’.

Indicator
Number Of Numeric 2 M Number of registers for this meter. The total

Registers number of registers for the premises (for this
ICP) must be greater than or equal to Meter
Register Count of the Metering event
applicable on the Actual Transfer Date. 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.
Meter Reader Char 50 O Free text. Optional.

Notes
For each There must be exactly <number of register>
register within
rows after each ‘M’ row.
the meter:
Record type Char 1 M ‘R’ – register.
Meter Identifier Char 15 M Unique identifier of meter. Must be the same

as in the preceding M record.
Register Number Numeric 2 M Sequential register number (identifier).
Register Content Char 6 M Valid register content code – see static data
sub-process, eg D—daytime only, N—night-
time only.
Period of Numeric 2 M/O Minimum service hours of supply per day.

Availability Required if register has controlled or inclusive
load (see register content codes – static data
maintenance sub-process).
Register Units Char 6 M Valid register unit – see static data

maintenance sub-process, eg kWh, kW, kVA,
kVArh.
133
Version 22.24

optional
Energy Flow Char 1 M Valid values are ‘L’ for load and ‘G’ for
Direction generation.
Register Reading Numeric 12 M Reading value for this register on this date.
Number of digits must not be greater than the
number of dials.
Actual or Char 1 M Indicates whether the read was an actual or

Estimate estimate. Valid values: (A)ctual, ie validated
meter reading, or (E)stimate, ie permanent
estimate.
Examples:
HDR,RQSWITCHTN,RETA,RGST,19/07/2007,14:48:34,3
P,9999999999AB123,RETA,01/01/2009,RETA,1,premises user ref
M,9999999999AB123,17/12/2008,,6677AB,,,,12.33,Y,1,MetrNotes
R,9999999999AB123,6677AB,12,,,,,,1234,A
A TN with 2 meters each with 2 registers:

HDR,RQSWITCHTN,CTCT,RGST,19/07/2007,14:48:34,5
P,12345678901AB123,GENE,18/07/2007,,1,100471481:001
M,12345678901AB123,15/07/2007,NGCM,501824,1.000,5, BA,554,N,3
R,12345678901AB123,501824,1,D,16,KWH,L,26699,A
R,12345678901AB123,501824,2,N,8,KWH,L,08444,A
M,12345678901AB123,15/07/2007,NGCM,501825,1.000,5, BA,374,N,3
R,12345678901AB123,501825,1,D,16,KWH,L,26699,A
R,12345678901AB123,501825,2,N,8,KWH,L,08444,A
Processing:
System
2. Checks that the TN is being sent by the losing Trader and that there is a switch in progress for
the ICP.
3. Rejects a TN with errors and returns it to the sender with the reason for the rejection.
4. Keeps a partial copy of the TN comprising the Actual Transfer Date, number of meters and
User Reference attributes and the Proposed Transfer Date from the original transfer request
(NT).
5. Generates an audit trail for the partial TN.
134
Version 22.24
6. Sends the complete TN to the gaining Trader either immediately or as part of a later batch in
7. Sends the complete TN to the affected Distributor and Meter Owner of the ICP. All TNs are
batched together in one file and delivered overnight.
8. Generates a Reconciliation event for the ICP, in order to effect the change in Trader, setting the
Event Date to be the Actual Transfer Date from the TN and taking the remaining reconciliation
attributes from the information in the original switch request (NT).
9. Updates the ICP so that there is no longer a switch in progress.

10. Reverses any Trader events that may have been input by the losing Trader prior to the start of
the switch process and that have Event Dates later than the Actual Transfer Date.
11. Completes audit trail information for each event inserted and reversed.
12. Generates an acknowledgement for the TN to the losing Trader.
13. Determines affected participants of each event insertion and reversal and generates
notifications to them, with reference to their notification parameters. Both Traders are classed
as affected participants.
Data outputs:
ICP updated to indicate the switch is no longer in progress.

Reconciliation event.
Possible reconciliation, metering and Status event reversals.
Partial copy of the TN and its associated audit trail information stored on registry for online query.
TN to forward to the gaining Trader, Distributor, and Meter Owner.
Notifications.
Acknowledgements.
135
Version 22.24
Sub-process: RS-040 Complete half-hour switch (TT) – Discontinued
Dependencies:
Description:
will be available to view and report on. Replaced by new switch transaction (CS). See RS-
050.
There will however be a change to this function required, to remove updates to Metering
events using this message type (required for the transition period).
A TT message is sent to the registry by the gaining Trader to complete a half-hour (H), half-hour
move (HM), non-half-hour to half-hour (NH) or half-hour to non-half-hour switch (HN). The TT
provides only information about the losing Trader and the gaining Trader. No meter reading
information or other final information is supplied to the old Trader.
1. Only the gaining Trader can send the TT for a switch in progress for the ICP.
2. There must be a prior AN present for the ICP and it must relate to the switch in progress.
3. The switch type on the original NT must have been either half-hour (H), half-hour move (HM),
non-half-hour to half-hour (NH) or half-hour to non-half-hour switch (HN).
4. The registry must keep a copy of the TT for a minimum of 3 months.
5. An audit trail and an acknowledgement must be generated for the TT.

6. The TT must be forwarded by the registry to the losing Trader in a file and in accordance with
their switch notify parameters.
7. A TT cannot be corrected or reversed once accepted by the registry. The withdrawal sub-
process must be used instead.
Data inputs:
TT (transfer notice) attributes are:
Name Type Mandatory/optional Description
Record type Char 1 M Must be ‘P’ – premises.
136
Version 22.24
Trader Char 4 O New requesting Trader Participant

Identifier. If blank, will be derived by
system.
Actual Transfer DD/MM/YYYY M Actual date transfer will occur (switch

Date Event Date).
Status Event Optional.

Information:
ICP Status Char 3 O Inactive (001) or Active (002). Required

only if current ICP Status needs to
change.
ICP Status Numeric 2 O/M If ICP Status of inactive is entered then

Reason a valid inactive reason code is required
(mandatory
See static data tables for valid values
Metering event Optional input; however, if one of the

Information:
following attributes is input then ALL
other attributes are required to be input
(ie are mandatory).
MEP Participant Char 4 O/M Valid MEP.

Identifier
Metering Numeric 1 O/M 0 to 6.

Category
Meter Type Char 1 O/M Y or N. At least one of the Meter Types

HHR must be Y.

NHH must be Y.

UNM must be Y.
Meter Type PP Char 1 O/M Y or N. At least one of the Meter Types

must be Y.
Advanced Char 1 O/M Y or N.

Metering
Infrastructure
137
Version 22.24
Daily Char 6 O/M Mandatory if one of the Meter Types is

Unmetered kWh Unmetered or Meter Register Count is
0. Value must be decimal (to 3 decimal
places) or ‘ENG’ if the load is profiled
accordance with profile class 2.1.
Unmetered Char 50 O/M Optional.

Load Details –
Trader
Meter Register Numeric 3 O/M 0 to 999. This is the number of half-

Count hour meters that are used in the
settlement process.
Meter Multiplier Char 1 O/M N(o) if all meters at the ICP have a
Flag multiplier of 1 or the ICP is unmetered,
otherwise Y(es).
Additional Optional.
Trader event
information:
Profile Char 25 O One or more Profiles separated by

spaces. Each one must be valid for the
Trader on the Actual Transfer Date. If
not provided then Profiles from the NT
will be used.
User Reference Char 32 O Free text field. Optional.

Example:
HDR,RQSWITCHTT,RETA,RGST,16/07/2007,13:14:00,1
P,9999999999AB123,RETA,01/01/2009,002,,MEPA,,N,Y,N,,,1.54,UnmtrLoadDetails,,,MXP
RPS,TTUserRef
Processing:
System
2. Checks that the TT was sent by the gaining Trader and that there is a prior AN sent by the
current Trader.
3. Rejects a TT with errors and returns it to the sender with the reason for the rejection.
4. Keeps a copy of the TT in the registry under the ICP.

5. Forwards the TT to the losing Trader either immediately or as part of a later batch in
138
Version 22.24
6. Generates a Trader event for the ICP in order to effect the change in Trader. The Trader
event’s Event Date is set to the Actual Transfer Date of the TT and takes the Profiles either
from the TT, if they are provided, or from the original switch request NT.
7. Constructs events of the appropriate event types from information contained in the TT.
Depending on what information has been provided, this may result in the insertion of new
Status events.
8. Updates the ICP so that there is no longer a switch in progress.

9. Reverses any Trader events that may have been input by the losing Trader prior to the start of
the switch process and that have Event Dates later than Actual Transfer Date
10. Completes audit trail information for each event inserted and reversed as well as for the TT.
11. Generates an acknowledgement for the TT to the gaining Trader.

12. Determines the affected participants of the event insertions and reversals and generates
notifications to them, in accordance with the requirements of their notification parameters. Both
Traders are classed as affected participants.
Data outputs:
 ICP updated to indicate the switch is no longer in progress.
 Trader event.
 Possible Status events.
 Possible Trader, and/or Status event reversals.
 Copy of the TT and its associated audit trail information.
 TT to forward to the losing Trader.
 Notifications.
139
Version 22.24
Sub-process: RS-050 Complete switch or replace switch reading (CS and RR)
Code references: Clauses 1 to 22 of Schedule 11.3 and Schedule 11.5 of the Code
Dependencies: MP-020, PR-030
Description:
This message is used to send final information to complete a switch. For HH switch types (see RS-
010) it is submitted by the gaining Trader to the Registry. For all other switch types it is sent by the
losing Trader to the Registry. The Registry forwards the message to all interested parties and
generates a new Trader event that records the new Trader.
The submitter is required to provide channel readings for all existing (non-removed) metering
components with channels that have an accumulator type = ‘C’ and a settlement indicator of ‘Y’.
This applies to all metering component types.
This message type can also be used to change the readings in accordance with clauses 6 and 12
of Schedule 11.3. In this case it is only the gaining Trader that submits it to the registry where it is
delivered to the losing Trader and only where it was the losing Trader that submitted the original
CS. The original CS remains in the system. The ‘correction’ version of this format will have a
message type of RR to distinguish it from the original CS.
As part of the CS message delivery and in accordance with the notify parameter settings of the new
Trader, the system can also provide (only to) the new Trader an additional file at the same time as
the CS is delivered, containing the latest applicable ICP event details, of every event type, for each
ICP within the CS message. The format of this file is the snapshot version of PR-030 – Event
Detail Report. The report can be requested to be provided in csv or xml format which is a
parameter setting within the notify parameters process (MP-020).
User information: When switching an ICP that has only unmetered load (ie. UNM) and therefore no
metering records, the CS message will contain only a Premises record type. Similarly, for ICPs
with no existing metering components with channels that have an accumulator type of ‘C’ and a
settlement indicator of ‘Y’, the CS message will contain only a Premises record type.
Transitional requirement: For back-dated switches, where the Actual Transfer Date is prior to the
go-live date, all validation requiring checks to be made against the metering event information
applicable at the Actual Transfer Date of an ICP is to be omitted. This applies to the CS and the
RR. This relaxation functionality is only available if the CS or RR is submitted by file (SFTP). This
relaxation functionality extends to RRs submitted against matching TNs i.e. only available via file.
Trader Default Situation
A Trader may not submit a CS to the Registry where the result will be a gain in responsibility to a
Trader in a Trader Default situation.
140
Version 22.24
A Trader may not submit a RR to the Registry where the Trader is required to respond is in a
Trader Default situation.
1. For CS messages, where the switch type on the NT is HH, it is submitted by the gaining Trader
to the Registry. For all other switch types it is sent by the losing Trader to the Registry.
2. For RR messages, it is submitted by the gaining Trader to the Registry but only where the
original CS was submitted by the losing Trader or where there is a matching TN.
3. Traders can provide CS/RR information to the registry via a file or via a browser screen. Only
the affected parties to the switch - Traders (gaining and losing), Distributor, the MEP and the
Proposed MEP (if an MEP switch is in progress) can view the full CS/RR information via the
browser. Other parties can view all the information except the channel readings.
4. For a CS message type, there must be an immediately prior switch request (NT) or
acknowledgement notice (AN) present for the ICP and it must relate to the switch.
5. For a CS message type, the gaining Trader must be active in the role of ‘Trader’ ‘as at’ the
Actual Transfer Date.
6. For a CS message type, the Actual Transfer Date must be greater than the ICP initial
assignment date.
7. For a CS message, the gaining Trader must not be in a Trader Default situation.
8. For a RR message, the Trader required to respond must not be in a Trader Default situation.
9. An audit trail and an acknowledgement must be generated for the CS and RR.
10. The CS/RR information must be forwarded by the registry to the other Trader in a file in the
same format and order as input, and, in accordance with their switch notify parameters.
11. The CS (but not the RR) must also be forwarded to the other (gaining or losing) Trader,
Distributor the MEP and the Proposed MEP (if an MEP switch was in progress) of the ICP
applicable at the Actual Transfer Date. “Where an ‘affected party’ has dual roles e.g. Trader
and Proposed MEP, only one message is forwarded.
12. Once accepted by the registry, a CS cannot be reversed. The withdrawal sub-process must be
used instead.
13. The CS can be corrected (in certain circumstances) by submitting an RR transaction but only
by the gaining Trader party but only where the original CS was submitted by the losing Trader.
The RR Actual Transfer Date must match the Actual Transfer Date of the original CS or TN. All
the validation rules are re-applied based on the latest version of the Metering and Trader
events (in case metering information have been updated in the meantime as there may have
been additional or fewer existing (non-removed) metering components with channels that have
an accumulator type of ‘C’ and a settlement indicator of ‘Y’ found at the site since the CS was
submitted) applicable at the Actual Transfer Date.
141
Version 22.24
14. Only the CS message changes the responsibility from the losing Trader to the gaining Trader
and triggers the updating of Trader event information. The RR is purely for information
purposes.
15. Depending on the notification parameters, a snapshot version of the Event Detail report PR-030
may be generated containing each ICP successfully switched via a CS message. The report is
delivered to a new Trader at the same time as the CS is delivered. This is only required where
it is the old Trader that inputs the CS message. The format of the report can be xml or csv.
The format is set as a supervisor-defined parameter. This report will contain the events ‘as at’
the Switch Date and any events that have changed since that date for each ICP. The name of
this file will be the same as the forwarded CS message with a file extension of “.eda”.
16. For back-dated switches, where the Actual Transfer Date is prior to the go-live date, all
validation requiring checks to be made against the metering event information applicable at the
Actual Transfer Date of an ICP is to be omitted when the CS or RR is submitted via file.
17. There can be multiple RR messages sent for any completed switch (CS or TN) where the
Actual Transfer Date on the RR matches the one on the completed switch. There is a limitation
on the submission of RRs via the browser. The browser can only be used to submit multiple (or
subsequent) RR’s against the latest completed switch. The file mechanism is used to submit
multiple (or subsequent) RR’s for any prior completed switch, not just the latest.
N.B.
a) An RR cannot be sent for a completed switch that has been withdrawn or is in the
process of being withdrawn.
b) An RR cannot be sent for a completed switch where there is already an RR that has no
associated (matching) AC i.e. an AC must always follow an RR.
c) There is no checking whether the previous AC was a rejection or acceptance before a
subsequent RR can be sent for a particular completed switch.
Data inputs:
 Each attribute on an input line is comma separated.
 CS/RR (completed switch/replacement reading notice) attributes are:

 N.B. For RR message types the ‘I’ and ‘M’ rows must not be provided.
 Sequence of input file: ICP Number, Metering Installation Identifier, Metering Component Serial
Number, Channel Number.

/optional
Record Type Char 1 M Must be ‘P’ – premises
Trader Char 4 O Submitting Trader Participant Identifier.

Derived by the system if left blank.
142
Version 22.24

/optional
Actual Transfer DD/MM/YYYY M The submitting Trader must be active in the

Date role of ‘Trader’ on the Actual Transfer Date.
For each Where the Actual Transfer Date is on or after
Metering
the go-live date: there must be exactly the
Installation that
has channels same number of installation rows as found in
requiring the Metering event applicable at the Actual
readings Transfer Date for this ICP where the
installation contains non-removed metering
components with at least one Channel with an
accumulator type = ‘C’ and settlement
indicator = ‘Y’. They will be separated by
intervening ‘M’ and ‘R’ rows.
For RR message types the ‘I’ row is not to be
submitted.
Record Type Char 1 M ‘I’ – installation.
Metering Numeric 3 M A unique Metering Installation Identifier within

Installation the ICP. Where the Actual Transfer Date is on
Number or after the go-live date, this must match the
Metering Installation Identifier in the related
Metering event applicable at the Actual
Transfer Date.

Indicator
Where the Actual Transfer Date is on or after

the go-live date, there here must be exactly
the same number of ‘M’ rows following an ‘I’
row, as the number of existing (non-removed)
metering components within the installation
with at least one Channel with an accumulator
type = ‘C’ and settlement indicator = ‘Y’.
Each ‘M’ row will be separated by intervening
‘R’ rows.
For RR message types the ‘M’ row is not to be
submitted.
Record type Char 1 M ‘M’ – meter.
143
Version 22.24

/optional
Metering Numeric 3 M Metering Installation Identifier. Must be the

Installation same as in the preceding ‘I’ record.
Number
Metering Char 25 M Unique identifier of the metering component

Component Serial within the ICP. Where the Actual Transfer
Date is on or after the go-live date, it must
Number
match the Metering Component Serial Number
in the related Metering event applicable at the
Last Read Date DD/MM/YYYY M Date the metering component was last
physically read, e.g. 05/05/2002, or the last
validated meter reading if a permanent
estimate supplied.
Meter Reader Char 50 O Free text. Optional.

Notes
For CS message types, where the Actual

Transfer Date is on or after the go-live date,
there must be exactly the same number of ‘R’
rows, as the number of channels within the
metering component of the previous ‘M’ row
that have an accumulator type = ‘C’ and a
settlement indicator = ‘Y’ applicable at the
For RR message types, where the Actual
Transfer Date is on or after the go-live date,
there must be exactly the same number of ‘R’
rows, as there are channels recorded against
the ICP and metering component in the ICP’s
Metering event, that have an accumulator type
= ‘C’ and a settlement indicator = ‘Y’
applicable at the Actual Transfer Date.
Record type Char 1 M ‘R’ – register/channel.
Metering Numeric 3 M For the CS, must be the same as in the

Installation preceding ‘I’ record.
Number
Metering Char 25 M Unique Metering Component Serial Number

Component Serial for the ICP. For the CS, must be the same as
Number in the preceding ‘M’ row.
144
Version 22.24

/optional
Channel Number Numeric 2 M A unique combination of Metering Installation

Number/Metering Component/Serial
Number/Channel Number for the ICP. Where
the Actual Transfer Date is on or after the go-
live date, the unique combination must identify
a channel that has accumulator type = ‘C’ and
a settlement indicator of ‘Y’ in the associated
Metering event to which the reading applies.
Reading Numeric 12 M Reading value for this channel on this date.

Where the Actual Transfer Date is on or after
the go-live date: the number of digits must not
be greater than the number of dials recorded
for this channel in the associated Metering
event.

Estimate estimate. Valid values: (A)ctual, i.e. validated
meter reading, or (E)stimate, i.e. permanent
estimate or (D)efault i.e. Trader Default
initiated. N.B. “D” cannot be used by Traders.
Examples:
A CS with 1 installation, with 1 meter but with 2 channels, the Last Read Date is the same as the
Actual Transfer Date, so the Reading is Actual:
HDR,RQSWITCHCS,RETA,RGST,19/07/2016,14:48:34,5
P,9999999999AB123,RETA,18/07/2016,premises user ref
I, 9999999999AB123,1,12,Y
M,9999999999AB123,1,6677AB,18/07/2016,MetrNotes
R,9999999999AB123,1,6677AB,0,1234,A
R,9999999999AB123,1,23454789,1,7894,A
A CS with 2 installations, each with 1 meter but with 2 channels. The switch date is 3 days later
than the Last Read Date so the Reading is an Estimate:
HDR,RQSWITCHCS,CTCT,RGST,19/07/2016,14:48:34,9
P,12345678901AB123,GENE,18/07/2016,2100471481:001
I, 12345678901AB123,1,12,Y
M,12345678901AB123,1,501824,15/07/2016,Notes
R,12345678901AB123,1,501824,1,26699,E
R,12345678901AB123,1,501824,2,08444,E
I, 12345678901AB123,2,62,N
M,12345678901AB123,2,501825,15/07/2016,Notes
R,12345678901AB123,2,501825,1,26699,E
R,12345678901AB123,2,501825,2,8444,E
145
Version 22.24

/optional
An RR with 1 installation, with 1 meter but with 2 channels:

HDR,RQSWITCHRR,RETA,RGST,19/07/2007,14:48:34,3
R,9999999999AB123,1,6677AB,0,1284,A
R,9999999999AB123,1,23454789,1,9894,A
A CS for an ICP with only UNM of where there are no components with a channel with a settlement
indicator of ‘Y’:
HDR,RQSWITCHCS,RETA,RGST,19/07/2007,14:48:34,3
Processing:
System
1. Validates all attributes, using relevant information from the Metering and Trader events, and
checks their dependencies.
2. Checks that the CS is being sent by the appropriate Trader.
3. Checks that the CS will not result in a Trader in a Trader Default situation gaining responsibility.
4. Checks that the CS Actual Transfer Date is greater than the ICP initial assignment date
5. For an RR message checks that the Trader required to respond is not in a Trader Default
situation.
6. Checks that the RR is being sent by the appropriate Trader.

7. There must be a Trader switch in progress for the ICP.
8. Rejects a CS/RR with errors and returns it to the sender with the reason for the rejection.
9. Keeps a copy of the CS/RR.

10. Generates an audit trail for the CS/RR.
11. Sends the CS/RR to the other Trader either immediately or as part of a later batch in
accordance with that Trader's switch notify parameters.
12. Sends the CS (not RR messages) to the affected Distributor and Metering Equipment Provider
(unless the MEP has already been sent the CS in the dual role of Trader) of the ICP. All CS
messages are batched together in one file and delivered overnight.
13. For CS message types only, generates a Trader event for the ICP, in order to effect the change
in Trader, setting the Event Date to be the Actual Transfer Date from the CS and taking the
remaining reconciliation attributes from the information in the original switch request (NT), if
present, otherwise from the immediately prior Trader event, if present.
14. For CS message types only, when generating the Trader event from the attributes found in the
original switch request (NT), sets the Trader event submission types based on the classification
of the profile codes supplied in the NT message as follows:
146
Version 22.24
For the purpose of setting the submission types, profile codes beginning with the letter H are to
be classified as half hourly profiles except for the code HSL (used for street lights).
All other codes, including HSL, are to be classified as non half hourly profiles.
Then
a) for an NT message where all the profile code(s) are for half hourly profiles:
i. submission type NHH = “N”; and
ii. submission type HHR = “Y”.
b) for an NT message where all profile code(s) are for non half hourly profiles:
i. submission type NHH = “Y”; and
ii. submission type HHR = “N”.
c) for an NT message where there are a mix of half hourly and non half hourly profiles:
i. submission type NHH = “Y”; and
ii. submission type HHR = “Y”
15. For CS message types only, updates the ICP so that there is no longer a Trader switch in
progress (not applicable to RRs).
16. For CS message types only, reverses any Trader submitted events (Trader and Status) that
have Event Dates later than the Actual Transfer Date but not Trader events that commenced
an MEP switch where an MN acceptance was also submitted. In this instance, the system will
replace these Trader events with details inherited from the Trader event generated as a result
of this Trader switch, but with the Event Date and Proposed MEP attributes taken from the
Trader event being replaced.
17. Completes audit trail information for each event inserted and reversed.
18. Generates an acknowledgement for the CS/RR to the submitting Trader.

19. Generates a snapshot Event Detail report (PR-030) for each ICP switched but only for new
Traders where the CS was submitted by an old Trader, if applicable.
20. Determines the affected party of each event insertion, replacement and reversal and generates
notifications to them, with reference to their notification parameters. The affected parties are
the Distributor, gaining Trader, losing Trader, MEP, and the Proposed MEP if there is an MEP
switch in progress.
21. A Trader event reversal may result in the MEP switch in progress status being set off.
Data outputs:
 ICP updated to indicate the Trader switch is no longer in progress.
 Trader event.
 Possible Trader and Status event reversals.
 Possible Trader event replacements.
 Possible MEP switch in progress status set off.
 Copy of the CS/RR and its associated audit trail information stored on registry for online query
but without the channel reading attribute value.
147
Version 22.24
 CS/RR to forward to the other Trader

 CS message only to the Distributor and Metering Equipment Provider.
 Snapshot Event Detail report (PR-030) for each ICP switched, to the new Trader.
 Notifications.
148
Version 22.24
Sub-process: RW-010 Make withdrawal request (NW)
Process: Trader withdraws switch
Code references: Clauses 17 and 18 of Schedule 11.3 and Schedule 11.5 of the Code.
Dependencies:
Description:
A Trader currently or previously involved in a switch sends a notify withdrawal message (NW) to the
registry requesting the withdrawal of a switch.
1. Only the losing Trader or gaining Trader can request a switch withdrawal.
2. A Trader must not submit a NW message where the end result will be a Trader in a Trader
Default situation gaining responsibility for an ICP.
3. A Trader must only submit a NW message where the result would be, if accepted via the AW, a
Trader gaining responsibility for the ICP in a period where they have an active role of ‘Trader’.
4. Either losing Trader or gaining Trader can initiate the switch withdrawal process.
5. Only the latest switch may be withdrawn. The Trader switch can be one that is still in progress
or one that has been completed.
6. A switch cannot be withdrawn where it would invalidate later events.

7. The withdrawal process can be initiated at any point in the switch process, ie after the NT, AN
or CS.
8. If any Distributor maintenance is done, any notifications sent to affected parties must indicate
that a Trader switch withdrawal is in progress and both Traders involved must be notified.
9. The registry must keep a copy of the NW for a minimum of 3 months.
10. An audit trail and an acknowledgement must be generated for the NW.
11. The NW must be forwarded by the registry to the other Trader in a file and in accordance with
12. The withdrawal process must be completed once the NW has been accepted by the registry,
since an NW cannot be corrected or reversed.
13. Once the NW has been accepted, all online queries relating to the ICP in question must
highlight that a switch is being withdrawn.
Data inputs:
149
Version 22.24
NW (notice of withdrawal) attributes are:

optional
Record type Char 1 M Must be ‘P’ - premises.
ICP Char 15 M
Trader Char 4 O Participant identifier of the Trader who submits

withdrawal notice. Either party of current or last
switch. Can be derived by system.
Withdrawal advisory Char 3 M Valid withdrawal advisory code – static data

maintenance sub-process.
code
Refer to static data tables for codes values
Example:
HDR,RQSWITCHNW,RETA,RGST,10/07/2007,11:00:00,1
P,9999999999AB123,RETA,CR,NW UserRef
Processing:
System
2. Checks that the requesting Trader is allowed to make the switch withdrawal request.
3. Checks that the gaining Trader is not in a Trader Default situation.
4. Rejects an NW with errors and returns it to the sender with the reason for the rejection.
5. Updates the relevant ICP to indicate that a switch is being withdrawn.
6. Keeps a copy of the NW, and completes the audit trail information for it.
7. Forwards the NW to the other Trader either immediately or as part of a later batch in
8. Generates an acknowledgement to the requesting Trader.
Data outputs:
 ICP updated to indicate that the latest switch is being withdrawn.
 Stored copy of the NW and its associated audit trail information.
 NW to forward to the other Trader.
150
Version 22.24
Sub-process: RW-020 Acknowledges withdrawal request (AW)
Process: Trader withdraws switch
Participants: Trader, Metering Equipment Provider
Code references: Clauses 17 and 18 of Schedule 11.3 and Schedule 11.5 of the Code.
Dependencies: RW-010
Description:
A Trader, having received a notice requesting a switch withdrawal, sends an acknowledge

withdrawal (AW) message to the registry in reply. The acknowledgement can either accept or reject
the withdrawal request.
1. The Trader receiving a notice to withdraw a switch must respond to it by sending an AW to the
registry.
2. There must be an immediately prior NW for the latest switch of the ICP and no matching AW.
3. A Trader must not submit a AW message where the result is a Trader in a Trader Default
situation gaining responsibility for an ICP.
4. A Trader must only submit an AW acceptance message which would cause the ICP to become
the responsibility of a Trader in a period where they were active in the role of ‘Trader’.
5. The registry must keep a copy of the AW for a minimum of 3 months.
6. An audit trail and an acknowledgement must be generated for the AW.
7. The AW must be forwarded to the other Trader by the registry in a file and in accordance with
8. The AW must be forwarded to the current MEP, unless they have been sent the AW as a result
of also being the Trader.
9. An AW cannot be corrected or reversed once accepted by the registry.
Data inputs:
 AW (withdrawal acknowledgement)

optional
Record type Char 1 M Must be ‘P’ - premises.
ICP Char 15 M
Trader Char 4 O Trader Participant Identifier who submits the

withdrawal acknowledgement. Can be derived
by system.
151
Version 22.24
Withdrawal Transfer Char 1 M A—withdrawal accepted.

Status
R—withdrawal rejected.
Example:
HDR,RQSWITCHAW,RETB,RGST,10/07/2007,11:00:00,1
P,9999999999AB123,RETB,A,AW_UserReference
Processing:
System
2. Checks that the responding Trader is allowed to send the AW message.
3. Checks the gaining Trader is not in a Trader Default situation.
4. Rejects an AW message with errors and returns it to the sender with a reason for the rejection.
5. If the AW message indicates that the withdrawal is accepted, cancels the latest switch. If it was
a completed switch, any events inserted by the gaining Trader after the Actual Transfer Date of
the switch are reversed except for Trader events that commenced an MEP switch where an MN
acceptance was also submitted. In this instance, the system will replace these Trader events
with details inherited from the prior Trader’s latest Trader event, but with the Event Date and
Proposed MEP attributes taken from the Trader event being replaced. The ICP is updated to
indicate that a switch is no longer in the withdrawal process. Responsibility for the ICP reverts
to the losing Trader.
6. If AW indicates that the withdrawal is rejected and, prior to the commencement of the
withdrawal being initiated, a Trader switch was in progress, the system restores the ICP to the
switch in progress state. (The Trader switch can proceed or another withdrawal can be
initiated.) If the withdrawal was for an already completed Trader switch, the system ends the
withdrawal in progress for the ICP. (It is available for switching again.)
7. Forwards the AW to the other Trader either immediately or as part of a later batch in
accordance with that Trader's switch notify parameters.
8. Forwards the AW to the current Metering Equipment Provider of the ICP. All AW messages are
batched together in one file and delivered overnight.
9. Completes the audit trail information of each event inserted and reversed as well as for the AW.
10. Generates an acknowledgement of the AW for the responding Trader.
11. Determines the affected parties of each event insertion, replacement and reversal and
generates notifications to them, with reference to their notification parameters. The affected
parties are the Distributor, gaining Trader, losing Trader, MEP and the Proposed MEP if there
is an MEP switch in progress.
12. Each withdrawal initiation and acknowledgement pair of transactions, regardless of whether the
acknowledgement is an acceptance or a rejection, resolves a switch withdrawal request.
13. A Trader event reversal may result in the MEP switch in progress status being set off.
152
Version 22.24
Data outputs:
 ICP updated to indicate that the latest Trader switch is no longer being withdrawn.
 Stored copy of the AW and its associated audit trail information.
 AW to forward to the other Trader and MEP.
 Possible Trader event replacements.
 Possible MEP switch in progress status set off.
 Notifications.
153
Version 22.24
Sub-process: RC-010 Request switch read change (NC) - Discontinued
Process: Trader changes switch read
Code references: Clauses 6(b) and 12(2)(b) and (3) of Schedule 11.3 of the Code
Dependencies:
Description:
will be available to view and report on. Replaced by new switch message RR. See RS-050.
A gaining Trader wishing to change the validated meter reading or permanent estimate on any
completed switch that has not been or is not in the process of being withdrawn sends a request
switch read change message (NC) to the registry to be forwarded to the losing Trader involved in
the switch.
1. All NC messages must be sent to the registry in a file. However, the system must also provide
an online view of the basic NC information.
2. An NC message must only be applied to any completed switch that has not been or is not in the
process of being withdrawn and it must have been for either a standard non-half-hour or
standard non-half-hour move switch (S, SM), ie completed with a TN.
3. The premises information given on the NC must be the same as that of the TN message of the
most recently completed switch sequence (except for the relay owner field).
4. The registry must keep a copy of the NC for a minimum of 3 months.
5. An audit trail and an acknowledgement must be generated for the NC.

6. The NC must be forwarded by the registry to the other Trader in a file and in accordance with
7. Receipt of the NC must not affect the current switching status in any way.
8. Processing of the message must not generate any events.

9. A subsequent NC relating to a particular switch cannot be sent if there is an existing NC
awaiting an associated AC for this switch.
10. Only the graining Trader of the switch in question can input an NC request.
11. Note that the NC is an exact copy of the TN format and the same validation of the values can
be applied to the NC.
154
Version 22.24
Data inputs:

NC (notice of change of switch read)

optional
Record type Char 1 M Must be ‘P’—premises.
Trader Char 4 O Sending Trader Participant Identifier. Derived

by the system if left blank.
Actual Transfer DD/MM/YYYY M

Date
Relay Owner Char 6 O Owner of relays on premises.
Number Of Numeric 2 M Number of meters at ICP.

Meters
For each meter: There must be exactly <number of meter>
rows of ‘M’ record types for this ICP. They will
be separated by intervening ‘R’ rows.
Record type Char 1 M ‘M’—meter.
Last Read Date DD/MM/YYYY M Date meter was last physically read, eg
05/05/2002, or the last validated meter reading
if permanent estimate supplied.
Primary Metering Char 4 M Must be a valid Primary Metering Contact.

Contact
Participant
Identifier
Meter Identifier Char 15 M Unique identifier of meter.
Meter Multiplier Numeric 3.3 M Multiplier (up to three decimal places) to

transform readings difference to actual usage.
Checked against the value of the Meter
Multiplier Flag of the Metering event applicable
on the Actual Transfer Date. If the Metering
event Meter Multiplier Flag is ‘Y’ then at least
one of the Meter Multipliers for this premise
must have a value other than unity, ie not 1.
155
Version 22.24

optional
Register Dials Numeric 2 M Number of dials/digits on the meter’s registers.

Valid values are between 4 and 12.
Meter Location Char 3 M Value must be one of those in the list of valid
Code meter location codes held by the registry.

Indicator
Number Of Numeric 2 M Number of registers for this meter. The total

Registers number of registers for the premises (for this
ICP) must be greater than or equal to the
Meter Register Count of the Metering event
applicable on the Actual Transfer Date. 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.
Meter Reader Char 50 O Free text.

Notes
For each There must be exactly <number of register>
register within
rows after each ‘M’ row.
the meter:
Record type Char 1 M ‘R’—register.
Meter Identifier Char 15 M Unique identifier of meter. Must be the same

as in the preceding M record.
Register Number Numeric 2 M Sequential register number (identifier).
Register Content Char 6 M Valid register content code – see static data
sub-process, eg D—daytime only, N—night-
time only.
Period of Numeric 2 M/O Minimum service hours of supply per day.

Availability Required if register has controlled or inclusive
load. (See register content codes – static data
maintenance sub-process.)
Register Units Char 6 M Valid register unit – see static data

maintenance sub-process, eg kWh, kW, kVA,
kVArh.
156
Version 22.24

optional
Energy Flow Char 1 M Valid values are ‘L’ for load and ‘G’ for
Direction generation.
Register Reading Numeric 12 M Reading value, for this register on this date.
Number of digits must not be greater than the
number of dials.

Estimate estimate. Valid values: (A)ctual, i.e. validated
meter reading, or (E)stimate, i.e. permanent
estimate.
Example:
HDR,RQSWITCHNC,RETA,RGST,19/07/2007,14:48:34,3
P,9999999999AB123,RETA,01/01/2009,RETA,1,premises user ref
M,9999999999AB123,17/12/2008,,6677AB,,,,12.33,Y,1,MetrNotes
R,9999999999AB123,6677AB,12,,,,,,1234,A
Processing:
System
2. Checks that the most recently completed switch for the ICP was either a standard non-half-hour
(S) or a standard non-half-hour move (SM) switch.
3. Checks that the NC is being sent by the new Trader of the most recently completed switch.
4. Checks that the Actual Transfer Date, number of meters and User Reference attributes are the
same as those given on the TN message of that switch sequence.
5. Rejects any NC with errors and returns it to the sender with the reason for the rejection.
6. Keeps a partial copy of the NC comprising the Actual Transfer Date, relay owner, number of
meters and User Reference attributes.
7. Generates an audit trail for the partial NC.
8. Sends the complete NC to the losing Trader either immediately or as part of a later batch in
9. Generates an acknowledgement for the NC to the other Trader.
Data outputs:
Partial copy of the NC and its associated audit trail information stored on registry for online query.
NC to forward to the other Trader.
Acknowledgements.
157
Version 22.24
Sub-process: RC-020 Acknowledge switch read change (AC)
Process: Trader changes switch read
Participants: Traders, Metering Equipment Providers, Distributors
Code references: Clauses 6(b) and 12(2)(b) and (3) of Schedule 11.3 of the Code
Dependencies:
Description:
The losing Trader, having received a notice to change the validated meter reading or permanent
estimate RR on any completed switch that has not been or is not in the process of being withdrawn,
sends an acknowledge switch read change message (AC) to the registry in reply. The
acknowledgement can either accept or reject the change request.
1. The Trader receiving a notice to change a validated meter reading or permanent estimate must
respond to it by sending an AC message to the registry.
2. The registry must keep a copy of the AC message for a minimum of 3 months.
3. If the AC is for an acceptance of the change, the registry must forward the associated RR to the
affected Distributor and Metering Equipment Provider unless they have already been sent the
RR as a result of also being the Trader.
4. An audit trail and an acknowledgement must be generated for the AC message.

5. The AC message must be forwarded to the other Trader by the registry in a file and in
accordance with the other Trader's switch notify parameters.
6. An AC cannot be corrected or reversed once accepted by the registry.
Data inputs:

AC (acknowledge change request of switch read) attributes are:

optional
Record type Char 1 M Must be ‘P’ - premises
ICP Char M
15
Trader Char 4 O Trader that submits the change

acknowledgement. Can be derived by system.
Actual Transfer Date Date DD/MM/YYYY. Used to identify the switch.
158
Version 22.24
Switch read Char 1 M A—change accepted.

acknowledgement R—change rejected.
User Reference Char O Free text.

32
Example:
HDR,RQSWITCHAC,RETB,RGST,10/07/2007,11:00:00,1
P,9999999999AB123,RETB,01/01/2009,A,USerReference
Processing:
System
2. Checks that the responding Trader is allowed to send the AC message.
3. Rejects an AC with errors and returns it to the sender with a reason for the rejection.
4. Forwards the AC to the other Trader either immediately or as part of a later batch in
5. If the AC switch read acknowledgement is A—accept, the associated (prior) RR is to be
forwarded to the affected Distributor and Metering Equipment Provider, via an overnight batch
file.
6. Generates an acknowledgement of the AC for the responding Trader.
Data outputs:
1. Stored copy of the AC message and its associated audit trail information.
2. AC message to be forwarded to the other Trader.
3. If the AC switch read acknowledgement is A—accept, the associated (prior) RR is to be
forwarded to the affected Distributor and Metering Equipment Provider.
4. Acknowledgement.
159
Version 22.24
Sub-process: MN-010 Accept or decline MEP responsibility for ICP (MN)
Process: MEP Responsibility Notice
Participants: Metering Equipment Provider
Code references: Clauses 1(2) and 1(3) Schedule 11.4 of the Code
Dependencies:
Description:
The Proposed MEP, having received a notice that the Trader has loaded them in the Trader event
as the new Proposed MEP, sends a notice to the registry to decline or accept the responsibility.
For an acceptance, the notice will contain the required intended transfer date.
1. Only the Proposed MEP as indicated on the latest Trader event can send the responsibility
notice to the registry for an ICP.
2. If the MN is for an acceptance of responsibility, the registry must forward the associated MN to
the affected Distributor, Trader (both parties if a Trader switch is in progress) and old MEP (if
exists). An MN decline is only delivered to the current Trader.
3. The MN message must be forwarded to Traders by the registry in a file and in accordance with
their (Traders) switch notify parameters. To Distributors and old MEP, the message is sent
overnight.
4. The Transfer Date of the MN must be on or after the Event Date of the Trader event that first
proposed them.
5. If there are any non-reversed Metering events with Event Dates on or after the Transfer Date,
the MN must be rejected. The current (old) MEP will have to reverse them first.
6. An audit trail must be generated for all MN messages and for any replacements.
7. An acknowledgement must be generated for the MN message to the submitting MEP.
Data inputs:

MN (MEP responsibility notice) attributes are:
160
Version 22.24
Data inputs:
optional
Record type Char 1 M Must be ‘P’ - premises
ICP Char M Valid ICP.

15
MEP Identifier Char 4 O MEP that submits the change

acknowledgement. Can be derived by system.
Transfer Date Date M/O DD/MM/YYYY. Can be in the future. Mandatory

for an acceptance, optional for a decline.
Responsibility Indicator Char 1 M A—responsibility accepted.

R—responsibility rejected.
Decline Advisory Code Char 3 M/O Only mandatory for a Responsibility Indicator of
R. Valid decline advisory code –see static data
maintenance sub-process. Current valid codes
are:
WP – wrong premises
AR – No arrangement with Trader
(more codes to be advised).
User Reference Char O Free text.

32
Example:
HDR,RQSWITCHMN,METB,RGST,10/07/2007,11:00:00,1
P,9999999999AB123,METB,01/01/2012,A,,USerReference
Processing:
161
Version 22.24
System
2. Checks that the responding MEP is allowed to send the MN message.
3. Rejects an MN with errors and returns it to the sender with a reason for the rejection.
4. Forwards the MN acceptance to the affected Trader(s) either immediately or as part of a later
batch in accordance with that Trader’s switch notify parameters. Forward the MN decline only
to the current Trader.
5. Forwards the MN acceptance to the Distributor and old MEP (unless the old MEP has already
been sent the MN in the dual role of Trader) overnight.
6. Generates an acknowledgement of the MN for the responding MEP.
7. Generates all required audit records.
8. Assigns an Event Date (to enable the correct sorting of this message in the online display of
event history) that is the same as the Event Date of the Trader event that initiated the MEP
switch.
162
Version 22.24
Data outputs:
Stored copy of the MN message and its associated audit trail information.
MN message to be forwarded to the Trader(s), Distributor and current MEP
Acknowledgement.
163
Version 22.24
Sub-process: DS-010 Transfer ICPs between Distributors
Process: Switching
Participants: Registry manager
Dependencies:
Description:
This process is used primarily to accommodate acquisitions or mergers of Distributors, to facilitate

transfer of ICPs from one Distributor Participant Identifier to another. The process is managed by
the Authority, and performed by the registry manager.
1. The registry manager accepts instructions from the Authority in the form of a file in CSV format
containing a list of ICPs to be transferred, plus data associated with each ICP. The spreadsheet
may optionally contain a one-row header line.
2. Based on these instructions, the registry transfers the ICPs to the new Distributor Participant
Identifier in a single operation. The registry does not manage any transfer negotiation. Results
(acknowledgement) and notifications are advised in the normal manner.
3. Updates for large files (>1000 ICPs) may require process scheduling by mutual agreement
between the Authority and the registry manager.
Data inputs:
 Pre-requisites to this process are valid NSP Mapping records for the new Distributor (added
by the Reconciliation Manager) and valid Distributor Price Category and loss factor codes
(added by the new Distributor).
 The NSP Mapping must be for the new Distributor and POC that are supplied in the
Distributor transfer file.
(Note: the DS010 input file does not require a header line)

/optional
Record type Char 3 M Must be “DET”
ICP Char 15 M
Transfer effective date D/MM/YYYY M
Old network Char 4 M Participant identifier of the old Distributor
New network Char 4 M Participant identifier of the new Distributor
164
Version 22.24

/optional
New POC Char 7 M POC for NSP mapping
Reconciliation Type Char 2 M Existing Reconciliation Type, provided for

validation purposes only.
Dedicated NSP Char 1 M Existing Dedicated NSP (Y/N), provided

for validation purposes only.
Installation Type Char 1 M Existing Installation Type (L, G, B),

provided for validation purposes only.
Proposed Trader Char 4 M Ignored if ICP Status is other than NEW

or READY
Unmetered Load Char 30 M Existing Unmetered Load Details,

Details - Distributor provided for validation purposes only.
Must match the Unmetered Load Details
– Distributor on the network event valid at
the Transfer effective date
Shared ICP List Char 500 M Existing list of ICP Identifiers, space
delimited. Only valid if Reconciliation
Type is SI, provided for validation
purposes only. Must match the Shared
ICP List on the network event valid at the
Transfer effective date
New Distributor Price Char 50 M Multiple allowed, space delimited

Category Codes
New Distributor Loss Char 7 M

Category Code
Distributor Installation Char 30 M Existing Installation Details, provided for

Details validation purposes only. Must match the
Distributor Installation Details on the
pricing event valid at the Transfer
effective date
Chargeable Capacity Num 7.2 M Existing Chargeable Capacity, provided

for validation purposes only. Must match
the Chargeable Capacity on the pricing
event valid at the Transfer effective date
Example:
DET,9999999999AB123,01/01/2009,NETA,NETB,ABC0111,GN,N,L,RETA,,,PRCat1
PRCat2,LCat1,,,UserReference
165
Version 22.24
Processing:
System
Performs the following validation for each ICP
1. Validates all parameter formats:
 The effective transfer date can be in the past or future.

 The ICP exists at the effective transfer date and is not decommissioned.
 The ICP has no network or Pricing events dated beyond the transfer effective
date.
 The ICP belongs to the old Distributor at the transfer effective date.
 The new Distributor is valid and active in the role of ‘Distributor’ at the transfer
effective date.
 The Reconciliation Type does not change the type of the ICP ie from standard to
Distributor-only or vice-versa.
 The NSP Mapping with new POC exists and is valid for the new Distributor at
the transfer effective date.
 The Distributor Loss Category Code and Distributor Price Category Code(s)
exist and are valid for the new Distributor at the transfer effective date.
 The values are unchanged for Reconciliation Type, Dedicated NSP, Installation
Type, Unmetered Load Details - Distributor, Shared ICP List, Installation Details,
Chargeable Capacity, Generation Capacity, Fuel Type, Initial Electrically
ConnectedDate, Direct Billed Status and Direct Billed Details.
2. For each ICP meeting validation requirements:

 A new Network event is recorded for the ICP, effective transfer date and supplied
Network event data.
 A new Pricing event is recorded for the ICP, effective transfer date and supplied
Pricing event data.
3. If the ICP was previously at New” state, and the addition of any network or pricing data
allows it to become Ready (or in the case of a Distributor-Only ICP, to become Distributor-
Only), a Status event is recorded for the ICP and effective transfer date.
4. An audit trail is maintained.
5. An acknowledgement is generated for each event created. For each ICP, this indicates
success, or an error code notifying the reason for rejection
6. For each ICP successfully updated, notifications showing the ICPs new values are
generated for the old and new Distributor. If a Status event is created, and there is no
current or future Trader event, a notification is also generated for the Proposed Trader.
7. For each ICP successfully updated, notifications will be generated for any Traders and
Metering Equipment Providers current at the transfer effective date.
166
Version 22.24
Data outputs:
 ICP updated with network and Pricing events recording new Distributor details and User
Reference.
 Audit.
 Notification to old and new Distributor (and possible notifications to Proposed Trader, current
Trader and current Metering Equipment Provider). A Trader switch in progress will result in
notifications to both Traders involved in the switch.
167
Version 22.24
3.5 Reporting
Sub-process: PR-010 Produce ICP list (on demand)
Process: Produce reports
Participants: Traders, Distributors, Authority, Metering Equipment Providers,

Reconciliation Manager
Code references: Clause 11.19 of the Code
Dependencies:
Description:
This report is used to show the state of a participant’s ICPs over time. It can be requested by
Traders, Distributors, Metering Equipment Providers and the Authority. The participant specifies
which ICPs to include in the report by providing a set of selection criteria or a list of ICP Identifiers.
The report is produced for a given Event Date range. The output of addresses for the ICPs is
optional and selectable.
1. The report must show the values of all attributes, but only the summary level attributes of the
metering attributes of the Metering event, at the start of the date range and all subsequent
changes made during the date range. For every change, all attributes must be shown.
2. The report must be produced as a file in CSV format, as a minimum standard.
3. Events that have been reversed or replaced must not be reported.

4. When selection criteria are used:
 Users must be prevented from using the report as a means of trawling through the ICP
database to extract information from ICPs they do not own,
 The output must only show ICP information for Event Dates that were within the
submitter’s period of responsibility AND are within the specified date range.
5. When a list of specific ICP Identifiers is provided, the output must show all the ICP information
within the specified date range, ie it must ignore responsibility restrictions. Responsibility
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’.
6. Where the report requester has more than one role, the report should extract ICP information
for all the requester’s roles (and be selectable). However, the report should not display
duplicate information. For example, if the requester is both a Distributor and a Metering
Equipment Providers, any ICP information where the requester is both the Distributor and the
Metering Equipment Provider is to appear only once in the report.
168
Version 22.24
7. If the Address is not required, the report is to exclude the Address information for each ICP
output.
8. Selection criteria and ICP lists must be able to be submitted online or via a file.
9. The Authority and the Reconciliation Manager must be able to view information for all
participants.
10. If the output format of PR-010 changes in future then the same format changes must apply to
PR-020.
Data inputs:
Each parameter line is preceded by a line type identifier consisting of “PRAMnn” where nn refers to
the parameter number.
Leaving an optional parameter blank it is assumed that ALL values are required, i.e. there is no
filter.
Multiple space separated values may by input for search criteria.
N.B. Options I and D can now be submitted via the browser as well as SFTP.
Parameter Name Type Mandatory Description/Example

/Optional
List Type Char 1 M I – indicates a list of ICPs is provided in the file
PRAM01 (after PRAM02)
P – indicates a set of parameters defining the
selection criteria
D – indicates a set of ICPs is provided (after
PRAM04) which are date bounded
S – indicates a “snapshot” of currently owned
ICPs is required.
Include Address Char 1 M Y/N
PRAM02
If List Type is “I” the list of ICPs follow the parameters in lines in the following format
Detail record type Char 3 M Must be “DET”
ICP number Char 15 M Valid ICP number
DET lines re-occurring
If List Type is “P” the following parameters are required
Status Char 20 O Report only ICPs with the entered Status.
PRAM03
Trader / Distributor Char 25 O List of participant codes.
PRAM04 If a Trader is submitting the request the codes
must be for Distributors.
If a Distributor or MEP is submitting the report
the participants must be Traders.
If EA or RM is submitting the report then
participants are Traders and Distributors.
169
Version 22.24

/Optional
Reconciliation Char 25 O List of Reconciliation Types.
Type
PRAM05
POC Char 25 O List of POCs.
PRAM06
1Proposed Trader Char 25 O List of Proposed Trader codes.
PRAM07
Roles Char 1 O If a participant has multiple roles then define
PRAM08 under what role the request has been made. For
example if a participant is both a MEP and
Trader they may request the report as a MEP
which will provide visibility to ICPs where they
are not the Trader. Values are
R – Trader
D – Distributor
M – MEP
Blank is the participants default role, e.g. if both
Trader/Distributor and MEP will default to
Trader/Distributor
Profile Char 25 O List of Profiles.
PRAM09
MEP/Distributor Char 25 O List of participant codes.
PRAM10 If a Trader or Distributor is submitting the
request the codes must be for MEPs.
If a MEP is submitting the request then the
codes must be for Distributors.
If EA or RM is submitting the report the the
codes must be for MEPs.
Submission Char 11 O UNM, TNHH, THHR, (for the Trader event
Type/Meter attributes), NHH, PP, HHR (for the Meter Types
Type/UNM Flag on the Metering Event summary).
PRAM11
Highest Metering Char 25 O List of Highest Metering Category Codes from
Category the Metering event summary. Valid values are
PRAM12 1, 2, 3, 4, 5 and 9.
Distributor Price Char 25 O List of Price Category Codes.
Category
PRAM13
Distributor Loss Char 25 O List of Loss Category Codes.
Category
PRAM14
Installation Type Char 6 O
PRAM15
Start Date DD/MM/YY M Report ICPs that submitting participant had
PRAM16 YY responsibility for as at this date
170
Version 22.24

/Optional
End Date DD/MM/YY M Report ICPs that submitting participant had
PRAM17 YY responsibility for as at this date, or between the
Start Date and End Date parameters
If List Type is “D” the following parameters are required
Start Date DD/MM/YY M Report ICPs that submitting participant had
End Date DD/MM/YY M Report ICPs that submitting participant had
The list of ICPs, follow the parameters, in lines in the following format
If List Type is “S” the following parameters are required
Roles Char 1 O See above for description.
PRAM03
List Type I example:

HDR,RQICPLIST,CTCT,RGST,27/12/2001,11:13:12,3,list this ICP
PRAM01,I
PRAM02,N
DET,9999999999AB123
List Type P example:

HDR,RQICPLIST,CTCT,RGST,27/12/2001,11:13:12,17,list these ICP’s
PRAM01,P
PRAM02,Y
PRAM03,001 002
PRAM04,RETA RETB
PRAM05,GN
PRAM06,HOR0661 HOR0331
PRAM07,RETA
PRAM08,R
PRAM09,GXP PP1 PP2
PRAM10,MET1 MET2
PRAM11,UNM HHR
PRAM12,
PRAM13,PrCat
PRAM14,LCat
PRAM15,L
PRAM16,01/04/2009
PRAM17,30/04/2009
List Type D example

HDR,RQICPLIST,CTCT,RGST,27/12/2001,11:13:12,5,list ICP’s
PRAM01,D
PRAM02,Y
171
Version 22.24

/Optional
PRAM03,01/04/2009
PRAM04,30/04/2009
DET,9999999999AB123
List Type “S” example:

HDR,RQICPLIST,CTCT,RGST,27/12/2001,11:13:12,3,list ICP’s
PRAM01,S
PRAM02,Y
PRAM03,M
1 When the report is requested by a Trader, the value of this parameter must be that Trader’s own
Trader code. The output will include all those new and ready ICPs for which the Trader is
nominated as the Proposed Trader. Note that in this instance the ICPs will not be ‘owned’ by the
Proposed Trader as there will not have been a Trader assigned.
So this parameter is not a true filter but it causes the system to include in the resultant output an
additional list of ICPs that are in the New and Ready states (and thus not the responsibility of any
Trader) that have the requesting Trader as the Proposed Trader (ie. where the Distributor believes
Trader responsibility will lie). So in effect the output will show all ICPs the Trader is responsible for
and those where they may have responsibility for. The other filters input will be applied against this
combined list."
Processing:
1. Validate report selection criteria.

Deliver output to correct party.
Data outputs:
Each attribute on an output line is comma separated.

Report information:
Name Format Description (if value not directly obtained from

the registry database)
Record Type Char 3 “DET”
ICP Identifier Char 15
ICP creation date DD/MM/YYYY The date the ICP Identifier of the ICP was first
entered on the registry (Event Date).
Original commissioning DD/MM/YYYY The effective date that the Proposed Trader took
Event Date responsibility for the ICP (Event Date).
Event start date DD/MM/YYYY The Event Date of the change or the date given by
start date parameter, whichever is later.
172
Version 22.24

Event end date DD/MM/YYYY The day before the Event Date of the next change
event, or today’s date, or the date given by the end
date parameter, whichever is earlier.
NSP event audit number Char 15
Network (Distributor) Char 4 Valid Participant Identifier for Distributor.
POC Char 7
Reconciliation Type Char 2
Dedicated NSP Char 1
Installation Type Char 1
Proposed Trader Char 4
Unmetered Load Details – Char 50

Distributor
Shared ICP List List
Generation Capacity Numeric 6.2
Fuel Type Char 15
Initial Electrically DD/MM/YYYY

Connected Date
Direct Billed Status Char 11
Direct Billed Details Char 60
NSP User Reference Char 32
Pricing audit number Char 15
Distributor Price Category Char 50

Code
Distributor Loss Category Char 7

Code
Chargeable Capacity Numeric 7.2
Distributor Installation Char 30

Details
Pricing User Reference Char 32
Trader audit number Char 15
Trader Char 4
Profile Char 25
ANZSIC Char 7
173
Version 22.24

Proposed MEP Char 4
Submission Type HHR Char 1
Submission Type NHH Char 1
UNM Flag Char 1
Daily Unmetered kWh Char 6
Unmetered Load Details – Char 50

Trader
Trader User Reference Char 32
Metering audit number Char 15
MEP Char 4
Highest Metering Category Numeric 1
Meter Type HHR Char 1
Meter Type NHH Char 1
Meter Type PP Char 1
Advanced Metering Char 1

Infrastructure Flag
Meter Channel Count Numeric 3
Meter Multiplier Flag Char 1
Metering User Reference Char 32
Status audit number Char 15
ICP Status Char 3
ICP Status Reason code Numeric 2
Status User Reference Char 32
Address audit number Char 15
Physical Address Unit Char 20
Physical Address Number Char 25

/RAPID number
Physical Address Region Char 20
Physical Address Street Char 30
Physical Address Suburb Char 30
Physical Address Town Char 30
174
Version 22.24

Physical Address Post Numeric 4

Code
Address Property Name Char 75
GPS_Easting Numeric 7.3
GPS_Northing Numeric 7.3
Address User Reference Char 32

Example:
HDR,RSICPLIST,RGST,RETA,01/08/2012,18:44:17,2,ICP List
DET,0000000102TRDBF,01/01/2001,03/01/2001,01/06/2012,15/06/2012,NSP-
123,NETA,TRK1101,GN,N,B,RETA,,,123.5,wind,03/01/2001,Retailer,All,NSPref,PRI-124,PC1,LC1,12.3,,Priceref,REC-
341,RETA,RPS,1234567,RETB,N,Y,N,,,Treref,MET-148,RETB,1,N,Y,N,N,1,N,Metref,STA-123,2,,Statref,ADD-
123,,23,Wellington,23 Hope Street,Seatoun,Wellington,7004,The Gables,1234567.123,123.1,Addref
DET,0000000102TRDBF,01/01/2001,03/01/2001,16/06/2012,31/06/2012,NSP-
123,NETA,TRK1101,GN,N,B,RETA,,,123.5,wind,03/01/2001,Retailer,All,NSPref,PRI-124,PC1,LC1,12.3,,Priceref,REC-
341,RETA,RPS,1234567,RETC,N,Y,N,,,Treref,MET-148,RETB,1,N,Y,N,N,1,N,Metref,STA-123,2,,Statref,ADD-
123,,23,Wellington,23 Hope Street,Seatoun,Wellington,7004,The Gables,1234567.123,123.1,Addref
175
Version 22.24
Sub-process: PR-015 Produce current details report
Participants: Traders, Distributors, Metering Equipment Providers
Code references:
Dependencies: PR-010
Criticality: Non core
Description:
This report allows selection and reporting of individual event attributes of an ICP but only the
summary level attributes for Metering events.
1. The report must allow selection of any ICP attribute for all event types except only the summary
level attributes for Metering events. The selected attribute(s) will be reported.
2. The report will report the selected attributes on all ICP’s for which the participant has
responsibility.
3. The report will build a secondary heading based on the attributes selected.
4. The report is available on-line only.
Data inputs:
Selected ICP attributes
Processing:
For all ICP’s for which the participant has current responsibility report the selected attributes.
Data outputs:
Report information.
The report’s secondary heading and output varies depending on the attributes selected.
Name Type Mandatory/ Description/Example

Optional
Secondary header variable depending on attributes selected
Variable output depending on attributes selected
For example:
Attributes selected on the Trader event:
 Event Date
176
Version 22.24
 Current audit number

 Date changed
 Trader identifier
 Profiles
Output file produced:
HDR,RSCDLIST,RGST,RETA,17/02/2012,12:05:35,00000212
ICP Number, Event Date,Date Changed,Current Audit,Trader,Profiles
0000000102TRDBF,01/08/2004,26/09/2005,REC-22158,RETA,RPS MXP
...
177
Version 22.24
Sub-process: PR-020 Produce monthly Trader ICP reports
Code references: Clause 11 of Schedule 11.1
Description:
This is an automatic report that is produced by 0900 hours on the first business day of each
reconciliation period for each Trader. The report shows the attributes of each ICP for which they are
recorded on the registry as the responsible Trader during the preceding 14 months.
1. The report must show the state of each attribute at the start and end of the date range and all
changes made during the date range. For every change, all attributes must be shown.

4. The automatic run of this report must be initiated by the registry manager for all Traders (or
their agents).
5. The list must include all ICPs for which they are recorded as the responsible Trader within the
last 14 months.
6. An automatic run of this report must be initiated by the registry manager with the following
parameters: for each individual participants extract only ICPs at which the participant is
recorded on the registry as trading, no address, all ICPs (from event Status) and an Event Date
range from the first day of the previous 14th month to the last day of the previous month. N.B.
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.
Data inputs:
Processing:
1. Deliver output to correct party by the time required.
Data outputs:
Report information: See sub-process map PR-010.
178
Version 22.24
Sub-process: PR-030 Produce ICP event detail audit report
Participants: Traders, Distributors, Metering Equipment Providers, Authority
Code references:
Dependencies:
Description:
This report is used to detail individual events together with their audit trail information. It is available
to Traders, Distributors, Metering Equipment Providers and the Authority ‘on demand’.
The objective of the report is to show participants all events that had some impact on them during a
particular period. This could be because they apply to their period of responsibility, or involved a
change (gain or loss) of their responsibility, ie all switch transactions that they were a party to and
events where either the Trader, Metering Equipment Provider or Distributor changed causing a loss
or gain of their responsibility.
The report can be selected to show those events that were input within a date range (audit date) or
that had Event Dates within a date range or a snapshot of all the events “as at” a date and, if
required, subsequent changes to these events up to an end date.
2. For the snapshot option automatically generated as a result of a CS switch or the NT switch
message, the format will be provided in accordance with the participant’s notification
parameters which allows for an XML formatted report. The automatically generated report will
include Event types of Trader, Metering, Address, Network, Pricing and Status only.
3. When requesting the report using a list of ICPs, the resulting output must show all the ICP
events within the specified date range, regardless of responsibility impact considerations.
4. If no ICP list is provided then the output must show all events within the specified date range
that:
 were in the requester’s period of responsibility;
 involve a switch that the requester was a party to; or
 involve a loss or gain of the requester’s responsibility; or
 were inserted, replaced or reversed by the requester.
5. When the requester’s organisation has two roles, (eg Distributors and Traders can also be
Metering Equipment Providers), the report must be generated with reference to the combined
roles i.e. where the event affected both roles it will appear only once in the report.
6. When requesting the report to include reversals and replacements with the search criterion of
Physical/Event = P, the date of the reversal or replacements is to be taken into account ie is
selected if either the input date or the reversal/replaced date falls within the Start and End
Dates.
179
Version 22.24
7. Selection criteria must be able to be submitted online or via a file.

8. If the output format of PR-030 changes in future then the same format changes must apply to
PR-035 and PR-255.
Data inputs:
Each parameter line is preceded by a line type identifier consisting of “PRAMnn”
where nn refers to the parameter number.
filter.
N.B. Option I can now be submitted via the browser as well as SFTP.
Parameter Type Mandatory/ Description/Example

Name Optional
Record Type Char 1 M I – indicates a list of ICPs is provided in the file

PRAM01 as well as parameters to further filter the
information
P – indicates a set of parameters defining the
selection criteria.
S – indicates that a snapshot of the event
information ‘as at’ the Start Date and also any
events from the Start Date to the End Date,
where these dates are different, is required for
the list of ICPs provided in the file. Where
Output file is returned in csv format.
X - indicates that a snapshot of the event
information ‘as at’ a Start Date and also any
events from the Start Date to the End Date,
where these dates are different, is required
for the list of ICPs provided in the file. Output
file is returned in XML format.
If Record Type is “P” or ‘I” the following parameters are required
Trader Char 4 O Ignored if Record Type = I. For Record Type
PRAM02 P, may be specified if the requester has a role
of Distributor, MEP or the EA.
Distributor Char 4 O Ignored if Record Type = I. For Record Type
PRAM03 P, may be specified if the requester has a role
of Trader, MEP or the EA.
MEP Char 4 O Ignored if Record Type = I , S or X. Record
PRAM04 Type P, may be specified if the requester has
a role of Distributor, Trader or the EA.
Note:: when a Trader, Distributor or MEP submits using the Record Type “P” option the submitting
Participants index of ICP current and historical responsibility is used, this ensures only the
Participants own data is returned.
The Authority is not responsible for ICP’s. When submitted by the Authority. instead of trawling the
entire Registry database the responsibility index used is the smallest of PRAM02(Trader),
PRAM03(Distributor) or PRAM04(MEP).
180
Version 22.24

Name Optional
Event Type Char 40 M List event types to be reported, one or more as

PRAM05 below space separated:
TRA – Trader
MET – Metering
SWI – Switch (all TRA events caused by
switching)
ADD – Address
PRI – Pricing
NET - Network
STA – Status
NT – NT message
AN – AN message
TN – TN message (discontinued)
CS – CS message
TT – TT message (discontinued)
NW - NW message
AW - AW message
NC– NC message (discontinued)
RR – RR message
MN – MN message
AC – AC message
Physical/ Char 1 M P – search audits using a date range based on

Event when they arrived at the database or, if the
PRAM06 Include/Reversals is 'Y', then also the date of
the reversal/replacement date.
E – search audits using a date range based on
the Event Date.
Include Char 1 M Y/N.
Reversals
PRAM07
Sort Option Char 1 M Blank – no sort
PRAM08 1 – ICP/Event Type/Date
2 – Event Type/Date/ICP
Start Date DD/MM/YYYY M Start date range to search audits.

PRAM09
End Date DD/MM/YYYY M End date range to search audits.
PRAM10
If Record Type is “S” or “X” the following parameters are required
Start Date DD/MM/YYYY M Report ICPs that submitting participant had
PRAM02 responsibility for as at this date.
Start date range to search audits.
If the Record Type = S or X then this is the ‘as
at’ date (the date the events apply) which
defaults to today’s date if not provided.
End Date DD/MM/YYYY M Report ICPs that submitting participant had
PRAM03 responsibility for as at this date.
181
Version 22.24

Name Optional
End date range to search audits.

If Record Type = S or X and a date value is
input here that is > Start Date then the system
also searches for Events with Event Dates >
Start Date and <= End Date. To obtain only a
snapshot "as at" a date, both the Start and
End Dates must be the same. End Date must
be >= Start Date when input.
The sort sequence for Record Type “S” and “X” is ICP/Event Type/Date (Sort Option 1)
If Record Type is “I”, “S” or “X” the list of ICPs are provided after the parameters in the following
format
Event request example where ICP numbers are supplied:
HDR,RQEVENTDTL,RETA,RGST,27/12/2001,11:13:12,11,list ICP’s
PRAM01,I
PRAM02,
PRAM03,
PRAM04,
PRAM05,TRA AW EP
PRAM06,P
PRAM07,N
PRAM08,1
PRAM09,01/01/2009
PRAM10,31/01/2009
DET,9999999999AB123
Event request example where parameters are supplied:

HDR,RQEVENTDTL,RETA,RGST,27/12/2001,11:13:12,10,list these
PRAM01,P
PRAM02,RETA
PRAM03,NETA
PRAM04,META
PRAM05,REC
PRAM06,P
PRAM07,N
PRAM08,1
PRAM09,01/04/2002
PRAM10,30/04/2002
Event request example for a snapshot with results returned in csv format
PRAM01,S
PRAM02,01/04/2011
PRAM03,01/04/2011
DET,9999999999AB123
DET,8888888888AB321
182
Version 22.24

Name Optional
Event request example for a snapshot with results returned in xml format:
PRAM01,X
PRAM02,01/04/2011
PRAM03,01/04/2011
DET,9999999999AB123
DET,8888888888AB321
Processing:
1. Validate report selection criteria.

2. Deliver output to correct party. For the snapshot option produced as a result of a switch (RS-
050) format the output either in CSV or XML format as indicated by the participant’s notification
option.
Data outputs:
Report information:
Fields returned vary depending on the Event Type(s) selected
Verbose output event types correspond to input event types as follows.

Input Event Type Output Event Type (full description) XML Level
TRA Trader 1
NET Network 1
MET MeterSummary 1
MeterInstall 2
MeterComp 3
MeterChannel 4
PRI Pricing 1
STA Status 1
ADD Address 1
SWI Switch 1
NT NT 1
AN AN 1
TN TN 1
TT TT 1
CS CSPremises 1
CSMeterInstall 2
CSMeterComp 3
CSMeterChannel 4
183
Version 22.24
RR RRPremises 1
RRMeterChannel 2
AW AW 1
AC AC 1
NW NW 1
AW AW 1
AC AC 1
MN MN 1
184
Version 22.24

the database)
Event type (full description) Char 14 Variable fields depend on the value of this field.
For example, if the event type is ‘metering’ then
immediately after the last fixed field, the Metering
event attributes are listed.
Event audit number Char 15
Event Date DD/MM/YYYY
Event creation date/time DD/MM/YYYY

HH:MM:SS
Created by Char 15 Participant ID
File name Char 25 N.B. Registry definition is actually variable length

and can be more than 25 Characters.
Event state Char 8
Reversal/replaced date/ DD/MM/YYYY

time HH:MM:SS
Reversed/replaced by Char 15
Reversal/replacement file Char 25

name
Replacement event audit Char 15

number
Trader event Variable fields. Event type is “TRADER”
Trader
Profile
Submission Type HHR
Submission Type NHH
ANZSIC
Proposed Metering
Equipment Provider
UNM Flag
Unmetered load details –

Trader
Daily unmetered kWh
Trader User Reference
185
Version 22.24

the database)
Metering event – Summary Variable fields. Event type is “METERSUMMARY”
Metering Equipment
Provider
Highest Metering Category
HHR Flag
NHH Flag
PP Flag
AMI Flag
Meter Channel Count
Meter Multiplier Flag
Metering User Reference

Metering event – Installation Information Variable fields. Event type is “METERINSTALL”
Metering Installation
Number
Location Code
ATH Participant Identifier
Metering Installation Type
Certification Type
Certification Date
Control Device Certification

Flag
Certification Variations
Expiry Date
Certification Number
Maximum Interrogation
Cycle
186
Version 22.24

the database)
Lease Price Code

Metering event – Component Information Variable fields. Event type is “METERCOMP”
Number
Metering Component Serial

Number
Metering Component Type
Meter Type
AMI Flag
Category
Compensation Factor
Owner
Removal Date
Metering event – Channel Information Variable fields. Event type is “METERCHANNEL”
Number

Number
Channel number
Number of Dials
Register content code
Period of availability
Unit of Measurement
Energy Flow Direction
Accumulator Type
Settlement Indicator
Event Reading
Switch Variable fields. Event type is “SWITCH”.
Trader
Address Variable fields. Event type is “ADDRESS”
Physical Address Unit
187
Version 22.24

the database)
Physical Address Number/

RAPID number
Physical Address Region
Physical Address Street
Physical Address Suburb
Physical Address Town
Physical Address Post

Code
Address Property Name
GPS_Easting
GPS_Northing
Address User Reference

Network pricing Variable fields. Event type is “PRICING”.
Distributor Price Category

Code
Distributor Loss Category

Code
Chargeable Capacity
Distributor Installation
Details
Network pricing User

Reference
NET Variable fields. Event type is “NETWORK”.
Network Valid Participant Identifier for Distributor.
POC
Reconciliation Type
Dedicated NSP
Installation Type
Proposed Trader
Participant Identifier
Unmetered Load Details –

Distributor
Shared ICP List
188
Version 22.24

the database)
Generation Capacity
Fuel Type
Initial Energisation Date Note: Initial Electrically Connected as described in

the code is synonymous with Initial Energisation
Date. For XML output the term Initial Energisation
Date will continue to be used so participants are not
required to make any internal change to their
systems. Participants will be notified in advance
when the XML term (Initial Energisation Date) is
aligned with the term used by the code.
Direct Billed Status
Direct Billed Details
Network User Reference

Status Variable fields. Event type is “STATUS”.
ICP Status
ICP Status Reason code
Status User Reference

NT Variable fields. Event type is “NT”.
Trader
Install Address Unit
Install Address Number/

RAPID number
Install Address Region
Install Address Street
Install Address Suburb
Install Address city
Install Post Code
Install Property Name
Proposed Transfer Date
Switch Type
Proposed Profiles
Proposed ANZSIC
User Reference
189
Version 22.24

the database)
AN Variable fields. Event type is “AN”
Trader
Response Code
Expected Transfer Date
User Reference
TN Variable fields (Discontinued). Event type is “TN”
Trader
Actual Transfer Date
Relay Owner
Number Of Meters
User Reference
TT Variable fields. (Discontinued) Event type is “TT”
Trader
ICP Status
Status Reason
Primary Metering Contact

Category
Meter Type HHR
Meter Type NHH
Meter Type UNM
Meter Type PP
Meter Type ADV
Unmetered Load Details –

Trader
Daily Unmetered kWh
Meter Register Count
Profile
User Reference
190
Version 22.24

the database)
NW Variable fields. Event type is “NW”
Trader
Advisory code
User Reference
AW Variable fields. Event type is “AW”
Trader
Withdrawal Transfer Status
User Reference
NC Variable fields. . (Discontinued) Event type is “NC”
Trader
Relay Owner
Number Of Meters
User Reference
AC Variable fields. Event type is “AC”
Trader
Switch Read
Acknowledgement
User Reference
CS and RR - Premises Variable fields. Event type is “CS” or “RR”
Trader
User Reference
CS - Installation Variable fields. Event type is “CSMETERINSTALL”
Identifier
Average Daily
Consumption
Key Held Indicator
CS - Meter Variable fields. Event type is “CSMETERCOMP”
191
Version 22.24

the database)
Identifier

Number
Last Read Date
Meter Reader Notes
CS and RR - Channel Variable fields. Event type is

“CSMETERCHANNEL” or “RRMETERCHANNEL
Identifier

Number
Channel Number
Reading Only shown in the report of the Traders that were

parties to the switch and also the responsible
Distributor and the MEP, otherwise null.
Actual or Estimate
MN Variable fields. Event type is “MN”
MEP Identifier
Transfer Date
Responsibility Indicator
Decline Advisory code
User Reference
192
Version 22.24

the database)
Examples:
See appendix 5 for example of snapshot report in XML format (produced from a CS switch).
PR-030 snapshot “as at” 01/04/2012 Start Date and End Date are the same, output in csv format
(including Meter event with 1 installation, 1 meter and 1 register):
HDR,RSEVENTDTL,RGST,RETA,01/03/2012,18:44:17,9,CS Switch snapshot

DET,1234567890AB123,ADDRESS,ADD-987656,25/01/2009,25/01/2009 08:15:30,Bruce,File
A.csv,Active,,,,,,27,Wellington,234 Seaview Road,Seatoun,Wellington,4001,The Larches,1234567.123,987.3,myref
DET,1234567890AB123,METERSUMMARY,MET-123,12/03/2012,13/03/2012 11:11:30,Matt,File
D.csv,Active,,,,,META,1,N,Y,N,N,2,Y,myref
DET,1234567890AB123,METERINSTALL,MET-123,12/03/2012,13/03/2012 11:11:30,Matt,File
D.csv,Active,,,,,1,1,BD,ATHA,NHH,F,21/03/2012,21/03/2023,Y,X,21/03/2015,12345ABC,12,Code1
DET,1234567890AB123,METERCOMP,MET-123,12/03/2012,13/03/2012 11:11:30,Matt,File
D.csv,Active,,,,,1,ABCDE1,M,NHH,N,1,2.234,OWNER1,
DET,1234567890AB123,METERCHANNEL,MET-123,12/03/2012,13/03/2012 11:11:30,Matt,File
D.csv,Active,,,,,1,ABCDE1,1,3,DN,24,kWh,X,C,Y,678
DET,1234567890AB123,NETWORK,NET-222,25/01/2009,25/01/2009 08:15:30,Bruce,File
A.csv,Active,,,,,NETA,GFD0331,GN,N,B,RETA,,,123.5,wind,05/01/2009,Retailer,bill half to Acc Number 349145,myref
DET,1234567890AB123,PRICING,PRI-456,25/01/2009,25/01/2009 08:15:30,Bruce,File
A.csv,Active,,,,,PC1,LC1,12.3,,myref
DET,1234567890AB123,STATUS,STA-444,12/03/2012,14/03/2012 07:00:59,Matt,File C.csv,Active,,,,,2,0,myref
DET,1234567890AB123,TRADER,REC-333,12/03/2012,13/03/2012 10:21:30,Matt,File B.csv,Active,,,,,RETA,RPS
MXP,N,Y,1234567,META,Y,5kWh,7,myref
193
Version 22.24
Sub-process: PR-035 Produce ICP Attribute Changes
Participants: Authority
Code references:
Criticality: Non-core
Description:
This report is used to detail daily changes to ICP attributes.
The report provides information to the Authority’s data warehouse for analysis of switch trend
information.
Daily extract
The net results of ICP Attribute updates occurring the previous day are reported.
The resulting extract file will be delivered to the Authority’s SFTP fromreg folder and the Authority’s
SFTP server. The target delivery time is 6am.
The extract is sorted by ICP Identifier, Event Type and Event Date.
File output name will be “ICPEventFile_<timestamp>.csv” where timestamp is format
“yyyymmddhhmmss” and specifies the report run time.
Baseline Data extract

A special case of this report is a baseline data extract which can be obtained upon arrangement
with the registry manager.
This baseline report includes attributes for all ICP’s which resided in the registry as at a date
specified by the Authority. This will contain one record for each ICP and event type (Address,
Network, Pricing, Trader, Metering, Status), and does not include switch messages.
The resulting extract file will be delivered to the Authority’s SFTP fromreg folder and the Authority’s
SFTP server.
194
Version 22.24
Data inputs:
1. Daily report
(or Baseline report, by arrangement only)
2. Report start date
3. Report end date (daily report only).
Processing:
Baseline Report
1. Read all ICP records at the report date
2. Generate output file with ICP events as the report date
3. Transfer the output file to the Authority SFTP fromreg folder
4. Transfer the output file to the Authority SFTP server
Daily Extract
1. Read the event audit records that have been updated in the registry in the reporting day.
2. Identify the net effective event updates for the previous day
3. Generate output statistic file
4. Transfer of output file to:
i. Authority SFTP fromreg folder
ii. Authority SFTP server
Data outputs:
Format for the baseline report is as defined for report PR-030, and includes base events only.
Format for the daily report is as defined for report PR-030, with the following modifications to
include TN and CS information:
ICP Identifier As PR-030
Event Description As PR-030
Event Audit Number As PR-030
Event Date As PR-030
Event Creation Date/Time As PR-030
Created By As PR-030
File name As PR-030
Event state As PR-030
Reversal/replaced date/ time Blank
Reversed/replaced by Blank
Reversal/replacement file name Blank
Creation event audit number Populated where the event is a reversal or
replacement and cross references to the Audit
Number which created the Event
TN Variable fields.
Trader As PR-030
Actual Transfer Date As PR-030
195
Version 22.24
Relay Owner As PR-030

Number Of Meters As PR-030
User Reference As PR-030
Meter Location Codes Multiple codes are space-delimited. Extracted from
the ‘M’ record types submitted in the TN.
Register Content Codes Multiple codes are space-delimited. Extracted from
the ‘R’ record types submitted in the TN.
CS
Trader As PR-030
Actual Transfer Date As PR-030
Relay Owner null
Number Of Meters Calculated from the number of component rows
supplied in the CS.
User Reference As PR-030
196
Version 22.24
Sub-process: PR-040 Produce switch compliance reports
Participants: Traders, Authority, Metering Equipment Providers
Code references: 11.23 and 11.19
Dependencies:
Description:
This is an automatic report that is produced every month by 1600 hours on the first business day of
each reconciliation period for the Authority. It can also be requested ‘on demand’ at other times by
Traders, MEPs and by the Authority. Traders and MEPs can only obtain information pertaining to
themselves. The Authority can select information for individual or all Traders and MEPs.
There are two types of switch compliance reports: historical and current.
The ‘historical’ reports show, either in summary or in detail, those switch transactions that were not
received by their due date, where the due date was in the past. The Authority requires the
automatic delivery of both the summary and detail historical reports for potential Code breaches of
the previous consumption period.
The ‘current’ reports show, either in summary or in detail, which switch transactions have not been
completed ‘as at’ today, either because the relevant switch message has not arrived and, either the
due date has passed (overdue), or because the due date has not been reached yet. This report is
used to show work in progress.
Calculation of due dates
The provisions for the calculation of due dates of each potential breach type need to be
maintainable by the Authority as they may change over time. The provisions set out in this report
relate to the receipt of the following breach types within certain timeframes by the intended
recipient:
AN delivery—an AN must be delivered by the losing Trader within 3 business days of the receipt of
an NT unless a CS or NW notice was provided within this time.
TN*/CS delivery—a TN*/CS with a switch type of either MI or TR must be delivered by the losing
Trader within 10 business days of the receipt of the NT if an AN or NW notice has been received. If
an AN or NW notice has not been received, the TN*/CS (with a switch type of either MI or TR) must
be delivered within 3 business days of the receipt of the NT.
TN*/CS Event Date—a TN*/CS must be delivered within 3 business days of the Actual Transfer
Date recorded on the same TN*/CS or (if the Actual Transfer Date was backdated) within 3
business days of the receipt of the NT, whichever is the later date. For a switch type of HH the CS
is delivered by the gaining Trader otherwise it is the losing trader that delivers it.
197
Version 22.24
TT* Event Date—a TT* must be delivered within three business days after the Actual Transfer
Date recorded on the same TT* or (if the Actual Transfer Date was backdated) within 3 business
days of the receipt of the NT, whichever is the later date.
NW delivery—an NW must be delivered by either Trader within 3 business days of the receipt of
the NT unless an AN or TN*/CS notice was provided within this time.
NW after switch completion delivery – an NW must be delivered within 2 calendar months after
the completion of the switch.
AW delivery—an AW must be delivered within five business days of the receipt of the
corresponding NW.
Withdrawal cycle resolution—an AW acceptance must be delivered within 10 business days of
the receipt of the initial NW unless an AN, TN*/CS or TT* was provided in this time.
NC*/RR delivery—an NC*/RR must be delivered within four calendar months after the Actual
Transfer Date of the latest TN*/CS.
AC delivery—an AC must be delivered within five business days of the receipt of the
corresponding NC*/RR.
MN delivery – an MN acceptance must be delivered within 11 business days of the Input Date of
the Trader event that first proposed the MEP. For switch breach processing purposes, the Switch
Type of MN is assigned to any MN delivery breaches reported (due and overdue).
The arrival of an MN decline or a nomination of a new MEP by the submission of a new Proposed
MEP attribute on the Trader event or the reversal of the Trader event that commenced this MEP
switch means that there will be no MN acceptance arriving therefore the potential switch breach
record is deleted (even if overdue).
* These messages will be discontinued from go live but will be retained in historical records.
______________________________________________________________________________
Note that after the receipt of an NT, if either the AN, TN*/CS or NW is received late then the report
will show three breaches – an AN delivery breach, a TN*/CS delivery breach and an NW delivery
breach.
It must be noted that the ‘delivery’ of a message, for compliance purposes, means the time the
message was sent to the registry. Delivery to the required party is assumed to be ‘immediate’ even
though the time between the registry receiving the messages and their delivery to the required
party could be significantly different as participants can elect that the registry sends switch
messages at specific times of the day (see switch notify parameters). However, if the message
was received by the registry after 1930 hours, it is deemed to be provided at 0730 hours the next
day (clause 11.20(2) of the Code).
Note also that TN*/CS Event Date, TT* Event Date and NC*/RR delivery breaches are not relevant
to the ‘current’ switch breach reports as they cannot be evaluated until they have actually been
received.
198
Version 22.24
Calculation of days overdue
Days overdue = Number of days between (date of delivery of relevant document to participant, due
date), where date of delivery is after due date.
If the relevant document has not arrived (no date of delivery), then for reporting purposes use
today’s date (runtime of the report). Assume document has until midnight to arrive.
Calculation of business days
From Part 1 of the Code: “business day” means any day of the week except Saturdays, Sundays,
national holidays and any other day from time to time declared by the market administrator not
to be a business day by notice to each registered participant in the manner set out in the Code;
Business days must be treated as calendar days, not multiples of 24 hours. For example, registry
routes NT to Trader at any time on 23 January; current Trader then has until midnight on 26
January to deliver the AN back to the registry.
The days overdue calculation is performed to a maximum of 100 days, with larger durations
represented by the value 99999 business days.
Note: There may be multiple potential breaches per ICP: for example, an AN not received and CS
not received (this counts as two breaches); NT sent out by the registry on 2 April 2002, no AN
received at all, CS received by the registry on 19 April 2002. The report should output this as a
breach of type AN with days overdue equal to 10 (assuming no holidays).
Data inputs:
filter.
Parameter Type Mandatory Description/Example

Name /Optional
Switch Type Char 15 M S SM H HM HN NH MI or TR or MN or HH

PRAM01
Breach Type Char 29 M AC (AC Delivery)
PRAM02 AN (AN Delivery)
AW (AW Delivery)
NC*/RR (NC*/RR Delivery)
NW ( NW Delivery)
NA (NW after switch completion)
TN*/CS (TN*/CS after an AN)
T2 (TN*/CS after an NT)
E2 (TN*/CS Event Date)
199
Version 22.24

Name /Optional
TT* (TT* – historical only)

E3* (TT* Event Date)
WC (AW acceptance – withdrawal cycle
resolution)
MN (MN Delivery)
TN, TT, E3 and NC breaches are retained in
historical records only
Summary or Char 1 M S or D
Detail
PRAM03
For the current report:

As At Date DD/MM/YYYY M Input ignored, this is always defaulted to today’s
PRAM04 date
Days Due or Num 3 M If negative then days until due, if positive then
over due days over due
PRAM05
PRAM06
PRAM07
1Days Due or Num 3 M If negative then days until due, if positive then
PRAM08
Trader or Char 4 M The submitting Trader or MEPs participant code,
MEP EA may enter any code.
PRAM09
Breach Party Char 1 O B – report breaches on both participants in the
PRAM10 breach
S – report breaches you are responsible for
O – report breaches other participant is
responsible for
For the historical report:
Start Date DD/MM/YYYY M
PRAM04
End Date DD/MM/YYYY M
PRAM05
PRAM06
PRAM07
200
Version 22.24

Name /Optional
PRAM08
1Days Due or Num 3 M If negative then days until due, if positive then
PRAM09
Trader or Char 4 M The submitting Trader or MEPs participant code,
MEP EA may enter any code.
PRAM10
Breach Party Char 1 O B – report breaches on both participants in the
PRAM11 breach
S – report breaches you are responsible for
O – report breaches other participant is
responsible for
1anassumed 5th bucket exists which is > than highest positive bucket specified, if no positive value
specified then 1 day is assumed
Switch breach report request example (historical):
HDR,RQSWBRHIST,RETA,RGST,27/12/2001,11:13:12,11,list breaches
PRAM01,S HN
PRAM02,TT E3
PRAM03,D
PRAM04,01/09/2009
PRAM05,30/09/2009
PRAM06,-20
PRAM07,-10
PRAM08,5
PRAM09,10
PRAM10,RETA
PRAM11,B
Switch breach report request example (current):

HDR,RQCUSWBR,RETA,RGST,27/12/2001,11:13:12,10,list breaches
PRAM01,S HN
PRAM02,TT E3
PRAM03,D
PRAM04,
PRAM05,1
PRAM06,3
PRAM07,5
PRAM08,10
PRAM9,RETA
PRAM10,B
201
Version 22.24
For the historical report
1. From/to date range: transactions that had due dates in this range.
Days overdue or ageing buckets: for the detail report, only the minimum days overdue is specified
(minimum value is 1). For the summary report, the user can specify up to four ageing buckets.
The resultant report must generate an additional column for all overdues greater than the final
bucket. The values are to be input in sequence, i.e. in ascending sequence.
For the current report
1. Ageing buckets (summary report only): The report can be produced summarising transactions
that are overdue as at today’s date and also those due in the future. The resultant report
generates an additional column for all greater than the final bucket input. If requiring those due
in the future in a bucket, negative values are input. The values should be input in ascending
sequence, ie greatest negative through to the highest positive.
Days till due (detail report only): Selects those due within this number of days (from today’s date).
Days overdue (detail report only): Selects those with this minimum number of days overdue.
Processing:
For the history summary report system
1. Calculates the due dates.
2. Selects those where:
 they are overdue;

 the specified Trader or MEP (s) was a participant (sender or other participant);
 the due date is within the from/to date range specified; and
 all other selection criteria is satisfied.

3. Assigns the days overdue count into one of the user-specified ageing buckets or the system-
generated catch-all bucket. It is possible that the transaction does not fall into any bucket
therefore is excluded from the report.
4. Determines the participant in breach (defaulting participant).
5. Sorts the report by switch type/breach type/defaulting participant.
For the history detail report system
 they are overdue;

 the specified Trader or MEP (s) was a participant (sender or other participant);
 the due date is within the from/to date range specified; and
202
Version 22.24
Processing:

3. Selects only those transactions overdue by a number of days equal to or greater than the days
overdue input by user.
4. Determines the defaulting participant.

5. Sorts the output by switch type/breach type/defaulting participant/days overdue (descending).
For the current summary report system

 the actual arrival date is missing (not arrived yet);
 the specified Trader or MEP (s) was a participant (sender or other participant); and
3. Determines the days overdue or days till due (ie if due date not reached yet) and assigns the
count into one of the user-specified ageing buckets or the system-generated catch-all bucket.
For the purposes of this report the days till due are treated as negative values. It is possible
that a transaction does not fall in any bucket and therefore is excluded from the report.

5. Sorts the report by switch type/breach type/defaulting participant.
For the current detail report system

 the actual arrival date is missing (not arrived yet);
 the specified Trader or MEP (s) was a participant (sender or other participant); and
3. Determines the days overdue or days till due. If overdue, selects only those transactions
overdue by a number of days equal to or greater than the days overdue input by user. If due,
selects those transactions less than or equal to the days till due parameter.

5. Sorts the output by switch type/breach type/defaulting participant/days overdue (descending)
then days till due (descending).
NB: If the user specified all breach types then an ICP could potentially be included several times in
the report.
203
Version 22.24
Data outputs:
The current/details output line is preceded by a line type identifier consisting of “DET” (detail). All
other output files have no line type identifier and start with the Switch Type.
History summary output information
Name Format Description
Switch Type Char 2 From qualifying event.
Breach type Char 2
Defaulting Char 4 Derived by system.

participant
Other Numeric The non-defaulting participant impacted by the switch.

participant
Total count in Numeric Total of ageing 1 to 5.

breach
Ageing 1 Numeric Overdue <= ageing 1 days.
Ageing 2 Numeric Overdue > ageing 1 days and <= ageing 2 days.
Ageing 5 Numeric Overdue > ageing 4 days.

History detail output information
Breach type Char 2

Participant
Identifier
Other Char 4 The non-defaulting participant impacted by the switch.

Participant
Identifier
ICP # Char 15
Sent date DD/MM/YYYY The date the notice or message was sent by the registry to the
recipient.
Due date DD/MM/YYYY The date that notice of the switch event that is subject to a
breach was due to be received (Event Date).
Completion DD/MM/YYYY The date that notice of the switch event that is subject to the
date breach was completed (actual arrival date).
Days overdue Numeric Number of business days the event is overdue.
204
Version 22.24
Data outputs:
Current summary output information
Breach type Char 2

participant

participant
Total count in Numeric Total of ageing 1 to 5.

breach
Ageing 1 Numeric Overdue or due <= to ageing 1 days.
Ageing 2 Numeric Overdue or due > ageing 1 days and <= to ageing 2 days.
Ageing 3 Numeric Overdue or due > ageing 2 days and <= to ageing 3 days.
Ageing 4 Numeric Overdue or due > ageing 3 days and <= ageing 4 days.
Ageing 5 Numeric Overdue or due > ageing 4 days.

Current detail output information
Breach type Char 2

Participant
Identifier

Participant
Identifier
Sent date DD/MM/Y The date the notice or message was sent by the registry to the
YYY recipient.
Due date DD/MM/Y The date that notice of the switch event that is subject to a breach
YYY was due to be received.
Days till due Numeric Number of business days from today’s date until the event is due
(calculated if the due date is in the future).
Days overdue Numeric Number of business days the event is overdue.
205
Version 22.24
Sub-process: PR-050 Produce ICP days report
Participants: Reconciliation Manager
Code Clause 11.26(a) of the Code.

references:
Dependencies:
Description:
This report is produced for the Reconciliation Manager automatically twice a month and on
demand. The report identifies the number of ICP days, per NSP, differentiated by half-hour
metering type or non-half hour metering type attributable to each Trader for NSPs that are recorded
on the registry as consuming electricity during the consumption period(s) (i.e ICPs that had the
Status of active). Only ICPs with Installation Types of ‘Load’ and ‘Both’ are included.
N.B. If an ICP is active on a day when its associated NSP is inactive, the day is excluded from the
count of ICP days for that ICP. If the count of ICP days is zero for a whole consumption period, the
entry is not reported to the Reconciliation Manager.
206
Version 22.24
1. The registry must deliver the information to the Reconciliation Manager for the prior
consumption period by 1600 hours on the 4th business day of the current reconciliation period.
2. The registry must deliver revised information to the Reconciliation Manager in respect of the
immediately preceding 14 consumption periods, by 1600 hours on the 13th business day of the
current reconciliation period.
3. The calculation for each Trader includes all those ICPs for which a Trader was responsible
during the relevant consumption period that were active during that time. The number of active
days is split by month.
4. Only ICPs with Installation Types of ‘Load’ and ‘Both’ are included.
5. The ICP days calculated per ICP and month (consumption period) are then summarised by
NSP, submission type HHR, submission type NHH and month. Metering types of unmetered
and pre-pay will have been taken into account by the Trader when assigning the submission
types HHR and NHH.
6. Where an ICP has both half-hour and non-half-hour submission types, two entries are to
appear on this report (they will have the same number of ICP days calculated for each
submission type).
7. Each ICP must be regarded as active only for the days when the associated NSP is also
active. Where an ICP is recorded as being active outside its NSP effective date range (as per
the NSP Mapping static data table), the Registry must:
a. reduce the ICP days calculated to match the number of days the NSP was active in the
consumption period where the ICP consumption days exceeds the NSP active days for
the consumption period, and
b. exclude the ICP days calculated from the report to the Reconciliation Manager, where
an NSP has zero days active in the consumption period, and
c. report to the Authority, as a Consumption Error (see SD-050), all instances of

consumption outside the NSP effective date range and include the following
information:
i. ICP Identifier
ii. NSP Identifier

iii. Trader Identifier
iv. Consumption period end date.

8. The results of NSP level validation must be reported regardless of whether Consumption
Errors have been detected.
9. The report must be able to be re-sent for a particular month via an ftp request.
207
Version 22.24
Data inputs:
Name Format Mandatory/ Description/Example
Optional
Reporting Type Integer M 1 – 1 month period
14 – 14 month period
Reporting Period MMYYYY M/O Mandatory if Reporting Type is 1. This will be

the period being reported.
Optional if Reporting Type is 14. The 14

month report will cover the 14 prior months up
to and including the previous month.
Participant Char 4 O Participant whose ICP days will be reported.

Identifier
Request example:
HDR,RQMICPDAYS,RETA,RGST,24/02/2012,10:11:12,1,ListDays
DET,1,102011,RETB
Processing:
The system:
1. For each preceding consumption period, Trader, Submission Type, NSP, and ICP, calculates
the ICP period (start date and end date) and the total number of days the ICP was recorded in
the registry as being active (ICP days).
2. For each ICP period, checks against the NSP Mapping table to ensure that the whole period
falls within an active period of the associated NSP. If it does not, then the system reduces the
calculated ICP days by the number of days the NSP was inactive during this ICP period.
3. Sums the ICP days of all the ICP periods by consumption period (descending), Trader,
Submission Type and NSP.
4. Where the ICP days is zero for a consumption period, omits reporting the ICP days information
to the Reconciliation Manager.
5. Informs the Authority of the results of the NSP level validation..
Data outputs:
ICP days output information
Name Format Comment
Month MM/YYYY Consumption period (format mm/yyyy).
Trader Identifier Char 4 Trader Participant Identifier.
208
Version 22.24
Submission Type Char 3 ‘NHH’ or ‘HHR’.
NSP Char 11 NSP identifier.
ICP days Numeric Calculated value – total number of days the Trader’s
ICPs were active for NSPs recorded on the registry as
consuming electricity during the consumption period.
Note that NSP consumption is inferred from the

consumption of ICPs recorded at that NSP.
Example:
HDR,RSMICPDAYS,RGST,RETA,24/02/2012,11:02:13,00000002,ListDays
DET,01/2011,RETB,NHH,NETAABY0111,123
DET,01/2011,RETB,NHH,NETAAZZ0111,14
Sample email for an ICP Days Consumption Error
Heading:
Consumption error report from Registry: Report - ICP Days
Message text:
The following ICPs have been detected with consumption outside their NSPs effective date ranges,
An investigation is required to determine why the Registry has identified these ICPs:
ICP <ICP Id> has consumption recorded for Trader <trader id> exceeding the number of days the
NSP <NSP identifier> was active during Month: <consumption month>
Alternate Message text where no consumption errors detected:

No ICP’s were detected with consumption outside any NSP’s effective date ranges.
Example 1: PR-050 ICP Days report

Consumption error report from Registry : Report - ICP Days
The following ICPs have been detected with consumption outside the NSP effective date ranges.,
An investigation is required to determine why the Registry has identified consumption these:
ICP 123456789ABC123 has consumption recorded for Trader RETA exceeding the number of days
the NSP NETANETA001 was active during. Month: 30/04/2015
ICP 9876543210AB321 has consumption recorded for Trader RETB exceeding the number of days
the NSP NETANETA001 was active. during Month: 30/04/2015
Example 2: PR-050 ICP Days report

Consumption error report from Registry: Report - ICP Days
No ICP’s were detected with consumption outside any NSP’s effective date ranges.
209
Version 22.24
Sub-process: PR-060 Produce audit log
Participants: Distributors, Traders, Metering Equipment Providers, Authority.
Code references: 11.19
Dependencies:
Description:
The user can request ‘on demand’ that the registry sends them a log of all the files the registry has
delivered to them, over a specified period, in order to check that the registry has processed all the
information the participant has sent.
1. The registry must be able to provide all users with a log giving all the dates and times when
files were sent by it to the user’s company.
2. The user must be able to specify a period during which files were sent.
3. Only details of files sent to the requesting user’s company must be included in the log.
4. The log must include details of all types of file sent, ie switching messages, acknowledgements,
notifications and reports.
5. For each file, the log must contain the time and date it was sent.
6. The registry must deliver the log immediately in a single file.
Data inputs:
filter.

Optional
File Type Char 3 M Type of file to be reported, Recognised types

are
ACK – overnight acknowledgement files
NOT – overnight notification files

SW – switch files
Start Date DD/MM/YYYY M Start date for query
210
Version 22.24

Optional
End Date DD/MM/YYYY M End date for query, must be equal of later
than Start Date
Request example:
HDR,RQAUDIT,CTCT,RGST,27/12/2001,11:13:12,2,list files
DET,NOT,01/01/2009,31/01/2009
Processing:
1. Validate selection criteria.
Deliver the log to the correct party.
Data outputs:
Each attribute on an output line is comma separated
A file containing the requested audit log.
Record Type Char 3 Will always be “DET”
File Name Char 25
Sent Date DD/MM/YYYY Date file was sent from the Registry
Example:
HDR,RSAUDIT,RGST,CTCT,22/02/2002,15:55:33,4,All My Files For April
DET,ICP20010401111114.ack,01/04/2001
DET,NOT20010401000035.txt,01/04/2001
DET,LIS20010404161417.txt,04/04/2001
DET,ICPUpdateProfiles.ack,16/04/2001
211
Version 22.24
Sub-process: PR-065 Request file handler status
Participants: Distributors, Traders, Metering Equipment Providers, Authority.
Code references:
Dependencies:
Criticality: Non core
Description:
The Participant may request a report on all batch jobs currently queued or being processed by the
Registry file processors.
1. The registry must be able to provide all users with a list of the batch jobs currently queued or
being processed
Data inputs:
A file containing a header may be submitted.
Request example:
HDR,RQFHSTATUS,RETA,RGST,23/03/2007,15:49:06,00000000,my user reference
Processing:
1. Interrogate the Registry job queue and report all batch jobs
Data outputs:
A file containing the requested audit log.
Object Identifier Char Unique job object identifier
File Name Char 25
File Status Char 4 000 – waiting file handler

010 – processing
011 – recovering
999 – in error
212
Version 22.24
Participant Identifier Char 4
Date processing started DD MMM YY
File size Char 1 S – Small

L - large
Records processed Numeric
Char 4 LFP0 – Large File processor number 0

LFP1 – Large File processor number 1
LFP2 – Large File processor number 2
DFP0 – Dual file processor number 1
File processor identifier DFP1 – Dual File processor number 1
DFP2 – Dual File processor number 2
SFP0 – Small file processor number 1
SFP1 – Small File processor number 1
SFP2 – Small File processor number 2
NFP0 – Notify File processor number
Example:
HDR,RSFHSTATUS,RGST,RETA,30/05/2011,10:42:50,00000004,Jason
2245.769,$_LIS20070530103209.txt,000,RETA,30 May 2007 10:34:52,S,4750,DFP2
2245.771,$_LIS20070530103242.txt,010,RETA,30 May 2007 10:35:56,S,4750,SFP0
2245.773,$_LIS20070530103305.txt,010,RETB,30 May 2007 10:36:14,S,4750,DFP1
2245.783,$_FHSFHS20070323154906.txt,010,NETA,30 May 2007 10:42:37,S,0,DFP2
213
Version 22.24
Sub-process: PR-070 Produce monthly statistics
Participants: Distributors, Traders, Metering Equipment Providers, Authority
Code references: Clause 11.23 of the Code.
Dependencies:
Description:
The registry must publish monthly statistics about the number of ICPs notified to the registry, the
number of switch notifications received by the registry in accordance with clause 2 of Schedule
11.3, and any other information agreed between the registry and the Authority, by 1600 hours on
the 6th business day of each month for the previous consumption period.
Business Requirements:
Part 1: ICP Totals [file 1]
Report the following summary totals at the end of each month. These represent accumulated total
values for the Registry at the end of the report month.
End of the Month. A snapshot of the Registry demographics as at the end of the month. This
includes:
1. Number of ICP’s on the registry.
Number of ICP’s split by Status, i.e. total number new, ready, active, inactive, distributor,
decommissioned
2. Number of ICP’s with NEW Status
3. Number of ICP’s with READY Status
4. Number of ICP’s with ACTIVE Status

5. Number of ICP’s with INACTIVE Status
6. Number of ICP’s with DISTRIBUTOR Status
7. Number of ICP’s with DECOMISSIONED Status

8. Number of switches completed during the month. This includes all non withdrawn switches
where the switch Actual Transfer Date is in the report month.
9. Number of unique NSP’s where the NSP is used by an ICP

In addition, the following Activity Statistics are collected for reporting purposes. These represent
activity values for the Registry during the report month.
1. Number of customers switched. Includes all switches that are completed (TN, CS or TT
received) during the month regardless of the Actual Transfer Date of the switch. Does not
include withdrawn switches
214
Version 22.24
2. Number of ICP’s created in the month (new ICP’s)
3. Number of ICP’s decommissioned during the month.
4. Number of ICP’s made inactive during the month.

5. Number of ICP enquiries during the month. This includes:
o on-line
 address search, increment for each search request

 inquiry on an individual ICP
o FTP, number of response lines for each of:

 PR-010, PR-020, PR-030, PR-040, PR-060, NP-020, NP-030, NP-040,
RS-010, RS-020, RS-030, RS-040, RW-010, RW-020
6. Number of Trader switches in progress as at the end of the month.
7. Number of switch withdrawal requests made in the month.

8. Number of switch withdrawals where the switch itself had been completed
9. Number of switch withdrawals where the Trader switch itself was in progress.
10. Number of switch withdrawals rejected where the Trader switch itself was completed.
11. Number of switch withdrawals rejected where the Trader switch itself was in progress.
Number of events inserted during the month by event type and how many of these were
historical inserts. An historical event is an event that does not affect an ICP’s current state.
1. Inserted Address
2. Inserted Address Historical
3. Inserted Metering
4. Inserted Metering Historical
5. Inserted Network
6. Inserted Network Historical

7. Inserted Pricing
8. Inserted Pricing Historical
9. Inserted Trader
10. Inserted Trader Historical
11. Inserted Status
12. Inserted Status Historical

Number of event reversals/replacements made in the month by event type and how many of
these were historical.
1. Reversed / Replaced Address
215
Version 22.24
2. Reversed / Replaced Address Historical
3. Reversed / Replaced Metering
4. Reversed / Replaced Metering Historical

5. Reversed / Replaced Network
6. Reversed / Replaced Network Historical
7. Reversed / Replaced Pricing

8. Reversed / Replaced Pricing Historical
9. Reversed / Replaced Trader
10. Reversed / Replaced Trader Historical

11. Reversed / Replaced Status
12. Reversed / Replaced Status Historical
13. ICP's changed - consolidated total of non historical updates (reversals/replacements/inserts)

14. ICP histories changed - consolidated total of historical updates
(reversals/replacements/inserts)
Part 2: ICP’s By Role
The Authority is required to receive four sets of statistics detailing the number of ICP’s active,
inactive and decommissioned at the end of the month and the *number that have been switched
during the month by:
1. Trader Participant Identifier; [file 2]
2. Distributor Participant identifier; [file 3]
3. NSP identifier; and [file 4]

4. Trader participant Identifier and NSP. [file 5]
*Number that have been switched includes non withdrawn switches where the switch Actual
Transfer Date is greater than the start of the month. Switches with an Actual Transfer Date prior to
the start of the month are not included
Data Inputs:
Processing:
216
Version 22.24
Data Outputs:
Monthly statistics to be available, online and downloadable, to all participants. Report contents are
the same for all participants, i.e. irrespective of responsibility.
Authority reports to be automatically delivered at the end of each month in CSV format to
a) the registry FTP server’s fromreg folder for the Authority, and
b) the Authority’s Secure FTP server, for subsequent data warehouse upload.
The Authority reports will include files 1 through 5
The Administrator has the facility to manually resend files to the Authority SFTP server using
Win_SCP.
Files contain the standard Registry file header. Header fields are as follows:
Header record type,File type,Sender,Recipient,File creation date,File creation time (24

hour format),Number of detail recs,User Reference
e.g. HDR,RMSTATR1,RGST,BOPE,27/12/2010,11:10:30,24,
The second heading line contains column headings, which are the field descriptions below.
Statistics Files 1: ICP Totals
File Name File type

MonthlyStatisticsYYYYMM.csv RMSTATR1
Description Type
Record type DET
Month Char
Parameter description Numeric
Value Numeric
Statistics Files 2: ICP Statistics by Trader
File Name File type

RetailerStatsYYYYMMnnnn.csv RMSTATR2
Description Type
Record type DET
Trader Name Char 30
Trader Participant Identifier Char 4
ICP’s Active Numeric
ICP’s Inactive Numeric
ICP’s Decommissioned Numeric
ICP’s Switched Numeric
217
Version 22.24
Statistics Files 3: ICP Statistics by Distributor
File Name File type

DistributorTotalsYYYYMMnnnn.csv RMSTATR3
Description Type
Record type DET
Distributor Name Char 30
Distributor Participant Identifier Char 4
Statistics Files 4: ICP Statistics by NSP Identifier
File Name File type

NSPTotalsYYYYMMnnnn.csv RMSTATR4
Description Type
Record type DET
NSP Char
Statistics Files 5: ICP Statistics by Trader and NSP Identifier
File Name File type

ICPByRetailerNSPYYYYMMnnnn.csv RMSTATR5
Description Type
Record type DET
Trader Name Char 30
Trader Participant Identifier Char 4
NSP Char
218
Version 22.24
Sub-process: PR-080 Produce monthly HHR ICP list
Participants: Reconciliation Manager
Code references: Clause 11.26(d) of the Code.
Dependencies:
Description:
This report is produced automatically for the Reconciliation Manager. It lists, by NSP and Trader,
all those ICPs with Submission Type HHR= ‘Y’ that were active during the relevant consumption
period and the periods for which they were active.
219
Version 22.24
2. The registry must deliver revised information to the Reconciliation Manager, in respect of the
3. Only ICPs with a Submission Type HHR = ‘Y’ must be included in the list.
4. Only ICPs that were status active at some time during the relevant consumption period must be
included in the list. An entry in the list must be for a contiguous period during which the ICP
was active for a single Trader and NSP within a single consumption period (ICP active period).
There may be multiple ICP active periods for a consumption period
5. Each ICP must be regarded as active only for the days when the associated NSP is also active.
Where an ICP is recorded as being active outside its NSP effective date range (as per the NSP
Mapping static data table), the Registry must:
a. adjust the ICPs reported consumption days so that they do not exceed the associated
NSP’s active date range for that consumption period, and
b. exclude the ICP consumption days from the report to the Reconciliation Manager, if an
NSP was not active at all during the consumption period, and
c. report to the Authority, as a Consumption Error (see SD-050), all instances of
consumption outside the NSP effective date range and include the following
information:
i. ICP Identifier
ii. NSP Identifier
iii. Trader Identifier

iv. Consumption period end date.
6. The results of NSP level validation must be reported regardless of whether Consumption Errors
have been detected
7. The report must be able to be resent for a particular month upon request to the Registry
Manager.
Data inputs:
Processing:
220
Version 22.24
The system:
1. For each consumption period and for each Trader, identifies those ICPs with submission type
HHR = Y that had an active status during some part of the consumption period and derives
their start and end dates (ICP active periods). Note that if there are periods for which the ICP
was inactive during the consumption period there will be more than one entry in this report.
2. Calculates the ICP days for each ICP active period (end date – start date + 1).
3. Reduces the ICP days for every day the ICP active period falls outside the associated NSPs
active period, as recorded in the NSP Mapping table. Note that the start date and the end date
of an ICP active period are not affected by any adjustment.
4. If the ICP days are reduced to zero, omits reporting the ICP days information to the
Reconciliation Manager.
5. Sorts the list entries by NSP, Trader, ICP Identifier and start date.
6. Notifies the Authority of the results of the NSP level validation
Data outputs:
HHR ICP list output information for the Reconciliation Manager
Name Format Comment
Month MM/YYYY Consumption period.
NSP Char 11 NSP identifier
Trader Participant Char 4

Identifier
Start date DD/MM/YYYY First day in month that the ICP was the responsibility
of the Trader and was active.
End date DD/MM/YYYY Last day in month that the ICP was the responsibility
of the Trader and was active.
ICP days Numeric Number of days between start date and end date.
Sample email for an ICP Days Consumption Error
221
Version 22.24
Heading:
Consumption error report from Registry: Report - HHR ICP List
Message text:
The following ICPs have been detected with consumption outside their NSP effective date ranges.
ICP <ICP Id> has consumption recorded for Trader <trader id> exceeding the number of days the
NSP <NSP identifier> was active during Month: <consumption month>
Alternate Message text where no Consumption Errors detected:

No ICP’s were detected with consumption outside NSP effective date ranges.
Example 1: PR-080 HHR ICP List report

The following ICPs have been detected with consumption outside their NSP effective date ranges.
ICP 123456789ABC123 has consumption recorded for Trader RETA exceeding the number of days
the NSP NETANETA001 was active during Month: 30/04/2015
Example 2: PR-080 HHR ICP List report

No ICP’s were detected with consumption outside NSP effective date ranges.
222
Version 22.24
Sub-process: PR-090 Produce active NSPs report
Participants: Clearing manager, system operator, Reconciliation Manager
Dependencies:
Description:
This report is produced at the request of the clearing manager, system operator, or Reconciliation
Manager, each of whom may request that the report be provided automatically (ie a frequency over
an indefinite period). The report lists all active NSPs connected to a local network, all active NSPs
connected to a network for which a Trader has been responsible, and the dates on which each
Trader's responsibility under the Code at an NSP commenced and ceased, during the previous 14
months.
1. The report must be produced at the request of the clearing manager, system operator, or
Reconciliation Manager. It has been requested that the report be provided by 1600 hours on
the first business day of every month.
The report must list only those NSPs that are active.
Data inputs:
Processing:
1. Extract the Trader, NSPs and periods (start and end dates) of ICPs that were active during the
previous 14 months.
2. Sort and summarise by Trader, NSP reporting the earliest start date and latest end date of the
active ICPs. Note that it is possible for all ICPs of a Trader to be inactive for a duration then
become active again. The system will therefore show at least two entries in the report for this
type of situation.
223
Version 22.24
Data outputs:
Active NSPs report output information
Name Format Comment
Trader Participant Char 4 All Traders.

Identifier
NSP Char 11 Each NSP Identifier at which Trader was responsible

for an ICP in the active state.
Start date of active DD/MM/YYYY Start date of earliest ICP.

period
End date of active DD/MM/YYYY End date of latest ICP.

period
224
Version 22.24
Sub-process: PR-100 Produce loss factors report
Participants: Reconciliation Manager, Participants, Authority
Code references: Clause 11.26(b) of the Code.
Dependencies:
Description:
This report is produced twice a month automatically for the Reconciliation Manager. It details the
loss factor values for each Distributor Loss Category Code recorded by the registry in respect of all
trading periods during the previous 14 months.
3. The report must show details of all Distributor Loss Category Codes recorded by the registry in
respect of all trading periods during the previous 14 month – i.e. that are still current or were
current during any of those consumption periods.
4. The report must be able to be requested via ftp by any participant.
Data inputs:
filter.
Name Type Mandatory Description/Example

/Optional
Start Date DD/MM/YYYY M
End date DD/MM/YYYY M
Participant Identifier Char 4 M
Current Codes Char 1 O Y to report current codes.
Historical Codes Char 1 O Y to report current codes.
225
Version 22.24
Example
HDR,RQMLOSSFS,RETA,RGST,23/03/2007,15:49:06,00000005,my user reference
PRAM01,01/01/2009
PRAM02,25/11/2011
PRAM03,NETA
PRAM04,Y
PRAM05,N
Processing:
1. From the loss factor table on the registry, identify all Distributor Loss Category ’s except those
with an end date after 14 months before the current consumption period.
Sort by Network Participant Identifier, Distributor Loss Category Code, and start date.
Data outputs:
Loss factors report output information
Name Format Comment
Distributor Char 4 Valid Participant Identifier for Distributor.

Distributor Loss Char 15

Category Code
Consumption loss Numeric 1.4 1.0024

factor
Generation loss Numeric 1.4 1.0024

factor
Start date DD/MM/YYYY
End date DD/MM/YYYY Within preceding 14 months or blank.
Start trading period Numeric 4 For example: 0000
End trading period Numeric 4 For example: 2300
Date and time of DD/MM/YYYY Audit date/time of insert or update.

last change HH:MM:SS
226
Version 22.24
Sub-process: PR-110 Produce maintenance compliance report
Participants: Authority, Distributors, Traders, Reconciliation Manager, Metering

Equipment Providers
Code references: Clause 11.20(2), clauses 8, 9, 22, 23, 28 and 30 of Schedule 11.1 and
clauses 2 and 3 of Schedule 11.4 of the Code.
Dependencies:
Description:
This is an automatic report that is produced every month by 1600 hours on the 1st business day of
each reconciliation period for the market administrator.
It can also be requested by Traders, Distributors, the Reconciliation Manager, Metering Equipment
Providers and the Authority. Traders, Metering Equipment Providers, the Reconciliation Manager
and Distributors can only obtain information pertaining to themselves. The market administrator
can select information for individual or all participants.
Both a summary and detailed reports are automatically produced every month for the market
administrator. These reports summarise and detail the number of events that have not been notified
to the registry within the timeframes specified in Part 11 of the Code. Those events might relate to
ICPs, events, NSPs, Distributor Loss and Price Categories.
1. The report must be produced monthly by 1600 hours on the 1st business day of each
reconciliation period for the market administrator or on request by Traders, Metering Equipment
Providers and Distributors.
2. The report must show the non-compliance instances that have not been notified to the registry
as required by the Code of which the registry is aware. Those events include the following:
For Distributor compliance:
a) (Clause 8(2) of schedule 11.1.) The provision of information by Distributors about:
 Network events (including the creation of an ICP Identifier for an ICP);
 Address event information; or
 Pricing event information; or
 Status event information
Changes to these events must be input no later than 3 business days after the change
takes effect.
* However, NSP identifier changes must be input no later than 8 business days after
the change takes effect.
227
Version 22.24
b) Distributor Loss Category Codes. Changes to loss factors must be entered on the
table in the registry at least 2 calendar months before the loss factor takes effect
(clause 22 of Schedule 11.1);
c) Distributor Price Category Codes. Changes to Distributor Price Category Codes

must be entered on the table in the registry at least 2 calendar months before the code
takes effect (clause 23 of Schedule 11.1);
For Trader compliance:

 Clause 9 of Schedule 11.1. The provision of information by Traders about Trader events and
Status events must be provided no later than 5 business days after the change takes effect.
For Reconciliation Manager compliance:

 Clauses 28 and 30 of Schedule 11.1. Reconciliation Manager maintenance of NSP
information. A new NSP identifier must be allocated at least 1 business day of the
Reconciliation Manager receiving notice of the creation of the NSP. The creation or
decommissioning of an NSP must be notified to the registry within 1 business day after the
Reconciliation Manager receives notice of the creation or decommissioning.
For Metering Equipment Provider Compliance
 Clause 3 of Schedule 11.4. A change to metering event information (not the initial
population) must be made no later than 10 business days after the change comes into effect
(MTR).
 Clause 2 of Schedule 11.4. The first population metering event information by a new MEP
must be made no later than 15 business days after the change comes into effect (MT1).
3. All inserts, updates and reversals are to be reported.
4. Information provided to the registry after 1930 hours is deemed to be provided at 0730 the next
day (clause 11.20(2) of the Code).
Data inputs:
Each parameter line is preceded by a line type identifier consisting of “PRAMnn”

where nn refers to the parameter number.
filter.
Each attribute on an input line is comma separated
Parameter Name Type Mandatory/ Description/Example

Optional
Month and year of MMYYYY M
breaches
PRAM01
228
Version 22.24

Optional
Breach Type Char 32 M List event types to be reported, one or more
PRAM02 as below space separated:
 NET – Distributor maintenance

(including ICP creation)
 NSP – ICP NSP change
 PRI – Distributor pricing
 ADD – Distributor Address
 REC – Trader change
 MTR –Metering change (not first)
 MT1 –Metering change (first)
 STAT –Distributor Status change
 TRADERSTATUS – Trader status
change
 LFT – Loss factor table
 PCT – Price Category Table
 NSPT – NSP table
Detail or Summary Char 1 M S or D
PRAM03
Participant Char 4 M Defaults to report requester. Authority may
PRAM04 request for any participant
Example request:
HDR,RQMMAINTCP,CTCT,RGST,27/12/2001,11:13:12,2,list data
PRAM01,032010
PRAM02,NET ADD
PRAM03,S
PRAM04,RETA
Processing:
1. Extract all relevant information (eg event maintenance, Distributor Loss Category maintenance,
Distributor Pricing Category maintenance and NSP mapping table information) entered on the
registry during the previous month.
Detail report is sorted by participant, maintenance type, input date sequence.
Summary report is sorted by participant and maintenance type.
Note the days overdue calculation is performed to a maximum of 100 days. Larger durations are
represented (internally to the Registry only) by the value 99999 business days.
Data outputs:
229
Version 22.24

Maintenance compliance report output information – detail
Name Format Comment
Maintenance type Char 3 <For event maintenance the event type

description>, loss factor, price category
code, NSP mapping table.
Input date DD/MM/YYYY
Effective date DD/MM/YYYY Event Date or start date or end date.
ICP Identifier Char 15 Only for event maintenance.
The following depends on the maintenance type value:
Name Comment
For Network event maintenance (NSP and NET):
(If only NSP Identifier is changed then NSP, or
else NET. If NSP and NET then 2 rows
generated.)
Network Participant Identifier Valid Participant Identifier for Distributor.
POC
Reconciliation Type
Dedicated NSP
Installation Type
Proposed Trader Participant Identifier
Unmetered Load Details – Distributor
Shared ICP List Space separated ICP numbers
Generation Capacity
Fuel Type
Initial Electrically Connected Date
Direct Billed Status
Direct Billed Details
Network User Reference
For network Pricing event maintenance: (PRI)
Distributor Price Category Code

Distributor Loss Category Code
Chargeable Capacity
230
Version 22.24
Name Comment
Distributor Installation Details
Network pricing User Reference
For Address event maintenance: (ADD)
Physical Address Unit

Physical Address Number/ RAPID number
Physical Address Region
Physical Address Street
Physical Address Suburb
Physical Address Town
Physical Address Post Code
Address Property Name
GPS Easting
GPS Northing
Address User Reference
For loss factor table maintenance: (LFT)

Distributor Loss Category Code
Loss factor consumption
Loss factor generation
Start date
End date
Start period
End period
For pricing category table maintenance: (PCT)

Distributor Price Category Code
Effective start date
Effective end date
Price category description
For NSP mapping table maintenance: (NSPT)
Owner
POC
Registry network
231
Version 22.24
Name Comment
Registry NSP description
Parent POC
Parent network
Balancing area
Network type
Network connection status
Start date
Start trading period
End date
End trading period
ICP# of EN NSP
For Trader event maintenance: (REC)
Trader
Profile
Proposed MEP
UNM Flag
Daily Unmetered kWh
Unmetered Load Details – Trader
Submission Type HHR
Submission Type NHH
ANZSIC
Trader User Reference
For Metering event maintenance: (MTR and
MT1)
MEP Participant Identifier
HHR Flag
NHH Flag
PP Flag
AMI Flag
Meter Channel Count
232
Version 22.24
Name Comment
For Status event maintenance: (STAT and
TRADERSTATUS) (Distributor and Trader
respectively)
ICP Status
ICP Status Reason code
Status User Reference
233
Version 22.24
Maintenance compliance report output information – summary

Field Format Comment
Month MM/YYYY 03/2010
Maintenance type Char 3 <For event maintenance the event type
description>, loss factor, price category,
NSP mapping table.
Number of non- Numeric 6 999999
compliant events
234
Version 22.24
Sub-process: PR-120 Produce NSP mapping table report
Participants: Reconciliation Manager, participants
Code references: Clause 11.26(c) of the Code.
Dependencies:
Description:
This report is produced automatically for the Reconciliation Manager but is produced for all
participants ‘on demand’. It details the entries in the NSP mapping table that were applicable
during previous consumption periods – ie the balancing area to which each NSP belongs recorded
by the registry in respect of all trading periods.
3. The registry must allow all registry participants to view the NSP mapping table online and to
download it.
4. The information must be able to be requested via ftp by any participant.
5. Entries in the report must have the following information:

 identifier – Char 4 (Distributor Participant Identifier);
 registry POC – Char 7;
 registry Network Participant Identifier – Char 4;

 registry NSP description – Char 32;
 parent POC – Char 7;
 parent Network Participant Identifier – Char 4;

 balancing area – Char 12;
 network type – Char 1 (G = grid connected, E = embedded or I = interconnection point);
 network connection status – Char 1 (active = Y or inactive = N);

 start date – date (DD/MM/YYYY);
 start trading period – Char 2;
 end date – date (DD/MM/YYYY or blank);

 end trading period – Char 2;
235
Version 22.24
 ICP Identifier of SB ICP – Char 15;

 audit input date/time;
 input by (user name);
 audit deletion date/time; and

 deleted by (user name).
Data inputs:
A report may be requested by submitting a file with a header only

Example request:
HDR,RQMNSPMAP,RETA,RGST,27/12/2016,11:13:12,0,
Processing:
1. From the NSP mapping table, select all entries except those with an end date prior to 14
months previous.
Sort by registry POC, registry Network Participant Identifier, start date, and start trading period.
Data outputs:
NSP mapping table report output information
Name Format Comment
Identifier Char 4 Distributor Participant identifier
Registry POC
Registry Network
Registry NSP
description
Parent POC
Parent network
Balancing area
Network type
Network connection
status
Start date DD/MM/YYYY
236
Version 22.24
Name Format Comment
Start trading period Numeric
End date DD/MM/YYYY
End trading period Numeric
ICP Identifier of EN Char 15

NSP
Audit input DD/MM/YYYY

date/time HH:MM:SS
Input by (user Char 10

name)
Audit deletion DD/MM/YYYY

date/time HH:MM:SS
Deleted by (user Char 10

name)
237
Version 22.24
Sub-process: PR-130 Produce monthly activity and status summary report
Code references:
Dependencies:
Description:
This report is produced automatically for the Authority and provides statistics for each of the
previous 3 months. It is a combination of monthly activity and status as at the end of each month.
1. The report should be delivered to the Authority by 1600 hours on the 6th business day of each
month covering the previous 3 months.
Data inputs:
Processing:
Data outputs:
Authority reports to be automatically delivered at the end of each month in CSV format to:
b) the Authority’s secure FTP server, for subsequent data warehouse upload.
Win_SCP.

Monthly activity and status summary report output information
Name Format Comment
Month MMYYYY
POC Char 7
Network Participant Identifier Char 4 Valid Participant Identifier for Distributor.
Trader Char 4 Trader Participant Identifier
238
Version 22.24
Name Format Comment
Number of ICPs Numeric As at end of month
ICPs created Numeric In month
Status new (999) Numeric As at end of month
Status ready (000) Numeric As at end of month
Status active (001) Numeric As at end of month
Status inactive (002) Numeric As at end of month
Status decommissioned (003) Numeric As at end of month
Status distributor (888) Numeric As at end of month
Metering type HHR Numeric As at end of month
Metering type NHH Numeric As at end of month
UNM Flag Numeric As at end of month
Metering type PP As at end of month
Advanced Metering Numeric As at end of month

Infrastructure
Submission Type HHR Numeric As at end of month
Submission Type NHH Numeric As at end of month
Meter installation category 1 Numeric As at end of month

active

active

active

active

active

inactive

inactive

inactive

inactive
239
Version 22.24
Name Format Comment

inactive

decommissioned

decommissioned

decommissioned

decommissioned

decommissioned
ICP enquiries Numeric In month
ICPs changed Numeric In month
CS switches Numeric In month
Switch withdrawals Numeric In month
Price category changes Numeric In month
Loss category changes Numeric In month
No meter setting Numeric ICPs with all metering types = N as at end of month
No metering event ICPs in month with no metering event data e.g. new
ICPs and solely UML ICPs.
240
Version 22.24
Sub-process: PR-140 Produce monthly switch completion report
Code references:
Dependencies:
Description:
This report is produced automatically for the Authority and provides switch completion statistics for
each of the previous 3 months.
1. The report must be delivered to the Authority by 1600 hours on the 3rd business day of each
month covering the previous 3 months
2. The report counts the number of business days taken between NT arrival and the TN/CS /TT.
These numbers are expressed as average business days to two decimal points per calendar
month by participant and meter type (HHR and NHH).
3. The switch counts appear against the Trader who has responsibility for completing the switch.
 NHH switch will appear against the losing Trader who has responsibility for supplying the
TN/CS and for switch types of MI and TR.
 HHR switch will appear against the gaining Trader who has responsibility for supplying the
TT/CS and for the switch type of HH.
4. The count refers to the calendar month in which the NT was initiated; for example, an NT
initiated in January that completes in February appears in January’s figures.
5. For the purposes of the business days calculation, if notification of a switch event arrives on a
public holiday it is assumed to have arrived the next business day.
6. Number of days will be based on date of receipt of the switch event, ie a switch event
notification received after 19:30 will be deemed to have arrived today not tomorrow.
7. The report includes maximum and minimum business days recorded to complete a switch per
participant per month, the maximum and minimum are across both HHR and NHH switches.
8. The total NHH switches performed by a participant will be printed and also expressed as a
percentage of the total NHH switches performed in the month to 2 decimal points. HHR
switches will be accumulated and expressed in the same manner.
9. A weighted average business days until completion will be calculated separately for each
month against NHH, HHR and across all switches. The weighted average figures will be
detailed in a separate line at the end of each month.
10. The type S/TR and SM/MI non half hour switches will be reported separately and in addition to
the aggregated NHH figures. Type S/TR and SM/MI switches will each include figures for
241
Version 22.24
minimum, maximum and average business days. Type S/TR and SM/MI switches will each be
reported with a weighted average at the end of each month.
11. Any switch that has been withdrawn is excluded from the counts.
12. The report data will be comma separated.
13. The Authority reports to be automatically delivered at the end of each month in CSV format to:
 the registry FTP server’s fromreg folder for the Authority, and
 the Authority’s secure FTP server, for subsequent data warehouse upload.
Data inputs:
Processing:
Data outputs:
Monthly activity and status summary report output information
Name Format Comment
Month MMM-99 e.g. Jan-08
S or TR minimum Numeric Minimum days taken to complete a type S

or TR NHH switch
S or TR maximum Numeric Minimum days taken to complete a type S

or TR NHH switch
SM or MI minimum Numeric Maximum days taken to complete a type

SM or MI NHH switch
SM or MI maximum Numeric Maximum days taken to complete a type

SM or MI NHH switch
Avg Bus Days S or TR Numeric 3.2 Average business days taken to complete a
type S or TR NHH switch
Avg Bus Days SM or MI Numeric 3.2 Average business days taken to complete a
type SM or MI NHH switch
Avg Bus Days NHH Numeric 3.2 Average business days taken to complete a
NHH switch
242
Version 22.24
Name Format Comment
Avg Bus Days HHR Numeric 3.2 Average business days taken to complete a
HHR switch
Maximum Numeric Maximum days taken to complete a switch
Minimum Numeric Minimum days taken to complete a switch
NHH Numeric Number of NHH switches performed by the

participant and percentage that represents
of all NHH for all participants in the month
HHR Numeric Number of HHR switches performed by the

participant and percentage that represents
of all HHR for all participants in the month
Total Numeric Number of switches (NHH and HHR)

performed by the participant and
percentage that represents of all switches
for all participants in the month
Weighted averages Numeric 3.2 Weighted averages for each month for:
 Type S/TR NHH switches

 Type SM/MI NHH switches
 NHH
 HHR
 Total switches
243
Version 22.24
Sub-process: PR-145 Produce daily switch report - Discontinued
Code references:
Criticality: Non Core
Description:
No longer required.
1. Refer to PR-140 Monthly Switch Completion report for a full description of business
requirements and output format. PR-145 differs in the following manner:
2. The report must be delivered to the Authority by 0900 hours each day covering the previous
day.
3. A switch withdrawal (AW) is included in the count.
4. A switch that is started, completed and withdrawn on the same day is not included.
Data inputs:
Processing:
Data outputs:
Daily activity and status summary report output information.
The fields are as specified for PR-140 Monthly Switch Completion report, except those below.
Name Comment
Day (replaces Month) Format dd/mm/yyyy
NHH S or TR opened Number of S or TR switches opened of

NHH meter types
NHH SM or MI opened Number of SM or MI switches opened of

NHH meter types
HHR opened Number of HHR switches opened
244
Version 22.24
Sub-process: PR-160 Produce Automated Trade Notification
Participants: Reconciliation Manager, System Operator
Code references: Clauses 11.25 and 11.26 of the Code
Dependencies:
Description:
The registry will provide to the Reconciliation Manager a file containing a Traders start date of
trading at an NSP and the end date of trading at an NSP. The data covers the preceding 14
months, summarised by Installation criteria.
1. The Trade Notifications file must be delivered to the Reconciliation Manager by 9am
each day.
2. The Reconciliation Manager and System Operator may also request the report on
demand.
3. The report details the date that a Trader started trading on an NSP and the date a
Trader ended trading on an NSP for each unique occurrence of Installation criteria:
 NSP
 Installation Type
 Reconciliation Type
 Profile
4. Only ICP’s that have the Status active are considered to be trading.
Data inputs:
The report may be requested by the Reconciliation Manager or System Operator at any time either
on-line or by FTP. A FTP request requires a header record in the following format:
Name Type Mandatory/ Description/Example

Optional
Header Char 3 M Must be “HDR”
Request name Char 10 M Must be “RQATRADE”
Sender Char 4 M Participant identifier for example NZRM
Recipient Char 4 M Must be “RGST”
Date DD/MM/YYYY M Valid date
Time HH:MM:SS M Valid time
Number of records Numeric M Must be 0
User Reference Char 32 O Free format User Reference. This is carried
through and placed on the output file.
Example
HDR,RQATRADE,NZRM,RGST,03/08/2010,14:27:05,0,AdHoc trade report request
245
Version 22.24
Processing:
1. Report all periods where a Trader traded on an NSP

2. Sort the output by NSP then Trader
Data outputs:
The output report will contain a standard header followed by the trading information.
The output file name will have the following format:
 RSMATRADE< yyyyMMddHHMMSS>.txt
Name Format Comment
Point of connection Char 7
Network Char 4 Valid Participant Identifier for Distributor.
Participant identifier Char 4
Profile code Char 3 Profile that was active on the NSP
Installation Type Char 1 L - Load

G - Generation
B - Both
Start date DD/MM/YYYY Date Trader started trading on the NSP
End date DD/MM/YYYY Date Trader end trading on the NSP. If the
Trader is still trading then the end date is
null
Output example:
HDR,RSMATRADE,RGST,NZRM,04/08/2010,00:05:00, 3984,REGISTRY
ABY0111,NETA,GN,RETA,PG1,L,01/05/2010,
ABY0111,NETA,GN,RETA,EG1,L,01/05/2010,
ABY0111,NETA,GN,RETA,HHR,L,01/05/2010,
ABY0111,NETA,GN,RETA,T08,L,01/05/2010,27/07/2010
ABY0111,NETA,GN,RETA,T08,L,14/08/2010,
246
Version 22.24
Sub-process: PR-170 Produce Monthly report
Code references:
Dependencies:
Description:
This report is produced automatically for the Authority each month and provides a count of the
number of ICP’s a participant is responsible for in Active or Ready state.
1. The report must be delivered to the Authority by 06:00 hours on the 1st day of each month.
2. An ICP is included where it is in a Ready or Active state.
3. Number of ICP’s a distributor or Trader are responsible for are counted against that participant.
Data inputs:
Processing:
1. Read all ICP’s.

2. Ignore ICP where Status is other than Ready or Active.
3. Accumulate counts against the current Distributor and Trader who are responsible for the ICP.
4. Write counts to output file.
5. Transfer the output file to the Authority by email.
Data outputs:
The Authority report to be automatically delivered at the end of each month, report name:
 ICPsOwned<month name><year>.csv, for example ICPsOwnedFebruary2011.
Name Comment
Industry Code and Name Participant identifier and description
Active Number of ICP’s owned in Active state
Ready Number of ICP’s owned in Ready state
Trader Whether Participant is a Trader
Network Whether Participant is a Distributor
247
Version 22.24
Sub-process: PR-180 Produce ICP Switching Trend Report
Code references:
Dependencies:
Description:
The report provides the following information:

1. ICPs that have switched Trader
2. ICP’s whose Status changes from Ready to Active or Inactive
3. ICP’s whose Status changes from Decommissioned to Inactive
4. ICP’s whose Status changes from Inactive to Decommissioned
5. ICP’s whose current Address has changed
This information is provided to the Authority by 1600 hours on the 6th business day of each month
for the previous month.
The report provides information to the Authority’s data warehouse for analysis of switch trend
information.
The terminology used in the following functional description has been selected to maintain
consistency with common registry usage.
Base Data extract

Extract ICP data as at an input effective date. A Base extract will contain records of the following
Action type (see Action field description below).
1. BASE; consists of
 ICP’s with Status Active or Inactive as at the input report start date
Delta Data extract

Extract net deltas for ICP’s between an effective date range. The delta is identified as one of the
following:
1. SWITCH; consists of
 ICPs that have switched.
 ICP’s who have had a completed switch withdrawn.
2. START TRADING; consists of

 ICPs that have moved from a non Trading state (New, Ready or Decommissioned) to a
Trading state (Active or Inactive).
248
Version 22.24
3. STOP TRADING; consists of

 ICP’s moved from Inactive to Decommissioned
 ICP’s moved from Inactive or Active to Ready (initial Trader assignment reversal)
4. ADDRESS; consists of
 ICPs that have had an Address change to their current Address.
Notes
1. The Delta Data contains the net changes across the input date range. If there is no net change
the ICP is not reported.
For example these are not reported:
a) an ICP that became ACTIVE then returned to READY during the period
b) an ICP with a switch notification that was subsequently withdrawn during the period.
2. Where multiple deltas occur of the same action type over the same reporting period only the
latest delta is reported, and is identified by the most recent event Effective Date.
3. The BASE report contains records with action type of BASE only, to provide an indication of the
report type. This record is otherwise identical to action type ADDRESS.
Data inputs:
1. Base or Delta report

2. Report start date
3. Report end date (delta report only).
Processing:
Base Report
1. Read all ICP records at the report date that have an active or inactive Status.
2. Generate output statistic file with BASE action records
3. Transfer the output file to the Authority FTP fromreg folder
Delta Report
1. Read the event audit records that have been updated in the registry in the consumption month
2. Generate output statistic file
3. Transfer the output file to the Authority SFTP fromreg folder
249
Version 22.24
Data outputs:
Authority report to be automatically delivered at the end of each month in CSV format to
b) the Authority’s secure FTP server, for subsequent data warehouse upload.
Win_SCP.
Files contain the standard registry file header. Header fields are as follows:
 Header record type,File type,Sender,Recipient,File creation date,File creation time (24 hour
format),Number of detail recs,User Reference
e.g. HDR,RSPR180STA,RGST,EMCO,15/02/2011,11:10:30,24,
Report sort order will be
 ICP Identifier
 Effective Date
ICP Identifier Char 15 ICP Identifier.
Effective Date Date The date the change became effective.

DD/MM/CCYY
Creation Date Date The date the delta was updated to the Registry
DD/MM/CCYY Null for Base Report
Action Char 18 One of:

 BASE
 SWITCH
 START TRADING
 STOP TRADING
 ADDRESS
(Note the format for records with action of BASE and
ADDRESS are identical)
Losing Trader Char 4 Populated where Action is SWITCH, otherwise blank.

This contains the Trader who has lost the ICP
Gaining Trader Char 4 If Action is SWITCH

 Trader who has gained the ICP
If Action is BASE or START TRADING,
 Trader who assigned an ICP to themselves or
 Trader who owns the ICP after reversal of a
decommission event.
Otherwise blank
250
Version 22.24
Withdrawal Reason Char 2 Populated if action is SWITCH.

The Switch Withdrawal Code
Status Char 14 ICP Status as at the Effective Date, one of:

 Inactive
 Active
 Decommissioned
Distributor Char 4 Distributor at the Effective Date
NSP Char 11 NSP identifier as at the Effective Date
Meter Category Numeric Meter Category as at Effective Date
Address Details The Address details apply as at the Effective Date,

Address details are populated if action is BASE,
ADDRESS or START TRADING.
Physical Address Unit Char 20 Physical Address Unit
Physical Address Char 25 Physical Address Number/Rapid Number

Number/Rapid Number
Physical Address Street Char 30 Physical Address Street
Physical Address Char 30 Physical Address Suburb

Suburb
Physical Address Town Char 30 Physical Address Town
Physical Address Char 20 Physical Address Region

Region
Physical Address Post Numeric Physical Address Post Code

Code
251
Version 22.24
Sub-process: PR-190 Produce EIEP Statistics
Process: Produce Reports
Rule references: None
Dependencies: EI-010, EI-020, EI-030
Criticality Non-core
Description:
Monthly statistics representing the number and volumes of files sent and received by the EIEP
transfer hub.
1. The report is delivered to the Authority by 06:00 hours on the 1st day of each month
2. The Authority will receive a file detailing EIEP Transfer statistics by Participant, as described in
Data Outputs.
3. The report will be automatically delivered at the end of each month in CSV format to
a) the Registry FTP server’s fromreg folder for the Authority, and
b) the Authority’s Secure FTP server, for subsequent data warehouse upload.
4. The Administrator has the facility to manually resend files to the Authority SFTP server using
Win_SCP.
Data inputs:
None
Processing:
Accumulate statistics through examination of the EIEP transfer audits for the report month.
252
Version 22.24
Data outputs:
Files contain the standard Registry file header. Header fields are as follows:
Header record type, File type, Sender, Recipient, File creation date, File creation time (24 hour
format), Number of detail records, User reference
Description Type Value
Report Month MMYYYY
Participant Code Char 4
Total Files sent Numeric
Volume files sent Numeric Total volume in bytes
Total Files received Numeric
Volume files received Numeric Total volume in bytes
Total Files rejected Numeric
File example:
HDR,RMSTATEIEP,RGST,EMCO,01/08/2011,00:10:30,5,
072011,CTCT,266,36578923,199,887691,0
072011,GEOL,212,59886311,190,999499,4
072011,MERI,119,67779,61,1880,1
253
Version 22.24
Sub-process: PR-210 Missing Metering Data
Participants: Authority, MEP
Code references:
Dependencies:
Description:
This report is used to identify where a MEP has sent an MN notification but has not populated the
Metering data.
1. The report may be run by a MEP or the Authority

2. The report will include ICP’s which are MEP Switch In Progress where a MEP has sent either
 an MN notification rejecting responsibility, or
 an MN notification accepting responsibility but has not populated the metering data.
3. The report may be run on demand by MEP’s and the Authority.
4. Report output is as at the run date of the report
5. If run by a MEP the report will return ICP’s where the MEP is the last notified MEP.
6. If run by the Authority the report will return ICP’s for the requested MEP, or ICP’s for all MEP’s
as per data inputs.
7. File output name will be “PR210_MissingMetering_<timestamp>.csv” where timestamp is
format “yyyymmddhhmmss” and specifies the report run time.
8. The file is sorted by gaining MEP.
Monthly reporting
The report is run automatically on the 2nd day of each month and delivered to the Authority’s SFTP
fromreg folder. The target delivery time is 6am.
The automated report will return ICP’s for all MEP’s.
254
Version 22.24
Data inputs:
filter.

Optional
PRAM01 Char 4 M/O Defaults to report requester.
Authority may request for any MEP Identifier.
Authority may report all MEP’s by leaving the
parameter blank
Example request:
HDR,RQMISSMETR,EMCO,RGST,27/11/2013,11:13:12,1,list data
PRAM01,META
Processing:
Validate input parameters.

Generate output file.
Transfer output file to Participant FTP fromreg folder
Trader Char 4 Participant identifier of trader currently responsible

for the ICP
Loosing MEP Char 4 Participant identifier of the MEP who will lose
responsibility.
Gaining MEP Char 4 Participant identifier of the last notified MEP
Submission Date DD/MM/YYYY Input date the MN notification of acceptance was

submitted by the Gaining MEP.
MN Responsibility Indicator Char 1
255
Version 22.24
Examples:
HDR,RSMISSMETR,RGST,EMCO,27/11/2013,11:13:12,7,list data
DET,1234567890AB123,RETA,METB,META,27/10/2013,A
DET,2345678901CD234,RETA,METB,META,27/10/2013,R
DET,3456789012EF345,RETA,METB,META,28/10/2013,A
DET,4567890123GH456,RETB,METB,META,28/10/2013,A
DET,5678901234IJ567,RETC,META,METB,30/10/2013,A
DET,6789012345KL678,RETC,META,METB,30/10/2013,A
DET,7890123456MN789,RETD,META,METB,30/10/2013,R
256
Version 22.24
Sub-process: PR-220 Uncertified Metering Installations
Code references:
Dependencies:
Description:
This report will report ICP’s where the latest metering event contains Uncertified Metering
Installations.
1. The report will include status Active ICP’s where the ICP’s latest Metering event contains the
following:
a. There is any interim certification in the metering records; or
b. There is full certification for any Metering Installation where the Metering Installation
Certification Date has expired; or
c. There is full certification for any Metering Installation and where the Metering Installation
Certification Variations Expiry Date has expired.
2. The report is run automatically on the 7th, 14th and 21st day of each month and delivered to the
Authority’s SFTP fromreg folder. The target delivery time is 6am.
3. File output name will be “PR220_UncertifiedMetering_<timestamp>.csv” where timestamp is
4. The file is sorted by ICP identifier.
257
Version 22.24
Data inputs:
Processing:
Generate output file.

Transfer output file to Participant FTP fromreg folder
Trader Char 4 Participant identifier of trader currently responsible

for the ICP
MEP Char 4 Participant identifier of MEP currently responsible

for the ICP
Metering Event Date DD/MM/YYYY Event date on the latest Metering event.
Metering Installation (repeating)
Record Type Char 2 “MI”
Metering Installation Numeric 3

Number

Category
Metering Installation Char 1

Certification Type
Metering Installation DD/MM/CCYY

Metering Certification Char 1

Variations
Metering Certification DD/MM/CCYY

Variations Expiry Date
Discrepancy Type Char 32 One of:

 Interim
 Certification Expired
 Certification Variations Expired
258
Version 22.24
Examples:
HDR,RSUNCERMTR,RGST,EMCO,27/10/2013,11:13:12,6,Uncertified Meter Insts – day
<n>
DET,1234567890AB123,RETA,META,27/09/2013
MI,1234567890AB123,674,NHH,1,F,12/10/2013,X,12/10/2013,Certification Expired
MI,1234567890AB123,675,NHH,1,F,31/01/2025,12/10/2013,Certification Variations
Expired
DET,1234567777CD666,RETA,META,18/04/2009
MI,1234567777CD666,888,NHH,1,I,12/10/2013,X,12/10/2013,Interim
MI,1234567777CD666,999,HHR,1,F,12/10/2013,X,12/10/2013,Certification Expired
259
Version 22.24
Sub-process: PR-230 Electrical Connection Misalignment
Code references:
Dependencies:
Description:
This report is used to identify ICP’s where the latest ICP Initial Electrically Connected date does not
align (match) with either:
 the Event Date of the first Status event with a status of Active (or Inactive if no Active
event), or
 the Event Date of the first Metering Event.
The report will also identify ICPs where either:
 the ICP Initial Electrically Connected Date is present on an ICP with a current Status of
New or Ready, or
where the Initial Electrically Connected date is missing.
1. The report must exclude ICP’s where the ICP was created before 29/8/2013 or the ICP’s
current Status is decommissioned.
2. ICP’s must be reported if any of the following criteria are met:
 the Initial Electrically Connected Date on the latest Network event containing an Initial
Electrically Connected Date doesn’t match the Event Date of the first Status Event with a
Status of Active (or Inactive if no Active Status event is found); or
 the Event Date of the first Metering event is after either the latest Initial Electrically
Connected Date or the first Active or Inactive status date; or
 the ICP’s current status is one of New or Ready, and an Initial Electrically Connected Date
exists on the latest Network Event, or
 the ICP currently has an Inactive/Active status and the Initial Electrically Connected date on
the latest Network Event is missing as at the latest Inactive/Active event date.
3. If an ICP has a current status of Active or Inactive it must only be reported where 15 business
days have elapsed between the Initial Electrically Connected Date, or, if null, the Event Date of
the first Status Event with a Status of Active (or Inactive if no Active Event found), and the run
date of the report. An ICP with a current status of New or Ready and an Initial Electrically
Connected Date must always be reported.
260
Version 22.24
4. The report must be run automatically on the 4th day of each month and delivered to the
Authority’s SFTP fromreg folder. The target delivery time is 6am.
Data inputs:
ICPs created on or after 29/8/2013.
Processing:
System:
1. Selects ICPs created on or after 29/8/2013 where the ICP’s current Status is not
decommissioned.
2. Identifies electrically connected misalignments.
3. Generates the output file.
Transfers the output file to Authority’s SFTP fromreg folder
Data outputs:
File output name will be “PR230_ElectricalConnectionAlign_<timestamp>.csv” where timestamp is

The file will be sorted by ICP identifier within the Distributor who input the first Initial Electrically
Connected Date (or the first Distributor if no Initial Electrically Connected Date exists).
Distributor Char 4 Participant identifier of the current Distributor of the

ICP
Proposed Trader Char 4 Participant identifier of First Proposed Trader of the

ICP. Null if missing
Accepting Trader Char 4 Participant identifier of Trader who provided the first
Status Event with a Status of Active (or Inactive if
no Active event found). Null if missing.
MEP Char 4 Participant identifier of of the MEP who provided

the first Metering Event. Null if missing.
Initial Electrically DD/MM/YYYY Initial Electrically Connected Date on the most

Connected Date recent Network event. If the Initial Electrically
Connected Date is missing, then “Missing”
First Active Status Event DD/MM/YYYY Date ICP first moved to Status Active or Inactive,
Date else null.
First Metering Event Date DD/MM/YYYY Event Date of first Metering event, otherwise if
status New or Ready then null, else “Missing”.
261
Version 22.24
Current New or Ready DD/MM/YYYY Event date of the current Status if the ICPs current
Event Date status is New or Ready, otherwise null.
Examples:
HDR,RS230NRG,RGST,EMCO,02/11/2013,11:13:12,5, Energisation Misalignment
DET,1234567890AB123,NETA,RETA,RETA,META,Missing,27/04/2003,26/08/2013,
DET,2345678901CD234,NETA,RETA,RETA,META,14/04/2009,27/04/2003,26/08/2013,
DET,3456789012EF345,NETB,RETB,RETB,META,21/08/2013,26/08/2013,Missing,
DET,4567890123GH456,NETC,RETA,RETA,META,12/12/2012,27/04/2003,Missing,
DET,4567890123GH456,NETC,RETA,RETA,META,24/04/2003,,,25/04/2003
262
Version 22.24
Sub-process: PR-240 Profiles Misalignment
Code references:
Dependencies:
Description:
This report is used to identify ICP’s where the Profiles Codes on the latest Trader Event do not
align with either the latest Metering, or with the Trader Submission Type.
1. The report will include ICP’s where the current ICP status is Active
2. ICP’s will be reported where
a. The latest Metering Event contains at least one Metering Component Type of “L”, and the
Control Device Certification Flag is “N”, and the Profile list on the latest Trader Event
contains other than RPS, HHR, PV1, EG1 and UML; or
b. the Profile list on the latest Trader Event includes HHR, and there is no Metering Event or
the Latest Metering Event does not contain a Metering Component Type of M; or
c. the Profile list on the latest Trader Event includes HHR and the Submission Type HHR on
the latest Trader Event is N
3. The report is run automatically on the 3rd day of each month and delivered to the Authority’s
SFTP fromreg folder. The target delivery time is 6am.
4. Three output files will be produced (see data outputs). File output names will be
 “PR240_UncertifiedControlDevice_<timestamp>.csv”
 “PR240_NoMeterForHHR_<timestamp>.csv”
 “PR240_SubmissionHHRMismatch_<timestamp>.csv”
where timestamp is format “yyyymmddhhmmss” and specifies the report run time.
5. Each file is sorted by ICP identifier
263
Version 22.24
Data inputs:
Processing:
Identify Profile misalignments.

Generate output files.
Transfer output file to Authority SFTP fromreg folder.
Data outputs:
File: PR240_UncertifiedControlDevice
Latest Metering Event Date DD/MM/YYYY Event Date of the currently in force Metering Event
MEP Char 4 Participant identifier of the MEP
Trader Char 4 Participant identifier of the current Trader who has

responsibity for the ICP
Latest Trader Event Date DD/MM/YYYY Event Date of the currently in force Trader Event
Profiles Char Space separated Profile codes from the currently in

force Trader Event
For each load control device
Record Type Char 2 LC

Number
Metering Installation Type Char 3
Metering Installation Char 1

Certification Type
Metering Installation DD/MM/YYYY

Control Device Certification Char 1

Flag
264
Version 22.24
Example:
HDR,RSUNCERTDV,RGST,EMCO,27/11/2013,05:05:17,7,Automatic from Registry
DET,1234567890AB123,24/08/2013,META,RETA,13/01/2012,VV1 RPS
LC,1234567890AB123,123,NHH,F,25/10/2015,Y
LC,1234567890AB123,124,NHH,F,25/10/2015,Y
LC,1234567890AB123,125,HHR,F,25/10/2015,Y
DET,9876543210DE345,24/08/2013,META,RETA,13/01/2012,VV1 RPS
LC,9876543210DE345,455,NHH,F,25/10/2015,Y
LC,9876543210DE345,456,NHH,F,25/10/2015,Y
File: PR240_NoMeterForHHR
Latest Metering Event Date DD/MM/YYYY Event Date of the currently in force Metering Event,
or “Missing”
MEP Char 4 Participant identifier of MEP, or “Missing”
Trader Char 4
Participant identifier of the current Trader who has

force Trader Event
Example:
HDR,RSNOMTRHHR,RGST,EMCO,27/11/2013,05:05:17,2,Automatic from Registry
DET,1234567890AB123,24/08/2013,META,RETA,13/01/2012,HHR RPS
DET,9876543210DE345,24/01/2011,Missing,RETA,13/01/2012,HHR
File: PR240_SubmissionHHRMismatch
Trader Char 4
Participant identifier of the current Trader who has
Submission Type HHR Char 1 Submission Type HHR from the currently in force
Trader Event
Submission Type NHH Char 1 Submission Type NHH from the currently in force
Trader Event

force Trader Event
265
Version 22.24
Example:
HDR,RSHHRMISMA,RGST,EMCO,27/11/2013,05:05:17,2,Automatic from Registry
DET,1234567890AB123,RETA,24/08/2013,N,N,HHR RPS
DET,9876543210DE345,RETB,24/01/2011,Y,Y,RPS
266
Version 22.24
Sub-process: PR-250 Trader Default General Information
Code references: Schedule 11.5 of the Code
Dependencies:
Description:
This report is used to identify general information for ICP’s under the responsibility of a Trader who
is in a Trader Default situation. The Report will also identify ICP’s for which the Defaulting Trader
may gain or lose responsibility due to in-progress Trader Switch/Switch Withdrawal activity.
1. The report is available ad-hoc

2. ICP’s will be reported where:
a. The Trader in Trader Default has responsibility for the ICP; or
b. An ICP is in the process of a Trader Switch or Switch Withdrawal where the successful
completion of the switch/withdrawal will result in the defaulting Trader gaining responsibility
for the ICP; or
c. An ICP is in the process of a Trader Switch or Switch Withdrawal where the successful
completion of the switch will result in the defaulting Trader losing responsibility for the ICP
(a switch away)
3. The report will include active, inactive and decommissioned ICP’s
4. A csv output file will be produced (see data outputs) refer appendix 4
5. The file output is sorted by ICP identifier
267
Version 22.24
Data inputs:

Optional
Participant Char 4 M
Trader Default Trader Participant Identifier
PRAM01
Request example:
HDR,RQDTGENERL,EMCO,RGST,24/02/2014,1,DefaultTraderGeneralData
PRAM01,RETA
Processing:
System:
1. Identify all the ICP’s for selected Trader in default where their current ICP status is active,
inactive or decommissioned.
2. Identifies all ICP’s in a state of “Trader Switch in Progress” where the defaulting Trader will
potentially gain or lose responsibility
3. Identifies all ICP’s in a state of being withdrawals where defaulting Trader will gain or lose
responsibility
4. Generate output file for these ICPs
Data outputs:
Defaulting Trader Char 4 Participant Identifier for Trader in Trader Default
ICP Status Char 3 Current ICP status. One of:

 002 (Active)
 001 (Inactive)
 003 (Decommissioned)
ICP Status Reason Char 14 Status reason code. Populated where ICP status is
Description one of
 Inactive; or
 Decommissioned
ICP Status Reason Char 120 Text description of the ICP Status Reason code
description
Distributor price category Char 50

code
Installation Type Char 1
268
Version 22.24
Meter Type Pre Pay Char 1 Indicator (Y/N) the ICP has Pre Pay metering
Meter Type AMI Char 1 Indicator (Y/N) the ICP has AMI metering
Meter Type NHH Char 1 Indicator (Y/N) the ICP has NHH metering
Meter Type HHR Char 1 Indicator (Y/N) the ICP has HHR metering
Submission Type HHR Char 1 Indicator (Y/N) ICP Trader submission type is HHR
Submission Type NHH Char 1 Indicator (Y/N) ICP Trader submission type is NHH
Submission Type NHH and Char 1 Indicator (Y/N) ICP Trader submission type is HHR
Submission Type HHR and NHH
UNM Char 1 Indicator (Y/N) the UNM flag is set on the latest
Trader Event.
Unmetered Load recorded Char 6 The Daily Unmetered kWh recorded on the latest
against ICP Trader event.
Profile Codes Char 25 Profile codes on latest Trader Event.
Switch Status Char 2 Indicator of ICP Switch in progress state.

One of:
 SA – Switch away from defaulting Trader
 SG – Switch gain to defaulting Trader
 WA – Switch withdrawal away from defaulting
Trader
 WG – Switch withdrawal gain to defaulting
Trader
 Null – no switch in progress
MEP Switch in Progress Char 1 Indicator (Y/N) ICP MEP Switch is in progress:
Highest Metering Category Numeric 1 The highest code of any of the Metering Installation
Categories
MEP Char 4 MEP Identifier of the current MEP. Null if ICP does
not have a current MEP.
Example:
HDR, RSDTGENERL,RGST,EMCO,24/02/2014,1,RetailerDefaultGeneralData
DET,RETA,1234567890AB123,1,4,Electrically disconnected vacant property,PR1,L,N,Y,N,N,Y,N,N,N,,HHR
C24,SA,N,2,META
DET,RETA,1234567890AB456,2,,,PR2,L,N,Y,Y,Y,Y,Y,Y,Y,1219,HHR RPS,WG,N,2,META
DET,RETA,1234567890AB012,1,8,Electrically disconnected due to pole fuse fault,PR2,L,N,Y,N,Y,Y,N,N,N,,HHR
,SG,N,2,META
DET,RETA,1234567890AB345,2,,,PR3,G,N,N,Y,N,N,Y,N,N,,RPS,WA,Y,2,META
269
Version 22.24
Sub-process: PR-255 Produce Metering Installation Information
Participants: Traders, Distributors, Authority, Metering Equipment Providers
Code references:
Dependencies:
Description:
This report is used to show full metering installation information, in PR-030 format, applicable during
a particular period.
It can be requested by Traders, Distributors, MEPs and the Authority. It can be submitted online
and via file.
The participant specifies parameters to be used as selection criteria (filters) to extract the required
metering installation information to be returned in the report rather than having to provide a list of
specific ICPs as required by PR-030. The metering installation information reported is limited to
ICPs where the requester had responsibility during a selected period.
Business Requirements:
1. The report must show the values of all metering installation attributes applicable for the date
range input.
2. The report must be able to be produced as a file in both CSV and XML format.
4. The output must only show metering installation information for event dates that were within the
submitter’s period of responsibility AND satisfy the selection criteria.
5. Where the report requester has more than one role, the report must extract ICP information for
all the requester’s roles (and be selectable); however, duplicate information must not be
displayed e.g. if the requester is both a Distributor and an MEP, any ICP information where the
requester is both the Distributor and the MEP must appear only once in the report.
6. The report must be able to be submitted online or via a file.
7. The Authority must be able to view information for all participants.
Data Inputs:
Leaving an optional parameter null is assumed that ALL values are required, i.e. there is no filter.
Name /Optional
Format Char 1 O C or null indicates file is returned in CSV format
PRAM01 (the default).
X indicates file is returned in XML format.
270
Version 22.24
Status Char 20 O List of space separated valid status codes. Only

PRAM02 001, 002 and 003 are valid.
Filters the report to only include those ICPs with

the selected Status(es) as at the Event Date.
If no filter is entered, all Status values will be
included.
Trader(s) Char 24 O List of space separated valid Trader participant
PRAM03 codes.
If a Trader is the submitter, any values input are
ignored. The submitting Trader’s participant
code is the default value when omitted and the
only input value permitted.
The Authority may input multiple participant
codes of valid Traders.
Filters the report to only include those ICPs

where the Trader(s) had responsibility within the
Start and End Date parameters.
Distributor(s) Char 24 O List of space separated valid Distributor
PRAM04 participant codes.
If a Distributor is the submitter, any values input
are ignored. The submitting Distributor’s
participant code is the default value when
omitted and the only input value permitted.
codes of valid Distributors.

where the Distributor(s) had responsibility within
the Start and End Date parameters.
MEP(s) Char 24 O List of space separated valid MEP participant
PRAM05 codes.
If a MEP is the submitter, any values input are
ignored. The submitting MEP’s participant code
is the default value when omitted and the only
input value permitted.
codes of valid MEPs.

where the MEP(s) had responsibility within the
Start and End Date parameters.
If this report is being run by the Authority, at

least one Trader, Distributor or MEP filter must
be entered.
Role Char 1 O Valid values are
PRAM06  R – Trader
 D – Distributor
 M – MEP.
If a participant has multiple roles then the
parameter defines under what role the request
has been made. For example, if a participant is
271
Version 22.24
both a MEP and Trader and they request the

report as a MEP, the report will provide visibility
to ICPs where they were the responsible MEP
only and not the Trader. Blank is the participants
default role, e.g. if both Trader/Distributor and
MEP will default to Trader/Distributor.
Start Date DD/MM/YYYY M Valid Date.
PRAM07
Filters the report to only include ICPs that the
submitting participant had responsibility for as at
this date or between the Start Date and End
Date parameters.
End Date DD/MM/YYYY M Valid Date >= Start Date,
PRAM08
Filters the report to only include ICPs that the
submitting participant had responsibility for as at
this date.
List request example:
HDR,RQICPLISTM,META,RGST,27/12/2001,11:13:12,13,list by filter
PRAM01,C
PRAM02,001 002
PRAM03,RETA
PRAM04,NETA
PRAM05,
PRAM06,M
PRAM07,01/04/2014
PRAM08,30/04/2014
Processing:
3. Validates report selection criteria (parameters).
4. Extracts metering events based on the report filters. All 4 levels of metering information are
extracted.
5. Delivers output to correct party according to the input format parameter.
Data Outputs:
File output is identical to PR-030 for Input Event Type MET. The output will automatically be sorted
into ICP identifier and event date order.
Reversed/replaced events are not reported, to retain compatibility with PR-030 the following fields
are null:
 Reversal/replaced date/ time
 Reversed/replaced by
 Reversal/replacement file name
 Replacement event audit number
the database)
272
Version 22.24
Event type (full description) Char 14 Variable fields depend on the value of this field. For
example, if the event type is ‘metering’ then
immediately after the last fixed field, the Metering
event attributes are listed.
Event audit number Char 15
Event Date DD/MM/YYYY
Event creation date/time DD/MM/YYYY

HH:MM:SS
Created by Char 15
File name Char 25
Event state Char 8
Reversal/replaced date/ DD/MM/YYYY Always null

time HH:MM:SS
Reversed/replaced by Char 15 Always null
Reversal/replacement file Char 25 Always null

name
Replacement event audit Char 15 Always null

number
Metering event – Summary Variable fields. Event type is “METERSUMMARY”
Metering Equipment
Provider
HHR Flag
NHH Flag
PP Flag
AMI Flag
Meter Register Count

Metering event – Installation Information Variable fields. Event type is “METERINSTALL”
Number
Location Code
273
Version 22.24
ATH Participant Identifier
Certification Type
Certification Date
Control Device Certification

Flag
Expiry Date
Certification Number
Maximum Interrogation
Cycle
Lease Price Code

Metering event – Component Information Variable fields. Event type is “METERCOMP”
Number

Number
Metering Component Type
Meter Type
AMI Flag
Category
Compensation Factor
Owner
Removal Date
Metering event – Channel Information Variable fields. Event type is “METERCHANNEL”
Number

Number
274
Version 22.24
Channel number
Number of Dials
Register content code
Unit of Measurement
Energy Flow Direction
Accumulator Type
Settlement Indicator
Event Reading
275
Version 22.24
Sub-process: PR-270 Produce report of Traders in a trader default situation by

NSP
Code references: Schedule 11.5 of the Code
Dependencies:
Description:
This report is used to identify Traders trading on NSP’s on which a Trader, in a trader default
situation, also trades.
The information will assist the Authority in the ICP Tender and assignment process during a trader
default situation.
The report must be available on demand and only by the Authority.
1. The report may only be run against a Trader who is in a trader default situation (defaulting
Trader). The defaulting Trader is identified by a trader default start date set by the Registry
Manager on instruction from the Authority
2. The report must show all NSPs on which a defaulting Trader trades and detail all the other
Traders, not in a trader default situation, trading on those NSPs. A Trader trades on an NSP
where they have responsibility for ICPs that are in the active or inactive states.
Data inputs:

Optional
Trader Identifier Char 4 M
Participant identifier of trader in a trader
PRAM01 default situation
Request example:
HDR,RQDTNSPTR,EMCO,RGST,24/02/2014,1,NSPTraders
PRAM01,RETA
Processing:
System:
1. Verifies that the selected Trader is in a trader default situation.
2. Identifies ICP’s with a status of active and inactive for which the selected Trader is currently
responsible for.
3. Identifies the NSP of these ICP’s.
276
Version 22.24
4. Identifies the other Traders trading at these NSPs excluding any traders that are in a trader
default situation (ie. excluding the selected Trader and all other defaulting Traders).
5. Generates the output file sorting in ascending NSP order.
Data outputs:
Defaulting Trader Char 4 Participant Identifier of Trader in a trader default

participant identifier situation
NSP identifier Char 11 NSP in use by ICP’s belonging to the defaulting

Trader
Trader participant Char Comma separated list of Trader participant

identifiers identifiers operating on the NSP.
Example:
HDR, RSDTNSPTR,RGST,EMCO,24/02/2014,3,NSPTraders
DET,RETA,NETAABC0011,RETB,RETC,RETZ
DET,RETA,NETAABC0099,RETB
DET,RETA,NETAABD0011,RETC,RETZ
277
Version 22.24
Sub-process: PR-280 Responsibility outside Participant Role
Process: Participant Role Change
Code references:
Dependencies:
Description:
This report will identify ICP’s, for a specified Participant, where the Participant has responsibility for
an ICP in periods where they were or are no longer active in that role. It will also, automatically,
detail the number of ICPs where a responsible participant’s role will end in the next 5 days.
1. The report must only be accessible by the Authority.

2. The report must be available on demand.
3. The on demand report must be submitted to provide either the total number of qualifying ICPs
(summary) or list each qualifying ICP (detail).
4. The on demand report must report ICP’s for a specified Participant and Role where:
a. The ICPs Status is not decommissioned, and
b. The ICPs responsibility resides with the Participant in a period where the Participant
was or is not currently or will not be in the future active in that role. (The active periods
– Role Start Date and Role End Date per Participant and Role is stored in the
reference data within the Registry.)
N.B. If the ICP is currently being switched (Trader, MEP or Distributor switch, as appropriate) it
will still be reported.
5. An automatic report providing advance warning must be delivered to the Authority each day. It
will detail Participants who have a future-dated Role End Date but have ICP’s for which they
will retain responsibility past the Role End Date. The automatic report will produce only
summary information – total numbers of ICPs. A detailed report identifying the individual ICPs
will be available via the on demand report.
6. The automatic report must be run automatically at 7:30pm each night. The automatic report will
include all Participants and their Roles where a Role is due to end within the next 5 days. It will
report the count of ICPs currently the responsibility of the Participant against each Role. N.B:
Where a Role End Date is greater than the report run date + 5 days, the Participant is not
reported.
7. The Detail report option will list ICP id’s in ascending order
Data inputs:
278
Version 22.24
Parameter Name Type Mandatory/ Description

optional
Participant Char 4 M Participant Identifier.

PRAM01
Role Period Char 1 M F – Future

PRAM02  Report ICP’s only if the Participant has
a future dated Role End Date; and
 Report ICP’s where Participant ICP
responsibility extends beyond the future
Role End Date
A – All
 Report ICP’s where a Participant has
ICP responsibility outside the period in
which their Role is/was active.
Future Role End Numeric O If the Role Period is ‘A’ then the entered value is
Days ignored.
PRAM03
If the Role Period is ‘F’ then:
 include Participants whose Role End
Date is within today + Future Role End
Days
 if zero or null, default to 5.
Participant Role Char 1 M T – Trader

PRAM04 D – Distributor
M - MEP
Summary or Detail Char 1 M S – Summary

PRAM05  Produce a summary report
D – Detail
 Produce a report detailing each ICP
Example:
HDR,RQPARTYROL,EMCO,RGST,28/03/2014,11:00:00,4
PRAM01,RETA
PRAM02,F
PRAM03,35
PRAM04,T
PRAM05,S
Processing:
System
1. Validates the input parameters.
2. When the Role Period is ‘F’, identifies the non-decommissioned ICP’s that are currently the
responsibility of the specified Participant in the specified Role and where the Participant’s Role
End Date is within today + Future Role End Days parameter.
279
Version 22.24
3. When the Role Period is ‘A’, identifies non-decommissioned ICP’s that were/are the
responsibility of the specified Participant in the specified Role and where the Participant either
was not or is not active in that role ie. the ICP is not in the Participant’s active period for the
role.
4. If the Summary report was requested then counts the ICPs identified.
5. Generates either the Summary or Detail report format.
Data outputs:
Summary report format:
Participant Char 4 Participant Identifier (from Data Inputs)
Role Char 1 Participant Role (from Data Inputs)
Number of ICPs Numeric Number of ICP’s under the Participant’s
responsibility in the Role as at today’s date.
Detail report format:
Participant Char 4 Participant Identifier (from Data Inputs)
Role Char 1 Participant Role (from Data Inputs)
ICP Identifier Char 15 ICP Identifier of the ICP under the responsibility of
the Participant in the Role
Event date DD/MM/CCYY Event Date of relevant event where Participant
gained responsibility
ICP Status Char 3 ICP Status as at the Event Date.
Summary output example:
HDR,RSPARTYROL,RGST,EMCO,28/03/2014,11:00:00,1
DET,RETA,T,3
Detail output example:
HDR,RSPARTYROL,RGST,EMCO,28/03/2014,11:00:00,3
DET,RETA,T,00012345678AB2E,27/04/2014,002
DET,RETA,T,00012345679AC3E,21/04/2014,002
DET,RETA,T,00012345670AD4E,12/04/2014,001
280
Version 22.24
Sub-process: PR-290 Produce Trader Default Situation Market Share Report
Dependencies:
Description:
This report is produced on request for the Authority and provides a market share percentage for
each Trader trading at NSPs where there is a defaulting Trader. The market share is divided into
mass market and commercial & industrial (C&I) categories.
Market share is aggregated to NSP level across Trader Participants trading on NSP’s at which a
defaulting Trader is also trading.
1. The report is available on demand and only by the Authority.

2. The report may only be run against a Trader who is in a trader default situation (defaulting
Trader). The defaulting Trader is identified by a trader default start date set by the Registry
Manager on instruction from the Authority.
3. The report must calculate the market share per Trader trading at NSPs where the defaulting
Trader is trading. The market share is split per category. All Traders that are in a trader default
situation are excluded from the market share calculation.
4. The report must include all the NSPs where the defaulting Trader is trading. Traders trading at
an NSP where there is a default situation are identified from the ICPs where:
a. The Trader is the currently responsible Trader; and
b. The ICPs status is Active, or Inactive with a status reason other than ‘Ready for
Decommissioning’.
5. The report must calculate the market share for the following categories per Trader trading at an
NSP:
Mass Market* ICPs

6. A Mass Market ICP is identified as having a Highest Metering Category of 0, 1 or 2.
7. Where Metering information has not been provided an ICP will default to mass market
8. The Mass Market ICP’s count is further split by Submission Type NHH and Submission Type
HHR.
9. Where a Mass Market ICP is both Submission Type NHH and HHR it will appear in both counts
Commercial & Industrial ICPs

10. A Commercial & Industrial ICP is identified as having a Highest Metering Category of 3, 4, 5 or
9.
11. Each Commercial & Industrial ICP count is split by Highest Metering Category.
12. Where a defaulting Trader is the only Trader trading at an NSP, the report must contain just the
NSP identifier and total numbers of ICP’s where the defaulting Trader is trading.
281
Version 22.24
N.B. Where a Trader(s) percentage is < 1 %, rounding may cause the total percentage to exceed
100%.
Data inputs:
Parameter Name Type Mandatory Description

/optional
Trader Default Char 4 M Participant Identifier of Trader in a Trader
PRAM01 Default situation.
Example
HDR,RQMKTSHARE,EMCO,RGST,23/03/2007,15:49:06,1,Trader Default Market Share
PRAM01,RETZ
Processing:
System:
1. Verifies that the selected Trader is in a Trader Default situation.
2. Identifies the NSP’s where the selected defaulting Trader is currently trading.
3. Identifies all the other Traders (other than the selected defaulting Trader) trading at these NSPs
excluding those traders that are also in a Trader Default situation.
4. For each NSP:
a) Counts the number of ICPs where the selected defaulting Trader is currently trading.
b) Counts the number of ICPs where all the non-defaulting Traders are currently trading.
c) Counts the number of ICPs where all the Traders are currently trading (including the
defaulting Traders).
d) For each non-defaulting Trader counts the number of ICPs, where that Trader is currently
trading, by each of the following categories:
 highest metering category is one of 0, 1 or 2, and submission type NHH;

 highest metering category is one of 0, 1 or 2 and submission type HHR;
 highest metering category 3;

 highest metering category 9.

e) For each category calculates the market share as a percentage of the total count of ICPs
excluding the defaulting Traders portion (i.e. uses b above)
282
Version 22.24
f) Rounds the percentage to the nearest whole number except when the percentage > 0 and
< 1 when it is rounded up to 1%.
5. Where all (100%) of the ICPs at an NSP are being traded by the selected defaulting Trader, the
non-defaulting Trader and subsequent fields are left blank and reported.
6. Formats the report in ascending NSP sequence.
Data outputs:
NSP Char 11 NSP identifier where the selected defaulting Trader is

currently trading.
Number of ICPs at NSP Numeric Count of ICP’s at the NSP where Traders are currently
trading, including all Traders in a trader default situation.
Number of defaulting Numeric Count of all ICP’s at the NSP for which the defaulting
Trader ICP’s at NSP Trader is responsible.
Trader Char 4 Trader Participant Identifier of a non-defaulting Trader

trading at the NSP.
Mass Market NHH Char 4 Percentage of the non-defaulting Trader’s NHH Mass
Market ICP’s at the NSP.
Mass Market HHR Char 4 Percentage of the non-defaulting Trader’s HHR Mass
Market ICP’s at the NSP.
C&I Category 3 Char 4 Percentage of the non-defaulting Trader’s Metering

Installation Category 3 ICP’s at the NSP.



File example:
HDR,RSMKTSHARE,RGST,EMCO,28/03/2014,11:00:00,5,Trader Default Market Share
DET,ABC0123,1600,800,RETA,12%,16%,25%,1%,25%,0%
DET,ABC0123,1600,800,RETB,78%,26%,25%,1%,1%,0%
DET,ABC0123,1600,800,RETC,10%,58%,50%,99%,74%,0%
DET,DEF0321,1800,25,RETB,90%,10%,50%,0%,1%,0%
DET,DEF0321,1800,25,RETD,10%,90%,50%,0%,99%,0%
DET,GHI0999,2,2,,,,,
283
Version 22.24
Sub-process: PR-320 Monitor switch saving protection scheme
Process: Switching
Dependencies:
Description:
In order to monitor the effectiveness of the switch saving protection scheme, the Authority has
introduced two switch withdrawal codes:
a. CE - Customer cancels the switch because the original switch request was an error (e.g.,
customer provides incorrect information)
b. CX –Customer cancels the switch for a reason other than that in CE (e.g. the customer
changes their mind)
This report is produced monthly for the Authority and provides statistics on the above switch
withdrawal advisory codes for the previous reporting period.
The report is available to run on an ad-hoc basis where it will report statistics on the above switch
withdrawal advisory codes for any reporting period.
1. The automatic report must be delivered to the Authority by 09:00 hours on the 15th day of each
month covering the previous reporting period.
2. It must be possible to run the report ad-hoc for any date range.
3. The report must include Trader switch withdrawals (NW), in the report date range, where the
switch withdrawal code is one of:
a) CE – customer error; or
b) CX – customer cancellation.
4. The report date range refers to the input date when the switch withdrawal NW was supplied.
For example an NT initiated in January has a NW supplied in February. The ICP appears in
February figures.
5. The report must identify the state of the switch when the withdrawal was submitted, this will be
one of:
a) In progress – the switch was awaiting a CS i.e. had not completed when the
withdrawal request occurred
b) Completed – the switch had been completed (a CS had been supplied). The switch
was being withdrawn after completion
6. The report must identify the outcome of the switch withdrawal, this will be one of:
a) Accepted - the withdrawal acknowledgement (AW) accepted the withdrawal
284
Version 22.24
b) Rejected – the withdrawal acknowledgement (AW) rejected the withdrawal

c) Unknown – the withdrawal acknowledgement (AW) has not been received
Data inputs:
/optional
Start Date DD/MM/YYYY M Start date of the report period during
PRAM01 which the switch withdrawal NW was
supplied.
End Date DD/MM/YYYY M End date of the report period during which
PRAM02 the switch withdrawal NW was supplied.
Example:
HDR,RQSWSVPRSC,EMCO,RGST,23/03/2007,15:49:06,2,Switch Save Protection Scheme
PRAM01,01/01/2015
PRAM02,31/01/2015
Processing:
System:
1. Validates the input parameters
2. Identifies all ICPs that have received a switch withdrawal (NW) message between the start and
end date reporting period, where the withdrawal code is one of CE or CX
3. Generates the results file and delivers it to the Authority.
Data outputs:
Results File supplied to the Authority detailing the withdrawal switch. The file output name for the
automatic monthly file will be:
 “PR320_SaveProtectionScheme_<timestamp>.csv where timestamp is format

“yyyymmddhhmmss” and specifies the run time.
ICP identifier Char 15
Withdrawal code Char 2 One of CE or CX
285
Version 22.24
Submitting Trader Char 4 Participant identifier of the Trader submitting the

withdrawal request
Other Trader Char 4 Participant identifier of the other Trader involved in the
Trader switch
Trader Switch status Char One of

 In progress
 Completed
Result of withdrawal Char 11 One of

 Accepted - where withdrawal was accepted
 Rejected - where withdrawal was rejected
 Unknown- where the AW has not yet been
received
File example:
HDR,RSWDLSAVWB,RGST,EMCO,28/03/2014,11:00:00,6, Switch Save Protection Scheme
DET,1234567890AB123,CE,RETB,RETD,In progress,Unknown
DET,2345678901AB234,CE,RETB,RETD,In progress,Unknown
DET,3456789012AB345,CE,RETB,RETE,Completed,Accepted
DET,3456789012AB345,CX,RETB,RETE,Completed.Rejected
DET,4567890123AB456,CE,RETC,RETA,In progress,Unknown
DET,5678901234AB567,CE,RETC,RETA,In progress,Unknown
286
Version 22.24
Sub-process: PR-330 Produce Distributor Annual Levy report
Process: Produce annual levy report
Code references:
Dependencies:
Description:
This report is produced automatically for the Authority on 30 October each year, and provides the
daily average per month of the number of ICPs of each reconciliation type, in the active or ready
state, that were the responsibility of each distributor during the previous 12 month period from 1
July to 30 June.
1. The report must be delivered to the Authority by 06:00 hours on 30 October.

2. The report must cover the period 1 July of the previous year to 30 June of the current year.
3. Only ICPs that were in the ready or active state for any time during the above period must be
included in the report
Data inputs:
Processing:
The system:
1. Accumulate counts against the Distributor responsible for the ICP in the month
2. Calculates the daily average number of ICPs per month for each distributor, reconciliation type
and status (ready, active) by dividing the number of ICPs by the number of days in the month.
3. Constructs the appropriate output rows and writes them to the output file.
4. Transfers the output file to the Authority by email to an email group as specified by the
Authority
Data outputs:
The Authority report to be automatically delivered 30 October each year, report name:
 ICPsOwnedDistributor<previous year><current year>.csv,
for example ICPsOwnedDistributor20142015.
287
Version 22.24
Description row
Event data Format Validation rules
Title column 1 Char 3 Must be “Record type”
Title column 2 Char 50 Must be “Distributor”
Title column 3 Char 20 Must be “Reconciliation Type”
Title column 4 Char 20 Must be “Ready July”
Title column 5 Char 20 Must be “Ready August”
Title column 6 Char 20 Must be “Ready September”
Title column 7 Char 20 Must be “Ready October”
Title column 8 Char 20 Must be “Ready November”
Title column 9 Char 20 Must be “Ready December”
Title column 10 Char 20 Must be “Ready January”
Title column 11 Char 20 Must be “Ready February”
Title column 12 Char 20 Must be “Ready March”
Title column 13 Char 20 Must be “Ready April”
Title column 14 Char 20 Must be “Ready May”
Title column 15 Char 20 Must be “Ready June”
Title column 16 Char 20 Must be “Ready Total”
Title column 17 Char 20 Blank column to separate ready and active counts
Title column 18 Char 20 Must be “Active July”
Title column 19 Char 20 Must be “Active August”
Title column 20 Char 20 Must be “Active September”
Title column 21 Char 20 Must be “Active October”
Title column 22 Char 20 Must be “Active November”
288
Version 22.24
Description row
Title column 23 Char 20 Must be “Active December”
Title column 24 Char 20 Must be “Active January”
Title column 25 Char 20 Must be “Active February”
Title column 26 Char 20 Must be “Active March”
Title column 27 Char 20 Must be “Active April”
Title column 28 Char 20 Must be “Active May”
Title column 29 Char 20 Must be “Active June”
Title column 30 Char 20 Must be “Active Total”
Title column 31 Char 20 Blank column to separate counts
Title column 32 Char 20 Must be “Ready/Active Total”
Detail row
DET – indicates the row is a detail record of

Detail record type Char 3
consumption information.
Valid participant identifier that existed within the

report period
Reconciliation type of group of ICPs over which the

Reconciliation type Char 2
calculation is performed
Count of ICP days in the month of July in the

Ready July Numeric 8.2 previous year where the ICP was in the Ready
status/total days in the month
Count of ICP days in the month of August in the

Ready August Numeric 8.2 previous year where the ICP was in the Ready
Count of ICP days in the month of September in the

Ready September Numeric 8.2 previous year where the ICP was in the Ready
289
Version 22.24
Detail row
Count of ICP days in the month of October in the

Ready October Numeric 8.2 previous year where the ICP was in the Ready
Count of ICP days in the month of November in the

Ready November Numeric 8.2 previous year where the ICP was in the Ready
Count of ICP days in the month of December in the

Ready December Numeric 8.2 previous year where the ICP was in the Ready
Count of ICP days in the month of January in the

Ready January Numeric 8.2 current year where the ICP was in the Ready
Count of ICP days in the month of February in the

Ready February Numeric 8.2 current year where the ICP was in the Ready
Count of ICP days in the month of March in the

Ready March Numeric 8.2 current year where the ICP was in the Ready
Count of ICP days in the month of April in the current

Ready April Numeric 8.2 year where the ICP was in the Ready status/total
days in the month
Count of ICP days in the month of May in the current

Ready May Numeric 8.2 year where the ICP was in the Ready status/total
days in the month
Count of ICP days in the month of June in the current

Ready June Numeric 8.2 year where the ICP was in the Ready status/total
days in the month
Ready Total Numeric Sum of Ready count rounded
Blank column Char 20 Blank column to separate ready and active counts

Active July Numeric 8.2 previous year where the ICP was in the Active
290
Version 22.24
Detail row

Active August Numeric 8.2 previous year where the ICP was in the Active

Active September Numeric 8.2 previous year where the ICP was in the Active

Active October Numeric 8.2 previous year where the ICP was in the Active

Active November Numeric 8.2 previous year where the ICP was in the Active

Active December Numeric 8.2 previous year where the ICP was in the Active

Active January Numeric 8.2 current year where the ICP was in the Active

Active February Numeric 8.2 current year where the ICP was in the Active

Active March Numeric 8.2 current year where the ICP was in the Active

Active April Numeric 8.2 year where the ICP was in the Active status/total
days in the month

Active May Numeric 8.2 year where the ICP was in the Active status/total
days in the month

Active June Numeric 8.2 year where the ICP was in the Active status/total
days in the month
Active Total Numeric Sum of active count rounded
291
Version 22.24
Detail row
Blank column Char 20 Blank column to separate ready and active counts
Ready/Active Total Numeric Sum of Ready and Active annual total rounded
Example:
HDR,RSDISTLEVY,RGST,EMCO,30/10/2015,01:33:47,32,Levy
DET,Distributor,Reconciliation Type,Ready July,Ready August,….Active July,Active August …
DET,NETA,GN,124.65,127.00,…..127.00,186.25…
292
Version 22.24
Sub-process: PR-340 Produce Trader Annual Levy report
Process: Produce annual levy report
Code references:
Dependencies:
Description:
This report is produced automatically for the Authority on 30 October each year, and provides a
weighted average count of the number of ICP’s in an active state a Trader participant is responsible
for in the period 1 July in the previous years to 30 June in the current year.
1. The report must be delivered to the Authority by 06:00 hours on 30 October.

2. The report must cover the period 1 July of the previous year to 30 June of the current year.
3. Only ICPs that were in the active state for any time during the above period must be included in
the report
Data inputs:
Processing:
The system:
1. Accumulate counts against the Trader responsible for the ICP in the month
2. Calculates the daily average number of ICPs per month for each Trader, reconciliation type and
status by dividing the number of ICPs by the number of days in the month.
3. Constructs the appropriate output rows and writes them to the output file.
4. Transfers the output file to the Authority by email to an email group as specified by the
Authority
Data outputs:
The report will contain a standard header.
The following line comprises a description row
The output file name will have the following format:
 ICPsOwnedTrader<previous year><current year>.csv,
for example ICPsOwnedTrader20142015.
293
Version 22.24
Description row
Title column 1 Char 3 Must be “Record type”
Title column 2 Char 50 Must be “Trader”
Title column 3 Char 20 Must be “Reconciliation Type”
Title column 4 Char 20 Must be “Active July”
Title column 5 Char 20 Must be “Active August”
Title column 6 Char 20 Must be “Active September”
Title column 7 Char 20 Must be “Active October”
Title column 8 Char 20 Must be “Active November”
Title column 9 Char 20 Must be “Active December”
Title column 10 Char 20 Must be “Active January”
Title column 11 Char 20 Must be “Active February”
Title column 12 Char 20 Must be “Active March”
Title column 13 Char 20 Must be “Active April”
Title column 14 Char 20 Must be “Active May”
Title column 15 Char 20 Must be “Active June”
Title column 16 Char 20 Must be “Active Total”
Detail row
DET – indicates the row is a detail record of

Detail record type Char 3
consumption information.
Valid participant identifier that existed within the

report period
294
Version 22.24
Detail row
Reconciliation type of group of ICPs over which the

Reconciliation type Char 2
calculation is performed

Active July Numeric 8.2 previous year where the ICP was in the Active

Active August Numeric 8.2 previous year where the ICP was in the Active

Active September Numeric 8.2 previous year where the ICP was in the Active

Active October Numeric 8.2 previous year where the ICP was in the Active

Active November Numeric 8.2 previous year where the ICP was in the Active

Active December Numeric 8.2 previous year where the ICP was in the Active

Active January Numeric 8.2 current year where the ICP was in the Active

Active February Numeric 8.2 current year where the ICP was in the Active

Active March Numeric 8.2 current year where the ICP was in the Active

Active April Numeric 8.2 year where the ICP was in the Active status/total
days in the month

Active May Numeric 8.2 year where the ICP was in the Active status/total
days in the month
295
Version 22.24
Detail row

Active June Numeric 8.2 year where the ICP was in the Active status/total
days in the month
Active Total Char 12 Sum of active count rounded
Example:
HDR,RSTRADLEVY,RGST,EMCO,30/10/2015,01:33:47,32,Trader Levy
DET,Trader,Reconciliation Type,Active July,Active August,Active September,Active October…
DET,RETA,GN,124.65,127.00,127.00,186.25…
296
Version 22.24
3.6 User parameters

Sub-process: MP-010 Set switching message receipt times
Process: Maintain user parameters
Participants: The relevant Traders, Metering Equipment Providers and Distributors
Code references:
Dependencies:
Description:
A user with supervisor privileges should be able to choose the time switch messages are received
and how they are grouped.
Note that Distributors and Metering Equipment Providers will always receive their MN, CS and RR
notifications overnight so do not need to set switching receipt times.
Switching options are :

 To deliver switch messages at specific times each day (08:00 hours or 11:00 hours or
15:00 hours or 18:00 hours) or sent immediately they are received by the Registry
 To batch all switch messages in one file or in separate files.
1. Only a user with supervisor privileges will be able to perform this function.
2. Users must be able to choose to receive switching messages individually immediately when
they are processed by the registry or in batches at specific times during the day.
3. Where users choose to receive switching messages at specific times, all messages of one
type, eg NT or AN, will be sent by the registry in separate files.
4. Users must be able to further choose to separate switching messages into files based on
sending Trader, ie NTs sent by RETA will be in a separate file as will NTs from RETB. The
default is all Traders together in one file per message type.
5. Once set, the parameter settings will apply to all switching messages received by the
participant company.
Processing:
Data inputs:
 Delivery time(s).
 Grouping selection.
297
Version 22.24
Data outputs:
Confirmation of new settings on screen.

Audit trail of changes.
298
Version 22.24
Sub-process: MP-020 Set notify parameters
Process: Maintain user parameters
Code references:
Dependencies: RS-050, NP-020, NP-060
Description:
A user with supervisor privileges will be able to select for which event types notifications are
received by their participant company. Only those notifications not explicitly mentioned in the Code
will be available for selection.
In addition, participants can select whether to receive

 their snapshot version of the PR-030 in CSV or XML format.
 whether their snapshot version of the PR-030 is to be delivered with NT, the CS or not at
all. The delivery will be immediate for the NT to the new Trader, but for the CS it will be
delivered in accordance with the switch notify parameters of the CS of the new Trader.
1. Only a user with supervisor privileges must be able to perform this function.
2. Where a participant has a dual role, eg Trader and Metering Equipment Providers, it must be
able to set the parameters separately for each role.
3. The Registry must not send duplicate notifications for the same event at an ICP in respect of
which a participant has dual roles.
4. Traders must always receive notification of Address, Status, Network, Metering and all Trader
events.
5. Distributors must always receive notification of Address, Status, Network, Metering, Pricing
events and of Trader events generated at the completion of a switch.
6. Metering Equipment Providers must always receive notification of Status, Metering and Trader
events generated at the completion of a switch.
7. Once set, the parameter settings must apply immediately to all the participant’s notifications.
Processing:
1. Validate and process notification options.
Data inputs:
299
Version 22.24
 Event notification settings for each event type and role.
 Event Detail report snapshot reporting format – CSV or XML.
Data outputs:
 Confirmation of new settings on screen.
 Audit trail of changes.
300
Version 22.24
3.7 Notifications
Sub-process: NP-010 Acknowledge event change
Process: Notify participants
Dependencies: DC-010, DC-020, DM-010, DM-020, DM-030, DM-040, RA-010, RM-010,

RM-020, RM-030, RM-040, RS-010, RS-020, RS-030, RS-040, RS-050,
RW-010, RW-020, RC-010, RC-020, MN-010, SD-030, SD-040
Description:
The Code requires that when information such as a change to an ICP attribute and notification of a
switch transaction is sent to the registry, the registry confirms receipt of the information to the
participant within four hours of the information being provided to the registry.
For transactions entered online (except for Loss Factor and Pricing category maintenance),
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 file.
For batch updates sent in a file, acknowledgements of each update must be provided in a file. If
the system rejects a change received in the file, it must indicate the reason as part of the
acknowledgement (error processing).
Users must be able to see online whether their changes, whether submitted online or via file, have
been confirmed (acknowledged). The details shown must include:
 date and time stamp;

 participant (sent to); and
 file name.
1. The participant who provided the information must be sent an acknowledgement within four
hours of the information being provided by the participant.
Processing:
System
1. Formats and sends acknowledgement to submitter.
301
Version 22.24
Data inputs:
As a result of the following sub-processes:
DC-010, DC-020, DM-010, DM-020, DM-030, DM-040, RA-010, RM-010, RM-020, RM-030, RM-
040, RS-010, RS-020, RS-030, RS-040, RS-050, RW-010, RW-020, RC-010, RC-020, MM-010,
MM-020, MM-030, MN-010, SD-030, SD-040
Data outputs:
Acknowledgements.
Acknowledgement information to include:
Name Format Mandatory/ Comments

optional
Record Type Char 3 M “DET”
Date processed DD/MM/YYYY M
Time processed HH:MM:SS M
Registry audit Char 15 O Audit number of the successful update.

reference
Request mode Char 1 M W (web browser)
F (file upload)
ICP Identifier Char 15 M For PC and LF Action Requested types, the

category code, otherwise the ICP identifier.
302
Version 22.24

optional
Event Date DD/MM/CCYY O For PC and LF Action Requested types this

is the Start Date of the code.
For switch messages :

NT switch – requested transfer date
AN switch – input date
TN switch – actual transfer date (switch
Event Date)
TT switch – actual transfer date (switch
Event Date)
NC switch – switch Event Date
AC switch – switch Event Date
CS switch – actual transfer date (switch
Event Date)
RR switch – actual transfer date (switch
Event Date)
MN switch – transfer date. This is null if the
MN rejects the nomination
For event change acknowledgements this is

the Event Date of the transaction.
Action requested Char 3 M REC—Trader event

MET—Metering event
STA—Status event
PRI—Pricing event
NET—network (NSP) event
ADD—Address event
NT—NT message
AN—AN message
TN*—TN message
CS —CS message
TT*—TT message
NW—NW message
AW—AW message
NC*—NC message
RR—RR message
AC—AC message
MN – MN responsibility message
DCH—initial creation date
PC—Price category code change
LF—Loss category code change
* Discontinued.
303
Version 22.24

optional
Result Num 3 M 000 if update successful, otherwise an error

code.
Submitted by Char 10 O User ID.
User supplied Char 32 O Free text field carried over from input file.
reference
Metering Error Char 100 O When Result is an error code, contextual

Location information which may be helpful in finding
the error, e.g. locating the specific row within
a set of metering event data.
H: for the header row,
I:<Metering Installation Number> to identify

the installation row.
M:<serial number> to identify the component

row.
R:<serial number>:<channel number> to

identify the channel row.
P: for the premises row (CS/RR)
304
Version 22.24
Sub-process: NP-020 Send switch messages
Participants: Traders, Metering Equipment Providers
Code references: Clauses 19, 20 and 22 of Schedule 11.3 of the Code.
Dependencies: RS-010, RS-020, RS-030, RS-040, RS-050, RW-010, RW-020, RC-010,

RC-020, MN-010, PR-030
Description:
Traders and MEPs are required to send all their switch messages to the registry, not directly to the
other participant. It is the responsibility of the registry to pass them on to the other participant.
In providing the switch transfer mechanism, the registry must:
1. Route only valid switch messages and only to the appropriate recipient;
2. Take into account the recipient’s switch file delivery preferences (switching parameters);
3. Deliver the switching messages via file to the recipient in the same format as they are input;
4. Provide an authoritative audit trail of all switch data transfer activity, ie who, when, filename,
from which participant, to which participant, etc; and retain the actual switch files for a minimum
of 3 months.
5. Deliver the PR-030 snapshot where appropriate and in accordance with the Traders switch
notify parameters (MP-020).
Processing:
System
1. Determines who is the intended recipient from the information contained in the switch message
and the participants to the switch (see table in section 1.12.4).
2. Determines if the PR-030 snapshot is also to be delivered and to whom.
3. Groups the messages and PR-030 snapshot (if relevant) and delivers them at the time and
batching method indicated in the recipient’s switching parameters.
Data inputs:
Valid switch messages – NT, AN, TT, TN, CS, NW, AW, NC, RR, AC, MN.
Switch notify parameters.
305
Version 22.24
Data outputs:
Switch file.
PR-030 snapshot file with the same filename as the related switch file but with a .eda file extension.
306
Version 22.24
Sub-process: NP-030 Notify of event change
Participants: Traders, Distributors, Metering Equipment Providers, Approved Test

Houses, Metering Equipment Owners

RM-020, RM-030, RM-040, RW-020, NP-020, RS-050, MM-010, MM-
020, MM-030, NP-020
Description:
The purpose of notifications is to enable participants to synchronise the data stored in their systems
with that held in the Registry. Whenever there is a change to Registry information, notifications are
delivered to the affected parties (see 1.11.13), taking into account the participant’s preferences
indicated in their notification parameters (see NP-020).
Notifications have two output formats, one for standard (i.e. non-metering) information and one for
metering information. The standard file has a filename beginning with “NOT” while the notification
file containing metering information has a filename beginning with “NMR”. Both files are delivered in
the same manner and at the same time.
Participants can access their notifications either directly from their FTP directory or via web
services in the case of participants with ICP responsibility (traders, distributors, MEPs).
1. The Registry must send a notification of changes to and ICP to all affected parties on the day
the Registry receives the information (clause 11.29).
2. Since one or more of the responsible parties may be the subject of a change to an ICP, the
Registry must be able to inform both current (old) and/or new responsible or proposed parties
of the change (see above section 1.11 Notifications for details).
3. The Registry must only provide an affected participant with those notifications requested by that
participant.
4. Where a participant has multiple roles that includes ATH/MEO, the Registry must be able to
provide ATH/MEO output separately, if required.
5. Where an ATH/MEO also fulfils a role that includes ICP responsibility; that is MEP, Trader or
Distributor, and an ICP for which they have responsibility in that role is updated, they must
receive notifications based on ICP responsibility. In all circumstances, a participant with
multiple roles must receive a single notification.
Data inputs:
307
Version 22.24
 Valid new, reversed or replaced events.
 Participants notification parameters (NP-020)
Processing:
System
1. Determines who the participants are that are affected by the change.
2. Checks whether the participant wishes to receive notifications for the event type of the change
and type of maintenance, and whether metering notifications are to be reported separately for
ATH and MEO roles, as indicated by its notification parameters (see NP-020).
3. Formats the notification and makes it available to each affected participant that requires it
Data outputs:
 Notification file (current format for all events except Metering)

 Metering Event Notification file.
The (standard) notification should contain the following information:

optional
Notification type Char 1 M R (event reversal), A (change of

data).
Switch status Char 1 O S if ICP is currently undergoing a

Trader switch,
M if ICP is currently undergoing an
MEP switch,
B if ICP is undergoing both a Trader
and MEP switch
or else blank.
Network audit number Char 15 O For a Notification Type of R this is

the Audit Number of the event that
was reversed or replaced. For a
Notification Type of A this is the audit
number of the new event.
Network Participant Char 4 O Valid Participant Identifier for

Identifier Distributor.
308
Version 22.24

optional
POC Char 7 O
Reconciliation Type Char 2 O
Dedicated NSP Char 1 O
Installation Type Char 1 O
Proposed Trader Char 4 O
Unmetered Load Details - Char 50 O

Distributor
Shared ICP List List O
Generation Capacity Numeric 6.2 O
Fuel Type Char 15 O
Initial Electrically DD/MM/YYYY O

Connected Date
Direct Billed Status Char 11 O
Direct Billed Details Char 60 O
Network pricing audit Char 15 O For a Notification Type of R this is

number the Audit Number of the event that

Code
Distributor Loss Category Char 7 O

Code
Distributor Installation Char 30 O

Details
Network pricing User Char 32 O

Reference
Address audit number Char 15 O For a Notification Type of R this is

309
Version 22.24

optional
Physical Address Char 25 O

Number/ RAPID number
Physical Address Street Char 30 O
Physical Address Suburb Char 30 O
Physical Address Town Char 30 O
Physical Address Post Numeric 4 O

Code
Physical Address Region Char 20 O
Address Property Name Char 75 O
GPS_Easting Numeric 7.3 O
GPS_Northing Numeric 7.3 O
Trader audit number Char 15 O For a Notification Type of R this is

Trader Char 4 O
Profile Char 25 O
ANZSIC Char 7 O
Proposed MEP Char 4 O From Trader event

Submission Type HHR Y/N O From Trader event
Submission Type NHH Y/N O From Trader event
UNM Flag Y/N O From Trader event
Unmetered Load Details – Char 50 O From Trader event

Trader
Daily Unmetered kWh Char 6 O From Trader event
Trader User Reference Char 32 O
310
Version 22.24

optional
Status audit number Char 15 O For a Notification Type of R this is

ICP Status Char 3 O 999—new, 888—distributor, 000—

ready, 002—active, 001—inactive,
003—decommissioned.
ICP Status Reason Numeric 2 M/O See static data tables for current
codes.
Status User Reference Char 32 O
311
Version 22.24

optional
Example 1:
Assume we have an ICP on the Registry with the following Pricing Details:
Event Date 1 April 2001 Price Code = 40W
Event Date 30 September 2001 Price Code = 60W.
The Distributor realises that the ICP should have been on Price code 45W for the period 1 April
2001 to 30 Sept 2001 at which time it changed to 60W and so updates the Registry by inserting a
new network pricing event (via the “Change Distributor Details” screen or via Distributor
Maintenance) with an event date of 1 April 2001. The following notification file would be generated:
DET,01/04/2001,0000123456UNAED,R,,,,,,,,,,,,,,,,,123456799,40W,L1,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
DET,01/04/2001,0000123456UNAED,,,,,,,,,,,,,,,,,,123456800,45W,L1,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
Example 2:
If the Distributor wanted to update the ICP so that the Price Code was 45W for the period 1April
2001 to current date then he would be required to do two things, reverse the Network Pricing event
dated 30 September 2001 (via the “Change Distributor Details” screen or via Distributor
Maintenance) and insert the Network Pricing Event dated 1 April 2001 as per above. Under this
scenario three notification lines would be output to the relevant parties these would be as follows:
Line 1 for the reversal of the 30 Sept. event:

DET,30/09/2001,0000123456UNAED,R,,,,,,,,,,,,,,,,,123456797,60W,L1,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
Lines 2 and 3 for the insertion of the 1 April event:
DET,1/04/2001,0000123456UNAED,R,,,,,,,,,,,,,,,,,123456799,40W,L1,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
DET,1/04/2001,0000123456UNAED,,,,,,,,,,,,,,,,,,123456800,45W,L1,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
Example 3 New distributor and retailer events added:

HDR,RSAUNOTIFY,RGST,EMCO,13/06/2012,00:32:00,00000002
DET,1/01/2009,99999999999AB123,A,,NET-
123,NETA,ABCD123,GN,N,B,RETA,UnmeteredDetail,,B,wind,1/01/2009,Both,Optional
Field,NetworkUserRef,PRI-123,Pcat1,Lcat1,1234,installdetails,PricingUserref,ADD-
123,Unit1,678,Perkins Road,Ohau,Tekapo,7797,Canterbury,White
House,1234567.123,57.6,Addref,,,,,,,,,,,,,,,
DET,1/01/2009,99999999999AB123,A,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,REC-
123,RETA,RPS,123456,META,N,Y,N,,,TraderRef,STA-123,2,,StatusUserRef
312
Version 22.24
Metering Event Notification file format:
The first 6 columns are identical for all transaction types and will contain the same values
for a single ICP. The order of the transaction types follows the usual pattern of
METERHEADER, METERINSTALL, METERCOMP, METERCHANNEL, METERCHANNEL etc.,
METERINSTALL, METERCOMP, METERCHANNEL, METERCHANNEL etc. for a single ICP. A
new ICP is indicated by a METERINSTALL transaction Type.
Header row:

optional

Event date DD/MM/YYYY M
ICP Char 15 M
Notification type Char 1 M R (event reversal), A (change of data).
Switch status Char 1 O S if ICP is currently undergoing a Trader switch,
M if ICP is currently undergoing an MEP switch,
B if ICP is undergoing both a Trader and MEP
switch,
else blank.
Metering audit number Char 15 O For a Notification Type of R this is the Audit
Number of the event that was reversed or
replaced. For a Notification Type of A this is the
audit number of the new event.
Transaction Type Char 14 M ‘METERHEADER’ for metering header information
MEP Participant Identifier Char 4 M
Highest Metering Category Numeric 1 M
HHR Flag Y/N M
NHH Flag Y/N M
PP Flag Y/N M
AMI Flag Y/N M
Meter Channel Count Numeric 3 M
Meter Multiplier Flag Char 1 M
Metering user reference Char 32 O
Number of installations Numeric 2 M There must be this many ‘METERINSTALL’ rows
following (interspersed with the associated
‘METERCOMP’ and ‘METERCHANNEL’ rows)
immediately following this row
Installation Row:
313
Version 22.24

optional

ICP Char 15 M Must be same as the ICP in the prior
‘METERHEADER’ record.
switch,
else blank.
Transaction Type Char 14 M ‘METERINSTALL’ for metering installation
information.
Metering Installation Number Numeric 3 M A number identifying the installation within the ICP.
Is unique within the ICP.
Highest Metering Category Numeric 1 M 1 to 5.
Metering Installation Location Char 50 M A 6 character code (can be 1 to 6 characters) from
Code the list of codes within the Registry that identifies the
location of the metering installation and, optionally,
concatenated with the New Zealand Transverse
Mercator 2000 (NZTM2000) GPS co-ordinates of the
ATH Participant Identifier Char 4 M/O A valid Participant Identifier of the ATH. Mandatory if
the Metering Installation Certification Type is ‘F’.
Metering Installation Type Char 3 M ‘HHR’ or ‘NHH’ or ‘NON.
Certification Type
Flag
Certification Variations Char 1 M ‘X’ – An exemption under the Act for the metering
‘A’ – The alternate measuring transformer
certification process is used; or
‘N’ – None.
314
Version 22.24

optional
Date
Type is ‘F’.
Maximum Interrogation Cycle Numeric 3 M In days.
Number Of Components Numeric 2 M There must be this many ‘METERCOMP’ rows
(interspersed with the associated
‘METERCHANNEL’ rows) following this row for this
ICP.
Meter/Component Row:

optional

ICP Char 15 M Must be same as the ICP in the prior
‘METERINSTALL’ record.
switch,
else blank.
Transaction Type Char 14 M ‘METERCOMP’ for meter/component information
Metering Installation Number Numeric 3 M Must be the same as the Metering Installation
Number in the prior ‘METERINSTALL’ record.
Metering Component Serial Char 25 M Identifier of meter. Validated by system to be unique
Number within the ICP.
Metering Component Type Char 1 M M – Meter, C – CT, V – VT, D – Data Storage
Device,
L- Control Device
Meter Type Char 3 M/O. HHR/NHH/PP. Mandatory where Metering
Component Type = M.
AMI Flag Char 1 M Y/N
315
Version 22.24

optional
Metering Installation Numeric 1 M/O 1 – 5. Mandatory where Metering Component Type

Category = M.
Compensation Factor Numeric 6.3 M Maximum value is 999999.999. W here the
Metering Components Type is M (meter) the
value is greater than zero.
Owner Char 6 O If the Owner is a participant then their valid 4

character Participant Identifier otherwise free text > 4
characters.
Removal Date DD/MM/YYYY O
Number of Channels Numeric 3 M Total number of channels on the component. There
must be this many ‘METERCHANNEL’ rows
immediately following this row.
Channel Row:

optional

Event date DD/MM/YYY M
Y
ICP Char 15 M Must be same as the ICP in the prior ‘METERCOMP’
record.
switch,
else blank.
Transaction Type Char 14 M ‘METERCHANNEL’ for register/channel information
Metering Installation Number Numeric 3 M Must be same as the Metering Installation Number in
the prior ‘METERCOMP’ record.
Metering Component Serial Char 25 M Must be same as the Metering Component Serial
Number Number in the prior ‘METERCOMP’ record.
Channel Number Numeric 2 M Must be a unique number within the metering
component.
Number of Dials Numeric 2 M/O Number of dials/digits (not recording fractions of a
unit) on the meter’s registers/channels. Valid values
316
Version 22.24

optional
are between 4 and 12. Mandatory where Metering

Component Type = M.
Register Content Code Char 6 M/O Valid register content code from the static reference
table stored in the registry. Mandatory where
Metering Component Type = M or D.
Period of Availability Numeric 2 M/O <=24. Minimum service hours per day that supply
is available for. Mandatory where Metering
Component Type = M or D.
Unit of Measurement Char 6 M/O Valid channel unit code from the static reference
table stored in the registry. Eg. kWh, kW, kVA,
kVArh. Mandatory where Metering Component Type
= M or D.
Energy Flow Direction Char 1 M/O Valid values are 'I' for injection and 'X' for exit.
Mandatory where Metering Component Type = M or
D.
Accumulator Type Char 1 M/O Valid values are ‘C’ for cumulative and ‘A’ for
absolute. Mandatory where Metering Component
Type = M or D.
Settlement Indicator Char 1 M Y/N.
Event Reading Numeric 12 O Must be less than what can be stored with the
Number of Dials.
File example:
HDR, RSMENOTIFY,RGST,EMCO,01/08/2011,00:10:30,7,Myref
DET,01/02/2012,9999999999AB123,A,,MET-234,METERHEADER,META,1,N,Y,N ,N,2,N,Myref,2
DET,01/02/2012,9999999999AB123,A,,MET-
234,METERINSTALL,1,1,BA,ATH1,NHH,F,3/12/2000,3/12/2015,N,N,,123456B,180,,1
DET,01/02/2012,9999999999AB123,A,,MET-234,METERCOMP,1,44455Cv,M,NHH,N,1,1,MOwner,,1
DET,01/02/2012,9999999999AB123,A,,MET-234,METERCHANNEL,1,44455Cv,1,5,UN,24,kWh,X,C,Y
DET,01/02/2012,9999999999AB123,A,,MET-
234,METERINSTALL,2,1,BP,ATH1,NHH,I,3/12/2000,3/12/2015,N,N,,43555554,180,,1
DET,01/02/2012,9999999999AB123,A,,MET-234,METERCOMP,2,435545,M,NHH,N,1,1,MOwner,,1
DET,01/02/2012,9999999999AB123,A,,MET-234,METERCHANNEL,2,435545,1,5,UN,24,kWh,X,C,Y
317
Version 22.24
Sub-process: NP-040 Re-send switching messages
Code references:
Dependencies: NP-020
Description:
Participants will be able to request that the registry re-sends all the switch messages that were
delivered to them during a period of time.
Note that Distributors and Metering Equipment Providers are only able to receive MN, CS and RR
switch messages.
1. The registry must be able to send participants their switching protocol messages again when
requested.
2. Participants must be able to request that all messages be re-sent for a specific period.
3. Participants must be able to select that, only messages of a specific type, eg NT or AW, for a
specific period be re-sent to them.
4. The registry must re-send all the requested messages immediately in a single file.
Processing:
Data inputs:
Start date.
End date.
Switching message type.

Example:
HDR,RQRSSWFLS,CTCT,RGST,27/12/2001,11:13:12,1,All notifications for April
DET,01/04/2007,30/04/2007
Data outputs:
File of requested switching messages.
318
Version 22.24
Sub-process: NP-050 Re-send notifications
Participants: Distributors, Traders, Metering Equipment Providers
Code references:
Dependencies: NP-030
Description:
A Trader, Distributor or Metering Equipment Providers can request that the registry re-sends all the
notifications that were delivered to them during a period of time.
1. The registry must be able to re-send to participants their notifications when requested by that
participant. They must be able to re-send standard and/or metering notifications.
2. Only Traders, Metering Equipment Providers and Distributors must be able to request their
notifications be re-sent.
3. Users must be able to specify the period for which notifications are re-sent.
4. The registry must deliver all the notifications immediately in a single file (however, standard
notifications must remain separate from Metering notifications).
Processing:
Data inputs:
Start date.
End date.
Example:
HDR,RQRSNOTIFY,CTCT,RGST,27/12/2001,11:13:12,1,All NOT notifications for April
DET,01/04/2007,30/04/2007
HDR,RQMTNOTIFY,CTCT,RGST,27/12/2001,11:13:12,1,All NMR notifications for April

DET,01/04/2007,30/04/2007
Data outputs:
A file containing the requested notifications. This includes the standard notifications and the
Metering event notifications
319
Version 22.24
Sub-process: NP-060 Alert Participants
Participants: Distributors, Traders, Metering Equipment Providers, Authority
Code references:
Dependencies: MP-020, SD-050
Description:
The system will alert participants daily when the following situations occur:
1. The responsible Trader, Distributor and MEP will be notified if any of their meter’s certification is
within 2 months of expiry.
2. The responsible Trader and Distributor will be notified where:
 an ICP has no Trader applicable for the Event Date matching the Initial Electrically
Connected Date, or within one day either side of it , and
 there is no Initial Electrically Connected Date but the ICP Status is Active. This condition
only applies to ICPs that have creation dates after the transition date to the new Code (29
August 2013).
3. The system will alert the Authority when a Meter Event, with a Metering Installation Certification
Type of Interim, is added to the Registry and the event date of the meter event is after the
Metering Installation Certification Type code effective end date.
Notices will be delivered daily overnight in a single report and optionally an email alerts will be sent
to the email addresses held in the participants Metering Alerts email group (see SD-050).
For all alert types the Authority requires a report (no emails) as at the last day of each month, not
daily.
Requirements:
1. The Registry must send responsible participants of an ICP an alert overnight when a meter on
the most recent metering event is within 2 months of its expiry date and beyond and the ICP
Status is Active. An alert will continue to be reported until the expiry date is updated to fall
outside the scope of the report.
2. The Registry must send the responsible Trader and Distributor as well as the Authority alerts for
each of the following conditions:
 Where an ICP has no Trader applicable for the Event Date matching the Initial Electrically
Connected Date, or within one day either side of it, and
 where there is no Initial Electrically Connected Date but the ICP Status is Active. This
condition only applies to ICPs that have creation dates after the transition date to the new
Code.
320
Version 22.24
N.B. Where there is no Trader, the responsible Trader for the notice delivery is the
Proposed Trader on the Network Event applicable at the Initial Electrically Connected Date.
If there is no Proposed Trader no alert is sent to any responsible Trader but it will/may
appear in the report to the Authority.
3. The Registry must deliver to the Authority alerts for the following condition:
 Where a metering event has been added with a Metering Installation Certification Type
value of Interim with an event date after the Certification Type interim effective end
date.
4. The Registry must deliver the alerts overnight in a single file to participants each day but only
once a month, as at the last day of each month, to the Authority. An Alert for the same ICP and
situation sent to participants must be reported to the Authority as a single alert. Where an alert
for the same ICP and situation has been sent multiple times the most recent alert only must be
sent.
5. The Authority does not require email alerts but when requested by the participant an email
notice must be sent to the email addresses held in the participants Metering Alerts email group
(see SD-050).
Processing:
1. Determines who the participants are that are affected by the alert.
2. Formats the appropriate alert, calculates the number of days (due or overdue) and delivers it to
each affected responsible participant.
Data inputs:
Metering Events
Network Events
Status Events
Trader Events
Data outputs:
A file containing the requested alerts identifying the ICP.
An optional email with alerts attached. The email body lists the alert filenames.
Example (monthly alert file to the Authority):

HDR,RSPALERTM,RGST,EMCO,01/05/2016,00:10:16,00000005,Monthly Participant Alerts
DET,0000000100AA7D1,C,1,1,BA,ATH1,NHH,F,01/03/2009,05/10/2012,N,N,,123456B,180,,-86
DET,0000000107AAA1B,T,01/01/2016,05/04/2016,05/01/2016,NETC,NETC001,GN,N,L,RETB,05/01/2016,2,0
,60
DET,0000000108AA5C5,E,02/04/2016,02/04/2016,05/01/2016,NETB,NETB001,GN,N,L,RETC,,2,RETC,0
DET,0000000101AAB94,I,02/04/2016,08/04/2016,METB
DET,0000000214AAF75,I,25/04/2016,28/04/2016,METC
For certification alerts:
321
Version 22.24
Attributes Format Mandatory/ Comments

optional
Record Type Char 1 M ‘DET’

ICP Char 15 M
Alert Type Char 1 M ‘C’ for certification alerts.
Metering Installation Number Numeric 3 M Sequential number identifying the installation within
the ICP. Must be unique within the ICP.
Highest Metering Category Numeric 1 M 1 to 5 and 9.
Metering Installation Location Char 50 M A valid code from a list stored in the registry static
Code reference tables.
ATH Participant Identifier Char 4 M/O A valid Participant Identifier of the ATH. Mandatory if
the Metering Installation Certification Type is ‘F’.
Metering Installation Type Char 3 M ‘HHR’ or ‘NHH’ or ‘NON’.
Certification Type
Flag
Certification Variations Char 1 M ‘X’ - An exemption under the Act for the metering
‘A’ - The alternate measuring transformer
certification process is used; or
‘N’ – None.
Date
Type is ‘F’.
Maximum Interrogation Cycle Numeric 3 M In days.
Number of days until Numeric 5 M Calculated. Number of days between the Metering
certification expiry Installation Certification Expiry Date and report run
date. Positive value if the installation has yet to
expire otherwise a negative value.
For alerts where there is no Trader at the Initial Electrically Connected Date:

optional

ICP Char 15 M
Alert Type Char 1 M ‘T’ for no Trader electrically connected alert.
322
Version 22.24

optional
Event Date DD/MM/YYYY M Event Date of the Network Event in which the latest
Initial Electrically Connected Date was first input.
Input Date DD/MM/YYYY M Input date of the event from which the Event Date
above was obtained.
Network Participant Char 4 M As at the Event Date.
Identifier
POC Char 7 M As at the Event Date.
Reconciliation Type Char 2 M As at the Event Date.
Dedicated NSP Char 1 M As at the Event Date.
Installation Type Char 1 M As at the Event Date.
Proposed Trader Char 4 O As at the Event Date.
Initial Electrically Connected DD/MM/YYYY M As at the Event Date.

Date
Current ICP Status Char 3 M From the Status event applicable at the date the
report was run.
ICP Status on Initial Char 3 M From the Status event applicable at the Initial
Electrically Connected Date Electrically Connected Date.
Overdue Days Numeric 5 M Calculated. Number of business days between Initial

Electrically Connected Date and date the report was
run. Where there is no Initial Electrically Connected
Date set to 99999.
For alerts where the Initial Electrically Connected Date is missing but the
status is active:

optional

ICP Char 15 M
Alert Type Char 1 M ‘E’ for no initial electrically connected date alert.
Event Date DD/MM/YYYY M The Event Date of the Event which triggered the
alert.
above was obtained.
Network Participant Char 4 M As at the Event Date.
Identifier
323
Version 22.24

optional
POC Char 7 M As at the Event Date.
Reconciliation Type Char 2 M As at the Event Date.
Dedicated NSP Char 1 M As at the Event Date.
Installation Type Char 1 M As at the Event Date.
Proposed Trader Char 4 O As at the Event Date.
Initial Electrically Connected DD/MM/YYYY M As at the Event Date.

Date
Current ICP Status Char 3 M From the Status event applicable at the date the
report was run.
Trader Char 4 O From the Trader event applicable at Event Date.
Overdue Days Numeric 5 M Calculated. Number of business days between the

first Status event with an active status and date the
report was run.
For alerts where the Metering Installation Certification Type is Interim

optional

ICP Char 15 M
Alert Type Char 1 M ‘I’ for Interim certification type
Event Date DD/MM/YYYY M The Event Date of the Event which triggered the
alert.
above was obtained.
MEP Participant Identifier Char 4 M As at the Event Date.
324
Version 22.24
Sub-process: NP-070 Web Service notify of event change
Participants: Distributors, Traders, Metering Equipment Providers
Code references: Clause 11.29 of the code

RM-020, RM-030, RM-040, NP-020, RS-050, MM-010, MM-020, MM-
030
Description:
This function is concerned with provision of a web service to allow participants to download ICP
notifications.
A participant polls the Registry requesting either unsent notifications are sent, or that previously
sent notifications are resent.
The Registry will respond with either:
a) A batch of notifications; or
b) An “all notifications sent” response.
A participant continues to poll the Registry requesting notifications are sent until an all notifications
sent response is received.
Requirements:
1. A participant calling the web service must:
a) Fulfil a role that allows access to the web service; that is has a role of Trader,
Distributor or MEP; and
b) Have authorisation to use the Web Service from the Registry Administrator
2. A participant call the web service must provide a valid logon and password
3. A participant must be able to request notifications for a Notification Date. The Notification Date
may be and date on which notifications have been generated by the Registry.
4. If a null of invalid Notification Date is provided the Registry must default the Notification Date to
the date notifications were last generated
5. The Registry must send notifications starting from the provided *Resumption Point that were
created on the Notification Date.
6. If an invalid, null or 0 (zero) Resumption Point is provided the Registry must send notifications
starting from the first notification created on the Notification Date.
7. The Registry must return a response with a batch of notifications (if any), Notification Date and
Resumption Point.
325
Version 22.24
8. If all notifications have been delivered, or there are no notifications for the Notification date and
Resumption Point the Registry must return a Resumption Point of 0 (zero) and a message
stating “All notifications have been delivered”.
9. Each notification must contain a single event occurring on the Notification Date for an ICP.
Multiple events with the same event date are reported as separate notification outputs. Note:
this differs from NP-030 batch file output where events for an ICP occurring on the same
event date are combined into a single output line.
10. The Registry Administrator must have the ability to vary the maximum number of notified
returned in a batch.
11. A participant may continue to request notifications, providing the Notification Date and
Resumption Point from the previous response until the Registry stats that all notifications have
been delivered.
12. A participant must not send duplicate requests; that’s is ‘x” requests for the same Notification
Date and Resumption Point within “y” minutes. If duplicate requests are sent the Registry must:
a) Alert the Registry Administrator via email to email group NotificationAPI; and
b) Deactivate participant access to the web service
13. The “x” and “y” settings must be maintained by the Registry Administrator.
14. The Registry Administrator may deactivate access to the web service.
Data inputs:
 Logon user ID and password
 Notification Date
 Resumption Point
Processing:
326
Version 22.24
System:
1. Validates participant has provided a valid logon user ID and password
2. Validates participant is permitted to access the web service based on their role. If invalid returns
a response message:
a) “No access to this Registry Web Service. Please contact the Registry Administrator”
3. Validates participant access to the web service. If deactivated returns a response message:
a) “Access to this Registry Web Service is deactivated. Please contact the Registry
Administrator”.
4. Validates if participant has exceeded maximum duplicate requests (“x” in “y” period). If
exceeded the Registry:
a) Deactivates access to the web service
b) Returns a response message:
i. “Multiple requests for the same input parameters received. Please contact the
Registry Administrator”
c) Raises an alert email to the NotificationAPI email group.
5. Creates a response including:
a) Collection of Metering and non-metering notifications, the number returned not
exceeding the maximum number of notifies returned in a batch (note web service is
XML format and allows metering and non-metering information to be provided in the
same response).
b) Notification Date
c) Resumption Point, 0 (zero) if all notifications have been sent
d) Response message. If all notifications for a Notification Date have been sent the
message must state “All notifications have been delivered”; otherwise null.
Data outputs:
Web service response including:
 Notification Date
 Resumption Point
 Message
 Collection of Notifications
The (standard) notification output must contain the following information
Name Format Mandatory / Comments

optional
Notification type Char 1 M R (event reversal), A (change of data)
327
Version 22.24
Switch status Char 1 O S if ICP is currently undergoing a Trader

switch; otherwise
M if ICP is currently undergoing an MEP
switch; otherwise
B if ICP is undergoing both a Trader and

MEP switch; otherwise
Blank
Notification information as per NP-030; that is one of Network, Address, Trader, Status, Pricing or
Metering
328
Version 22.24
3.8 Online queries

Sub-process: QU-010 Search to find an ICP identifier
Process: Make query online
Participants: All users
Dependencies:
Description:
A user may wish to find an ICP identifier by using its Address or Metering Component Serial
Number with, optionally, a Metering Component Type to find it and check its details.
Users may particularly want to use this facility when an ICP identifier is being switched in order to
verify that the correct ICP identifier is being switched.
N.B. In order that the address search produces consistent results, Distributors are provided with
Address completion standards. These are provided in Appendix 2 for reference.
329
Version 22.24
1. Users must be able to search for an ICP identifier using address or metering attributes as
search criteria. When more than one ICP identifier matches the search criteria, all the matching
ICP identifiers must be presented to the user and the user must be able to select the required
ICP identifier from the list.
2. The minimum information required for searching must be either Physical Address Property
Name or Physical Address Street or Metering Component Serial Number.
3. A wildcard search facility must be provided unless an exact match is required.

4. It must be possible to search for an exact match on the Physical Address Street, or if a Street
has not been provided on the ICP address record, by the Address Property Name. Exact match
requires the full name including “Road”, “Street” etc.
5. It must be possible to search for multiple words or words that include a hyphen e.g. Great King
or Raymond-Blanc, when searching on Physical Address Property Name or the Physical
Address Street.
6. It must be possible to restrict the list of ICP identifiers to only those that are currently the
responsibility of the user’s company.
7. It must be possible to restrict the list of ICP identifiers to only those that have been
commissioned i.e. are in the ‘active’ or ‘inactive’ state.
8. When searching for ICP identifiers whose ICP metering information contains a specific
Metering Component Serial Number, an additional filter on Meter Component Type must be
available.
9. The search facility must be available online and via web services
Data inputs:
Search criteria on the following attributes:
 Physical Address Unit.
 Physical Address Number.
 Physical Address Street.

 Physical Address Property Name.
 Physical Address Suburb.
 Physical Address Town.

 Physical Address Region.
 Metering Component Serial Number.
 Metering Component Type.

Additional search criteria filters:
 Exact match only.
 Own ICPs only.
330
Version 22.24
1. Only Commissioned.
Processing:
System
 Finds and displays all the ICP identifiers that meet the search criteria, current responsible
Participants (Network, Trader and MEP), Status, first Metering Component Serial Number and
GPS co-ordinates. The last 2 attributes are not displayed when performing search on Metering
Component Serial Number
 Allows the user to select an individual address.
Data outputs:
 List of ICP Identifiers associated with the search criteria.
331
Version 22.24
Sub-process: QU-020 View ICP information
Dependencies: QU-010
Description:
A user can view all the information about an ICP that includes its current attributes, history of
changes, notifications delivered and audit details. The only exception to this is the channel reading
value provided in CS and RR switch messages. This information is only viewable by users of the
responsible participants at the Event Date of the switch.
1. All approved users must be able to view all attributes of an ICP. However, the channel reading
values provided in the CS and RR switch messages must only be available to the participants
responsible for the ICP on the Event Date.
2. The details of the ICP must be displayed ‘as at’ a particular date including whether the ICP is
the subject of any switch. All attributes that were applicable on the ‘as at’ day must be shown.
3. The user must be able to view the history of the ICP (i.e. all the events associated with an ICP)
and all switch messages.
4. The user must be able to drill down from events to see the full details of the event, details of
changes made, the notifications delivered and the audit details.
5. The user must be able to view and download a CSV version of events and switch transactions.
6. The user must be able to view a map of the location of the ICP using its stored GPS co-
ordinates.
7. The user must be able to view reconciliation information including periods of responsibility of
participants and NSP trading periods.
8. All screen layouts and contents must be agreed with the Authority, and must not be changed
without the Authority’s consent.
Data Inputs:
 ICP Identifier.
 ‘As at’ date – defaulted to today’s date.
 ICP history filters – event/switch type, with or without changes.

 Map display option.
 CSV file download option
332
Version 22.24
Processing:
For the ICP identified, the system:

Finds and displays the attributes, derived attributes (summary data), historical information,
notifications, reconciliation information and audit details of the ICP that were applicable on the “As
at’ date.
Data outputs:
Summary Data:
The following attributes and derived attributes are displayed:
ICP Identifier
‘As at’ Date

ICP switch status derived attributes:
 Trader Switch
 MEP Switch
Status Event attributes
 Event Date
 ICP Status
 Status Reason
Address Event 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
Network Event attributes

 Event Date
 Network participant Identifier
 POC
333
Version 22.24
 Dedicated NSP
 Unmetered Load Details – Distributor
 Shared ICP List

 Direct Billed Status
Pricing Event attributes
 Event Date
 Distributor Price category Code
 Chargeable Capacity
 Distributor Installation Details

 Distributor Loss Category Code
Trader Event attributes:
 Event Date
 Participant Identifier of Trader
 Proposed MEP
 Profile
 Unmetered Load Details for Trader
 ANZSIC
 Submission Type HHR

 Submission Type NHH
Metering Event attributes:
 Event Date
 MEP Participant Identifier
 HHR Flag
 NHH Flag
 PP Flag
 Meter Multiplier Flag
 Highest Metering Category

 Meter Channel Count
Metering Event derived attributes:
 C&I TOU
334
Version 22.24
 AMI Comm
 AMI Non Comm

 Serial Numbers
ICP History and Audit Details:
Shows all events and switch transactions for a selected ICP. The information displayed for each is:
 Event Type
 Effective Date
 Input Date
 Input Time
 Audit Reference
 Input By Participant Identifier

 User’s Participant Identifier
 Mode of input (screen or file)
 State of event (Active, Reversed or Replaced)

For reversed or replaced events the following extra information is shown:
 Reversal or Replacement date and time
 Audit reference
 Participant
 Input By Participant Identifier
 User’s Participant Identifier

 Mode of input (screen or file)
View Details:
Shows a selected event or switch transaction’s details either on screen or in CSV format - see ICP
event maintenance and switching (sections 3.1 to 3.4) for formats. All CSV formatted details are
downloadable.
Notifications:
Shows a selected event or switch transaction’s notifications that were delivered, detailing:
 Notification Type
 Operation Type (input/reversal/replacement)

 Filename
 Date and time submitted
Reconciliation information:
335
Version 22.24
Shows the periods of responsibility of reconciliation participant s of an ICP, identifying, per change
of Trader, Network, POC Installation Type and Submission Type where the Status was ‘active’ with
an Installation Types of 'Load' or 'Both':
 Start Date
 End Date
 Trader Participant Identifier
 Network Participant Identifier
 POC
 Status
 Meter Type(s)
Shows an ICP’s NSP trading periods, identifying per change of Trader, NSP, Installation Type,
Reconciliation Type and Profile:
 Start Date
 End Date
 Trader Participant Identifier

 POC
 Status
 Profiles
336
Version 22.24
Sub-process: QU-030 View static table information
Dependencies: SD-010 to SD-040
Description:
A participant may request access to the registry. If the participant is granted access, the participant
can view the static data tables online and download them, particularly the NSP mapping table,
pricing categories and loss categories.
1. Users require online and download facilities of all static table information.
2. For pricing categories and loss categories, the download should be selectable by Network
Participant Identifier.
Processing:
Data inputs:
 Static table files.
Data outputs:
 Same format as input.
337
Version 22.24
Sub-process: QU-040 View Registry Audit Data
Process: Online Queries
Participants: Registry Manager, Authority, Participants
Dependencies: None
Criticality Non core
Description:
A search and inquiry screen to allow a participant to view and download their own audit records.
The Authority may view audit records for any Participant.
The audit information relates to the following types of activity:
Data Change
 Changes to pricing codes
 Changes to Loss Factor Codes, Price Category Codes, NSP Mapping and Static Data.
User Event
 User logon, logoff events, and logon access denied
Supervisor Event
 Supervisor modification to notification parameters
 Supervisor modification to switch notification parameters
 Supervisor modification to EIEP notification parameters
 Supervisor modification to email contact addresses
EIEP Event
 EIEP transfer receipts, deliveries, acknowledgements and notifications.
Administrator Event
 Administrator modifications to Non Contiguous NSP Mapping information
 Administrator modifications to Participant definitions
 Changes to email contact addresses on behalf of Participants
1. A participant must only be able to view the audit information that relates to their own activity on
the Registry.
2. The Authority and the administrator must be able to view audit information for any Participant.
338
Version 22.24
Data inputs:
A participant may perform an audit search using the criteria below.
 Audit Type, Audit Activity, Audit Category

 Participant and User
 Date Range or most recent audits
Processing:
1. System displays the audit records that match the selection criteria entered.
Data outputs:
Audit records which satisfy the selection criteria

Download file in csv format
Audit Type Details

User Event  Licenses available
 Licences used
Data Change Loss Factor Code:
 Code
 Description
 Start Date
 End Date
 Network
 Consumption
 Generation
 Start Period
 End Period
NSP Mapping
 Owner
 Network
 POC
 Balance Area
 Network Type
 Parent Network
 Parent POC
 Start Date
 End Date
 Active
 Description
 Start Period
339
Version 22.24
Audit Type Details

 End Period
 SB ICP’s
Price Category Code

 Code
 Description
 Start Date
 End Date
 Network
Static Data
 Code Type
 Code
 Description
 Start Date
 End Date
EIEP Event  Sender
 Recipient
 Utility
 File Type
 Report Month
 Report Date
 Unique ID
 File Name
 Delivered As
 File Size
 Arrival Time
 Error code
Supervisor Event EIEP Parameters
 Acknowledge receipt to sender by email
 Acknowledge receipt to sender’s inbox
 Confirm successful transfer to sender by email
 Confirm successful transfer to sender’s inbox
 Notify receipt file transfer by email
 EIEP email contact address list
Switch Notifications
 Send at 08:00
 Send at 11:00
 Send at 15:00
 Send at 18:00
 Send immediately
 Use separate files
Email contact address (excluding EIEP)
340
Version 22.24
Audit Type Details

 Email address group
 Email contact address list
Administrator Event Administrator Maintenance
 Participant Code
 Description
 Industry Company
 Participant Disabled Indicator Start Date
 Stop Date
 Network Indicator
 Reconciliation Manager Indicator
 Trader Indicator
 Clearing Manager indicator
 Market Surveyor Indicator
 System Operator Indicator
 Complaints Commission Indicator
 Metering Equipment Provider Indicator
 Suppress Trader EOM List Report indicator
 Non-Reconciled Indicator
 FTP Directory Name
 Zip Files Indicator
 Email contact address list
NSP Mapping Non Contiguous Dates

 NSP Network
 NSP POC
 NSP Network
 Network Type
341
Version 22.24
3.9 Maintaining static data

Sub-process: SD-010 Maintain NSP data
Process: Maintain static data
Participants: Reconciliation Manager, participants
Code references: Clauses 24 to 30 of Schedule 11.1 of the Code.
Dependencies:
Description:
The Reconciliation Manager maintains the NSP information stored in the registry. The registry uses
the information to validate the NSP identifier recorded as being connected to an ICP and to
determine the Distributor on whose network the NSP is located.
1. Entries in the NSP table must have the following information:

 owner** – Char 4 (Distributor code);
 registry POC ** – Char 7;
 registry Network Participant Identifier** – Char 4;

 registry NSP description – Char 32;
 network type** – Char 1 (G—grid, E—embedded, I—interconnection point);
 network connection status – Char 1 (active = Y or inactive = N);

 parent POC – Char 7 (blank if grid connected);
 parent network – Char 4 (blank if grid connected);
 balancing area** – Char 12;

 start date** – date (DD/MM/YYYY);
 start trading period** – Char 2;
 end date – date (DD/MM/YYYY or blank);

 end trading period – Char 2; and
 ICP Identifier of SB ICP – Char 15.

2. **Each entry in the NSP table must be unique within the registry for the fields above shown
marked with asterisks.
3. The Reconciliation Manager must be able to insert, delete and expire NSP information (ie input
and end date and end trading period); must be able to do this online and in batch mode; and
must be the only service provider able to do it.
4. The system must record audit information of changes.
342
Version 22.24
5. An online facility must be provided for all users to view the NSP information, sorted by registry
POC, registry network and start date.
6. The information held in the NSP table must be available for all users to download.
7. Registry must maintain an audit trail for each insert/update/deletion to record who made the
change and when.
8. The information must be able to be requested via ftp by any participant.
9. The validation for an NSP may be lifted on request of the Authority to allow non-contiguous
dates on the same NSP.
Non Contiguous Date Relaxation
NSP mapping validation does not allow non-contiguous dates however there are specific mappings
that require this validation to be relaxed. To enable the rule relaxation the registry manager, under
instruction from the Authority, will mark specific NSP’s as being allowed to have non-contiguous
active date ranges. The NSP mapping entries will be identified by unique keys advised by the
Authority:
 NSP Owner
 POC
 Network Type
10. On instruction from the Authority, the registry manager will update mapping entries permitted to
exist with non-contiguous dates. Where the Reconciliation Manager submits an NSP Mapping
table update either via FTP or on-line the table of NSP mappings allowed non-contiguous date
ranges will be referenced. If an NSP Mapping with the same unique keys is present in the non-
contiguous table then a non-contiguous date range will be allowed, otherwise the update will be
rejected as per existing rules.
Processing:
Data inputs:
1. Maintenance values for NSP table entries.
Data outputs:
2. Updated NSP table.
343
Version 22.24
Sub-process: SD-020 Maintain static data
Participants: Registry Manager
Code references: Clauses 19 to 22 of Schedule 11.3 of the Code.
Dependencies:
Description:
All the codes and identifiers used in the registry are maintained by the registry manager. The
registry manager receives instructions regarding the maintenance of these codes and identifiers
from the Authority, which approves all new codes and identifiers. The types of codes and identifiers
to be maintained and their purposes are as follows:
 Participant identifiers and the roles of each participant (4 characters) – valid Trader,
Metering Equipment Providers, Approved Test Houses and Distributor Participant
Identifiers, their full company names and their roles.
 Event types (3 characters) – used to validate events.
 Profiles (3 characters) – general list of all Profiles that can be used in the system.
 Profiles available to individual Traders during specific periods.
 Regions (15 characters) – used to validate the regions that can be used in addresses. The
current regions are:
 Auckland;
 Bay of Plenty;
 Canterbury;
 Gisborne;
 Hawke’s Bay;
 Manawatu;
 Marlborough;
 Nelson & Bays;
 Northland;
 Otago;
 Southland;
 Taranaki;
 Timaru & Oamaru;
 Waikato;
 Wairarapa;
 Wanganui;
 Wellington; and
 West Coast.
 Event Status codes (three digits numeric) – used to validate Status events.
 Status Reason codes (two digits numeric) – used to validate the Status Reason in Status
events:
344
Version 22.24
The current reasons associated with a decommissioned Status are:
01—setup in error;
02—installation dismantled; and
03—ICP amalgamation.
The current reasons associated with an inactive Status are:
04— electrically disconnected vacant property;
05—reconciled elsewhere;
06— electrically disconnected ready for decommissioning;
07— electrically disconnected remotely by AMI meter;
08— electrically disconnected at pole fuse;
09— electrically disconnected due to meter disconnected;
10— electrically disconnected at meter box fuse; and
11— electrically disconnected at meter box switch and
12 – New connection in progress

 NT switch types (two characters) – used to validate NT switching protocol messages: S, SM, H,
HM, NH, HN, HH, MI and TR. S, SM, H, HM, NH, HN will be discontinued after migration but
will remain in historical records.
 Additional NT switch types for a Trader Default situation –T<n> (where <n> is A, B, etc for ICPs
allocated during tender 1, 2, etc) and MA (ICPs allocated during mandatory assignment). The
Trader Default switch types must only be used by the Registry Manager during a Trader Default
switching process
 Meter channel, TN/NC and CS/RR register content codes (four characters) – used to validate
metering channel updates, TN, NC, CS and RR switching protocol messages (see below).
 TN/NC and CS/RR register units (five characters) – valid values for TN, NC, CS and RR
messages: kWh, kW, kVA, kVArh.
 TN/NC and CS/RR meter location codes – valid values for use in TN, NC, CS and RR
messages (see below).
 AN response codes and MN advisory codes (two characters) – used to validate AN and MN
switching protocol messages (see below).
 NW withdrawal advisory codes (two characters) – used to validate NW switching protocol
messages (see below).
 AW/AC withdrawal response codes (one character) – used to validate AW and AC switching
protocol messages: A—accept, R—reject.
 Fuel Type codes (char 15) and Description (char 100):
bio-mass - bio-mass (includes wastes and residues);
345
Version 22.24
electric vehicl - electric vehicle (includes fuel cells);

fresh water - fresh water (includes stored, pumped and run of river);
geothermal - geothermal;
industrial proc - industrial process (includes heat, excludes bio-mass);
liquid fuel - liquid fuel (includes diesel, petrol and fuel oil);
natural gas -natural gas;
solar - solar;
tidal - tidal;
wave - wave;
wind - wind;
other - includes any process that doesn’t fit neatly into another category, includes
multiple generators of different fuel types; and
undefined - this code exists only to support the creation of the fuel type field and
cannot be selected by distributors.
 ANZSIC codes with an additional code “000000” to indicate a residential consumer. A table of :
ANZSIC Code (char 7)

Description (char 120)
 Direct Billed Status codes (char 11). A table of ’Retailer’, ‘Distributor’, ’Neither’, ’Both’, ’TBA’ and
NULL.
 Reconciliation Type codes (2 characters). Used to validate the Reconciliation Type in Network
events. For a list of valid codes see the description of this attribute in section 1.4.
 Installation Type codes (1 character). Used to validate the Installation Type in Network events.
For a list of valid codes see the description of this attribute in section 1.4.
 Metering Installation Type codes (3 characters). Used to validate the Metering Installation Type
in the Metering Installation level of Metering events. For a list of valid codes see the description
of this attribute in section 1.4.
 Certification Type codes (1 character). Used to validate the Certification Type in the Metering
Installation level of Metering events. For a list of valid codes see the description of this attribute
in section 1.4.
 Certification Variation codes (1 character). Used to validate the Certification Variations in the
Metering Installation level of Metering events. For a list of valid codes see the description of this
attribute in section 1.4.
 Component Type codes (1 character). Used to validate the Metering Component Type in the
Metering Component level of Metering events. For a list of valid codes see the description of this
attribute in section 1.4.11.
 Trader Default minimum tariff (numeric 6.6). Used during a Trader Default situation. Compared
against the tariff supplied by a Trader tendering for ICPs. An unrealistic tariff could inadvertently
cause a recipient Trader to receive ICP’s that may cause hardship. The minimum tariff is set by
the Authority and is in c/kWh
346
Version 22.24
 Switch Saving Participant register. Used to record traders that have elected to have or cancel
the switch saving protection scheme. Register includes trader name, participant identifier, start
date, and end date.
Trader Default Exclusion Code (3 characters). Describes the reason why a Trader is unable to
accept a mandatory assignment of ICPs.
1. Only the registry manager must be able to add, modify or delete codes.
2. Each code and identifier must have an effective start date and end date associated with it and a
full description.
3. The registry must maintain an audit trail for each insert/update/deletion to record who made the
change and when.
Processing:
Data inputs:
 New or changed information for each table.
Data outputs:
 Updated static data tables.
347
Version 22.24
Current valid codes
AN response codes
Code Description Explanation of use
AA Acknowledge and accept Switch is accepted; there are no relevant issues.
CO Contracted customer Alerts that this customer has a fixed-term contract at the
ICP. The current Trader may be contacting this
customer, relative to a switch.
MP Metering is pre-paid Alerts that meter is pre-paid.
MU Unmetered supply Alerts supply is unmetered.
OC Occupied premises Advises that the existing customer has not yet advised
they are moving out. The premises are occupied.
PD Premises electrically Alerts that this site is electrically disconnected.

disconnected
AD Advanced Metering Alerts that meter is an advanced meter.

Infrastructure metering
infrastructure
NW withdrawal advisory codes

CR Customer requests Customer has changed their mind and wishes to cancel.
cancellation
IN Invalid ICP Status Site is in the process of being decommissioned.
UA Unauthorised switch Account holder did not authorise switch request.
WS Wrong switch type Switch notification received is being withdrawn.
MI Withdrawn on metering issue Gaining Trader requests withdrawal because of

metering issue.
WP Wrong premises The wrong premises have or are being switched (due to
the Trader’s error).
DF Date failed RTD (requested transfer date) greater than 10 business

days in the future.
WR Losing Trader not current Withdrawn, as the losing Trader is not the current
Trader Trader for the ICP. ICP has been switched to another
Trader and the registry has not been updated to reflect
that switch.
348
Version 22.24
MG Temporary withdrawal code Used only during transition to indicate that the switch
was withdrawn due to transition requirements.
CE Customer error Customer cancels the switch because the original

switch request was an error (e.g. customer provides
incorrect information)
CX Customer cancellation Customer cancels the switch for a reason other than
that in CE (e.g. the customer changes their mind)
TD Trader Default Switch withdrawn as Trader is in a Trader Default

situation.
Reserved for system use.
Register Content codes

The register content codes use the standard convention, in the following order:
1. season – e.g. ‘S’ or ‘SR’ (summer), ‘W’ or ‘WR’ (winter)
2. day of week – e.g. WD (weekday), WE (weekend)
3. time of day – e.g. PK (peak), OP (off-peak), SH (shoulder)
4. type of load – e.g. CN (controlled), IN (inclusive, combination of controlled and
uncontrolled load), UN (uncontrolled).
In the below table, where a “Status” cell covers multiple register content code rows, the
register content codes must be used together at the same metering installation
Register Description Status Comments

content
code
AD kVA demand - kVA MDI Approved for use
AH kVAh - cumulative kVA channel Approved for use
CN Controlled - all load on the channel is Grandfathered Use of CN is grandfathered

subject to control by the distributor at for fully controlled at fixed
any time via a load control device. times, night only and night
boost metering installations
(for example CN8 and
CN11) until the next
recertification. All new and
recertified night only and
night boost metering
installations to use NO or
NB (as appropriate)
349
Version 22.24

content
code
D Day – may only be used with N. Approved for use. Day/Night uncontrolled
Daytime of an uncontrolled 2-channel
Grandfathered Use of N on its own is
day/night meter, switched between
where N is used grandfathered for fully
channels at fixed times via an internal
on its own. controlled at fixed times,
time clock or external signal.
night only and night boost
metering installations (for
N Night – may only be used with D. Night- example N8 and N11) until
time of an uncontrolled 2-channel the next recertification. All
day/night meter, switched between new and recertified night
channels at fixed times via an internal only and night boost
time clock or external signal. metering installations to
use NO or NB (as
appropriate).
DC Day Controlled – may only be used with Approved for use Day/Night controlled
NC. Daytime of a 2-channel day/night
meter switched between channels at
fixed times via an internal time clock or
external signal. All metered load is
subject to control at any time via a load
control device, and consumption is
separately recorded for the day and
night periods.
NC Night Controlled – may only be used

with DC. Night-time of a 2-channel
day/night meter switched between
channels at fixed times via an internal
time clock or external signal. All
metered load is subject to control at any
time via a load control device, and
consumption is separately recorded for
the day and night periods.
DIN Day Inclusive – may only be used with Approved for use Day/Night inclusive
NIN. Day time of a 2-channel day/night
meter, switched between channels at
external signal. All metered load on the
channel is a combination of controlled
and uncontrolled loads.
350
Version 22.24

content
code
NIN Night Inclusive – may only be used with

DIN. Night-time of a 2-channel day/night
meter, switched between channels at
external signal. All metered load on the
channel is a combination of controlled
and uncontrolled loads.
DOP Triple Saver Off-Peak (11:00-17:00, Grandfathered Use of this combination is

21:00-23:00) grandfathered for existing
metering installations until
DPK Triple Saver Peak (07:00-11:00, 17:00- the next recertification
21:00)
Use generic codes for all
new or recertified metering
N Night 23:00-07:00
installations
EG Embedded Generation Approved for use
IN Inclusive - load on the channel is a Approved for use

combination of controlled and
uncontrolled loads
INEM Emergency - load on the channel is a Approved for use

combination of load controlled only in
an emergency and uncontrolled load
KD kW demand - kW MDI Approved for use
NB Night Boost - for a single channel Approved for use

meter, where the load is switched on/off
at fixed times during the night period
and a boost period during day via a load
control device
NO Night Only - for a single channel meter, Approved for use

where the load is switched on/off at
fixed times for the night period via a
load control device
OP Off-peak Approved for use
351
Version 22.24

content
code
PK Peak Use PK/OP for 2-channel

peak/off-peak and
SH Shoulder PK/OP/SH for 3- channel
peak/off-peak/shoulder
metering configurations
RH kVArh - reactive meter register Approved for use
SL Metered streetlights. Only applies to Approved for use

NHH meter channels used for
streetlights.
S Summer - records consumption during Approved for use Summer/winter

summer
W Winter - records consumption during

winter
SENW Weekday night (Monday – Friday 21:00 Grandfathered Use of these codes is
- 07:00); and all weekend (Friday 21:00 grandfathered for existing
- Monday 07:00) metering installations until
the next recertification.
SEOP Off-peak (Monday - Friday 11:00 -
17:00; and 19:30 - 21:00)
installations
SEPK Peak (Monday - Friday 07:00 - 11:00;
and 17:00 - 19:30)
SRD Summer Day – Records day Approved for use Summer/winter day/night
consumption during summer
SRN Summer Night – Records night

consumption during summer
WRD Winter Day – Records day consumption

during winter
WRN Winter Night – Records night

consumption during winter
352
Version 22.24

content
code
SWD Summer Weekday - records Approved for use Summer/winter

consumption during summer weekdays weekday/weekends
SWE Summer Weekend - records

consumption during summer weekends
WWD Winter Weekday - records consumption

during winter weekdays
WWE Winter Weekend - records consumption

during winter weekends
SWDD Summer Weekday Day - records day Approved for use Summer/winter
consumption during summer weekdays weekday/weekend
day/night
SWDN Summer Weekday Night - records night
consumption during summer weekdays
SWED Summer Weekend Day - records day

SWEN Summer Weekend Night - records night

WWDD Winter Weekday Day - records day

consumption during winter weekdays
WWDN Winter Weekday Night - records night

consumption during winter weekdays
WWED Winter Weekend Day - records day

consumption during winter weekends
WWEN Winter Weekend Night - records night

consumption during winter weekends
SWDPK Standard 3 Rate Summer Weekday Grandfathered Use of this combination of

Peak (07:00-11:00, 17:00-21:00) codes is grandfathered for
353
Version 22.24

content
code
WDOP Standard 3 Rate Weekday Off-peak existing metering

(11:00-17:00, 21:00-23:00) & Weekend installations until the ICPs
Off-peak (07:00-23:00) are moved from the closed
price category to a different
WWDPK Standard 3 Rate Winter Weekday Peak price category or the
(07:00-11:00, 17:00-21:00) combination is no longer
required.
N Night 23:00-07:00
UN Uncontrolled - no load on the channel is Approved for use

subject to control via a load control
device
WD Weekday - records consumption during Approved for use Weekday/weekend

weekdays
WE Weekend - records consumption during

weekends
WDD Weekday Day (Mon-Fri). Must be used Approved for use Weekday/weekend day
with WED and may be used with other
May be used with other
register content codes for the night
codes for night periods.
period.
Records day consumption during

weekdays. Non-seasonal equivalents of
SWDD and WWDD (Summer and
Winter weekday daytime).
WED Weekend Day. Must be used with WDD

and may be used with other register
content codes for the night period.
Records day consumption during

weekends. Non-seasonal equivalents of
SWED and WWED (Summer and
Winter weekend daytime).
354
Version 22.24

content
code
OPKOOB Weekdays 11:00 - 17:00, 21:00 - 7:00 & Grandfathered Use of these codes is
Weekend 24 Hours. Must be used with grandfathered for existing
PKOOB. metering installations until
the next recertification.

installations.
PKOOB Weekdays 07:00 - 11:00 & 17:00 -

21:00. Must be used with OPKOOB.
OPKOOC Any day 22:00 - 07:00. Must be used Grandfathered Use of these codes is
with PKOOC and SPKOOC. grandfathered for existing
metering installations until
PKOOC Weekdays 07:00 - 09:30 & 17:30 - the next recertification.
20:00. Must be used with OPKOOC and
SPKOOC.
installations.
SPKOOC Weekdays 09:30 - 17:30, 20:00 - 22:00
& weekend 07:00 - 22:00. Must be used
with OPKOOC and PKOOC.
7302 30 minute recorded channel kVAh Approved for use
7304 30 minute recorded channel kWh Approved for use
7306 30 minute recorded channel kVArh Approved for use
7052 5 minute recorded channel kVAh Approved for use
7054 5 minute recorded channel kWh Approved for use
7056 5 minute recorded channel kVArh Approved for use
Discontinued register content codes
DWD Day of week days (7:00am-9:00pm) Discontinued
NWD Night of week days (9:00pm-7:00am) Discontinued
355
Version 22.24

content
code
OPKOOA Any Day 22:00 - 06:00, part of a three Discontinued

register tariff. Must be used with
PKOOA and SPKOOA. Period of
availability must be 8 hours
PKOOA Weekdays 07:30 - 09:30 & 17:30 - Discontinued

19:30, part of a three register tariff.
Must be used with OPKOOA and
SPKOOA. Period of availability must be
4 hours
SPKOOA Weekdays 06:00 - 07:30, 09:30 - 17:30, Discontinued

19:30 - 22:00 & Weekend 06:00 - 22:00,
part of a three register tariff. Must be
used with OPKOOA and PKOOA.
Period of availability must be 12 hours
OPKOOD Any Day 23:00 - 07:00, part of a three Discontinued

register tariff:
 must be used with either:

− PKOOD and SPKOOD; or
− PKOOE and SPKOOE
period of availability must be 8 hours.
PKOOD Any day 07:00 - 09:30 & 17:30 - 20:00, Discontinued

part of a three register tariff:
 must be used with OPKOOD and

SPKOOD
SPKOOD Any day 09:30 - 17:30, 20:00 - 23:00, Discontinued


PKOOD
356
Version 22.24

content
code
OPKOOD Any Day 23:00 - 07:00, part of a three Discontinued

register tariff:
 must be used with PKOOE and

SPKOOE
PKOOE Any day 07:00 - 10:00 & 16:00 - 21:00, Discontinued


SPKOOE
SPKOOE Any day 10:00 - 16:00, 21:00 - 23:00, Discontinued


PKOOE
Meter Location Codes

Code Description Code Description Code Description
0 No ML code DR DRIVEWAY SIDE GW GARAGE WALL
BA BASEMENT DS DEER SHED IB INSIDE BACK DOOR
BD BACK DOOR FB UNDER FRONT BALCO IC INSIDE IN CUPBOARD
BG BACK OF GARAGE FC FW OF GARAGE ID IN DINING ROOM
BO BOILER ROOM FD FRONT DOOR IF INSIDE FRONT DOOR
BP BACK PORCH FF FIRST FLOOR IG INSIDE GARAGE
BR IN BEDROOM FG FRONT GATE IH INSIDE HALL
BS BACK OF SHED FO FOYER IK INSIDE KITCHEN
BW BACK WALL FP FRONT PORCH IL INSIDE LIVING ROOM
CM CENTRAL MTR FS IMPLMENT SHED IM IN MONTROSE BOX
CP CAR PORT FW FRONT WALL IN INSIDE
CS DAIRY SHED GF GROUND FLOOR INP IN PORCH
CT CELL TOWER GH GLASS HOUSE IO INSIDE OFFICE
DE INST DISCON@ POLE GO GO TO OFFICE IP IN PUMP SHED
357
Version 22.24
Code Description Code Description Code Description
IR INSIDE REAR MX METER ROOM RP RIGHT PORCH
IS INSIDE STORE NM NOT METERED RS REAR SHED
ISD IN SHED OC OUTSIDE CUPBOARD RT READ THRU WINDOW
IT IN TRANSFORMER OF ON FENCE RU ON REAR UNIT
IW IN WORKSHOP OH ON HOUSE RW RIGHT WALL
LA LAUNDRY OM ON MONTROSE BOX SA SAME
LB LEFT BACK OMB ON MAIN SW/BOARD SB STABLE
LF LEFT ON FRONT OP ON PUMP SHED SH SHED
LG LH ON GARAGE PB POLE BOX SQ SHEARERS QUARTERS
LP LEFT PORCH PD PUMP IN OLD DAIRY SR IN SWITCH ROOM
LR IN LUNCH ROOM PF PLYNTH ON FENCE SS WOOL SHED
LS LEFT SHED PL IN PLYNTH ST SUB STATION
LW LEFT WALL PM PUMP TR TRANSFORMER RM
MC IN CUBICLE PS PACKSHED TS IN TEMP SUP BOX
ME MAIN ENTRANCE RB RIGHT BACK UP UPSTAIRS
ML MULTIPLE LOCATION RF RH ON FRONT US UNDER STAIRWAY
MM MOTOR ROOM RG RH ON GARAGE UT UNDER TREE
MR UP RIGHT OF WAY RM REMOTE METER WH WHISPER CABINET
MT IN MEN’S TOILET RO REAR OF OFFICE WS WORKSHOP
358
Version 22.24
Trader Default Exclusion Codes
DIA Distributor Agreement There is no arrangement in place with the

Distributor to trade on that NSP, Trader
only offers spot price
FV Financial Viability Obtaining responsibility for ICP’s may

pose a serious threat to financial viability
MTR Meter Types The Trader is unable to trade against the

Meter Type
PC Price Category Codes The Trader is unable to trade against the

Distributor Price Code category
MC Meter Category The Trader is unable to trade against the

Meter Category
INT Installation Type The Trader is unable to trade against this

installation Type
OTH Other Used where other codes do not cover a

specific situation where a Trader cannot
gain ICP’s
EIEP File Type Codes
EIEP1 Detailed ICP billing and volume This protocol allows:

information
a) traders to provide billing and
volume information to distributors at an
ICP level to enable distributors to invoice
fixed and variable network charges, and
provide information to the extended
reserve manager.
b) distributors to provide information to

traders to support their invoices for
network charges, and to enable traders to
reconcile the network charges at detailed
level.
359
Version 22.24
Sub-process: SD-030 Maintain Distributor Loss Category Codes
Code references: Clause 22 of Schedule 11.1 of the Code.
Dependencies:
Description:
Each Distributor must update their own loss factor codes for Distributor Loss Category Codes entered
on the table in the registry.
‘Distributors’ include local network owners, embedded network owners and grid-connected generators.
1. Only Distributors must be able to maintain Loss Category codes and only in respect of codes that
they own.
2. It should be possible to update codes both online and in batch mode.
3. A Loss Category Code must have no more than two loss factors in a calendar month. This means
that loss factors must apply to the whole month (there can be no changes to the loss factors
partway through a month), but there can be two records applicable to the month for different sets
of trading periods, ie day and night.
4. Each Loss Category Code must be associated with a date range, consisting of one or more
complete calendar months, during which its loss factor applies.
5. There must be only one Loss Category Code associated with any date range, and date ranges
must not overlap.
6. The combination of Distributor code, Loss category Code, start date and start period must be
unique.
7. Only Loss Category Code information relating to a future date range may be modified.
8. Each Loss Category Code must cover a range of trading periods so that every trading period has a
single applicable loss factor. (For example, there could be different factors applied to day and
night.)
9. Each participant must be able to view and download the complete Loss Category Code table on
the registry online.
10. The table entry relating to a Loss Category Code may only be deleted if it has never been used
against an ICP.
change and when.
360
Version 22.24
NB: It must be noted that a trading period of 48 indicates the end of day. Users are to make their
own appropriate adjustments for Daylight Saving.
Example of Loss Factor Code changes over time showing how the Start Period and End Period is to
be applied:
Network Loss Loss factor Loss Start date End date Start End
Categoryc consump- factor period period
ode tion genera-
tion
NELS N5 1.0490 1.0000 01/04/04 1 48
NELS N6 1.0300 1.0000 01/04/04 31/05/05 1 48
NELS N6 1.0300 1.0000 01/06/05 1 48
ORON WGL 1.0470 .9530 01/10/03 31/03/04 1 15
ORON WGL 1.0520 1.0000 01/10/03 31/03/04 16 48
ORON WGL 1.0550 1.0000 01/04/04 30/09/04 1 15
ORON WGL 1.0610 1.0000 01/04/04 30/09/04 16 48
ORON WGL 1.0470 1.0000 01/10/04 1 15
ORON WGL 1.0520 1.0000 01/10/04 16 48
Processing:
System
Validates all attributes and checks any dependencies.

Updates the Loss Category Code table in the registry accordingly.
Generates notifications to all Traders who are responsible for ICPs that have been assigned the
affected loss factor code.
Data inputs:

New or modified loss category code information.

optional
361
Version 22.24

optional
Network Participant Identifier Char 4 M Valid Participant Identifier for

Distributor.
Distributor Loss Category Char 7 M

Code
Loss factor consumption Numeric 1.4 M May be modified only if the start
date is in the future.
Loss factor generation Numeric 1.4 O May be modified only if the start
date is in the future.
Start date DD/MM/YYYY M May be modified only if in the

future.
End date DD/MM/YYYY O If missing, denotes that loss factors

are valid until further notice. May
only be modified when missing or in
the future, and cannot be changed
to a date in the past.
Start period Numeric 2 (1 O Defaults to 1.

to 48)
End period Numeric 2 (1 O Defaults to 48. If < start period then

to 48) the duration indicated ends on the
following day, ie goes over
midnight.
Example
HDR,RQMAINTLF,NETA,RGST,27/03/2008,14:01:01,1, LF factors
DET,NETA,LFCA,1.1234,0.9876,01/05/2008,,1,48
Data outputs:
 Updated distributor loss category code table.
 Audit trail.
 Notifications sent to all Traders who are responsible for ICPs that have been assigned the affected
distributor loss category code. This file output is shared with notifications of Distributor Price
Category Code changes (SD-040). It is different from the notification file described in NP-030) .
 For consistency the Distributor Loss Category Code table acknowledgements use the same output
format as NP-010 but the code and Start Date are included in place of the ICP identifier and the
Event Date respectively.
362
Version 22.24
Notification file format “NON”:

optional
Notification Type Char 2 M “LF”
Network Participant Identifier Char 4 M
Distributor Loss Category Char 7 M

Code
Loss factor consumption Numeric 1.4 M
Loss factor generation Numeric 1.4 O
Start date DD/MM/YYYY M
End date DD/MM/YYYY O
Start period Numeric 2 (1 M

to 48)
End period Numeric 2 (1 M

to 48)
Date and time of last change DD/MM/YYYY M Date and time when information
HH:MM:SS was last updated or inserted.
Example:
HDR,RSOTHERNT,RGST,RETA,05/04/2012,01:36:15,00000001
DET,LF,NETA,LFC0001,1.045,1.070,04/04/2012,03/04/2012,1,48,10/07/2010 12:15:03
363
Version 22.24
Sub-process: SD-040 Maintain Distributor Price Category Codes
Participants: Distributors, participants
Code references: Clause 23 of Schedule 11.1 of the Code.
Dependencies:
Description:
Each Distributor must update their own Distributor Price Category Codes entered on the table in the
registry.
1. Only Distributors must be able to update Distributor Price Category Codes and only in respect of
codes that they own.
2. It should be possible to update codes both online and in batch mode.

3. A Distributor Price Category Code must be included on the table in respect of all periods for which
an ICP has the Distributor Price Category Code assigned to it.
4. Each Distributor Price Category Code must be associated with a date range.
5. There must be only one Distributor Price Category Code associated with any date range, and date
ranges must not overlap.
6. The combination of Distributor Participant Identifier, Distributor Price Category Code and start date
must be unique.
7. Each participant must be able to view and download the complete loss factor code table on the
registry online.
8. A table entry relating to a Distributor Price Category Code may only be deleted if it the Code has
never been assigned to an ICP.
change and when.
10. The information must be able to be requested via FTP by any participant.
Processing:
System:
1. Validates all attributes and checks any dependencies.

2. Updates the Distributor Price Category Code table in the registry accordingly.
364
Version 22.24
3. Generates notifications to all Traders who are responsible for ICPs that have been assigned the
relevant Distributor Price Category Code.
Data inputs:

New or modified Distributor Price Category Code information.

optional
Network Participant Identifier Char 4 M Valid Participant Identifier for

Distributor.
Distributor Price Category Char 15 M

Code
Effective start date DD/MM/YYYY M May be modified only if in the future.
Effective end date DD/MM/YYYY O If missing, denotes that pricing

factors are valid until further notice.
May be modified:
 Where no end date currently
exists the supplied end date is
future dated relative to today; or
 Where an end date does exist
the supplied end date is future
dated relative to the existing
end date

Code description
Example
HDR,RQPRICECAT,RETA,RGST,03/08/2011,14:27:05,1,Price Category Updates
DET,NETA,PRCAT99,01/04/2013,,High Value Category
Data outputs:
Updated Distributor Price Category Code table.

Audit trail.
Notifications sent to all Traders who are responsible for ICPs that have been assigned the affected
Distributor Price Category. This file output is shared with notifications of Distributor Loss Category
Code changes (SD-030). It is different from the notification file described in NP-030).
Acknowledgements. For consistency, Distributor Price Category Code table acknowledgements use
the same output format as NP-010 but the code and Start Date are included in place of the ICP
identifier and the Event Date respectively.
365
Version 22.24
Notification file format “NON”:

optional
Notification Type Char 2 M “PC”
Network Participant Identifier Char 4 M
Distributor Price Category Char 15 M

Code

description
Effective start date DD/MM/YYYY M
Effective end date DD/MM/YYYY O
Date and time of last change DD/MM/YYYY M Date and time when information
HH:MM:SS was last updated or inserted.
Example:
HDR,RSOTHERNT,RGST,RETA,05/04/2012,01:36:15,00000001
DET,PC,NETA,PRC0001,PriceCategoryCode1,12/07/2011,12/07/2012,10/07/2010 12:15:03
366
Version 22.24
Sub-process: SD-050 Maintain email groups
Participants: Distributors, Traders, MEP, Registry Manager
Code references: None
Dependencies: None
Description:
The Registry Manager, on instruction from the Authority, will define new email groups.
The list of Email contact addresses in an email group is maintained by a Participant’s supervisor
user (or a user nominated by the supervisor).
An inquiry screen allows participant users to view and download their own email contact address
list for each email group.
The Registry Manager and Authority, via the administration or web application, may view and
download email contacts address lists for any participant.
In addition the Registry Manager may perform maintenance of email contact address lists on behalf
of a Participant by inputting contact address details via the administration or web application, or by
importing a file containing contact address details for an email group for multiple participants using
the administration application.
1. A Participant must be able only to view and download their own company’s email contact
address list for each email group
2. A Participant supervisor (or a user nominated by the supervisor) must be able to maintain their
own company’s email contact address lists for all email groups.
3. The Registry Manager must be able to maintain email contact address lists on behalf of a
Participant via the administration or web application.
4. The Registry Manager must be able to import a batch file of email contact address lists via the
administration application.
5. The Authority and Registry Manager must be able to view email contact address lists for any
Participant.
6. The Authority and Registry Manager must be able to download email contact address lists.
7. The Registry Manager, on instruction from the Authority, must be able to create or delete email
contact groups. An email group must not be removed if any Participant has an email contact
address list in that group.
367
Version 22.24
8. The Registry must maintain an audit trail of changes to email groups and email contact address
lists.
Data inputs:
New or changed email addresses:
Attributes input Format Mandatory Comments

/optional
Email Group name Char 50 M Valid Email Group name already known to
the Registry.
Email Contact Address Char Max O Semi colon space delimited email contact
List addresses, for example
 [email protected];
[email protected]
New or changed email group:

/optional
Email Group Name Char 50 M Email Group name, for example:

 Trader Default
 EIEP
 EIEP13A (EIEP13B, EIEP13C)

 Metering Alerts
Email Group Description Char 120 M Free format description of the email group
Email Import batch file:

/optional
File header:
Email Group Heading Char 11 M “Email Group”
368
Version 22.24
Email Group Identifier Char 50 M Identifies the email group against which the
participant email contact addresses will be
loaded.
Must be a valid Email Group. A file

containing no Email group or an invalid Email
group is treated as a fatal error and the
import aborted.
File detail:
Participant Char 4 M Participant Identifier.

Must be a valid participant identifier; else the
import line is reported as in error.
Email Contact Address Char Max O Semi colon space separated email
List addresses.
If the field contains “Removal” the
participant’s existing email contact
addresses are removed otherwise the email
addresses themselves are not validated.
If no email addresses are supplied, any
existing email addresses for the Participant
are left unchanged.
File example:
Email Group,Switching Saves
RETA,helpdesk@reta_energy.com;savesdesk@reta_energy.com
RETB,energyHelpDesk@retb_energyGroup.com; energyGroupSaves@retb_energyGroup.com
RETC,Removal
RETD,[email protected]
RETE,
The above file will perform the following:

1. Add or replace email address for RETA, RETB and RETD
2. Remove any existing email address for RETC
3. RETE’s existing email contact address list will remain unchanged
Download selection criteria:

a. Selected participant
b. All participants
c. An email group for all participants
d. All email groups for all participants
Processing:
369
Version 22.24
The system:
1. Enables the appropriate access to email groups and email contact address lists according
to whether the user is a participant, participant supervisor, Registry Manager or the
Authority.
2. Processes any uploads and/or downloads of email group information and/or email contact
address lists
3. Updates email group and email contact address lists.
4. Generates an audit trail.
Data outputs:
 Updated static data

 Audit record
 Downloaded email groups and emails contact address lists
N.B. Each attribute on an output line is comma separated
Download format for:

 Selected participant
 All participants
Name Format Comment
Participant Char 4 Participant Identifier
Email Group Name Char 50 Email group name
Email Contact Address Char Email contact addresses, semi colon space
List delimited
370
Version 22.24
Example: Download all email groups for selected participant

Participant,Email Group, Email Contact Address
RETA,Outages,[email protected]; [email protected]
RETA,EIEP,[email protected]; [email protected]
Example: Download all email groups for all participants with no concatenation
Participant,Email Group, Email Contact Address
RETA, Outages,[email protected]; [email protected]
RETA,EIEP,[email protected]; [email protected]
RETB, Outages,[email protected]; [email protected]
RETB,EIEP,[email protected]; [email protected]
RETC,Outages,
RETC,EIEP,
Example: Download all email groups for all participants with concatenation
Email Group, Email Contact Address
Outages,[email protected]; [email protected]; [email protected];
[email protected]
EIEP, [email protected]; [email protected]; [email protected];
[email protected]
Download format for:

 Email group for all participants. File name format
o No concatenation
 <email group>_AllParties_<dateTimestamp>.csv, for example: Trader
Default_AllParties_20150218132617.csv
o Concatenation
 <email group>_AllParties_Concatenate_<dateTimestamp>.csv, for
example: Trader Default_AllParties_Concatenate_20150218132617.csv
 All email groups for all participants File name format
o No concatenation
 AllGroups_AllParties_<dateTimestamp>.csv, for example:
AllGroups _AllParties_20150218132617.csv
o Concatenation
 AllGroups_AllParties_Concatenate_<dateTimestamp>.csv, for example:
AllGroups _AllParties_Concatenate_20150218132617.csv
Name Format Comment
Email Group Char 50 Email group name
Email Contact Address Char Max Email contact addresses, semi colon space
List delimited for all participants
371
Version 22.24
Example: Download email group EIEP for all participants with no concatenation
Participant, Email Group, Email Contact Address
RETA,EIEP,[email protected]; [email protected];
RETB,EIEP,[email protected]; [email protected]
Example: Download email group for all participants with concatenation

Email Group, Email Contact Address
EIEP,[email protected]; [email protected]; [email protected];
[email protected]
372
Version 22.24
3.10 Security
Sub-process: SU-010 Add and maintain new users
Process: Supervise own users
Code references:
Dependencies:
Description:
The participant supervisor for a participant organisation adds new users to the Registry and maintains
the information associated with existing users. The information provided includes an initial one-time-
use password,web services usage restrictions, access rights and an email address to which the
system sends notifications when passwords are reset.
N.B. The email address must be supplied when creating a new user. For existing users, it must be
supplied when updating their details.
1. A participant supervisor must be able to add and maintain user logons.
2. Each User Id must be unique within the set of User Ids of the user’s company and passwords
must conform to industry standards. (See Appendix 3).
3. Each User Id must have an associated email address where the Registry can send a one-time-
use password when passwords are reset by the system (see SU-030).
4. A participant supervisor must be able to identify user logons that will only be able to access the
Registry via web services.
5. A participant supervisor must be able to assign different access rights for different Registry
functions (e.g. ICP maintenance, switching, submission of reports) to individual users as required.
Data Inputs:
 Valid participant supervisor logon.

 New User Id, user name, user email address, required roles and access rights
Processing:
373
Version 22.24
System:
1. Enables the participant supervisor to create a new user or update an existing user; and stores the
associated user data, the new User Id, user name, one-time-use password, user e-mail address,
web services only indicator, access rights and other required information.
2. Generates appropriate audit trail information.
Data outputs:
 New user information.

 Audit trail information.
 Confirmation of a successful addition of new user logon or update of an existing logon.
374
Version 22.24
Sub-process: SU-020 Disable and re-enable logons
Code references:
Dependencies: SU-010
Description:
An existing logon may be disabled in order to prevent the user’s logon from being used to gain access
to the system. When required, it must be possible to re-enable a disabled logon.
1. The Registry must allow a participant supervisor to disable any of their participant company’s
logons when they are no longer required.
2. It must be possible to re-enable a user’s logon once it has been disabled
The logon must only be re-enabled by the assigned participant supervisor responsible for the logon.
Data inputs:
 Logon User Id of the participant supervisor.
 Logon User Id to be disabled or re-enabled..
Processing:
The system:
1. Disables or re-enables the logon User Id selected by the logged-on supervisor.
Data outputs:
 Confirmation of successful disablement or re-enablement.
375
Version 22.24
376
Version 22.24
Sub-process: SU-030 Reset user password
Code references:
Dependencies: SU-020, SU050
Description:
When a logon has been disabled, either by the system, the participant supervisor can reset (unlock)
the user’s password by updating it.
. The new password will be a one-time-use password that the user must change after logging on with it.
1.
2. When a participant supervisor resets a user’s password by updating it, the Registry must treat it as
a one-time-use password for the user.
3. The Registry must ensure that the one-time-use password can only be used once.
Data inputs:
 Logon User Id of the participant supervisor.
 Locked-out User Id.
 New user password.


Processing:
377
Version 22.24
The system:
1. Checks that the locked-out user being updated has an email address and, if missing, informs the
participant supervisor that the user lacks an email address and it must be input.
Checks that the password conforms to the password standard then, if valid, unlocks the User Id and
stores the password with the User Id.
Data outputs:
 Confirmation of successful password reset

 New one-time-use password assigned to the unlocked User Id.
378
Version 22.24
Sub-process: SU-040 Assign agent
Dependencies: SU010
Description:
The supervisor provides that a person who is acting as an agent for its participant organisation can
access the system on behalf of the participant organisation, by assigning access rights to that agent.
That agent will be able to create logons, which will be able to be used to perform maintenance,
switching and reporting on behalf of the participant.
1. Only users with supervisor privileges must be able to assign agency rights to another party’s logon.
2. Logons that can access the Registry via web services only must not be assigned agency rights.
Processing:
System
1. Provides an online function to allow the supervisor to assign agency rights responsible for the
logon.
2. Ensures that only supervisors can assign agency rights.
3. Ensures that Logons identified as web services only cannot act as agents.
4. Ensures that logons of acting agents cannot be modified to become web services only logons.
Data inputs:
 Logon of another company to be assigned agency rights.
Data outputs:
 Confirmation of successful assignment.
379
Version 22.24
Sub-process: SU-050 Lockout logons
Participants: Registry Manager
Code references:
Description:
User’s logons are locked out when:
1. There have been three attempts to logon with a valid logon code and invalid password. After
the third failure the logon code is locked out and can’t be used again until it is re-enabled by
the supervisor responsible for the logon.
2. The logon has expired due to the password not being changed within 30 days and after the 3
grace logons have been used up without a change of password.
When multiple lockouts occur for the same logon code within a specified period, the Registry Manager
is alerted . By default, a maximum of 5 lockouts are allowed within any 4 hour period.
1. The Registry must lock out a logon user Id after three failed attempts to log on.
2. The Registry must lock out logon user Id’s that have expired due to the password not being
changed within 30 days and after the 3 grace logons have been used up without a change of
password.
3. The Registry must maintain a lockout alert rule with the following parameters:
a. maximum number of lockouts;
b. lockout period i.e. the period of time, in minutes, during which the maximum number of
lockouts can occur before a lockout alert is triggered.
The default settings for the lockout alert rule parameters must be:
i. maximum number of lockouts: 5,
ii. lockout period: 240 minutes.

4. The Registry must be able to adjust the lockout alert rule parameters at any time when directed by
the Authority.
5. The Registry must trigger a lockout alert whenever the maximum number of lockouts is exceeded
in the lockout period.
6. The Registry must send a lockout alert email to the Registry Manager via the appropriate email
group whenever a lockout alert is triggered. The information sent must include
a. participant’s identifier,
b. user Id,
380
Version 22.24
c. date and time of alert,

d. number of lockouts and time period in which they occurred.
Data inputs:
 Logon user Id and password
Processing:
System:
1. Locks out a logon user Id whenever an incorrect password for that logon user Id is entered in the
browser more than three times, or, when a logon has expired.
2. Records a password lockout against the logon user Id.
3. Compares the number of password lockouts against the lockout alert rule, and whenever the
parameters of the rule are exceeded:
 generates an email to the Registry Manager’s LockoutAlert email group,
 records the lockout information for reporting in monthly statistics;
 resets password lockout count for the logon user Id to zero.
Data outputs:
 Password lockout count for logon user Id
 Lockout information for monthly statistics reporting
 Lockout alert email

Sample lockout alert email text
Heading: Electricity Registry – Password Max Lockouts Exceeded
Message text:
User <user Id> had <99> lockouts over a period of <x> minutes:
Lockouts occurred at the following times:
<dd/mm/ccyy hh:mm:ss>
Please raise an issue and initiate an investigation
381
Version 22.24
Sub-process: PW-010 Change user password
Process: Security
Code references:
Description:
Users are required to change their passwords at least every 60 days to maintain security, except for
web services only logons. A user is also able to change their password at any time.
Passwords of web services only logons can only be changed by participant supervisors as they do not
have browser access to the Registry; and hence no access to this function.
1. The Registry must ensure that users change their password at least every 60 days, except in the
case of password associated with web services only users, which do not expire..
2. Passwords must conform to the password standard (see Appendix 3).
Data inputs:
 User ID.
 Current password.
 New password.
Processing:
The system:
1. Accepts the new password if it conforms to the password standard.
2. Stores the new password as the user’s password.
Data outputs:
 New password
 Confirmation of successful change
382
Version 22.24
383
Version 22.24
Sub-process: PW-020 Request new password
Process: Security
Code references:
Description:
If a user forgets their password when they want to log on, they can request that a new one-time-use
password is emailed to them. Logons used for web services only cannot request a new password.
4. The Registry must be able to generate one-time-use passwords that conform to the password
standards (see Appendix 3).
5. The Registry must send a one-time-use password to a user’s email address when the user
indicates they have forgotten their password at logon, unless the user is restricted to web services
only..
6. The Registry must ensure that a one-time-use password can only be used once.
Data inputs:
 Password request
Processing:
The system:
1. If the logon is for web services only, informs the user that the request is invalid.
2. For non-web services user logons, checks that the system holds an appropriate email address for
the user. If it does, the system generates a one-time-use password and emails it to that email
address; otherwise, informs the user to contact their participant supervisor to reset their password.
3. Records an audit log of the reset request for monthly usage reporting.
Data outputs:
 New one-time password

 Confirmation that an email has been sent to the user or message to the user to contact their
participant supervisor
 Audit log of password reset request

 Email to user
Example Email
384
Version 22.24
N.B. Suggested wording only

Heading: Electricity Registry – Password Reset
Message text:
We received a request to reset your password for your Electricity Registry User Id.
Your new one-time password is: <password>
You must change your password after logging on with the password above.
If you did not request a password reset or have any questions or issues, please contact your
participant supervisor or the Registry Manager for assistance.
385
Version 22.24
3.11 EIEP Transfer
Sub-process: EI-010 Configure EIEP Transfer Settings
Process: EIEP Transfer
Participants: Participants (supervisor)
Dependencies: None
Description:
The participant supervisor configures optional additional email parameters to receive

acknowledgements of successful EIEP file uploads, confirmations of EIEP file deliveries to the
recipient, and notifications when EIEP files have been received from another participant.
Where the options of receiving acknowledgements, confirmations or delivery notices by email have
been selected, they will be sent to the email addresses listed in the participants EIEP email group,
or to email addresses listed in an email group, if present, whose name matches the file type of the
EIEP file. See SD-050 for further details.
1. A participants supervisor must be able modify communication options to:

a. receive by email from the Registry acknowledgements of the receipt of EIEP files;
b. receive by file in the senders EIEP in box from the Registry acknowledgements of the
receipt of EIEP files (set by default);
c. receive by email from the Registry confirmations of successful transfers;
d. receive by file in the senders EIEP in box from the Registry confirmations of successful
transfers (set by default);
e. receive by email from the Registry notifications of EIEP file deliveries.
2. Where a participant is a Third Party provider and does not have access to the configuration
settings, the settings must be maintained by the Registry Manager on their behalf.
3. Changes to EIEP communication options must have an audit record.
Data inputs:
EIEP Communication Settings.
386
Version 22.24
Processing:
System:
1. Validates EIEP communication settings.
2. Updates communication settings.
3. Generates audit records for each communication setting change.
Data outputs:
Updated EIEP communication option settings.
387
Version 22.24
Sub-process: EI-020 Upload and Download EIEP via the browser
Dependencies: None
Description:
In addition to the SFTP facility to upload and download EIEP files and notices, a browser screen
allows a participant to:
 View and download their EIEP files and notices from their EIEP inbox (EIEPin folder) that have
been received.
 Upload EIEP files for delivery to another participant by selecting local computer files and
uploading them into their EIEP outbox (EIEPout folder) for delivery to a recipient participant.
1. Access to the EIEP Upload and Download screen is assigned to users by their participant’s
supervisor.
2. EIEP Directory Monitoring.

A user may view the contents of their EIEP inbox directory.
Search criteria may be applied when searching the EIEP inbox directory:
 Sender or All.
 File Creation Date From.
3. File Download.
A file from the EIEP inbox directory may be selected and downloaded to a local computer.
All downloads have audit records generated.
4. File Upload.
A user may search a local computer and upload a file into their EIEP outbox. The file will
subsequently be picked up and delivered to the recipient participant.
Audit records are generated for successful uploads and deliveries.
5. Error processing.
If the Registry is unable to deliver the EIEP file, then an error message will be displayed, and the
file will be moved to the sender’s inbox with an appended error code.
Audit records are generated for all files with errors.
6. Notices
A user is able to view the progress of the transfer by monitoring their EIEP inbox for
acknowledgements and confirmations.
388
Version 22.24
Data inputs:
Uploaded file.
EIEPin folder contents.
Processing:
For EIEP Downloads, system:

1. Applies search criteria to interrogate the EIEP Inbox directory
2. Displays results of the search.
3. Downloads the selected file to a local computer.
4. Generates audit records of the download of a file.
For EIEP Uploads, system:

1. Loads the selected file into the EIEP out box inquiry criteria.
2. Validates the filename.
3. If valid, transfers the file to the recipients EIEP inbox . See process EI-030 for further details on
the transfer process.
4. If invalid, transfers the file to the senders EIEP outbox directory with an appended error code.
5. Generates audit records of the online upload of a file.
Data outputs:
EIEP Audit w records.

Downloaded file from EIEP inbox.
389
Version 22.24
Sub-process: EI-030 Transfer EIEP via SFTP
Participants: Authority, Participants
Dependencies: None
Description:
Participants are provided with an EIEP outbox (EIEPout folder) into which files are deposited for
delivery to other participants, and an EIEP inbox (EIEPin folder) where files are received that have
been delivered from other participants as well as acknowledgement and confirmation notices from
the Registry.
Email confirmations of the successful delivery of files are also generated, using the email
addresses stored in the email groups of the sending and receiving participants. To receive these
email notifications, email addresses must be set up under the appropriate email group names for:
 The default email group with a name of ”EIEP”. The email addresses listed under this
email group will be used to notify of file deliveries and receipts for all filetypes where there
is no specific email group name set up for the participant.
 Optionally, the email group name matching a specific EIEP filetype, such as EIEP13C.
1. EIEP file delivery must be via SFTP.

2. EIEP files must be retained for a period of one month before their deletion from the EIEP
outbox.
3. In accordance with the Authority’s EIEP Transfer Permissions, transfer a copy of the EIEP file to
the Authority’s EIEP inbox and SFTP server (EI-040).
4. If the EIEP Unique ID attribute contains the text “SendToEAOnly” in any position, the file and
the file type section of the file name corresponds to an EIEP file type (EI-040), the file must be
transferred to the Authority’s EIEP inbox and SFTP server. The Recipient must not receive the
file. Recipient communication settings must be substituted with those of the Authority.
5. Duplicate files (same file name) must not be transferred to the Authority’s SFTP server. If a file
has 1 or more matching Authority’s EIEP Transfer Permissions and/or “SendToEAOnly” in
Unique ID the Authority must receive the file once.
6. The Authority must not receive duplicate files.If a file has 1 or more matching Authority’s EIEP
Transfer Permissions and/or “SendToEAOnly” in Unique ID, the Authority must receive the file
once.In accordance with the participants EIEP communication settings, an optional
acknowledgement file notice must be generated (for delivery to the sender’s inbox) when the file
is put into the sender’s outbox (ie. a successful upload).
7. In accordance with the participants EIEP communication settings, an optional
acknowledgement email notice must be generated (for delivery to the sender’s email address)
when the file is put into the senders outbox (ie. a successful upload).
390
Version 22.24
8. In accordance with the participants EIEP communication settings, an optional confirmation file
notice must be generated (for delivery to the sender’s inbox) when the file is delivered to the
recipient.
9. In accordance with the participants EIEP communication settings, an optional confirmation
email notice must be generated (for delivery to the sender’s email address) when the file is
delivered to the recipient.
10. In accordance with the participants EIEP communication settings, an optional delivery notice
email must be generated (for delivery to the recipient’s email address) when the file is delivered
to the recipient.
11. Where a filename does not conform to the file naming convention then the file must be rejected
and placed in the senders inbox with an appropriate error message attached to the filename.
12. All successful uploads, deliveries and file rejections must have associated audit records.
Data inputs:
 EIEP file to be delivered.

 EIEP Transfer Settings
An EIEP file must conform to the following file naming format:

Component Format Description
Sender Char 4 Code of submitting participant
Utility Type Char 1
Recipient Char 4 Code of recipient participant
File Type Char 7 EIEP File Format
Report Month yyyymm
Report Run Date yyyymmdd
Unique ID Char 60 e.g. hhmm run time, or ICP number but max 60 characters
Each component is underscore separated.
Example: RETA_E_NETA_EIEP13A_201503_20151203_myfile.zip
1. Sender must be a valid participant code and must also be the owner of the outbox into which
the EIEP file has been placed.
2. The recipient must be a valid participant code.
3. The allowed character set for all components includes:
“abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789."
Processing:
System:
1. Picks up the file submitted to the participants EIEP outbox.
2. Determines, according to the EIEP communication settings, whether to generate the
acknowledgments (by SFTP, email, both or neither). The format of the acknowledgement file
name is the input file name with “.ake” appended.
3. Validates the filename. There is no validation of Utility Type, File Type, Unique ID or the file
extension other than they conform to the defined format. There is no validation of the file data,
391
Version 22.24
not even headers, so as is the case with all EIEPs, it is the responsibility of the sending
participant to ensure that the file information is complete and correct.
4. If file is valid, transfers the file and
a. if Unique ID contains “SendToEAOnly” substitutes the Authority as the recipient of the
file (the recipient section (the file name is changed to EMCO), and substitutes the
Recipient communication settings with those of the Authority.
b. moves it to the recipients EIEP inbox. The file being delivered to a recipient will not
overwrite any existing file of the same name. The file name will be amended to create a
unique filename by appending a numeric identifier.
c. according to the Authority EIEP Transfer Permissions transfers a copy to the
Authority’s EIEP inbox and SFTP server.
d. according to the EIEP communication settings, generates the optional file confirmation
to the sender (by SFTP, email, both or neither). The format of the confirmation file
name is the input file name with “.confirm” appended.
e. according to the EIEP communication settings, generates the optional email notification
to recipient (by SFTP, email, both or neither).
N.B. When emails are generated, if the filename (e.g EIEP13A) matches an email group
they are sent to the email address(es) listed under the email group, otherwise they are sent
to the email address of the default email group named “EIEP”. If no email address can be
found, no email is sent. See SD-050 for further details.
5. If file has an error, rejects by
a. moving the file to the sender’s EIEP inbox with a relevant error code appended. The
rejected file is named by appending the error code of the first error encountered to the
input file name.
b. according to the EIEP communication settings, generating an optional file notification to
the sender (by email)
6. Generates EIEP file tracking information for audit and compliance analysis that includes:
 Sender
 Recipient
 Arrival time
 File size
 File name
 Delivery name
 Sent to Authority SFTP server
 Error number (if present)
Data outputs:
Email and/or file acknowledgement notice.

Email and/or file confirmation notice.
Email delivery notice.
EIEP file - delivered to recipient.
EIEP file with error code – delivered to sender.
EIEP audit records.
392
Version 22.24
Sub-process: EI-040 Maintain EIEP Transfer Permissions
Dependencies: None
Criticality Non-core
Description:
The Authority gains authorisation from Participants to allow specific EIEP files, where the
Participant is either the sender or recipient, to be transferred to the Authority. That is; they agree to
share EIEP information they send or receive with the Authority.
The Authority instructs the Registry Administrator to actualise an appropriate EIEP Transfer
Permission for use in the EIEP Transfer Process to transfer to the Authority a copy of an EIEP file.
1. Entries in the EIEP Transfer Permission table must have the following information:
 File Type*
 Participant Identifier*
 Authorisation to transfer files as Recipient
 Authorisation to transfer files as Sender
 Authorisation Active
2. Each entry in the EIEP Transfer Permission table must be unique for the fields above marked
with an asterisk.
3. On instruction from the Authority the Registry Administrator must update EIEP Transfer
Permission table entries.
4. The Registry Administrator must be able to insert, delete and activate (i.e. set Authorisation
Active) Transfer Permission table entries.
5. The Registry must record audit information of changes.
393
Version 22.24
Data inputs:
New or changed EIEP Transfer Permission:

Attributes input Format Mandatory / Description
Optional
File Type Char 7 M EIEP File Format
On request of the Authority, EIEP file types are
added by the Registry Administrator
Participant Char 4 M Participant identifier of Participant that has agreed
Identifier to share EIEP files with the Authority
Authorisation to Boolean O Participant agrees to share files they receive
transfer files as
Recipient
Authorisation to Boolean O Participant agrees to share files they send
transfer files as
Sender
Authorisation Boolean O True - EIEP Transfer Permission is active.
Active May only be active if at least one of Authorisation to
transfer files as Recipient or Authorisation to
transfer files as Sender is true.
False (the default) - EIEP Transfer Permission is
not active
Processing:
System:
1. Validates all attributes and checks any dependencies
2. Updates the EIEP Transfer Permission table
3. Generates appropriate audit trail information
Data outputs:
 New or amended EIEP Transfer Permission

 Audit trail information
394
Version 22.24
3.12 Trader Default

Sub-process: TD-010 Complete Switch Activity for Trader in Trader Default
Process: Switching
Dependencies:
Description:
On instruction from the Authority the Registry Manager will process in-progress Trader switch
activity on behalf of a Trader in a Trader Default situation.
This process will locate all ICPs that have a Trader switch or switch withdrawal in progress and that
involve the defaulting Trader. The registry will then generate the next switch messages in the
switching cycle, required to be submitted by the defaulting Trader only, in order to switch ICPs to a
responsible non-defaulting Trader i.e. a switch away or a withdrawal that reverts responsibility away
from the defaulting Trader. This process will NOT generate switch messages on behalf of any non-
defaulting Trader. It will generate a report for non-defaulting Traders detailing the next switch
messages that the non-defaulting Trader may submit in order for the switch to complete.
This process:
 generates CS switch messages to complete all switches in progress where the defaulting
Trader is the losing Trader and the switch type is not HH, and
 generates AN switch messages for switches in progress where the defaulting Trader is the
losing Trader and the switch type is HH and only an NT has been submitted, and
 generates NW withdrawal messages for switches in progress where the defaulting Trader
is the gaining Trader (to prevent the gain by the defaulter), and
 generates AW acceptance of withdrawal messages for withdrawals in progress where the
result of the withdrawal would leave the ICP with a non-defaulting Trader or where both
parties are defaulting Traders, and
 generates AW rejection of withdrawal messages for withdrawals in progress where the
result of the withdrawal would leave the ICP with a defaulting Trader.
The switch messages generated by the registry will use exactly the same attributes and validation
rules that the standard switch messages use (for AN, CS, NW and AW switch messages). This
means that the same updates, outputs and notifications will be generated to all affected parties of
the switch that are specified in the associated sub-processes for the AN (RS-020), CS (RS-050),
NW (RW-010) and AW (RW-020), such as :
 delivery of switch messages to the ‘other’ Trader involved in the switch (in accordance with
the ‘other’ Trader’s switch notification parameters); and
 insertions, replacements and reversals of events as a result of completed switches or
completed withdrawals; and
 any required updates to the switch statuses (Trader or MEP); and
395
Version 22.24
 delivery of all notifications to all affected parties (to Traders, Distributors, MEPs) as a result
of completed switches or completed switch withdrawals, in accordance with each party’s
notification parameters; and
 delivery of any snapshot version of the PR-030 report required to delivered to new Traders
for completed switches, in accordance with that Trader’s notification parameters; and
 creation of audit information where the participant submitting the messages will be
recorded as the defaulting Trader but the creation user id will be set to “TD-010”.
This process will run in either edit or update mode. In edit mode, the registry will generate the
switch messages and submit them for validation checking but not commit the updates to the
database. In update mode the updates to the database will be committed and all notifications will
be generated.
A progress report is output for the Authority. A report is also generated for Traders to detail any
switch messages they would need to submit to complete any switches or withdrawals away from
the defaulting Trader. In edit mode the Traders’ reports will not be delivered.
1. The Registry Manager may only act to complete Trader switch activity (on behalf of a defaulting
Trader) upon instruction from the Authority.
2. Only Traders in a Trader Default situation may have their Trader switches generated by the
Registry Manager.
3. The Registry Manager must not perform switch activity on behalf of a non-defaulting Trader.
Switch messages required to be submitted by a non-defaulting Trader must remain that
Trader’s responsibility.
4. The Registry Manager will only process ICPs which are switch in progress or withdrawal in
progress, where the switch requires input from the defaulting Trader in order to proceed.
5. Where an ICP is being switched between 2 Traders, where both traders are in a Trader Default
situation, the switch must be withdrawn. The ICP must remain with the current Trader and
become available as part of the Tender process for that Trader. Only in this instance will the
Registry Manager generate both the NW and the AW messages. The withdrawal message
(NW) will have a withdrawal advisory code set to “TD”. Both messages will have a User
Reference of “Trader Default initiated”.
6. Where dependencies exist switch messages must be processed in the correct order, for
example submission of an AW before submission of a CS.
7. Where a switch has a Switch Type HH and is awaiting an AN message from the defaulting
Trader, the Registry Manager must generate the AN with a Response Code of “TD” and a User
Reference of “Trader Default initiated”. The Expected Transfer Date will be taken from the NT,
if provided, otherwise it will be set to the Actual Transfer Date parameter.
8. Where a switch is awaiting a CS from the defaulting Trader, the Registry Manager must
generate a CS. The values for the CS attributes will be populated using the ICPs metering
records as at the Actual Transfer Date as follows:
For the Premises row:
 Trader – Trader participant identifier of defaulting Trader.
396
Version 22.24
 Actual Transfer Date – date of the switch to be defined by the Authority and input as a
run parameter.
 User Reference – set to “Trader Default initiated”.
Then for each Metering Installation that has channels requiring readings:
a) Metering Installation Number – obtained from the Metering information held on the
Registry.
b) Average Daily Consumption – 0.
c) Key Held Indicator – “N”.
Then for each Metering Component in the installation with at least 1 Channel with an
Accumulator Type of “C” and Settlement Indicator of “Y”:
d) Metering Installation Number – obtained from the Metering information held on the
Registry.
e) Metering Component Serial Number – obtained from the Metering information held on
the Registry.
f) Last Read Date – Actual Transfer Date.
g) Meter Reader Notes – null.
Then for each channel with an Accumulator Type of “C” and Settlement Indicator of “Y”:
h) Metering Installation Number – obtained from the Metering information held on the
Registry.
i) Metering Component Serial Number – obtained from the Metering information held on
the Registry.
j) Channel Number – obtained from the Metering information held on the Registry
k) Reading – 0.
l) Actual or Estimate – "D”.
N.B.
i. Where there are no channels with accumulator type = ‘C’ and a settlement indicator of
‘Y’, such as for an ICP with only unmetered load, there will only be a premises record
type generated.
ii. No CS message for a switch type of HH will be generated as these are only input by
gaining Traders. In this process a defaulting Trader cannot gain an ICP, also, a CS
cannot be generated on behalf of a non-defaulting Trader.
9. Where a switch is being withdrawn and acceptance of the withdrawal would result in either
a. the defaulting Trader losing ICP responsibility, or
b. a non-defaulting Trader retaining responsibility,
then an AW acceptance of the withdrawal must be generated. Otherwise, an AW must be
generated rejecting the withdrawal. AWs must be generated with a User Reference of “Trader
Default initiated”.
10. Where the Registry Manager has generated an AW rejection and the result of the AW leaves
the ICP in a switch in progress state and completion of the switch would result in a non-
defaulting Trader gaining responsibility, the Registry Manager must also generate the
appropriate switch message to progress the switch away from the defaulting Trader (i.e.
generate AN or CS).
11. The Registry Manager must withdraw a switch in progress by generating an NW switch
message, where the completion of a switch would result in the defaulting Trader gaining the
ICP. This means that all switches in progress where the NT was submitted by the defaulting
397
Version 22.24
Trader will be withdrawn, regardless of switch type. The withdrawal advisory code will be set to
“TD” and the User Reference set to “Trader Default initiated”.
12. In general where the completion of ICP switch activity (Complete Switch (CS), or Acknowledge
Withdrawal (AW)) would result in a gain or retention of responsibility by the defaulting Trader,
the gain/retention must be prevented.
13. The Registry Manager must be able to interrogate resultant error messages, and provide or
implement recommendations to allow switch activity to be completed. Any error must be
referred to the Authority.
14. Switch activity requiring action by a non-defaulting Trader must be notified to that Trader
immediately by delivery to the Traders FTP directory.
15. It must be possible to run the processing of switch messages in edit or update mode, where:
 edit mode will only validate the generated switch messages (NOTE: errors may occur
where switch message dependencies exist) allowing the Registry Manager to investigate
errors and generate reports to the Authority;
 update mode will validate generated switch messages, apply all the standard process
updates to the Registry where no error is reported and deliver all notifications and
messages in the standard way (as defined in RS-020, RS-050, RW-010 and RW-020).
16. A report must be provided to the Authority giving details of those ICPs where switch activity has
or will be performed on behalf of the defaulting Trader.
17. A report must be provided to the non-defaulting Traders giving details of the switch messages
they should submit to complete ICP switches away from the defaulting Trader. These must not
be delivered to Traders when run in edit mode.
Data inputs:
/optional
Trader Char 4 M Participant identifier of defaulting Trader
Actual Transfer Date Date M Determined by the Authority.

Defaulted to today’s date.
N.B. Should not be before today’s date
but the system will not validate it to be so.
Run mode Char 1 M E – edit

U - update
Processing:
System:
2. Identifies all ICPs that have a Trader switch in progress (including switch withdrawals) where
the defaulting Trader is involved in the switch and is required to provide the next switch
message in the switch cycle.
398
Version 22.24
3. Identifies dependencies and ensures switch messages are generated according to those
dependencies i.e. follows the switching cycle according to the switch type of the NT.
4. If the switch is between 2 Traders, both of whom are in Trader Default, generates the
appropriate switch messages to withdraw the switch.
5. Identifies ICPs where the completion of the switch activity (including withdrawals) will result in a
loss of ICP responsibility by the defaulting Trader (switch away) and generates switch
messages to facilitate the loss of responsibility.
6. Identifies ICPs where the completion of the switch activity will result in a gain of ICP
responsibility by the defaulting Trader (switch gain) and generates NW withdrawal messages to
prevent the gain of responsibility.
7. If run in edit mode, validates all updates reporting the result for each switch message but does
not apply the updates.
8. If run in update mode, validates and where no errors are reported, performs all the updates and
generates all the appropriate notifications in accordance with the standard process detailed in
RS-020, RS-050, RW-010 and RW-020, for the switch message type. The audit trail records
will be generated detailing the participant as the defaulting Trader but the creation user id will
be set to “TD-010”.
9. Generates the results file and delivers it to the Authority.
10. Generates the outstanding switch activity report that details the switch messages non-
defaulting Traders must provide next. If run in update mode, delivers these reports to non-
defaulting Traders.
Data outputs:
 Results File supplied to the Authority detailing the switch messages generated on behalf
of the defaulting Trader.
The file output name will be:
“TD010_SwitchMessages_<timestamp>.csv where timestamp is format

The results file is delivered to the Authority by email.
Run Mode Char 17 “Run Mode” followed by one of

 Edit or
 Update
Defaulting Trader Char 24 “Defaulting Trader“ followed by Participant identifier of

the defaulting Trader.
399
Version 22.24
Header row:
“ICP Identifier, Switch Message, Recipient Trader, Result”
A row for each ICP processed, in ICP Identifier then Switch Message Type order, containing:
ICP Identifier Char 15 ICP Identifier
Switch Message Type Char 9 One of:

 AN
 CS
 NW
 AW Accept if AW is an acceptance of the
withdrawal
 AW Reject if the AW is a rejection of the
withdrawal
Recipient Trader Char 4 Participant identifier of recipient Trader
Result Numeric Error code
File example; performed where defaulting Trader is RETA:

Run Mode - Edit
Defaulting Trader - RETA
ICP Identifier, Switch Message, Recipient Trader, Result
1234567890AB123,AN,RETB,000
2345678901AB234,AN,RETB,000
3456789012AB345,NW,RETB,000
3456789012AB345,AW Accept,RETB,000
4567890123AB456,CS,RETC,000
5678901234AB567,AW Reject,RETC,000
 Outstanding Switch Activity File supplied to non-defaulting Trader FTP directory

advising of outstanding switch messages they are required to supply in Switch Message
Type then ICP Identifier order.
““TD010_SuggestedSwitchMessages _<timestamp>.csv where timestamp is format

Switch Message Type Char 2 Switch type required to be supplied
Switch Message Char Recommended switch message input line in order to

progress the switch.
For a Switch Message of type CS, no recommended
Switch Message is supplied as the required CS
information resides with the Trader.
File example
HDR,RSRQDSMSGS,RGST,RETB,06/03/2015,15:29:14,00000003,Trader default initiated
0000000102AA754,CS,
0000245007UN741,AW,P,0000245007UN741,RETB,R,Trader Default
348577122LLJEAB,AW,P,348577122LLJEAB,RETB,A,Trader Default
400
Version 22.24
 AN switch messages. See RS-020 for details on the attributes and processing.
 CS switch messages. See RS-050 for details on the attributes and processing.
 NW switch messages. See RW-010 for details on the attributes and processing .
 AW switch messages. See RW-020 for details on the attributes and processing.
401
Version 22.24
Sub-process: TD-020 Maintain Trader ICP Allocation Exclusion List
Process: Mandatory transfer of ICPs
Participants: Traders, Authority
Dependencies:
Description:
During a Trader Default situation the Registry may be required by the Authority to perform
mandatory allocation of ICPs not allocated to Traders during the tender process.
In this process, Traders maintain an allocation exclusion list that contains filters that the Trader
requires to be used to exclude ICPs from their mandatory allocation.
In the mandatory allocation process, before allocating an ICP to a Trader, the system will check the
Traders allocation exclusion list. If there is an entry (row) where all the filters match, the ICP will be
excluded from being allocated to the Trader. Where a filter allows multiple values, only one of
these values is required to match.
An allocation exclusion list provides Traders with the ability to avoid ICPs they are unable to accept,
or that would pose a serious threat to their financial viability.
Where ICPs are unable to be allocated due to Traders exclusion tables, the Authority may allocate
remaining ICPs as necessary.
1. Only Traders must be able to maintain allocation exclusion lists.

2. Traders must only be able to maintain their own allocation exclusion list.
3. Traders must be able to view and download their exclusion list online.
4. The Authority must be able to view and download exclusion lists for any Trader online.
5. Traders must only be able to update their exclusion list in batch mode.
6. When Traders update their exclusion list they must provide a complete set of exclusion criteria.
Data inputs:
Allocation exclusion list.
Attribute Name Format Mandatory Description
/optional
Reason Code Char 3 M Valid Trader Default Exclusion Code
402
Version 22.24
Reason Description Char 250 M/O Free format text. Mandatory if Reason
Code is “OTH”.
Distributor Char 4 M Distributor Participant identifier. Must be

valid in the distributor role as at today’s
date.
POC Char 7 O Valid POC. In combination with the

Distributor must exist in the NSP Mapping
table.
Meter Types Char O Space separated. Any combination of

HHR, NHH, PP or UML.
HHR – Any meter installation type
(installation row) within an ICP is HHR
NHH - All meter installation types
(installation row) within an ICP are NHH,
NON or there is no metering installation
(solely UML or MEP has not populated
information).
PP – the presence of a pre-pay Meter
Type on Metering/Component Type within
any of the metering installations of the
ICP
UML – Trader event UNM Flag = Y
Price Category Codes Char O Space separated.

Must be a valid Price Category Code for
the Distributor.
Highest Meter Char O Space separated. Any combination of 1,

Installation Category 2, 3, 4, 5, 9.
Installation Type Char O Space separated. Any combination of L,

G, B.
403
Version 22.24
File examples:
HDR,RQEXCLTBL,RETA,RGST,16/06/2014,15:36:36,1,maintain RETA exclusions
DET,DIA,,NETA
Meaning:
Do not allocate ICPs where current Distributor is NETA

DET,DIA,,NETB,ABC0011
Meaning:
Do not allocate ICP’s where current Distributor is NETB AND POC is ABC0011

DET,MTR,,NETB,ABC0022,NHH PP,
Meaning:
Do not allocate ICPs where current Distributor is NETB AND POC is ABC0022 AND (ICP NHH flag
= Y OR PP flag = Y)

DET,MTR,,NETB,ABC0022,HHR,,5
Meaning:
Do not allocate ICPs where current Distributor is NETB AND POC is ABC0022 AND ICP HHR flag
= Y AND Highest Meter Category = 5

DET,PC,,NETB,ABC0033,,PCAT1 PCAT2
Meaning:
Do not allocate ICPs where current Distributor is NETB AND POC is ABC0033 AND (Price
Category Code = PCAT1 OR Price Category Code = PCAT2)

DET,MTR,,NETB,ABC0044,NHH HHR PP,PCAT1 PCAT2,4 5 9
DET,INT,,NETB,,,PCAT9,,G B
Meaning:
Line1:
Do not allocate ICPs where current Distributor is NETB AND POC is ABC0044 AND (ICP NHH flag
= Y OR ICP HHR flag = Y OR ICP PP flag = Y) AND (Price Category Code = PCAT1 OR Price
Category Code = PCAT2) AND (Highest Meter Category = 4 OR Highest Meter Category Code = 5
OR Highest Meter Category = 9)
Line 2:
And do not allocate ICPs where current Distributor is NETB AND (Price Category Code = PCAT9)
AND (ICP Installation Type = G OR ICP Installation Type = B)
Processing:
System:
1. Validates that the participant is a Trader (active in the role and not in default) as at today’s date.
2. Validates the data inputs and if no errors are found, removes the participant’s current
exclusions, and creates a new set of exclusion rules.
3. Reports results to the participant.
404
Version 22.24
Data outputs:
Updated allocation exclusion table.
Each attribute on an output line is comma separated. Multiple attribute values are space
separated.
Input line Char Input line as supplied by participant
Result code Numeric Result of update

 000 – successful update, else
 error code
File example – based on the data inputs examples and as if they had been input in a single file:
HDR,RSEXCLTBL,RGST,RETA,16/06/2014,15:36:36,6,maintain RETA exclusions
DET,DIA,,NETA,000
DET,DIA,,NETB,ABC0011,000
DET,MTR,,NETB,ABC0022,NHH PP,000
DET,PC,,NETB,ABC0033,HHR PP,PCAT1,000
DET,INT,,NETB,ABC0044,NHH HHR PP,PCAT1 PCAT2,4 5 9,000
DET,PC,,NETB,,,PCAT9,,,000
405
Version 22.24
Sub-process: TD-030 Create Tender Blocks
Process: ICP Tendering
Dependencies: TD-050
Description:
On instruction from the Authority the Registry Manager will open a Tender Round and generate
Tender Blocks against a Trader in a Trader Default situation.
A Tender Block consists of a defaulting Trader’s ICP’s grouped together due to commonality of
specific attributes according to shared characteristics.
Tender Blocks form the basis of tender documents forwarded to Traders who are not in a Trader
Default situation.
1. The Registry Manager must act to initiate a new Tender Round and create Tender Blocks upon
instruction from the Authority.
2. Tender Blocks must only be created against a defaulting Trader.
3. By default there will be 2 Tender Rounds. However, if more rounds are required these must be
authorised by the Authority in consultation with the Registry Manager (refer SD-020).
4. Tender Blocks for the first Tender Round must only be comprised of active, or inactive but not
ready for decommissioning, ICPs for which the defaulting Trader has current responsibility.
Subsequent Tender Blocks for subsequent rounds, must only be comprised of untendered ICPs
remaining after the immediately prior round has closed that are still the responsibility of the
defaulting Trader, together with any ICPs that have become available for tender since the last
set of Tender Blocks were created.
5. Tender Blocks for a given round must be able to be re-created or removed provided that it is
the latest tender and that no Traders have supplied bids against.
6. A report detailing Tender Blocks must be sent to the Authority.
Data inputs:
ICPs that the defaulting Trader has current responsibility for.
Trader bids (if applicable). TD-050.
Parameters:
406
Version 22.24

/optional
Allocation Identifier Numeric M <x> where <x> refers to the Tender

Round.
Action Char 1 O Blank – default. Create new, or replace

existing, Tender Blocks.
D – Delete existing Tender Blocks.
Processing:
System:
1. Verifies the Trader is in a Trader Default situation.
2. If a tender is being replaced or deleted, checks that it is the latest tender and that no Traders
have tendered against it and, if valid, removes the Tender Blocks associated with the tender.
3. Creates new or replacement Tender Blocks by considering all the ICPs for which the defaulting
Trader is currently responsible and:
a. excludes those ICPs subject to a switch or switch withdrawal or with a Status other
than Active or Inactive, or with a Status of Inactive and a Status Reason of Ready for
Decommissioning.
b. groups the rest into Tender Blocks according to the following characteristics:
i. NSP
ii. Distributor Price Category codes

iii. MEP
iv. Meter Types
v. Highest Metering Category

vi. Installation Type
vii. Reconciliation Type.
c. Calculates the number of ICPs in each Tender Block

d. Subtracts the total number of ICPs bid on for the same Tender Block in any/all prior
Tender Round(s), to obtain the number of ICPs for the current Tender Round.
4. Reports to the Authority the Tender Block information.
Data outputs:
Tender Blocks constructed from defaulting Trader’s ICPs, where each item contains:
 Defaulting Trader
407
Version 22.24
 Allocation Identifier
 NSP
 Distributor Price Codes
 MEP
 Meter Types
 Highest Metering Category
 Number of ICPs available in the Tender Block
Tender Block information reported to the Authority, as follows:

The report will be in characterisitics order. Report output name will be
“ICPTenderBlockTender<TenderNumber>_<DefaultTrader>_<timeStamp> where
TenderNumber = tender number
DefaultTrader = the Trader against whom the ICP Tender Blocks have been generated
timeStamp = creation time in yyyymmddhhmmss format
for example: ICPTenderBlockTender1_RETA_2014091511:15:21.csv
Defaulting Trader Char 4 Participant identifier of the defaulting Trader and

selection parameter
Allocation Identifier Char 1 <x> where <x> refers to the Tender Round.
NSP Char 11 NSP Identifier
Distributor Price Char 2000 Comprises one or more unique price category code(s)
Category Codes space separated.
408
Version 22.24
Meter Types Char 20 One or more of the following, space separated:

 HHR – Any meter installation type (installation row)
within an ICP is HHR
 NHH - All meter installation types (installation row)
within an ICP are NHH, NON or there is no metering
installation (solely UML or MEP has not populated
information).
 PP – the presence of a pre-pay Meter Type on
Metering/Component Type within any of the
metering installations of the ICP
 AMI – the presence of an advanced infrastructure
metering device (AMI Flag = Y) on
Metering/Component within any of the metering
installations of the ICP
 UML – Trader event UNM Flag = Y
Highest Metering Numeric 1 1 through 5, or 9, null if not populated

Category
Installation Type Char 1 One of:

 L
 G
 B
Reconciliation Type Char 2 One of:

 GN grid connected network;
 EN embedded network;
 SB embedded network residual load.
Number of ICPs Numeric 9 Number of ICPs in the Tender Block calculated as

specified above
Report example:
Trader,Allocation ID,NSP, Distributor Price Category Codes,MEP,Meter Types,Highest Metering Category,Installation
Type,Reconciliation Type,Number of ICPs
RETA,1,NETAABC0111,PC1,META,HHR,3,L,GN,1560
RETA,1,NETAABC0111,PC1,META,NHH,1,L,GN,778
RETA,1,NETAABC0111,PC1 PC3,META,HHR,4,L,GN,12
409
Version 22.24
Sub-process: TD-040 Send Tender Documentation
Participants: Authority, Traders
Dependencies: MP-020, TD-030
Description:
On instruction from the Authority the Registry Manager transfers tender documentation to Traders
that are not in a Trader Default situation.
Transmission of tender documentation is via the EIEP hub.
The tender documentation includes the Tender Blocks created by the Registry and a prepared
information sheet provided by the Authority.
Traders are notified of the availability of tender documentation via the email address previously
notified to the Registry Manager (MP-020).
The Authority may, on an ad-hoc basis, supply the Registry Manager with further information to be
transmitted via email or EIEP to Traders. This information may relate to tender closure or other
information regarded by the Authority as required for completion of a successful tender.
1. The Registry Manager must act to send tender documents for the latest unpublished open
Tender Round to Traders on instruction from the Authority.
2. The Authority must instruct the Registry Manager of the open and close date/time of the tender.
A tender open and close date must not overlap the open and close date of any other tender for
the defaulting Trader.
3. Tender open date/time cannot be historical.
4. The Authority may instruct the Registry Manager to delay, extend or shorten a tender i.e. adjust
the tender open or close date/time.
5. A tender open date must not change if Traders have tendered against any of the ICP Tender
Blocks.
6. Tender documents must be sent to Traders via the EIEP hub (refer data outputs section for
EIEP file name convention).
7. The Authority provided information sheet must be sent to Traders via the EIEP hub.
8. Traders must be notified via email (MP-020) that tender documents have been transferred to
their EIEP inbox and are available for download.
410
Version 22.24
9. The Authority must request the Registry Manager to advise Traders that the tender process
has, or is due to close. The Registry Manager must convey this information to Traders via email
(MP-020).
10. The Authority may be required to provide further clarity, or answer specific or general questions
from Traders during the tender process. On instruction from the Authority the Registry Manager
must send additional information provided by the Authority to Traders via email or to the
Traders EIEP inbox.
Data inputs:
Tender Blocks.
Authority provided information sheet.
Authority provided additional information.

List of non-defaulting Traders and their email address and EIEP folder location.
Parameters:

/optional
Processing:
System:
1. Extracts the Tender Block information for the latest unpublished Tender Round of the defaulting
Trader into a file with the specific naming convention that includes information on which Tender
Round the documentation relates.
2. Transfers the Tender Block documents, along with the Authority provided information sheet to
each non-defaulting Trader’s EIEP inbox.
3. Transmits via EIEP, specific or general tender information to Traders as required by the
Authority.
Registry Manager:
4. Sends an email to Traders to inform them that tender documentation is available. The email
address is the one specified for the delivery of Trader Default information.
5. Transmits via email, specific or general tender information to Traders as required by the
Authority.
411
Version 22.24
Data outputs:
Authority provided information sheet sent to each Trader’s EIEP inbox.
An email sent to Trader’s Trader Default email notification address.
An email and/or EIEP file sent to Traders providing additional information as required.
Tender Block information sent to each Trader’s EIEP inbox:
Tender Block information EIEP transfer file name.

Each component of the file name is underscore delimited.
Sender Char 3 RGST
Utility Type Char 1 E
Recipient Char 4 Recipient Trader participant identifier
File Type Char 7 TDTTNDR (Trader Default Tender)
Report Month YYYYMM
Report Run Date YYYYMMDD
Unique ID Char 60 Tender<x> where <x> refers to the Tender Round, for
example:
 Tender1
File example:
RGST_E_RETB_TDTTNDR_201407_20140709_Tender1.csv
The Tender Block information EIEP file contains a header line and the following comma
separated Tender Block information
Defaulting Trader Char 4 Participant identifier of defaulting Trader
Allocation Identifier Char 1 <x> where <x> refers to the Tender Round.

 NHH
 HHR
 PP
 AMI
 UML
412
Version 22.24

Category

 L
 G
 B

Number of ICPs Numeric 9 Number of ICPs with the same characteristics.

Available
ICPs tendered Numeric 9 Null.

Supplied by Trader in returned file as per the format
specified by the Authority.
The number of ICPs the Trader wishes to tender. Must
be less than or equal to the Number of ICPs and >= 0.
Tariff Numeric 6.6 Null.

Supplied by Trader in returned file.
Tariff against the ICPs tendered, in cents per kWh.
Trader Char 4 Null.

Supplied by Trader in returned file.
Trader participant identifier submitting the tender.
File example:
Detail,Defaulting Trader,Allocation ID,NSP,Distributor Price Category Codes,MEP,Meter Types,Highest Metering
Category,Installation Type,Reconciliation Type,Number of ICPs, ICPs tendered,Tariff,Trader
DET,RETA,1,NETAABC0111,PC1,META,HHR,3,L,GN,1560,,,
DET,RETA,1,NETAABC0111,PC1,META,NHH,1,L,GN,778,,,
DET,RETA,1,NETAABC0111,PC1 PC3,META,HHR,4,L,GN,12,,,
Authority information sheet EIEP transfer file name.

Sender Char 3 RGST
Utility Type Cha 1 E
Recipient Char 4 Recipient Trader Participant identifier
File Type Char 7 TDTTNDR
Report Month YYYYMM
413
Version 22.24
Unique ID Char 60 Tender<x>Information where <x> refers to the tender

number, for example:
 Tender1Information
File example:
RGST_E_RETB_TDTTNDR_201407_20140709_Tender1Information.pdf
(The file type will depend on the type of file supplied, e.g. docx, pdf)
Additional Authority provided additional information EIEP transfer file name.

Sender Char 3 RGST
Utility Type Cha 1 E
Recipient Char 4 Recipient Trader Participant identifier
File Type Char 7 TDTTNDR
Report Month YYYYMM
Unique ID Char 60 Tender<x>AdditionalInformation<z> where <x> refers to

the tender number and <z> is an ascending alpha
identifier, for example:
 Tender1AdditionalInformationA
File examples:
RGST_E_RETB_TDTTNDR_201407_20140709_Tender1AdditionalInformationA.pdf
RGST_E_RETB_TDTTNDR_201407_20140710_Tender1AdditionalInformationB.pdf
RGST_E_RETB_TDTTNDR_201407_20140712_Tender2AdditionalInformationA.pdf
(The file type will depend on the type of file supplied, e.g. docx, pdf)
Email examples:
N.B. Suggested wording only.
Tender documentation:
Heading: Trader Default Tender Documentation
Message text:
The following documents have been transferred to your EIEP inbox
1. ICP Tender documents for tender <tender number>
2. Information Sheet from the Authority
Please familiarise yourself with the information sheet before responding with your bid.
The tender is scheduled to open at <dd/mm/ccyy hh:mm>.

The tender is scheduled to close at <dd/mm/ccyy hh:mm>.
If you have any questions or issues please contact the Authority
414
Version 22.24
Additional information:
Heading: Trader Default Tender Additional Information
Message text:
<free format text provided by the Authority, and/or attachment from the Authority>
<example 1>
The Authority has provided additional information in the attached document. Please review this
information as it may affect your bid.
<example 2>
The Authority has provided additional tender information which has been transferred to your EIEP
in box with the following name:
RGST_E_RETB_TDTTNDR_201407_20140709_Tender1AdditionalInformationA
Please review this information as it may affect your bid.
Impending tender closure:
Heading: Trader Default Tender Closure information
Message text:
Tender <tender number> is due to close at <date/time>.
Please ensure you have submitted your bids before this time.
Tenders received after the above time will be rejected.
Tender closed:
Heading: Trader Default Tender Closure information
Message text:
Tender <tender number> is now closed.
415
Version 22.24
Sub-process: TD-050 Load Trader Bids
Participants: Authority, Trader
Dependencies: SD-020, MP-020, TD-040
Description:
Traders return tender documents containing their bids for each Tender Block of the latest open
Tender Round containing:
 the number of ICPs tendered for
 the tariff to be applied
 Trader who is tendering.
The Registry validates and loads the Trader bids, reporting results to the Trader.
1. Trader bid files must be submitted by file (placed in the SFTP toreg folder).
2. Only bids from the last successful file submitted will be stored for any Trader. Bids for different
Tender Blocks cannot be input in separate files. Therefore a Trader’s bid file must be
considered a complete bid document. If a Trader wants to amend a bid, then the Trader must
submit a complete new file with replacement bids and the header in the file marked ‘Update’.
The previous file and all its bids will be removed (deleted).
3. Traders must be able to remove bid information for the latest Tender Round at any time up to
the time when the round closes by supplying a file with the header in the file marked ‘Removal’.
4. All bid files that arrive while the current tender is open must be accepted even if they are not
processed until after the tender is closed. For example:
a) File arrives at 19:59
b) Tender closes at 20:00
c) File processing starts 20:01
d) File is processed as arrival precedes tender closure
5. The Tariff must be checked against the Authority supplied minimum tariff (SD-020) to ensure (in
the opinion of the Authority) it is not unfeasibly low. Where the tariff falls under the Authority
defined minimum an email must be sent to the participant (MP-020) alerting of a potential issue.
However, the file load process must still continue.
6. An email must be sent to the Traders tender email address (MP-020) stating the success or
failure of the file load.
7. An acknowledgement file must be returned to the submitting Trader.
Data inputs:
Tender Blocks (TD-030)
Trader Bid File
416
Version 22.24
The completed Tender Block information that was provided in the tender documentation EIEP file
described in TD-040 Data Inputs section, for the latest open Tender Round.
It is not necessary to retain the Tender Block Information filename. Any valid filename is
acceptable, e.g. TenderBids_RETA_Round1.txt.
If a Trader wants to load a file of initial bids, or replacement bids, a parameter must be included
with a value of “Update”.
If a Trader wants to remove all previously submitted bids, a parameter must be included with a
value of “Removal”, and with no following input lines.
File examples:
HDR,RQTENDER,RETB,RGST,16/09/2014,09:09:36,3,a tender
PRAM01,Update
PRAM02,RETA
RETA,1,NETAABC0111,PC1,META,HHR,3,L,GN,1560,1000,.35,RETB
RETA,1,NETAABC0111,PC1,META,NHH,1,L,GN,778,500,.30,RETB
RETA,1,NETAABC0111,PC1 PC3,META,HHR,4,L,GN,12,12,.55,RETB
HDR,RQTENDER,RETB,RGST,16/09/2014,09:09:36,3,a tender update

PRAM01,Update
PRAM02,RETA
RETA,1,NETAABC0111,PC1,META,HHR,3,L,GN,1560,500,.32,RETB
RETA,1,NETAABC0111,PC1,META,NHH,1,L,GN,778,500,.30,RETB
RETA,1,NETAABC0111,PC1 PC3,META,HHR,4,L,GN,12,12,.55,RETB
HDR,RQTENDER,RETB,RGST,16/09/2014,09:09:36,3,a tender removal

PRAM01,Removal
PRAM02,RETA
Processing:
System:
1. Verifies that the participant supplying the completed tender file is currently in the role of Trader.
2. Verifies that the Trader is not in a Trader Default situation.
3. Verifies that the Tender Round is open. If the Tender Round is closed the entire file is rejected.
4. Validates the submitted Trader bid file:
a) If a removal is requested, checks that only the two parameter rows are input.
b) If an update is requested, checks that there is at least one bid row following the
parameter rows.
c) Checks each bid file input row matches a Tender Block in the current Tender Round
and that the Number of ICPs Available matches.
d) Checks the bid file contains complete information including:
 Number of ICPs tendered for
 Tariff
417
Version 22.24
 Trader Participant identifier.

e) Checks that the number of ICPs tendered for is not more than the Number of ICPs
Available.
f) Checks that the tariff is not lower than the Authority supplied minimum tariff (SD-020).
If it is, an email is sent to the participant (MP-020) alerting them of a potential issue but
the validation still continues.
5. Accepts or rejects the bid file. If any input line fails validation the entire file is rejected.
6. If the validation succeeds, saves the Trader bid file information removing and/or replacing (as
required by the parameter) any bids that already exist for the submitting Trader in the latest
round. Additional audit information is stored with the bid file identifying:
 date and time the bid file was received loaded; and
 input file name of the bid file.
7. Supplies an acknowledgement file to the submitting Trader with the results of the Trader bid file
validation.
8. Alerts the Trader who supplied the bid file via an email of the success or failure of the bid file
load and any associated warnings.
Data outputs:
Email alert stating file load success or failure.
Updated trader bids for the submitting Trader for the Tender Round.
Acknowledgement file:
Input line Char line as supplied in the Traders input file
Result Code Numeric  Error code, else

 000 – no error,
File example:
HDR,RSACK,RGST,RETB,08/07/2014,12:28:25,00000003,a tender update
PRAM01,Update,000
PRAM02,RETA,000
RETA,NETAABC0111,PC1,META,HHR,3,L,GN,1560,1000,.35,RETB,000
RETA,NETAABC0111,PC1,META,NHH,1,L,GN,778,500,.30,RETB,000
RETA,NETAABC0111,PC1 PC3,META,HHR,4,L,GN,12,12,.55,RETB,000
418
Version 22.24
Example email – note:

 The subject line is fixed, and always contains the filename
 The message text has 3 alternative forms – which one is used depends on the outcome:
o Success with no warning
o Success with low tariff warning
o Errors
 Each of the 3 forms consists of fixed text which is entered by the Registry Manager (for
example when the tender documentation is sent out) and may be modified at any time.
There is no provision for substitution of data (e.g. tariff threshold, closing time, error codes) within
the text.
Tender file load:
Subject: Trader Default Tender File Load – File: <filename>
Message text:
The above file has been processed by the Registry.
The file has been successfully loaded. You may view and download your tender information online.

<or>
The file has been successfully loaded with the following warnings:
The tariff supplied for one or more tender blocks was less than the Authority defined threshold of
0.20.
The file has been successfully loaded. You may view and download your tender information online.

<or>
Your tender file has not been loaded as it contained errors.
Please review the returned acknowledgement file in your SFTP (fromreg) directory, correct and re-
submit.
Remember the tender is scheduled to close at 17:00 on 12/06/2015.
If you have any questions or issues please contact the Authority.
419
Version 22.24
Sub-process: TD-060 View tender bids, tender and mandatory assignment

allocation results
Process: ICP Tendering and Mandatory Assignment
Dependencies: TD-050, TD-070
Description:
A Trader may view and download tender bids they have supplied to the Registry (Trader bid files).
Once the allocation process has run a Trader may also view and download summarised results of
any Tender Round and mandatory assignment.
The Authority may view or download tender bids and allocation results for any Trader.
Summarised allocation results include the number of ICPs allocated to a Trader in a Tender Block
or Mandatory Assignment Block.
1. A Trader must be able to view and download Trader bids supplied in a Trader Default situation,
and the summarised results of the subsequent Tender Round and mandatory assignment
allocation.
2. A Trader must only be able to view/download their own tender Trader bid files and summarised
allocation results.
3. The Authority must be able to view and download the Trader bid files and summarised
allocation results for any Trader.
4. The summarised allocation details must include the number of ICPs allocated to a Trader per
Tender Round, and through the mandatory assignment process.
Data inputs:
All trader bids for all Traders relating to all Tender Rounds (TD-050).
Allocation results. (TD-070).
Parameters:
/optional
Defaulting Trader Char 4 M Participant identifier of Trader in a Trader
Default situation.
420
Version 22.24
Trader Identifier Char 4 M The participant identifier whose tender

allocation or mandatory assignment
results will be displayed. Defaults to
Trader participant identifier.
If Authority, presents a list of Trader

participant identifiers for selection,
otherwise the list contains only the
Trader’s own participant code.
Allocation Identifier Char 1 M List of tenders that have been opened for
the Trader Default situation.
 <x> where <x> refers to the Tender
Round
 M - Mandatory Assignment
 Blank – no filter (show all available)
Processing:
System:
1. Validates the parameters.
2. Retrieves and displays the trader bids submitted by the Trader for the selected Tender Round.
3. If the ICP allocation process has been completed, displays the number of ICPs allocated to the
Trader in each Tender Block or Mandatory Assignment Block.
4. Downloads the information for each Tender Block or Mandatory Assignment Block in csv format
file.
Data outputs:
Additional audit information is displayed and downloaded identifying:

 date and time the Trader bids were received; and
 input file name in which the Trader bids were received
Trader bids and allocation results:
Information is displayed in characteristics then Allocation Identifier order.

Defaulting Trader Char 4 Defaulting Trader participant identifier
Allocation Identifier Char 1 <x> where <x> is the Tender Round number
M – mandatory assignment
Price Category Codes Char 2000 Space separated list of Price Category Codes
MEP Char 4 Meter Equipment Provider participant identifier
421
Version 22.24

 NHH
 HHR
 PP
 AMI
 UML
Highest Metering Numeric 1 1 through 5, or 9, null if not reported

Category
Installation Category Char 1 One of:

 L
 G
 B

ICPs Available Numeric 9 Number of ICPs available in the Tender Block or
Mandatory Assignment Block
ICPs Tendered Numeric 9 Number of ICPs tendered by the Trader. Blank for
Mandatory Assignment.
Allocated Trader Char 4 Trader participant identifier of trader allocated the ICPs.
Null if allocation process not yet run for Tender Round.
Tariff Numeric 6.6 Tariff supplied with bid. Blank for Mandatory
Assignment.
ICPs Allocated Numeric 9 Number of ICPs allocated. Populated only when the
tender and mandatory allocation has been run.
Downloaded file example (before allocation):
Defaulting Trader,Allocation ID,NSP,Price Category Codes,MEP,Meter Types,Highest Metering Installation
Category,Installation Category,Reconciliation Type,ICPs Available,ICPs Tendered,Allocated Trader,Tariff, ICPs Allocated
RETA,1,NETAABC0111,PC1,META,NHH,1,L,GN,12000,5000,RETB,0.29,5000
Downloaded file example (after allocation and including a mandatory allocation):

Defaulting Trader, Allocation ID,NSP,Price Category Codes,MEP,Meter Types,Highest Metering Installation
Category,Installation Category,Reconciliation Type,ICPs Available,ICPs Tendered,Allocated Trader,Tariff, ICPs Allocated
RETA,1,NETAABC0111,PC1,META,NHH,1,L,GN,12000,5000,RETB,0.29,5000
RETA,M,NETZABC0111,PC1,META,PP,1,L,GN,1000,RETB,0,0,25
422
Version 22.24
Sub-process: TD-070 Allocate ICPs
Process: ICP Tendering and Mandatory Assignment
Dependencies: TD-020, TD-050, PR-290
Description:
On instruction from the Authority the Registry Manager will allocate ICPs to Traders based on:
 the Trader bids returned by each Trader, and
 mandatory assignment (if applicable).
Allocation identifies and assigns individual ICPs that will be switched to the gaining Trader during
the Trader Default switch process (TD-080).
The allocation process does not perform Trader Switching.
1. The Registry Manager must be able to allocate ICPs to Traders based on Traders’ bids and
mandatory assignment (if applicable).
2. Any allocation must be able to be re-run and, if re-run, the results of the previous allocation
must be removed and replaced by the new allocation.
3. Once an allocation has been run, there must be an audit trail to show in which Tender Round or
mandatory assignment Traders were allocated specific ICPs.
Data inputs:
List of ICPs currently the responsibility of the defaulting Trader that are active, or inactive but not
ready for decommissioning, and that are not in the process of being switched or withdrawn.
All trader bids for all Traders relating to all Tender Rounds (TD-050).
Traders’ exclusion tables (TD-020).
Market share % of Traders at each NSP for mandatory assignment (PR-290).
Parameters:
/optional
Trader Char 4 M Defaulting Trader participant identifier
Processing:
423
Version 22.24
System:
2. Verifies no tenders are open, and no tender files are currently being loaded.
3. Considers all the ICPs for which the defaulting Trader is currently responsible and excludes all
ICPs that at run time:
a. are subject to a switch in progress; or
b. have a Status other than Active or Inactive; or
c. have a Status of Inactive and a Status Reason of Ready for Decommissioning.
4. Performs the allocation of all bids in Tender Round sequence. If any ICPs remain unallocated
following the final Tender Round, mandatory assignment is performed.
5. When allocating bids, first sorts the bids in ascending Tender Round and Tender Block
sequence. Then for each Tender Round and Tender Block:
a. Ranks Traders’ bids by average cents/kWh (tariff).
b. Sorts the defaulting Trader’s ICPs (excluding those allocated by any previous Tender
Rounds) related to the same Tender Block, by ICP identifier checksum to randomise
the allocation.
c. Allocates ICPs to Trader’s bids with the lowest tariff:
i. If the bid with the lowest tariff is allocated all of the available ICPs in a Tender
Block, that Tender Block’s processing is complete and the process moves to
the next Tender Block.
ii. If there are ICPs still to be allocated in a Tender Block, allocates these ICPs to
the bid with the next lowest tariff. This process repeats until all ICPs in the
Tender Block are allocated.
iii. if there are bids with the same tariff, and there are insufficient ICPs remaining
in the Tender Block to fulfil all their bid volumes, the remaining ICPs will be
shared between those Traders pro rata according to their bid volumes.
iv. if there are fewer bids than ICPs available for allocation of a Trader Block, the
ICPs left over are allocated to bids that were loaded in the subsequent Tender
Round for this Tender Block, if any exist.
6. For a mandatory assignment:
a. For reporting purposes, the ICPs which were not allocated during the bid allocation
process are grouped into “Mandatory Assignment Blocks”, using the same
characteristics as for Tender Blocks.
b. For the purposes of the allocation algorithm which follows, the ICPs at each NSP are
divided into the following groups:
 highest metering category is one of 0, 1 or 2 and has submission type NHH but
not HHR
 highest metering category is one of 0, 1 or 2 and has submission type HHR
 highest metering category is 3
The algorithm is applied to each group, to allocate the ICPs for that group.
c. Does not allocate an ICP to a Trader if that ICP is excluded based on the Trader’s
exclusions table. See the examples in TD-020 for the meaning of the attributes of an
exclusion rule i.e. precisely which ICPs are excluded by the rule.
424
Version 22.24
d. Sorts all Traders on the NSP/group into order based on their market share % of ICPs
for the NSP/group (refer PR-290). E.g. for a particular NSP and the first group in the list
above, the “Mass Market NHH” percentage for that NSP would be used.
e. If there are more Traders than ICPs then the smaller Traders (descending based on
market share) receive no ICPs, otherwise allocates 1 ICP to each Trader.
f. Allocates the balance of ICPs pro-rata, based on Traders individual market share % of
ICPs, with allocations always being rounded up to the next whole number. The
Trader(s) with lowest market share, however, will be allocated the remaining ICPs (if
any) after all other allocations have been made. This may represent less than their pro
rata allocation due to rounding considerations. For example if 126 ICPs are to be
allocated between two Traders who have 70% and 30% of the market share:
 The first will receive 89 (126 * 0.70 rounded up)
 The second will receive 37 (the rest)
g. If exclusion rules prevent one or more traders being allocated their full quota of ICPs as
calculated above, then the remaining ICPs are allocated to other traders, pro-rata
based on their market share, to the extent that their exclusion rules allow. This process
continues until all ICPs which can be allocated are allocated
7. Stores the allocation details against each and every ICP of each Tender Block or Mandatory
Assignment Block. The allocation details to include:
 Allocated Trader
 Allocation Identifier in which allocated.
 Tariff supplied with bid.
If an ICP is not allocated in any Tender Round or in mandatory assignment, the reason for
non-allocation should be stored against the ICP. Currently the only possible reason is “No
Trader Available”
8. Notifies Traders via email that the allocation(s) are complete and runs a PR-310 report on their
behalf with the detail option selected, and Allocation Identifier = blank (all).
9. Reports results of allocation to the Authority and Traders.
Data outputs:
Report sent to Authority of allocation results (PR-300 with ICP detail).
Email to Traders informing that allocation has been run.
Reports sent to Traders of their allocation results (PR-310 detail).
Allocation results (stored in database):
ICP Identifier Char 15 ICP identifier
Defaulting Trader Char 4 Participant identifier of defaulting Trader
Allocation Identifier Char 1 <x> where <x> refers to the Tender Round of the bid or
M – mandatory assignment.
425
Version 22.24

 NHH
 HHR
 PP
 AMI
 UML

Category

 L
 G
 B

Allocated Trader Char 4 Trader participant identifier of trader allocated the ICP.
Null if unallocated.
Tariff Numeric 6.6 Tariff from the bid. Null for Mandatory Assignment.
Non-allocation Reason Char 1 N – No Trader Available. Only applicable where

Allocated Trader is null.

Example Email
Completion of tender allocations
Heading: Trader Default Allocation is Complete
Message text:
The Trader Default allocation process has been run. Results of the allocation are available for
review. Report PR-310 Report Trader Default Allocation Results is available in your fromreg
directory.
The Registry is now awaiting approval from the Authority to commence switching of allocated ICPs
to their new Traders.
426
Version 22.24
Sub-process: TD-080 Switch Trader Default Trader ICPs
Process: ICP Tendering and mandatory assignment
Description:
On instruction from the Authority the Registry Manager will initiate switching based on the results of
the allocation process (TD-070) and ICP re-assignment process (TD-090).
ICPs under the responsibility of a defaulting Trader will be switched to a non defaulting Trader, the
Registry will control all aspects of the switch, submitting switch messages on behalf of all Traders
involved.
Note that due to the possibility of an ICP’s characteristics changing since the allocation run (TD-
070), an ICP may be switched to a Trader on the basis of a bid which was for a Tender Block with a
different set of characteristics.
1. On instruction from the Authority, the Registry Manager must initiate switching of ICPs from the
defaulting Trader to non-defaulting Traders based on the results of the tender(s) and
mandatory assignment.
2. The Registry Manager must report to the Authority the results of all the switch messages.
Data inputs:
Allocation results but only those with allocation details i.e. ignore ICPs with non-allocation reasons.
(TD-070).
Parameters:
/optional
Trader Char 4 M Defaulting Trader participant identifier
Processing:
System:
1. Verifies the Trader is in Trader Default.
427
Version 22.24
2. Verifies the allocation process has been run.

3. Stops attempting to switch an allocated ICP if the ICP has been updated since the allocation
process has been run and the ICPs trader responsibility or status has changed to any of:
a) Switch in progress – a customer has requested a switch between days 15-18;

b) ICP decommissioned – network has decommissioned a previously inactive ICP.
c) ICP already switched away from the defaulting Trader between days 15 and 18.
4. Creates and submits switch NT messages on behalf of the gaining Trader for the ICPs
allocated to them using the following default values:
a) Requesting Trader – the gaining Trader participant identifier, the Trader who has been
allocated the ICP.
b) Confirmation address details – optional fields, left null.

c) Proposed Transfer Date – optional field, left null.
d) Switch Type – one of:
i. TA – Tender 1
ii. TB – Tender 2
iii. MA – Mandatory Assignment.

e) Proposed Profiles – if there is a standard profile(s) at the ICP that profile(s) will be
used. If a non standard profile(s) exists, profile RPS will be used unless RPS already
exists. A standard profile is one of RPS, PV1, EG1, UML or HHR.
f) Proposed ANZSIC – optional field, left null

g) User Reference – “TDT ‘x’ allocation” where ‘x’ refers to the switch type. For example
TDT TA allocation
5. Supplies a report of all NT message rejections to the Authority that are not benign.
6. Generates and submits switch CS messages for each valid NT generated using the following
default values:
a) For the Premises row:
i. Trader – Trader participant identifier of defaulting Trader
ii. Actual Transfer Date – date of the switch i.e. day 18 of the Trader Default
situation
iii. User Reference – “TDT ‘x’ allocation” where ‘x’ refers to the switch type e.g.
TDT MA allocation.
b) For each Metering Installation that has channels requiring readings:
i. Metering Installation Number – obtained from the Metering information held on
the Registry
ii. Average Daily Consumption – 0
iii. Key Held Indicator – N
c) For each Metering Component in the installation with at least 1 Channel with an
Accumulator Type of “C” and Settlement Indicator of “Y”:
the Registry
428
Version 22.24
ii. Metering Component Serial Number – obtained from the Metering information
held on the Registry
iii. Last Read Date – Trader Default start date minus 1 day
iv. Meter Reader Notes – null
d) For each channel with an Accumulator Type of “C” and Settlement Indicator of “Y”:
the Registry
ii. Metering Component Serial Number – obtained from the Metering information
held on the Registry
iii. Channel Number – obtained from the Metering information held on the Registry
iv. Reading – 1
v. Actual or Estimate - E
7. Forwards CS file to the gaining Trader that is identical to the standard file definition (as per RS-
050) with the following difference:
a) File Type definition of RSTDTCS, e.g. HDR,RSTDTCS,RGST,RETB,<standard
convention>
8. Considers the CS as a normal switch and performs all appropriate and necessary activities as
defined in RS-050 including:
a) Generation of PR-030 to the gaining Trader;
b) Forwarding of the CS switch message to the gaining Trader, current Distributor and
current MEP.
9. Supplies report of CS message rejections to the Authority.
Data outputs:
 NT switch messages
 A Report detailing NT switch message that have been rejected by Registry validation
 CS switch messages forwarded to gaining Trader, Distributor and Metering Equipment Provider.
Trader CS message file contains amended header File Type identifier
 ICP updated to no longer switch in progress.
 Trader event.

 Snapshot Event Detail report (PR-030) for each ICP switched, to the new Trader.
 Notifications.
 A Report detailing CS switch message that have been rejected by Registry validation.
429
Version 22.24
Report sent to the Authority detail switch messages rejected by Registry validation (of NT and CS
messages generated and processed):
The output file name will be TD080_SwitchMessageRejections<timestamp>.csv where timestamp

is format “yyyymmddhhmmss” and specifies the run date of the update.
ICP Identifier Char 15 ICP identifier
Switch Message Char Switch message submitted
Error Code Char 3 Error code
Description Char Error code description
File contains header followed by output lines.
Example from submission of switch NT message

ICP Identifier,Switch Message,Error Code,Description
1234567999ABC13,NT,677,ICP Status invalid for switch
1234567666ABC14,NT,229,Switch in progress
Example from submission of switch CS message

ICP Identifier,Switch Message,Error Code,Description
1234567999ABC13,CS,677,ICP Status invalid for switch
1234567666ABC14,CS,229,Switch in progress
430
Version 22.24
Sub-process: TD-090 ICP re-assignment process
Process: ICP Tendering and mandatory assignment
Description:
After ICP allocation is complete, and prior to the start of ICP switching, the Authority may adjust
ICP allocations for mandatory assignment by re-assigning individual ICPs to Traders, in batch
mode only.
Allocation maintenance may be due to:

 Requests from individual Traders where ICP allocation through mandatory assignment
would pose a serious threat to the financial viability of the recipient Trader, or
 Traders unable to cater for ICPs with specific characteristics, or
 Assignment of unallocated ICPs remaining after the mandatory assignment process
completed.
1. The Allocate ICPs process (TD-070) for a defaulting Trader must be complete and switching of
ICPs (TD-080) not started.
2. The Authority must be able to select one or more ICPs by ICP identifier, and allocate each ICP
to a new Trader.
3. The Trader allocated to each ICP must not be in a Trader Default situation, and must currently
fulfil the role of Trader.
4. Only ICPs which were not allocated or were allocated by mandatory assignment are able to be
adjusted.
Data inputs:
Allocation results. (TD-070). Only select results where Allocation Identifier = M (mandatory
assignment) or where there is a non-allocation reason.
Allocation results extract:

/optional
Defaulting Trader Char 4 M Participant identifier of Trader in a
Trader Default situation
ICP Identifier Char 15 M ICP to be allocated to the Gaining
Trader
431
Version 22.24
Gaining Trader Char 4 M Participant identifier of Trader

who is being allocated the ICP
Example:
HDR,RQTDTICPMT,EMCO,RGST,09/12/2013,13:57:59,3,transfer ICP Allocations
DET,RETA,0001234569AB123,RETZ
DET,RETA,0002341237BB490,RETZ
DET,RETA,0000045540BC333,RETX
Processing:
System:
1. Verifies the Defaulting Trader is in a Trader Default situation.
2. Verifies that the Allocation process (TD-070) for the Defaulting Trader has been run, and
Switch Trader Default Trader ICP (TD-080) has not been run.
3. For each ICP in the input file, checks that:
a. The ICP currently belongs to the Defaulting Trader.
b. The ICP has either not been allocated, or was allocated during Mandatory Assignment
(ICPs allocated as a result of tender bids are excluded).
c. The gaining Trader is not in a Trader Default situation.
d. The gaining Trader is currently active in the role of Trader.
4. Allocates the ICP to the Gaining Trader.
5. Notifies Traders via email that the allocation(s) are complete and runs a PR-310 report on their
behalf with the detail option selected for this allocation.
6. Reports results of allocation to the Authority and Traders.
Data outputs:
Updated allocation results.
Acknowledgement file.
Input line Char line as supplied in the input file
Result Code Numeric  Error code, else

 000 – no error
Result Code Description Char If Result Code is not 000 this contains a brief description
of the error
Example:
HDR,RSACK,RGST,EMCO,09/12/2013,13:57:59,3,transfer ICP Allocations
DET,RETZ,0001234569AB123,RETZ,776,Trader is not in default
DET,RETA,0002341237BB490,RETB,777,Gaining Trader is in default
DET,RETA,0000045540BC333,RETX,778,ICP does not belong to Defaulting Trader
432
Version 22.24
Email to Traders (those who have either lost or gained ICPs during the adjustment) informing them
that adjustments have been made.
Reports sent to Traders (those who have either lost or gained ICPs during the adjustment) of their
allocation results (PR-310 detail) with the Allocation Identifier parameter set to M.
Example Email
Adjustment to mandatory assignment allocations
Heading: Trader Default Allocation Adjustment is Complete
Message text:
Adjustments have been made to the Mandatory Assignment allocations from the Trader Default
allocation process previously notified. Results of the adjusted Mandatory Assignment allocation are
available for review. Report PR-310 Report Trader Default Allocation Results is available in your
fromreg directory. This does not include tender allocations.
The Registry is now awaiting approval from the Electricity Authority to commence switching of
allocated ICPs to their new Traders.
433
Version 22.24
Sub-process: PR-300 Report Trader Default tender and mandatory assignment
Process: Provide reports
Description:
The Authority may request to see summarised or detailed results of a Tender Round or mandatory
assignment. For a Tender Round, the report may be run either whilst the Tender Round is in
progress or after it has closed.
When run for a Tender Round, the report provides an overview of the Tender Round’s progress, by
Tender Block, including information on potential or actual over/under subscription of ICPs.
The report also allows early identification of Tender Blocks which are undersubscribed that will form
part of a mandatory assignment.
1. The report must be available to the Authority only.

2. The report must specify the defaulting Traders Participant identifier.
3. The report must allow selection by Allocation Identifier, or all Allocations (all Tender Rounds
and mandatory assignment).
4. Any tender, closed or in-progress must be able to be reported.
5. The report must be available in summary or detail form.
6. For a Tender Round, the detail level determines the output as follows:
a. Summary – provides a breakdown for each Tender Block and the over- or under-
subscription.
b. Trader detail – provides a breakdown as per the summary but additionally must report
Traders bid information such as the volume of ICPs bid per Tender Block and the
Tariff.
c. ICP detail – only available when the allocation process has been run. Provides a
breakdown as per the summary but additionally provides allocation details or the non-
allocation reason of each ICP of each Tender Block.
7. For Mandatory Assignment, the detail level determines the output as follows:
a. Summary – provides the number of ICPs allocated in each Mandatory Assignment
Block.
b. Trader detail – provides a breakdown as per the summary but also provides the
number of ICPs allocated to each Trader in each Mandatory Assignment Block.
c. ICP detail – provides a breakdown as per the summary but additionally provides
allocation details or the non-allocation reason of each ICP of each Mandatory
Assignment Block.
434
Version 22.24
Data inputs:
Tender Blocks (TD-030)
Trader bid files (TD-050).
Parameters:
Each parameter is preceded by a line type identifier or “PRAMnn” where nn refers to the parameter
number
Leaving an optional parameter blank it is assumed that ALL values are required.
Multiple space separated values may be input for tender identifier
/optional
Defaulting Trader Char 4 M Defaulting Trader participant identifier
Allocation Identifier Char 1 O Space separated.

Any combination of
 <x> where <x> is the Tender Round
number
 M – Mandatory Assignment
 Blank indicates all rounds
Report Detail Level Char 1 O S – Summary only (the default)

T – Summary and Trader details
I – Summary and ICP details
Unallocated ICPs only Char 1 O Only applies to Report Detail Level I.

Y or N. Defaulted to No.
If Y then the report only selects the ICPs
where there is no Allocated Trader.
File Example
HDR,RQTNDRLIST,EMCO,RGST,27/12/2001,11:13:12,3,Summary Tender 1_Mandatory
PRAM01,RETA
PRAM02,1
PRAM03,S
HDR,RQTNDRLIST,EMCO,RGST,27/12/2001,11:13:12,3,Detail summary and trader bids

PRAM01,RETA
PRAM02,
PRAM03,T
HDR,RQTNDRLIST,EMCO,RGST,27/12/2001,11:13:12,4,Details down to ICP level

PRAM01,RETA
PRAM02,2
435
Version 22.24
PRAM03,I
PRAM04,N
Processing:
System:
1. Verifies the Trader is in a Trader Default situation.
2. Verifies the parameters.
3. Extracts information from the Tender Blocks or Mandatory Assignment Blocks, ICPs related to
these and the Trader Bid files provided by Traders that satisfy the parameters.
4. Reports the information to the level required – summary only, summary and trader details or
summary and ICP details.
Data outputs:
The output file name is PR300_TenderResults<timestamp>.csv where timestamp is format

“yyyymmddhhmmss” and specifies the report run time
Summary output.
Tender Block information sorted by Allocation Identifier and characteristics sequence.
NSP Char 11 NSP identifier

 NHH
 HHR
 PP
 AMI
 UML

Category

 L
 G
 B
436
Version 22.24

Number of ICPs Numeric 9 Number of ICPs available for tender in the Tender Block
available for Tender in the Tender Round. Null for a Mandatory Assignment
Block.
Number of ICPs Numeric 9  Number of ICPs available in the Tender Block or

available for allocation Mandatory Assignment Block at allocation time.
 Null for a Tender Block before the allocation has
been run
 For a Tender Block after the allocation has been
run, this may be different from Number of ICPs
available for Tender, due to switching or change of
characteristics or status of ICPs.
ICPs tendered Numeric 9 For a Tender Round, the total volume of bids tendered
by all Traders. Null for a Mandatory Assignment block.
ICPs allocated Numeric 9  The total number of ICPs in the block allocated to all
Traders.
 Null for a Tender Block before the allocation has
been run
Subscription Numeric 9 Over or under(-) subscription for the Tender Block. Null
for a Mandatory Assignment Block.
Trader details output, additional comma separated values appearing under the related summary
line. Sorted by Trader.
Trader Char 4 Allocated Trader participant identifier.
Allocation Identifier Char 1 One of:

 <x> where <x> is the Tender Round number
 M – mandatory assignment
ICPs Bid Numeric 9 Number of ICPs this Trader has tendered in their bid in
this Tender Round for the Tender Block. Blank for a
Mandatory Assignment Block.
Tariff Numeric 6.6 Tariff supplied by this Trader in the bid. Blank for a
Mandatory Assignment Block.
ICPs allocated Numeric 9 Number of ICPs allocated to the Trader in this Tender
Round for the Tender Block (field populated only after
allocation process has run).
ICP detail output, additional comma separated values appearing after the related Summary line.
Sorted by allocated Trader.
ICP identifier Char 15 ICP number
437
Version 22.24
Allocation Identifier Char 1 One of:

 <x> where <x> is the Tender Round number
 M – mandatory assignment
Allocated Trader Char 4 Trader participant identifier of trader allocated the ICP.
Null if ICP was not allocated to a trader in this Tender
Round.
Tariff Numeric 6.6 Tariff supplied by this Trader.

Null if ICP unallocated, or Mandatory Assignment.
Reason for non- Char 1 Null if ICP allocated.

allocation N – No Trader Available
Example of summary option for tender 1:

HDR,RSTNDRLIST,EMCO,RGST,27/12/2001,11:13:12,3,Summary results
RETA,1,NETANETA001,PCAT1,META,NHH,0,L,GN,5,4,1,1,-4
RETA,1,NETANETA001,PCAT1,META,HHR,1,L,GN,4,4,10,4,6
RETA,1,NETANETA001,PCAT2,META,NHH UML,0,L,GN,1,1,0,0,-1
Example of trader detail option for all Tender Rounds:

HDR,RSTNDRLIST,EMCO,RGST,27/12/2001,11:13:12,9,Detail results of Tender
RETA,1,NETANETA001,PCAT1,,NHH,0,L,GN,5,,1,,-4
RETB,1,1,0.30,
RETA,1,NETANETA001,PCAT1,META,HHR,1,L,GN,4,,10,,6
RETB,1,4,0.32,
RETC,1,4,0.30,
RETD,1,2,0.30,
RETA,1,NETANETA001,PCAT2,,NHH UML,0,L,GN,1,,0,,-1
RETA,1,NETBNETB001,PCAT1,META,HHR,3,L,GN,5,,11,,6
RETB,1,3,0.31,
RETC,1,3,0.30,
RETD,1,5,0.32,
Example of ICP detail option for all Tender Rounds

HDR,RSTNDRLIST,EMCO,RGST,27/12/2001,11:13:12,9,Detail results of Tender
RETA,M,NETANETA001,PCAT1,,NHH,0,L,GN,,1,,1,
0000000110AAD7C,M,RETD,,
RETA,M,NETBNETB001,PCAT1,META,NHH,1,L,GN,,1,,1,
0000000215AA330,M,RETC,,
RETA,M,NETBNETB001,PCAT1,META,NHH PP,1,B,SB,,1,,0,
0000000218AAC6B,M,,,N
438
Version 22.24
Sub-process: PR-310 Report Trader Default allocation results
Process: Provide Reports
Description:
A Trader may report their own ICP allocations for a Tender Round or mandatory assignment once
the allocation process has been run for the relevant allocation identifier. The report is available in
either summary or detail form.
The Authority may report the results of any Tender Round for any Trader.
1. A Trader must only be able to report the results of their own ICP allocations.
2. The Authority must be able to report the allocation results for a specific Trader.
3. The report must be available in summary or detail form. When requested in summary, the
Tender Block or Mandatory Assignment Block information must be summarised with the
number of ICPs allocated to the Trader. When requested in detail form, Tender Block or
Mandatory Assignment Block information must be reported with the individual ICP identifiers
and the current address information.
Data inputs:
ICP address events
Parameters:
/optional
Defaulting Trader Char 4 M List of participant identifiers in a Trader
Default situation. One of whom must be
selected.
439
Version 22.24
Trader Identifier Char 4 M The participant identifier whose tender

allocation will be reported. Defaults to
Trader participant identifier.
If Authority, presents a list of Trader

participant identifiers otherwise only the
submitting Trader will be listed.
Allocation Identifier Char 1 O Space separated.

Any combination of
 <x> where <x> is the Tender Round
number
 M – Mandatory Assignment
 Blank indicates all rounds
Summary or Detail Char 1 M S – Summary
D - Detail
File example:
HDR,RQTDTALLOC,RETB,RGST,23/09/2014,09:01:17,4,My Allocated ICPs
PRAM01,RETA
PRAM02,RETB
PRAM03,M
PRAM04,D
Processing:
System:
1. Validates report selection criteria.
2. Validates that the allocation process has been run for the defaulting Trader and if not rejects
the request.
3. Generates either summary or detail output extracting the address details from the latest
Address Event of the ICP.
4. Delivers output to requesters fromreg directory.
Data outputs:
 “PR310_ICPAllocation<timestamp>.csv” where timestamp is format “yyyymmddhhmmss”

and specifies the report run time
NSP Char 11
440
Version 22.24
MEP Char 4 Meter Equipment Provider participant identifier

 NHH
 HHR
 PP
 AMI
 UML

Category

 L
 G
 B

Allocated Trader Char 4 Trader to which the ICP was allocated in the allocation
process.
Summary request: The following attribute is appended to the row detailed above.
ICPs allocated Numeric 9 Total number of ICPs allocated to the Allocated Trader
in the Tender Block.
Detail request: The following attributes are appended to the row detailed above.
Tariff Numeric 6.6 Tariff supplied by the Trader.
Physical Address Unit Char 20
Physical Address Char 25

Number/ RAPID
Number
Physical Address Street Char 30

Suburb
Physical Address Town Char 30
Physical Address Post Numeric 4

Code

Region
441
Version 22.24
Address Property Name Char 75
GPS_Easting Numeric 7.3 The easting location
GPS_Northing Numeric 7.3 The northing location

Summary option example:
HDR,RSTDTALLOC,RGST,RETB,23/09/2014,09:01:17,3, My Allocated ICPs
DET, RETX,1,NETAABC0111,PC1,META,NHH,1,L,GN,RETB,100
DET, RETX,1,NETAABC0111,PC1,METB,NHH,1,L,GN,RETB,850
DET, RETX,1,NETAABC0222,PC1,META,NHH,1,L,GN,RETB,275
…
Detail option example:

HDR,RSTDTALLOC,RGST,RETB,23/09/2014,09:01:17,1225,My Allocated ICPs
DET,RETX,1,NETAABC0111,PC1,META,NHH,1,L,GN, RETB,1234567890AB123,.28,A.23,Kelvin
Drive,,Temuka,8877,Canterbury,123.55,321.77
DET,RETX,1,NETAABC0111,PC1,META,NHH,1,L,GN, RETB ,4455789333CDAB2,..30,.455,Leonard
Street,,Auckland,1455,Auckland,457.22,321.12
…
442
Version 22.24
3.13 Publish Information

Sub-process: PI-010 Publish information
Process: Publish information
Participants: Public, Participants, Authority
Code references:
Dependencies:
Description:
The Registry provides open access to any member of the public, via the Internet, to all documents
relating to the Registry, such as the Functional Specification and User Guide.
1. The Registry must allow open access to the following documents:

 The latest copy of the Registry Functional Specification
 The Registry User Guide.
 Error codes used in the Registry and data hub.
 Registry Access Policy.
 Participant Identifier list.
 ICP Checksum calculator
 Registry News
 Web Services guide
 FAQ where the FAQ is not considered internal or commercially sensitive
 Trouble Shooting guide where the Trouble Shooting is not considered internal or
commercially sensitive.
2. The Registry must maintain a set of FAQ and a Trouble Shooting guide. A FAQ or Trouble
Shooting issue must be either:
a. publically available (public), or
b. available only to registered users of the Registry (internal or commercially sensitive).

3. Internal or commercially sensitive FAQ and Trouble Shooting must be at the discretion of the
Authority.
4. The Registry must publish the Registry helpdesk contact details.

5. The Registry must allow access by the Authority to the User Business Continuity Plan.
Data inputs:
443
Version 22.24
 Document request.
Processing:
System:
1. Depending on the type of user, displays the name of the permitted documents for selection.
2. Either permits the document to be opened/downloaded, or navigates the requester to the
destination page if the document is a link to a web page.
3. Displays the helpdesk contact details.
Data outputs:
 Requested document or web page.

 Helpdesk contact details.
444
Version 22.24
Appendix 1: Calculation of the ICP checksum
Retail competition committee
27 January 1999
Approach to generating checksums for unique IDs v1.1

Executive summary
This paper considers the requirements for the checksum to be used with the Unique ID. Based
on the requirements outlined in this paper an approach to generating the checksum is
prescribed. This approach should be used by networks to generate Unique IDs initially and all
parties to validate the Unique IDs.
445
Version 22.24
Version control
Version Date amended Comments
1.0 19/1/1999 Original version issued to industry.
1.1 27/1/1999 Revised test data.
2.0 27/01/2012 Updated to reflect transition to the Electricity

Authority and updates to parts 11 and 15 of the
Code.
446
Version 22.24
Introduction
Background To facilitate the switching of customers from one Trader to another, every
Installation Control Point (ICP)1 in New Zealand has a unique ICP identifier.
The unique ICP identifier consists of a numerical sequence provided by the

Distributor who is creating the ICP Identifier, a code assigned by the Authority, and
a checksum. Each ICP Identifier has a maximum of 10 numbers followed by two
letters (the code assigned by the Authority).
The numbering scheme adopted across the industry is set out in the Unique ID –
Installation Control Point v1.2 paper dated 12 January 1999.
Each ICP Identifier must be created in accordance with the following format:
ICP Identifier = (numerical sequence + Authority-assigned code + checksum)

where:
ICP Identifier = yyyyyyyyyyxx-checksum,
And:
ICP {numerical sequence (yyyyyyyyyy) + Authority generated Code (xx)} =

yyyyyyyyyyxx.
The purpose of this paper is to outline the approach for generating and validating
the checksum.
Introduction The paper is divided into two main sections. The first section considers the
requirements for the checksum. The second section prescribes in detail the
method to generate and validate the checksums based on this requirement.
1 ICP is defined as being 1 of more of the following: (a) a point of connection at which a customer
installation is connected to a network other than the grid, or (b) a point of connection between a network
and an embedded network, or (c) a point of connection between a network and shared unmetered load.
447
Version 22.24
Checksum requirements
Factors to A checksum is used to help ensure that a number has been correctly transmitted
consider
without corruption. The checksum provides additional information that can be used
to validate the number provided and with some level of confidence indicate whether
an error has been introduced into the number. No checksum can guarantee that an
error has not been introduced but depending on the complexity of the checksum,
varying degrees of certainty can be provided. When considering the type of
checksum to use, the degree of confidence that is required in the number and the
implications if the number is wrong should be considered.
The checksum must be capable of being printed and should be kept as short as
possible.
Implications if The ICP Identifier is the sole mechanism for identifying a record in relation to an
the ICP
ICP in the registry. The registry does not contain any other field specific to ICP
Identifier ID is
incorrect (such as name or address) that could be used to check information about the ICP.
Therefore the ICP Identifier provided to the registry must be correct.
Every time a registry record is accessed or modified, the ICP Identifier must be
quoted. The worst possible result of an ICP Identifier being used incorrectly relates
to the Trader switching process. A gaining Trader will obtain the ICP Identifier from
a customer they have signed up and will advise the registry of this change. If the
wrong ICP Identifier is provided to the registry (either because it was incorrectly
given by the customer or incorrectly entered by the Trader), the record for the
Trader will be amended incorrectly. This will result in the losing Trader not being
given incorrect information as to which ICP it no longer supplies. The net result to
the customers will be that the customer whose ICP Identifier number was
incorrectly given to the registry as being the ICP Identifier of the ICP being switched
will receive a closing account notification, despite never asking to change Trader,
and the customer that has changed Traders will receive two bills.
A Trader quoting the incorrect ICP Identifier when switching an ICP will also
eventually affect the reconciliation process, although the error but may go
undetected for some time.
These scenarios are just two examples of the potential impact on customers and
companies if an ICP Identifier provided to the registry is incorrect.
448
Version 22.24
Level of When the registry is fully populated there will be approximately 2.04 million ICP
confidence Identifiers. If we assume that 5 percent of customers change Traders each year,
required
there will be 80,000 change of Trader requests. A prudent assumption is that in 10
percent of these cases some form of error may be introduced in the communication
of the ICP Identifier from the customer to Trader and then to the registry. This will
result in 8,000 incorrect transactions.
If the checksum is capable of spotting 99 percent of errors this would still mean that
each year 80 people would receive incorrect account closures and a further 80
people would receive two bills. If the checksum is capable of spotting 99.9 percent
of errors this number falls to 8 each year. These errors would be additional to any
other errors currently occurring in the system.
The above example is only one type of possible errors, and it is likely that there will
be a much larger number of other types of transactions, including enquiries,
changes of Profile, changes of Meter Owner, addition or deletion of ICPs etc. All
these transactions will have some adverse impact on customers or companies if
the ICP Identifier is entered incorrectly.
The number of errors each year is greatly dependent on the number of transactions
and the number of times that a number is entered incorrectly. As there is no other
way of cross checking an ICP Identifier in the registry it is clear that ideally the
checksum should be able to detect as many errors as possible.
449
Version 22.24
Specifying the checksum

Expert advice The approach outlined below has been developed through discussions between the
Implementation Team and Dr Anand Venkataraman, lecturer in computer science
at Massey University.
Overall The ideal scenario is one in which the space of ICP Identifier is designed with a
approach specified Hamming distance.2 However, there are two constraints which limit the
way in which this issue can be addressed.
The checksum needs to consist of printable characters.
The checksum needs to be small, preferably no bigger than 3 characters.

Since the total number of possible customer IDs is approximately 6.76*1012 (all
possible numbers between 0 and 1010 followed by all possible combinations of two
letters), which is greater than the number of allowable checksums, it is inevitable
that more than one valid ICP Identifier will end up sharing the same checksum.
Thus the aim is not to detect all errors, but to minimise the likelihood of errors going
undetected.
It is proposed that a polynomial code (Cyclic Redundancy Check or CRC)3 is used

to generate the checksum. The theory behind such a scheme can be found
described in such works as Data and Computer Communications4. A two digit
decimal checksum would spot about 98.4 percent of all errors. However by using a
three three-digit hexadecimal checksum it will detect more than 99.9 percent of all
errors. In order to maximise the error detection based on the requirements outlined
above it has been decided that a three digit hexadecimal checksum will be used.
2 Hamming, R. W. (1980). Coding and Information Theory, 2nd ed., Prentice-Hall, Englewood Cliffs, NJ.
3 Peterson W. W. and D. T. Brown. (1961). Cyclic Codes for Error Detection, Proc. IRE, v.49, pp.228-235, Jan 1961.
4 Stallings, W. (1997). Data and Computer Communications, 5th ed., Prentice-Hall, Englewood Cliffs, NJ.
450
Version 22.24
Calculating the The 15 characters comprising the ICP Identifier are viewed as a stream of 96 bits
checksum where each character of the ID is simply treated as an ASCII bit string regardless of
its type (numeric or alpha).
The bits can be imagined to represent a polynomial in x of the 95th degree where
their values represent the co-efficients of the corresponding powers of x. (Eg
101101 represents x5 + x3 + x2 +1). Let this polynomial be the Message
polynomial M.
We choose a generator polynomial of degree n, where n is the number of bits

desired in the checksum. Call this polynomial G.
We divide G into M*2n to get remainder R using modulo-2 long division.
This remainder R is then subtracted from M*2n again using modulo-2. This gives a
polynomial that is guaranteed to be divisible by G.
M*2n - R is the complete frame (message including checksum).
If either the message or the checksum is corrupted in transit, then the checking
procedure will find that M'*2n-R' is not divisible by R' and so can report an error.
A wise choice of the generator polynomial can guarantee to catch most errors. The
international standard polynomial CRC-12 which is x12 + x11 + x3 + x2 + x + 1
(180F HEX) is proposed. Some advantages of this choice are:
It has been shown that G should ideally have at least three 1s in it. CRC-12 has
six.
It has (x+1) as a prime factor. It has been shown that this property enables it to
catch all odd numbers of bit errors as well.
Algorithm to Initialise a 2-byte register R to zero.

calculate the
checksum Initialise a 2-byte divisor D to 180F hex (00011000 00001111)
Append 12 bits all equal to zero to the end of the ICP
FOR each bit of the ICP (left to right): DO
Shift that bit into the 20 bit position of R
IF the 21 bit position of R is 1 THEN
R = R XOR D
ENDIF
END
Append R as 3 digit hexadecimal integer to the ICP.
451
Version 22.24
Algorithm to Remove the last three (hexadecimal) digits of a given ICP Identifier
validate the
checksum Compute and append checksum using Algorithm above.
IF result is equal to given ICP Identifier THEN
Given customer ID was valid.
ELSE
Given customer ID was invalid.
ENDIF
Intellectual The method described in this document does not infringe on any Intellectual
property rights Property Rights.
Code available Software is available from the Implementation Team (free of charge) to calculate
and validate checksums. The code is available in C / C++ and Unix Command /
Perl languages.
Printing the The checksum should be separated from the ICP by a dash to improve the
checksum
readability of the number.
The format of the Unique ID is to be as follows:
The UI = (ICP + Checksum)
Where:
UI = yyyyyyyyyyxx-ccc,
And:
ICP {Existing code (yyyyyyyyyy) + network ID (xx)} = yyyyyyyyyyxx.
452
Version 22.24
Sample ICP Identifiers

The following sample ICP Identifiers have been produced using the approach outlined in
this paper:
0230994598FDDF1 0230994599FD1B4 0230994600FD301 0230994601FDF44 0230994602FD384
0230994603FDFC1 0230994604FD20B 0230994605FDE4E 0230994606FD28E 0230994607FDECB
0230994608FD115 0230994609FDD50 0230994610FD9AC 0230994611FD5E9 0230994612FD929
0230994613FD56C 0230994614FD8A6 0230994615FD4E3 0230994616FD823 0230994617FD466
0230994618FDBB8 0230994619FD7FD 0230994620FDE54 0230994621FD211 0230994622FDED1
0230994623FD294 0230994624FDF5E 0230994625FD31B 0230994626FDFDB 0230994627FD39E
0230994628FDC40 0230994629FD005 0230994630FD4F9 0230994631FD8BC 0230994632FD47C
0230994633FD839 0230994634FD5F3 0230994635FD9B6 0230994636FD576 0230994637FD933
0230994638FD6ED 0230994639FDAA8 0230994640FD1A4 0230994641FDDE1 0230994642FD121
0230994643FDD64 0230994644FD0AE 0230994645FDCEB 0230994646FD02B 0230994647FDC6E
0230994648FD3B0 0230994649FDFF5 0230994650FDB09 0230994651FD74C 0230994652FDB8C
0230994653FD7C9 0230994654FDA03 0230994655FD646 0230994656FDA86 0230994657FD6C3
0230994658FD91D 0230994659FD558 0230994660FDCF1 0230994661FD0B4 0230994662FDC74
0230994663FD031 0230994664FDDFB 0230994665FD1BE 0230994666FDD7E 0230994667FD13B
0230994668FDEE5 0230994669FD2A0 0230994670FD65C 0230994671FDA19 0230994672FD6D9
0230994673FDA9C 0230994674FD756 0230994675FDB13 0230994676FD7D3 0230994677FDB96
0230994678FD448 0230994679FD80D 0230994680FD64B 0230994681FDA0E 0230994682FD6CE
0230994683FDA8B 0230994684FD741 0230994685FDB04 0230994686FD7C4 0230994687FDB81
0230994688FD45F 0230994689FD81A 0230994690FDCE6 0230994691FD0A3 0230994692FDC63
0230994693FD026 0230994694FDDEC 0230994695FD1A9 0230994696FDD69 0230994697FD12C
0230994698FDEF2 0230994699FD2B7 0230994700FDA05 0230994701FD640 0230994702FDA80
0230994703FD6C5 0230994704FDB0F 0230994705FD74A 0230994706FDB8A 0230994707FD7CF
0230994708FD811 0230994709FD454 0230994710FD0A8 0230994711FDCED 0230994712FD02D
0230994713FDC68 0230994714FD1A2 0230994715FDDE7 0230994716FD127 0230994717FDD62
0230994718FD2BC 0230994719FDEF9 0230994720FD750 0230994721FDB15 0230994722FD7D5
0230994723FDB90 0230994724FD65A 0230994725FDA1F 0230994726FD6DF 0230994727FDA9A
0230994728FD544 0230994729FD901 0230994730FDDFD 0230994731FD1B8 0230994732FDD78
0230994733FD13D 0230994734FDCF7 0230994735FD0B2 0230994736FDC72 0230994737FD037
453
Version 22.24
0230994738FDFE9 0230994739FD3AC 0230994740FD8A0 0230994741FD4E5 0230994742FD825
0230994743FD460 0230994744FD9AA 0230994745FD5EF 0230994746FD92F 0230994747FD56A
0230994748FDAB4 0230994749FD6F1 0230994750FD20D 0230994751FDE48 0230994752FD288
0230994753FDECD 0230994754FD307 0230994755FDF42 0230994756FD382 0230994757FDFC7
0230994758FD019 0230994759FDC5C 0230994760FD5F5 0230994761FD9B0 0230994762FD570
0230994763FD935 0230994764FD4FF 0230994765FD8BA 0230994766FD47A 0230994767FD83F
0230994768FD7E1 0230994769FDBA4 0230994770FDF58 0230994771FD31D 0230994772FDFDD
0230994773FD398 0230994774FDE52 0230994775FD217 0230994776FDED7 0230994777FD292
0230994778FDD4C 0230994779FD109 0230994780FDF4F 0230994781FD30A 0230994782FDFCA
0230994783FD38F 0230994784FDE45
454
Version 22.24
Appendix 2: Address population standards
Registry project
Address population guidelines

Version number Release date Description
1.0 4 Feb Draft for comment
1.1 Updated for comments received
1.2 8 Mar 2002 Issued to all participants
2.0 21 Jun 2002 Total rewrite based on A/NZ addressing standards
3.0 27 Jan 2012 Updated to reflect transition to the Electricity

Authority and updates to parts 11 and 15 of the
Code
3.0 22 November Formatting updated to include numbering

2013
455
Version 22.24
Introduction
About this document

1.1.1 This document is a rewrite of the “address population guidelines” based on the
A/NZ addressing standards.
Purpose
1.1.2 The purpose of this document is to provide Distributors with guidelines on how
they should populate the address fields on the registry. The outcome we are
seeking to achieve is the consistent population of the fields so that we maximise
the chance that users will correctly locate an ICP via the registry address search
function.
A/NZ addressing standard

1.1.3 To obtain a full copy and the background of the standards please go to
www.anzlic.org.au.
1.1.4 LINZ, who is the facilitator of these standards in New Zealand, has informed us
that many of the councils have been active in the development of the standard
and that they are eagerly awaiting the standard, and intend including them in
contracts they let. Submissions from NZ Post have also been considered in
developing the standards.
Changes to the registry address format and validations

1.1.5 The adoption of these new guidelines has meant that the following changes have
been made to the registry address format:
(a) Property name field size has been increased to 75 characters.
(b) Validation rules modified to make it mandatory to populate the Street name
field and/or the Property Name field.
Best efforts
1.1.6 It expected that Distributors will, on a best endeavours basis and where practical,
attempt to align their address data with these guidelines over time.
456
Version 22.24
The following sections

1.1.7 The document is broken into three sections:
(a) A/NZ addressing standard for street addressing – this section details the
component parts of an address per the A/NZ addressing standards and a
definition of each component.
(b) Guidelines for Population of Registry Address structure – this section

details the rules for population of the registry Address fields.
(c) Address population examples.
A/NZ addressing standard for street addressing
1.1.8 The definitions below are not extracted directly from the standards document.
The standards provide a concise definition for some of the component parts,
whereas other parts have an entire section detailing with the component part
definition. Where there was a concise definition it has been included, and where
not we have attempted to distil the essence of the standard.
1.1.9 The reader should refer to the full version of the A/NZ addressing standards
where they require a fuller explanation of an address component. A copy of the
standards can be obtained from http://www.anzlic.org.au/icsm/street/
Urban addressing
Components of urban addresses
1.1.10 The A/NZ addressing standard dissects an urban address into the following
component parts:
(a) Address number or address number range = a number issued by

government agency or local government authority that identifies a point or
location on a street.
(b) Road name = official road name issued by government agency or local
government authority.
(c) Suburb/locality name = a bounded locality within a city, town or shire

principally of urban character and usually with a focus of a shopping centre,
schools or transport facility.
(d) Nearest service town/city = an officially recognised and named population

centre, defined within a geographic boundary.
457
Version 22.24
1.1.11 Optional:
(a) Sub dwelling number = identifier for sub dwelling, eg A, 1, Flat 1, Unit 1,
Unit G Apartment 1, etc.
(b) Level of sub dwelling = spatial reference to the sub-dwelling, eg

basement, first floor etc.
(c) Property/building name = name given to the property or building by the

owner or party with legal naming rights.
(d) Complex name = name given to the development by the owner of the
development, eg “Central Park” office park in Greenlane.
(e) Private street name = is a made up address by a body other than that
responsible for the definition of official street names (a corner address is
made up of two official street names & therefore by definition a private
street name).
(f) Utility = this is a description of something useful, eg traffic lights, street

lights, barbecue, fountain.
(g) Postcode = official postal postcode.
Presentation order rules

1.1.12 For presentation purposes, the components of an urban address must be
ordered as follows:
(a) Sub dwelling number;
(b) Level of sub dwelling;
(c) Utility;
(d) Property/building name;
(e) Private street name;
(f) Complex name;
(g) Address number or address number range, road name; and
(h) Suburb/locality name, nearest service town/city, postcode.
Rural addresses
1.1.13 Rural addressing applies to the addressing of sites which lie outside the limits of
an urban numbering system.
458
Version 22.24
Components of rural addresses
1.1.14 The A/NZ proposed standard dissects a rural address into the following parts:
(a) Rural address number = a number derived from the distance between a
datum point and a property access point eg RAPID No.
(b) Road name = official road name issued by government agency or local
authority.
(c) Locality.
(d) Nearest service town/city.
1.1.15 Optional:
(a) Postcode.
(b) Rural delivery number.
(c) Property name (habitation name).
(d) GPS_Easting.
(e) GPS_Northing.
Presentation order rules

1.1.16 For presentation purposes, the components of a rural address must be ordered
as follows:
(a) Personal details;
(b) Property name (habitation name);
(c) Rural address number & road name;
(d) Locality;
(e) Rural delivery number; and
(f) Town/city, postcode.
Guidelines for population of registry address structure

1.1.17 The address should uniquely identify the property/installation or device to which
electricity is or can be supplied. The address is not intended to be a postal
address; where possible the address held on the registry should be formatted to
comply with the A/NZ addressing standards. This will improve address search
results and matching exercises between various participants’ databases.
459
Version 22.24
The acid test to be applied when determining whether the address is

adequate is…
1.1.18 Can you precisely locate, without ambiguity, the property/device or installation
that is being supplied electricity? This means no two commissioned ICPs should
have the same address, though in practice this may be difficult to achieve at
times, eg two pumps in a paddock. ICP addresses that fail this test should
ideally be cleansed prior to population of the registry; however, recognising that
this is not a small task and not always possible we suggest that you (where
possible) flag these ICPs on the registry as having an “ambiguous address”.
It is recognised that when a user finds the address is ambiguous they will need to contact
the Distributor who may have additional information that will assist in the identification of
the ICP, eg neighbours’ names and details, network plans and maps, and importantly,
faultsmen/ staff with good memories.
Components of registry Address

1.1.19 The ICP Address held on the registry has the following attributes:
Registry address attribute Characteristics Optional / Mandatory
Unit Text box 20A Optional
Property name Text box 75A Mandatory if Street not entered
Number Text box 25A Optional
Street Drop down combo 30A Mandatory if Property Name not entered
Suburb Drop down combo 30A Mandatory if Town not entered
Town Drop down combo 30A Mandatory if Suburb not entered
Region 20A Mandatory. Must be a valid Region, see list

below.
Post Code Text box 4N Optional
GPS_Easting Numeric 7.3 Optional unless GPS_Northing input
GPS_Northing Numeric 7.3 Optional unless GPS_Easting input
Registry Address population rules

1.1.20 The table below details how each component part, as defined by the A/NZ
addressing standard, of an address should be populated in the registry.
Note: The order that data is entered in the fields is important.
460
Version 22.24
Registry address A/NZ standard for street addressing

attribute
Unit Sub dwelling number; Level of sub dwelling
Property Name Utility; Property/building name; Private street name; Complex name
Street Number Address number or address number range; rural address Number
Street name Road name
Suburb Suburb/locality name; Rural delivery number
Town Nearest service town/city
Region
Postcode Postcode
GPS_Easting New Zealand Transverse Mercator 2000

(NZTM2000) coordinates, as defined in Land Information New
Zealand’s LINZS25002 standard (Standard for New Zealand Geodetic
Datum 2000 Projections)
GPS_Northing New Zealand Transverse Mercator 2000
(NZTM2000) coordinates, as defined in Land Information New
Zealand’s LINZS25002 standard (Standard for New Zealand Geodetic
Datum 2000 Projections)
See below for some examples
Appellation
1.1.21 Not included in the A/NZ standard but another component that needs to be
handled is the legal description of a parcel of land, ie appellation. The
appellation is a textual legal description of the parcel of land, eg Lot 66.
1.1.22 Where only the legal description of the property is known this should be
populated in the Property Name field, as the property/building name.
Field delineators
1.1.23 Ideally where multiple address components are entered into one field they should
be delineated by a delineator such as a “;” Commas must not be used in
addresses due to the use of CSV files.
Dairy numbers
1.1.24 Dairy farms are often assigned a number by the local dairy company. Where this
number is available it should be populated in the “street number” field.
461
Version 22.24
Regions
1.1.25 The purpose of the inclusion of region is to provide an extra segmentation of the
country so that a search on an awkward street (eg Main Road) or one with only a
loose association with a town or suburb will return a manageable number of
matching records.
1.1.26 While the list of regions could be larger, the list will be restricted to the list below
because the more regions the more boundaries and thus the more ambiguous
situations.
1.1.27 The regions are based on phone book areas that are generally known by callers.
(a) Auckland
(b) Bay of Plenty
(c) Canterbury
(d) Gisborne
(e) Hawkes Bay
(f) Manawatu
(g) Marlborough
(h) Nelson & Bays
(i) Northland
(j) Otago
(k) Southland
(l) Taranaki
(m) Timaru & Oamaru
(n) Waikato
(o) Wairarapa
(p) Wanganui
(q) Wellington
(r) West Coast
462
Version 22.24
Case insensitive
1.1.28 The registry address search function is case insensitive so Distributors are free to
populate the address fields as all upper case or a mixture or upper and lower.
Change address process

1.1.29 In recognising that the addresses held by Distributors are sometimes ambiguous
it is critical that Distributors establish and clearly communicate the processes that
the Trader should follow to obtain clarification of an address and, if need be, a
change of the address details on the registry. It will be equally important that the
Traders then communicate and train their staff in these processes.
Examples of address
1.1.30 Below are a few examples of how various addresses should be populated in the
registry.
Shed 4
Ansett Terminal
Auckland Airport
200 Hope Road
Otara 1234
Unit Shed 4
Property name Ansett Terminal; Auckland Airport
Street number 200
Street name Hope Road
Suburb
Town Otara
Region Auckland
Postcode 1234
Site 10
Outer Road
Paradise Caravan Park
45–67 Smith Street
French Bay
Unit Site 10
Property name Outer Road; Paradise Caravan Park
Street number 45–67
463
Version 22.24
Street name Smith Street

Suburb
Town FRENCH BAY
Region Timaru & Oamaru
Postcode
Marine Berth 15
Westhaven Marina
36–38 Westhaven Drive
Auckland
Unit Marine Berth 15

Property name Westhaven Marina
Street name Westhaven Drive
Suburb
Town Auckland
Region Auckland
Postcode
Office 2
Graphic Arts Building
O’Briens Walk
Auckland University
55-78 Symonds Street
Auckland
Unit Office 2
Property name Graphic Arts Building; O’Briens Walk; Auckland University
Street number 55-78
Street name Symonds Street
Suburb
Town Auckland
Region Auckland
Postcode
Suite 16
Level 5
Burnett Building
Park Alley
464
Version 22.24
Northern Private Hospital

580–780 Plenty Road
Auckland
Unit Suite 16; Level 5
Property name Burnett Building; Park Alley; Northern Private Hospital
Street name Plenty Road
Suburb
Town Auckland
Region Auckland
Postcode
Corner address:
Unit
Property name
Street number 232
Street name Stafford Street
Suburb
Town Timaru
Postcode
Or where not a street but more a location:
Unit
Property name Irrigation Pump; Corner of Highway 1 & Lower Hook Rd
Street number
Street name Lower Hook Rd (select the minor of the two roads as it will be easier to
find. This field could be left blank if it was deemed of no benefit given the
Property Name description)
Suburb
Town Waimate
Postcode
465
Version 22.24
Unit
Property name Timaru Railway Station
Street number
Street name Sophia Street
Suburb
Town Timaru
Postcode
Unit Shop 6; Level 2
Property name Westfield Shopping Centre
Street number
Street name Albert Street
Suburb
Town Auckland
Region Auckland
Postcode
Unit Shop W
Property name Lynnmall Shopping Centre
Street number
Street name
Suburb New Lynn
Town Auckland
Region Auckland
Postcode
Unit Shop 8
Property name Royale Arcade
Street number 253
Street name Stafford Street
Suburb
466
Version 22.24
Town Timaru
Postcode
Addresses with no street:
Unit
Property name Hut 54; MT Cook National Park
Street number
Street name
Suburb
Town Mt Cook
Region West Coast
Postcode
467
Version 22.24
Unit
Property name Streetlighting; Cnr State Highways 1 & 82
Street number
Street name
Suburb
Town Studholme
Postcode
468
Version 22.24
Appendix 3: Password standards

1.1.1 Password standards for the registry are set out below:
(a) Minimum eight characters.
(b) Maximum twenty characters.
(c) Must have one alphabetic character.
(d) Must have one numeric digit.
(e) Must have one non-alphanumeric (from the list of valid characters)
(f) No more than three characters can be the same.
(g) Cannot be part of logon ID. This is implemented as ‘Not case sensitive and
no 3 consecutive characters of the password must match 3 consecutive
characters in the User Id
(h) Must be composed of any of the following characters:
!$#%&'()+./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^
_`abcdefghijklmnopqrstuvwxy z{|}éÉ
Note: The list of characters above is the same used for the User Reference
field on ICP event histories. A space must accepted (it has been inserted
between two printable characters ‘y’ and ‘z’).
(i) Is case sensitive.
(j) Must not contain any sequence of three characters that are in ascending or
descending sequence (eg abc, zxy, 123).
(k) Must not contain any three consecutive characters that are part of a
common sequence. The implementation defines ‘common sequence’ as
being the strings which form keyboard sequences (ie keys next to each
other), for example, qwe, asd, ghj, p[], etc, and the string ‘password’ (eg
‘pas’ is not allowed to be part of the password).
(l) The password will expire after 60 days unless it is for a logon that is
identified as being for use with web services only.
469
Version 22.24
(m) Cannot be one of the last six passwords used by the User Id.
(n) Initial or reset passwords, unless for a logon that is identified as being for
use with web services only, must be a one-time password. Users must
change it after login on with the one-time password (*).
(o) Initial passwords or passwords provided for requests from the Forgot
Password form (i.e. direct request to the system) must be pseudo-random
generated (*).
(p) A User Id must be locked out after three failed attempts to log on (*)
* These items conform to the New Zealand ICT (ICT.govt.nz) Password Minimum
Requirements Sections 6.5.1;6.5.3 and 6.7.1
470
Version 22.24
Appendix 4: Batch file standards and file

processing
1.1.1 This appendix provides the specification for batch file processing.
1.1.2 The format for the header record is:
Field Format Mandatory/ Description

Optional
Record Char 3 M “HDR”

Type
Process Char 10 M The Input or Output header

Identifier
Sender Char 4 M For files sent to the Registry this is the

Participant Identifier. For files sent from the
Registry is “RGST”
Recipient Char 4 M For files sent to the Registry this is “RGST”.

For files sent from the Registry is the
Participant Identifier to whom the file is sent.
Creation DD/MM/YYYY M
Date
Creation HH:MM:SS M
Time
Number of Numeric M Number of records in the file excluding the

detail Header record
records
User Char 32 O When supplied for an input file is carried

Reference through onto the User Reference of the header
of the returned output file
Input Request Example:
HDR,RQRETMAINT,RETA,RGST,27/11/2011,11:34:12,5,RETA Update ICPs
Output Example:
HDR,RSACK,RGST,RETA,27/11/2011,11:34:12,5,RETA Update ICPs
471
Version 22.24
Batch interface cross reference map
Process Input Output Input Filename Maintenance Report Output File naming Convention
Header Header Example Acknowledgement Filename or delivered
Filename Example (if switch file (if
applicable) applicable)
Event and other maintenance interfaces
DC-010 Create an RQNETMAINT RSACK DIS19990523152530.txt DIS19990523152530.ack Same filename except for suffix
ICP
DC-020 Make a new
ICP ready
DC-030 Make a new
ICP distributor
DM-020 Add
additional
Distributor
information
DM-030 Correct
Distributor
information
DM-040 Reverse
Distributor
information
DM-010 Change RQDATECHQ RSACK DCH19990523152530.txt DCH19990523152530.ack Same filename except for suffix
initial ICP creation
date
RA-010 Trader RQRETMAINT RSACK TRM19990523152530.txt TRM19990523152530.ack Same filename except for suffix
becomes
472
Version 22.24
responsible for an
ICP
RM-010 Reverse
initial assignment
RM-020 Add new
Trader information
RM-030 Correct
Trader information
RM-040 Reverse
Trader information
MM-010 Add new RQMEPMAIN RSACK MEP19990523152530.txt MEP19990523152530.ack Same filename except for suffix
metering T
information
MM-010 Correct
metering
information
MM-030 Reverse
metering
information
DS-010 Transfer N/A RSACK DTS19990523152530.txt DTS19990523152530.ack Same filename except for suffix
ICPs between
Distributors
SD-010 Maintain RQMACNSP RSACK MNP19990523152530.txt MNP19990523152530.ack Same filename except for suffix
NSP data
473
Version 22.24
SD-030 Maintain RQMAINTLF RSACK LCS19990523152530.txt LCS19990523152530.ack Same filename except for suffix
loss category
codes*
SD-040 Maintain RQPRICECAT RSACK PCS19990523152530.txt PCS19990523152530.ack Same filename except for suffix
price category
codes*
*SD-030 and SD- N/A RSOTHERNT NON19990523152530.txt NON<date/time>.txt
040 Price and Loss
Category code
notification file
(output overnight
only)
Switch interfaces
RS-010 Make switch RQSWITCHNT RSACK to SWITCH_NT.txt SWITCH_NT.ack NT20121129091427.txt Acknowledgement: Same filename
request (NT) submitting Trader except for suffix
RSSWITCHNT to
other Trader Switch file to other party format:
RSEVENTDTL to
NT<date/time>.txt
submitting Trader
but only if this
accords with the NT20121129091427.eda (snapshot) Snapshot: Same filename except for
Trader’s
suffix of .eda
notification
parameters. This
is the PR-030
snapshot.
474
Version 22.24
RS-020 RQSWITCHAN RSACK to SWITCH_AN19990523152530.t SWITCH_AN19990523152530.ack AN19990523152855.txt Acknowledgement: Same filename
Acknowledge submitting Trader xt except for suffix
RSSWITCHAN to
switch request (AN) Switch file to other party format:
other Trader
AN<date/time>.txt
RS-030 Complete RQSWITCHTN RSACK to SWITCH_TN19990523152530.t SWITCH_TN19990523152530.ack TN19990523152855.txt Acknowledgement: Same filename
non half-hour submitting Trader xt except for suffix
RSSWITCHTN to
switch (TN) (to be Switch file to other party format:
other Trader
discontinued) TN<date/time>.txt
RS-040 Complete RQSWITCHTT RSACK to SWITCH_TT19990523152530.t SWITCH_TT19990523152530.ack TT19990523152855.txt Acknowledgement: Same filename
half-hour switch submitting Trader xt except for suffix
RSSWITCHTT to
(TT) (to be Switch file to other party format:
other Trader
discontinued) TT<date/time>.txt
RS-050 Complete RQSWITCHCS RSACK to SWITCH_CS19990523152530.t SWITCH_CS19990523152530.ack CS19990523152855.txt Acknowledgement: Same filename
switch (CS) submitting Trader xt except for suffix
RSSWITCHCS to Switch file to other party format:
other Trader, MEP CS<date/time>.txt
and Distributor
RSEVENTDTL to
CS19990523152855.eda (snapshot) Snapshot: Same filename except for
other Trader if
submitted by suffix of .eda
current (old)
Trader but only if
this accords with
the other Trader’s
notification
parameters. This
475
Version 22.24
is the PR-030
snapshot.
RS-050 Replace RQSWITCHRR RSACK to SWITCH_RR19990523152530.t SWITCH_RR19990523152530.ack RR19990523152855.txt Acknowledgement: Same filename
switch reading (RR) submitting Trader xt except for suffixSwitch file to other
RSSWITCHRR to
party format: RR<date/time>.txt
other Trader
RW-010 Make RQSWITCHN RSACK to SWITCH_NW19990523152530. SWITCH_NW19990523152530.ac NW19990523152855.txt Acknowledgement: Same filename
withdrawal request W submitting Trader txt k except for suffix
RSSWITCHNW to
(NW) Switch file to other party format:
other Trader
NW<date/time>.txt
RW-020 RQSWITCHA RSACK to SWITCH_AW19990523152530. SWITCH_AW19990523152530.ac AW19990523152855.txt Acknowledgement: Same filename
Acknowledge W submitting Trader txt k except for suffix
RSSWITCHAW to
withdrawal request Switch file to other party format:
other Trader and
(AW) MEP AW<date/time>.txt
476
Version 22.24
RC-010 Request RQSWITCHNC RSACK to SWITCH_NC19990523152530.t SWITCH_NC19990523152530.ack NC19990523152530.txt Acknowledgement: Same filename
switch read change submitting Trader xt except for suffix
RSSWITCHNC to
(NC) (to be Switch file to other party format:
other Trader
discontinued) NC<date/time>.txt
RC-020 RQSWITCHAC RSACK to SWITCH_AC19990523152530.t SWITCH_AC19990523152530.ack AC19990523152530.txt Acknowledgement: Same filename
Acknowledge submitting Trader xt except for suffix
RSSWITCHAC to
switch read change Switch file to other party format:
other Trader, MEP
(AC) and Distributor AC<date/time>.txt
MN-010 Accept or RQSWITCHM RSACK to SWITCH_MN19990523152530. SWITCH_MN19990523152530.ac MN19990523152530.txt Acknowledgement: Same filename
decline N submitting MEP txt k except for suffix
RSSWITCHMN to
responsibility (MN) Switch file to other party format:
other Trader,
(current) MEP and MN<date/time>.txt
Distributor
Reports and Notifications

PR-010 Produce ICP RQICPLIST RSICPLIST REQ19990523152530.txt LIS19990523152530.txt Same filename except first 3 character
list replaced
PR-015 Current Online submit RSCDLIST N/A CD19990523152530.txt CD<date/time>.txt
details report only
PR-020 Produce Automatic RSICPLIST N/A RES19990523152530_RETA.txt LIS<date/time>_<participant
monthly Trader ICP Distribution* Identifier>.txt.txt
reports delivered on
1st business
477
Version 22.24
day of month
to Traders
PR-030 Produce ICP RQEVENTDTL RSEVENTDTL RQA19990523152530.txt EDA19990523152530.txt Same filename except first 3 character
event detail report replaced
PR-035 Produce ICP Automatic RSPR035ATT N/A ICPEventFile_20121106001235.csv ICPEventFile_<date/time>.csv

attribute report Distribution*
PR-040 Produce RQCUSWBR RSSWBRCURD if BREACH_REQUEST.txt SCDACH_REQUEST.txt Same filename except first 3 character
switch compliance detail option replaced
report (current selected.
breach option) RSSWBRCURS if BREACH_REQUEST.txt SCSACH_REQUEST.txt Same filename except first 3 character
summary option replaced
selected
PR-040 Produce RQSWBRHIST RSSWBRHSTD if BREACH_REQUEST.txt SHDACH_REQUEST.txt Same filename except first 3 character
switch compliance and detail option replaced
report (historical Automatic selected. SHD20121129145216.txt SHD<date/time>.csv (Automatic)
breach option) Distribution* (Automatic)
RSSWBRHSTS if BREACH_REQUEST.txt SHSACH_REQUEST.txt Same filename except first 3 character
summary option replaced
selected SHS20121129145216.txt SHS<date/time>.csv (Automatic)
(Automatic)
PR-050 Produce ICP RQMICPDAYS RSMICPDAYS ICPDAYS_REQUEST.txt RSMICPDAYS20121129145216.txt RSMICPDAYS<date/time>.csv
days report and
Automatic
Distribution*
478
Version 22.24
PR-060 Produce RQAUDIT RSAUDIT FILEAUDITNETA.txt FALEAUDITNETA.txt Same filename except first 3 character
audit log replaced
PR-065 Request file RQFHSTATUS RSFHSTATUS HANDLER.txt FHSDLER.txt Same filename except first 3 character
handler status replaced
PR-070 Produce Automatic 5 files produced: N/A

monthly statistics Distribution* • RMSTATR2 RetailerStats2012110803.csv RetailerStats<YYYYMMDDHH>.csv
• RMSTATR4 NSPTotals2012110803.csv NSPTotals<YYYYMMDDHH>.csv
• RMSTATR1 MonthlyStatistics201211.csv MonthlyStatistics<YYYYMM>.csv
• RMSTATR5 ICPByRetailerNSP2012110803.csv ICPByRetailerNSP<YYYYMMDDHH>.csv
• RMSTATR3 DistributorTotals2012110803.csv DistributorTotals<YYYYMMDDHH>.csv
PR-080 Produce Automatic RSMHHRLIST N/A RSMHHRLIST20121129145216.txt RSMHHRLIST<date/time>.csv
monthly HHR ICP Distribution*
list
PR-090 Produce RQMACTNSP RSMACNSP ACTIVENSP_REQUEST.txt RSMACNSP _REQUEST.txt Same filename except first 8 characters
active NSPs report and replaced with RSMACNSP
Automatic
RSMACNSP20121129145216.txt RSMACNSP <date/time>.csv
Distribution*
(Automatic) (Automatic)
PR-100 Produce RQMLOSSFS RSMLOSSFS LossFactorREP_REQ.txt RSMLOSSFSrREP_REQ.txt Same filename except first 9 characters
loss factors report and replaced with RSMLOSSFS
Automatic N/A
RSMLOSSFS20121122135711.txt RSMLOSSFS<date/time>.csv
Distribution*
(Automatic) (Automatic)
479
Version 22.24
PR-110 Produce RQMMAINTC RSMMAINTCP Maint_Compliance_REQ.txt PR110_Compliance_REQ.txt Same filename except first 5 characters
maintenance P and replaced with PR110
Automatic N/A
compliance report RSMMAINTCPDET20121101000236 RSMMAINTCP<DET or
Distribution*
.txt (Automatic - detail) SUM><date/time>.csv
RSMMAINTCPSUM2012110100023
6.txt (Automatic - summary)
PR-120 Produce RQMNSPMAP RSNMNSPMAP NSPMappingTable_REQ.txt RSMNSPMAPgTable_REQ.txt Same filename except first 9 characters
NSP mapping table and replaced with RSMNSPMAP
N/A
report Automatic RSMNSPMAP20121122135922.txt RSMNSPMAP <date/time>.csv
Distribution* (Automatic) (Automatic)
PR-130 Produce Automatic RSPR130STA N/A PR-130_EA_Statistics_2012_11.csv PR-
monthly activity Distribution* (Automatic) 130_EA_Statistics_<YYY>_<MM>.csv
and status
summary report
PR-140 Produce Automatic RSSWCOMPLT N/A AverageSwitchCompletion2012110 AverageSwitchCompletion<date/time>.
monthly switch Distribution* 6000735.csv csv
completion report
PR-145 Produce Automatic RSSWIDAILY N/A DailyAverageSwitchCompletion201 DailyAverageSwitchCompletion<date/ti
daily switch report Distribution* 21106000735.csv me>.csv
PR-160 Automated RQATRADE RSMATRADE N/A RSMATRADE20121106000735.csv RSMATRADE<date/time>.csv

Trade Notification and
Automatic
Distribution*
PR-170 Produce Automatic none N/A ICPsOwned0622012.csv ICPsOwned<month><year>.csv

monthly report Distribution*
480
Version 22.24
PR-180 Produce ICP Automatic RSPR180STA N/A PR-180_EA20121101000236.csv PR-180_EA<date/time>.csv
switching trend Distribution*
report
PR-190 EIEP Automatic RMSTATEIEP N/A EIEPMonthlyStatistics20121101044 EIEPMonthlyStatistics<date/time>.csv
statistics Distribution* 246.csv
PR-210 Missing Automatic RSMISSMETR N/A PR210_MissingMetering201401020 PR210_MissingMetering<date/time>.csv
Metering Data Distribution* 01530.csv
PR-220 Uncertified Automatic RSUNCERMTR N/A PR220_UncertifiedMetering201401 PR220_UncertifiedMetering<date/time>
Metering Distribution* 02001530.csv .csv
Installations
PR-230 Electrical Automatic RS230NRG N/A PR230_ElectricalConnectionAlign_2 PR230_ElectricalConnectionAlign_<date
Connection Distribution* 0140102001530.csv /time>.csv
Misalignment
PR-240 Profile Automatic RSUNCERTDV N/A PR240_UncertifiedControlDevice20 PR240_UncertifiedControlDevice<date/t
Misalignment Distribution* RSNOMTRHHR 140102001530.csv ime>.csv
(produces 3 report RSHHRMISMA PR240_NoMeterForHHR201401020 PR240_NoMeterForHHR<date/time>.csv
outputs) 01530.csv PR240_SubmissionHHRMisMatch<date/
PR240_SubmissionHHRMisMatch20 time>.csv
140102001530.csv
PR-250 Trader RQDTGENERL RSDTGENERL DefaultDataRequest.txt PR250_DefaultGeneral_<timestam
Default General p>.csv” where timestamp is format
Information “yyyymmddhhmmss” and specifies
the report run time.
For example:
481
Version 22.24
PR250_DefaultGeneral_201411170
92501.csv
PR-270 Trader by RQDTNSPTR RSDTNSPTR TraderByNSPRequest.txt PR270_NSPTraders

NSP in the event of _<timestamp>.csv” where
a Trader Default timestamp is format
situation “yyyymmddhhmmss” and specifies
For example:
PR270_NSPTraders_201411170925
01.csv
PR-280 RQPARTYROL RSPARTYROL PARTYROLEEXPIRY.txt PR280_PartyRole_<timestamp>.csv
Responsibility ” where timestamp is format
Outside Participant “yyyymmddhhmmss” and specifies
Role the report run time.
For example:
PR280_PartyRole_2014111709250
1.csv
PR-290 Trader RQMKTSHAR RSMKTSHARE TraderMarketShare.Requesttxt PR290_RetailerDefault_timestamp
Default Market E >.csv” where timestamp is format
Share “yyyymmddhhmmss” and specifies
For example:
482
Version 22.24
PR290_RetailerDefault_201406101
11824.csv
PR-320 Monitor RQSWSVPRSC RSWDLSAVWB PR320_SaveProtectionScheme PR320_SaveProtectionScheme_<ti

switch saving Request.csv mestamp>.csv where timestamp is
protection scheme format “yyyymmddhhmmss” aqnd
specidfies the report run time. For
example:
PR320_SaveProtectionScheme_201
50505113214.csv
PR-330 Produce RQDISTLEVY RSDISTLEVY N/A ICPsOwnedDistributor20142015.cs ICPsOwnedDistributor<previous
Distributor annual v year><current year>.csv
levy report
PR-340 Produce RQTRADLEVY RSTRADLEVY N/A ICPsOwnedTrader20142016.csv ICPsOwnedTrader<previous

Trader annual levy year><current year>.csv
report
NP-010 Automatic RSACK N/A RSACK20121101044246.csv RSACK<date/time>.csv

Acknowledge event Distribution*
change for online
event
maintenance
(Trader,
Distributor
483
Version 22.24
and MEP)
delivered
overnight
This interface is also output as a result of event and other maintenance functions performed via SFTP (see above)
NP-020 Send switch This interface is one of the outputs of the switch interfaces (see above)
messages
NP-030 Notify of Automatic RSAUNOTIFY N/A NOT19990523152530.txt NOT<date/time>.txt
event change Distribution*
(standard or NOT delivered
file) daily
overnight
NP-030 Notify of Automatic RSMENOTIFY N/A NMR19990523152530.txt NMR<date/time>.txt
event change Distribution*
(metering or NMR delivered
file) daily
overnight
NP-040 Re-send RQRSSWFLS Depending on the RESEND_SWITCH_REQ.txt Depending on the message being
switching messages message being resent one of:
resent one of:
RSSWITCHNT NT19990523152530.txt Switch file to other party format:
NT<date/time>.txt
RSSWITCHAN AN19990523152530.txt Switch file to other party format:
AN<date/time>.txt
484
Version 22.24
RSSWITCHTN* TN19990523152530.txt* Switch file to other party format:
TN<date/time>.txt
RSSWITCHTT* TT19990523152530.txt* Switch file to other party format:
TT<date/time>.txt
RSSWITCHCS CS19990523152530.txt Switch file to other party format:
CS<date/time>.txt
RSSWITCHRR RR19990523152530.txt Switch file to other party format:
RR<date/time>.txt
RSSWITCHNW NW19990523152530.txt Switch file to other party format:
NW<date/time>.txt
RSSWITCHAW AW19990523152530.txt Switch file to other party format:
AW<date/time>.txt
RSSWITCHNC* NC19990523152530.txt* Switch file to other party format:
NC<date/time>.txt
RSSWITCHAC AC19990523152530.txt Switch file to other party format:
AC<date/time>.txt
RSSWITCHMN MN19990523152530.txt Switch file to other party format:
MN<date/time>.txt
*To be *To be discontinued
discontinued
NP-050 re-send RQRSNOTIFY RSAUNOTIFY RESEND_NOT_REQ.txt NOT19990523152530.txt NOT<date/time>.txt
notifications
(standard or NOT
file)
485
Version 22.24
NP-050 re-send RQMTNOTIFY RSMENOTIFY RESEND_NMR_REQ.txt NMR19990523152530.txt NMR<date/time>.txt
notifications
(metering or NMR
file)
NP-060 Automatic RSPALERT N/A RSPALERT19990523152530.txt RSPALERT<date/time>.txt
Distribution*
daily
overnight
EIEP Interface
EI-020 and EI-030 N/A N/A RETA_E_NETA_201112_20111 RETA_E_NETA_201112_2011120 RETA_E_NETA_201112_20111201_ No change to filename to recipient
201_myfile.zip 1_myfile.ake myfile.zip
Same filename except suffix of .confirm

RETA_E_NETA_201112_20111201_ for the confirmation of delivery to
myfile.confirm sender
Trader Default Interfaces
TD-020 Maintain RQEXCLTBL RSACK Exclusions.txt Exclusions.ack
Trader ICP
Allocation Exclusion
List
TD-050 Load Trader RQTENDER RSACK Tender1.txt Tender1.ack
Bids
486
Version 22.24
TD-090 ICP re- RQTDTICPMT RSACK to Reassign.txt Reassign.ack PR310_ICPAllocation201502041601
assignment process submitter (EA). 48.csv
RSTDTALLOC to
Traders
PR-300 Report RQTNDRLIST RSTNDRLIST TenderList.txt PR300_TenderResults20150204160
Trader Default 148.csv
tender and
mandatory
assignment
PR-310 Report RQTDTALLOC RSTDTALLOC AllocResults.txt PR310_ICPAllocation201502041601
Trader Default 48.csv
allocation results
Automatic Distribution* - the batch interface is initiated automatically, no header is defined.
487
Version 22.24
1.1.3 The conventions for processing files for input and output are:
In the main,
 Acknowledgement files are given the same filename as the related maintenance file except
the suffix is changed to .ack.
 Most reports will be given the same name by the Registry but in some cases the first 3 or
more characters are changed. For example, a request for a list file contained in a file
called REQ19991005123542.txt will produce an output file with a filename of
LIS19991005123542.txt - the timestamp will be the same as the request file for ease of
matching requests with lists.
1.1.4 File delivery mechanism
Files are delivered to and received from the registry via FTP or SFTP.
For non-EIEP files, there are 4 directories or folders that are used for the following purposes:
 toreg - this is where users transfer their files for the Registry to process
 fromreg – this is where the Registry delivers outputs from processing (acknowledgements,
notifications, reports, etc.)
 processed –files are moved to this directory from the toreg directory once they have been
processed by the Registry
 reject - files that have errors in the header line are moved to this directory from the toreg
directory.
For EIEP files, there are 2 additional directories or folders (only visible when using SFTP) that are
used as follows:
 EIEPout - this is where users transfer their files for the Registry to process (deliver to
another participant
 EIEPin – this is where the Registry delivers EIEPs sent by other participants.
The Registry has the facility to apply zip compression to outgoing files for individual users - the
naming conventions above still stand, but the zipped file is suffixed with ‘.zip’ instead of ‘.txt’, and
the original file is removed from the outgoing directory.
The naming conventions here are suggested conventions only. Any filename can be used for files
sent to the Registry, with the following provisos:
 File extension (.txt in the above examples) cannot be longer than 100 characters
 File name (e.g. ICP19990523152530) cannot be longer than 125 characters
 Overriding both these allowances, the total filename (comprising your FTP usercode, incoming
directory name, file name and file extension) cannot be longer than 100 characters e.g.
marftp01\toreg\REQ20000405123445.txt
The registry will cope with processing files with the same name, if submitted the identical file has
001(002…) appended prior to processing, likewise output files have 001(002…) appended.
488
Version 22.24
For example, repeated submission of a file named UIS19990523152530.csv would result in output
files
UIS19990523152530.ack
UIS19990523152530.ack.001
UIS19990523152530.ack.002
etc
The registry does not reject a file that has been previously submitted (currently a very common
occurrence especially when requesting ICP Lists). Records are subject to validation appropriate to
the file submitted so for example if an identical AN file is submitted twice the second AN records
would be rejected as an AN cannot follow an AN, likewise if a NT file is submitted twice the second
NT would be rejected as ICP’s would already be switch in progress.
489
Version 22.24
Appendix 5 – Period of availability and mapping of

customised to generic register
content codes
1.1.1 Period of availability is the minimum number of hours within a day that supply is
available (or the controlled part of the supply is available for an inclusive channel)
and must be <=24.
1.1.2 The following is provided for guidance and clarity:
(a) For single channel uncontrolled configurations, the period of availability must
be 24.
(b) For single channel controlled or inclusive configurations, the period of
availability must be the minimum number of hours in any day that supply is
available (or the controlled part of the supply is available for an inclusive
channel).
(c) For multi-channel uncontrolled configurations, the period of availability is the
actual period for which each channel is active, and must add to 24 in any day
for register content codes that need to work together.
(d) For multi-channel controlled or inclusive configurations, the period of
availability must be the minimum number of hours in any day that supply is
available (or the controlled part is available for an inclusive channel):
(i) where the distributor’s load control policy does not differentiate
between time-blocks, the period of availability for each channel must
be identical and reflect the minimum number of hours that supply is
available to the controlled load; or
(ii) where the distributor’s load control policy differentiates between time-
blocks, the period of availability for each channel must reflect the
minimum number of hours for the channel that supply is available to
the controlled load.
1.1.3 Period of availability must reflect the physical or programmed configuration of
metering installations, and not pricing or virtual channels.
1.1.4 Where the active period for a multi-channel configuration is for an odd number of
trading periods, the period of availability is to be rounded up or down to a whole
number for each channel such that the sum of all periods of availability in any day
does not exceed 24.
1.1.5 Distributors are encouraged to always specify minimum service levels for each
controlled or inclusive delivery price in their pricing information. However, if the
490
Version 22.24
distributor does not specify a minimum service level, the period of availability
should default to 0 or 24 (depending on the scenario), as follows:
(e) period of availability should default to ‘0’ where the distributor specifies “no
maximum hours of control” or the equivalent, or does not specify any load
control policy
(f) period of availability should default to ‘24’ where the distributor specifies it
does not actively control the load.
1.1.6 Where time-blocks are different between weekdays/workdays and weekend/non-
workdays, the period of availability must reflect the weekdays/workdays time-
blocks.
Mapping of customised to generic register content

codes
1.1.7 The table below shows the extent to which existing customised register content
codes are used, and mapping to new generic register content codes.
1.1.8 The SRWDPK and WRWDPH customised register content codes are specific to a
closed price category which is to be grandfathered for existing ICPs.
SRWDPK – Summer weekday peak
WRWDPK – Winter weekday peak

Generic codes >>
SH – Shoulder
OP – Off-peak
PK – Peak
POA ICPs
Use of existing customised codes as at 22/11/17
DWD – Day of weekdays 0700-2100 14 0 x

NWD – Night of weekdays 2100-0700 10 0 x
WE - Weekend 24 0 x
Electra Triple Saver (now TOU)

DOP – Triple Saver off peak 1100-1700, 2100-2300 (Shoulder) 8 740 x
DPK – Triple Saver peak 0700-1100, 1700-2100 8 740 x
N - Night 2300-0700 (Off peak) 8 740 x
Orion
491
Version 22.24
66 or
SEPK – Weekdays 0700-1100, 1700-1930 (Peak) 7 1887 x
7 or
SEOP – Weekdays 1100-1700, 1930-2100 (Shoulder) 8 1887 x
SENW – Nights 2100-0700 + Weekend Fri 2100-Mon 0700 (Off
peak) 10 1887 x
Vector (when it initially offered 3 rate TOU)

OPKOOA - Any day 2200-0600 (Off peak) 8 0 x
PKOOA - Weekdays 0730-0930, 1730-1930 (Peak) 4 0 x
SPKOOA - Weekdays 0600-0730, 0930-1730, 1930-2200 +
Weekend 0600-2200 (Shoulder) 12 0 x
Vector, Unison, Counties Power

OPKOOB - Off peak - Weekdays 1100-1700, 2100-0700 + All
Weekend 0000-2400 16 0 x
PKOOB - Peak - Weekdays 0700-1100, 1700-2100 8 0 x
WEL Networks
PKOOC – Workdays peak 0700-0930, 1730-2000 5 30 x
SPKOOC – Workdays shoulder 0930-1730, 2000-2200 +
Weekends/public holidays 0700-2200 (Shoulder) 10 30 x
OPKOOC – Off peak 2200-0700 (Off peak) 9 30 x
Top Energy
OPKOOD - Off peak 2300-0700 8 0 x
PKOOD - Peak 0700-0930, 1730-2000 5 0 x
SPKOOD - Shoulder 0930-1730, 2000-2300 11 0 x
Waipa Networks
OPKOOD - Off peak 2300-0700 8 0 x
PKOOE - Peak 0700-1000, 1600-2100 8 0 x
SPKOOE - Shoulder 1000-1600, 2100-2300 8 0 x
Counties Power GEN 3 RATE (closed)

SWDPK – Summer weekday peak 0700-1100, 1700-2100 8 123 x
WWDPK – Winter weekday peak 0700-1100, 1700-2100 8 123 x
WDOP – Weekday shoulder 1100-1700, 2100-2300 + Weekend
0700-2300 (Shoulder) 8 123 x
N- Night 2300-0700 (Off peak) 8 123 x
6 Where the time block for a channel is an odd number of trading periods and rounded up or down, the sum of
all periods of availability for any day must not exceed 24
492
Version 22.24
493
Version 22.24
Appendix 6 – XML format of PR-030 ICP

information
1.1.9 An example of the XML snapshot output is shown below.
1.1.10 Notes:
(a) It is necessary to have a single root element – in this case <PR-030>
(b) XML tag names are based on the “Output Event Type” defined in the PR-
030 data output format, e.g. “Address”.
(c) XML attribute names are derived from the field names defined in section
1.4 of this document, with spaces removed from attribute names e.g.
physicalAddressStreet is the XML attribute name for Physical Address
Street.
<?xml version="1.0"?>
<PR-030>
<Header processIdentifier="RQEVENTDTL" sender="RGST" recipient="RETA" creationDate="18/09/2012"
creationTime="14:41:42" numberOfDetailRecords="6"
userReference="runValidTests(2)"/>
<Address iCPIdentifier="0000000216AAFF0" eventType="Address" auditNumber="ADD-120154"
eventDate="01/02/2001" changedDate="18/09/2012 14:41:39"
userIdentifier="NETB" fileName="" eventState="Active"
reversalReplacedDateTime="" reversalReplacedBy=""
reversalReplacementFileName="" replacementEventAuditNumber=""
physicalAddressUnit="A" physicalAddressNumber="109"
physicalAddressRegion="Canterbury" physicalAddressStreet="High"
physicalAddressSuburb="West Belt" physicalAddressTown="Rangiora"
physicalAddressPostCode="7733" physicalAddressPropertyName="My Place"
gPS_Easting="1234567.123" gPS_Northing="100008.21"
addressUserReference="UserRef"/>
<MeterSummary iCPIdentifier="0000000216AAFF0" eventType="MeterSummary" auditNumber="MET-
144580" eventDate="01/03/2010" changedDate="18/09/2012 14:41:40"
userIdentifier="META" fileName="" eventState="Active"
mEPParticipantIdentifier="META" highestMeteringCategory="9" hHRFlag="N"
nHHFlag="N" pPFlag="N" aMIFlag="N" meterChannelCount="0"
meterMultiplierFlag="N" meteringUserReference="Myref">
<MeterInstall meteringInstallationNumber="1" highestMeteringCategory="9"
meteringInstallationLocationCode="BA" aTHParticipantIdentifier="ATH1"
meteringInstallationType="NHH" meteringInstallationCertificationType="F"
494
Version 22.24
meteringInstallationCertificationDate="03/12/2000"
meteringInstallationCertificationExpiryDate="03/12/2015"
controlDeviceCertificationFlag="N" certificationVariations="X"
certificationVariationsExpiryDate="31/01/2017" certificationNumber="123456B"
maximumInterrogationCycle="180" leasePriceCode="Lease">
<MeterComp meteringInstallationNumber="1" meteringComponentSerialNumber="44455Cv"
meteringComponentType="M" meterType="NHH" aMIFlag="N"
meteringCategory="1" compensationFactor="1" owner="METB"
removalDate="01/03/2010">
<MeterChannel meteringInstallationNumber="1" meteringComponentSerialNumber="44455Cv"
channelNumber="1" numberOfDials="5" registerContentCode="UN"
periodOfAvailability="24" unitOfMeasurement="KWH" energyFlowDirection="X"
accumulatorType="C" settlementIndicator="Y" eventReading="65431"/>
</MeterComp>
</MeterInstall>
</MeterSummary>
<Network iCPIdentifier="0000000216AAFF0" eventType="Network" auditNumber="NET-339556"
networkParticipantIdentifier="NETB" pOC="NETB001" reconciliationType="GN"
dedicatedNSP="N" installationType="B" proposedTrader="RETB"
unmeteredLoadDetails-Distributor="Unmetered Load" sharedICPList=""
generationCapacity="123.12" fuelType="wind" initialEnergisationDate=""
directBilledStatus="Retailer" directBilledDetails="Direct Billed"
networkUserReference="UserRef"/>
<Pricing iCPIdentifier="0000000216AAFF0" eventType="Pricing" auditNumber="PRI-310587"
distributorPriceCategoryCode="PCAT1" distributorLossCategoryCode="LFC1"
chargeableCapacity="112.20" distributorInstallationDetails="Inst details"
pricingUserReference="UserRef"/>
<Status iCPIdentifier="0000000216AAFF0" eventType="Status" auditNumber="STA-237970"
userIdentifier="RETA" fileName="" eventState="Active"
iCPStatus="2" statusReason="0" statusUserReference="UserRef"/>
<Trader iCPIdentifier="0000000216AAFF0" eventType="Trader" auditNumber="REC-170214"
495
Version 22.24
userIdentifier="RETA" fileName="" eventState="Active"

traderParticipantIdentifier="RETA" profile="RPS" submissionTypeHHR="N"
submissionTypeNHH="Y" aNZSIC="A01" proposedMEP="META" uNMFlag="Y"
unmeteredLoadDetails-Trader="UnMeteredLoadDetsTrader"
dailyUnmeteredKWh="1.1" traderUserReference="UserRef"/>
</PR-030>
496
Version 22.24
Appendix 7 – Switch Process Flow Diagrams
497
Version 22.24
498
Version 22.24
Switch Withdrawal - Current Process

Customer
Cancel Switch
Trader A
Wrong ICP under Request Switch Process Withdrawal Rejected Negotiate with Other
switch or customer Withdrawal Notice Response cancelation Retailer or New
cancels Switch
NW File AW File
Registry
Note: For AW accptance,

possible trader, metering and
Process Switch Process Switch status event reversals
Withdrawal Request Withdrawal
Registry Response Registry
EA
NW File
Note: Could be multiple NW/AW files for
AW File
the one Switch i.e cancellation may be
Process Withdrawal rejected at first but may be accepted
Trader B
Notice and after negotiations

determine response AW File
Provider
Receive Switch
Withdrawal
Response
Metering Eq uipment
499
Version 22.24
Switch Meter Reading Change - Current Process
Receive revised
validated meter
Distributor
reading or a
permanent estimate.
RR file but only with AC

acceptance
Disputed reading Provide revised Process revised Process rejected Negotiate with Other
Trader A
validated meter reading response revised reading Retailer.

reading or a
permanent estimate
RR File AC File
EA Registry
Process revised Process revised

reading reading response Note: for AC acceptance,
Registry Registry
RR sent to MEP and
distributor
RR File
RR file but only with AC acceptance
Note: Could be multiple RR/AC files for

Trader B
the one Switch i.e revised reading may

Process revised Receive revised be rejected at first but may be accepted
reading and validated meter after negotiations
determine response AC File reading or a
permanent estimate.
Provider
Receive revised
validated meter
reading or a
permanent estimate.
Metering Eq uipment
500
Version 22.24
Meter Equipment Provider Switch - Current Process

Old MEP
Receive notification Receive MN

Message
Receive notification Receive MN

Message
Distributor
Receive MN
New Trader
Receive notification Message
Acceptance MN
Propose New MEP Change proposed Receive notification Receive MN Propose New MEP
Trader
MEP attribute in Message and if

Trader Event declined then may
propose a new MEP
Acceptance/
Decline MN
EA Registry
Apply proposed Notify affected Process MN and

MEP attribute particpants notify affected
Registry change Registry Registry
participants
New MEP
Receive notification Accept/Decline Load Metering Event

proposal using MN
message
501
Version 22.24
TD-010 Complete Switch Activity for Trader in Trader Default
502
Version 22.24
503
Version 22.24
504
Version 22.24
Appendix 8 – Use of MNON and MREM

1.1.1 The Authority sent a memo to participants on 3 September 2013 (from Ron
Beatty Principal Adviser Market Services) describing the use of the Metering
Equipment Provider (MEP) Codes MNON and MREM in the Registry.
1.1.2 In the memo, the Authority noted that the MEP identifiers MNON and MREM:
(a) were created to provide a primary metering contact in the “pre Part 10”
registry, and indicated that either an ICP was solely unmetered load
(MNON) or the ICP was inactive and meters had been removed (MREM)
(b) will eventually be end dated, but have been left as active for a time to allow
historical ICP maintenance to be carried out.
1.1.3 The Authority also noted that some participants have selected MREM as an
MEP, probably because an ICP was made inactive and metering was removed
(either long term inactive or waiting for decommissioning). While this was the
practice in the pre Part 10 registry, the new Part and amended Part 11 of the
Code requires the following:
Solely unmetered load

(a) If the ICP has never had an MEP nominated, there is no need to nominate
an MEP. The field may be left blank
ICP accepted from “Ready” but no MEP nominated yet

(b) ICP should be “Inactive” on the registry i.e. electrically disconnected until a
metering installation is installed. The retailer must not authorise the
electrical connection of the ICP until the electrical installation is safe, has
been authorised for electrical connection by the distributor, and a metering
installation is in place to measure all electricity conveyed at the ICP
(c) If the metering installation is installed prior to ICP acceptance, then the ICP
status may go directly to “Active” on the registry and be electrically
connected provided that the electrical installation is safe and has been
authorised for electrical connection by the distributor
(d) The MEP field may in any case be left blank until the MEP is nominated (for
clarity, this nomination could be after the installation date with the MEP
event backdated)
All metering removed from an existing ICP
(e) ICP should be inactive until a metering installation is re-installed. The
retailer must not authorise the electrical connection of the ICP until the
505
Version 22.24
electrical installation is safe and a metering installation is in place to

measure all electricity conveyed at the ICP
(f) The registry should automatically change the metering category to “9”
indicating that there is no metering installation at the ICP
(g) MEP remains as the MEP that was previously nominated. As there is no
metering equipment and the site is inactive, there are no compliance
obligations for the MEP
(h) When re-energising such an ICP, the retailer may elect to use the current
MEP in the registry, or propose a new MEP.
1.1.4 Participants should not select MNON or MREM to become the MEP going
forward. However, in the event that a trader has selected MNON or MREM since
29 August 2013, the following occurs:
(a) the MEP proposal will not be accepted, and the MEP that is shown on the
registry for the ICP will remain the responsible MEP
(b) the warning that an MEP switch is in progress will show on the registry
screens. Note that this will not prevent the switching of an ICP between
traders, or the replacement of an MEP switch proposal with a new MEP
switch proposal.
506

Registry Functional Specification v22 24

Uploaded by

Copyright:

Available Formats

Registry Functional Specification v22 24

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Registry Functional Specification v22 24

Uploaded by

Copyright:

Available Formats

Electricity Authority Registry

1 to 21. September Pre-Part10 Registry Functional Specifications. Revision

19A.8 August 2013 Development version of the Part10 Registry upgrade

22 29 August Clean copy of version 19A.8.

22.1 4 September Appx. 7 Use of MNON and MREM.

PR-040, Days overdue calculation for irregular event updates

RA-010, Notation added to reference appendix 7 when using

NP-010 Event date field is optional not mandatory as no date is

Metering certification date, if entered, cannot be greater

22.2 28 January PR-210 Addition of Missing Metering Data Report

PR-220 Addition of Uncertified Metering Installations Report

PR-230 Addition of Energisation Misalignment Report

PR-240 Addition of Profiles Report

NP-060 Alerts Type C applicable to ICPs where the Status is Active

Appendix 4 Appendix 4 updated with PR-210/220/230/240

Version Release Date Section Description

13 March 2014 PR-210

Version Release Date Section Description

22.6 21 July 2014 SD-020 Addition of new Register Content Codes

30 July 2014 SU-030 Supervisor ability to disable logons (existing functionality -

17 November RS-050 CR-1157 Manage setting of submission type during a trader

CR-1158 Amendments to the energisation misalignment

22.8 21 December PR-255 CR-1153 Metering installation information report

22.9 2 February 1.14 CR-1149 Trader Default Exclusions Table

Version Release Date Section Description

29 April 2015 CR-1170 NHH meter using H profile

Version Release Date Section Description

26 July 2015 PR-330 CR-1172 Annual Levy reports

22.13 07 August PR-010 Documentation - correct example.

22.14 18 September RS-050 Noted by auditor in review of CR-1176: Remove

22.15 21 October Section Documentation change only, EIEP table missing a

11 December Documentation change only

Version Release Date Section Description

Clarify when end date may be set on Distributor Price

CR-1186 phase 1: metering installation certification type of

01 April 2016 SD-020 Addition of new register Content Codes

05 April 2016 PR-050 CR-1171 – improve accuracy of consumption data

15/04/2016 NP-060 CR-1186 phase 2: report to the Authority, in the monthly

Spelling errors in Switch Meter Reading Change diagram

10/06/2016 CR-1152: provide greater clarity on the type of metering

23/06/2016 PI-010 Addition of Publish information process and PI-010 sub

Version Release Date Section Description

SU-010 Documentation clarifications to Add new user process

22.19 28/06/2016 MM-010 Clarification to business rule 3 a.

PR-120 Addition of NSP table report request example.

Addition of MM-040 Missing MEP Ownership Historical

PI-010 CRCON-1005 Amendments to publish information,

02/06/2017 DS-010 Change Optional parameter to Mandatory and clarify the

22.20 07/06/2017 RS-050 Correction to CS switch examples

13/06/2917 CR CON-1002 Password Reset

Version Release Date Section Description

22.21 08/08/2017 Security JIRA ER-702

20/09/2017 1.4.13 ER-714/ER-716 revised terminology for energised and de-

Version Release Date Section Description

22.23 31/01/2018 1.15.4 CR-1201 Transfer EIEP files to the Authority

As per Auditor suggestion - Remove FTP references (use

Removal of references to ‘Market Administrator’ as it longer

22.24 Process ER-390 Addition of Process Map 9 Trader Default

SD-020 Authority adjustments to Register Content Codes (based on