Abhishek6122008 commented on PR #6174:
URL: https://github.com/apache/fineract/pull/6174#issuecomment-5944811033
@adamsaghy @bharathcgowda I've pushed the changes. Summary:
**Original issue**
The Post Interest For Savings job resolves the GL accounts for each new
transaction in `selectAccountId`, which always used the accrual-only mappings:
`INTEREST_PAYABLE` for interest posting and `INTEREST_RECEIVABLE` for overdraft
interest. Cash-based products don't have these mappings, so the account id
resolved to `0`, the batch insert into `acc_gl_journal_entry` failed on the FK,
and interest posting was rolled back for every account in that batch.
Separately, the `apm2`–`apm4` joins in the interest-posting query didn't
filter on `product_type = 2`, so they could potentially pick up a loan
product's mapping when the product IDs matched.
**What was changed**
* Removed the skip guard from the previous version of this PR.
* `selectAccountId`: cash-based products now book the same entries as
`CashBasedAccountingProcessorForSavings`:
* Interest posting: debit `INTEREST_ON_SAVINGS`, credit `SAVINGS_CONTROL`
* Overdraft interest: debit `SAVINGS_REFERENCE`, credit
`INCOME_FROM_INTEREST` (as Bharath suggested)
* `SavingAccountMapperForInterestPosting`: added `product_type = 2` to the
`apm2`–`apm4` joins, plus joins for the `SAVINGS_REFERENCE` and
`INCOME_FROM_INTEREST` mappings. The `SAVINGS_REFERENCE` join also checks
`payment_type is null` so payment-channel mappings are skipped, consistent with
`findCoreProductToFinAccountMapping`.
* `SavingsAccountData`: added two transient fields for these GL account IDs.
**Side effects**
* Cash-based accounts: the job now writes their journal entries instead of
failing, so they no longer cause other accounts in the same batch to roll back.
* Accrual and no-accounting products: unchanged.
* If a savings product ID matches a loan product ID, only the savings
product's mappings are used. If a required mapping is missing, the ID resolves
to `0` and the job fails loudly rather than booking against the loan's GL
account.
**How it is covered**
* `SavingsAccountWritePlatformServiceJpaRepositoryImplTest`: covers
`selectAccountId` for cash-based and accrual products, for both interest
posting and overdraft interest.
* `SavingsAccountReadPlatformServiceImplTest`: captures the interest-posting
SQL and verifies that every `acc_product_mapping` join filters on `product_type
= 2`. I covered the shared-ID case this way because product IDs can't be chosen
through the API, so an integration test can't reliably create a loan and
savings product with the same ID.
* `SavingsAccrualAccountingIntegrationTest`: runs the Post Interest job for
a cash-based product, a cash-based product in overdraft, and an accrual
product, and verifies the resulting journal entries.
* Without the fix, the new cash-based and SQL tests fail; the accrual tests
pass either way.
The CI workflows for the new commit are currently waiting for approval to
run.
--
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]
