113 Commits

Include renames

Author	SHA1	Message	Date
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
keshavandClaude Opus 5	e4cc2e558e	cash-only registers, day book sections and DD amendments ... Cashier reports now reconcile against the drawer: - Received/Payment exclude what cannot be cash rather than admitting only proven cash, so registers that pay out without recording a denomination breakdown are no longer silently dropped - Closing report scoped to the cashier, with opening/closing balance, reversed counter transactions excluded, and cash DD receipts counted - Day book split into Cashier and Clerk sections, filed by whose cash moved rather than who raised the request Fixed one deposit or withdrawal raising two vouchers: the cashier deposit and clerk withdrawal registers did not suppress the inner savings command's voucher, doubling the day's cash on both reports. Sponsor DD: - Amendment request flow (beneficiary, payable-at branch and city) under maker-checker; face value and funding stay unamendable - Cash DD denominations were collected but never saved, and the amount check demanded a figure notes could not add to; both fixed and the breakdown is now required Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-03 18:45:36 +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
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	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	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	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	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
Anshul Rathore	a2fa8688ae	Update client KYC and AML changes	2026-08-14 12:54:43 +05:30
keshav	1107610c08	add KYC document renewal alerts, Aadhaar/PAN exceptions, and AML recurring alerts UI; remove old journal AML marking	2026-08-11 11:34:54 +05:30
keshav	026d902199	minor change on client	2026-07-28 10:43:06 +05:30
keshav	f18b5d97d3	share certificate and share product maker checker	2026-07-27 14:14:05 +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
Jaanu423andClaude Sonnet 5	383dfdc6e9	feat(chequebook): silent balance hold instead of activation-time charge ... - Removed the "CHEQUE_BOOK" facility charge from account-activation auto-apply (both savings and current) — the per-leaf issuance charge is now the only cheque-book charge, applied at request/approval time only. - Cheque book request now reserves the charge amount via a direct on-hold-funds field update instead of Fineract's native hold-amount command, so no "Amount on hold"/"Release Amount" transaction row is ever created — nothing shows in the passbook/transactions list, and the reservation is released the same way (silently) on approval (then charged) or rejection (returned), for both savings and current accounts. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-17 15:03:30 +05:30
keshav898966	b064ee6307	existing account saving and current add or remove nominee and digital & account features and also FE & RD nominee add or remove	2026-07-10 18:40:16 +05:30
keshav898966	9980310c9e	table changes on Maker-Checker workflow for Products, with approval-based updates and product locking to prevent concurrent edits	2026-07-06 17:49:39 +05:30
keshav898966	b0bfa386ce	implemented a Maker-Checker workflow for Products, with approval-based updates and product locking to prevent concurrent edits	2026-07-03 15:15:09 +05:30
keshav898966	99c153830c	pending account terminate feature develop	2026-07-01 17:25:04 +05:30
keshav898966	1bd41cff43	saving, currun, fd and rd account working and tested	2026-06-30 10:06:59 +05:30
keshav898966	db41c2b606	feat: add share linking enabled to current and savings accounts	2026-06-26 11:12:00 +05:30
Jaanu423andClaude Sonnet 4.6	6e31ac9acd	fix(savings): allow modifyApplication for rejected Savings/FD/RD accounts ... SavingsAccount.modifyApplication() previously blocked modification unless the account was in SUBMITTED_AND_PENDING_APPROVAL state. Extended to also allow REJECTED state so bank users can amend and re-submit rejected applications. When a rejected account is modified, status resets to SUBMITTED_AND_PENDING_APPROVAL (rejectedOnDate and rejectedBy cleared) so the account re-enters the approval workflow. Applies to Savings, FD, and RD accounts (all extend SavingsAccount). Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>	2026-06-03 14:55:39 +05:30
Jaanu423andClaude Sonnet 4.6	a051faba5d	feat(accounts): backend fixes for Modify Application feature (Current/Savings/FD/RD) ... Current Account: - CurrentAccountReadPlatformServiceImpl: add retrieveJointHolders() and retrievePartners() - CurrentAccountWritePlatformServiceImpl: full modifyApplication() - updates all CBS fields, joint holders, partners, nominees, facility config, dates, introducer - Fix cbsAccountType save: parse string account type from 'accountType' JSON field Nominees: - ClientNomineeWritePlatformService: add replaceNomineesForAccount() for atomic replace - Savings/FD/RD modifyApplication: replace nominees on modify FD/RD Read (DepositAccountReadPlatformServiceImpl): - Add isSeniorCitizen, seniorCitizenInterestRate to BASE SQL SELECT - Add setCbsAccountFields() call in FD/RD mappers reading accountStatus, modeOfOperation, introducerClientId, guardianFields, linkedAccountId, isSeniorCitizen from ResultSet - Fix retrieveOne() to also fetch joint holders from m_savings_account_joint_holders - Use explicit LinkedHashMap in joint holder query (camelCase keys for Angular) FD/RD Data Classes: - FixedDepositAccountData: add accountStatus, modeOfOperation, introducerClientId, linkedAccountId, jointHolders, isSeniorCitizen, seniorCitizenInterestRate fields - RecurringDepositAccountData: same fields added - Fix all factory methods (withInterestChartAndRecurringDetails, withClosureTemplateDetails, withTemplateOptions, associationsAndTemplate) to call copyCbsFieldsFrom() - Fix SavingsAccountReadPlatformServiceImpl joint holders: use camelCase keys FD Calculator: - FixedDepositAccountInterestCalculationServiceImpl: add calculateExact() with actual calendar-based calculation matching PostingPeriod engine (exact same as account creation) - Add submittedOnDate, daysInYear, interestPostingPeriodInMonths optional params - Support interestCompoundingPeriodInMonths=0 (daily compounding) in both validator and calc - DepositsApiConstants: add submittedOnDate/dateFormat/locale/daysInYear to allowed params - DepositAccountDataValidator: allow 0 (daily) in interestCompoundingPeriodInMonths Misc: - SavingsProductData: null-check in isCashBased/isAccrualBased methods (NPE fix) Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>	2026-06-03 10:32:59 +05:30
Jaanu423andClaude Opus 4.7	ee915e395a	feat: Denomination Master backend - master, audit, soft delete, txn breakdown ... - m_denomination_master CRUD API with duplicate (denomination+kind) validation, soft delete + restore, and a full audit trail (m_denomination_master_audit logs CREATE/UPDATE/ACTIVATE/DEACTIVATE/ DELETE/RESTORE with snapshot, changes, user and timestamp) - m_savings_txn_denomination: persist per-transaction cash denomination breakdown on savings deposit; allow denominationBreakdown request param - Liquibase 0012_denomination_master registered in tenant changelog Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-27 11:16:52 +05:30
Jaanu423andClaude Sonnet 4.6	7d4f409202	feat: fix standing instructions GL accounting for current account transfers ... - AccountTransfersWritePlatformServiceImpl: * Direct GL posting for current↔savings/current transfers: DR debit-side account GL (with correct account entity_id) CR credit-side account GL (with correct account entity_id) * Prefix current account txn_id with CA (not C) so JournalEntryReadPlatformServiceImpl joins m_current_account and shows correct current account number on GL entries * Suppress redundant savings deposit/withdrawal GL entries (skipAccountingPostings=true) when current account handles the full double-entry directly * Separate performCurrentWithdrawalForLoan for Current→Loan transfers (loan domain service handles the other GL leg) * Reuse existing AccountTransferDetails for SI recurring runs so transactions appear in list-account-transactions history - SavingsAccountDomainService / SavingsAccountDomainServiceJpa: * New handleDeposit overload with skipAccountingPostings flag * handleWithdrawal respects SavingsTransactionBooleanValues .isSkipAccountingPostings() to suppress redundant GL entries - SavingsTransactionBooleanValues: * Added skipAccountingPostings field + overloaded constructor - AccountingProcessorHelper: * New createDirectTransferJournalEntriesForSavings() method creates DR and CR entries with separate productId/entityId so each GL line shows the correct account number - JournalEntryReadPlatformServiceImpl: * Join both m_savings_account and m_current_account always * COALESCE(ca.account_no, sa.account_no) to resolve correct account number regardless of transaction_id prefix - ExecuteStandingInstructionsTasklet: * Load existing AccountTransferDetails via repository so subsequent SI runs link to the same transfer detail record - ExecuteStandingInstructionsConfig / AccountConfiguration: * Wire AccountTransferDetailRepository and AccountingProcessorHelper into the relevant beans Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>	2026-05-26 16:30:04 +05:30
Jaanu423andClaude Sonnet 4.6	ea2dfd789d	feat: senior citizen interest rate fix for FD/RD accounts + CBS table renames ... - Apply senior citizen rate override in FixedDepositAccount and RecurringDepositAccount getEffectiveInterestRateAsFraction() so maturity is calculated at correct rate (e.g. 7.5%) instead of chart slab rate on every event: submit, activate, posting, pre-closure, maturity - Override getEffectiveInterestRateAsFractionAccrual() in both FD/RD to keep accrual consistent with maturity calculation — independent of DB nominalAnnualInterestRate value - Add isSeniorCitizen and seniorCitizenInterestRate fields to SavingsAccount entity with JPA mapping and accessor methods; updateNominalAnnualInterestRate() helper added - Extend DepositsApiConstants whitelist and SavingsAccountAssembler.applyCbsFields() to read and persist senior citizen fields from API request as final override step - Add DepositAccountAssembler early-stage rate override for senior citizen accounts - Liquibase migration 2015: add is_senior_citizen and senior_citizen_interest_rate columns to m_savings_account table - Liquibase migration 0300: rename fd_base_interest_rate tables to CBS naming convention - Update CBS copyright header in FdBaseInterestRateEffective and FdBaseInterestRateSlabHistory Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>	2026-05-21 20:57:17 +05:30
Jaanu423andClaude Sonnet 4.6	b25d5a30d2	feat: FD/RD GL transaction prefixes + savingsAccountNo in journal entry API ... - Use FD/RD transaction ID prefixes for Fixed/Recurring Deposit GL entries via ThreadLocal context set in Cash/AccrualBasedAccountingProcessorForSavings - Add depositAccountType to SavingsDTO and pass from SavingsAccount bridge data - Add savingsAccountNo field to JournalEntryData; populate via LEFT JOIN on m_savings_account (SB/FD/RD) and m_current_account (CA prefix) in read query - Fix JournalEntryMapper MapStruct: ignore savingsAccountNo (SQL-populated) - Fix JournalEntryRunningBalanceUpdateServiceImpl constructor call (27 params) Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>	2026-05-20 18:26:15 +05:30
Nitesh YadavandClaude Sonnet 4.6	cc0ccbb461	feat: multi-nominee support, duplicate validation, and FD/RD required fields ... Account Creation Enhancements: - Added multi-nominee support for SB, CA, FD, RD accounts (nominees[] array) - Backend: saveNomineesIfPresent() validates total share <= 100% before saving - Added 'nominees' to parameter whitelists (SavingsAccountConstant, DepositsApiConstants) Duplicate Validation Fixes: - SB/FD/RD: Fixed duplicate externalId error handler to walk full exception cause chain (EclipseLink wraps PSQLException deep) — now matches constraint 'm_savings_account_external_id_key' and returns proper 400 error - CA: Added try-catch around both saveAndFlush calls for duplicate externalId (constraint: ca_unq_external_id) with throwIfDuplicateExternalId() helper - CA: Added duplicate product check — blocks creating same product twice for client - SB/FD/RD: Added JpaSystemException handling via getAllCauseMessages() helper Current Account (CA) Improvements: - CurrentAccount entity: added @UniqueConstraint for external_id (ca_unq_external_id) - CurrentAccountRepository: added countActiveByClientAndProduct() JPQL query - Liquibase 0298: unique constraint on m_current_account.external_id FD/RD Required Field Validation (Backend): - DepositAccountDataValidator: depositPeriod now required for RD (was FD-only) - DepositAccountDataValidator: mandatoryRecommendedDepositAmount now notNull+positive for RD - DepositAccountDataValidator: customerSegment now required (notBlank) for both FD and RD Liquibase Migrations: - 0297: fix unique nominee per account constraint - 0298: unique external_id on m_current_account - 2014: add is_mandatory column to m_savings_account_joint_holders Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>	2026-05-20 08:00:00 +05:30
Nitesh Yadav	390bded7ef	rd and fd account active code update	2026-05-18 15:16:25 +05:30
Nitesh Yadav	d0c8be4ee9	charges add module add in the saving account and current account	2026-05-16 21:20:30 +05:30
Nitesh Yadav	30bbd6d0af	fixed error db migration and rd product edit error fixed	2026-05-12 11:32:13 +05:30
Nitesh Yadav	fbc6fcdcc1	rd and fd product and account code update	2026-05-08 15:55:22 +05:30
Nitesh Yadav	44878377d8	rd account and rd product code update	2026-05-08 13:09:07 +05:30
Nitesh Yadav	f1535a40c8	fd account complete mddule	2026-05-07 17:19:34 +05:30
Nitesh Yadav	407d567175	update fd account	2026-05-07 10:56:29 +05:30
Nitesh Yadav	4735111a4f	fd product releated update code	2026-05-05 15:18:35 +05:30
Nitesh Yadav	0bbf2faa3e	fixed some error releated product code	2026-05-01 11:33:07 +05:30
Nitesh Yadav	be220d8778	rd account save api update	2026-04-30 16:12:17 +05:30
Nitesh Yadav	a7965f8792	current account save api update	2026-04-29 15:18:45 +05:30
Nitesh Yadav	dc4a720ae2	feat: update savings product backend changes	2026-04-28 13:12:27 +05:30
Nitesh YadavandClaude Sonnet 4.6	72adbf6305	add accountTypeOptions and customerSegmentOptions to savings/current/RD account templates ... - Added accountTypeOptions and customerSegmentOptions fields to SavingsAccountData and RecurringDepositAccountData - Added CodeValueReadPlatformService to SavingsAccountTemplateReadPlatformServiceImpl, CurrentAccountTemplateReadPlatformServiceImpl, and DepositAccountReadPlatformServiceImpl to fetch options from code values - Added options to SAVINGS_ACCOUNT_RESPONSE_DATA_PARAMETERS and RD response parameters - Updated SavingsConfiguration bean factory methods to pass new CodeValueReadPlatformService dependency - Added validCheckSum for modified Liquibase changeset 0272 - Fixed AccountNumberGeneratorTest constructor to include GLAccountRepository and SavingsProductRepository Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>	2026-04-27 15:39:58 +05:30
Nitesh Yadav	159633f59a	add gl mapping in the saving product,current product,rd product and also add genrate account no all three	2026-04-26 02:02:56 +05:30
Nitesh Yadav	efb0511725	update account code current,saving and RD	2026-04-24 16:14:13 +05:30
Nitesh Yadav	691a3fc471	saving , current and RD account code update	2026-04-22 18:15:46 +05:30