Oracle® Communications Billing and

Revenue Management
Collections Manager

Release 12.0
E51006-02
December 2020
Oracle Communications Billing and Revenue Management Collections Manager, Release 12.0

E51006-02

Copyright © 2017, 2020, Oracle and/or its affiliates.

This software and related documentation are provided under a license agreement containing restrictions on
use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your
license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license,
transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse
engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is
prohibited.

The information contained herein is subject to change without notice and is not warranted to be error-free. If
you find any errors, please report them to us in writing.

If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on
behalf of the U.S. Government, then the following notice is applicable:

U.S. GOVERNMENT END USERS: Oracle programs (including any operating system, integrated software,
any programs embedded, installed or activated on delivered hardware, and modifications of such programs)
and Oracle computer documentation or other Oracle data delivered to or accessed by U.S. Government
end users are "commercial computer software" or "commercial computer software documentation" pursuant
to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such,
the use, reproduction, duplication, release, display, disclosure, modification, preparation of derivative works,
and/or adaptation of i) Oracle programs (including any operating system, integrated software, any programs
embedded, installed or activated on delivered hardware, and modifications of such programs), ii) Oracle
computer documentation and/or iii) other Oracle data, is subject to the rights and limitations specified in the
license contained in the applicable contract. The terms governing the U.S. Government’s use of Oracle cloud
services are defined by the applicable contract for such services. No other rights are granted to the U.S.
Government.

This software or hardware is developed for general use in a variety of information management applications.
It is not developed or intended for use in any inherently dangerous applications, including applications that
may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you
shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its
safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this
software or hardware in dangerous applications.

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of
their respective owners.

Intel and Intel Inside are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are
used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Epyc,
and the AMD logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered
trademark of The Open Group.

This software or hardware and documentation may provide access to or information about content, products,
and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly
disclaim all warranties of any kind with respect to third-party content, products, and services unless otherwise
set forth in an applicable agreement between you and Oracle. Oracle Corporation and its affiliates will not
be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content,
products, or services, except as set forth in an applicable agreement between you and Oracle.
Contents
Preface
Audience vi
Documentation Accessibility vi
Related Documents vi

1 Understanding Collections Manager

About Collections 1-1
About Collections Manager 1-1
How Collections Manager Processes Bill Units 1-4
Collections Manager Preprocessing 1-4
About Scenario Processing 1-5
About Collections Scenarios 1-6
About Overdue and Entry Dates 1-7
About Collections Action Dependencies 1-8
About Collections Groups 1-8
Corrective Billing and Collections 1-9
Promise-to-Pay Agreements 1-9
About Defining Rule-Based Collections Scenario Assignment 1-10
About Collections Scenario Replacement 1-10
Customizing Collections 1-10

2 List of Collections Features

Collections Features 2-1

3 Installing and Configuring Collections Manager

Installing and Configuring Collections Manager Server 3-1
Installing Collections Manager 3-1
Configuring Collections Manager 3-1
Updating Partitions 3-1
Configuring the pin_bill_day Script to Run Collections 3-2

iii
 Uninstalling BRM Collections Manager 3-2
Installing Collections Manager Client 3-2
Installation Collections Configuration Center 3-2
Uninstalling Collections Configuration Center 3-2

4 Assigning Collections Personnel Roles

Assigning Collections Personnel Roles 4-1

5 Setting Up Collections Manager

Adding Custom Pay Types 5-1
Setting the Minimum Overdue Balance to Process 5-2
Setting the Number of Bill Units Retrieved during Step Searches 5-2
Setting Up Invoice Reminders 5-3
Creating Dependencies between Collections Actions in a Scenario 5-3
Adding Custom Reason Codes for Collections Center 5-4

6 Setting Up Dunning Letters

About Setting Up Dunning Letters 6-1
Loading Dunning Letter Templates 6-1
Setting Dunning Letter Delivery Preferences for Noninvoice Bill Units 6-2
Setting the Delivery Option 6-3
Setting the Email Delivery Preference 6-3
Specifying a File for the Email Body 6-3

7 Defining Collections Actions

About Defining Collections Actions 7-1
Understanding Manual Actions 7-2
Understanding System Actions 7-2
Performing Scheduled Collections Actions after Reinstalling Collections Manager 7-3
Understanding Custom Actions 7-3
Increasing the Size of the CM Cache for Actions Data 7-4

8 Defining Collections Scenarios

Defining Collections Scenarios 8-1
Loading Additional Parameters for Scenario Assignment 8-1
Increasing the Size of the CM Cache for Scenario Data 8-4

iv
9 Setting Up Collections Profiles
Setting Up Collections Profiles 9-1
Increasing the Size of the CM Cache for Profiles Data 9-2

10 Configuring How Collections Manager Determines Dates

Configuring How Collections Manager Determines Dates 10-1
Configuring the Overdue Date 10-3
Configuring the Entry Date 10-3

11 Integrating Collections Manager with Custom Client Applications

About Integrating Collections Manager with Custom Client Applications 11-1
About Calling the Collections Manager API 11-2
About Notifying Custom Client Applications when Collections Activity Occurs 11-3
Sending Collections Notifications to Custom Client Applications 11-3
Creating CollectionsInfoChange Business Events 11-4

12 Collections Manager Utilities

pin_collections_process 12-1
pin_collections_send_dunning 12-2
pin_load_template 12-3

v
 Preface

Preface
This guide describes how to use Oracle Communications Billing and Revenue
Management (BRM) Collections Manager to manage collections for your business.

Audience
This guide is intended for anyone who installs, configures, or administers Collections
Manager and for those who manage collections for your business.

Documentation Accessibility
For information about Oracle's commitment to accessibility, visit the
Oracle Accessibility Program website at http://www.oracle.com/pls/topic/lookup?
ctx=acc&id=docacc.

Access to Oracle Support

Oracle customers that have purchased support have access to electronic support
through My Oracle Support. For information, visit http://www.oracle.com/pls/topic/
lookup?ctx=acc&id=info or visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs
if you are hearing impaired.

Related Documents
For more information, see the following documents in the BRM Release 12.0
documentation set:
• BRM Release Notes
• BRM Concepts

vi
1
Understanding Collections Manager
This document provides an overview of using Oracle Communications Billing and
Revenue Management (BRM) Collections Manager to manage collections for your
business.
See also:
• Installing and Configuring Collections Manager
• Setting Up Collections Manager
• List of Collections Features
• BRM Concepts

About Collections
Collections, or debt management, is a proactive process used by businesses to collect
overdue payments from their customers. Collections includes identifying accounts that
have overdue balances, determining whether those accounts meet predefined criteria
for action, and then taking those actions.
Every business defines its own processes, but collections generally involves a series
of increasingly serious steps taken against the customer:
• There is usually a minimum amount due that qualifies for collections. Very small
amounts may not be worth the effort required to collect them.
• In most cases, businesses allow a grace period after payment is due. If payment is
received within the grace period, no action is taken.
• After the grace period ends, a first action such as a reminder on an invoice, a
dunning letter, or a phone call takes place. A late fee may also be assessed.
• If no payment is received as the result of the first collections action, additional
steps can be taken. These actions range from additional letters or phone calls to
stopping service to referring the case to a collections agency.
• An account is removed from collections when the overdue amount and any late
fees are paid or when the debt is written off.

About Collections Manager

Collections Manager is an optional product that manages in-house debt collection.
Collections Manager performs all of its activities at the bill unit (/billinfo object) level
rather than at the account level. When an account has multiple bill units, Collections
Manager targets only those bill units that have overdue balances, but it ignores the
account's bill units that do not qualify for collections.
Collections Manager provides tools that enable you to:
• Configure collections criteria

1-1
 Chapter 1
About Collections Manager

• Determine which bill units have overdue balances

• Apply your collections criteria to those bill units
• Perform automatic collections activities, such as imposing late fees and sending
dunning letters
• Manage manual collections activities, such as phone calls by collections agents, or
converting payments to installments
• Replace a billing scenario based on the severity
Collections Manager includes client and server components that work together, as
shown in Figure 1-1.

Figure 1-1 Collections Manager Components

Collections Manager includes these main components:

