Closed CDR-API-Stream closed 2 years ago
A proposal for this consultation is under development. It is hoped that it will be posted in the next few days.
I had a review of those standards and I believe these need further considerations:
Thank you for the feedback Danny.
- 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:
- 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.
- 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?
The EME team appreciates the opportunity to provide feedback on this decision proposal.
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.
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.
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.
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
.
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:
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.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.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.
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:
rateBlockUType
enumeration field values are rendered as SCREAMING_SNAKE_CASE identifiers.startDate
field is Mandatory and not Conditional. The text “Required if there is more than one period” should be removed from the description.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:
amount
field is Mandatory and not Conditional.days
field is Mandatory and not Optional. This will ensure clarity for recipients.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.
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.
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.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.
The EME team agrees with the addition of the category
enumeration field, its values, and the eligibility
string field to the incentives
object.
- 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 – 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.
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.
Thank you for the feedback Danny.
- 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
- 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.
- 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
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 - 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 – 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.
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.
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 |
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.
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
- 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
andpremium
.Fees
- 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
andgasContract.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.
- As our GST application is for generic tariffs, will this application closely align with commercial and industrial tariffs, and tailored tariffs?
- 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 thesolarFeedInTariff
object array in thegasContract
object is invalid. We therefore recommend that thesolarFeedInTariff
object array is removed from thegasContract
object.We also recommend that the
greenPowerCharges
object array is removed from thegasContract
object. The term 'GreenPower' relates exclusively to the government accredited renewable energy scheme for electricity, and it is therefore erroneous to include thegreenPowerCharges
object array under thegasContract
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
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 newNO_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 thethirdPartyAgentName
field and the addition of a new business rule stating that theinformation
field of the eligibility object will be populated with the third party agent name when the eligibility type isTHIRD_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:
- The
includedPostcodes
andexcludedPostcodes
fields are removed and replaced with a singlepostcodes
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.- The
supplyAreaId
field is removed. We understand that thesupplyAreaId
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.- The geography object and its property hierarchy is mandatory;
distributor
andstate
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 ademandCharges
value to the tariff period’srateBlockUType
enumeration field.Proposed changes:
tariffPeriod
object:
- The
rateBlockUType
enumeration field values are rendered as SCREAMING_SNAKE_CASE identifiers.- The
startDate
field is Mandatory and not Conditional. The text “Required if there is more than one period” should be removed from the description.- 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:
- The
amount
field is Mandatory and not Conditional.- The
days
field is Mandatory and not Optional. This will ensure clarity for recipients.- 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.
- 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
measurementPeriod
enumeration field is Mandatory and not Optional. TheSEASON
value should be renamed asTARIFF_PERIOD
to indicate that the measurement period relates to the start and end dates of the tariff period.- The
chargePeriod
enumeration field is Mandatory and not Optional. TheSEASON
value should be renamed asTARIFF_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 theeligibility
string field to theincentives
object.Solar
- 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
andpremium
.Fees
- 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
andgasContract.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:
Thanks for the response @DannyDuong
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'
displayName
field.Time Varying Tariffs
timeVaryingTariffs
object.singleTariff
and timeVaryingTariffs
objects are conditional on the value of the tariffType
field.Payer Type
type
was too ambiguous, and open to misinterpretation.type
field has been renamed to payerType
to sharpen its meaning to specifically refer to the entity paying the tariff amount.payerType
value of GOVERNMENT
captures FiT for all government schemes.payerType
value of RETAILER
captures FiT for all retailers.payerType
field is required.Scheme
scheme
field is to enable data holders to capture, codify, and communicate generally (nationally) recognised schemes, programmes, or strategies. For example, Premium FiT.scheme
field is optional. If absent then it is assumed that the tariff is not part of any scheme.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.
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
scheme
field.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?
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.
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?
Thanks for the opportunity to provide feedback on this topic.
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.
Thanks everyone for the feedback. This consultation is now being closed. We will provide a response to feedback shortly.
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.
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.
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 –
- 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
- 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.
- 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.
- 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.
- 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
- 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
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
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
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.
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 https://github.com/ConsumerDataStandardsAustralia/standards/issues/190#issuecomment-922643873.
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.
Based on lack of support a flag indicating green power will not be included.
Based on feedback from EME the thirdPartyAgentId and thirdPartyAgentName fields will be removed.
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.
in relation to the feedback on geography - after examination of the responses the DSB has the following comments:
As a result the following changes will be made to the schema:
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.
In relation to feedback from EME on the demand charges object:
For the tariffPeriod object:
- 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.
- 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
- 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:
- The amount field is Mandatory and not Conditional.
This will be incorporated
- The days field is Mandatory and not Optional. This will ensure clarity for recipients.
This will be incorporated
- 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.
- 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.
- 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.
- 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
Please find attached the final decision of the Chair: Decision 190 - Candidate Generic Tariff End Points.pdf
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.