10 About Discounts

This chapter provides an overview of Oracle Communications Billing and Revenue Management (BRM) discounting. You can discount events rated in real time and by pipeline batch rating.

Important:

The Batch Discounts (batch discounting in a pipeline) feature is bundled with Advanced Discounting Manager, an optional feature that requires a separate license.

Before reading this chapter, you should be familiar with real-time and batch rating. See "About Real-Time Rate Plans" in BRM Setting Up Pricing and Rating and "About Pipeline Rating" for more information.

Note:

In addition to the discounting procedures discussed in this chapter, you can create rate adjustments for real-time events in two ways:

• You can reduce purchase, recurring, and usage fees by a flat percentage. These rate adjustments are offered through deals. See "Providing Deal-Level Discounts" in BRM Setting Up Pricing and Rating for more information.

• You can use multiple rates and set minimum and maximum quantity values for them. You do this in real-time rate plans. See "About Quantity-Based Rating" in BRM Setting Up Pricing and Rating for more information.

For information about setting up specific types of discounts, see "About Implementing Discounts". For information about configuring discounting modules and real-time discounting pipelines, see "Configuring Discounting Modules and Components".

About Discounting

You use discounts to reduce the charges associated with billable events and to grant or consume non-monetary resources such as free minutes or frequent flier miles. You can discount usage charges, purchase fees, and recurring charges. You can discount events rated in real time and by pipeline batch rating.

Note:

In real-time rating, non-currency resources can be consumed during rating (by the real-time rating engine), or they can be consumed by the real-time discounting pipeline. In batch pipeline rating, non-currency resources are consumed by your batch discounting module. As such, in batch rating, you use a discount to consume a non-currency resource. In addition, note that you cannot use the pipeline rating module to consume non-currency resources (the pipeline rating module does not have the necessary access to non-currency resource sub-balances).

You can set up offer profiles using the provisioning tags in discounts to manage policy-driven charging. For more information, see "Policy-Driven Charging" in BRM Setting Up Pricing and Rating.

Discounts are separate, purchasable items similar to products. You bundle discounts with products in deals that customers purchase.

For example, you can offer a deal called GSM Plus that includes basic GSM telephony with 300 free peak and 500 free off-peak minutes for a $60 setup fee, a $40 monthly fee, and usage charges. The deal already includes one discount, the free minutes, but you can add an additional promotional discount to the deal that reduces the charges even more:

• 50% off the monthly fee for the first 6 months

• Waiver of the setup fee (a 100% discount, in effect)

• 25% off for usage over 750 minutes

This deal now includes discounts on events rated in real time (the monthly and setup fees) and events rated in batch by Pipeline Manager (the free minutes and the 25% usage discount). The discounts cover usage charges, recurring charges (the monthly fee), and purchase charges (the setup fee).

When you provide free resources such as free minutes, discounts and products can work together:

• You use products to grant the free resources. When you define the product, you use cycle events to grant the free resources. For example, you can define the product to grant 100 free minutes each week or 500 minutes on a one-time basis.

• You use discounts to determine how free resources are consumed. Charges are applied by rating before events are discounted, so in the case of free minutes, the discount credits the amount charged for the free minutes used and reduces the balance of free minutes.

Not all discounts necessarily grant, consume, or discount resources. For example:

• When an account shares free minutes with other accounts, you can use one discount to record the balance of available minutes in the sharing account. A second discount uses the recorded balance to consume free minutes for the account that made the call.

• When you set up billing-time discounts, you can use a discount to update a counter balance; for example, a balance that tracks total usage. You use a second discount to apply a percentage off based on the total usage balance.

BRM supports subscription discounts and system discounts.

You use Pricing Center to set up discounts for both real-time and batch pipeline rating.

Discounting Process Overview

Discounts are processed after rating and are based on events. Discounting changes the amount that was charged during rating. Discounting takes place in a pipeline, even if the rated event originates in real-time rating.

The way events are passed to discounting depends on whether they were rated in real time or in batch. (See "Understanding the Discounting Architecture".) But the discounting process is similar for both real-time and batch events.

Discounting works on event data records (EDRs), each of which contains data about a single rated event. Every EDR includes one or more charge packets that result from the event being rated. (Real-time rating does not normally produce EDRs or charge packets, but real-time charges are converted to EDR format when passed to a discounting pipeline.)

There are four main phases to the discounting process:

1. Discount analysis. During discount analysis, every EDR is examined to determine whether there are any discounts that apply to this event type. For example, if the EDR contains a Global System for Mobile Communications (GSM) usage event, the discount analysis module checks for discounts that apply to GSM usage.

2. Filtering by event attribute. In this phase, discounting evaluates the charge packets in each EDR to determine whether they qualify for discounting. When you define a discount model, you specify event attributes that determine whether charge packets qualify for a particular discount. The discount filter can filter by date and time, zone model, impact category, service code, and other attributes. See "Filtering EDRs for Discounting" for information about setting up discount filters.

3. Checking conditions. If a charge packet passes through the discount filter successfully, discounting now checks whether the charge packet meets the conditions that trigger discounting. Conditions include factors such as charge, usage quantity, and number of events. You can also create conditions that include arithmetic operations and other expressions.

   Note:

   • Discount triggers are required. However, if you do not need to set conditions, you can configure the trigger to pass all charge packets.

   • If either the usage quantity or the charge amount is 0, discounting does not evaluate the charge packet and no discounts are applied.

   See "Determining if Usage Qualifies for Discounting" for more information about defining discount conditions.

4. Calculating and applying the discount. If all the required discount conditions are met, discounting calculates and applies the discount by using a discount rule. A discount rule defines the amount of usage to consider for discounting, how much of the usage to discount, the discount amount, and the balances to impact. See "Defining How Discounts Are Applied".

Discounts and Balances

When discounting processes an EDR, it requires access to balances related to the event and the discount. Balances keep track of resources, which can be monetary or non-monetary. Non-monetary resources include usage quantities such as minutes or bytes, as well as special-purpose resources such as loyalty points.

For example:

• If you grant free minutes, discounting needs to know how many minutes have already been consumed so that it can determine how much of a call is covered. Discounting also requires the ability to update the free minutes balance to reflect the minutes consumed.

• If you give a 25% discount on usage charges over $100, discounting needs to know the current balance of usage charges in order to determine whether the discount applies and to calculate the amount of the discount.

• If you set up a billing-time discount that grants a discount based on the total amount of usage during a certain period, discounting needs to know the amount of usage during the validity period.

Some balances are primarily aimed at tracking balances that are granted and then used, such as free minutes. Other balances keep track of usage or consumption, such as the total quantity of data received or minutes used. This latter kind of balance is called an aggregation counter and can be used as the basis for granting a discount. For example, you can create a discount that grants 10 frequent flier miles for every 60 minutes of usage.

You specify which balances are used by a discount when you set up the discount balance impact. See "Defining How Discounts Are Applied". If you use an aggregation counter to calculate the discount, you include that balance in the expression you enter for the calculation. See "Using Expressions in Discount Models".

Some kinds of balances, such as those used for free minutes, can be affected by rollovers. For example, the current balance of free minutes could include minutes granted this month as well as minutes rolled over from previous months. You set up rules that govern how balances are rolled over when you set up products. For more information, see "About Rollovers" in BRM Setting Up Pricing and Rating.

The balances referenced by discounts are configured when you set up plans. For more information, see "About Tracking Resources in Account Sub-Balances" in BRM Setting Up Pricing and Rating.

BRM handles balances differently for real-time discounting and batch discounting. See "Balances and Real-Time Discounts" and "Balances and Pipeline Discounts".

In addition to balances that are maintained permanently, you can configure temporary event balances for use in discounts. See "Using Event Balances in Discounts".

Balances and Real-Time Discounts

For real-time rating and discounting, BRM stores balances in the BRM database. These balances are updated in real time as transactions occur. Because balances are stored in only one location, there is no need for synchronization. The discounting pipeline gets and updates these balances through the Connection Manager (CM). See "Real-Time Discounting Architecture".

Balances and Pipeline Discounts

For pipeline rating and discounting, BRM stores balances in data modules in the pipeline as well as in the BRM database. Because data is stored in two locations, balances must be synchronized:

• Rating and discounting in the pipeline result in balance impacts that must be reflected in the BRM database. For example, if a discount results in the reduction of a free minutes balance, that change must be reflected in the BRM database so that the balance can be displayed accurately in Customer Center. These updates are made to the BRM database by Rated Event (RE) Loader when it loads rated events.

• Activity in the BRM database affects discount balances used in pipeline rating. For example, a customer might purchase a discount that provides 500 free minutes or a customer service representative (CSR) could post a debit to a balance. These balance changes must be reflected in the discount balance handled by pipeline rating. When these balance changes occur, BRM uses the Account Synchronization Data Manager (DM) to send the discount balance impact to Pipeline Manager.

See "Pipeline Discounting Architecture" for more information about how discounting updates balances.

About Billing-Time Discounts

Important:

The billing-time discounts feature is included in Advanced Discounting Manager, an optional feature that requires a separate license.

A billing-time discount is determined at the end of the billing cycle. This allows you to grant discounts based on resources used during a billing cycle. For example, you can create a billing-time discount to discount $10 if the total usage fee is more than $100 or to grant 10 free minutes if the total minutes used are more than 500. A billing-time discount can also be based on values other than usage; for example, the number of months a customer has subscribed to a service.

Billing-time discounts are calculated and balance impacts are applied when BRM billing is run. You can configure the discount to be applied in the current or next billing cycle. For example, an account can purchase a billing-time discount that grants 10% of the total telephony minutes used in the current cycle to the next billing cycle as free minutes. If, at the end of the current billing cycle, the account has a total of 100 minutes, when the pin_bill_day script is run to run billing, 10 free minutes are granted to the account for the next billing cycle.

Billing-time discounts require an aggregation counter that tracks the aggregated amount for which the discount is granted. For example, to grant 20% off all usage charges for the month, usage amounts are added to the aggregation counter. When billing is run, the discount is based on the amount in the aggregation counter.

To offer a billing-time discount, you set up the following elements:

• A non-currency resource for the aggregation counter to track the total charges or amount that is discounted. You include this resource in the price plan. BRM provides some aggregation counter resources for specific types of discounts, such as volume-based discounts.

• Two discounts:

  • A usage discount to update the aggregation counter. See "About Using Discounts to Aggregate Usage".

  • A billing-time discount to apply the discount when billing is run.

For more information, see "Creating a Real-Time Aggregation Discount".

Billing-time discounts can also be shared with accounts in a discount sharing group. The billing-time discount is based on the total resources used by the entire group. The discount can be applied to the group owner or it can be distributed among group members. See "About Snowball Discounts".

About Using Discounts to Aggregate Usage

Aggregation discounts are usage discounts that increment an account's aggregation counter by an amount that is equal to the usage. For example, when a subscriber makes a 10-minute call, the discount increments the aggregation counter by 10.

Aggregation discounts do not reduce fees or grant resources. Instead, they are used in conjunction with billing-time discounts, which are granted based on the aggregated balance; for example, 10% off when the number of minutes used for all calls exceeds 300.

The amount aggregated can be charges or units used, such as minutes, SMS messages, and bytes. The aggregation counter that is incremented is always a non-currency balance regardless of whether the usage aggregated is a charge or a unit.

Aggregation discounts can also be shared. You share aggregation discounts for two reasons:

• To aggregate the service usage fees for several accounts when a discount is granted to one account based on the total usage of all accounts. For example, a corporate account can receive 15% off its monthly service charge when the total usage for all its employees exceeds $900.

• To track the consumption of free resources (such as minutes or text messages) when those resources are shared among several accounts. You do this when you want to limit the amount of resource that an account can consume. For example, an account shares 600 free minutes with two user accounts whose usage should be limited to 100 minutes each. The user's service usage is aggregated in each user's account. When a user's aggregation counter reaches 100, the discount does not allow the user to consume additional free minutes.

For more information about sharing discounts, see "About Shared Discounts".

For information on setting up aggregation discounts, see "Setting Up Billing-Time Discounts".

About Cycle-Event Discounts

A cycle event is a recurring event typically used for charging a fee, such as a monthly subscription fee. You can apply a discount to one or more cycle events. For example, you can grant 50% off the subscription fee for the first six months of usage.

You can also grant discounts on cycle events that are not dependent on a billing or accounting cycle (known as flexible cycles). You select the type of cycle event to discount when creating the discount. For information about flexible cycles, see "About Flexible Cycles" in BRM Configuring and Running Billing.

If a cycle-event discount grants non-currency resources, such as free minutes or bonus points, those resources are applied to either the current or future accounting cycle, regardless of the type of cycle event you select. You specify the accounting cycle for which the granted resource is valid when you configure the discount balance impact.

For information about setting up cycle-event discounts, see "Setting Up Cycle-Event Discounts".

About Shared Discounts

Discounts can be shared among several accounts. For example, you might offer 10 free minutes for every 500 minutes of combined usage for all accounts or share a pool of free minutes with a group of accounts or services.

To share discounts, you create discount sharing groups. A discount sharing group consists of an owner account or service and one or more services from member accounts. The owner shares its discount with the members. For more information, see "About Discount Sharing Groups" in BRM Managing Accounts Receivable.

With discount sharing, you sometimes need several discounts to specify how resources are granted or consumed for each account. For example, to offer 20% off to member accounts when the total usage for all accounts exceeds 1,000 minutes, you set up a discount to record the usage for each account and another discount to apply the percentage off based on the total usage.

When a discount is shared, BRM can access and impact the balance that belongs to the discount owner or the event owner. For example, a discount can read the balance of minutes from the owner account and update the currency balance in the member account.

Discounting can access balances in different accounts for the same discount only when that discount is shared. If the discount is not shared, only the discount owner's balance can be accessed. However, you can still use discounts that are not shared in a discount sharing scenario by creating event balances. See "Using Event Balances in Discounts".

About Snowball Discounts

A snowball discount is a shared billing-time discount that distributes a percentage off to all accounts in a discount sharing group. The percent that is granted to each account can be distributed evenly or based on how much usage each account accrued.

For example, a discount sharing group is owned by account A1 and has telephony services from three member accounts: M1, M2, and M3. The owner account purchases a plan that includes a snowball discount that grants $0.01 for every minute of telephone usage. At the end of a billing cycle, the group has made 5,000 minutes of telephone calls. The owner account and member accounts M1 and M2 made 1,000 minutes of calls each and account M3 made calls totaling 2,000 minutes. When pin_bill_day is run, $50 is granted to the group. The owner account and accounts M1 and M2 are granted $10 each, and account M3 is granted $20.

You specify whether a discount is a snowball discount when you create the discount in Pricing Center. To implement a snowball discount, you use two discounts: one that updates a common aggregation balance when accounts incur usage, and another that calculates and distributes the discount based on the aggregated amount. For more information, see "Setting Up Snowball Discounts".

About Discounts Based on Query Values

