Decision Proposal 190 - Candidate Generic Tariff End Points

[CDR-API-Stream]

This decision proposal contains a recommendation for the candidate URIs and end points for Generic Tariff Data. This proposal has been developed with the aid of AER and DELWP.

The decision proposal is embedded below:
Decision Proposal 190 - Candidate Generic Tariff End Points.pdf

This consultation will be open for feedback until the 1st October 2021.

[CDR-API-Stream]

A proposal for this consultation is under development. It is hoped that it will be posted in the next few days.

[DannyDuong]

I had a review of those standards and I believe these need further considerations:

1. Solar - Available feed in types are 'Government' and 'Retailer', no way to differentiate between premium and current feed-in tariff
2. Fees – please add an additional_info field to describe general information about all fees E.g. "for additional information on fees go to xxxx"
3. Fees and incentive amounts are GST inclusive (apart from the annual fees, these amounts are not used by the VEC calculation engine when calculating annual costs)

[CDR-API-Stream]

Thank you for the feedback Danny.

1. Solar - Available feed in types are 'Government' and 'Retailer', no way to differentiate between premium and current feed-in tariff

Just to clarify, would your feedback be addressed with two additional enumeration values should be added to the solarFeedInTariff.type field:

• PREMIUM
• CURRENT

2. Fees – please add an additional_info field to describe general information about all fees E.g. "for additional information on fees go to xxxx"

An additionalInfo field will be added.

3. Fees and incentive amounts are GST inclusive (apart from the annual fees, these amounts are not used by the VEC calculation engine when calculating annual costs)

Would an overall statement indicating that all prices are GST inclusive be an appropriate response to this feedback?

[joe-aer]

The EME team appreciates the opportunity to provide feedback on this decision proposal.

Contingent Plans

The EME team understands from the DSB that the generic tariff APIs have been specifically designed for a full plan extract and cache use case as opposed to a real-time query use case. Therefore, whilst we recognise the need to represent the contingent plan concept in the data standard, we believe that an additional contingent plan flag delivers limited value and utility when this concept can be represented through the eligibility object with an additional CONTINGENT_PLAN eligibility type enumeration value.

We therefore oppose the creation of the field.

Green Power

The EME team understands from the DSB that the generic tariff APIs have been specifically designed for a full plan extract and cache use case as opposed to a real-time query use case. Therefore, we believe that this derived flag field delivers limited value and utility when the greenPowerCharges object can indicate the presence of green power in a plan.

Further, creating this derived field would represent a duplication of state, something that should be avoided to mitigate any extra synchronisation or validation work for both data holder and recipient.

We therefore oppose the creation of the field.

Intrinsic Green Power

The EME team understands the need to capture the concept of green power being an inclusive rather than additive component of a plan, and as such, attracts no charge.

We offer here an alternative option to the 3 proposed, combining elements from options 1 and 2. We oppose option 3 on the grounds that an additional object is unnecessary.

We propose that the type field of the greenPowerCharges object receives a new NO_CHARGE enumeration value to represent an inclusive green power percentage for a plan. A tier object would still be required under this type to capture the percent green power included in the plan.

This option would also ensure that any green power boolean logic remains simple and dependent upon one object array having members.

Third Party Agent

The EME team recognises the need to represent commercial partnerships by including third party agent data in the data standard, however, due to the absence of a nationally accepted standard or an authoritative reference source, the third party agent name should be considered as annotation and not assumed to represent an external reference.

Further, we understand that the thirdPartyAgentId field was originally added due to its presence in the EME data model, however, beyond its use in EME, we believe that the field serves no purpose for recipients and propose that the field be removed.

Finally, not described in the data standard, is the business rule (originating from EME) that the presence of third party agent details must be accompanied by an eligibility restriction of type THIRD_PARTY_ONLY. Considering this business rule, we propose a further simplification of the data standard with the removal of the thirdPartyAgentName field and the addition of a new business rule stating that the information field of the eligibility object will be populated with the third party agent name when the eligibility type is THIRD_PARTY_ONLY.

Geography

The EME team recognises the need to represent the postcodes for which a plan is available in the data standard, however, we believe that the current design is overly complicated and we strongly favour an explicit approach to describing a plan’s geographical availability.

Proposed changes:

1. The includedPostcodes and excludedPostcodes fields are removed and replaced with a single postcodes field to represent the postcodes for which a plan is available. This explicit approach places the responsibility of determining geographical availability on the data holder rather than all recipients, and we believe will simplify plan-postcode query logic.
2. The supplyAreaId field is removed. We understand that the supplyAreaId field was originally added due to its presence in the EME data model, however, beyond its use in EME, we believe that the field serves no purpose for recipients.
3. The geography object and its property hierarchy is mandatory; distributor and state will always be known.

Note that due to the absence of a nationally accepted standard or an authoritative reference source, the supply area name should be considered as annotation and not assumed to represent an external reference.

It should also be noted that this design continues to combine postcodes from all supply areas into a distinct list. This approach makes sense from the data standard and its plan perspective, however, this is at the expense of data completeness; the relationship between supply areas, distributors, and their postcodes, which is known by data holders, is irrevocably lost. Furthermore, this approach assumes how recipients will use geography data and could limit utility.

Demand Charges

The EME team agrees with the promotion of the demandCharges object, its field expansion, and the addition of a demandCharges value to the tariff period’s rateBlockUType enumeration field.

Proposed changes:

tariffPeriod object:

1. The rateBlockUType enumeration field values are rendered as SCREAMING_SNAKE_CASE identifiers.
2. The startDate field is Mandatory and not Conditional. The text “Required if there is more than one period” should be removed from the description.
3. The endDate field is Mandatory and not Conditional. The text “Required if there is more than one period” should be removed from the description.

