#1 What are the rules for Read Status? If the HHR data is not validated should it be labelled as estimated? (13A)

#2 Postal address fields in EIEP13C are not required as it is not an "EIEP delivery method". (13A, 13B, 13C) 

#3 There are no specifications under which the EIEP 13A or B rejection file should be provided. Please can you confirm whether the intention is that this be limited only to where the request for the EIEP 13A or B has been made via the EIEP 13C file through the Registry Hub? i.e. requests made via e-mail, whether they include an EIEP 13C file or not, may be rejected by way of return e-mail to the requestor without provision of a rejection file. (EIEP 13A and B)

#4 11.32C specifies that retailers must notify consumers at least once each calendar year. We would like clarification on how this is intended to work in the case where a consumer switches to a retailer on, for example, 30th November? Is the retailer expected to notify that consumer before the end of the calendar year (given that it is possible that consumer has only just been notified by their previous retailer)? The obligation to notify consumers would be more efficient to manage and more easily aligned with other notifications(i.e. low user, medically dependent) if this was required once in a 12 month period rather than once in a calendar year.

#5 Regarding requirement 14/15 of EIEP 13A, it is likely that HH data provided to agents/consumers will contain some gaps. This will be the most detailed consumption information available in our system at the time of the request. Those gaps may be resolved in our system at a date after the request has been fulfilled via a “catch up” file from the MEP. Is it intended that, following receipt of such a catch up file, we would be required to provide revised data to the agent/consumer? (EIEP 13A)

#6  Under clause 11.32B(2) where the retailer has 5 business days to provide consumption information to the requesting consumer, is information considered ‘provided’ to the consumer when it is sent by the retailer or when it is received by the consumer? i.e. for requests fulfilled by post, is a retailer expected to consider in its processes the time taken for the information to reach the consumer.

#7  Will the Authority’s approval process for granting consumer agents access to the Registry EIEP Hub include any requirement for the agent to have arrangements in place with retailers for requesting consumption data or will ‘anyone’ be able to be granted access and start sending requests for consumption data without a retailer having visibility to what agents it may receive requests from?

#8 The Authority requirement to provide ‘all’ data pertaining to a consumer will be a challenge for some consumers to understand. Is it acceptable to condense the data into something more reasonable and present it in a manner that the consumer will understand? (EIEP 13B and procedures document)

#9 If HH data is available at element level (rather than register level), however daily and/or monthly data is available at register level, which should be supplied in EIEP 13A i.e. would like to clarify which is considered the “most detailed” in this scenario as arguably summarised information at a lower level of detail (i.e. register level) could be considered more detailed in the context of what the data is to be used for. (EIEP 13A and procedures document)

#10 The DET line Read Status field allows RD/read and ES/estimated, as EIEP 13A is consumption information while EIEP 13B is billed consumption. It looks like NHH EIEP 13A files can contain read-to-read consumption with estimates removed. Is that correct? (EIEP 13A and 13B)

#11 The file types in the HDR records (ICPCONS, ICPSUMM, and REQCONS) will be the file type in the file name (4th component of the filename). However this is not explicitly stated.

#12 Just wondering why there is an installation address country (this is not a postal address)? And why the install address postcode makes reference to outside NZ (besides it is always just a ‘postcode’ regardless of the local name)? (EIEP 13C)

#13 DET row NZDT Adjustment field in EIEP 13A is char 3 but requires char 4 (EIEP13B has char 4). (EIEP 13A)

#14 The EIEP 13B HDR row has no ‘sent on behalf of’ field which is inconsistent with EIEP13A which has this field (I expected EIEP13A and EIEP13B to have similar HDR structures). (EIEP 13B)

#15 The following format and example are inconsistent in EIEP 13B:

  1. The DES row does not have an ICP field while the DET row does (these 2 row types should match as the DES row is really a “header row” for Excel etc).
  2. The example file does not have an ICP in the DET row but does have an ICP in the HDR row which the format does not.
  3. A lot of the example file HDR does not match the HDR format (the example HDR looks a bit like an EIEP 1 HDR with “E,I” etc, it lacks a file type of ICPSUMM, has no NZDT field). Basically the EIEP 13B format and example need looked at / checked.

#16 A decision is required as to what is acceptable as a representation of an authorisation from an agent. Do we need to view the authorisation is some form or do we accept an agent’s representation

