1 About Rerating Events

Learn about rerating events in Oracle Communications Billing and Revenue Management (BRM) using Oracle Communications Elastic Charging Engine (ECE).

Topics in this document:

• About Rerating Events

• Run-time Options for Rerating

• How BRM Applies the Balance Impacts of Rerating

• How BRM Generates Rerated Events

If you are using the BRM real-time rating and batch rating engines for usage rating, see "Setting Up Rerating" in BRM Configuring Pipeline Rating and Discounting for information about rerating events.

About Rerating Events

You might need to rerate events for several reasons. For example:

• To correct charges.

  For example, if several customers are charged the wrong price for using a service, you can rerate the events for all those customers.

• To rerate an account when a CSR backdates a subscriber's purchase or cancellation.

  For example, if a customer upgrades a service and purchases a backdated charge offer, you can rerate events based on the old charge offer using the upgraded charge offer.

• To rerate events that should have been rated using a different charge offer.

• To correct rollover amounts consumed by offline charging.

  This can occur if a delayed event arrives after the end of the accounting cycle and during the delayed billing period. The event can borrow against the rollover of the current cycle even when events of the current cycle consume the current rollover.

• To reset first-usage validity dates for recurring charges associated with offers or balances that start on the first usage.

  For example, suppose the first event rated was not the first event to use the offer's service. In that case, rerating corrects the order of events and resets the validity period based on the first-usage event.

• To perform backout-only rerating.

  Backout-only rerating backs out the balance impacts of rating without reapplying new balance impacts.

BRM rerates events in two separate processes:

1. It finds the events to rerate and groups them into a rerate job. For example, it could find all events associated with a charge offer and then group them into a rerate job.

   You can perform this task in two different ways:

   • Manually using the pin_rerate utility. See "Manually Creating Rerate Jobs".

   • Automatically through the BRM automatic rerating mechanism. In this case, when an event occurs, such as backdating a customer's purchase, BRM creates rerate jobs to rerate those events. You must configure BRM to create rerate jobs automatically. See "Configuring BRM to Create Rerate Jobs Automatically".

2. It rerates the events in the rerate job. You perform this task by running the pin_rerate utility manually or through a cron job. See "Processing Events in Rerate Jobs".

   If you use ECE for usage rating, the BRM server sends the usage events to ECE to rerate. ECE rerates the events and sends the new balance impacts to the BRM server.

   If you use the BRM real-time rating and batch rating engines for usage rating, BRM rerates the events. See "Setting Up Rerating" in BRM Configuring Pipeline Rating and Discounting.

BRM uses rerate jobs for two purposes:

• To manage the processing of many events in an efficient, transactional way. Multiple rerate jobs are created for every rerate request.

• To manage the status of the accounts selected for rerating. For example, if an account is part of a rerate job in progress, it cannot be migrated to another database until rerating has finished.

Run-time Options for Rerating

When you rerate events, you have the following options:

• You can select events for rerating based on various criteria such as the time the event occurred, the account number, bundles, charge offers, discount offers, event, service, and so on. See "About Manually Selecting Events for Rerate Jobs" for information.

• You can control the order in which rerating occurs by creating reason codes. For example, to rerate events that impact future rating, such as volume-based discounting, use reason codes to rerate those events first. See "Specifying the Order to Process Rerate Jobs".

• You can specify the order in which events are rated by either the order that they were created in the BRM database, or by the order in which the events occurred. See "Specifying the Event Sequence in a Rerate Job" for information.

• You can run reports during rerating that include statistics such as the original amount, rerated amount, and the difference between them. See "Generating Reports During Rerating" for information.

• You can rerate events without reapplying a charge. This is known as back-out rerating. You typically use this only for usage charges that should not have occurred. See "Backing Out Rating for Select Events" for information.

How BRM Applies the Balance Impacts of Rerating

BRM rerates both billed and unbilled events and can rerate events that belong to multiple billing cycles. Therefore, BRM might need to distribute balance impacts across numerous balances.

When rerated events include noncurrency balance impacts, BRM rerating charges or credits the account accordingly. Financial effects on accounts receivable (A/R), general ledger (G/L), and taxation are considered during rerating.

