This is related to issue #1610. There were 3 scenarios that haven't yet been
implemented. They should be prioritized by Enda who requested this feature:
I) Create a loan
create another loan (will be under next loan cycle)
cancel loan 1
What should be the state of loan 2? Should it be cancelled because its cycle
is no longer valid?
ANSWER: You can't cancel a loan that's been disbursed-- you can only pay if off
(which keeps the loan cycle incremented) or move it to rescheduled or written
off (which decrements the loan cycle). If you move it to rescheduled or
written off, then the user should be prevented from moving loan 2 to approved
(if in partial application status) or prevented from disbursing the loan (if in
approved status). The following error message should be displayed:
You cannot disburse the loan because the loan cycle is no longer valid. Please
cancel the loan and create a new loan.
You cannot move the loan into approved status because the loan cycle is no
longer valid. Please cancel the loan and create a new loan.
II) Currently, the UI allows you to create future loans only from the next
immediate loan cycle. Is that desired behaviour, or should the user be able to
select from subsequent cycles also?
ANSWER: Yes, this is the desired behavior. There is no need for the user to be
able to select from subsequent cycles.
III) Create 2 loans in pending approval (both will be in loan cycle 0)
Disburse loan 1 and repay loan 1 (loan cycle gets incremented to 1)
Disburse loan 2 and repay loan 2 (loan cycle gets incremented to 2)
Now, if another loan is created, this will be taken as loan cycle 3, though the
user has never taken a loan of cycle 1 and 2. Is this expected behaviour?
ANSWER: Yes this is expected behavior. The user has repaid 2 loans so they
should be on loan cycle 2.
And your last question....
Do I block disbursal if the customer has unpaid
loans for any of the loan products he has borrowed, or only for this particular
ANSWER: Only if the customer has unpaid loans for that particular product.
Platform: All, OS: All
Moving Enda bugs to vRhino release
I'd like to clarify that it seems only the first scenario needs to be coded for?
There are four actual issues in here and its kind of confusing to determine
what IS the actual issue.
These are edge cases for the most part, moving to unscheduled
Moving these to the developer queue. I have investigated each of these issues
and determined their are not requirements for vRhino.
Marking as won't fix. These are extreme edge cases and no one has mentioned the need to address them.