Additional field to support Step Tariff calculations

[DannyDuong]

Description

Currently, the data standards for EnergyPlanResponseV2 support step tariff only for tariffPeriod.singleRate as it has the measurement period defined in the tariffPeriod.singleRate.period

This measurement period is missing for the following objects, and hence step tariffs for these objects cannot be fully supported:
• tariffPeriod.timeOfUseRates
• solarFeedInTariff
• controlledLoad

Area Affected

The EnergyPlanResponseV2 response payload for the Get Generic Plan Detail API.
This measurement period is missing for the following objects:
• tariffPeriod.timeOfUseRates
• solarFeedInTariff
• controlledLoad

Change Proposed

DEECA propose a CR to add the period field, as per tariffPeriod.singleRate.period to the following objects:
• tariffPeriod.timeOfUseRates
• solarFeedInTariff
• controlledLoad

The addition of the period field will facilitate step tariffs to be calculated properly by the ADRs.

DSB Proposed Solution

The proposed solution can be found through the staging link provided in #625 (comment)

[HemangCDR]

@danny thank you for raising this CR.

I wanted to clairfy my undestanding of the problem.

The standards currently allow sharing of stepped tariffs with the assumption that they are not time bound. For e.g.

• Step 1 rate - 20c/kWh for first 10kWh
• Step 2 rate - 35c/kWh for rest

Is the proposed change seeking to update the standards to cater for scenarios where the stepped tariffs are time bound? For e.g.

• Step 1 rate - 20c/kWh for first 10kWh per day
• Step 2 rate - 35c/kWh for rest

If so, I'd suggest the period attribute be optional value to cater for plans that may not have time bound stepped rates.

Another suggestion is to add the period field to the rates object within the above structures as individual stepped rates may have different applicability period? For e.g.

  "timeOfUseRates": [
    {
      "displayName": "string",
      "description": "string",
      "dailySupplyCharge": "string",
      "rates": [
        {
          "unitPrice": "string",
          "measureUnit": "KWH",
          "volume": 0,
          "period" : "ExternalRef" //Optional field indicating the period over which the stepped rate is calculated. Formatted according to ISO 8601 Durations (excludes recurrence syntax)
        }
      ],
      .
      .
   }
]

Feedback on the above is welcome, including from other retailers as this also affects the Account Detail endpoint

[Jacqui-AER]

@HemangCDR
The AER agree with adding the period into the rates object.

The Energy Made Easy website requires a period to calculate the pricing for each volume so if this is deemed an optional attribute, a default value will need to be assumed.

The period enum values that EME currently uses are:
P1D = per day
P7D = per week
P1M = per month
P2M = per 2 months
P3M = per 3 months
P6M = per 6 months
P1Y = per year

[DannyDuong]

@danny thank you for raising this CR.

I wanted to clairfy my undestanding of the problem.

The standards currently allow sharing of stepped tariffs with the assumption that they are not time bound. For e.g.

• Step 1 rate - 20c/kWh for first 10kWh
• Step 2 rate - 35c/kWh for rest

Is the proposed change seeking to update the standards to cater for scenarios where the stepped tariffs are time bound? For e.g.

• Step 1 rate - 20c/kWh for first 10kWh per day
• Step 2 rate - 35c/kWh for rest

If so, I'd suggest the period attribute be optional value to cater for plans that may not have time bound stepped rates.

Another suggestion is to add the period field to the rates object within the above structures as individual stepped rates may have different applicability period? For e.g.

  "timeOfUseRates": [
    {
      "displayName": "string",
      "description": "string",
      "dailySupplyCharge": "string",
      "rates": [
        {
          "unitPrice": "string",
          "measureUnit": "KWH",
          "volume": 0,
          "period" : "ExternalRef" //Optional field indicating the period over which the stepped rate is calculated. Formatted according to ISO 8601 Durations (excludes recurrence syntax)
        }
      ],
      .
      .
   }
]

Feedback on the above is welcome, including from other retailers as this also affects the Account Detail endpoint

@HemangCDR

What you've proposed is too complicated and unnecessary.

Essentially, the measurement period should be the same as per the tariffPeriod.singleRate.
For calculation purposes, this measurement period needs to be consistent for each step, as it the usage period for which the block rate applies.

[DannyDuong]

@HemangCDR The AER agree with adding the period into the rates object.

The Energy Made Easy website requires a period to calculate the pricing for each volume so if this is deemed an optional attribute, a default value will need to be assumed.

The period enum values that EME currently uses are: P1D = per day P7D = per week P1M = per month P2M = per 2 months P3M = per 3 months P6M = per 6 months P1Y = per year

DEECA agrees with this as VEC has a similar set of values. The only difference is Quarterly vs Per 3 months, but this can be translated to P3M.

[HemangCDR]

@HemangCDR

What you've proposed is too complicated and unnecessary.

Essentially, the measurement period should be the same as per the tariffPeriod.singleRate.
For calculation purposes, this measurement period needs to be consistent for each step, as it the usage period for which the block rate applies.

