28 About Comprehensive Rerating Using pin_rerate

This chapter provides an overview of rerating using the Oracle Communications Billing and Revenue Management (BRM) "pin_rerate" utility to rerate real-time-rated events and pipeline-batch-rated events.

Note:

This documentation does not apply to rerating only pipeline-batch-rated events by using a batch rerating pipeline.

For general information about rerating, see "About Rerating Events".

About Comprehensive Rerating

The pin_rerate utility provides a comprehensive rerating solution: You can rerate both real-time-rated and pipeline-batch-rated events concurrently or, if you do not use Pipeline Manager for batch rating, you can rerate only real-time-rated events. You can select accounts and events for rerating based on any event criteria. And you can configure BRM to automatically rerate certain accounts and events when you run pin_rerate.

The "pin_rerate" utility controls the rerating workflow. It follows a different rerating process depending on whether batch pipeline rating is enabled. See:

About Rerating Real-Time-Rated and Pipeline-Rated Events Concurrently
About Rerating Events When You Do Not Use Pipeline Batch Rating

About Rerate Jobs

A rerate job is a set of objects in the BRM database used to track the accounts selected for rerating and the status of the rerating process. Rerate jobs are created for all accounts to be rerated by pin_rerate. (For more information about rerate job objects, see "How BRM Creates Rerate Jobs".)

Rerate jobs are typically associated with a batch of accounts, but can also be associated with a single account.

Rerate jobs are created manually when you use pin_rerate to select accounts for rerating. Rerate jobs are created automatically when certain events occur, such as when backdated events or rate changes trigger automatic rerating.

When you use pin_rerate to select accounts for rerating, the utility assigns accounts to each rerate job and creates 2 rerate jobs per transaction. This enables pin_rerate to more easily roll back a transaction if an error occurs.

You can configure the number of accounts assigned to each rerate job and the number of jobs to create per transaction. See "Configuring the Number of Accounts Per Job and Number of Jobs per Transaction".

About Rerating Real-Time-Rated and Pipeline-Rated Events Concurrently

When you use pin_rerate to rerate both real-time-rated and pipeline-batch-rated events concurrently, the following tasks are performed:

The utility retrieves the accounts for rerating from the BRM database based on search criteria that you specify.
BRM extracts the events associated with those accounts and then backs out the original event balance impacts.
BRM determines whether the original event was rated in real time or by the batch rating pipeline:
1. It sends events previously rated in real time to the real-time rating opcodes for rating and discounting.
2. It sends events previously rated by a batch pipeline to the real-time rerating pipeline for rating and discounting. See "About the Real-Time Rerating Pipeline".
BRM records the rerated events in the BRM database.

About the Real-Time Rerating Pipeline

The pin_rerate utility sends events previously rated by the batch rating pipeline to a real-time rerating pipeline to be rerated.

The pin_rerate utility routes the pipeline-rated events to the Connection Manager (CM). The CM sends the pipeline-rated events in the form of an flist to the NET_EM pipeline module. The NET_EM module transfers the event to the real-time rerating pipeline for rerating.

The real-time rating opcodes add to the flist all the enrichment data needed by the real-time rerating pipeline to rate the event. For example, if the real-time rating opcodes determine that a discount should be applied, it adds the discount information to the flist.

Note:

Real-time rerating process does not check credit limits when applying discounts. To configure rerating to check credit limits, create a custom iScript that sets the DETAIL.CREDIT_LIMIT_CHECK EDR field to 1. See "Creating iScripts and iRules" in BRM Developer's Guide.

Similar to a batch rerating pipeline, a real-time rerating pipeline performs both rating and discounting functions.

To rerate events, the real-time rerating pipeline gets the new pricing information from the Pipeline Manager database. Certain configuration data, such as currency and non-currency resource information, are obtained from the BRM database.

The real-time rerating pipeline performs the following tasks:

The INP_Realtime input module converts the flist received from the NET_EM module to event data record (EDR) format and creates an EDR container.

