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

Review Pricing Model & Time Zone attributes within Account Detail Payload #439

Closed priyaH-OriginEnergy closed 2 years ago

priyaH-OriginEnergy commented 3 years ago

Description

Pricing Model & Time Zone should be represented at the charge level not at the plan level

Area Affected

Energy APIs - Account Detail API

Change Proposed

Pricing Model (such as TOU, Single Rate etc.) and Time Zone for C&I customers are specific to charge categories such as usage, environmental, metering etc. and can therefore vary. These attributes are currently defined at the plan level within the Account Detail API, these should instead be defined at a charge category level

CDR-API-Stream commented 2 years ago

Given this change request was raised late during the iteration, the DSB proposes it be carried over to the next maintenance iteration.

CDR-API-Stream commented 2 years ago

@priyaH-OriginEnergy, could you provide an example use case or scenario that can help understand the problem. It will help work through solution options.

CDR-API-Stream commented 2 years ago

To help facilitate discussion, the DSB would like to summarise our understanding of the problem:

  1. A C&I customer can have an energy contract with different pricing models applied to different charges. For example, there could be environmental charges that are based on time of use whilst the usage charges could be single rate
  2. The time zone in which certain charges have the time of use threshold calculated can also be different per charge
  3. Currently, both pricing model and time zone are specified at the contract level

If the above understanding is correct, the current structure should allow representation of point 1 within the EnergyPlanTariffPeriod schema using the ‘type’ attribute to specify the charge type (e.g. ENVIRONMENTAL) and specifying rateBlockUType as timeOfUseRates.

The second point can be addressed by including an optional ‘timeZone’ attribute within EnergyPlanTariffPeriod so charge specific time zones can be provided. If absent, contract level timezone would be assumed.

Ram-Origin commented 2 years ago

Hi DSB,

The above statement is correct for first point and agree with the solution proposed. With the second agree with the the proposed solution for time zone attribute.

Regards, Ram

CDR-API-Stream commented 2 years ago

This change was incorporated into release v1.17.0. Refer to https://github.com/ConsumerDataStandardsAustralia/standards/issues/237 for further details.