[
https://issues.apache.org/jira/browse/FINERACT-2896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18128355#comment-18128355
]
Abhinav Kumar Jha commented on FINERACT-2896:
---------------------------------------------
I've assigned this to myself.
Before changing anything I checked how a waiver behaves in reverse-replay today
on develop: a progressive loan with advanced payment allocation, a fee of 100,
a repayment of 60, then the waiver of the remaining 40:
||Then||Result on develop||
|the repayment of 60 is undone|charge paid 0, waived 40, *outstanding 60*,
still flagged as waived|
|a backdated repayment of 50 is dated before the waiver|the 50 goes to
principal: the waiver counts from the start of the replay, not from its own
date|
|a backdated repayment of 50 is dated after the waiver|the 50 goes to principal
(correct)|
{{AdvancedPaymentScheduleTransactionProcessor}} skips {{WAIVE_CHARGES}} and
{{LoanCharge.resetPaidAmount}} keeps {{amountWaived}}, so the replay never
revisits the waived amount. This already happens without a transactionDate on
the waive.
*Plan:*
# Make the waive part of reverse-replay: process it on its own date and waive
what is outstanding on that date, but never more than the amount originally
waived. If nothing is outstanding, the waiver is reversed.
# Then add the optional transactionDate on top, with the validations from the
description.
With this, the backdated repayment dated before the waiver pays the remaining
40 and the waiver is reversed, and the one dated after the waiver stays as it
is. When the repayment of 60 is undone, the waiver stays 40 and 60 is owed
again, so the charge is no longer flagged as fully waived. A reversed payment
never increases what was waived, which is also closer to how the cumulative
processors replay a waiver.
The alternative would be to let the waiver grow to the full outstanding amount
(100 in the first case), so the charge stays fully waived.
[~adamsaghy], is the capped version fine with you, or would you prefer the
waiver to grow?
> Allow an optional transactionDate when waiving a loan charge
> ------------------------------------------------------------
>
> Key: FINERACT-2896
> URL: https://issues.apache.org/jira/browse/FINERACT-2896
> Project: Apache Fineract
> Issue Type: Bug
> Components: Charges
> Reporter: Piotr Wargulak
> Assignee: Abhinav Kumar Jha
> Priority: Major
>
> Waiving a loan charge offers no way to choose the waiver's transaction date.
> {{LoanChargeWritePlatformServiceImpl}} derives it: the charge's due date if
> that has passed, otherwise the current business date. That date also drives
> schedule recalculation and the loan's lifecycle transition, so a waiver that
> closes a loan stamps the closing date as well.
> When a waiver is the consequence of an earlier-dated event, it gets the date
> the request happened to be processed, not the date of the event. An example
> is a backdated repayment that settles the loan. Statements, the closing date
> and any later replay then follow the processing date. Correcting the date
> after the fact is not safe, because the recalculation and the lifecycle
> transition have already used it.
> *Proposed change:*
> * Accept an optional {{transactionDate}} (with
> {{{}dateFormat{}}}/{{{}locale{}}}) on the waive-charge command.
> * When it is given, use it in place of the derived date for the waiver
> transaction, for the schedule recalculation and for the lifecycle transition.
> * Validate it as other loan transaction dates are validated: not in the
> future, not before disbursement.
> * When it is absent, behaviour is unchanged.
> * Add unit and integration tests for a backdated waiver that closes the loan.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
