Skip Headers
Oracle® Communications Billing and Revenue Management Setting Up Pricing and Rating
Release 7.5

E16711-10
Go to Documentation Home
Home
Go to Table of Contents
Contents
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

23 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 price plan.

  • 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.

    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:

  1. Extracting events. BRM extracts the events to rerate for an account or a group of accounts from the BRM database.

  2. 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.

  3. Calculating new balances. BRM rerates the events based on new pricing information and calculates the new discount and aggregation balances.

  4. Recording the event. BRM loads the events with the new balance impacts into the BRM database, updating all relevant account data.

For more information on configuring rerating with your charging engine:

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

You enable automatic allocation of rerating adjustments by setting the AllocateReratingAdjustments business parameter in the /config/business_params object by using the pin_bus_params utility.

To enable automatic allocation of rerating adjustments:

  1. Go to the BRM_Home/sys/data/config directory, where BRM_Home is the directory in which you installed BRM components.

  2. Run the following command to create 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.

  3. Open the bus_params_rerate.xml.out file.

  4. Search for the following line.

    <AllocateReratingAdjustments>disabled</AllocateReratingAdjustments>
      
    
  5. Change disabled to enabled.

  6. Save the file as bus_params_rerate.xml.

  7. Go to the BRM_Home/sys/data/config directory, which includes support files used by the pin_bus_params utility.

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

    Note:

    To run this command from a different directory, see "pin_bus_params" in BRM Developer's Guide.
  9. Read the object with the testnap utility or Object Browser to verify that all fields are correct.

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

  10. Stop and restart the Connection Manager (CM). For more information, see "Starting and Stopping the BRM System" in BRM System Administrator's Guide.

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

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.

    For more information about rerating by using pin_rerate, see "About Comprehensive Rerating Using pin_rerate".

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, R1 and R2 are real-time rated events and P1 and P2 are pipeline-rated events. The sequence in which these events were generated in real time was R1, P1, P2, R2. However, the order in which they were recorded in the BRM database was R1, R2, P1, P2. When these events are rerated by pin_rerate, the events are rerated and recorded in the original sequence in which they occurred (R1, P1, P2, R2).

You can also use pin_rerate parameters to rerate the events in the order they were originally recorded (R1, R2, P1, P2).

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 deals, products, discounts, or specific event and service types.

    • Events associated with specific products, 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, deals, products, 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 product that has been canceled.

  • Create custom pin_rerate parameters, which enables you to select events based on any event criteria.

For more information about rerating by using pin_rerate, see "About Comprehensive Rerating Using pin_rerate".

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 the RE Loader. See "Overview of Rerating Events" in BRM Setting Up Pricing and Rating.

  • 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. See "About Comprehensive Rerating Using pin_rerate".

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 non-currency balance impacts, BRM rerating properly redistributes non-currency resources 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:

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 resource 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 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 product 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.

There are three ways in which rerating generates events:

  • Rerate 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.

  • 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 product's purchase fee may have been changed since the purchase fee event was generated. To reapply the purchase fee, rerating passes the product information in the original deal-purchase event to PCM_OP_SUBSCRIPTION_PURCHASE_DEAL, 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- or cancellation-fee event. For more information, see "Events That Are Not Rerated".
  • Reapply 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 products that have a cycle fee, rerating calls the cycle fee opcode and generates a new cycle fee event based on the product'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 23-1 shows the rerating process for specific event types.

Table 23-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 product 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 in information in the original event.

Cancellation

Chronological, based on event time.

Reapply business logic based in 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 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 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-rerate is run from January 1, since 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 non-currency resource has a zero balance, no cycle event is generated for that resource. 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 resource that was previously zero when billed, the rerating process generates the appropriate cycle event.

About Rerating and Pricing Changes

Changes to account products are audited. If you change a product 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 deal purchase event (/event/billing/deal/purchase) and product cancellation event (/event/billing/product/action/cancel) are 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- 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

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 Resources

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 resource that is shared with another account, the resource 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 resource 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 B and C both make calls, and then B is rerated, any impact on the free minutes 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 C shares those resources.

BRM Functionality Affected by Rerating

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

Determining the G/l Entry for an Event