Tip:
You can also create and run an iScript to manipulate data in the EDR container before it is sent to the pipeline modules. See "Creating iScripts and iRules" in BRM Developer's Guide.
The pipeline function modules calculate the new balance impacts by using the new pricing and discounting information and then adds the balance impacts to the EDR container.
The OUT_Realtime module converts the EDR back into flist format and sends the flist to NET_EM.
NET_EM sends the flist with the new balance impacts back to the CM.
BRM updates the account's balances and records the event in the BRM database.

For detailed information about configuring the real-time rerating pipeline, see "Configuring a Real-Time Rerating Pipeline".

Figure 28-1 shows the data flow for rerating events by using the real-time rerating pipeline:

Figure 28-1 Real-Time Rerating Pipeline Data Flow

Description of ''Figure 28-1 Real-Time Rerating Pipeline Data Flow''

About Transaction Management for the Real-Time Rerating Pipeline

The real-time rerating pipeline does not use the Transaction Manager (TAM) module. Instead, transaction handling is provided by the CM. When a rerating transaction fails, the CM rolls back the transaction and restores all the account balances in the BRM database. For this reason, function modules and iScripts used by the real-time rerating pipeline are stateless.

Important:

If you use iScripts for custom processing, ensure that the iScripts are stateless.

How pin_rerate and the Batch-Rating Pipeline Synchronize Processes

While pipeline-rated events are being rerated, the batch pipeline temporarily suspends new EDRs for the accounts that are currently being rerated. When rerating is complete, account balance data in Pipeline Manager is synchronized with the account balance data in the BRM database, and the batch pipeline resumes processing the suspended EDRs using the updated data.

The batch pipeline and pin_rerate use the Account Synchronization DM and BRM standard recycling to synchronize processes.

When you run pin_rerate for concurrent rerating, the following actions are taken to synchronize pin_rerate and batch pipeline processes:

The pin_rerate utility retrieves the accounts to be rerated and creates the rerate jobs. The rerate jobs are queued until they are processed.
pin_rerate sends a business event through the Account Synchronization DM to notify the batch pipeline that rerating for the selected accounts is about to begin. When it receives the notification, the batch pipeline suspends rating incoming CDRs for the accounts and sends pin_rerate a corresponding acknowledgment event.
pin_rerate rerates the accounts in the rerate job and BRM records the new balance impacts of the rerated events in the BRM database.
pin_rerate sends a business event through the Account Synchronization DM to notify the batch pipeline that rerating is complete for the selected accounts. The batch pipeline synchronizes the account data in pipeline memory with the account data in the BRM database and resumes processing EDRs. The batch pipeline sends pin_rerate a corresponding acknowledgment event.
pin_rerate recycles the EDRs suspended during the rerating process by calling the standard recycling opcode.

For more information about the Account Synchronization DM, see "About Account Synchronization" in BRM Installation Guide.

After successful completion of each step, pin_rerate updates the rerate job status so that the next step in the rerate workflow can be executed.

Rerate jobs that are processed during concurrent rerating can have the statuses shown in Table 28-1:

Table 28-1 Status for Rerate Jobs

Status	Description
NEW	The initial status of a rerate job.
WAITING_ACCOUNT_LOCKED	The status after pin_rerate has notified the batch pipeline to suspend EDRs for accounts in the rerate job.
ACCOUNT_LOCKED	The status after pin_rerate has received acknowledgment from the batch pipeline.
RERATED	The status after the events associated with the accounts in the rerate jobs have been rerated.
READY_FOR_RECYCLE	The status after account data has been synchronized between the BRM database and Pipeline Manager and when the batch pipeline has resumed processing EDRs for the accounts in the rerate job.
COMPLETE	The status when rerating is completed for all the accounts in the rerate job.

About Suspending and Recycling EDRs during the Rerating Process

To suspend EDRs for Accounts that are being rerated, the pipeline DAT_AccountBatch module sets a rerate error code and a recycle key value in the EDR. The error code causes the EDR to be suspended by BRM standard recycling. The recycle key is used to select the EDRs to be recycled.

For information about recycling, see "About the EDR Recycling Features" in BRM Configuring Pipeline Rating and Discounting.

You must load suspended EDRs into the BRM database by running Suspended Event (SE) Loader. You typically schedule SE Loader to run automatically when you set up standard recycling. For more information, see "About Suspended Event (SE) and Suspended Batch (SB) Loader" in BRM Configuring Pipeline Rating and Discounting.

