Decision Proposal 173 - Energy Draft Feedback Cycle 2

[CDR-API-Stream]

This consultation thread has been raised to allow for holistic feedback to be provided on the draft energy standards as a whole. It is a continuation of the previous holistic consultation.

The draft energy standards (which are draft only and non-binding) can be found on the standards site at:
https://consumerdatastandardsaustralia.github.io/standards/draft/energy-draft.html

Feedback is now open on any issue related to draft. This thread will remain open until April 15th 2021. At that time proposed changes will be incorporated and a second consultation cycle will commence.

[EnergyAustraliaCDR]

Please see below the feedback from EnergyAustralia.

We would like further clarifications for a few of the questions that we had raised previously.

Accounts:

EnergyAustralia question: solarFeedInTariff – this structure does not seem to support split of kWh on $X for y kWh; and $Y for z kWh) i.e. different charges for different levels of kWH.

DSB Response: This field is an array with the intent that each entry defines the upper bound for the tariff

Please further clarify the below:
Array solarFeedInTariff contains type (“government” or “retailer”), amount (The tariff amount per kWh) and description. Unclear how this construct can have multiple entries for blocks unless description is ‘misused’ for this. Other arrays for example rates under timeOfUseRates consist of unitPrice and volume.

NMI standing data

EnergyAustralia question: Should there be fields to reflect nextScheduledReadDate, lastReadDate and lastReadQuality?

DSB Response: These are not available in the AEMO NMI data set

Please further clarify the below:
Can the last 2 fields be added to the NMI Standing Data for Reducing Customer Switching Times as they are significant to indicate Customer Transfer?
In MSATS the lastReadDate and lastReadQuality will be added later this year to support Reducing Customer Switching Times as they are of significance to determine the day the Customer can be transferred across.

For this consultation, we have the following new questions:

Billing: Get Billing for account

Do we agree that Billing data is default for 12 months, while Invoice data is default for 24 months? This timeframe should be consistent and aligned with what the ACCC decides.

Get Generic Plans and Get Generic Plan detail
We are keen to discuss with Vic Energy Compare and EME how bundled products are currently reflected in their data fields. We wish to ensure that no frills energy plans can be distinguished from energy plans which are value added. e.g. a product which may bundle the price of the solar PV system with the energy tariff, and subscription type plans similar to mobile plans.

[jonmilne]

Hi @EnergyAustraliaCDR

In relation to this comment:

Get Generic Plans and Get Generic Plan detail
We are keen to discuss with Vic Energy Compare and EME how bundled products are currently reflected in their data fields. We wish to ensure that no frills energy plans can be distinguished from energy plans which are value added. e.g. a product which may bundle the price of the solar PV system with the energy tariff, and subscription type plans similar to mobile plans.

Subscription type plans are currently supported in EME. These are currently distinguished by a value of QUOTA for electricityContract:pricingModel. In EME, most existing data fields are applicable to this pricing model, though it does change the interpretation of unitPrice/volume for the plan rates. For example, the volume will be reflective of the included usage allowance for the corresponding fixed unitPrice i.e. $X for up to y kWh per period, $Y for next z kWh per period and so on. This treatment is based on how these products typically operate today, for those retailers that offer them (or have done so in the past). Should additional flexibility be required in EME, we would need to discuss any specific retailer requirements.

EME does not currently support bundled products in the way that you describe, though there are a few ways in which it is possible for retailers to define value-added plan/contract inclusions, that may comprise other recurring plan/contract costs in addition to the energy tariff and supply charge.

[PratibhaOrigin]

Thank you for providing us the opportunity to provide feedback on the energy standards.

We would also like to thank DSB for the acknowledgement and response to most of the queries raised by Origin in the previous submission of DP-149.

Generic tariff data

Regarding most of Origin’s concerns/feedback raised around the generic tariff data, DSB was going to consult with EME. Origin would appreciate any inputs/clarifications/updates on the requested items from previous submission – DP-149.

One of the feedbacks provided by Origin previously was –

Origin - Neither of the two Generic Plan APIs are suited for C&I because we don’t have pre-determined plans for large business organisations. They vary based on businesses' priorities and go through negotiation. Further to this, a customer's contract is made up of multiple plans covering retail charges, metering charges, environmental charges etc. and so a full accurate picture of applicable rates cannot be made available without knowing the customer's usage, metering information and other requirements.