#17 Irrespective of the decision as to the approach to accepting authorisations for each type of agents (i.e. with or without agreements) what are retailer’s minimum requirements for a valid authorisation? Does it have to be a copy of a document? If so what should the wording be and what information should be on there?

#18 If a retailer has an agreement to accept a representation from an agent that they hold a consumer authorisation then presumably they would be subject to an audit. Who would perform this audit and how often? What actions would have to be taken if there was insufficient evidence of an authorisation? Would retailers need to advise all consumers affected that there had been a breach of privacy? Who else would retailers need to advise?

#19 The Authority procedures and EIEP 13C contains a Consumer Authorisation Code. When is this expected to be used? Is this supposed to be issued by the retailer prior to any EIEP 13C request and then referenced within the EIEP 13C or is it meant to issued by the agent in the first EIEP 13C and the referenced in subsequent EIEP 13Cs for that consumer?

#20 Who can be an agent? Are there any restrictions? Is there any way to confirm that a party is genuinely an agent or could anybody just get an authorisation from a consumer and then acquire their data?

#21 EIEP 13C identifies the matching of customer names where multiple names are concatenated on a request. This looks likely to be highly error prone. In order for this to work the names would have to recorded exactly as they are specified on the invoice including punctuation and the number of blank spaces between words. (EIEP 13C)

#22 EIEP13C contains install address details. Are these supposed to be the same as the billing address on the invoice or are they install details from the Registry i.e. the address of the ICP?

#23 What happens if there is a breach of the five day response time to consumers as per the Code? Do we self-report a breach or will it be up to the customer to complain?

#24 An item that would be really beneficial are sample files or file formats in the pdfs. When we reviewed earlier, some of the EIEP 13 documents had samples but others did not. Would it be possible to include sample files in the correct format to aid in understanding?

#25 EIEP 13A has a mandatory field in the header for version number to be shown. EIEPs 13B and 13C have no field\requirement for the version number to be shown?

#26 Energy Flow Direction field: Both formats specify ‘Char 1’ but EIEP 13B specifies the words to be shown in full – as verified by the sample file supplied?

#27 We have been considering our options for authenticating agent requests, and are considering requiring agents to always provide an EIEP13C (whether via the registry hub or as an email attachment). The advantage is EIEP 13C is structured. We don’t see anything in the Procedures that would prevent us requiring that EIEP 13C be provided for all agent requests. Can you please confirm?

#28  In both EIEP13A and 13B there is a column called ' Metering component serial number '. Is it appropriate/acceptable to include the channel number in the data provided for this field as that will help customers reconcile the data to their invoices more accurately in the case where there are multiple channels?  For example, if there were a Metering Component with Serial Number 12345 and Channels 1 & 2 - the output would be 12345/1 and 12345/2 respectively. 

 #29 In the situation where a NHH ICP is billed monthly (for example from the 15th to the 15th of the month; and another meter reading is received in the middle of this period - on the 30th of the month) is the retailer required to report the reading dated on the 30th of the month if it is not used in preparation of the invoice to the customer? 

#30 The field size of "Energy flow direction" in EIEP 13B needs to be increased from Char1 to at least Char11 to allow the words “Consumption” or “Generation” to be used.

#31 Is there an embedded generation register content code for HHR?

#32 EIEP13A includes a mandatory  field ‘Sent on behalf of’ .  We assume this is to cover where a retailer’s service provider might provide the consumption information on the retailer’s behalf.  Where the retailer is the sender, as the field is a mandatory one, should the ‘Sent on behalf of’ field also contain the participant identifier of the retailer?  

#33 There is an error in the example file in EIEP 13B. The example file lists 'ICPSUM', but the file type field lists Char 7 with 'ICPSUMM'. Which is correct?

#34 The example file in EIEP 13B has leading spaces in several of its fields. Is this correct?

#35 Has the Authority given any thought to standardising the agent authentication process to ensure that it:

• meets retailers’ privacy obligations to consumers and does not result in reputational harm to the industry because of an inadvertent breach
• provides a smooth experience for third parties and consumers.

 #36 13A has a "Version of EIEP" field.......what is expected in here? Is it the version of the latest spec document ie 1.1 or is it something else? Please advise. 

# 37  13B doesnt have a "Version of EIEP" field.......is this an over-site or planned?

#38 EIEP13C – “Consumer Number” – We would like to clarify our understanding that this may be any identifying number that can be used to link the premises and the customer in the Retailers system (e.g. may be a “customer number” or an “account number”).

