About Rerating Events

58 About Rerating Events

This chapter provides an overview of Oracle Communications Billing and Revenue Management (BRM) rerating.

About Rerating

BRM rerating is the process you use to rerate events that were originally rated in batch by Pipeline Manager or in real time. You might rerate events for several reasons:

To rerate a group of accounts after changing a charge offer
To rerate an account when a customer service representative (CSR) backdates a subscriber's purchase or cancellation
To back out events when call detail records (CDRs) contain field errors
To rerate events when the rating conditions change during the session
Note:
- Member, child, and subordinate accounts in charge sharing, discount sharing, and account sponsorship and hierarchy groups are not automatically rerated when the parent or sponsoring account is rerated. For more information, see "About Rerating Events for Account Sharing Groups".
- You can rerate remittance accounts, but rerating subscriber accounts does not automatically rerate the remittance accounts. Events already included in remittance processing are not rerated.

The balance impact of rerating is the difference between the original rated event and the rerated event. This difference is applied to the account balance in the current billing cycle. For more information, see "How BRM Applies the Balance Impacts of Rerating".

About the Rerating Process

The rerating process consists of the following steps:

Extracting events. BRM extracts the events to rerate for an account or a group of accounts from the BRM database.
Restoring balances. BRM backs out the original event balance impacts and restores the account's discount and aggregation balances to their original states before rating the events.
Calculating new balances. BRM rerates the events based on new pricing information and calculates the new discount and aggregation balances.
Recording the event. BRM loads the events with the new balance impacts into the BRM database, updating all relevant account data.

About Automatic Allocation from Rerating

By default, BRM creates unallocated items for any adjustment items that are created as a result of rerating.

Corrective Billing and Automatic Allocation of Rerating Adjustments

If your corrective bills must contain the aggregation and allocation of automatic adjustments to the items on the original bill, you must enable the AllocateReratingAdjustments business parameter before you rerate the original bills. When the AllocateReratingAdjustments business parameter is enabled, adjustment details by original item by original bill are reported on the next bill for regular billing also.

To ensure that the corrective billing process includes or excludes these adjustments, check the setting for the AllocateReratingAdjustments business parameter before you run the rerating process.

If BRM has rerated a /bill object without allocating automatic adjustments (from the rerating) to the original bills, the corrective bill for that /bill object will not include the item adjustments generated by that rerating.

Note:

For such a /bill object, if you set the AllocateReratingAdjustments business parameter to enabled and rerun the rerating process for the bill, BRM does not allocate the adjustments.

You must manually allocate the rerated items before you generate the corrective bill for such a /bill object.

If you enable BRM to automatically allocate the item adjustments generated by the rerating process to the original bill, BRM allocates adjustments to the bill items being corrected in the following manner:

For open item accounting, the adjustment items are allocated to each bill that was corrected. Allocation is made to each of the original bills that included events or items that were corrected by these adjustments.
For balance forward accounting, corrections are posted to the last bill only. Therefore, the rerating allocation is made to the final bill only. This final bill carries over the balances from all prior bill periods.

Enabling Automatic Allocation of Rerating Adjustments

To enable automatic allocation of rerating adjustments:

Go to the BRM_home/sys/data/config directory, where BRM_home is the directory in which BRM is installed.
Run the following command, which creates an editable XML file from the rerate instance of the /config/business_params object:
```
pin_bus_params -r BusParamsRerate bus_params_rerate.xml
```
This command creates the XML file named bus_params_rerate.xml.out in your working directory. To place this file in a different directory, specify the path as part of the file name.
Open the bus_params_rerate.xml.out file.

Search for the following line:

<AllocateReratingAdjustments>disabled</AllocateReratingAdjustments>

Change disabled to enabled.
Save the file as bus_params_rerate.xml.
Go to the BRM_home/sys/data/config directory, which includes support files used by the pin_bus_params utility.
Run the following command, which loads this change into the appropriate /config/business_params object:
```
pin_bus_params PathToWorkingDirectory/bus_params_rerate.xml
```
where PathToWorkingDirectory is the directory in which bus_params_rerate.xml resides.

Caution:

BRM uses the XML in this file to overwrite the existing rerate 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 rerate configuration.
Read the object with the testnap utility or Object Browser to verify that all fields are correct.
Stop and restart the Connection Manager (CM).
(Multischema systems only) Run the pin_multidb script with the -R CONFIG parameter.

