This is of high importance for housing-related programs, for multiple reasons.

First, it is common for homeless clients to have accrued arrears with certain landlords, that would prohibit the landlord from accepting them as a tenant in the future, at least until the arrears are paid. Similarly, clients may have accumulated utility arrears with similar conditions. Therefore, it is necessary for caseworkers helping clients to find housing to know about and address arrears situations. Caseworkers need to know who arrears are owed to, the amount of the arrears, and whether there’s a repayment plan in place.

_Screenshot: Current Add Financial Debt screen_

Second, eviction prevention programs are often very interested in knowing what a client owes, because assisting them with their arrears is one of the primary things an eviction prevention program does.

Finally, it’s important for landlords to track arrears, but a more likely use of the software is for caseworkers who support clients in housing to stay on top of arrears to prevent evictions.

HIFIS 4 already contains a place where users can track arrears, called the Debts module, but it is sadly lacking in utility. As an example, there is a mandatory drop-down field in this module called “Debt Type” but it only contains one option: “Debt.” At a bare minimum, this list should be expanded. Some suggested options include:

A second issue with the Debts module is that it does not capture information that is most useful to users. One key piece of information that is missing is who the debt is owed to. It is proposed that this field should contain a list of Places (i.e. Directory of Services), but that this field should be optional. It may also be useful to have an “Other” option in this drop-down.

Participants in focus groups also identified the need for further information. In particular, they expressed the need to know whether a repayment plan was in place. In addition, the ability to attach documents would be useful. These documents would generally be assumed to behave like other documents, and would also appear in the Client Documents List, as usual.

The current “Country” and “Province/Territory” fields in the Debts module are not particularly relevant. The utility of these fields is unclear, and it is suggested that the possibility of removing these fields be investigated.

_Mock-up: New Add Financial Debt screen could look more like this_

Another issue with the Debts module is it is unclear how it should be used to manage changing debts. Each Debt record has an amount and a start date and an end date. If a client owes $1000, then pays off $100 and now owes $900, how should that be recorded? If interest increases it to $925, how can a user easily capture that? One option is to add an end date to the old record and start a new record with the new amount, but that is a cumbersome process. Alternatively, a user could change the amount, but that erases the history (a similar challenge as in <u>Rent Adjustments</u>).

As in Action Item RA-3: Create a “Add Rent Adjustment” form, a separate form could be created that simply allows a user to update the current Debt amount, along with a date. A similar discussion could be had (as in Rent Adjustments) as to whether it is also necessary to include a “Reason for Adjustment” field.

Alternatively, adjusting the Debt amount could be part of the Edit Debt screen that would allow a user to change the Amount value, while somehow keeping a record that the amount was changed and what the previous and current values are. This would be a model more akin to how Statuses are updated in the Waiting List module.

Regardless of the specific approach undertaken, the Start Date and End Date fields seem problematic, as it is unclear to users how they should be used. Given the preferred method of use, it may be most logical to remove the Start and End Date fields altogether, and have them replaced by a series of update dates. Or, perhaps the Start Date and End Date are hidden from the user, and are automatically populated: the Start Date with the first date listed, and the End Date with the date attached when the Amount reaches 0.

It is still necessary to be able to indicate which Debts are “active” and which are “archived,” but this can simply be achieved by reviewing what the current Debt amount is.

In order to accommodate some of these suggestions, the database structure and rights may need to be altered somewhat. Currently, Assets and Liabilities (Debts) are bundled together. If users have rights to one, they have rights to the other. Similarly, they are both stored in the same table, with the same fields (a Debt is simply a negative Asset). It is suggested that these be split into two distinct entities, with updated rights and database to illustrate this.