Using Batch IDs in Revenue Assurance Manager

5 Using Batch IDs in Revenue Assurance Manager

This chapter describes how to use batch IDs in Oracle Communications Billing and Revenue Management (BRM) Revenue Assurance Manager.

Tracking Event Records by Batch IDs

Each batch file received from the mediation system is assigned a batch ID, which is stored in every record derived from the file. Each record also receives a unique event ID.

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

Revenue Assurance Manager uses the following fields to track event records as they are 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 event records for events in the file are assigned this batch ID. ECE processes event records from this batch and loads their data into the BRM database.

Later, some of the event records from this batch and a second batch, Mediation099, are recycled. During recycling, the two sets of event records from different batches are given the new batch ID RecyclingBatch007. When the individual event records are given the new batch ID, their original batch IDs are moved to the ORIGINAL_BATCH_ID field.

Table 5-1 contains selected data from a record in the batch after recycleing :

Table 5-1 Original Record Data

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

Table 5-2 contains the data for the record after recycling:

Table 5-2 Recycled Record Data

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

Keeping Track of Rejected Event Records by Batch IDs

When a batch file is processed, BRM might be unable to rate some of its event records because of missing data or other reasons. The rejected event records can be processed by Suspense Manager and recycled.

When Suspense Manager recycles the event records, 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 record was rejected.

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

Table 5-3 summarizes how the three different batch ID fields change as event records are recycled.

Table 5-3 Batch ID Changed Fields

Process	Value for BATCH_ID	Value for ORIGINAL_BATCH_ID	Value for SUSPENDED_FROM_BATCH_ID
Rating Batch MED1	MED1	MED1	MED1¹
Rating Batch MED2	MED2	MED2	MED2¹
Recycle Batch RCL1 (containing suspended event records from MED1 and MED2)	RCL1	MED1/MED2	MED1/MED2
Rerating Batch RRT1 (containing event records from MED1 and MED2)	RRT1	MED1/MED2	RRT1¹
Recycle Batch RCL2 (containing suspended event records from RRT1)	RCL2	MED1/MED2	RRT1

Note

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