16 Managing Purchased Discount Offers

Learn how to manage your customers' discount offers in Oracle Communications Billing and Revenue Management (BRM).

Topics in this document:

Setting Discount Offer Status

The status of a discount offer can be Active, Inactive, or Canceled. A discount offer is not valid when it is inactive. The discount offer does not apply to any user events generated while it is inactive.

When you change the status of a discount offer, you specify the new status and the reason for the status change.

A discount offer's status can change when you:

  • Purchase a discount offer: You can set the status to Active or Inactive in the case of deferred purchase.

  • Purchase an inactive discount offer: You can later reactivate it by setting its status to Active.

  • Cancel a discount offer: You set the discount offer status to Canceled. See "Canceling Discount Offers".

  • Change the status of an account or service that owns a discount offer: You change the status of the discount offer to the same status. When you close an account, you cancel any discount offers it owns.

  • Change the status of a discount: You can set the discount offer status to active or inactive.

Setting Discount Offer Purchase, Cycle, and Usage Start and End Times

You specify a discount offer's validity period for the account that purchases the discount offer by setting the purchase start and end times. The cycle and usage start and end times specify when to start and stop charging cycle forward fees and rating usage events by using the discounted charge.

You can modify a discount offer's purchase, usage, and cycle start and end times at the following times:

  • When purchasing a discount offer.

  • When canceling a discount offer. By default, the discount offer's purchase, cycle, and usage end times are set to the cancellation time. You can change the date the discount offer expires by modifying the discount offer's end time.

  • When changing the status of a discount offer.

    Note:

    Do not change a discount offer's purchase, cycle, or usage start time after the discount has been applied to the account; otherwise, the discount will be applied incorrectly.

BRM does not allow you to backdate the discount offer's purchase, usage, or cycle end date prior to the discount offer's purchase start date or prior to the G/L posting date.

The cycle and usage periods must start after the purchase period start time and end before the purchase period end time.

If you configure BRM for time stamp rounding, BRM rounds all start and end times to 00:00:00 hours.

Enabling Mutually Exclusive Discount Offers

You configure discount offer exclusions to prevent a discount offer from being used or purchased when another discount offer or package is owned. You configure discount offer exclusions in either PDC or Pricing Center, and in a BRM server configuration file.

By default, discount exclusions are disabled in BRM. You can enable them by running the pin_bus_params utility to change the ValidateDiscountDependency business parameter. For information about this utility, see "pin_bus_params" in BRM Developer's Guide.

When you enable discount exclusions, you have the following options:

  • You can enable both discount offer-to-discount offer exclusion and discount offer-to-package exclusion only simultaneously.

  • With discount offer to-package exclusions, you can disable the exclusion when a discount offer is purchased, but allow it to be enforced at run time when a discount is applied to a charge.

