Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Energy C&I tariff extensions #422

Closed
CDR-API-Stream opened this issue Nov 3, 2021 · 5 comments
Closed

Energy C&I tariff extensions #422

CDR-API-Stream opened this issue Nov 3, 2021 · 5 comments
Labels

Comments

@CDR-API-Stream
Copy link
Collaborator

Description

In the recently published candidate standards for energy feedback on the representation of tariffs for C&I customer plans was received. As the payloads were initially defined for EME presentment, where C&I is not represented, there is concern the structures in account details are not comprehensive enough to accurately represent C&I plans

Area Affected

Energy APIs and payloads

Change Proposed

Review the existing representation of C&I taridds in the energy account details payload to determine if changes need to be made

@CDR-API-Stream
Copy link
Collaborator Author

This change request covers, but is not limited to, the following feedback re C&I tariffs/charges:

  • Modification of payload to capture charges specific to C&I customers listed below
    • “environmentalCharge”, “regulatedCharge”, “networkCharge”, “meteringCharge”, “retailServiceCharge”, “RCTICharge”

Note that the billing & invoicing payloads have "otherCharges" object to capture the above type of charges. An option would be to add a similar object to the account payload which will maintain consistency. Another benefit would be flexibility (e.g. if any more charges are added in future the structure does not have to change).

Note: the tariff structures will need to be aligned across generic tariff payloads.

The above feedback can be found in below decision proposals:

@priyaH-OriginEnergy
Copy link

priyaH-OriginEnergy commented Nov 23, 2021

  • We support the list of charge types captured
  • With using otherCharges within the Account Detail payload, our assumption is that an enumeration list will be available for each charge type
  • Attributes within the otherCharges array (for Account Detail payload) will need to include displayName, description, rate, rateUnit, startDate and endDate

@CDR-API-Stream
Copy link
Collaborator Author

Thank you for your feedback @priyaH-OriginEnergy.

We propose the following specific changes

  • Update "otherCharges" object in billing & invoicing payload with C&I specific enum values suggested above
  • Update the "fees" object in Account detail payload with the C&I specific enum values suggested above and also add a "rateUnit" attribute. This will ensure payload consistency between generic tariff and plans whilst accommodating C&I specific charges. The "rateUnit" attribute will also be added to Generic Tariff payload.

@CDR-API-Stream
Copy link
Collaborator Author

CDR-API-Stream commented Dec 23, 2021

This change was incorporated into release v1.15.0. Refer to Decision 212 for further details.

@CDR-API-Stream
Copy link
Collaborator Author

The DSB would like to provide the an update regarding changes to the account detail payload.

Upon further assessment, we found that it would be better to Time Of Use Rates object instead of Fees object to reflect C&I related charges in the Account detail payload as they can be reflected with minimal changes. As such, we have made the following changes:

  • Added ‘type’ enumeration to EnergyPlanTariffPeriod object with C&I specific ENUM values mentioned above
  • Added ‘measureUnit’ to EnergyPlanTariffPeriod where applicable to cater for different units of measure for amount/unit prices (e.g. KVA, KVAR, DAYS, etc.)

As always, if the above changes are not sufficient, we can review them in future maintenance iterations.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Archived in project
Development

No branches or pull requests

2 participants