Suspended EDRs are stored in the database until they are recycled. To recycle the EDRs that were suspended during the rerating process, you run pin_rerate with the -process recycle parameter after rerating is completed. For more information, see "Recycling EDRs Suspended during Rerating".

Procedure for Concurrent Rerating of Real-Time-Rated and Pipeline-Rated Events

To rerate both real-time-rated events and pipeline-batch-rated events concurrently, you perform the following steps:

Run pin_rerate to select the accounts for rerating and create rerate jobs. See "Selecting Accounts and Events for Rerating".

Note:
Rerate jobs can also be created automatically through BRM automatic rerating or trigger-dependent rerating.
Run a series of pin_rerate commands to rerate the events associated with the accounts in the rerate job. See "Rerating Real-Time-Rated and Pipeline-Rated Events Concurrently".
Run pin_rerate to recycle the EDRs associated with the accounts in the rerate job that were suspended during rerating. See "Recycling EDRs Suspended during Rerating".

For more information, see "Using the pin_rerate Utility".

Figure 28-2 shows the rerating commands, process flow, and job status transitions when you perform concurrent rerating:

Figure 28-2 Concurrent Rerating Process Flow

Description of ''Figure 28-2 Concurrent Rerating Process Flow''

About Rerating Events When You Do Not Use Pipeline Batch Rating

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

Note:

Real-time-rated events are events that are rated by the BRM rating opcodes. Real-time-rated events include events that are loaded in batches by Universal Event (UE) Loader.

To rerate only real-time-rated events, you must configure the batch_rating_pipeline business parameter so that pin_rerate does not attempt to communicate with a batch pipeline, which will cause rerating to fail. For more information, see "Specifying Whether the Batch Rating Pipeline Is Enabled".

When rerating only real-time-rated events, the following actions are taken when you run pin_rerate:

The pin_rerate utility selects the accounts to be rerated from the BRM database based on the specified search criteria and creates rerate jobs.

Note:
Rerate jobs can also be created automatically through BRM automatic rerating or trigger-dependent rerating.
pin_rerate invokes rerating of the selected accounts in the rerate jobs.
BRM extracts the events associated with the selected accounts from the BRM database and does the following:
1. Rerates the real-time-rated events.
2. Records the new balance impacts of the rerated events in the BRM database.

After the successful completion of each step, pin_rerate updates the rerate job status so that the next step in the rerate workflow can be executed.

Rerate jobs that are processed when rerating only real-time-rated events can have the statuses shown in Table 28-2:

Table 28-2 Status for Real-Time Rerate Events

Status	Description
ACCOUNT_LOCKED	The initial status of rerate jobs.
COMPLETE	The status when rerating has completed for all the accounts in the rerate job.

Procedure for Rerating Only Real-Time-Rated Events

To rerate only real-time-rated events when you do not use Pipeline Manager for batch rating, you select the accounts to rerate and rerate the selected accounts using a single pin_rerate command. See "Processing Rerate Jobs When You Do Not Use Pipeline Batch Rating".

For more information about using pin_rerate, see "Using the pin_rerate Utility".

Figure 28-3 shows the rerating command, process flow, and job status transitions when rerating only real-time-rated events:

Figure 28-3 Rerating Only Real-Time Events

Description of ''Figure 28-3 Rerating Only Real-Time Events''

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, pin_rerate sets the status of the accounts in the rerate job batch to FAILED. When 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.

For more information about rerating accounts associated with subscription service transfer, see "Configuring Rerating for Accounts Associated With Subscription Service Transfer".

About Automatic Rerating

When certain events occur in the BRM system (such as backdated purchase events), customer accounts require rerating so they are billed accurately. In automatic rerating, BRM automatically creates rerate jobs for these events.

Note:

Automatic rerating does not immediately rerate accounts when the rerate job is created. You must still run the pin_rerate utility.

Accounts and events associated with rerate jobs that are created automatically are rerated the next time you run "pin_rerate" to process rerate jobs: you do not need to first select the accounts and events by specifying pin_rerate selection criteria. For more information, see "About Processing Rerate Jobs Created by Automatic Rerating".