You can create discounts based on data that is searched for and retrieved from the BRM database. For example, you can create the following types of discounts:

• Billing-time discounts for subscribers' most-called numbers. The list of most-called numbers can be based on such factors as:

  • The number of calls to each number

  • The total connection time

  • The total cost

• Billing-time discounts with discount levels based on the type of call, such as:

  • National, international, and in-network calls

  • The call destination (such as Access Point Names (APNs), SMS servers, and URLs)

• Retroactive discounts based on usage during billing periods that have already passed

You implement these discounts by writing iScripts that retrieve the data required for the discount. Data can be retrieved in two ways:

• Directly from the database with opcode calls in the iScript

• From the EDR, after data returned by customized opcodes is added

See "Setting Up Discounts Based on Query Values" for information about configuring query-based discounts.

You trigger the iScript functions by including EVAL tokens in expressions when you create discount models in Pricing Center. An EVAL token points to an iScript function that returns the data required for the discount. See "Understanding the EVAL Token" for more information.

You can use provisioning tags to help configure query-based discounts. The provisioning tags define /profile objects that can be used to store data for use in discounts. See "Using Provisioning Tags with Query-Based Discounts".

BRM includes iScripts and other sample components that enable you to configure discounts based on the subscriber's most-called numbers. See "Discounts Based on Most-Called Numbers" for more information.

Understanding the EVAL Token

When you create discount models in Pricing Center, you can use EVAL tokens in discount expressions to invoke iScript functions. See the Pricing Center Help and "Using Expressions in Discount Models" for more information about discount expressions.

An EVAL token in a discount expression calls a specific function in an iScript file, which must be defined in the registry of the DAT_Discount module. This iScript function can include code that calls a BRM opcode. When BRM evaluates the discount expression, the numeric value returned by the function is substituted for the EVAL token in the discount expression.

For example, suppose you want to implement different discounts on data usage depending on the access point used. You want to apply a 10% discount for data usage from AccessPointX and a 15% discount for usage from AccessPointZ.

To implement this discount, you could include EVAL tokens in the Base Expression fields for two discount balance impacts. Each token includes the name of a different iScript function:

• EVAL("AcPtX") refers to an iScript function that returns the total amount of data usage from AccessPointX.

• EVAL("AcPtZ") refers to an iScript function that returns the total amount of data usage from AccessPointZ.

When BRM processes this discount, the usage amounts for each access point are substituted into the expressions. A 10% discount is applied to AccessPointX usage and a 15% discount to AccessPointZ usage.

Like other discount expressions, expressions including an EVAL token can be used in the following discount model components:

• Discount Rule

• Discount Condition

• Discount Balance Impact

• Discount Step

Performance Impacts of Query-Based Discounts that Include Opcode Calls

iScripts that call opcodes can slow the processing of events to which a query-based discount applies. The exact performance impact depends on system configuration and resources.

Some of the impact results from the time taken to route the opcode call to and from the CM. Using a global or wrapper opcode to call individual opcodes is more efficient than calling those same individual opcodes individually from the iScript. Because a wrapper opcode reduces the total number of round trip calls to the CM, performance is improved compared to a series of individual calls.

The bulk of the performance impact results from opcode processing, however. The complexity of the opcodes called therefore plays a large role in the performance overhead of a query.

There is a separate performance impact for each expression in a discount model that uses an EVAL token to call an opcode through an iScript function. Because the discounting pipeline evaluates each expression separately, each opcode call is handled separately.

Because of these performance impacts, query-based discounts that use opcode calls should be configured as billing-time discounts. The overhead associated with opcode calls is more acceptable at billing time than during normal event processing.

Important:

Pricing Center does not prevent you from including the EVAL token in regular discounts, but you should use this functionality for those discounts only with extreme caution.

Using Provisioning Tags with Query-Based Discounts

You can use provisioning tags to define information used in query-based discounts. For example, you can create provisioning tags that define search and aggregation criteria to be used in collecting data for the query. See "About Provisioning Tags" in BRM Setting Up Pricing and Rating for general information. See "Using Provisioning Tags for Most-Called-Number Discounts" for specific information.

You define provisioning tags in the pin_config_provisioning_tags.xml file. The XML definition specifies the content of a /profile object. The data in the /profile object can be accessed by opcodes for use in discounting or rating.

You assign provisioning tags to discounts in Pricing Center by selecting the tag on the Detailed Discount Info tab of the Discount Attributes dialog box when you create a discount object. (See the Pricing Center Help for more information.) When a discount with a particular provisioning tag is purchased, BRM creates an instance of the /profile object defined by the provisioning tag.

You can use provisioning tags to configure multiple discounts for the same service. For example, you might want to provide one discount for the most-called numbers outside your network and another for the most-called numbers within your network. In this case, you could define two provisioning tags specifying different search and aggregation criteria.

About Setting Up Discounts

You set up discounts in Pricing Center. A complete discount comprises a number of different components that work together:

• A discount master, which filters EDRs based on their attributes to determine whether the charge packets should be discounted. See "Filtering EDRs for Discounting". You select the master to use when defining a discount rule.

• A discount trigger, which defines the conditions that must be met before a discount can take place. These conditions are based on balances and usage and can include charge, usage quantity, or number of events. For example, to apply a discount for usage over $100, the condition is that the account balance is greater than $100. See "Determining if Usage Qualifies for Discounting".

  Note:

  Not every discount configuration requires a trigger. Although you must include a trigger in the discount, you can configure the trigger to pass every EDR.

• A discount rule, which defines the type and amount of the discount. A discount is applied based on the amount or quantity of usage, which is defined by thresholds. The discount can impact multiple resource balances. See "Defining How Discounts Are Applied"

• A discount model, which links discount triggers and rules, grouping all the discount components together. See "Grouping Discount Components into Discount Models".

After you configure discount components, you add discounts to price lists. When adding a discount, you map discount models or discount model selectors to the events that are covered by the discount. See "Creating Discounts".

Figure 10-1 shows the relationships among the components of a discount:

Figure 10-1 Discount Component Relationships

Description of ''Figure 10-1 Discount Component Relationships''

Filtering EDRs for Discounting

You filter EDRs to determine whether they contain charge packets that are eligible to be discounted. You filter EDRs by creating discount masters that evaluate the event attributes. For example, you can use a discount master to filter for long distance calls made during off-peak time or for local SMS usage. You specify which master to use when you define a rule. See "Defining How Discounts Are Applied".

When discounting processes EDRs, it compares the data in the EDR to the data defined in the discount master. For example, if an EDR includes charge packets for an event that occurred at 6 a.m. and a discount master specifies a time range of 8 a.m to 5 p.m., those charge packets do not pass through the filter.

A discount master includes one or more discount details. The discount details specify the filter criteria. If a master includes more than one detail, an EDR must only pass through only a single detail to be discounted. An EDR must pass through all the criteria in at least one detail before it can be discounted.

You create discount masters and discount details in Pricing Center.

When you create a discount detail, you must enter a starting date. An end date is optional, as are starting and ending times. To pass the filter, the charge packets in the EDR must fall within the range of dates and times specified.

In addition to the date and time criteria, you can filter by the contents of many of the fields that appear in EDRs. For example, if you specify TEL for the Service Code field, all EDRs that pass the filter represent usage of the Telephony service.

You can enter either specific values or regular expressions for these criteria. The default value for most criteria is a dot followed by an asterisk (.*), which means that any value is valid. For more information, see "About Using Regular Expressions when Specifying the Data to Extract".

Because real-time events are not processed by the full rating pipeline, the following fields are not available for filtering real-time discounts. You should enter .* for these fields for real-time discounts:

• Time Model

• Time Period

• Service Code

• Service Class

• RUM

Figure 10-2 shows the Discount/ChargeShare Detail dialog box, which you use to specify filter criteria:

Figure 10-2 Discount/ChargeShare Detail Configuration

Description of ''Figure 10-2 Discount/ChargeShare Detail Configuration''

Determining if Usage Qualifies for Discounting

A discount might require usage or balances to reach certain levels before the discount is applied. In this case, you create a discount trigger to define the conditions that must be met before the discount can take effect. A trigger is linked to a specific discount rule in a discount model.

Not every discount configuration requires specific conditions to trigger the discount. For example, you may want discounting to process every EDR that passes through the discount master's filters. You must configure a discount trigger, but you can configure it to pass all EDRs.

Note:

Discounting does not evaluate charge packets that have both usage quantity as well as charge amount as 0, even if you configure the trigger to pass all EDRs.

A discount can be triggered in many different ways. For example:

• When a specified charge amount is reached; for example, after 50 US dollars worth of usage.

• When usage is less than a particular value; for example, when the number of international call minutes is less than 120.

• When a specified quantity has been reached; for example, a discount for the first 100 minutes and another discount for the second 100 minutes.

• When a specified number of events has occurred; for example, a discount for the first 100 downloads.

• When a combination of conditions are met; for example, for GPRS, when the bytes used is greater than 1 MB and the session duration is longer than 60 minutes.

• When a balance has available resources; for example, available free minutes that can be consumed.

When you define a discount trigger, you define one or more discount conditions. If a trigger includes more than one condition, all conditions must be met for the discount to take effect. For example, the trigger for a GPRS discount can include conditions that specify that the total charges in the EDR must be greater than $5 and that the total quantity of received data is greater than 10,000 bytes.

A condition is essentially a comparison of one value or amount to another. The comparison is based on an operator such as Greater than or Less than. If the comparison statement is true, then the condition is met.

A discount condition includes the following elements:

• A condition expression. The condition expression specifies the basis of the comparison. The expression can refer to a specific resource balance, total charges, or several other values. It can also include arithmetic operators and decimal constants. (See "Using Expressions in Discount Models".) The condition expression is evaluated, which results in a value that is used for the comparison.

• A condition operator. The valid operators are:

  • Greater than

  • Greater than or equal to

  • Less than

  • Less than or equal to

  • Equal to

  • Not equal to

• A condition value. This value is compared to the result of the condition expression by using the condition operator. For example, a condition value of 0 combined with a Greater than condition operator stores a positive number, which usually represents a charge to the customer. Conversely, a condition value of 0 combined with a Less than condition operator stores a negative number, which represents a credit balance.

You define discount triggers and conditions in Pricing Center.

Figure 10-3 shows the Discount/Charge Share Condition dialog box, where you define a condition for a discount trigger:

Figure 10-3 Discount/ChargeShare Condition Configuration

Description of ''Figure 10-3 Discount/ChargeShare Condition Configuration''

Defining How Discounts Are Applied

You define the type and amount of the discount as well as the balances that are impacted in discount rules. For example, a rule can specify that GSM usage up to 20 minutes be discounted 20% and that usage over that amount be discounted 35%.

When you set up a discount rule in Pricing Center, you define the following attributes:

• The rule itself. The rule defines the basic attributes, such as discount master to use for the rule, the DRUM (discount ratable usage metric) expression, the DRUM type, and the rule type. The DRUM defines the amount or quantity of usage to consider for discounting. For example, to discount a call made to a specific area code, the DRUM might be the total charge for that call. See "Defining the Usage Amount to Consider for Discounting".

• The balance impacts for each discount step. Discount steps define threshold values that affect the amount of discount applied. For example, you can define one step for the first 20 minutes of a call and a second for all usage over 20 minutes. Each step has one or more balance impacts that define which resource balances are affected by the discount and how the balances are impacted. For example, you can specify that the customer's balance of free minutes be debited by the length of the call and that charges for usage not covered by free minutes should be discounted by 10%. See "How Thresholds Define the Amount of Discount Applied".

Defining the Usage Amount to Consider for Discounting

The DRUM is the amount or quantity of usage to consider for discounting. The DRUM can specify several values:

• The total charge or quantity used from the EDR; for example, to discount a single call made to a friend or family member.

• An account's counter balance; for example, to apply a billing-time discount based on the total charges or total minutes used.

• A decimal constant. You typically use a decimal constant when the discount is applied regardless of the usage level; for example, to consume free minutes or apply a fixed discount amount such as 500 bonus points for purchasing a new service.

You enter the DRUM as an expression. The expression can include arithmetic operators and discount expressions. For example, to specify the charge in an EDR, you use the discount expression TotalC. To specify an account balance, you use the expression Bal(resource_ID). For more information, see "Using Expressions in Discount Models".

The DRUM expression is evaluated, resulting in a specific amount or quantity. This value is compared with the step thresholds to determine the balance impacts that are applied. Whether the DRUM can overlap a threshold or must fall entirely within it is determined by the rule type. The discount rule includes a Rule Type value, which can be set to either tiered or threshold. For more information, see "How Thresholds Define the Amount of Discount Applied".

You also choose the DRUM type, which can be either Charge or Quantity. This setting determines whether the DRUM and the threshold values are based on monetary charges or on quantities such as bytes.

For more information about possible DRUM values, see "How DRUMs, Steps, and Balance Impacts Work Together".

Figure 10-4 shows the Discount/ChargeShare Rule dialog box, where you specify discount rules and DRUM values:

Figure 10-4 Discount/ChargeShare Rule Configuration

Description of ''Figure 10-4 Discount/ChargeShare Rule Configuration''

How Thresholds Define the Amount of Discount Applied

The amount of discount applied can be based on any amount of usage, the total amount of usage, or portions of the usage. You define the usage levels by setting their threshold values in discount steps.

To discount one or more portions of the usage, you set up one or more steps in the same discount rule.

Note:

To apply different discounts to the same usage or to select from several possible discounts based on the usage amount, you create a discount model that includes multiple rules and triggers.

Each discount rule can have one or more steps. A step's threshold values determine when the step becomes effective. Each step in turn can have one or more balance impacts, which determine the amount of the discount and the balance that is impacted.

Note:

Threshold values for steps should not overlap.

For example, you could define these three steps for a GSM usage shown in Figure 10-5:

Figure 10-5 Example GSM Minute Usage Steps

Description of ''Figure 10-5 Example GSM Minute Usage Steps''

For each step, you define Threshold From and Threshold To values, which define the lower and upper limits of the step. The DRUM, which specifies the amount of usage to consider for discounting, is compared to the threshold values in the step. If the DRUM falls within a step's threshold, the discount balance impacts are applied for that step. In Figure 10-5, if the DRUM is the total length of a call specified in the EDR and the call lasted 10 minutes, the usage falls within step 1, so the balance impacts configured for step 1 are applied.

Threshold From must be a decimal value, but the Threshold To value can include an expression, typically to reference a balance; for example, the total charge in the charge packet. See "Using Expressions in Discount Models" for more information about expressions.

If the discount should be applied regardless of the level of usage, you specify the threshold as unlimited (0 to infinity).

Defining How Thresholds Are Interpreted

Determining if usage falls within a threshold depends on whether the discount rule type is Tiered or Threshold:

• In a tiered rule, the amount of usage specified by the DRUM can overlap the threshold values and still qualify for the discount in that step. For example, if the step threshold is 0 to 20 and the call lasts 30 minutes, the discount for that step is applied to 20 minutes of the call.