demandCharges object:

1. The amount field is Mandatory and not Conditional.
2. The days field is Mandatory and not Optional. This will ensure clarity for recipients.
3. The minDemand field description should read,
   “Minimum demand for this demand tariff in kW. If absent then 0 is assumed.”

The EME team seeks clarity on what this field is describing, i.e. minimum chargeable or minimum measurable, or something else.

4. The maxDemand field description should read,
   “Maximum demand for this demand tariff in kW. If present, must be higher than the value of the minDemand field.”

The EME team seeks clarity on what this field is describing, i.e. maximum chargeable or maximum measurable, or something else.

5. The measurementPeriod enumeration field is Mandatory and not Optional. The SEASON value should be renamed as TARIFF_PERIOD to indicate that the measurement period relates to the start and end dates of the tariff period.
6. The chargePeriod enumeration field is Mandatory and not Optional. The SEASON value should be renamed as TARIFF_PERIOD to indicate that the charge period relates to the start and end dates of the tariff period.

The EME team requests specific input from retailers as to whether the demand charges design can accommodate your product configurations.

Incentives

The EME team agrees with the addition of the category enumeration field, its values, and the eligibility string field to the incentives object.

Solar

1. Solar - Available feed in types are 'Government' and 'Retailer', no way to differentiate between premium and current feed-in tariff

To help the EME team understand the need for additional enumeration values, please clarify what is meant by current and premium.

Fees

2. Fees – please add an additional_info field to describe general information about all fees E.g. "for additional information on fees go to xxxx"

To help the EME team understand the need for an additional fee information field, please comment on whether the electricityContract.additionalFeeInformation and gasContract.additionalFeeInformation fields could satisfy this requirement? EME uses these fields for the purpose described in the example.

GST

As the data standard is a contract between data holder and recipient, the EME team opposes sweeping statements regarding field content, and proposes that the description of each amount field requires text to clearly and explicitly indicate GST inclusivity.

The EME team will submit their proposed edits shortly.

[DannyDuong]

Thank you for the feedback Danny.

1. Solar - Available feed in types are 'Government' and 'Retailer', no way to differentiate between premium and current feed-in tariff

Just to clarify, would your feedback be addressed with two additional enumeration values should be added to the solarFeedInTariff.type field:

• PREMIUM
• CURRENT

1. Fees – please add an additional_info field to describe general information about all fees E.g. "for additional information on fees go to xxxx"

An additionalInfo field will be added.

1. Fees and incentive amounts are GST inclusive (apart from the annual fees, these amounts are not used by the VEC calculation engine when calculating annual costs)

Would an overall statement indicating that all prices are GST inclusive be an appropriate response to this feedback?

Agree with your answers to #1 and #2.
With #3 however, we have a mix of GST and non GST in our system and we prefer to keep the data close to the source.
The preference is to have items that feed into the annual price calculations calculations as GST exclusive and any other items that is outside of the annual price calculations should be in it's final amount i.e. GST inclusive.
Hence, we are happy for all other rate/ amount fields to be GST exclusive (as they are currently described in the standards); but Fees and incentive amounts to be GST inclusive

[joe-aer]

The EME team appreciates the opportunity to provide feedback on this decision proposal.

This is a continuation to our original comment above and a continued response to Danny from DELWP.

Solar Feed In Tariffs

1. Solar - Available feed in types are 'Government' and 'Retailer', no way to differentiate between premium and current feed-in tariff

To help the EME team understand the need for additional enumeration values, please clarify what is meant by current and premium.

Fees

2. Fees – please add an additional_info field to describe general information about all fees E.g. "for additional information on fees go to xxxx"

To help the EME team understand the need for an additional fee information field, please comment on whether the electricityContract.additionalFeeInformation and gasContract.additionalFeeInformation fields could satisfy this requirement? EME uses these fields for the purpose described in the example.

GST

The EME team recognises that applying GST based on EME’s energy plan data standard, which is driven in part by EME’s internal computational requirements, may not produce the best overall outcome for the energy data standard or data recipients. We therefore have the following two questions.

1. As our GST application is for generic tariffs, will this application closely align with commercial and industrial tariffs, and tailored tariffs?
2. Will our GST application meet the needs of the widest number of use cases without the need for data recipients to manipulate field values?

For reference, we have included below the EME GST field application as it aligns to the draft energy data standard.

In lieu of feedback and guidance from data recipients and retailers, the EME team believes that GST should be handled consistently across the energy data standard, simplifying downstream expectations and data management.

We therefore recommend that all applicable fields should be GST inclusive, because this is typically how this information is presented to energy consumers for the purpose of evaluating and comparing products.

CDR Fields	CDR GST	EME GST
gasContract.fee.amount, electricityContract.fee.amount	Inclusive	Inclusive
gasContract.discount.fixedAmount.amount, electricityContract.discount.fixedAmount.amount	Not Specified	Inclusive
gasContract.greenPowerCharge.tiers.amount, electricityContract.greenPowerCharge.tiers.amount	Inclusive	Inclusive
meteringCharges.minimumValue	Inclusive	Inclusive
meteringCharges.maximumValue	Inclusive	Inclusive
gasContract.controlledLoad.dailyCharge, electricityContract.controlledLoad.dailyCharge	Exclusive	Exclusive
gasContract.controlledLoad.rates.unitPrice, electricityContract.controlledLoad.rates.unitPrice	Exclusive	Exclusive
gasContract.tariffPeriod.dailySupplyCharge, electricityContract.tariffPeriod.dailySupplyCharge	Exclusive	Exclusive
gasContract.tariffPeriod.dailySupplyCharge, electricityContract.tariffPeriod.dailySupplyCharge	Exclusive	Exclusive
gasContract.tariffPeriod.dailySupplyCharge, electricityContract.tariffPeriod.dailySupplyCharge	Exclusive	Exclusive
gasContract.tariffPeriod.singleRate.rates.unitPrice, electricityContract.tariffPeriod.singleRate.rates.unitPrice	Exclusive	Exclusive
gasContract.tariffPeriod.timeOfUseRates.rates.unitPrice, electricityContract.tariffPeriod.timeOfUseRates.rates.unitPrice	Exclusive	Exclusive
gasContract.tariffPeriod.singleRate.rates.unitPrice	Exclusive	Exclusive
gasContract.tariffPeriod.singleRate.generalUnitPrice, electricityContract.tariffPeriod.singleRate.generalUnitPrice	Inclusive	Inclusive
gasContract.solarFeedInTariff.amount, electricityContract.solarFeedInTariff.amount	Exclusive	Exclusive
gasContract.tariffPeriod.demandCharges.amount, electricityContract.tariffPeriod.demandCharges.amount	Exclusive	Exclusive

