Closed DannyDuong closed 2 months ago
@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.
Is the proposed change seeking to update the standards to cater for scenarios where the stepped tariffs are time bound? For e.g.
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 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
@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.
@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
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.
@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)
To help participants review and provide feedback, I've summarised the changes proposed in this CR in 2 parts below:
Update the following structures with a new optional period
field in their :singleRate
and timeOfUseRates
objects
singleRate
and timeOfUseRates
in EnergyPlanControlledLoadsingleRate
and timeVaryingTariffs
in EnergyPlanSolarFeedInTariffV2Note: 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"
}
],
Update the following structure with a new optional period
field timeOfUseRates
object:
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.
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.
As discussed in the call:
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.
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.
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 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
.
The DSB have conducted further analysis and found the following:
period
field with comparison sites like iSelectperiod
field, as noted in the CR, addresses an existing gap in certain structures for step rate calculationsAs 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.
The change has been staged and can be reviewed here: https://github.com/ConsumerDataStandardsAustralia/standards-staging/compare/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
- EnergyPlanSolarFeedInTariffV2
@HemangCDR The following are DEECA feedback on this:
@DannyDuong thank you for your feedback. Please note the following response:
@HemangCDR The following are DEECA feedback on this:
- 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.
- 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.
- 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.
Standards version 1.30.0 was published on 24/04/2024 incorporating this change from MI18.
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 https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/625#issuecomment-1993734451