Setting Up Revenue Assurance Manager for Pipeline Batch Rating

41 Setting Up Revenue Assurance Manager for Pipeline Batch Rating

This chapter describes how to configure Oracle Communications Billing and Revenue Management (BRM) Revenue Assurance Manager to collect revenue assurance data from pipeline batch rating.

About Revenue Assurance

You use Revenue Assurance Manager to verify the end-to-end completeness, accuracy, and integrity of BRM billing and pipeline batch rating results. You can analyze revenue assurance data to find revenue leakage in your system.

You obtain revenue assurance data by auditing the results of these processes:

Billing: Revenue Assurance Manager provides statistics such as the number of accounts billed or invoiced, the total revenue, and the number of records that were successfully billed or failed to be billed.
Pipeline batch rating: Revenue Assurance Manager provides statistics such as total duration and charges, retail and wholesale amounts, and total discount amounts.

About Collecting Revenue Assurance Data from Pipeline Batch Rating

You can collect revenue assurance data to analyze the effect of pipeline rating on Event Data Records (EDRs). You configure Revenue Assurance Manager to collect statistics on EDRs at various points in your pipelines, and then compare those statistics to see how a batch of EDRs changes as it is processed.

The statistics collected can include:

The number of EDRs in the batch
Retail charged amount
Event wholesale value
Discounts applied
Total time usage
Amount of data transferred
When a call started
When a call ended

Revenue assurance data is collected and aggregated at control points that you configure in pipelines. You establish control points by adding the FCT_AggreGate module at appropriate pipeline locations. You determine the data to be collected by specifying aggregation scenarios used by the module.

You can configure related control points into flows that enable you to examine data for a batch sequentially. You can also link pairs of control points to see original and current values.

FCT_AggreGate outputs aggregated data into flat files. You configure the Batch Controller to send these flat files to the Universal Event (UE) Loader as they are created. UE Loader parses the flat files and then calls opcodes to load the information into the database as /process_audit/batchstat objects.

Collecting revenue assurance data from pipeline batch rating involves these tasks:

Configuring event notification to capture data on written-off EDRs and set up revenue assurance alerts.

See "About Using Event Notification to Generate Revenue Assurance Data" for more information.
Configuring control points in your pipelines to determine where revenue assurance data is captured.

See "About Control Points" for more information.
Associating an aggregation scenario with each of your control points to determine how revenue assurance data is organized. Revenue Assurance Manager includes preconfigured aggregation scenarios that group revenue assurance statistics by using different fields.

See "About Aggregation Scenarios" for more information.
Linking pairs of control points related to rating, rerating, and written-off EDRs. Revenue Assurance Center uses these linked pairs to establish the original and current values for a set of EDRs.

See "About Linking Pairs of Rating, Rerating, and Written-Off Control Points" for more information.
Defining flows, which are ordered lists of control points that Revenue Assurance Center uses to display revenue assurance data. Flows allow you to track revenue assurance data for EDR batches at various stages during pipeline processing.
Configuring Universal Event (UE) Loader to load revenue assurance data into the database.
Configuring alerts to be sent when revenue assurance data passes a threshold that you set.

About Using Event Notification to Generate Revenue Assurance Data

Revenue Assurance Manager uses event notification to collect data on written-off EDRs and set up revenue assurance alerts.

The following events are generated specifically to facilitate the revenue assurance event notification process:

/event/notification/suspense/writeoff: When suspended EDRs are written off, Suspense Manager generates this event. By default, when this event occurs, the PCM_OP_PROCESS_AUDIT_CREATE_WRITEOFF_SUMMARY opcode is called.
/event/notification/ra_threshold: When specified conditions for producing revenue leakage alerts occur, the load_pin_config_ra_thresholds utility generates this event. By default, when this event occurs, the PCM_OP_PROCESS_AUDIT_POL_ALERT policy opcode is called.

About Control Points

You establish control points in batch pipelines to determine where Revenue Assurance Manager collects data. You can configure control points in locations that enable you to compare data from different stages in the rating processes.

You define a control point by adding the FCT_AggreGate module to the pipeline in the desired location and specifying the control point name in the module registry. Each control point must have a unique name that describes its purpose. For example, in a rating pipeline, you could have control points named Rating and CP_After_Rating.