Gas Contract

The EME team notes that the solarFeedInTariff object array is required for both electricity and gas contracts, and whilst we wholly support parity between the contract types when it makes sense, including the solarFeedInTariff object array in the gasContract object is invalid. We therefore recommend that the solarFeedInTariff object array is removed from the gasContract object.

We also recommend that the greenPowerCharges object array is removed from the gasContract object. The term 'GreenPower' relates exclusively to the government accredited renewable energy scheme for electricity, and it is therefore erroneous to include the greenPowerCharges object array under the gasContract object.

[DannyDuong]

The EME team appreciates the opportunity to provide feedback on this decision proposal.

This is a continuation to our original comment above and a continued response to Danny from DELWP.

Solar Feed In Tariffs

1. Solar - Available feed in types are 'Government' and 'Retailer', no way to differentiate between premium and current feed-in tariff

To help the EME team understand the need for additional enumeration values, please clarify what is meant by current and premium.

Fees

1. Fees – please add an additional_info field to describe general information about all fees E.g. "for additional information on fees go to xxxx"

To help the EME team understand the need for an additional fee information field, please comment on whether the electricityContract.additionalFeeInformation and gasContract.additionalFeeInformation fields could satisfy this requirement? EME uses these fields for the purpose described in the example.

GST

The EME team recognises that applying GST based on EME’s energy plan data standard, which is driven in part by EME’s internal computational requirements, may not produce the best overall outcome for the energy data standard or data recipients. We therefore have the following two questions.

1. As our GST application is for generic tariffs, will this application closely align with commercial and industrial tariffs, and tailored tariffs?
2. Will our GST application meet the needs of the widest number of use cases without the need for data recipients to manipulate field values?

For reference, we have included below the EME GST field application as it aligns to the draft energy data standard.

In lieu of feedback and guidance from data recipients and retailers, the EME team believes that GST should be handled consistently across the energy data standard, simplifying downstream expectations and data management.

We therefore recommend that all applicable fields should be GST inclusive, because this is typically how this information is presented to energy consumers for the purpose of evaluating and comparing products.

CDR Fields CDR GST EME GST
gasContract.fee.amount, electricityContract.fee.amount Inclusive Inclusive
gasContract.discount.fixedAmount.amount, electricityContract.discount.fixedAmount.amount Not Specified Inclusive
gasContract.greenPowerCharge.tiers.amount, electricityContract.greenPowerCharge.tiers.amount Inclusive Inclusive
meteringCharges.minimumValue Inclusive Inclusive
meteringCharges.maximumValue Inclusive Inclusive
gasContract.controlledLoad.dailyCharge, electricityContract.controlledLoad.dailyCharge Exclusive Exclusive
gasContract.controlledLoad.rates.unitPrice, electricityContract.controlledLoad.rates.unitPrice Exclusive Exclusive
gasContract.tariffPeriod.dailySupplyCharge, electricityContract.tariffPeriod.dailySupplyCharge Exclusive Exclusive
gasContract.tariffPeriod.dailySupplyCharge, electricityContract.tariffPeriod.dailySupplyCharge Exclusive Exclusive
gasContract.tariffPeriod.dailySupplyCharge, electricityContract.tariffPeriod.dailySupplyCharge Exclusive Exclusive
gasContract.tariffPeriod.singleRate.rates.unitPrice, electricityContract.tariffPeriod.singleRate.rates.unitPrice Exclusive Exclusive
gasContract.tariffPeriod.timeOfUseRates.rates.unitPrice, electricityContract.tariffPeriod.timeOfUseRates.rates.unitPrice Exclusive Exclusive
gasContract.tariffPeriod.singleRate.rates.unitPrice Exclusive Exclusive
gasContract.tariffPeriod.singleRate.generalUnitPrice, electricityContract.tariffPeriod.singleRate.generalUnitPrice Inclusive Inclusive
gasContract.solarFeedInTariff.amount, electricityContract.solarFeedInTariff.amount Exclusive Exclusive
gasContract.tariffPeriod.demandCharges.amount, electricityContract.tariffPeriod.demandCharges.amount Exclusive Exclusive

Gas Contract

The EME team notes that the solarFeedInTariff object array is required for both electricity and gas contracts, and whilst we wholly support parity between the contract types when it makes sense, including the solarFeedInTariff object array in the gasContract object is invalid. We therefore recommend that the solarFeedInTariff object array is removed from the gasContract object.

We also recommend that the greenPowerCharges object array is removed from the gasContract object. The term 'GreenPower' relates exclusively to the government accredited renewable energy scheme for electricity, and it is therefore erroneous to include the greenPowerCharges object array under the gasContract object.

@joe-parkin-aer

