Defining Collections Scenarios

7 Defining Collections Scenarios

In Oracle Communications Billing and Revenue Management (BRM), collections scenarios are an ordered list of actions that are taken against a bill unit that is in collections.

Topics in this document:

Defining Collections Scenarios

Defining Collections Scenarios

When you create a new scenario, you decide which collections profile it applies to. You can define multiple scenarios with different characteristics for the same profile. For example, you could set up one scenario for relatively small overdue balances and another for larger balances.

A single scenario cannot be used with multiple collections profiles. If you want to implement scenarios with the same functionality across several profiles, you can define multiple scenarios with the same characteristics but different names.

A scenario includes an ordered list of actions that are taken against the bill unit. When you define a scenario, you select from a list of actions that you have previously defined and then specify the following characteristics:

The order in which the actions should take place.
The number of days after entering collections that the action should be completed. For example, 5 days after entering collections.
Whether an action is optional or mandatory.

Note:

If you define a collections scenario that includes both a writeoff and a bill unit inactivation, the writeoff must come before the inactivation. When a bill unit is inactivated, an event with a credit balance is created to cancel the remaining service for the bill unit. The cycle fees are then prorated and the remaining credit is returned to the bill unit, in some cases as a separate item. If the bill unit has already been inactivated, the writeoff will fail because of the unallocated item. In this case, a customer service representative (CSR) must manually allocate the item so that it can be written off.

Loading Additional Parameters for Scenario Assignment

You load additional parameters for a collections scenario assignment by using the load_config utility. See "load_config" in BRM Developer's Guide for more information.

The utility takes an XML file as input and creates or updates the /config/collections/scenario_params object in the BRM database. Billing Care reads the /config/collections/scenario_params object and displays the parameters while defining the evaluation formula to associate with a collections scenario.

To load additional collections scenario parameters:

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

Edit the file, which includes examples and instructions. Table 7-1 describes the parameters in this file.

Table 7-1 Elements Used to Store Additional Scenario Parameters

Element	Description
PARAM_NAME	Name of the parameter.
STRING_ID	The string ID of the parameter name. This field is used for localization.
STR_VERSION	The version of the localized string within the domain. This field is used for localization.
TYPE	The type of value that the parameter can be assigned, from one of the following types: 1: STR (alphanumeric) 2: INT (integer) 3: ENUM (indicating that the parameter is one of an ordered list of possible values. An array of values must be provided for this selection.) 4: DECIMAL 5: TSTAMP (timestamp) For example, to provide a set of possible values, you set the <TYPE> element to 3, and enter an array of values for this parameter in the <VALUES> element
CLASS_NAME	The storable class object associated with the parameter.
FIELD_NAME	The field inside the storable class referenced in the <CLASS_NAME> element. To enter the field name of a field present under an array or a substruct, use the format <FIELD_NAME>array.field</FIELD_NAME >, which includes the parent field of the attribute separated by periods (.). For example: <FIELD_NAME>PIN_FLD_COLLECTIONS_PARAMS.PIN_FLD_CREDIT_PROFILE</FIELD_NAME >.
VALUES	An array list of values that the parameter can assume. The <VALUES> array list is present only if the selection for the <TYPE> element is 3.

For example, the following entry defines a new parameter called Payment Method:

<PARAMS elem="0">
     <PARAM_NAME>Payment Method</PARAM_NAME>
     <TYPE>3</TYPE>
     <CLASS_NAME>/billinfo</CLASS_NAME>
     <FIELD_NAME>pay_type</FIELD_NAME>
     <VALUES elem="0">
                <NAME>CC</NAME>
                <VALUE>10003</VALUE>
     </VALUES>
     <VALUES elem="1">
                <NAME>DD</NAME>
                <VALUE>10005</VALUE>
     </VALUES>
     <VALUES elem="2">
                <NAME>CASH</NAME>
                <VALUE>10011</VALUE>
     </VALUES>
     <VALUES elem="3">
                <NAME>CHECK</NAME>
                <VALUE>10012</VALUE>
     </VALUES>
</PARAMS>

In this example:

The name of the parameter is Payment Method.
The type of value is 3 (which is ENUM, and so an array of values follows).
The storable class is /billinfo.
The field inside the storable class object is pay_type.
The Values array lists the four possible payment methods: CC, DD, Cash, and Check.

For example, the following entry defines a parameter called Credit Profile:

<PARAMS elem="3">
     <PARAM_NAME>Credit Profile</PARAM_NAME>
     <TYPE>2</TYPE>
     <CLASS_NAME>/profile/collections_params</CLASS_NAME>
     <FIELD_NAME>PIN_FLD_COLLECTIONS_PARAMS.PIN_FLD_CREDIT_PROFILE</FIELD_NAME>
</PARAMS>

In this example:

The name of the parameter is Credit Profile.
The type of value is 2 (which is INT).
The storable class is /profile/collections_params.
The field including the path to the storable class object is PIN_FLD_COLLECTIONS_PARAMS.PIN_FLD_CREDIT_PROFILE.

By default, the config_collections_scenario_params.xml file contains sample data for the following parameters:

Payment Method (Credit Card, Direct Debit, cash, check) from the /billinfo storable class
Account Status from the /account storable class
Account Type from the /account storable class

To define additional data during scenario evaluation, you can create and maintain the required data (parameters and their values) in a customized storable class or by extending the /profile storable class. This storable class should have a link to the bill unit to which the data is applicable. There can be only one record per bill unit. The parameter used should be at the 0th level of the storable class.

Save and close the file.
Open the BRM_home/apps/load_config/pin.conf file in a text editor.

Uncomment the following entry:

- load_config validation_module libLoadValidCollections  LoadValidCollections_init

Save and close the file.
Load the updated file by running the following command:
```
load_config -v config_collections_scenario_params.xml
```
Note:
- The load_config utility requires a configuration (pin.conf) file.
- If you do not run the utility from the directory in which the configuration file is located, include the complete path to the file. For example,
```
load_config -v BRM_home/sys/data/config/config_collections_scenario_params.xml
```
Stop and restart the CM.

To verify that the updated collections parameter configurations were loaded, you can display the /config/collections/scenario_params object by using Object Browser, or use the robj command with the testnap utility.

Increasing the Size of the CM Cache for Scenario Data

When evaluating scenarios, you might need to increase the space allocated to the scenario data in the CM cache.

To increase the CM cache size for scenario data:

Open the CM configuration file (BRM_home/sys/cm/pin.conf).
Increase cache_size in the following entry:
```
- cm_cache fm_collections_config_scenario_cache number_of_entries, cache_size, hash_size
```
Note:
The default is 40960 bytes.

If the file does not have this entry, add it.
Save and close the file.
Stop and restart the CM.