Group-Owned Balances and Meters

All balances associated with a product offer that was purchased by a group can be shared by group members or limited to the group owner. The balances can be allocated across devices to enable family sharing plans, corporate asset pools, and the like, and enable service providers a way to enforce spend control on services and track member usage.

You configure a balance to be shared by setting an aggregated flag on the balance template during pricing plan creation. When the product offer requiring the aggregated balance instance is purchased by a subscriber or group, the operations described here occur.
Note: For a description of the operations that occur for required tier balances, see the discussion about required tier balances.
  • The aggregated balance is added to the purchaser's wallet, or the wallet of the group at the specified tier if a required balance tier is specified. This balance is a G/L balance that the owner is responsible for paying. Aggregated G/L balances are typically associated with a product offer purchased by a group and provide a grant of assets to group members. All impacts, credit limits, and notifications related to non-usage pricing are associated only with the aggregated G/L balance and processed against it. These impacts are, however, propagated up to any associated virtual balance in any parent group wallets so they can be tracked at all levels of the group hierarchy.
  • A virtual balance with the same Aggregated ID is added to the wallet of each subscriber in the group and each subgroup. This balance has no GL implication for the subscriber. It is impacted during subscriber usage and can have credit limits set on it to limit subscriber usage. The impacts are propagated up to the aggregated G/L balance in real-time so usage can be tracked across all group members concurrently and spend control enforced.
  • A virtual balance with the same Aggregated ID is added to each parent group wallet in the same group hierarchy. This balance has no GL implication for the parent group. It enables usage from all sub-group members in the hierarchy to roll up to the highest ancestor group so impacts can be tracked at all levels of the group hierarchy. The aggregated virtual balance can also have credit limits set to limit subscriber usage.
  • If an aggregate balance template is marked as private in the product offer’s required balance list, the corresponding virtual balances (including virtual periodic balances) across the group hierarchy are marked as private to the original purchasing owner and offer.
  • For each aggregate balance, you can specify whether virtual balances are created in both higher and lower group tiers (default behavior) or only in lower tiers. For more information, see the discussion about suppressing higher tier virtual balances.

Figure 1 shows a group hierarchy with GL and virtual balances. Note that the aggregated G/L balance in Group B has a virtual aggregated balance that was propagated up the hierarchy to Group A.

Figure 1. Aggregated and Virtual Balances
Parent group A virtual aggregated balance has child aggregated group balance B which has two virtual group balances B1 and B2.
During subscriber usage, all charges against descendant virtual balances are propagated up the group hierarchy and applied to aggregated balance at the top of the group hierarchy. This balance can be the G/L balance or a virtual balance, depending on whether the top group owns the product offer requiring the balance. Unlike charges, grants are not propagated up the group hierarchy to the group balance. Instead, they impact the purchaser's balance only.
Note: First-use charges apply to the product offer purchaser's G/L balances only.

During rating, when selecting the rate tables and rating formulas to apply, a balance is considered only if there is a G/L balance in the wallet of the subscriber who initiated the event or in the wallet of any ancestor group in the hierarchy.

During product offer purchasing, if there is already an aggregated balance with the same balance ID in any parent group's wallet, it is used instead of creating a new balance. This is true for both GL and virtual balances and enables the MATRIXX Charging Application to manage spend control across all groups and group members.

If a group purchases a product offer that adds a periodic balance to the group wallet (aggregated G/L balance), and the balance is configured to align with the billing cycle, it is aligned with the billing cycle associated with the group wallet. In addition, each virtual balance created in the group members' wallets assumes the billing cycle associated with the member's wallet—not the billing cycle of the group. If any subscribers in the group do not have a billing profile associated with their wallet, the operation will fail, and the group will not be able to purchase the product offer requiring the periodic balance. Similarly, if a group's G/L balance is aligned with the billing cycle and a subscriber joining the group does not have a billing cycle defined, the add membership operation will fail.
Note: Recurring processing is triggered by the start of a new period in the cycle for the product offer purchaser's G/L balance only.
Note: On-demand periodic balances cannot be aggregated balances.
If Event Enabled is selected on a balance template threshold, each time a threshold is reached or crossed, an MtxBalanceThresholdEvent event is generated. To override the Event Enabled attribute, use the following SubMan APIs:
  • MtxRequestSubscriberAddThreshold
  • MtxRequestGroupAddThreshold

Whenever an AddThreshold or RemoveThreshold SubMan API is called to add, modify, or remove a threshold for a subscriber or group, an MtxBalanceThresholdModifyEvent event is generated.

You can use the MtxRequestSubscriberAddThreshold and MtxRequestGroupAddThreshold SubMan APIs to override new threshold history configuration data details in My MATRIXX for a subscriber or group addressed by the SubMan request. These requests contain the MDC structure MtxThresholdData.

For more information about configuring a balance template threshold and overriding the threshold history configuration data details, see the discussion about configuring balance template thresholds in My MATRIXX Help. For more information about the Event Enabled attribute, see the discussions about MtxThresholdData and MtxThresholdInfo in MATRIXX Subscriber Management API. For more information about the AddThreshold and RemoveThreshold SubMan APIs, see the discussions about MtxRequestSubscriberAddThreshold, MtxRequestGroupAddThreshold, MtxRequestSubscriberRemoveThreshold, and MtxRequestGroupRemoveThreshold in MATRIXX Subscriber Management API.