Solar - please refer to these
https://www.energy.vic.gov.au/renewable-energy/victorian-feed-in-tariff/current-feed-in-tariff
https://www.energy.vic.gov.au/renewable-energy/victorian-feed-in-tariff/premium-feed-in-tariff

Fees
Thanks for pointing it out.
Those fields are exactly what we are looking for. It wasn't immediately obvious as it wasn't associated with the Fees object.

GST
Making GST inclusive is ok,
However, please be aware that the data is then one step removed from the source (entered data) and we may therefore encounter rounding issues.
Also, there are some fields where GST is not applicable e.g. Solar FIT

[DannyDuong]

The EME team appreciates the opportunity to provide feedback on this decision proposal.

Contingent Plans

The EME team understands from the DSB that the generic tariff APIs have been specifically designed for a full plan extract and cache use case as opposed to a real-time query use case. Therefore, whilst we recognise the need to represent the contingent plan concept in the data standard, we believe that an additional contingent plan flag delivers limited value and utility when this concept can be represented through the eligibility object with an additional CONTINGENT_PLAN eligibility type enumeration value.

We therefore oppose the creation of the field.

Green Power

The EME team understands from the DSB that the generic tariff APIs have been specifically designed for a full plan extract and cache use case as opposed to a real-time query use case. Therefore, we believe that this derived flag field delivers limited value and utility when the greenPowerCharges object can indicate the presence of green power in a plan.

Further, creating this derived field would represent a duplication of state, something that should be avoided to mitigate any extra synchronisation or validation work for both data holder and recipient.

We therefore oppose the creation of the field.

Intrinsic Green Power

The EME team understands the need to capture the concept of green power being an inclusive rather than additive component of a plan, and as such, attracts no charge.

We offer here an alternative option to the 3 proposed, combining elements from options 1 and 2. We oppose option 3 on the grounds that an additional object is unnecessary.

We propose that the type field of the greenPowerCharges object receives a new NO_CHARGE enumeration value to represent an inclusive green power percentage for a plan. A tier object would still be required under this type to capture the percent green power included in the plan.

This option would also ensure that any green power boolean logic remains simple and dependent upon one object array having members.

Third Party Agent

The EME team recognises the need to represent commercial partnerships by including third party agent data in the data standard, however, due to the absence of a nationally accepted standard or an authoritative reference source, the third party agent name should be considered as annotation and not assumed to represent an external reference.

Further, we understand that the thirdPartyAgentId field was originally added due to its presence in the EME data model, however, beyond its use in EME, we believe that the field serves no purpose for recipients and propose that the field be removed.

Finally, not described in the data standard, is the business rule (originating from EME) that the presence of third party agent details must be accompanied by an eligibility restriction of type THIRD_PARTY_ONLY. Considering this business rule, we propose a further simplification of the data standard with the removal of the thirdPartyAgentName field and the addition of a new business rule stating that the information field of the eligibility object will be populated with the third party agent name when the eligibility type is THIRD_PARTY_ONLY.

Geography

The EME team recognises the need to represent the postcodes for which a plan is available in the data standard, however, we believe that the current design is overly complicated and we strongly favour an explicit approach to describing a plan’s geographical availability.

Proposed changes:

1. The includedPostcodes and excludedPostcodes fields are removed and replaced with a single postcodes field to represent the postcodes for which a plan is available. This explicit approach places the responsibility of determining geographical availability on the data holder rather than all recipients, and we believe will simplify plan-postcode query logic.
2. The supplyAreaId field is removed. We understand that the supplyAreaId field was originally added due to its presence in the EME data model, however, beyond its use in EME, we believe that the field serves no purpose for recipients.
3. The geography object and its property hierarchy is mandatory; distributor and state will always be known.

Note that due to the absence of a nationally accepted standard or an authoritative reference source, the supply area name should be considered as annotation and not assumed to represent an external reference.

It should also be noted that this design continues to combine postcodes from all supply areas into a distinct list. This approach makes sense from the data standard and its plan perspective, however, this is at the expense of data completeness; the relationship between supply areas, distributors, and their postcodes, which is known by data holders, is irrevocably lost. Furthermore, this approach assumes how recipients will use geography data and could limit utility.

Demand Charges

The EME team agrees with the promotion of the demandCharges object, its field expansion, and the addition of a demandCharges value to the tariff period’s rateBlockUType enumeration field.

Proposed changes:

tariffPeriod object:

1. The rateBlockUType enumeration field values are rendered as SCREAMING_SNAKE_CASE identifiers.
2. The startDate field is Mandatory and not Conditional. The text “Required if there is more than one period” should be removed from the description.
3. The endDate field is Mandatory and not Conditional. The text “Required if there is more than one period” should be removed from the description.

demandCharges object:

1. The amount field is Mandatory and not Conditional.
2. The days field is Mandatory and not Optional. This will ensure clarity for recipients.
3. The minDemand field description should read,
   “Minimum demand for this demand tariff in kW. If absent then 0 is assumed.”

The EME team seeks clarity on what this field is describing, i.e. minimum chargeable or minimum measurable, or something else.

1. The maxDemand field description should read,
   “Maximum demand for this demand tariff in kW. If present, must be higher than the value of the minDemand field.”

The EME team seeks clarity on what this field is describing, i.e. maximum chargeable or maximum measurable, or something else.

1. The measurementPeriod enumeration field is Mandatory and not Optional. The SEASON value should be renamed as TARIFF_PERIOD to indicate that the measurement period relates to the start and end dates of the tariff period.
2. The chargePeriod enumeration field is Mandatory and not Optional. The SEASON value should be renamed as TARIFF_PERIOD to indicate that the charge period relates to the start and end dates of the tariff period.

The EME team requests specific input from retailers as to whether the demand charges design can accommodate your product configurations.

Incentives

The EME team agrees with the addition of the category enumeration field, its values, and the eligibility string field to the incentives object.

