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

Representing adjustment transactions within the Billing Payload for C&I customers #438

Closed priyaH-OriginEnergy closed 2 years ago

priyaH-OriginEnergy commented 2 years ago

Description

Adjustments are currently only displayed as relating to usage transactions whereas for C&I adjustments can arise due to various reasons (that are not usage related) such as environmental rate update, tariff change, etc.

Area Affected

Energy APIs and payloads

Change Proposed

Options to denote back dated adjustments (may or may not be usage related)

Attributes to include: start & end date, quantity, rate, reason, calculation factor (similar structure to usage transactions, but made optional to cater to non-usage adjustments)

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

The DSB proposes the following amendment to the otherCharges schema to cater for the issue raised in the CR.

"otherCharges": {
  "servicePointId": "string",
  "invoiceNumber": "string",
  "startDate": "DateString",
  "endDate": "DateString",
  "type": [ "ENVIRONMENTAL", "REGULATED", "NETWORK", "METERING", "RETAIL_SERVICE", "RCTI", "OTHER"],
  "amount": "AmountString",
  "description": "string",
  "calculationFactors": [ //Optional object to capture additional calculation factors that inform the transaction
    {
      "value": "number",
      "type": [ "DLF", "MLF"]
    }
  ],
  "adjustments": [ //Optional array of adjustments arising for this transaction
    {
      "amount": "AmountString",
      "description": "string"
    }
  ]
}

The change involves including 'calculationFactors' and 'adjustments' arrays within ‘otherChargers’. The arrays are currently used within the usage and demand charges of EnergyBillingTransaction.

This should allow consistent representation of any calculation factors (i.e. DLF or MLF) used for deriving other charges and any adjustments arising from other types of charges such as environmental charge.

Ram-Origin commented 2 years ago

Hi DSB,

The proposed changes address the problem and agree with the solution proposed.

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.