Collections Technical Reference
Collections Technical Reference
Collections Technical Reference
EMEA:
+44 (0) 20 8580 0400
Contents
iii
Chordiant Queues .......................................................................................................................... 23
Contact Center ............................................................................................................................... 24
Collections Processing Activities ............................................................................................................. 25
Identify Party ........................................................................................................................ 25
Pay Now ................................................................................................................................ 25
Negotiate Arrangement ......................................................................................................... 25
Cancel Arrangement ............................................................................................................. 25
Change Account Status ......................................................................................................... 26
Change Credit Limit ............................................................................................................. 26
Credit Fees and Charges ....................................................................................................... 26
Manage Collateral ................................................................................................................. 26
Manage Dispute .................................................................................................................... 26
Modify APR .......................................................................................................................... 27
Update Address ..................................................................................................................... 27
Update Contact Details ......................................................................................................... 27
Update Financial Details ....................................................................................................... 28
Update Personal Details ........................................................................................................ 29
Manage Circumstances ......................................................................................................... 29
Send Documentation ............................................................................................................. 30
Re-Assign or Defer Work Item ............................................................................................. 30
Set Follow-up Date ............................................................................................................... 30
Wrap up Case ........................................................................................................................ 30
Manage Customer Alerts ...................................................................................................... 30
Place with Agency ................................................................................................................ 31
Recall From Agency ............................................................................................................. 31
Supervisor Review ................................................................................................................ 31
Questions .............................................................................................................................. 31
Business Process Models .......................................................................................................................... 32
EMC Business Activity History ........................................................................................... 32
Login ..................................................................................................................................... 32
Dialer .................................................................................................................................... 32
Interview Process .................................................................................................................. 32
Data Models .............................................................................................................................................. 32
Contents v
Recall from Agency ............................................................................................................ 169
Wrap-Up Case .................................................................................................................... 172
Supervisor Review .............................................................................................................. 173
Manage Collateral ............................................................................................................... 174
Manage Dispute .................................................................................................................. 176
Supervisor Pages ..................................................................................................................................... 178
View Your Work Tab .................................................................................................................. 179
Supervisor Additional Metrics ............................................................................................ 180
Manage Your Group Tab............................................................................................................. 181
Supervisor Additional Group Metrics ................................................................................ 182
View Users’ (Agents’) Inboxes .......................................................................................... 183
Queue Manager ................................................................................................................... 185
Queue Work Item Listing ................................................................................................... 188
Re-Queue Selected Items .................................................................................................... 189
..................................................................................................................................................... 190
This guide is designed to present users with an overview of Collections Manager, including architectural
details, process flow, and user interface information.
W h o S h o u ld U s e T h is Guide
Business Analysts, systems administrators, developers, and other interested persons will find this
information relevant.
Manual Organization
This document contains the following chapters:
Additional Documentation
For more information on Collections Manager, refer to the following documents:
• Chordiant Collections Manager Installation and Deployment Guide
• Chordiant Collections Manager Decision Logic Gudie
• Chordiant Collections Manager Release Notes
Note: For additional technical information refer to the Javadoc included with your product. The
javadoc directory is in the root directory of the Collections Manager Developers
Supplement CD.
vii
Typographical Conventions
This section explains how to interpret the font changes and notes that you see in this manual.
CONVENTION EXAMPLE
System filenames and pathnames Readme.txt is a text file that is stored on the
application server in the /etc (for UNIX) or C:\ (for
Windows) directory.
Document names and module names See the “Security” section within the Ongoing Tasks
document, or the online help from within the
Security module.
Names of code elements and small pieces of code Use the getInfo method
- or -
Onscreen text and text typed on the keyboard Type the password cmyk.
Screen element labels, including buttons and menus- Click OK. Then from the File menu, select Save.
or -
Keys that you press on the keyboard To save the information on the page, press CTRL +
SHIFT + s.
Variables that you must define based on your own {JAVA_HOME}/com/chordiant/jxw
settings
Note: A note shows important information that you should be sure to read. Many notes refer to
other sections for more information.
Tip: A tip gives suggestions on how you can use the application faster or more efficiently.
Caution: A caution statement warns of steps you should take, or avoid, so you do not damage your
equipment, data, or system reliability.
Product Overview
Collections is the process of negotiating payments or settlements with customers who are late on their
payments, have exceeded their credit limit, or are at risk of defaulting altogether. The goal of a collections
group is to minimize the financial losses to the lending institution by using strategies that can recover the
maximum amount of outstanding debt, retain customers, and keep costs within guidelines.
Chordiant Collections Manager is a powerful and sophisticated application designed for lenders that deal in
customer debt management. This next-generation Collections solution features real-time processing,
decision-driven actions, and a framework that can be customized to accommodate the needs of different
lending institutions.
FEATURES
The key features of Collections Manager are:
• Real Time Processing — to support interactive conversations between the collections user and the
customer, with the goal of negotiating a payment plan or settlement.
• CDM Decisioning — using a customer’s profile, business rules, and Decision logic to determine the
best method of contact, the best course of action to take, and the optimal arrangement for each
individual customer. These actions are all performed in real-time.
• Inbound/Outbound Contact Center — for real-time interaction between a user and the customer to reach
a mutually agreeable solution to debt collection.
• Customizable — for lending institutions with different policies, procedures, and business rules.
• Case Management — as a way to manage a wide range of case-related information within the lending
institution.
• Multi-Product Framework — to support debt management for multiple types of accounts such as:
unsecured credit cards, utility debts (i.e., water, electric) and secured debts (i.e., auto loans).
• Manage Dispute — to indicate when an invoice/statement is under dispute, including a reason for
disputing the invoice/statement.
These features are discussed in greater detail in the rest of this chapter.
1
Features
The following diagram presents an overview of the Collections Manager process. For a more detailed
explanation, refer to Chapter 2, Architecture and Chapter 3, Process Flows.
R e a l Ti m e P r o c e s s i n g
Many Collections applications run in a bulk process on a host system, often at night. Collections Manager is
a real-time application that does not change mode, or need to be shut down at any time.
Lending institutions run queries against their system of record to identify accounts that are delinquent or
have exceeded their credit limit. Collections Manager then takes these query results as its input, and
transforms them into a format that can be used in real-time to determine a collections contact strategy across
any or all channels. This interactive processing continues in the Contact Center.
Using the results of Decision logic processing, the system guides the collections user through a conversation
with the customer, and presents various payment, settlement, or fee adjustment options designed to
maximize debt recovery in the shortest amount of time and minimize the loss to the lending institution while
still appropriately managing the customer relationship.
CDM Decisioning
Decisioning is the core of Collections Manager processing, and is provided by the embedded Chordiant
Decision Management (CDM) software. Decisioning is a process that uses information about the customer,
account, and case and business rules to determine what action to take or what arrangements to propose. The
real-time, interactive processing used in Collections Manager is managed by Decisioning. For example:
• Segmentation of accounts into manageable groups of customers with common attributes.
• Development of contact strategies for dealing with different segments including best time and methods
of contact.
• Next recommended action to take while in conversation with the customer.
• Scripting, to guide the user through the conversations with the customer, including offer scripts and
wrap-up scripts.
• Determining dynamic repayment offers, based on a customer’s profile and the goals of the lending
institution.
• Validating payment arrangements made with a customer to ensure they fall within the lending
institution’s guidelines.
• Ongoing monitoring of arrangements made with the customer to ensure terms of the arrangement are
fulfilled.
I n b o u n d / O u t b o u n d C o n ta c t C e n t e r
The Contact Center is where collections users interact with customers over the telephone. Work enters the
Contact Center either through inbound/outbound telephone calls or Chordiant work queues. While the user
is speaking to the customer, Decision logic is constantly determining a next best action.
Actions that take place during the conversation with the customer include:
• A dynamic interview process, where Decision logic displays questions and recommended actions on the
user’s screen.
• Real time generation and validation of offers by Decision logic, based on business rules and customer
profiles.
Information is collected throughout the entire interview process, which is constantly assessed and evaluated
by Decision logic. In addition, demographic and circumstance information is captured, updated, validated,
and recorded on the system by the user.
Customizable
Out of the box, Collections Manager includes business process templates and a standard user interface, both
of which can be reconfigured by the customer to meet their requirements. Institutions can modify the user
interface, integrate with other processes, and configure Decision logic to use their own business rules. For
additional customization information, refer to Chapter 5, Customizing Collections Manager.
Case Management
Chordiant Enterprise Case Management (ECM) provides a single, centralized repository for all historical
information across an organization. A case is created each time a customer enters the Collections system,
and is used to track a variety of information. For example:
• All work and the state that it is in (started, in progress, completed).
• Customer information — name, address, telephone numbers and financial information.
• Account information — account number, financial details, and state.
• Details about any arrangements in place — payment schedules and amounts.
The information managed by ECM is used by Collections Manager services such as Decisioning and
Chordiant work queues.
M U L T I -P R O D U C T F R A M E W O RK
Chordiant Collections Manager 3.1 framework is multi-product aware. Multi-product aware means that the
application:
• Displays different tabs for different product types, i.e. displays a Collateral Details tab for secured debt
(auto loans) but not for unsecured debt (credit cards).
• Displays different data on each tab depending on product type, i.e. displays a different summary tab for
a credit card debt and an auto loan as compared to the utility debt.
• Displays a different list in the “Other Activities” menu items based on product type, i.e. displays a
Credit Limit activity for credit card debt but not for an auto loan.
• Enables individual process area activities to be "aware" of product type and behave differently, i.e.
different components would be available in Negotiate Arrangement for a credit card debt than an auto
loan and different special circumstances would be available for a credit card debt versus an auto loan.
• Multi-product CDM strategies.
For the purposes of R3.1, Chordiant Collections Manager 3.1 supports three product types:
• Unsecured Debt (i.e. Credit Cards)
• Secured Debt (i.e. Auto Loans)
• Utility Debt (i.e. Water, Electricity, Municipal Taxes, Mobile Phones)
Note: This functionality is configurable by a client. The customer can define their types and
indicate how the application should behave for each type.
Architecture
This chapter describes the components and architecture of Chordiant Collections Manager.
E N VI R O N M E N T
Collections Manager runs on Sun Solaris and IBM AIX platforms. It is built with J2EE components, making
it robust, stable, and scalable. Tried and proven Chordiant applications provide the technology for many
features. The following software is used in Collections Manager:
• Chordiant Decision Management (CDM)
— Chordiant Strategy Director
— Chordiant Decision Planner
— Chordiant Decisioning Server
— Chordiant Deployment Manager
— Chordiant Decision Monitor (optional)
• Chordiant Foundation Server
— Interaction Controller
• Chordiant Faces Framework
• Chordiant Call Center Advisor - Browser Edition (CCABE)
• Oracle
• Oracle Data Integrator (ODI)
Note: Oracle Data Integrator is used only as a reference implementation. Any ELT tool can be
used to load data into the application.
Refer to the Chordiant Collections Manager Installation and Deployment Guide for specific versions of
software referenced above.
7
Overview
OVERVIEW
The following diagram shows the major components and processes used by Collections Manager. Details
about these are provided in the sections that follow. For a description of the process flow between
components, refer to Chapter 3, Process Flows.
D ATA P R O C E S S I N G
The Collections Manager product begins with the staging tables (see Figure 2-1). It is the responsibility of
the lending institution to output data from their host system into these tables. Oracle Data Integrator (ODI)
then transforms the data into a format that can be processed by Collections Manager services.
Note: Oracle Data Integrator is used only as a reference implementation therefore; any ETL
application can be used to perform the task of extracting, transforming and loading data.
Bulk Processing
Typically, a lending institution runs queries against the host system overnight, in a bulk processing session.
Accounts that are delinquent or over their credit limit are flagged for processing. Records can also be
preemptively flagged in cases where a customer’s credit score goes down or the lending institution learns of
an impending bankruptcy.
O r a c l e D a ta I n t e g r a t o r ( O D I )
Oracle Data Integrator is a data integration tool that reads the staging tables populated by the host system,
and transforms the data into a real-time schema that can be used by Collections Manager. Unlike other data
integration tools, it runs inside the database instead of on a separate server. ODI performs the following
actions:
• Creates a new case, if required
• Adds a party relationship, if required
• Validates all accounts
• Reconciles old accounts
• Matches information to correct accounts
Note: Oracle Data Integrator is used only as a reference implementation; therefore, any ETL
application can be used to perform the task of extracting, transforming and loading data.
Chapter 2: Architecture 9
Application Servers
R e a l Ti m e P r o c e s s i n g
After transformed data is introduced into the Collections system, it is tracked, assessed, acted upon by users,
and reassessed. This cycle continues until the case is “cured” or otherwise closed.
Much of the real-time, interactive processing used in Collections Manager is driven by Chordiant Decision
Management (CDM) software. Some of the tasks CDM performs are:
• Segmenting accounts into categories that meet predefined criteria.
• Determining the best method of contacting a customer.
• Determining suitable courses of action.
• Periodically re-assessing the state of the case.
For more details about the role of CDM and Decision logic, refer to Chordiant Decision Management.
JMS
The Java Message Service (JMS) is a standard that provides reliable, asynchronous messaging for
Collections Manager. JMS queues carry information about the action to perform — reassess, or monitor
arrangement and then reassess — to a cluster of Application severs running Collections Manager services.
A P P L I C AT I O N S ER VERS
Collections Manager is installed on one or more Application servers that host Collections services. Data is
processed in a interactive, real-time mode of operation.
Collections Manager runs on either WebSphere or WebLogic. To scale a configuration to handle additional
throughput, more Application servers can be added to the server cluster. Collections Manager balances work
between the servers, ensuring efficient processing.
Refer to the Collections Manager Technical Stack for specific configurations and Application Server
software versions.
Business rules help to determine a best course of action. Outputs are used by the system to initiate the action
that has been decided upon. After Decision logic is created, it is made available to Collections Manager
through the CDM Deployment Manager application.
Note: All logic is customizable, details about each piece are determined by how it will be used.
For a more comprehensive discussion about the CDM applications, refer to the CDM documentation set. For
more information about how Decisioning is used by Collections Manager, refer to the Decision Logic
Reports which accompany the Decision logic files. For example, the RetrieveOffers.html report describes
the Retrieve Offers Logic.
Chapter 2: Architecture 11
Chordiant Decision Management
The following diagram shows the types of Decision logic used by Collections Manager. These modules —
Monitor Arrangement, Assess Case, Next Best Contact, Retrieve Offers (sometimes referred to as Dynamic
Offers) , Offer Validation, and Next Best Action are described in the sections that follow.
Monitor Arrangement
Monitor Arrangement Logic is responsible for the following activities:
• Determining Promise to Pay (PTP) statuses.
• Determining the overall arrangement status based on the number of PTPs and their individual statuses.
• Monitoring all types of arrangements such as:
— Payment Plans
— Settlements
Monitor Arrangement Logic uses the Risk Score, number of Cycles Past Due and the Arrangement Amount
to determine the appropriate Tolerance Percentage. The appropriate Tolerance Percentage is then compared
to the Arrangement Percent Paid. This comparison makes the following decision:
IF... THEN...
the PTP Percent Paid is >= The the PTP is considered Kept
Tolerance Percentage
the PTP Percent Paid is < the the PTP is considered Not Kept and
Tolerance Percentage additional decisioning is needed.
Note: The Tolerance Percentage is the minimum percentage of the promised amount that must
be paid in order for the promise to be considered kept. When all PTPs are kept an
arrangement is considered kept.
Chapter 2: Architecture 13
Chordiant Decision Management
Assess Case
Assess Case logic is responsible for these activities:
• Determining when a Case should be closed or charged off.
• Setting a number of indicators and flags such as:
— First Payment default flag
— Skip Trace indicator
• Reconciling case data to determine the next high level status or composite status. This reconciliation is
accomplished by:
— Initially assessing new Cases.
— Re-assigning Cases after each work activity.
— Re-assigning Cases after new information is provided from the Host or other system.
— Controlling the life-cycles of special circumstances by updating special circumstance statuses.
The assess case OXL is comprised of the following ten smml files or sub-packages:
• assessCase.smml
• specialCircumstance.smml
• Bankruptcy Life Cycle.smml
• CCCS Life Cycle.smml
• Deceased Life Cycle.smml
• Fraud Life Cycle.smml
• HealthMatter Life Cycle.smml
• Incarceration Life Cycle.smml
• Military Service Life Cycle.smml
• NaturalDisaster Life Cycle.smml
The assessCase.smml is the main sub-package of the assessCase.oxl. The assessCase.smml is the smml file
that is used when generating the assessCase.oxl.
The specialCircumstance.smml and all the .smml files that end in “Life Cycle” contain the special
circumstance life cycle logic and are included in the assessCase.oxl when it is generated.
Note: The current CDM logic report functionality only generates a logic report on the smml file
that is open. In order to generate a complete logic report for Assess Case all smml files
need to be merged.
N e x t B e s t C o n ta c t
Next Best Contact (NBC) logic segments customer cases and executes contact strategies for those cases.
Contact strategies may result in the creation of one or more business steps (work items).
Note: Business steps will not be produced when an account is re-decisioned between steps of the
same strategy.
Chapter 2: Architecture 15
Chordiant Decision Management
Segmenta tion
Segmentation is a process that divides a list of customers into segments (or categories), based on predefined
criteria. The members of a segment have certain attributes in common, such as having similar risk profiles.
CDM uses this criteria when making decisions, which can result in different treatments for different
segments. For example, the contact method and tone used with a segment of customers who have never
missed a payment before will be different than with a segment that frequently misses payments. Some
examples of segmentation criteria used are:
• Type of card a customer holds — Visa, MasterCard, American Express, or Discover.
• Risk of defaulting.
• Balance of account.
• How long the customer has been an account holder.
Contact Strategy
Contact strategy involves choosing the most appropriate way to communicate with a customer. In making
this decision, CDM looks at different segments and determines which strategy would be best for achieving a
certain outcome — such as securing a payment or finding the most cost effective way to establish contact.
The best strategy is determined by specific customer attributes and by the lending institution’s business
rules.
The same contact strategy can be executed against different cases or against multiple segments.
Additionally, a contact strategy can be run against the same segment several times.
Does the existing This question is asked This matching is If an existing business step
business step to ensure that accomplished by matches a new business
match any of the duplicate business comparing the following step from the logic, the new
new business steps are not created business step attributes: business step is discarded.
steps output from in the system. • externalRefID If an existing business step
the logic? • externalContext does not match a new
business step from the
• queueLocation
logic, the next question is
• dueDate asked.
• subprocessName
Have new This question is asked This comparison will If an existing business step
business steps to determine if next check if the subprocess subprocess name matches
been created in a best contact is creating name of an existing a subprocess name of a
strategy for which new business steps for business step matches new business step from the
there are existing a strategy that already the subprocess names of logic, the existing business
business steps in has existing business any of the new business step is discarded (assuming
the system? steps. The assumption steps output by the logic. the answer to Q1 was no)
is made that if the If an existing business step
business steps that are subprocess name does not
created are in the match a subprocess name
same strategy but do of a new business step from
not match any existing the logic, the next check is
business steps the old performed.
/ existing business
steps should be
discarded and replaced
with the new business
steps.
Has the logic This question is asked This comparison will If an existing business step
output a strategy to determine the check if the subprocess subprocess name matches
ID in its list of validity of the existing name of an existing a strategyID from the logic,
strategyIDs that business steps. The business step matches the existing business step is
matches the assumption is made any of the strategyIDs kept. (assuming the
strategy ID of an that if no new business output from NBC. answers to Q1 and Q2 were
existing business steps are created for a No)
step? valid strategy (as If an existing business step
denoted by the subprocess name does not
strategyIDs output match a strategyID from
from the logic) the the logic, the existing
existing business steps business step is discarded.
for that strategy (See open questions)
should be kept.
Chapter 2: Architecture 17
Chordiant Decision Management
Note: If the cancel flag of a business step be set to No / False, none of the rules above will apply
as that business step can never be discarded.
Retrieve Offers
The Retrieve Offers logic is responsible for two activities:
• Dynamically determining the best five predefined offers to present to a customer.
Note: The number of predefined offers is customizable to meet your business needs. The system
default is set to present up to five offers.
Note: Each arrangement must include either a payment plan or a settlement to be considered a
valid arrangement.
O f f e r Va l i d a t i o n
Offer Validation logic is responsible for:
• Validating offers at the component level.
• Validating combinations of components.
• Collecting validation failures – including reason codes and reason descriptions.
• Determining whether the offer becomes an accepted arrangement or is available for supervisor review.
• Passing through the offer details.
Chapter 2: Architecture 19
ECM Case Service
E C M C A S E S ERVIC E
ECM Case Service uses Chordiant’s Enterprise Case Management (ECM) component to track details about
accounts that were processed, business steps run, and history about actions that took place during the
Collections cycle. The information managed by ECM is also used by Collections Manager services such as
Decisioning and Chordiant work queues.
Collections Manager interacts with ECM through a specialized “personality” layer. This layer extends the
generic types of information managed by ECM to include detailed information required by Collections
Manager. Calls to ECM by Collections Manager are made through the personality layer, using ECM API
methods.
A Case is created each time a customer enters the Collections system. ECM Cases hold generic information
such as:
• Case Type
• Case number
• Open/close dates
• Status code
Through the Collections Manager personality layer, ECM Cases are customized to hold additional,
Collections-specific information, such as:
• Past due amount
• Date of last payment
• Account balance
• Payment due date
The following figure shows the relationship between ECM and with Collections Manager.
In addition to creating and tracking cases, Collections Manager uses ECM to manage:
• All work and the state that it is in — started, in progress, completed.
• History, such as arrangements, fee adjustments, and special circumstances.
Chapter 2: Architecture 21
ECM Case Service
Each activity or business service is responsible for recording its own history. Recording history for
Collections Manager involves calling the Enterprise Case Management (ECM) API for
createBusinessActivityHistory(). In addition to creating the actual ECMBusinessActivityHistory Object ,
this API requires a contactID (from an ECMContact) and a caseId (from the ECMCase). If history is created
from a JSF backing bean on the client both IDs are available from the CollectionsBackingBeanImpl (using
#{collectionsBackingBean.contactId} and #{collectionsBackingBean.ecmCase.id}). If history is created
within a business service these IDs are generally passed in as input to the service API.
Note: If the service is a back-end-only process, then the service should have created an
ECMContact for itself which can be used for recording history.
As a preferred pattern, most of the history recorded in Collections Manager is done within the business
service in an effort to create a more robust set of services (as opposed to trusting the client to record the
history on return from the service).
When populating the startTime and endTime properties of the ECMBusinessActivityHistory Object, you are
free to put in different Date values as long as the endTime is chronologically after the startTime. For the
OOTB application, ECMBusinessActivityHistory records information for a particular point in time and sets
both the startTime and endTime to the same Date value.
B u s i n e s s St e ps Ta b l e
The Business Steps table is part of ECM. It holds and tracks all of the work in an organization, and the state
that business steps are currently in.
After being processed against the business steps in ECM, work is handled in one of several ways, described
in this section.
Send Letter
A letter, such as a reminder that payment is overdue, is prepared and sent to the customer.
Wai t
The wait business step is used in two situations:
1. A standard wait period — the case waits for the prescribed period of time before it is sent to the Assess
Case logic for decisioning.
2. A wait period that is part of an arrangement — an assessment date is written to the case, which is a
trigger for the case to be sent to Monitor Arrangement logic and then Assess Case logic for processing.
Chordiant Queues
A Chordiant queue (not to be confused with other queues, such as a JMS queue) is a named object that
contains work items (pieces of work) being routed to users for processing. Queues are created by the
Collections system, which also balances the work load by distributing work items between queues.
Queue Properties can be set that enable the system to group queue items based on predefined criteria.
Properties can also determine to which queues work is assigned and how work items are routed.
Queue Item (work item) attributes are typed descriptors of Queue Items and are used as search criteria in
browsing queue items. Queue Item attributes also contain basic data about the Queue Item such as creation
date and priority that can be used by Collections Manager.
Chapter 2: Architecture 23
ECM Case Service
C o n ta c t C e n t e r
The Contact Center is where users interact with customers over the telephone. Work enters the Contact
Center either through telephone calls or Chordiant work queues.
Outbound calls can be initiated manually or by the Dialer service. For manual outbound calls, the user
retrieves a case from the queue and dials the customer’s phone number. The Dialer Service initiates an
outbound call by dialing a number. If a person — instead of an answering machine — picks up the call, the
dialer service routes the call to a user.
Inbound calls are received from customers who call to discuss their account. For example, a customer who
wants to negotiate a settlement, or change the terms of their account.
Note: Several of the following activities are initiated by Decision logic which decides
which activity to present to the user based on business rules and customer
information. Regardless of what the Decision logic presents, the user can perform
actions manually by selecting the activity from the Other Activities menu. The availability
of activities is driven by user role; therefore, some activites may not be present in the
Other Activites menu for all users.
Id entify P arty
Allows the user to identify the party to whom they are speaking.
Pay Now
A manual process that enables a user to accept a one-time payment on a delinquent or over limit account.
Negotiate Arrangement
Displays appropriate arrangements (or offers) that the Retrieve Offers Decision logic generated for the
customer. The user presents each offer to the customer, who can accept, reject, or make a counter offer.
If the customer accepts an offer, the user records the appropriate information and wraps up the call.
If the customer rejects all of the recommended offers, the user can manually build a new offer, and then
submit it for supervisor approval if it falls outside predetermined guidelines.
If the customer proposes an alternative arrangement, the user records the details, and the case is sent to the
Offer Validation logic.
Cancel Arrangement
Enables a user to cancel an active or pending arrangement. When canceling an arrangement a user can select
the cancel reason and view the most recent arrangement information.
Chapter 2: Architecture 25
Collections Processing Activities
Manage Dispute
Manage Dispute is an activity that enables a user to indicate that an invoice/statement is being disputed by a
customer. The user is allowed to capture the following information for a dispute:
• Dispute Reason
• Dispute Amount
Mod ify A PR
Enables a user to manually change, freeze, or suspend the Annual Percentage Rate for an account.
Update Address
Enables the user to edit the following address information for a customer:
• Preferred Address
• Contact Preference
• Primary Address
• Secondary Address
The requested changes are passed to the host account system through the output staging table.
Chapter 2: Architecture 27
Collections Processing Activities
Note: Income and expenditure information can be configured to suit business needs.
Chapter 2: Architecture 29
Collections Processing Activities
Send Documentation
Enables a user to send a selected document to a designated party. A user can choose any delivery method if
more than one is available.
S e t F o llo w-u p D a te
Enables a user to specify a date on which to follow-up on the case (the case as a whole, not an individual
work item). The date must be today's date or a date in the future in the format Mon-DD-YYYY (for
example, Feb-12-2008) or can be chosen from the calendar icon.
Wr ap up Case
Enables a user to wrap up the current call by summarizing what actions the user completed during the call.
The user can add a disposition of the call such as "Left Message" or "Disconnected" to be recorded with the
case before closing it. The disposition code is used by Decision logic to determine if the work item for the
case should remain open because of the case requires additional work or if the work item should close.
The list of available disposition codes presented to the user and the default disposition codes selected are
both controllable through the Next Best Action Decision logic. The state of the work item (or business step)
after a disposition code is submitted and is controlled through the Next Best Contact Decision logic.
Note: The following activities are part of the Next Best Action Decision logic which determines
the activities presented to the user. These activities cannot be launched manually
from the Other Activities menu.
Supervisor Review
A process by which a supervisor can review an offer and then either accept or reject it. The Supervisor
review activity can be launched manually by a supervisor or recommended as a Next Best Action when a
supervisor opens a queue item from the Supervisor Review Queue.
Questions
Next Best Action displays question sets for the user to ask the customer, for example:
• What is your reason for delinquency?
• What is your reason for the broken arrangement?
• Have you sent your payment?
• Are you in a Special Circumstance?
• Have you received your statement?
• Can you make a payment today?
The user captures the customer’s response, which is evaluated by Decision logic and used to determine the
Next Best Action. The Questions activity launches only when Next Best Action Decision logic determines
that answers to the questions are needed before another activity can be recommended.
Note: In addition to being used by Next Best Action, individual questions can be configured to
launch manually from the Other Activities Menu. The Reason for Delinquency question
is an example of an activity configured in such a way.
Chapter 2: Architecture 31
Business Process Models
B U S I N E S S P ROCESS M O DEL S
Collections Manager uses the following business process models.
L o g in
Access to Collections Manager is controlled by log in and authentication. The system Administrator assigns
users to groups and roles with certain rights. For example, a user who logs on as a member of the Supervisor
group will be able to see statistical information and access screens that members of the agent group can not.
Diale r
The Dialer Service automatically initiates an outbound call by dialing a customer’s telephone number. If the
line is disconnected, there is no answer, or an answering machine comes on, the call is terminated. If a
person answers, the line is routed to a user.
In terview Proces s
CDM presents a list of questions and recommended activities for the user to preform while speaking to a
customer. As the user records the answers and completes or skips actions, CDM determines the Next Best
Action. Depending on business rules and details about the customer, CDM can generate an offer to present
to the customer, and then validate any changes to that offer.
D ATA M O D E L S
Several Data models provide very detailed information about Collections Manager. These are located on the
Collections Manager Installation CD as well as on the Chordiant Mesh.
• Class Model — (or Object model) a UML model of java classes. These are in both Rational Rose and
DB Visual Architect formats.
• Data Model — the design of the database tables in a database design tool such as Erwin. This is also
known as an Entity Relationship Diagram (ERD).
• Data Dictionary — the document that contains all the information pertaining to the Data Model. This
includes comments for tables and columns, list of columns, column sizes, indexes, constraints, and
defaults.
Process Flows
This chapter provides the following diagrams that illustrate how a case and/or its associated business steps
move between different services in Collections Manager:
• Process Overview
• Contact Center
• Business Steps
Collections Manager is a case-based system. As a case moves through the system, Enterprise Case
Management (ECM) tracks details about actions that occur, decisions that are made, business steps that are
created, and information that is added to the case.
The Collections Manager user interface is completely Decision driven. There is no fixed path through the
system because it varies with the results of real-time Decision processing. As actions are taken or
information is added to the case, the case is reassessed, and another action is recommended by Decision
logic. This is an iterative process that continues until the case can be closed.
33
Process Overview
P R O C E SS O V E R V I E W
The following diagram shows the general flow of a case through the Collections system.
Process Flow
1. A lending institution runs queries against its host system to produce a list of accounts that are
delinquent, or that have exceeded their credit limit. These results are read into database staging tables.
2. Collections Manager processing begins when Oracle Data Integrator (ODI) extracts and transforms the
data from the staging tables into a real-time database schema. Some of the actions performed by ODI
are validating accounts, checking for arrangements, and creating a new case, if necessary.
Note: ODI is used as a reference implementation in Collections Manager; however, any ETL
application can be used to perform the task of extracting, transforming and loading data.
3. Information from the real-time staging tables is added to a case and a wait step is created. This is the
signal for the system to evaluate the case.
4. The IDs of cases that need to be reassessed are periodically (this interval is set through configuration)
loaded into a Java Messaging System (JMS) queue and delivered to the cluster of Application servers
running Collections Manager. The messages are distributed between the servers by the Application
server. This allows messages to be processed in parallel across the cluster.
5. A case is processed by Assess Case logic and Next Best Contact (NBC) logic, and any resulting work is
sent to the ECM business steps table.
6. The ECM tables provide a staging area where each business step is fulfilled according to its type. For
example, if a warning letter is going to be sent to a customer, the output tables prepare the files that are
sent to the print service. If the case is routed to the contact center, the output staging tables hold data that
is passed to the dialer or queuing subsystems.
7. In the scenario where a case is routed to the contact center, it is processed by several Decision logic
modules — Next Best Action (NBA), Retrieve Offers, and Offer Validation. Refer to Contact Center for
more detailed information about the processing that occurs in the contact center.
8. The Agent or system performs the suggested action(s) such as Negotiate Arrangement, Modify Fees, or
Capture Special Circumstances. Refer to Next Best Action for other actions.
9. After being processed, additional information is added to a case so the case needs to be reassessed by
the Assess Case logic. If no more processing is required, the case is closed. Otherwise, it is sent to Next
Best Contact logic where other work in the form of business steps will be generated.
C ONTACT C E N T E R
The Contact Center is a location where Agents interact with customers over the telephone. Cases enter the
Contact Center either through telephone calls or Chordiant work queues. When a case is accessed by an
Agent, CDM evaluates the case and recommends an appropriate course of action. After that action is
performed, and the Agent adds more information to the case, it is reevaluated, factoring in any new
information. This cycle continues until the case interaction ends.
The following diagram shows the general flow of a case through the Contact Center.
Process Flow
1. Work enters the Contact Center either through outbound telephone calls, inbound calls, or work queues.
When a case is accessed, it is is evaluated by Decision logic, and a Next Best Action is determined in
real-time while the Agent is speaking with the customer.
2. The appropriate processing for the selected Next Best Action is initiated. Actions such as Negotiate
Arrangement, Modify Fees, or Capture Special Circumstances can be recommended. Refer to Next Best
Action for other actions.
3. The information captured from actions are sent back to Assess Case and Next Best Action logic to be
re-evaluated.
4. The example process flow in Figure 3-2 shows Negotiate Arrangement as the Next Best Action. A
screen displays one or more offers to the Agent, which the Agent then presents to the customer. The
customer can accept, reject, or make a counter proposal to the offers.
a. If the customer accepts an offer, the case is sent to Assess Case, where Decision logic
determines what status should be sent, and then to Next Best Action to determine what
additional action is required.
b. If the customer makes a counter offer, the case is sent to Offer Validation logic. If the customer
refuses all of the offers, it goes to Assess Case.
c. If a customer makes a counter offer that outside of the guidelines, validation includes queuing
the business step for Supervisor review at a later time. Once a case is queued for Supervisor
review, the Assess Case and NBA logic determine what additional, if any, action is required by
the Agent.
B U S I N E S S S T E PS
The following diagram shows the flow of Business steps (also referred to as work items) through the
Collections system. Business steps are managed by the Enterprise Case Management (ECM) application.
Process Flow
1. The system creates BusinessSteps in the ECMBusinessStep table (ECM schema). This creation can
happen by running the Wrap Up Case activity through the UI , by having a business step expire, or
having them injected during a bulk load process from the stage_in tables.
2. The MV_WAIT_STEP view (Collections schema) is populated with all expired BusinessSteps. The
criteria for an expired BusinessStep is one with a statusCode of PLANNED, OPENED, or REASSESS
and a dueDate of <= NOW.
3. On a regular interval (configured in ECM_CustomObject.xml, default of +1m), the
ECMWaitStepClientAgent.processExpiredWaitSteps() API is called. This API queries the
MV_WAIT_STEP table and creates a JMS message to be queued for each expired BusinessStep.
Note: The BusinessStep is NOT fully processed at this point. The purpose of this API is to create
a JMS messages for each expired BusinessStep to help with load balancing.
4. When a server is available to receive a message, a BusinessStep is taken from the queue to be worked
on. At this point, the ECMWaitStepWorkerClientAgent.waitStepExpired() API is called. This API will
fetch the BusinessStep in question (using the ID supplied with the JMS message) and begin processing
it.
5. A lock is placed on the BusinessStep’s parent Case. This is done to ensure that the Case is assessed only
once should there be multiple expired BusinessSteps in the queue for the same Case.
6. One of two things can happen when attempting to lock the Case:
a. The lock cannot be acquired. This indicates that another expired BusinessStep has already
locked the Case and is working on it. In this scenario, the system simply stops processing this
BusinessStep since it is no longer necessary.
b. A lock is acquired. The statusCode of this BusinessStep is set to CLOSED.
7. The businessStepType property of the BusinessStep is checked.
8. A businessStepType of WAIT_ARRANGE indicates that this BusinessStep is associated with a
FinancialTransaction. In this scenario, the Monitor Arrangement service is called to gather the latest
information on the active Arrangement and all of its payment components.
9. The Case is assessed.
10. The Next Best Contact is determined. This may result in more BusinessSteps being created in the
system. This is also where any QueueItems or Stage_Out data is created for a particular BusinessStep (if
necessary).
This chapter provides a detailed overview of the Collections Manager User Interface (UI). Collections
Manager has two main work windows:
• User’s Homepage — This is the first page the user (agent) encounters after they log in and is their home
base.
• Collections View — This is the page used for working collections cases.
U S E R ’ S H O M EPA G E
The Homepage displays (Figure 4-1) when the user (agent) or supervisor logs into Collections Manager. The
following areas on the Homepage provide additional information:
• View User Additional Metrics link — Statistical information and user’s performance.
• Inbox Details — List of work items in a user’s personal inbox.
Note: Inboxes are controlled by role. Users who do not have access to them will not see inboxes
on their homepage.
Note: The user can also access the Homepage from the Tools menu.
The Supervisor also has a Homepage that looks very similar to the user’s (agent’s). See section Supervisor
Pages for more information about the Supervisor’s Homepage, activities, and setting up user permissions.
41
User’s Homepage
File Names:
• homepage.jspx • queues.jspx
• metrics.jspx • viewyourworkdetails.jspx
• metricown.jspx
The supervisor has additional metrics that are described in section View Your Work Tab.
File Name:
• monthlymetrics.jspx
Note: Adobe has discontinued support of the plug-in needed to render SVG charts in Internet
Explorer, so these charts have been removed from version 3.0. The architecture is
designed to support alternative charting plug-ins should that requirement exist.
If a user, group, or role has not been set up to have an inbox, that area of the homepage does not display.
Permissions are set up by the supervisor (see Supervisor Pages) or the system Administrator (see the
Chordiant Tools Platform Administration Manager Guide).
Queue Summary
The Queue Summary area of the Homepage (Figure 4-1) shows the following information for each listed
queue:
• Queue Name — A descriptive name for the queue
• Total balance — The total monetary value of all work items in the queue
• Number of Work Items — The number of work items remaining to be completed in the queue
To select a queue, the user clicks the radio button for that Queue in the Select column. The buttons allow the
user to:
• Get Next Queue Item opens the next case in the queue to be worked.
• View Queue Items that displays a list of the queue items. For example, Figure 4-4 shows the Broken
Promise queue work items.
File Name:
• viewworkitems.jspx
When there are several items in a queue, it can be useful to use the Filter link to selectively filter the criteria.
Figure 4-5 shows a sample of the criteria the user can filter on. The criteria can also be sorted by ascending
or descending order.
Note: The ability to filter is determined by the user’s role. The Collections software initially
comes with filtering enabled for the manager, supervisor, and agent; however, the trainee
role will not be able to filter.
When the user provides the criteria and then clicks the Apply Filters button, the queue window is refreshed
with the appropriate queue items.
Note: If the user logs out, the filter will need to be re-created.
If accounts have been worked on, the user should click the Refresh button (see Figure 4-4) to ensure that the
most up to date filtering criteria displays.
This screen allows the user to enter criteria and perform a search on existing accounts. The user can enter
partial information; special characters will be ignored. For example, if the user enters the dashes in the
phone number, the dashes will be ignored.
File Name:
• searchforcasejsf.jspx
Note: All searches are "starts with" searches and will return results that begin with the entered
characters.
Only a maximum of 20 (this value can be configured to be a different number) results are displayed; the
query will stop when it reaches this threshold to limit the number of results retrieved to improve
performance. If the account is not found within the 20 results, the user must provide additional information
in order to narrow the search.
Note: Since searching for a customer with a short last name will usually exceed the threshold,
the user will usually need to enter some other criteria, such as a first name.
From the search results, the user can select an account by clicking the appropriate radio button and then
clicking the Open Account button.
If the user already knows the account number, that number can be entered in the Enter Account Number box
next to the Search button in the upper right corner of the Collection View screen as shown in Figure 4-9.
Vi e w R e c e n t l y Wo r k e d A c c o u n ts
The View Recently Worked Accounts link allows the user to view a list of the accounts they most recently
worked on so they can go back into an account to do more work or add a note.
The Recently Worked Accounts screen (Figure 4-8) is accessed from either:
• The “View recently worked accounts” link on the Homepage (Figure 4-1)
• The Customers menu on the dark blue toolbar (Figure 4-6)
This screen lists the last 15 accounts (this number is configurable) that the user worked on in descending
order from most recent account worked to least recent account worked (determined by the date and time
opened). An account is considered “worked on”even if the user just opened and then closed it. If an account is
accessed multiple times during a session, only the most current will display in the list.
Note: If the user logs out, and logs back in (thereby closing the Collections application session),
the contents of the list are cleared.
To view a recently worked account, select the radio button next to the Customer Name and click the Open
Account button. This list can be sorted by clicking the appropriate column heading.
When an account is opened to be worked on, it is removed from the list. When work is completed that
account is shown at the top of this list as the the most recently work account. In order to keep this list
updated, the user should click the Refresh button.
C O L L E C T I O N S V IE W
The Collections View enables a user (agent) or supervisor to view the details of a case in Collections.
Account, customer, and case details determine the questions and work areas which display to assist the user
in working a case.
C o l l e c t i o n s Vie w D e ta i l s
This section provides details about the Collections View, including the following:
• Sizing and Spacing the Collections View
• Other Activities Menu
Horizontal Vertical
Thumbnail 990 pixels minimum 16 pixel space between the thumbnail and
next area
Tab, History, and 16 pixels gutter between the 8 pixels space between Tab (or Reference)
Process Areas Tab (or Reference) area, area and Notes (History) area
Notes (History) area and
Process area
Note: The Other Activities Menu links are based on the user’s role (agent, supervisor, etc.)
therefore some users may not have access to some activities.
Identify Party Displays the Identify Party process area that allows the user to identify the
party to whom they are speaking.
Pay Now Displays the Pay Now process area that allows the user to capture a one
time payment on an account.
Negotiate Arrangement Displays the recommended offers for the customer in the process area
where the use can edit the offer or create a payment or settlement plan.
Cancel Arrangement Displays the Cancel Arrangement process area that allows the user to view
and cancel an active arrangement.
Change Account Status Displays the Change Account Status process area that allows the user to
request a change to the status (to Active or Suspended) on an account.
Change Credit Limit Displays the Change Credit Limit process area that allows the user to
request a change to the credit limit on an account.
Credit Fees and Charges Displays the Credit Fees and Process area that allows the user to select the
charge or fee to be changed.
Modify APR Displays the Modify APR process area that allows the user to change an
account's Annual Percentage Rate (APR).
Verify Party Details Displays the Verify Party process area that allows the user to verify and
edit the phone number and/or primary address with the party they are
speaking with.
Update Personal Details Displays the Update Personal Details process area that allows the user to
edit personal details, for example, last name.
Update Address Displays the Update Address process area that allows the user to edit
primary and secondary address information; for example, a new address.
Update Contact Details Displays the Update Contact Details process area that allows the user to
edit contact information; for example, home telephone number.
Update Financial Details Displays the Update Financial Details process area that allows the user to
edit the associated parties’ income and expense information.
Capture Reason for Displays the Reason(s) for Delinquency (RFD), the customer’s ability or
Delinquency willingness to pay and the resolution date.
Manage Circumstances Displays the Modify Circumstance process area, that allows the user to
collect information about special circumstances.
Manage Dispute Displays the Manage Dispute process area that allows the user to indicate
that one or more invoices/statements are under dispute and then capture
the dispute reason and amount.
Re-Assign or Defer Work Displays the Re-Assign process area that allows the user to:
Item • Reassign a Work Item to a specific user
• Reassign a Work Item to a different queue
• Select the Defer option
• Add notes to the transaction
Set Follow-up Date Displays that Set Follow-up Date process area that allows the user to
specify a date on which to follow-up on the case (the case as a whole, not
an individual work item).
Send Documentation Displays the Send Documentation process area that allows the user to
manually send correspondence.
Manage Customer Alerts Displays the Manage Customer Alerts process area that allows the user to
enter alert(s) about the customer; for example, the nickname the
customer prefers to be addressed by.
Manage Collateral Displays the Manage Collateral process area that allows the user to
Capture appraisal and insurance details for collateral used on a secured
debt product. This activity is available for secured debt products only.
Place with Agency Displays the Place with Agency process area that allows the user to
transfer an account to an external agency for further action.
Recall from Agency Displays the Recall from Agency process area that allows the user to
withdraw an account from an external agency.
Wrap-Up Case Displays the Wrap up Call process area that allows the user to wrap up
(complete) working a case.
Thumbnail Area
The Thumbnail (Figure 4-12) displays the account and customer information that is relevant to the
collections case. The top row displays fields that are associated with the account. This area identifies the
account’s responsible parties including their demographic information and is always visible in the
Collections View regardless of activities being performed in that view.
The Thumbnail contains a drop-down list containing all responsible parties on the account. The Thumbnail
information changes as the party selection is changed. This area contains only critical fields to minimize its
size.
File Names:
• thumbnail.jspx • caseviewlayout.jspx
• accountidentifier.jspx •
If a blue credit card icon displays in the Thumbnail, the selected customer has other accounts that are in
Collections. When the user clicks the icon, the Other Accounts pop-up (Figure 4-13) displays. These
accounts can be active or accounts previously in Collections.
The user can click on the account number to view the case for that account.
The Thumbnail also displays Special Circumstance information which allows a user to immediately know
whether special circumstances apply to any party on the account. The Thumbnail displays the type of special
circumstance as well as more detailed information in tooltip form:
File Name:
• accountidentifier.jspx
Note: When there is more than one liable party on the account, and more than one person has the
same special circumstance, only display the special circumstance once within the text of
the Thumbnail. However, display all occurrences and their statuses within the tooltip.
Ta b A r e a
The Tab area contains a series of tabs that display reference information for the account and customer in
Collections. These tabs contain information the user may need during customer interaction. The order of the
tabs is fixed and the Summary tab is the default.
The system determines which data is loaded; if a data value is not available double-dashes ( -- ) display.
Summary Tab
The Summary Tab (Figure 4-15) displays a quick view of account information including (click on the blue
link for more information about that Summary tab item):
File Names:
• reftabsummary.jspx • processpaneltemplate.jspx
• caseviewlayout.jspx • utilityreftabsummary.jspx
Note: The content of Summary Tab is multi-product product aware and will vary based on the
product type.
If there are multiple reasons for delinquency associated with the case, as many reasons as possible are listed
alphabetically. If all the reasons cannot fit in the list, the text “…” displays (as shown in Figure 4-15). When
the user hovers over the text, a tooltip lists each reason.
Negotiate Link
Clicking the Negotiate link displays the Negotiate Arrangement process area where the user can see
recommended offers or build a new arrangement.
Clicking the View History link displays historical details (Figure 4-16) of past arrangements, including past
PTPs, fee waivers, etc and the status of the account. This information can be helpful in determining if the
customer has kept or broken promises in the past when determining future PTPs. The history popup shows
all the past arrangements except for the current 'ACTIVE' or 'PENDING' arrangement which can be seen on
The Most Recent Arrangement region of the Summary Tab. The user can scroll down to see all the
arrangements in decending order and click on an arrangement to see more detail on the right side of the
screen.
File Name:
• historyofbrokenandkeptptps.jspx
The following components can be viewed in the Most Recent Arrangement region of the Summary Tab.
Table 4-3 outlines the details displayed for each component type:
COMPONENT DETAILS
Waive Fee If there is a Waive Fee component in the arrangement, there is an entry in the
Most Recent Arrangement area that states:
Waive Fee - Total $ <total amount of fees waived in this arrangement>
Account Status If the user has changed the Account Status in the arrangement, the Most Recent
Arrangement area on the Summary tab will display information about the change
to the account status.
APR If the APR component is part of an arrangement, then the component name with
the percentage rate and the duration displays.
• If the APR Change is to happen immediately, and the duration is not equal to
“No End Date” then display:
“APR - (value for Requested APR) for (value for Duration)”
• If the APR Change is to happen immediately, and the duration is equal to “No
End Date” then display:
“APR - (value for Requested APR)”
• If the APR Change is to happen when the arrangement is complete, then
display:
“APR - (value for Requested APR) - When PTPs Kept”
Re-age If the Re-age component is part of an arrangement, then the component name is
displayed.
Itemized Promises
The Itemized Promises region of the Summary Tab indicates the following:
• If the customer has fully met their obligation for this payment a green checkmark displays.
• If the customer has not met their complete obligation for this payment a red “X” displays.
When money has been received for a specific payment the payment's sum amount will be shown in the Total
Received column, and that Total Received data will be a link to display all the individual received amounts
that apply to that payment.
The user can click the link that indicates the name of the agency to access agency specific information.
The Past Collections Instances field displays the total number of times the account has been in collections.
Clicking the Past Collections Instances link displays the details of past collections instances.
This tab shows additional information about the account beyond what is displayed in the Summary tab.
There will be some duplicate information on both of the tabs. For example, the Balance and Credit Limit
information will appear in both the Summary and Account Details tabs. Additional detailed information on
this tab includes Last NSF, Last Re-Age Date, Portfolio name, and Financial Account Status.
File Names:
• reftabaccountdetails.jspx • processpaneltemplate.jspx
• sdreftabaccountdetails.jspx • utilityreftabaccountdetails.jspx
Note: The content of Summary Tab is multi-product product aware and will vary based on the
product type.
A
Figure 4-21: Account Details Tab
All associated parties are available in the Party drop-down list. When a party is selected, the customer Detail
tab information changes to display the information for that particular party.
Note: Certain fields of information do not display when a non-responsible party is selected from
the Party drop-down list.
File Names:
• reftabdemographics.jspx • reftabdemographicsfinancialhistory.jspx
• reftabdemographicsaddresshistory.jspx • processpaneltemplate.jspx
• reftabdemographicscontacthistory.jspx
Additional historical information is available by clicking the View History link in these sections of the tab:
• Contact Details (Figure 4-23)
• Addresses (Figure 4-24)
• Financial Details (Figure 4-25)
The user can also perform the following tasks by clicking the Edit link in each section:
• Update Personal Details
• Update Contact Details
• Update Address
• Update Financial Details
File Names:
• reftabdemographicscontacthistory.jspx • processpaneltemplate.jspx
• reftabdemographics.jspx • caseviewlayout.jspx
File Names:
• reftabdemographicsaddresshistory.jspx • processpaneltemplate.jspx
• reftabdemographics.jspx • caseviewlayout.jspx
File Names:
• reftabdemographicsfinancialhistory.jspx • reftabdemographics.jspx
• processpaneltemplate.jspx • caseviewlayout.jspx
Circumstances Tab
The Circumstances Tab (Figure 4-26) allows the user to view special circumstances information for a
particular party on the account.
File Names:
• reftabspecialcirstances.jspx • processpaneltemplate.jspx
• caseviewlayout.jspx •
Depending on the parties special circumstance information, the tab can contain the following areas of
information:
• Party Identification area — indicates which party's information is being shown on the Circumstances
tab. In the case of multiple parties, Text will display indicating that additional parties on the account
have special circumstances.
The party's name will always be displayed at the top of the Circumstances tab. If there is more than one
party on the account, a drop-down list is available to select an individual party. Select a party from the
drop-down list to display that party’s special circumstance information. If there is no Special
Circumstance information for a party the following message displays:
There is no special circumstance information for <Party Name>.
• Non-Concluded Special Circumstances area — lists any special circumstance that currently has a status
other than “Concluded”.
• Concluded Special Circumstances area — lists any special circumstance (under the gray bar) which has
a most recent status of “Concluded”.
• The Edit link — launches the Modify Circumstance activity where the user can edit the data for the
particular Special Circumstance.
If more then one Special Circumstance exists the details are displayed in the following order:
1. Deceased
2. Natural Disaster
3. Fraud
4. Incarceration
5. Bankruptcy
6. CCCS (Consumer Credit Counseling Service)
7. Health Matter
8. Military Service
Note: Fraud Circumstance will be available for Credit Card Products only.
Each special circumstance contains data specific to its type (see Look-up Table Values) as well as the
following common data:
• most recent status
• date it was first reported or captured
• date it was concluded if applicable
Note: The labels for common data are always displayed even if there is no data available.
Drop-down lists in the UI are populated from a specific look-up list. Table 4-4 shows the listcodes that
correspond to each special circumstance drop-down list (if applicable).
CCCS n/a
Type DISABILITY_TYPE
Incarceration n/a
Collateral Tab
The Collateral Tab (Figure 4-27) allows the user to view collateral information, including appraisal and
insurance details for Secured Debt products.
Note: This tab is currently configured to be available for ‘ccmanager’ role agents only.
The user will be able to edit only Collateral Appraisal or Insurance details from this tab.
File Names:
• sdreftabcollateraldetails.jspx
History Area
The History area (Figure 4-28) contains history details generated by the system based on actions taken or
notes entered by the user. The History area has the ability to expand, allowing the user to see additional
notes by using the scroll bar. The History area is always visible regardless of activities being performed in
the Collections view.
The History link lists the date, type description, and user associated with the event (Figure 4-28).
File Names:
• bahtable.jspx • processpaneltemplate.jspx
• caseviewlayout.jspx •
When the user clicks on a link in the Description column, a popup (Figure 4-29) displays additional
information about that activity.
Note: Click on a column header to sort the view according to the values in that column.
Figure 4-29 shows a sample popup. The Summary bar at the top of the popup shows the same activity as in
the History log.
COLUMN DESCRIPTION
Arrangement Offers that have been accepted, kept, and broken by the account holder. For
example, canceled Payment Plan.
Reassign Task that has been reassigned. For example, requeued from the user to the
supervisor’s inbox.
Rule/Routing A system-generated event that displays when work items have been re-routed
between queues. For example, account enters collections.
Transaction Financial transactions. For example, received payments, arrears fees, over
limit fees, and NSF fees.
There are other links in the History event area that the user can click on to display additional information:
• Planned Activities
• Enter a Note
• Filter
Planned Activities
The Planned Activities link lists the due date, type description, and queue location for work items that are
planned, but not yet completed for the case (Figure 4-30).
File Name:
• bahtable.jspx
Enter a No te
The user can add notes to the History area by clicking Enter a Note (Figure 4-31).
File Name:
• bahtable.jspx • enteranote.jspx
Filter
The user can click Filter to display the events that occurred by date of event, type of event, and event
initiated by (Figure 4-32).
File Name:
• bahtable.jspx
A l e r ts A r e a
The Alerts area (Figure 4-33) displays alerts to record important information related to the account. If there
are several alerts on an account, this area is scrollable and shows all the alerts for the party in descending
order from the most recent alert to the oldest.
If there is more than one party on the account that also has alerts, a yellow bell icon displays. Hovering over
the icon displays a tooltip that provides more information. In this case, the user should also view the alerts
for the other party to verify how the alert impacts the account.
Note: Clicking on the icon does not navigate to the other party’s alerts.
See section Manage Customer Alerts to add, edit, and remove alerts.
File Names:
• displayalerts.jspx • processpaneltemplate.jspx
Alerts Area
Process Area
The Process area (Figure 4-34) is the area within the Collections view where the user performs actions when
working a case, including:
• Questions to ask the customer/party
• Other Activity Menu task screens
• Next Best Action recommendations
• Confirmation screens
File Names:
• processpaneltemplate.jspx • caseviewlayout.jspx
Process Area
The Next Best Action decision logic determines what displays in the Process area of the case view.
If the user clicks the Cancel button, the activity is canceled and the process page refreshes with next best
action.
The following subsections describe the following pages that can display in the Process area:
• Question Pages
• Confirmation Pages
Question Pages
The Process area may display the following Next Best Action questions for the user to ask when speaking
with a customer:
• Have you sent your payment?
• Can you make a payment today?
• What is your reason for delinquency?
• What is your reason for your broken promise?
• Have you received your statement?
• Are you in a special circumstance?
• Able to make payments as normal?
Caution: Activities that have a question set are built using the Interview Service which relies on
properly configured seed data to display the question(s) in the process area. If the question
set is removed, the activity will not display correctly.
Each of these questions has a unique set of subsequent questions or actions, depending on the response from
the customer. Figure 4-35 shows a sample question screen; all of these screens look similar with a different
question and action.
File Names:
• displayquestions.jspx • processFooter.jspx
Confirmation Pages
Many of the process area activities have confirmation pages after the user selects the Submit button.
Figure 4-36 shows a typical confirmation that displays in the Process area.
Note: After the user clicks the Submit button, any changes made take effect immediately.
However, some changes may not display on the Thumbnail or the Tabs until the OK
button is clicked on the corresponding Confirmation page. For example, a change to the
address will not display in the Thumbnail until after the OK button is clicked on the
Update Address Confirmation page (Figure 4-74).
To oltips
The user can view tooltips by hovering the cursor over a active area of the screen. The tooltip displays as a
popup. Tooltips provide additional information about the following:
• Links
• Buttons (for example, the Submit and Cancel buttons on the Negotiate Arrangement process page)
• Icons (for example, in the Offers and Arrangements components)
• Menus and Menu Items
• Keyboard shortcuts
Figure 4-37 shows the tooltip when the user clicks the Script link.
Figure 4-38 shows the re-age tooltip that provides information about the state of the re-age component as
part of an offer.
Each of these activities is described in more detail in this section. In the following list, click on an activity
link to go to that subsection.
• Identify Party • Update Contact Details
• Pay Now • Update Financial Details
• Negotiate Arrangement • Capture Reason for Delinquency
• Cancel Arrangement • Manage Circumstances
• Change Account Status • Re-Assign or Defer Work Item
• Change Credit Limit • Set Follow-up Date
• Credit Fees and Charges • Send Documentation
• Modify APR • Manage Customer Alerts
• Verify Party Details • Place with Agency
• Update Personal Details • Recall from Agency
• Update Address • Wrap-Up Case
• Manage Collateral • Manage Dispute
Id entify P arty
The Identify Party process area (Figure 4-41) allows the user to identify the party to whom they are
speaking.
Note: There may be instances when the user is working on a case without a party on the phone
with them or someone who is not the primary/liable party.
The last value that is selected is retained only while that case view remains opened. When the case is closed,
the value for the selected party is reset.
File Names:
• identifyparty.jspx •
Figure 4-42 shows the Confirmation page that displays after the user clicks the Submit button.
File Name:
• identifypartyconfirmation.jspx
Pay Now
The Pay Now process area allows the user to submit a one time payment on a delinquent account. This
activity is accessed from the Other Activities menu as well as through Next Best Action (NBA). There are
several methods a customer can use to make a payment.
• Check
• Credit/Debit Card
• Electronic Funds Transfer
By default, the Payment Method, Date, and Amount fields are supplied by CDM.
Note: The default payment method is by Check. When a different payment method is selected,
the corresponding fields change to reflect the appropriate information needed for that
payment method.
To change the name on an account or card, select "Other" from the dropdown and enter the new name in the
fields supplied.
Clicking the Cancel button cancels the activity and refreshes the process area with the next best action.
Check
The Pay Now by Check process area (Figure 4-43) allows the user to submit a check payment from the
account holder.
File Names:
• paynow.jspx • processHeader.jspx
• paynowcomponent.jspx • processFooter.jspx
• utilitypaynow.jspx • utilitypaynowcomponent.jspx
Credit/Debit Card
The Pay Now by Credit/Debit process area (Figure 4-44) allows the user to submit a credit or debit card
payment from the account holder.
File Names:
• paynow.jspx • processHeader.jspx
• paynowcomponent.jspx • processFooter.jspx
• utilitypaynow.jspx • utilitypaynowcomponent.jspx
The Pay Now by Electronic Funds Transfer process area (Figure 4-45) allows the user to submit an EFT
payment from the account holder.
File Names:
• paynow.jspx • processHeader.jspx
• paynowcomponent.jspx • processFooter.jspx
• utilitypaynow.jspx • utilitypaynowcomponent.jspx
A Confirmation page with the appropriate information for each payment method displays when the user
clicks the Submit button. The confirmation number displayed comes from the Payment Gateway.
Figure 4-46 shows the Check payment Confirmation page.
When the user clicks the OK button from the Confirmation Page, the process page refreshes with the Next
Best Action.
File Name:
• paynowcomponentconfirmation.jspx
Negotiate Arrangement
The Negotiate Arrangement process area (Figure 4-47) displays the recommended offers that the user can
present to the customer.
File Name:
• offersandarrangements.jspx • processFooter.jspx
• processHeader.jspx
There are several components that the user can use to negotiate an arrangement. Click on the component link
below for more information:
• Payment Plan Component
• Waive Fees Component
• Account Status Component
• APR Component
• Re-Age Component
• Settlement Plan Component
To add a component. click on the component’s icon. To remove an offer component, the user can click on
the red “X” box in the upper right corner of the component.
The user can toggle between the system Recommended and manually created offers by clicking the “+” icon
next to Recommendations. This icon collapses the system offers so the user can more easily view the offers
they are manually creating.
When the user clicks the Submit button the offer is validated. If accepted by the offer validation logic, the
Most Recent Arrangement area and the Process page displays the next best action.
If an error message displays, the user should make the necessary change according to the message. Some
possible reasons for error messages are:
• User entered a PTP amount that was less than the acceptable minimum amount. In this instance, CDM
logic rejected the amount entered and returned this error. In the OOTB application, any amount less
than $5.00 is rejected.
• User entered a PTP amount that exceeded the acceptable minimum amount (more than the balance
owed). The user has the option to edit this arrangement or send it to the supervisor for review. See for
more information.
When the user attempts to submit a new arrangement when an active one is already present on the case, the
following popup displays to warn that they are about to cancel the existing arrangement.
File Name:
• offerwarningdialog.jspx
Note: If the user corrects any fields, the validation messages will persist on the screen until that
user clicks the Submit button again.
If the arrangement includes a change that must be processed by the system of record, such as an account
status change,, the change will not be seen immediately on the Summary bar when the offer is submitted.
This is because the final change needs to be performed by the client's system of record. When accepted by
the host, a message also displays in the History area.
The Recommendations region (Figure 4-49) contains a rank-ordered list of recommended offers which are
determined by the Retrieve Offers decision logic. Each offer is displayed in its own area which contains an
offer suitability measurement. The level of offer suitability is illustrated by a stacked green bar to the right of
the offer. The tallest set of bars indicates the offer is the best or most suitable offer presented. The user can
click in the upper half of the offer area to display the details of the offer in the Details region. In this figure,
the second offer displays the frequency (monthly).
The user can also indicate whether a recommended offer has been presented to a customer. There is a
checkbox with the label of “Offered” within the bubble of each recommended offer. After the user has
presented a specific offer to the customer, the checkbox should be clicked so that a check is placed in the
box. This “offered” information, in combination with information about the accepted offer, can be used to
generate more effective offers within the Retrieve Offers decision logic.
The user can also manually create or edit a recommended offer (see section Manually Created Offers Using
Build New for more information). For example, changing a payment amount or adding another offer
component. When a recommended offer is modified, the offer's icon changes within the Details area from a
number to the hammer (shown in Figure 4-50) in the blue Offer Summary bar. This bar shows each of the
current offers by displaying the component’s icon.
The user can click the Script link to expand the Script view where they can read from a prepared script when
talking with a customer. The script is generated by CDM and only applies to offers that are recommended by
CDM (not manually built offers). The Scripts link is disabled when an offer is manually created using the
Build New link or when the user edits a recommended offer.
File Names:
• offersandarrangements.jspx • offerssummary.jspx
• offerdetails.jspx
The user can click the Build New link (Figure 4-50) from the top of the Recommended Offers region to
manually create a new offer. When this link is clicked, any existing offer is cleared from the Details area and
the user can construct an entirely new offer. Additionally, the Offer Palette is automatically expanded to
facilitate the creation of a custom offer.
The Details region (Figure 4-50) contains the components of the offer selected in the Offer Palette. The blue
bar with the hammer icon in the left corner is called the Offer Summary bar. This bar shows each of the
current offers by displaying the component’s icon.
The user can click on the Offer Palette link to choose from various offer component links. If CDM
determines that a component does not apply to the account (for example, if the account does not have any
fees to waive), that button is disabled (grayed out) on the Offer Palette.
A Payment Plan (Figure 4-51) is a type of arrangement composed of one or more promises to pay (PTP)
from a customer. When the user selects the Payment Plan component from the Offer Palette, a call is made
to Retrieve Offers decision logic and a recommended payment schedule, with default dates and amounts is
returned.
Note: The default number of PTPs presented (as well as dates and amounts) can be customized.
The user can add more PTPs by entering a number in the blank area next to the Add button. That number of
PTP rows is displayed. The Collections system divides the amount of the payments equally between the total
number of PTPs. There is a maximum of 25 PTPs. Initially, the Date field(s) will be blank, so the user must
choose a valid date by entering the date or choosing it from the calendar. The Payment Method used
previously will populate the new PTP fields.
To remove a Payment Plan, the user can click on the trash can.
Note: There are variations on the Payment Plan icon to accommodate different currencies, for
example the Euro.
File Name:
• paymentplan.jspx
The process of waiving a fee (Figure 4-52) involves reducing or eliminating an account fee amount. This
reduction or elimination is a component of a Collections arrangement and can be done immediately or when
the arrangement is kept by the customer.
The Waive Fees component can be part of a recommended offer or can be manually selected from the Offer
Palette. Retrieve Offers decision logic determines if this account has fees that can be waived. If the account
does not have any fees to waive, then the Waive Fee button on the Offer Palette is disabled (grayed out) as
shown in Figure 4-52. If Retrieve Offers decision logic determines there are fees to be waived, the type of
fee and amount(s) is displayed.
File Name:
• modifyfee.jspx
The user can choose to add a fee to waive by clicking the Add Fee(s) to Waive button. The Add Fees to
Waive dialog box (Figure 4-53) displays the fees available to waive based on a date range.
To remove a waived fee, the user can click on the trash can.
Note: If a specific fee is already listed in the Waive Fee component, it will not be displayed in
this dialog box.
If there are no fees available to be waived, the tooltip message “There are no available fees to waive for this
account” displays.
File Name:
• feesummarydialog.jspx
The user can request a change to the account status (Figure 4-54) as part of an offer. The Current Status
options (received from the host) are either Active or Suspended. When the user changes the Requested
Status value, the Reason drop-down is updated with the appropriate values, and the value “Select...” displays
in the drop-down. Values are:
• For a requested Active status, the Reason choices are:
— System Recommendation
— Issue Resolved
— Contact Information Confirmed
— Override System Decision
• For a requested Suspended status, the Reason choices are:
— System Recommendation
— Non-Sufficient Funds
— Over-Indebted
— Over Limit
— Past Due
— Refused to Pay
When the new status (Active or Suspended) is accepted and returned from the host, this status will display
on the case view.
File Name:
• accountstatus.jspx
APR Component
The APR (Annual Percentage Rate) component (Figure 4-55) allows the user to offer an adjustment to the
APR. The requested APR percentages in the drop-down list is controlled by the Retrieve Offers decision
logic.
When an APR change is included as part of an accepted offer, that information is written to a staging table
(sent to the host). The requested APR percent is effective either:
• Immediately
• When PTPS Kept
Note: The APR change will not be immediately seen on the UI when the offer is accepted (even
if it was set to occur immediately). The final APR change is performed by the host. The
Collections application will not reflect the new APR on the case view until the APR
change is sent back from the host.
File Name:
• apr.jspx
Re-Age Component
The Re-age component (Figure 4-56) allows the user to take a delinguent account and artificially bring it
current so the account is no longer delinquent.
This action is often done as part of a repayment arrangement where the customer can make minimum
monthly payments but not enough to get out of delinquency on their own. This does not change the balance
due, it simply takes the arrears amount and moves it into the 'current' bucket.
Note: The Re-age change will not be immediately displayed on the Account Details tab until it is
processed by the host.
When the user uses clicks the Submit button, CDM validation logic is called to validate the field entries.
File Name:
• reageaccount.jspx
A Settlement Plan component (Figure 4-57) is a type of arrangement that provides a way for the user to
collect payment of a customer account by settling for a percentage of the current balance.
Whether the Retrieve Offers decision logic recommends the offer or it is created manually, the amount
field(s) are pre-calculated. The decision logic returns a recommended settlement schedule with Settlement
Reason, payment due date(s), payment amount(s) and payment method(s) filled in. The user has the option
to change these fields to make a customized plan for the customer.
Note: There are variations on the Settlement Plan icon to accommodate different currencies, for
example the Euro.
The Minimum Settlement Amount displays the minimum acceptable settlement amount needed for the offer
to pass validation. The percentage after this amount lets the user know what percentage this Minimum
Settlement Amount is of the total Current Balance due. After a settlement is negotiated, the Settlement
Amount percentage and Loss Amount on this account are displayed. These two percentages give the user a
sense of how their negotiated offer compares to the minimum requirement.
The First Payment Due by is the latest possible date for the first payment in order for the offer to pass
validation.
The Retrieve Offers decision logic can return the following Settlement Reason values in the drop-down list:
• System Recommendation (the default)
• Received Settlement Letter
• Special Circumstance
• Requested by Customer
File Name:
• settlement.jspx
The user can add more PTPs by entering a number in the blank area next to the Add button. That number of
PTP rows is displayed. The Collections system divides the amount of the payments equally between the total
number of PTPs. There is a maximum of 25 PTPs. Initially, the Date field(s) will be blank, so the user must
choose a valid date by entering the date or choosing it from the calendar. The Payment Method used
previously will populate the new PTP fields.
Cancel Arrangement
The Cancel Arrangement process area (Figure 4-58) allows the user to cancel a previously created
arrangement. The user can select a reason for canceling and can view the active arrangement to be canceled.
Clicking the Submit button will cancel the arrangement. Clicking the Cancel button cancels the activity and
the process page refreshes with next best action.
File Name:
• cancelarrangement.jspx
The user must chose the requested account status and reason from the Requested Status and Reason
drop-down. Values are:
• For a requested Active status, the Reason choices are:
— Issue Resolved
— Contact Information Confirmed
— Override System Decision
— System Recommendation
• For a requested Suspended status, the Reason choices are:
— Non-Sufficient Funds
— Over-Indebted
— Over Limit
— System Recommendation
— Refused to Pay
— Past Due
If the user clicks the Cancel button, the activity is canceled and the process page refreshes with next best
action.
File Name:
• changeaccountstatus.jspx
The requested status and reason are both passed to the host account system through the output staging table.
The host system updates the account status and then sends the change back to the Collections system
through an input staging table. When accepted by the host, the new status is displayed in the Thumbnail
area. If the request is canceled or when it is submitted, the process page refreshes with the next best action
(NBA) page.
Figure 4-79 shows the Confirmation page that displays after the user clicks the Submit button.
File Name:
• changeaccountstatusconfirmation.jspx
A call is made to Retrieve Offers decision logic which returns the best credit limit choice for this customer
on the Change Credit Limit page. However, any other credit limit choices are shown in the drop-down list.
which the user can manually chose one of those instead. If the Retrieve Offers decision logic cannot make a
recommendation, “Select...” displays as the Requested Limit and the user must select a value from the
drop-down list.
The decision logic determines what the credit limit can be changed to based on various factors such as:
• the type of product (for example, Platinum Visa or Gold MasterCard)
• customer risk score
• special circumstances
If the user clicks the Cancel button, the activity is canceled and the process page refreshes with next best
action.
File Name:
• changecreditlimit.jspx
When the user clicks the Submit button, the Process page refreshes with the Confirmation Page
(Figure 4-62). If the request is canceled, the process page with next best action.
When the user clicks the OK button, this information is passed to the host using an output staging table. The
host system updates the credit limit and then communicates the change back to the Collections system
through an input staging table. Only then is the new credit limit shown in the Collections UI in the History
log.
File Name:
• changecreditlimitconfirmation.jspx
If the user clicks the Cancel button, the activity is canceled and the process page refreshes with next best
action.
Note: By crediting a fee (either part of it or all of it) the user is removing it from the account.
File Names:
• modifyfee.jspx • modifyfeecomponent.jspx
Figure 4-64 shows the Confirmation page that displays after the user clicks the Submit button.
File Names:
• offerscommonapprovalconfirmation.jspx • modifyfeecomponentconfirmation.jspx
Mod ify A PR
The Modify APR process area allows the user to make changes to an account's Annual Percentage Rate
(APR). The options are:
• Change APR (Figure 4-65)
• Freeze APR (Figure 4-66)
• Suspend APR (Figure 4-67)
If the user clicks the Cancel button, the activity is canceled and the process page refreshes with next best
action.
File Names:
• modifyterms.jspx • reagecomponent.jspx
• aprcomponent.jspx • changelimitcomponent.jspx
• accountstatuscomponent.jspx
The Change APR option allows the user to change the APR on an account at different levels, choose the
effective date and duration.
File Names:
• modifyterms.jspx • aprcomponent.jspx
The Freeze APR option allows the user to freeze the APR on an account at different levels, choose the
effective date and duration.
File Names:
• modifyterms.jspx • aprcomponent.jspx
The Suspend APR option allows the user to suspend the APR on an account at different levels, choose the
effective date and duration.
File Names:
• modifyterms.jspx • aprcomponent.jspx
Figure 4-68 shows the Confirmation Page that displays after the user clicks the Submit button.
File Names:
• aprcomponentconfirmation.jspx • offerscommonapprovalconfirmation.jspx
Initially, the checkboxes are not selected. There are two ways the checkbox can become selected:
1 The user clicks inside the checkbox to show that they have verified the address and/or the phone
number(s) for the selected party
2 If the user edits any information in the editable fields (or adds any information to a blank field), the
checkbox becomes selected when the user tabs out of or leaves the updated field.
If there is more than one party on the account, the user can select which party's information they are
verifying or editing from the drop-down menu. Otherwise, the party displayed defaults to:
• The party identified previously by launching the Identify Party activity.
• The Primary account holder if None or Other was selected in the Identify Party activity, or if the
Identify Party activity has not been run.
File Name:
• verifyparty.jspx •
Figure 4-70 shows the Confirmation page that displays after the user clicks the Submit button.
File Name:
• verifypartyconfirmation.jspx
Some information, like the Tax Id and Language Preference is also shown in the Thumbnail Area.
Note: There is a 20-character limit for the Tax ID field. Numbers, letters and any special
characters are accepted.
If the user clicks the Cancel button, the activity is canceled and the process page refreshes with next best
action.
File Name:
• updatedemographicspersonalinfo.jspx
Figure 4-72 shows the Confirmation Page that displays after the user clicks the Submit button.
File Name:
• updatedemographicspersonalinfoconfirmation.jspx
Update Address
The Update Address process area (Figure 4-73) allows the user to edit associated parties’ primary and
secondary addresses. This process area is also accessible from the Party Details tab by clicking the Edit link.
If the user clicks the Cancel button, the activity is canceled and the process page refreshes with next best
action.
To delete a current address, remove all the data from address fields and click the Submit button.
File Name:
• updatedemographicsaddress.jspx
Figure 4-74 shows the Confirmation Page that displays after the user clicks the Submit button.
File Name:
• updatedemographicsaddressconfirmation.jspx
The user can select the customer’s local Time Zone from the drop-down list.
Note: This is the customer's Time Zone that is stored in the Collections system. If a Time Zone
has not previously been specified, the value “Select...” displays and the user must choose a
Time Zone from the drop-down list. There is only one Time Zone associated with each
customer on the account.
This Time Zone displays on the Thumbnail of the account until it is changed using Update Contact Details
from the Other Activities menu. However, no updates to the Time Zone are sent back to the host. If a Time
Zone value is not available, double dashes (--) display instead.
If the user clicks the Cancel button, the activity is canceled and the process page refreshes with next best
action.
File Name:
• updatedemographicscontact.jspx
Figure 4-76 shows the Confirmation Page that displays after the user clicks the Submit button.
File Name:
• updatedemographicscontactconfirmation.jspx
Note: If the Net amount is negative, then the amount is shown in RED numbers. For example,
-102.50.
The Date Last Updated date contains the date corresponding to active income or expenses.
If the user clicks the Cancel button, the activity is canceled and the process page refreshes with next best
action.
File Names:
• modifyfinancialdetails.jspx • modifyfinancialdetailsconfirmation.jspx
Figure 4-79 shows the confirmation page that displays after the user clicks the Submit button.
The user can choose one or multiple reason(s) for delinquency by holding down the Ctrl key.
• Military Service
• Natural Disaster
• Not my invoice
• Final invoice dispute
• Invoice amount incorrect
• Invoice never received
• Other
The resolution date can be chosen by clicking on the calendar or entering the date in the format
Mon-DD-YYYY, for example Feb-04-2007.
Note: The date can be today’s date or a date in the future, it can not be a past date.
Caution: This activity requires a question set and is built using the Interview Service. It relies on
properly configured seed data to display the question(s) in the process area. Specifically,
the Reason for Delinquency activity uses the QSET1 question set. Do not remove the
question set or these questions will not display. See section Question Pages for more
information.
File Name:
• displayquestions.jspx
When the user clicks the Submit button, the process page refreshes with the Next Best Action.
The Reason(s) for Delinquency for the account are shown on the Summary Tab.
Note: Fraud circumstance is not available for Utility and Secured Debt products.
This information is also shown on the Circumstances Tab and in the thumbnail.
The user can only create one of each type of Special Circumstance for each party on an account. For
example, if a Bankruptcy Special Circumstance already exists for one party on the account, the user can
create another Bankruptcy Special Circumstance for another party on the account. However, Fraud is
account based, so only one party on the account can have a Fraud Special Circumstance.
When the Manage Circumstances activity is launched, one of the following images displays for an account
with multiple parties:
The following screen displays when multiple parties are present as well as already existing Special
Circumstances. On this screen, the user can select the radio button to:
• Add a special circumstance
• Update and/or conclude an existing special circumstance
If the user concluds a special circumstance, it will not show up in the thumbnail or Summary tab.
File Name:
• modifyspecialcircumstance
The following screen displays when multiple parties are present on the account and no Special
Circumstances exist. The user can select a special circumstance.
File Name:
• modifyspecialcircumstance.jspx
The user can edit or conclude a Special Circumstance from the Manage Circumstances screen by clicking
the Yes radio button and choosing a reason from the dropdown list. All of the Special Circumstances have
this option at the bottom of the update and/or conclude screen. Figure 4-81 shows the Fraud Special
Circumstance as an example.
File Name:
• scfraud.jspx
After clicking the Submit button, a confirmation page displays that is appropriate for that Special
Circumstance. Figure 4-84 shows the Health Matter Confirmation page that displays. Each Special
Circumstance has its own confirmation page with the appropriate information included.
File Name:
• confirmdisabilityspecialcircumstance.jspx
Each Confirmation Page has it’s own .jspx file name as listed below:
• confirmationbankruptcyspecialcircumstance.jspx
• confirmationcccsspecialcircumstance.jspx
• confirmationdeceasedspecialcircumstance.jspx
• confirmationfraudspecialcircumstance.jspx
• confirmationdisabilityspecialcircumstance.jspx
• confirmationincarcerationspecialcircumstance.jspx
• confirmationmilitaryservicespecialcircumstance.jspx
• confirmationdisasterspecialcircumstance.jspx
Bankruptcy
If the user selects to add a Bankruptcy Special Circumstance from the Manage Circumstances screen
(Figure 4-81) the following screen displays:
File Name:
• scbankrupt.jspx
CCCS
If the user selects to add a CCCS Special Circumstance from the Manage Circumstances screen
(Figure 4-81) the following screen displays:
File Name:
• sccccs.jspx
Deceased
If the user selects to add a Deceased Special Circumstance from the Manage Circumstances screen
(Figure 4-81) the following screen displays:
File Name:
• scdeceased.jspx
Fraud
If the user selects to add a Fraud Special Circumstance from the Manage Circumstances screen
(Figure 4-81) the following screen displays:
Note: The Fraud special circumstance is account based (all other circumstances are party based),
so only on e can exist on the account.
File Name:
• scfraud.jspx
Health Matter
If the user selects to add a Health Matter Special Circumstance from the Manage Circumstances screen
(Figure 4-81) the following screen displays:
File Name:
• scdisability.jspx
Incarceration
If the user selects to add an Incarceration Special Circumstance from the Manage Circumstances screen
(Figure 4-81) the following screen displays:
File Name:
• scincarceration.jspx
Military Service
Once the user selects to add a Military Service Special Circumstance from the Manage Circumstances
screen (Figure 4-81) the following screen displays:
File Name:
• scmilitaryservice.jspx
Natural Disaster
If the user selects to add a Natural Disaster Special Circumstance from the Manage Circumstances screen
(Figure 4-81) the following screen displays:
File Name:
• scnaturaldisaster.jspx
If there are no agents in the "To a specific agent" dropdown list (i.e. no agents have inboxes available to
re-queue to), then the radio button associated with that dropdown is disabled.
Note: The Defer date is only saved in the database (not as the Follow-up Date on the Summary
Tab).
File Name:
• reassignworkitem.jspx
Figure 4-94 shows the Confirmation Page that displays after the user clicks the Submit button.
File Name:
• confirmReassignworkitem.jspx
S e t F o llo w-u p D a te
The Set Follow-up Date process area allows the user to specify a date on which to follow-up on the case (the
case as a whole, not an individual work item).
The date must be today's date or a date in the future in the format Mon-DD-YYYY (for example,
Feb-12-2007) or can be chosen from the calendar icon.
File Name:
• displayquestions.jspx
Caution: This activity requires a question set and is built using the Interview Service. It relies on
properly configured seed data to display the question(s) in the process area. Specifically,
the Set Follow-up Date activity uses the QSET11 question set. Do not remove the
question set or this question will not display. See section Question Pages for more
information.
When the user clicks the Submit button, the process page refreshes with the next best action (NBA) and the
Follow-up Date displays on the Summary Tab.
Send Documentation
The Send Documentation process area (Figure 4-96) allows the user to select a document type and send it to
the customer. The user can select:
• Document type
• Party sent to
• Delivery Method (after selecting Party sent to).
• Below the Delivery Method, the following links display that allow the user to modify the address or
contact information:
— Update Address
— Update Contact Details
If the user clicks the Cancel button, the activity is canceled and the process page refreshes with next best
action.
File Name:
• manuallysendcorrespondence.jspx
Figure 4-97 shows the confirmation page that displays after the user clicks the Submit button.
File Name:
• manuallysendcorrespondenceconfirmation.jspx
The alerts display as a bulleted list at the top of the process area under the heading Customer Alerts. If there
are multiple alerts, the list is scrollable so the user can view all the alerts for the customer.
If there is more than one party on the account that also has alerts, an icon displays. Hovering over the icon
displays a tooltip that provides more information. In this case, the user should also see the alerts for the other
party to verify how the alert impacts the account.
Note: Clicking on the icon does not navigate to the other party’s alerts.
Any previously created alerts display the Created date, Last Modified date, and user’s ID.
Clicking the Cancel button cancels the activity and refreshes the process area with the next best action.
Note: The Continue button is not enabled until a radio button has been selected.
File Name:
• managecustomeralerts.jspx
Clicking the Add New Alert radio button (shown in Figure 4-98) allows the user to add new alerts. By
default, the checkbox next to the customer’s name that was selected in the drop-down on the initial page is
checked. For example, if Mary Susan Kriss was selected in the drop-down on the previous page, then the
checkbox associated with her name is checked on this screen.
The same alert can be applied to other parties on this account by selecting the checkbox next to the
appropriate name(s). The Alert text can be a maximum of 255 characters in length.
Clicking the Previous button brings the user to the page viewed prior to the current page.
File Name:
• createcustomeralert.jspx
Figure 4-100 shows the confirmation page that displays after the user clicks the Submit button.
File Name:
• managecustomeralertsconfirmation.jspx
Clicking the Edit or Remove Existing Alerts radio button next to the appropriate existing alert (shown in
Figure 4-98) for a customer allows the user to edit an existing alert’s text. The Alert text can be a maximum
of 255 characters in length.
The Previous button brings the user to the page viewed prior to the current page.
File Name:
• editcustomeralert.jspx
Figure 4-102 shows the confirmation page that displays after the user clicks the Submit button.
File Name:
• managecustomeralertsconfirmation.jspx
Clicking the Edit or Remove Existing Alerts radio button next to the appropriate existing alert (shown in
Figure 4-98) for the customer allows the user to remove that alert.
The existing Alert Text is displayed and can be removed by clicking the Remove this Alert checkbox. The
text to be removed is disabled (grayed out) and cannot be edited. Deselecting the Remove this Alert checkbox
re-enables the Alert Text box for editing.
The Previous button brings the user to the page viewed prior to the current page.
File Name:
• managecustomeralerts.jspx
Figure 4-104 shows the confirmation page that displays after the user clicks the Submit button.
File Name:
• managecustomeralertsconfirmation.jspx
If the user selects the Place with Agency activity from the Other Activities menu, the Place with Agency
process area can display differently based on the state of the account. The following Place with Agency
scenarios may occur:
IF... THEN...
Account is Not Currently with an The user must select a placement reason from the dropdown
Agency menu and click Submit.
Account is Pending Agency Placement The user only has the option of clicking OK.
Account Already Placed with an Agency The user only has the option of clicking OK.
Account Already Placed with an Agency The user only has the option of clicking OK.
and Recall Requested
If the account is not currently placed with an agency the following screen displays:
File Name:
• placeagency.jspx
Once the user chooses a Placement Reason and clicks Submit the following Confirmation screen displays:
File Name:
• confirmationplacement.jspx
If the user selects the Place with Agency activity and the account is pending placement with an agency, the
following screen displays:
If the account has already been placed with an agency, and the user selects the Place with Agency activity,
the following screen displays:
If the account has already been placed with an agency and a a recall has been requested on the placement the
following screen displays:
Figure 4-109: Account is Already Placed with an Agency and Recall Requested
Once the user selects the Recall from Agency activity from the Other Activities menu, the Recall from
Agency process area can display differently based on the state of the account. The following Recall from
Agency scenarios may occur:
IF... THEN
Account is Currently with an Agency The user must select a Recall Reason and click the Submit
button.
Account is Not Placed with an Agency The user only has the option of clicking OK.
Account is Pending a Recall from an The user only has the option of clicking OK.
Agency
Account is Pending Placement with an The user only has the option of clicking OK.
Agency
Once the user chooses a Recall Reason and clicks the Submit button, the following Confirmation screen
displays:
File Name:
• confirmationrecall.jspx
If the account has not been placed with an agency the following screen displays:
If the account is already pending a recall from an agency the following screen displays:
If the account is pending placement with an agency the following screen displays:
Wr ap-Up Case
The Wrap-Up Case process area displays the actions that took place during the current call. The user can
also select a disposition of the call to be recorded with the case before closing it, such as:
• Contact Details Updated
• Arrangement Taken
• Circumstance Updated
If a disposition code is selected, it is stored on the ECM business step corresponding to the work case
session for use in the NBC decision logic. See Chapter 4, “Next Best Contact Decision Logic” in the
Decision Logic Guide for implemention details.
The Wrap-Up Case page is displayed either when the Wrap-Up option is selected from the Other Activities
menu or the system determines there are no more tasks for the user to perform on the current call, and
triggers Wrap-Up as the next best action. What displays on the page and as a disposition selection depends
on:
• If a Trainee agent is logged in, then the Wrap-Up page shows no disposition dropdown selection
• When an arrangement has been taken in the last two hours, the disposition “Arrangement Taken”
displays (as shown in Figure 4-115) as the default value
• When a Circumstance was updated, the disposition “Circumstance Updated” displays as the default
value
• When contact information was updated, the disposition “Contact Details Updated” displays as the
default
Note: When working a case from a queue, the user (agent) needs to perform the Wrap-Up
activity in order to close the work item.
Clicking the Exit button closes the Collections View and returns the user to the Homepage.
File Name:
• wrapup.jspx
Supervisor Review
When the Collections system tries to validate an arrangement that has been submitted and determines that it
that falls outside the recommended range, message(s) display in red text (Figure 4-116). The user can do the
following:
• Edit the arrangement
• Route the arrangement for approval by the supervisor
• Enter a note for the supervisor to provide more details
See section Manage Your Group Tab for more information on having an arrangement approved by the
supervisor.
When the supervisor receives an arrangement for review, the reasons the offer failed validation are displayed
on the supervisor review pop-up in red text and the details of the arrangement are shown in the box titled
“Arrangement Information”.
File Name:
• sendtosupervisordialog.jspx
• Cancel - Cancels the current activity and the system will invoke NBA for the next best action
• Edit Arrangement - Takes the user back so they can edit the arrangement details
• Route to Supervisor - Submits the arrangement for supervisor review
File Name:
• managecollateraldetails.jspx
Figure 4-118 shows the confirmation page that displays after the user clicks the Submit button.
File Name:
• Managecollateralconfirmation.jspx
Manage Dispute
The Manage dispute process area (Figure 4-119) allows the user to indicate that a customer is disputing one
or more invoices/statements and enables the user to capture the reason and amount of dispute.
File Names:
• managedisputedetails.jspx • sd managedisputedetails.jspx
• utilitymanagedisputedetails.jspx
Figure 4-120 shows the confirmation page that displays after the user clicks the Submit button.
File Names:
• managedisputeconfirmation.jspx • sd managedisputeconfirmation.jspx
• utilitymanagedisputeconfirmation.jspx
S U P E R V I S O R P A G ES
The supervisor has access to screens that are not accessible to a user (agent). The supervisor’s Homepage
has two tabs:
• View Your Work Tab — Allows the supervisor to review their own personal inbox and work queues
(Figure 4-121). These areas on this screen provide additional information (similar to the user’s/agent’s):
— The View Supervisor Additional Metrics link — Statistical information and user’s
performance.
— Inbox Details — List of work items in a supervisor’s personal inbox.
— Queue Summary — List of queues to be worked.
• Manage Your Group Tab — Allows the supervisor to review the work queues of the users (agents)
within their group. This tab contains these areas of information:
— Inboxes of Agents in Your group — List of agent’s and supervisor’s work items.
— Queue Summary — List of queues to be worked.
Note: The supervisor also has access to the user’s (agent’s) activities.
Vi e w Yo u r Wo r k Ta b
The View Your Work tab (Figure 4-121) allows the supervisor to view their own:
• Personal inbox
• Work queues
Similar to a user (agent), the supervisor can view additional metrics (Figure 4-122)
File Names:
• homepage.jspx • queues.jspx
• metrics.jspx • viewyourworkdetails.jspx
• metricown.jspx
File Names:
• monthlymetrics.jspx
Note: Adobe has discontinued support of the plug-in needed to render SVG charts in Internet
Explorer, so these charts have been removed from version 3.0. The architecture is
designed to support alternative charting plug-ins should that requirement exist.
M a n a g e Yo u r G r o u p Ta b
The Manage Your Group tab (Figure 4-123) allows supervisors to:
• View the inboxes of the users (agents) in their group
• View inbox and queue work items
• Reassign work to the users (agents) in their group
Inboxes or area of the screen will not display in the following instances:
• If an agent in the supervisor's group does not have an inbox, then that inbox will not display in the
"Inboxes of Agents in your Group" list.
• If there are no available inboxes in a supervisor's group for a supervisor to re-queue a work item to, then
the "Inboxes of Agents in your Group" portion of the homepage does not display.
File Names:
• homepage.jspx • queues.jspx
• metrics.jspx • viewyourgroupdetails.jspx
• metricown.jspx
File Names:
• monthlymetricssupervisor.jspx
Note: Adobe has discontinued support of the plug-in needed to render SVG charts in Internet
Explorer, so these charts have been removed from version 3.0. The architecture is
designed to support alternative charting plug-ins should that requirement exist.
File Name:
• viewworkitems.jspx
The supervisor sets permissions for users to allow or deny them the ability to see and/or work inboxes and
queues using the Queue Manager. Refer to the Chordiant Tools Platform Administration Manager Guide for
details.
Que ue Manag er
The supervisor can click the View/Assign Agents button to display the Queue Manager (Figure 4-126). The
Queue Manager screens are for information only.
File Name:
• QueueManager.html
To view queues and access queue-specific information, the supervisor can click on any queue link in the
Name column. The following queue tabs display:
• General (Figure 4-127)
• Assignments (Figure 4-128)
• Properties(Figure 4-130)
The Queue Manager General tab (Figure 4-127) displays the name, description, status, and priority of the
queue.
File Name:
• QueueManager.html
File Name:
• Assignments.html
l
Figure 4-128: Queue Manager - Assignments Tab (Assigned Users, Groups and Roles)
File Name:
• Assignments.html
The Queue Manager Properties tab (Figure 4-130) displays the Key and the Value. Where Key is the name
of the property and Value is the value of the property.
File Names:
• PropertyTabPage.xsl • PropertyTabPage.xml
Q u e u e Work I te m L i s ti n g
The supervisor can click the View/Re-Queue Items button to select a work item to re-queue. The Queue
Work Item Listing page (Figure 4-131) displays information about the customer name, the account number,
the balance owed by the customer, the amount past due, the date the work item is due, and the last action
taken.
File Name:
• viewworkitems.jspx
R e - Q u e u e S e l e c te d I te ms
The supervisor can select a work item to re-queue. from the list. The Re-Queue Selected Items page
(Figure 4-132) allows the supervisor to select to requeue the item to a different user (agent) or a different
queue. A supervisor can requeue selected items from the Inbox Details or Queue Details page.
Note: Agents who do not have inboxes will not display in the "Agent" dropdown list.
If a Supervisor chooses to re-queue a work item from the queue window, and there are no agents in the
"Agent" dropdown (meaning that no agents have inboxes available to re-queue to), then the radio button and
associated dropdown box will not display.
File Name:
• requeueselecteditems.jspx
C U S T O M I Z I N G TH E C O L L E C T I O N S M A N A G E R A P P L I C A T I O N
This chapter contains customization instructions used to extend the following commonly changed
components of Collections Manager:
• Party Role
• Other Activities Menu
• Special Circumstance tab
• Pay Now activity
• Queue Filtering
• Queuing Permissions
• Case APIs
• Collections Dialer APIs
• User Profile Data APIs
• Multi-Product Support
Note: The following steps pertain to the Attorney Party Role and are shown as an example.
1. Create a new RSM 6.0 model using the Business Services Party Management Facility (PMF) model as
the base and extend PartyRole.
a. Open RSM 6.0 and create a new simple project.
b. Copy the out-of-the-box Chordiant Business Services RSM model:
https://src.chordiant.net/repos/BusinessServices/trunk/Dev/server/models/Chordiant_Object/model/Chor
diant_Object.emx
c. Save this model workspace in the newly created project folder. For this example, the following
CommonPartyRole project and .emx file is created:
https://src.chordiant.net/repos/Collections/trunk/Dev/common/PartyRole_Objects_RSM/CommonPartyR
ole.emx
191
Customizing the Collections Manager Application
d. Create new businessclasses and JXP packages for this new PartyRole extension. In this
example, com.chordiant.common.partyrole.businessclasses was created.
e. Create a new class diagram and pull in the PartyRole class from
com.chordiant.pmf.businessclasses into the class diagram.
f. Extend PartyRole with the new specialization role descriptive title. In this example, the
“Attorney” role is created.
g. Add attributes to the extended class. Do not add in any JXP persistence metadata to this new
class. Persistence metadata will be added to the classes under the JXP package only.
h. Create at least the “partyroleid” primary key attribute in the business object (BO) followed by
subclass’ additional attributes. If the subclass needs no persistence (for example, if an
Attorney object strictly for passing business domain typed objects within the code is needed,
then create the Attorney object with no attributes and no specific table persistence). In this
example, an Attorney class with two additional attributes (barNumber and barStateCode) is
created.
2. If the BO will be persisted, it is recommended to follow the PMF pattern of creating the system business
object (SBO) under the JXP package which will require an attributes transfer from the common
business object (CBO) (Attorney) to the SBO (AttorneyTable).
a. Create a class under the JXP package which will contain the JXP metadata. The standard
naming convention is to name it <tablename>Table. This example persists Attorney in a new
table ATTORNEY, so the class AttorneyTable class is created.
b. Make sure to add the JXP stereotypes that are needed following the standards in the Chordiant
Foundation Server Application Components Developer Guide.
c. Edit the appropriate JXP stereotype data to map the new class to table and attributes to
columns.
d. Once everything is mapped, save the model changes and export the CMI file
3. Using the CMI file generated in the previous step, run it through the Business Component Generator in
the Foundation development environment (DE).
a. Create a new project to be used for BO generation. In this example, a PartyRole_Objects
project is created.
b. Run the CMI file through the BCG process (refer to the Chordiant Foundation Server
Application Components Developer Guide).
4. Create a new table and make other necessary database changes.
a. If the PartyRole subclass has additional attributes to be persisted, create a new database table
to persist those attributes. In this example, a new ATTORNEY table is created.
b. Use ERwin (or other data modeling tool) to model the new table and columns. Make sure the
new table has a foreign key (FK) reference to PARTYROLE and it's primary key (PK) is
PARTYROLEID. The best practice is to put new tables into a new schema, not in
CS_BUSINESS_SERVICES_OWNER or CCSOWNER.
c. Generate DDL for the new table, constraints (FK) and indexes. Apply DDL to the development
database instance.
d. Insert a new row into the PARTYROLETYPE database table for the new type of role that was
just modeled. In this example, the value “ATTORNEY” is inserted.
5. Manually code a corresponding AttorneyBehavior class that extends PartyRoleBehavior (PartyRole
Service uses server-side behaviors) This class must be in a subpackage business object behavior (BOB)
called “bob” under the Applicant class and must have the same class name as the BO with the word
“Behavior” appended. For example:
— com.foo.Attorney.java
— com.foo.bob.AttorneyBehavior.java
Note: The BOB must exist regardless of whether the BO is persisted to its own table or not.
6. The server-side behavior must have the following three methods to persist the BO service:
• readSubtypeData()
• writeSubtypeData()
• updateSubtypeData()
a. These methods are only on the PartyRoleBehavior classes and their descendents,
CustomerBehavior, OrganizationUnitBehavior, LeadRoleBehavior etc. However, the
PartyBehavior and derivatives (OrganizationBehavior, PersonBehavior) do not have these
three SubtypeData methods.
b. Optionally, this behavior can be generated if the BO has at least one method defined on it or if
the three mandatory subtypeData methods above are defined as shown in the model. Having at
least one method flags the business component generator (BCG) to generate a BOB.
Note: If these three subtype methods are not defined, only the previously-generated methods that
were defined will be in the BO. In this case, the generated behavior will need to be
modified to add these subtype methods. It is recommended to manually hand-code the
behavior extending PartyRoleBehavior and the readSubtypeData, writeSubtypeData or
updateSubtypeData methods because the BO looks less cluttered if these methods are not
defined. Ensure that the hand-coded BOB class is defined under src/custom and NOT
src/generated so the clean target will not be inadvertently deleted.
7. Modify the config.master/PmfFactory.xml file to define an ATTORNEY type code and associate it to the
Attorney BO (and it’s fully qualified class) as the ResourceValue. This info is used by
PartyRoleFactory to vend business objects based on the ATTORNEY type code. Do the same for the
Relationship specializations (see below)
Note: The party role service does not use the Chordiant metadata exchange (CMI) file of the
objects to locate the associated behavior for the party role derivative. Instead, it is
hard-coded to look for a behavior in the Attorney’s business object behavior (BOB)
subpackage with same BO name + Behavior appended!
Caution: Do not try to create a party role specialization by extending NullPartyRole or a behavior
object by extending NullPartyRoleBehavior classes. These classes are defined ONLY
because the PartyRoleBehavior should be a Java interface and not an abstract class. When
the PartyRoleService needs an object of type PartyRoleBehavior vended from the business
object factory, it has to have an instantiable object. It does this by requesting a
NullPartyRoleBehavior object (which has implementations for the three abstract
subtypeData methods), then casting it to a PartyRoleBehavior. Ideally, the PMF could use
Java interfaces, if this is not done, null versions of the abstract PartyRoleBehavior object
need to be created.
USER INTERFACE
Note: The Administration Manager application already provides functionality for adding
resources, assigning agents, and assigning agent permissions.
Resources represent the activities within the Other Activities Menu. By mapping Resources to Activities,
permissions can be added on Activities and can be restricted or access can be granted to Users within
Collections Manager. If a user lacks the proper permissions for a Resource, then the associated activity will
not display in the Other Activities drop-down menu.
The following table contains the Activity mappings within Collections Manager. Each Activity is mapped
to an individual Resource and users are granted access to the Resources by role.
To grant access to a Resource for a specific Role, 'READ' permissions must be granted on the Resource for
the Role. Refer to the Foundation Server Developer’s Guide for additional information
Note: Resources are organized into a tree structure and the root of the tree is 'Activities' with a
subgroup of 'Collections'.
Negotiate Activities/Collections/OffersandA X X X X
Arrangement rrangements
Cancel Activities/Collections/CancelArra X X X
Arrangement ngement
Manage Activities/Collections/CaptureSp X X X X
Circumstances ecialCircumstance
Re-Assign or Activities/Collections/ReAssignW X X X X
Defer Work Item orkItem
Send Activities/Collections/ManuallyS X X X X
Documentation endCorrespondence
Manage Activities/Collections/ManageCu X X X X
Customer Alerts stomerAlerts
Manage Activities/Collections/ManageCol X
Collateral lateral
Supervisor Activities/Collections/Supervisor X X
Review Review
Resource Bean
The Resource Bean fetches and holds a list of Resources given one or more resource paths. The Resources
bean is a simple bean with two properties:
• resourcePath - defined in the configuration of the bean, this will indicate the path to the resources that
will be held by that instance of the bean.
• Map that holds the associated access rights that the User has for that Resource. The first time that this
Map is accessed, it will be initialized.
Because this is kept generic for re-usability, it is the responsibility of the code that uses this bean to interpret
it accordingly (such as, in this usage scenario, a list of resources representing menu items that the user can
access).
This bean could conceivably be enhanced to include a Map of recourse properties or even other related
Recourses.
Agent Bean
The Agent bean is a session-scoped bean that is intended to hold information about the logged in agent.
Through configuration, an instance of the Resources bean is injected into the Agent bean to be interpreted as
a set of activities that the user has the right to execute.
This bean could be enhanced to hold other info about the agent (Roles, Relationships, Agent Name, Login
time, etc.).
Configuration
<managed-bean>
<managed-bean-name>activities</managed-bean-name>
<managed-bean-class>bundles.collectionscommon.jsf.classes.Resources</managed-bean-class>
<managed-bean-scope>application</managed-bean-scope>
<managed-property>
<property-name>resourcePaths</property-name>
<list-entries>
<value>Activities/Collections</value>
</list-entries>
</managed-property>
</managed-bean>
<managed-bean>
<managed-bean-name>agent</managed-bean-name>
<managed-bean-class>bundles.collectionscommon.jsf.classes.Agent</managed-bean-class>
<managed-bean-scope>session</managed-bean-scope>
<managed-property>
<property-name>otherActivitiesMenu</property-name>
<value>#{activities}</value>
</managed-property>
<managed-property>
<property-name>queueManagerResources</property-name>
<value>#{queueManagerResources}</value>
</managed-property>
<managed-property>
<property-name>inboxResource</property-name>
<value>Activities/Collections/CollectionsAgentInbox</value>
</managed-property>
</managed-bean>
Usage
The Other Activities menu is defined as a static list of commandLinks in the otheractivities.jspx file. With
the Resources bean responsible for retrieving the appropriate resources and associated permissions, and the
Agent bean responsible for holding those resources to be interpreted as a set of executable activities for that
user, the only thing left to do is properly code the rendered="" attribute of each commandLink to check the
permissions in the otherActivitiesMenu property of the Agent bean:
<tr:commandLink id="offersandarrangements"
styleClass="activitiesLink"
text="#{otherActivitiesProps.values.offer_summary_label}"
action="#{otherActivitiesBean.launchActivity}" immediate="true"
rendered="#{agent.otherActivitiesMenu.permissions['OffersAndArrangements']}">
<tr:setActionListener from="OffersAndArrangements"
to="#{otherActivitiesBean.activityName}" />
</tr:commandLink>
As mentioned above, the Resources bean is intentionally kept generic so that it is up to the user of the bean
instance to decide what those resources represent. Given this, one could easily use another set of Resources
to affect other parts of the UI with very little code updates to what is described above. All that should be
needed are:
1. A new managed-bean configuration, using the Resources class, but with a difference
managed-bean-name and (more than likely) a different value for the resourcePath property.
2. Code to read those resources/rights and use them accordingly. This involves a new bean to inject the
instance of Resources into (or a new property in an existing bean, if appropriate) and some attributes in
the UI components as determined by the design (the two most likely attributes to use are rendered="" or
disabled="").
Sp e c i a l C i r c u m s ta n c e s
Note: The name should be the code of the type of special circumstance lowercase (first letter
uppercase). For example, SCDisputeWrapper.java. This class will add the additional
properties needed for that particular type.
• Add a new page for the details following this convention name:
sctab<type_code_lower_case>.jspx. It will show the specific data for this particular type on the tab.
• Add a new page for the details following this convention name:
sctabconcluded<type_code_lower_case>.jspx
The special circumstance tab page is defined at reftabspecialcircumstances.jspx which displays the parties
associated with the case and any messages indicating whether or not a party has Special circumstances
associated. In addition, dynamic circumstance child pages are also included which contain the circumstance
information returned by the APIs.
• sctabbankrupt.jspx • sctabconcludedbankrupt.jspx
• sctabcccs.jspx • sctabconcludedcccs.jspx
• sctabdeceased.jspx • sctabconcludeddeceased.jspx
• sctabdisability.jspx • sctabconcludeddisability.jspx
• sctabfraud.jspx • sctabconcludedfraud.jspx
• sctabincarceration.jspx • sctabconcludedincarceration.jspx
• sctabmilitaryservice.jspx • sctabconcludedmilitaryservice.jspx
• sctabnaturaldisaster.jspx • sctabconcludednaturaldisaster.jspx
• sctabunemployment.jspx • sctabunemployment.jspx
Note: The pages receive special circumstance wrapper objects and display the specific
information for that special circumstance based on type.
Business Services
CircumstanceOutputImpl: (Implements
com.chordiant.ecm.businessstep.businessstepactioninterface.ExtInterface)
• StageOutCircumstance populateStageOutCircumstances (String username,String authentication,
ECMBusinessStep ecmBusinessStep): This method returns the populated StageOutAccount Object
based on passed business step.
• Object executeCreateAction(String username, String authentication, ECMBusinessStep
ecmBusinessStep,Object object): This method creates/updates the StageOutCircumstance,
StageOutCircumstance based upon business step passed.
• StageOutCircumstance getCircumstanceStageOut(StageOutCircumstance oStageOutCircumstance,
Circumstance specialCircum): This method set all attributes that has the circumstance in the
StageOutCircumstance object.
Business Objects
• StageOutCircumstance: The stage out object used to send information back to the host about the special
circumstances captured on the Collections System.
• ECMBusinessStep: NBC creates a specific business step that triggers the persistence of the Stage out
object.
• Circumstance: The Special Circumstance captured on the Collections System.
The out of the box payment gateway interface needs to be customized to interact with the real time payment
gateway to do the following:
• Create individual implementation classes like XXOutputImpl which implements the
PaymentGatewayInterface.
• Provide implementation for the method contactExternalSystem(Payment payment).
Queue Filtering
Queue Items can be filtered based on various criteria. Each criteria corresponds to an attribute in the Queue
Item. For more information about Queue Items refer to section Customizing Queue Items for Personal
Worklist in the Chordiant Customization Guide.
The following are the filter criteria that are available out-of-the-box:
• Priority
• Due Date
• Past Due
• Balance
The service API used for multiple criteria queue filtering is:
The following code shows how to pass this criteria to the browseQueueItem method.
firstCriteria.setAmount(new BigDecimal(45));
firstCriteria.setAmountCriteria(BusinessObjectCriteria.CRITERIA_EQUAL_GREATER);
secondCriteria.setAmount(new BigDecimal(150));
secondCriteria.setAmountCriteria(BusinessObjectCriteria.CRITERIA_EQUAL_LESSER);
orderCriteria.setPriorityCriteria(BusinessObjectCriteria.ORDER_ASCENDING);
The orderVector is used to pass the various order criteria. Additional criteria can be set by using the
firstCriteria and secondCriteria parameter.
CollectionsJSFQueueHelper.java is the helper class that passes all the necessary filter information to the
service API.
The following diagram illustrates the Create Collections Case API high level design:
The following diagram illustrates how the Create Collections Case API works:
CollectionsCaseService
The CollectionsCaseBuilder is responsible for populating objects that are needed to fully create a collections
case. These objects are populated with data that comes from the stage in tables. This singleton class will
instantiate the class that is defined in the config/chordiant/components/master/ObjectBuilders.xml.
CollectionsCaseInput
The CollectionsCaseInput object is a POJO that contains all of the data that the builder will need to populate
the objects needed to create a collections case. For the out of the box Collections applications java objects
have been created for the following stage in tables.
TABLE OBJECTS
STAGE_IN_ACCOUNT com.chordiant.collections.staging.businessclasses.
StageInAccount
STAGE_IN_PARTYINFO com.chordiant.collections.staging.businessclasses.
StageInPartyInfo
STAGE_IN_CONTACTINFO com.chordiant.collections.staging.businessclasses.
StageInContactInfo
CollectionsCaseOutput
The CollectionsCaseOutput object is a POJO that contains all of the objects that populated from the stage in
data. These objects are need to create a collections case.
PartyWrapper
The PartyWrapper contains objects that are in one way or another associated to a Party. By grouping these
objects together it simplifies the object creation since they are all reliant on each other. This allows us to
pass these related objects around together in a group.
ContactInfoWraper
The ContactInfoWraper the contact info and case party contact info that need to be created together.
Customization Pattern
• Input Object: The CollectionsCaseInput object can be extended to include any additional data or to
simply change attribute mappings to the host data.
• Output Object: The CollectionsCaseOutput object can be extended to include any additional output
provided. This customization would require a new builder to populate the output accordingly. The
consumer of the builder in the out of the box application is the CollectionsCaseServiceImpl. This class
would need to be customized to use the extended output accordingly. The service should be customized
following the Chordiant customization guidelines.
• Builder: The CollectionsCaseBuilder can be extended to meet any custom requirements by extending
the input or output objects. In order for the collections system to use the extended builder modify the
ObjectBuilders.xml to point to the custom builder.
For example:
<Section>ObjectBuilders
<Tag>CollectionsCaseBuilder
<Value>com.customer.collections.builder.CustomCollectionsCaseBuilder</Value>
</Tag>
</Section>
The following diagram illustrates the Import Collections Dialer API high level design:
The following diagram illustrates how the Import Collections Dialer API works:
CollectionsCaseService
The CollectionsCaseService is the consumer of the CollectionsDialerBuilder. The following new method
will be added to this service.
CollectionsDialerBuilder
The CollectionsDialerBuilder is responsible for populating objects that are needed to save dialer information
in the Collections system. These objects are populated with data that comes from the stage in tables. This
singleton class will instantiate the class that is defined in the
config/chordiant/components/master/ObjectBuilders.xml.
CollectionsDialerInput
The CollectionsDialerInput object is a POJO that contains all of the data that the builder will need to
populate the objects needed to save dialer information in the Collections system. For the out of the box
Collections applications java objects have been created for the following stage in table.
TABLE OBJECTS
STAGE_IN_DIALER com.chordiant.collections.staginginterface.
businessclasses.StageInDialer
The CollectionsDialerInput object has setter and getter methods for the following private member variable:
- private com.chordiant.collections.staginginterface.businessclasses.StageInDialer stageInDialer;
CollectionsDialerOutput
The CollectionsDialerOutput object is a POJO that contains all of the objects that were able to be populate
from the stage in data. These objects are need to save dialer information in the Collections system. The
CollectionsDialerOutput object has setter and getter methods for the following private member variables.
<!--
###########################################################################
# Configuration: ObjectBuilders
#
# Description: Defines the object builders that are used by the system.
# Builders are responsible for taking some input data and
# populating java objects appropriately. It is up to the
# implementation to decide out the objects are populated.
# Custom implementations can be added to this section.
###########################################################################
-->
<Section>ObjectBuilders
<!--
############################################################################
# Variable: CollectionsDialerBuilder
#
# Valid values: Class name providing an implementation for the builder
#
# Default value: com.chordiant.collections.objectbuilder.CollectionsDialerBuilder
#
# Description: The CollectionsDialerBuilder is responsible for building
# all of the objects necessary to save collections
# dialer information.
############################################################################
-->
<Tag>CollectionsDialerBuilder
<Value>com.chordiant.collections.objectbuilder.CollectionsDialerBuilder</Value>
</Tag>
</Section>
R e t r i e v e U s e r P r o f i l e D a ta A P I
The Retrieve User Profile Data API retrieve the Role Names, Resource Names, and Group Names that are
associated to a user in the system. This API allows user profile data to be sent to any piece of CDM decision
logic to in turn make decisions based on user profile data.
The CDM vocabulary will include this object for logic use and it is the logics’ responsibility to know the
possible values. Logic possible value knowledge can be accomplished by creating a lookup table containing
all valid Role Names, Resource Names, and Group Names.
Resources and Groups can be defined in a tree structure and the name of the Resource or Group may not be
unique. As a result, the RESOURCE_NAMES and GROUP_NAMES lookup tables must have a
FULLNAME column that contains the full path to the associated Resource or Group. For example:
Activities
Collections
IdentifyParty
VerifyParty
Disputes
IdentifyParty
VerifyParty
If the User is a Collections agent, they should have access to the Collections Activities. The
RESOURCE_NAMES.FULLNAME lookup table column would contain the following choices for the logic
developer to choose from in order to be unique:
• Activities/Collections/IdentifyParty
• Activities/Collections/VerifyParty
Note: This same concept is used for Groups as well; Group Names contain the Group directly
associated to the user and also include the Groups related to the user.
/**
* <pre>
* Retrieves a fully populated UserProfileData object.
* The UserProfileData object is intended to be used as an input bean for cdm logic to use.
* This method will internally use the UserProfileClientAgent to populate the UserProfileData object.
* The following unchecked exception could be thrown by this api.
* - @see java.lang.IllegalArgumentException, theUserName cannot be null or empty.
* </pre>
*
* @param username The username of the agent logged into the system.
* @param authenticationToken The authentication token used to validate the user that is logged into the system.
* @param theUserName The user name required to get the user profile data.
* @return UserProfileData the fully populated UserProfileData object.
* @throws ServiceException The service method encountered and unexpected Exception.
* The cause of this exception could be an error retrieving the service, RegistryConnectorException or
UserProfileSecurityException.
* We are throwing this in case the consumer of this api needs to react differently if this occurs.
* @see UserProfileData
* @see ServiceException
* @see RegistryConnectorException
* @see UserProfileSecurityException
*/
public com.chordiant.collections.cdm.beans.UserProfileData retrieveUserProfileData(String username, String
authenticationToken, String theUserName) throws ServiceException
Multi-Product Support
CollectionsLayoutFactoryBean.java is defined to instantiate the LayOut manager based on the product type.
This helps in including pages based on the product type in tab area, thumbnail area, and account identifier
area in order to display the content based on product type. This bean holds the product type and is in
application scope.
#Product Types
creditcard=CC
utilitydebtwater=UWTR
utilitydebttax=UTAX
utilitydebtelectricity=UEL
utiliytdebttelco=TELCO
autoloan=AL
homeloan=HL
finloan=FIL
The following method of CollectionsLayoutFactoryBean.java instantiates the layout manager (for example
for Utilities):
/**
* @return the isUtilityProductSeleted
*/
private boolean isUtilityProductSeleted(String productType)
String typeWater = (String) ChordiantFacesContext.getValueFromBackingBean
(CollectionsCommonConstants.COLLECTIONS_COMMON_PROPS,
CollectionsCommonConstants.COLLECTIONS_UTILITYDEBT_WATER);
if(typeWater.equalsIgnoreCase(productType.trim()) ||
typeTax.equalsIgnoreCase(productType.trim()) ||
typeEle.equalsIgnoreCase(productType.trim()) )
|typeTelco.equalsIgnoreCase(productType.trim()))
return true;
else
return false;
}
By using the ProcessPanelLayoutManager we can define different templates based on the product. This will
help in adding or removing the tabs in tab area. The following example loads the different
processpaneltemplate for secured debt products.
LayoutManager.java:
/**
* Gets the LayoutTemplate based on Product
* @return The file path and name to the file that will define the layout for the view
*/
public final String getLayoutTemplate() {
String productType = getProductType();
/**
* Check the product type, if it is Secured debt type
* Set the Secured debt layout template or else normal layout template
*/
if(isAutoLoanProductSeleted(productType))
setLayoutTemplate(getSdLayoutTemplate());
/**
* Gets the LayoutTemplate for Secured Debt
* @return the sdLayoutTemplate
*/
public final String getSdLayoutTemplate() {
return sdLayoutTemplate;
}
faces-config-bean.xml:
<managed-bean>
<managed-bean-name>processPanelLayoutManager</managed-bean-name>
<managed-bean-class>bundles.collectionscommon.jsf.classes.ProcessPanelLayoutManager</managed-bean-class>
<managed-bean-scope>application</managed-bean-scope>
<managed-property>
<property-name>layoutTemplate</property-name>
<value>/iAdvisorWeb/bundles/collections/layout/processpaneltemplate.jspx</value>
</managed-property>
<managed-property>
<property-name>sdLayoutTemplate</property-name>
<value>/iAdvisorWeb/bundles/sdcollections/layout/processpaneltemplate.jspx</value>
</managed-property>
<managed-property>
<property-name>processHeaderContent</property-name>
<value>/iAdvisorWeb/bundles/collectionscommon/jsf/processHeader.jspx</value>
</managed-property>
<managed-property>
<property-name>processFooterContent</property-name>
<value>/iAdvisorWeb/bundles/collectionscommon/jsf/processFooter.jspx</value>
</managed-property>
</managed-bean>
Activities for different products can be controlled independently based on the role of the logged in Agent.
The resources are added for each activity and each product separately.
The absolute resource path for the various product types is:
• CC product: Activities/Collections/CC
• Utility Debt product: Activities/Collections/UD
• Secured Debt product: Activities/Collections/SD
Note: The resources under “Activities/Collections” path are used for Credit Card product types.
For common resources such as CollectionsAgentInbox and Queuemanager, The
“Activities/Collections” path is used for all products.