Decision Proposal 111 - Generic Tariff Data Payloads

[CDR-API-Stream]

The decision proposal for Generic Tariff data payloads is attached below:
Decision Proposal 111 - Generic Tariff Data Payloads.pdf

Feedback is welcome on this proposal. This thread will remain open for feedback until the 21st of August.

As previously discussed in various forums, the practice of the DSB is to respond to feedback incrementally before the consultation is complete to promote an interactive style of consultation.
Participants are therefore encouraged to provide feedback earlier in the consultation process so that the community can work together to a consensus outcome.

[dziga97]

How are seasonal tariffs recorded in the data payloads? I couldn't see them being accounted for - are common in South Australia and more recently have been introduced in NSW Ausgrid has Seasonal flexible tariffs.

[jonmilne]

@dziga97 As the basis for this proposal is the Energy Made Easy data/documentation, I can clarify that the 'tariffPeriod' array is used to define the unique periods of the year to which the nested rates apply. While tariff periods may be aligned to a calendar season, this is not always the case - hence the use of the more generic 'tariffPeriod' rather than 'season'.

[evtricity]

Some questions/feedback:

1. Is there an attribute for network tariff code? e.g. EA225
2. Is there support for time-varying feed-in tariffs?
3. Are there attributes covering feed-in tariff export caps/steps?
4. Are there attributes covering PV array and/or inverter size limits? eg. 5kW, 10kW
5. Are there attributes covering minimum and maximum usage limits? eg. 160MWh < 400MWh p.a.
6. Is there an attribute for minimum chargeable demand quantity? e.g. 1.5kWh
7. Is there an attribute covering minimum battery capacity? eg. 6kWh for VPP plans
8. Is there a fee type for solar metering e.g. 7c per day in Energex network
9. Is there a need for a Cheque Dishonour fee if cheques aren't a supported payment option?
10. PAPER_BILL is not a payment option.
11. Can the isFixed field be enhanced to be a string and support the three types of pricing that exists - variable, fixed and market-linked (i.e. Amber Electric and Powerclub are market-linked which is very different from "normal" variable rate plans)?
12. Is there a field for the BPID ID and the Victorian Energy Fact Sheet ID e.g. RED21338MRE4, RED181822MR?
13. Need to add an Eligibility restriction for having an Electric Vehicle? eg. EXISTING_ELECTRIC_VEHICLE for AGL/Powershop/Red EV plans
14. Can attributes be added to reflect whether a plan is 100% Carbon Offset?
15. What attributes make up the natural/business key?

Cheers.

[SelenaLiuEA]

Good afternoon,

EnergyAustralia's general comments are:

• These data payloads might not be appropriate to clearly present non-conventional energy plans with different tariff and product structures. For example, subscription type energy plans. This is an issue that likely exists today for data that is input into EME and Vic Energy Compare and we will raise this in the ACCC’s Rule Framework Consultation as it relates to a broader policy question.

• There are inconsistencies with the data entry requirements for Vic Energy Compare and EME which is again an issue that exists today and results in inefficiencies in providing data to EME and Vic Energy Compare. Under the CDR, this will mean inconsistencies in Victorian and non-Victorian Energy Plan data which will need to be addressed by ADRs and retailers, when building their analytical or data holder solutions.

• There are significant opportunities to streamline the data entry requirements across Vic Energy Compare and EME. Ultimately one portal for both Vic Energy Compare and EME would be ideal. But other efficiencies can be achieved in the meantime starting with ensuring the same data is entered for the same data fields in EME and Vic Energy Compare. We will discuss these streamlining opportunities in more detail in our submission to the ACCC’s Rule Framework Consultation and will share this with the AER and the Department as well.

Our specific comments on the payloads are:

• Please confirm the meaning of Regulated offers. This does not seem to be clearly defined in the guidance provided for EME and Vic Energy Compare (EME Portal application – Energy Plan data standard and VRP User Manual). Is this meant to refer to state/territory offers where the DMO prices do not apply and other regulated tariffs apply?

• Conditional Category for discounts only includes data inputs for pay on time and direct debit conditions. This does not account for other conditional discounts. This is also an example where the data inputs are different for EME and Vic Energy Compare. Please include Ebilling, Bundled services and Other categories which align with the Victorian requirements (and offer more response options than EME).

• Solar feed in tariff information does not reflect variability in how the feed in tariff may change due to volumes of electricity exported or the time it is exported.

Cheers,
Selena

[mannharleen]

Feedback from Origin Energy on DP-111

• Our understanding is that only generally available offers should be available via this endpoint. Therefore, the field named “availability” on Pg.9 should be mandatory and the only applicable value should be = GENERAL

• Should additional query parameters be considered, such as: State/Jurisdiction, Customer type – Resi/Busi etc.

• Payment methods on Pg.12 - We also use Australia Post as a payment method. We don't use Paper bill

• Pg.13 - With discounts/optional discounts in Origin , we have a discount period, discount start etc fields. Say the plan may be 12 months but discount will be applied after 3 months of contract start and for a period of 6 months. How will the payload cater for this?

• Pg.13 - We also offer a fixed discount/rebate in few cases – Will that be covered as part of amount field ? Say 50$ credit on your first bill. How will the payload cater for this?

• Will the endpoint always be exposed by EME/VEC? Is there an expectation for the Retailer to build/host this endpoint in the future?

[ghost]

Good afternoon

Ahmed from AGL Energy

I do have the following comments:

• Should the specification include meta-attributes that can assist with the consumption or presentment of the tariff data such as eligibility attributes of a particular product (e.g. Available only in Victoria)?

• With the complexity of tariff data, there is an assumption of knowledge required of the industry and state-based nuances for a consumer of these APIs to correctly interpret and render tariff details. Is there a general principle or assumption for level of understanding that API design needs to meet?

• It is common practice to have plans that are not generally available to the public. Given that /energy/plans is a public endpoint and allow passing available field to RESTRICTED, what does that mean to us?

• For percentOfBill discount, we want to confirm that the expectation is that percentage is calculated from supply and usage charges.

• Should meterTypes be array of Enum instead of String.

• Is there is specific expected format for description fields i.e. plain text, html, markdown etc?