You enable automatic rerating by configuring event notification to call the PCM_OP_SUBSCRIPTION_POL_GENERATE_RERATE_REQUEST policy opcode when events occur that require rerating.

Automatic rerating uses rerate reason codes. A rerate reason code is passed in to PCM_OP_SUBSCRIPTION_POL_GENERATE_RERATE_REQUEST, which uses the code to help determine whether rerating is required for an event.

BRM creates rerate jobs for automatic rerating as follows:

An event occurs that requires accounts to be rerated.

The opcode that triggers rerating when that particular event occurs creates a notification event.

Table 28-3 summarizes the types of notification events used to trigger automatic rerating and the rerating scenario to which each event applies:

Table 28-3 Types of Notifications for Automatic Rerating

Notification Events for Automatic Rerating	Rerating Scenario
/event/notification/auto_rerate	Automatic rerating of backdated events. See "About Automatic Rerating of Backdated Events".
/event/notification/rate_change	Automatic rerating for rate changes.
/event/notification/rollover_correction/rerate	Automatic rerating of rollover corrections due to delayed events.
An event by which you want rerating to be triggered	Automatic rerating for your custom rerating requirements. See "About Trigger-Dependent Rerating".

The event notification mechanism calls PCM_OP_SUBSCRIPTION_POL_GENERATE_RERATE_REQUEST.
PCM_OP_SUBSCRIPTION_POL_GENERATE_RERATE_REQUEST takes as input the event type and the rerate reason code associated with the event and analyzes the event to determine if rerating is required.

Note:
BRM reserves the range of 100 to 120 for automatic rerating reason codes.
If rerating is required, PCM_OP_SUBSCRIPTION_POL_GENERATE_RERATE_REQUEST calls the PCM_OP_RERATE_INSERT_RERATE_REQUEST opcode along with the appropriate rerating criteria to create a rerate job.

PCM_OP_SUBSCRIPTION_POL_GENERATE_RERATE_REQUEST calls PCM_OP_SUBSCRIPTION_INSERT_RERATE_REQUEST only when the reason code passed in is one of those reserved for automatic rerating (reason codes between 100 and 120). By default, if a different reason code is passed in, the opcode does nothing. To create rerate jobs for reason codes other than those reserved for automatic rerating, you must customize PCM_OP_SUBSCRIPTION_POL_GENERATE_RERATE_REQUEST.

By default, PCM_OP_SUBSCRIPTION_POL_GENERATE_RERATE_REQUEST passes a reason code of 0 (no rerate reason) to PCM_OP_SUBSCRIPTION_INSERT_RERATE_REQUEST. To rerate accounts separately based on a rerate reason code, customize PCM_OP_SUBSCRIPTION_POL_GENERATE_RERATE_REQUEST to pass the rerate reason code it receives (or a different rerate reason code). The rerate reason code is stored in the rerate job object, and you can select rerate jobs based on the specific rerate reason code when you run pin_rerate to process rerate jobs.

Note:

You can also assign reason codes when you manually create rerate jobs by using pin_rerate. For more information, see "Assigning Rerate Reasons to Rerate Jobs".

For information about rerating accounts based on a reason code, see "Rerating Real-Time-Rated and Pipeline-Rated Events Concurrently" and"Processing Rerate Jobs When You Do Not Use Pipeline Batch Rating".

You can also customize PCM_OP_SUBSCRIPTION_POL_GENERATE_RERATE_REQUEST in other ways. For example, you can change whether rerate jobs are created for specific events: such as when you want to rerate events for only a few (rather than all) automatic rerating scenarios.

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 migration of an account to another database if the account is being rerated by pin_rerate.

The AMM does not migrate an account if the account is in a rerate job and the rerate job status is one of the following:

WAITING_ACCOUNT_LOCKED
ACCOUNT_LOCKED
RERATED
READY_FOR_RECYCLE

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 is complete, you must run pin_rerate in the destination database to rerate the account.

Managing Comprehensive Rerating with Custom Applications

BRM uses the following opcodes for comprehensive rerating with pin_rerate:

PCM_OP_SUBSCRIPTION_RERATE_REBILL. See "How Comprehensive Rerating Works".
PCM_OP_RERATE_INSERT_RERATE_REQUEST. See "How BRM Creates Rerate Jobs".
PCM_OP_SUBSCRIPTION_PREP_RATE_CHANGE. See "Tracking Rate Changes for Rerating".
PCM_OP_SUBSCRIPTION_RATE_CHANGE. See "Rerating Cycle Fees".
PCM_OP_SUBSCRIPTION_POL_SPEC_RERATE. See "Customizing Event Searches for Selective Rerating".

How Comprehensive Rerating Works

To rerate events, use PCM_OP_SUBSCRIPTION_RERATE_REBILL.

This opcode rerates the events for accounts identified by the pin_rerate utility, rerating one account at a time. The rerating start time is specified in the input flist. This opcode calls other opcodes to perform rerating functions.

PCM_OP_SUBSCRIPTION_RERATE_REBILL generates either a shadow event or an adjustment event to apply the results of rerating to the account balance in the current billing cycle:

If the event is unbilled, a shadow event is created, which is an adjustment event that is applied to the bill item instead of the adjustment item.
If the event is billed, or if the event is unbilled but already posted to the G/L, an adjustment event is created and applied to the adjustment item.

PCM_OP_SUBSCRIPTION_RERATE_REBILL does not rerate, but only reapplies the balance impacts of the original event for these event types: adjustment, payment, writeoff, dispute, settlement, refund, charge, item transfer, cycle fold, cycle tax, reversal, and pre-rated.

If there is no balance impact associated with an event or if there is no rated quantity on the original event, the event is not rerated.

The input to PCM_OP_SUBSCRIPTION_RERATE_REBILL includes:

The POID of the account to rerate.
The time from which to start rerating. Events occurring from this start time are rerated.
Flags that modify rerating behavior. See "Flags Used for Rerating".
The session object. When PCM_OP_SUBSCRIPTION_RERATE_REBILL is invoked by the pin_rerate utility, the session object passed is the rerating audit object (/event/control_rerate). This object is used to generate rerating reports.

PCM_OP_SUBSCRIPTION_RERATE_REBILL does the following:

Closes the billing cycle, if due.
Retrieves all events for the account from the start date specified.
Determines the balance for each resource in the account when rerating starts. This is the current balance minus the cumulative total of all balance impacts for the resource from the rerating start time until the current time.
For each event:
- If the effective time is passed in the PIN_FLD_START_T field, no balance impact is required and the event is not rerated.
- Checks the /data/ledger_report object to determine whether the G/L for the event has been posted.
- Calls the PCM_OP_ACT_USAGE opcode to determine the difference between the original rated event and the rerated event.
  
  Note:
  PCM_OP_ACT_USAGE does not check credit limits when rerating events.
- Calls PCM_OP_ACT_USAGE again to apply the results of rerating to the account balance. If the event is sponsored, the balance impacts are applied to the sponsoring account.
- Updates the RERATE_OBJ field for the event being rerated with the POID of the new rerated event.

The account balance is updated after rerating each event so that each subsequent event is rerated based on the most current balance.

Some rerated events may be associated with a product, discount, or resource balance whose validity period starts on first usage. If the event that triggered the validity period is not the actual first usage event, PCM_OP_SUBSCRIPTION_RERATE_REBILL backs out the validity period of the product, discount, or resource balance and resets it based on the event time of the actual first-usage event.

When override pricing is passed to PCM_OP_SUBSCRIPTION_RERATE_REBILL, it creates a /rerate_session/override_info object to capture the override pricing information used during rerating.

Flags Used for Rerating

The PIN_FLD_FLAGS field specifies whether to rerate events in order based on the event creation time or the event end time. The end time is the default. For more information, see "Specifying the Event Sequence for Rerating".

The PIN_FLD_RERATE_FLAGS field can take two flags:

A flag that specifies back-out-only rerating. When this flag is set, the balance impacts of the events selected for rerating are backed out, but the events are not rerated.
A flag that specifies selective rerating of specific events. When this flag is set, the account selection criteria is also applied to the account's events and only events that meet the selection criteria are rerated.
Important:
- Do not use selective rerating if your rating scheme includes credit limits or resource-based tiers. These schemes require that all events related to an account are rerated to assure accurate rerating.
- Do not use selective rerating if deferred taxation is used for taxing events during rerating.
- Use caution when specifying selective rerating. Account balances can be impacted by different types of events and the order of the balance impacts is important to accurately apply discounts and consume resources. It is typically safer to rerate all of an account's events.
For more information, see "Specifying Events for Rerating".

