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 recycling :
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 |
MED11 |
Rating Batch MED2 |
MED2 |
MED2 |
MED21 |
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 |
RRT11 |
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.