Product Offer Selection During Rating

When trying to apply a product offer for its charges, there are three possible outcomes—pass, fail, and not applicable. The outcome depends on whether the product offer is supplemental or non-supplemental.

Selection Process

Supplemental product offers:
  • Pass — If no charge component fails and at least one charge component passes.
  • Fail — If one or more charge components fails to be applied.
  • Not applicable — If no charge component applies.
Note: Decision tables for usage, policy, or repository select either a profile (Pass) or SKIP (Not applicable).

The selection process is slightly different for discounts and grants.

  • Discounts — Product offers do not fail because of discounts—they either pass or are not applicable. Note that the product offers selected for discounts can be different than those selected for charges, for example, when a product offer is applicable for charges and not discounts, or the reverse. Discounts do not cause denial of usage authorization unless they have an explicit deny in the rate table row selected. In addition, they do not cause a non-usage operation to fail unless they have an explicit deny in the rate table row selected.
    Note: Purchase and cancelation discounts within any product offers in a bundle apply to all the purchase or cancelation charges within a bundle. For example:
    • A bundle has three product offers:
      • Voice offer — $10.00 purchase charge.
      • Data offer — $20.00 purchase charge.
      • Discount offer — 10% off USD purchase charges.
    • The 10% discount applies to the purchase charges in both the voice and data offers; the total purchase charge is $27.00.
  • Grants — Grants are handled similarly to those with discounts with the following additions: usage grants are not supported and the credit limit is not used in selecting the balance instance to impact.
Note: Bundles can change the rating results of product offers within the bundle by directly referencing pricing components. These directly-referenced pricing components (bundle components) override or supplement the charges, discounts, or grants of a product offer selected for rating that is in a bundle. This allows product offers to be created without having to consider if they will be included in a bundle. For more information about bundle pricing components, see the discussion about bundle components.
Non-supplemental product offers:
  • Pass — If no charge component fails and at least one charge component passes.
  • Fail — There is no fail outcome.
  • Not applicable — If one charge component fails or all the charges are not applicable. When a non-supplemental product offer is not applicable, any lower priority non-supplemental offers are checked to see if they are applicable.

Event Segmentation

When events are received in MATRIXX Engine, a list of candidate product offers is created and examined for each event segment to determine which ones apply. Each usage, policy, or repository request is rated as a series of event segments up to some boundary. Any segment can be bounded by time, and usage segments can additionally be bounded by the amount used or by the amount charged for that usage.

If a supplemental offer fails, the segment fails.

If a segment fails, a result based on segments that pass might be returned. For example, if segments pass until midnight but fail thereafter, the system might authorize quota, deploy policies, or publish repository data that expires at midnight.

Usage is charged separately before and after a Tariff-Time-Change (TTC). Sometimes, segments can fail before the change, but pass after it.

For other non-usage rating, there is no distinction between supplemental and non-supplemental offers. Relevant components are collected from all applicable offers:

  • For purchase, cancelation, activation, or recurring processing of a purchased item, all components come from that purchased item.
  • For offer auto-renewal, all components come from that offer.
  • For bill/balance recurring, balance first-usage, or balance threshold-based pricing, components can come from all offers owned by the owner of the relevant bill cycle or balance.

The components are then applied together. If any component fails, the event fails. Otherwise, the event succeeds.

For more information about event segmentation, see the discussion about event segmentation during rating.

For more information about TTCs, see the discussion about TTCs in MATRIXX Diameter Integration.

Decision Tables During Rating

During rating, the product offer outcome is based on decision tables.

First, the charge decision table considers the following order:
  1. If a decision table indicates a charge to a balance class, balance template, or balance tag without any matching valid balances, the result is Fail.
    Note: If the balance does not exist, the table automatically equals Fail even if it would otherwise decide to skip, causing the component to equal Fail, which results in the offer also equaling Fail. However, if the component has another table that, for example, charges 0 to the main balance so that the table equals Pass, the component then equals Pass.
  2. If the decision is to use a pricing-specific denial formula, the result is Deny.
  3. If the decision is to charge with insufficient credit, the result is Fail.
  4. If the decision is to charge with sufficient credit, including charging zero (or less) to a balance with no credit, the result is Pass.
  5. If the decision is to SKIP, the result is Not applicable.
Next, each component considers the following in order:
  1. If any table equals Deny or Pass, the component equals Deny or Pass according to the first such table found.
  2. If any table equals Fail, then the component equals Fail.
  3. Otherwise, the component equals Not applicable.
The offer outcome always equals the component outcome:
  1. If any component equals Deny, then the offer equals Deny.
  2. If any component equals Fail, then the offer equals Fail.
  3. If any component equals Pass, then the offer equals Pass.
Finally, for each usage, policy, or repository rating segment, each offer is evaluated in order of priority to construct a list of Pass offers:
  1. If the offer is non-supplemental but there is already an offer in the Pass list, then the offer is ignored and the remaining steps are skipped for this offer.
  2. If the offer equals Deny, then the segment is immediately denied.
  3. If the offer equals Pass, then the offer is added to the Pass list.
  4. If the offer equals Fail, the offer is ignored but noted.
  5. If an offer equals Not applicable, the offer is ignored.
Note: If there is an offer auto-renewal:
  • A non-supplemental offer can change from Fail or Not applicable to Pass.
  • A supplemental offer can change from Fail to Not applicable or Pass.
The result of this process is a list of zero or more Pass offers, including zero to one non-supplemental offers, and any Fail offers are noted. Then:
  • For future usage authorization, the Pass list must include one non-supplemental offer, and there must be zero Fail supplemental offers noted.
  • For policy and repository data deployment, the Pass list must not be empty, and there must be no Fail supplemental offers noted.
  • For past usage charging, the Pass list must not be empty so that offers that equal Pass can be charged.

If a supplemental offer's component skips all the way through the decision table, the component equals Not applicable and is ignored. If all the offer's components equal Not applicable, then the offer equals Not applicable and is ignored.

If a non-supplemental offer's components skip all the way through the decision table, the offer equals Not applicable and is ignored.