Thank you, Elisabeth, for your response. It is indeed completely aligned to my view. So, summarizing my understanding here -
there are relevant constructs in SID to support the definition in applicable domains. UsageVolumeBalance (with a parameter defining it as shared in nature) from Usage and Rating Domain and RootEntityGroup from Patterns domain can be used to achieve the concept of shared allowance groups and consuming products or services.
That clarifies the definition part, however from service exposure part - it is still being worked upon within TMF.
If the above understanding is correct, will be useful to know the outcome of on-going analysis on service exposure to determine the possible fitment of functions related to this concept.
Original Message:
Sent: Oct 14, 2025 05:35
From: Elisabeth Andersson
Subject: TMF654 for PostPay? - Shared Allowance Groups and Gifting
Hej Nabanit,
Excellent question - allowance-sharing groups are a recurring modeling challenge because they sit across Product, Service, and Balance management and are evolving.
An allowance-sharing group is not a product, but a shared usage-balance construct.
It defines which products or services consume from a common allowance and under what sharing rules.
In SID the runtime allowance concept already exists in the Usage and Rating domains, particularly through:
– UsageVolumeBalance → represents an available monetary or non-monetary allowance.
– ProductUsage or ServiceUsage → records each occurrence of consumption that affects a balance.
• Each usage event consumes from a UsageVolumeBalance, which may be individual or shared across multiple products or services.
• The CustomerBillingAccountBalance in the Customer domain is a financial position (after rating and billing); it is not a runtime or reservable balance.
The relationship between a shared balance and the consuming products or services can be modeled using RootEntityGroup (from the Patterns domain).
This allows multiple ProductUsage or ServiceUsage entities to be associated with a single UsageVolumeBalance.
The shared UsageVolumeBalance is the actual object of consumption; group membership defines who can use it and under what policy. This avoids creating pseudo "root offer" instances in Product Inventory, which should only hold realized commercial products, not runtime sharing constructs.
Usage and billing behavior
• Each participating service still generates usage (Product, Service)
• For wallet-style pre-funded offers, rating still occurs, but the charge is settled against the available balance rather than generating an additional billed charge - avoiding double charging.
• Policies controlling sharing, rollover, or hierarchy can be defined using RootEntityGroup combined with policy rules (Patterns or Policy domains).
In summary allowance-sharing groups can be represented in SID through shared UsageVolumeBalance entities, linked to multiple ProductUsage or ServiceUsage records using RootEntityGroup. Product Inventory continues to hold the individual product instances.
Any billing or reporting exposure is derived from the ProductUsage level, which is the customer-visible representation.
On the ODA Component and Open API side, we are still working out what component(s) will hold the balance and what APIs to related. Today in v4 we only have the TMF654 PrepayBalance Mgmt that needs an evolution.
If you want to see examples of possible modeling of generic allowances you can look at TMFS009 Usage and Balance Management. It is still evolving to contain the basic before we show a shared allowance to indicate the relationship of multiple services consuming the same balance.
------------------------------
Elisabeth Andersson
MATRIXX Software
Original Message:
Sent: Oct 13, 2025 05:37
From: Nabanit Kalita
Subject: TMF654 for PostPay? - Shared Allowance Groups and Gifting
Hello Elisabeth,
Coming back to this earlier thread - I am seeking guidance from the community on the topic of allowance sharing groups. Is there a proper representation of allowance sharing groups in TMF ODA?
In my view, if there is a possible representation of such allowance sharing groups in appropriate domain like Billing, it may help us in avoiding creation of equivalent product instances created in Product Inventory for the purpose of representing an allowance sharing group (which is may not be a candidate to be stored in Product Inventory ideally). At times certain implementations have mirrored the allowance sharing groups by defining a root offer instance in inventory and associating the actual product instances under it just for replicating the allowance sharing group concept.
Any guidance will be very helpful!
------------------------------
Nabanit Kalita
Telstra Corporation
Original Message:
Sent: Apr 19, 2024 03:29
From: Elisabeth Andersson
Subject: TMF654 for PostPay? - Shared Allowance Groups and Gifting
Hej Alistair,
Yes, the intention with 654 is to make it customer agnostic. It should be the home of balances/allowances no matter if the customer pays on invoice or with a top up paid in advance. I did an attempt to update 654 to 4.1 stating that this should be customer agnostic by adding textual context, but for several reasons it looks like the only thing that has made it to the pre-production table is the swagger. I have also raised a JIra ticket to rename the API for v5 to remove the reference to Prepay and this has been approved.
Best regards,
Elisabeth
The key when you look at the underlying data model is the Bucket resource. as
------------------------------
Elisabeth Andersson
MATRIXX Software
Original Message:
Sent: Apr 18, 2024 03:20
From: Alastair Black
Subject: TMF654 for PostPay? - Shared Allowance Groups and Gifting
All,
We're looking at the best approach to support grouping and gifting of data allowances for postpay mobile customers.
TMF654 logically describes the capability we need though positioned today solely for prepay.
I've noticed a couple of threads suggesting 654 could be potentially extended to cover postpay scenarios although there don't seem to be any recent discussions in this area.
Is anyone aware of any further thinking or work in this area?
Thanks Alastair
------------------------------
Alastair Black
BT Group plc
------------------------------