Each control point is associated with an aggregation scenario that specifies the data to be collected and how it should be organized.

You add related control points to flows. In Revenue Assurance Center, you can view data from all the control points in a flow. This enables you to follow the progress of EDR batches of EDRs through the pipeline. See "About Flows" for more information.

About Aggregation Scenarios

Each control point requires an aggregation scenario to specify the data that the control point collects and how the data will be organized.

An aggregation scenario specifies:

The EDR fields to collect data from. For example, a scenario can collect information from the discount amount or duration fields.
Aggregation functions to apply to the data. For example, you can add data together or average it.
Fields by which to group the data collected. For example, you can group data by service type. In this case, the data for each batch is grouped by the type of service, such as TEL, SMS, or GPRS.

You can also collect revenue assurance data on more than one grouping field. For example, in the BatchStat_SvcType_Status scenario, the grouping fields are Service Type and EDR Status. The revenue assurance data collected is the EDR status such as Duplicate, Rejected, or Successful for each service type.

You specify the scenario to use when you define a control point in the FCT_AggreGate module registry. Scenarios can be used by any number of control points.

Revenue Assurance Manager provides a number of preconfigured scenarios. These scenarios are suitable for use in a production system. You can also create new scenarios if necessary.

About Linking Pairs of Rating, Rerating, and Written-Off Control Points

Certain types of control points must be linked to establish original and current values displayed in Revenue Assurance Center. You should link these types of control points:

A rating control point to a rerating control point.
A rating control point to a writeoff control point.
A rerating control point to a writeoff control point.

When pairs of control points are linked, Revenue Assurance Center shows the linked control points in the same area. Values for the first control point are marked as original values, and the last control point as current values.

About Flows

A flow is an ordered set of related control points that you group together for convenient searching and viewing in Revenue Assurance Center. You can add any number of control points to a flow, from any pipelines that are relevant.

You use Revenue Assurance Center to display data for flows. Each control point appears in its own area. In this example, you can see two control points (P1_END and CP_AfterRating) from Flow12. The second control point shows the effect that rating had on a small batch of EDRs.

About Using UE Loader to Load Revenue Assurance Data

In order to view batch pipeline revenue assurance data, you must first load that data into /process_audit objects in the BRM database. You use Universal Event (UE) Loader to load the data.

The UE Loader loads revenue assurance data into the following /process_audit objects:

/process_audit/pipeline objects store information about processed EDRs.

/process_audit/batchstat objects store information about the revenue assurance data collected for specific scenarios.

You can configure the BRM Batch Controller to probe automatically for revenue assurance data files and then call UE Loader to load them into the database. You can also decide to load the data periodically by using cron or a similar program.

About the Revenue Assurance Data Collected in Rated Event Loader

Revenue Assurance Manager collects data from Rated Event (RE) Loader. BRM uses RE Loader to load events that have been rated or rerated with pipeline batch rating.

The revenue assurance data collected from RE Loader include:

Total revenue generated by the batch.
Total number of EDRs loaded.

You can view the RE Loader data in Revenue Assurance Center or in Revenue Assurance reports.

When the rated EDRs are loaded in RE Loader, either all the EDRs are loaded, or they all fail. There is no possibility of some records getting loaded and some records failing. In Revenue Assurance Manager, the data collected for RE Loader is not grouped by status or any other fields.

You must load the CollectProcessAuditForIREL.sql file to enable the collection of revenue assurance data from RE Loader.

About Collecting Revenue Assurance Data on Written-Off EDRs

You can use Revenue Assurance Manager to view statistics about the number of EDRs that have been written off.

When an EDR is written off through Suspense Manager, an /event/notification/suspense/writeoff event is generated. You configure event notification so that Revenue Assurance Manager collects data every time such an event occurs. The data collected from a written-off EDR includes the original batch ID and the number of EDRs that were written off in that batch of EDRs.

Configuring Revenue Assurance Manager

To set up Revenue Assurance Manager for pipeline batch rating, you need to complete the following tasks:

Configure event notification to notify Revenue Assurance Manager when events occur.

See "Configuring Event Notification" for more information.
Choose scenarios that determine how the revenue assurance data is grouped.

See "Selecting Aggregation Scenarios" for more information.
Identify control points for pipeline data collection.

