Decision Proposal 180 - Energy Draft Feedback Cycle 3

[CDR-API-Stream]

This consultation thread has been raised to allow for holistic feedback to be provided on the draft energy standards as a whole. It is a continuation of the previous holistic consultation.

The draft energy standards (which are draft only and non-binding) can be found on the standards site at:
https://consumerdatastandardsaustralia.github.io/standards/draft/energy-draft.html

Feedback is now open on any issue related to draft. This thread will remain open until June 11th 2021. At that time proposed changes will be incorporated and a second consultation cycle will commence.

[EnergyAustraliaCDR]

Hi All,

Feedback from EnergyAustralia below:

Get Generic Plans and Get Generic Plan Detail
The AER provides retailers with a portal to create and change Basic Plan Information Documents (BPIDs) for the Energy Made Easy (EME) website. A similar arrangement exists in Victoria. In the Generic tariff response samples, the code refers to the various fields as defined for EME and Vic Energy Compare. The CDR process for Generic tariff data will leverage off the processes for EME and Vic Energy Compare. We understand that changes to the Generic tariff data set will ultimately require changes to the EME and Vic Energy Compare data fields.

While the EME and Vic Energy Compare data fields are very good at summarising the key pricing information, it is worth noting that sometimes the data fields may not work for certain plans. For example, the structure of Energex’s Small Business Wide Inclining Fixed Tariff (network tariff codes 6000 & 6020) which has an inclining fixed charge in $/day based on 20 MWh p.a. blocks (0-20,20-40,40-60,60-80,80-100 MWh p.a.), plus a flat volume charge in $/kWh. No retailer tariffs reflected this network tariff structure prior to its introduction. Further the AER had not designed EME to provide for this tariff structure. To create BPIDs, EnergyAustralia used the ‘additional_fees’ field to enter the inclining fixed charge as a string. EnergyAustralia’s current WIFT offer is at: Energy Made Easy. While this workaround may work for EME, it may not be appropriate for the CDR where the preference is for machine readability. ADRs will also struggle to work with free text data.

The above example relates to a fairly standard electricity plan offer. For innovative products which do not align with a typical electricity plan structure there may be a greater issue. We intend to post further examples of EA’s innovative products which do not easily fit into the EME and Vic Energy Compare data fields. While this is a problem that exists around the presentation of offers in the government comparison websites today, we wish to ensure that this problem is not continued under the CDR and through ADR use of the data – where the scale of usage could be much larger. It is very important that ADRs can compare like for like and that the generic tariff data supports these comparisons.

Get Invoices for Account & Get Billing for Account

We have noticed that the query parameters for the “Oldest-date” is inconsistent between Get Invoices for Account and Get Billing for Account, with the former showing 24 months vs the latter 12 months. We recommend aligning the two dates to either 12 or 24 months. Screenshots below.

[jonmilne]

Hi @EnergyAustraliaCDR . In response to your specific feedback that relates to Energy Made Easy...

The Energy Made Easy (EME) team recognises that there are network tariff structures that cannot currently be accommodated in retailer plan/product configurations in EME today. In addition, we acknowledge that there is an increasing need for greater flexibility in EME, to accommodate more innovative product offerings that retailers have introduced, or intend to introduce, to the market.

We are giving consideration to a range of changes to the existing EME Data Standard (and subsequent public website changes) that will afford retailers greater flexibility in their product configurations in EME. We anticipate needing to make changes to support the Energex small business tariff provided as an example, as well as changes to controlled load, solar, and demand charge components.

We will engage with retailers, using our established EME communications channels, once we commence planning and design for any required EME changes post-1 July. We will continue to work closely with both Victorian Energy Compare and the DSB to advise of any intended EME Data Standard changes, so that these can be incorporated in future iterations of the CDR Energy Standards.

[CDR-API-Stream]

In response to feedback from the previous cycle the DSB has met with the EME team and, as a result, we can provide the following clarifications and guidance. There are also some changes that will be incorporated into v1.10.0 of the draft standards:

Clarifications

• The effective from and to flags will be supported by the EME is considering an additional flag indicating that a plan would not be available until the effective from date. This will allow for the publishing of submitted plans on a specied future data/time but will also allow for pre-publishing with a future effective date/time so that clients can take the effective date into account.

• The use of brand in generic tariff end points has been discussed and clarified. The use of brand will be as follows:

  • The main retailer brand will be embedded in the base path URI under which the plans for each retailer are available. This will allow for a dedicated base path for each retailer that can be added to the Register by the retailer. It will also allow the retailer to apply their own domain name to redirect to this path if they wish to provide a vanity domain to the path.
  • The brand field in the payloads will only be for sub-brands that are clearly aligned to the master brand. Please refer to the white labelling and brand guidance provided to the banking sector on the CDR portal for further clarification of this position.
  • The mapping of legal entity to master brand will be managed by the AER in the EME system as it is currently