DSB’s response was – “As this structure is a reflection of the data held by Energy Made Easy (EME) it is difficult for the DSB to incorporate this feedback as it will not be reflective of the data held by EME.As a result, the suggested changes will be noted but not actioned until comment from EME can be obtained.

Origin would appreciate any feedback from EME whether C&I products will be excluded from the generic tariff data. It is not currently a requirement and we do not expect this to change. We believe that it would be difficult to include C&I tariffs and conditions given the bespoke nature of pricing and contract arrangements. For example, how would spot price data be captured as it is a dynamic pricing arrangement? The negotiable data (which covers the majority of a customer's contract) cannot be excluded as it really is the differentiating factor and looking at tariffs from a comparison point of view would make sense if the negotiable data were included. Another consideration is spot price tariffs that could change dynamically.

Also, the API should be robust enough to handle new tariff structures being brought in by the regulatory changes (including 5MS).

Get Generic Plan Detail

As requested in previous submission DP-149, Origin still requests more clarification on the "pricingModel": around the different pricing models within the pricingModel attribute, specifically around FLEXIBLE and QUOTA pricing models

DP-149 feedback –

Eligibility - How will information for plans available to specific set of customers be catered for? Like only e-bill, online, concession customers.

DSB’s response - This feedback will be provided to EME. In the interim the expectation is that availability would be set to RESTRICTED and the detail of the eligibility would be described via the eligibilityUri.

Origin’s feedback – Eligibility and restricted plans are 2 different things. We have eligibility criteria under general available plans like a plan available for concession customers in NSW. These are visible to all but not everyone can sign up to that.

However, there are specific plans (i.e. certain offers only available to hardship customers or employee offers or retention) which we provide to EME and VCE as “Restricted” plans which are not visible to anyone except Origin.

We seek feedback on the treatment of restricted plans. We support consistency with energy regulatory requirements – that is, only “generally available” plans are disclosed to the market.

3. DP-149 feedback –

Account number - Information such as accountNumber are tokenized in our systems, so there is no means by which we can provide it.

DSB’s response - While credit card numbers are frequently tokenised, BSB and Account Number often are not. Are BSB and Account Number also being tokenised, or just Account Number? If so, a modification to communicate this can be made.

Just wanted to confirm – Yes, we have BSB and Account number tokenised in our system for retail customers. So, keeping it optional will be Origin’s preference.

Get Service Points and Get Service Point Detail – Origin had provided few comments in DP-149 for these 2 API’s which were not addressed in DSB’s response.

Get Account Detail

1. From C&I - Demand calculation methodology is not specified within the demand charges. For example, rolling demand, average, highest value etc.

Origin wants to highlight that it is difficult to provide any recommendations here on how to solve this specifically for a C&I customer as this is complicated data to provide in an API (due to the unbundled nature) and will require the structure of the API to change significantly to bring in the underlying data used for various demand calculation methodologies. This may also not serve any purpose to mass market customers.

We also need to rely on other parties such as Distributors to provide certain information (for instance with ratcheting demand).

2. Conditions around roll in / roll out of sites are not specified- This is applicable for multi-site accounts and the current APIs do not cater to multi-site contracts.

3. DP-149 feedback –

Fee - With the disconnection/connection charges, the value can vary based on how the connection/disconnection was done - remote vs. manual. How does the payload cater for this?

DSB’s response - An indicative fee, or base fee should be supplied with the potential variability included in the description.

Based on DSB’s suggestion, we wanted to confirm that we will be providing the standard connection fee in that case (which is usually the higher value, in case of variable charges).

4. DP-149 feedback –

Discount category - What are the possible values for this. DP 115 had options - Must be one of:

PAY_ON_TIME

DIRECT_DEBIT

However, there are other possible values like dual-fuel, e-bill etc. Do we need another value ‘Other’ to handle such conditional discounts?

DSB’s response - If a list of additional values are suggested they can be added. In these situations the DSB is open to adding an OTHER value but only if a definitive and specific list is developed and shown to be inadequate for all situations.

Origin would suggest adding a 3rd value – “Guaranteed Discount”. This is something available with the plan details currently being provided to EME and VCE as well. Other scenarios mentioned earlier like dual fuel, e-bill etc will also be covered as “Guaranteed Discount’ if the eligibility is met.

5. Environmental and regulatory charges are not specified – DSB’s suggestion was to include this in the metering charges or fees with appropriate descriptions.

Origin wanted to highlight the concern here that customer contracts for C&I have an unbundled format which is different to the defined (bundled) structure for mass market customers. Combining environmental, regulatory and other charges with metering charges will be complicated as metering charges themselves have multiple components (supply charge, DMA / SLA charge etc.)

We also offer Flexible prices where the rates could change continually. This data will be complicated to provide.

6. A consideration to the development of the API is that the AEMC has recently released a final Determination on bill contents and billing requirements requiring the AER to develop a Bills Guidelines. This would replace the currently billing requirements in the Energy Retail Rules. The API will need to be flexible to adapt to any further changes from the development of this Guideline.

7. The fee attribute is not setup for C&I customers as some of the listed fees are applicable to customers but are not specified on the plan / contract. There are also other fees that are not specified on the list such as Break/termination fee (where the customer decides to terminate the contract before the agreed contract end date), we also have different credit card fees applicable based on the amount and card type.

Origin wants to raise the concern again that it is difficult to recommend anything on how to incorporate this specifically for a C&I customer as the API structure does not support multiple fee types that could change variably based on other factors / attributes

Get Balance For Account

Account balances for C&I customers and collective accounts could sit at the parent level or child level. Contracted level account vs. site level account. How do we deal with complex hierarchies and also providing the true account balance to the customer? How will this API structure support the parent-child relationship in accounts and balances?

Origin wants to raise the concern again that it is difficult to recommend anything on how to incorporate this specifically for a C&I customer. One of the options could be to always provide the site level balance (which may not reflect the true balance)

An additional thing to consider is that multiple people could be responsible for managing a single large customer's account with varying levels of access i.e., one could be responsible for usage enquiries, another for billing enquiries etc.

2. DP -149 feedback –

Which type of charges constitute as usage? - Is it any energy which is charged based c/kwh or c/kVA or c/Day or c/Month ? More clarification around calculating electricityTotalUsageCharges is needed for the GET INVOICES API. We have variety of charges for a typical C&I customer like -

· Energy Charges → c/kWh

· Network Charges → $/kVA, $/Day, c/kWh

· Regulated Charges (AEMO) → c/kWh, c/kWh, c/Day

· Metering & Service Charges → $/Meter, $/Day, c/Meter

DSB’s response was - This is expected to be managed by the data holder. The content of the invoice payload should align to what is already presented on physical invoices.

Origin wants to highlight that the C&I invoice breaks down the usage component for different charges and they may be calculated as either $/day, c/kWh, $kVA etc. Is the recommendation to aggregate these C&I charges and display as total usage charge?

Different invoices could have different line items based on the customer's agreement which could be specific based on their location / contracted load / priorities, therefore usage is not looked at in isolation for C&I invoices.

3. DP- 149 query –

Origin feedback - How will cancel/rebill invoices be handled ?

DSB’s response was - The API is expected to provide a point in time response. Cancelled and re-issued invoices should be presented in their correct form at the time the API is called.

Origin wanted to highlight C&I invoices where - we could be rebilled for a partial period of an existing bill and the replacement bill may not have the correct dates as the original bill. So, in this instance, if we were to provide a bill for a given period, it would cover two bills (one partially correct and the other fully correct).

4. Where should we include any sundry charges (such as account set setup for gas infrastructure) and Instalment Agreements (where the customer can pay off an asset over a period of time)?

5. Adjustments - For C&I we issue standalone adjustment invoices containing multiple adjustment transactions, how will this be catered? Also bearing in mind that this could change based on customer preference. Some customers prefer a rebill of the entire period whereas some prefer an adjustment invoice.

6. Overall, these APIs seem more tailored to mass market bundled charges. Has the un-bundled charging model of the large commercial and industrial customers been considered for these payloads?

Invoices for large customers include a list of un-bundled charges calculated using a combination of $/kwh, c/kwh, $/day, $/kva, $/month etc and charge types can vary from one customer to another.

For more details on what a C&I bill looks like for Elec and Gas (including consolidated) please refer this link that's available on the Origin website https://www.originenergy.com.au/business/commercial-and-industrial/market-events-charges/understanding-your-bill.html

[ghost]

On behalf of AGL Energy CDR technical working group

Previously we have asked for clarification on the following and didn't receive feedback:

Decision Proposal 115 - Tailored Tariff Data Payloads

electricityContract > pricingModel

Given AGL's electricity contract (account level) can be linked to multiple meters, and each meter potentially subject to different pricing model; it's unclear how electricityContract is associated with a single pricingModel enum.

electricityContract > isFixed

Contracts can be fixed temporarily, fixed for amount of time then variable. We don't see how that can be expressed.

electricityContract > fee > amount

Some fees have unknown amounts at time of contract or mentioned as a range. For example pass-on fees where fee is subject to a different vendor. i.e installation of a meter required.

electricityContract > fee > term

Should we consider adding Weekly and Daily to terms enum. For example AGL carbon neutral plan fee is $1 a week for residential customers.

electricityContract > fee > type

Should fee type enum be extended to include types like device purchase plans i.e. Google Home or Amazon Alexa or carbon neutral plans.

Decision Proposal 111 - Generic Tariff Data Payloads

It is common practice to have plans that are not generally available to the public. Given that /energy/plans is a public endpoint and allow passing available field to RESTRICTED, what does that mean to us?

For percentOfBill discount, we want to confirm that the expectation is that percentage is calculated from supply and usage charges.

Should meterTypes be array of Enum instead of String.

Is there is specific expected format for description fields i.e. plain text, html, markdown etc?

Decision Proposal 116 - Billing Data Payloads

Invoice Common Type

We need more clarification or examples on how retailers can represent historical adjustments into an invoice.

Given we have accounts where both electricity and non-electricity services are items in the same invoice; what's the expected behavior of properties like amountDue, totalAccountCharges, totalAccountDiscounts which sets outside of electricity object? should these represent only electricity ? or energy i.e. electricity and gas or any product regardless of its industry? noting that its quite hard to change these properties to only represent electricity if that's the intention.

isPaid: With AGL providing budget planning features and payment plans to customers, we are thinking that a basic isPaid = false, might not be enough for ADRs to present relevant value to customers.

servicePoints: Given this is a mandatory array of strings, we are assuming this can be an empty array. i.e. an invoice issued for an account where all charges are not related to any service point. Please confirm.

---

Previously we have asked for the following changes in standards and we don't see these being modified in draft:

Decision Proposal 115 - Tailored Tariff Data Payloads

electricityContract > discount > category

Requesting adding new items to enum: Loyalty (discount for loyal customers) and Multi-Product (discount for customers opting-in to multiple products)

electricityContract > fee > amount

Notion of inclusive/exclusive of GST is missing here.

Decision Proposal 116 - Billing Data Payloads

Billing Transaction Common Type

timeOfUseType: We recommend this enum to have "Other" value to support retailer custom types if it exists in future.

---

Thanks for the feedback provided to our comments on Decision Proposal 114 - Account Payloads and incorporating our suggestions regarding concession data.

[CDR-API-Stream]

Energy 2

In response to EnergyAustralia:

EnergyAustralia question: solarFeedInTariff – this structure does not seem to support split of kWh on $X for y kWh; and $Y for z kWh) i.e. different charges for different levels of kWH.
DSB Response: This field is an array with the intent that each entry defines the upper bound for the tariff