• Collections Configuration: A GUI application used to define collections
scenarios and actions, set up aging buckets, and define user roles for collections
personnel. See "Setting Up Collections Manager".
• Collections Center: A GUI application used by collections agents and collections
managers. Collections agents use it to view, add, and cancel collections actions
for bill units. Collections managers use it to oversee the collections process and to
assign bill units to agents.

1-2
 Chapter 1
About Collections Manager

• Collections Reports: A comprehensive reporting feature that you use to display

information such as the bill unit status, the delinquent amount, and the total
balance for all bill units in collections. Reports can be displayed in summary or
detailed form. See "Collections Manager Reports" in BRM Reports.
• Utilities: Command-line applications that perform specific collections tasks.
– The pin_collections_process utility is a daily batch process that identifies bill
units that should be placed in collections and performs automatic collections
actions. pin_collections_process uses criteria set up in Collections
Configuration to identify bill units.
– The pin_collections_send_dunning utility is a daily batch process
that generates dunning letters based on data collected by
pin_collections_process. Dunning letters can be sent via email or printed.
– The pin_load_template utility loads dunning letter templates into the
database.
– The load_config utility loads additional criteria to be used for assigning a bill
unit to a collections scenario.
• Collections Manager Facilities Modules (FMs): Opcodes that are called by the
collections applications and utilities. There are standard opcodes that perform the
basic collections functionality and policy opcodes that you use to customize that
functionality. See "Collections Manager FM Standard Opcodes" and "Collections
Manager FM Policy Opcodes" in BRM Developer's Reference.
• Storable classes: New and extended classes, including /config subclasses, that
store collections-related data.
You use Collections Center to perform day-to-day collections tasks. It supports the
work of both collections agents and collections managers.
You assign collections roles (agent and manager) in the Collections Configuration
application. All collections personnel must have customer service representative
(CSR) accounts.
Collections agents monitor and run collections activities for the bill units assigned to
them. Using Collections Center, collections agents can:
• View collections tasks for bill units assigned to them.
• Monitor the status of both automatic and manual actions defined by the collections
scenario.
• Insert new actions for a particular bill unit.
• Reschedule actions.
• Receive credit card payments.
Collections managers supervise the work of collections agents. Using Collections
Center, managers can:
• Find specific bill units in collections.
• View bill units.
• View all collections tasks scheduled for a bill unit.
• Assign bill units to collections agents.
• View collections tasks assigned to particular agents.

1-3
 Chapter 1
How Collections Manager Processes Bill Units

• Exempt bill units from collections.

• Perform all collections agent tasks.

How Collections Manager Processes Bill Units

The main Collections Manager process (triggered by the pin_collections_process
utility) searches the BRM database to find bill units with overdue balances and bill
units that are already in collections.

Note:
You should run pin_collections_process every day to ensure that bill units
enter collections promptly. The timing of actions, such as invoice reminders,
dunning letters, and late fees, is based on the day the bill unit enters
collections. See "About Overdue and Entry Dates".

Collections Manager processes bill units in two phases:

• During collections preprocessing, the bill unit is evaluated to determine if it should
enter, exit, or remain in collections.
• During scenario processing, a bill unit that enters or remains in collections is
processed based on its collections profile. These profiles are used only for
collections and are not the same as the customer profiles associated with
accounts.

Collections Manager Preprocessing