• In a threshold rule, the total usage must fall within the threshold to qualify for the discount in that step. For example, if the step threshold is 0 to 20 and the call lasts 30 minutes, the discount is not applied. If a second step has a threshold from 20 to 60, the discount for that step is applied to the entire 30 minutes of usage. Threshold rules are useful for applying discounts based on a count, such as the number of months a user has been a subscriber.

Prorating the Threshold Balance Impact

When you define a discount step, you can select options to prorate the balance impact for the amount that falls within the step threshold. These proration options apply only to discounts on cycle fees.

• The Prorate Purchase option enables you to choose how a discount should be prorated if a purchase event occurs during the accounting cycle.

• The Prorate Cancel option enables you to choose how the discount should be prorated if a cancellation event occurs during the accounting cycle.

For both proration options, you can choose to not apply the discount, to prorate the discount, or to discount for the entire cycle.

Figure 10-6 shows the Discount/ChargeShare Step dialog box, where you specify discount steps:

Figure 10-6 Discount/ChargeShare Step Configuration

Description of ''Figure 10-6 Discount/ChargeShare Step Configuration''

Defining the Threshold Balance Impacts

Discount balance impacts determine the actual discount amounts for a step as well as which balances are impacted. A step can have one or more balance impacts. Any resource balance can be impacted.

A discount balance impact can be a percentage or a fixed amount:

• A percentage discount changes the amount to discount by the percentage you enter.

• A fixed amount discount changes the amount to discount by an amount that you enter.

Balance impacts do not necessarily have to be a reduction of an amount like they are for a traditional discount. For example, you can configure a balance impact to award one loyalty point for every minute of usage. In this case, the balance of loyalty points increases as a result of the discount.

Some kinds of discounting require two or more balance impacts for each step. For example, if a discount includes free minutes, each step requires two balance impacts: one to discount the charge by 100% and another to reduce the free minutes balance to reflect the usage.

When you set up a discount balance impact in Pricing Center, you enter several different types of information:

• The ID of the resource that is impacted. Resources include currency, free minutes, and so on. You choose from a list of available resources.

• Whether the discount should be applied to the balances of the account that owns the event or the account that owns the discount. This is relevant when the discount is shared in a discount sharing group because the account that generates the usage can be different from the account that owns the discount. Choose Discount/ChargeShare Owner to apply the discount to the discount owner's balances. If the discount is not shared, the account that generates the usage is also the discount owner. For more information, see "About Shared Discounts".

• The base expression. This expression determines the basis of the discount calculation. The discount is calculated on the value in the base expression, and the resulting balance impact is applied to the account balance.

  The base expression can include a decimal value, an arithmetic expression, or a reference to a balance. To reference a balance, you use a discount expression. For example, the expression Bal(1234) references the account balance for the resource with ID 1234, and the expression StepC or StepQ respectively references the charge or quantity used in the charge packet. See "Using Expressions in Discount Models".

  Important:

  If multiple discounts can apply to an event and the discount type is Cascading, the base expression must be StepC or StepQ for all the discount balance impacts. If a different expression is used, discounting ignores that expression and chooses StepC or StepQ based on the resource type (currency or non-currency).

  When the EVAL token is used in discount base expressions, discounting does not consider the proration scale for evaluating the expression. The iScript function triggered by the EVAL token should use the prorate scale to calculate the return value. For example, if the iScript function returns the total cost value, the return value should be prorated based on the proration scale value.

  When the base expression references a specific resource balance, the resource in the base expression can be different from the resource that is impacted. For example, to add bonus points based on the minutes used, the base expression refers to an aggregation counter for all minutes used, and the resource to impact is the balance of bonus points.

  When the base expression references a specific resource balance, it always refers to the balance of the account that owns the discount.

  For more information about the values you can specify in the base expression, see "How DRUMs, Steps, and Balance Impacts Work Together"

• The discount amount or percentage. This value is applied to the value in the base expression to compute the discount. For example, a discount percentage is 10 and the base expression refers to a balance of 120. The 10% discount is calculated on 120, which results in a balance impact of 12.

  Enter a positive number to reduce the value of the resource impacted and a negative number to increase it. For example, entering 25% reduces the value; entering -25% increases it.

  A discount amount is an absolute value. If the discount is not based on the quantity of usage, the absolute discount amount is applied directly to the account balance. For more information, see "How DRUMs, Steps, and Balance Impacts Work Together".

• The beat, or discount increment. For example, to give a monetary credit for each 10 seconds of call usage, the beat is 10.

  Note:

  The beat is relevant only for amount discounts.

  The beat value determines whether the discount amount is based on the entire value in the base expression or to incremental portions of the base expression value:

  • If the beat is set to 0 or a negative number, the discount amount is applied to the balance. For example, to grant one bonus point for every SMS message sent, set the amount to 1 and the beat to 0. For this discount, you would specify the bonus point resource as the balance to impact. When the subscriber sends an SMS message, the SMS event triggers this discount and one bonus point is added to the account balance.

    Note:

    BRM cannot prorate usage discounts when the beat is set to 0. To prorate a fixed usage discount, use a recurring discount in a product.

  • If the beat is set to a positive number, the value in the base expression is divided by the beat value. The resulting number is then multiplied by the discount amount to arrive at the final discount. The discount calculation looks like this: discount balance impact = (Base Expression/Beat) *Amount.

    For example, the base expression references an account balance of 100 minutes of usage. The amount is 1 and the beat is 20 to apply a discount of 1 bonus point for every 20 minutes used. The base expression (100) divided by the beat (20) results in a value of 5. This value is multiplied by the discount amount (1) resulting in a balance impact of 5 bonus points.

    You can also apply the discount amount to portions of the usage by using a mathematical expression in the base expression. For example, if Bal(1000002) references the account balance of 100 minutes, to apply 1 bonus point for every 20 minutes used, the base expression is Bal(1000002)/20. For more information, see "Dividing Base Expressions into Increments".

• Whether to prorate the discount amount for partial beats. For example, if you give a credit of 10 free downloads for every 100 calls, you can credit 5 free downloads for every 50 calls. If you do not specify to prorate the discount, a partial beat is counted as a whole beat, and the full amount of the discount is applied.

• Whether to grant or consume the resource impacted:

  • Select Consume to consume a non-currency resource such as free minutes or to discount a currency resource.

  • Select Impact only to grant a non-currency resource. You specify the period during which the resource granted, such as free minutes, can be consumed. You can set the resource validity period to start immediately, on a date relative to the grant date, or when the subscriber consumes the resource for the first time (on first usage). For information about resources that start on first usage, see "About Balance Impacts That Become Valid on First Usage" in BRM Setting Up Pricing and Rating.

• Financial information, such as the tax code, general ledger (G/L) ID code, and impact category.

• An optional event balance ID. Entering an event balance ID creates a temporary event balance that stores the discount balance impact. The balance impact is not applied to the account balance. You use event balances when you need the results of one discount to calculate another discount. The event balance can be referenced in expressions that you use in discount rules, conditions, and subsequent balance impacts. See "Using Event Balances in Discounts" for more information.

Figure 10-7 shows the Discount/Charge Share Balance Impact dialog box, where you specify the balance impacts for the step:

Figure 10-7 Discount/ChargeShare Balance Impact Configuration

Description of ''Figure 10-7 Discount/ChargeShare Balance Impact Configuration''

How DRUMs, Steps, and Balance Impacts Work Together

The values you enter in the components of a discount rule are interdependent and are based on the type of discount you are creating. For information about possible values, see the following topics:

• How the DRUM Value, Step Thresholds, and Rule Type Determine the Discount that Is Applied

• Determining the Number of Steps Needed

• Referencing Account Balances in Base Expressions

• Using Absolute Values in Base Expressions

• Dividing Base Expressions into Increments

• Determining the Discount Amount

How the DRUM Value, Step Thresholds, and Rule Type Determine the Discount that Is Applied

The DRUM expression should be set to the amount of usage that is being considered for discounting, which can be either a charge (currency) or a quantity (non-currency) value.

To reference the amount of usage in consideration, enter one of the following values as the DRUM expression:

• TotalC, which evaluates to the total charge in the EDR.

• TotalQ, which evaluates to the total quantity used in the EDR.

• Bal(resource_ID), which references the account's aggregation balance, such as the total minutes used or total accumulated charges.

  Note:

  Currency balances are not loaded into Pipeline Manager memory; therefore, you cannot directly retrieve an account's currency balance for discounting. If the DRUM refers to an account balance, it must be a non-currency balance.

The value of the DRUM expression is then compared with the step thresholds to determine which balance impacts to apply. This is a two-step process:

1. BRM determines which discount steps qualify for discount evaluation. The steps that qualify will have their discounts applied to the account. The type of rule determines whether more than one step can qualify:

   • For a tiered type rule, all steps with a threshold range that overlaps the DRUM range qualify. The DRUM range is 0 to the DRUM value.

     For example, if the DRUM expression evaluates to a quantity of 100 (the DRUM range is 0 to 100):

     - Step 1 with a threshold of 0 to 60 qualifies for evaluation.

     - Step 2 with a threshold of 60 to 120 also qualifies for evaluation.

     - Step 3 with a threshold of 120 to infinity does not qualify for evaluation.

   • For a threshold type rule, only the step with a threshold range that encompasses the DRUM value qualifies for discount evaluation.

     For example, if the DRUM expression evaluates to a quantity of 100:

     - Step 1 with a threshold of 0 to 60 does not qualify for evaluation.

     - Step 2 with a threshold of 60 to 120 qualifies for evaluation.

     - Step 3 with a threshold of 120 to infinity does not qualify for evaluation.

2. BRM determines the amount of usage that receives the discount in each qualifying step by checking the value of the base expression. The value of the base expression also depends on the type of rule:

   • For a tiered type rule, the base expression is typically either StepC or StepQ. In this case, the value of StepC or StepQ is the portion of the DRUM range that intersects with the step's threshold range. The step's discount is applied to that amount. For more information, see "Referencing Steps in Base Expressions".

     For example, if the DRUM expression evaluates to a value of 100 (the DRUM range is 0 to 100):

     - Step 1 with a threshold of 0 to 60 qualifies: StepC or StepQ evaluates to 60 and Step 1's discount is calculated on 60 units (such as seconds, minutes, or bytes).

     - Step 2 with a threshold range of 60 to 120 also qualifies: StepC or StepQ evaluates to 40 (100 - 60 = 40) and Step 2's discount is calculated on 40 units.

     - Step 3 with a threshold range of 120 to infinity does not qualify, so its discount balance impacts are not applied.

   • For a threshold type rule, the base expression is typically TotalC, TotalQ, or Bal(resource_ID). In this case, the discount balance impacts of the qualifying step are calculated on the entire amount in the base expression.

     For example, if the DRUM expression evaluates to a value of 100:

     - Step 1 with a threshold of 0 to 60 does not qualify, so its discount balance impacts are not applied.

     - Step 2 with a threshold range of 60 to 120 qualifies: Step 2's discount is calculated on the entire amount of TotalC, TotalQ, or Bal(resource_ID).

     - Step 3 with a threshold range of 120 to infinity does not qualify, so its discount balance impacts are not applied.

     Discounts with threshold rules typically apply to the entire amount of a balance: for usage discounts, the total charge (TotalC) or quantity (TotalQ) in the EDR; for billing-time discounts, an account's aggregation balance (Bal(resource_ID)). You do not use StepC or StepQ in the base expression for threshold discounts because this would calculate the discount on only part of the usage rather than the entire usage.

Determining the Number of Steps Needed

At the discount step level, you never need to completely disqualify the entire usage from discounting. Therefore, you set up steps so that the usage falls within at least one step. You use different steps for three types of usage levels:

• To apply a discount for any amount of usage, use only one step with a threshold that is unlimited (from 0 to infinity). In this case, any positive amount specified by the DRUM falls within the threshold and the balance impact is applied without regard to the amount of usage.

  This step is useful for one-time discounts that do not depend on usage; for example, a $15 credit for the purchase of an extra handset. This step can also be used for billing-time or usage discounts when the discount is applied to the entire balance. For example, you can apply a promotional discount of 30% off all usage in the first six months. In this case, the base expression refers to the total usage balance. (See "Referencing Account Balances in Base Expressions".)

• To apply a discount for the total amount of usage, use one step and reference the balance containing the total usage (such as the total charge or number of seconds in the charge packet) as the Threshold To value. In this case, the DRUM specifies the minimum amount of usage required. For example, to consume free seconds, only one second of usage is required. To provide 10% off for usage over $100, the minimum amount is 100.

  This step is useful for consuming free seconds, discounting calls within specific networks, and applying discounts such as bonus points based on the total usage.

• To apply different balance impacts to different portions of the usage, use multiple steps. This is the only case in which you need multiple steps. In this case, the DRUM typically references the balance containing the amount or quantity of usage. For example, a discount that grants bonus points for usage up to 180 minutes, and 10% off for usage over 180 minutes, has two steps, and the DRUM references the account balance containing the total count of minutes used.

Referencing Steps in Base Expressions

When you use a step with a specific threshold because the amount of usage is significant, you always reference the amount from the step in the base expression. By referencing the step, you calculate the discount on the amount of usage that falls within the step threshold.

To reference the step, you enter the discount expression StepC if the resource to impact is currency or StepQ if the resource to impact is non-currency. StepC evaluates to the currency charge for the amount that falls within the step threshold. StepQ evaluates to the non-currency quantity that falls within the step threshold.

For example, in a tiered rule, the DRUM is 120 minutes and the step threshold is between 0 and 60. A base expression of StepQ evaluates to 60 minutes because that is the amount of the usage (the DRUM) that falls within the step threshold. The discount is then calculated for a value of 60 and the resulting balance impact applied to the account balance.

Referencing Account Balances in Base Expressions

You refer to an account balance in the base expression to calculate the discount for the entire balance. For example, to grant a billing-time discount of 10 bonus points for every 60 minutes of usage, you reference the total usage balance. In this case, any amount of usage is considered, so the DRUM is 1 and the step threshold is unlimited.

Using Absolute Values in Base Expressions

When the discount is an absolute amount that is applied regardless of the usage level, the base expression can be any positive number because you do not need to calculate the discount. For example, to apply a promotional discount of 50 free minutes for the first six months, The DRUM is 1, the threshold unlimited, and the base expression is 1. The discount amount (50 free minutes) is then applied directly to the resource balance.

Dividing Base Expressions into Increments

There are two ways you can apply a discount amount to portions of the usage. For example, to grant 10 frequent flyer miles for every hour of telephony usage, use one of the following methods:

• Specify a beat value. If you use a beat, you enter the following values:

  • The base expression is Bal(total_usage); the balance that tracks the total minutes used.

  • The beat is 60 (assuming the resource is minutes).

  • The discount amount is 10.

  • The balance to impact is the resource of frequent flyer miles.