See "Identifying Control Point Locations for Revenue Assurance Data" for more information.
Configure FCT_Aggregate to use your aggregation scenarios and control points.

See "Configuring the FCT_AggreGate Module to Collect Revenue Assurance Data" for more information.
Configure SimpleSample files to map the batchIDs of the EDRs.

See "Configuring SimpleSample Files" for more information.
Add related sets of control points to flows.

See "Adding Control Points to Flows" for more information.
Link control points for rating, rerating, and written-off EDRs.

See "Linking Rating, Rerating, and Write-Off Control Points" for more information.
Configure Universal Event (UE) Loader to load revenue assurance data into the database.

See "Setting Up UE Loader to Load Revenue Assurance Data into the Database" for more information.
Configure Batch Controller to call UE Loader.

See "Setting Up Batch Controller to Call UE Loader" for more information.

Configuring Event Notification

Revenue Assurance Manager uses event notification to collect data on written-off EDRs and set up revenue assurance alerts.

Before you can use Revenue Assurance Manager, you must configure the event notification feature as follows:

If your system has multiple configuration files for event notification, merge them.
Ensure that the merged file includes the entire event notification list in the BRM_home/sys/data/config/pin_notify_ra file.
(Optional) If necessary to accommodate your business needs, add, modify, or delete entries in your final event notification list.
(Optional) If necessary to accommodate your business needs, create custom opcodes for event notification to trigger.
Load your final event notification list into the BRM database.

Note:

In addition, your business needs may require that you use event notification to call opcodes when other objects are created in the BRM database.

Selecting Aggregation Scenarios

Aggregation scenarios determine what revenue assurance data is collected from pipelines and how that data is grouped.

You may be able to use one or more of the preconfigured scenarios supplied with Revenue Assurance Manager. Each scenario groups data differently.

If none of the preconfigured aggregation scenarios satisfies your business requirements, you can create your own.

You must associate aggregation scenarios with control points in the registry of the FCT_Aggregate module.

Loading Scenarios into the Pipeline Manager Database

You must load aggregation scenarios into the Pipeline Manager database before you can use them. Scenarios that you create are loaded into the database by Pricing Center at the time of creation.

To load scenarios into an Oracle Pipeline Manager database, run the following command against the Pipeline Manager database from the pipeline_home/database/oracle/scripts directory:

% sqlplus user@databaseAlias
Enter password: password

SQL> RevenueAssurance_Scenarios.sql

where:

pipeline_home is the directory in which you installed Pipeline Manager.
user is the Pipeline Manager user ID.
password is the Pipeline Manager user password.
database is the Pipeline Manager database alias.

Identifying Control Point Locations for Revenue Assurance Data

You configure control points in pipeline locations where you want to collect revenue assurance data. You associate an aggregation scenario with the control point to determine the data that is collected.

The exact locations where you place control points depend on the data you are collecting. It is often useful to insert control points before and after a critical point in the pipeline. For example, you can insert a control point before and after rating so that you can analyze the impact on EDRs.

You place a control point in a pipeline by inserting an instance of the FCT_AggreGate module at the desired point in the pipeline. You specify the control point ID and aggregation scenario in the module registry. See "Configuring the FCT_AggreGate Module to Collect Revenue Assurance Data" for more information. Each control point ID must be unique system-wide.

Configuring the FCT_AggreGate Module to Collect Revenue Assurance Data

You insert the FCT_AggreGate module at locations that you identify to collect revenue assurance data. You define a control point and associated aggregation scenario in the registry of each FCT_AggreGate module that you insert.

Note:

If an aggregation scenario requires one or more iScripts, you must specify them in the Function Pool section of the pipeline registry. See "Using iScripts to Derive Grouping Fields" for more information.

You also configure other options in the module registry, including details about control and result files. These are standard options unrelated to revenue assurance.

To configure an FCT_AggreGate module for revenue assurance:

Add the FCT_AggreGate module to the pipeline registry at the desired location.
Configure the module for revenue assurance data:
- In the Scenarios section of the registry, create a block for the scenario by entering the scenario name. For example, enter RA_03 to use the Service Type scenario.
- For the ControlPointId parameter, enter an ID for the control point you are defining. The control point ID must be unique and have maximum of 30 characters. For example, if you use the Service Type scenario, you might define the CP_PostRatingBatchStat_Svctype control point.
- For the TableName registry entry, enter the name of the scenario that you defined earlier.
  
  Note:
  
  The value of the TableName entry is used as the name of the output files for the scenario. Using the scenario name for this entry makes it easier to associate files with the scenarios from which they were created.