When an event is rerated, BRM backs out the event from the BRM database by creating an adjustment event that entirely negates the original balance impacts. Adjustments are handled differently depending on if the event is billed or unbilled.

• If the event is unbilled, a shadow adjustment event is created. This event is called a shadow event because its balance impact is added to the original event's bill item rather than an adjustment item. See "About Rerating Unbilled Events".

• If the event has already been billed or posted to the G/L, a regular adjustment event is created. See "About Rerating Billed and Posted Events".

When the total rerating adjustment is zero, BRM does not generate a rerating adjustment event if the balance impacts of rerating and previous rating are equivalent. To determine if the balance impacts are equal, BRM compares the values of certain balance impact fields for rerating with the previous rating, such as the balance element ID and balance group. You can customize how BRM determines whether the balance impacts of rerating and the previous rating are equivalent by modifying the event balance impact fields used for comparison. See "Configuring Rerating Adjustment Events".

About Rerating Unbilled Events

When unbilled events are rerated, a shadow adjustment event is added to the original event's bill item instead of an adjustment item.

Note:

When recording a shadow event, you can customize your invoice to either show the details of rerating or show the result only in an end balance. See BRM Designing and Generating Invoices for information.

Shadow events are handled differently for usage events and recurring events:

• When unbilled usage events are rerated, the shadow adjustment event fully negates the original balance impacts and applies new balance impacts for the rerated amount.

• When unbilled recurring events are rerated, the shadow adjustment event fully negates the original balance impacts. Then a new recurring event is created that applies the rerated balance impacts. The new recurring event is the same type of event as the original event.

Adjustments When Billing Follows Rerating

When the purchase start time is the same as the current accounting cycle end date, the cycle forward fee balance impact is applied to the next month's bill instead of the current month's bill when billing is run after rerating is performed.

For example, suppose an account is created on January 1 with a cycle forward fee of $20, and the purchase start time is deferred by one month (set to the accounting cycle end date). When pin_rerate is run on February 1, rerating internally triggers automatic billing because the purchase start time is the same as the accounting cycle end date. The billing process changes the status of the bill item to open. Because the bill item status is now open, rerating applies the rerate adjustments to the next bill. When regular billing is run on February 2, the cycle fee is not applied to the January bill and is instead applied to the February bill.

About Rerating Billed and Posted Events

When you rerate events that have already been billed, and unbilled events already posted to the G/L, an adjustment event entirely negates the original balance impacts. It applies new balance impacts for the rerated amount. The results of rerating are applied to the adjustment item in the next bill, which is the bill for the current cycle. For billed cycle fee, fold, rollover, and cycle discount events, a new cycle event is then created that applies the rerated balance impacts.

When billing is run, if a noncurrency balance is zero, no cycle event is generated for that balance. For example, no rollover event is created if there are no remaining minutes to roll over at billing time. However, if rerating creates a nonzero balance that was previously zero when billed, the rerating process generates the appropriate cycle event.

Determining the G/L Entry for an Event

The general ledger (G/L) entry is determined at rating time. If you rerate due to pricing changes, the G/L entry could change. Whether to record a shadow or adjustment event, you must determine the correct balance to be posted in the G/L.

When recording a shadow event, the G/L ID of the rerating balance impacts has the same G/L ID as the original event's balance impacts. If you changed the G/L ID after the original event was rated, the balance impacts of rerating use the new G/L ID.

When recording an adjustment, you can configure the G/L ID to use. For example, you can use the same G/L ID as the original event, a new G/L ID, or an adjustment G/L ID (a separate G/L ID bucket to record all adjustments as part of rerating). The adjustment G/L ID can be the same or different than the G/L ID used for regular (not rerated) event adjustments. For information about setting up G/L IDs, BRM Collecting General Ledger Data.

How Rerating Affects Account Migration

When an account is selected for rerating, the account cannot be migrated to another database until rerating is complete. Otherwise, the account is not rerated. For this reason, the Account Migration Manager (AMM) does not allow the migration of an account to another database if it is being rerated.

However, the account is migrated if the rerate job status is NEW. In this case, the AMM deletes the account from the rerate job in the source database and creates a new rerate job with the account in the destination database.

