FINERACT-2455: Working Capital Loan Charge - Product Creation & Template

[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]

Hi @contributor, thanks for the PR. The feature shape looks reasonable. I have a few things I'd like to discuss before approving.

The retrieveCalculationTypes override returns null when chargeAppliesTo is WORKING_CAPITAL_LOAN and chargeTimeType is provided but isn't SPECIFIED_DUE_DATE - that's a potential NPE for any caller that iterates the returned list. And in the step defs, the new methods break the pattern established by the rest of the file and hardcode raw integers where the existing code uses proper enum types.

Also one small thing in the feature file. Thoughts?

[galovics]

I'm not convinced returning null is safe here. Today it's probably unreachable since validWorkingCapitalLoanValues() only contains SPECIFIED_DUE_DATE, but if more time types are added to working capital loans later, any caller iterating the result will get an NPE. Wouldn't it make more sense to return an empty list (or Collections.emptyList()) as the fallback? Thoughts?

[galovics]

The rest of this file uses ChargeCalculationType.valueOf(...) and ChargeProductType.valueOf(...) to avoid magic numbers, but these new methods bypass that entirely and hardcode 5, 2, 1 directly (with comments explaining what they mean, which is a smell in itself). Any chance we can extract these into constants or reuse the existing enum abstractions the way the other step defs in this class do? Thanks.

[galovics]

Looks like a placeholder - was this intentional or did the TestRail ID not get filled in?