9722 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
nitesh	3a37a5f90f	Merge branch 'feature/bugfix' into dev-latest ... Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> # Conflicts: # fineract-provider/src/main/resources/db/changelog/tenant/final-changelog-tenant.xml	2026-09-28 18:36:12 +05:30
niteshandClaude Sonnet 5	e7417d16a6	chore: renumber migration 0585 to 0587 ahead of feature/bugfix merge ... feature/bugfix independently used 0585/0586 for unrelated migrations (loan COB catch-up, system module checker permissions), colliding with this session's own 0585 file. Renumbered to the first free slot after theirs so both sets of changesets coexist without ambiguity; content and semantics are unchanged, only the file name and changeset ids moved. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-28 18:35:11 +05:30
niteshandClaude Sonnet 5	24d3bf83bb	fix: correct Current-product OD columns, PortfolioProductType mapping, and duplicate Bank Transfer voucher ... - Add migration 0585 to add the OD-scheme columns to the correctly-named pending-edit shadow table (m_saving_product_temp, singular), fixing migration 2033's typo that made it a permanent no-op and broke editing any Current product with OD fields set. - Fix PortfolioProductType.fromInt() to switch on each constant's declared value instead of declaration position, which silently mis-mapped ids 3-5 and NPE'd on id 6 (CURRENT), crashing Journal Entries for Current-account GL rows. - Stop generating a second Bank Transfer voucher at approve time; reuse the one already created at raise/submit time instead, eliminating duplicate vouchers for the same transfer under two different users' names. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-28 17:53:25 +05:30
anshul	af052dcb4f	Merge branch 'dev-latest' into feature/bugfix	2026-09-28 17:22:25 +05:30
keshav	b12268e740	feat: add RBI Form A and Form 9 SLR filing APIs, jobs, and migrations	2026-09-28 13:35:32 +05:30
anshul	6ee3bbe67c	feat: add command handlers, permissions, and API resources for surveys and loan COB catch-up	2026-09-28 12:55:21 +05:30
anshul	d8f6c25875	Merge branch 'dev-latest' into feature/bugfix ... especially if it merges an updated upstream into a topic branch.	2026-09-28 12:39:03 +05:30
niteshandClaude Sonnet 5	2155c94161	fix(fd): Reinvest Principal Only renews in place, same account, instead of opening a new one ... Reinvest Principal Only was still on the legacy close-and-reopen path (open a new FD with just the principal, close the old one) while Reinvest Principal + Interest and Partial Reinvest had already moved to renewInPlace -- the same customer choosing a different split ended up with two different outcomes: same account number, or a brand new one. Unified all three onto renewInPlace: Principal Only is now exactly Partial Reinvest with the split fixed at the closing principal, so it renews on the same account with only the leftover interest actually leaving (to the chosen/linked Savings account), in both handleFDAccountPayment (Payment dialog / FD Dashboard Renew) and handleFDAccountMaturityClosure (the nightly job's path for an account with an already-stored instruction). Also fixes a related bug found while testing this: recordInPlaceRenewal re-archived the closing term's full rate chart on every renewal of the same term, even when it had already been archived by an earlier renewal -- archiveChartSlabs now only runs the first time a term's closing row is created. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-28 11:41:18 +05:30
niteshandClaude Sonnet 5	87f3e591ce	fix(accounting): tag current-account GL entries entity_type_enum=CURRENT instead of reusing SAVING, everywhere this codebase links an entry to its account ... 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. Every place that links a GL journal entry back to its account for display -- so the Journal Entries screen shows an Account No instead of a blank "-" -- was tagging entity_type_enum=2 (PortfolioProductType.SAVING) unconditionally, even when the account was actually a current account. Whenever a current account's id collided with an unrelated savings account's id, the entry resolved to the wrong one entirely: a customer's savings deposit could display someone else's current account number, or vice versa. Fixed at the write side, in every place found doing this: - ClerkDisbursementRequestApiResource (Bank Transfer, Collection, Disbursement) -- GlEntry now carries an isCurrentAccount flag, decided once where the account was already resolved, instead of being re-guessed. - ChequeBookIssuanceChargeService, ClearingJournalService, SponsorDDIssueRequestWritePlatformServiceImpl -- same pattern, each already knew savings vs current at the point it linked the entry; that answer is now threaded through instead of discarded. Also fixed on the read side: - JournalEntryReadPlatformServiceImpl: entity_type_enum=6 now resolves unambiguously to the current account; entity_type_enum=2 still falls back to savings_transaction_id (a reliable signal only a genuine savings transaction sets) before guessing, for older rows written before this fix. - JournalEntryReferralServiceImpl (AML referral resolution): the same ambiguity could attribute a suspicious-activity alert to the wrong client entirely -- a same-numbered stranger's account -- when a current account's entity_id collided with a savings account's. Resolved with the same entity_type=6 / savings_transaction_id precedence as the read-side fix. Not touched: JournalEntryAggregationJobReader (year-end aggregation batch job) has the same ambiguity for legacy entity_type_enum=2 rows, but only ever joins m_savings_account -- it has no current-account handling at all, standard-Fineract in origin. Extending it is a real feature addition, not a targeted fix, and touches a scheduled financial batch job this session cannot rebuild or run to verify; flagged for separate, deliberate work instead. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-28 10:34:39 +05:30
niteshandClaude Sonnet 5	1e903232f0	fix(fd): pay late-renewal gap interest to the linked Savings account, not the FD ... Gap-period interest is earned at the linked account's rate, not the FD's -- folding it onto the FD's own balance meant "Re-Invest Maturity Amount" silently carried savings interest into the new FD term as if it were FD interest, and "Re-Invest Principal Only" paid it out through the FD's own closure math instead of it already being where it belongs. Now posted directly onto the linked account as its own INTEREST_POSTING transaction; the FD's balance is left untouched, so every closure type renews/transfers its real maturity amount. Renewal Preview updated to match (projectedBalance is now just the FD's own balance) and now also returns the linked account's own account number, so staff can see exactly where the gap interest is about to land before confirming. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-25 14:11:50 +05:30
niteshandClaude Sonnet 5	2c49d6f637	feat(fd): add read-only renewal preview endpoint, fix stale linked-account reads ... GET /fixeddepositaccounts/{id}/renewal-preview -- shown in the FD Dashboard's Payment dialog before staff confirm a late renewal, so they see the actual numbers (linked account's rate, gap days, gap-interest amount, projected new balance) instead of confirming blind. Shares its calculation with the posting path (creditGapInterest) via a new computeGapInterestAmount helper, so the previewed number is exactly what gets credited. Also fixes fdAccount.getLinkedAccountId() returning null for an account confirmed to have linked_account_id set in the database -- every caller that needs the FD's Deposit Account Link now reads it fresh via SQL (resolveLinkedAccountId) instead of that stale JPA entity accessor. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-25 12:40:55 +05:30
niteshandClaude Sonnet 5	331c553164	fix(accounting): interest postings were never reaching the general ledger ... createInterestPostingJournalEntriesForSavings() documents a 3-stage posting (Dr Interest On Savings -> Cr Payable, Dr Payable -> Cr Paid, Dr Paid -> Cr Savings Control), but the first stage was never actually coded -- the interest expense account was never even fetched. For a product with no distinct Interest Payable/Paid accounts configured (every product in this system, checked directly), the remaining two stages then collapsed into a same-account no-op that correctly refuses to post, leaving interest silently added to the account's balance with zero GL entries. Affects every deposit type equally (Savings, FD, RD), not just FD -- confirmed by checking every product's accounting mappings. Added the missing stage. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-25 12:40:46 +05:30
niteshandClaude Sonnet 5	3fb008a22a	fix(products): clearer error message for an FD product amount field that's too large ... The FD product's exception mapper fell back to a bare "Unknown data integrity issue with savings product." for any DB error it didn't recognize, with no detail -- unlike its sibling class for regular Savings products, which at least appends the underlying error. Added a specific, actionable message for the numeric-overflow case (an amount field entered too large for its column), and made the generic fallback include the real detail too. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-25 12:40:28 +05:30
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
anshul	cebba87864	Merge branch 'dev-latest' into feature/bugfix	2026-09-25 11:24:24 +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
anshul	7eabaf2542	Merge branch 'dev-latest' into feature/bugfix	2026-09-24 18:09:48 +05:30
keshav	4b9093007f	feat: update TDS config, RBI reserve, current products, OSS returns, and dormancy services	2026-09-24 18:06:29 +05:30
anshul	9beae3df28	Implement organization maker-checker workflows	2026-09-24 17:22:39 +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
keshav	fde2699957	feat: sponsor bank DD payable GL, AML stale review release, and dividend updates	2026-09-21 10:23:52 +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
keshav	934c11bf87	Merge branch 'dev-latest' of https://git.lincpay.tech/CBSNexora/cbsnexora-backend into dev-latest	2026-09-18 10:29:24 +05:30
keshav	c1e6e036d0	feat(aml): enforce review locking and sync STR case conclusions to linked alerts	2026-09-18 10:29:17 +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
keshav	521d61d6b7	feat: AML alert rule disposition, Client Behaviour Window evaluation, Risk Policy parameters & Board Resolution register	2026-09-16 12:50:43 +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
keshav	39fa100c70	Merge branch 'dev' of https://git.lincpay.tech/CBSNexora/cbsnexora-backend into dev ... # Conflicts: # fineract-provider/src/main/resources/db/changelog/tenant/final-changelog-tenant.xml	2026-09-14 11:46:43 +05:30
keshav	1c6ac9d77f	feat: AML direction/entity scoping, Sponsor DD revoke workflow, Dividend GL resolution & TDS module	2026-09-14 11:46:16 +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
keshav	3d196276c8	feat(savings): support rounding adjustment GL mapping and floor rounding on clerk closure	2026-09-11 10:48:50 +05:30
keshav	5cc5d680f2	feat: separate kyc/aml risk rules, dormancy clock, and savings daily interest fixes	2026-09-10 18:27:50 +05:30