You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@fineract.apache.org by "mariiaKraievska (via GitHub)" <gi...@apache.org> on 2026/09/21 14:26:49 UTC
[PR] FINERACT-2814: Investor immediate buy down fee amortization [fineract]
mariiaKraievska opened a new pull request, #6489:
URL: https://github.com/apache/fineract/pull/6489
## 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](https://github.com/apache/fineract/blob/develop/CONTRIBUTING.md#pull-requests)
- [ ] 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](https://fineract.apache.org/docs/current/#_testing) for verifying the changes made.
- [ ] Follow our [coding conventions](https://cwiki.apache.org/confluence/display/FINERACT/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"](https://cwiki.apache.org/confluence/display/FINERACT/Pull+Request+Size+Limit). Large changes can be made in a branch, with assistance. Ask for help on the [developer mailing list](https://fineract.apache.org/#contribute).
- [ ] 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](https://github.com/apache/fineract/blob/develop/CONTRIBUTING.md#ai-policy).
Your assigned reviewer(s) will follow our [guidelines for code reviews](https://cwiki.apache.org/confluence/display/FINERACT/Code+Review+Guide).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@fineract.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] FINERACT-2814: Investor immediate buy down fee amortization [fineract]
Posted by "adamsaghy (via GitHub)" <gi...@apache.org>.
adamsaghy merged PR #6489:
URL: https://github.com/apache/fineract/pull/6489
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@fineract.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] FINERACT-2814: Investor immediate buy down fee amortization [fineract]
Posted by "adamsaghy (via GitHub)" <gi...@apache.org>.
adamsaghy commented on PR #6489:
URL: https://github.com/apache/fineract/pull/6489#issuecomment-6035493581
@mariiaKraievska Can you please review the below concerns?
1. **The expensive check runs first** (`BuyDownFeeAmortizationStrategyServiceImpl.java:44`). `shouldRecognizeImmediately` looks up the product attribute before checking whether the loan is sold. The attribute lookup costs about three queries (product existence check, paged query, count query). That runs on every buy-down fee, adjustment and reversal for any open loan, even though most loans aren't sold. Checking `findActiveByLoanId(...).isPresent()` first would skip it in the common case.
2. **One balance is found by loading all of them** (`LoanBuyDownFeeAmortizationProcessingServiceImpl.java:185`). `resolveRelatedBuyDownFeeBalance` loads every open balance on the loan and filters in memory by transaction id. A targeted repository method like `findByLoanIdAndLoanTransactionIdAndClosedFalse` would return the row directly. It must not filter on `deleted`, so that reversed fees are still found.
3. **The attribute lookup is duplicated** (`BuyDownFeeAmortizationStrategyServiceImpl.java:48`). `isImmediateProduct` copies the lookup from `DelayedSettlementAttributeServiceImpl.isEnabled`. The copies already compare differently (`equals` vs `equalsIgnoreCase`). Both behave correctly today because stored values are always uppercase, but a shared helper on the read service would stop them drifting further.
4. **Tests are missing.**
- There are no unit tests for `BuyDownFeeAmortizationStrategyServiceImpl` or `processBuyDownFeeAmortizationImmediately`.
- The branch that computes the amount from only the related balance (`useLoanWideAmortizedTotal=false`) has no unit test.
- No end-to-end scenario reverses a buy-down fee *adjustment* on a sold IMMEDIATE loan. That's the only new path with no test at all.
If anything here is worth holding the PR for, it's the missing adjustment-reversal scenario; the first three are optional cleanups.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@fineract.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] FINERACT-2814: Investor immediate buy down fee amortization [fineract]
Posted by "mariiaKraievska (via GitHub)" <gi...@apache.org>.
mariiaKraievska commented on PR #6489:
URL: https://github.com/apache/fineract/pull/6489#issuecomment-6037467967
> @mariiaKraievska Can you please review the below concerns?
>
> 1. **The expensive check runs first** (`BuyDownFeeAmortizationStrategyServiceImpl.java:44`). `shouldRecognizeImmediately` looks up the product attribute before checking whether the loan is sold. The attribute lookup costs about three queries (product existence check, paged query, count query). That runs on every buy-down fee, adjustment and reversal for any open loan, even though most loans aren't sold. Checking `findActiveByLoanId(...).isPresent()` first would skip it in the common case.
> 2. **One balance is found by loading all of them** (`LoanBuyDownFeeAmortizationProcessingServiceImpl.java:185`). `resolveRelatedBuyDownFeeBalance` loads every open balance on the loan and filters in memory by transaction id. A targeted repository method like `findByLoanIdAndLoanTransactionIdAndClosedFalse` would return the row directly. It must not filter on `deleted`, so that reversed fees are still found.
> 3. **The attribute lookup is duplicated** (`BuyDownFeeAmortizationStrategyServiceImpl.java:48`). `isImmediateProduct` copies the lookup from `DelayedSettlementAttributeServiceImpl.isEnabled`. The copies already compare differently (`equals` vs `equalsIgnoreCase`). Both behave correctly today because stored values are always uppercase, but a shared helper on the read service would stop them drifting further.
> 4. **Tests are missing.**
>
> * There are no unit tests for `BuyDownFeeAmortizationStrategyServiceImpl` or `processBuyDownFeeAmortizationImmediately`.
> * The branch that computes the amount from only the related balance (`useLoanWideAmortizedTotal=false`) has no unit test.
> * No end-to-end scenario reverses a buy-down fee _adjustment_ on a sold IMMEDIATE loan. That's the only new path with no test at all.
>
> If anything here is worth holding the PR for, it's the missing adjustment-reversal scenario; the first three are optional cleanups.
Thanks — addressed:
1. Sold check before attribute lookup
2. Targeted balance query (incl. deleted for reversals)
3. Shared getAttributeValue on the read service
4. Unit tests for the strategy service + e2e for adjustment reversal on sold IMMEDIATE
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@fineract.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org