Hello Xamit,

This is the Jira https://issues.apache.org/jira/browse/FINERACT-2819

El lun, 7 sept 2026 a las 19:17, Khamit Kadirbekov (<[email protected]>)
escribió:

> Hello Fineract developers,
>
> I found a separate reproducible calculation defect in
> DefaultPaymentPeriodsInOneYearCalculator.calculatePortionOfRepaymentPeriodInterestChargingGrace().
> This is independent of FINERACT-2809.
>
> Minimal case:
> repaymentPeriodStartDate = 2026-01-01
> scheduledDueDate = 2026-01-15
> interestChargedFromLocalDate = 2026-01-08
> frequency = WEEKS
> repaidEvery = 2
> MathContext = DECIMAL64
>
> Actual grace fraction: 2
> Expected: 7 / 14 = 0.5
>
> The same dates represented as DAYS with repaidEvery = 14 produce 98. The
> helper multiplies by repaidEvery where a fraction of the full interval
> requires division.
>
> Full report, proposed patch and regression test:
>
> https://gist.github.com/kadyrbekovhamit-cyber/757b38a445df3819c819a343167c2c45
>
> Verified against develop e4474a0f4a4c65a75e7758e47db1fd277e5fcfef on JDK
> 25 through the project's Gradle build. Six of nine tests fail on the
> original calculator; all nine pass with the correction. The tests call the
> actual public calculator without mocked date or interval helpers. Spotless
> and main/test Checkstyle also pass. The affected source file is identical
> in tag 1.15.0.
>
> There is a call site in AbstractCumulativeLoanScheduleGenerator, but I
> have not yet demonstrated a specific end-to-end API loan schedule or
> customer monetary impact.
>
> Could you confirm whether this should receive a separate Jira ticket, or
> point me to an existing one? I can then prepare the conforming PR.
>
> Best regards,
> Xamit Kadirbekov
> GERO Research
>

Reply via email to