About Deferred Taxes During Rerating

By default, BRM does not compute deferred tax during rerating.

Enabling Calculation of Deferred Taxes During Rerating

Note:

When deferred taxation is enabled for rerating:

You cannot use selective rerating.
You cannot rerate events created by Bill Now.
You cannot rerate events that use multiple tax suppliers.

By default, BRM calculates taxes on any deferred taxable amount in the rerated events during the subsequent bill run. The rerated tax appears on the invoice for the subsequent bill run. Calculating taxes during rerating using the ApplyDeferredTaxDuringRerating business parameter enables corrected invoices to show the corrected tax amount. When combined with corrective invoicing, rerated events will occur and their tax amounts will appear on the invoice for the original billing period.

To enable calculation of deferred taxes during rerating:

Go to the BRM_home/sys/data/config directory.
Run the following command, which creates an editable XML file from the rerate instance of the /config/business_params object:
```
pin_bus_params -r BusParamsRerate bus_params_rerate.xml
```
This command creates the XML file named bus_params_rerate.xml.out in your working directory. To place this file in a different directory, specify the path as part of the file name.
Open the bus_params_rerate.xml.out file.

Search for the following line:

<ApplyDeferredTaxDuringRerating>disabled</ApplyDeferredTaxDuringRerating>

Change disabled to enabled.
Save the file as bus_params_rerate.xml.
Go to the BRM_home/sys/data/config directory, which includes support files used by the pin_bus_params utility.
Run the following command, which loads this change into the appropriate /config/business_params object:
```
pin_bus_params PathToWorkingDirectory/bus_params_rerate.xml
```
where PathToWorkingDirectory is the directory in which bus_params_rerate.xml resides.

Caution:

BRM uses the XML in this file to overwrite the existing rerate 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 rerate configuration.
Read the object with the testnap utility or Object Browser to verify that all fields are correct.
Stop and restart the CM.
(Multischema systems only) Run the pin_multidb script with the -R CONFIG parameter.

About Rerating Events by Using the Rates Applied when the Rating Conditions Change During the Session

By default, events are rerated in order of occurrence based on the event end time. Rerating the events using the OfferEligibilitySelectionMode business parameter enables to rerate the events in order of event start time when the rating conditions change during the session. For example, if during a call session, the subscriber adds the called number of that session to a Friends and Family list, BRM applies the Friends and Family discount for the session from the time the called number is added to the Friends and Family list. When the call is rerated, the actual rate is applied from the start time of the call until the called number is added to the Friends and Family list, and the discount is applied for the remaining session.

Enabling Rerating when the Rating Conditions Change During the Session

To enable rerating when the rating conditions change during the session:

Go to the BRM_home/sys/data/config directory, where BRM_home is the directory in which BRM is installed.
Run the following command, which creates an editable XML file from the rerate instance of the /config/business_params object:
```
pin_bus_params -r BusParamsRerate bus_params_rerate.xml
```
This command creates the XML file named bus_params_rerate.xml.out in your working directory. To place this file in a different directory, specify the path as part of the file name.
Open the bus_params_rerate.xml.out file.

Search for the following line:

<OfferEligibilitySelectionMode>endtime</OfferEligibilitySelectionMode>

Change endtime to timeperiod.
Save the file as bus_params_rerate.xml.
Go to the BRM_home/sys/data/config directory, which includes support files used by the pin_bus_params utility.
Run the following command, which loads this change into the appropriate /config/business_params object:
```
pin_bus_params PathToWorkingDirectory/bus_params_rerate.xml
```
where PathToWorkingDirectory is the directory in which bus_params_rerate.xml resides.

Caution:

BRM uses the XML in this file to overwrite the existing rerate 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 rerate configuration.
Read the object with the testnap utility or Object Browser to verify that all fields are correct.
Stop and restart the CM.
(Multischema systems only) Run the pin_multidb script with the -R CONFIG parameter.

Understanding the BRM Rerating Features

Using BRM, you can rerate events in the following ways:

By using Pipeline Manager to rerate pipeline-rated events only. This method is used for rerating events originally rated by Pipeline Manager.

With this method, you extract the events for rerating from the BRM database by using the pin_event_extract utility. You then rerate the events in a batch rerating pipeline.