Please further clarify the below:
Array solarFeedInTariff contains type (“government” or “retailer”), amount (The tariff amount per kWh) and description. Unclear how this construct can have multiple entries for blocks unless description is ‘misused’ for this. Other arrays for example rates under timeOfUseRates consist of unitPrice and volume.

Apologies, I think I was looking at the wrong schema object when I responded in the last cycle. This is valid feedback. As EME has indicated there is a willingness to extend the schema but the DSB can't arbitrarily factor in these changes. We will take this one on notice for further discussion.

NMI standing data

EnergyAustralia question: Should there be fields to reflect nextScheduledReadDate, lastReadDate and lastReadQuality?
DSB Response: These are not available in the AEMO NMI data set

Please further clarify the below:
Can the last 2 fields be added to the NMI Standing Data for Reducing Customer Switching Times as they are significant to indicate Customer Transfer?
In MSATS the lastReadDate and lastReadQuality will be added later this year to support Reducing Customer Switching Times as they are of significance to determine the day the Customer can be transferred across.

These can be added to the schema. I will contact AEMO to understand the field types.

Billing: Get Billing for account

Do we agree that Billing data is default for 12 months, while Invoice data is default for 24 months? This timeframe should be consistent and aligned with what the ACCC decides.

The extent of data is usually limited by legislation and rules. For the first sector time extent for financial transactions was required back to 1st January 2017. I would expect that limiting these data sets to 12 months and 24 months would be unlikely to align to the intent of the regime and longer periods should be assumed.

