Pre-Active Purchased Item Activation

A pre-active purchased item can be activated as the result of a status life cycle transition, by a subscription, group, or device SubMan modify request, by usage-triggered activation, and by time-triggered activation. If the purchased item is a bundle, all product offers in the bundle are activated at the same time.

The following actions occur when a purchased item is activated.
  1. Required balances are created.
    Note: If the required balances in a product offer are changed between the purchase time and validation, there could be balances that are not valid for the object that purchased the offer (for example, if there are device-specific required balances, only a device can purchase the offer). In this situation, activation will not succeed.
  2. The activation time is set for the purchased item.
  3. If the validity end time is specified as relative to purchase, the validity end time is set relative to the activation time.
  4. Purchased item activation components are applied. See the discussion about activation components for more information.
    Note: A balance state update component can be either a purchase component or an activation component. If you configure balance state update components as activation components, they can be applied at purchase time (when purchased in an active state), or they can be applied at activation time (if purchased in a pre-active state). If balance threshold components are defined, they are executed after all the purchase components (if thresholds are crossed), and once more after all purchased item activation components (if thresholds are crossed).

    Balance state update extensions are performed before rating occurs, so the G/L balance instance can be impacted by the associated pricing if it has already expired. This also enables the balance quantity that was added at purchase time to be available for a longer period of time. If the balance state update component is configured for auto-renew, the balance-state update is applied before auto-renew charges, discounts, and grants.

    For more information about balance state update components, see the discussion about balance state update components in MATRIXX Pricing and Rating.

  5. Prorated recurring processing occurs for all recurring components within the purchased item. The the amount of the proration is based on the position of the activation time within a cycle.
  6. If the purchased item has a cycle, details of the cycle are established based on the activation time and on cycle data supplied when the item was purchased.
    • Even though cycle data specified during the purchase was validated at that time, it could be invalid when the purchased offer is activated due to changes in the state of the subscription, group, or device. For example, if the purchase request specified that the purchased item cycle should align with the cycle of another purchased item, and the master purchased item was canceled, the activation will fail.
    • If the purchased item has a cycle, the cycle offset for the cycle is established based on the activation time.
    • If a request to modify a purchased item both activates the item and specifies a cycle modification, the cycle modification data is used in place of the cycle data provided during the purchase. Some fields in the cycle data that can be supplied during a modification are not used when initially setting up the cycle during an activation (such as the ImmediateChange field).
    • Prorated recurring processing occurs for all recurring components within the purchased item. The amount of proration is based on the position of the activation time within the cycle.
  7. A purchased item activation event (MtxPurchasedItemActivationEvent) is generated (includes activation charges) and a recurring event is generated and linked to the activation event. The recurring event includes the recurring charges. See the discussion about activation events for more information.
  8. If the purchased item is owned by a subscription or device, the policy for open policy sessions is evaluated and policy notification messages (Gx RAR or Sy SNR) are generated for any session in which a policy has changed. If the item is owned by a device, the device-associated policy sessions are checked. If the item is owned by a subscription, the policy sessions checked are those associated with any device that is associated with the subscription.
  9. If the purchased item is owned by a subscription or device, Gy RAR messages are sent for associated, open charging sessions.
Note: During a purchase request, you can set the ActivationExpirationTime to decide when the purchased item should expire if it has not been activated. The un-activated purchased item is canceled and purged. For more information about purchase request fields, see the discussion about the MtxPurchasedOfferData MDC.

Activation Relative Offset

If you define the subscription with a billing cycle, when using the SubMan modify requests, you can set the following two fields in MtxPurchasedOfferData:
  • AutoActivationRelativeOffset — This is used only if PreActiveState field is set to true. The number of units relative to the offer purchase time to set the automatic activation time. There will be an error if more than one of AutoActivationTime, AutoActivationRelativeOffset, or AutoActivationCycleResourceId are set. An error occurs if you set the expiration time and auto-activation.
  • AutoActivationRelativeOffsetUnit — Sets the activation time unit only if PreActiveState is set to true. The units are:
    • 1 = hours
    • 2 = days
    • 3 = weeks
    • 4 = months
    • 5 = years
    • 6 = billing_cycle_inclusive (including current billing cycle)

      With x units of billing_cycle_inclusive, the AutoActivationTime will be the end time of the current cycle plus the product of (x-1) * billing_cycle_length.

    • 7 = billing_cycle_exclusive (excluding current billing cycle)

      With x units of billing_cycle_exclusive, the AutoActivationTime will be the end time of the current cycle plus the product of x * billing_cycle_length.

    • 8 = minutes
For example, the subscription billing cycle starts on the 1st day of every month with a start time at 00:00:00.000000. If the offer is purchased on May 5:
  • (6) Inclusive: 2 units of billing_cycle_inclusive – AutoActivationTime is 2021-07-01T00:00:00.000000.
  • (7) Exclusive: 2 units of billing_cycle_exclusive – AutoActivationTime is 2021-08-01T00:00:00.000000.
Note: If you specify an EndTime and the resulting AutoActivationTime value is not less than the EndTime value, it is an error.

For information about activation revenue recognition and GL processing for pre-active purchased items, see the discussion about recognizing revenue in MATRIXX Integration.