• Use mathematical operators in the base expression. In this case, you enter the following values:

  • The base expression is Bal(total_usage)/60: the total minutes used divided by 60.

  • The beat is 1.

  • The discount amount is 10.

  • The balance to impact is the resource of frequent flyer miles.

In both of the above examples the discount calculation is the same. For example, if the balance of total minutes used is 300, the discount calculation is (300/60) * 10 = 5.

Determining the Discount Amount

When the discount is a percentage, the percentage is multiplied by the value in the base expression to determine the balance impact.

When the discount is an absolute amount, that amount can be one of the following:

• The actual amount that should be applied to the account balance. For example, to grant 100 free minutes as a birthday bonus, the amount is 100.

• An amount that should be applied to portions of the usage. For example, to grant 10 frequent flyer miles for every hour of usage, the amount is 10 and the beat is 60 (assuming the resource is minutes).

• An amount that should equal the usage. For example, to consume one free minute for every minute used, the amount is 1 and the beat is 1. This is also useful for copying an account balance into a temporary event balance. (See "Using Event Balances in Discounts".)

Grouping Discount Components into Discount Models

A discount model links discount triggers with discount rules. Each discount model can have one or more discount versions, which are defined by validity periods. Only one version can be valid at any one time. During rating, BRM uses the discount model version that is valid at the time the discounted event occurred.

Each version includes one or more discount configurations. A discount configuration associates a trigger with a discount rule for a particular discount model version. When all of the trigger's conditions are met, the discount rule is evaluated for eligible EDRs.

Note:

A trigger is not required in a configuration. If you want discounting to process all EDRs that pass through the discount master associated with a rule, do not include a trigger in the configuration.

You create different discount configurations to provide various types of discounts; for example, discounts that provide a percentage off and discounts for consuming free minutes.

You can mix and match rules and triggers to meet your business needs. You can use the same rules and triggers in more than one model. You select the model you need when you create the purchasable discount. See "Creating Discounts".

When you set up a discount model configuration, you specify whether it is cascading, parallel, or sequential. This setting and the cascading/parallel/sequential setting in the /discount object determine whether discounts are applied to values from the entire charge packet or only to the amount not yet discounted.

For example, if an EDR meets the conditions for two discount configurations that are set for cascading, discounting first applies the discount configuration that has a rule with the highest priority. If there is still an amount left in the discount balance account, the discount configuration that has a rule with the second highest priority is applied.

Note:

Cascading discounts are designed for discounts that consume non-currency resources or that discount currency charges, not for discounts that grant resources.

For more information, see "About Cascading, Parallel, and Sequential Discounts".

Figure 10-8 shows the Discount Model Configuration dialog box:

Figure 10-8 Discount Model Configuration

Description of ''Figure 10-8 Discount Model Configuration''

Prioritizing Discount Model Components

You can prioritize the order in which discounting evaluates certain discount model components:

• Discount details in a discount master

• Discount steps in a discount rule

• Discount model configurations in a discount model version

For each charge packet, discounting evaluates the ranked components in order and Uses the first one that is valid.

Creating Discounts

When you create a discount in Pricing Center, BRM creates a /discount object. The /discount object is the top-level discounting component and links together the other components.

Discount objects are purchasable items similar to products. You include them in deals along with products.

You can create the following types of discount:

• Subscription

• System

When you create a discount object, you specify which events are covered by the discount. For example, you can include the following events:

• Delayed GSM Session Event

• Monthly Cycle Forward Event

For each event, you choose either a discount model or discount model selector that will be used to discount the event. For example, for the Delayed GSM Session Event, you could choose a discount model that supplies free minutes; for the Monthly Cycle Forward Event, you could choose a model that applies a percentage discount. See "Grouping Discount Components into Discount Models" for more information.

You map events to discount models and model selectors in the Map an Event to a Discount Model/Model Selector section of the Discount Attributes dialog box in Pricing Center.

You can also flag an event for inclusion in a discount that is used to distribute the results of a discount among group members. See "About Snowball Discounts".

Other attributes you specify for discount objects include the following:

• The purchase level. This determines whether the discount applies to events related to all services owned by the account or only to a specific service.

• How to handle multiple discounts. See "About Cascading, Parallel, and Sequential Discounts".

• The discount priority. When an account owns more than one discount, the priority determines the order in which they are processed.

• Whether to continue discounting if the discount is canceled or inactivated.

• (Optional) A provisioning tag. You can use a provisioning tag to configure a discount's service with additional information. For example, you can use a provisioning tag to create an extended rating attribute (ERA). See "Working with Provisioning Tags" in BRM Setting Up Pricing and Rating.

• Start and end dates.

• Discount quantity allowed.

• Ownership quantity allowed.

• Whether the discount is valid for the entire month or only part of the month when it is purchased or canceled mid-cycle. See "Prorating Discount Balances".

• Whether the discount can be purchased with other discounts or whether it is mutually exclusive of other discounts. See "About Discount Exclusion Rules". You define discount exclusion rules in the Discount Restrictions tab of the Discount Attributes dialog box.

If a rate plan has discounts, enable the Override Credit Limit option for the rate for all products in Pricing Center.

Caution:

If an event can be discounted but the required resources to rate the event exceed the available resources and the Override Credit Limit option is not enabled, the rating engine does not rate the event correctly. If the available currency resource is 0, the rating engine fails with the "Credit limit exceeded" message without applying the available discounts.

You define discount objects in the Discount Attributes dialog box in Pricing Center, as shown in Figure 10-9:

Figure 10-9 Discount Attributes Configuration

Description of ''Figure 10-9 Discount Attributes Configuration''

For more information, see "Defining a Discount Based on the Number of Subscriptions".

Prorating Discount Balances

When you use BRM to manage customers, you can create or change a customer's discount balance. When you do so, you often need to prorate the discount balance to handle changes that do not coincide with the customer's accounting cycle; for example:

• If the account creation date is different from the billing day of month, the customer will have a partial accounting cycle. For example, if the account is created on July 15, but the billing day of month is the 1st, the customer has a partial accounting cycle of 15 days. If you give 100 free minutes per month, you can prorate those free minutes and give only 50 free minutes for the partial accounting cycle.

• If customers change a service in the middle of an accounting cycle, they might purchase different discounts. In that case, you can cancel the existing discount balance and delete the prorated amount.

For information about the proration settings, see "About Applying Discounts Activated or Canceled in Mid-Cycle".

For information about how BRM calculates prorated cycle fees, see "Calculating Prorated Cycle Fees" in BRM Configuring and Running Billing.

You define discount validity rules in the Detailed Discount Info tab of the Discount Attributes dialog box.

Using Expressions in Discount Models

You can use expressions when defining several different discount model components. Unlike a normal value that is written directly into the database, an expression is evaluated by BRM to produce a value.

For example, if you enter Bal(444) into a field, this expression is evaluated to mean the current balance of the resource with ID 444.

An expression can include more than one token or individual element. For example, if you use a discount to provide one free SMS message for every 100 minutes of telephony usage, the discount balance impact could include the expression Bal(1001)/100, where Bal(1001) refers to the current total of telephony minutes.

Note:

Currency balances are not stored in Pipeline Manager memory; therefore, you cannot reference an account's currency balance in a discount expression. If you need to use an account's currency resource to calculate a discount, set up an aggregation counter and use a separate discount to update the counter balance when usage occurs. You can then use this counter balance to calculate the discount amount.

You can use expressions when defining discount conditions and rules:

• Discount condition

  You use a discount expression in the Condition Expression field. For example if the discount consumes free minutes, you use the Bal(resource_ID) expression to reference the account balance that contains those free minutes. You can then use the condition to check whether there are free minutes available for consumption.

  If you grant a percentage off for all usage over 300 minutes, the condition expression can reference the account balance that contains the total number of minutes used. You can then use the condition to check that the subscriber used over 300 minutes to qualify for the discount.

  For more information about conditions, see "Determining if Usage Qualifies for Discounting".

• Discount rule

  In a discount rule, you can use an expression when defining the DRUM, steps, and balance impacts:

  • DRUM

    You can use a discount expression in the DRUM Expression field. If the amount of usage is relevant to the discount (defined by limiting the step threshold), the DRUM refers to the usage balance. This can be the total usage in the EDR or an account's counter balance.

    For example, to discount calls made within a specific network, use the expression TotalC, which evaluates to the total charge in the EDR. To consume free minutes, use the expression TotalQ, which evaluates to the total quantity used in the EDR.

    To apply a billing-time discount based on the total usage, use the expression Bal(resource_ID) to refer to the account's usage balance; for example, the aggregation balance that tracks total charges.

    For more information about DRUMs, see "Defining the Usage Amount to Consider for Discounting".

  • Step

    You can use a discount expression in the Threshold To field. This is typical when the usage amount is relevant but there is only one step. For example, when a discount consumes free minutes, you use the Bal(resource_ID) expression to refer to the account's balance of free minutes. This limits the consumption to the amount in the balance.

    For more information about steps, see "How Thresholds Define the Amount of Discount Applied".

  • Balance Impacts

    You can use a discount expression in the Base Expression field. The base expression is the amount for which to calculate the discount. You can reference a non-currency account balance or the amount of usage that falls within the step threshold. You always use the amount from the step when the Threshold To value is specific (not unlimited).

    To refer to an account balance, use the expression Bal(resource_ID). To refer to the amount from the step, use the expression StepC or StepQ. StepC evaluates to the currency charge for the amount that falls within the step threshold. StepQ evaluates to the non-currency quantity that falls within the step threshold.

    For example, to apply a billing-time discount based on the total usage for the month, the base expression refers to the account balance (Bal(resource_ID)) that tracks the total usage. To reduce a balance of free minutes by the number of minutes used, the base expression is StepQ (the number of minutes used that fall within the step threshold). To discount the currency balance for free minutes used, the base expression is StepC (the charge for the minutes used that fall within the step threshold).

    Important:

    If multiple discounts can apply to an event and the discount type is Cascading, the base expression must be StepC or StepQ for all the discount balance impacts. If a different expression is used, discounting ignores that expression and chooses StepC or StepQ based on the resource type (currency or non-currency).

    For more information about balance impacts, see "Defining the Threshold Balance Impacts".

Using Event Balances in Discounts

An event balance stores the results of a discount balance impact for a single event. You use event balances when you need the results of one discount to calculate another discount for the same event. This is useful when:

• Sharing discounts or applying a discount to one account based on a balance from another account. For example, one discount records the number of minutes used by account A and stores it in an event balance. A second discount reduces the number of free minutes in account B based on the amount in the event balance. In this example, the event balance is passed between separate discounts.

• Applying discounts based on two or more attributes of the EDR. For example, one discount records the number of minutes used and stores it in event balance 1. A second discount records the number of bytes sent and stores it in event balance 2. A third discount calculates the discount based on the values in event balance 1 and 2. In this example, the event balance is passed between several discount configurations in the same discount. For a complete description of this example, see "Example of Using Event Balances to Discount Based on Multiple EDR Attributes".

Unlike other balances, event balances are temporary. They are maintained only while a single event is in the process of being discounted. Balance impacts stored in event balances are not included in the discount packet that records the results of a discount. If multiple discounts are applied to a single event, the event balance is maintained until all the discounts are processed. However, for billing-time discounts, event balances are only maintained while a single discount is processed. See "Using Event Balances in Billing Time Discounts".

Because the balance impact in an event balance is not applied to account's resource, it does not matter whether you select to impact the event owner or the discount owner, or whether to impact or consume the resource when you define the discount balance impact. For more information, see "Defining the Threshold Balance Impacts".

Just as with other balances, you can use event balances in expressions that determine whether an event qualifies for discounting and how the discount is calculated. For example, a discount condition can include an event balance expression that requires GPRS usage in a event to be greater than 1 MB. In this example, the event balance stores the number of bytes used. (See "Determining if Usage Qualifies for Discounting" for information about discount conditions.)

The way you reference event balances is different from the way you reference other balances, however. Before referencing an event balance, you must define it. You define event balances in discount balance impacts by entering an ID in the Event Balance ID field. Specifying an ID in this field causes an event balance with that ID to be created when the balance impact is processed.

You reference an event balance by using the EBal expression with the appropriate ID number. For example, if you create an event balance with the ID 99, you reference it with the expression EBal(99). (See "Using Expressions in Discount Models".) You can reference the event balance in the same fields that can take discount expressions: in conditions, steps, and balance impacts.

Using Event Balances in Billing Time Discounts

You cannot use event balances for billing-time discounts to pass a balance impact from one discount object to another. Event balances are deleted at the end of the discount transaction. When discounting usage events, all discounts for that event are processed in the same transaction. However, for billing events, each discount associated with the event is processed in a separate transaction; therefore, the event balance is deleted after the discount that creates the event balance is processed.

Example of Using Event Balances to Discount Based on Multiple EDR Attributes

An EDR can potentially include many different charge packets containing charges and amounts for several different ratable usage metrics (RUMs), such as duration or bytes received. To narrow the scope of the event balance, you use discount masters to filter in the charge packets you want. This capability is illustrated in the following example.

You can create a 10% discount on total charges for GPRS usage when the session duration is 60 minutes or longer and the number of bytes sent or received is 1 MB or greater. This example uses two event balances: one records the minutes used and another records the number of bytes sent or received.

This discount requires a discount model with three discount configurations:

• In the first configuration, you filter in charge packets that record the event duration and then save that duration in an event balance. To filter in charge packets recording duration, you create a master that specifies duration as the RUM.

  In the balance impact for the step and rule associated with the master, you create an event balance, EBal(1). You configure the rule and balance impact to record the total quantity in the charge packet that passed the filter by setting the following values:

  • In the rule, set the DRUM expression to TotalQ, or the total quantity in the charge packets that passed the filter. (In this case, TotalQ reflects the duration of the event.)

  • Make the step threshold unlimited.

  • Set the discount amount to 1 and specify a beat of 1.

  A trigger is not necessary in this configuration.

• In the second configuration, you filter in the bytes sent and received, then record them in a second event balance, EBal(2). You set up the second configuration in the same way you setup the first, except that you specify bytes as the RUM and supply a different event balance ID.

• In the third configuration, you set up a master to filter in all EDRs for the GPRS service. You also set up a trigger with two conditions. One condition specifies that EBal(1) must be greater than or equal to 60 and the second specifies that EBal(2) must be greater than or equal to 1024. The balance impact for the rule and step triggered by these conditions discounts the total charges (TotalC) by 10%.

Using Provisioning Tags in Discounts

You can use custom provisioning tags to include ERAs in discounts. This enables you to vary the discount based on an attribute of an event.

Important:

You cannot use provisioning tags with discounts for telco services.

When creating discounts in Pricing Center, you choose the provisioning tag on the Detailed Discount Info tab of the Discount Attributes dialog box as shown in Figure 10-10:

Figure 10-10 Provisioning Tag Configuration in Detailed Discount Info Tab

Description of ''Figure 10-10 Provisioning Tag Configuration in Detailed Discount Info Tab''