Events are rerated and recorded using a two-step process: Events are rerated by the pipeline and then recorded in the BRM database when they are loaded by Rated Event (RE) Loader. As a result, pipeline event balance impacts are applied when they are recorded in the BRM database (event creation time).

Because an account can also have real-time event balance impacts that are recorded in real time (event end time), there is a possibility that the pipeline-rated and real-time rated event balance impacts are applied out of sequence, which might affect how BRM bills for the usage.

Note:

When using Pipeline Manager to rerate pipeline-rated events, you must determine whether this method of rerating is sufficient to provide consistent results. Accounts with pipeline-rated usage may also have real-time events, such as purchase events, cancel events, or cycle fee events that can impact the rating of usage events.
By using the pin_rerate utility to rerate pipeline-rated and real-time rated events. This method can be used for rerating events originally rated in real time and events originally rated in batch by Pipeline Manager.

With this method, you select events for rerating and rerate the events by running the pin_rerate utility. Pipeline-rated events are rerated in a real-time rerating pipeline and real-time rated events are rerated by real-time rating opcodes.

Pipeline-rated and real-time rated events are rerated and recorded in the same process. Events are rerated in order, based on the time they occurred (the event end time). This results in pipeline-rated and real-time-rated event balance impacts being applied in the correct sequence. For more information, see "About Rerating Pipeline and Real-Time Events Concurrently".

If you do not use Pipeline Manager for batch rating, you can also use pin_rerate to rerate only real-time-rated events.

Note:

Using pin_rerate to rerate events can degrade system performance, depending on the system load.

When you have a high volume of events to rerate (for example, more than 100,000), you might be able to use Pipeline Manager to rerate pipeline-rated events and use pin_rerate to rerate real-time rated events to reduce the system load. You can do this if the accounts being rerated have only real-time-rated events or have only pipeline-rated events. If accounts have both real-time rated and pipeline-rated events, you should use pin_rerate to ensure consistent results.

About Rerating Pipeline and Real-Time Events Concurrently

When you use pin_rerate to rerate pipeline-rated and real-time-rated events concurrently, by default, events are rerated in order of occurrence based on the event end time and recorded in the BRM database as they are processed. This process applies the pipeline and real-time event balance impacts in the sequence that the original real-time usage occurred.

For example, R₁ and R₂ are real-time-rated events and P₁ and P₂ are pipeline-rated events. The sequence in which these events were generated in real time was R₁, P₁, P_2,R₂. However, the order in which they were recorded in the BRM database was R₁, R₂, P₁, P₂. When these events are rerated by pin_rerate, the events are rerated and recorded in the original sequence in which they occurred (R₁, P₁, P_2,R₂).

You can also use pin_rerate parameters to rerate the events in the order they were originally recorded (R₁, R₂, P₁, P₂).

What You Can Do with Rerating

When using Pipeline Manager to rerate pipeline-rated events only, you can do the following:

Select accounts and events for rerating based on various criteria, such as:
- Account number
- Accounts that have events related to specific bundles, charge offers, discount offers, or specific event and service types
- Events associated with specific charge offers, discounts, subscription services, or bill units
Perform back-out-only rerating, which backs out the balance impacts of rating without reapplying new balance impacts.

When using pin_rerate to rerate pipeline-rated and real-time-rated events, you can do the following:

Select accounts and events for rerating based on various criteria such as account number, bundles, charge offers, discounts, event type, service type, bill unit and so on.

Rerating a bill unit rerates all usage events, cycle events, billing-time discounts, folds, and rollover events associated with the bill unit.
Perform back-out-only rerating, which backs out the balance impacts of rating without reapplying new balance impacts.
Rerate real-time-rated and pipeline-batch-rated events concurrently or, if you do not use Pipeline Manager for batch rating, rerate only real-time-rated events.
Assign a rerate reason code to accounts selected for rerating. This enables you to rerate only accounts matching the reason for rerating.
Set up automatic rerating, which automatically selects certain events for rerating so that you do not need to specify the accounts and events when you run the pin_rerate utility. You can set up the following automatic rerating features:
- Automatic rerating for backdated events, rate changes, and rollover corrections
- Out-of-order rerating for pipeline-rated events that are rated out of order (non-chronologically)
- Trigger-dependent rerating for events based on custom rerating triggers that you configure. For example, you can automatically select events for rerating that are rated for a charge offer that has been canceled.
Create custom pin_rerate parameters, which enables you to select events based on any event criteria.

