Decision Proposal 264 - Telco Invoice Payloads

[CDR-API-Stream]

This decision proposal contains a recommendation for the candidate payloads for the Invoice data cluster for the telecommunications sector.

The decision proposal is embedded below:
Decision Proposal 264 - Billing Invoice Data Payloads.pdf

This consultation will be open for feedback until the 17th October 2022.

[CDR-API-Stream]

The decision proposal has been attached to the issue's original comment.

[LeanneVOD]

The billing invoice data proposal includes fields re data uploaded and data downloaded. These fields should be optional depending on whether the provider currently provides this information. Not all telco invoices include this information. For example, dodo's invoices for NBN FTTP Unlimited 100Mbps plan does not include this information.

Some of the fields re pay on time discount are optional and others are mandatory, given not all telcos offer such discounts these fields should be all optional.

Leanne O'Donnell
Vocus

[ghost]

Out of interest, @LeanneVOD, if a provider doesn't provide certain information on an invoice does that mean they don't hold that information?

The banking sector is required to share all sorts of data that some banks don't make available through any other channel and this is what makes CDR so good for the consumer; they can access and share all of their data! 🙌

So, I would hope in this case that data uploaded and data downloaded are both properties that are held by the provider even if they don't disclose it on their invoices. For the benefit of the consumer, it would be awesome for this data to be available for sharing 😊

[perlboy]

There's a lot of overlapping data across endpoints popping up across the DPs. Suggest that telco endpoints maintain clear boundaries of data sets across endpoints rather than repetition in different shapes. It is a distinct possibility that endpoints are crossing data type boundaries (rules) which will cascade into CX language and ultimately implementations.

[Telstra-CDR]

Please note some of the feedback provided below also applies to the #265 Billing Transactions and #266 Balance and Usage and any changes should be applied across.

General Comment
The boundaries of each of the endpoints is unclear with a lot of overlap / duplication across the data payloads

General Comment across Account, Invoice, Billing transaction, Balance and Usage payloads.
Further exploration is required on the correct model to ensure compatibility across both a Post-paid Billing Account Model and a Subscription. For example the current model would break for a hybrid situation where a customer has both subscription services and post-paid billing accounts. The following is an illustration of one such scenario.

End Points

POST /telco/account/invoices
Why is this API a POST but all the data is being transferred via query parameters? Should this either use request payloads or be a GET request?

GET /telco/accounts/{accountId}/invoices
This seems to the same API as the /telco/account/invoices
There are no query paraments to limit history
This API is missing pagination.

Query Parameters

newest-date & oldest-date
Suggestion to strengthen the definition of newest and oldest date, the current drafting results in no boundaries. i.e newest date can be any date in the past.
Also, for oldest-date, DSB should reconsider the duration and limit it to 12 Months in the past. Is this aligned to the CDR Rules on historic data requirements?
Suggestion/s
• Default date for newest-date is current date
• newest-date cannot be older than Oldest Date.
• oldest-date cannot be earlier than current date minus 12 months

Amount

Response Payloads > usage > data > amount
Response Payloads > usage > voice > national > amount
Response Payloads > usage > voice > international > amount
Response Payloads > usage > messaging > sms > amount
Response Payloads > usage > messaging > mms > amount
Cost amount of data usage
Considerations should be made for plans with unlimited data/calls or no amount tagged to usage

Roaming & International

Response Payloads > usage > voice > international (International and roaming calls)
Suggest consistency and clear delineation between Roaming and international, The data usage breaks out roaming usage but also expects roaming calls to be included as part of international Calls.

data.invoices[].invoice.usage.roaming
This is inconsistent with usage.data as it is lacking upload, and session. Is this deliberate?

Charges

data.invoices[].invoice.accountCharges.totalGst
Consider the field being called as totalUsageGst given it is only the GST for usage and excludes once off charges. Also, this makes it consistent with totalUsageCharges where it includes the word “usage” in the key.

data.invoices[].invoice.usage
Usage and associated attributes should be optional as usage charges may no apply in an invoice.

Duration

data.invoices[].invoice.usage.voice.national.duration
data.invoices[].invoice.usage.voice.international.duration
TimeString is defined as full-time according to RFC3339. This would mean that we need to include a time-offset which would be inaccurate in this context. Also, there is a potential for making greater than 23 hours of calls in a month which doesn’t fit the type.

SMS & MMS

data.invoices[].invoice.messaging
The payload should allow for scenarios where operators do not split SMS and MMS.

[CDR-API-Stream]

This consultation is now being closed for feedback.

As described in Noting Paper 255 - Approach to Telco Sector Standards, next steps will be to:

• respond to the feedback already given
• integrate that into a draft standard including all of the designated data clusters
• open a holistic consultation to obtain further participant feedback.

[CDR-API-Stream]

Marking this consultation as No Decision Made. While the proposal and feedback for this consultation have been incorporated into the draft standards this is not yet a formal decision of the Chair.