Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Decision Proposal 115 - Tailored Tariff Data Payloads #115

Closed
CDR-API-Stream opened this issue Apr 13, 2020 · 4 comments
Closed

Decision Proposal 115 - Tailored Tariff Data Payloads #115

CDR-API-Stream opened this issue Apr 13, 2020 · 4 comments
Labels
Category: API A proposal for a decision to be made for the API Standards made Industry: Electricity This proposal impacts the electricity industry sector Status: No Decision Taken No determination for this decision has been made

Comments

@CDR-API-Stream
Copy link
Contributor

CDR-API-Stream commented Apr 13, 2020

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

Note that this proposal does not include any additional end points. It contains a data structure which will be included in the account end points. Please refer to the Account Data proposal for reference.

The structures contained in this proposal were derived from the Generic Tariff data proposal.

Feedback is welcome on this proposal. This thread will remain open for feedback until the 20th of November.

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.

@CDR-API-Stream CDR-API-Stream added Category: API A proposal for a decision to be made for the API Standards made Status: Proposal Pending A proposal for the decision is still pending Industry: Electricity This proposal impacts the electricity industry sector labels Apr 13, 2020
@CDR-API-Stream CDR-API-Stream added Status: Open For Feedback Feedback has been requested for the decision and removed Status: Proposal Pending A proposal for the decision is still pending labels Oct 27, 2020
@SelenaLiuEA
Copy link

Hi All

EnergyAustralia’s views are below:

General

  • As mentioned in our comments to the billing payload proposal, the proposal works for conventionally structured pricing (with a usage component and daily charge for supply costs) but it may work less well for newer types or innovative pricing e.g. subscription pricing. It is also not clear how energy products bundled with other related services will work under these payloads which is still subject to ACCC decisions, but this detail will need to be clarified in the standards at some point.
  • For some charges, the proposal does not specify whether the charge is exclusive of GST. E.g. Solar feed in tariffs are exclusive of GST.

electricityContract

  • timeZone – This does not capture Australian Central Standard Time for SA. Note that different charges can be based on different time zones – e.g. one on AEST and one for Australian Central Standard Time.

discount

  • Conditional – must be one of PAY_ON_TIME and DIRECT_DEBIT under the Proposal. There are other types of conditional discounts e.g. e-billing for example. Please include an other category. The list could be expanded more to capture more options that are prevalent in the market – the DSB can refer to EME or Vic Energy Compare data requirements – which I can see if I can send across to the DSB if that’ll assist.
  • methodUType – Regarding percentOfBill – we note that what retailers refer to as a whole of bill discount may not constitute a full bill discount because there are some charges some retailers do not discount off (e.g. not discounting off demand charges in any circumstance)

fee

  • For disconnection and reconnection – it might be helpful to distinguish between manual and remote de-energisation and re-energisation because there is a large price differential. Please also note that as third party (distributor or metering coordinator) charges can differ depending on the sites requirements – this data may be returned in a range value or multiple values.
  • Type – years 1 – 5 is listed, but it is possible to have electricity contracts with a contact term that is greater than 5 years

greenPowerCharges

  • It is unclear what description is expected, where the percentGreen is separately captured – not suggesting it be removed but more clarity be provided on what the intent is.

solarFeedInTariff

  • Fields need to reflect that there can be time of use Feed in Tariffs. See for example, https://www.energyaustralia.com.au/home/electricity-and-gas/solar-power/feed-in-tariffs . This will need to be reflected in the data object with peak, shoulder and off peak rates and start and end times.
  • Fields need to also reflect that there will be different Feed in Tariffs across different states/territories, this also applies to pricing and charges as well. This might already be the case, but just want to confirm.

Time of use

  • Type – should reflect that there can be different TOU rates which vary by season.
  • Days – Business days in this context means business days minus public holidays which is important for demand charges. Work days means all business days (inclusive of public holidays).

Thanks
Selena