You use provisioning tags to specify opcodes to run and parameters for the opcodes to use when a discount is purchased and canceled. For example, a provisioning tag can create a custom profile used in a discounting policy, such as an ERA.

To create provisioning tags, see "Working with Provisioning Tags" in BRM Setting Up Pricing and Rating.

About Discount Model Selectors

A discount model selector chooses a discount model during rating based on specific values in an EDR. This enables you to provide discounts of different amounts for different scenarios in a single discount object.

You can use discount model selectors to apply preferential, promotional, or other selective discounts based on EDR characteristics.

The elements of a discount model selector, and the relationship between them, are as follows:

• A discount model selector contains one or more configurations. You rank the configurations in the order in which you want Pipeline Manager to evaluate them.

• A configuration maps a price/discount model selector rule to a discount model. Each configuration has a validity period.

Figure 10-11shows the Price Model Selector Configuration dialog box, where you map a price/discount model selector rule to a discount model.

Figure 10-11 Price Model Selector Configuration

Description of ''Figure 10-11 Price Model Selector Configuration''

• A price/discount model selector rule associates an EDR field with a specific value. A rule can contain one or more such associations, all of which are logical ANDs and must be in the EDR for the rule to be satisfied.

Figure 10-12 shows the Price/Discount Model Selector Rule dialog box, where you associate an EDR field with a specific value.

Figure 10-12 Price/Discount Model Selector Rule Configuration

Description of ''Figure 10-12 Price/Discount Model Selector Rule Configuration''

Note:

• You can use any EDR field that is defined in the data dictionary except EDR fields that have the data format of Block.

• You use the same price/discount model selector rules for both discount model selectors and price model selectors.

Pipeline Manager evaluates the configurations in a discount model selector in the order in which you rank them. When a rule in a configuration is satisfied (that is, when the specified EDR fields contain the specified values), Pipeline Manager uses the discount model that is mapped to that rule and ignores any configurations that are ranked lower. If an EDR does not contain the specified values, it does not qualify for the associated discount.

You set up discount model selectors in Pricing Center.

You also need to configure the Pipeline Manager DAT_ModelSelector module. See "DAT_ModelSelector".

Example of Using a Discount Model Selector

In this example, you rate a discount model selector to apply a specific discount model only to EDRs for particular roaming partners.

The following are the overall steps for setting up this example:

1. Create and configure a discount model that gives the discount you want to apply.

2. Create a price/discount model selector rule that maps the EDR fields DETAIL.SOURCE_NETWORK and DETAIL.TARIFF_CLASS to the names of the network and the tariff class that qualify for this discount.

   Create as many rules as you need to represent all the roaming partners to whom you want to apply this discount.

3. Create a discount model selector that maps the discount model you created to the rules you defined.

4. In the price list, add a discount with a discount usage map that maps your discount model selector to the event to which the discount applies.

5. Create a customer to purchase the discount you created.

When an EDR for this customer is for both the destination network and tariff class in the rule, the rule is satisfied and the associated discount model is used. EDRs that do not contain both these pieces of information do not qualify for this discount.

About Cascading, Parallel, and Sequential Discounts

The same EDR can be eligible for discounting by multiple discounts and by multiple discount configurations within each discount. For example, two different discounts can be applied to the same event type. Similarly, within a discount model, filters and conditions can pass the same EDR to multiple discount model configurations for processing.

You use the Multiple discounts per event setting (Cascade, Parallel, or Sequential) at the discount object level and the Cascading, Parallel, or Sequential setting at the discount model configuration level to determine how EDRs should be processed when multiple discounts and configurations apply. For more information, see "Creating Discounts" and "Grouping Discount Components into Discount Models".

These multiple discount types work as follows:

• Cascading discounts are evaluated so that no part of the charge packet is used as the basis for more than one discount. A cascading discount can be used only if part of the charge packet has not yet been evaluated for a discount. In general, cascading results in smaller discounts.

  Note:

  Cascading discounts are designed for discounts that consume non-currency resources or that discount currency charges, not for discounts that grant resources. If you specify Cascading for a discount, you must also configure the discount balance impact to consume available resources, otherwise the discount calculated will be incorrect.

• Parallel discounts are evaluated independently of each other. The entire charge packet is discounted, regardless of whether it has been discounted previously. In essence, discounting starts over from the beginning for each discount. This usually results in larger discounts.

• Sequential discounts are applied as long as a customer charge remains. The size of these discounts usually falls between those of cascading and parallel, but not always. This always reduces the customer charge, irrespective of whether the discount value is negative or positive.

Examples of Using Multiple Discount Types

To understand how the cascading/parallel/sequential setting works at the discount object level, consider the following two examples:

• A customer has purchased a deal that includes two discounts that apply to GSM usage. Usage is $0.10 per minute. One discount has a higher priority, provides a 10% discount, and is present in the cascaded mode. The other discount applies a 20% discount to all GSM usage charges. The customer makes a 100-minute ($10) call.

  The 10% discount is processed first because it has a higher priority. The call is discounted 10%, resulting in a $1 discount.

  • If the second discount is set to Cascading, no further discounts apply because the entire charge packet has already been evaluated by the previous discount. The total charge for the call is $9.

  • If the second discount is set to Parallel, it applies the 20% discount to the entire charge packet, resulting in a second discount to the entire 100-minute event. This results in another discount of $2, which is combined with the first discount of $1, for a total charge of $7.

  • If the second discount is set to Sequential, it applies to the remaining charge, which is $9. The second discount is 20% of $9, or $1.80. The discounts combine for a total charge of $7.20.

• Another customer makes a 100-minute call ($10), but that customer's deal has different discounts. The first discount is 50 free minutes, and the second discount is 20% off all minutes.

  The first discount, which has the highest priority, is processed first. The discount determines that there are 50 minutes that can be provided for free and provides them.

  • If the second discount is set to Cascading, the customer gets 20% off the remaining portion (50 minutes) and so pays a total charge of $4. The cascading discount applies in this example because the first discount did not evaluate the entire charge packet.

  • If the second discount is set to Parallel, it applies the 20% discount to the entire 100 minute call, even though there was no charge for the first half. The discount is 20% of $10. This results in another discount of $2. The total charge for the call is $3.

  • If the second discount is set to Sequential, it applies to the remaining charge, which is $5, resulting in a charge of $4. In this case, the final charge to the customer is the same as that provided by a cascading discount.

Examples of Using Discount Configurations in Discount Objects

Within a discount model, the Cascading, Parallel, and Sequential settings in the discount model configuration work the same way as the Cascade/Parallel/Sequential setting in discount objects. If the discounts in the previous examples were included in two configurations within the same model, the results would be the same as they are for separate discounts.

The discount type settings on discount objects and the discount model configurations they include can differ. The discount configuration settings (particularly cascading) in one object affect the way that discounts are evaluated by configurations in subsequent objects. The complex discounting structures such as those described below are not typical, but may help you understand the implications of your settings.

Consider a scenario that includes two discount objects, one with two discount configurations.

• Discount Object 1: any type

  • Discount Configuration A: 10% off if the charge is between $0 and $60

• Discount Object 2:

  • Discount Configuration B: 20% off

  • Discount Configuration C: 10% off

  • There is a charge of $100.

The following examples show how the discounts are calculated differently depending on whether:

• Discount Configuration A is set to Cascading, Parallel, or Sequential.

• Discount Object 2 is set to Cascading, Parallel, or Sequential.

• The configurations included in Discount Object 2 are set to Cascading, Parallel, or Sequential.

Example one

Consider the following objects and configurations:

• Discount Object 1: any type

  • Discount Configuration A: any type

• Discount Object 2: Parallel

  • Discount Configuration B: Sequential

  • Discount Configuration C: Sequential

The following rules apply:

• Discount Configuration A applies to charges up to $60, so only $60 is considered for discount. The discount is 60 * 10% = $6.

• Discount Object 2 is parallel, so it ignores previous discounting and applies to the original amount of 100 minutes and charge of $100.

• Discount Configuration B is sequential so it applies to the entire charge evaluated by Discount Object 2. The discount is 100 * 20% = $20.

• Discount Configuration C is sequential so it applies to the charge that remains after Discount Configuration B is applied, 80.00 * 10% = $8.

The final charge is $66.

Example two

Consider the following objects and configurations:

• Discount Object 1: any type

  • Discount Configuration A: Cascading versus Parallel or Sequential

• Discount Object 2: Cascading

  • Discount Configuration B: Cascading

  • Discount Configuration C: Parallel

The following rules apply:

• Discount Configuration A discounts on charges up to $60, (that is, only $60 is considered for discount). The discount is 60 * 10% = $6. The remaining charge is $94 (100 - 6).

• Discount Object 2 is cascading, so only the part of the charge packet that has not been evaluated yet is considered for discount.

• Discount Configuration B is cascading. The application of a cascading discount changes if a cascading configuration discount has already been applied.

  If Discount Configuration A is parallel or sequential, the basis for Discount Configuration B is 94.00 * 20% = $18.80.

  However, subsequent cascading discounts apply to the part of the charge packet that has not been evaluated for discount. If Discount Configuration A is cascading, the basis for Discount Configuration B is 40 * 20% = $8.

• Because Discount Configuration C is parallel, it applies to the full amount of the charge packet that Discount Object 2 evaluates.

  If Discount Configuration A is cascading, Discount Configuration C provides 40 * 10% = $4.

  If Discount Configuration A is parallel or sequential, Discount Configuration C provides 94 * 10% = $9.40.

The final charge possibilities are $82 (if Discount Configuration A is cascading) or $65.80 (if Discount Configuration A is parallel or sequential).

Example three

Consider the following objects and configurations:

• Discount Object 1: any type

  • Discount Configuration A: cascading versus parallel or sequential

• Discount Object 2: sequential

  • Discount Configuration B: sequential

  • Discount Configuration C: cascading

  The following rules apply:

  • Discount Configuration A discounts on charges up to $60, so only $60 is considered for discount. The discount is $60 * 10% = 6. The remaining charge is $94 (100 - 6).

  • Discount Object 2 is sequential, so it applies to the remaining amount of $94.

  • Discount Configuration B is sequential, so it applies to the entire remaining charge. The discount is $94 * 20% = 18.80. The remaining charge is $76.20.

  • Discount Configuration C is cascading, but it is in a sequential object. If a cascading configuration discount is in a parallel or sequential discount object, the cascading configuration applies to parts of the charge packet that have already been evaluated.

    If Discount Configuration A is parallel or sequential, Discount Configuration C provides 76.20 * 10% = $7.62.

    If Discount Configuration A is cascading, the discount for Discount Configuration C is based on the amount remaining from Discount Configuration A; that is 100 - 60 = $40. Subtract from this amount the discount by Discount Configuration B, 40 - 18.80 = $21.20. Discount Configuration C provides 21.20 * 10% = $2.12.

The final charge possibilities are $74.58 (if Discount Configuration A is cascading) or $68.58 (if Discount Configuration A is parallel or sequential).

Sequential Discounting of Cycle Fees

Sequential discounting of cycle fees is a process that evaluates cycle fee discounts that are purchased or canceled mid-cycle in conjunction with other discounts that are valid during the same period. BRM applies all discount exclusion rules that are in effect at the time of this evaluation.

The process refunds all cycle fee discounts already charged from the point when the discount purchase or cancellation occurs. BRM then reapplies all remaining and any new cycle fee discounts from that point to the end of the cycle.

To accomplish this reevaluation, BRM divides a cycle (internally) into subcycles based on where discounts start and end. Discounts and exclusion rules are then applied for each subcycle. Both refunds and charges are determined based on the subcycles.

Although this process is run for all cycle fee discounts that are purchased or canceled mid-cycle, it can change the outcome only for sequential cycle fee discounts that are prorated. For general information about cycle fee proration, see "Calculating Prorated Cycle Fees" in BRM Configuring and Running Billing.

In essence, this process reevaluates past discounting activity in light of new information. This means that BRM always applies sequential discounts correctly over time, regardless of when they are purchased or canceled.

When this process is not enabled, BRM treats sequential cycle fee discounts as parallel discounts when they are purchased or canceled mid-cycle. You can use the BRM rerating process to adjust the outcome in that case.

This process has the following consequences and limitations:

• This process locks the account involved in the discount purchase or cancellation during the entire process or refunding and reapplying discounts.

  Locks are released for all members at the end of the transaction. The propagate_discount entry specifies when sharing begins. All members of the discount sharing group are locked, if the discount is shared and the propagate_discount entry is set to 1 in the Connection Manager (CM) pin.conf file. See "Configuring the Start and End Times for Discount Sharing" in BRM Managing Accounts Receivable.

• This process does not retroactively change resource balances.

  When a discount that grants a non-currency resource is purchased or canceled mid-cycle, calls rated based on the non-currency balance can be incorrect.

  For example, a cycle fee discount grants 100 free minutes and the subscriber uses all 100 minutes in the first week. The discount is then canceled mid-month. The discount amount is reevaluated, resulting in an adjusted grant of 50 free minutes. However, the minutes already used by the subscriber beyond the new grant amount are not recovered because the calls have already been rated. In this case, you can use BRM rerating to rerate the calls for the account.

• This process uses the discount exclusion rules that are in effect at the time of the evaluation.

  For example, if an exclusion rule changes on the 15th of the month and discounts are reevaluated on the 20th, the exclusion rule that took effect on the 15th is used when reevaluating discounts for the entire cycle.

Example of Recalculating Sequential Discounts in Mid-Cycle

In this example, an existing discount is applied to the monthly fee for June when the fee is charged. A second, lower priority discount is purchased mid-cycle.

These are the cycle fee and discount values used in this example:

• Monthly cycle fee for June: $30

• Discount D1 - existing

  Sequential; prorated; priority 2: 10%

• Discount D2 - purchased June 11

  Sequential; prorated; priority 1: 20%

Because the discounts are sequential and prorated, D1 is refunded from the point at which D2 becomes effective to the end of the cycle. BRM then handles the two discounts sequentially for the rest of the month.

Specifically, to handle D1 and D2 sequentially from June 11 on, BRM refunds the portion of D1 for June 11 through June 30 so that the portion of D1 that applies to the rest of the month can be calculated to form the basis for calculating D2. See Table 10-1.

Note:

The formula for proration scale is (number of days to prorate) / (number of days in cycle). A 30-day cycle is used in this example.

Table 10-1 Recalculating Sequential DIscounts (mid-cycle)

Date	Activity	Calculation	Running Balance
June 1	Charge cycle fee less D1	30 * (1-10%)	27.00
June 11	Refund the portion of the discounted cycle fee that applies to June 11 through 30	30 * 20/30 * (1-10%) = 18.00	9.00
June 11	Charge the cycle fee for June 11 through 30, applying D1 and D2 sequentially	30 * 20/30 * (1-10%) * (1-20%) = 14.40	23.40
July 1	Charge cycle fee less D1 and D2, applied sequentially	30 * (1-10%)* (1-20%)	21.60

