-
Notifications
You must be signed in to change notification settings - Fork 2.2k
FINERACT-2092: New transaction type interest payment waiver #3932
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
FINERACT-2092: New transaction type interest payment waiver #3932
Conversation
79e3da2 to
5269d8e
Compare
|
|
||
| @Transactional | ||
| @Override | ||
| public CommandProcessingResult makeLoanRepaymentWithPaymentWaiver(final JsonCommand command) { |
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.
We might wanna rename this to makePaymentWaiver
| return isChronologicallyLatestRepaymentOrWaiver; | ||
| } | ||
|
|
||
| LoanTransaction assembleTransactionAndCalculateChanges(Loan loan, JsonCommand command, Map<String, Object> changes) { |
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 wanna move this into a LoanTransactionAssembler.
| txnExternalId, null); | ||
| } | ||
|
|
||
| ChangedTransactionDetail assembleUpdatedLoan(Loan loan, LoanTransaction newPaymentWaiverTransaction) { |
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 wanna rename this something more descriptive: example: recalculateLoanWithPaymentWaiverTxn
| loan = saveAndFlushLoanWithDataIntegrityViolationChecks(loan); | ||
|
|
||
| // Save Note | ||
| if (StringUtils.isNotBlank(noteText)) { |
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.
Would it make sense to call the createNote(noteText, loan) instead?
|
|
||
| // Save changedTransactionDetail if exists | ||
|
|
||
| if (changedTransactionDetail != null) { |
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.
Would it make sense to extract into a method this logic?
| changes.put("paymentTypeId", command.longValueOfParameterNamed("paymentTypeId")); | ||
|
|
||
| if (StringUtils.isNotBlank(noteText)) { | ||
| changes.put("note", noteText); |
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.
Is there any logic which requires the note to be in the changes array?
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.
We don't have any build-in logic on it. But as I see we send back it in the response, and other repayment type returns it, I think, we should keep it in the changes set to keep uniform response values.
| doPostLoanTransactionChecks(loan, newPaymentWaiverTransaction.getTransactionDate(), defaultLoanLifecycleStateMachine); | ||
|
|
||
| // Payment allocation calculates the new total principal repaid and it should be validated after recalculation | ||
| if (loan.getLoanProduct().isMultiDisburseLoan()) { |
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.
Can we move this out from this method and be called after assembleTransactionAndCalculateChanges ?
| } | ||
| } | ||
| } | ||
| if (reprocess) { |
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.
Would it make sense to extract it into a new method?
| final LoanRepaymentScheduleInstallment currentInstallment = loan | ||
| .fetchLoanRepaymentScheduleInstallment(newPaymentWaiverTransaction.getTransactionDate()); | ||
|
|
||
| boolean reprocess = true; |
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.
Would it make sense to extract it into a new method?
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.
As I see, the logic calculates reprocess flag and also does repayment schedule calculation in some cases which strongly connects the main logic.
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.
Maybe it would be better to move this where ever we storing the note. Thoughts?
adamsaghy
left a comment
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.
Please kindly check my review!
8aaa1ec to
45b0c6d
Compare
45b0c6d to
952b085
Compare
| this.entityName = "LOAN"; | ||
| this.entityId = null; | ||
| this.loanId = loanId; | ||
| this.href = "/loans/" + loanId + "/transactions/template?command=paymentwaiver"; |
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.
Please change this to be "interestPaymentWaiver"
| public CommandProcessingResult processCommand(final JsonCommand command) { | ||
| try { | ||
| return this.writePlatformService.makeInterestPaymentWaiver(command); | ||
| } catch (final JpaSystemException | DataIntegrityViolationException dve) { |
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.
I think we can remove the try catch from here. Let it be handled in the error mappers ;)
| } | ||
| } | ||
|
|
||
| public void validateLoanStatusIsActiveOrFullyPAidOrOverpaid(final Loan loan) { |
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.
typo in the method name
| } | ||
|
|
||
| private boolean isForeclosure() { | ||
| public Integer getLoanSubStatus() { |
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.
Lombok getter is on the Loan entity, so probably this getter method can be removed.
| .addAdvancedPaymentAllocation(defaultAllocation, goodwillCreditAllocation, merchantIssuedRefundAllocation, | ||
| payoutRefundAllocation, interestPaymentWaiver) | ||
| .withInterestCalculationPeriodTypeAsRepaymentPeriod(true).withInterestTypeAsDecliningBalance().withMultiDisburse() | ||
| .withDisallowExpectedDisbursements(true).withLoanScheduleType(loanScheduleType) |
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.
Please rewrite the test cases to the following:
- Loans with interest
- The test cases are checking the accounting entries are proper
7e3191a to
1316940
Compare
1316940 to
580a8fb
Compare
| this.entityName = "LOAN"; | ||
| this.entityId = null; | ||
| this.loanId = loanId; | ||
| this.href = "/loans/" + loanId + "/transactions/template?command=interestpaymentwaiver"; |
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.
typo: interestpaymentwaiver -> interestPaymentWaiver
adamsaghy
left a comment
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.
LGTM
Description
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.