#39 EIEP13C – “Consumer Number” –The validation rules for this field state “if not available then use null” which contradicts it’s classification as a mandatory field. We view the provision of this field as essential to the validation of these electronic file and sees no reason why this information would not be available to an agent. Please can you clarify the intended status of this field (i.e. optional or mandatory)

#40 EIEP13A/B –Rejection codes – given that multiple error conditions may exist (e.g. and agent may not be authorised and the supplied ICP record may not exist), only one rejection code may be used at a time and the priority in which these should be used has not been specified, is it intended that each retailer will determine their own rules for application of rejection codes?

#41 Will there be any centrally held  list of agents (that are approved to use the Registry Hub) that contains contact details?  We are looking at whether there will be any way for us to contact an agent if necessary to obtain further information in relation to a request received via the Hub.

#42 We note that the EIEP13B does not contain any Consumer Authorisation Code field (as the EIEP13A does) although it is able to be requested using an EIEP13C – perhaps this needs inclusion?

#43 In the EIEP13C we think the Validation rules for the Customer Authorisation Code are incorrect and should say “Mandatory if the Consumer Authorisation Code field was populated in a corresponding request using EIEP13C” or words to that effect. 

#44 We would like to clarify that for a customer with a legacy TOU meter, where HH consumption information is displayed in summarised time periods on the customers invoice (e.g. Business day/Non Business day “144” format) , whether it would be acceptable to provide HH level information in the EIEP13B or whether this must be summarised to the time periods displayed on the invoice?

#45 We note that HH active and reactive energy have differing register content codes in the SD-020.  Given that EIEP 13A allows for the provision of both active and reactive energy in a single DET row, we would like to clarify that, for this scenario, the register content code populated in that row should relate to the active energy only (i.e. 7304).

#46 We would like to confirm what should populated in “Unit quantity active energy volume” field of the EIEP 13A file if data for 1 or more time periods is not available (i.e. missing). Should this be:

a. left blank (i.e. represented by “,,” in the file); or
b. populated with the word “null”?

#47 We would like to know whether the Authority intends to provide any further guideline to retailers, regarding the content of annual notifications to consumers regarding the availability of consumption data or whether this will be entirely left to retailers (provided it covers the consumer’s right/ability to access their consumption information)?

#48 In relation to clause 11.32A(2) of the Code, if more granular data than that used for billing purposes has, at any point during the 24 months preceding  1 February 2016, been used to provide a service but that service is not being provided at 1 February 2016, is a retailer obliged to provide the more granular data to a customer who requests it for the period during which that service was provided?  Or is it the case that as the service is not being provided and the data is not being used as at 1 February 2016 that the retailer is not obliged to provide the data it holds (but does not use) as at 1 February?

#49 What are the principle differences between EIEP 13A and EIEP 13B, and why would you request one over the other?

#50 We would like to clarify the 5 business day timeframe outlined in 11.32B of the Code so we can ensure our processes are designed to meet this and reporting correctly identifies any non-compliance. When is the first business day - on the day of the request or the day after?

#51 Does the consumption data being supplied need to be Bill Consumption or should it be Normalised Consumption?

#1 What are the rules for Read Status? If the HHR data is not validated should it be labelled as estimated? (13A)

The Authority has decided that the most granular information is to be provided, regardless of whether it is validated. If the information is not validated, it should be marked as an estimate.

Return to top

#2 Postal address fields in EIEP13C are not required as it is not an "EIEP delivery method". (13A, 13B, 13C) 

Agree. EIEP 13C would not be used by a consumer to request a posted hard copy of EIEP 13B. We have amended EIEP 13C to use the ‘install’ address rather than the ‘postal’ address. A consequential change has been made to EIEPs 13A and 13B in the ‘response code’ field. Reject code 001 now reads: 001 – Request rejected, no ICP or address or and customer match.

Return to top

#3 There are no specifications under which the EIEP 13A or B rejection file should be provided. Please can you confirm whether the intention is that this be limited only to where the request for the EIEP 13A or B has been made via the EIEP 13C file through the Registry Hub? i.e. requests made via e-mail, whether they include an EIEP 13C file or not, may be rejected by way of return e-mail to the requestor without provision of a rejection file. (EIEP 13A and B)

The purpose of the rejection file is for automation (machine to machine) so our expectation is that this would only be provided on this basis. Requests made by email may be rejected by way of return email without the provision of a rejection file.

Return to top

#4 11.32C specifies that retailers must notify consumers at least once each calendar year. We would like clarification on how this is intended to work in the case where a consumer switches to a retailer on, for example, 30th November? Is the retailer expected to notify that consumer before the end of the calendar year (given that it is possible that consumer has only just been notified by their previous retailer)? The obligation to notify consumers would be more efficient to manage and more easily aligned with other notifications(i.e. low user, medically dependent) if this was required once in a 12 month period rather than once in a calendar year.

The reference to calendar year does mean that the retailer must notify the consumer by the end of the year. In the example where the customer is switched in on 30 November would mean that the retailer would need to tell the consumer by end of December. However, the retailer could include such a notification in its initial information that is provided to consumers at the time of the switch. Subsequent notification could be via its annual notifications.

Return to top

#5 Regarding requirement 14/15 of EIEP 13A, it is likely that HH data provided to agents/consumers will contain some gaps. This will be the most detailed consumption information available in our system at the time of the request. Those gaps may be resolved in our system at a date after the request has been fulfilled via a “catch up” file from the MEP. Is it intended that, following receipt of such a catch up file, we would be required to provide revised data to the agent/consumer? (EIEP 13A)

No, there is no requirement for retailers to provide revised data. The consumer would need to request the information in a subsequent request.

Return to top

#6  Under clause 11.32B(2) where the retailer has 5 business days to provide consumption information to the requesting consumer, is information considered ‘provided’ to the consumer when it is sent by the retailer or when it is received by the consumer? i.e. for requests fulfilled by post, is a retailer expected to consider in its processes the time taken for the information to reach the consumer.

Clause 11.32B(2) is intended to give retailers five business days to respond to the consumer’s request for consumption information. Therefore the retailer, if processing by post, may post the information on the fifth business day to the consumer.

Return to top

#7  Will the Authority’s approval process for granting consumer agents access to the Registry EIEP Hub include any requirement for the agent to have arrangements in place with retailers for requesting consumption data or will ‘anyone’ be able to be granted access and start sending requests for consumption data without a retailer having visibility to what agents it may receive requests from?
  1. The Authority’s process for granting consumers agents access to the registry EIEP hub will not include requirements for the agent to have arrangements in place with retailers for requesting consumption data. There is a possibility that a retailer may receive a request from a third party provider prior to that retailer and third party provider having an arrangement in place. We will be encouraging third party providers to discuss arrangements with retailers prior to sending requests through the EIEP hub.
  2. We will have a sign-up process for any third party providers looking to access the EIEP hub for the purposes of requesting consumption data from retailers. We are currently working through the details of the sign-up process for third party providers.

Return to top

#8 The Authority requirement to provide ‘all’ data pertaining to a consumer will be a challenge for some consumers to understand. Is it acceptable to condense the data into something more reasonable and present it in a manner that the consumer will understand? (EIEP 13B and procedures document)

In this instance, paragraph 36 of the procedures document would apply. If a consumer requests EIEP 13B, the retailer may re-direct the consumer to its website as long as the information provided on the website contains the same information as EIEP 13B, but perhaps in a different format. We believe that if the consumer wants to perform any analysis on its consumption information, the consumer may request EIEP 13A.

Please note that if the request is from a consumer's authorised agent, you would be required to provide EIEP 13B.

Return to top

#9If HH data is available at element level (rather than register level), however daily and/or monthly data is available at register level, which should be supplied in EIEP 13A i.e. would like to clarify which is considered the “most detailed” in this scenario as arguably summarised information at a lower level of detail (i.e. register level) could be considered more detailed in the context of what the data is to be used for. (EIEP 13A and procedures document)

Two example diagrams have been provided to answer this question.

In diagram 1, the trader would:

  • provide the register HH data (at the elemental level) in EIEP 13A as this is the greatest granularity of data with a register content code of 7304
  • if asked, for EIEP 13B provide the meter register volumes against the appropriate register content code.

In diagram 2, the trader would:

  • provide the register HH data (at the elemental level) in EIEP 13A as this is the greatest granularity of data with a register content code of 7304, although it would not provide any resolution of the UN and CN register content codes
  • if asked, for EIEP13B provide the meter register volumes against the appropriate register content code.

Return to top

#10 The DET line Read Status field allows RD/read and ES/estimated, as EIEP 13A is consumption information while EIEP 13B is billed consumption. It looks like NHH EIEP 13A files can contain read-to-read consumption with estimates removed. Is that correct? (EIEP 13A and 13B)

The requirement is the same for both EIEP 13A and 13B – estimates should be provided.

Return to top

#11 The file types in the HDR records (ICPCONS, ICPSUMM, and REQCONS) will be the file type in the file name (4th component of the filename). However this is not explicitly stated.

It is implied, but when we next update the EIEPs we will include it as an amendment. EI-030 requires file type.

Return to top

#12 Just wondering why there is an installation address country (this is not a postal address)? And why the install address postcode makes reference to outside NZ (besides it is always just a ‘postcode’ regardless of the local name)? (EIEP 13C)

These are the same physical address fields that the registry uses, and it can be blank. It is the retailers’ choice whether the information is used or not. Retailers will need to agree with the third party provider that will use the file format.

Return to top

#13 DET row NZDT Adjustment field in EIEP 13A is char 3 but requires char 4 (EIEP13B has char 4). (EIEP 13A)

Agree. EIEP 13A should be char 4. This will be updated and notified to all parties.

Return to top

#14 The EIEP 13B HDR row has no ‘sent on behalf of’ field which is inconsistent with EIEP13A which has this field (I expected EIEP13A and EIEP13B to have similar HDR structures). (EIEP 13B)

EIEPs 13A and 13B are not meant to be consistent. It is correct that they have different HDR rows.

Return to top

#15 The following format and example are inconsistent in EIEP 13B:
(a) The DES row does not have an ICP field while the DET row does (these 2 row types should match as the DES row is really a “header row” for Excel etc).

This is a mistake in the file format. There should be a text header for “ICP identifier” added. We will amend the file format and notify all parties.

(b) The example file does not have an ICP in the DET row but does have an ICP in the HDR row which the format does not.

This is a mistake. There should be an ICP identifier in the example. This will be corrected.

(c) A lot of the example file HDR does not match the HDR format (the example HDR looks a bit like an EIEP 1 HDR with “E,I” etc, it lacks a file type of ICPSUMM, has no NZDT field). Basically the EIEP 13B format and example need looked at / checked.

That was deliberate. EIEP 13A is for machine to machine. EIEP 13B is intended to be for customer information.

Return to top

#16 A decision is required as to what is acceptable as a representation of an authorisation from an agent. Do we need to view the authorisation is some form or do we accept an agent’s representation

This is a policy issue for retailers. Retailers must consider the Privacy Act and customer confidentiality. Agents are currently not a participant and are not a party that the Authority can regulate.

Return to top

#17 Irrespective of the decision as to the approach to accepting authorisations for each type of agents (i.e. with or without agreements) what are retailer’s minimum requirements for a valid authorisation? Does it have to be a copy of a document? If so what should the wording be and what information should be on there?

This is a policy issue for retailers. Retailers must consider the Privacy Act and customer confidentiality.

Return to top

#18 If a retailer has an agreement to accept a representation from an agent that they hold a consumer authorisation then presumably they would be subject to an audit. Who would perform this audit and how often? What actions would have to be taken if there was insufficient evidence of an authorisation? Would retailers need to advise all consumers affected that there had been a breach of privacy? Who else would retailers need to advise?

This is a policy issue for retailers. If there was a breach of your terms with an agent, you could report that breach to the Authority, who may terminate the agent’s use of the EIEP transfer hub.

Return to top

#19 The Authority procedures and EIEP 13C contains a Consumer Authorisation Code. When is this expected to be used? Is this supposed to be issued by the retailer prior to any EIEP 13C request and then referenced within the EIEP 13C or is it meant to issued by the agent in the first EIEP 13C and the referenced in subsequent EIEP 13Cs for that consumer?

The Consumer Authorisation Code is an optional field. It could be issued by either the retailer or the agent, subject to mutual agreement. The Code does not include this as a requirement; we included the field in case it is useful for retailers and agents

Return to top

#20 Who can be an agent? Are there any restrictions? Is there any way to confirm that a party is genuinely an agent or could anybody just get an authorisation from a consumer and then acquire their data?

The Authority will not be vetting agents, although we will be approving access to the EIEP transfer hub. We also have the right to terminate an agent’s access to the EIEP transfer hub for inappropriate use. We would expect that an agent could be any person acting on behalf of a consumer, but it is likely that there will be a smaller number of third party suppliers that will act for a large number of consumers that will be well known to retailers.

Return to top

#21 EIEP 13C identifies the matching of customer names where multiple names are concatenated on a request. This looks likely to be highly error prone. In order for this to work the names would have to recorded exactly as they are specified on the invoice including punctuation and the number of blank spaces between words. (EIEP 13C)

This would depend how much variation you would allow in your internal criteria. For instance you could match on words rather than the exact string.

Return to top

#22 EIEP13C contains install address details. Are these supposed to be the same as the billing address on the invoice or are they install details from the Registry i.e. the address of the ICP?

Billing address and install address may be two different things. Billing address may be a P.O. Box number so will not identify an ICP. Although the fields are in the format, if you consider that the ICP number and name fields or customer number meet your requirement, the validation used is the retailer’s choice.

Return to top

#23 What happens if there is a breach of the five day response time to consumers as per the Code? Do we self-report a breach or will it be up to the customer to complain?

This is a policy issue for retailers. The Electricity Industry (Enforcement) Regulations 2010 do not require you to self-report a breach, but does require any participant that notices a breach on another participant to report it.

Return to top

#24 An item that would be really beneficial are sample files or file formats in the pdfs. When we reviewed earlier, some of the EIEP 13 documents had samples but others did not. Would it be possible to include sample files in the correct format to aid in understanding?

We will produce some example files, publish them on our website and notify all parties.

Return to top

#25 EIEP 13A has a mandatory field in the header for version number to be shown. EIEPs 13B and 13C have no field\requirement for the version number to be shown?

Originally headers were the same but somewhere along the line it was decided to make them different. We will investigate tidying this up.

Return to top

#26 Energy Flow Direction field: Both formats specify ‘Char 1’ but EIEP 13B specifies the words to be shown in full – as verified by the sample file supplied?

The formats are correct. We did not think consumers would understand I or X so used words on EIEP13B. EIEP 13A is machine to machine so I and X are fine.

Return to top

#27 We have been considering our options for authenticating agent requests, and are considering requiring agents to always provide an EIEP13C (whether via the registry hub or as an email attachment). The advantage is EIEP 13C is structured. We don’t see anything in the Procedures that would prevent us requiring that EIEP 13C be provided for all agent requests. Can you please confirm?

As per paragraph 18 of the procedures, we would encourage all consumers agents to use EIEP 13C when requesting consumption information. We agree that this would be of benefit to both the agent and the retailer. The retailer and the agent may come to an arrangement that this would be the manner in which all consumer consumption information would be requested. Certainly if the agent is using the EIEP transfer hub, EIEP 13C would be required. However, as agents are not regulated under the Code, the Authority cannot require that agents use EIEP 13C when requesting consumption information via email.

Return to top

#28 In both EIEP13A and 13B there is a column called ' Metering component serial number '. Is it appropriate/acceptable to include the channel number in the data provided for this field as that will help customers reconcile the data to their invoices more accurately in the case where there are multiple channels? For example, if there were a Metering Component with Serial Number 12345 and Channels 1 & 2 - the output would be 12345/1 and 12345/2 respectively.

Yes, one of the purposes of this field is to enable customers to reconcile the data provided to their invoices, so it is up to retailers to include channel numbers where this has been detailed on their invoices. Volumes that have the same meter serial number, register content code and period of availability may also be aggregated .

Return to top

#29 In the situation where a NHH ICP is billed monthly (for example from the 15th to the 15th of the month; and another meter reading is received in the middle of this period - on the 30th of the month) is the retailer required to report the reading dated on the 30th of the month if it is not used in preparation of the invoice to the customer?

The Code states that all data must be provided in the EIEP13A and 13B reports if that data is 'used', but the Code is silent on what that use might constitute. If the reading on the 30th is not used for any purpose at all by the retailer then it can be excluded from both reports. If however, that reading is used by the retailer in other parts of their business (for example for preparation of historic/forward estimates for reconciliation data reporting) or used on web portal data, then it is being used and therefore should be included in both report outputs.

Return to top

#30 The field size of "Energy flow direction" in EIEP 13B needs to be increased from Char1 to at least Char11 to allow the words “Consumption” or “Generation” to be used.

We agree. The 'Energy flow direction' field size will be increased to Char15 in version 1.2 of EIEP 13B.

Return to top

#31 Is there an embedded generation register content code for HHR?

7304 is the HHR code which is a bidirectional register content code. There is a flow direction of I or X included in the registry for all channels. I or X is also included in EIEPs 1 and 3, and all other market files to indicate flow direction.

Return to top

#32 EIEP13A includes a mandatory field ‘Sent on behalf of’ . We assume this is to cover where a retailer’s service provider might provide the consumption information on the retailer’s behalf. Where the retailer is the sender, as the field is a mandatory one, should the ‘Sent on behalf of’ field also contain the participant identifier of the retailer?

This is correct, where the retailer is the sender the 'Sent on behalf of' field should contain the retailer’s participant identifier.

Return to top

#33 There is an error in the example file in EIEP 13B. The example file lists 'ICPSUM', but the file type field lists Char 7 with 'ICPSUMM'. Which is correct?

The correct file type is 'ICPSUMM'. EIEP 13B has been updated accordingly.

Return to top

#34 The example file in EIEP 13B has leading spaces in several of its fields. Is this correct?

No, there should not be any leading spaces in the example file in EIEP 13B. EIEP 13B has been updated.

Return to top

 

#35 Has the Authority given any thought to standardising the agent authentication process to ensure that it:
• meets retailers’ privacy obligations to consumers and does not result in reputational harm to the industry because of an inadvertent breach
• provides a smooth experience for third parties and consumers.

 

The Privacy Act 1993 requirements with regard to consumers rights to access data about their electricity usage was a key consideration by the Authority. The Authority considers that retailers are best placed to address and consider privacy issues because they are responsible for protecting consumer information as part of their business, and are likely to have appropriate procedures in place.

The Authority does not consider that it has a role to play in standardising the authentication process. This is something retailers and potential agents need to agree between themselves as part of their commercial arrangements, taking into account the requirements of the Privacy Act.

Return to top


#36 13A has a "Version of EIEP" field.......what is expected in here? Is it the version of the latest spec document ie 1.1 or is it something else? Please advise. 

The version number is 1.1

Return to top

# 37 13B doesnt have a "Version of EIEP" field.......is this an over-site or planned?

13B does not have a “Version of EIEP” field- this was planned.

Return to top

#38 EIEP13C – “Consumer Number” – We would like to clarify our understanding that this may be any identifying number that can be used to link the premises and the customer in the Retailers system (e.g. may be a “customer number” or an “account number”).

Correct.

Return to top

#39 EIEP13C – “Consumer Number” –The validation rules for this field state “if not available then use null” which contradicts it’s classification as a mandatory field.  We view the provision of this field as essential to the validation of these electronic file and sees no reason why this information would not be available to an agent.  Please can you clarify the intended status of this field (i.e. optional or mandatory)

 The intent was if the consumer number is available on invoices it should be used. However if a retailer has not provided the consumer number to its customers, an agent would not have access to it. The consumer or its agent would either need to obtain the consumer number from the retailer, or leave the field as “null”. Retailers need to develop their own processes for validating that a request for information is appropriate. EIEP13C format does state “Mandatory where a code has been agreed” for that particular field.

Return to top

#40 EIEP13A/B –Rejection codes – given that multiple error conditions may exist (e.g. and agent may not be authorised and the supplied ICP record may not exist), only one rejection code may be used at a time and the priority in which these should be used has not been specified, is it intended that each retailer will determine their own rules for application of rejection codes?  

Correct. 

Return to top

 

#41 Will there be any centrally held list of agents (that are approved to use the Registry Hub) that contains contact details? We are looking at whether there will be any way for us to contact an agent if necessary to obtain further information in relation to a request received via the Hub.

The Authority will be publishing the participant identifier and name of the agent, but not contact details. If a trader receives an unknown agent request, they can reject the request.

Return to top

#42 We note that the EIEP13B does not contain any Consumer Authorisation Code field (as the EIEP13A does) although it is able to be requested using an EIEP13C – perhaps this needs inclusion?

The Authority does not consider Consumer Authorisation Code field necessary in EIEP13B.

Return to top

#43 In the EIEP13C we think the Validation rules for the Customer Authorisation Code are incorrect and should say “Mandatory if the Consumer Authorisation Code field was populated in a corresponding request using EIEP13C” or words to that effect.

 It is up to the trader to agree with agents what will be provided.

Return to top

#44 We would like to clarify that for a customer with a legacy TOU meter, where HH consumption information is displayed in summarised time periods on the customers invoice (e.g. Business day/Non Business day “144” format) , whether it would be acceptable to provide HH level information in the EIEP13B or whether this must be summarised to the time periods displayed on the invoice?

EIEP 13B should have the same time periods as used in invoicing.

Return to top


#45 We note that HH active and reactive energy have differing register content codes in the SD-020. Given that EIEP 13A allows for the provision of both active and reactive energy in a single DET row, we would like to clarify that, for this scenario, the register content code populated in that row should relate to the active energy only (i.e. 7304).

Yes, this is correct. For this scenario, it should relate to the active energy only.

Return to top


#46 We would like to confirm what should populated in “Unit quantity active energy volume” field of the EIEP 13A file if data for 1 or more time periods is not available (i.e. missing). Should this be:
a. left blank (i.e. represented by “,,” in the file); or
b. populated with the word “null”?

Where there is data for 1 or more time periods not available, the ‘unit quantity active energy volume’ should be left blank (i.e. represented by “,,” in the file).

Return to top

#47 We would like to know whether the Authority intends to provide any further guideline to retailers, regarding the content of annual notifications to consumers regarding the availability of consumption data or whether this will be entirely left to retailers (provided it covers the consumer’s right/ability to access their consumption information)?

We will not be providing any guidance to retailers on the content of the annual notifications to consumers regarding the availability of consumption data. We may, in the future, perform some monitoring of the provision of consumer consumption information.

Return to top

#48 In relation to clause 11.32A(2) of the Code, if more granular data than that used for billing purposes has, at any point during the 24 months preceding  1 February 2016, been used to provide a service but that service is not being provided at 1 February 2016, is a retailer obliged to provide the more granular data to a customer who requests it for the period during which that service was provided?  Or is it the case that as the service is not being provided and the data is not being used as at 1 February 2016 that the retailer is not obliged to provide the data it holds (but does not use) as at 1 February?

Yes. A retailer would have to provide the more granular data. The Code specifies this by stating the ‘information relating to any period in the 24 months preceding the request’.  

Return to top

#49 What are the principle differences between EIEP 13A and EIEP 13B, and why would you request one over the other?


In order to clarify the expected use of the two EIEP13 returns, it probably helps to think of them as:

EIEP13A – Consumption data for a two year period

Returns consumption information at as fine a granular level (HHR or NHH) as recorded in the retailer’s system.

As examples,

  1. if a retailer receives and uses both HHR and NHH meter readings from an AMI meter and
    1. Uses HHR information, eg in the reconciliation process or in a web portal or to deliver any other service, and
    2. Uses NHH information for invoicing purposes, then the retailer should return HHR information in EIEP13A
  2. if a retailer receives both HHR and NHH meter readings from an AMI meter and
    1. Does not use the HHR information in any process, and
    2. Uses NHH information for invoicing purposes, then the retailer should return NHH information in EIEP13A for each register content code
  3. if a retailer receives only HHR meter readings from an AMI meter and
    1. Does not use the HHR information in any process, and
    2. Sums HHR information into time periods for invoicing purposes, then the retailer should return HHR information in EIEP13A

EIEP13B – Billed data for a two year period

Returns Billed volumes (irrespective of whether the data is supplied as HHR or NHH).

Volumes must match the billed consumption information that the retailer has supplied to the consumer.

Any read period comprising date and time can be accommodated using this format, whether monthly, weekly, daily, or certain parts of a day.

As examples,

  1. If an ICP’s data is supplied as HHR, but it is billed on a monthly total, then there would be one line per month per register content code.
  2. If an ICP’s data is supplied as HHR, but it is billed on a monthly total, split into day and night then there would be two lines per month as there would be two register content codes.
  3. If an ICP’s data is supplied as (say) 9 register reads and billed as 8 Rate (Summer/Winter, Day/Night,Weekend/weekday) + max demand, there would be 9 lines per month as there would be 9 register content codes
50. We would like to clarify the 5 business day timeframe outlined in 11.32B of the Code so we can ensure our processes are designed to meet this and reporting correctly identifies any non-compliance. When is the first business day - on the day of the request or the day after?

The first business day is on the day after the request is made. For example:

  • Monday 7 December request is received
  • Tuesday 8 December is the first business day
  • Monday 14 December is the fifth business day

The day a request is made does not count as a business day.

Return to top

#51 Does the consumption data being supplied need to be Bill Consumption or should it be Normalised Consumption?

Billed consumption for EIEP 13B, Actual recorded consumption in the EIEP 13A, no option for normalisation. The difference being if you calculate your bills from HHR data, but bill it as (say) inclusive monthly, 1440 lines in the A, 1 line in the B.

Return to top