Piotr Wargulak created FINERACT-3007:
----------------------------------------
Summary: Fees or penalties due on the same date are paid in a
random order
Key: FINERACT-3007
URL: https://issues.apache.org/jira/browse/FINERACT-3007
Project: Apache Fineract
Issue Type: Bug
Reporter: Piotr Wargulak
Assignee: Piotr Wargulak
When a payment covers only part of an installment's fees (or penalties), which
of two charges due on the same date receives the money changes from run to run.
Balances are right in total, but the paid-by links, the charges' paid amounts
and anything derived from them (for example the tax booked on a taxed charge)
differ between two identical runs.
Cause:
* {{AdvancedPaymentScheduleTransactionProcessor}} collects an installment's
fees and penalties with {{Collectors.toSet()}} (:2055, :2061) and passes them
to {{{}updateChargesPaidAmountBy{}}}.
*
{{AbstractLoanRepaymentScheduleTransactionProcessor#findEarliestUnpaidChargeFromUnOrderedSet}}
(:736) picks the earliest due date with a strict {{{}DateUtils.isBefore{}}},
so on a tie the first charge the set yields wins.
* {{LoanCharge}} has {{{}equals{}}}/{{{}hashCode{}}} commented out (:480-493),
so the set iterates in identity-hash order, which differs per JVM run. Creation
order does not decide it.
Steps to reproduce:
# Progressive loan (advanced-payment-allocation-strategy), one or more
installments.
# Add two specified-due-date fees with the same due date inside one
installment, e.g. 10.00 and 2 000.00.
# Repay less than the sum of the two fees once that installment is due.
# Read \{{GET /loans/ {loanId}?associations=charges,transactions}}: which fee
is paid in full and which is partly paid varies between runs of the same
scenario (on a fresh server, or after a replay).
Expected: a deterministic order.
Proposed: on equal due dates, the charge with the lower id first (the one
created first); charges not yet saved after saved ones.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
