Subscription Offers

Subscription offers identify the pricing for a service. When purchased, a subscription offer is saved with the subscriber or group for which it was purchased, any required balances are added to the wallet, and all applicable pricing is applied. During usage, any policies defined for the product offer are returned to the GGSN.

A subscriber or group can own multiple subscription offers. A subscription offer can contain the standard (non-supplemental) pricing for a service, supplemental pricing for a service, and policy profiles for a service.

  • Non-supplemental subscription offers contain the base pricing for the service. During non-usage rating, only one non-supplemental subscription offer can be used. During usage rating, multiple non-supplemental product offers can be applied during one session when one or more event segments are created. In such cases, only one non-supplemental product offer is applied for each segment, but it can be a different product offer for each segment.
  • Supplemental subscription offers define pricing that is applied in addition to the pricing in a standard (non-supplemental) product offer(s) chosen during rating. You can use supplemental product offers to provide subscribers and groups with special rates and to define additional meters that track or limit subscriber usage. If a subscriber or group owns multiple supplemental product offers, all are considered eligible candidates for rating and, if more than one are applicable, the pricing in all is applied.
  • Policy components define the PCC rules, counters, and counter statuses to return to the network for a certain subscriber or group. In each offer, you can specify an offer is supplemental for charging and policy. For information about how product offers are selected for policy, see MATRIXX Policy.
Note: Discount pricing components can be selected from offers owned by objects in the hierarchy (device, subscription, group) and the global offers. For more information about applying the scope of a discount to a product offer, see the discussion about discount component selection.

The order in which offers are examined for applicability during rating is determined by the offer's priority, which is defined during offer creation. This also determines the order in which the rates are applied. The highest priority non-supplemental offer is selected, including all applicable supplemental offers, and uses them to rate the event. This is important when there are rates in different non-supplemental product offers that are all valid for rating when the event is received. If the first one is not applicable, the one with the next highest priority is examined and used and so on. This process occurs for each segment of an event. If two non-supplemental product offers have the same priority, they are ordered arbitrarily during rating.

A priority can either be a static number or it can be determined by a priority generator that you attach to the product offer. The priority generator is a reusable price component that assigns a priority to a product offer dynamically during rating. The assignment occurs based on conditions specified in a decision table, which is a matrix of one or more normalizer parameters and their specified values. You create priority generators in My MATRIXX. After the priority generators are created, they are listed in the Inventory panel in the Offers tab.

Note: For product offers that contain usage price components, the product offer defines the service type to which the usage components in the offer apply. If the product offer does not include any usage components, the service type setting is not used. The service type defined for a product offer can be a leaf node or an interior node in the service type hierarchy. If it is an interior node, the product offer applies to the specified type and all subtypes.

For more information about the selection process during rating, see the discussion about product offer selection during rating.

When a product offer is purchased through a bundle, during validation, the system verifies the following cycle data objects set on the product offer exist in the system:
  • Selected grace period profile
  • Selected late charge notification profile
  • Selected recurring failure notification profile
  • Selected recurring advance notification profile
  • Selected recurring recharge notification profile

When a product offer is purchased through a bundle, during validation, the system verifies any filters associated with the product offer exist in the system, and that the balance template ID is set and is not 0.

When defining a subscription offer or bundle in My MATRIXX, when Purchased Item Close Event is selected, an MtxPurchasedItemClose event is generated at the offer period close, expiration, or cancelation of the subscription offer.

Filters added to a subscription product offer determine when pre-active purchased items (product offers and bundles) are activated by usage. During purchase, the system verifies that the selected filter exists in the system.