...
Attribute | Description | Notes |
---|---|---|
LoanID | Loan ID | |
Status | Status of the reschedule request | (Similar Enum to loans etc) |
from installment | Reschedule starting at this instalment # | |
Grace on Principal | Integer describing how many instalments will be added with 0 principal | Instalments will be added straight after the from instalment. |
Grace on Interest | Integer describing how many instalments will be added with 0 interest | Grace on P and I will be combined into 1 if applicable. |
Change instalment date | New Date for the selected instalment | Used to reschedule rest of the loan from this instalment forward |
Extra Terms | Integer for # of extra terms to add at end of schedule | |
Interest Rate | New Interest rate for the loan | Applied to the remainder of the loan. |
Recalculate interest? | Boolean , always true if Interest is entered. | If true then the new schedule will recalculate the interest using the P outstanding at starting instalment, and the new end-date of loan. |
Reschedule_Reason | CodeValue | Link to Code listing reasons for rescheduling |
Reschedule_Comments | Free text | Free text description to be used in addition to the CV. |
Submitted On | Date | |
Submitted By | UserID | |
Approved On Date | Date | |
Approved By | UserID | |
Declined On | Date | |
Declined By | UserID |
|
Loan Schedule History
Attribute | Description | Notes |
---|---|---|
Loan Reschedule ID | ID Of the reschedule request | |
Loan_ID | ||
From Date | ||
Due Date | ||
Instalment # | ||
Principal | ||
.... | This item just follows same attributes as current loan schedule table. |
Security and Permissions
The feature should follow regular security rules, so permissions required for:
...
Question | Outcome |
---|---|
What do we do with product level limits, such as max loan term, min/max interest etc. Proposal is to ignore them, as this is already a feature for exception cases. | |
Do we want to store historical schedules in the same loan schedule table? This might have negative effects on performance of that table. It also avoids the need to go in and change all areas of code (reports/jobs/loans package) that use this code. | |
Right now the reschedule is a simple maker/checker workflow, do we want to extend it to the more extensive, create / pending approval / approved / declined workflow? | |
We have the ability to classify loans as NPA, do we need to automatically do this for restructured loans? (some regulations do require this) | |
When storing the old schedule for comparison, do we also copy the derived fields (paid etc) ? | |
Do we allow loan repayments backdated before date of reschedule? |
Out of Scope
- Flexible loan schedules. Even though the feature might re-use a lot of code from this feature we do not want to implement it straight away to reduce complexity. At the same time this process should take place before creating loan, rescheduling is after the disbursement.
- Rescheduling of interest on past instalments
- Rescheduling of instalments that have already been fully or partially paid.
...