Note:

After the account migration, you must run pin_rerate in the destination database to rerate the account.

How BRM Generates Rerated Events

BRM rerates events in chronological order:

• Usage events are rerated in order starting with the earliest usage event.

• Rollover, fold, cycle discount, and cycle fee events are generated in the order they logically occur. For example, billing-time discount events are generated before rollover events.

There are three ways in which rerating generates events:

• Rerate the original event.

  This process passes the event being rerated to ECE for rerating. This is the most basic rerating process.

• Reapply business logic based on information in the original event.

  This process passes information from the event being rerated to the opcode that generated the event. The opcode may or may not generate a new event. This process is used when the event attributes may be different after rerating. For example, a charge offer's purchase fee may have been changed since the purchase fee event was generated.

  Usually, purchase events and cancellation events are not directly rerated. Instead, information in the original purchase event and cancel event is used to generate new fee events, if applicable.

• Reapply business logic independent of the original event.

  This process performs business logic that might generate new events even if no existing event exists. With this process, information from the original event is not used. Instead, the original event's business logic is reapplied, and a new event is generated, if appropriate.

  For example, when rerating an account for a specific period, if the events selected for rerating are associated with charge offers that have a cycle fee, rerating calls the cycle fee opcode and generates a new cycle fee event based on the charge offer's current rates. This is done independent of any existing cycle fee event. If there is an existing cycle fee event, it is replaced by the corresponding new cycle fee event generated by rerating.

  In some cases, the purchase- and cancellation-fee events are directly rerated because the purchase and cancellation events may not be available for rerating. For example, when rerating deferred purchase fees or when using selective rerating in which only purchase or cancellation-fee events are specified.

The following events are not rerated but are reapplied because they were not originally generated by rating:

• /event/billing/adjustment

• /event/billing/debit

• /event/billing/dispute

• /event/billing/item

• /event/billing/settlement

• /event/billing/payment

• /event/billing/reversal

• /event/billing/writeoff

• /event/billing/cycle/tax

• /event/billing/refund

• /event/billing/charge

Table 1-1 shows the rerating process for specific types of events.

Table 1-1 Rerating Process and Event

Event Type	Order of Rerating	How Rerated
Usage	Chronological, based on event time.	Rerate the original event.
Cycle fee	Generated according to the time that the charge offer is purchased or canceled or when the associated accounting cycle starts or ends, and based on the logical order of events.	Reapply business logic independent of the original event.
Rollover	Generated according to the time that the associated billing cycle ends, and based on the logical order of events.	Reapply business logic independent of the original event.
Fold	Generated according to the time that the associated billing cycle ends, and based on the logical order of events.	Reapply business logic independent of the original event.
Billing-time discount	Generated according to the time that the associated billing cycle ends, and based on the logical order of events.	Reapply business logic independent of the original event.
Purchase	Chronological, based on event time.	Reapply business logic based on information in the original event.
Cancellation	Chronological, based on event time.	Reapply business logic based on information in the original event.

How Failed Rerate Jobs Are Processed

The accounts in a rerate job are typically processed individually in separate rerate operations. When rerating fails for one or more accounts in a rerate job, the pin_rerate utility sets the status of the accounts in the rerate job batch to FAILED. When the rerating process is complete for the rerate job, pin_rerate creates a new rerate job consisting of only the accounts that failed. The new rerate job is processed the next time pin_rerate is run.

If an account selected for rerating is associated with a subscription service that was transferred during the period for which rerating is specified, then the account to which the service was transferred is included in the rerate job and all those accounts are rerated concurrently in a single rerate operation. When rerating fails for one of these accounts, then rerating fails for all accounts in the rerate request. In this case, pin_rerate creates a new rerate job containing all the accounts in the rerate request.

For example, subscription service X is originally owned by Account A and transferred to Account B on June 15. Later in the month, it is transferred from Account B to Account C. Rerating of Account A from June 1 also results in rerating of accounts B and C. Accounts A, B, and C are grouped together in a single rerate request. If rerating fails for any of these accounts, pin_rerate creates a new rerate job consisting of all three accounts in a single rerate request. The accounts are rerated again the next time pin_rerate is run.