Decision Proposal 265 - Telco Billing Transactions Payloads

[CDR-API-Stream]

This decision proposal contains a recommendation for the candidate payloads for the Billing and Transaction data clusters for the telecommunications sector.

The decision proposal is embedded below:
Decision Proposal 265 - Billing Transactions 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.

[perlboy]

Preamble

There seems to be an explicit definition of Fixed Internet Services in this and all the other Decision Proposals. During Treasury consultation on the Rules Amendments for Telco last week it was stated the rules proposal of "fixed internet services" was deliberately ambiguous. On this basis, I feel the assumptions made in this and other telco DPs on the definition of fixed internet services is quite likely to be incorrect. Things that can be classified as fixed internet services include data centre terminations (ie. ethernet), SHDSL, legacy connectivity methods (ISDN) and even POTS terminations (ie. 14kbit connectivity for back to base services). There's also very limited clarification as to the definition of "internet" in this context because services can be terminated in a variety of ways and have access to the "internet" via a variety of routing mechanisms. If the limitation was whether the service has a "public internet address" that wouldn't be accurate either because carrier-grade NAT is in use in a variety of retail offerings.

Suffice to say, the definition of what is actually in scope needs to be clarified rather than assumed in a Decision Proposal by a government entity who openly state they aren't responsible for Rules interpretation. Perhaps there should be a Decision Proposal to define the scope of what is a "fixed internet service" in the first place so at least "clarifications" in the future could have a baseline to work on a maintenance task to uplift?

Anyway, a few quick notes:

• accountName in a Transactions List, this is divergent from similar endpoints and represents duplication of other endpoints (ie. Account / Account Detail). It also doesn't appear as proposed billing data in the exposure draft (ie. we're now merging account data with billing data)
• balance is in Transaction List, this seems like divergent pattern from other sectoral endpoints
• Nested accounts array, this is divergent from other sectoral endpoints, maybe it's because of an odd definition in the Rules draft?
• Would the Transaction List payload be more aligned to being an array of bills (similar to array of invoices in energy) rather than account centric. Keeping it account will make it impossible to produce a bill that isn't attached to an account identifier (ie. a charge on the individual not for a specific account - yes, that happens)
• serviceId is described as a unique identifier "such as" an MSISDN or service identifier for NBN. This is very definitely a bad suggestion, MSISDNs can change and equipment identifiers without changing the service

Footnote: The payload in this draft seems really confused. It has account identifiers, payment methods, invoices and balances all in one big blob. It's a bit of a pick and mix. I can't help but wonder if an alignment to something like energy endpoints may be worthwhile because this endpoint seems like it will cross scopes and be a huge payload (ie. i can see ADRs implementing just this endpoint and slamming source systems). Ie. Split out to balances, billing, invoices and payment methods.

[Telstra-CDR]

Please review this in conjunction with #264 and #266 as there is common feedback across the proposals.

Data.account
AccountName – Consider removing this as an attribute for Telco.

Account.transactions.paymentmethod
Amount is incorrectly placed under a payment method obj.

data.accounts[].account.transactions[].transaction.services
Start and End Date (Date when the usage period starts) – Seeking clarity on what this is referring to and what purpose it serves?

For the services Array of Objects, when the transaction is a payment of the amount owing across multiple invoices (exceeds the value of any single invoice), do the services include all services associated with all applicable invoices?

data.accounts[].account.transactions[].transaction.paymentMethod
Given that the paymentMethod Object is not an array it should simply be an attribute and thus exclude the amount which would become a peer of the paymentMethod attribute.

data.accounts[].account.transactions[].transaction.services[].service.invoiceNumber
Is the invoiceNumber the invoice that lists the payment transaction (with the payment being for one the amount owing for one or more previous invoices)?

How does the invoiceNumber apply to a subscription scenario (given that it's Mandatory)?

transactionDate startDate, endDate
Please consider consistent naming standards as the suffix in the attribute name doesn’t match the type. In other parts of the CDR, this field may be called transactionTime or transactionDateTime.

type
Type of transaction
DEBIT
CREDIT
OTHER

Worth adding the definition of these attributes to remove any ambiguity of interpretation.

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