Closed CDR-API-Stream closed 1 year ago
Use the description
field in EnergyPlanSolarFeedInTariff
structure to described the stepped rates. Multiple entries can be provided (one per stepped rate) as EnergyPlanSolarFeedInTariff
structure is an array.
EnergyPlanSolarFeedInTariff
with rates
objectThe EnergyPlanSolarFeedInTariff
schema can be updated with the rates
object used in other parts of energy standards such as EnergyPlanTariffPeriod
. The volume
field in the rates
object could then be used to specify the volume of usage a particular rate applies to.
03/03/2023 Update The option is updated with optional startDate
and endDate
fields to accommodate seasonal rates as per the feedback in this comment.
The change would like as below:
"solarFeedInTariff": [
{
"displayName": "string",
"description": "string",
"startDate": "DateString", // Optional start date of the application of the feed in tariff
"endDate": "DateString", // Optional end date of the application of the feed in tariff
"scheme": "PREMIUM",
"payerType": "GOVERNMENT",
"tariffUType": "singleTariff",
"singleTariff": {
"rates": [ // mandatory - Array of rates
{
"unitPrice": "string", // mandatory- Unit price of usage per measure unit (exclusive of GST)
"measureUnit": [ "KWH", "KVA", "KVAR", "KVARH", "KW", "DAYS", "METER", "MONTH" ], // optional - The measurement unit of rate. Assumed to be KWH if absent
"volume": 0 // optional - Volume that this rate applies to. Only applicable for ‘stepped’ rates where different rates apply for different volumes in a period
}
],
},
"timeVaryingTariffs": {
"type": "PEAK",
"rates": [ // mandatory - Array of rates
{
"unitPrice": "string", // mandatory- Unit price of usage per measure unit (exclusive of GST)
"measureUnit": [ "KWH", "KVA", "KVAR", "KVARH", "KW", "DAYS", "METER", "MONTH" ], // optional - The measurement unit of rate. Assumed to be KWH if absent
"volume": 0 // optional - Volume that this rate applies to. Only applicable for ‘stepped’ rates where different rates apply for different volumes in a period
}
],
"timeVariations": [
{
"days": [
"SUN"
],
"startTime": "string",
"endTime": "string"
}
]
}
}
]
Feedback on the solution options and FDO date is welcome.
As discussed in MI call, it would be appreciated if the DSB could consider bundling changes to endpoints together such that energy sector is only incrementing endpoint versions once between the Retail and C&I go-lives.
This would be a very welcome change. Some plan documents (https://cdr.energymadeeasy.gov.au/simply-energy/cds-au/v1/energy/plans/SIM403916MR@VEC) have a single solarFeedInTariff entry to represent stepped pricing, and only mention the step amounts in the description field. Others (https://cdr.energymadeeasy.gov.au/agl/cds-au/v1/energy/plans/AGL15273MRE17@EME) at least provide separate entries, but still rely on parsing the description
field to determine the volumes.
As discussed in MI call, it would be appreciated if the DSB could consider bundling changes to endpoints together such that energy sector is only incrementing endpoint versions once between the Retail and C&I go-lives.
Option 2 of proposed solution has been updated with an FDO date of 15th May 2023 based on this feedback.
Does this mean we also have to wait 6 months for any other fixes? e.g. AmountString values being rounded to two decimal places (sometimes resulting in non-zero values being rounded to 0.00), greenPowerCharges.tiers.amount
values missing entirely from some plan documents, etc.
@garychapman, the future date obligation (FDO) date mentioned in the above comment relates to option 2 and would be applicable for only for that change if it is adopted after consultation. The other issues you have mentioned are not in the scope of this change request (CR). If you would like these issues to be considered for the next maintenance iteration you can recommend them during the backlog grooming.
We usually consider FDOs for breaking changes to the standards, this helps impacted participants plan accordingly for when that specific change will take effect. The date itself would depend on various factors (for e.g. size/scope of change and impact) and is usually discussed during the consultation of the issue.
Biza's feedback having consulted with Energy customers indicates broad support for Option 2 - especially moving away from the use of the description field for describing stepped rates.
Although not an immediate pressing need, the ability to accommodate and reflect stepped rates that have a temporal dimension to them could be required. For example, feed-in tariffs on specified days of the week may indeed vary. It appears that the proposed option 2 could accommodate these through timeVariations
During the last call for MI 13, participants requested more time to review the proposed options. As a result this CR will be carried over to Maintenance Iteration 14.
Sorry to respond pretty late on this, but has seasonality been considered for FiT? Given that we have to deal with step rates, time variance - any chance that seasonality needs to be considered as a future proofing item?
Thank you for the opportunity to provide comment on this proposed change. AGL supports the adoption of this change. We note that at the time of writing, AGL has no customers registered for CDR that are currently impacted by solar stepped tariffs. Our preference is that these optional fields become a future dated obligation (FDO) on 15th November 2023 aligning to our next deployment of Tranche 2.
The DSB discussed the feedback in this comment https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/520#issuecomment-1429093426 was discussed with @DannyDuong as per the action noted in MI14 meeting on February 22nd. Below is the summary of the discussion:
EnergyPlanSolarFeedInTariff
structure to accommodate seasonal Feed in Tariffs (FiT) that can be seasonal (i.e. different solar feed in tariffs based on the time of the year).startDate
and endDate
fields (similar to how EnergyPlanTariffPeriod
). This would allow specifying feed in tariffs that can change based on dates/seasonsThe above recommended option is reflected in a updated Option 2. Any feedback on if the inclusion of the optional dates fields is welcome.
@AGL-CDR thank you for your feedback. Note that the tranche 2 date is 15th May 2023 which is currently proposed for option 2. Did you mean tranche 3?
Feedback from participants during the previous MI call indicated the tranche 2 date of 15th May 2023 is not feasible. As a result, the DSB recommends the FDO date of 1st November 2023 which aligns with tranche 3 release for the energy sector. Option 2 has been updated with this new date.
@AGL-CDR thank you for your feedback. Note that the tranche 2 date is 15th May 2023 which is currently proposed for option 2. Did you mean tranche 3?
Feedback from participants during the previous MI call indicated the tranche 2 date of 15th May 2023 is not feasible. As a result, the DSB recommends the FDO date of 1st November 2023 which aligns with tranche 3 release for the energy sector. Option 2 has been updated with this new date.
Hello again @CDR-API-Stream , thank you for providing an updated FDO in line with November 2023. Apologies for the confusion caused on tranche delineation, the date put forward relates to our internal release schedules as defined and outlined in the Exemption Register.
This issue has been staged and can be viewed here: https://github.com/ConsumerDataStandardsAustralia/standards-staging/pull/274/commits/ca1b57a7bed3cb6bdffc0af5ffc10e800d8fce76. It will be incorporated into 1.24.0 release of the standards as part of MI14 changes.
Notes:
Description
During consultation on issue https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/472, the question of representation of stepped solar feed in tariffs in Energy APIs was raised.
This issue is raised to consult on if/how stepped solar feed in tariffs should be represented in EnergyPlanSolarFeedInTariff.
Area Affected
Change Proposed
This decision proposal is currently a placeholder. The DSB will publish recommended changes to be consulted on within the Maintenance Iteration it gets prioritised for.
DSB Proposed Solution
The current DSB proposal for this issue is in this comment. Note The comment was updated on 14th October 2022 with a "Do Nothing" option