Thank you for the clarification @DannyDuong.

To ensure I understand, what you are stating is that the period over which stepped rates are calculated stays consistent for a given plan? For e.g. if the solar FiT has a stepped tariff, all steps would be calculated over a fixed period (for e.g. daily, or weekly)?

Also, you have noted the need for the period field in tariffPeriod.timeOfUseRates. Would it also be needed in controlledLoad.timeOfUseRates and solarFeedInTariff.timeVaryingTariffs?

---

@HemangCDR The AER agree with adding the period into the rates object.

The Energy Made Easy website requires a period to calculate the pricing for each volume so if this is deemed an optional attribute, a default value will need to be assumed.

The period enum values that EME currently uses are: P1D = per day P7D = per week P1M = per month P2M = per 2 months P3M = per 3 months P6M = per 6 months P1Y = per year

@jsn2510 thank you for your feedback.

If the value of the field is the same for majority of the time we could look at noting a default value in the description if the fieldis not provided (e.g. if not provided, default value is P1D). What do you suggest the default to be?

Also note that the field would not be an ENUM, but rather an ExternalRef that refers to ISO 8601 Durations. See example below:

The values you have noted seem compliant with the ISO 8601 durations format so it shouldn't be an issue.

[Jacqui-AER]

@HemangCDR EME currently defaults the period value to P1Y.
Please also note that EME currently collects the period for the tariff period as suggested above by @DannyDuong
Jacqui (AER)

[HemangCDR]

To help participants review and provide feedback, I've summarised the changes proposed in this CR in 2 parts below:

Change 1:

Update the following structures with a new optional period field in their singleRate and timeOfUseRates objects:

• singleRate and timeOfUseRates in EnergyPlanControlledLoad
• singleRate and timeVaryingTariffs in EnergyPlanSolarFeedInTariffV2

Note: Updated the above on 17th April 2024 to clarify that the change applies to timeVaryingTariffs in EnergyPlanSolarFeedInTariffV2

Example code:

    "singleRate": {
      "displayName": "string",
      "description": "string",
      "generalUnitPrice": "string",
      "rates": [
        {
          "unitPrice": "string",
          "measureUnit": "KWH",
          "volume": 0
        }
      ],
      "period": "string" // new optional usage period field for which the block rate applies. Formatted according to ISO 8601 Durations (excludes recurrence syntax). Defaults to P1Y if not present
    },
    "timeOfUseRates": [
      {
        "displayName": "string",
        "description": "string",
        "rates": [
          {
            "unitPrice": "string",
            "measureUnit": "KWH",
            "volume": 0
          }
        ],
        "period": "string" // new optional usage period field for which the block rate applies. Formatted according to ISO 8601 Durations (excludes recurrence syntax). Defaults to P1Y if not present
        "timeOfUse": [
          {
            "days": [
              "SUN"
            ],
            "startTime": "string",
            "endTime": "string"
          }
        ],
        "type": "PEAK"
      }
    ],

Change 2

Update the following structure with a new optional period field timeOfUseRates object:

• EnergyPlanTariffPeriod

with:

    "timeOfUseRates": [
      {
        "displayName": "string",
        "description": "string",
        "rates": [
          {
            "unitPrice": "string",
            "measureUnit": "KWH",
            "volume": 0
          }
        ],
        "period": "string" // new optional usage period field for which the block rate applies. Formatted according to ISO 8601 Durations (excludes recurrence syntax). Defaults to P1Y if not present
        "timeOfUse": [
          {
            "days": [
              "SUN"
            ],
            "startTime": "string",
            "endTime": "string"
          }
        ],
        "type": "PEAK"
      }
    ],

As this would be a breaking change, a future dated obligation of September 9 2024 is being proposed (See
Obligation Dates Schedule).

Feedback from participants is welcome.

[DannyDuong]

Area Affected

@HemangCDR please refer to the original description for the Affected Area.

As I'm not a standards expert, it's best that you perform your analysis and come up with the proposed changes. I'll provide feedback once done. I'm happy to clarify any questions that you may have.

[perlboy]

As discussed in the call:

1. It's unclear whether it is important to know at what specific date an interval resets. For instance if it was P5D (every 5 days) and it started happening from the 3rd March the proposed model doesn't seem like it would communicate "from 3 March it's every 5 days". Once usage data is considered this can be highly variable and relevant for understanding things like "potential savings" type outcomes.
2. I'm not sure we should be so committed to makming the public vs. private version of the use of these models aligned. This thread doesn't have an ADR saying "We want this" and the complexity of change once one considers contextual data (i.e. specific account) is high so why decide on it in the absence of Recipient support?

[AGL-CDR]

Should this item be accepted, we will need at least six months lead time, starting from the date that final standards are published. With that in mind, we propose a FDO of early December.

[ProductCloudCDR]