This process of refunding and charging is the same for discount changes in other scenarios, including cancellation, purchase and cancellation in the same cycle, long cycles, subscription changes, and plan changes (where the plans have different discounts).

There can be more than the two discounts used in this example.

Enabling Sequential Discounting of Cycle Fees

By default, sequential discounting of cycle fees is disabled in BRM. You can enable this process by modifying a field in the billing instance of the /config/business_params object.

• With sequential discounting of cycle fees enabled, BRM processes mid-cycle purchase and cancellation of sequential cycle fee discounts sequentially.

• With sequential discounting of cycle fees disabled, BRM processes mid-cycle purchase and cancellation of sequential cycle fee discounts as parallel discounts.

You modify the /config/business_params object by using the pin_bus_params utility.

To enable sequential discounting of cycle fees:

1. Use the following command to create an editable XML file from the billing instance of the /config/business_params object:

   pin_bus_params -r BusParamsBilling bus_params_billing.xml
   

   This command creates the XML file named bus_params_billing.xml.out in your working directory. If you do not want this file in your working directory, specify the path as part of the file name.

2. Search the XML file for following line:

   <SequentialCycleDiscounting>disabled</SequentialCycleDiscounting>
   

3. Change disabled to enabled.

   Caution:

   BRM uses the XML in this file to overwrite the existing billing instance of the /config/business_params object. If you delete or modify any other parameters in the file, these changes affect the associated aspects of the BRM billing configuration.

4. Use the following command to load this change into the /config/business_params object:

   pin_bus_params bus_params_billing.xml
   

   You should run this command from the BRM_Home/sys/data/config directory, which includes support files used by the utility. BRM_Home is the directory where you installed BRM components. To run it from a different directory, see "pin_bus_params" in BRM Developer's Guide.

5. Read the object with the testnap utility or the Object Browser to verify that all fields are correct.

   See "Using testnap" in BRM Developer's Guide for general instruction on using testnap. See "Reading Objects by Using Object Browser" in BRM Developer's Guide for information on how to use Object Browser.

6. Stop and restart the CM. See "Starting and Stopping the BRM System" in BRM System Administrator's Guide.

7. (Multischema systems only) Run the pin_multidb script with the -R CONFIG parameter. For more information, see "pin_multidb" in BRM System Administrator's Guide.

About Applying Discounts Activated or Canceled in Mid-Cycle

Discounts are typically activated when they are purchased. They can also be purchased as inactive and activated later, or purchased with a deferred activation time.

When a discount is activated or canceled in the middle of an accounting cycle, BRM can prorate the discount, apply a full discount, or apply no discount for the accounting cycle in which it is activated or canceled. You specify the period in which the discount is applied by using Pricing Center to define discount validity rules.

When customers activate or cancel discounted products, BRM sets the discount start or end dates according to the discount validity rules. The discount is then granted for the period in which it is valid.

For example, if you specify that a discount activated in the middle of a cycle is granted for the entire cycle (full discount), the discount's start date is set to the first of the month and the discount is effective for the entire month in which it is activated.

You specify discount validity rules for cycle discounts (such as discounts on subscription fees) and for usage discounts (such as discounts on phone calls and text messaging).

Important:

Discount validity rules apply to cycle events that are aligned to a monthly billing cycle only. If the billing cycle is not monthly, discount validity rules do not apply.

About Discount Validity Rules

You set discount validity rules for three scenarios:

• Discounts that are activated in the middle of a cycle

• Discounts that are canceled in the middle of a cycle. The middle of a cycle is any time after the accounting cycle start time and before the accounting cycle end time.

• Discounts that are activated and canceled in the middle of the same cycle

For each scenario, you specify whether the discount is granted for the full cycle, prorated for part of the cycle, or not granted for the cycle.

You use Pricing Center to set the following discount validity rules:

• Valid from middle of cycle: Applies to a discount that is activated at any time during an accounting cycle and is still owned at the end of the cycle:

  • Full discount sets the discount start time to the start of the accounting cycle. The discount is granted for the entire cycle in which it is activated as shown in Figure 10-13.

    Figure 10-13 Valid from Middle of Cycle - Full Discount

    
    Description of ''Figure 10-13 Valid from Middle of Cycle - Full Discount''
    
    

  • Prorated discount sets the discount start time to the purchase time. The discount is granted for the period it is valid during the cycle in which it is activated as shown in Figure 10-14.

    Figure 10-14 Valid from Middle of Cycle - Prorated Discount

    
    Description of ''Figure 10-14 Valid from Middle of Cycle - Prorated Discount''
    
    

  • No discount sets the discount start time to the beginning of the next accounting cycle. The discount is not granted during the cycle in which it is activated as shown in Figure 10-15.

    Figure 10-15 Valid from Middle of Cycle - No Discount

    
    Description of ''Figure 10-15 Valid from Middle of Cycle - No Discount''
    
    

• Valid to middle of cycle: Applies to a discount owned at the beginning of an accounting cycle and canceled at any time during the cycle:

  • Full discount sets the discount end time to the end of the accounting cycle in which it is canceled. The discount is granted for the entire cycle in which it is canceled as shown in Figure 10-16.

    Figure 10-16 Valid to Middle of Cycle - Full Discount

    
    Description of ''Figure 10-16 Valid to Middle of Cycle - Full Discount''
    
    

  • Prorated discount sets the discount end time to the cancellation time. The discount is granted for the period it is valid during the cycle in which it is canceled as shown in Figure 10-17.

    Figure 10-17 Valid to Middle of Cycle - Prorated Discount

    
    Description of ''Figure 10-17 Valid to Middle of Cycle - Prorated Discount''
    
    

  • No discount sets the discount end time to the end of the previous accounting cycle. The discount is not granted during the cycle in which it is canceled as shown in Figure 10-18.

    Figure 10-18 Valid to Middle of Cycle - No Discount

    
    Description of ''Figure 10-18 Valid to Middle of Cycle - No Discount''
    
    

• Valid only part of the cycle: Applies to a discount that is both activated and canceled in the same accounting cycle:

  • Full discount sets the discount start time to the start of the accounting cycle and sets the discount end time to the end of the accounting cycle. The discount is granted for the entire cycle in which it is activated and canceled as shown in Figure 10-19.

    Figure 10-19 Valid Only Part of the Cycle - Full Discount

    
    Description of ''Figure 10-19 Valid Only Part of the Cycle - Full Discount''
    
    

  • Prorated discount sets the discount start time to the activation time and sets the discount end time to the cancellation time. The discount is granted only for the period it is valid as shown in Figure 10-20.

    Figure 10-20 Valid Only Part of the Cycle - Prorated Discount

    
    Description of ''Figure 10-20 Valid Only Part of the Cycle - Prorated Discount''
    
    

  • No discount sets both the discount start time and end time to the beginning of the next accounting cycle. The discount is not granted during the cycle in which it is activated and canceled as shown in Figure 10-21.

    Figure 10-21 Valid Only Part of the Cycle - No Discount

    
    Description of ''Figure 10-21 Valid Only Part of the Cycle - No Discount''
    
    

Discount validity rules are stored in the /discount object. When a discount is activated, its start and end times are set in the /purchased_discount object associated with the customer's account.

You set discount validity rules by using Pricing Center. To implement discount validity rules, you must also configure the batch rating pipeline if you use one, and for certain validity rules, run rerating to apply the discounts and run a utility to change the status of expired discounts.

For more information about implementing discount validity rules, see "Implementing Discount Validity Rules".

Immediate Cancellation of Discounts Canceled in Mid-Cycle

When a discount is canceled in the middle of an accounting cycle and the proration for the discount is set to Full discount, you can configure BRM to set the discount end date to the cancellation date, thereby cancelling the discount immediately.

Use the CancelFullDiscountImmediate business parameter to specify how BRM handles a discount canceled in the middle of a billing or accounting cycle when the proration for the discount is set to full discount. CancelFullDiscountImmediate is located in the subscription instance of /config/business_params object and takes one of the following values:

• disabled. The default value. When CancelFullDiscountImmediate is disabled and a discount is canceled in the middle of an accounting cycle, BRM sets the discount end date to the end date of the accounting cycle.

• enabled. When CancelFullDiscountImmediate is disabled and a discount is canceled in the middle of an accounting cycle, then if the proration for the discount is set to full discount, BRM cancels the discount immediately. It sets the discount end date to the cancellation date.

You modify the /config/business_params object by using the pin_bus_params utility. For more information on this utility, see "pin_bus_params" in BRM Developer's Guide.

To immediately cancel discounts canceled in mid-cycle:

1. Use the following command to create an editable XML file from the subscription instance of the /config/business_params object:

   pin_bus_params -r BusParamsSubscription bus_params_subscription.xml
   

   This command creates the XML file named bus_params_subscription.xml.out in your working directory. If you do not want this file in your working directory, specify the path as part of the file name.

2. Search the XML file for following line:

   <CancelFullDiscountImmediate>disabled</CancelFullDiscountImmediate>
   

3. Change disabled to enabled.

   Caution:

   BRM uses the XML in this file to overwrite the existing subscription instance of the /config/business_params object. If you delete or modify any other parameters in the file, these changes affect the associated aspects of the BRM subscription configurations.

4. Save this file and rename it as bus_params_subscription.xml.

5. Use the following command to load this change into the /config/business_params object:

   pin_bus_params bus_params_subscription.xml
   

   You should run this command from the BRM_Home/sys/data/config directory, which includes support files used by the utility. To run it from a different directory, see "pin_bus_params" in BRM Developer's Guide.

6. Read the object with the testnap utility or Object Browser to verify that all fields are correct.

   The resulting flist of the testnap utility must resemble the following example, with the PIN_FLD_PARAM_VALUE field value set to 1:

   0 PIN_FLD_POID POID [0] 0.0.0.1 /config/business_params 9806 0
   0 PIN_FLD_ACCOUNT_OBJ POID [0] 0.0.0.1 /account 1 0
   0 PIN_FLD_DESCR STR [0] "Business logic parameters for Subscription"
   0 PIN_FLD_HOSTNAME STR [0] "-"
   0 PIN_FLD_PARAMS ARRAY [7] allocated 4, used 4
   1 PIN_FLD_DESCR STR [0] "Parameter to enable or disable cancelling a prorated  full discount in the middle of a billing cycle. 1 means enabled."
   1 PIN_FLD_PARAM_NAME STR [0] "cancel_full_discount_immediate"
   1 PIN_FLD_PARAM_TYPE INT [0] 1
   1 PIN_FLD_PARAM_VALUE STR [0] "1"
   

   See "Using testnap" in BRM Developer's Guide for general instruction on using testnap. See "Reading Objects by Using Object Browser" in BRM Developer's Guide for information on how to use Object Browser.

7. Stop and restart the CM. See "Starting and Stopping the BRM System" in BRM System Administrator's Guide.

About Discount Exclusion Rules

Exclusion rules establish a mutually exclusive relationship between discounts or between a discount and a plan. When a mutually exclusive relationship exists between two discounts, only one of the discounts can be applied. When such a relationship exists between a discount and a plan, the discount is not applied.

After you configure two discounts as mutually exclusive, at run time BRM does not allow a deal to be committed when it has both of those discounts in the deal.

Exclusion rules between discounts can be applied at billing time or when cycle fees are applied. Exclusion rules between discounts and plans can be applied at purchase time or at billing time, but not when cycle fees are applied.

There are two types of discount exclusion rules:

• Discount exclusion rules that apply at billing time and govern purchases, such as shared discount groups

• Discount exclusion rules that are determined by ownership and govern discount application

Discounts can be combined with price plans and can belong to multiple price plans. If you define an exclusion rule between a plan and a discount, a customer who owns that pricing plan cannot purchase that excluded discount.

The following sections describe:

• About Exclusion Rules between Discounts

• About Exclusion Rules between Discounts and Plans

• About Cycle Fees and Discount Exclusions

• About Billing-Time Discount Exclusions

For information on configuring discount exclusion rules, see "Setting Up Discount Exclusion Rules".

How Exclusion Rules Are Evaluated

During discount evaluation, all discounts (system, billing, shared, usage, and cycle discounts) are retrieved and checked for exclusion rules. The discounts that are not excluded are then checked for the event type associated with the discount, such as the billing-time event or cycle event. Discounting then processes the discounts associated with the event that occurred.

For example, an account has three cycle discounts (CD1, CD2, and CD3) and a usage discount (UD). Exclusion rules are set between:

• CD2 and CD1 (CD1 is applied)

• CD1 and UD (UD is applied)

When cycle events are processed, all discounts are retrieved and checked for exclusion rules. At that time, CD2 and CD1 are eliminated. UD is eliminated as well because it is not a cycle discount. Only CD3 is applied for cycle events.

When usage events are processed, all discounts are retrieved and checked for exclusion rules. CD2, which is mutually exclusive with CD1, is eliminated. CD1, which is mutually exclusive with UD, is eliminated. CD3, which is not a usage discount, is eliminated. Only UD is applied for usage events.

About Exclusion Rules between Discounts

You can set up exclusion relationships between system, shared, or subscription discounts.

• A system discount is granted automatically to all accounts. This type of discount is always applied, except when specifically excluded by an exclusion rule.

• A shared discount is shared by members of an account or service group. Any exclusion rule that restricts a shared discount for use when another discount is active denies that discount to that service or account. Conversely, all members of a discount group are granted the discount as long as it is not restricted by an exclusion rule.

• A subscription discount is purchased by a customer as a separate discount or as part of a plan.

About Exclusion Rules between Discounts and Plans

If an exclusion relationship exists between a discount and a plan, a customer can own the discount or the plan, but not both. Further, the customer cannot own any discounts associated with the plan if the customer owns the excluded discount.

About Cycle Fees and Discount Exclusions

When discounts are applied to cycle fees and the ValidateDiscountDependency flag is set in the /config/business_params object, all discounts are filtered based on the cycle event type and then checked for discount exclusions stored in the /dependency object. Discounts that are filtered and checked include:

• All system discounts for the service type.

• All discounts for the subscription service.

• All shared discounts (if the discount is a member of a sharing group).

• All non-billing-time subscription discounts for the service instance.

Applicable discounts are calculated, and a final discount list is created for processing.

Example of Discount Exclusion with Cycle Fees

In the example illustrated in Figure 10-22, Account B has three subscription services: Service 1 and Service 2 are part of the discount share group GD1, and Service 3 is not part of the share group. There are four discounts:

• A 10% subscription discount for cycle fees (D1)

• A 5% system discount (SD1) that is defined as mutually exclusive with D1

• A 5% subscription discount (D2)

• A 5% shared discount for cycle fees (GD1)

Figure 10-22 Discount Exclusion with Cycle Fees Example

Description of ''Figure 10-22 Discount Exclusion with Cycle Fees Example''

At billing time, the following charges are owed by Account B:

• Service 1 is billed 850 Yen. Two discounts are applied: a 10% discount for D1 and a 5% group discount because Service 1 is a member of the GD1 shared discount group. The system discount SD1 is not applied because it is mutually exclusive with D1.

