Add new pricing models to EnergyPlanContractV2

[rhys-ergon]

Description

EnergyPlanContractV2 has the following pricing model options:

• SINGLE_RATE
• SINGLE_RATE_CONT_LOAD
• TIME_OF_USE
• TIME_OF_USE_CONT_LOAD
• FLEXIBLE
• FLEXIBLE_CONT_LOAD
• QUOTA

Ergon Energy has several contract pricing models that do not fit into any of the above options, these are:

• Multiple Primary Tariffs
• Multiple Primary Tariffs with one or more controlled load tariffs
• Demand Tariffs
• Demand Tariffs with one or more controlled load tariffs
• Primary Tariffs that are controlled load tariffs

Area Affected

Schema: EnergyPlanContractV2 Property: pricingModel Endpoint: GET /energy/accounts/{accountId}

Change Proposed

Add 3 new pricing model options:

1. DEMAND – This is to cover demand tariff contracts.
2. DEMAND_CONT_LOAD – This is to cover demand tariff contracts with controlled load tariffs.
3. OTHER – This is to cover multiple primary tariffs and primary tariffs as controlled load. Since these pricing models are likely unique to regional QLD, there may not be benefit in creating explicit categories and this option can be used by other energy retailers if they have niche pricing models.

DSB Proposed Solution

The proposed solution can be found through the staging link provided in https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/623#issuecomment-2024328249

[mattyp]

@rhys-ergon: on demand tariffs, I agree that the current demand tariff data structure is currently broken. Demand charges are currently defined in the standards as an alternative to singe rate or time-of-use rates within a tariff period, but the industry calculates demand tariffs in addition to single rates (conceivably TOU rates, too), rather than an alternative to the single rates.