The issue of specific dates vs periods is an important one to consider. It is currently an active issue in the banking sector where the specific date that a fixed rate ends has become important for recommending an alternative product. We would support consideration of how a specific date for an instance (ie. via Get Service Point Detail) could be determined for the start and end of longer durations.

We don't really think that a data recipient needs to support this change as AER and VEC are both active users of this data for the main use case of energy plan comparison (in fact, probably the most significant representatives of that use case in Australia).

If such support is needed, however, then ProductCloud supports this change as it is likely to be important for the plan comparison use case as more services start to use and rely on this data.

[HemangCDR]

Thank you all for your feedback.

• Regarding the need to know specific dates (start and end) of step periods:
  Further investigation into this indicates that the step rates are calculated over a billing period and as such the start and end is implied accordingly. See- https://www.globirdenergy.com.au/step-rates/ for example. As a result it does not seem inclusion of specific start and end for step period is required. Comments on this calculation method, especially from other retailers, would be helpful. If required, inclusion of start and end of period can be assessed in a separate CR.

• Regarding public vs private version alignment:
  Based on the above, this appears to be an issue impacting both PRD and account detail endpoints. As noted in the original comment, the period field is essential in calculating step rates appropriately over a period of time which can be beneficial in plan comparison and for calculating rates for consumer invoices

Considering the above points and other feedback on this issue, the current recommendation is for the change to be made as described in this comment, pending any further comments from @DannyDuong (or other participants) on the proposed structure.

Also noting feedback from @AGL-CDR, the FDO date of 11/11/2024 is recommended, which is the last obligation date noted in the obligation date schedule.

Feedback on any of the above is welcome.

[biza-io]

Biza.io supports the introduction of the proposed attributes as proposed by @HemangCDR most recently. We request clarification regarding the implied nature of the start and end dates because billing periods are not explicitly the same as the existing attributes contained within planOverview for startDate and endDate.

[CDR-API-Stream]

The DSB have conducted further analysis and found the following:

• Based on discussion with retailers, they currently only share the period field with comparison sites like iSelect
• Adding this period field, as noted in the CR, addresses an existing gap in certain structures for step rate calculations
• Based on discussions in the MI, there is lack of clear evidence for need to support the introduction of specific start and end dates for step calculations. These may be revisited in a future CR raised by the community if necessary

As a result, and based on the feedback thus far, the change described in this comment is being recommended with an FDO of 11/11/2024.

[CDR-API-Stream]

The change has been staged and can be reviewed here: ConsumerDataStandardsAustralia/standards-staging@release/1.30.0...maintenance/625

Note: The retirement date for the following endpoints impacted as a result of this change has been set to September 8th 2025

• Get Generic Plan Detail v2
• Get Energy Account Detail v3

[DannyDuong]

• EnergyPlanSolarFeedInTariffV2

@HemangCDR The following are DEECA feedback on this:

1. Please provide explicit example for EnergyPlanSolarFeedInTariffV2 as the construct is not the same as per the EnergyPlanControlledLoad
2. For both Change 1 and Change 2, we recommend that the "period" field should be moved up one level, as per the rateBlockUType/ tariffUType. This would be a cleaner solution than having the "period" field repeated in the same object
3. Please double check to ensure that this new period field is introduced wherever step tariffs need to be supported e.g. where "volume" is used

[CDR-API-Stream]

@DannyDuong thank you for your feedback. Please note the following response:

@HemangCDR The following are DEECA feedback on this:

1. Please provide explicit example for EnergyPlanSolarFeedInTariffV2 as the construct is not the same as per the EnergyPlanControlledLoad

Note that this was already catered for in the staged changes. We can update the proposal to clarify.

2. For both Change 1 and Change 2, we recommend that the "period" field should be moved up one level, as per the rateBlockUType/ tariffUType. This would be a cleaner solution than having the "period" field repeated in the same object

The period field is being added to singleRate and timeOfUseRates (or timeVaryingTariffs in case of solar feed in tariffs) which are UType (union type) objects. This would not result in duplication as only one rate type can be provided in a given response. As a result, no change is required.

3. Please double check to ensure that this new period field is introduced wherever step tariffs need to be supported e.g. where "volume" is used

We have noted where field will be added in this comment. As a summary it would be added to the following:

• EnergyPlanControlledLoad.singleRate
• EnergyPlanControlledLoad.timeOfUseRates
• EnergyPlanSolarFeedInTariffV2.singleRate
• EnergyPlanSolarFeedInTariffV2.timeVaryingTariffs
• EnergyPlanTariffPeriod.timeOfUseRates

All the above have the volume field and we did not note any other reference to the field. As a result no change is required.

Note The EnergyPlanTariffPeriod.timeOfUseRates was missed in the diff statements and release notes of the staged changes. It has been updated with the correction.

The above points were discussed in the MI19 call today (17th April) and participants agreed with the clarification provided.

[nils-work]

Standards version 1.30.0 was published on 24/04/2024 incorporating this change from MI18.