• Service 2 is billed 2550 Yen. Three discounts are applied: a 5% discount for D2, a 5% group discount because Service 2 is a member of the GD1 shared discount group, and a 5% discount for SD1. (SD1 is not mutually exclusive with D2 so can be applied.)

• Service 3 is billed 900 Yen. A 10% discount is applied for D3. No other discount is applied because Service 3 is not a member of the GD1 shared discount group.

Example of Plan-Discount Exclusion with Cycle Fees

The following example of discount exclusions between plans and discounts where the resulting valid discount is applied for cycle fees. In these examples, the automatic system discounts System_Discount1 and System_Discount2 apply to cycle forward, cycle arrears, and cycle forward arrears events.

When both discount-to-discount and plan-to-discount exclusions are enabled (see "Configuring Exclusion Rules"), the system validates the discount-to-discount exclusions first, followed by the discount-to-plan exclusions.

The following exclusion rules in Table 10-2 are used:

Table 10-2 Exclusion Rules

Exclusion Rule Set Between	Result
System_Discount1 and Plan2	System_Discount1 is not applied.
System_Discount2 and Plan1	System_Discount2 is not applied.
System_Discount2 and Subscription_Discount2	System_Discount2 is not applied.

The monthly fees for each plan are:

• Plan1 = 3000 Yen

• Plan2 = 4000 Yen

Each plan includes two discounts:

• System_Discount1 (automatic system discount) = 10%

• System_Discount2 (automatic system discount) = 40%

These additional discounts are purchased separately:

• Subscription_Discount1 (subscription discount) = 20%

• Subscription_Discount2 (subscription discount) = 30%

In this example, an account purchases Plan1 at the beginning of the month. Plan1 has two automatic system discounts (System_Discount1 and System_Discount2) and a mutually exclusive relationship with System_Discount2 as shown in Figure 10-23.

When the discounts are calculated, the mutual exclusion between Plan1 and System_Discount2 eliminates System_Discount2. System_Discount1 has no exclusion restriction and is applied.

The monthly cycle fees for Plan1 are 3000 Yen. System_Discount1 provides a 10% discount of 300 Yen, resulting in an adjusted cycle fee of 2700 Yen.

Figure 10-23 Plan-Discount Exclusion with Cycle Fees Example

Description of ''Figure 10-23 Plan-Discount Exclusion with Cycle Fees Example''

About Billing-Time Discount Exclusions

When billing-time discounts are applied and the ValidateDiscountDependency flag is set in the /config/business_params object, discount exclusions are performed based on the flag setting. Values for the ValidateDiscountDependency flag can be any combination of the following:

• 0x00: No discount dependency validation (this is the default value).

• PIN_DISC_VALIDATE_DISC_DISC_DEP (0x01): Validate exclusions between discounts.

• PIN_DISC_VALIDATE_PLAN_DISC_DEP (0x02): Validate exclusions between discounts and plans.

• PIN_DISC_VALIDATE_DISABLE_PURCH_TIME (0x04): Disable validations between plans and discount system wide. When this flag is set, no dependency validations occur at purchase time.

When specifying these values, you enter the sum of any of the parameter values shown above. For example, to enable exclusion rules between discounts (0x01) and between a discount and a plan (0x02), enter (0x03). Or, to enable exclusions between a discount and a plan only, but to disable exclusions at purchase time, enter (0x06).

Discounts that are filtered and checked include subscription, system, and shared billing-time discounts. System and subscription discounts are sorted and paired, and each pair is checked to see if an exclusion rule is set between them. If an exclusion rule is present, the dependent discount is dropped and the dependee discount is retained and added to a list that is sent to the discount pipeline for processing. For more information about dependent and dependee discount objects, see "Managing /dependency Objects" in BRM Setting Up Pricing and Rating.

Discount-to-discount exclusions are processed first, then discount-to-plan exclusions, if any.

Discount-to-plan exclusions are handled in much the same way as discount-to-discount exclusions. Discounts and plans owned by an account are compared for exclusion rules. Discounts for any plan/discount combinations with exclusion rules set are not applied.

The exclusion rules are applied for each service level or account level.

Examples of Exclusion Rules Applied at Billing Time

In this example, Account A has 2 subscription services (Service 1 and Service 2) and three discounts as illustrated in Figure 10-24:

• A 10% subscription discount for cycle fees (D1)

• A 5% system discount (SD1) that is defined as mutually exclusive with D1

• A 5% subscription discount (D2)

Figure 10-24 Exclusion Rules Applied at Billing Time Example 1

Description of ''Figure 10-24 Exclusion Rules Applied at Billing Time Example 1''

At billing time, the following charges are owed by Account A:

• Service 1 is billed 900 Yen after the 10% D1 discount is applied. The SD1 system discount is not applied because it is mutually exclusive with D1.

• Service 2 is billed 2700 Yen after two discounts are applied: the 5% D2 discount and the 5% SD1 system discount.

In this example, Account A has the following discounts as illustrated in Figure 10-25:

• A 10% subscription discount for cycle fees (D1)

• A 5% subscription discount (D2)

• A 5% system discount (SD1) that is defined as mutually exclusive with D2

Service 1 has member services with their own balance groups MS1 and MS2.

Figure 10-25 Exclusion Rules Applied at Billing Time Example 2

Description of ''Figure 10-25 Exclusion Rules Applied at Billing Time Example 2''

At billing time, the following charges are owed by Account A:

• Service 1 is billed 850 Yen. Two discounts are applied: a 10% discount for D1 and a 5% system discount for SD1.

• MS1 is billed 750 Yen. Three discounts are applied: a 10% discount for D1, a 5% system discount for SD1, and a 10% discount inherited from Service 1.

• MS2 is billed 800 Yen. Two discounts are applied: a 10% discount for D2 and another 10% discount inherited from Service 1. The system discount SD1 is excluded.

• Service 2 is billed 2850 Yen. One discount is granted: a 5% discount off the monthly fee. The system discount SD1 is excluded.

For more information, see "Setting Up Discount Exclusion Rules".

About Exclusion Rules for Usage Discounts

You can apply exclusion rules between a usage discount and any of the following discounts:

• Billing-time discounts

• Cycle discounts

• System discounts

• Other usage discounts

Usage discounts are applied when subscribers use their services; for example, by making phone calls.

Setting up exclusion rules between a usage discount and other discounts or plans is useful when you want to prevent additional discounting, including aggregation discounting, for an excluded billing-time discount. For example, if you purchase two cycle discounts (a 5% discount and a 10% discount) and set up an exclusion rule between them, one is eliminated. For more information, see "About Exclusions Between Usage Discounts and Billing-Time Discounts".

Usage discount exclusion can occur in both the real-time and batch pipeline.

About Exclusions Between Usage Discounts and Billing-Time Discounts

Billing-time discounts are granted based on balances accumulated by an aggregation discount. An aggregation discount is a discount that increments a counter resource balance when usage occurs.

Setting up an exclusion rule between a billing-time discount and another discount or a plan does not prevent aggregation. Because you want to prevent aggregation when the billing-time discount is excluded, you must also set up an exclusion rule between the aggregation discount associated with the billing-time discount and the other discount:

• If the billing-time discount is excluded by a plan, set up an exclusion rule between that plan and the aggregation discount.

• If billing-time discount 1 is excluded by billing-time discount 2, set up an exclusion rule between the aggregation discount and the billing-time discount 2.

• If the billing-time discount is excluded by a cycle fee discount, set up an exclusion rule between the aggregation discount and the cycle fee discount.

If a billing-time discount is owned for part of the month only, during the time the discount is owned, discount information added to the EDR and the discount is applied.

When a billing-time discount is owned for part of the month, the associated usage aggregation discount aggregates usage only during the period that the billing-time discount is owned. Therefore, the billing-time discount is based on aggregated usage for part of the month only.

For more information on billing-time and aggregation discounts, see the following topics:

• Setting Up Billing-Time Discounts

• Creating a Real-Time Aggregation Discount

Example of Usage Discount Exclusion Rules

Discount exclusion rules can affect how usage is aggregated for an account that owns several subscription services (lines) and a billing-time discount, and the billing-time discount is excluded by discounts or plans associated with the subscription services.

In this example, an account owns:

• One billing-time discount (BTD). This discount is granted based on the aggregated usage of all subscription services in the account.

• One account-level aggregation discount: a shared discount owned by the object owner (AGD). This discount is shared with each subscription service and aggregates the usage for all subscription services.

• An account-level resource balance (ARB). This balance stores the aggregated usage amount for all subscription services.

The following plans and discounts are associated with the subscription services:

• Three plans (Plan1, Plan2, and Plan3G).

• Two call-by-call (usage) discounts (CBC1 and CBC2).

• A subscription service-level resource balance (LRB). This balance stores the individual subscription's monthly usage amount.

When billing is run for the account at the end of the month, BRM does the following:

• Determines for each subscription service whether the billing-time discount applies.

• Applies a percent discount based on the aggregated ARB for total minutes on all subscription services in the account.

  Note:

  In this example, there is only one account-level billing-time discount. If another billing-time discount was owned by each subscription service, an additional percent discount would be applied for individual subscription service activity during the month, based on LRB.

Figure 10-26 shows the account structure, including the subscription services (the lines), discounts, and resource balances:

Figure 10-26 Usage Discount Exclusion Rules Example

Description of ''Figure 10-26 Usage Discount Exclusion Rules Example''

Exclusion rules are set between the following discounts and plans:

• BTD and Plan1 (BTD is not applied)

• AGD and Plan1 (AGD is not applied)

• BTD and CBC1 (BTD is not applied)

• AGD and CBC1 (AGD is not applied)

• BTD and Plan3G (BTD is not applied)

• AGD and Plan3G (AGD is not applied)

When these exclusion relationships are present and a subscription service owns any of the excluded discounts or plans, the aggregation discount is not applied and the account's aggregation balance is not incremented.

For more information, see "Setting Up Discount Exclusion Rules".

Table 10-3 shows the monthly subscription service activity for the account and each subscription service. It demonstrates, based on the subscription service activity, how exclusion rules and discounts are applied and how resource balances are incremented.

Table 10-3 Monthly Subscription Service Activity

Line	Monthly Subscription Service Activity	Usage Discounts Applied	Resource Balance Activity
Line1	Owns Plan2 and CBC2. Total minutes called: 5500.	No exclusion rules apply. The aggregation discount is applied. The CBC2 discount is applied.	The ARB increases from zero to 5500 minutes. The line resource balance (LRB) increases from zero to 5500 minutes.
Line 2	Owns Plan2 and CBC1. Total minutes called: 2300.	The aggregation discount is not applied because it is mutually exclusive with CBC1. The CBC1 discount is applied.	The ARB is not incremented. The LRB is increased to 2300 minutes.
Line 3	Owns Plan1 and CBC1. Total minutes called: 4000.	The aggregation discount is not applied because it is mutually exclusive with both Plan1 and CBC1. The CBC1 discount is applied.	The ARB is not incremented. The LRB is increased to 4000 minutes
Line 4	Owns Plan2 and CBC2. Total minutes called: 4500.	No exclusion rules apply. The aggregation discount is applied. The CBC2 discount is applied.	The ARB is incremented from 5500 to 10,000 minutes. The LRB (line resource balance) increases from zero to 4500 minutes.
Line 5	Owns Plan3G. Minutes for the first half of the month: 1900. Changes from Plan3G to Plan2G mid-month. Minutes for the second half of the month: 2200.	For the first half of the month: Because it is mutually exclusive with Plan3G, the aggregation discount is not applied. For the second half of the month: No exclusion rule applies between the aggregation discount and Plan2G, so the aggregation discount is applied.	For the first half of the month: The ARB is not incremented. The LRB increases from zero to 1900 minutes. For the second half of the month: The ARB is incremented from 10,000 to 12,200 minutes. The LRB increases from 1900 to 4100 minutes.

In Table 10-3, the billing-time discount is applied at the following rates listed in Table 10-4:

Table 10-4 Discount Rates

Total Minutes Consumed by all Subscription Services	Discount Rate On Charges
1 – 5000	10%
5001 – 10000	20%
10001 – maximum	30%

At the end of the cycle, the total usage for all subscription services is 20,400 minutes. However, because the aggregation discount was excluded by other discounts and plans, the aggregation balance for all subscription service usage is 12,200 minutes. When billing is run, the billing-time discount is based on 12,000 minutes of usage, and a 30% discount is applied to the balance due for the account.

About Volume-Based Discounts

Volume-based discounts are granted based on threshold values that define levels of usage such as the number of calls made, the amount of money a subscriber spends on calls, the number of subscriptions purchased, and the number of days a user has subscribed to a service.

Important:

Support for some volume-based discounts is included in Advanced Discounting Manager, an optional feature that requires a separate license.

You can set up several types of volume-based discounts. For information, see the following topics:

• About Discounts Based on Number of Subscriptions

• About Discounts Based on the Number of Contract Days

• About Discounts Based on Monthly Fees and Usage

About Discounts Based on Number of Subscriptions

You can grant discounts based on the number of active subscriptions in an account group. This type of discount is designed to be granted to corporate accounts. For example, you might offer a percentage off the monthly fee when the number of subscriptions exceeds certain limits.

The plans purchased by accounts in the account group must include a subscription service. The number-of-subscriptions discounts is granted at the end of each billing cycle and is based on the number of subscription services that are active at the end of the cycle.

BRM does not consider subscription services that were canceled or transferred out of the account group during the cycle. For example, an account group includes six subscription services at the beginning of a cycle. During the cycle, four subscription services are added and two subscription services are removed. At the end of that cycle, the discount is based on eight active subscription services (6+4-2=8).

An account's subscription service is not counted when the account owns a plan or discount that is mutually exclusive with the number-of-subscriptions discount. You set up exclusions between discounts and other discounts or plans by using discount exclusion rules. For information, see "About Excluding Subscriptions when Discount Exclusion Rules Apply".

To offer discounts based on a number of subscriptions, you set up a hierarchical account group and a discount sharing group. For more information, see "About Setting Up Discounts Based on Number of Subscriptions".

About Resources that Track the Number of Subscription Services

The number of active subscription services in an account group is stored in the Line Counter resource balance. Line Counter is a type of aggregation counter resource. When the account group's parent account purchases a plan that includes a Line Counter, that resource is added to the parent account's balance group. Discounting can then track the number of subscription services associated with the account group in the parent account's balance.

When you set up the number-of-subscriptions discount, you base the discount on the value in the parent account's Line Counter balance. The Line Counter is updated when billing is run.

About Excluding Subscriptions when Discount Exclusion Rules Apply

BRM does not count a subscription service as an active subscription when you set up a discount exclusion rule between the number-of-subscriptions discount and a plan (or discount in the plan) that includes the subscription service.

Important:

To exclude subscription services from being counted, you must enable and configure discount exclusion rules. See "About Discount Exclusion Rules".

An account can own other plans and discounts that are affected by discount exclusion rules and still have its subscription service counted, providing these exclusion rules do not exclude the number-of-subscriptions discount.

