Applying Multiple Adjustments

Date last updated: 04 Jun 2007 – Nesrine

There are no changes in Mifos current UI Screens for the "Apply Adjustment feature"

Test cases are available `here <https://mifos.dev.java.net/files/documents/5045/62250/file_62250.dat/TestCasesGAP(34)%20V1.0.0.xls>`_.

Scope

Only the following will be covered by the current feature:

• Ability to reverse more than one loan repayment

Feature summary

This feature is to address the following request: ability to reverse more than one loan repayment.

The user needs to make adjustments not only for the last entry. For example if for a loan, 3 payments were made, and the 1st one should be adjusted, the user should be able to adjust payments one by one till the first one, i.e.:

• Adjust the 3rd payment (as currently allowed by Mifos), then the 2nd payment, then he first payment,
• then makes the correct entries

By this way, the system should allow more than one adjustment (respecting the repayments rank).

Background

Currently in Mifos, the full amount of the last amount paid (only the last one) can be nullified. If the amount is nullified, system is required to make reverse transaction entries for the amount.

Feature Description

Prerequisites

• The payment, to adjust, shouldn't be already reverted
• The loan account status should be "active in good standing", "active in bad standing" or "closed met obligation"
• When the loan account status is closed-obligation met, the user must have an additional permission besides "can apply adjustment" which is "can adjust payment when account status is "closed-obligation met"

Primary Flow

• The user enter the Mifos system and search for the client or the account which repayment(s) need to be adjusted
• From the "account page", the "repayment schedule page" or the "next instalment details" page, the user clicks on apply adjustment
• The last payment made is displayed by default on the "Apply adjustment" page
• The user check to revert the last payment, enter notes and click on `
  Unknown macro: {review adjustment}
  `
• The review adjustment page is displayed
• The user click on `
  Unknown macro: {submit}

  `

  • The accounts details page is displayed
  • The user click on apply adjustment
  • The last amount paid prior to the one adjusted is displayed in the apply adjustment page
  • The user check to revert, enter notes, review and `
  `
• The accounts details page is displayed
• The user can repeat the upper steps till the first repayment made. Thus, he could adjust one by one all repayments till the first one (respecting the repayments order and under the defined prerequisites).

Post-conditions:

At each adjustment, the system should perform the following:

• Generate the related transaction ID (It is the link between the adjustment and the related adjusted payment)
• Break the last amount paid to its components, and updates the respective amounts. For example: if the last amount was paid for principal, interest and fees together, system should break the total amount into these amounts and reduce it from the principal paid till date, interest paid till date and fee paid till date and add it to the loan balance of principal, interest and fees to pay

At each adjustment, system should give a correct picture by updating the following:

• The Account summary: _ Total amount due on the current day is increased by the adjusted amounts _ Amount in arrears = adjusted amounts, if adjustment date > last installment date _ update the amount paid: reduce from the amount paid the amount adjusted _ update the loan balance: add the amount adjusted to the amount due
• The repayment schedule: update both "installments paid" section and "future installments" section. The repayment schedule should give a picture prior to the repayment adjusted * The repayment respective line is removed from "installments paid" section and inserted in the "future installments" section.
• The installment details: update current installment and overdue amount due on the next meeting (always from the current day) _ Current installment updated with the next meeting due amount _ Overdue amount will increase with the adjusted payment, if adjustment date > last installment date
• Performance history: _ Update the number of payments _ Update number of missed payments: increment the number of missed payments * Update number of days in arrears: recalculate the days in arrears = Today's date-last payment date
• Transaction history should make entries for the related transactions that was reversed due to the adjustment entries (as it is currently done in Mifos)

Alternate Flow

• By clicking on cancel, keep the current pipeline of applying adjustment

UI Screens * Keep Mifos current user interface of the "apply adjustment" feature

Additional information

• Roles and permissions - The loan account state is moved automatically to closed-obligation met, when paying the last installment. The user should be able to adjust payments even when loan account status is "closed-met obligation", since the last payment which needs to be nullified, could concern the last installment.

Thus, to avoid risks, a new permission needs to be added into Mifos: "can adjust payment when account status is "closed-obligation met"

• Apply payment - As it is currently done in Mifos, each correct entry (using the normal apply of payment) needs to fill the first missed "empty" instalment. There is no need to know that correct entries are related to the "adjustments".

Open issue

• How Penalty is recalculated after an adjustment? I referred to the FS but I need more clarifications since ENDA doesn't charge penalty.