search

ConsumerDataStandardsAustralia / standards-maintenance

This repository houses the interactions, consultations and work management to support the maintenance of baselined components of the Consumer Data Right API Standards and Information Security profile.
41 stars 9 forks source link

EnergyPlanTariffPeriod - Change to daily supply charge #627

Closed rhys-ergon closed 2 months ago

rhys-ergon commented 6 months ago

Description

Currently the energy schema EnergyPlanTariffPeriod only supports a single rate daily supply charge however QLD has 2 tariffs which have banded daily supply charges.

Example: image

The applicable daily supply charge for the billing period is that which corresponds with the applicable annual usage Bands:

Area Affected

  1. API - Get Energy Account Detail
  2. Schema - EnergyPlanTariffPeriod

Change Proposed

We propose 2 options:

Option 1 - Breaking Change

{
    "type": "ENVIRONMENTAL",
    "displayName": "string",
    "startDate": "string",
    "endDate": "string",
    "dailySupplyCharges": {
         "type": "single", // enum = single/band
         "singleRateSupplyCharge": 100,  // conditional 
         "bandedSupplyCharge": [  // conditional 
             {
                 "rate": 140,
                 "volume": 20000
             },
             {
                 "rate": 169,
                 "volume:" 40000
             }
          ],
     }
    "timeZone": "LOCAL",
    "rateBlockUType": "singleRate",
     ...
}

Option 2 - Non-breaking Change

{
    "type": "ENVIRONMENTAL"
    "displayName": "string",
    "startDate": "string",
    "endDate": "string",
    "dailySupplyChargeType": "single", // (optional, default = single, enum = single/band)
    "dailySupplyCharges": "string", // conditional 
    "bandedDailySupplyCharges": [  // conditional 
       {
          "rate": 140,
          "volume": 20000
       }
     ],
    "timeZone": "LOCAL",
    "rateBlockUType": "singleRate",
     ...
}

DSB Proposed Solution

The proposed solution can be found through the staging link provided in https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/627#issuecomment-2024573078

HemangCDR commented 4 months ago

@rhys-ergon, thank you for raising the options.

Option 2 seems to have minimal impact on existing DHs who do not have plans with banded daily supply rate to cater for. However, it would still be considered breaking as it would impact recipients.

Jacqui-AER commented 4 months ago

@HemangCDR EME does not currently support banded daily supply charges so option 2 would be the preference for AER. Jacqui (AER)

DannyDuong commented 4 months ago

Firstly, Offers (Plans) in Victorian Energy Compare (VEC) are for consumers with less than 40 MWh of energy consumption per year. As such, in Victoria we are not aware of a need for a similar set up as per the Queensland tariff above. If there is, we would assume that TOU rates would differ for each annual usage band, and therefore we don't really need the banded daily supply charges construct.

Given the above, from an impact perspective, DEECA prefers "Option 2 - Non-breaking Change". However, we acknowledge that the proposed changes may not be a neat extension to the data standards.

Purely from a data standards point of view, and if the decision is that a change to the data standards is required, then DEECA proposes an alternative format to @rhys-ergon 's suggestion:

"dailySupplyCharges": {
     "type": "single", // enum = single/band
     "period": "string" // optional
     "rates": [
       {
         "unitPrice": "string",
         "measureUnit": "MWH",
         "volume": 0  // optional
       }
     ],

The above uses the rates array that is currently been used in other parts of the Energy data standards. We've added the period here for completeness, in this case, we would assume the value is "per year".

AGL-CDR commented 3 months ago

AGL's preference is for this gap to be managed via a non-breaking change.

perlboy commented 3 months ago

During the call the discussion involved whether the contextual element of models for Account Detail vs. Plan details impacts the presentation. There was an indication that current data being submitted for plans associated with these bandings was being submitted as multiple plans which means AER is receiving it. This represents challenges when considered between aligning the data published via AER and those presented by Retailers.

ProductCloudCDR commented 3 months ago

We would recommend option 2 (to avoid breaking change and to allow for Get Generic Plan Detail and Get Service Point Detail to remain on a unified schema). This aligns to the feedback from @AGL-CDR and would make it easier for AER and DEECA who don't hold this info.

The suggestion from @DannyDuong about unifying the structure with the rates structure is a good one, however, as it would allow for common structures to be used for common purpose.

We therefore suggest (as a compromise between provided feedback):

{
    "type": "ENVIRONMENTAL"
    "displayName": "string",
    "startDate": "string",
    "endDate": "string",
    "dailySupplyChargeType": "single", // (optional, default = single, enum = single/band)
    "dailySupplyCharges": "string", // conditional 
    "bandedDailySupplyCharges": [  // conditional 
       {
         "unitPrice": "string",
         "measureUnit": "MWH",
         "volume": 100
       }
     ],
    "timeZone": "LOCAL",
    "rateBlockUType": "singleRate",
     ...
}

The comment from @perlboy doesn't really seem to change the recommended way forward but does raise a good issue about how AER and DEECA are intending to expand their platforms as electricity plans evolve. Do AER and DEECA intend to expand their data held to incorporate these additional fields and plan conditions over time?

If yes, then we would love to know how to provide feedback on that roadmap. If no then it means that the plan data will become less and less useful over time.

HemangCDR commented 3 months ago

Two main issues have been raised and discussed in this CR, which are summarised below:

1. Sharing of plan information with banded daily supply charges in CDR:

This is the primary issue for which this CR has been raised. Retailers offer plans that can consist of banded daily supply charges. The standards currently do not cater for this and only allow for a single daily supply charge to be provided per plan.

Various options have been presented and discussed for this. Based on the feedback on the options, the variation of option 2 (non breaking for Data Holders) proposed above is recommended as it does not impact Data Holders that don't support banded daily supply charges whilst maintaining alignment with other common structures.

This would also enable AER/DECCA to start sharing banded daily supply charges once issue 2 noted below is resolved.

I've noted it below with expanded descriptions:

{
    "type": "ENVIRONMENTAL"
    "displayName": "string",
    "startDate": "string",
    "endDate": "string",
    "dailySupplyChargeType": ["SINGLE", "BAND"],//  New optional field for daily supply charge type. Default value SINGLE is field not provided. Note: it is not a UType as it is an option field
    "dailySupplyCharge": "AmountString", // conditional - Mandatory if dailySupplyChargeType is SINGLE. NOTE: Field name typo corrected from `dailySupplyCharges` to `dailySupplyCharge`
    "bandedDailySupplyCharges": [  // conditional - Mandatory if dailySupplyChargeType is BAND
       {
         "unitPrice": "string",
         "measureUnit   : ["KWH", "KVA", "KVAR", "KVARH", "KW", "DAYS", "METER", "MONTH"], //Optional. The measurement unit of rate. Assumed to be DAYS if absent
         "volume": 100 // Optional. Volume the charge applies to.
       }
     ],
    "timeZone": "LOCAL",
    "rateBlockUType": "singleRate",
     ...
}

The above change would be applied to the following:

Recommendation: Given this is an existing issue DHs need resolved, we propose the above change to be made with an FDO of 11/11/2024, which is the last obligation date noted in the obligation date schedule. This is in alignment with the FDO of other energy CRs being discussed in this MI.

2. Consistent representation banded daily supply charges in CDR-PRD data and EME/AER channels:

As this issue relates to how the data is shared between retailers and AER/DECCA, it is outside the scope of MI/CDR to resolve. However, we acknowledge that it is important to address, specifically to ensure alignment between energy PRD and account detail information which is vital for plan comparison and switching use cases.

Recommendation: We recommend it be resolved externally with relevant stakeholders which the DSB is willing to provide support for. We have already initiated discussions with AER to understand how this can be progressed.

Feedback on the above approach of addressing the two issues and the respective recommendations is welcome.

joshharris3 commented 3 months ago

The AER supports the solution suggested above. However, updating EME to accommodate these changes will require considerable time and resources on our end. Therefore we are able to commit to being compliant with the schema, but cannot commit to providing banded daily supply charges within a single plan within the suggested time frame.

CDR-API-Stream commented 2 months ago

As discussed during the MI call on 3rd April, the proposed change will be recommended to the Chair for approval.

The change has been staged and can be reviewed here: https://github.com/ConsumerDataStandardsAustralia/standards-staging/compare/release/1.30.0...maintenance/627

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

DannyDuong commented 2 months ago

Two main issues have been raised and discussed in this CR, which are summarised below:

1. Sharing of plan information with banded daily supply charges in CDR:

This is the primary issue for which this CR has been raised. Retailers offer plans that can consist of banded daily supply charges. The standards currently do not cater for this and only allow for a single daily supply charge to be provided per plan.

Various options have been presented and discussed for this. Based on the feedback on the options, the variation of option 2 (non breaking for Data Holders) proposed above is recommended as it does not impact Data Holders that don't support banded daily supply charges whilst maintaining alignment with other common structures.

This would also enable AER/DECCA to start sharing banded daily supply charges once issue 2 noted below is resolved.

I've noted it below with expanded descriptions:

{
    "type": "ENVIRONMENTAL"
    "displayName": "string",
    "startDate": "string",
    "endDate": "string",
    "dailySupplyChargeType": ["SINGLE", "BAND"],//  New optional field for daily supply charge type. Default value SINGLE is field not provided. Note: it is not a UType as it is an option field
    "dailySupplyCharge": "AmountString", // conditional - Mandatory if dailySupplyChargeType is SINGLE. NOTE: Field name typo corrected from `dailySupplyCharges` to `dailySupplyCharge`
    "bandedDailySupplyCharges": [  // conditional - Mandatory if dailySupplyChargeType is BAND
       {
         "unitPrice": "string",
         "measureUnit : ["KWH", "KVA", "KVAR", "KVARH", "KW", "DAYS", "METER", "MONTH"], //Optional. The measurement unit of rate. Assumed to be DAYS if absent
         "volume": 100 // Optional. Volume the charge applies to.
       }
     ],
    "timeZone": "LOCAL",
    "rateBlockUType": "singleRate",
     ...
}

The above change would be applied to the following:

  • EnergyPlanTariffPeriod.dailySupplyCharges ~- EnergyPlanControlledLoad.singleRate.dailySupplyCharge~ ~- EnergyPlanControlledLoad.timeOfUseRates.dailySupplyCharge~ Note: As per participant feedback during MI call on 3rd April, the changes only need to apply to EnergyPlanTariffPeriod.dailySupplyCharges as the controlled load do not have banded daily supply charges.

Recommendation: Given this is an existing issue DHs need resolved, we propose the above change to be made with an FDO of 11/11/2024, which is the last obligation date noted in the obligation date schedule. This is in alignment with the FDO of other energy CRs being discussed in this MI.

2. Consistent representation banded daily supply charges in CDR-PRD data and EME/AER channels:

As this issue relates to how the data is shared between retailers and AER/DECCA, it is outside the scope of MI/CDR to resolve. However, we acknowledge that it is important to address, specifically to ensure alignment between energy PRD and account detail information which is vital for plan comparison and switching use cases.

Recommendation: We recommend it be resolved externally with relevant stakeholders which the DSB is willing to provide support for. We have already initiated discussions with AER to understand how this can be progressed.

Feedback on the above approach of addressing the two issues and the respective recommendations is welcome.

DEECA feedback to this is aligned with feedback on https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/625

i.e. 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 commented 2 months ago

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

DEECA feedback to this is aligned with feedback on #625

i.e. 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

As noted in the original request, the daily supply charge bands are annual. This was discussed during the MI as well and was confirmed by participants, noting that there are no other applicable periods . As a result, adding a period field is not recommended.

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

nils-work commented 2 months ago

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

AGL-CDR commented 1 week ago

@HemangCDR AGL needs to raise some findings while implementing these changes from MI18. The short version is that the change breaks existing capacity to manage C&I customers with no itemised Daily Service Charge.

For such customers we currently send null for dailySupplyChargeType and dailySupplyCharge, but post change a null value will be interpreted as SINGLE (incorrectly) and also make dailySupplyCharge mandatory which cannot be populated as no such charge exists. These customers have daily charges passed through in network TUOS and DUOS.

Requesting feedback on how best to proceed here. AGL is essentially unable to comply with these change in their current form without introducing flow on errors.