Solar

1. Solar - Available feed in types are 'Government' and 'Retailer', no way to differentiate between premium and current feed-in tariff

To help the EME team understand the need for additional enumeration values, please clarify what is meant by current and premium.

Fees

1. Fees – please add an additional_info field to describe general information about all fees E.g. "for additional information on fees go to xxxx"

To help the EME team understand the need for an additional fee information field, please comment on whether the electricityContract.additionalFeeInformation and gasContract.additionalFeeInformation fields could satisfy this requirement? EME uses these fields for the purpose described in the example.

GST

As the data standard is a contract between data holder and recipient, the EME team opposes sweeping statements regarding field content, and proposes that the description of each amount field requires text to clearly and explicitly indicate GST inclusivity.

The EME team will submit their proposed edits shortly.

I'll discuss only the items where we have discrepancies in our views.

Intrinsic Green Power
This is different to the GreenPower accredited program, we agree with DSB recommended option 3 in this proposal document.
We prefer to keep this outside of the existing greenPowerCharges object.

Also, having a NO_CHARGE greenPowerCharges does not necessarily imply Intrinsic Green Power.
What it is saying is that there are no charges associated with a given GreenPower option, whereby a retailer may choose to absorbed the additional costs associated with the associated GreenPower option

Geography
We prefer to use the existing construct due to a number of reasons:

1. The data is closer to the source (entered data)
2. Smaller payload per offer, e.g. nominating an SupplyArea is much simpler than a long list of postcodes
3. Dealing with new postcodes. New postcodes are created from time to time, does that invalidate some existing offers if we were to adopt the suggested solution you've outlined?

[joe-aer]

Thanks for the response @DannyDuong

Solar Feed In Tariffs

Solar - please refer to these
https://www.energy.vic.gov.au/renewable-energy/victorian-feed-in-tariff/current-feed-in-tariff
https://www.energy.vic.gov.au/renewable-energy/victorian-feed-in-tariff/premium-feed-in-tariff

After reviewing the links that you provided, we now have a better understanding of the Victorian solar feed-in tariffs.

We now propose the following redesign of the solarFeedInTariff object.

"solarFeedInTariff": [
	{
		"displayName": "String",
		"description": "String",
		"scheme": "Enum { PREMIUM | OTHER }",
		"payerType": "Enum { GOVERNMENT | RETAILER }",
		"tariffType": "Enum { SINGLE_TARIFF | TIME_VARYING_TARIFFS }",
		"singleTariff": 
		{
			"amount": "AmountString"
		},
		"timeVaryingTariffs": [
		{
			"type": "Enum { PEAK | OFF_PEAK | SHOULDER }",
			"amount": "AmountString",
			"timeVariations": [{
				"days":
				{
					"weekdays": "Boolean",
					"weekends": "Boolean"
				},
				"startTime": "TimeString",
				"endTime": "TimeString"
			}]
		}]
	}
]

'current' & 'premium'

• We endorse the inclusion of 'premium' as a scheme in the data standard, see below.
• We don't endorse the inclusion 'current' in the data standard. Codifying an entity as 'current' is too specific both in time and in jurisdiction; it is only applicable right now and in Victoria. Outside of this context, 'current' adds no value to the data standard, and may only serve to confuse data recipients.
• We had debated the need to include some aspect of the VIC ESC minimum tariff regulation that sits behind the 'current' tariff, however, we don't believe that knowing this information about a plan would be beneficial for data recipients.
• We envisage that both 'current' and 'premium' could be also be captured as free-text in the (new) displayName field.

Time Varying Tariffs

• The concept of a time varying tariff has been added through the timeVaryingTariffs object.
• EME currently doesn't cater for these tariffs, but adding the concept now will enable future implementation to take place without the need to change the data standard.
• We have designed this tariff type based on the Victorian model, found here: https://www.energy.vic.gov.au/renewable-energy/victorian-feed-in-tariff/current-feed-in-tariff.
• singleTariff and timeVaryingTariffs objects are conditional on the value of the tariffType field.

Payer Type

• We believe that the field name type was too ambiguous, and open to misinterpretation.
• The type field has been renamed to payerType to sharpen its meaning to specifically refer to the entity paying the tariff amount.
• The payerType value of GOVERNMENT captures FiT for all government schemes.
• The payerType value of RETAILER captures FiT for all retailers.
• The payerType field is required.

Scheme

• The scheme field is to enable data holders to capture, codify, and communicate generally (nationally) recognised schemes, programmes, or strategies. For example, Premium FiT.
• This codification seeks to enable data recipients to detect the presence of such schemes and, when appropriate, display any associated banners or logos.
• The field is typed as enum to facilitate codification and to minimise the impact of scheme changes.
• The scheme field is optional. If absent then it is assumed that the tariff is not part of any scheme.

GST

Making GST inclusive is ok,
However, please be aware that the data is then one step removed from the source (entered data) and we may therefore encounter rounding issues.
Also, there are some fields where GST is not applicable e.g. Solar FIT

Our aim with GST, as with all other aspects of the data standard, incl. geography, was to limit the influence of EME and its operational requirements and strive for a faithful representation of retailer products, as if the retailer themselves had provided the product data direct to data recipients. This is why we proposed to align GST across all applicable fields, attempting to remove any EME influence. This is also why retailer guidance on this matter is essential.

Intrinsic Green Power

This is different to the GreenPower accredited program, we agree with DSB recommended option 3 in this proposal document.
We prefer to keep this outside of the existing greenPowerCharges object.

Also, having a NO_CHARGE greenPowerCharges does not necessarily imply Intrinsic Green Power.
What it is saying is that there are no charges associated with a given GreenPower option, whereby a retailer may choose to absorbed the additional costs associated with the associated GreenPower option

