[
https://issues.apache.org/jira/browse/FINERACT-2820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Mugarura reassigned FINERACT-2820:
----------------------------------------
Assignee: (was: Kevin Mugarura)
> Fiscal compounding boundaries use the wrong year around February
> ----------------------------------------------------------------
>
> Key: FINERACT-2820
> URL: https://issues.apache.org/jira/browse/FINERACT-2820
> Project: Apache Fineract
> Issue Type: Bug
> Reporter: Victor Romero
> Priority: Major
>
> Reported by Xamit Kadirbekov
> Fiscal compounding boundaries use the wrong year around February
> Hello Fineract developers,
>
> During further review of savings arithmetic I reproduced a separate calendar
> correctness issue in PostingPeriod on develop
> e4474a0f4a4c65a75e7758e47db1fd277e5fcfef. This is distinct from FINERACT-2809
> and the previously reported grace-period fraction issue.
>
> Annual compounding with a March fiscal-year start chooses February 28, 2024
> instead of February 29, 2024 when the period starts in March 2023. A native
> example with principal 1000, annual rate 36.5%, a fixed 365-day denominator,
> DAILY_BALANCE, and the inclusive period 2023-03-01 through 2024-02-29 returns
> 366.37 interest instead of 366.00. Interest compounds one day early.
>
> The quarterly and biannual paths also take February's length from the
> business-date year and then build a date in the target year. For example, a
> valid one-day period on 2025-02-28 with business date 2024-06-15 and fiscal
> start month 3 throws DateTimeException for a fabricated February 29, 2025.
>
> The public report, proposed patch, regression tests and deterministic input
> vectors are available here:
> [https://gist.github.com/kadyrbekovhamit-cyber/e6a609ea22ed1934015e957867fd1a28]
>
> The patch uses the target YearMonth and reapplies month-end adjustment after
> annual year rollover. Before correction, 9 of 13 focused native cases fail.
> After correction, those 13 cases, a further 144-case fiscal calendar corpus,
> and 9 existing adjacent tests pass (166 total); Spotless and Checkstyle pass
> on JDK 25. The additional 144-case corpus was run on the corrected version
> only. The tests use the real public PostingPeriod methods, Money, and dates
> without mocked calculations. The same PostingPeriod source is present in
> 1.15.0. No HTTP/account-level customer impact is claimed.
>
> The closest historic report I found is FINERACT-491 / PR #423, which
> introduced fiscal-month support; it does not describe this leap-year
> mismatch. Could you point me to an existing issue, or create a separate Jira
> ticket so I can submit the prepared patch and tests?
>
> Regards,
> Xamit Kadirbekov
> GERO Research
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