To enable discount exclusions in BRM:

  1. Go to BRM_home/sys/data/config.

  2. Create an XML file from the /config/business_params object:

    pin_bus_params -r BusParamsBilling bus_params_billing.xml
  3. Find the following line:

    <ValidateDiscountDependency>disabled</ValidateDiscountDependency>
  4. Change disabled to any of the following:

    • discToDiscExcl: Enable discount offer-to-discount offer exclusions.

    • discToPlanExcl: Enable discount offer-to-package exclusions.

    • enableBothExcl: Enable both discount offer-to-discount offer and discount offer-to-package exclusions.

    • disableDiscToPlanExclAndNoPurTimeValidation: Disable exclusions between packages and discount offers systemwide. When this flag is set, at purchase time no dependency validations are performed.

    • enableBothExclAndNoPurTimeValidation: Enable both discount offer-to-discount offer and discount offer-to-package exclusions, and do not support dependency validations at purchase time.

    • returnOnFirstExcl: Use the first mutually exclusive discount offers or discount offer/package if BRM finds any such conflicts.

      Note:

      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, the changes affect the associated aspects of the BRM billing configuration.

  5. Save the file as bus_params_billing.xml.

  6. Load the XML file into the BRM database:

    pin_bus_params bus_params_billing.xml
  7. Stop and restart the CM.

  8. (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.

Configuring Remaining Charge Cycle Discounting

Remaining charge cycle discounting is used in the following situation:

  1. A discount is applied to a recurring fee.

  2. A second discount is applied mid-cycle. In this case, the second discount might be applied to the original charge instead of to the remaining charge.

  3. If remaining charge cycle discounting is enabled, the original discount is backed out and the two discounts are evaluated based on priority.

If a second discount is purchased mid-cycle, the original discount is backed out and the two discounts are evaluated based on priority.

This process has the following consequences and limitations:

  • Although this process is run for all cycle fee discounts that are applied mid-cycle, it can change the outcome only for cycle fee discounts that are set to Remaining Charge, and are prorated.

  • This process locks the account involved in the discount offer applied during the entire process or refunding and reapplying discounts. The lock is released at the end of the transaction.

  • If the discount is shared, all members of the discount sharing group are locked, but only if the sharing start time is set to start when the discount sharing group is created or a member is added (the propagate_discount entry is set to 1 in the Connection Manager (CM) pin.conf file). Locks are released for all members at the end of the transaction.

  • This process does not retroactively change balances. When a discount that grants a noncurrency balance is applied mid-cycle, calls rated based on the noncurrency balance can be incorrect.

    For example, a cycle fee discount grants 100 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 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 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.

By default, remaining charge discounting of cycle fees is disabled. You can enable this process by running the pin_bus_params utility to change the SequentialCycleDiscounting business parameter. For information about this utility, see "pin_bus_params" in BRM Developer's Guide.

To enable remaining charge discounting of cycle fees:

  1. Go to BRM_home/sys/data/config.

  2. Create an XML file from the /config/business_params object:

    pin_bus_params -r BusParamsBilling bus_params_billing.xml
  3. In the file, change disabled to enabled:

    <SequentialCycleDiscounting>enabled</SequentialCycleDiscounting>
  4. Save the file as bus_params_billing.xml.

  5. Load the XML file into the BRM database:

    pin_bus_params bus_params_billing.xml
  6. Stop and restart the CM.

  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.

Canceling Discount Offers

You typically cancel a discount offer when you cancel the bundle in which it is bundled or when you close the account or service that owns the discount offer. You can also cancel a discount offer immediately or backdate the cancellation to a date earlier than the current date. A discount offer gets canceled automatically when the discount offer's purchase end date has been reached.

When you cancel a discount offer, you also prorate and charge cycle forward fees that may have been discounted for the period during which the discount offer is no longer valid.

To cancel a discount offer, you must specify the quantity to cancel:

  • If the quantity is the same as the quantity purchased by the account or service, BRM cancels the discount offer.

  • If the quantity is less than the quantity purchased by the account or service, BRM does not cancel the discount offer; it subtracts that quantity from the internal count variable within the /purchased_discount object that represents the discount offer.

By default, when you cancel a discount offer, BRM retains the /purchased_discount object that describes the discount offer with a status of Canceled. You can specify whether to delete /purchased_discount objects or retain them with a status of Canceled.

Changing the status of a discount offer to canceled sets the purchase, usage, and cycle end times to the cancellation time.

When you cancel a discount offer for an account or service, you also cancel the discount offer for each discount sharing group that the account or service owns. For information about discount sharing groups, see "About Charge and Discount Sharing Groups".

See these related topics:

Configuring Discount End Dates during Mid-Cycle Cancellations

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 two ways to handle the discount:

  • By default, BRM sets the discount end date to the end date of the accounting cycle.

  • You can configure BRM to cancel the discount immediately. In this case, BRM sets the discount end date to the cancellation date.

To enable this feature, run the pin_bus_params utility to change the CancelFullDiscountImmediate business parameter. For information about this utility, see "pin_bus_params" in BRM Developer's Guide.

To immediately cancel discounts canceled in mid-cycle:

  1. Go to BRM_home/sys/data/config.

  2. Create an XML file from the /config/business_params object:

    pin_bus_params -r BusParamsSubscription bus_params_subscription.xml
  3. In the file, change disabled to enabled:

    <CancelFullDiscountImmediate>enabled</CancelFullDiscountImmediate>
  4. Save the file as bus_params_subscription.xml.

  5. Load the XML file into the BRM database:

    pin_bus_params bus_params_subscription.xml
  6. Stop and restart the CM.

  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.

Rating Delayed Events for a Canceled Discount Offer

By default, when you cancel a discount offer instance, you set the /purchased_discount object's status to Canceled. When you set up BRM to use delayed billing, BRM requires information about the canceled discount offers. BRM uses this information to rate the delayed events that were generated before the discount offer was canceled. To rate events for canceled discount offers, the canceled discount offers must not be deleted.

BRM does not delete canceled discount offers by default. To ensure that canceled discount offer objects are not deleted, do the following:

  1. Open the CM configuration file (BRM_home/sys/cm/pin.conf).

  2. If necessary, set the value of the keep_cancelled_products_or_discounts entry to 1.

  3. Save and close the file.

  4. Restart the CM.

  5. Edit the PCM_OP_SUBSCRIPTION_POL_SPEC_CANCEL_DISCOUNT policy opcode. By default, this policy opcode keeps /purchased_discount objects when they are canceled. Verify that you set the opcode to cancel, not delete, the discount offer.

When you change the status of a discount offer to Canceled, you also set its purchase, usage, and cycle end dates to the cancellation date.

Changing the Status of Discounts Canceled in Mid-Cycle

When an entire discount is applied to discounts that are canceled in the middle of a cycle, BRM sets the discount to expire at the end of the cycle, but its status remains active.

To change the status of expired discounts from active to canceled, you must run the pin_discount_cleanup utility with the -m parameter.

You can run this utility daily or add it to the pin_bill_day utility to be run automatically.

Deleting Canceled Discount Offers

You might want to delete canceled discount offers from your database (for example, to improve performance by reducing the amount of data stored in the database).

Note:

  • Do not delete canceled discount offers if you use delayed billing.

  • Do not delete canceled discount offers if you rerate events. Events that use deleted discount offers cannot be rerated.

To delete /purchased_discount objects when you cancel a discount offer:

  1. Open the CM configuration file (BRM_home/sys/cm/pin.conf).

  2. Change the value of the keep_cancelled_products_or_discounts entry:

    • 0 deletes /purchased_discount objects when you cancel the discount offer.

    • 1 (default) keeps the canceled discount offers in /purchased_discount objects.

  3. Save and close the file.

  4. Restart the CM.