[budaidev]

Description

Describe the changes made and why they were made. (Ignore if these details are present on the associated Apache Fineract JIRA ticket.)

Checklist

Please make sure these boxes are checked before submitting your pull request - thanks!

• Write the commit message as per our guidelines
• Acknowledge that we will not review PRs that are not passing the build ("green") - it is your responsibility to get a proposed PR to pass the build, not primarily the project's maintainers.
• Create/update unit or integration tests for verifying the changes made.
• Follow our coding conventions.
• Add required Swagger annotation and update API documentation at fineract-provider/src/main/resources/static/legacy-docs/apiLive.htm with details of any API changes
• This PR must not be a "code dump". Large changes can be made in a branch, with assistance. Ask for help on the developer mailing list.
• If merging this PR resolves a JIRA issue, I will mark that issue as resolved and set "Fix Version/s" appropriately.
• I followed the AI Policy.

Your assigned reviewer(s) will follow our guidelines for code reviews.

[galovics]

Review

Hi @budaidev, thanks for the PR. I know it's a draft. CI is green, I couldn't find double posting (COB measures against the per-charge accrued amount, the real-time path skips charges that already have an accrual, and the post-maturity immediate accrual is turned off when real-time applies), and the pl-charge-accrual-time Liquibase entry mirrors the WCL one. Two behaviour changes need an explicit decision before it leaves draft.

LoanAccrualsProcessingServiceImpl.java:1443-1457 (isAlreadyAdjusted / countNonReversedWithSameSplit):

The accrual adjustment dedupe changed for all loans, not just the ones under the new flag. Before, an adjustment was skipped if any non-reversed adjustment with the same date and amount existed. Now it matches on the same interest/fee/penalty split and compares counts (adjustments >= max(accruals, 1)), which also runs for cumulative loans and PL on EOD (the unit test even asserts "cumulative, 2 accruals, 1 adjusted -> 1 new"). It's probably a real fix, but it's outside the flag, so either a separate ticket or at least a clear note in the description so reviewers know existing tenants are affected.

LoanAccrualsProcessingServiceImpl.java:1316-1318 (resolveChargeOnDueDate):

With real-time on, PL loans always use submitted-date matching, even when the tenant has charge-accrual-date=due-date. When switching EOD to real-time, charges added under EOD with a future due date get accrued at the next COB, before their due date (eodToRealTimeFlip_... expects an accrual dated 11 Jan for a fee due 20 Jan). The config description mentions neither. Needs product confirmation and documentation.

LoanRepository.java:109, 118-122:

With the flag on, (:progressiveFutureCharges = true and <PROGRESSIVE>) bypasses the date filter, so "Add Periodic Accrual Transactions" and "Add Accrual Transactions" load essentially every active periodic-accrual PL loan. The submitted-date futureCharges path already does it for all loans, so it's not new, but it's a real load increase for PL-heavy tenants. Nit: the fully-qualified enum literal in the JPQL string, and no blank line before LOANS_FOR_ACCRUAL.

Smaller ones: the BooleanSupplier overload of isRealTimeChargeAccrual is only called with () -> plChargeAccrualRealTime or a method reference, a plain boolean would remove the lambdas. ConfigurationDomainServiceJpa adds another "real-time" literal while WorkingCapitalLoanChargeAccrualService already has an identical constant, so a shared one would keep the two flags consistent. LoanAccrualsProcessingServiceImplTest calls the private isChargeDue via ReflectionTestUtils, driving it through addPeriodicAccruals would survive a rename. No test covers undoing a charge-off on a loan that already has real-time accruals (low risk since real-time is skipped for charged-off loans). And pls fill in the PR description. Heads-up: 0260 is also claimed by #6610, #6613, #6659, #6643 and #6588, so whoever merges second renumbers.

Recommendation: COMMENT