The points that you highlight have led to the following proposed redesign for the greenPowerCharges object.

"greenPowerCharges": [
	{
		"displayName": "String",
		"description": "String",
		"scheme": "Enum { GREENPOWER | OTHER }",
		"type": "Enum { NO_CHARGE | FIXED_PER_DAY | FIXED_PER_WEEK | FIXED_PER_MONTH | FIXED_PER_UNIT | PERCENT_OF_USE | PERCENT_OF_BILL }",
		"tiers": [
		{
			"percentGreen": "RateString",
			"rate": "RateString",
			"amount": "AmountString",
		}]
	}
]

The greenPowerCharges object has been extended to cover all green power charges, incl. retailer absorbed charges or NO_CHARGE charges and intrinsic green power charges.

Scheme

• GreenPower accreditation scheme charges are codified and captured through the scheme field.
• This codification seeks to enable data recipients to detect the presence of such schemes and, when appropriate, display any associated banners or logos.
• The field is typed as enum to facilitate codification and to minimise the impact of scheme changes.
• The scheme field is optional. If absent then it is assumed that the charge is not part of any scheme, i.e. intrinsic.

As a matter of reference, please could you provide a link to an energy product that contains intrinsic green power?

Geography

We prefer to use the existing construct due to a number of reasons:

The data is closer to the source (entered data)

We believe that the need to keep the data closer to its source structure is outweighed by the need to provide data recipients with a simple to use and understand design.

Smaller payload per offer, e.g. nominating an SupplyArea is much simpler than a long list of postcodes

It would certainly be simpler, and the payload smaller, if plans only needed to reference supply areas. However, we know from our comparator services that customers begin their plan search using postcode, and therefore, we cannot see how a supply area only design can be implemented without the support of a supply area reference source or service that can map from postcode to supply area.

Dealing with new postcodes. New postcodes are created from time to time, does that invalidate some existing offers if we were to adopt the suggested solution you've outlined?

In the event that postcodes were added or removed (or any extensive plan update performed), it would follow that some plans would be invalidated throughout the plan data supply chain, from retailer to AER/DELWP to data recipient.

[EnergyAustraliaBA]

A general question regarding why are references to gas and dual fuel included when CDR is only applicable to Electricity? e.g. ‘fuelType’ description; ‘gasContract’; ‘pricingModel’ description. If fuel types other than electricity are included then it should fail?

We think a possible explanation is this is likely just a flag as some plans will include these elements, even though the billing data for non electricity items is not relevant?

[PratibhaOrigin]

Thanks for the opportunity to provide feedback on this topic.

• A general query - For few fields , its suggested in this paper that it is determined by the retailer offering the plan how to populate this field.
  As you are aware, retailers already share their generic available plans and few restricted plans (specific eligibility criteria based) with Energy Made Easy (EME) and Victoria Energy Compare (VEC) as per specific formats.
  There are data standards and manuals for these comparison websites.
  Question: We want to confirm that there will be no change to the data that retailers provide EME or VEC and it will be up to the ADR EME to interpret and respond with the details as per the generic tariff APIs? We assume that the CDR APIs will not impact the current format on how retailers share the data with EME and VEC. .If there is to be a change or an updated format , we would like to review these.

A couple of points regarding specific fields in this paper –

1. Postcodes – Origin concurs with EME’s feedback on postcodes as mentioned below –

The includedPostcodes and excludedPostcodes fields are removed and replaced with a single postcodes field to represent the postcodes for which a plan is available. This explicit approach places the responsibility of determining geographical availability on the data holder rather than all recipients, and we believe will simplify plan-postcode query logic.

2. Can the postcode be added as a request parameter in the generic tariff APIs? That is, if an ADR requests plan details, it will be specific to one postcode. This will remove some of the API complications on how to present the data for multiple postcodes , DB patches , few charges are specific to DBs and not a fixed.
   Also, Iin terms of use case, we see that the ADR will be requesting this data to compare the plans available for a customer at a specific site (postcode). Therefore, there should not be a need to include multiple postcodes.
   We would like the DSB’s views on the above.
3. SupplyAreaID – This field is used in the EME plan data model for their purposes. There is no proper decision on how to populate this field and we recommend that this field be excluded. This is also given that the generic tariff structures may transfer over to the tailored tariff structure and is not a term we use.
4. meteringCharges - Is this field GST exclusive or inclusive? There is no set standard for setting the fees / charges/ discounts – some are represented on a GST inclusive basis and others are on a GST exclusive basis. We support one standard for the presentation of offers (charges/fees/discounts) in relation to GST.
5. Eligibility Type – It should be noted that not all eligibility criteria are included here. Retailers may have eligibility criteria that are only relevant to certain plans or certain groups of customers. These criteria could be based on employee status or credit history. We would represent these in the “OTHER” field
6. We note that the paper makes reference to business customers and whether the fields are flexible to include C&I customers in the future if they were deemed to be in scope. Some further feedback from a C&I perspective -
   • C&I customers do not have a set "plan list" that is offered in the market as each contract is unique based on the customer's preferences and usage patterns;
   • "metering charges" for C&I customers can have varying unit of measures such as $/meter, $/days etc. Should these be specified in the payload? C&I customers can also have their own independent metering contracts with other metering participants and so the charges can vary accordingly or there be no charges included on a bill as they are charged separately;
   • Some fee types such as disconnection / reconnection etc. are applicable but may not have a fixed rate. These fees are directly passed through from the Network. It will not be possible to indicate the amount/rate in these instances. Should these be excluded for C&I customers?
   • "daily supply charges" are not applicable for all C&I customers. This field is currently mandatory in the payload and would not be relevant to C&I customers;
   • Energy rates are not always fixed/agreed to for a contract. For some types of contracts, these are determined dynamically and so the usage rates cannot be made available within the tariff Period block;
   • A single tariff period can have charges that are single rate and time of use rate, in these cases, will we need to have 2 blocks with the same start and end date, but one displaying single rate information and the other displaying TOU information?
   • Demand charges are assumed to be calculated on a $/kwh basis within the payload. For C&I customers, these can also be calculated on $/kVA basis;
   • There are other variable pass through charges that the customer pays for based on their network tariff as well as based on AEMO's annual market fee structure (some of these are usage based while some are $/day), the rates for these are not fixed.

