Cocoa-Puffs commented on code in PR #6067:
URL: https://github.com/apache/fineract/pull/6067#discussion_r3506344767


##########
fineract-provider/src/main/java/org/apache/fineract/portfolio/loanaccount/service/LoanBuyDownFeeAmortizationProcessingServiceImpl.java:
##########
@@ -80,14 +80,17 @@ public void processBuyDownFeeAmortizationTillDate(@NonNull 
Loan loan, @NonNull L
             AmortizationType amortizationType;
             if (!balance.isDeleted()) {
                 final List<LoanTransaction> adjustments = 
loanTransactionRepository.findAdjustments(balance.getLoanTransaction());
-                final Money amortizationTillDate = 
BuyDownFeeAmortizationUtil.calculateTotalAmortizationTillDate(balance, 
adjustments,
-                        maturityDate, 
loan.getLoanProductRelatedDetail().getBuyDownFeeStrategy(), tillDatePlusOne, 
loan.getCurrency());
                 final BigDecimal alreadyAmortizedAmount = 
loanAmortizationAllocationService
                         
.calculateAlreadyAmortizedAmount(balance.getLoanTransaction().getId(), 
loan.getId());
                 if (MathUtil.isZero(balance.getUnrecognizedAmount()) && 
adjustments.isEmpty()) {
                     totalAmortization = 
totalAmortization.add(Money.of(loan.getCurrency(), alreadyAmortizedAmount));
                     continue;
                 }
+                final boolean fullyAmortizedOnSaleOrClosure = 
MathUtil.isZero(balance.getUnrecognizedAmount())
+                        && 
alreadyAmortizedAmount.compareTo(balance.getAmount()) >= 0;

Review Comment:
   Unfortunately, while this fix worked fine with this usecase it broke two 
cases in Reporting.feature
   
   two scenarios:
   Scenario: Verify Transaction Summary Reports contain all buydown fee 
transaction types
   Scenario: Verify Transaction Summary Reports with buyDownFeeIncomeType = FEE
   
   failed, because they trigger the same over-adjustment case differently. They 
send backdated repayments and they push unrecognizedAmount to 0. When this 
happens alreadyAmortizedAmount can be greater than netFeeAmount by accident. 
triggering a false positive and calculating amortization with the maturity date.
   
   Instead I added a new query that calculates gross amortized amount and 
compare with that. Which should only match the balance if the loan was actually 
closed or sold.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to