Decision Proposal 149 - Energy Draft Feedback Cycle 1

[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.

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 February 12th 2021. At that time proposed changes will be incorporated and a second consultation cycle will commence.

[perlboy]

Please publish the redocs source.

[CDR-API-Stream]

@perlboy, the static HTML was generated using the ReDoc CLI. There is no additional source beyond the OAS spec available for download from the draft site.

[perlboy]

@CDR-API-Stream If this is the case then the initial feedback would be to evaluate Redocs properly. create-openapi-repo exists to split an existing spec into more manageable chunks and includes a structure to allow for efficient display of code examples as well as a way of injecting non-openapi markdown during rendering

An example of such a deployment is available at dsb-standards and includes an example of a travis ci build and npm deploy to github.

Fundamentally such an approach would significantly aid implementers to understand the changes made per release far beyond the convoluted release process currently in place while resulting in a DRY approach to the DSB capable of effectively tracking impact of changes across multiple industries.

[JamesMBligh]

Hi Stuart, this is a really fertile discussion. As this thread is targeted at the energy payload standards it would be helpful to transfer the discussion to standards-staging. To facilitate this I have created an issue: ConsumerDataStandardsAustralia/standards-staging#7

[perlboy]

This approach is incongruous with the "Noting Paper" on releases which states:

Changes to the standards will be staged in this repository and the issue tracker associated with this repository will be used to manage commentary on the changes only (i.e. management of the work of the DSB and commentary on errors in transcription from the decisions of the Chair). This repository will be not be used for feedback on the standards themselves

By definition the presentation method for implementers is part of the standards.

[commbankoss]

Commonwealth Bank appreciates this holistic consultation on the draft energy standards, and would like to provide the following feedback regarding the suggested format:

• In the Responses sections, each node needs to be expanded individually and there is no option to automatically expand all. This is inefficient and limits the ability to search quickly within the document. An expand all function to Responses, as well as to the sidebar, could make the new format more usable.
• Similarly, the new format can be a bit bulky, and could benefit from collapsible sections (e.g. query parameters, headers sections).
• Overall the new format looks cleaner and has all the swagger files, which are advantages.

We also recommend keeping in mind previously raised in issues, such as those mentioned in issue 315:

• Clear obligation dates for delivery, transitions, deprecation, etc.
• Clear links to current and previous versions of the endpoints and payloads.

[SelenaLiuEA]

Hi all,

EnergyAustralia’s feedback is below.

Generic Tariffs

Get Generic PlanDetail

• meteringCharges is not linked to gasContract and elecContract, would it be helpful to include a fueltype against meteringCharges?
• fuelType: The options are Elec, Gas or Dual. How will gas supplied for hot water services be captured? (noting it is not clear whether it would be captured from a policy perspective)
• gasContract/electricityContract: This is fairly straightforward but we note that most retailers will have many variations of gas and electricity plans, with further variations on pricing. For instance, two different customers could be on the same plan but have different pricing discounts (as additional discounts can be added). We know that this is for generic plan data – but this should be kept in mind for tailored tariff data.
• discounts: We want to note, similar to the above, that some discounts are not linked to the plan. Additional discounts can be applied to a customer’s account (in addition to the standard discounts that apply to the plan). The standards should be able to link in more than one discount to a plan. There is a broader interpretation question (more for tailored tariff data) as to how to calculate the discounts for a given plan. Retailers have already considered this issue under Victoria’s best offer obligations which might be helpful here.
• At EA, solar feed in tariffs are not specifically linked to a plan, rather it is added on. The DSB should consider how to reflect this in our plan information.
• fee: This may be more relevant for billing data, but for some customers fees are removed e.g. fee removal for a hardship customer, how will we reflect this?
• gasContract - contains some fields (solar / controlled load) which are not relevant for gas.
• /energy/plans vs /energy/plans/{planID}: We understand the two level structure reflects that of NMI standing data. However, we question whether some of the information in Get Generic Plan Detail should be replicated and brought up to Get Generic Plans. For example, customerType and geography so that an ADR won’t have to request the data twice (in Get Generic Plans and then again in Get Generic Plan Detail) to obtain these data points. We also note that the geography is in postcodes/supply areas and query if there is value in having whole jurisdictions e.g. NSW, VIC, WA.

Energy Accounts

Get accounts

• authorisedContacts: We understand that authorisedContacts could link back to the concept of secondary users (if adopted for the energy sector). While not directly relevant here, the DSB will likely need to consider the design of standards around family violence risks, at some point.
• accountNumber: was mandatory during initial consultation and now it reads as Optional.
• Name has been rebranded to displayName across the APIs. Is this to align with Banking?

Get Account detail

• /energy/accounts/{id}/payment-schedule – this assumes that there are no other payment types outside of cardDebit and directDebit. What about paypal? Afterpay? And others?
• credit Card Scheme – It is common practice for retailers to not store the card type e.g. mastercard, Visa etc., but to use a token which links to BPOINT which then stores this information. It is unclear if retailers will be able to provide this data.
• creationDate in Get Accounts means the date that the account was created or opened. But in getAccountDetail, openDate is defined with the same meaning. Is this intentional?
• meteringCharges has attribute name not displayName (“Display name of the charge”)
• discount has attribute name not displayName (“Display name of the charge”)
• 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.

Get concessions

• concessions – Some concessions apply to an account, and then after a threshold is reached, the concession is capped and no longer applies. Does the concession for an account reflect a point in time? i.e. it would not appear for an account once the concession has been applied and the cap has been reached.
  Billing

Get Balance for Account

• Will the balance for an account reflect unbilled debits against that account? ie. Fees on an account that have been incurred but not billed to the customer yet.

Get Billing for Account

• usage.timeOfUseType - only supports one type of TOU (Peak Off/peak Shoulder) whereas bills will have multiple.
• usage.usage - Only supports KWH. Should this also reflect other measurements of usage? i.e. kVAr for demand tariffs
  NMI Standing Data
  Get Service Points
• nationalMeteringId – is this intended to be with or without NMIChecksum?

Get Service Point Detail

• meters: For a greenfield NMI, this may not exist. The same comment applies to streams.
• If there is a meter, should readType be required?
• Should there be fields to reflect nextScheduledReadDate, lastReadDate and lastReadQuality?
• Is there any reason why peakDemand1 and peakDemand2 are required ?
• unitOfMeasure - should that be an enumerated list? It may be worth checking with AEMO as to what they have in place.

Electricity Usage

Get Usage For Service Point

• Query parameter - There is no parameter to set the time period limit (like newest-date and oldest-date for Get Invoices For Account). A time period limit seems like a useful parameter to align with time limited consents.
• energy/electricity/servicepoints/{servicePointId}/usage: What is AEMO’s thinking on how to use this construct? Will the register be for a day or some other time period?

Get Bulk Usage

• There is no parameter to set the limit Get Usage For Specific Service Points

Get Usage For Specific Service Points

• There is no parameter to set the limit Get Usage For Specific Service Points

Other feedback

• Page-size param does not specify maximum page size. This is important for 5MS reads for POC type events (2 years at 5 min intervals is circa 210,000 data points)
• Pagination – paging is done by pointing to first record of page, and then how many records beyond to return. This can result in missing data if the records are changing between requests – say for example if another read is added, so you would have records 1-25, then 27-51. A better way is to return unique ids to continue paging off (#26 in this scenario)

Cheers
Selena

[PratibhaOrigin]

Origin Feedback

 Thanks for the opportunity to provide feedback on the overall energy standards.

General call outs

• It was noticed that few concerns and queries raised previously have not been answered or incorporated in the updated API standards. Hence, we have called out few of these again.
• This DP format was not giving clear indication of which fields are mandatory /optional /conditional and hence had to refer previous DPs for that. But, in few cases there was feedback provided earlier to make fields optional. Not sure if that has been incorporated as this DP format doesn’t suggest that.
• This DP format doesn’t help with the definition of the fields and again have to refer all previous DP PDFs for the same. IF its overall DPs energy standards , it should have that field definitions as well in this DP.
• Enumerated values for the fields are not defined here clearly in this DP format.
• Across all APIs, tags are denoted with incorrect data type. Example – Balance as String , date as string.
• With each API , it will be good to call out the data holder for respective the respective data cluster. It has been called out in previous consultation papers. But considering its overall energy standards better to have this information called next to the each API header here will be beneficial.

Generic Tariffs

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

Get Generic Plans

 "thirdPartyAgentName": "string", - What does this field indicate and how is it used?

 Get Generic Plan Detail

• Should this API structure be implemented by all retailers? Or is it only for generic plan and will be implemented by Energy made easy type of services ?
•  "customerType": "RESIDENTIAL", - What is the definition of business? Does any customer with ABN defines ‘business’ or there are any other criteria ?
•  "excludedPostcodes" and "includedPostcodes": and "supplyAreaId": - This depends on tariff in the standing data so providing post code will be difficult. For example if its available across all a DB patch , what’s the expectation ?
•  "distributor": "string" - Few Origin plans could stretch to multiple distributors so not sure how this value will be used for multiple DBs.
•  Eligibility - How will information for plans available to specific set of customers be catered for? Like only e-bill , online , concession customers ?
•  "meteringCharges": - Is this applicable for gas or elec ? Is this expected to be Standing Charges? If so why is it outside the Gas or Elec structure? how will min & max be used? What does period state – is it frequency like monthly, daily etc. ? 
• "additionalFeeInformation": - Need more info on what this relates too? Please provide an example.
•  "pricingModel": More clarification is needed around the different pricing models within the pricingModel attribute, specifically around FLEXIBLE and QUOTA pricing models
•  Green power – We have different green products like green 25%, Green 50% etc. How will the API structure cater for that information.

Get Service Points 

• ServicepointID – Who generates it? AEMO (gateway) and passes on to retailer (data holder) or vice versa ?
• Its not NMI but specific to NMI. How will this work for embedded networks where there is no market NMI for off market sites.
• validFromDate in the response file vs. fromdate in the payload file - which of these is applicable for Get Service Points API?
• Does the creationDateTime field relate to when the record was first created in the system or the market or the customer’s move in date? From a customer’s point of view, the creationDate (within the GET ACCOUNTS API) could be the start date. Is this the date that the account was created in the system or the start date of the customer account / contract at this site because they could be different?
• nationalMeteringId" - Is it including checksum or excluding ?

 Get Service Point Detail

• If read data is not available for a requested date range: is empty "reads" array is returned or no "reads" attribute at all?

Get Accounts

• AccountID generation - Is the dataholder generating it based on the ID permanence rules or AEMO/ gateway? Confirming that the AccountID specific to a specific site or location ?

Get Account Detail

•  Discount - With discounts/conditional discounts in Origin , we have a discount period, discount start etc. fields. Say the plan may be 12 months but discount will be applied after 3 months of contract start and for a period of 6 months. How will the payload cater for this?-
• Amount - We also offer a fixed discount/rebate in few cases – Will that be covered as part of amount field ? Say 50$ credit on your first bill. How will the payload cater for this?
  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 ?
• GST component - The GST inclusive/exclusive component should be clearly defined for the retail, solar and fee/charges as it works slightly differently for each of these. Also, the rounding rules for the same should be specified.
• 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 ?

• From C&I - Demand calculation methodology is not specified within the demand charges. For example, rolling demand, average, highest value etc.
• Conditions around roll in / roll out of sites are not specified
• Environmental and regulatory charges are not specified
• The fee attribute is not setup for C&I customers as the 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 Breakfee (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
• More clarification is needed on the isFixed attribute - does this refer to whether prices are fixed throughout the lifetime of the contract or whether prices can change based on consumption / time bands etc?
• More clarification is needed around the different pricing models within the pricingModel attribute, specifically around FLEXIBLE and QUOTA pricing models

 Get Agreed Payment Schedule

•  Account number - Information such as accountNumber are tokenized in our systems, so there is no means by which we can provide it. Not very clear in this DP if this is mandatory or optional field
• Payment schedule API seem not to be time-bound.So, wanted to confirm only current payment schedule details are to be shared via this API.

Get Concessions

• Concession - We do not share the concession information outside of our validation process with Centrelink unless Services Australia or a State Government has requested. Ques: Has Centrelink/ Services Australia been engaged as a part of this activity? We would not be able to share concession details without the engagement and approval from them. This feedback was provided previously as part of DP-114.But , wanted to confirm the same.
• We feel that the two terms (concession & hardship) have been mixed up, and they indeed mean very different things. Concessions are supported by the government () while hardships are energy specific arrangements. It seems the payload should be limited to concessions only.The treatment of hardship customers is very specific to individual organisation's hardship policy. If hardship customers get govt. grants , in few cases the hardship customers are supported via hardship payment plan where the following API may not be able to accommodate the details and in fact that might come under current payment schedule API. Hence , mixing concession and hardship information should be avoided.
• Is there a reason for different naming of similar fields in response and payload fields ?
  ·       dailyDiscount in the response file vs. perDayDiscount in the payload file - which one are we meant to use for the GET CONCESSIONS API?
  ·       monthlyDiscount in the response file vs. perMonthDiscount in the paylaod file - which one are we meant to use for the GET CONCESSIONS API?
  ·       yearlyDiscount in the response file vs. annualDiscount in the payload file - which one are we meant to use for the GET CONCESSIONS API?

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 ?
• The structure of the API is split into Elec and Gas - would be easier as a consolidated view.

Get Bulk Balances

• Should we also link the NMI/address with the bulk balances?

Get Invoices For Account 

• Need to include Daily/Service Charges (for both Elec and Gas).Where does that sit ?
• Not every NMI has generation credits
• Should include consumption (broken down into total or based on TOU)
• Should include usage x rate (c/kWh) = Amount
• Do we need to include - Ave cost /day, Ave daily usage, same time last year,GGH emissions ,meter id?
• 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 -

1. • Energy Charges → c/kWh
2. • Network Charges → $/kVA, $/Day, c/kWh
3. • Regulated Charges (AEMO) → c/kWh, c/kWh, c/Day
4. • Metering & Service Charges → $/Meter, $/Day, c/Meter

• How will cancel/rebill invoices be handled ?
• Are we including Demand in usage?
• Do we include Service Order Charges in electricitytotalOnceOffCharges?
• isPaid (boolean) defined in the payload file vs. paymentStatus used in the response file  - are they the same fields?
• If Boolean, this is not consistent with the data in the sample response file i.e. “PAID”
• What if the invoice is only partially paid? What would the boolean or enumeration value be?
• For interval sites, it could be possible that reads are partially estimated. What is the expectation in this case within the isEstimate field in the GET BILLING TRANSACTIONS API?

 Get Invoices For Specific Accounts

• See comments against 'Get Invoices for Account'.
• Assuming that TotalUsageCharges includes Other non usage charges (i.e. Supply charge and Greenpower charges, etc however these are not strictly Usage related charges otherwise the sub totals will not add up to the total charges required by this API.
• List of Enumerated values of Time of Use Type not fully defined.
• Also do we really want to specify this value via a Enumerated List of values that would need to be decoded by the subscriber of this service OR should this be a real world value of a Time Period (i.e. 09:00 - 16:00) that can be used intelligently by the systems that consume this data in the future, give that we are moving to a world of all INTERVAL data where this latter form of data can be better used.
• TOU list needs to also include Off Peak DC.

Get Billing For Account

• What is the purpose of the adjustments object within the GET BILLING API? Is this for bill corrections or generic adjustments?
•  For GET BILLING API, non-commodity invoices “may” not be linked to a NMI / Service point - so the servicePointId will need to be optional ?

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

[CDR-API-Stream]

AEMO has provided feedback that some of their previous feedback was missed. Specifically the feedback provided at this comment: #109 (comment)

This will be addressed in this consultation.

[CDR-API-Stream]

Thanks all for the feedback. There is a lot to consume here. We will endeavour to incorporate the proposed changes in v1.7.0 of the standards. In the meantime this thread will be locked. Once the changes are incorporated into the draft a new holistic thread will be opened.

[CDR-API-Stream]

Thanks for the feedback on the presentation model being used for the draft energy standards. This is really helpful in helping us evolve how the standards are documented.

What we have noted is the following general feedback:

• The new format has some display advantages
• The fact that the response schemas are collapsed by default makes the page difficult to search
• The inability to collapse the header and path sections reduces readability
• Binding obligation dates would be a good addition

In addition, there was feedback that would appear to be detrimental if this format was used for the full standards:

• Links to older end point versions and payloads would be needed
• The current display doesn’t show mandatory/optional/conditional fields so participants are referring back to the decision proposal documents
• The types of the fields is not as clear in this format
• Enumerated types are not as clear in this format

This feedback has been noted and the DSB engineering team will look at whether modification or configuration of the ReDoc control will address these issues.

In response to some of the specific feedback clarification is warranted:

• This standard is only draft. It is currently non-binding so obligation dates are not valid
• The DSB does not include statements around applicability of the standards to any specific designation or phasing. This is left to the Treasury and the ACCC to specify in the designation documents and the rules
• The types of the fields are specified according to the existing common types defined in the high level CDR standards. In some cases the numbers and dates with specific formats actually have the string base type with a modifying pattern applied. In these cases the type shown in the draft standards is technically accurate (although inadequate to provide readability to participants)

In coming releases we will be working on addressing all of this feedback.

[CDR-API-Stream]

Responses to feedback on generic tariff data:

There was lots of good feedback on the generic tariff data structure. 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.

Feedback on specific items is below:

meteringCharges is not linked to gasContract and elecContract, would it be helpful to include a fueltype against meteringCharges?

The suggested way to address this is to include contract specific metering charges underneath the contract structure while the high level metering charges are for charges that are generic to the plan rather than the fuel type. This change will not be made until feedback from EME can be obtained.

The options are Elec, Gas or Dual. How will gas supplied for hot water services be captured? (noting it is not clear whether it would be captured from a policy perspective)

If this information is not currently separated by EME (or VEC) then it will not be communicated under the current designation.

We want to note that some discounts are not linked to the plan. Additional discounts can be applied to a customer’s account (in addition to the standard discounts that apply to the plan). The standards should be able to link in more than one discount to a plan. There is a broader interpretation question (more for tailored tariff data) as to how to calculate the discounts for a given plan. Retailers have already considered this issue under Victoria’s best offer obligations which might be helpful here.

In the draft standards discounts are represented in an array so it is expected that there can be multiple. The label of the array field will be modified to show that it is plural

At EA, solar feed in tariffs are not specifically linked to a plan, rather it is added on. The DSB should consider how to reflect this in our plan information.

In the next round of consultation it would be welcome if some specifics as to how these can be addressed in the standards so a specific change can be considered.

This may be more relevant for billing data, but for some customers fees are removed e.g. fee removal for a hardship customer, how will we reflect this?

This is a good call out and should be included in the generic tariff structure since a comparison scenario can take into account concession data. It will, however, need to be raised with EME and VEC.

gasContract contains some fields (solar / controlled load) which are not relevant for gas.

For simplicity, a common structure has been used for both contract types. Field descriptions have attempted to highlight fuel type specific values but, even without this, it would be expected that only relevant values will be populated.

• /energy/plans vs /energy/plans/{planID}: We understand the two level structure reflects that of NMI standing data. However, we question whether some of the information in Get Generic Plan Detail should be replicated and brought up to Get Generic Plans. For example, customerType and geography so that an ADR won’t have to request the data twice (in Get Generic Plans and then again in Get Generic Plan Detail) to obtain these data points. We also note that the geography is in postcodes/supply areas and query if there is value in having whole jurisdictions e.g. NSW, VIC, WA.

This isn’t so much reflective of NMI standing data as it is reflective of a standardised approach for the CDR standards across the board (ie. the banking APIs all follow this pattern also). The customerType and Geography can be lifted to the basic layer, however.

It should be noted that the expectation is that these APIs are unlikely to be used transactionally. Experience from the banking sector is that recipients will call a few times a day to obtain changes and will then store the data locally and incorporate the data into internal models for the specific service.

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

This is good feedback and will be raised with the other teams in Treasury to see if there is an impact on policy expectations.

From a standard perspective, very field fields are actually mandatory. The model developed for CDR in the previous sector was that, for product offerings that are negotiable the detailed information would simply not be provided but the product/plan would still be included so that its existence is known.

 "thirdPartyAgentName": "string", - What does this field indicate and how is it used?

This field, and the “thirdPartyAgentId” field also, are to identify third party origination channels if they exist. They are part of the data set held by EME/VEC

• Should these API structures be implemented by all retailers? Or is it only for generic plan and will be implemented by Energy made easy type of services ?

The designated data holders for the generic tariff structures is EME and VEC. Currently retailers are not expected to implement the generic tariff endpoints.

• "customerType": "RESIDENTIAL", - What is the definition of business? Does any customer with ABN defines ‘business’ or there are any other criteria?

The DSB does not have this specified. We will pass this question to EME for clarification.

• "excludedPostcodes" and "includedPostcodes": and "supplyAreaId": - This depends on tariff in the standing data so providing post code will be difficult. For example if its available across all a DB patch , what’s the expectation ?

These are optional arrays and may be populated as appropriate for the plan. It is also understood by the DSB that Retailers are already populating these structures when they provide plan information to EME/VEC.

• "distributor": "string" - Few Origin plans could stretch to multiple distributors so not sure how this value will be used for multiple DBs.

It isn’t clear what this feedback is implying. More detail would be welcome on the impacts of this item.

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

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.

• "additionalFeeInformation": - Need more info on what this relates too? Please provide an example.

This is free for the Retailer to populate as they wish.

• "pricingModel": More clarification is needed around the different pricing models within the pricingModel attribute, specifically around FLEXIBLE and QUOTA pricing models

We will take this on notice and attempt to get additional clarification.

• Green power – We have different green products like green 25%, Green 50% etc. How will the API structure cater for that information.

More detail would be needed to answer this question. As a superficial response, these would either be different plans or would have appropriate conditional fees and charges to allow them to be represented as a single plan.

[CDR-API-Stream]

Responses to feedback on energy account data:

AccountID generation - Is the dataholder generating it based on the ID permanence rules or AEMO/ gateway? Confirming that the AccountID specific to a specific site or location ?

No position has yet been taken on where the ID generation would take place. This will be determined when the AEMO to Retailer standards are consulted on.

authorisedContacts: We understand that authorisedContacts could link back to the concept of secondary users (if adopted for the energy sector). While not directly relevant here, the DSB will likely need to consider the design of standards around family violence risks, at some point.

This is an important distinction to address and clarify. The addition of authorisedContacts is intended to capture the concept of additional contacts that can act on an account if contact is made to an assisted channel like a retail location or call centre.

This is not synonymous with a secondary user. A secondary user would be capable of independently establishing a data sharing arrangement for the account. It may be possible for a single retailer to support both concepts, one of these concepts or neither depending on their existing arrangements.

accountNumber: was mandatory during initial consultation and now it reads as Optional.

Yes. This was in response to participant feedback.

Name has been rebranded to displayName across the APIs. Is this to align with Banking?

Yes. This was in response to participant feedback.

/energy/accounts/{id}/payment-schedule – this assumes that there are no other payment types outside of cardDebit and directDebit. What about paypal? Afterpay? And others?

Feedback on what to include, and what fields would be valid, would be most welcome. If a structure is proposed it can be included.

credit Card Scheme – It is common practice for retailers to not store the card type e.g. mastercard, Visa etc., but to use a token which links to BPOINT which then stores this information. It is unclear if retailers will be able to provide this data.

An additional value of UNKNOWN will be added to the cardScheme field

Account number - Information such as accountNumber are tokenized in our systems, so there is no means by which we can provide it. Not very clear in this DP if this is mandatory or optional field

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.

Payment schedule API seem not to be time-bound.So, wanted to confirm only current payment schedule details are to be shared via this API.

That is correct

creationDate in Get Accounts means the date that the account was created or opened. But in getAccountDetail, openDate is defined with the same meaning. Is this intentional?

No. There was previously feedback that aligning with the same field name for banking (ie. creationDate) would be a good point of consistency. It was accidentally only applied to one of the structures. This will be fixed

meteringCharges has attribute name not displayName (“Display name of the charge”)

This will be modified

discount has attribute name not displayName (“Display name of the charge”)

This will be modified

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.

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

Discount - With discounts/conditional discounts in Origin , we have a discount period, discount start etc. fields. Say the plan may be 12 months but discount will be applied after 3 months of contract start and for a period of 6 months. How will the payload cater for this?-

Under the current structure this would be addressed via detail in the description field. If a change is suggested to accommodate the scenario describes a suggestion would be welcome. Any changes would need to be synchronised with the generic tariff structures

Amount - We also offer a fixed discount/rebate in few cases – Will that be covered as part of amount field ? Say 50$ credit on your first bill. How will the payload cater for this?

As above. If a change is suggested to accommodate the scenario describes a suggestion would be welcome. Any changes would need to be synchronised with the generic tariff structures

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 ?

An indicative fee, or base fee should be supplied with the potential variability included in the description.

GST component - The GST inclusive/exclusive component should be clearly defined for the retail, solar and fee/charges as it works slightly differently for each of these. Also, the rounding rules for the same should be specified.

The standards do not seek to specify logic that is specified definitively in other regulations or standards. In this case, a redefinition of how GST should be calculated would not be appropriate. It is up to the data holder to ensure that the data they provide is accurate for the context.

• 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 ?

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.

What additional values should be included?

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

A recommendation on how this could be included would be welcome.

• Conditions around roll in / roll out of sites are not specified

A recommendation on how this could be included would be welcome.

• Environmental and regulatory charges are not specified

These would be expected to be included in the metering charges or fees with appropriate descriptions.

• The fee attribute is not setup for C&I customers as the 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 Breakfee (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

A recommendation on how this could be included would be welcome.

• More clarification is needed on the isFixed attribute - does this refer to whether prices are fixed throughout the lifetime of the contract or whether prices can change based on consumption / time bands etc?

Clarification on this field will be sought from EME

Will the balance for an account reflect unbilled debits against that account? ie. Fees on an account that have been incurred but not billed to the customer yet.

This would be up to the data holder. The consistently applied bench mark for questions of this nature is that the value should reflect the value that would be given to the customer via other channels such as a digital experience or via a call centre.

• usage.timeOfUseType - only supports one type of TOU (Peak Off/peak Shoulder) whereas bills will have multiple.

Multiple TOU would be expected to be separated as multiple billing transaction records

• usage.usage - Only supports KWH. Should this also reflect other measurements of usage? i.e. kVAr for demand tariffs

This is a complex problem. Currently all of the tariff information and AEMO provided usage is in KWH only. How would kVAr be added consistently across the standards?

• nationalMeteringId – is this intended to be with or without NMIChecksum?

It is intended to align with the usage of AEMO in NMI standing data. If this unclear clarification can be obtained from AEMO

• 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 ?

A recommendation on how this could be included would be welcome.

• The structure of the API is split into Elec and Gas - would be easier as a consolidated view.

Separation was deliberate to allow for separation of billing for the sub fuel types on an account. This is perceived to essentially be a consolidated view of the charges to an account as opposed to charges for the fuel type which is of value to separate out.

• Should we also link the NMI/address with the bulk balances?

No, this should be avoided due to the data minimisation principle. Address information and NMI are accessed on a separate scope. Using the accountId for reference means that the additional detail can be obtained if consented to being shared without expanding the scope for obtaining just the balance.

[CDR-API-Stream]

Responses to feedback on concession data:

concessions – Some concessions apply to an account, and then after a threshold is reached, the concession is capped and no longer applies. Does the concession for an account reflect a point in time? i.e. it would not appear for an account once the concession has been applied and the cap has been reached.

Yes

Concession - We do not share the concession information outside of our validation process with Centrelink unless Services Australia or a State Government has requested. Ques: Has Centrelink/ Services Australia been engaged as a part of this activity? We would not be able to share concession details without the engagement and approval from them. This feedback was provided previously as part of DP-114.But , wanted to confirm the same.

As previously responded, it is the understanding of the DSB that the requirement for the sharing of data via a designation instrument validly registered according to the CDR legislation would remove the need for further sharing authorisation.

We feel that the two terms (concession & hardship) have been mixed up, and they indeed mean very different things. Concessions are supported by the government () while hardships are energy specific arrangements. It seems the payload should be limited to concessions only.The treatment of hardship customers is very specific to individual organisation's hardship policy. If hardship customers get govt. grants , in few cases the hardship customers are supported via hardship payment plan where the following API may not be able to accommodate the details and in fact that might come under current payment schedule API. Hence , mixing concession and hardship information should be avoided.

This is not a mix up. The removal of the term hardship was deliberate due to the negative connotations associated with it. In the standards the concession endpoint is expected to include any form of discount provided to a customer due to their specific circumstances whether that is government supported or not.

Is there a reason for different naming of similar fields in response and payload fields ?
·       dailyDiscount in the response file vs. perDayDiscount in the payload file - which one are we meant to use for the GET CONCESSIONS API?
·       monthlyDiscount in the response file vs. perMonthDiscount in the paylaod file - which one are we meant to use for the GET CONCESSIONS API?
·       yearlyDiscount in the response file vs. annualDiscount in the payload file - which one are we meant to use for the GET CONCESSIONS API?

This was a mistake in previous updates. Feedback requested the field names be changed but the field descriptions were not updated to reflect the field name changes

[CDR-API-Stream]

Responses to feedback on invoices and billing data:

Need to include Daily/Service Charges (for both Elec and Gas).Where does that sit ?

These should be aggregated in the totalOnceOffCharges charges fields at the fuel type level or the overall invoice level as desired by the data holder

Not every NMI has generation credits

For invoices related to accounts for these NMIs a value of zero should be reported

Should include consumption (broken down into total or based on TOU)
Should include usage x rate (c/kWh) = Amount
Do we need to include - Ave cost /day, Ave daily usage, same time last year,GGH emissions ,meter id?

The breakdown information is available via the billing payloads. The invoice data is deliberately aggregated to suit the data minimisation principle

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…

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

How will cancel/rebill invoices be handled ?

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

Are we including Demand in usage?

In an invoice the demand is not expected to be included. Only the resulting charges. The demand information should be included in the billing transactions endpoint payloads

Do we include Service Order Charges in electricity->totalOnceOffCharges?

Yes. Or in the totalAccountCharges at the higher level

isPaid (boolean) defined in the payload file vs. paymentStatus used in the response file  - are they the same fields?
If Boolean, this is not consistent with the data in the sample response file i.e. “PAID”
What if the invoice is only partially paid? What would the boolean or enumeration value be?

It isn’t clear what the “payload file” and the “response file” are. Feedback was provided that the isPaid field should be an enumeration with multiple values and this change has been included. The isPaid field is no longer part of the standards

For interval sites, it could be possible that reads are partially estimated. What is the expectation in this case within the isEstimate field in the GET BILLING TRANSACTIONS API?

Currently the standard does not make a separation between partially and fully estimated. A partially estimated value is still based on estimation and is therefore not an actual reading. If the underlying specificity is to be provided it should be accomplished by breaking the value into the actual and estimated components. Otherwise it should be reported as estimated

Assuming that TotalUsageCharges includes Other non usage charges (i.e. Supply charge and Greenpower charges, etc however these are not strictly Usage related charges otherwise the sub totals will not add up to the total charges required by this API.

If they are related to usage (such as fixed charges for a high level of consumption) then yes. If they are not that can be included in totalAccountCharges

List of Enumerated values of Time of Use Type not fully defined.
TOU list needs to also include Off Peak DC.

OFF_PEAK_DC will be added. What additional values should be added?

Do we really want to specify this value via a Enumerated List of values that would need to be decoded by the subscriber of this service OR should this be a real world value of a Time Period (i.e. 09:00 - 16:00) that can be used intelligently by the systems that consume this data in the future, give that we are moving to a world of all INTERVAL data where this latter form of data can be better used.

The detailed interval information is expected to be provided via the usage endpoints. As this is a billing transaction payload it is expected to be aggregated values contributing to a specific charge to an account rather than the detailed usage itself

What is the purpose of the adjustments object within the GET BILLING API? Is this for bill corrections or generic adjustments?

Both. It is for any adjustments made to previous transactions that could impact the account balance

For GET BILLING API, non-commodity invoices “may” not be linked to a NMI / Service point - so the servicePointId will need to be optional ?

The servicePointId field will be made optional

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

Feedback on what such an invoice would look like would be welcome so it can be assessed to see if the payload needs to be altered

[CDR-API-Stream]

Responses to feedback on NMI standing data:

meters: For a greenfield NMI, this may not exist. The same comment applies to streams.

If an NMI doesn’t yet have meters is it able to be assigned to a customer and charged against? In discussions with AEMO they have indicated that they maintain a lifecycle for NMIs and that only NMIs that are active and associated with a retailer would be shared.

If there is a meter, should readType be required?

It is understood by DSB that the readType field is not always populated in MSATS so cannot be mandatory

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

These are not available in the AEMO NMI data set

Is there any reason why peakDemand1 and peakDemand2 are required ?

These will be removed. AEMO have indicated also that they are redundant

unitOfMeasure - should that be an enumerated list? It may be worth checking with AEMO as to what they have in place.

AEMO have indicated that this is not enumerated

AEMO feedback:

unitOfMeasure should be optional

This field will be made optional

Classification - As part of the move to 5MS, the list of possible values assigned to this field will change; the attribute will also take: 1) BULK 2) XBOUNDARY (Cross boundary) 3) NCONUML (Non-Contestable Unmetered Load) 4) NREG (Non-registered Embedded Generator) 5) DWHOLSAL (Distribution Connection point where energy is purchased from Spot Market)
Also recommended that this be optional as it is not populated reliably before 2015

Additional enum values will be added to classification and the field will be made optional

Threshold - As per Classification, AEMO recommends that this field be made Optional.

threshold will be made optional

Consumer Profile - Note that as both Classification and Threshold could be missing, AEMO recommends that this object be made Optional

consumerProfile will be made optional

Valid Period - AEMO assumes that this API will supply only data that is currently active at the time of the request. Therefore, we recommend that this Object be Removed in its entirety and that the Last Update Date Time be used to flag the most recent change date.

validPeriod will be removed

Creation Date Time - AEMO assumes that this information is unlikely to be beneficial to the consuming parties and recommends not supplying this information. AEMO recommends that this field is Removed.

creationDateTime will be removed

Installation Type - As part of the move to 5MS, the new value of NCOLNUML (noncontestable meter load) is being introduced.

The additional enum value will be added to installationType

Stream Status - AEMO recommends that this attribute be removed as AEMO only provides active registers

streamStatus will be removed

Averaged Daily Load - Post 5MS this field will store average daily load for each Register – not for each Stream as it does now. In the interim however, there will be instances where, at a Register level at least, this value is missing. Therefore, AEMO recommends that this field be made Optional. There will be a large number of instances where there is only one Register at a NMI and therefore only one Stream, so in the interim the current value for averaged daily load for the Stream will be provided.

averagedDailyLoad will be made optional

Data Stream Type - AEMO recommends renaming this to register consumption type

Field will be renamed to registerConsumptionType

Profile Name - This is provided by MDPs to construct the various load profiles used exclusively by AEMO to derive 5-minute meter reads for market settlement. AEMO recommends removing this attribute.

profileName will be removed

Time of Day - There are records where the data for this is unavailable. This will become an enumerated field as a result of the MSDR. AEMO recommends that this field be Optional.

timeOfDay will be made optional

Multiplier - There are records where the data for this is unavailable. AEMO recommends that this field be Optional.

multiplier will be made optional

Controlled Load - Currently this field is free form. However, as a function of the MSDR this attribute will become an enumerated field. AEMO recommends that this field be Optional.

controlledLoad will be made optional

Consumption Type - There are records where the data for this is unavailable. AEMO recommends that this field be Optional.

consumptionType will be made optional

[CDR-API-Stream]

Responses to feedback on usage data:

Query parameter - There is no parameter to set the time period limit (like newest-date and oldest-date for Get Invoices For Account). A time period limit seems like a useful parameter to align with time limited consents.

Dates will be added and aligned with the billing transaction query parameters (ie. by date - without time) for all variants of the usage endpoints

energy/electricity/servicepoints/{servicePointId}/usage: What is AEMO’s thinking on how to use this construct? Will the register be for a day or some other time period?

It is expected to be provided along day boundaries

If read data is not available for a requested date range: is empty "reads" array is returned or no "reads" attribute at all?

As reads is mandatory it is expected to be returned with an empty array in this situation

[CDR-API-Stream]

Responses to general technical feedback:

Page-size param does not specify maximum page size. This is important for 5MS reads for POC type events (2 years at 5 min intervals is circa 210,000 data points)

The CDR standards apply an overall maximum of 1000 records for all end points. See the Pagination section of the standards.

Pagination – paging is done by pointing to first record of page, and then how many records beyond to return. This can result in missing data if the records are changing between requests – say for example if another read is added, so you would have records 1-25, then 27-51. A better way is to return unique ids to continue paging off (#26 in this scenario)

This is cursor based pagination and is covered in the CDR standards already. See the Pagination section of the standards (look for the Cursor Support heading).