- Add the registry parameter IncludeProcessingTimestamps and set it to TRUE.
- Enter values for the standard FCT_AggreGate parameters, such as Threshold, TempDir, DoneDir, CtlDir.
- Enter a semicolon (;) for the FieldDelimiter.
- Add the parameters IncludeErrorEDRs and IncludeInvalidDetailEDRs and set them to TRUE.
  
  Note:
  
  When configuring scenarios that do not use grouping based on the field EDRStatus, do not specify the IncludeErrorEDRs and IncludeInvalidDetailEDRs parameters.

The following example shows FCT_AggreGate configured for control point CP_PostRatingBatchStat_Svctype using the Service Type aggregation scenario (RA_03):

# Aggregation
--------------------------------------------------
# AggreGate
{
 ModuleName = FCT_AggreGate
 Module
 {
  Active                   = TRUE
  ScenarioReaderDataModule = ifw.DataPool.ScenarioReader
  Scenarios
  {
   RA_03
   {
    TableName       = RA_03
    Threshold       = 10000
    TempDir         = ./data/aggregate
    DoneDir         = ./data/aggregate
    CtlDir          = ./data/aggregate
    FieldDelimiter  = ;
    ControlPointId  = CP_PostRatingBatchStat_Svctype
    IncludeErrorEDRs            = TRUE
    IncludeInvalidDetailEDRs    = TRUE
    IncludeProcessingTimestamps = TRUE
  
  ResultFile
  {
   IncludeFormat  = FALSE
   TempSuffix     = .tmp
   DoneSuffix     = .dat
   WriteEmptyFile = FALSE
  }
  ControlFile
  {
   IncludeFormat  = FALSE
   Suffix         = .ctl
   DataFilePath   = TRUE
  }
 }
}

Using iScripts to Derive Grouping Fields

Review the description of the scenario you are using to see if it requires any iScripts. Scenarios use iScripts to derive grouping fields such as EDR Status, Revenue Stream, and Output Stream.

If required, you need to specify the iScripts in the FunctionPool section of the registry file, before the FCT_AggreGate module.

ISC_SetEDRStatus
ISC_SetOutputStream
ISC_SetRevenueStream
ISC_SetRevenueFigures

The following iScript must be placed at the beginning of the pipeline to ensure that the batch ID is inserted before any further processing of the mediation batches.

ISC_SetAndValidateBatchInfo

Configuring SimpleSample Files

Configure the SimpleSample files to map the batchIDs of the EDRs. This is a mandatory step for Revenue Assurance Manager to work correctly.

You can find the SimpleSample files at: pipeline_home/ifw/formatDesc/Formats/Sample.

To configure the SimpleSample files:

Open the SIMPLESAMPLE_v1.dsc file using a text editor such as Notepad.

Find the following line:

SERVICE                     AscString();

Add the following lines before the aforementioned line:

BATCH_ID                    AscString();
ORIGINAL_BATCH_ID           AscString();
SUSPENDED_FROM_BATCH_ID     AscString();
EVENT_ID                    AscString();

Save and close the file.
Open the SIMPLESAMPLE_v1_InMap.dsc file using a text editor such as Notepad.

Find the following line:

"020"                     -> DETAIL.RECORD_TYPE;

Add the following lines before the aforementioned line:

BATCH_ID                 -> DETAIL.BATCH_ID;
ORIGINAL_BATCH_ID        -> DETAIL.ORIGINAL_BATCH_ID;
SUSPENDED_FROM_BATCH_ID   -> DETAIL.ASS_SUSPENSEEXT.SUSPENDED_FROM_BATCH_ID;
EVENT_ID                  -> DETAIL.EVENT_ID;

Save and close the file.
Open the SIMPLESAMPLE_v1_InGrammar.dsc file using a text editor such as Notepad.

Find the following line:

edrInputMap( "SIMPLESAMPLE_V1.DETAIL.STD_MAPPING" );

Add the following lines before the aforementioned line:
```
edrAddDatablock( DETAIL.ASS_SUSPENSE_EXT );
```
Save and close the file.

Adding Control Points to Flows

Flows are ordered sets of related control points. You group control points into flows so that you can search for and view them conveniently in Revenue Assurance Center. When you view a flow in Revenue Assurance Center, its control points are displayed in the order in which they were defined.

You define flows in the pin_config_ra_flows file and load the flows into the database by using the load_pin_config_ra_flows utility. Flows are stored as /config/ra_flows objects.

The load_pin_config_ra_flows utility overwrites existing flows. You must load a complete set of flows each time you run the utility.

To add control points into flows and load them into the database:

Open the BRM_home/sys/data/config/pin_config_ra_flows file in a text editor.

This file includes instructions about the syntax to use to add control points to flows.
Save and close the file.
Use the following command to load your control points into the database:
```
% load_pin_config_ra_flows pin_config_ra_flows
```
If you do not run the utility from the directory in which the file is located, include the complete path to the file; for example:
```
% load_pin_config_ra_flows BRM_home/sys/data/config/pin_config_ra_flows
```
Tip:

If you copy the pin_config_ra_flows file to the directory from which you run the load_pin_config_ra_flows utility, you do not have to specify the path or file name. The file must be named load_pin_config_ra_flows.

To verify that the flows were loaded, you can display the /config/ra_flows object by using the Object Browser, or use the robj command with the testnap utility.

Linking Rating, Rerating, and Write-Off Control Points

For Revenue Assurance Center to recognize original and current values for certain types of control points, you must link them and add the links to the BRM database. The control points that require linking include:

Rating to rerating.
Rerating to written-off.
Rating to written-off.

To link control points, you define the links in the pin_config_controlpoint_link file and then load them into the BRM database by using the load_pin_config_controlpoint_link utility. Links are stored in the /config/link_controlpoint object in the BRM database. The PCM_OP_PROCESS_AUDIT_CREATE_AND_LINK opcode links /process_audit/batchstat objects based on the data in the /config/link_controlpoint object.

Caution:

The load_pin_config_controlpoint_link utility overwrites existing links. You must load a complete set of links each time you run the utility.

Note:

The load_pin_config_controlpoint_link utility needs a configuration (pin.conf) file in the directory from which you run the utility.

To configure your control points into flows and load them into the database:

Open the BRM_home/sys/data/config/pin_config_controlpoint_link file in a text editor. This file includes instructions on how to add control points into flows.
Save and close the file.
Use the following command to load your control points into the database:
```
% load_pin_config_controlpoint_link pin_config_controlpoint_link
```
If you do not run the utility from the directory in which the file is located, include the complete path to the file; for example:
```
% load_pin_config_controlpoint_link BRM_home/sys/data/config/pin_config_controlpoint_link
```
Tip:

If you copy the pin_config_controlpoint_link file to the directory from which you run the load_pin_config_controlpoint_link utility, you do not have to specify the path or file name. The file must be named pin_config_controlpoint_link.

To verify that the control point links were loaded, you can display the /config/controlpoint_link object by using Object Browser, or use the robj command with the testnap utility.

Setting Up UE Loader to Load Revenue Assurance Data into the Database

UE Loader takes the revenue assurance data from the FCT_AggreGate output files and loads it into the BRM database. The following sections explain how to configure UE Loader.

Setting Up UE Loader Templates

UE Loader requires that each aggregation scenario have a separate UE Loader event input template in XML format to map the data generated by FCT_AggreGate to the input flist for the opcodes that data. Revenue Assurance Manager provides XML templates for each of the preconfigured scenarios.

Setting Up Batch Controller to Call UE Loader

Batch Controller runs programs such as UE Loader either when a specific event occurs or automatically at timed intervals.

Most implementations use the occurrence-driven execution feature of Batch Controller to run UE Loader whenever FCT_AggreGate creates output files with revenue assurance data.

Note:

If you set up Batch Controller to load scenario data files periodically rather than by occurrence, make sure the files are loaded frequently. Revenue Assurance Center uses the time when records were loaded into the database when it searches for data in time range. For the revenue assurance data to be meaningful, it should be loaded into the database soon after creation.

Setting Up Revenue Assurance Manager to Collect Data on Written-Off EDRs

For written-off EDRs, Revenue Assurance Manager collects the original batch ID and the number of EDRs that were written off in the batch.

To collect revenue assurance data on written-off EDRs, do the following:

Enable event notification for Revenue Assurance Manager.
Set a parameter in the Connection Manager pin.conf file to configure the control point ID to collect the revenue assurance data on written-off EDRs. You can change this control point ID.

About Aggregation Scenarios

Aggregation scenarios specify the data that is collected by Revenue Assurance Manager from pipeline batch rating. You must specify an aggregation scenario at every control point you set up in the pipeline.

Revenue Assurance Manager includes scenarios that are suitable for use in a production system. These scenarios group revenue assurance data in different ways. See "Data Fields Collected by All Scenarios" for a list of the fields from which the scenarios collect data. See "Fields Used to Group Scenario Data" for a list of the fields by which the scenarios can group data.

For example, the EDR statistics for scenario RA_03 are grouped by service type, such as TEL, SMS, or GPRS. Data, such as event count, retail charged amount, and so on, is aggregated for each service type.

Most of the scenarios group by combinations of grouping fields. For example, scenario RA_04 groups fields by both service type (TEL, SMS, and so on) and EDR status (duplicate, rejected, written-off or successful). Data is aggregated separately for each combination; duplicate EDRs for the SMS service, for example.

If the preconfigured scenarios do not meet your business needs, you can also create your own.

Note:

Custom scenarios require custom UEL templates and cannot be used with Revenue Assurance Center.

Before you can use the preconfigured scenarios, you must load them into the pipeline database.

Data Fields Collected by All Scenarios

All of the preconfigured aggregation scenarios collect statistics from the EDR fields listed in Table 41-1:

Table 41-1 All Scenarios Data Fields

Field	Description
Event count	Number of EDRs.
Retail charged amount	Retail charged amount collected.
Event wholesale value	Total wholesale amount charged for the EDR, if appropriate.
Discount amount	Discount amount applied.
Duration	Total usage time, in seconds, if appropriate (for example, for a voice call).
Volume sent	Data transferred in bytes, if appropriate (for example, for a GPRS event).
Volume received	Data received in bytes, if appropriate (for example, for a GPRS event).
Earliest call made	The earliest call start timestamp.
Latest call made	The latest call start timestamp.

Fields Used to Group Scenario Data

The EDR data fields in Table 41-2 are available to use for grouping data.

Table 41-2 Grouping Data Fields

Grouping Field	Description
Batch ID	Batch ID of the batch being processed.
Original batch ID	Mediation batch ID of the rerating or recycling EDR batches.
Suspended from batch ID	The batch ID from which the EDR was suspended.
Service type	Type of service, such as TEL, SMS, or GPRS.
Revenue stream	Retail, Wholesale, or Roaming.
Output stream	The output stream of the EDR. This is based on the service type; for example, if the service type is SMS, the output stream is SMS.
EDR status	Success, Suspense, Duplicate, Discard, Rejected, or Skipped.
Suspense code	Suspense reason code assigned to the EDR.

Preconfigured Aggregation Scenario Details

Table 41-3 provides information about the Revenue Assurance Manager preconfigured aggregation scenarios.

Table 41-3 RA Manager Preconfigured Aggregation Scenarios

Scenario/ File Name	Collects Data for an EDR Batch Based On	Grouping Fields (Listed in the Grouping Order)	Storable Class	Installation Point	iScripts Required
RA_01, Batchstatat_simple	An EDR batch.	Batch ID, Original batch ID, Suspended from batch ID	/process_audit/batchstat/simple	Anywhere in a pipeline	None
RA_02, BatchStat_status	EDR Status.	Batch ID, Original batch ID, Suspended from batch ID, EDR status	/process_audit/batchstat/status	Anywhere in a pipeline	ISC_SetEDRStatus
RA_03, BatchStat_SvcType	Service type.	Batch ID, Original batch ID, Suspended from batch ID, Service type	/process_audit/batchstat/svctype	After FCT_ServiceCodeMap	None
RA_04, BatchStat_SvcTypeStatus	Service type and EDR status. Using this scenario, you can find the number of records that are duplicate, rejected, or successful for each service type.	Batch ID, Original batch ID, Suspended from batch ID, Service type, EDR status	/process_audit/batchstat/svctype_status	After FCT_ServicecodeMap	ISC_SetEDRStatus
RA_05, BatchStat_RevenueStream	Revenue stream. The revenue streams are: Retail, Wholesale, and Roaming.	Batch ID, Original batch ID, Suspended from batch ID, Revenue stream	/process_audit/batchstat/revstream	After Post Rating	ISC_SetRevenueStream
RA_06, BatchStat_Revenue Stream_Status	Revenue stream and EDR status.	Batch ID, Original batch ID, Suspended from batch ID, Revenue stream, EDR status	/process_audit/batchstat/revstream_status	After Post Rating	ISC_SetRevenueStream, ISC_SetEDRStatus
RA_07, BatchStat_RevenueStream_SvcType	Revenue stream and service type.	Batch ID, Original batch ID, Suspended from batch ID, Revenue stream, Service type	/process_audit/batchstat/revstream_svctype	After Post Rating	ISC_SetRevenueStream
RA_08, BatchStat_RevenueStream_ServiceType_Status	Revenue stream, service type, and EDR status.	Batch ID, Original batch ID, Suspended from batch ID, Revenue stream, Service type, EDR status	/process_audit/batchstat/revstream_svctype_status	After Post Rating	ISC_SetRevenueStream, ISC_SetEDRStatus
RA_09, BatchStat_SvcType_RevenueStream	Service type and the revenue stream.	Batch ID, Original batch ID, Suspended from batch ID, Revenue stream, Service type	/process_audit/batchstat/revstream_status_svctype	After Post Rating	ISC_SetRevenueStream
RA_10, BatchStat_ServiceType_RevenueStream_Status	Service type, revenue stream, and EDR status.	Batch ID, Original batch ID, Suspended from batch ID, Revenue stream, Service type, EDR status	/process_audit/batchstat/svctype_revstream_status	After Post Rating	ISC_SetRevenueStream, ISC_SetEDRStatus
RA_11, BatchStat_Outputstream	Output stream.	Batch ID, Original batch ID, Suspended from batch ID, Output stream	/process_audit/batchstat/outputstream	Just before output	ISC_SetOutputStream
RA_12, BatchStat_ServiceType_RevenueStream_Outputstream	Service type, revenue stream, and output stream.	Batch ID, Original batch ID, Suspended from batch ID, Output stream, Service type, Revenue stream	/process_audit/batchstat/svctype_revstream_outputstream	Just before output	ISC_SetRevenueStream and ISC_SetOutputStream
RA_13, BatchStat_Suspense	Suspense reason code.	Batch ID, Original batch ID, Suspended from batch ID, Suspense code	/process_audit/batchstat/suspense	After FCT_Suspense	None
RA_14, BatchStat_ServiceType_RevenueStream_Status_Outputstream	Service type, revenue stream, EDR status, and output stream.	Batch ID, Original batch ID, Suspended from batch ID, Service type, Revenue stream, EDR status, Output stream	/process_audit/batchstat/svctype_revstream_status_outputstream	Just before output	ISC_SetRevenueStream, ISC_SetOutputStream, and ISC_SetEDRStatus

Creating New Aggregation Scenarios for Revenue Assurance

Revenue Assurance Manager uses aggregation scenarios to group the data that it collects from the pipeline. If the aggregation scenarios provided with Revenue Assurance Manager do not meet you needs, you can create your own.

Note:

You cannot view data from custom scenarios in Revenue Assurance Center.

To create your own aggregation scenarios:

Create an aggregation scenario by using Pricing Center or PCC.
Create the appropriate /process_audit/batchstat subclasses.

Note:

The new subclasses created must contain an array field of type PIN_FLD_GROUP_DETAILS. The PIN_FLD_ORIGINAL_BATCHID field must also be created in the array.
Create the XML templates used by Universal Event (UE) Loader to load the aggregation data generated by the new scenario.
Modify the PCM_OP_PROCESS_AUDIT_POL_CREATE_AND_LINK policy opcode to check for duplication of records in the newly created /process_audit object.

Tracking EDRs by Using Batch IDs

In pipeline batch rating, each batch file received from the mediation system is assigned a batch ID, which is stored in every EDR derived from the file. Each EDR also receives a unique event ID.

Note:

The KeepExistingBatchIds registry entry in FCT_PreSuspense module controls the way batch IDs are set. For details, see "Setting the Default Batch ID Behavior".

During rerating and recycling, the EDR receives a new batch ID, but the original batch ID is retained in a different field. Retaining the original batch ID in the EDR makes it possible to determine the revenue impact of EDRs for each batch that is received from mediation, even if some EDRs are rerated or recycled.

Revenue Assurance Manager uses the following fields to track EDRs as they are processed by pipelines and as they are rerated or recycled:

DETAIL.BATCH_ID
DETAIL.ORIGINAL_BATCH_ID
DETAIL.ASS_SUSPENSE_EXT.SUSPENDED_FROM_BATCH_ID

For example, BRM receives a batch file with batch ID Mediation087. All EDRs for events in the file are assigned this batch ID. The batch rating pipeline processes EDRs from this batch loads their data into the BRM database.

Later, some of the EDRs from this batch and a second batch, Mediation099, are rerated. During rerating, the two sets of EDRs from different batches are given the new batch ID ReratingBatch007. When the individual EDRs are given the new batch ID, their original batch IDs are moved to the ORIGINAL_BATCH_ID field.

Table 41-4 contains selected data from an EDR in the batch after rating:

Table 41-4 Rating EDR Data

Event ID	Duration	Charge	Batch ID	Original Batch ID
189	180	3	Mediation087	Mediation087

Table 41-5 contains the data for the EDR after rerating:

Table 41-5 Rerating EDR Data

Event ID	Duration	Charge	Batch ID	Original Batch ID
189	180	5	ReratingBatch007	Mediation087

Keeping Track of Rejected EDRs by Using Batch IDs

When a batch file is processed, some of its EDRs may not be able to be rated because of missing data or another reason. These rejected EDRs can be processed by Suspense Manager and recycled back into the rating pipeline. EDRs that are being rerated can also be rejected and sent to recycling.

When Suspense Manager recycles the rerated EDRs back through the pipeline, they receive new batch IDs based on the recycling batch. Their original batch IDs remain to reflect the mediation batch they started in. The suspended-from batch ID field (DETAIL.ASS_SUSPENSE_EXT.SUSPENDED_FROM_BATCH_ID) stores the ID of the batch in which the EDR was rejected. This could be the original batch or a rerating batch.

For example, two batches (MED1 and MED2) are received from the mediation system and processed by the batch rating pipeline. Some EDRs from each of the two batches are rejected and then recycled as part of batch RCL1. In addition, some EDRs from the original two batches are rerated as part of batch RRT1. Some of the EDRs in that rerating batch are rejected and then recycled as part of batch RCL2.

Table 41-6 summarizes how the three different batch ID fields change as EDRs are rated, rerated, and recycled.

Table 41-6 Batch ID Changed Fields

Pipeline Process	Value for BATCH_ID	Value for ORIGINAL_BATCH_ID	Value for SUSPENDED_FROM_BATCH_ID
Rating Batch MED1	MED1	MED1	MED1*^Foot 1
Rating Batch MED2	MED2	MED2	MED2*^Foot 1
Recycle Batch RCL1 (containing suspended EDRs from MED1 and MED2)	RCL1	MED1/MED2	MED1/MED2
Rerating Batch RRT1 (containing EDRs from MED1 and MED2)	RRT1	MED1/MED2	RRT1*^Foot 1
Recycle Batch RCL2 (containing suspended EDRs from RRT1)	RCL2	MED1/MED2	RRT1

^Footnote 1

The value of the suspended-from batch ID is ignored in rating and rerating. Because it is left blank, it is assigned the value of batch ID.

By linking the control point in the original mediation pipeline to the control point in the recycle pipeline that processed the rerated EDRs, you can determine the revenue impact for each of the mediation batches and identify the revenue leakage in your system.

Setting the Default Batch ID Behavior

The KeepExistingBatchIds registry entry in FCT_PreSuspense module controls whether the values for batch IDs in EDR records are preserved as originally set by the input module.

A value of True preserves the batch ID in each detail record of the batch input file.
A value of False (the default) sets the batch ID of each record to the batch ID contained in the header record of the batch input file.