FINERACT-2455: Working Capital Loan Transaction - Payout Refund

[somasorosdpc]

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.

[galovics]

In WorkingCapitalLoanPaymentAllocationProcessor.java (resolveAllocationOrder):

if (rules != null && !rules.isEmpty()) {
    // TODO smells, it does not supports other customisation than repayment
    final WorkingCapitalLoanPaymentAllocationRule repaymentRule = findRule(rules, PaymentAllocationTransactionType.REPAYMENT);

PaymentAllocationTransactionType already has a PAYOUT_REFUND value and the product model already lets an admin configure a rule specifically for it, but this always resolves the REPAYMENT rule regardless of transaction type. So a payout refund on a product with a distinct payout-refund allocation rule configured will silently use the repayment rule instead. Is that intentional for this iteration, or should it be wired now that payout refund exists? At least a follow-up ticket referenced here instead of just "smells". Also: "does not supports" -> "does not support".