We will aim to provide more feedback on the above for C&I customers as part of reviewing the detailed tariff payloads within the Account Detail DP.

[CDR-API-Stream]

Thanks everyone for the feedback. This consultation is now being closed. We will provide a response to feedback shortly.

[CDR-API-Stream]

Apologies for taking time to respond to the feedback. The conversation between AER and VEC has been very constructive and detailed but it has taken some time to fully compare the different positions.

Responses on specific topics will follow and these will be included in the decision to be submitted for review to the Data Standards Chair.

It is also noted that there will continue to be opportunities to finalise and enhance these payloads following any formal decision of the Chair using the standard processes used by the DSB to manage the standards over time.

[CDR-API-Stream]

In response to the feedback from @EnergyAustraliaBA:

A general question regarding why are references to gas and dual fuel included when CDR is only applicable to Electricity? e.g. ‘fuelType’ description; ‘gasContract’; ‘pricingModel’ description. If fuel types other than electricity are included then it should fail?

We think a possible explanation is this is likely just a flag as some plans will include these elements, even though the billing data for non electricity items is not relevant?

While the focus is on electricity the designation instrument explicit includes gas data if that data is appropriate to support the sharing of electricity data. The sharing of gas and dual tariff plans is an area that is explicitly referenced in the designation.

[CDR-API-Stream]

In response to the feedback from @PratibhaOrigin:

• A general query - For few fields , its suggested in this paper that it is determined by the retailer offering the plan how to populate this field.
  As you are aware, retailers already share their generic available plans and few restricted plans (specific eligibility criteria based) with Energy Made Easy (EME) and Victoria Energy Compare (VEC) as per specific formats.
  There are data standards and manuals for these comparison websites.
  Question: We want to confirm that there will be no change to the data that retailers provide EME or VEC and it will be up to the ADR EME to interpret and respond with the details as per the generic tariff APIs? We assume that the CDR APIs will not impact the current format on how retailers share the data with EME and VEC. .If there is to be a change or an updated format , we would like to review these.

The CDR regime is not creating any requirement for either VEC or EME to change the data they are collecting from Retailers. The CDR regime also does not prevent them from making any changes. The processes covering the changes to data provided to both EME and VEC is separate to the CDR regime.

A couple of points regarding specific fields in this paper –

1. Postcodes – Origin concurs with EME’s feedback on postcodes as mentioned below –

The includedPostcodes and excludedPostcodes fields are removed and replaced with a single postcodes field to represent the postcodes for which a plan is available. This explicit approach places the responsibility of determining geographical availability on the data holder rather than all recipients, and we believe will simplify plan-postcode query logic.

Noted

1. Can the postcode be added as a request parameter in the generic tariff APIs? That is, if an ADR requests plan details, it will be specific to one postcode. This will remove some of the API complications on how to present the data for multiple postcodes , DB patches , few charges are specific to DBs and not a fixed.

This is a good consideration but will not be included without clear feedback from potential recipients that it will be of use do to the build impost on the data holder. We will actively seek feedback from recipients as to whether this will be useful.

Also, Iin terms of use case, we see that the ADR will be requesting this data to compare the plans available for a customer at a specific site (postcode). Therefore, there should not be a need to include multiple postcodes.

This logic does not hold for all situations. There are scenarios where the client will obtain this data to feed decision making systems on the recipient side. In these cases the full list of geographical applicability is needed.

We would like the DSB’s views on the above.
2. SupplyAreaID – This field is used in the EME plan data model for their purposes. There is no proper decision on how to populate this field and we recommend that this field be excluded. This is also given that the generic tariff structures may transfer over to the tailored tariff structure and is not a term we use.

This will be responded to in a later, more specific comment.

3. meteringCharges - Is this field GST exclusive or inclusive? There is no set standard for setting the fees / charges/ discounts – some are represented on a GST inclusive basis and others are on a GST exclusive basis. We support one standard for the presentation of offers (charges/fees/discounts) in relation to GST.

This will be responded to in a later, more specific comment.

4. Eligibility Type – It should be noted that not all eligibility criteria are included here. Retailers may have eligibility criteria that are only relevant to certain plans or certain groups of customers. These criteria could be based on employee status or credit history. We would represent these in the “OTHER” field

This will be added

5. We note that the paper makes reference to business customers and whether the fields are flexible to include C&I customers in the future if they were deemed to be in scope. Some further feedback from a C&I perspective -
   • C&I customers do not have a set "plan list" that is offered in the market as each contract is unique based on the customer's preferences and usage patterns;
   • "metering charges" for C&I customers can have varying unit of measures such as $/meter, $/days etc. Should these be specified in the payload? C&I customers can also have their own independent metering contracts with other metering participants and so the charges can vary accordingly or there be no charges included on a bill as they are charged separately;
   • Some fee types such as disconnection / reconnection etc. are applicable but may not have a fixed rate. These fees are directly passed through from the Network. It will not be possible to indicate the amount/rate in these instances. Should these be excluded for C&I customers?
   • "daily supply charges" are not applicable for all C&I customers. This field is currently mandatory in the payload and would not be relevant to C&I customers;
   • Energy rates are not always fixed/agreed to for a contract. For some types of contracts, these are determined dynamically and so the usage rates cannot be made available within the tariff Period block;
   • A single tariff period can have charges that are single rate and time of use rate, in these cases, will we need to have 2 blocks with the same start and end date, but one displaying single rate information and the other displaying TOU information?
   • Demand charges are assumed to be calculated on a $/kwh basis within the payload. For C&I customers, these can also be calculated on $/kVA basis;
   • There are other variable pass through charges that the customer pays for based on their network tariff as well as based on AEMO's annual market fee structure (some of these are usage based while some are $/day), the rates for these are not fixed.

