Skip to content

FINERACT-2455: Working Capital transaction reprocessing#5962

Draft
budaidev wants to merge 1 commit into
apache:developfrom
openMF:FINERACT-2455/wc-transaction-reprocessing
Draft

FINERACT-2455: Working Capital transaction reprocessing#5962
budaidev wants to merge 1 commit into
apache:developfrom
openMF:FINERACT-2455/wc-transaction-reprocessing

Conversation

@budaidev

@budaidev budaidev commented Jun 9, 2026

Copy link
Copy Markdown
Contributor

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.

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

@budaidev budaidev force-pushed the FINERACT-2455/wc-transaction-reprocessing branch 2 times, most recently from 679b60d to 859ddad Compare June 10, 2026 12:28
@budaidev budaidev force-pushed the FINERACT-2455/wc-transaction-reprocessing branch from 859ddad to 67c970f Compare June 10, 2026 12:52
}

@Override
public void reprocessTransactions(final WorkingCapitalLoan loan, final List<WorkingCapitalLoanTransaction> allTransactions) {

@adamsaghy adamsaghy Jun 10, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we might want to consider a different approach:

  • Quickly we can have a high number of transactions and we would like to avoid to recalculate / reprocess all transactions and the amortization schedule
  • We should focus on the changes in the transaction allocations only

What if:

  • Transaction was reversed:
    • transaction reprocessing should only happen if
      • reverted transaction was repaying any charge -> The next upcoming transaction(s) need to reprocessed till charge is repaid by them, the rest of the transactions does not matter.
      • otherwise it does not matter -> No transaction reprocessing needed!
  • Backdated transaction:
    • transaction reprocessing should only happen if
      • backdated transaction needs to repay any charge -> The next upcoming transaction(s) might need to be reprocessed as they might not or with different amount to pay charges from now.
      • otherwise it does not matter -> No transaction reprocessing needed!
  • If no charges were added on the loan, there is no reprocessing needed at all!
  • If reprocessing was needed, we should have the "new" allocations of the involved transaction(s) and based on this amortization schedule / breach schedule / delinquency schedule balances might need to be updated. But only with the delta (difference). No need to recalculate everything, but only with impacted parts.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants