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.

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.

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.

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.

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

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.

  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.

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.

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.

 

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

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

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.

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

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

  1. 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.
  2. This is a mistake. There should be an ICP identifier in the example. This will be corrected.
  3. That was deliberate. EIEP 13A is for machine to machine. EIEP 13B is intended to be for customer information.

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.

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

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.

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

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.

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.

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.

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.

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

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

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.

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.

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 .

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.

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

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.

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

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

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

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.

The version number is 1.1

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

Correct.

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. 

Correct. 

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.

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

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

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

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

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).

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.

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’. 

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

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.

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.