[jira] [Created] (FINERACT-2820) Fiscal compounding boundaries use the wrong year around February

["Victor Romero (Jira)" <ji...@apache.org>]

Victor Romero created FINERACT-2820:
---------------------------------------

             Summary: 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


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)