89 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
niteshandClaude Sonnet 5	8b2fb052d4	fix(fd): keep a genuinely-matured FD on the Dashboard instead of dropping it ... The maturity-dashboard query only ever selected ACTIVE(300) accounts. That was fine while nothing ever really reached MATURED(800) in this dev setup (test dates were only SQL-backdated, never run through the real nightly job), but the first time the job actually flipped an account's real status, it silently vanished from the ladder instead of showing under "Matured" -- exactly the state the ladder exists to surface. Now selects ACTIVE or MATURED. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-25 12:40:21 +05:30
niteshandClaude Sonnet 5	ea39c8e82a	fix(current-account): recognize Withdrawn and Rejected as terminal when checking for a duplicate product application ... countActiveByClientAndProduct only excluded status 600 (CLOSED), so a client whose prior application for the same product was Withdrawn (400) or Rejected (500) -- both terminal, per CurrentAccount.withdraw()/ reject() -- was still blocked from applying again, same as if that account were genuinely still open. Only 100/200/300 (submitted, approved, active) should collide with a fresh application. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-25 11:22:31 +05:30
niteshandClaude Sonnet 5	32411c924b	fix(accounting): stop the Journal Entry view showing a colliding current account's number for a savings GL entry ... entity_type_enum=2 (PortfolioProductType.SAVING) is written for both savings and current-account journal entries -- current products deliberately share SAVING's GL type space -- so it can't distinguish them, and m_savings_account/m_current_account each have their own id sequence, meaning an entity_id can be a real row in both. The account- number column's COALESCE(ca.account_no, sa.account_no) always preferred the current account's number whenever both matched, so a savings deposit's own journal entry displayed an unrelated current account's number instead of the account it actually posted against. savings_transaction_id is the one reliable signal available on this query: only a genuine savings transaction sets it. Checking it first resolves the correct account whenever it's present, and falls back to the previous behavior only when it's absent (current-account entries, which don't set it). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-25 10:58:44 +05:30
niteshandClaude Sonnet 5	f696499102	fix(current-account): stop account-id collisions between savings and current accounts from misrouting money and losing GL entries ... m_current_account and m_savings_account each keep their own identity sequence, so the same numeric id can be a real row in both -- an id-only lookup used to decide "is this a current account?" once sent a real deposit into an unrelated client's current account instead of the savings account a request actually named, across every entry point that did this: cashier deposit approval/reprocess, clerk withdrawal approval, and clerk disbursement collection/disbursement/bank-transfer. All of those now also verify the account_no before trusting an id match. Separately, GL posting for current-account transactions has been silently failing since acc_product_mapping had two rows for the same (product_id, product_type, financial_account_type) slot -- current products share PortfolioProductType.SAVING's id space with real savings products, and a NULL payment_type doesn't collide under that column's own unique constraint, so duplicates went unnoticed. The single-result repository lookup that read this mapping threw on the duplicate, which was swallowed by a try/catch, so account balances kept updating while no journal entry was ever posted. Both current-account GL lookups now take the most recently created mapping instead of failing outright. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-24 18:14:32 +05:30
niteshandClaude Sonnet 5	d2e13cc7b9	feat(fd): dashboard-driven maturity renewal, plus fix stranded interest on Reinvest Principal Only ... A SINGLE/DOUBLE FD opened with an explicit maturity instruction still auto-processes on its own via the nightly job, exactly as before -- the grace period never delays that. An FD opened with NO instruction at all (the new default -- see the frontend's account-creation changes) is now never touched by the job; it just sits matured until staff renew it manually from the FD Dashboard, backdated to the original maturity date within the product's grace window, or from today with gap-period interest (at the linked account's rate) credited first once it's passed. New endpoints: - POST /fixeddepositaccounts/{id}/renew -- the Dashboard's own quick Reinvest choice (Principal+Interest / Principal Only), for the two-option case. - POST /fixeddepositaccounts/{id}/credit-gap-interest -- a pre-step the frontend's Payment dialog now calls before submitting the existing generic `payment` command, so the Dashboard's Renew action offers every closure type Payment does (Transfer to Savings, both Reinvest options, Partial Reinvest), not just two, while still crediting gap-period interest first. Also fixes a real, pre-existing bug found while building this: REINVEST_PRINCIPAL_ONLY never actually paid its leftover interest anywhere -- handleFDAccountMaturityClosure withdrew only the principal into the new deposit and never referenced its own toSavingsId parameter, silently stranding the interest on an account it also never closed. Now transfers the remainder to the target savings account and actually closes the old account. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-24 15:55:25 +05:30
niteshandClaude Sonnet 5	ecfe8aa76a	feat(fd): add Renewal Grace Period product field, both storage paths ... New per-FD-product "Renewal Grace Period (Days)" term field: null/0 (every existing product) keeps today's instant, same-night auto-renewal; a positive value is later read by the nightly maturity job and the manual Renew action to decide whether/how a matured FD waits for staff to act instead of renewing itself. Wired into the live product path end-to-end -- DepositsApiConstants param, DepositTermDetail column + diffing, DepositProductAssembler (create and update), DepositProductReadPlatformServiceImpl, FixedDepositProductData -- migration 0572 adds the column. Also wired into the maker-checker pending-edit mirror (m_saving_product_temp / FixedDepositEditFields / ProductPendingEditFieldMapper), a second, independent storage path a governed product edit uses -- without this the field silently dropped out of a checker's "Proposed changes" review even though it was submitted. Migration 0573 adds its column. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-24 15:55:11 +05:30
niteshandClaude Sonnet 5	a7cb09f15c	feat(fd): add lean FD maturity dashboard read endpoint ... New GET /v1/fixeddepositaccounts/maturity-dashboard: a narrow, purpose-built query for the FD Dashboard's maturity ladder (account/client/product identity, maturity date, deposit/maturity amounts) instead of routing through the general FixedDepositAccountsApiResource#retrieveAll, whose mapper joins six extra tables for audit/currency/tax fields this screen never shows. Adds the index migration (0571) the dashboard's WHERE clause needs -- neither m_savings_account.deposit_type_enum/status_enum nor m_deposit_account_term_and_preclosure.maturity_date had one before, so the endpoint would otherwise run a full table scan on top of being wide. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-24 15:54:57 +05:30
niteshandClaude Sonnet 5	26d4c241c7	fix(clerk-disbursement): validate savings withdrawal eligibility when a request is raised ... A clerk raising a disbursement request with a Dr leg against a savings account had no way to know the withdrawal would be refused (inactive account, still locked-in, or insufficient balance against its own minimum) until a manager tried to approve it and the whole request bounced back. Checks the same conditions SavingsAccount.withdraw() enforces at entry time instead, against the same columns, so the clerk sees the real reason immediately. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-24 15:54:03 +05:30
niteshandClaude Sonnet 5	dbc2737ada	fix(deposits): FD interest posting silently missed its GL entry on single-period maturity ... SYMPTOM An FD account whose entire term fits inside one interest-posting period (e.g. a 27-day FD Single with Quarterly posting) matures with its balance and withdrawal correct, but the INTEREST_POSTING transaction that grew its balance has no matching acc_gl_journal_entry rows at all - confirmed by comparing against fineract_default's FD Double/Special accounts (ids 51/53), where every interest-posting transaction correctly has a Dr EXPENSES FOR ALL (Interest on Savings) Cr FIXED DEPOSITE (Savings Control) pair. Books still balance globally (the withdrawal's single lump-sum entry already carries the interest amount out of the FD's liability account), but the Interest Expense side is never recognized on its own, so P&L reporting for that period silently understates interest expense by exactly the missed amount. ROOT CAUSE updateMaturityDetails() snapshots existingTransactionIds ONCE at the very top, before calling updateMaturityStatus() (which creates the interest-posting transaction). The old comment here said this was deliberate - "interest postings ... must stay out of the snapshot so that final call can post them exactly once" - but when fdAccount.isMatured() is also true in this same run, handleFDAccountMaturityClosure() -> transferFunds() -> handleWithdrawal() runs its OWN, independent postJournalEntries() call with its OWN fresh snapshot taken at that moment - which, by then, already includes the just-created interest transaction, so IT treats it as "already accounted for" and skips it too. Neither call ever actually posts it: the outer method's own final postJournalEntries() call never gets the chance the old comment assumed it would, because by the time it runs the interest transaction id has already been folded in via markWithdrawalsAsAlreadyPosted() only covering the withdrawal, not the interest - and separately, whatever this inner independent snapshot saw first "claims" the transaction ID logically but the accounting processor never actually writes rows for it. Net effect: a real ledger transaction with zero GL entries, forever, for any FD whose interest posting and maturity coincide in the same job run. Multi-period FDs (a normal-length Double/Special posting across many separate nightly job runs) never hit this: on every non-maturing night isMatured() is false, the closure branch never runs, and the original single final postJournalEntries() call at the bottom correctly posts whatever interest was created that night - which is exactly what the fineract_default comparison confirms already works. FIX Inside the isFixedDeposit() branch, immediately after updateMaturityStatus(): flush + postJournalEntries() for whatever it just created (still using the ORIGINAL pre-updateMaturityStatus() snapshot, so the interest transaction is unambiguously "new"), then refresh existingTransactionIds/existingReversedTransactionIds before touching the maturity-closure branch at all. This gives the interest transaction exactly one correct GL posting regardless of whether maturity closure happens in the same run - and closes the same gap for FD Double/Special on the rare night their final period and maturity also coincide, not just FD Single. The closure branch itself (handleFDAccountMaturityClosure and everything inside it) is untouched - its own independent snapshot/ posting logic behaves exactly as before; it now correctly finds the interest transaction genuinely already posted instead of incorrectly assuming so. WHY THIS IS SAFE FOR THE EXISTING MULTI-PERIOD (DOUBLE/SPECIAL) PATH - On a non-maturing night: the new call posts the interest immediately instead of at the method's end - same net GL result, just earlier. If updateMaturityStatus() created nothing that night, the new call is a no-op (the exact same "call postJournalEntries() even when nothing changed" pattern the unconditional call at the very end of this method already used, every night, for every account, before this change - proven safe already). - The RecurringDepositAccount (else-if) branch is completely untouched. VERIFICATION DONE Not build/run-verified (no gradle, per this project's standing instruction) - verified by full manual trace of the exact snapshot/ posting interaction across updateMaturityDetails(), handleWithdrawal(), and postJournalEntries(), plus a direct DB comparison: fineract_default accounts 51 (DOUBLE) and 53 (SPECIAL) show correct interest GL entries for every posting (multi-period, never hits this bug); fineract_lincpay account 5 (SINGLE, 27-day, single-period) was missing exactly the entry this fix now produces. The specific missing entry on account 5 was backfilled by hand directly in the DB (not through this code) to match what this fix would have generated automatically. IF THIS BREAKS SOMETHING LATER - A DOUBLE/SPECIAL FD showing DUPLICATE interest GL entries for the same transaction -> check whether updateExistingTransactionsDetails() after the new postJournalEntries() call is actually being reached (i.e. no exception thrown by that call swallowing the refresh). - An FD's interest-posting transaction still missing its GL entry -> query acc_gl_journal_entry WHERE savings_transaction_id = <the INTEREST_POSTING txn id> and confirm 0 rows; if so, this fix (or its ordering relative to a future change here) has regressed. - Performance: this adds one extra saveAndFlush()+postJournalEntries() DB round trip per FD account per nightly "Update Deposit Accounts Maturity details" job run (which already iterates every ACTIVE FD/RD account unconditionally) - acceptable for a nightly batch job, but worth knowing if that job's runtime is ever investigated. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-23 14:21:40 +05:30
niteshandClaude Sonnet 5	f457b9b8c7	fix(cashier): route FD/RD cashier deposits through maker-checker approval ... 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>	2026-09-23 14:21:13 +05:30
niteshandClaude Sonnet 5	23ee4f1063	fix(deposits): Deposit Account Link wrongly demanded a co-op share account ... SYMPTOM Creating an FD/RD account with "Deposit Account Link" enabled and a Savings/Current account correctly picked in the UI still failed with: "A share account must be chosen when Share Linking is enabled." even though no share account field exists anywhere on the FD/RD form. ROOT CAUSE SavingsAccountAssembler.applyCbsFields() has one boolean flag, shareLinkingEnabled, serving two unrelated features that got collided together (traceable to commit dc0539d53, which repurposed the flag for co-op Share Account linking on plain Savings products): - On a plain Savings product: "Share Linking" = link a co-op m_share_account (shareAccountId). - On an FD/RD product: the SAME flag is literally labeled "Deposit Account Link" on the product screen (fixed-deposit-product-details-step.component.html) and is meant to require the pre-existing, native linkedAccountId field (already wired end-to-end: SavingsAccountAssembler sets it a few lines below this check, the FD "Maturity Instructions: Transfer to Savings" flow already depends on it, DepositAccountReadPlatformServiceImpl already reads it back for display). Before dc0539d53, 7 real historical FD accounts (ids 51-57 in fineract_default) prove linkedAccountId was the correct, working mechanism for this. The block added by that commit made shareAccountId mandatory unconditionally, for every product, breaking FD/RD. FIX SavingsAccountAssembler.applyCbsFields(): when shareLinkingEnabled is true, branch on account.depositAccountType(): - FIXED_DEPOSIT / RECURRING_DEPOSIT: require linkedAccountId (the field the FD/RD form already sends) instead of shareAccountId. - everything else (plain Savings): unchanged, still requires and validates shareAccountId against m_share_account. SCOPE Single method, single file. No new column, no new flag, no frontend change - the frontend's Deposit Account Link picker was already correct; only this one validation block was reading the wrong field for FD/RD. IF THIS BREAKS SOMETHING LATER - "A share account must be chosen..." reappearing for FD/RD -> check account.depositAccountType() is resolving to FIXED_DEPOSIT/ RECURRING_DEPOSIT at this point (it's a simple override per account subclass, see FixedDepositAccount#depositAccountType()). - A plain Savings product's genuine co-op Share Linking breaking -> that path (the `else` branch here) is untouched; if it breaks, the regression is elsewhere. - A much larger version of this fix (a whole new depositAccountLinkRequired flag decoupled from shareLinkingEnabled, ~18 files) was attempted earlier in the same session and fully reverted at the user's request after repeated Gradle build-cache issues made it impossible to verify was even running; this is the intentionally minimal replacement. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-23 14:20:55 +05:30
niteshandClaude Sonnet 5	bc38216ca3	fix(deposits): FD Single Rate Calculator crashed for tenures under 30 days ... SYMPTOM Opening the FD account create screen for a "SINGLE" (Days < 1 Year) product, entering a Deposit Tenure under 30 days (e.g. 27), and clicking "Find Rate" returned a 400: "The parameter `tenureInMonths` must be greater than 0." ROOT CAUSE The Rate Calculator preview always converted the entered tenure to months before calling GET /fixeddepositaccounts/calculate-fd-interest (fixed-deposits.service.ts -> fixed-deposit-account-interest-rate- chart-step.component.ts, calculateRate()): tenureInMonths = Math.floor(enteredDays / 30) For any tenure under 30 days this floors to 0, and DepositAccountDataValidator.validateForInterestCalc() requires tenureInMonths > 0 unconditionally, so the request was rejected before it ever reached the calculation service. FIX Added `tenureInDays` as an alternative to `tenureInMonths` for this one calculator endpoint only (DepositsApiConstants. FIXED_DEPOSIT_ACCOUNT_INTEREST_CALCULATION_PARAMETERS) - not a general-purpose FD field, not touched anywhere else: - DepositAccountDataValidator: tenureInMonths is required unless tenureInDays is a positive value (either satisfies the check). - FixedDepositAccountsApiResource#calculateFixedDepositInterest: accepts the optional tenureInDays query param. - FixedDepositAccountInterestCalculationServiceImpl#calculateInterest: when tenureInDays > 0, the exact-calendar maturityDate is computed via submittedOnDate.plusDays(tenureInDays) instead of plusMonths(tenureInMonths) (which would silently compute a 0-day maturity window for a sub-month tenure). - Frontend (separate commit) now sends tenureInDays instead of a truncated-to-zero tenureInMonths whenever the entered tenure is under 30 days. SCOPE / WHAT THIS DOES NOT TOUCH Only the interest-preview calculator endpoint above. Real FD/RD account submission still uses depositPeriod + depositPeriodFrequencyId (Days=0) exactly as before; this commit does not change how an actual account's maturity date/amount gets computed at activation. IF THIS BREAKS SOMETHING LATER - "tenureInMonths must be greater than 0" reappearing for a SHORT FD tenure -> check the frontend is actually sending tenureInDays (network tab on the Find Rate call); the validator's OR-logic is in DepositAccountDataValidator.validateForInterestCalc(). - A wrong preview maturity amount for a sub-month FD Single -> check FixedDepositAccountInterestCalculationServiceImpl#calculateInterest's branch choosing plusDays vs plusMonths for maturityDate. - This bug and fix were previously implemented once, then fully reverted mid-session at the user's request (unrelated Deposit Account Link regression got tangled up with it), then reapplied cleanly here as a standalone, narrowly-scoped fix. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-23 14:20:38 +05:30
niteshandClaude Opus 5	dd4bb4a1c0	feat(shares, cashier): enforce Share Collection entry type on listing, single receipt fetch, product summary ... Only vouchers tagged with the "Share Collection" entry type reach a share account. The adoption path already checked this, but the listing did not, so an already-adopted "General" voucher kept reappearing at Apply Collection and Apply Additional Shares time. SHARE_COLLECTION_TAGGED_ONLY now filters the listing query itself, against both the cashier-deposit and clerk-disbursement request tables. /unattributed takes an optional clientId and answers with both lists in one response -- that member's own unapplied receipts under "own", every other available receipt under "rows", with the member's own excluded from the latter. The two endpoints read the same table under the same filters, so asking twice only ever fetched the same rows twice, and keeping the query in two places is what let the entry-type filter land on one and miss the other. Both now share unappliedFor(). The entry fee is never posted a second time. A receipt already sitting in an INCOME GL was recognised as income by the cashier's own entry when it was taken, so applying the collection now skips both legs for it and counts it only towards verifying the fee was collected. Adds GET /sharereports/product-summary: authorised, issued, available and unpaid shares per product, with the distinctive range and account count. Adds a series-overlap pre-check to sponsor DD inventory registration, which previously surfaced as a bare duplicate-key error. Adds migration 0568 for the columns the clerk share-withdrawal settlement path reads (settlement_mode, tok_no, cash_settlement_txn_id, cashier_id, disbursed_by, disbursed_at, disbursement_denomination_data), each changeset guarded so it is a no-op where the column already exists. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-18 18:58:40 +05:30
niteshandClaude Sonnet 5	6046134b51	fix(shares): drop stale client-mismatch check, fix stale client_id on settle ... - Remove the client-mismatch validation in the Additional Shares tranche submit path (ShareAccountDataSerializer) for parity with the same decision already made on the first-application Apply Collection flow -- a voucher a counter was shown and allowed to pick should not then be rejected for the same reason at the very last step - Rewrite m_share_advance_collection.client_id to the settling account's own client at the moment a voucher is actually applied (both ShareAdvanceCollectionApiResource.apply() and AdditionalShareTrancheFundingService.settle()) -- a voucher can now be found and applied from any member's screen, so whoever last searched it is not necessarily who its money became share capital for, and the stale value was misnaming the receipt in its own detail popup after settlement Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-18 13:56:49 +05:30
nitesh	e4fad8b648	Merge branch 'dev-latest' of https://git.lincpay.tech/CBSNexora/cbsnexora-backend into dev-latest	2026-09-18 13:11:10 +05:30
niteshandClaude Sonnet 5	e206536a6b	feat(shares): reports suite, GL transaction fixes, strict entry-type enforcement ... - Add ShareReportsApiResource (final balance, account statement, issued/status/ nominal/share-wise/guarantor/member-interest reports, enquiry, payment certificate, share detail, dividend statement, folio statement, distinctive numbers, area-wise, mailing list) and ShareTransferApiResource, applying the paid-up-capital predicate everywhere so an unsettled application never counts as issued capital - Add share transfer migration (0567) - Enforce the original application's collection before a further tranche can be applied (ShareAccountDataSerializer), matching the same gate on screen - Fix postGlOffsetEntry silently discarding the real GL transaction id on the clerk-collection fallback posting path, leaving gl_transaction_id blank and the receipt's GL-detail popup empty - Add gl_code to the by-voucher and adoption responses so the GL Account picker on screen follows whichever receipt was found or adopted - Require an exact "Share Collection" entry-type tag to adopt a voucher -- "General" and untagged rows no longer qualify Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-18 13:02:55 +05:30
niteshandClaude Sonnet 5	bf52c2cda1	feat(shares): year-safe voucher numbers, universal Share Collection visibility, unrestricted apply ... Voucher numbers now embed the year (PREFIX/DDMMYYYY/NNNN) so the same day and month a year apart can never produce the same voucher_no text, which every lookup/dedup across the cash registers matches on literally. /shareadvancecollection/unattributed now lists every unapplied Share Collection receipt across every share account screen, not just ownerless GL deposits -- filtered to rows whose current Entry Type is still Share Collection even after adoption, with the linked member named for transparency. Applying a receipt to a share account no longer blocks on a client mismatch, per product decision. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-18 12:48:22 +05:30
niteshandClaude Sonnet 5	4c0512f154	feat(shares, cashier): tag GL counter entries by purpose, close DD/Share voucher cross-use ... A cashier Receipt or clerk Collection into a GL account never named who or what it was for, so a manager applying a share request could adopt a voucher a cashier had actually collected for a Demand Draft, and vice versa. Adds a GLEntryType code (General/Share Collection/DD Issue, extensible via Manage Codes) that the counter sets at save time; Share Advance Collection and Sponsor DD issuance both check it before adopting a voucher, and also cross-check each other's own consumption tables directly so the guard holds even for untagged legacy rows. Also: - Share-Collection-tagged vouchers auto-surface on Apply Share / Additional Share screens instead of requiring a manual GL-account search, but only when a matching client_id already exists on the row or the request is scoped to a specific member's screen -- a clientless GL receipt is never auto-attributed to whoever's screen happened to be open. - gl_transaction_id column on m_clerk_disbursement_request captures the real GL posting a Collection approval makes, previously generated and discarded. - New GET .../gl-entries endpoint exposes a receipt's actual Dr/Cr legs for detail popups. - Additional-share tranches restricted to a single funding voucher for now. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-17 17:39:59 +05:30
niteshandClaude Opus 5	b779d04571	fix(accounting): ledger transaction-id integrity, share GL correctness, and validation fixes ... Ledger transaction ids: - New LedgerTransactionId generator (PREFIX-YYMMDD-NNNN, e.g. DIVRND-260916-0001) backed by a dedicated m_ledger_txn_sequence counter (migration 0563) that belongs to no business table, so no table's sequence reset can make an id repeat. Migrated 18 hand-rolled id sites (dividend, branch day, closure, year-end, share collection/advance) off ad hoc nanoTime()/PK-concatenation strings. - ShareAccount.getShareAccountTransaction() matched a just-saved transaction by date+shares+price+ type and took the first hit -- two identical transactions on the same day resolved to the wrong one and posted under the older transaction's id. Now matches by id where one exists. Share accounting -- Cash at Vault fully retired from the share account/product lifecycle: - New ShareAccountingSuppression lets a register that posts its own accounting tell the platform not to post its native version (mirrors VoucherService.withOwnVoucher). Wired into share withdrawal, additional-shares apply/approve/reject and account close, so every governed flow now posts one balanced entry against the real counterparty instead of the platform's fixed Shares Reference placeholder, reversed and reposted. - Modify Application and Reject (the account's first application, pre-approval) no longer post via the native bridge at all -- no money has moved at that stage, so there was nothing to post. - The native "close" command no longer force-redeems a share account's remaining holding in one unguarded step; closing with a balance outstanding is now refused, so redemption can only happen through the governed Share Withdrawal flow the frontend already restricts it to. - "Share Reference (Cash Vault or Suspense)" is optional on the product, not mandatory: validator, GL mapping write/merge (including removing a stale mapping when the field is cleared on edit), and AccountingProcessorHelper's resolver (now throws a named error instead of NPEing when a product carries no mapping) all updated together. Removed from the product UI entirely (create, edit, preview, view). - AdditionalShareTrancheFundingService: submit posts nothing; settle() posts the whole entry itself, debiting whichever GL a voucher receipt actually landed in (read back from its own posting) or the member's savings account, crediting Share Capital. A voucher-funded tranche whose receipts total more than it costs now credits the difference to the member's linked savings account -- every named receipt is visited, not just enough to cover the tranche, since one left untouched here was still marked APPLIED and its money left untraceable. - ShareAccountDataSerializer: redeeming every share down to zero is exempt from the product's minimum-shares check (the check protects an account staying open with a reduced holding, not one being closed via a full exit); an over-payment on a voucher-funded tranche is refused at submit when no savings account is linked to receive it, rather than accepted and left unable to settle; six failWithCode(code, message) calls in the tranche validator were silently discarding their own message for the generic fallback text (failWithCode's second argument is a template arg, not a displayed string) -- switched to failWithCodeAndMessage. Removed: ShareCollectionApiResource, a direct-cash counter-collection endpoint that read m_share_account.cashier_collected, a column that has never existed in this schema -- no call site in this codebase's frontend reached it, and no entry it could have produced ever has. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-17 12:54:04 +05:30
niteshandClaude Opus 5	184d1b8cf8	feat(accounting): GL-funded DD issuance, share-withdrawal GL settlement, and ledger txn-id hardening ... Share withdrawal (clerk): - Add GL and NONE settlement modes alongside the existing SAVINGS mode. A clerk can now credit any GL account on the CR row of a Fund Transfer instead of the member's linked savings account; picking the product's own Sundry account self-cancels, so it downgrades to NONE and the request stands on leg 1 alone. - Post Dr Sundry / Cr chosen GL for GL mode; raise a standalone Dr Share / Cr Sundry voucher for NONE mode, read back from the ledger. Sponsor DD: - Let a clerk fund a Demand Draft by debiting a GL account directly (payment_method = GL) under the existing maker-checker flow, reusing the shared postGlOffsetEntry() so only the debit-side GL resolution differs. Cash reports and vouchers: - Fix the Closing Cash Report total row and opening-balance carry-forward. - Read the real till GL back from the underlying transaction when raising withdrawal, closure and loan vouchers, instead of labelling every leg "Cash in Hand". Ledger transaction-id hardening: A derived transaction_id text (e.g. "SH" + share transaction id) is not guaranteed unique if the underlying numeric id is ever reused, which a manual sequence reset can cause. Queries that read those rows back now disambiguate, and flag flips can no longer touch an unrelated transaction: - Read-back sites pick the most recently posted matching rows (ORDER BY id DESC + LIMIT) or, where the read happens long after posting, the candidate group whose created_date sits closest to the owning request's actioned_at. - Every UPDATE ... SET reversed = true/false WHERE transaction_id = ? is now guarded by the opposite reversed state, so a collision can only flip rows that are currently live. - Covers clerk disbursement, sponsor DD, cheque book, clearing, share tranche funding and share withdrawal. Migrations 0551-0554: settlement GL account and voucher_no columns for the clerk share withdrawal, dividend claim and sponsor DD issue request tables. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-16 17:16:17 +05:30
nitesh	af43944699	Merge branch 'dev' of https://git.lincpay.tech/CBSNexora/cbsnexora-backend into dev ... # Conflicts: # fineract-provider/src/main/java/org/apache/fineract/accounting/yearend/service/IncomeProfitTransferService.java # fineract-provider/src/main/java/org/apache/fineract/portfolio/dividenddashboard/api/DividendClaimRequestApiResource.java # fineract-provider/src/main/java/org/apache/fineract/portfolio/shareaccounts/service/ShareAccountSchedularServiceImpl.java # fineract-provider/src/main/java/org/apache/fineract/portfolio/shareproducts/service/ShareProductWritePlatformServiceJpaRepositoryImpl.java # fineract-provider/src/main/resources/db/changelog/tenant/final-changelog-tenant.xml	2026-09-14 12:17:01 +05:30
niteshandClaude Sonnet 5	6bb512e1fe	fix(cash): recognize GL-entry cash correctly in reconciliation and reports ... - Add CountedCashLedger: one shared rule for which m_savings_txn_denomination rows are real counted cash. Replaces a magnitude-only guard (which had itself been silently excluding legitimate manual-GL-entry cash from every cash screen) with a date-plausibility test -- a stamped garbage id decodes back to the day it was written, a real GL reference to an arbitrary date -- so a hex reference that happens to land in the old guard's excluded band is no longer misclassified as timestamp garbage - Apply it consistently in the day register close preview, the cashier position/day-book reports, the cash reconciliation screen, and the withdrawal stock check, so all four agree on the same drawer - GL Entries report: join m_voucher_line to show both legs of each voucher (debit and credit account) instead of only the cash leg its own denomination row happens to carry Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-14 07:19:05 +05:30
niteshandClaude Sonnet 5	04ac233fbe	fix: share collection GL lookup, tenant chart-of-accounts cleanup, and dormancy/date fixes ... - Add balancesheet API, GL account transaction guard, and disabled-feature filter - Recognize an approved Clerk Disbursement Request (COLLECTION direction) as a second valid source when resolving a Share Advance Collection voucher, not just a Cashier Transaction Entry deposit - Fix a NullPointerException in ShareAccount.getShareAccountTransaction() when an existing charge transaction has no total-shares/purchase-price recorded - Null out DormancyClock's "last live" date before an account is ever activated, instead of falling through to the client's own KYC re-verification date via Postgres's null-skipping GREATEST() - Stop seeding "Cash at Tellers" for new tenants (0502); drop the unused Facility & Service Charges Income accounts (0548); group header-less GL accounts under real-world header accounts (0549); uppercase GL account names and rename Share Sundry to match the bank's own chart (0550) - Fix 0527's savings-daily-interest changeset to skip objects 0517 already creates on a fresh tenant, instead of failing tenant startup - Update the local Postgres dev password default to match this environment Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-13 15:22:07 +05:30
nitesh	9e0c04583d	fix(roles): remove unused roles, merge managers, revoke Clerk's ALL_FUNCTIONS ... Audited role usage/permissions across all tenants and cleaned up several inconsistencies: - Removed 'Self Service User' (zero users, no wired-up purpose in the app). - Merged 'As Manager' into 'Branch Manager' (union of both permission sets, users reassigned, As Manager dropped) since the two covered overlapping ground with no clear split. - Revoked Clerk's ALL_FUNCTIONS grant: it unconditionally bypassed every individual permission check (HasPermissionDirective), so unticking any menu/permission for Clerk in Roles & Permissions had no effect. Clerk's own explicit permission rows are untouched and remain the effective set. - Renamed 'CASHIER' to 'Cashier' for display consistency with every other role name; the role-name check this touches (CashierRoleHelper) is case-insensitive, so behavior is unchanged. ('Principal Officer' was audited too but kept - it's the statutory PMLA/RBI compliance seat from 0435, just not yet assigned to anyone.) Each change was applied directly to all three tenant DBs and captured as a migration (0543, 0546, 0547), dry-run verified as a no-op against the now-updated DBs so it applies cleanly here and correctly for any new tenant.	2026-09-12 13:54:56 +05:30
nitesh	c20a7d0728	feat(security): tenant-level nav menu access control, independent of role permissions ... Adds a per-tenant ceiling on which of the 27 top-nav sections a bank can ever show, closing a real gap the "Clerk" role's ALL_FUNCTIONS misconfiguration exposed this session: HasPermissionDirective already hid a menu a user's own role lacked, but any role carrying ALL_FUNCTIONS bypassed that check unconditionally, so a bank's own super user (or a role accidentally granted ALL_FUNCTIONS) could always see everything regardless of intent. New table m_tenant_menu_access (0541), one row per menu code, seeded enabled for every existing tenant so nothing already deployed changes behaviour. New TenantMenuAccessApiResource: - GET /v1/tenant-menu-access — dual-mode (session or X-Api-Key), same posture as ClientAllAccountsApiResource. A tenant's own users read their own list to render their nav; the platform operator reads any tenant's list with the key, to know current state before toggling it. - GET /v1/tenant-menu-access/tenants — API key only, the master tenant list for the operator's own tenant picker. - PUT /v1/tenant-menu-access — API key only, no session fallback at all, even for a super user. This is the actual security boundary: a bank's own admin has no path to lift its own ceiling, because there is nothing inside their own tenant that can satisfy this endpoint's auth requirement. 0542 splits two nav items that had been sharing a permission code with their neighbour — Loan Origination rode on MENU_ADVANCES, Investment rode on MENU_RBI — into their own MENU_LOAN_ORIGINATION / MENU_INVESTMENT codes, so all 27 top-nav items are now independently controllable. Every role that already held the shared code is granted the new one in the same migration, so this changes nothing about who sees what today. SecurityConfig: permitAll for the two API-key-only paths, same posture as the existing clientaccounts carve-out — the handler itself is what actually authenticates the caller, not Spring Security's outer gate.	2026-09-11 15:07:13 +05:30
nitesh	6aa655a8a3	fix(cash): correct branch-day reconciliation, voucher classification and duplicate posting bugs ... BranchDayRegisterApiResource: - Make openDay/closeDay transactional and add an atomic closed_at guard so a double-close or a mid-write failure cannot leave the register half-updated. - Fix bookBreakdown()'s slip/closure withdrawal queries: m_clerk_withdrawal_request and m_clerk_closure_request store cashier_id as an appuser id in some registers and an m_cashiers id in others; try both via a dual EXISTS instead of assuming one, which was silently dropping real withdrawals from expected cash and producing a false "Short" on close. - Office-scope vault-in/settled-out and close-preview queries so a multi-office tenant's close no longer mixes another branch's cash into this one's. - closeDay requires closingCash and uses DateUtils.getBusinessLocalDate() for late-close detection instead of the server's own LocalDate.now(). - saveDenominationDetail() now deletes any prior snapshot for the same register/leg/teller before inserting, so a repeated save no longer sums duplicate denomination rows into the vault position. - resolveOffice() enforces office-hierarchy authorization via PlatformSecurityContext.validateAccessRights(). CashReconciliationApiResource / CashReportApiResource / DenominationBreakdownWriter: - Add a MAX_PLAUSIBLE_TXN_ID filter (consistent with the existing cash report guard) so a fabricated/oversized transaction id can no longer distort a cashier's expected or counted position. - Tolerate sub-rupee (paisa) rounding differences instead of requiring an exact amount match — Indian cash has no paisa coins, so exact-equality was rejecting correctly-counted cash. - CashReconciliationApiResource now trusts its own server-computed expected count rather than the client-submitted one when recording a reconciliation. VaultPositionService: - Only fall back to the branch-total OPENING leg when the office has exactly one teller; a multi-teller branch was getting one teller's vault entry applied to all of them. CashSettlementApiResource / CashInterCashierApiResource / CashExchangeApiResource: - Make settlement creation transactional; add a partial unique index (0540) blocking two active settlements for the same cashier/day, closing a double-submit race the application-level count check alone could not. - Validate a cash transfer against the sending cashier's actual denomination holdings and require both cashiers to be in the same office. - Default cash exchange date to the business date instead of null, and add the missing CREATE/REVERSE permission checks (0539 seeds them). CashierDepositRequestApiResource: - Namespace pending-deposit denomination rows with a +500,000,000 offset so they cannot collide with real transaction ids during approve/reject. ClerkDisbursementRequestApiResource (Disbursement/Collection/Fund Transfer/Bank Transfer register): - executeSavingsWithdrawal() was missing the withOwnVoucher() suppression its sibling methods already had, so every Collection-mode approval raised a second, orphaned voucher for the same money on top of the request's own — double-counting the figure in Received and Payments on My Vouchers. - Voucher numbering no longer hard-codes CR/DR by money direction. It now checks whether the payment type the clerk actually selected is cash (m_payment_type.is_cash_payment) and numbers into the Journal series when it is not, since a Transfer/Cheque/DD instrument never crosses the counter regardless of which GL it posts against. Bank Transfer vouchers (always account-to-account, never cash) are now unconditionally Journal too. - The voucher's TYPE column stopped being hard-coded to "DISBURSEMENT" for every request this register raises; it now stores the clerk's own request type (Disbursement/Collection/Fund Transfer/Bank Transfer) so My Vouchers shows what was actually submitted. VoucherVerificationApiResource (/my-work): - Classify a voucher's side (Received/Payment/Journal) by whether either of its lines actually touches the till (Cash in Hand or a cash-at-vault/teller GL), the same test the register listing already uses, instead of trusting the voucher number's own CR/DR prefix at face value. A Collection or Disbursement posted against a plain GL (no cash involved) was being counted as real cash received/paid; it now reads as Journal, matching what actually happened at the counter. Existing CR/DR requests with no lines yet are left alone, since there is nothing to test the till against.	2026-09-10 12:36:38 +05:30
niteshandClaude Opus 5	518b4d4afc	feat(client-accounts): active accounts only, drop balances/shares, add branch and bank details ... Adds branch pincode (new column + API + migration 0538) since it was missing. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-09 13:00:12 +05:30
niteshandClaude Sonnet 5	05bceea2d4	feat(office): maker-checker delete for offices; fix DB password leak, migration ordering, job id drift ... Adds the missing DELETE /offices/{officeId} endpoint -- the UI's "Remove" action called it already, but no backend route existed, so every attempt failed with a generic error regardless of how empty the office was. Wired the standard command-handler chain (CommandWrapperBuilder.deleteOffice -> DeleteOfficeCommandHandler -> OfficeWritePlatformService.deleteOffice), which pre-checks sub-offices/staff/clients/groups/users before deleting, and catches any remaining FK violation on delete itself. The new DELETE_OFFICE permission (0537) is seeded maker-checker-enabled (0538), since this app runs with the global maker-checker switch on and office deletion is irreversible -- 0538 is a separate changeset rather than 0537 itself because 0537 had already executed on local tenants by the time that requirement surfaced, and editing an already-run changeset's content breaks Liquibase's checksum validation on every tenant that ran it. Also bundles a few DB/startup fixes found while getting this feature running across local and a remote environment: - application.properties: restores the tenant DB password default that a teammate's own local password had overwritten in a previous push, and adds server.error.include-message=always so a servlet-level rejection (e.g. TenantAwareBasicAuthenticationFilter on a missing/invalid Fineract-Platform-TenantId header) carries a real message instead of a bare {timestamp,status,error,path}. - changelog-tenant.xml / final-changelog-tenant.xml: moves the 0517/0518 table-creation includes ahead of 0525-0527/0533, which read/write those tables but previously ran first per db.changelog-master.xml's include order -- caused "relation ... does not exist" on any tenant reaching that point for the first time. - 0536_sync_job_identity_sequence.xml: job.id is GENERATED BY DEFAULT AS IDENTITY; explicit-id job-seed inserts never advanced the backing sequence, so a later identity-generated insert could collide with an earlier explicit id ("duplicate key value violates ... job_pkey"). - ClientAllAccountsApiResource: NotFoundException(String) only sets the exception's own message for logs, it never reaches the response body, so a "client not found" 404 always came back empty; now built as a proper JSON error body. Also collapsed the message/defaultUserMessage/ errors[0].defaultUserMessage triple down to one message field -- this endpoint never raises more than one error at a time, so the repetition added nothing. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-08 15:16:07 +05:30
nitesh	317a308d8c	feat(client): add fast client-accounts lookup by client number or mobile number ... GET /v1/clientaccounts/{identifier} -- a single client's full deposit + share picture (Savings, Fixed Deposit, Recurring Deposit, Current, Share), looked up by client number or mobile number rather than the internal client id, so a teller with only the slip in front of them (or a third-party caller with only a mobile number) needs no separate client-search step first. Meant to answer "is there a problem here" (e.g. a share purchase that would exceed a product's issuable shares) BEFORE a manager approves something, not after. Deliberately its own lightweight resource rather than a reuse of the existing GET /clients/{clientId}/accounts (AccountSummaryCollectionData): that endpoint's row mappers each carry six LEFT JOINs to m_appuser for a full submitted/approved/rejected/activated/closed audit trail per account, which this caller doesn't need. One UNION ALL query (SB/FD/RD from m_savings_account split by deposit_type_enum, CD from its own m_current_account table, Share from m_share_account), each leg filtering on an indexed client_id -- fewer joins and one round trip is what actually makes this fast, not a different query engine. Identifier resolution tries m_client.account_no first (what a teller has), then mobile_no (what a third-party caller more often has) -- both unique indexed columns, so neither path costs more than a single index lookup. Reachable two ways: an ordinary logged-in Fineract user exactly as with any other endpoint, or a third-party caller via the new X-Api-Key mechanism (see the ApiClientCredentialService commit) -- one key now valid across every tenant, so the response echoes back tenantId/tenantName and the identifier that was searched, and a not-found error names the bank actually searched. Without that, "no client found" from the wrong bank (a stale or mistyped Fineract-Platform-TenantId header) was indistinguishable from a genuinely unknown client. Every date field is serialized as a plain ISO string, never a raw java.time.LocalDate: this Gson instance has no java.time adapter registered, and reflectively touching LocalDate's private fields is blocked outright by the JVM module system (java.base does not open java.time to an unnamed module) -- passing one through untouched turns the whole response into a 500.	2026-09-07 18:38:09 +05:30
nitesh	a83806062e	feat(security): add cross-tenant API key auth for third-party callers ... Endpoints that need to be reachable by a third-party integration without a Fineract username/password used to have no supported way to do that other than the heavyweight IMPS/NPCI pattern (RSA-signed JWT envelopes, built for one specific bank-switch protocol). This adds a general-purpose one: mint an X-Api-Key credential, hand it to the partner, done. New table m_api_client lives in the tenant-STORE database (fineract_tenants), not any one bank's own tenant database. That is deliberate: a key identifies a CALLER, independent of which bank's data a given request asks for, so one minted key keeps working against every tenant that exists now and every one provisioned later -- a per-tenant copy would need a manual re-insert on every new bank and a row per tenant per key, which is exactly what storing it once, centrally, avoids. Fineract-Platform-TenantId keeps doing what it always did: routes the rest of a request to the right bank's database. This table only decides who is allowed to make the request at all. ApiClientCredentialService.authenticate() is what an endpoint calls in place of PlatformSecurityContext#authenticatedUser() when it sees an X-Api-Key header. Security properties: - Only a SHA-256 hash of the key is ever stored -- same reason Fineract never stores a user's plaintext password. The raw key is returned exactly once, at creation (POST /v1/apiclients), and cannot be retrieved again. - Every failure path (key doesn't exist, is deactivated, caller's IP isn't on its allowlist) raises the identical 401 message, so a probing caller can't use the response to tell a wrong key apart from a valid-but-blocked one. - allowedIps is a plain comma-separated exact-match list, adequate for a small set of known partner integrations, not CIDR ranges. ApiClientAdminApiResource (create/list/deactivate/reactivate a key) is itself gated by an ordinary Fineract login restricted to a super user (ALL_FUNCTIONS) -- issuing a credential that skips login is not something to hand out casually. SecurityConfig gets one new permitAll() matcher, narrowly scoped to GET /api/*/clientaccounts/** -- the same posture this fork already uses for the IMPS and NPCI receivers: the outer Spring Security gate stays open for one specific path, and the resource itself is what actually authenticates the caller. A normal logged-in SPA user hitting that same path is unaffected -- Basic Auth still runs for any request that carries an Authorization header, permitAll only stops an anonymous one from being rejected before the handler gets a chance to check for a key instead.	2026-09-07 18:38:08 +05:30
nitesh	a04b65583e	fix(closure): post interest for real at submission, not as a dry-run estimate ... Ticking "Close this account" used to only preview the payout: assemble the account, run the same postInterest domain call close() will, read the resulting balance, then roll the whole thing back (GET /preview/{id}). Nothing was ever credited until the manager approved, and the account's own Interest Posted / Interest Earned figures stayed stale in the meantime. Changed to actually post the interest at that moment (POST /post-interest/{id} and again in submit()), via SavingsAccountWritePlatformService#postInterest(SavingsAccount, boolean, LocalDate, boolean) -- the exact service method close() itself calls, not a new calculation. Not routed through the POSTINTEREST_SAVINGSACCOUNT command: that command ships maker-checker-enabled in base Fineract, and CommandSourceService#processCommand runs the handler first, then throws RollbackTransactionNotApprovedException from inside the @Transactional method -- which would silently roll back the very posting just made. Depends on the sibling SavingsAccount fix (double-posting across runs) -- without it, ticking the checkbox on one business day and having the manager approve on a later one re-slices posting periods and credits the overlapping days twice. Also: - Locks the closure date at submission (stored on the request row) and replays that same date at approve() instead of re-reading today's business date, so close()'s own postInterest(account, true, closedOnDate, false) slices identical periods, matches the amounts already posted at submission, and adds nothing -- the figure quoted to the member at submission is what gets paid out however long the request sits in the manager's queue. - Populates closing_amount/rounding_amount/cashier_disbursed_amount at submission time instead of leaving them null until approval, since the interest posting above already makes the real payout figure known then -- the manager's review screen no longer shows a blank amount for a PENDING request.	2026-09-03 10:41:38 +05:30
nitesh	f6686b0c8f	fix(savings): stop manual interest postings from double-counting across runs ... SavingsAccount#postInterest silently double-credited interest whenever a manual posting ("Post Interest As On", or close() closing an account) ran on two different dates against the same account. Root cause: postInterestOnDate=D makes SavingsHelper#determineInterestPostingPeriods close a period at D-1, so the resulting transaction is dated D-1, not D. The next run's getManualPostingDates() feeds that D-1 date back in as a boundary, which closes a period at D-2 instead. The old posting's date (D-1) then matches no period end in the new run, so findInterestPostingTransactionFor() never finds it, it is never reversed or corrected, and a new posting is created alongside it covering the very same days. total_interest_posted_derived drifts above what was actually earned by exactly the overlapping amount. Reproduced live: posting "as on" 02 Sep then 03 Sep on the same account left a stray 0.35 posting dated 01 Sep plus a new 0.97 posting for 01-02 Sep -- 1.32 posted against 0.97 actually earned. Fix: before applying this run's periods, reverse any manual posting whose date matches no period-posting-date this run computed AND whose days are covered by a period this run WILL post (posting date <= interestPostingUpToDate). The second condition is deliberate -- it is what stops this from reversing a posting whose days are simply not being re-posted yet (e.g. the recalculation Fineract runs right after a withdrawal, where the remaining period matures in the future and posts nothing for those days). Automatic (non-manual) postings are untouched; they sit on natural period ends, which always recur correctly. Affects every caller of the base postInterest/calculateInterestUsing pair, including FixedDepositAccount and RecurringDepositAccount (both delegate to super.postInterest for their day-to-day interest recalculation, though not for postMaturityInterest, which is a separate, untouched method) -- so this also closes the same double-count window for FD/RD accounts, not just plain savings.	2026-09-03 10:41:14 +05:30
nitesh	45c2826a42	Revert "fix(savings,closure): post interest for real when a closure is checked" ... This reverts commit c86e0d1cc2.	2026-09-02 18:31:45 +05:30
niteshandClaude Opus 5	c86e0d1cc2	fix(savings,closure): post interest for real when a closure is checked ... Ticking "Close this account" previewed the payout with a dry run — assemble the account, call the same postInterest domain method close() will, roll the whole transaction back. The clerk asked for the actual thing: post the interest now, the same as "Post Interest As On" always did and the same basis FD uses at maturity, so the figure shown is the account's real balance rather than a simulation of one. Switched to calling SavingsAccountWritePlatformService#postInterest(SavingsAccount, boolean, LocalDate, boolean) directly -- the exact method close() itself calls -- instead of going through the ordinary POSTINTEREST command pipeline. That matters: POSTINTEREST_SAVINGSACCOUNT ships maker-checker-enabled in base Fineract, and a Clerk is not a checker for it. Routed through commandsSourceWritePlatformService, CommandSourceService#processCommand runs the handler first, then evaluates maker-checker and throws RollbackTransactionNotApprovedException -- which, thrown from inside that @Transactional method, rolls back everything the handler just did and drops the request into Fineract's own generic Checker Inbox. This feature already has its own maker-checker (submit here, approve in Closure Requests); the posting now rides inside that instead of opening a second, unrelated approval queue for the same click. Left uncommitted-to on purpose: unticking the box or a later rejection leaves the posting in place, since it is interest the member had genuinely earned either way. Re-ticking re-runs postInterest safely -- the domain layer finds today's posting already there and no-ops rather than posting twice. If manager approval lands on a later business date, close() tops up the extra days on top; it never re-posts what already matches the date it is closing on. Endpoint changed GET -> POST to match: it now mutates. The dry-run machinery (SavingsAccountAssembler kept, but PlatformTransactionManager/TransactionTemplate/ ConfigurationDomainService/MathContext all dropped) is gone with it -- the real service method already handles all of that internally, the same way it does for every other caller of postInterest. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-02 17:29:14 +05:30
nitesh	c052beeacf	feat(branchday): reject day close if cashiers given cash are not reconciled or settled	2026-09-02 12:07:24 +05:30
niteshandClaude Opus 5	942bad6c8c	fix(branchday): count account closures in the day-close cash reconciliation ... Day Close reported SHORT by exactly the amount a closure had paid out. The "Cash paid out (approved withdrawals)" line only summed m_clerk_withdrawal_request, so a closure -- which pays cash over the same counter but lives in its own register -- was missing from the total. Expected cash stayed high by what had actually been handed over, and a closure that balanced perfectly read as a shortage. Verified against live data: opening 145,304 + deposits 0 - slip withdrawals 0 - closure 12,999 = 132,305, which is exactly the counted branch total. Variance goes from -12,999 to 0. Sums cashier_disbursed_amount rather than closing_amount: the member's ledger gives up the paisa-exact figure, but what physically leaves the drawer is that figure rounded to whole rupees, and this total has to agree with a physical count. Restricted to CLOSED rows dated on disbursed_at, since a closure takes nothing out of the drawer until the cashier hands it over. Note: dividend cash claims (m_share_dividend_claim_request) are also absent from this total and will misreport the same way. Left alone deliberately -- that register splits a claim across loan/savings/cash with its own cash_status column that nothing in the Java sets, so the right predicate cannot be established from the code as it stands. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-01 21:58:12 +05:30
niteshandClaude Opus 5	5a9a103832	Merge branch 'maker-checker' into dev ... Brings in maker-checker for GL accounts, charges, product creation (loan, savings, current, share, FD), admin users/roles and base interest rates, plus the UserPendingRequest domain and AppUserPreference. Two resolutions: changelog-tenant.xml — both branches appended <include> lines at the end of the file, so the conflict was append-vs-append with no semantic overlap. Kept both sets in order: dev's 0470-0499 followed by maker-checker's eight. Liquibase runs in <include> order, not filename order, so the reused 0466-0476 numbers change nothing (dev already carries duplicate numbers in that range). application.properties — the branch carried another developer's local database password, which would have stopped this backend connecting at startup. Restored ours; the file is now byte-identical to its pre-merge state. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-01 18:07:24 +05:30
niteshandClaude Opus 5	fd91da3d76	feat(savings,cashier): maker-checker cash closure with vouchers and rounding ... Closing a savings account paid real cash out of a teller's drawer in one click, with no maker-checker, no cash-position tracking, and no way to hand over a paisa balance (no paisa coins circulate, and the denomination writer demands an exact match). This adds a Clerk -> Manager -> Cashier flow for Cash closures, modelled on the existing Clerk Withdrawal Request. New ClerkClosureRequestApiResource: - submit: Cash only, token required, guards ACTIVE status and open requests - approve: runs Fineract's own close command (pro-rata interest and the real GL withdrawal post here, atomically), reads the posted transaction back, rounds the payout to whole rupees and posts the difference to a new Round Off Account. A nil-balance closure goes straight to CLOSED rather than parking forever in a cashier queue with no cash to hand over. - disburse: cashier records the denomination breakdown against the rounded figure and the account closes - preview: dry-runs the very same interest posting close() performs, inside a REQUIRES_NEW transaction that is rolled back, so the figure shown to the clerk matches the real payout to the paisa. Reading the stored accrual instead gave a days-stale number, and CALCULATEINTEREST is not equivalent: it uses MathContext(15) and no postInterestOnDate, where close() uses MathContext(10) and feeds the closing date in as a posting-period boundary, which changes how many per-period roundings happen. Vouchers: close() reaches handleWithdrawal directly rather than through the withdrawal command handler, so the handler's own raiseSavingsVoucher never ran and a closure paid cash out with nothing in the voucher register. One is now raised at disbursement -- when the cash actually crosses the counter, in the cashier's name -- with three lines that match the posted GL exactly: Dr Savings Control + Dr Round Off = Cr Cash. Cash direction: the rounding adjustment debited Cash where cash leaving the drawer is a credit, leaving the cash GL disagreeing with what was physically handed over. Both legs corrected. Dates: closure_date, closedOnDate, the preview and the rounding entry now all use the CBS business date, so preview and approval cannot land on different days across a day roll. Day Book: closures were absent entirely (it reads the request registers, not m_voucher). Added as a fourth register, restricted to CLOSED rows and dated on disbursed_at, since a closure only becomes a cash-book event at hand-over. Its terminal status CLOSED was also missing from the totals gate, so a completed closure moved real money out without appearing in the DR total. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-01 15:20:08 +05:30
nitesh	c4a99fea5d	feat(savings,clerkwithdrawal): expose linked share account on savings read, add search filter to withdrawal request lists ... Surfaces shareAccountId/shareAccountNo on the savings account read API so the UI can display and auto-select an already-linked share account; adds an optional search query param to the clerk cash and share withdrawal request list endpoints for the Approval Center's new search boxes.	2026-09-01 07:40:39 +05:30
niteshandClaude Sonnet 5	dc0539d53d	feat(savings,shares): bidirectional savings/share account linking, optional savings link on share create ... - Savings account creation validates and stores a required "shareAccountId" once Share Linking is enabled, checked against the client's own active share accounts (raw SQL - fineract-savings has no dependency on the shareaccounts domain). On save, mirrors the link back onto the share account's own savings_account_id, the same way that field already gets set from the share side. - New GET /clients/{id}/activeshareaccounts - a client's active share accounts, for the savings creation screen's picker (kept separate from the shared Savings/FD/RD/Current template DTO). - ShareAccountDataSerializer.validateAndCreate no longer requires savingsAccountId on create - the DB column and domain relationship were already nullable, only this validation blocked it. fix(branchday): stop the denomination carry-forward preview from doubling yesterday's closing count GET /branchday/denominations classified every detail row that wasn't literally leg='OPENING' as "closing" - which, once CLOSING_VAULT rows existed alongside CLOSING (single-teller offices record the same breakdown under both), silently doubled every count shown as "yesterday's closing" when opening the next business day. Filters to leg IN ('OPENING','CLOSING') explicitly instead of an else-catches-everything branch. feat(accounting): seed missing Income/Expense/Transfers-Suspense/Escheat-Liability accounts The Basoda-derived chart of accounts (0523) carried none of these - a balance sheet has no P&L heads, and Transfers Suspense/Escheat Liability aren't balance-sheet line items either - so a Savings Product's accounting mapping had nowhere to point those required fields. Same guard as 0523: only seeds a Basoda-derived tenant that hasn't already gotten it, never touches a tenant with its own chart of accounts. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-31 22:17:54 +05:30
niteshandClaude Sonnet 5	509370eaeb	fix(shares,voucher,cashreport): route redeem/withdrawal through Sundry, fix voucher cashier attribution and GL-name resolution ... - ClerkShareWithdrawalRequestApiResource: reverse native redeem GL legs and reroute through Sundry (Dr Share Reference / Cr Sundry, then Dr Sundry / Cr Savings Control), reusing the native transaction_id so both legs display as balanced; wholesale-reverse and reroute the linked savings credit the same way. - ShareAccountWritePlatformServiceJpaRepositoryImpl: undoApproveShareAccount no longer re-triggers the native "isApplied()" phantom GL posting Fineract's accounting bridge makes on approval. - VoucherService/ClerkWithdrawalRequestApiResource: attribute a voucher to the cashier who actually disbursed cash, not the submitting clerk, once disbursal completes. - CashReportApiResource: scope the GL-entries deposit/withdrawal joins by txn_type to stop a hex/decimal txn_id collision from borrowing an unrelated transaction's voucher number; resolve GL account names (not just client names) in the "A/C NAME" column. fix(branchday,cashreport): stop the vault position from double-counting a cashier's unsettled cash BranchDayRegisterApiResource's day-close folded every cashier's still-held cash into the branch's combined closing figure, which then carried forward as next day's vault opening. When that cash was later settled back to the vault, CashReportApiResource added it a second time - once already baked into the carried-forward opening, once as the settlement itself - manufacturing a phantom "Excess" equal to whatever was unsettled. Adds a vault-only OPENING_VAULT/CLOSING_VAULT leg (new VaultPositionService, shared by both resources) alongside the existing branch-total OPENING/CLOSING legs, so the vault's own anchor never includes cash that still physically sits with a cashier. feat(accounting): seed a missing opening-balance contra account and a real bank's chart of accounts - Financial Activity 300 (opening-balance transfer contra) was never mapped in any tenant's chart of accounts, so any opening-balance flow failed outright; backfilled it and added a migration to seed it for every tenant going forward. - Seeds a brand-new, otherwise-empty tenant with a real cooperative bank's chart of accounts (transcribed from its balance sheet), guarded to never touch a tenant that already has its own. - Removes 0451's hardcoded demo branch offices, which were seeding into every new tenant regardless of institution. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-31 15:06:57 +05:30
niteshandClaude Sonnet 5	1130a482a0	feat(shares): centralized Additional Shares approval queue, remove unused Share Savings Debit ... - Add ShareAdditionRequestsApiResource (/v1/shareadditionrequests): lists every pending additional-share tranche across all accounts, with a per-tranche detail view carrying the route-specific proof of funding a list row can't show (which voucher(s) fund a cash tranche, or which savings account a savings tranche already debited). Approval/rejection still go through Fineract's own approveadditionalshares/rejectadditionalshares commands unchanged -- this is a read side only, so the existing settle()/unwind() hooks fire from exactly one code path. - Remove ShareSavingsDebitRequestApiResource and its m_share_savings_debit_request table (migration 0520): confirmed zero rows on both tenants since it was built, and superseded by Additional Shares' own savings-funding route, which values a tranche on its own rather than by summing the account's entire holding history. - Update comments in ShareAccountWritePlatformServiceJpaRepositoryImpl, ShareAccountDataSerializer, AdditionalShareTrancheFundingService and AdditionalSharesFundingApiResource that referenced the removed class/endpoint. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-30 20:37:33 +05:30
niteshandClaude Sonnet 5	8ecab08d57	fix(shares,savings): remove product-config voucher auto-resolve, fix charge/currency edit bugs, gate withdrawal on settlement ... - ShareAdvanceCollectionApiResource: drop the hardcoded/auto-resolved Share Suspense GL lookup for by-voucher search; GL account and voucher are now both required, manually-selected inputs. apply() now accepts a separately-verified entry-fee receipt (chargeCollectionId) so a fee collected into a different GL than the share value is never swept into the Sundry leg or double-posted to income. - ClerkShareWithdrawalRequestApiResource: hard-block approval when collection_applied is false, so shares nobody has actually paid for can't be redeemed off an Active-but-unsettled account. - ProductPendingEditFieldMapper / ShareProductDataSerializer: fix maker-checker edits on share products silently dropping charges (chargesSelected vs charges field-name mismatch) and NPEing on approval when the replay JSON carries no currencyCode. - SavingsAccount: initialize the clearing-hold field to zero so new savings submissions don't violate the NOT NULL constraint on total_savings_amount_on_hold_clearing. - CashReportApiResource: fix voucher number resolution for GL-type ledger entries. - application.properties: revert local tenant DB password default. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-30 20:02:50 +05:30
niteshandClaude Sonnet 5	6ffb0dd9c0	fix(savings,cashier): auto-post pro-rata interest on closure, split Cash/Clearing hold, fix WITHDRAWN-status blind spots ... Closing a savings account used to only ever validate that interest had already been posted on the closing date (opt-in, off by default) -- with nothing posted beforehand the partial period's interest was simply never paid. It now always calculates and posts it before the account closes, reusing the same machinery the manual "post interest as of date" action already relied on. Savings accounts now track two separate hold totals instead of one: a manual/staff-placed Cash Hold (the existing lien mechanism, unchanged for every caller that doesn't ask for the new category) and a Clearing Hold for money still moving through the clearing process -- a Cheque/DD cashier deposit now automatically places one for the full amount at approval time, and CTS inward-clearing holds are now bucketed here too, since both are genuinely about the clearing pipeline rather than a lien someone chose to place. A new self-contained endpoint releases due Clearing Holds (wire it into an external scheduler); the existing manual release action now credits back whichever bucket the original hold actually debited. Approving a Cheque/DD deposit dispatches this automatically as the approving manager, so the checker roles that call deposit-approval needed the underlying HOLDAMOUNT/RELEASEAMOUNT permissions granted -- without it every such approval would now fail outright; a stray column-name bug in the payment- type lookup that surfaced this in testing is fixed too, guarded going forward by a try/catch so a problem in this best-effort step can never sink the deposit approval it rides along with. A clerk withdrawal's own terminal status is WITHDRAWN, not APPROVED -- deposits and disbursements use APPROVED, withdrawal is the one register that doesn't. Three places were still filtering on APPROVED alone and silently excluding every completed withdrawal: the Day Book's CR/DR totals, and the branch day register's own "cash the branch should be holding" formula (which overstated the expected figure by exactly what had been paid out, manufacturing a phantom cash-short every time a withdrawal happened that day). The GL Entries report showed a bare internal transaction id under "Voucher No" instead of the real formatted voucher stamped on the underlying deposit/withdrawal request; it now resolves and shows that instead. Denomination rows saved at deposit/withdrawal submission never recorded which payment type was used, always leaving "Payment Type" blank regardless of what the cashier actually collected -- both insert paths now carry it through, and existing rows are backfilled. FacilityChargeSeederService no longer hardcodes an income GL account onto the facility charges (ATM, UPI, Cheque Book, NEFT, ...) it seeds. Fineract's accounting engine uses a charge's own GL account ahead of its savings product's own "Income From Fees" mapping whenever one is set, so seeding all sixteen onto the same shared account (picked essentially by accident) silently overrode every product's own accounting configuration with it. Leaving it unset lets each product's own mapping decide where this income actually posts, which is the point of that mapping existing at all. Institution/Branch Profile's READ permission was scoped to manager/admin roles only, since it started as an org-setup-only screen -- now that the Passbook and Statement screens read it for their letterhead (real bank name, license number, branch IFSC/MICR) instead of a hardcoded name, and both are reachable by a cashier/clerk/teller, the read-only permission is extended to those roles too. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-30 10:37:53 +05:30
niteshandClaude Sonnet 5	8d224a22b4	fix(branchday): correct timestamp serialization, require a reason for an opening cash mismatch ... Opened-by/closed-by times on the day register were rendering blank: the JDBC Timestamp's own toString() separates date and time with a space, not the ISO-8601 'T' every frontend consumer parses on. str() now formats a Timestamp explicitly instead of falling through to the generic toString(). Opening a business day with a note/coin count or lump sum that did not match the branch's own closing figure from the day before was previously accepted with no record of why -- every downstream figure (vault position, EOD summary, the next day's own carry-forward) would then be built on an unexplained short or excess baseline with nothing to explain it later. The open endpoint now requires an openingDifferenceReason whenever the caller supplies a figure that differs from the prior close, enforced server-side so it can't be bypassed by calling the API directly; a day with no prior close, or one left to the automatic carry-forward untouched, is unaffected. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-29 11:01:30 +05:30
niteshandClaude Sonnet 5	f746a1fb2c	feat(cashier,accounting): denomination-aware vault controls, Bank/Branch Master, Fund Transfer request type ... Closes the gap where a vault could hand out more cash (in total or in a specific note/coin) than it actually held: CashTransferApiResource now validates against the branch day's opening denomination breakdown plus today's settlements/transfers, and blocks entirely when no business day is open. BranchDayRegisterApiResource gains a real denomination breakdown per open/close leg (migration 0510), carried forward automatically day to day, and its book-cash formula no longer double-counts vault-to-cashier transfers as new cash in. CashReportApiResource adds a vault-position report (the teller/vault analogue of cashier-position) and fixes an off-by-one date comparison that excluded same-day transfers from a vault's anchor position. Institution/Branch Master: new InstitutionProfileApiResource and BranchProfileApiResource (migrations 0511-0513) give the bank a real "Bank Master" profile (identity, regulatory details, address, SWIFT/BIC) and each office its own branch-level fields (code, IFSC/MICR, working hours, geo-location) as side tables on m_office rather than touching the stock Fineract office entity. ClearingGlConfigApiResource exposes the previously config-only-via-SQL m_clearing_gl_config mapping (CTS/NACH/RTGS suspense accounts) as a proper admin API. ClerkDisbursementRequestApiResource now accepts a FUND_TRANSFER request type alongside DISBURSEMENT/COLLECTION/BANK_TRANSFER, and migration 0514 grants the teller-facing roles READ_CLIENTNOMINEE, which they were missing entirely. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-28 14:36:59 +05:30
niteshandClaude Sonnet 5	1bc9d0901d	feat(savings): facility charge mapping admin API, enforce mapped-charge validation, INR-only currency, GL chart backfill ... Adds the admin read/write API for m_facility_charge_mapping (list, template, update) so facilities can be pointed at a real charge instead of relying on the seeder's implicit auto-link, and makes enable-on-account paths (activation and edit-approval, both savings and current accounts) throw instead of silently skipping the charge when a facility isn't mapped or is inactive. Migrations 0497-0509 back this up: reset all facility mappings to unmapped/inactive by default, backfill lost roles/permissions/charges, enforce INR as the only organisation currency, backfill the full real-world chart of accounts (44 core + 60 priority GL heads) with standardized gl_codes, and retire the unused system-defined payment types (Share Redemption Transfer and friends) in favor of Cash/Transfer only, matching the teller dashboard's simplified payment-type flow. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-27 18:41:42 +05:30
niteshandClaude Sonnet 5	58187c23d0	fix(migrations): remove fake test-data seeds, backfill lost permissions, merge redundant roles ... Migration-hygiene fixes found while auditing whether a fresh database would end up with the same schema/permissions/roles as this dev database. 1. Remove fake test-data seed migrations 0449_seed_aml_test_alerts.xml and 0459_seed_aml_alerts_awaiting_review.xml unconditionally inserted 3 fictional clients (CLIENT_RAJESH/SONIA/VIKRAM) and 5 fake AML alerts against them on every environment, including production if this migration path ever ran there. 0459's own comment confirms it was written purely to exercise the AML review UI. Deleted both files and their <include> entries; cleaned the same fake rows out of this dev database (3 clients, 5 alerts, plus the now-orphaned databasechangelog bookkeeping rows for the two deleted files). 2. Backfill 3 permissions lost to a migration-number collision Auditing all 2712 changesets applied to this dev database against the current codebase found 18 changeset filenames with no matching file anywhere in git; changelog-tenant.xml itself already documents the root cause (multiple branches independently reusing the same numeric prefix for unrelated migrations, e.g. 0456-0462 twice). Cross-checking each affected table/permission against actual Java usage (@CommandType handlers, domain/API classes, and both permission-insert styles used in this codebase -- Liquibase <insert> columns and raw <sql> literals) showed 15 of the 18 are genuinely dead (reconciliation-batch/settlement- cycle prototype tables, fixed asset/inventory tracking) with zero current code referencing them, so nothing to backfill there. The remaining 3 -- MENU_RECONCILIATION, READ_RECONCILIATION, SIDEBAR_RECONCILIATION -- gate a live module (CashReconciliation / ClearingReconciliation have real API resources and domain classes) but were never seeded by any migration; without them a fresh database can build and expose the reconciliation screens with no way to grant a role access to them. Added 0491_add_reconciliation_menu_permissions.xml. 3. Merge two pairs of redundant roles - "Bank Cashier" (4 fund-transfer permissions, 0 of which overlapped "CASHIER", 0 users assigned) folded into CASHIER. - "AML Officer" (2 permissions, both already present on "Principal Officer", 0 users assigned) folded into Principal Officer. Both migrations copy any missing permissions and move any assigned users onto the surviving role before deleting the redundant one, so they're safe to run against an environment that isn't empty the way this dev database is. Applied the same merge directly to this dev database's m_role / m_role_permission / m_appuser_role rows. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-27 11:27:42 +05:30
niteshandClaude Sonnet 5	72221f704d	feat(deposits,clients): FD Special auto-configuration, interest schedule projection, and minor-age backend mirror ... Three related pieces of backend support for this session's FD Special (monthly interest payout) work, plus one more instance of the same transaction-ordering bug fixed elsewhere this session. 1. FD Special account creation/modification auto-configuration FD Special (fdType=SPECIAL) is a non-cumulative product: interest must post monthly and leave for a linked savings account, and maturity must auto-transfer the principal out -- regardless of whatever compounding/ posting period or maturity instruction the request otherwise carries. Previously none of this was enforced, so a SPECIAL account could be created with e.g. quarterly compounding, or a later "modify application" request could silently unset transferInterestToLinkedAccount / the maturity instruction / the linked account by mere omission of those fields from the payload, while the account kept displaying as "FD Special". - DepositAccountAssembler: on create, forces interestCompoundingPeriodType and interestPostingPeriodType to MONTHLY, transferInterestToSavings to true, transferToSavingsId to the (now required) linked savings account, and accountOnClosureType to TRANSFER_TO_SAVINGS, whenever fdType is SPECIAL. Throws a clear domain error if no linked account was selected. - DepositAccountTermAndPreClosure: new forceMonthlyPayoutToLinkedSavings(), re-applying those same three standing-instruction fields. - DepositApplicationProcessWritePlatformServiceJpaRepositoryImpl: calls the equivalent re-enforcement on every modify-application request for a SPECIAL account, after the linked-account resolution in that same method has settled what account (if any) ends up linked. 2. FD Special projected interest schedule (engine + API) Staff/customers previously only saw a flat rate/12 approximation of monthly interest. Added a real, engine-computed month-by-month schedule: - DepositAccountWritePlatformService(Impl): new retrieveProjectedInterestSchedule(), running the same PostingPeriod engine the real maturity calculation uses (FixedDepositAccount# projectInterestSchedule), side-effect-free (@Transactional(readOnly)), clipping the last period's displayed end-date to maturityDate-1 (the engine otherwise rounds it out to the next calendar boundary even when maturity falls partway through), and flagging each period "paid" by matching real posted-interest transaction dates. - FixedDepositAccountsApiResource: computes and attaches the schedule, plus server-computed totalProjectedInterest/totalValueAtMaturity, to the FD template response for SPECIAL accounts only. - FixedDepositAccountData / DepositsApiConstants: carrier fields and response-parameter whitelist entries for the three new fields. 3. Minor-age threshold: backend now matches the frontend's shared constant Companion to this session's frontend minor-age-threshold change (18 -> 10, see client-age.util.ts). ClientKycApiResource's minor detection (which gates the required-KYC-document list, including whether PAN is mandatory) was still hardcoded to age < 18. Added ClientApiConstants.MINOR_AGE_THRESHOLD (10) and SENIOR_CITIZEN_AGE_ THRESHOLD (60) as the backend's own named constants, and switched the KYC endpoint to use MINOR_AGE_THRESHOLD, so the two sides can't silently disagree on who counts as a minor. 4. SavingsAccountTransactionComparator: same-date tie-break fixes another instance of this session's core reversal bug For a Special FD's interest-transfer sweep, the withdrawal shares the exact transaction_date of the interest posting it pays out. When that posting is reversed and recreated, the new posting transaction gets a higher id than the already-existing withdrawal; the comparator's id-order tiebreaker then sorted the withdrawal before the new posting, which understated the running balance shown between them (e.g. showing Rs.99,901.39 instead of Rs.100,000.00 immediately after the pair). Added an explicit tiebreaker so a same-date, same-createdDate interest posting always sorts before a withdrawal/debit. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-26 19:02:17 +05:30
niteshandClaude Sonnet 5	a42a874811	fix(deposits): stop FD Special interest postings from self-correcting after settlement ... FD Special (monthly interest payout) accounts post interest each month and immediately sweep it to a linked savings account. Two independent interest recalculation paths were treating that sweep withdrawal as ordinary account activity and silently reversing + reposting already-settled periods at a slightly different (rounding-drifted) amount — after the original, correct amount had already been transferred out. This left the FD short by the difference every time it happened. Root causes (two separate engines, same underlying bug pattern): 1. SavingsAccountDomainServiceJpa#handleWithdrawal re-triggers a full postInterest()/calculateInterestUsing() after every withdrawal, including the sweep withdrawal itself. At that exact moment the withdrawal's own m_account_transfer_transaction linking row does not exist yet, so the balance-exclusion logic can't recognise it as a transfer leg — it gets treated as a real balance-reducing transaction and corrupts that period's (and any later period's) interest calculation. 2. SavingsAccountInterestPostingServiceImpl (the "Post Interest For Savings" batch job) has its own, separate reverse-and-repost correction loop with the same lack of a "was this period already settled" guard. Fixes, both scoped strictly to FD Special (transfer_interest_to_linked_account = true) so plain savings and recurring deposit behaviour is provably unchanged (the new hooks all default to the prior behaviour unless overridden): - SavingsAccount: new isInterestPostingCorrectionAllowed(...) extension point guarding the postInterest() correction loop; new isPostWithdrawalInterestRecalculationRequired(...) hook checked by handleWithdrawal before it re-recalculates; new refreshBalancesAndSummaryAfterTransfer(...) — the running-balance/summary bookkeeping postInterest() always performs, without re-running the posting/correction loop, so skipping the full recalculation doesn't leave the withdrawal's own running balance and the account summary stale. - FixedDepositAccount: overrides both hooks using the existing interestAlreadyPaidOut(...) date-matched sweep-withdrawal check (already used by postMaturityInterest) so an already-swept period is never recalculated again, from either the withdrawal path or a later job run. - SavingsAccountInterestPostingServiceImpl: mirrors the same guard (isInterestAlreadySweptOut) in its own correction loop for the batch job. Unrelated correctness fixes carried in the same files, applicable to any account type (not FD-Special-specific), found while investigating the above: - SavingsAccountWritePlatformServiceJpaRepositoryImpl: interest-payable GL entries were reading a financial_account_type that never exists in acc_product_mapping, always resolving to account id 0. Now reads the correct getGlAccountIdForInterestOnSavings(). - DepositAccountInterestRateChart#getApplicableInterestRate: missing break in the slab-matching loop meant HashSet's non-deterministic iteration order could pick an arbitrary matching slab instead of the intended one. - SavingsAccountReadPlatformServiceImpl / SavingsAccountData: thread the real transfer_interest_to_linked_account flag into the batch interest engine's per-account data so it can correctly disable interest compounding for FD Special (previously hard-coded false, causing the batch job to compound interest that should reset to zero each period). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-26 18:53:12 +05:30
niteshandClaude Sonnet 5	46f5a1babd	feat(deposits): FD in-place renewal, senior-citizen rate persistence, and Payment action ... WHAT THIS CHANGES ================== Three related FD (Fixed Deposit) features, built incrementally in one session: 1. IN-PLACE RENEWAL -- when an FD matures with "Re-Invest Principal and Interest", the SAME m_savings_account row is now reused across every renewal (account number never changes) instead of closing the account and opening a new one. FixedDepositAccount.renewInPlace() does this by setting start_interest_calculation_date as a pivot: interest for terms before the pivot is never recalculated, only the new term's window is computed from there. A new one-to-many audit table m_fd_renewal_history records one row per term (renewal_no 0,1,2...) with that term's own principal, rate, dates, interest earned, maturity, and status. A companion table m_fd_renewal_chart_slab_history archives each closing term's full rate-by-tenure chart, captured just before renewInPlace overwrites it. 2. SENIOR-CITIZEN RATE -- the CBS Base Interest Rate master (m_cbs_base_interest_rate_slab_history) was the only place that ever stored a senior-citizen premium. It is now also persisted on m_savings_account_interest_rate_slab (new senior_citizen_rate column, nullable, added only to this account-level table -- NOT to the shared InterestRateChartSlabFields embeddable, so the product-level table m_interest_rate_slab is untouched). Applied both at account creation (DepositAccountAssembler now prices a new FD off the active CBS base version when one exists for that FD type, falling back to the product's own chart otherwise) and at renewal (renewInPlace refreshes the chart from the same base version). 3. PAYMENT ACTION -- a new manual command, POST /fixeddepositaccounts/{id}?command=payment, available whether the FD is ACTIVE or MATURED, unlike Close (Matured-only) and Premature Close (Active-only, no reinvest). Offers: Transfer to Savings, Re-Invest Principal and Interest (via renewInPlace), Re-Invest Principal Only (legacy close-and-reopen, now also transfers the leftover interest to a chosen savings account instead of stranding it), and a new closure type PARTIAL_REINVEST (500) -- part of the matured balance renews in place on the same account, the remainder transfers to a savings account picked at request time. Withdraw Deposit is deliberately excluded from this command. New permission PAYMENT_FIXEDDEPOSITACCOUNT plus its CHECKER twin were added in migration 0478. KEY FILES ========= - DepositAccountDomainServiceJpa.java: handleFDAccountPayment (new), renewInPlace call sites, recordInPlaceRenewal, senior-citizen rate matching with unit conversion across days/weeks and months/years families. - FixedDepositAccount.java: renewInPlace, validateRenewalDate, isLockedOnDate, fdAccountNumber/renewalCycleNo chain tracking. - SavingsAccount.java (SHARED with Savings and RD): added findLastTransactionBefore -- the interest-posting opening balance for a pivot-dated account now seeds from the last transaction strictly before the pivot, not the one on it. This fixes a bug where a renewed term could accrue zero interest, or double-subtract a same-day withdrawal, depending on transaction list order. Also widened calculateDateAccountIsLockedUntil to protected so renewInPlace can refresh lock-in on each renewed term. - DepositAccountTransactionDataValidator.java: new validatePayment. validateClosing now explicitly rejects PARTIAL_REINVEST (500) so it can never reach the Close or Premature-Close handlers, which have no branch for it and would otherwise pay the whole balance out in cash. This applies to both FD and RD, since they share validateClosing. - DepositAccountReadPlatformServiceImpl.java: retrieveOneWithClosureTemplate (Close and Premature Close, excludes PARTIAL_REINVEST) split from the new retrieveOneWithPaymentTemplate (Payment, includes it), sharing one private method with a flag. The renewal-history fallback query, for chains that predate m_fd_renewal_history, was rewritten to emit the exact same column shape as the primary query. - New: FixedDepositRenewalHistory plus its repository, FixedDepositRenewalChartSlabHistory plus its repository, PaymentFixedDepositAccountCommandHandler. - Migrations 0471 through 0478 under tenant/parts, each registered once in changelog-tenant.xml. RD AND SAVINGS IMPACT -- READ THIS IF SOMETHING BREAKS THERE ============================================================ RD and plain Savings share several of the touched files. Verified during this work: - handleRDAccountClosure and RecurringDepositAccount.java were not modified. - PARTIAL_REINVEST (500) is now rejected by validateClosing for both FD and RD close and prematureClose commands, and excluded from their template option lists. This was a real regression caught mid-session: the enum value briefly leaked into RD's Close dropdown as a working looking option that actually paid the whole RD balance out in cash. It was found and fixed before this commit. - The SavingsAccount.calculateInterestUsing opening-balance change only affects accounts where start_interest_calculation_date differs from activatedon_date. On the dev DB this was exactly two accounts, both FD test accounts created this session. Before deploying, run: SELECT deposit_type_enum, COUNT(*) FROM m_savings_account WHERE start_interest_calculation_date IS NOT NULL AND start_interest_calculation_date <> activatedon_date GROUP BY deposit_type_enum; Any non-FD rows (100 or 300) there mean a Savings or RD account will get a different, corrected interest amount than before. This is expected to be rare or zero, but confirm before deploy. - DepositAccountAssembler's creation-time base-rate pricing is guarded by depositAccountType.isFixedDeposit, so RD account creation is unaffected. - is_active on InterestRateChart (migration 0474) is read only by FixedDepositProduct.activeChart, which only FD's renewInPlace and reInvest call. RD's applicableChart path is untouched. Migration 0474 also retires (is_active = false) any chart whose end_date is already past. On the dev DB this retired zero rows; check on the target DB before deploy, since there is currently no API to reactivate a retired chart. KNOWN CAVEATS -- NOT YET DONE, FLAGGING RATHER THAN HIDING ============================================================ - Migrations 0471 through 0477, the DDL ones, have never actually executed via Liquibase. They were mirrored by hand directly into the dev DB (ADD COLUMN IF NOT EXISTS, CREATE TABLE IF NOT EXISTS) so testing could proceed without a full rebuild each time. Liquibase will mark them MARK_RAN via preConditions on the dev DB's next real run, but their first genuine execution will be on whatever environment does not already have these columns and tables, such as a fresh QA or production database. Test a migration-from-scratch run before relying on this in production. - This code has not been compiled. Every new or changed method signature, import, and call site was manually cross-checked with grep against real declarations, but that is not a substitute for gradle actually compiling it. Run a full build before deploying and treat any compiler error as expected until confirmed clean. - DepositAccountAssembler pricing every new FD off the active CBS base rate master, instead of the product's own chart, whenever one exists is a real behaviour change affecting all new FD accounts of a type that has a base-rate version, not just senior-citizen ones. Flagging this for explicit product sign-off, not assuming it in this commit. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-23 16:44:11 +05:30
niteshandClaude Opus 5	20fe11e60d	fix(deposits): correct FD reinvestment on maturity and unblock product edit submission ... Reinvestment on maturity was creating the new deposit with a zero balance, because it sourced the amount from activateWithBalance() -- a guard that deliberately returns zero to stop a manually opened FD from auto-crediting itself. It now carries over what reInvest() actually put on the new account. Both legs of the renewal are also posted as an internal transfer, so the funds move through the transfer-suspense GL instead of appearing to leave and re-enter the cash vault. Reinvested accounts no longer fall back to a 0% rate when no chart slab covers the tenure, and a senior-citizen depositor keeps their premium rate on the renewed term. Adds a reinvestment trail: the new account records which account it came from, and the account view resolves both directions of the link so either side can be traced. Also fixes product edit submission, which failed outright for any product carrying payment-channel GL mappings: the pending-edit mapper read "glAccountId" while the payload carries "fundSourceAccountId" (and "incomeAccountId" for fee/penalty arrays), leaving gl_account_id null and tripping the satellite table's NOT NULL constraint. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-21 12:57:02 +05:30
niteshandClaude Sonnet 5	eb1aa767f7	fix(deposits): enforce savings-only maturity transfers and fix duplicate GL posting on FD/RD closure ... Adds validation so Transfer-to-Savings can only target a real savings account, with a proper user-facing message instead of the generic validation error. Fixes three duplicate journal-entry bugs uncovered while testing FD/RD maturity: the dormant-accounts job re-posting already-closed accounts (escheat/setSubStatusInactive/setSubStatusDormant), and the maturity-closure flow itself re-deriving accounting for a withdrawal that the account-transfer service had already posted. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-20 11:04:23 +05:30
nitesh	8724c54d9b	Merge branch 'dev' of https://git.lincpay.tech/CBSNexora/cbsnexora-backend into dev ... # Conflicts: # fineract-provider/src/main/java/org/apache/fineract/portfolio/mobilelookup/service/MobileLookupServiceImpl.java	2026-08-19 10:50:25 +05:30
nitesh	5c0a482f49	feat(kyc): resolve DIP/MNRL demo verdicts locally, make the check toggleable ... Every mobile-number lookup was calling out to a local mock HTTP service on port 8090 that had to be started separately, so the check failed with a connection error whenever that process wasn't running. Ports the mock's full verdict table (suspected, disconnected, suspected+disconnected, clean) into MobileLookupServiceImpl itself, so the demo/test numbers resolve in-process with no HTTP call. Adds fineract.mobile-lookup.enabled (default off) to skip the real DIP/MNRL call entirely for local work; every number then resolves CLEAN and is stamped LOOKUP_DISABLED_BY_CONFIG in the log so it's never mistaken for a genuine pass. Must be turned back on before UAT/production.	2026-08-19 10:35:48 +05:30
nitesh	0e07e60328	feat(current-accounts): add document upload/list/download/delete endpoints ... /v1/currentaccounts/{id}/documents had no handler at all -- the account's own /v1/currentaccounts resource matches the request path first and has no documents method, so it never fell through to the generic /v1/{entityType}/{entityId}/documents resource that every other entity type relies on. Current accounts got a 404 on every Documents-tab request. Delegates straight to the existing DocumentApiResource so current accounts get identical behaviour to clients, loans, etc.	2026-08-19 10:35:35 +05:30
nitesh	e227e8ae0f	fix(savings): post GL entries for facility-charge collections at edit approval ... Charges collected when a maker-checker Nominee/Digital-Feature edit is approved deducted the account balance and appeared in the passbook, but never posted a journal entry -- collectCharges() saved the charge transaction directly and skipped the accounting bridge entirely, so the GL never balanced against the subledger. Also fixes an unrelated NPE this exposed: collectCharges() used saveAll() instead of saveAllAndFlush(), so the new charge transaction had no id yet when the journal-entry code tried to read it.	2026-08-19 10:35:18 +05:30
nitesh	231919b62b	fix(savings): stop crediting accounts automatically on activation ... Activation for Savings, RD, FD and Current accounts no longer books an opening deposit or enforces a minimum opening balance -- accounts go active at zero balance and a clerk deposits funds afterward as a separate transaction, matching how these branches actually operate. Fixed Deposit and Recurring Deposit have their own override of activateWithBalance() that a prior fix to the shared SavingsAccount base class missed, so they kept auto-depositing after Savings was already fixed. Removing that auto-deposit exposed two follow-on bugs in the FD/RD activation flow, now also fixed: - the opening deposit's journal entries were posted twice (once by the deposit helper, once by the activation command's own posting call) - FD/RD maturity amount was computed from the account's real (now empty) transaction history at activation and never recalculated once a deposit actually landed, so it showed no projected interest until the account was reloaded from a lucky code path	2026-08-19 10:34:54 +05:30
niteshandClaude Sonnet 5	14b2585cf5	feat(loan-origination): add full backend persistence for the sanctioning pipeline ... Adds a lightweight loan-origination-pipeline module (application, stage history, approvals, FI checks and documents) with server-side validation per stage transition, so every field, upload and decision on the Loan Origination screen survives a page refresh instead of living only in the browser. Also fixes two content-store bugs found while wiring document uploads through the generic Fineract document store: the CSV mime/extension whitelist rejected bank-statement uploads outright, and the post-upload mime consistency check rejected any CSV whose byte-content sniffs as text/plain (which is all of them, since CSV has no distinguishing magic bytes). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-17 17:12:43 +05:30
niteshandClaude Sonnet 5	c8833367b9	feat(shares): route dividend cash claims through cashier token disbursement ... Cash claims now mirror the existing clerk-withdrawal token flow: clerk submits with a token, manager approval posts the GL entry, and a cashier redeems the token at Transaction Entry to record physical hand-over -- no direct manager-to-member cash handover, and no double-disbursement. Also fixes GL accounting for the loan/savings legs: instead of reversing the native command's own debit with a second manual entry pair (leaving the fund-source account confusingly appearing twice), that debit leg is now rewritten in place to Dividend Payable. Floors cash claims to whole rupees since notes/coins can't represent paise, with backward-compatible tolerance for claims submitted before the fix. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-12 10:17:35 +05:30
nitesh	94b0afff38	Merge branch 'dev' of https://git.lincpay.tech/CBSNexora/cbsnexora-backend into dev ... # Conflicts: # fineract-provider/src/main/resources/db/changelog/tenant/changelog-tenant.xml	2026-08-11 12:53:20 +05:30
niteshandClaude Sonnet 5	9dd4f8bedb	feat(shares): real-profit driven dividends with GL-only liability model and member claim workflow ... Reworks the share dividend lifecycle end to end: - Dividend amount now auto-computed from real GL profit x officer-entered percentage instead of manual entry; adds a Dividend Paid report over the existing Dividend Payable ledger. - Declaration posts a real GL entry (Dr Reserve for Dividend / Cr Dividend Payable); approval no longer credits any savings account up front -- every member's entitlement stays a pure "Dividend Payable" liability until claimed, resolved synchronously at approval time (no background job or per-member failure mode). - New maker-checker Dividend Claim Request workflow: a clerk records how a member wants their unclaimed dividend split (overdue loan / savings credit / cash), a manager approves, which executes native repayment/deposit commands and replenishes whichever GL account they actually debited (not a hardcoded assumption) from the Dividend Payable liability. - Unclaimed dividends carry a 3-year window (m_share_dividend_lock) after which a daily job forfeits them straight to profit; a Dividend Dashboard consolidates summary stats, every declaration's status, full lock history, and proactive loan-application for members with overdue EMIs. - Fixes a native negative-share-days bug in ShareProductDividendAssembler and adds overlap-period validation so a product can't have two declarations covering the same days. - Removes the now-unreachable failed/pending-payout tracking that the old per-member job-based model needed. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-11 12:42:45 +05:30
niteshandClaude Sonnet 5	2213308254	fix(shares): skip zero-value redeem transaction on account close ... Closing a share account that already has zero approved shares no longer synthesizes a redeem transaction, so it stops posting a meaningless ₹0.00/₹0.00 GL journal-entry pair. Save/note-capture on close now happen unconditionally instead of being gated on a transaction existing. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-06 20:10:57 +05:30
nitesh	c568eb0abf	feat(shares): close share account directly on withdrawal approval ... Replaces the auto-submit-closure-request behavior with an immediate account close, in the same @Transactional approval action, when a redemption brings a share account's holding to zero — no separate "Share Closure Request" maker-checker step is needed since the redemption amount itself already went through this same review. Removes ClerkShareClosureRequestApiResource entirely (the migration for m_clerk_share_closure_request is left in place as a harmless, now-unused table, to avoid a Liquibase checksum churn). Also fixes a genuine Postgres-incompatibility bug this uncovered in validateNoActiveLoanOrGuaranteeBeforeClosure(): `is_active = 1` doesn't type-check against a boolean column on Postgres ("operator does not exist: boolean = integer"), which was silently aborting the whole approval transaction (harmlessly, since it's @Transactional — verified no partial state was ever left behind). Fixed to `is_active = true`, added the missing `type_enum = 1` (customer-type guarantors only, matching the existing Guarantor Check elsewhere in this workflow), and widened both this and the active-loan check to the same loan_status_id set (300, 303, 304, 700) used there too.	2026-08-06 19:29:44 +05:30
nitesh	1426be9531	fix: correct changeset ids after renumbering merged AML/family-member migrations ... Follow-up to the previous merge commit — the internal Liquibase changeSet ids in the 9 renumbered files (0447-0455) still referenced their old 0438-0446 numbers; the rename staged the files before the id update was applied. Ids now match filenames as intended.	2026-08-06 16:50:39 +05:30
nitesh	541c6ab062	Merge branch 'demo' of https://git.lincpay.tech/CBSNexora/cbsnexora-backend into dev ... Resolved two conflicts: - changelog-tenant.xml: both branches independently added Liquibase parts numbered 0438-0446 (dev: Share Withdrawal/Closure governance + KYC exception fields; demo: AML rule tiers/branch seeding/email tracking/family-member children table). Renumbered demo's incoming set to 0447-0455 (files renamed + internal changeSet ids updated to match) so both feature sets keep their own migrations intact. - 0434_seed_aml_transaction_rules.xml: same seed data on both sides, differing only in the disambiguating SQL predicate. Kept dev's `AND aml_check_status IS NOT NULL` (deterministically targets the intended m_client_risk_rule row, per the file's own comment) over demo's `LIMIT 1` (arbitrary, could pick the wrong row). Also dropped two JVM crash-dump log files that got staged by mistake.	2026-08-06 16:49:15 +05:30
niteshandClaude Sonnet 5	66a6a4766f	feat(shares): add Share Account Closure maker-checker workflow ... New ClerkShareClosureRequestApiResource mirrors the withdrawal resource: clerk submits a closure request only once a share account holds zero shares; a /validate endpoint re-checks shares-held, account status, any active loan/guarantee, and client KYC/AML compliance; approve() executes the real native "close" command. ClerkShareWithdrawalRequestApiResource.approve() now also auto-submits a PENDING closure request (via the same table) whenever a redemption brings the account's share holding to zero, reusing the withdrawal's own maker identity — a manager still has to separately Validate and Approve it, so the closure request is created automatically but never executed without review. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-06 11:44:47 +05:30
nitesh	1a9adaec24	Merge branch 'dev' of https://git.lincpay.tech/CBSNexora/cbsnexora-backend into dev	2026-08-05 18:34:33 +05:30
niteshandClaude Sonnet 5	2da5a25e04	feat(shares): add compliance and loan/guarantor/tenure checks to validation ... The /validate endpoint now re-checks live state that matters for a real UCB share redemption: Client KYC verified, Risk Category not High, no open AML alerts, and — since this bank supports loan-against-shares via m_share_account.linked_loan_id — a Loan Check (no active loan secured by these shares), Tenure Check (linked loan's term completed), and Guarantor Check (client not guaranteeing someone else's active loan). Dropped the redundant "status is PENDING" check and replaced raw status_enum codes with human-readable labels throughout. getById() also now returns a client compliance summary so the review screen can show it without running the popup validation. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-05 18:33:12 +05:30
niteshandClaude Sonnet 5	f1d68d17fe	feat(shares): add Share Withdrawal maker-checker workflow with GL settlement ... New ClerkShareWithdrawalRequestApiResource backs a clerk-submits/manager- approves flow for share redemption: on submit, validates and persists the clerk-chosen settlement Payment Type (must be non-cash) plus a full audit snapshot of the settlement row; on approve, executes the real "redeemshares" command and, in the same transaction, credits the redemption value to the share account's linked savings account using that stored payment type (with a hardcoded-lookup fallback for pre-existing rows). Adds a /validate endpoint that re-checks live account/GL state (not just the submit-time snapshot) so a manager can verify before approving. Also exposes linked-savings-account data on ShareAccount reads so the frontend can display/validate it. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-05 16:56:50 +05:30
niteshandClaude Sonnet 5	7cdc25322e	fix(aml): resolve ambiguous order_position subquery breaking tenant migration/startup ... 0434_seed_aml_transaction_rules.xml resolved source_client_risk_rule_id via `SELECT id FROM m_client_risk_rule WHERE order_position = N`, assuming order_position was unique. It isn't: 0430_seed_aml_compliance_rules.xml seeds its own 221 rows with order_position 1-235, independently of the older 0428_add_client_risk_rules.xml rows, and several values collide (e.g. both insert a row at order_position 10 and 30). Every affected subquery returned more than one row, aborting the whole tenant's Liquibase run and app startup. aml_check_status is populated only on 0430's rows (0428's predate that column and are NULL there), so pairing it with order_position uniquely targets the intended row without touching either seed changeset. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-31 14:27:08 +05:30
nitesh	a4c3dbb6c4	Merge remote-tracking branch 'origin/dev' into uate	2026-07-31 13:58:55 +05:30
niteshandClaude Sonnet 5	dd8445de06	fix(accounting): resolve Sponsor DD Payable SBI GL account parent by gl_code, update default tenant DB password ... The 0345 changelog hardcoded the "OTHER LIABILITY" parent row's numeric id (22), which only matched the default tenant's auto-increment history and broke the FK insert (and the whole Liquibase run / app startup) on tenants seeded differently, e.g. saga. Now resolves parent_id via a SELECT on gl_code='9' and marks the changeSet runOnChange so it safely re-validates on tenants that already ran the old version. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-31 13:56:04 +05:30
nitesh	9345f2294c	Merge remote-tracking branch 'origin/uate' into uate	2026-07-31 13:54:07 +05:30
niteshandClaude Sonnet 5	190cd92a85	fix(accounting): resolve Sponsor DD Payable SBI GL account parent by gl_code, update default tenant DB password ... The 0345 changelog hardcoded the "OTHER LIABILITY" parent row's numeric id (22), which only matched the default tenant's auto-increment history and broke the FK insert (and the whole Liquibase run / app startup) on tenants seeded differently, e.g. saga. Now resolves parent_id via a SELECT on gl_code='9' and marks the changeSet runOnChange so it safely re-validates on tenants that already ran the old version. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-31 13:53:27 +05:30
nitesh	b1cfa996b4	feat(clients): fromDate/toDate submittedon_date range filter on GET /clients ... Backs the Client Approval tab's Today/Yesterday quick filters server-side. offset/limit/displayName/orderBy/sortOrder/status already existed on this endpoint; added fromDate/toDate (yyyy-MM-dd, inclusive) alongside them, filtering on c.submittedon_date, following the same ::date-cast convention already used by ClientPendingEditReadPlatformServiceImpl for the equivalent pending-edits filter. Updated the one other caller (SelfClientsApiResource) to pass null/null.	2026-07-30 10:33:48 +05:30
nitesh	02541eed6c	feat(sanctions): expose the loaded list's data-currency date on every screening result ... Screening only ever told a caller whether a name matched and when the check ran — not which dated snapshot of the UN Security Council list it ran against. Added SanctionsEntryRepository.findListLastLoadedOn() (MAX(createdDate) over active entries) and threaded it through SanctionsScreeningResult as listDataAsOf, so the frontend can show "List Data As Of: <date>" alongside "Screened On".	2026-07-30 10:33:33 +05:30
niteshandClaude Sonnet 5	7c15fbb0c7	fix(documentmanagement): close leaked file handles causing Windows re-upload failures; add entity KYC document CodeValues ... FileContentStoreService.upload() opened a FileOutputStream (write) and an InputStream (post-upload MIME check) without closing either. Windows keeps those handles open for the JVM's lifetime, so the next upsert-style delete-then-recreate of the same file (e.g. client signature/photo re-upload) failed with FileSystemException: "being used by another process". Wrapped both in try-with-resources. Also adds every distinct non-individual/constitution KYC document name (HUF, Private/Public Ltd, LLP, Partnership, Trust, Society, Proprietorship, Association, Govt/PSU, Cooperative) as a KYCIdProofType code value. resolveDocumentTypeId() on the frontend matches the picked document name against this list before creating a client_identifier; since these entity document names had no corresponding code value, every non-individual client's KYC document upload silently failed to persist. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-29 11:34:18 +05:30
nitesh	6e3f195de0	Merge remote-tracking branch 'origin/uate' into uate	2026-07-29 10:31:58 +05:30
niteshandClaude Sonnet 5	a65d801250	feat(clients): maker-checker for client creation and edits (backend) ... - Client activation now requires a different user than the one who created the client (client.getCreatedBy() vs current user) — no bypass, including CHECKER_SUPER_USER, since a bypass would recreate the exact "role bypasses the hold" loophole this closes. Client creation itself is unaffected (the wizard needs a real client id immediately for photo/KYC/address/family follow-up uploads), only activation is gated. - New maker-checker queue for Client edits, modelled on this codebase's existing m_share_account_pending_edit / chequebook patterns rather than Fineract's native command-approval engine (which any ALL_FUNCTIONS role bypasses unconditionally): - m_client_pending_edit (migrations 0429-0431): stores the maker's raw edit payload plus a point-in-time "before" snapshot (original_json, extracted from the frontend's _originalValues key) so the checker's diff stays accurate even after the edit is approved/rejected, when the live client no longer reflects the pre-edit state. - ClientEditWritePlatformService: submitEditForApproval() stages the edit (refusing a second submission while one's already pending, via a nullable-but-unique pending_lock_key); approveEdit() replays the payload through the existing updateClient() so all of Client's validation/change-detection runs unchanged, just deferred; rejectEdit() discards it. The maker can never approve/reject their own submission. - ClientEditApiResource: /clients/{id}/edit (submit), /clients/edit/pending (paginated + status/clientName/date-range filterable list, mirrors /chequebook/pending-requests), /clients/{id}/edit/approve, /clients/{id}/edit/reject. New permissions (migration 0430): SUBMITEDIT_CLIENT, APPROVEEDIT_CLIENT, REJECTEDIT_CLIENT, APPROVEEDIT_CLIENT_CHECKER (the last one surfaces pending edits in the generic Checker Inbox too). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-29 10:31:10 +05:30
niteshandClaude Sonnet 5	3c58bb231f	fix(clients): pwdCategoryOptions on edit template, minor-age threshold to 18, minor KYC identity-proof bypass ... - ClientData.templateOnTop()/templateWithSavingAccountOptions() never copied pwdCategoryOptions from the template — the Disability Type dropdown was always empty on the edit-mode GET /clients/{id}?template=true call, even though create-time template() had it. - Raise the minor-detection threshold in ClientKycApiResource from age <10 to <18 (legal definition), mirroring the frontend's own rule so the required-documents list served here stays consistent. - ClientKycCommand.validateForInitiate() unconditionally required at least one of PAN/Aadhaar/GSTIN, with no awareness of the Birth Certificate/School ID document-type picker minors actually use — blocking "Save & Next" on the KYC tab for every minor client. Added a skipIdentityDocumentCheck flag, set from client.getIsMinor() at both call sites (initiateKyc/initiateKycInline). - Added Birth Certificate and School ID Card as KYCIdProofType code values — they were already offered as document-type options for minors but never existed in the code-value list that saveKycDocProof() resolves against, so selecting either silently failed to save any identifier/document. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-28 15:51:08 +05:30
niteshandClaude Sonnet 5	aabda18b69	feat(clients): enforce Mother + Father/Caretaker family members on client activation ... - Add CARETAKER as a new RELATIONSHIP code value (previously missing — a client with no father had no valid way to satisfy the rule below). - Add ClientFamilyMembersWritePlatformService.validateFamilyRequirementsForActivation(), called from activateClient(): requires an active "Mother" family member, plus either "Father" or "Caretaker", for individual clients (non-individual entities are exempt). - Two distinct exceptions (ClientFamilyMemberMotherRequiredException / ClientFamilyMemberFatherOrCaretakerRequiredException) so the two failure reasons surface as separate errors instead of one merged message, mirroring the frontend's separate banners. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-28 12:37:24 +05:30
nitesh	0e5671b706	Merge remote-tracking branch 'origin/uate' into uate	2026-07-28 10:55:05 +05:30
niteshandClaude Sonnet 5	67214ec0f8	fix(clients): stale signature bug, CKYC fixes, monthly turnover/annual income, senior citizen/PWD classification ... - Add m_client.signature_id (single-slot pointer, mirrors image_id) plus ClientSignatureIdAdapter/EntitySignatureIdAdapter so re-uploading a signature updates the existing m_document row in place instead of leaving duplicate rows behind that readers picked inconsistently. - Fix CkycBatchBuilderServiceImpl address-proof classification to read the client identifier's actual m_code (KYCAddressProofType vs KYCIdProofType) instead of a hardcoded string set that disagreed with the CKYC tab and silently dropped Aadhaar-as-address-proof identifiers. - Organize the CKYC ZIP into per-artefact-type folders (PHOTO/SIGNATURE/ID_PROOF/ADDRESS_PROOF). - Fix CkycBatchBuilderServiceImpl.createBatch() using the daily batch sequence number as the ZIP document's parent_entity_id instead of the real m_ckyc_batch.id, which 404'd on download whenever the two diverged (i.e. almost always). - Add monthlyTurnover and annualIncome fields alongside the existing annualTurnover/monthlyIncome. - Add isSeniorCitizen, isPwd, and pwdCategory (proper m_code_value-backed PwdCategory code, not a free-text column) to m_client, following the same pattern as occupation/religion/marital status. - Add Diploma as its own Education Level (with diploma-specific DegreeQualification values) and Graduate as a level distinct from Undergraduate. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-28 10:50:16 +05:30
nitesh	bc30241950	Merge remote-tracking branch 'origin/uate' into dev	2026-07-27 14:24:16 +05:30
niteshandClaude Sonnet 5	14df914b9a	feat(clients): dual-OTP verified contact changes with customer notification ... Mobile number and email address changes now require OTP verification on both the old and new destination (staff-entered) before the update is accepted, at both client creation and edit time — closing a gap where an unverified wrong number/email could never be corrected later. Every mobile/email/address change also emails the customer at their pre-change address so an unauthorized change is never silent. - New ClientContactOtpService (+Impl) mirrors the existing login OTP services, reusing OtpLog with a CLIENT_CONTACT_CHANGE purpose. - New sibling API resources for edit (/clients/{id}/contact-verification/otp) and create (/clients/contact-verification/otp, no clientId yet). - ClientWritePlatformServiceJpaRepositoryImpl / AddressWritePlatformServiceImpl gate the actual field change on verified OTPs and fire ClientChangeNotificationService afterwards; the notification recipient is always snapshotted before any mutation so a same-request mobile+email change can't accidentally alert the new (unverified-by-its-real-owner) address instead of the old one. - ClientDataValidator validates OTP id format only (ignoreIfNull) — enforcement lives solely in the write-service's diff-gated calls, since edit-client always PUTs the full client object regardless of what changed. - 0420 migration seeds 8 CLIENTKYC action permissions (GenerateAadhaarOtp/VerifyAadhaar/VerifyPan/VerifyCin/VerifyDin/ VerifyGstin/UploadCkyc/CompleteRekyc) that were referenced by existing command handlers but never seeded, causing a 404 for every user including Super User. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-26 14:36:48 +05:30
niteshandClaude Sonnet 5	5dc175c5e1	feat(users): auto-enroll admin-chosen OTP channel as MFA factor at creation ... Admin now picks a mandatory OTP delivery method (Email/Mobile) when creating a user. The channel is enrolled immediately as a verified m_user_mfa_factor row, so the existing 2FA system (MfaFactorBackedTwoFactorServiceImpl + /twofactor) challenges the user for OTP on their very first login - reusing the already-built login-OTP infrastructure instead of a parallel flow. Also adds a versioned, admin-manageable user-agreement (disclaimer) API (/v1/useragreements) with per-user acceptance tracking, checked right after every login, plus a Liquibase cleanup migration and a shared OTP-destination masking utility extracted from the two existing login-OTP services. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-24 16:16:40 +05:30
nitesh	cf60515bf6	Merge remote-tracking branch 'nexora/uate' into merge-uate-into-dev ... # Conflicts: # .gitignore # fineract-provider/src/main/resources/db/changelog/tenant/changelog-tenant.xml # fineract-savings/src/main/java/org/apache/fineract/portfolio/savings/service/FacilityChargeAutoApplyService.java	2026-07-23 17:36:10 +05:30
niteshandClaude Sonnet 5	a098f8ba75	fix(chequebook): prevent cheque-leaf serial collisions across series at issuance time ... The real root cause behind the leaf-serial collision bug: stock-lot overlap checking was scoped to "within the same series only" (ChequeStockLotRepository.countOverlappingInSeries), on the incorrect assumption that two different cheque designs never share a numeric range. A real bank allocates leaf serials from one bank-wide numbering authority, so this is exactly what let two series end up with overlapping ranges that, once both were issued to the same account, produced an unresolvable serial collision (NpciInwardPushService's drawer-account-number disambiguation can't help when every colliding leaf belongs to the same account). Widened the check to countOverlappingAnySeries — both the maker-submit and checker-approval paths in ChequeBookWritePlatformServiceImpl now reject a stock receipt whose range overlaps ANY existing lot, regardless of series. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-23 17:24:17 +05:30