Designing Overdue Process Templates and Event Types

The following table shows a sample overdue process template for one of the rules in the Residential / North cell in the previous section's matrix.


Overdue Process Template	Overdue Event Type	When Triggered
Accelerated overdue process for residential customers	Old debt letter	At inception of process
	Cut active service agreements	10 days after inception
	Reduce customer's credit rating	10 days after inception (i.e., at the same time the cut process is created)
	Write down small debt	0 days after completion of the cut process(es)
	Refer debt to collection agent	0 days after attempting the small write down (this means that either the small write-down or the agency referral will take place as if the write-down is successful, the bill's FTs will be matched to balanced match events and the overdue process will stop)
	Cancel collection agent referral	45 days after referral
	Write-off debt	0 days after collection agent cancellation

You should create a similar table for each of the distinct overdue process templates in your matrix.

At this point, you've designed the distinct overdue process templates. Next, you'll need to design the algorithms that control their overdue processes:

A template's Calculate Unpaid and Original Amount algorithm calculates the original and unpaid amounts of the objects being collected by a process. These values are used throughout the overdue processing module.
A template's Cancel Criteria algorithm is executed to determine if a process should be cancelled. Refer to How Are Overdue Processes Cancelled for the details.
A template's Cancel Logic algorithm is executed to cancel a process. Refer to How Are Overdue Processes Cancelled for the details. Please note that the logic embodied in this type of algorithm can be sophisticated because it is responsible for stopping an ongoing process's activities (e.g., this could involve cancelling field activities or cases). Cancellation algorithms are also responsible for inserting log entry(s).
A template's Hold Event Activation algorithm is invoked to determine if the Overdue / Cut Event Manager should suspend the activation of the process's events.
A template's Information algorithm is invoked to construct the override "info string".

Next, extract each unique event type from the above table:


Overdue Event Type	Action
Old debt letter	Create a customer contact
Cut active service agreement(s)	Start a cut process for every active SA with an unpaid FT on the bill
Reduce customer's credit rating	Insert an account credit rating history record
Write down small debt	Create write-down adjustments if unpaid debt is less than $x
Refer debt to collection agent	Create a collection agency referral
Cancel collection agent referral	Cancel the collection agency referral
Write off unpaid debt	Create adjustments to write-off unpaid debt

At this point, you know the distinct event types. Next, you'll need to design the algorithms that control the lifecycle of each event type:

The event type's Event Activation algorithm(s) are executed by the Overdue / Cut Event Manager on its trigger date. The following points describe the logic embodied in such an algorithm:
- The activity that happens on the trigger date (e.g., creation of a customer contact, To Do, etc.). Refer to Overdue Events Can Do Many Things for the details.
- Whether the event is transitioned into the Waiting or Complete state when it's triggered. Refer to Some Events Can Wait for the details.
- How the log entry(s) associated with event activation will be constructed. The base-package algorithms allow you to control the verbiage in the log entry by defining the desired message number on the algorithm. This means that you may have to set up new messages. Refer to Activating Events Should Add A Log Entry for the details.
The event type's Cancel Logic algorithm(s) are invoked when an event is cancelled. The following points describe the logic embodied in such an algorithm:
- If the event is allowed to be canceled. This logic may be necessary if some conditions prevent events of this type from canceling. For example, you may want to prevent an event from canceling when there are later dependent events that aren't canceled.
- Any ancillary actions that take place during cancellation.
- How the log entry(s) associated with event cancellation will be constructed.
The event type's Monitor Waiting Event algorithm(s) are invoked to monitor a waiting event. These algorithms are responsible for transitioning a Waiting event to Complete if the object on which it's waiting is complete.
The event type's Event Information algorithm is invoked to construct the override "info string".

Once you've designed each event type's algorithms, you're ready to design your cut processes.