@PratibhaOrigin
Copy link

Comments from Origin Energy on DP-115

  • Discount - With discounts/conditional 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?

  • Amount - 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?

  • Category - The type of the discount. Mandatory if the discount type is CONDITIONAL. Must be one of:
    PAY_ON_TIME or DIRECT_DEBIT. However, there are other types are conditional discounts like dual-fuel , e-bill etc. Do we need another value ‘Other’ to handle such conditional discounts ?

  • Fee- With the disconnection/connection charges , the value can be vary based on how the connection/disconnection was done - remote vs. manual. How does the payload cater for this ?

  • GST component - The GST inclusive/exclusive component should be clearly defined for the retail, solar and fee/charges as it works slightly differently for each of these. Also, the rounding rules for the same should be specified.

  • Generic Comment -
    Overall the payload seems more tailored to mass market bundled charges. Has the unbundled charging model of the large commercial and industrial customers been considered for these payloads or will it be submitted for consultation at a later stage after the confirmation of ACCC rule regarding inclusion of the large customers ?

Cheers!
Pratibha

@ghost
Copy link

ghost commented Nov 20, 2020

Hello,

On behalf of AGL Energy CDR technical working group

General Feedback
Tailored tariffs provide Retailer opportunity to differentiate and simplify their products and service through bundled charging which amongst other items may include energy consumption charges and fees. Subsequently due to the bundled nature of the inclusive charge, fee, or discounts embedded the product plan items, it should be noted that for ADRs who wish to provide comparative analysis between retailers may find it difficult to effectively match or determine equivalencies.
Further to this point, it is unclear beyond the “Display name” and potentially the optional description of the charge, fee, or discount how a match or determination could be achieved.

Another important consideration is the inclusion of behind the meter services, carbon offset, demand response, EV and in some instances non-energy product propositions that may form part of the contract. Focusing only on electricity or gas only may not provide the end consumer the complete comparison or understanding of the full value proposition. Its unclear within the standard how these might be surfaced or acknowledge as missing or incomplete.

electricityContract
pricingModel: Given AGL's electricity contract (account level) can be linked to multiple meters, and each meter potentially subject to different pricing model; it's unclear how electricityContract is associated with a single pricingModel enum.

isFixed: Contracts can be fixed temporarily, fixed for amount of time then variable. We don't see how that can be expressed.

discount
category: Requesting adding new items to enum: Loyalty (discount for loyal customers) and Multi-Product (discount for customers opting-in to multiple products)

fee
amount:

  • Notion of inclusive/exclusive of GST is missing here.
  • Some fees have unknown amounts at time of contract or mentioned as a range. For example pass-on fees where fee is subject to a different vendor. i.e installation of a meter required.

type: Should fee type enum be extended to include types like device purchase plans i.e. Google Home or Amazon Alexa or carbon neutral plans.

term: Should we consider adding Weekly and Daily to terms enum. For example AGL carbon neutral plan fee is $1 a week for residential customers.

@CDR-API-Stream CDR-API-Stream added Status: Feedback Period Closed The feedback period is complete and a final decision is being formulated and removed Status: Open For Feedback Feedback has been requested for the decision labels Nov 23, 2020
@CDR-API-Stream
Copy link
Contributor Author

Thank you all for the feedback. This will be reviewed and incorporated into the full standards draft for the Energy sector

@ConsumerDataStandardsAustralia ConsumerDataStandardsAustralia locked and limited conversation to collaborators Nov 23, 2020
@CDR-API-Stream CDR-API-Stream added Status: No Decision Taken No determination for this decision has been made and removed Status: Feedback Period Closed The feedback period is complete and a final decision is being formulated labels Aug 29, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Category: API A proposal for a decision to be made for the API Standards made Industry: Electricity This proposal impacts the electricity industry sector Status: No Decision Taken No determination for this decision has been made
Projects
None yet
Development

No branches or pull requests

3 participants