How Subscriptions Are Counted

BRM counts the number of subscription services at billing time, before discounts are calculated, as shown in Figure 10-27. All active subscription services in the account group are counted except for those excluded by discount exclusion rules.

Figure 10-27 Subscription Count at Billing Time

Description of ''Figure 10-27 Subscription Count at Billing Time''

Subscription services that are added to the account group during the cycle are counted at the end of the cycle, providing they are active. Subscription services that are removed from the account group during the cycle are not counted at the end of the cycle.

The status of exclusion rules and the discounts or plans associated with exclusion rule is considered only at the time subscription services are counted. If the status is changed after the end of the billing cycle, but before billing is run, the new status is not considered.

Updating the Count of Subscriptions

The count of subscription services is updated by the PCM_OP_SUBSCRIPTION_COUNT_LINES opcode. This opcode is called by the billing event when billing is run. It counts the active subscription services in the account group, updates the Line Counter in the parent account, and then generates an /event/billing/lcupdate event to record the update.

PCM_OP_SUBSCRIPTION_COUNT_LINES performs the following tasks:

1. Determines the identity of the parent account in the account hierarchy.

2. Checks that the parent account's balance group includes the Line Counter resource.

3. Checks each child account to determine the following:

   • How many subscription services are associated with the child account and whether the subscription services are active.

   • For each active subscription service, what exclusion rules exist between the subscription service's active plans and discounts, including shared discounts. If exclusion rules exist for the subscription service at the end of the cycle, the Line Counter is not incremented for that subscription service.

4. Updates the value of the Line Counter in the parent account's balance group.

You can customize the criteria for counting subscription services by implementing the PCM_OP_SUBSCRIPTION_POL_COUNT_LINES policy opcode.

About Counting Subscriptions During Rerating

The Line Counter is updated with the count of active subscription services at the end of each billing cycle. This count determines the discount amount applied by the number-of-subscriptions discount. If rerating is requested for a date occurring before the start of the current billing cycle:

• The number of subscription services is not recounted; instead, the count from the beginning of the cycle is used to apply discounts.

• Exclusion rules are re-evaluated so that the number-of-subscriptions discount is not applied if it is excluded.

About Setting Up Discounts Based on Number of Subscriptions

To offer discounts based on a number of subscriptions, you set up the following components:

• The number-of-subscriptions discount. How you set up this discount depends on what kind of discount you will offer. For example, this can be a billing-time discount applied to service usage fees or a cycle fee discount applied only to cycle fees. For information about billing-time discounts, see "About Billing-Time Discounts".

• Plans that include subscription services that will be purchased by the child accounts in an account group. A subscription service represents the customer's subscription. You set up subscription services by using Pricing Center.

  For information about subscription services, see "Managing Customers' Subscription-Level Services" in BRM Managing Customers.

• Plans that include the Line Counter resource and the number-of-subscriptions discount that will be purchased by the parent account in an account group. The Line Counter is used to track the number of active subscription services. You create plans by using Pricing Center.

• An account hierarchy. This hierarchy is needed because BRM counts the number of subscription services in the account group to determine the number of active subscriptions. You create account hierarchies by using Customer Center.

  For information about account hierarchies, see "About Hierarchical Account Groups" in BRM Managing Accounts Receivable.

• A discount sharing group that is owned by the parent account and has the subscription services in the child accounts as members. You create a discount sharing group to share the number-of-subscriptions discount; for example, to grant a discount on the service fees for each child account based on the total number of subscription services.

For information about sharing discounts, see "About Shared Discounts".

For more information about setting up discounts based on number of subscriptions, see "Setting Up Discounts Based on Number of Subscriptions".

Figure 10-28 shows the hierarchical relationship and components required to apply discounts based on number of subscriptions:

Figure 10-28 Hierarchy of Discounts Based on Number of Subscriptions

Description of ''Figure 10-28 Hierarchy of Discounts Based on Number of Subscriptions''

Example of Applying a Discount Based on the Number of Subscriptions

The following example shows how a number-of-subscriptions discount is applied.

In this example:

• Each child account includes one subscription service. The subscription services are members of the discount sharing group that shares the number-of-subscriptions discount.

• The discount granted by the number-of-subscriptions discount is a percentage off the cycle fees:

  • 0 – 1 Subscription services:       0%

  • 2 – 3 Subscription services:    10%

  • 4 – 5 Subscription services:    15%

• Each child account's subscription service is associated with one of the following discounts or plans:

  • Plan B

  • Plan C

  • Discount 1

  • Discount 2

• Exclusion rules exist between the number-of-subscriptions discount and the following plan and discount:

  • Plan C

  • Discount 1

  Any subscription service associated with Plan C or Discount 1 at the end of the cycle, before billing is run, is not counted.

Of the subscription services shown in Figure 10-29, Subscription 1, Subscription 4, and Subscription 5 are included in the subscription count at the end of the cycle. Subscription 2 and Subscription 3 are excluded because they are associated with a discount or plan that is mutually exclusive with the number-of-subscriptions discount.

Figure 10-29 Number of Subscriptions and Mutually Exclusive Discounts at Cycle End

Description of ''Figure 10-29 Number of Subscriptions and Mutually Exclusive Discounts at Cycle End''

In Table 10-4, based on the exclusion rules, BRM applies discounts as follows:

• Subscription 1 receives the number-of-subscriptions discount.

• Subscription 2 receives no discount because the number-of-subscriptions discount is excluded by Plan C.

• Subscription 3 receives only Discount 1 because the number-of-subscriptions discount is excluded by Discount 1.

• Subscription 4 receives Discount 2 and the number-of-subscriptions discount.

• Subscription 5 receives the number-of-subscriptions discount.

The number-of-subscriptions discount grants a percentage of 10% off to each eligible account because three subscription services are included in the count at the end of the cycle.

About Discounts Based on the Number of Contract Days

Important:

Support for discounts based on the number of contract days is included in Advanced Discounting Manager, an optional feature that requires a separate license.

BRM provides support for offering discounts based on the number of active days a customer has been under contract. This support enables you to track the number of days a customer's subscription service has been active from the date of enrollment and to provide discounts based on this value.

BRM calculates the active contract days as follows:

Contract days = billing date - enrollment date - days of suspension

BRM provides two aggregation counters that you use when setting up discounts based on contract days:

• Contract Days Counter (CDC) stores the total number of contract days.

• Contract Days Counter for Discount (CDCD) stores an account's aggregated usage fees for the month.

BRM updates the count of contract days when:

• Subscription services are created for a new account or added for an existing account.

  When a subscription service is created, the CDC is equal to the number of days between the subscription service creation date and the next billing cycle start date. If a subscription service is created in an inactive state, the CDC has a value of zero (0) until the subscription service is activated.

• Billing starts for the subscription service.

  When billing begins, the contract days counter is incremented by the number of days in the billing cycle.

• There is a change in the status of the subscription service.

  If the status of the subscription service changes from closed to active or from inactive to active, the number of days between the change-of-status date and the next billing cycle start date is added to the contract days counter.

  If the status of the subscription service changes from active to inactive or from active to closed, the number of days between the inactivation date and the start of the next billing cycle is subtracted from the contract days counter. This adjusts the total number of days that were added in the beginning of the cycle.

  If the status of the subscription service changes from inactive to closed or from closed to inactive, the contract days counter is not updated.

You can customize how the contract days counter is updated by implementing the PCM_OP_SUBSCRIPTION_POL_UPDATE_CDC policy opcode.

You can configure the contract days counter to include or exclude the days on which a subscription service changes status (for example, the day the subscription service is created or suspended).

For information on setting up discounts based on contract days, see "Setting Up Discounts Based on Contract Days" in BRM Managing Accounts Receivable.

For information on transferring a subscription service, see "About Transferring a Subscription Service to Another Subscriber" in BRM Managing Customers.

For more information on subscription management, see "How Service Status Changes Affect Subscription Services" in BRM Managing Customers.

About Discounts Based on Monthly Fees and Usage

Important:

Support for discounts based on monthly fees and usage is included in Advanced Discounting Manager, an optional feature that requires a separate license.

This type of discount tracks the monthly fees and service usage in a discount sharing group (a group owner account that shares discounts with user or child accounts) so that you can grant discounts based on aggregated fees of all users in the discount sharing group.

To implement this feature, BRM provides three aggregation counter resources:

• Parent-level monthly fee and usage counter (MFUC)

• Child-level monthly and usage fee counter (CMFUC)

• Child-level aggregation counter (CHAGC)

When a billing-time discount is applied, the value of the parent counter, MFUC, is copied to the child counter, CMFUC. The child aggregation counter, CHAGC, aggregates all the fees of the child services for real-time discounts.

BRM augments the child aggregation counter when a billable event occurs, and it resets the counter at the end of the billing cycle or whenever an adjustment event updates the monthly fee and usage counter. You can customize how the counter is updated by implementing the PCM_OP_SUBSCRIPTION_POL_NOTIFY_AGGREGATION policy opcode.

Understanding the Discounting Architecture

Discounting for both real-time rating and batch rating takes place in a pipeline.

• For real-time events, discounting occurs in a separate discounting-only pipeline. See "Real-Time Discounting Architecture".

• For batch events, discounting occurs in modules that are part of Pipeline Manager. See "Pipeline Discounting Architecture".

Real-time discounting pipelines and batch rating/discounting pipelines use many of the same function modules and data modules. They also share the same interface for requesting balance data.

Real-Time Discounting Architecture

Discounting for events rated in real time takes place in a pipeline that is used only for this purpose.

Important:

Real-Time Discounting is a feature of the Advanced Discounting Manager, an optional feature that requires a separate license.

Discounts are handled by a pipeline in the following way:

1. During real-time rating, BRM checks if the event qualifies for discounting.

2. If the event needs discounting, BRM sends the event to the CM. The CM adds data used for discounting and sends the event to Pipeline Manager. The data includes the A number.

3. The pipeline NET_EM module receives the discount request and sends it to the appropriate discount pipeline.

4. The INP_Realtime input module converts the data from flist to EDR format and creates an EDR container for the pipeline.

   Note:

   You can create and run an iScript to manipulate data in the EDR container before it is sent to the pipeline modules. See "About Customizing Mapping of Flist Fields to Rating EDR Container Fields".

5. Pipeline Manager processes the event and discounts it. It adds charge packets and discount packets to the EDR.

6. The OUT_Realtime module does the following:

   • Adds the discount balance impact.

   • Runs an iScript that you can customize to manipulate data. See "Creating iScripts and iRules" in BRM Developer's Guide.

   • Converts the data back into flist format.

   • Sends the flist to the NET_EM module.

7. The NET_EM module sends the flist back to the CM with the discount balance impact.

8. The customer's discount balances are updated in the BRM database, and the rated event object is stored.

Figure 10-30 illustrates the flow of data for real-time discounting:

Figure 10-30 Real-Time Discounting Data Flow

Description of ''Figure 10-30 Real-Time Discounting Data Flow''

In addition to modules required for input and output, the discounting pipeline includes the following function and data modules:

• The discount analysis module (FCT_DiscountAnalysis) associates discounts with events. See "FCT_DiscountAnalysis".

• The discounting module (FCT_Discount) filters events, checks conditions, and calculates discounts. (See "FCT_Discount" and "Discounting Process Overview".) The FCT_Discount module requests data from the following data modules:

  • DAT_Discount, which stores the pricing data, such as discount models, that are used to process discounts. See "DAT_Discount".

  • DAT_BalanceRealtime, which provides balance data. The DAT_BalanceRealtime module gets data from the BRM database by connecting with the NET_EM module. It does not store data in memory, so it does not load data when you start Pipeline Manager. See "DAT_BalanceRealtime".

  • DAT_AccountRealtime, which provides account data. The DAT_AccountRealtime module gets data from the BRM database by connecting with the NET_EM module. It does not store data in memory, so it does not load data when you start Pipeline Manager. See "DAT_AccountRealtime".

• The credit limit checking module (FCT_CreditLimitCheck) is used during prepaid authorization to determine whether event owners have enough resources in their prepaid account balance to cover the cost of usage. See "FCT_CreditLimitCheck".

Figure 10-31 shows a real-time discounting pipeline and data pool:

Figure 10-31 Real-Time Discounting and Data Pool

Description of ''Figure 10-31 Real-Time Discounting and Data Pool''

For information about setting up a real-time discounting pipeline, see "Configuring a Real-Time Discounting Pipeline".

About Transaction Management for Real-Time Discounting

Because no data is added to the Pipeline Manager database, a real-time discounting pipeline does not use the Transaction Manager (TAM). Instead, transaction handling is provided by the CM.

Data Sent to Pipeline Manager for Real-Time Discounting

The data sent to Pipeline Manager includes:

• The event to discount, including data from the network such as the number, APN, and start time.

• Data pertaining to the A number account, including account number, balance data, product data, service data, and ERA data.

  Note:

  You can filter the types of ERAs considered during real-time rating to improve performance. For information, see "Filtering the ERAs Considered during Rating and Discounting" in BRM System Administrator's Guide.

Pipeline Discounting Architecture

Batch discounting is performed by Pipeline Manager. The following function modules process EDRs for discounting:

• The discount analysis module (FCT_DiscountAnalysis) associates discounts with events. This module analyzes the discounts owned by the account associated with the event. It does the following:

  • Compares discount validity dates to the event time.

  • Checks if the event matches an event type in the discount's event usage map.

  • Evaluates whether any discounts should be excluded based on discount exclusion rules. To support exclusion rules for usage discounts, the FCT_DiscountAnalysis module retrieves from the DAT_Discount module the value of the /config/business_params object's ValidateDiscountDependency entry. See "DAT_Discount".

  • Checks if a discount is active or inactive.

    Note:

    When BRM is configured to use filter sets, Pipeline Manager uses FCT_DiscountAnalysis to apply any standard or promotional discounts and FCT_Filter_Set to apply any system discounts. See "About Using Filter Sets to Apply System Products and Discounts".

• The discounting module (FCT_Discount) filters events, checks conditions, and calculates discounts. (See "Discounting Process Overview".) The FCT_Discount module requests data from the following data modules:

  • DAT_Discount, which stores the pricing data, such as discount models, that are used to process discounts.

  • DAT_BalanceBatch, which stores balance data. This data is provided at startup by the BRM database and kept up to date by the Account Synchronization feature. See "About Account Synchronization" in BRM Installation Guide.

  • DAT_AccountBatch, which stores account data. This data is provided at startup by the BRM database and kept up to date by the Account Synchronization feature.

• The FCT_Rounding module rounds the discount balance impacts.

• The FCT_ApplyBalance module adds the discount balance impacts to the EDR and updates the Pipeline Manager memory.

Figure 10-32 illustrates the flow of data for discounting events rated by Pipeline Manager:

Figure 10-32 Pipeline Manager Discounting Events Data Flow

Description of ''Figure 10-32 Pipeline Manager Discounting Events Data Flow''