Hi Fineract community, Looking at LoanTransaction.isRepaymentLikeType(), CHARGE_ADJUSTMENT has been included since the original FINERACT-1761 <https://github.com/apache/fineract/pull/2724/changes>implementation. I'd like to understand the intent behind that decision.
When a charge adjustment is included in isRepaymentLikeType(), it gets counted in getTotalPaidInRepayments(), which feeds into calculateTotalOverpayment(). Since a charge adjustment reduces what is owed rather than bringing in actual cash, the overpayment formula reports an inflated amount. For example: Principal = 1000, fee = 100 Repayment = 1100 (loan fully paid) Charge adjustment = 50 (fee reduced after the fact) Expected overpayment: 50 Actual result: totalPaidInRepayments (1150) − cumulativeTotalPaidOnInstallments (1050) = 100 Additionally, getLastRepaymentDate() and getLastPaymentTransaction() return the adjustment rather than the last actual payment, which could affect delinquency tagging and UI display. Was the inclusion in isRepaymentLikeType() intentional, accepting these side effects in exchange for reprocessing loop participation? Or was an alternative classification ever considered so similar to how WAIVE_INTEREST is handled, explicitly included in the reprocessing guards but not in isRepaymentLikeType() itself? If the inclusion is intentional, would the correct fix for the overpayment formula be: totalPaidInRepayments − cumulativeTotalPaidOnInstallments − totalFeeAdjustments − totalPenaltyAdjustments Any insight into the original design rationale would be very helpful. -- Best regards, Hysnije
