-
Notifications
You must be signed in to change notification settings - Fork 0
fix(CRED-107): Fixes Interest rate history #88
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: develop
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you might need to rebase and fix code violations for this PR as well since it's 2 weeks old
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR fixes the Interest rate history functionality by improving how loan interest variations are processed and displayed. The changes ensure that interest rate variations are properly filtered to only include active records and correctly handle the original approved interest rate in calculations.
Key changes:
- Added filtering for active loan term variations only in the database query
- Enhanced the interest period building logic to include the original approved interest rate
- Improved handling of edge cases where variation dates align with installment dates
Reviewed Changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
File | Description |
---|---|
CredXLoanReadPlatformServiceImpl.java | Adds active record filtering to SQL query and passes original interest rate to buildInterestPeriods method |
LoanInterestVariationsData.java | Enhances constructor and buildInterestPeriods method to handle original approved interest rate and improve date range calculations |
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
if (variations == null) { | ||
variations = new ArrayList<>(); | ||
} | ||
|
||
else { | ||
variations = variations.stream().sorted(Comparator.comparing(LoanTermVariationsData::getTermVariationApplicableFrom)) | ||
.collect(Collectors.toList()); | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The else block is unnecessary since variations is already checked for null on line 54. The sorting logic should be moved outside the if-else block to apply to all non-null variations lists.
if (variations == null) { | |
variations = new ArrayList<>(); | |
} | |
else { | |
variations = variations.stream().sorted(Comparator.comparing(LoanTermVariationsData::getTermVariationApplicableFrom)) | |
.collect(Collectors.toList()); | |
} |
Copilot uses AI. Check for mistakes.
LocalDate toDate = schedule.stream().map(LoanSchedulePeriodData::getDueDate).filter(d -> !d.isAfter(firstVariationDate)) // <= | ||
// firstVariationDate | ||
.max(LocalDate::compareTo).orElse(firstInstallmentDueDate); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[nitpick] The inline comment formatting is inconsistent and unclear. Consider using a more readable comment format or extracting this logic into a well-named method.
LocalDate toDate = schedule.stream().map(LoanSchedulePeriodData::getDueDate).filter(d -> !d.isAfter(firstVariationDate)) // <= | |
// firstVariationDate | |
.max(LocalDate::compareTo).orElse(firstInstallmentDueDate); | |
// Find the latest due date that is on or before the first variation date | |
LocalDate toDate = schedule.stream() | |
.map(LoanSchedulePeriodData::getDueDate) | |
.filter(d -> !d.isAfter(firstVariationDate)) | |
.max(LocalDate::compareTo) | |
.orElse(firstInstallmentDueDate); |
Copilot uses AI. Check for mistakes.
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 https://github.com/apache/fineract/#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 for verifying the changes made.
Follow coding conventions at 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
Submission is not a "code dump". (Large changes can be made "in repository" via a branch. Ask on the developer mailing list for guidance, if required.)
FYI our guidelines for code reviews are at https://cwiki.apache.org/confluence/display/FINERACT/Code+Review+Guide.