Maintenance Iteration 22 Holistic Feedback

[ElizabethArnold-DSB]

This change request has been created to simplify the raising of minor changes, such as text corrections or description clarifications, that are not really material to the standards but do have a real impact on readability and clarity.

Please raise any such suggestions that you would like included in ConsumerDataStandardsAustralia/standards#364 on this issue and the DSB will review them. If a suggestion is a material change a dedicated change request will be raised.

[nils-work]

The current deposit/lending rate tiers field has the confusing description:

Rate tiers applicable for this rate.

Could we consider changing this to more clearly explain the intent of the array, perhaps reflecting the description of the BankingProductRateTierV3 object it contains, which is: "Defines the criteria and conditions for which a rate applies."

The proposed replacement text for the tiers array field is:

Qualifying criteria or conditions relevant to the associated rate.

[nils-work]

The Error Response Structure section describes the isSecondaryDataHolderError field which had an FDO of May 15 2023, but it is not specified in any schema:

• isSecondaryDataHolderError field MAY be present: an optional Boolean flag which indicates the error is propagated from a designated secondary data holder.

If this optional field were to be added to the relevant error response schema, should it be considered a breaking, or non-breaking change?

The change may affect the following Energy endpoints:

• Get Service Points
• Get Service Point Detail
• Get Usage For Service Point
• Get Bulk Usage
• Get Usage For Specific Service Points
• Get DER For Service Point
• Get Bulk DER
• Get DER For Specific Service Points

[nils-work]

In the MI22 call on 5 Feb., there was an indication of support for the two issues noted in the previous comments to be resolved as non-breaking changes.

[nils-work]

The Banking Scheduled Payments endpoints are specified under two different paths; /banking/accounts and /banking/payments:

#	Name	Method	Path
1	Get Scheduled Payments for Account	GET	/banking/accounts/{accountId}/payments/scheduled
2	Get Scheduled Payments Bulk	GET	/banking/payments/scheduled
3	Get Scheduled Payments For Specific Accounts	POST	/banking/payments/scheduled

If they were to follow the pattern of other endpoints, this group would have been specified under a single common path:
/banking/accounts

If introducing this consistency would simplify implementations or provide other benefits, the misalignment of the second and third endpoints could be noted in the Future improvements section and considered with future changes to those endpoints.

[mattyp]

Simple text/typo correction @ https://consumerdatastandardsaustralia.github.io/standards/#cdr-energy-api_schemas_tocSenergyplancontrolledloadv2

Change: controlloed to controlled

[CDR-CX-Stream]

Proposed change
Remove the 'Effective from July 1 2024' FDO references from the DH dashboard CX standards.

This obligation date has passed and this change will not materially alter the CX standards requirement. The historical obligation date is captured separately in the FDO section.

[mattyp]

Array delimiters ([]) are missing from several array properties of Energy Plan Contract v3:

[mattyp]

Description clarification

The current description for EnergyPlanTariffPeriodV2 is:

Array of tariff periods.

Sometimes this schema is used by DHs to describe intra-day time-of-use tariff periods, rather than the presumably intended intra-year tariff periods (e.g. seasonal tariffs). Can we expand on the description to help ensure a consistent interpretation of the intended use of this schema? My suggestion would be:

Array of tariffs that apply to periods throughout the year

This improvement should also be mimicked in the EnergyPlanContractV3 description for the tariffPeriod property.