We will aim to provide more feedback on the above for C&I customers as part of reviewing the detailed tariff payloads within the Account Detail DP.

This will be responded to in the response to #197

[CDR-API-Stream]

In relation to the discussion of additional information for fees, it would appear that a good outcome has been determined by the community without the need for a change to the standards

[CDR-API-Stream]

In relation to the concept of contingent plans, the suggestion from AER will be adopted. A CONTINGENT_PLAN enum value will be added to list of constraint types

[CDR-API-Stream]

In relation to feedback on the gas contract.

It has been suggested that a separate object should be created for gas vs energy contracts as some objects are not valid for gas contracts. This has come up in the past for pricing structures (lending vs deposit products in banking for instance).
The DSB pattern in the past has been to maintain a consistent structure as this simplifies implementation for data holders and data recipients. A single library can be created to marshal both contract types simplifying build.

To address the fact that some specific structures are electricity specific we will mark these objects as conditional (if they were mandatory) and optional otherwise. A comment is also added to the description indicating applicability.

Specifically, based on feedback, the solarFeedInTariff, greenPowerCharges and intrinsicGreenPower objects will be made conditional and applicable only to electricity contracts.

[CDR-API-Stream]

In relation to feedback regarding GST, there seems to be a consensus that GST status is field specific. Field descriptions will be updated according to the table provided by EME in #190 (comment).

[CDR-API-Stream]

In relation to the feedback on the solarFeedInTariffs object. The proposed structure by EME appears to incorporate the feedback will accommodate the changes requested by VEC. This structure will be incorporated.

[CDR-API-Stream]

Based on lack of support a flag indicating green power will not be included.

[CDR-API-Stream]

Based on feedback from EME the thirdPartyAgentId and thirdPartyAgentName fields will be removed.

[CDR-API-Stream]

In relation to feedback regarding intrinsic green power. The feedback from EME indicating that this could be incorporated into the green power charges structure is noted. After examining that incorporation in detail it appears that the conditionality of the sub fields would be much more complicated. Considering that intrinsic and extrinsic green power can simultaneously exist on a plan the current proposal would appear to be the clearest structure.

The proposed scheme field will be added to the green power charges object.

[CDR-API-Stream]

in relation to the feedback on geography - after examination of the responses the DSB has the following comments:

• The feedback that having supply areas but not definitive taxonomy for them is fair. A recipient would have no reasonable way to interpret these fields
• Having a simple list of included postcodes is advantageous as it would be simple to interpret
• There are hundreds of postcodes in Australia and most plans will cover a wider area. A simple list of included postcodes may end up resulting is sever payload bloat
• As raised by Danny, the plan data should be resilient to postcode additions or changes. This could indicate the need for postcode ranges where a plan has wide availability

As a result the following changes will be made to the schema:

• Remove supply area concept
• Retain included and excluded postcodes
• Extend the definition of an entry in these arrays to include "xxxx-yyyy" as a viable format indicating a postcode range (to reduce payload size)

For example, a plan applying only to Victoria but available across the state could be defined as includedPostcodes: {"3000-3999"}

It should be noted that, while this is an interim position, this could be an area of the standard that will need to change once implementation experience is gained.

[CDR-API-Stream]

In relation to feedback from EME on the demand charges object:

For the tariffPeriod object:

1. The rateBlockUType enumeration field values are rendered as SCREAMING_SNAKE_CASE identifiers.

The 'UType' model is a mechanism in the CDR standards for allowing for union objects that also allows the client to use the value of the UType field to reference the object supplied. The allowed values are therefore the field name that is expected to be present.

2. The startDate field is Mandatory and not Conditional. The text “Required if there is more than one period” should be removed from the description.

This will be incorporated

3. The endDate field is Mandatory and not Conditional. The text “Required if there is more than one period” should be removed from the description.

This will be incorporated

For the demandCharges object:

1. The amount field is Mandatory and not Conditional.

This will be incorporated

2. The days field is Mandatory and not Optional. This will ensure clarity for recipients.

This will be incorporated

3. The minDemand field description should read,
“Minimum demand for this demand tariff in kW. If absent then 0 is assumed.”
   The EME team seeks clarity on what this field is describing, i.e. minimum chargeable or minimum measurable, or something else.
4. The maxDemand field description should read,
“Maximum demand for this demand tariff in kW. If present, must be higher than the value of the minDemand field.”
   The EME team seeks clarity on what this field is describing, i.e. maximum chargeable or maximum measurable, or something else.

The change will be incorporated. The expectation of these fields is that demand below or above these thresholds would not result in a charge under this particular charge record. This allows for different tiers of charging to be explicitly represented.

5. The measurementPeriod enumeration field is Mandatory and not Optional. The SEASON value should be renamed as TARIFF_PERIOD to indicate that the measurement period relates to the start and end dates of the tariff period.
6. The chargePeriod enumeration field is Mandatory and not Optional. The SEASON value should be renamed as TARIFF_PERIOD to indicate that the charge period relates to the start and end dates of the tariff period.

These change will be incorporated

[CDR-API-Stream]

Please find attached the final decision of the Chair:
Decision 190 - Candidate Generic Tariff End Points.pdf