The system periodically monitors how much your taxpayers owe to ensure they haven’t violated your collection rules. When a violation is detected, the system initiates the appropriate activities (e.g., letters, collection agency referrals, and eventually write off). The topics in this section describe how to configure the system to manage your overdue processing and collection requirements.
Collecting on unpaid debt. The overdue processing module has been designed to collect on virtually anything from an unpaid bill to an unmatched financial transaction. You tell the system what you collect on by configuring the various overdue processing control tables.
Straightforward rules = straightforward set up. Setting up this module is as challenging as your organization’s collection rules. If you have simple rules, the set up process will be straightforward. If your rules are complicated (e.g., they differ based on the type of taxpayer, the age of debt, the type of tax, etc.), your setup process will be more challenging.
Note: The terms “customer” and “taxpayer” may be used interchangeably in this chapter.
Contents
Case Study - Collecting On Overdue Debt
How Does The Overdue Monitor Work?
The Big Picture Of Overdue Processes
The following topics introduce a case study that describes how overdue processing can be used to collect on overdue debt. This is just an example as virtually every aspect of overdue processing is configurable. Use this case study to familiarize yourself with the overdue processing core concepts.
The following diagram illustrates the objects and processes involved with collecting overdue debt.
There are many important concepts illustrated above:
The Overdue Monitor checks if your accounts have debt that violates your overdue rules |
The Overdue Monitor is a background process that periodically reviews your account's financial obligations. Note well: every account belongs to a collection class. Collection classes are monitored by the Overdue Monitor. This chapter describes the Overdue Monitor. |
Overdue rules define when and how unpaid debt is collected |
An account's collection class overdue rules have algorithms that monitor an account's financial obligations. These algorithms are invoked by the Overdue Monitor when it's time to review an account's obligations. These algorithms can contain any type of criteria. When you set up a monitoring algorithm, you define the type of overdue process that should be created when overdue debt is detected. You do this by defining the appropriate “overdue process template”. |
An overdue process template defines how to handle overdue debt |
An overdue process template contains one or more overdue event types. These define the number and type of events that are created to prod the taxpayer to pay. For example, you might set up an overdue process template with event types to send a series of letters followed up by a call. The overdue process template has contains the rules defining when events are activated. The specific action that's performed by an overdue event is controlled by the Activation algorithm defined on its event type. Refer to Overdue Event Type - Main for a list of the various Activation algorithms delivered with the base product. |
Multiple objects can be associated with a single process |
The above diagram shows a single assessment linked to an overdue process. It should be noted that an overdue process is capable of referencing multiple assessments (or other objects). Note well: while a single overdue process can reference many overdue objects, all such objects must be of the same type. For example, you cannot commingle bills and obligations under a single overdue process. The type of object managed by an overdue process is defined on its overdue process template. |
If a taxpayer pays the debt, the overdue process is cancelled |
If the overdue debt is paid, the overdue process is canceled real-time. You control if and how an overdue process is cancelled by setting up the appropriate rules on the overdue process template. |
The Overdue Event Manager activates and triggers overdue events |
The Overdue Event Manager is a background process that activates overdue events on the appropriate date. On this date, the event's Activation algorithm(s) are called. This Overdue Event Manager also has the responsibility of recursively activating later events that are dependent on the completion of earlier events. |
Events can be activated real-time |
Overdue Process - Main has a button that allows users to activate (and recursively trigger) overdue events online / real-time. This means you don't have to wait for a batch job to activate events. |
Overdue events can wait for related activities to complete |
As described above, an overdue event's Activation algorithm can create virtually any object. What wasn't explained is that the event can be set up to wait for the ancillary object to finish before it completes. For example, an event can create a To Do entry and wait for it to complete before the next event is triggered. You can introduce plug-ins to create and wait on virtually any object. While an overdue event is in the Wait state, the Overdue Event Manager monitors the state of the related object(s). When the related object completes, the event is transitioned to the Complete state (thus triggering dependent overdue events). Please see Some Events Wait For Something Before Completing for more information. |
This section describes how the Overdue Monitor background process (batch control: C1-ADMOV) uses your overdue rules to collect overdue debt.
Recommendation. We recommend that you familiarize yourself with the concepts described in the case studies before reading this section.
Different Overdue Rules For Different Taxpayers
Overdue Rules Are Embodied In Algorithms
Collection Class Defines If And How Accounts Are Monitored
The Overdue Monitor uses rules to control how it monitors an account's debt. The system allows you to define different rules for different combinations of collection class, division and currency code. For example,
· You may have different collection rules for different jurisdictions (i.e., divisions).
· You may have different collection rules for different taxpayer segments. You differentiate your taxpayers in respect of the overdue via the collection class on the taxpayers’ accounts. An account’s initial collection class is defaulted from its account type. You may override an account’s collection class at will.
· You may have different criteria for every currency in which you work because the monitoring process always compares a taxpayer’s debt against some value and this value must be denominated in the taxpayer’s currency. A taxpayer’s currency is defined using a currency code on the account.
Your organization's overdue rules are defined in algorithms plugged in on Collection Class Overdue Rules (in the Overdue Monitor Rule system event). When the Overdue Monitor analyzes an account, it uses the rules associated with the account's collection class, division and currency code. To analyze an account, it simply invokes these algorithms in sequence order, i.e., the lower the sequence, the higher its priority.
An Overdue Monitor Rule algorithm has two responsibilities:
· it determines if an account violates its overdue rules,
· if so, it creates one or more overdue processes using an overdue process template
Additional rules. Your implementation can have an Overdue Monitor Rulethat caters for credit balances on obligations. For an example of an algorithm that creates an overpayment process for an obligation in credit, please refer to the base algorithm type C1-CC-INITOP.
The Overdue Monitor determines if an account violates your overdue rules at least every X days, where X is defined on the Account Type - Controls associated with the account’s account type and division (in the field Min Compliance Review Freq (Days)).
In addition, the Overdue Monitor examines an account’s debt as follows:
· X days after an account’s bill due date (X is defined in the field Compliance Review Grace Days on account type control).
· If a payment is canceled with a cancellation reason that indicates non-sufficient funds.
· If a match event is added, changed or deleted.
Additional events. Your implementation can have other events trigger the analysis of an account by the Overdue Monitor such as the freezing of an FT that affects the account balance. To do this, add logic to insert a row on the CI_ADM_RVW_SCH table when the event occurs. This row simply references the account ID to be reviewed and the desired review date. For an example of triggering review at FT Freeze time, please refer to the base algorithm type C1-CFTZ-CMRV.
As described above, every account references a collection class. The collection class defines if and how its accounts are monitored. There are the following options:
· The accounts are monitored by the Overdue Monitor (this is described in this chapter).
· The accounts are not monitored for overdue debt.
As described above, the Overdue Monitor subjects your accounts to overdue rules. If a rule is violated, an overdue process is created. The topics in this section provide background information about overdue processes.
Contents
How Are Overdue Processes Created?
The Components Of An Overdue Process
Experimenting With Alternative Overdue Process Templates
Overdue Process Information Is Overridable
Overdue Processes Are Highlighted Elsewhere
How Are Overdue Processes Cancelled?
Overdue Processes Are Created From Templates
The Big Picture Of Overdue Events
The Big Picture of Collection Cases
The Big Picture Of Collection Agency Referrals
Write Offs Are Implemented Using Overdue Events
As described above, the system creates an overdue process when an account violates your overdue rules. In addition, a user can manually create an overdue process at their discretion.
The following topics describe the major components of an overdue process.
Contents
When an overdue process is created, the system links the overdue object(s) to the process. For example, if an overdue bill is detected, the bill is linked to the overdue process.
When you set up an overdue process template, you define the type of object it collects on by defining the foreign key characteristic type used to reference the object. For example, when you set up an overdue process template to collect on bills, you define a foreign key characteristic type that references the bill object.
An overdue process has one or more overdue events. These events are the actions designed to encourage the taxpayer to pay. For example, you might set up overdue events that:
· Send letters (via the creation of a customer contact)
· Create To Do entries
· Impact the account's compliance rating
· Create a collection case to manage actions such as creating pay plans and referring debt to collection agencies
· … (the list is only limited by your imagination as algorithms are used to perform the event's actions)
You define the number and type of events by configuring overdue process templates. When the system creates an overdue process, it copies the events defined on the specified template.
It’s important to note that all overdue events are created when the overdue process is created. A separate background process, the Overdue Event Manager, is responsible for activating, monitoring, and triggering overdue events. Activation of an event causes the system to do whatever the event indicates; for instance, send a letter, send a To Do entry to a user or write-off debt.
Every overdue process has a log holding its history. Entries are added to the log when meaningful events occur, for example:
· When the process is created, a log entry is created to describe why the process was started.
· When an overdue event is activated, a log entry is created. These entries frequently contain a foreign key to the object that the event created so that users can easily drill down to the object from the log. For example, if an event creates a To Do entry, the To Do entry's foreign key is placed on the log and this allows a user to drill down on the log entry to see the To Do entry.
· When a process is canceled, a log entry is created to describe the circumstances of the cancellation (e.g., manual versus automated).
· Users can manually add log entries (you might want to think of these as "diary" entries) as desired.
Many of the base-product algorithms involved in overdue processing insert log entries so that a thorough audit trail is maintained. These algorithms have been designed to allow you to control the verbiage in each log entry by defining the desired message number using an algorithm parameter.
The log is viewable on the Overdue Process - Log page.
More than just an audit trail. Please note that the log entries are more than just an audit trail. The system makes use of the log entries to know what it did. For example, when an overdue event needs to monitor the state of the To Do entries that it created, it uses the log to determine the identity of these To Do entries.
The system allows you to determine the efficacy of proposed overdue process templates using a small subset of taxpayers before implementing the templates on the entire taxpayer base. We use the term "champion / challenger" to reference this functionality.
We'll use an example to explain. Let's assume your prevailing overdue process template for individual taxpayers starts with a "gentle reminder" letter followed 10 days later by a letter threatening to place a lien to secure the debt if payment is not received. You may want to experiment with the impact of a change to this template. For example, you may want to change the "gentle reminder" to something more assertive and follow this up 5 days later with an even sterner warning. You can use the "champion / challenger" functionality to perform this experiment.
The following points describe how to implement "champion / challenger" functionality:
· Set up a "challenger" overdue process template for each template that you want to experiment with.
· Insert a new Champion/Challenger option on the Overdue Processing Feature Configuration for every champion template. Each option's value defines:
· the "champion" overdue process template code
· the "challenger" overdue process template code
· the percentage of the time the system should use the "challenger" template
Keep in mind that you can only experiment with one challenger template per champion template.
After setting up the above, the Overdue Rule Plug-In will use the challenger template X% of the time rather than the champion template.
If you are using the Oracle Utilities Business Intelligence product, you can configure analytic zones in innumerable ways to compare the efficacy of the champion versus the challenger. For example,
· You can set up a graph to show the average duration of each type of process.
· You can set up a graph to show the average dollars that were successfully collected.
· You can set up a dimensional scorecard to show how each template performed in different regions (or account types or …).
· Etc (the list is limited by your imagination)
“Overdue process info” is the concatenated string of information that summarizes an overdue process throughout the user interface. The base-product logic constructs this string by concatenating the following information:
· The description of its overdue process template
· Its status
· For active processes, the number of days since it was created. For inactive processes, the number of days since it was inactivated.
· For active processes, the unpaid amount of the objects being collected
If you'd prefer a different info string, you can develop a new algorithm and plug-it in on your overdue process templates. This design allows some / all overdue process templates to have an override info string.
There are two amounts associated with each overdue object linked to an overdue process: its Original Amount and its Unpaid Amount. These amounts are used throughout overdue processing.
You control how these amounts are calculated by defining the appropriate algorithm on your overdue process templates. For example, you can plug in a base-product algorithm (C1-OBASM-AMT) if you collect on overdue assessments or obligations. The base algorithm uses the Obligation Type - Determine Detailed Balance algorithm to calculate the amounts.
The topics in this section describe how other parts of the system highlight the existence of overdue processes.
If you plug-in the appropriate alert algorithm (C1-OD-PROC) on the Installation record, alert(s) will be shown for active overdue processes in the Alert Zone that appears in the Dashboard and on Control Central - Account Information.
The Compliance zone on Control Central - Account Information shows active overdue processes.
The Account Activity History Zone on Control Central - Account Information shows pending and waiting events and inactive processes.
A user may cancel an overdue process at their discretion, online / real-time using Overdue Process - Main.
The system will automatically cancel an overdue process when the object(s) associated with the overdue process are sufficiently paid. Exactly when the system checks if an overdue process should be cancelled is dependent on your organization's billing and accounting rules. For example, if you practice open-item accounting, you'd want to analyze an account's active overdue processes whenever a match event is added, changed or deleted (as match events are the only objects that impact if debt is considered paid in an open-item world). The base-product supports this specific example. Alternatively, if you plug in the base product Account Type - FT Freeze algorithm (C1-CFTZ-CMRV), an account's overdue processes will be reviewed for cancellation whenever a credit FT is frozen for the account. If you need additional events to check if an overdue process should be canceled, a base-product change MAY be necessary. Please check with customer support if you have questions.
Two algorithms plugged-in on the overdue process template handle the cancellation:
· The Cancel Criteria algorithm is responsible for determining if an overdue process should be canceled. Algorithms of this type analyze the outstanding debt on the objects linked to the overdue process and indicate whether a process can be cancelled.
· The Cancel Logic algorithm is responsible for actually canceling the process. The logic involved in cancellation can be quite sophisticated as canceling an overdue process can result in the cancellation of its pending events.
Why two algorithms? The reason two algorithms are involved in cancellation is that we want the cancellation logic to be encapsulated in one place so it can be called during both manual and automated cancellation.
Different logic for different templates. Because both the Cancel Criteria and Cancel Logic algorithms are plugged-in on the overdue process's template, you can have different cancellation criteria and logic for different templates.
As described above, you set up overdue process templates to define the types of events and when they are executed. When an overdue process is created, its events are created by copying the event types from an overdue process template. The remaining topics in this section provide background information to assist you in setting up your templates.
This section describes the various types of overdue events and their lifecycle.
Contents
How Are Overdue Events Created?
Overdue Events Can Do Many Things
Overdue Event Information Is Overridable
Overdue events are created as follows:
· The Overdue Monitor invokes Overdue Monitor Rules to periodically check your accounts (refer to Overdue Rules Are Embodied In Algorithms for how this works). An Overdue Monitor Rule creates an overdue process when an account violates your overdue rules. The overdue process has one or more overdue event(s). The number and type of events is controlled by the overdue process template specified on the Overdue Monitor Rule.
· Users can create an overdue process manually on Overdue Process - Main. To do this, they specify an overdue process template. The number and type of overdue events is defaulted from the template.
· An overdue event may be manually added to an existing overdue process by a user on Overdue Process - Events.
Bottom line. Most overdue events are created by the system when it creates an overdue process for delinquent debt. If you need to create an ad hoc overdue event, you can either create an overdue process whose template contains the desired event OR link the desired event to an existing process.
An overdue event can perform a wide number of activities as the logic is embodied in an algorithm. The following points describe how this works:
· Every overdue event references an overdue event type.
· The overdue event type, in turn, references an Event Activation algorithm.
· The Event Activation algorithm is invoked when the event is triggered.
“Overdue event info” is the concatenated string of information that summarizes an overdue event throughout the system. The base-product logic constructs this string by concatenating the following information:
· The event type's description
· The event's status
· If it's pending:
· If the event has a trigger date, the number of days until it's triggered plus the verbiage day(s) from today
· Otherwise, the verbiage dependent on other events
· If it's waiting, the number of days, hours and minutes that it's been waiting
· If it's canceled, the cancel reason code's description
· If it's complete, the number of days, hours and minutes that it's been complete
If you'd prefer a different info string, you can develop a new algorithm and plug-it in on your event types. This design allows some / all event types to have an override info string.
The following diagram shows the possible lifecycle of an overdue event:
Overdue events are initially created in the Pending state. An event can take myriad paths after it's created; it all depends on how you've configured the system. The following topics describe an event's lifecycle:
Contents
How and When Events Are Activated
Activating Events Should Add A Log Entry
Some Events Wait For Something Before They Activate
An overdue event contains the date it should be activated; this is referred to as its trigger date. On this date, the Overdue Event Manager (a background process (C1-ODET)) invokes the Event Activation algorithm plugged-in on the event's event type. The Event Activation algorithm, in turn, will decide on the state in which to leave the overdue event (e.g., it may transition it to the Complete state or the Waiting state).
If a user can't wait for the Overdue Event Manager real-time, they can click a button on Overdue Process - Main to activate (and recursively trigger) events online / real-time.
You control how an event's trigger date is populated by configuring the overdue process template. You are given two choices when you link an event type to an overdue process template:
· You can indicate the event should be assigned a trigger date when it is first created. You'd use this approach on the first event and events with no dependencies on earlier events. The following points describe how to configure the overdue process template to do this:
· Indicate the event type is NOT dependent on other events, and
· Define the number of days after the process's creation to use when calculating the trigger date.
· You can indicate the event should be assigned a trigger date only after earlier events are Complete. This technique should be used whenever you have an event that is only executed after other events are Complete. The following points describe how to configure the overdue process template to do this:
· Indicate the event is dependent on other events, and
· Define the number of days after the completion / cancellation of all dependent event(s) that the trigger date should be set to. The Overdue Event Manager sets the trigger date on such an event when it detects that all of its dependent events are complete / canceled.
Calendar vs. Workdays. When an overdue event is created by the system, its trigger date is set in accordance with your date arithmetic preferences. Refer to Calendar vs. Work Days for more information.
As described above, an overdue process has a log holding a history of meaningful events in the process's life. Most Event Activation algorithms will add an entry to the process's log.
These log entries are more than just an audit trail as they also reference the objects that are created during activation. For example, if an activation algorithm creates a customer contact, the ID of the customer contact will be referenced on the log (and end-users will be able to drill down on the log entry to see the customer contact).
You can prevent a pending event with a trigger date on / before the current date from activating by plugging-in a Hold Event Activation plug-in on the overdue process template. This might prove useful, for example, if you want to suspend an overdue process while another process, such as an appeal by the taxpayer, is outstanding. Then, when the other process is complete, the overdue process can start up where it left off. Currently the base provides an algorithm type (C1-HIOCE) to suspend an overdue process while an account is linked to an open case of a given type.
Consider this scenario - you want an overdue event to create a To Do entry so a user can authorize the next phase of an overdue process. When this event activates, the event's activation algorithm will create a To Do entry, but it will NOT transition the event to complete. Rather, the overdue event will exist in the waiting state. While in the waiting state, the Overdue Event Manager will monitor the state of the To Do entry. When the To Do entry completes, the original overdue event can transition to the complete state and then latter dependent events can be triggered. The following points describe how to configure the system to support this type of event:
· The event type's Event Activation algorithm should behave as follows:
· It creates the object on which the overdue event waits.
· It must link this object to the overdue process by creating a log entry where the prime-key of the related object is referenced (in a foreign-key characteristic). This log entry should also reference the event.
· It should leave the overdue event in the waiting state.
· The event type must have a Monitor Waiting Event algorithm. This algorithm is invoked each time the Overdue Event Manager executes. If the related object has transitioned to a "final" state, the originating overdue event is transitioned to the complete state (and then latter dependent events are triggered).
Bottom line. Two algorithms must be set up on an overdue event type to implement waiting functionality: an Event Activation algorithm that creates the monitored object and a Monitor Waiting Event algorithm to check on the state of the monitored object. The Overdue Event Manager has the dual responsibility of activating the event and monitoring its related object for completion (and then triggering the dependent events when it completes).
While the above example illustrated how an overdue event could create and then monitor a To Do entry, you can use this functionality to create and monitor any object that has an initial and final state. If the base product does not contain the algorithms you need, simply develop new ones using the base-product algorithms as examples.
A pending event will be cancelled automatically by the system when the overdue process is canceled. Refer to How Are Overdue Processes Cancelled for more information.
A user may cancel a pending or waiting event at their discretion.
Regardless of what triggers the cancellation, the Cancel Logic algorithm plugged in on the overdue event type handles the cancellation. This allows you to introduce additional cancellation logic should the need arise. Please note that the base product cancel algorithms insert a log entry when a user manually cancels an event.
In many tax authorities collecting unpaid debt is typically done in two phases: a series of unmonitored actions, typically letters, attempting to convince the taxpayer to pay, and a series of user-oriented actions such as contacting the taxpayer, setting up payment plans, and referring debt to a collection agency. The user-oriented actions are handled using a collection case. While not required, it is expected that many overdue processes will create a collection case when the overdue events did not prompt payment of the debt.
The topics in this section provide background information about collection cases.
Contents
How Are Collection Cases Created?
How Are Collection Cases Closed?
Overdue Events Wait For The Collection Case To Conclude
Collection Case Type Defines Parameters
A collection case provides the functionality to record and track the interactions between the taxpayer and the user responsible for the collection. Many actions can take place once a collection case is created:
· A lien may be placed to secure the debt
The activation of an overdue event creates a collection case. It is possible for an overdue process to be linked to more than one collection case over time but only one collection case can be active for an overdue process at a given time. The base package provides a sample overdue event activation algorithm (C1-CR-COL-CS) to create a standard collection case.
Collection cases are created for persons not accounts. It is possible for collection cases that are linked to different overdue processes to be consolidated into a single case.
It is important to note that a collection case exists with respect to one or more overdue processes. A collection case's overdue process defines the objects in arrears. These objects are monitored to determine if the overdue process can be cancelled and the collection case can be closed.
The lifecycle of the collection case depends upon the configuration of the associated business object. The base package includes a sample standard collection case with a simple lifecycle, as follows:
· The collection case is initially created in the Pending Investigation state.
· The case will transition to the Actions In Progress state the first time a user initiates an action, such as creating a pay plan or sending a letter. Since many collection case actions happen in parallel, the expectation is that the case remains in this state until closed. Monitoring algorithms can be configured to check whether any of the actions in progress for the case have been waiting too long.
· The case may be Transferred to another collection case type or to an existing collection case.
· The user can manually transition the collection case to the Uncollectible state if they determine that no further action is to collect the debt is possible.
In addition to the standard actions for edit and state transition, a collection case may have special actions that apply to this type of collection, such as creating a pay plan or a collection agency referral. Additional actions are configured via the maintenance UI map. Refer to the base business objects for further details of the sample configuration.
Collection cases can be closed at the user's discretion or when the associated overdue process is cancelled. The base package provides a sample Cancel Logic algorithm (C1-CL-COLLCS) that closes any open collection cases linked to the process provided there are no other active overdue processes for the case.
Overdue events that create collection cases are perfect examples of events that wait for the object they create to complete before they, in turn, complete. After the collection case concludes, the originating overdue event will complete thus triggering its dependent events, such as writing off the debt. The base package provides a sample Monitor Waiting Event algorithm that checks whether all collection cases associated with the overdue process are in a final state.
For each type of collection case, you must configure a collection case type to capture the appropriate parameters needed by the collection case actions. Typical parameters include:
· The To Do Type used to notify the responsible user that a new collection case has been created
· The default pay plan type to be used for a collection case of this type
· The To Do Types to be used to notify the responsible user if certain actions have been outstanding for too long without a response, such as a collection agency referral with no updates.
Before debt is written off, many implementations refer the unpaid debt to a collection agency. The following topics describe how collection agency referrals are managed.
Contents
Collection Agency Referrals Overview
How Are Collection Agency Referrals Created?
Cancelling Collection Agency Referrals
The system creates a Collection Referral record for a collection agency to track the debt that is to be collected. A collection referral is linked to an account. Collection referrals have history records that contain the amount of debt referred to the agency. Creating a history record triggers the interface of information to the collection agency. The method used to interface the information to the agency is defined on the collection agency’s record. Refer to Setting Up Collection Agencies for more information.
Users can create collection agency referral manually or by configuring an overdue event type with an activation algorithm that creates the referral. The base package sample activation algorithm (C1-OE-AGYREF) will refer the total unpaid debt for the overdue process to the collection agency with the least amount of referred debt. If you prefer different logic, you must develop your own algorithm.
In many tax authorities, creating a collection agency referral is one of the actions that would typically take place for a collection case. The base product BO for collection case C1-StandardCollectioncase can be used as an example of how to include the functionality to create a collection agency referral and link it to the collection case.
Collection agencies are notified of the cancellation of a referral by the creation of a new collection agency referral history record (with a type of cancel). This record will be interfaced to the agency in the same manner used to interface a new referral (see above). You can cancel a referral manually by simply creating a new collection agency referral history record (with a type of cancel).
If the collection agency is successful in obtaining the funds, a payment will be added. If the payment satisfies the cancel criteria defined on the overdue process template's cancellation plug-in, the overdue process will cancel. When an overdue process is cancelled, the cancel criteria on the overdue process's template are executed. If your implementation chooses to create collection agency referrals via overdue events, we strongly recommend plugging in an algorithm that will cancel the referrals when an overdue process is cancelled. If you choose to manage collection agency referrals via collection cases, the base package provides a sample business object status Enter algorithm (C1-CCC-AGCYR) to cancel any referrals linked to the collection case when it is closed.
If the collection agency is not successful in obtaining your funds after a given amount of time, you probably want to cancel the referral and write-off the debt. If your implementation chooses to create collection agency referrals via overdue events, you set can set up your overdue process template to have an event that creates a collection agency cancellation X days after the referral. The base package provides a sample event activation algorithm (C1-OE-AGYCAN) to cancel all active collection agency referrals associated with the overdue process
Log entry. The base-product overdue event activation algorithms that make and cancel collection agency referrals insert rows in the overdue process's log to audit these events.
The system has been designed to allow overdue events on the original overdue process to write-off the objects being collected.
Contents
Starting Write-Off Oriented Events
Write Offs And Overdue Process Cancellation
While the system provides overdue event activation algorithms that manage write-off oriented actions, such as referral to collection agency, tax authorities typically handle those actions as part of collection case activity.
Most overdue process templates will be configured to contain an event that writes-off the unpaid balance of the debt. This event should be configured to be dependent on the event that created the associated collection case. A Monitor Waiting Eventalgorithm can detect the collection case is closed and complete the waiting event. This allows the subsequent write off event to be triggered.
Many organizations will write-down a debt whose value is small early in an overdue process. The base package overdue event activation algorithm to write off assessments (C1-WRITE-OFF) includes a parameter to support this requirement. (For example, indicate that you should write down an overdue process's assessment if their value is less than a threshold amount).
If your organization writes-down small amounts differently than large amount, simply set up an overdue event type to reference such an activation algorithm and position it in the appropriate place in the overdue process template.
If an overdue event writes off debt, the state of the process depends on your cancel criteria and where the overdue event is positioned in the overdue process. For example, if an overdue process has an overdue event that writes off small amounts of debt early in the process, a process whose debt meets the threshold criterion will be canceled when the event activates.
Contrast this to an overdue process where the last event writes off the debt. Because there are no other events to activate, the process will complete (i.e., it will not be canceled).
When you set up your overdue templates, you supply information that controls how the event's trigger date is calculated. You have two options:
· You can say that an event's trigger date can only be populated after earlier, dependent events are complete. For example, the 2nd event is triggered 2 days after the 1st event is complete.
· You can say that an event's trigger date is populated when the process is first created. You simply define the number of days after the start of the process when each such event should be triggered. For example, the 2nd event can be triggered 7 days after the start of the process.
In addition to the above, an option defined on the Feature Configuration for Overdue Processing plays a part in the calculation of an event's trigger date:
· If you set the option to use calendar days, the trigger date of events will be set to the first workday on / after the calculated date. For example, if you indicate that the 2nd event is triggered 7 days after the 1st event, the system will add 7 days to the 1st event’s completion date. It then checks if this is a workday (and not a holiday); if so, this is the trigger date of the event; if not, it assigns the trigger date to the next workday.
· If you set the option to use workdays, the trigger date will be calculated by counting workdays. For example, if you indicate that the 2nd event is triggered 7 days after the 1st event, the system will count 7 workdays and set the trigger date accordingly.
Account's division controls the work calendar. The system uses the above information in conjunction with the work calendar associated with the account’s division to determine workdays.
Your overdue procedures define how your organization collects overdue debt. In this section, we describe how to set up the data that controls these procedures.
Warning! There are numerous ways to design your overdue procedures. Some designs will result in easy long-term maintenance; others will result in maintenance headaches. In this section, we provide information to help you understand the ramifications of the various options. Before you set up your overdue procedures, we encourage you to gain an intuitive understanding of these options by using the system to prototype the alternatives.
Contents
The above topics provided background information about how overdue processing works. The following discussion summarizes the various set up tasks.
Contents
Collection Class Overdue Monitor Rules
Collections - Installation Options
Alert To Highlight Active Overdue Processes
Alert To Highlight Active Collection Cases
Bill-Oriented Collection - Additional Set Up
You will find that most of the time spent setting up your overdue event types is spent setting up the objects that are referenced on the overdue event type algorithms. For example, if you use the base-product algorithms, you will set up the following:
· The various "types" for the objects created by the plug-ins. For example,
· If an overdue event type creates a To Do entry, you must set up the To Do type.
· If an overdue event type creates a customer contact, you must set up the customer contact type.
· Foreign key characteristic types that are used to reference the ancillary objects in the log entries (e.g., if an event creates a customer contact, the log references this customer contact using a FK characteristic type). Note, many of these will exist in the base-product.
· Messages that are used to define the verbiage in the log entries. For example, if you use the base-product algorithm that creates a customer contact, you must supply the desired message category and number that contains the verbiage that appears in the log when customer contacts are created. Note, messages have been set up for all base-product algorithms (this means you should not have to set up new messages).
The only way to compile the complete list is to design the parameters for each overdue event type algorithm. Refer to Overdue Event Type - Main for the supported plug-in spots.
After you've set up the objects referenced on the algorithms, you can then set up the algorithms. Only then can you set up the overdue event types.
After your overdue event types exist, you can set up your overdue process templates. You will find that most of the time spent setting up your overdue process templates is spent setting up the objects that are referenced on the overdue process template algorithms. Refer to Overdue Process Template - Main for the supported system events.
When setting up collection classes, make sure to indicate that these collection classes use the Overdue collection method (only accounts linked to collection classes designated as using the Overdue collection method or processed by the Overdue Monitor).
After your overdue process templates exist, you can set up your Overdue Monitor Rules. These rules are algorithms plugged in on Collection Class Overdue Rules. You will find most of the time spent setting up these algorithms is spent setting up the objects referenced on the base-product algorithm.
Control tables required to collect on overdue bills are described in Overdue Processing - Setup Tasks. For more information about collections installation options, refer to Installation Options - Collections.
The base product supplies the business object C1-StandardCollectionCase, which is designed to cater for collection cases that incorporate standard actions such as creating pay plans and collection agency referrals.
The base product also supplies the business object C1-StandardCollectionCaseType, which defines the configuration information used by the standard collection case. To enable this functionality the following configuration tasks are needed:
· Define an appropriate To Do type and To Do role for sending a notification that a new collection case has been created for an overdue process.
· Define a Customer Contact class and type that reference the default letter template to be sent to a taxpayer for a collection case of this type.
· Define an appropriate To Do type and To Do role for sending a notification that the maximum days to wait after sending a letter before additional activity should occur has been exceeded.
· Define an appropriate To Do type and To Do role for sending a notification that the maximum days to wait after referring debt to a collection agency has been exceeded.
· Define a default Pay Plan obligation type for collection cases of this type
· Define appropriate reasons for closing a collection case due to the debt being uncollectible. Uncollectible reasons are defined using a customizable lookup. The lookup field name is C1_COLL_CASE_UNCOLL_RSN_FLG.
· Define a collection case type for the business object C1-StandardCollectionCase
Your implementation can define additional business objects to support collection case processing.
You must set up a Feature Configuration to define parameters that control various overdue processing options. The following is an example of how the Feature Configuration would look for an implementation:
The following points describe the various Option Types that must be defined:
· Trigger Date: Y-Workdays, N-Calendar Days. This option controls how the system computes the trigger dates on overdue events. Enter Y if the system should use workdays. Enter N if the system should use calendar days. Refer to Calendar vs Work Days for the details.
· Champion Template$Challenger Template$Percentage(1-100). You need only set up options of this type if your implementation implements Champion / Challenger functionality. Options of this type are entered in the format A$B$nnn where A is the overdue process template of the champion template, B is the overdue process template of the challenger template, and C is the percent of the time that the system should create the challenger template. The overdue monitor rule algorithm uses this option to override the champion overdue process template X% of the time with the challenger template. You may enter any number of these options (but only one per Champion Template).
Overdue events can be cancelled automatically and manually (at the discretion of a user). Regardless of the method of cancellation, a cancellation reason must be supplied. You set up your overdue event cancellation reasons using Overdue Event Cancellation Reason - Main.
If you refer debt to collection agents, you must set up your collection agencies.
If you want an alert to appear if the account has active overdue processes, you must configure an appropriate Control Central Alert algorithm (C1-OD-PROC). This algorithm is plugged in on the Installation record.
If you want an alert to appear if the account has active collection cases, you must configure an appropriate Control Central Alert algorithm (C1-CCAL-COCS). This algorithm is plugged in on the Installation record.
The topics in this section provide information on additional set up requirements if you collect on unpaid bills.
Contents
Alert To Highlight Written Off Bills
A bill is considered paid if its financial transactions (FTs) are linked to a balanced match event. To determine a bill’s outstanding amount, FTs from different bills cannot be commingled on the same match event (but it’s OK for a bill’s FTs to be on multiple match events). If you stick by the rule of “just one bill per match event”, you will then be able to determine the outstanding balance of a partially paid bill. However, if you mix more than one bill under a match event, a particular bill’s balance may become indeterminate.
The following Open-Item algorithm types have been provided by the base product to help enforce this rule:
· The Distribute by Bill Due Date Payment Distribution algorithm (C1-PYDS-BDU).
· The match by Bill ID Payment Distribution Override algorithm (C1-PDOV-PYBL).
· The FT cancellation FT Freeze algorithm (C1-CFTZ-COFT).
If any of your customized plug-ins and processes create match events, it is important that these too enforce this rule. You may want to refer to the base product algorithms as an example of how to do this.
If you want an alert to appear if the account has bills with written-off debt, you must configure an appropriate Control Central Alert algorithm (C1-WO-BILL). This algorithm is plugged in on the Installation record.
You must set up the algorithm that computes the original, unpaid, and write-off amounts of your open-item bills. This algorithm is called by other algorithms when these amounts are needed. This algorithm is plugged-in on Installation in the Determine Open Item Bill Amounts spot.
The topics in this section describe how to set up the control tables to implement your overdue processing and collection procedures.
Contents
Setting Up Overdue Event Types
Setting Up Overdue Process Templates
Setting Up Collection Class Overdue Rules
Setting Up Overdue Event Cancellation Reasons
Setting Up Collection Case Types
Setting Up Collection Agencies
An overdue event type encapsulates the business rules that govern a given type of overdue event. Open this page by selecting Admin Menu, Overdue Event Type.
Recommendation. Before using this transaction, we strongly recommend that you review The Big Picture Of Overdue Events.
Description of Page
Enter a unique Overdue Event Type code and Description for the overdue event type.
Use Long Description to provide a more detailed explanation of the purpose of the overdue event type.
The Algorithms grid contains algorithms that control important functions. You must define the following for each algorithm:
· Specify the algorithm's System Event (see the following table for a description of all possible events).
· Specify the Algorithm to be executed when the System Event executes. Set the Sequence to 10 unless you have a System Event that has multiple Algorithms. In this case, you need to tell the system the Sequence in which they should execute.
The following table describes each System Event (note, all system event's are optional and you can define an unlimited number of algorithms for each event).
System Event |
Optional / Required |
Description |
Cancel Logic |
Required |
This algorithm is executed to cancel an overdue event. Refer to How Are Events Canceled for the details. Click here to see the algorithm types available for this system event. |
Event Activation |
Required |
This algorithm is executed to activate an overdue event on its trigger date. Refer to Overdue Events Can Do Many Things and How and When Events Are Activated for the details. Click here to see the algorithm types available for this system event. |
Event Information |
Optional - only used if you want to override an overdue event's info string |
This algorithm is executed to construct an overdue event's override info string. Refer to Overdue Event Information Is Overridable for the details. Click here to see the algorithm types available for this system event. |
Monitor Waiting Events |
Optional - only used if events of this type can enter the Waiting state |
This algorithm is invoked by the Overdue Event Manager for events in the Waiting state. Refer to Some Events Wait For Something Before Completing for the details. Click here to see the algorithm types available for this system event. |
Where Used
Follow this link to open the data dictionary where you can view the tables that reference CI_OD_EVT_TYPE.
An overdue process template encapsulates the business rules that govern a given type of overdue process. Open this page by selecting Admin, Overdue Process Template.
Recommendation. Before using this transaction, we strongly recommend that you review The Big Picture Of Overdue Processes.
Description of Page
Enter a unique Overdue Process Template and Description for the overdue process template.
Collecting On Object defines the type of object managed by this overdue process. This field actually references a foreign key characteristic type that references the managed object. For example, if this overdue process template manages overdue bills, you'd reference a foreign key characteristic that references the bill object.
The Algorithms grid contains algorithms that control important functions. You must define the following for each algorithm:
· Specify the algorithm's System Event (see the following table for a description of all possible events).
· Specify the Algorithm to be executed when the System Event executes. Set the Sequence to 10 unless you have a System Event that has multiple Algorithms. In this case, you need to tell the system the Sequence in which they should execute.
The following table describes each System Event (note, all system event's are optional and you can define an unlimited number of algorithms for each event).
System Event |
Optional / Required |
Description |
Calculate Unpaid & Original Amount |
Required |
This algorithm is executed to calculate the unpaid and original amounts of the objects associated with the overdue process. These amounts are shown on the overdue process page and in the base-product overdue info string. Click here to see the algorithm types available for this system event. |
Cancel Criteria |
Required |
This algorithm is executed to determine if an overdue process can be cancelled. Refer to How Are Overdue Processes Cancelled for the details. Click here to see the algorithm types available for this system event. |
Cancel Logic |
Required |
This algorithm is executed to cancel an overdue process. Refer to How Are Overdue Processes Cancelled for the details. Click here to see the algorithm types available for this system event. |
Hold Event Activation Criteria |
Optional - only used if overdue processes of this type can be suspended while some condition is true |
This algorithm is executed to determine if the activation of overdue events should be suspended. Refer to Holding Events for the details. Click here to see the algorithm types available for this system event. |
Overdue Process Information |
Optional - only used if you want to override an overdue process's info string |
This algorithm is executed to construct an overdue process's override info string. Refer to Overdue Process Information Is Overridable for the details. Click here to see the algorithm types available for this system event. |
The Event Types control the number and type of overdue events linked to an overdue process when it is first created. The information in the scroll defines these events and the date on which they will be triggered. The following fields are required for each event type:
· Event Sequence. Sequence controls the order in which the overdue event types appear in the scroll.
· Overdue Event Type. Specify the type of overdue event to be created.
· Days After. If Dep on Other Events is on, events will be triggered this many days after the completion of the dependent events (specified in the grid). Set this value to 0 (zero) if you want the event triggered immediately after the completion of the dependent events. If Dep on Other Events is off, events will be triggered this many days after the creation of the overdue process. Refer to How and When Events Are Activated for the details.
· If Dep on Other Events is on, define the events that must be completed or cancelled before the event will be triggered.
· Sequence is system-assigned and cannot be specified or changed.
· Dependent on Sequence is the sequence of the dependent event.
Where Used
Follow this link to open the data dictionary where you can view the tables that reference CI_OD_PROC_TMP.
Every account has a collection class. This class is one of several fields that control the collection method applied to the account’s debt. Open Admin Menu, Collection Class to define your collection classes.
Description of Page
Enter a unique Collection Class code and Description for each collection class.
Indicate a Collection Method of Overdue if the accounts belonging to this collection class are subject to overdue collection procedures. If accounts belonging to this collection class are not subject collection, select Not Eligible For Collection. Please be aware that these accounts will NOT be reviewed for overdue debt.
Where Used
Follow this link to open the data dictionary where you can view the tables that reference CI_COLL_CL.
Collection class overdue rules contain algorithm that impact accounts associated with a given collection class, division and currency code are managed. Open this page by selecting Admin, Collection Class Overdue Rules.
Recommendation. Before using this transaction, we strongly recommend that you review Different Overdue Rules For Different Taxpayers.
Description of Page
Enter the Collection Class, Division and Currency Code to which the rules apply.
The Algorithms grid contains algorithms that control important functions. You must define the following for each algorithm:
· Specify the algorithm's System Event (see the following table for a description of all possible events).
· Specify the Algorithm to be executed when the System Event executes. Set the Sequence to 10 unless you have a System Event that has multiple Algorithms. In this case, you need to tell the system the Sequence in which they should execute.
The following table describes each System Event.
System Event |
Optional / Required |
Description |
Overdue Monitor Rule |
Required |
This algorithm is invoked by the Overdue Monitor to analyze an account's debt. Refer to How Does The Overdue Monitor Work for the details. If you have multiple rules (and therefore multiple algorithms), please take care when assigning the sequence number, as the Overdue Monitor will invoke these rules in sequence order. Click here to see the algorithm types available for this system event. |
Where Used
Follow this link to open the data dictionary where you can view the tables that reference CI_OD_RULE_ALG.
An overdue event cancel reason must be supplied before an overdue event can be canceled. Open this page by selecting Admin, Overdue Event Cancel Reason.
Description of Page
Enter an easily recognizable Overdue Event Cancel Reason and Description for each cancellation reason.
Where Used
Follow this link to open the data dictionary where you can view the tables that reference CI_OEVT_CAN_RSN.
A Collection Case Type defines the configuration information that is common to collection cases of a given type. The type of information captured on the collection case type is governed by the collection case type's business object.
To set up a Collection Case Type, select Admin Menu, Collection Case Type.
The topics in this section describe the base-package zones that appear on the Collection Case Type portal.
Contents
The Collection Case Type List zone lists every collection case type. The following functions are available:
· Click a broadcast button to open other zones that contain more information about the adjacent collection case type.
· The standard actions of Edit, Duplicate and Delete are available for each collection case type.
· State transition buttons are available to transition the collection case type to an appropriate next state.
· Click the Add link in the zone's title bar to add a new collection case type.
This is a standard actions zone. The Edit, Delete and Duplicate actions and appropriate state transition buttons are available.
The Collection Case Type zone contains display-only information about a Collection Case Type. This zone appears when a Collection Case Type has been broadcast from the Collection Case Type List zone or if this portal is opened via a drill down from another page.
Please see the zone's help text for information about this zone's fields.
This is a standard log zone.
Where Used
Follow this link to open the data dictionary where you can view the tables that reference CI_COLL_CASE_TYPE and CI_COLL_CASE.
You must set up a collection agency for each such organization to which you refer delinquent debt. To define a collection agency, select Admin Menu, Collection Agency.
Description of Page
Enter an easily recognizable Collection Agency code and Description for each collection agency.
A collection agency must be associated with a Person. Choose the Person ID of the organization from the prompt.
Information about how to set up persons is discussed in Maintaining Persons.
Turn on the Active switch if the collection agency is actively receiving referrals.
Specify the Batch Control that’s used to route new and cancelled referrals to the collection agency. The batch control’s description is displayed adjacent.
Where Used
Collection agencies are assigned to collection agency referrals when the collection agency referral background process executes. Refer to The Big Picture Of Collection Agency Referrals for more information.