About the Rerating Pipelines

Pipeline Manager rerates only the events that it previously rated. Pipeline Manager has two rerating pipelines. The one you use depends on whether you rerate events by using Pipeline Manager or by using pin_rerate:

The batch rerating pipeline. This pipeline is used when rerating only pipeline-rated events by using Pipeline Manager. It receives and rerates events in batches. The rerated events are loaded into the BRM database in batches by RE Loader.
The real-time rerating pipeline. This pipeline is used when rerating pipeline-rated events by using pin_rerate. It rerates events individually that it receives from the CM. The rerated events are recorded into the BRM database as they are processed.

How BRM Applies the Balance Impacts of Rerating

BRM rerating handles both billed and unbilled events and rerating events across billing cycles. When events include noncurrency balance impacts, BRM rerating properly redistributes noncurrency balance elements and charges or credits the account accordingly. Financial impacts to accounts receivable (A/R), general ledger (G/L), and taxation are taken into account when adjustments are made as a result of rerating.

When an event is rerated, BRM backs out the event from the BRM database by creating an adjustment event that fully negates the original balance impacts. This adjustment event can be either a shadow adjustment event or a regular adjustment event:

If the event is unbilled, a shadow adjustment event is created. 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".

For rerated usage events, the balance impacts of rerating are applied by the adjustment event. For rerated cycle events, a new cycle event is created that applies the balance impacts of rerating. Cycle events include cycle fees, folds, rollovers, and cycle discounts.

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 equivalent, BRM compares the values of certain balance impact fields for rerating with previous rating, such as the balance element ID and balance group. If the values are different, BRM treats the rerated balance impacts as unique and generates rerating adjustment events.

You can customize how BRM determines whether the balance impacts of rerating and previous rating are equivalent by modifying the event balance impact fields that are used for comparison. For more information, see "Determining Whether Balance Impacts of Rerating and Previous Rating Are Equivalent".

How BRM Generates Rerated Events

BRM rerates events in chronological order:

Usage events are rerated in order starting with the earliest usage event.
For rollover, fold, and cycle discount events, BRM generates new events and applies the balance impacts according to the time that billing was run for the associated cycle.
For cycle fee events, BRM generates new events and applies the balance impacts according to the time that the accounting cycle ends or when the charge offer is purchased or canceled.

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

Rerating generates events in the following ways:

By rerating the original event

This process passes the event being rerated to the rating opcode. Rerating generates an adjustment event to apply the balance impacts of rerating. This is the most basic rerating process.
By reapplying 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. To reapply the purchase fee, rerating passes the charge offer information in the original bundle-purchase event to the PCM_OP_SUBSCRIPTION_PURCHASE_DEAL opcode, which generates a new purchase fee event, if applicable.

Note:

In some cases, purchase and cancellation events are not available during rerating. In such cases, BRM rerates the purchase-fee or cancellation-fee event. For more information, see "Events That Are Not Rerated".
By reapplying business logic independent of the original event

This process performs business logic that may generate new events even if there is no existing event. With this process, information in the original event is not used. Instead, the business logic that generated the original event 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.

Table 58-1 shows the rerating process for specific event types.

Table 58-1 Rerating Process and Event Type

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.

About Rerating Unbilled Events

When unbilled events are rerated, 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 to an adjustment item.

Rerating Unbilled Usage 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.

Rerating Unbilled Cycle Events

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

Note:

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 1 month (set to the accounting cycle end date). On February 1, when pin_rerateis run from January 1, because the purchase start time is the same as the accounting cycle end date, rerate internally triggers automatic billing. 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; instead, it is applied to the February bill. For more information about rerating billed events, see "About Rerating Billed and Posted Events".

About Rerating Billed and Posted Events

When you rerate events that are already billed and unbilled events that are already posted to the G/L, the results of rerating are applied as adjustments to the next bill, which is the bill for the current cycle. The balance impacts are applied to the adjustment item.

Rerating Billed and Posted Usage Events

When usage events that are billed or posted to the G/L are rerated, an adjustment event fully negates the original balance impacts and applies new balance impacts for the rerated amount.