During preprocessing, Collections Manager determines whether an account's bill
unit should enter, exit, or remain in collections. Preprocessing differs depending on
whether the bill unit is already in collections.
• For bill units already in collections, the process compares the current overdue
balance to the exit criteria you defined in the collections scenario (see "About
Scenario Processing"). If the overdue balance is less than or equal to the exit
criteria for the bill unit's scenario, the bill unit is removed from collections. If the
overdue balance is greater than the exit criteria, the bill unit remains in collections
and enters scenario processing.
For example, if the exit criteria is an overdue balance less than or equal to $10, a
bill unit with an overdue balance of $8 would be removed from collections, and a
bill unit with an overdue balance of $20 would remain in collections.
• For bill units not in collections, the process compares the current overdue
balance to the minimum collections value that you defined. (See "Setting the
Minimum Overdue Balance to Process".)
– If the overdue balance is less than the minimum collections value, the bill unit
remains out of collections and no further action takes place.
– If the overdue balance is greater than the minimum collections value, the
bill unit is assigned to a collections profile based on criteria you defined in
advance. By default, all bill units belong to a single collections profile, but you
can create any number of custom profiles. For example, you can assign bill

1-4
 Chapter 1
How Collections Manager Processes Bill Units

units to profiles based on credit score or payment history. See "Setting Up

Collections Profiles".
After a bill unit is assigned to a collections profile, the collections process checks if
the bill unit meets the entry criteria for any of the scenarios that are valid for the bill
unit's profile. The default entry criteria are based on severity, overdue balance and the
number of days overdue. For example, you can specify an overdue balance of $100
that is at least 30 days old. You can define additional parameters for the entry criteria.
See "About Collections Scenarios".
• If the bill unit does not meet the entry criteria for any of the scenarios for its
collections profile, it remains out of collections and no further action takes place.
• If the bill unit meets the entry criteria for a scenario, it is assigned to that scenario,
enters collections, and proceeds to scenario processing.
• If the bill unit meets the entry criteria for more than one scenario, it is assigned to
the scenario with the highest entry criteria or the highest severity.
For example, you might have the following three scenarios for a collections profile:
– $50 entry requirement and severity 1
– $100 entry requirement and severity 1
– $100 entry requirement and severity 2
A bill unit with an overdue balance of $101 is assigned to the scenario with
the $100 requirement with severity 1 because it has the highest entry criteria and
the highest severity.
• If you have configured additional parameters for the entry criteria, the bill unit
is evaluated for the new scenario. If the new scenario is different from the
existing scenario, the bill unit is exited from the existing scenario and is assigned
to the new scenario. For example: while in collections, the customer makes a
partial payment that reduces the overdue balance sufficiently to allow a scenario
replacement to something less severe. The customer service representative
(CSR) triggers an automated scenario replacement process that reevaluates the
scenario assignment logic on the bill unit and assigns the bill unit to a new
scenario.

About Scenario Processing

A collections scenario defines severity, entry and exit criteria as well as the sequence
of actions that take place while an account's bill unit is in collections. See "About
Collections Scenarios".
During scenario processing, Collections Manager first determines if any actions are
due for this bill unit today. The timing of actions is based on the number of days
since the bill unit entered the scenario. (For more information about the dates used in
scenario processing, see "About Overdue and Entry Dates".) If an action is due today,
Collections Manager then determines whether the action has a Pending status. (See
"About Collections Action Dependencies".)
• If no actions are due, the process moves to the next bill unit.
• If the scenario includes actions to be carried out today but they have a Waiting
For Dependents status, the process moves to the next bill unit.

1-5
 Chapter 1
How Collections Manager Processes Bill Units

• If the scenario includes actions to be carried out today and they have a Pending
status, these actions are processed. Some actions happen automatically, some
require manual intervention.
– Automatic actions are performed by Collections Manager. They include
predefined actions, such as sending dunning letters or invoice reminders, as
well as custom actions that you define. See "Understanding System Actions"
and "Understanding Custom Actions".
– Manual actions, such as making phone calls, or converting payments to
installments, are performed by collections agents. Collections agents use
Collections Center to track the bill units and actions, either mandatory or
optional, for which they are responsible. See "Understanding Manual Actions".
After all scheduled actions have taken place, Collections Manager updates the bill
unit's balance and checks to see if the bill unit now meets the exit criteria for the
scenario. (It is possible that a payment was received as part of a manual action or that
the scenario calls for writing off the balance.)
• If the new overdue balance is less than or equal to the amount specified in the
scenario's exit criteria, the bill unit exits the scenario and leaves collections.
• If the overdue balance is still greater than the exit criteria, the bill unit remains in
collections.

About Collections Scenarios

Collections scenarios determine the way bill units are handled in Collections Manager.
Scenarios define the entry criteria that determine whether a bill unit will be handled by
the collections system, the sequence of actions that take place when a bill unit is in
collections, the exit criteria that determine when a bill unit leaves collections, and the
severity level that determines priority of the scenario assignment to a bill unit when a
bill unit is eligible for two scenarios that have the same entry criteria.
For example, you can define a scenario with the following characteristics:
• A bill unit enters collections with a minimum overdue balance of $100 that is at
least 30 days old.
• A bill unit leaves collections when the overdue balance falls below $25.
• The customer receives a courtesy phone call after 10 days in collections.
• A late fee is assessed and a dunning letter is sent after 30 days in collections.
• A second dunning letter is sent after 45 days.
• The bill unit is closed and the debt written off after 120 days.
• The bill unit is inactivated after 180 days.
• The severity level that determines the priority of the scenario assignment.
Each scenario includes a list of actions that are performed either:
• On their due date. For example, a manual phone call is made 5 days after the bill
unit enters collections, and a dunning letter is sent 10 days after the bill unit enters
collections.
• In a specified order. For example, a CSR must make a courtesy phone call to the
customer before the system refers the account to a collections agency.

1-6
 Chapter 1
How Collections Manager Processes Bill Units

About Overdue and Entry Dates

There are two important dates that collections managers use when processing bill
units:
• The overdue date is the due date of the bill that causes the bill unit to enter
collections. By default, Collections Manager uses the due date of the latest
overdue bill at the time that the bill unit enters collections.
You can configure Collections Manager to use the earliest due date instead. See
"Configuring How Collections Manager Determines Dates".
• The entry date is the date on which the bill unit enters a collections scenario. By
default, Collections Manager defines the entry date as the overdue date plus the
number of days specified in the scenario's entry criteria. For example, if the bill
due date is June 15 and the scenario specifies that the bill must be at least 10
days overdue, the entry date is June 25. You can configure Collections Manager to
use the actual date on which the bill unit is processed and enters collections. See
"Configuring How Collections Manager Determines Dates".

Note:
Do not schedule actions for the same calender date as the entry date.
Scheduling actions on the entry date can cancel the actions.

Collections Manager stores the overdue date in the PIN_FLD_OVERDUE_T field of

the /collections_scenario object.
Collections Manager uses the overdue date to determine the aging buckets into
which a bill unit falls during scenario processing. Aging buckets are used to display
information about the age of overdue balances. This information is displayed in
Collections Center. For example, you could define 30-day, 60-day, and 90-day
buckets. The 30-day bucket holds balances that are 1 to 30 days overdue. The 60-day
bucket holds balances that are 31 to 60 days overdue, and the 90-day bucket holds
balances that are 61 to 90 days overdue. Balances older than 90 days fall into an
implicit fourth bucket.
Collections Manager uses the entry date to determine when the actions specified in a
scenario take place. For example, you can define a scenario so that a dunning letter is
sent 30 days after the bill unit enters the scenario.

Note:
If you run Collections Manager irregularly or at long intervals, the overdue
and entry dates for a bill unit could be misleading. For example, if you do not
run collections for several months, a bill unit that has not paid its bill during
this period will enter collections with overdue and entry dates based on the
latest of several overdue bills. As a result, collections actions will begin after
a lengthy period of nonpayment. To avoid this risk, you should run collections
regularly, preferably daily.

1-7
 Chapter 1
How Collections Manager Processes Bill Units

About Collections Action Dependencies

Collections action dependencies ensure that all of a scenario's actions are performed
in order and maintain the interval between actions. To do this, Collections Manager:
• Determines whether a scenario's preceding action has been completed or
canceled before performing an action on its due date.
• After an action is completed or canceled, reschedules the due date of all of the
scenario's remaining actions.
For example, assume a collections scenario includes the following actions:
• Action 1: Collections agent makes a courtesy phone call two business days after
the bill unit enters collections.
• Action 2: Collections Manager sends an invoice reminder four business days after
the bill unit enters collections.
• Action 3: Collections Manager applies a late fee six business days after the bill unit
enters collections.
On day four, Collections Manager determines whether Action 1 has been completed
or canceled and, since Action 1 is still open, does not send an invoice reminder. After
the collections agent makes the courtesy phone call on day five, Action 1 is marked
as completed and then Collections Manager reschedules Action 2 for seven business
days after the bill unit enters collections and Action 3 for nine business days after the
bill unit enters collections. This ensures that there are two business days between the
courtesy phone call and the invoice reminder, and four business days between the
courtesy phone call and the late fee.
Collections Manager creates dependencies between actions in a scenario by using
action status settings:
• Pending: This status specifies that the action can be run on its due date. All
preceding actions have been canceled or completed.
• Waiting For Dependents: This status specifies that the action cannot be
performed until the preceding action is canceled or completed. If an action is set to
this status on its due date, Collections Manager does not perform the action and
then moves to the next bill unit.
When a bill unit first enters a collections scenario, Collections Manager sets
the first action's status to Pending and all other actions' status to Waiting For
Dependents. After the first action is completed or canceled, Collections Manager
updates the second action's status from Waiting For Dependents to Pending and
then reschedules the due date of all remaining actions. After the second action is
completed or canceled, Collections Manager updates the third action's status from
Waiting For Dependents to Pending and reschedules the due date of all remaining
actions. This process continues for all of the scenario's remaining actions.

About Collections Groups

Some countries have legal requirements that prevent actions, such as collections,
from being taken against minors. This law applies to minors even when they have their
own accounts and pay their own bills. Collections groups enable you to define the
legal entity, such as a parent or guardian, who is responsible for a bill if it enters into
collections.

1-8
 Chapter 1
How Collections Manager Processes Bill Units

When you create an account and its bill units, you can specify whether collections
actions must be taken against another account and bill unit. To do this, you create a
collections group, which consists of the following:
• A parent bill unit: During collections processing, Collections Manager enters only
the parent bill unit into a collections scenario. The parent bill unit is assigned a
collections scenario based on:
– The combined overdue balance from all bill units in the collections group. For
example, if one child bill unit is $100 past due and a second child bill unit
is $50 past due, the overdue balance is $150.
– The oldest due date from all bill units in the collections group. For example, if
one child bill unit had a due date of June 1 and the second child bill unit had a
due date of June 10, the overdue date is June 1.
• One or more child bill units: During collections processing, Collections Manager
skips all child bill units in the group. The child bill unit and parent bill unit do not
need to be linked hierarchically.
A bill unit can belong to only one collections group, and a parent bill unit cannot be
a child bill unit of the same collections group. You can change a collections group's
parent and add or remove child bill units at any time.
When you define a collections action in Collections Configuration Center, you can
specify whether the action applies to the parent bill unit, to all the child bill units, or to
the parent and all the child bill units. For example, you can specify that all "Referring
the Account to a Collections Agency" actions apply to the parent bill unit only, and all
"Sending a Dunning Letter" actions apply to the parent and all child bill units.

Corrective Billing and Collections

When BRM generates a corrective bill for a bill that is not yet in collections, the
Collections Manager uses the sum of the adjustments for the bill to determine whether
an account's bill unit should enter collections.
If BRM generates a corrective bill for a bill already in collections, Collections Manager
takes the following actions based on the sum of the adjustments for the bill:
• If the sum of the adjustments for the bill goes below the threshold, BRM moves
that bill out of collections.
• If the sum of the adjustments for the bill remains above the threshold, BRM
maintains the account's bill unit in collections but replaces the bill number of that
bill with the bill number of the corrective bill.

Promise-to-Pay Agreements
When a bill unit is in collections, the customer can request a promise-to-pay
agreement. This agreement allows you to defer running the collections actions for
a bill unit, allowing the customer to pay the due amount at a date beyond the original
payment due date. The customer can pay the due amount in installments.
Using Collections Center, you can add or update a customer's payment method and
reschedule payment dates and amounts for Promise to Pay and Collect Payment
actions.
To use these options in Collections Center, you must set the following permissions
through Permissioning Center:

1-9
 Chapter 1
About Defining Rule-Based Collections Scenario Assignment

• /collectionapps/collections/updatepayment: To allow you to update promise-to-

pay payment details in Collections Center.
• /collectionapps/collections/newcard: To register a new credit card or direct debit
account details.
• /collectionapps/collections/maskcarddetails: To see all the digits of the credit
card or the direct debit account.

Note:
If credit card tokenization is enabled, you can view only the last four
digits of the credit card. See "Masking Credit Card Numbers by Using
Tokens" in BRM Configuring and Collecting Payments.

By default, the Promise to Pay option is available in the Collections Center Actions
menu. To disable the Promise to Pay option in the Collections Center Actions menu,
use the /collectionapps/collections/promisetopay permission.
You can customize the system's behavior using the policy opcodes. See "Collections
Manager FM Policy Opcodes" in BRM Opcode Guide for more information.

About Defining Rule-Based Collections Scenario

Assignment
By default, Collections Manager assigns the collections scenario to the bill unit
based on the overdue balance and the number of overdue days. You can use
the load_config utility to load additional parameters to be used for the collections
scenarios assignment. The utility loads the additional parameters into the /config/
collections/scenario_params object that is used to define an evaluation formula.
Each formula is in turn linked to the collections scenario assigned to the bill unit.
Using Collections Configuration, you can add, modify, or delete the value of the
additional parameters from the scenario definitions.

About Collections Scenario Replacement

When a bill unit meets the entry criteria for a collections scenario, it is assigned
to that scenario, enters collections, and proceeds to scenario processing. If there
is a change in the criteria, such as the customer making a partial payment, the
bill unit may not meet the entry criteria for the collections scenario. Collections
Manager reevaluates the entry criteria based on additional parameters and replaces
the assigned collections scenario with a new collections scenario. See BRM Opcode
Guide for more information.
When a bill unit is in collections, you can use Collections Center to replace the
collections scenario assigned to the bill unit.

Customizing Collections
You can use opcodes to customize collections, for example:

1-10
 Chapter 1
Customizing Collections

• You can customize dunning letter data before it is stored in the BRM database. For
example, you can enrich the standard data with additional information, such as the
date on which the account will be inactivated.
• You can apply finance charges to overdue amounts.
• You can customize how BRM calculates the collections due date (for example, to
take holidays into account).
• You can customize how BRM charges late fees for overdue charges.
See the chapter about collections opcodes in BRM Opcode Guide.

1-11
2
List of Collections Features
This document lists the collections features in Oracle Communications Billing and
Revenue Management (BRM).

Collections Features
This table lists collections features.

Task Topics
Learn about collections Understanding Collections Manager
Install Collections Manager Installing and Configuring Collections Manager
Assign collections roles Assigning Collections Personnel Roles
Configure collections options Adding Custom Pay Types
Setting the Minimum Overdue Balance to Process
Setting the Number of Bill Units Retrieved during Step
Searches
Setting Up Invoice Reminders
Creating Dependencies between Collections Actions in
a Scenario
Adding Custom Reason Codes for Collections Center
Set up dunning letters Setting Up Dunning Letters
Define collections actions Defining Collections Actions
Define collections scenarios Defining Collections Scenarios
Set up collections profiles Setting Up Collections Profiles
Configure dates in Collections Manager Configuring How Collections Manager Determines
Dates
Integrate your custom application with Collections Integrating Collections Manager with Custom Client
Manager Applications

2-1
3
Installing and Configuring Collections
Manager
This document explains how to install the Oracle Communications Billing and Revenue
Management (BRM) Collections Manager software. Installation includes both client
and server components.

Note:
Collections Manager Reports are installed separately. See "Installing BRM
Reports" in BRM Reports.

See also:
• Understanding Collections Manager
• Setting Up Collections Manager
• List of Collections Features

Installing and Configuring Collections Manager Server

The Collections Manager server components include opcodes, utilities, and storable
classes.

Installing Collections Manager

You can install Collections Manager in the BRM_home directory. For instructions, see
"Installing Individual BRM Components" in BRM Installation Guide.

Configuring Collections Manager

This section describes how to configure the Collections Manager software.

Updating Partitions
If your event tables are partitioned during installation, run the partition_utils utility with
the -o update parameter from the BRM_home/apps/partition_utils directory:
perl partition_utils.pl -o update

For more information, see "Updating Partitions" and "partition_utils" in BRM System
Administrator's Guide.

3-1
 Chapter 3
Installing Collections Manager Client

Configuring the pin_bill_day Script to Run Collections

To run collections automatically, you need to edit the pin_bill_day script.
1. Open the pin_bill_day script in a text editor. The script is located in
BRM_home\bin.
2. Find the Collections Manager section of the script. If the following lines are
commented out, remove the comment marks:
cd ${PINDIR}/apps/pin_collections
pin_collections_process
pin_collections_send_dunning
3. Save and close the file.

Uninstalling BRM Collections Manager

To uninstall BRM Collections Manager, See "Uninstalling Optional Components" in
BRM Installation Guide.

Installing Collections Manager Client

Before installing BRM Collections Configuration Center, you must install:
• BRM Collections Manager. See "Installing and Configuring Collections Manager
Server".
• An application such as WinZip for extracting compressed files.
Table 3-1 shows the disk space required to download, extract, and install the
Collections Manager client application:

Table 3-1 Disk Space Requirements

Application Required Space (MB)

Collections Configuration 110
Center

Installation Collections Configuration Center

You install the Collections Configuration Center in the same way that you install other
BRM clients. See "Installing BRM Clients" in BRM Installation Guide.

Uninstalling Collections Configuration Center

To uninstall Collections Configuration Center, See "Uninstalling BRM Client
Applications" in BRM Installation Guide.

3-2
4
Assigning Collections Personnel Roles
This document explains how to set up roles in Oracle Communications Billing and
Revenue Management (BRM) Collections Manager.
See also:
• Understanding Collections Manager
• List of Collections Features

Assigning Collections Personnel Roles

If you use Collections Center to manage collections activity, you need to assign
personnel roles to collections agents and collections managers. You assign collections
roles in Collections Configuration. The tasks that collections personnel can perform
and the information they can see depend on their role.
Collections Configuration displays a list of all CSR accounts. You select the accounts
that should have a collections role.
To customize how agents are assigned,
use the PCM_OP_COLLECTIONS_POL_ASSIGN_AGENT and
PCM_OP_COLLECTIONS_POL_ASSIGN_DCA opcodes. See BRM Opcode Guide.

4-1
5
Setting Up Collections Manager
This chapter explains how to set up Oracle Communications Billing and Revenue
Management (BRM) Collections Manager.
Topics in this document:
• Adding Custom Pay Types
• Setting the Minimum Overdue Balance to Process
• Setting the Number of Bill Units Retrieved during Step Searches
• Setting Up Invoice Reminders
• Creating Dependencies between Collections Actions in a Scenario
• Adding Custom Reason Codes for Collections Center
See also:
• Understanding Collections Manager
• List of Collections Features

Adding Custom Pay Types

When you run the pin_collections_process utility to trigger collections actions, the
utility considers only bill units with the default pay types. If you created a custom
payment type, you need to configure collections to support it.
To add custom pay types:
1. Open the pin_collections configuration file (BRM_home/apps/pin_collections/
pin.conf) in a text editor, where BRM_home is the directory in which the BRM
server software is installed.
2. Enter the custom BRM pay type code in the pay_type entry:
- pin_collections_process pay_type PaymentType

For example, enter 10013 for the wire transfer payment type:
- pin_collections_process pay_type 10013

To add multiple custom pay types, separate the PaymentType entries by a comma.
- pin_collections_process pay_type 10013,10014

Note:
You can find valid pay type codes in the BRM_home/include/pin_cust.h
file, under PAY_TYPE.

5-1
 Chapter 5
Setting the Minimum Overdue Balance to Process

3. Save and close the file.

Setting the Minimum Overdue Balance to Process

You can specify the minimum overdue balance that triggers Collections Manager.
When you run pin_collections_process, only bill units with overdue balances greater
than or equal to the amount you specify are considered.

Note:
The value you specify in the collections pin.conf file is a system-wide
minimum value. Collections scenarios cannot have entry criteria lower than
this value. For example, if the minimum value in the collections pin.conf file
is $20 and a collections scenario has an entry criteria of $10, a bill unit will
enter collections only if its overdue balance is $20 or more.

To set the minimum overdue balance for collections:

1. Open the pin_collections configuration file (BRM_home/apps/pin_collections/
pin.conf) in a text editor.
2. Set the minimum_due entry to the minimum overdue balance:
- pin_collections_process minimum_due Amount

For example, enter 25 to specify $25:

- pin_collections_process minimum_due 25.00

Note:
The default is 0.0.

3. Save and close the file.

Setting the Number of Bill Units Retrieved during Step

Searches
The Collections Facilities Module (FM) opcodes use step search when searching for
bill units. The step size determines the number of bill units retrieved at one time. You
can improve performance by changing this value.
To specify the number of bill units to retrieve in step searches:
1. Open the Connection Manager (CM) configuration file (BRM_home/sys/cm/
pin.conf) in a text editor.
2. Set the account_search_batch entry to the number of bill units.
- fm_collections account_search_batch Amount

For example, enter 500 to retrieve 500 bill units with each step of the search.

5-2
 Chapter 5
Setting Up Invoice Reminders

- fm_collections account_search_batch 500

Note:
The default is 1000.

3. Save and close the file.

4. Stop and restart the CM.

Setting Up Invoice Reminders

Collections Manager uses the Universal Message Store (UMS) framework to deliver
invoice reminders. See "Using BRM Messaging Services" in BRM Developer's Guide
for general information.
To use invoice reminders as part of the collections process, you must complete three
tasks related to the UMS framework:
• Enable messaging by modifying the PCM_OP_INV_POL_PREP_INVOICE policy
opcode. See "Enabling Messaging" in BRM Developer's Guide.
• Load a message style sheet (message.xsl) that makes it possible to display
messages in invoices. See"Loading the Message Style Sheet" in BRM Developer's
Guide.
• Load invoice reminder templates into /string objects in the BRM database.
See "Creating and Loading Message Templates" in BRM Developer's Guide.
Collections Manager includes a sample invoice reminder template that you can
modify and rename as necessary. The file is BRM_home/sys/msgs/messages/
message_invoice_reminder.en_US.

Creating Dependencies between Collections Actions in a

Scenario
By default, Collections Manager performs automated collections actions on their due
date, regardless of whether the preceding collections actions have been completed or
canceled. This can cause collections actions to be completed out of order.
You can configure Collections Manager to create dependencies between collections
actions in a scenario and thus perform collections actions in order.
When so configured, Collections Manager performs the following additional steps
during scenario processing:
• Performs a collections action on its due date only if the action's status is set to
Pending.
• After completing or canceling a collections action, Collections Center asks whether
to reschedule the due dates of any outstanding collections actions in the scenario.
When set, Collections Manager calculates the difference in days between the
action's completed or canceled date and the action's due date, and then moves
the due dates of all outstanding actions by the calculated number of days. For
example, assume a collections scenario contains two collections actions:

5-3
 Chapter 5
Adding Custom Reason Codes for Collections Center

– Action 1: A manual phone call from an agent 5 days after the bill unit enters
collections.
– Action 2: Referring the case to an outside collections agency 10 days after the
bill unit enters collections.
If action 1 does not occur until day 7, Collections Manager changes the due date
of action 2 from day 10 to day 12. This maintains the interval between Action 1
and Action 2.
To create dependencies between collections actions in a collections scenario:
1. Open the CM configuration file (BRM_home/sys/cm/pin.conf) in a text editor.
2. Set the collections_action_dependency entry to 1.
- fm_collections collections_action_dependency 1

Note:
The default is 0, which disables dependencies between collections
actions.

3. Save and close the file.

4. Stop and restart the CM.

Adding Custom Reason Codes for Collections Center

In Collections Center, you can perform operations such as inserting new actions,
rescheduling actions, and exempting bill units from collections.
For many of these operations, you choose a reason that is associated with the action.
Collections Center includes a default set of reasons, which you can modify.
To modify the default reasons, you can add or change reason codes in each
reasons.locale file.

5-4
6
Setting Up Dunning Letters
This document describes how to set up collections dunning letters in Oracle
Communications Billing and Revenue Management (BRM).
Topics in this document:
• About Setting Up Dunning Letters
• Loading Dunning Letter Templates
• Setting Dunning Letter Delivery Preferences for Noninvoice Bill Units
• Setting the Delivery Option
• Setting the Email Delivery Preference
• Specifying a File for the Email Body
See also:
• Understanding Collections Manager
• Setting Up Collections Manager
• List of Collections Features

About Setting Up Dunning Letters

To set up Collections Manager to generate dunning letters, you must run Email Data
Manager (DM) and load your dunning letter templates.
You can customize dunning letter data before it is stored in the BRM database.
For example, you can enrich the standard data with additional information, such
as the date on which the account will be inactivated. To do so, customize the
PCM_OP_COLLECTIONS_POL_PREP_DUNNING_DATA opcode. See BRM Opcode
Guide.
PCM_OP_COLLECTIONS_POL_PREP_DUNNING_DATA enables customization of
dunning letter data before it is stored in the database. You can modify the type of data
gathered by customizing the opcode. For example, you can enrich the standard data
with additional information, such as the date on which the account will be inactivated.

Loading Dunning Letter Templates

You load dunning letter templates by using the pin_load_template utility. These
dunning letter templates are used in Collections Configuration to set the dunning
letters action and the invoice reminders action.
Dunning letter templates are XSL documents that provide the basic content of the
letter, leaving placeholders for specific information such as the customer's name,
overdue balance, and so on. You can design and load multiple dunning letter
templates for different scenarios and situations.

6-1
 Chapter 6
Setting Dunning Letter Delivery Preferences for Noninvoice Bill Units

Collections Manager includes two sample dunning letter templates: dunning_first.xsl

and dunning_last.xsl. Both templates are stored in BRM_home/sys/data/config/
stylesheets. You can use a third-party XSL editor to modify these templates or to
create your own templates.
After creating your template, load it into the BRM database by using the
pin_load_template utility. Templates are available in Collections Configuration
immediately after you load them. See "Defining Collections Actions".
To load a dunning letter template:
1. Go to a directory that contains a valid configuration (pin.conf) file.

Note:
A configuration file is installed automatically in BRM_home/apps/
pin_collections.

The pin_load_template utility uses information in the configuration file to

connect to the BRM database. See "Connecting BRM Utilities" in BRM System
Administrator's Guide.
2. Load the XSL template by entering the following command:

pin_load_template -brand brand_POID - name template_name -type

dunning -locale locale_name -template file_name -usexsl

where:
• brand_POID is the Portal object ID (POID) of the root account.
• template_name is the name of the template as it should appear in Collections
Configuration.
• locale_name is the BRM locale of the template. See "Locale Names" in BRM
Developer's Guide.
• file_name is the name and full path of the template file.
For example, the following command loads the dunning_first.xsl template for the root
account:
pin_load_template -brand "0.0.0.1/account 1" -type dunning -locale en_US -
template BRM_home/config/dunning_first.xsl -name DunningTemplate -usexsl

Setting Dunning Letter Delivery Preferences for Noninvoice

Bill Units
You specify how to deliver dunning letters to noninvoice bill units by using the
pin_collections configuration file (BRM_home/apps/pin_collections/pin.conf).
For noninvoice bill units, you can set the following delivery options:
• Whether to deliver the dunning letter as hardcopy or by email.

6-2
 Chapter 6
Setting the Delivery Option

• For email delivery, whether to send the dunning letter as part of the message body
or as an attachment.
• For dunning letters sent as email attachments, the file path to use for providing
customized content in the email body.

Setting the Delivery Option

By default, dunning letters are printed and sent as hardcopy.
To set the delivery option for dunning letters:
1. Open the BRM_home/apps/pin_collections/pin.conf file in a text editor.
2. Change the value of the delivery_preference entry:
• To deliver dunning letters as hardcopy, enter a nonzero value. This is the
default.
• To deliver dunning letters by email, enter 0.
For example:
- pin_collections_send_dunning delivery_preference 0
3. Save and close the file.

Setting the Email Delivery Preference

By default, dunning letters are delivered in the body of the email.
To set the email delivery preference for dunning letters:
1. Open the BRM_home/apps/pin_collections/pin.conf file in a text editor.
2. Change the value of the email_option entry:
• To deliver dunning letters as email attachments, enter 1.
• To deliver dunning letters in the email body, enter 0. This is the default.
For example:
- pin_collections_send_dunning email_option 0
3. Save and close the file.

Specifying a File for the Email Body

When you send dunning letters as email attachments, you can include customized
information in the email body. You specify the path to a text file for the content of the
message.
To specify the path to the message content:
1. Open the BRM_home/apps/pin_collections/pin.conf file in a text editor.
2. Set the path in the email_body entry:
- pin_collections_send_dunning email_body Path

For example, the following entry specifies the path to the letter file:

6-3
 Chapter 6
Specifying a File for the Email Body

- pin_collections_send_dunning email_body ./letter

Note:
This option takes effect only if email_option is set to 1.

3. Save and close the file.

6-4
7
Defining Collections Actions
Collections actions are individual steps that are performed in the process of collecting
overdue balances. An action might be applying a late fee or making a phone call.
This document describes how to set up collections actions in Oracle Communications
Billing and Revenue Management (BRM).
Topics in this document:
• About Defining Collections Actions
• Understanding Manual Actions
• Understanding System Actions
• Performing Scheduled Collections Actions after Reinstalling Collections Manager
• Understanding Custom Actions
• Increasing the Size of the CM Cache for Actions Data
See also:
• Understanding Collections Manager
• Setting Up Collections Manager
• List of Collections Features

About Defining Collections Actions

Collections actions are individual steps that are performed in the process of collecting
overdue balances. An action might be applying a late fee or making a phone call.
You can define as many actions as you need. For example, you can define different
phone call actions for different situations: courtesy calls, warning calls, and so on. The
same action can be included in multiple scenarios.
When you define a collections action, you specify the following in Collections
Configuration:
• The collections action name
• The action type: manual, one of several system types, or custom
• For bill units in a collections group, the target bill units: the specified bill unit only
(Self), the parent and all child bill units (All Members and Parent), or all child bill
units (All Members)

7-1
 Chapter 7
Understanding Manual Actions

Note:
The action target defined for each of the actions for a customer is the same
for all scenarios. When the action target mode is set for an action, the action
target cannot be changed for any newly defined scenarios.

Understanding Manual Actions

Manual actions are completed by collections agents. When a scenario calls for a
manual action, BRM saves information about the action in the database. Collections
Center displays this information so that a collections agent can complete the action.
For example, suppose that a scenario calls for the customer to receive a courtesy
phone call when the account's bill unit is 10 days into the collections process. When
a bill unit enters collections, this phone call is included in the list of actions for the bill
unit. On the day when the phone call is due, the phone call appears in the list of tasks
for the collections agent assigned to the bill unit.
The most common manual action is a phone call, but you can create any others that
your business requires.

Understanding System Actions

System actions are performed automatically by BRM when either of the following two
utilities is run:
• pin_collections_process
• pin_deferred_act (as a part of the pin_bill_day script)
If an error occurs during any collections action performed when
pin_collections_process is run, the status of the collections action object (/
collections_action) and the schedule object (/schedule) corresponding to the
collections action is updated to Error.
If an error occurs during any collections action performed when pin_deferred_act
is run, the status of the collections action remains Pending but the schedule
object corresponding to the collections action is updated to Error. When
pin_collections_process is run and the collections actions is processed again, if an
error occurs, then the collections action object is updated to Error.
The status of collections actions is updated to Completed on successful completion of
the actions.
By default, Collections Manager supports the following types of system collections
actions:
• Charging a late fee. For late fees, you specify the currency type, such as US
dollars, and the late fee type, either a specified amount or a percentage of the
overdue amount.
• Adding a finance charge. For finance charges, you specify to charge a certain
percentage of the overdue amount.

7-2
 Chapter 7
Performing Scheduled Collections Actions after Reinstalling Collections Manager

• Sending a dunning letter. For dunning letters, you specify the dunning letter
template to use. You can have different templates for different purposes. For
example, you could define several dunning letter templates with varying levels of
severity. These templates could be used at different times in the same scenario or
in separate scenarios.
• Sending an invoice reminder. For invoice reminders, you specify the invoice
reminder template to use. You can have different templates for different purposes.
For example, you could define several invoice reminder templates with varying
levels of severity. These templates could be used at different times in the same
scenario or in separate scenarios.
You can customize each system action's behavior by modifying policy opcodes. See
the chapter on collections opcode workflows in BRM Opcode Guide for information.

Performing Scheduled Collections Actions after Reinstalling

Collections Manager
By default, if you run the pin_collections_process utility after reinstalling Collections
Manager, the scheduled collections actions that have a due date prior to the date on
which you reinstalled Collections Manager are not performed.
You can perform all the scheduled collections actions after reinstalling Collections
Manager and running the pin_collections_process utility irrespective of whether the
collections actions have a due date prior to the date or after the date on which you
reinstalled Collections Manager and ran pin_collections_process.
To perform all scheduled collections actions irrespective of whether they have a due
date prior to the date or after the date on which you reinstalled Collections Manager
and ran pin_collections_process:
1. Open the pin_collections_process configuration file (BRM_home/apps/
pin_collections/pin.conf) in a text editor.
2. Add the following entry:
- pin_collections_process execute_all_actions value

where value is:

• 1 to perform all collections actions irrespective of whether they have
a due date prior to the date or after the date on which you run
pin_collections_process after reinstalling Collections Manager.
• 0 to perform only those collections actions that have a due date later than the
date on which pin_collections_process is run after reinstalling Collections
Manager. This is the default.
3. Save and close the file.
4. Stop and restart the CM.

Understanding Custom Actions

Custom actions are system actions that you create. You define custom actions and
descriptions in Collections Configuration and implement the actions by modifying the
PCM_OP_COLLECTIONS_POL_EXEC_POLICY_ACTION policy opcode.

7-3
 Chapter 7
Increasing the Size of the CM Cache for Actions Data

Increasing the Size of the CM Cache for Actions Data

When defining actions, you might need to increase the space allocated to the action
data in the CM cache.
To increase the CM cache size for actions data:
1. Open the CM configuration file (BRM_home/sys/cm/pin.conf).
2. Increase cache_size in the following entry:

- cm_cache fm_collections_config_actions_cache number_of_entries,

cache_size, hash_size

Note:
The default is 40960 bytes.

3. Save the file.

4. Stop and restart the CM.

7-4
8
Defining Collections Scenarios
This document explains how to set up scenarios in Oracle Communications Billing and
Revenue Management (BRM) Collections Manager.
See also:
• Understanding Collections Manager
• List of Collections Features

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.

8-1
 Chapter 8
Defining Collections Scenarios

The utility takes an XML file as input and creates or updates the /config/collections/
scenario_params object in the BRM database. Collections Configuration 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:
1. Open the BRM_home/sys/data/config/
config_collections_scenario_params.xml file in a text editor.
2. Edit the file, which includes examples and instructions. Table 8-1 describes the
parameters in this file:

Table 8-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">

8-2
 Chapter 8
Defining Collections Scenarios

<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.
3. Save and close the file.
4. Open the BRM_home/apps/load_config/pin.conf file in a text editor.
5. Uncomment the following entry:
- load_config validation_module libLoadValidCollections
LoadValidCollections_init

8-3
 Chapter 8
Defining Collections Scenarios

6. Save and close the file.

7. 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
For more information on the load_config utility, see BRM Developer's
Guide.

8. 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:
1. Open the CM configuration file (BRM_home/sys/cm/pin.conf).
2. 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.

3. Save and close the file.
4. Stop and restart the CM.

8-4
9
Setting Up Collections Profiles
This document describes how to set up collections profiles in Oracle Communications
Billing and Revenue Management (BRM).
Topics in this document:
• Setting Up Collections Profiles
• Increasing the Size of the CM Cache for Profiles Data
See also:
• Understanding Collections Manager
• Setting Up Collections Manager
• List of Collections Features

Setting Up Collections Profiles

Collections profiles define categories into which you organize bill units for collections
purposes. For example, you could organize bill units by credit score. Bill units with a
score below a certain number are assigned to one collections profile, and bill units with
higher scores are assigned to a different profile.
A bill unit's collections profile helps determine to which collections scenario a bill unit
is assigned. (Scenarios define entry and exit criteria for collections as well as what
happens to a bill unit while it is in collections.)
For example, bill units in the low-credit-score profile might be assigned to scenarios
with more aggressive collections actions and lower entry criteria. Customers in the
high-credit-score profile could be assigned to scenarios with more lenient policies.
By default, all bill units belong to a single collections profile. If you do not need a more
complex system, you do not have to define any additional profiles. You can map all
your scenarios to the default profile.
To set up additional profiles, you complete two sets of tasks:
1. Define names and descriptions for the profiles by using Collections Configuration.
When you define a new profile, Collections Configuration creates a /config/
collections/profile object, which stores definitions of collections profiles.
2. Customize the PCM_OP_COLLECTIONS_POL_SELECT_PROFILE policy
opcode. You need to write code that defines the characteristics of the collections
profiles and maps bill units to them.

Note:
This step requires programming.

9-1
 Chapter 9
Increasing the Size of the CM Cache for Profiles Data

Increasing the Size of the CM Cache for Profiles Data

When setting up additional profiles, you might need to increase the space allocated to
the profiles data in the CM cache.
To increase the CM cache size for profiles data:
1. Open the CM configuration file (BRM_home/sys/cm/pin.conf) in a text editor.
2. Increase cache_size in the following entry:

- cm_cache fm_collections_config_profiles_cache number_of_entries,

cache_size, hash_size

Note:
The default is 20480 bytes.

3. Save and close the file.

4. Stop and restart the CM.

9-2
10
Configuring How Collections Manager
Determines Dates
This document describes how to configure dates for Oracle Communications Billing
and Revenue Management (BRM) Collections Manager.
See also:
• Understanding Collections Manager
• Setting Up Collections Manager
• List of Collections Features

Configuring How Collections Manager Determines Dates

You can configure how Collections Manager determines the overdue and entry dates
it uses (described in Table 10-1). For information about how Collections Manager uses
these dates, see "About Overdue and Entry Dates".

Table 10-1 Overdue and Entry Dates

Option Description
Overdue date • (Default) The overdue date is the due date of the latest overdue bill when the bill unit enters
collections. This date is not updated as long as the bill remains in collections.
• The overdue date is the due date of the oldest overdue bill when the bill unit enters
collections, even if the overdue balance from that bill is not sufficient by itself to meet a
scenario's entry criteria.
See "Configuring the Overdue Date" for instructions.
Entry date • (Default) The entry date is the overdue date plus the number of days specified in the entry
criteria of the scenario. This date is updated if the overdue date changes.
• The entry date is the actual date on which a bill unit is processed and enters collections.
This date is not updated as long as the bill unit remains in collections. If Collections
Manager is run at irregular or long intervals with this setting, the entry date can differ
significantly from the overdue date.
See "Configuring the Entry Date" for instructions.

To customize how due dates are set, use the

PCM_OP_COLLECTIONS_POL_CALC_DUE_DATE opcode. See BRM Opcode
Guide.
The following examples illustrate overdue and entry dates based on the four possible
combinations of configuration options. The examples are based on the following
assumptions:
• There is a monthly charge of $15, due on the 15th of the month.
• The collections scenario specifies a minimum overdue balance of $20, at least 10
days late.

10-1
 Chapter 10
Configuring How Collections Manager Determines Dates

• No payments are received in January, February, or March, but a $15 payment is

received before the due date in April.
• Collections Manager runs every day.
• The tables show the overdue and entry dates as of the end of each month.
Case 1: Default Settings for Both Dates
Table 10-2 shows the results of the default setting for both dates. The overdue and
entry dates stay the same as long as the bill unit remains in collections.

Table 10-2 Default Date Example

Option Jan. Feb. Mar. Apr.

Payment received None None None 15.00
Overdue amount 15.00 30.00 45.00 45.00
Overdue date None Feb. 15 Feb. 15 Feb. 15
Entry date None Feb. 25 Feb. 25 Feb. 25

Case 2: Optional Settings for Both Dates

Table 10-3 shows the results of the optional setting for both dates. When the bill unit
enters collections, the overdue date is January 15 even though the overdue balance
for that month was not sufficient by itself to enter the scenario. Also note that the
overdue date changes when a payment eliminates the overdue balance for January.

Table 10-3 Optional Date Example

Option Jan. Feb. Mar. Apr.

Payment received None None None 15.00
Overdue amount 15.00 30.00 45.00 45.00
Overdue date None Jan. 15 Jan. 15 Feb. 15
Entry date None Feb. 25 Feb. 25 Feb. 25

Case 3: Default Setting for Overdue Date and Optional Setting for Entry Date
In Table 10-4, the dates are identical with those for Case 1, but the entry date is
determined by the actual processing date. If the collections process was not run daily,
the entry date would not necessarily be the same as the date determined by the
scenario's entry criteria.

Table 10-4 Processing Date Example

Option Jan. Feb. Mar. Apr.

Payment received None None None 15.00
Overdue amount 15.00 30.00 45.00 45.00
Overdue date None Feb. 15 Feb. 15 Feb. 15
Entry date None Feb. 25 Feb. 25 Feb. 25

Case 4: Optional Setting for Overdue Date and Default Setting for Entry Date

10-2
 Chapter 10
Configuring How Collections Manager Determines Dates

In Table 10-5, the entry date changes when the overdue date is updated to reflect
the payment. This would have the effect of delaying any remaining collections actions
defined in the scenario.

Table 10-5 Varied Date Settings

Option Jan. Feb. Mar. Apr.

Payment received None None None 15.00
Overdue amount 15.00 30.00 45.00 45.00
Overdue date None Jan. 15 Jan. 15 Feb. 15
Entry date None Jan. 25 Jan. 25 Feb. 25

Configuring the Overdue Date

To configure how Collections Manager determines the overdue date:
1. Open the CM configuration file (BRM_home/sys/cm/pin.conf) in a text editor.
2. Change the value of the old_overdue_behavior entry:
• To use the latest overdue bill date, enter 0. This is the default.
• To use the earliest overdue bill date, enter 1.
For example:
- fm_collections old_overdue_behavior 1
3. Save and close the file.
4. Stop and restart the CM.

Configuring the Entry Date

To determine how Collections Manager determines the entry date:
1. Open the pin_collections configuration file (BRM_home/apps/pin_collections/
pin.conf) in a text editor.
2. Change the value of the use_current_time entry:
• To use the entry date, enter 0. This is the default.
• To use the current date, enter 1.
For example:
- pin_collections_process use_current_time 1
3. Save and close the file.

10-3
11
Integrating Collections Manager with
Custom Client Applications
This document describes how to integrate your custom application with Oracle
Communications Billing and Revenue Management (BRM) Collections Manager.
Topics in this document:
• About Integrating Collections Manager with Custom Client Applications
• About Calling the Collections Manager API
• About Notifying Custom Client Applications when Collections Activity Occurs
• Sending Collections Notifications to Custom Client Applications
• Creating CollectionsInfoChange Business Events
See also:
• Understanding Collections Manager
• Setting Up Collections Manager
• List of Collections Features

About Integrating Collections Manager with Custom Client

Applications
To enable a custom client application to manage collections activities:
• Configure BRM to send collections notification events to your custom client
application. See "Sending Collections Notifications to Custom Client Applications".
• Customize your client application to call the Collections FM opcodes. See BRM
Opcode Guide.
• (Application Integration Architecture systems only) Configure the
pin_collections_process utility to publish a CollectionsInfoChange business
event.
See "Creating CollectionsInfoChange Business Events".
Collections Manager can be integrated with a custom client application, such as Siebel
CRM, so customer service representatives (CSRs) can track and manage collections
activities directly in the custom client application.
The custom client application manages collections activity, such as preparing dunning
letters or applying late fees, by calling the Collections Manager API. Collections
Manager notifies the custom client application when a collections activity occurs, such
as an account entering collections, by using the event notification system. Figure 11-1
shows how data is passed.

11-1
 Chapter 11
About Calling the Collections Manager API

Figure 11-1 How Custom Client Applications Communicate with Collections

Manager

To integrate Collections Manager with a custom client application:

• Configure the custom client application to call the Collections Manager API. See
"About Calling the Collections Manager API".
• Configure Collections Manager to notify the custom client application when
collections information changes. See "About Notifying Custom Client Applications
when Collections Activity Occurs".

About Calling the Collections Manager API

CSRs need to perform the following collections tasks in their custom client application:
• Manage the collection of overdue balances
• Retrieve information about collections activities
• Perform manual collections activities
• Prepare dunning letters for customers
To perform these tasks, you must configure your client application to accept the
required information and pass it to the Collections Manager API. You can determine
the information required by looking at the target opcode's input flist. For more
information about calling the Collections Manager API, see "Using the Collections
Manager API" in BRM Opcode Guide.

Note:
You can pass information to the Collections Manager API either directly
from the custom client application or through Oracle Application Integration
Architecture (Oracle AIA). For more information about Oracle AIA, see
"Using BRM with Oracle Application Integration Architecture" in BRM
Developer's Guide.

11-2
 Chapter 11
About Notifying Custom Client Applications when Collections Activity Occurs

About Notifying Custom Client Applications when

Collections Activity Occurs
Collections Manager uses event notification to alert custom client applications when
collections activities occur, such as an account entering collections or a dunning
letter being sent. Collections Manager sends an alert in the form of an /event/audit/
collections/action notification event, which includes information about the collections
action, such as:
• The POID of the /collections_action object
• The action type: manual, custom, or system
• A description of the action
• The action status
To notify custom client applications when collections activity occurs:
• Configure BRM to publish /event/audit/collections/action notification events. See
"Sending Collections Notifications to Custom Client Applications".
• Customize your client application to retrieve notification events from the database
queue.

Sending Collections Notifications to Custom Client

Applications
To configure BRM to send collections notifications:
1. Install the EAI Framework on your system. See "Integrating BRM With Enterprise
Applications" in BRM Developer's Guide.
2. Install the Synchronization Queue DM on your system. See "Installing and
Configuring the Synchronization Queue DM" in BRM Synchronization Queue
Manager.
3. Configure the Synchronization Queue DM to publish the CollectionsAction
business event to the database queue. When configuring the system, make sure
you perform the following:
• Merge the BRM_home/sys/eai_js/payloadconfig_collections.xml file with
your existing EAI payload configuration file.
• Verify that the BRM_home/sys/eai_js/Infranet.properties file points to the
correct EAI payload configuration file. You set the path and file name in the
infranet.eai.configFile entry.
• Merge the BRM_home/sys/data/config/pin_notify_collections file with your
existing BRM_home/sys/data/config/pin_notify file. Load the merged file into
the database by using the load_pin_notify utility.
• Uncomment the CollectionsAction business event in your BRM_home/sys/
dm_aq/aq_queuenames file.
For more information, see "Installing and Configuring the Synchronization Queue
DM" in BRM Synchronization Queue Manager.

11-3
 Chapter 11
Creating CollectionsInfoChange Business Events

4. Start the Synchronization Queue DM. See "Starting and Stopping the
Synchronization Queue DM" in BRM Synchronization Queue Manager.
BRM publishes the CollectionsAction business event to the database queue
whenever an /event/audit/collections/action notification event occurs.

Creating CollectionsInfoChange Business Events

If your custom application connects to BRM through Oracle Application Integration
Architecture (Oracle AIA), the Oracle Advance Queue (AQ) needs to be notified with a
CollectionsInfoChange business event when a collections job has run.
To create a CollectionInfoChange business event:
1. Open the pin_collections_process configuration file (BRM_home/apps/
pin_collections/pin.conf) in a text editor.
2. Add a publish_run details entry and set it to 1:
- pin_collections_process publish_run_details 1
3. Save and close the file.

11-4
12
Collections Manager Utilities
This chapter provides reference information for Oracle Communications Billing and
Revenue Management (BRM) Collections Manager utilities.
Topics in this document:
• pin_collections_process
• pin_collections_send_dunning
• pin_load_template

pin_collections_process
Use this utility to find bill units (/billinfo objects) that are in collections and to trigger
collections actions defined by the bill unit's collections scenario.
You must set a minimum value that this utility uses to determine whether bill units
should be considered for collections. See "Setting the Minimum Overdue Balance to
Process".
This utility is included in the pin_bill_day script. It should be run daily before
"pin_collections_send_dunning". See "Running Billing Scripts" in BRM Configuring and
Running Billing for more information about the billing scripts.

Note:
To connect to the BRM database, pin_collections_process requires a
configuration (pin.conf) file in the directory from which you run the
utility. A configuration file is installed automatically in BRM_home/apps/
pin_collections when you install BRM Collections Manager.

Location
BRM_home/bin

Syntax
pin_collections_process [-billinfo BillInfoPOID] [-debug] [-verbose] [-report]
[-help]

Parameters

-billinfo BillInfoPOID
Triggers collections actions against the specified bill unit. Use this parameter to
perform collections against a single bill unit that belongs to a collections group.

12-1
 Chapter 12
pin_collections_send_dunning

-debug
Sets the log level to debug and outputs debug information into the log file for this
process. If not set, only error-level information is output.

-verbose
Displays progress information.

-report
Shows the summary of this billing run that includes information about how many
account bill units are in collections, how many exited collections, and which system
actions were performed.

-help
Displays the syntax and parameters for this utility.

Results
The collections status of all bill units with overdue balances is evaluated and, if
necessary, updated. For bill units that enter or remain in collections, all actions defined
by the relevant collections scenario are performed.

pin_collections_send_dunning
Use this utility to email or print dunning letters. This application is called by
"pin_collections_process", but it can also be run independently.
The delivery method for bill units that use the invoice payment type is specified in
Billing Care or Customer Center:
• If the delivery method is set to Email, pin_collections_send_dunning emails the
dunning letter.
• If the delivery method is set to Postal, pin_collections_send_dunning prints the
dunning letter.
For noninvoice bill units, you specify the delivery option in the collections configuration
(pin.conf) file. See "Setting Dunning Letter Delivery Preferences for Noninvoice Bill
Units".

Note:
The Email Data Manager must be running when you run this utility, even for
printing. For information, see "Sending Email to Customers Automatically"
in BRM Managing Customers and "Configuring the Email Data Manager for
Printing" in BRM Designing and Generating Invoices.

The data used to create the dunning letter is generated by "pin_collections_process"

and stored in the database. This data is combined with a dunning letter template to
create the final letter.

12-2
 Chapter 12
pin_load_template

Note:
To connect to the BRM database, pin_collections_send_dunning requires
a configuration (pin.conf) file in the directory from which you run the utility. A
configuration file is installed automatically when you install BRM Collections
Manager.

Location
BRM_home/bin

Syntax
pin_collections_send_dunning [-verbose] [-export Path]

Parameters

-verbose
Displays progress information.

-export Path
Exports the generated dunning letters to the directory you specify.

Results
The dunning letters whose data is collected by "pin_collections_process" are prepared
and sent using the delivery method for each bill unit.

pin_load_template
Use this utility to load dunning letter templates into the BRM database as /config/
invoice_templates/dunning objects. These objects contain the XSL templates that
you use to format dunning letters and invoice reminders.
For additional information, see "Loading Dunning Letter Templates".

Note:
To connect to the BRM database, pin_collections_process requires a
configuration (pin.conf) file in the directory from which you run the
utility. A configuration file is installed automatically in BRM_home/apps/
pin_collections when you install BRM Collections Manager.

Location
BRM_home/bin

Syntax
pin_load_template [-brand poid] -name template_name [-type template_type] -
format template_output_format -locale locale_string -template template_file [-
usexsl] [-debug] [-logfile log_file]

12-3
 Chapter 12
pin_load_template

Parameters

-brand poid
Specifies the root account POID for which you are loading the template: 0.0.0.1 /
account 1 must be used.

-name template_name
Specifies the template name. The name is displayed in the Collections Configuration
application.

Note:
If the name contains spaces, use quotation marks.

-type template_type
Specifies the template category. Use dunning for dunning letter templates.

-format template_output_format
Specifies the output format for the dunning letter templates.

-locale locale_string
Specifies the locale string. The default is en_US.

-template template_file
Specifies the template file name and path.

-usexsl
Specifies the use of XSL to format dunning letters. Must be used when loading an
XSL dunning letter template.

-debug
Logs the flist and detailed messages in the log file.

-logfile log_file
Specifies the full path and name of the log file.

Results
Loads the specified file into the BRM database as a /config/invoice_templates/
dunning object.
The utility fails if the specified file or path is invalid.

12-4