Get Generic Plans and Get Generic Plan detail
We are keen to discuss with Vic Energy Compare and EME how bundled products are currently reflected in their data fields. We wish to ensure that no frills energy plans can be distinguished from energy plans which are value added. e.g. a product which may bundle the price of the solar PV system with the energy tariff, and subscription type plans similar to mobile plans.

It is noted that EME has helpfully responded on this topic.

[CDR-API-Stream]

In response to queries from Origin:

First off, there was a significant number of feedback items relating to C&I customers. Rather than respond to these individually it would appear that the APIs are not sufficient for larger customers and a dedicated consultation on this topic is warranted. This will be scheduled and will be based on the feedback provided to date.

Other responses are below…

Regarding most of Origin’s concerns/feedback raised around the generic tariff data, DSB was going to consult with EME. Origin would appreciate any inputs/clarifications/updates on the requested items from previous submission – DP-149.

This is still in progress so the items that have not yet been responded should not be interpreted as ignored.

Origin would appreciate any feedback from EME whether C&I products will be excluded from the generic tariff data. It is not currently a requirement and we do not expect this to change. We believe that it would be difficult to include C&I tariffs and conditions given the bespoke nature of pricing and contract arrangements. For example, how would spot price data be captured as it is a dynamic pricing arrangement? The negotiable data (which covers the majority of a customer's contract) cannot be excluded as it really is the differentiating factor and looking at tariffs from a comparison point of view would make sense if the negotiable data were included. Another consideration is spot price tariffs that could change dynamically.

The inclusion of tariff data for C&I customers is not driven by EME or the DSB. It is driven by the designation instrument and clarified by the rules. Currently a plain reading of the designation instrument would indicate these plans should be included and that is the assumption the DSB is working towards. It is noted that representing highly tailored plans will be difficult in a structured data payload. The equivalent challenge was dealt with in the first sector by the inclusion of flags indicating that a high degree of negotiation is expected.

Also, the API should be robust enough to handle new tariff structures being brought in by the regulatory changes (including 5MS).

Feedback on how this could be achieved in the next cycle would be welcome.

We seek feedback on the treatment of restricted plans. We support consistency with energy regulatory requirements – that is, only “generally available” plans are disclosed to the market.

We will add this to the list of tariff issues to resolve.

Account number - Information such as accountNumber are tokenized in our systems, so there is no means by which we can provide it.
DSB’s response - While credit card numbers are frequently tokenised, BSB and Account Number often are not. Are BSB and Account Number also being tokenised, or just Account Number? If so, a modification to communicate this can be made.

Just wanted to confirm – Yes, we have BSB and Account number tokenised in our system for retail customers. So, keeping it optional will be Origin’s preference.

The schema will be updated to allow for the communication of tokenised instruments.

Get Service Points and Get Service Point Detail – Origin had provided few comments in DP-149 for these 2 API’s which were not addressed in DSB’s response.

Apologies for this omission please let us know which questions were missed.

Discount category - What are the possible values for this. DP 115 had options - Must be one of:
PAY_ON_TIME
DIRECT_DEBIT
However, there are other possible values like dual-fuel, e-bill etc. Do we need another value ‘Other’ to handle such conditional discounts?
DSB’s response - If a list of additional values are suggested they can be added. In these situations the DSB is open to adding an OTHER value but only if a definitive and specific list is developed and shown to be inadequate for all situations.

Origin would suggest adding a 3rd value – “Guaranteed Discount”. This is something available with the plan details currently being provided to EME and VCE as well. Other scenarios mentioned earlier like dual fuel, e-bill etc will also be covered as “Guaranteed Discount’ if the eligibility is met.

GUARANTEED_DISCOUNT will be added as an option.

1. A consideration to the development of the API is that the AEMC has recently released a final Determination on bill contents and billing requirements requiring the AER to develop a Bills Guidelines. This would replace the currently billing requirements in the Energy Retail Rules. The API will need to be flexible to adapt to any further changes from the development of this Guideline.

Alternatively, the AER could develop this standard in parallel to these endpoints so that both standards are aligned. This would be preferred as the CDR will be a distribution channel for bills under the current designation.

Which type of charges constitute as usage? - Is it any energy which is charged based c/kwh or c/kVA or c/Day or c/Month ? More clarification around calculating electricityTotalUsageCharges is needed for the GET INVOICES API. We have variety of charges for a typical C&I customer like -
· Energy Charges → c/kWh
· Network Charges → $/kVA, $/Day, c/kWh
· Regulated Charges (AEMO) → c/kWh, c/kWh, c/Day
· Metering & Service Charges → $/Meter, $/Day, c/Meter
DSB’s response was - This is expected to be managed by the data holder. The content of the invoice payload should align to what is already presented on physical invoices.

Origin wants to highlight that the C&I invoice breaks down the usage component for different charges and they may be calculated as either $/day, c/kWh, $kVA etc. Is the recommendation to aggregate these C&I charges and display as total usage charge?

In the invoice endpoints, yes. In the transaction endpoints these may be separate, individual records.

Different invoices could have different line items based on the customer's agreement which could be specific based on their location / contracted load / priorities, therefore usage is not looked at in isolation for C&I invoices.

In general, the invoice payload is aggregated deliberately to avoid the sharing of too much detail (ie. it allows for a less granular view of a customer’s activity) with the transaction endpoints allowing for more detail if needed. For C&I customers the more granular endpoints would still be available.

1. Where should we include any sundry charges (such as account set setup for gas infrastructure) and Instalment Agreements (where the customer can pay off an asset over a period of time)?

The totalAccountCharges is expected to be used for account level charges. If these charges are more appropriately considered to be associated with a gas or electricity plan then the totalOnceOffCharges field could be used.

[CDR-API-Stream]

In response to queries from AGL:

Decision Proposal 115 - Tailored Tariff Data Payloads

electricityContract > pricingModel

Given AGL's electricity contract (account level) can be linked to multiple meters, and each meter potentially subject to different pricing model; it's unclear how electricityContract is associated with a single pricingModel enum.

This is very important and fundamental feedback and goes back to questions asked in earlier consultations. Previously it was communicated that a single plan per account would suffice but this feedback would indicate otherwise. Before making this change it would be appropriate to get some additional clarification from other Retailers.

A separate consultation on this topic will be initiated.

electricityContract > isFixed

Contracts can be fixed temporarily, fixed for amount of time then variable. We don't see how that can be expressed.

This will be added to the list of issues to be dealt with in the Tariff structure.

electricityContract > fee > amount

Some fees have unknown amounts at time of contract or mentioned as a range. For example pass-on fees where fee is subject to a different vendor. i.e installation of a meter required.

This was responded to in the previous consultation in response to a question from Origin. The specific response to that question was An indicative fee, or base fee should be supplied with the potential variability included in the description.

electricityContract > fee > term

Should we consider adding Weekly and Daily to terms enum. For example AGL carbon neutral plan fee is $1 a week for residential customers.

These will be added to the structure

electricityContract > fee > type

Should fee type enum be extended to include types like device purchase plans i.e. Google Home or Amazon Alexa or carbon neutral plans.

If a set of enum values can be suggested they can be included. Being too specific is not recommended, however, as it means the schema is too volatile. For instance a preferred value might be ADDITIONAL_SERVICE with a free form text field used to indicate that the service is Google Home to Amazon Alexa.

It is common practice to have plans that are not generally available to the public. Given that /energy/plans is a public endpoint and allow passing available field to RESTRICTED, what does that mean to us?

It is understood that RESTRICTED doesn’t necessarily mean that the plan is not available to the public, only that it is restricted in eligibility. Feedback from other retailers has indicated this.

The intent of CDR is that the generic tariff endpoints only expose plans that can actually be originated. Plans that cannot be originated would therefore need to be filtered from the public responses.

For percentOfBill discount, we want to confirm that the expectation is that percentage is calculated from supply and usage charges.

The understanding should be according to the current usage of information provided to EME.

Should meterTypes be array of Enum instead of String.

More restricted types are preferred. Is there a sufficient enum value list that will suffice?

Is there is specific expected format for description fields i.e. plain text, html, markdown etc?

Free form text fields should be plain text.

Decision Proposal 116 - Billing Data Payloads

Invoice Common Type

We need more clarification or examples on how retailers can represent historical adjustments into an invoice.

It is difficult to provide arbitrary clarification. Could you articulate some scenarios where clarification is required and these can be worked through.

Given we have accounts where both electricity and non-electricity services are items in the same invoice; what's the expected behavior of properties like amountDue, totalAccountCharges, totalAccountDiscounts which sets outside of electricity object? should these represent only electricity ? or energy i.e. electricity and gas or any product regardless of its industry? noting that its quite hard to change these properties to only represent electricity if that's the intention.

That is not the intention. There are once off aggregate fields at both the fuel type layer (ie. for energy and gas) and at the account level.

The account level fields should include charges that are not fuel related and the ones at the fuel level should include charges that are fuel related.

isPaid: With AGL providing budget planning features and payment plans to customers, we are thinking that a basic isPaid = false, might not be enough for ADRs to present relevant value to customers.

This feedback isn’t clear. I’m not sure what the underlying issue is.

servicePoints: Given this is a mandatory array of strings, we are assuming this can be an empty array. i.e. an invoice issued for an account where all charges are not related to any service point. Please confirm.

Yes.

Previously we have asked for the following changes in standards and we don't see these being modified in draft:

Decision Proposal 115 - Tailored Tariff Data Payloads

electricityContract > discount > category

Requesting adding new items to enum: Loyalty (discount for loyal customers) and Multi-Product (discount for customers opting-in to multiple products)

This change was not made as the structure of tariffs is tied to the EME data structure. Adding fields to the tariff schema without commitment to change implementation by EME is not useful. This was previously stated in feedback.

electricityContract > fee > amount

Notion of inclusive/exclusive of GST is missing here.

Interpretation of this field should be according to the existing interpretation when Retailers are providing tariff data to EME.

Decision Proposal 116 - Billing Data Payloads

Billing Transaction Common Type

timeOfUseType: We recommend this enum to have "Other" value to support retailer custom types if it exists in future.

This change was not made as the structure of tariffs is tied to the EME data structure. Adding fields to the tariff schema without commitment to change implementation by EME is not useful. This was previously stated in feedback.

[CDR-API-Stream]

There is a lot of specific comments provided in the responses above but much of it is aligned with some common themes. Due to this it would appear appropriate to give some general feedback on some overarching themes.

1. Tariff schemas are heavily tied to the EME and VEC implementations due to the designation instrument. This means that requests to change these schemas cannot be trivially adopted. A process of working through these schemas with the EME and VEC needs to be undertaken.
2. Based on the feedback the complexity of C&I customers is not accommodated well in the current payload structures. A specific consultation on this topic will be undertaken to seek to address this gap.
3. A conversation with the AER about billing and invoicing standards needs to be started to ensure the new invoicing standards are aligned to the CDR technical standards

The following specific changes will be made to the standards

• Extra fields that are being added to MSATS will be added to the schema after AEMO is consulted (specifically, nextScheduledReadDate, lastReadDate and lastReadQuality)
• Support for instrument tokenisation will be added to the billing structure
• Add GUARANTEED_DISCOUNT as an enum value to the category field in the discount object (noting that this still needs to be confirmed with EME before it can be used)
• WEEKLY and DAILY to be added as enum values for the term field (noting that this still needs to be confirmed with EME before it can be used)

[CDR-API-Stream]

After discussion with AEMO some more work on the design of the nextScheduledReadDate, lastReadDate and lastReadQuality fields is required so they will not be included in the 1.9.0 release. We will seek to include these changes in the 1.10.0 release.