Rerating Billed and Posted Cycle Events

For billed cycle fee, fold, rollover, and cycle discount events, an adjustment event is created that fully negates the original balance impacts. The adjustment is applied to the current billing cycle and does not impact the original event's items. A new cycle event is then created that applies the rerated balance impacts. The new cycle event is of the same event type as the original event and is applied to the current cycle.

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

About Rerating and Pricing Changes

Changes to account charge offers are audited. If you change a charge offer attribute after events are rated, and then rerate those events, the rerating process uses only the current account subscription data.

Events That Are Not Rerated

Usually, purchase-fee events (/event/billing/product/fee/purchase) and cancellation-fee events (/event/billing/product/fee/cancel) are not directly rerated. Instead, information in the original bundle purchase event (/event/billing/deal/purchase) and product cancellation event (/event/billing/product/action/cancel) is resent to the PCM_OP_SUBSCRIPTION_PURCHASE_DEAL and PCM_OP_SUBCRIPTION_CANCEL_PRODUCT opcodes respectively. The opcodes generate new fee events, if applicable.

In some cases, the purchase-fee 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-fee 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/charge
/event/billing/cycle/tax
/event/billing/debit
/event/billing/dispute
/event/billing/item
/event/billing/payment
/event/billing/refund
/event/billing/reversal
/event/billing/settlement
/event/billing/writeoff

About Rerating Events for Account Sharing Groups

When rerating accounts and bill units in a hierarchy, sponsor, or discount sharing group, BRM does not automatically rerate subordinate and member accounts and bill units. To rerate subordinate and member accounts and bill units, you must specify them when you select the accounts for rerating. However, when BRM rerates an event for a service associated with sponsorship, rerating impacts the appropriate sponsoring or sponsored account's balance.

About Rerating Events That Impact Sponsored Balance Elements

If the balance impacts of an event are sponsored by another account, the balance impacts of rerating are applied to the sponsoring account. For example, account A pays for Internet access for account B. If account B's events are rerated, the balance impacts of rerating the Internet usage events are applied to account A's balance.

Likewise, if a rerated event impacts a balance element that is shared with another account, the balance element in the sponsored account is adjusted. For example, account A gets 1 frequent flyer mile for every dollar that account B spends. If account B's events are rerated and its current balance is reduced from $100 to $50, account A's frequent flyer miles are adjusted from 100 to 50.

If a rerated, sponsored event impacts a balance element that is shared by more than two accounts, rerating adjusts only the balances in the rerated account and the sponsoring account. For example, account A shares free minutes with accounts B and C. If account B and account C both make calls, and then account B is rerated, any impact on the free minutes account B used is applied to account A. However, that free-minute balance impact in account A is not carried over to account C, even though account C shares those balance elements.

BRM Functionality Affected by Rerating

When you rerate events, the following areas in BRM are affected:

General ledger entries. See "Determining the G/L Entry for an Event".
Invoices. See "Displaying Shadow-Event Rerating Details on Invoices".

Determining the G/L Entry for an Event

The G/L entry is determined at the time of rating. If you rerate as a result of pricing changes, the G/L entry could change. Whether you record a shadow event or an 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 have 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.

Displaying Shadow-Event Rerating Details on Invoices

When recording a shadow event, you can customize your invoice to either show the details of rerating or show the result of rerating only in an end balance.

To customize your invoice:

Open the BRM_home/sys/cm/pin.conf file.
Set the show_rerate_details entry:
- To show the details of rerating, set the entry to 1.
- To show the result of rerating only in an end balance, set the entry to 0. The default is 0.
For example:
```
- fm_inv_pol show_rerate_details 0
```
Save and close the file.
Stop and restart the CM.

Determining Whether Balance Impacts of Rerating and Previous Rating Are Equivalent

When usage events are rerated, an adjustment event is generated to apply the balance impacts of rerating. The total balance impacts of the adjustment event is the difference between the previous rating and rerating results.

When rerating produces the same result as previous rating, creating an adjustment event is not necessary. However, because an event can include multiple balance impacts, BRM must ensure that the balance impacts in each rating process are actually equivalent.

To determine whether the balance impacts of rerating and previous rating are equivalent, BRM checks the following values of the balance impacts in the event. If any of these values is different for rerating than it is for previous rating, BRM treats the associated balance impact as being unique and generates an adjustment event that includes the balance impact:

The ID of the balance element being impacted
The ID of the balance group being impacted
The G/L ID
The tax code
The charge offer used to rate the event

The list of default balance impact fields used to compare the balance impacts of events' rerating and previous rating results is stored in the /config/rerate_flds/compare_bi object in the BRM database. You can modify the balance impact fields stored in the /config/rerate_flds/compare_bi object to customize how BRM determines whether balance impacts are equivalent.

For example, if you remove the charge offer field and the total rerating adjustment is zero, adjustment events are not generated even when the charge offer used to rerate events is different than the charge offer previously used (providing the other balance impact fields are the same). Or, if you specify additional balance impact fields, adjustment events are generated when the values of those fields differ. For example, you can specify the impact category field to record the rerating adjustment when calls are made from different locations even though rerating results in the same total charge.

To customize the list of event balance impact fields that determine whether rerated and previously rated balance impacts are equivalent, see "Specifying How to Compare Balance Impacts When Creating Adjustment Events".

Specifying How to Compare Balance Impacts When Creating Adjustment Events

BRM checks the /config/rerate_flds/compare_bi object during rerating. If the balance impact fields in this object have the same values in the event for both rerating and previous rating, and the total rerating adjustment is zero, the results of rerating and previous rating are considered equivalent and no adjustment event is created.

Note:

The load_pin_rerate_flds utility overwrites existing balance-impact comparison fields. If you are updating balance-impact comparison fields, you cannot load new fields only: you must load complete sets of the balance-impact comparison fields when you run the load_pin_rerate_flds utility.

Note:

The load_pin_rerate_flds utility uses a configuration file (pin.conf) located in the same directory to connect to the BRM database. Edit the configuration file to connect to your BRM database.

Note:

The load_pin_rerate_flds utility loads extraction keys that define custom pin_rerate parameters. You cannot use the same file to specify extraction keys and balance-impact comparison fields; you must run load_pin_rerate_flds with separate files for each configuration.

To customize the fields used to compare the event balance impacts of rerating with previous rating:

Open the BRM_home/sys/data/config/pin_rerate_compare_bi.xml file.

Add a RerateCompareBalImpacts element for each event balance impact field. The following balance impact fields are mandatory:
- PIN_FLD_RESOURCE_ID
- PIN_FLD_BAL_GRP_OBJ
- PIN_FLD_GL_ID
- PIN_FLD_TAX_CODE
  
  Note:
  
  PIN_FLD_PRODUCT_OBJ is specified in the pin_rerate_compare_bi.xml file by default, but it is an optional field.
You can specify any additional field from the /event object's PIN_FLD_BAL_IMPACTS array.
Save and close the file.
Run the following command, which loads the contents of the XML file into the /config/rerate_flds/compare_bi object:
```
load_pin_rerate_flds pin_rerate_compare_bi.xml
```
If you do not run the utility from the directory in which the XML file is located, you must include the complete path to the file. For example:
```
load_pin_rerate_flds BRM_home/sys/data/config/pin_rerate_compare_bi.xml
```
Stop and restart the CM.
To verify that the balance-impact comparison fields were loaded, display the /config/rerate_flds/compare_bi object by using Object Browser, or use the robj command with the testnap utility.

How BRM Tracks Rerated Events

This section is useful if you write custom code that requires accessing events that were rerated.

To back out original rated events, BRM generates adjustment events (/event/billing/adjustment/event). These events contain a compliment of all balance impacts in the original events to fully negate the events. When an event is rerated, the PIN_FLD_RERATE_OBJ field in the original rated event references this backout adjustment event.

When usage events are rerated, the new balance impacts of rerating are included in the same adjustment event that backs out the original balance impacts. This means the original event references the new event that contains the rerated balance impacts.

When cycle fee, cycle discount, fold, and rollover events are rerated, new cycle events are created to apply the balance impacts of rerating. In this case, there is no relationship between the original events and the new (cycle) events that contains the rerated balance impacts.

Because you can use flexible cycles and multiple discounts, there might be more than one rollover, fold, and discount event to rerate for a given billing cycle:

A fold event is generated per balance for each balance element that has a fold.
A rollover event is generated per balance group for each charge offer that has a rollover.
A discount event is generated for each cycle discount.