[
https://issues.apache.org/jira/browse/FINERACT-2486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralph Hopman resolved FINERACT-2486.
------------------------------------
Resolution: Fixed
> Guarantor endpoint returns savingsAccount.id = 0 for group savings guarantors
> -----------------------------------------------------------------------------
>
> Key: FINERACT-2486
> URL: https://issues.apache.org/jira/browse/FINERACT-2486
> Project: Apache Fineract
> Issue Type: Bug
> Components: Groups, Loan
> Reporter: Ralph Hopman
> Assignee: Ralph Hopman
> Priority: Minor
>
> When retrieving guarantor details via {{{}GET
> /loans/\{loanId}/guarantors{}}}, the response shows {{savingsAccount.id = 0}}
> for guarantors backed by group savings accounts, even though the on-hold
> transactions are correctly recorded with the actual savings account ID.
> *Root Cause*
> The {{GuarantorReadPlatformServiceImpl}} SQL query joins savings accounts via
> {{{}m_portfolio_account_associations.linked_savings_account_id{}}}. For group
> savings guarantors, this field is {{{}NULL{}}}, causing the
> {{m_savings_account}} join to fail. This results in {{sa.id}} being
> {{{}NULL{}}}, which gets mapped to {{0}} in the response.
> *Why On-Hold Transactions Work*
> The {{/savingsaccounts/\{id}/onholdtransactions}} endpoint reads directly
> from the {{m_deposit_account_on_hold_transaction}} table using
> {{{}savings_account_id{}}}, so it is not affected by the portfolio
> association join path.
> *Expected Behavior:*
> The guarantor endpoint should return the correct savings account ID for group
> savings guarantors, matching the ID stored in the on-hold transaction records.
> h2. Solution
> Modify the SQL join in {{GuarantorReadPlatformServiceImpl.GuarantorMapper}}
> to:
> # Reorder joins so {{m_deposit_account_on_hold_transaction}} comes before
> {{m_savings_account}}
> # Use {{COALESCE(aa.linked_savings_account_id, oht.savings_account_id)}} for
> the savings account join
> # This allows the query to fall back to the savings account ID from the
> on-hold transaction when the portfolio association link is NULL
> h2. Testing
> Add integration test {{testGuarantorWithGroupSavingsAccount}} to verify:
> * Group savings account can be used as guarantor backing
> * Guarantor endpoint returns correct (non-zero) savings account ID
> * Savings account ID matches the actual group savings account
> * On-hold transactions are properly created with correct savings account
> reference
> h2. Workaround
> Query {{/savingsaccounts/\{id}/onholdtransactions}} directly to see correct
> account associations
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