The selection criteria for selective rerating and back-out-only rerating must be set in the PIN_FLD_ARGS array field in the input flist.

Return Values for Rerating

If the CALC_ONLY flag is set or if PCM_OP_FLAG_READ_RESULT is passed in the input flist, PCM_OP_SUBSCRIPTION_RERATE_REBILL returns all rerating details in the PIN_FLD_RESULTS array without modifying the account balances. Otherwise, the account balances are updated and only the POID of the rerated event is returned.

If PCM_OP_SUBSCRIPTION_RERATE_REBILL attempts to rerate an event that is already being rerated, an error is returned.

How BRM Creates Rerate Jobs

A rerate job is a pair of /job/rerate and /job/rerate objects in the BRM database. There is a one-to-one relationship between /job/rerate objects and /job_batch/rerate objects and both are created in the same transaction when one or more accounts are selected for rerating.

You create rerate jobs manually by using the "pin_rerate" utility. BRM creates rerate jobs automatically by using the PCM_OP_RERATE_INSERT_RERATE_REQUEST opcode. This opcode is called to create rerate jobs by the following:

The pin_rerate utility.
BRM's automatic-rerating mechanism.

BRM supports the automatic rerating of certain types of events. For more information, see "About Automatic Rerating".
Your trigger-dependent rerating configuration.

BRM enables you to rerate events automatically based on your own business requirements. For more information, see "About Trigger-Dependent Rerating".
Out-of-order rerating for pipeline rated events.

BRM supports the automatic rerating of events that are rated out of order in the batch rating pipeline. For more information, see "About Automatic Rerating of Out-of-Order Events".

PCM_OP_RERATE_INSERT_RERATE_REQUEST receives the following information in the input flist:

The POIDs of the accounts to be rerated (required).
The time from which events must be rerated for the accounts (required).
Accounts related to the accounts to be rerated (for example, an account that used the account's service before a line transfer) along with the start time for each account.

Note:
If more than one account is included in the rerate job, the same rerate start time, selection criteria, and price overrides apply to all the accounts.
Your rerate reason for trigger-dependent rerating (the default rerate reason passed in for BRM automatic rerating scenarios is 0).
Your selection criteria for trigger-dependent rerating to identify the events that must be rerated for the accounts.
A list of products, discounts, or deals to override the subscriber's existing pricing objects during rerating.

To create rerate jobs, PCM_OP_RERATE_INSERT_RERATE_REQUEST does the following:

Checks for duplicate rerate job requests.

For more information, see "How BRM Handles Duplicate Rerate Jobs".
Calls PCM_OP_RERATE_CREATE_JOB to create the /job/rerate and /job_bacth/rerate objects.

How BRM Handles Duplicate Rerate Jobs

The PCM_OP_RERATE_INSERT_RERATE_REQUEST opcode checks for existing jobs when a new rerate request is made; this opcode compares the data for each top-level account in the rerate request to the data in the existing jobs. To avoid duplicate rerate jobs, accounts are either eliminated from or updated in the rerate request or the existing jobs.

After the duplicate detection process is complete for each top-level account in the rerate request, PCM_OP_RERATE_INSERT_RERATE_REQUEST calls PCM_OP_RERATE_CREATE_JOB to create a rerate job with the resulting contents of the rerate request. PCM_OP_RERATE_CREATE_JOB then performs checks on the sub-accounts in the rerate request to check for duplicate jobs for line transfers before creating the rerate job.

Detecting Duplicate Rerate Requests

When the rerate reason code and rerate selection criteria for a rerate request match those of one or more rerate jobs, the request is considered a possible duplicate. When the rerate reason code and rerate selection criteria do not match, the rerate request is not a duplicate, and a new rerate job is created.

Avoiding Duplication of Rerate Jobs

To avoid duplicate rerate jobs for an account, PCM_OP_RERATE_INSERT_RERATE_REQUEST compares the following values for duplicate rerate job requests:

The rerate start times. BRM always uses the earlier start time to ensure that all events are rated.
The price overrides (if any). BRM uses the latest price overrides for an account because it is assumed to be the most updated.

When price overrides match

When the price overrides match, PCM_OP_RERATE_INSERT_RERATE_REQUEST does the following for each top-level account:

If the rerate start time of the rerate request is later than or equal to the start time of the existing job, does the following:
- If there is only this account in the rerate request, deletes the request. No rerate job is needed.
- If there are many accounts in the new request, removes only that account from the new request.
If the rerate start time of the rerate request is earlier than the start time of the existing job, does the following:
- If the existing job contains only this account, updates the existing job to use the earlier start time and removes the account from the rerate request.
- If the existing job contains other accounts, removes the account from the existing job, keeping the account in the rerate request.

When price overrides do not match

When the price overrides do not match, PCM_OP_RERATE_INSERT_RERATE_REQUEST does the following for each top-level account:

If the rerate start time of the rerate request is the same or earlier than the start time of the existing job, does the following:
- If there is only one account in the existing job, deletes the job.
- If there are many accounts in the existing job, keeps the account in the rerate request so the new rerate job start time and price overrides are used. Removes the account from the existing job.
If the rerate start time of the rerate request is later than the start time of the existing job, does the following:
- If there is only one account in the existing job, deletes the job.
- If there are many accounts in the existing job, keeps the account in the rerate request so the new price overrides are used. Updates the rerate request start time to use the existing job's start time. Removes the account from the existing job.

Table 28-4 summarizes how PCM_OP_RERATE_INSERT_RERATE_REQUEST handles duplicate rerate job requests:

Table 28-4 Request Handling by PCM_OP_RERATE_INSERT_RERATE_REQUEST

If the Start Time of the New Request Is:	And the Price Overrides:	Perform This Action:
Equal to or later than that of the existing job	Match	If there is only this account in the rerate request, delete the request. No rerate job is needed. If there are many accounts in the rerate request, remove only that account from the rerate request.
Earlier than that of the existing job	Match	If there is only one account in the existing job: Update the existing job to use the earlier start time. Remove the account from the rerate request. If there are many accounts in the existing job: Keep the account in the rerate request. Remove the account from the existing job.
Later than that of the existing job	Do not match	If there is only one account in the existing job, delete the job. If there are many accounts in the existing job: Keep the account in the rerate request so the new price overrides are used. Update the rerate request job start time to use the existing job's start time. Remove the account from the existing job.
Equal to or earlier than that of the existing job	Do not match	If there is only one account in the existing job, delete the existing job. If there are many accounts in the existing job: Keep the account in the rerate request so the rerate request start time and price overrides are used. Remove the account from the existing job.

For more information on how BRM creates rerate jobs, see "How BRM Creates Rerate Jobs".

Tracking Rate Changes for Rerating

To track rate changes for rerating, use the PCM_OP_SUBSCRIPTION_PREP_RATE_CHANGE opcode.

This opcode creates the /rate_change object, which stores details about the products affected by a rate change, including the rate tiers and rate plans for the product.

When you change a cycle fee by adding a new rate tier in Pricing Center, BRM event notification triggers this opcode. This opcode reads the products associated with the event and creates a /rate_change object, which is used by the pin_rate_change utility to create rerating requests.

PCM_OP_SUBSCRIPTION_PREP_RATE_CHANGE returns the POID of the /rate_change object.

Rerating Cycle Fees

To rerate cycle fees, use the PCM_OP_SUBSCRIPTION_RATE_CHANGE opcode. This opcode uses the event notification mechanism to trigger the creation of rerating requests when there is a cycle-forward or cycle-forward-arrears event rate change in the middle of the current cycle.

Note:

Rerating is not triggered for cycle-arrears rate changes or rate changes in future cycles.

When you run the pin_rate_change utility after a rate change, the utility calls this opcode and provides details about the accounts and products affected by the rate change.

This opcode returns a notification event of type /event/notification/rate_change for each account picked up by the pin_rate_change utility. Depending on how automatic rerating is configured, the notification event triggers the creation of rerating requests.