How Arrears History is Captured

The system captures a history of arrears (amount owed) for accounts under an active collection activity – those with an active collection, severance, or overdue process. The data is maintained from the creation of the process to when it set to inactive. Currently, there is no user interface to view the history records. Rather, they are stored in the system so they can be retrieved by other processes and APIs.

Where is this information captured? The system uses child maintenance objects that extend their parent object to capture this information. Arrears history records are stored in the following tables: Collection Process Arrears History, Collection Process SA Arrears History, Severance Process Arrears History and Overdue Process Arrears History. Arrears history is stored on the Collection Process SA Arrears History table when the system is configured to use service agreement-oriented cancel criteria. Refer to How Are Collection Processes Cancelled and How Are Severance Processes Cancelled for more information on debt class or service agreement-oriented cancel criteria configurations.

Why is this information captured? One reason is because it’s difficult to derive real-time. The system relies on plug-in spots to know if a collection activity can be canceled. These plug-in spots calculate the amount owned under a collection activity, sometime adjust that amount by promised future payments, and compare that amount to a threshold that is configured as an algorithm parameter. So, outside of the system processes that call these plug-in spots, it is difficult for an API or query to replicate the logic. Therefore, the system captures the information from the plug-in spot drivers – the programs that call the plug-ins. The drivers are base programs and will work with algorithms delivered with the system or your custom algorithms; just make sure they are populating the output elements for the plug-in spot.

The above explains the technical aspect of this, but why or how can this data be used? One reason is to allow inquiries across many accounts belonging to the same person or business. Consider a large entity such as a local government with hundreds or even thousands of accounts and the desire to know how much debt is under collection at any moment. Aside from being difficult to replicate the logic that derives these amounts, that query could be a timely one to perform.

The most recent amount owed and related information should meet the business needs for case like the one described above, however, instead of keeping a current snapshot of amount owed for each process, the system creates a record upon process creation and a new record each time there is a change in the amount owed or other data captured. One reason for this is to have the data to analyze the payment patterns for debt under collection. Is the debt paid in one lump sum or in small amounts? Is it paid close to the process creation or days or weeks later? Are customers paying the full amount owned or just enough to get below the threshold to cancel collection activity? This data makes these types of analytics possible.

What data is being stored? The key information is the amount still owed for the collection activity, the cancelation threshold amount, and the amount owed before being adjusted by future payments. Refer to How Pay Plans Affect The Account Debt Monitor for more information about how pay plans affect the amount owed . The system is also able to determine if debt class or service agreement-oriented cancel criteria configurations are used based on which plug-in spots are being used and this information is captured. This is important in knowing how to use and interpret the data. Refer to the system metadata for these tables to see exactly what data is captured.

What system processes call the plug-in spots responsible for capturing the arrears history? These plug-in spots are called when the processes that collect on debt are created. They are called in a special mode that does the calculations but doesn’t take any action. This is to capture the initial record. These plug-in spots are also called by the processes that monitor ongoing collection of debt, some updates to these processes, and by system events such as a payments or other credit financial transactions.