The general ledger (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 uses the new G/L ID.

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

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, do the following:

  1. Open the CM pin.conf file in BRM_Home/sys/cm/pin.conf.

  2. 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
      
    
  3. Save and close the file.

  4. 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 resource being impacted

  • The ID of the balance group being impacted

  • The G/L ID

  • The tax code

  • The product 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 are 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 product field and the total rerating adjustment is zero, adjustment events are not generated even when the product used to rerate events is different than the product 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.

To customize the fields used to compare the event balance impacts of rerating with previous rating, you modify the pin_rerate_compare_bi.xml file and then run the load_pin_rerate_flds utility to load the contents of the file into the /config/rerate_flds/compare_bi object in the BRM database.

Caution:

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.

Important:

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 also loads extraction keys that define custom pin_rerate parameters (see "Defining Custom pin_rerate Parameters for Rerating"). You cannot use the same file to specify extractions 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:

  1. Edit the pin_rerate_compare_bi.xml file in BRM_Home/sys/data/config. 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 is an optional field.

    You can specify any additional field from the /event object's PIN_FLD_BAL_IMPACTS array.

  2. Save and close the file.

  3. Use the following command to load 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
      
    

    For more information, see "load_pin_rerate_flds".

  4. Stop and restart the CM.

To verify that the balance-impact comparison fields were loaded, you can 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 resource that has a fold.

  • A rollover event is generated per balance group for each product that has a rollover.

  • A discount event is generated for each cycle discount.

Configuring BRM for Elastic Charging Engine Rerating

You can rerate events using the Oracle Communications Elastic Charging Engine (ECE).

To configure BRM for ECE Rerating:

  1. Enable and load the ECERating business parameter. See "Enabling Elastic Charging Engine Rerating".

  2. Configure the CM for rerating. See "Configuring Connection Manager for Elastic Charging Engine Rerating".

  3. Verify that the ECE payloadconfig_ece_sync.xml, pin_notify, event_t.ctl, and event_dlay_sess_tlcs_t.ctl configuration files are loaded into the BRM environment. See "Loading the Elastic Charging Engine Configuration Files into Your BRM Environment".

  4. Verify that the acknowledgment queue (Oracle AQ database queue) is created.

    Note:

    The acknowledgment queue is created by an ECE post-installation script. For more information, see the discussion on ECE post-installation tasks in the ECE Installation Guide.
  5. Verify that the ECE External Manager (EM) Gateway is up and running. For more information, see the discussion on starting and stopping ECE in the ECE System Administrator's Guide.

You can run rerating using the pin_rerate utility. For more information on how to run rerating using the pin_rerate utility, see "pin_rerate".

Enabling Elastic Charging Engine Rerating

By default, the ECERating business parameter is disabled in BRM. You can enable this feature by modifying a field in the rerate instance of the /config/business_params object.

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

To enable ECE rerating:

  1. Go to the BRM_Home/sys/data/config directory, where BRM_Home is the directory in which you installed BRM components.

  2. 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.

  3. Open the bus_params_rerate.xml.out file.

  4. Search for the following line:

    <ECERating>disabled</ECERating>
      
    
  5. Change disabled to enabled.

  6. Save the file as bus_params_rerate.xml.

  7. Go to the BRM_Home/sys/data/config directory, which includes support files used by the pin_bus_params utility.

  8. Run the following command, which loads this change into the /config/business_params object:

    pin_bus_params PathToWorkingDirectory/bus_params_rerate.xml
      
    

    where PathToWorkingDirectory is the directory in which the bus_params_rerate.xml file 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.

    Note:

    To run this command from a different directory, see "pin_bus_params" in BRM Developer's Guide.
  9. Read the object with the testnap utility or Object Browser to verify that all fields are correct.

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

  10. Stop and restart the CM. For more information, see "Starting and Stopping the BRM System" in BRM System Administrator's Guide.

  11. (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 Connection Manager for Elastic Charging Engine Rerating

ECE uses ECE EM Gateway to connect the CM with ECE. For rerating to work with ECE, the ECE EM Gateway group and pointer entries must be configured in CM.

To configure CM for ECE rerating:

  1. Open the CM configuration file (BRM_Home/sys/cm/pin.conf) in a text editor.

  2. For real-time rerating, uncomment the following entry:

    - cm fm_module BRM_home/lib/fm_rerate.so fm_rerate_config - pin 
      
    
  3. Search for the following line:

    - cm em_group rerating PCM_OP_RATE_PIPELINE_EVENT
      
    
  4. Replace with the following:

    - cm em_group rerating PCM_OP_RATE_ECE_EVENT
      
    
  5. Edit the rerating em_pointer entry to match your environment:

    - cm em_pointer rerating ip emGateway_host emGateway_port
      
    

    where:

    • emGateway_host is the IP address of the machine on which the ECE EM Gateway resides.

    • emGateway_port is the port of the machine on which the ECE EM Gateway resides.

  6. Save and close the file.

  7. Restart the CM to enable these entries.

Loading the Elastic Charging Engine Configuration Files into Your BRM Environment

The ECE BRM Integration Pack contains the following configuration files that you must apply to your BRM installation when integrating ECE with BRM:

where ECE_Home is the directory in which ECE is installed.

Loading the ECE Payload Configuration File

Business events that include BRM data needed by ECE are defined in the ECE payload configuration file (payloadconfig_ece_sync.xml).

To load the ECE payload configuration file into your BRM environment:

  1. Copy the ECE_Home/oceceserver/brm_config/payloadconfig_ece_sync.xml file to the BRM_Home/sys/eai_js directory.

  2. Do one of the following:

    If your BRM system does not already have an EAI publisher:

    1. Open the BRM_Home/sys/eai_js/Infranet_eai.properties file in a text editor.

    2. Set the infranet.eai.configFile entry to point to the ECE payload configuration file:

      infranet.eai.configFile=./payloadconfig_ece_sync.xml
       
      
    3. Save and close the file.

    If your BRM system already has an EAI publisher:

    1. Merge the payloadconfig_ece_sync.xml file with the existing payload configuration file.

    2. Set the infranet.eai.configFile entry in the BRM_Home/sys/eai_js/Infranet_eai.properties file to point to the merged file.

    See "Configuring the EAI Payload for Account Synchronization" in BRM Installation Guide.

  3. Go to the BRM_Home/bin directory.

  4. Stop and restart the Payload Generator External Module (the EAI Java server) by entering the following command:

    pin_ctl restart eai_js
    

Loading the ECE Event Notification List

The ECE pin_notify configuration file contains an event notification list that BRM uses to send update requests to ECE.

To load the ECE event notification list into your BRM environment:

  1. Open your current BRM event notification file and the ECE_Home/oceceserver/brm_config/pin_notify file in a text editor.

    Tip:

    Save a copy of the original files before merging them.
  2. Merge the files by copying the contents of the ECE_Home/oceceserver/brm_config/pin_notify file to the end of the BRM event notification file. See "Merging Event Notification Lists" in BRM Developer's Guide.

  3. Save and close the BRM event notification file.

  4. Close the ECE_Home/oceceserver/brm_config/pin_notify file.

  5. Load the merged file into the database by running the load_pin_notify utility using the following command:

    load_pin_notify -v event_notification_configuration_file_name
     
    
  6. Stop and restart the CM.

Updating the RE Loader Control Files with ECE Control Data

The following ECE control files are used by the BRM Rated Event (RE) Loader. RE Loader uses these files for processing rated events in the call details records (CDR) coming from ECE.

  • event_t.ctl: Includes control data used for loading data from the ECE usage request into columns of the EVENT_T table.

  • event_dlay_ses_tlcs_t.ctl: Includes control data used for loading input and output volume data from the ECE usage request into columns the of the EVENT_DLAY_SES_TLCS_T table.

To update the RE Loader control files with ECE control data:

  1. Go to BRM_Home/apps/pin_rel directory.

  2. Copy the ECE_Home/oceceserver/brm_config/event_t.ctl and ECE_Home/oceceserver/brm_config/event_dlay_ses_tlcs_t.ctl control files to each processing directory in BRM_Home/apps/pin_rel.

    For example, if you have a processing directory called GPRS, copy the ECE event_t.ctl and ECE event_dlay_ses_tlcs_t.ctl control files to BRM_Home/apps/pin_rel/GPRS.

    See "Setting Up RE Loader Processing Directories" in BRM Configuring Pipeline Rating and Discounting.

  3. If you have customized control files, modify the ECE control files to load your custom data.

    Customized control files are used, for example, when you write an extension mapping of an ECE usage request attribute in the RE Loader.

    For more information, see "Adding Support for a New Service" in BRM Developer's Guide, and "Adding New Event Types for RE Loader to Load" in BRM Configuring Pipeline Rating and Discounting.

    For information about adding custom ECE usage-request attributes, see the discussion on creating new usage requests in the ECE Implementation Guide.