• Regarding the differentiation between a residential or business customer in the customerType field - it has been determined that this delineation is at the discretion of the retailer defining the plan. No industry wide definition will be applied. This is consistent to current practice for plans provided to the EME.

• It was raised that it is not clear how plans for Corporate and Institutional customers will be handled. It has been clarified that EME and VEC do not currently hold these plans so, if they are to be made available, that would be a change at the discretion of AER and DELWP. The CDR designation is to make available the data held by EME and VEC and therefore C&I plans will only come into scope if EME or VEC data sets are expanded.

• Expanded definitions of the enumeration values of the pricingModel field have been obtained. These are:

  • SINGLE_RATE - all energy usage is charged at a single unit rate no matter when it is consumed. Multiple unit rates may exist that correspond to varying volumes of usage i.e. a ‘block’ or ‘step’ tariff (first 50kWh @ X cents, next 50kWh at Y cents etc.)
  • SINGLE_RATE_CONT_LOAD - as above, but with an additional, separate unit rate charged for all energy usage from a controlled load i.e. separately metered appliance like hot water service, pool pump etc.
  • TIME_OF_USE - energy usage is charged at unit rates that vary dependent on time of day and day of week that the energy is consumed
  • TIME_OF_USE_CONT_LOAD - as above, but with an additional, separate unit rate charged for all energy usage from a controlled load i.e. separately metered appliance like hot water service, pool pump etc.
  • QUOTA - all energy usage is charged at a single fixed rate, up to a specified usage quota/allowance. All excess usage beyond the allowance is then charged at a single unit rate (may not be the best way to explain it but it is essentially a ‘subscription’ or telco style product i.e. $50/month for up to 150kWh included usage

• If a discount is offered for a conditional time period, this will typically be linked to the contract ‘benefit period’ duration. As the plan benefits (discounts, incentives etc.) are available for that time period alone i.e. 10% discount off usage charges for the first year (12 month benefit period). Granted, there are some implied links here that may need to be fleshed out better for CDR participants.

• Regarding the isFixed attribute, if this field is true then it indicates the energy charges are fixed for the duration of the contract term, or benefit period.

• Regarding unit type for on demand plans. It is understood that the EME can support multiple unit types for on demand plans including cents per kW, per kVA or per kVAR. The type of unit is currently captured in free form, however, so more work needs to be done to understand how this should be transferred in the payload.

Changes

• “Restricted” plans will be excluded from the returned payloads and the structure will be updated accordingly by removing the available field

• The description field in generic tariff will be made optional (EDIT: confirmed that this change is already incorporated into v1.9.0)

• Detail on the additional pricingModel enumerations will be added

• For other types of discounts an OTHER enumeration value will be added. For example, retailers can use the discount attributes to incorporate a sign-up bonus or loyalty credit that may be conditional on staying in the contract for 2 billing cycles – this is not a ‘PAY_ON_TIME’ or ‘DIRECT_DEBIT’ condition, so ‘OTHER’ can used to cater for this. Fixed and once-off discounts can be represented in the current structure by reference to the ‘type’ and ‘methodUType’ values.

[SelenaLiuEA]

Hi All

Thanks to Jon and the DSB for their feedback above. We look forward to further progressing the generic tariff data issues in the future.

Below is further feedback from EnergyAustralia in relation to Generic Tariffs and examples of innovative products that do not seem to fit the EME/payload structure.

The potential effect of this is that it could lead to incorrect plan comparisons by ADRs where ADRs interpret the data in an incorrect way because the payload descriptions do not clearly reflect what the data is.

We note that these issues are not answered by the DSB’s feedback posted just above.

Product with declining exit fee

Under our Solar Plus Plan ─ On by EnergyAustralia installs a solar system and battery for no upfront cost on a 7-year plan. There is a total contract exit fee, which is calculated on the systems value and number of days completed in the contract. The exit fee is very large at the beginning of the contract but then declines as the contract term continues to reflect that the systems have been progressively paid off. The exit fee is calculated as follows:

Where:

• x is the number of calendar days between the Contract Exit Date and the Expiry Date; and
• y is the number of calendar days between the Installation Date and the Expiry Date

The fee is neither a fixed nor a periodical fee. Rather, it’s a declining fee. The payload under the fee term doesn't provide a value that appropriate reflects the nature of the fee. Currently, it's either a fixed fee or by time period. An example of the EME BPID for our Solar Plus Plan is set out below, with the exit fee section highlighted to show the issue.

We recommend adding two additional values: "Total Contract", "Other" to cater for these kinds of innovative products where the standard fee structure doesn't apply.

Product with Subscription based fee with Unlimited usage

Easy Plan Plus is a subscription-based product with unlimited usage. The current Generic data payload structure requires a unitPrice and volume. However, this structure doesn’t work for the subscription-based model, where it does not have a volume range or limit (unlimited usage). We’re currently working around this in EME by entering an arbitrary figure in the volume field and then adding zero cents for anything above it. Please see the highlighted EME BPID below.

[PratibhaOrigin]

Thank you for the opportunity to provide feedback on the energy standards.
We would also like to thank DSB for the acknowledgement and response to most of the queries raised by Origin in the previous submission of DP-173.

Generic tariff data

Also, the clarification from VCE and EME on the queries regarding generic tariff is very helpful.

1. “Restricted” plans will be excluded from the returned payloads and the structure will be updated accordingly by removing the available field

   Thank you for this confirmation. Origin supports this change.

2. For other types of discounts an OTHER enumeration value will be added. For example, retailers can use the discount attributes to incorporate a sign-up bonus or loyalty credit that may be conditional on staying in the contract for 2 billing cycles – this is not a ‘PAY_ON_TIME’ or ‘DIRECT_DEBIT’ condition, so ‘OTHER’ can used to cater for this. Fixed and once-off discounts can be represented in the current structure by reference to the ‘type’ and ‘methodUType’ values.

   Thank you for this confirmation. Origin supports this change.

3. First off, there was a significant number of feedback items relating to C&I customers. Rather than respond to these individually it would appear that the APIs are not sufficient for larger customers and a dedicated consultation on this topic is warranted. This will be scheduled and will be based on the feedback provided to date.

   It was raised that it is not clear how plans for Corporate and Institutional customers will be handled. It has been clarified that EME and VEC do not currently hold these plans so, if they are to be made available, that would be a change at the discretion of AER and DELWP. The CDR designation is to make available the data held by EME and VEC and therefore C&I plans will only come into scope if EME or VEC data sets are expanded.

   Thank you for this confirmation. This helps and supports the feedback provided by Origin of multiple scenarios where the structure doesn’t support the C&I plans. We’ll wait for the rules to confirm and the clarify the CDR scope around C&I customers and further consultation on the C&I customers.

4. Detail on the additional pricingModel enumerations will be added

   Thank you for the details on the QUOTA pricing model. Origin supports this change.

Get Generic Plan Detail

1. Account number –

"isTokenised": {
"description": "Flag indicating that the account details are tokenised and cannot be shared. False if absent. If false then bsb and accountNumber should not be expected to be included"

Origin supports this change of “istokenised”.

NMI Standing Data

Get Service Points

1. ServicepointID –
   We understand there needs to be further clarification on this and is dependent on the queries raised via peer-to-peer model design paper –
   • Who generates it? Retailer (data holder) and passes on to AEMO (usage data holder) or vice versa?
   • ServicePointID is not NMI but is specific to each NMI. How will this work for embedded networks where there is no market NMI for off market sites.

• "servicePointId": "string",
• "nationalMeteringId": "string",
• "servicePointClassification": "EXTERNAL_PROFILE",
• "servicePointStatus": "ACTIVE",

What value needs to go for embedded network off-market sites -

• “nationalMeteringId" – ??
• “servicePointClassification" – Which of the following values are applicable for embedded network off-market NMI –
  “EXTERNAL_PROFILE",
  "GENERATOR",
  "INTERCONNECTOR",
  "LARGE",
  "SAMPLE",
  "SMALL",
  "WHOLESALE"
• "servicePointStatus":"OFF_MARKET" – Is this correct ??

2. Does the creationDateTime field relate to when the record was first created in the system or the market or the customer’s move in date? From a customer’s point of view, the creationDate (within the GET ACCOUNTS API) could be the start date. Is this the date that the account was created in the system or the start date of the customer account / contract at this site because they could be different?

3. nationalMeteringId" - Is it including checksum or excluding?

"nationalMeteringId": {
"type": "string",
"description": "The independent ID of the service point, known in the industry as the NMI"

Get Invoices for Account & Get Billing for Account

1. We concur with EA’s comments on “Oldest-date”. It should be made consistent in both APIs – either 12 or 24 months.

2. Regarding previous query for bill reversal scenarios, DSB suggested that -

‘The API is expected to provide a point in time response. Cancelled and re-issued invoices should be presented in their correct form at the time the API is called.”

A scenario of cancelled invoices with a pending rebill needs to be considered. This may also cover a rebilled period greater than 24mths. Is the recommendation -

• To include the reversed invoice with the new invoice information OR just the new invoice?
• If the new invoice is not available at the time i.e., delayed, then to either exclude the old invoice OR add a flag when sharing old invoice.

[CDR-API-Stream]

Thanks everyone for the feedback. The feedback is still being assessed. In the meantime, the thread will be left open for additional comment.

[CDR-API-Stream]

Feedback here has slowed and the activity has moved to the other consultations. We will therefore close this thread and encourage feedback in the other open consultation threads.