niteshandClaude Sonnet 5
f457b9b8c7
SYMPTOM
A cashier could credit an FD/RD account with cash and the money moved
in instantly, with no Manager approval step - unlike a Savings/Current
deposit from the same screen, which correctly creates a PENDING
m_cashier_deposit_request. Discovered by tracing why a real FD
funding deposit never showed up in Branch Ops -> Approvals: it had
posted directly, no request record ever existed for it.
ROOT CAUSE (two layers, both fixed here / in the paired frontend commit)
1. Frontend gate (transaction-entry.component.ts confirmSubmit(), see
frontend commit): the maker-checker branch for a cashier deposit
only matched row.acTyp in ('SD','CA','CB','GL') - 'FD' and 'RD' were
never in that list, so a deposit into either fell through every
other branch to the generic, unguarded direct POST at the bottom of
confirmSubmit().
2. Even with the frontend gated correctly, approve() here only knew
how to tell Current apart from "everything else -> plain savings
deposit command" (isCurrentAccountById()). FD/RD accounts share the
m_savings_account table with plain Savings (distinguished only by
deposit_type_enum 200/300 vs 100), so an FD/RD deposit request would
have been posted through the generic savingsAccountDeposit command,
which does not accept a term-deposit account id.
FIX
- resolveDepositAccountCategory(accountId): looks up the real category
fresh from the DB (m_current_account / m_savings_account.
deposit_type_enum) instead of trusting the request's own account_type
string - same defensive pattern this class already used for Current.
- New executeFixedDepositDeposit() / executeRecurringDepositDeposit():
post through Fineract's actual FD/RD deposit commands
(CommandWrapperBuilder#fixedDepositAccountDeposit /
#recurringAccountDeposit, hitting /fixeddepositaccounts/{id}/
transactions and /recurringdepositaccounts/{id}/transactions) instead
of the generic savings command.
- approve() now branches on all four categories (Current / Fixed
Deposit / Recurring Deposit / Savings) instead of two.
RELATED DATA CLEANUP DONE THIS SESSION (not in this commit)
The one FD deposit made before this fix existed left an orphaned
m_savings_txn_denomination row (physically "counted" cash with no
approved request backing it), which inflated the Branch Day Register's
"Vault + Cashiers" total above the approved-requests-only "book" total
by exactly that amount every day going forward. That artifact row was
deleted directly (not backfilled with a fabricated approval - the
Claude Code safety layer correctly refused that approach as audit-log
tampering). No code in this repo does that cleanup automatically.
IF THIS BREAKS SOMETHING LATER
- A cashier FD/RD deposit posting instantly again -> check the
frontend gate list in confirmSubmit() (paired commit) still includes
'FD'/'RD'.
- approve() throwing on an FD/RD deposit request -> check
resolveDepositAccountCategory() is returning FIXED_DEPOSIT/
RECURRING_DEPOSIT (query m_savings_account.deposit_type_enum for the
account id in question: 200 = FD, 300 = RD).
- Branch Day Register showing a mysterious Vault-vs-book Excess again
-> check for an m_savings_txn_denomination row with no matching
m_cashier_deposit_request; that combination should be impossible now
that this fix is in place, so a new one appearing means this fix (or
its frontend half) regressed.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>