Re: [PR] FINERACT-2705: Resolve cash-based GL accounts in savings interest posting job [fineract]

["Abhishek6122008 (via GitHub)" <gi...@apache.org>]

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: issues-unsubscribe@fineract.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org