Demand tariffs are the defacto standard for most new plans on the AusGrid network (NSW largest), so it is quickly becoming a material issue. EME are somewhat working around this by including the demandCharges property on the tariffPeriod object anyway, even though the tariffPeriod object has a rateBlockUType of singleRate (just don't mention the quality of data within those demandCharges objects...).

Give this is broken in the standards, what are the options?

You have suggested an option of elevating demand charges to dedicated pricing models. I can see the logic in that. This makes it very clear to data consumers that there are demand components to the plan. The downside is that a whole new structure needs to be defined which essentially duplicates 99% of existing structures for other pricing models (which may not be a big deal). Also, which pricing model is assigned for plans that have demand charges for one tariff period but not in another (e.g. demand for winter, not for summer)?

As an alternative option, what do you think about declaring demandCharges to be a component property of a tariff period (tariffPeriod), as an independent sibling to existing rates (singleRate, timeOfUseRates)? This involves removing demandCharges as a rateBlockUType enum option. This property then outlines the demand charges that are in addition to the usage rates, which aligns with how the industry calculates this tariff. It can be conditional on an additional tariffPeriod boolean property called hasDemandCharges being set to true. The upside is that this augments existing pricing models and so is extensible to any pricing models, it solves for the in-between plans which have demand charges in on tariff period but not in another, and that it aligns with the industry calculation methods. The downside is that data consumers need to drill deep into the structure to discover if the plan includes a demand component or not (not such a big deal).

BTW, how do the 'multiple primary tariff' plans work in practice?

[rhys-ergon]

Hi @mattyp, thanks for the feedback. I was initially just proposing adding the new models to the pricingModel enum without any changes to the schemas in EnergyPlanContractV2. I think I would need to see an example of your proposed data structure to make sure I understand the changes you're suggesting.

Also, which pricing model is assigned for plans that have demand charges for one tariff period but not in another (e.g. demand for winter, not for summer)?

Some options would be:

• If it's going to be widely used, create a new model name that best represents it e.g. WINTER_DEMAND
• map it to an existing model based on its main feature
• map it to OTHER

how do the 'multiple primary tariff' plans work in practice?

In our case, an example would be a rural property with a house (residential tariff) and workshop (business tariff). I think this model is specific to rural Queensland.

[DannyDuong]

DEECA does not agree with extending the pricing model options for EnergyPlanContractV2.

The EnergyPlanContractV2.pricingModel is designed for energy usage charges. All other charges are considered in addition to the energy usage charges.

Adding additional enum options to the EnergyPlanContractV2.pricingModel can cause confusion, as to when we deal with a combination of charges and when we don't.

For example, in addition to the energy usage charges, an offer/ plan can have:

1. Demand charges
2. Greenpower charges
3. Solar tariffs

If the above mix of additional charges were added to the existing pricing model options, the enum list combinations would grow exponentially, i.e. adding demand in the mix we could go from 6 options to 12 (e.g. SINGLE_RATE_CONT_LOAD_DEMAND ), adding more (greenpower ,solar) would take that to 24, 48 + combinations.

Looking back at the standards, we may have already gone wrong by adding CONT_LOAD in the pricing model enum values, it could’ve easily been a flag.

The field itself becomes less descriptive and accurate the more complex offers become. The description of the pricing model is defined in the existence of objects - i.e. is there a demandCharges array within a EnergyPlanTariffPeriod object.

Alternatively, rather than adding more enum options to the pricing model, we can add more flags. This will avoid the need to loop through the tariff periods and looking for nested pricing model components, an object with component flags could be added to plan details, e.g. "electricityContract": { ... "pricingComponents": { "controlledLoad": true, "demand": true, "greenPower": false, "solar": true, } ... }

Potentially, at that point the sole remaining pricing model descriptor (SINGLE_RATE, TIME_OF_USE, FLEXIBLE ) could move into the pricing components object as well

[rhys-ergon]

Thanks for the feedback @DannyDuong

The EnergyPlanContractV2.pricingModel is designed for energy usage charges. All other charges are considered in addition to the energy usage charges.

If that's the case, then we would request the DSB to update the description to make that clearer. Currently it's "The pricing model for the contract. "

One issue would remain for us, which is that Ergon can have customers on multiple primary tariffs, so one might have a single rate and a TOU rate. We could just choose one but firstly, we'd like to understand what pricingModel is trying to achieve in CDR?

[mattyp]

@rhys-ergon in your example of multiple primary tariffs, wouldn't that be two separate service points, each with their own tariff?

a rural property with a house (residential tariff) and workshop (business tariff)

[HemangCDR]

Below is the comment I attempted to post last week but someone got deleted. Re-psoting it as discussed in today's MI call (February 21) to help progress the discussion.

---

Prior to considering changes, it would be worth understanding if current structure can cater for these scenarios given they were considered during the design. I've tried to summarise them with comments/questions for further consideration.

Multiple Primary Tariffs (with/without CL)

• Energy account structure allows for sharing of plans that include multiple servicespoints/NMIs. An account can have one or more plans, each plan can be associated with multiple NMIs
• The example where an account has plans for a rural property with a house (residential tariff) and workshop (business tariff) could be represented as separate plan objects, each with its relevant pricing structure. For e.g.

  accountDetailV3
  {
  "data": {
  "accountId": "abc123",
  "accountNumber": "1234",
  "displayName": "MixedAccount",
  .
  .
  "plans": [
    {
      "nickname": "residential plan",
      "servicePointIds": [
        "spid1"
      ],
      "planOverview": {
        "displayName": "string",
        "startDate": "string",
        "endDate": "string"
      },
      "planDetail": {
        "fuelType": "ELECTRICITY",
        .
        }
       }, //end of residential plan
    {
      "nickname": "business plan",
      "servicePointIds": [
        "spid2"
      ],
      "planOverview": {
        "displayName": "string",
        "startDate": "string",
        "endDate": "string"
      },
      "planDetail": {
        "fuelType": "ELECTRICITY",
        .
        }
       }, //end of business plan
      ]//end of plans
      .
      .
  }

Demand Tariffs (with/without CL)

• Demand tariffs/charges for a plan with or without controlled load can be provided as the EnergyPlanTariffPeriod is an array of rates.
• I am assuming demand charge with controlled rate would fall within SINGLE_RATE_CONT_LOAD category

• @rhys-ergon: on demand tariffs, I agree that the current demand tariff data structure is currently broken. Demand charges are currently defined in the standards as an alternative to singe rate or time-of-use rates within a tariff period, but the industry calculates demand tariffs in addition to single rates (conceivably TOU rates, too), rather than an alternative to the single rates.

  Demand charges can be provided along with single rate or time of use rates in the EnergyPlanTariffPeriod array. An example of it would be:

  "tariffPeriod": [
  {
    "type": "ENVIRONMENTAL"/"OTHER",
    .
    .
    "rateBlockUType": "singleRate",
    "singleRate": {
      "displayName": "string",
      "description": "string",
      "generalUnitPrice": "string",
      "rates": [
        {
          "unitPrice": "string",
          "measureUnit": "KWH",
          "volume": 0
        }
      ],
      "period": "string"
    },
    .
    .
  },//single rate end
  {
    "type": "ENVIRONMENTAL"/"OTHER",
    .
    .
    "rateBlockUType": "demandCharges",
     "demandCharges": [
     {
          "displayName": "string",
          "description": "string",
          "amount": "string",
          "measureUnit": "KWH",
          "startTime": "string",
          "endTime": "string",
          "days": [
            "SUN"
          ],
          "minDemand": "string",
          "maxDemand": "string",
          "measurementPeriod": "DAY",
          "chargePeriod": "DAY"
     }
  ]
    .
    .
  },//demand charge end

Primary Tariffs that are controlled load tariffs

• @rhys-ergon could you clarify this further? Is this a scenario where the customer has signed up for a controlled load only plan (i.e. no other rates?). If so, would this also be classified as SINGLE_RATE_CONT_LOAD and you could provide the rates within the EnergyPlanControlledLoad array.

Feedback on the above is welcome.

[rhys-ergon]

@rhys-ergon in your example of multiple primary tariffs, wouldn't that be two separate service points, each with their own tariff?

a rural property with a house (residential tariff) and workshop (business tariff)

@mattyp yes correct, 2 service points/meters each with their own tariff, 1 NMI, 1 contract, 1 account

[rhys-ergon]

Thanks for the examples @HemangCDR .

Can we now just make this ticket to update the description of EnergyPlanContractV2.pricingModel to make it clearer that pricing model is only based on usage charges?

Example:

"The pricing model for the contract based on usage charges only. Contracts for gas must use SINGLE_RATE. Note that the detail for the enumeration values are:"

[rhys-ergon]

@rhys-ergon could you clarify this further? Is this a scenario where the customer has signed up for a controlled load only plan (i.e. no other rates?). If so, would this also be classified as SINGLE_RATE_CONT_LOAD and you could provide the rates within the EnergyPlanControlledLoad array.

@HemangCDR I think there could be an issue with this use case.

Is this a scenario where the customer has signed up for a controlled load only plan (i.e. no other rates?)

That's correct.

The issue is that tariffPeriod is mandatory but its not applicable for this situation.

[HemangCDR]

Below is the summary of discussion on this CR:

• The original CR was raised due to misunderstanding on what the pricingModel options are for. i.e. they are based on usage charges
• The various scenarios described in the CR can be catered for within the existing standards without any change
• A proposal was made to update the description of pricingModel to make it more clear that it is about usage charges. This can be considered. However, noting that the description of the ENUM values provide the clarity, no change is recommended.

Feedback on the above is welcome.

[nils-work]

This issue was discussed in MI18 and the decision was for no change as described in this comment.