rymghosn commented on PR #6285: URL: https://github.com/apache/fineract/pull/6285#issuecomment-6335886054
@adamsaghy You're right, thank you. Your first finding settles it: `develop` already taxes loan charges on every payment path, since FINERACT-1289. The tax is stored in the charge's `taxDetails` and split out of each payment in `LoanJournalEntryPosterImpl`. This PR adds a second tax on top of that, so it can't be fixed by patching it, and the problem described in FINERACT-2764 doesn't exist on stock Fineract. I checked it live against current `develop` (71c39730e9) on PostgreSQL, with a 10% tax group whose credit account is a fresh liability account and a 100 flat fee: - **Specified-due-date fee, paid by repayment** (the ticket's main case): already covered by `LoanChargeTaxIntegrationTest`, which passes. Income from fees 90, tax liability 10, under both cash and accrual accounting. - **Instalment fee, paid by the repayment on the due date:** income from fees 90, tax liability 10. - **Account-transfer fee paid with `command=pay`** from a linked savings account (the path this PR changes in `LoanAccountDomainServiceJpa` / `TransferFeeChargeForLoansTasklet`): income from fees 90, tax liability 10. The issue reported in the ticket came from our fork, which adds the tax on top of the charge instead of keeping it inside the charge amount the way upstream does. So I'm closing this PR, and I'll ask for FINERACT-2764 to be closed as already covered by FINERACT-1289. #6237 is unaffected; it is about savings charges. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
