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 - cater for plans with no dailySupplyCharge #653

Closed CDR-API-Stream closed 1 month ago

CDR-API-Stream commented 4 months ago

Description

This issue is being raised to track and resolve the concern raised by @AGL-CDR as part of https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/627#issuecomment-2177322734

DSB Proposal

The current DSB proposal for this issue is in https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/653#issuecomment-2272758738

CDR-API-Stream commented 3 months ago

When implementing the change associated with CR 627, AGL identified a problem in sharing C&I customer plans that may not have any daily supply charge. The description of dailySupplyChargeType states that the default value is SINGLE if field not provided and as a result requires dailySupplyCharge to be provided. This creates an issue for sharing C&I (or other) plans that do not any daily supply charge.

There are two potential options to consider for this:

Option 1: 0 value dailySupplyCharge:

In this option, the retailer can provide a 0 value for dailySupplyCharge field for plans with no daily supply charge.

This option requires no standards change and is considered non-breaking.

Option 2: Remove default for dailySupplyChargeType:

This option involves updating the description of dailySupplyChargeType from: Specifies if daily supply charge is single or banded. Default value is SINGLE if field not provided

to: Specifies if daily supply charge is single or banded. If absent, it implies there is no daily supply charge for the plan

This is considered non-breaking.

Feedback on the above options is welcome.

AGL-CDR commented 3 months ago

For the sake of clarity: the issue is not that some C&I plans have no daily supply charges at all, but that sometimes the equivalent of a daily charge is combined within network pass-through charges. So issuing a value of zero might potentially be misconstrued as meaning the business is not subject to daily supply charges of any kind, which isn't true.

perlboy commented 3 months ago

As per MI call we are supportive of @AGL-CDR's statement and suggest Option 2 but omit the absent component, i.e. Specifies if daily supply charge is single or banded.

CDR-API-Stream commented 3 months ago

During the MI call on August 7, participants supported option 2 of updating the description of dailySupplyChargeType noting that "If absent, it implies there is no daily supply charge for the plan" should be removed from the proposal as it misrepresents the problem clarified by @AGL-CDR in this comment

The revised proposal is to update the description of dailySupplyChargeType from: Specifies if daily supply charge is single or banded. Default value is SINGLE if field not provided to: Specifies if daily supply charge is single or banded.

The feedback also noted that this would be a breaking change, resulting in version increment of following APIs:

As a result, the DSB is proposing a 6 month FDO of March 17 2025 as per the obligation date schedule. Given that this is a minor change, the DSB is seeking feedback on if the FDO can be brought forward.

perlboy commented 3 months ago

As discussed on MI, while we agree that incrementing the version is the right default proposal in this case we don't think an endpoint version bump here is the easiest/lowest cost for participants.

Reasons are as follows:

  1. There seems to be limited Holders impacted by the requirement to begin with, the ones that aren't impacted would be providing the same payload across versions
  2. Very few, probably zero if we assume Biza is first to market, Holders have delivered V4 at this stage and on that basis ADRs aren't currently impacted.
  3. Very small change for a version bump but also sacrificing an FDO date, doesn't seem worthwhile

This looks like maybe a concept of "V4 Errata 1" where eligibility is based on time horizon prior to an FDO (>8 weeks?).

Jacqui-AER commented 2 months ago

The AER also support option 2. As we are still in the process of developing Get Generic Plan Detail v3, we would also prefer this change to be included as an errata for v3 instead of a version increment. Jacqui (AER)

DannyDuong commented 2 months ago

DEECA can support either options and will be able to incorporate the changes as part of Get Generic Plan Detail v3

CDR-API-Stream commented 2 months ago

Thank you all for your feedback.

As noted above and discussed in the MI call on 4th September, the change can be accommodated within existing FDO of 11th Nov 2024 for the following APIs without needing a version increment:

The change has been staged for review.

nils-work commented 1 month ago

Incorporated into Standards v1.32.0.