9751 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
sonali	919bfb5204	Merge branch 'dev-latest' of https://git.lincpay.tech/CBSNexora/cbsnexora-backend into feature/advanceLoanProduct	2026-10-07 15:31:57 +05:30
sonali	39e3fcec59	feat: add loan interest backend functionality	2026-10-07 15:29:18 +05:30
keshav	cca4ae583f	Merge branch 'dev-latest' of https://git.lincpay.tech/CBSNexora/cbsnexora-backend into dev-latest	2026-10-07 10:14:13 +05:30
keshav	99a7e04872	feat: updates for tds services, rbi reserve config, and cashier api resources	2026-10-07 10:14:04 +05:30
niteshandClaude Opus 5	643427bd1a	fix(shares): correct share transaction lookup and validate NONE settlements ... redemptionValueOf() read from "m_share_account_transaction" with a "share_account_id" column. The table is m_share_account_transactions and the column is account_id, so every share withdrawal approval failed with a BadSqlGrammarException on the Share Sundry balance guard, before any posting was attempted. The lookup now also filters on is_active, matching ShareAdvanceCollectionApiResource.shareValueOf(), so a reversed purchase cannot price a redemption. validate() branched on "GL" versus everything else, but approve() handles a third settlement mode: submit() downgrades a request to NONE when the clerk names the product's own Share Sundry GL as the destination, and that mode posts Dr Share Capital / Cr Share Sundry and stops. Validating it as a savings settlement reported a missing fund source mapping that no posting in this mode ever reads, so a correct request showed a failed check. NONE is now reported as not applicable for both the linked-savings and the fund-source checks. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-10-06 19:03:51 +05:30
niteshandClaude Sonnet 5	6c7c0f8445	build: freeze the default (non-release/maintenance branch) jar version ... git-versioning's rev{} fallback previously derived the SNAPSHOT version from the nearest reachable git tag (major.(minor+1).0-SNAPSHOT), so the built jar's name drifted as tags moved. Pins it to a fixed 1.15.0-SNAPSHOT instead so the jar name stays predictable across builds on dev-latest/feature branches. release/*.*.* and maintenance/*.* branches still version off their own tags, unchanged. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-10-06 12:42:12 +05:30
niteshandClaude Sonnet 5	88157ee9d6	Revert "Enforce same-user maker-checker restriction" ... Reverts commits 2afd4aaf8 and 11a0d502b (both by anshul, same title). Restores the CHECKER_SUPER_USER self-approval bypass in CommandSourceService and the six *EditWritePlatformServiceJpaRepositoryImpl classes, and restores the original isSameMakerCheckerEnabled()/isCheckerSuperUser()-gated same-user check in PortfolioCommandSourceWritePlatformServiceImpl. Removes the 0588_persist_manually_enabled_maker_checker_permissions.xml migration added alongside the restriction. The unconditional same-user block these commits introduced was blocking legitimate single-admin operation/testing (e.g. creating and then activating a client as the same CHECKER_SUPER_USER), with no way to resolve it from inside the app. 11a0d502b's only change (0012_seed_default_platform_api_client.xml comment wording) is a no-op here: that exact text was independently reworded again by 82336cbe9 after 11a0d502b landed, so there is nothing left of 11a0d502b's change to revert in that file. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-10-06 10:02:34 +05:30
niteshandClaude Sonnet 5	760fff8d3e	fix(permissions): persist manually-enabled Teller/Cashier maker-checker settings ... Same pattern as 0588_persist_manually_enabled_maker_checker_permissions: converts a manually-applied Configure Maker Checker Tasks change into a repeatable migration, this time for the Teller/Cashier module. Found by diffing can_maker_checker across every permission code common to fineract_lincpay and a reference environment -- ALLOCATECASHIER_TELLER, ALLOCATECASHTOCASHIER_TELLER, SETTLECASHFROMCASHIER_TELLER, and UPDATECASHIERALLOCATION_TELLER were true there but still seeded false here, confirming they were toggled on manually and never captured for any other environment (including UAT). The _CHECKER permissions already exist and are already granted to Clerk/Teller/Branch Manager, so approval works as soon as this migration runs -- no role-grant changes needed. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-10-05 16:29:26 +05:30
Sonali LikhitkarandClaude Sonnet 5.5	b726577031	Update default DB password in application.properties ... Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>	2026-10-05 16:15:03 +05:30
Sonali Likhitkar	d1e94fd6a3	Add Fees-Penalty-Interest-Principal repayment transaction processor	2026-10-05 16:13:35 +05:30
keshav	d7ff4e4a7b	Merge remote-tracking branch 'origin/dev-latest' into dev-latest	2026-10-05 12:43:38 +05:30
keshav	7068d65422	feat: teller uniqueness, cashier allocation office check and interest posting report updates	2026-10-05 12:42:44 +05:30
nitesh	fd827dec27	fix(accounting,branchday): 3-stage FD interest posting in scheduler, fix branch day close business date validation	2026-10-04 16:02:25 +05:30
nitesh	aa264097e7	fix(savings,accounting): fix premature interest calculation date bounds and load interest payable GL mapping on edit ... Details of changes: 1. Premature Closure 1-Day Shortfall Fix (FixedDepositAccount & RecurringDepositAccount): - In calculatePreMatureInterest, explicitly reset transaction end-of-day balances to preMatureDate before invoking calculateInterestPayable. - Ensure end-of-day balances are restored to current business local date in a finally block. - Resolves the issue where premature closure missed 1 day of interest (e.g., -17.80 clawback) due to transaction end-of-day balances defaulting to the previous day when premature date matched current business date. 2. Interest Transfer Exclusions (SavingsAccountInterestPostingServiceImpl): - Exclude interest-transfer withdrawal transactions from non-interest posting transactions and end-of-day cumulative balance updates for fixed deposits transferring interest to linked accounts. 3. Interest Payable GL Load on Edit (AccountingConstants & ProductToGLAccountMappingReadPlatformServiceImpl): - Added INTEREST_PAYABLE(17) enum constant to CashAccountsForSavings in AccountingConstants. - Mapped CashAccountsForSavings.INTEREST_PAYABLE to SavingProductAccountingDataParams.INTEREST_PAYABLE in ProductToGLAccountMappingReadPlatformServiceImpl. - Fixes the bug where Liability -> Interest Payable Account GL was not loading in the product edit form (e.g., /products/fixed-deposit-products/:id/edit) even after being saved.	2026-10-04 11:54:28 +05:30
nitesh	16c67f6701	feat: Fixed Deposit - premature close logic, deposit account closure type, transaction validation, domain service and read service updates	2026-10-04 09:12:17 +05:30
nitesh	e846892e9f	Merge branch 'feature/bugfix' into dev-latest ... Brings in the backend counterpart of "Enforce same-user maker-checker restriction". Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> # Conflicts: # fineract-provider/src/main/resources/db/changelog/tenant-store/parts/0012_seed_default_platform_api_client.xml # fineract-provider/src/main/resources/db/changelog/tenant/final-changelog-tenant.xml	2026-10-01 13:25:29 +05:30
keshav	56d98bac8d	feat(rbi-reserve,savings): add Form1/Form9 returns, interest posting report and branch-day enhancements	2026-10-01 13:07:58 +05:30
niteshandClaude Sonnet 5	0d6066e0b6	fix(useradmin): strip password placeholder from a pending-edit replay payload ... A pending user edit's stored payload keeps a "[PROTECTED]" placeholder for the password rather than the real value. The actual new password is applied separately via request.getPasswordHash(), so the placeholder must not reach AppUser.update() or it tries to re-encode the literal placeholder string. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-10-01 12:13:02 +05:30
niteshandClaude Sonnet 5	4499b8afad	fix(accounting): post GL entries for a negative (clawback) interest transaction ... A premature FD closure that reprices interest downward (e.g. a pre-closure penalty) posts the difference as a negative interest-posting transaction -- a clawback of interest already recognised in earlier periods. Both the cash- and accrual-based accounting processors only posted journal entries when the transaction amount was greater than zero, so a clawback updated the FD subledger but silently posted nothing to the General Ledger, leaving the two out of sync. Treats a negative amount as a mirror-image reversal: positive magnitude, debit/credit legs swapped -- the same mechanism already used for isReversal. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-10-01 12:12:51 +05:30
niteshandClaude Sonnet 5	11a206f42a	feat(deposits): RBI premature closure compliance, simplified to always use the contracted rate ... Adds a Closure Reason to premature FD closure (Normal, Premature Extension, Conversion to Another TD, Deceased Settlement, Nominee/Legal-Heir), persisted as an RBI audit trail on m_deposit_account_term_and_preclosure. RBI-mandated reasons auto-waive the pre-closure penalty regardless of the maker's own checkbox; the maker can also waive it explicitly for any other reason. Interest rate for a premature closure is always the deposit's own contracted rate -- the same one its regular scheduled postings use throughout its life -- rather than a slab re-lookup against the actual period held. An earlier "actual-period vs contracted" toggle was built, tested, then deliberately removed per explicit request: simpler, and avoids disagreeing with interest the account was already accruing all along. Also fixes a real bug found while testing this: a renewed FD term's premature- closure interest was including the previous term's closing transaction a second time (it's dated the same day the new term starts), understating the first day's balance by the whole prior term's payout. Scoped the interest calculation to transactions strictly after the current term's start date. Known open issue: a renewed/auto-renewed account can still show a materially wrong (sometimes negative) premature-closure interest figure in some cases (seen on account 10, a QUARTERLY-posting auto-renewed FD) -- root cause not yet confirmed; needs further investigation with debug instrumentation before this is considered fully correct for every renewal shape. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-10-01 12:12:40 +05:30
anshul	11a0d502be	Enforce same-user maker-checker restriction	2026-10-01 12:03:32 +05:30
anshul	2afd4aaf83	Enforce same-user maker-checker restriction	2026-09-30 17:07:16 +05:30
anshul	e5dd6af366	Merge dev-latest into feature/bugfix	2026-09-30 16:47:41 +05:30
niteshandClaude Sonnet 5	ce8bb7e5ca	fix(products): named GL account changes (e.g. Savings Interest Payable/Paid) were silently lost on a pending edit ... Root cause: ProductPendingEditFieldMapper.populateCoreFields() captured otherGlMappings with stringValueOfParameterNamed(), which only handles a JSON string primitive. The maker's edit actually submits otherGlMappings as a nested {assets,liabilities,expenses,income} object -- the same shape SavingsProduct#update() already reads correctly via jsonFragment() -- so the pending-edit row was staged with this field blank every time, regardless of what the maker changed. Two consequences, both now fixed: - The checker's diff dialog showed "No changes to review" even when a GL account mapping (e.g. Savings/Current/FD/RD Interest Payable or Paid) was genuinely changed, since the submitted value never made it into proposedChanges. - Approving the edit replayed a payload with no otherGlMappings at all, so the GL account change was silently dropped rather than applied -- the edit showed as approved, but the product's accounting mapping never actually moved. Fixed the write side (jsonFragment instead of stringValueOfParameterNamed) and the read-side replay (writeCoreFieldsToJson now re-adds the stored value as a parsed JSON element via the new putJsonFragment, not a quoted string, which would have double-encoded it on replay). Shared by Savings, Current, FD and RD products, since they all go through this one mapper. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-30 12:39:58 +05:30
niteshandClaude Sonnet 5	82336cbe98	fix: remove illegal -- from migration 0012's XML comment ... Same mistake as an earlier migration this session: a literal "--" inside an XML comment is illegal per the XML spec and crashes the entire backend startup (Liquibase's XML parser rejects the whole changelog, not just this file). Reworded the prose to avoid it. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-30 12:00:59 +05:30
Sonali Likhitkar	22c4403a14	feat(loan-product): add advance loan product ext entity, API and liquibase	2026-09-29 17:56:50 +05:30
niteshandClaude Sonnet 5	9436eab129	feat(security): seed a fixed default platform API key via migration instead of a random one at runtime ... Replaces the previous DefaultApiClientBootstrapper (ApplicationRunner minting a random key on first startup) with a plain Liquibase seed on the tenant-store database: one fixed, well-known api_key_hash row, inserted once via migration 0012, same on every deployment and every tenant -- exactly like this fork already seeds default codes/permissions, rather than generating a secret at runtime. The trade-off is explicit in the migration's own comment: a fixed key checked into source is a bootstrap convenience, not a secret, and any deployment beyond local/dev must rotate it (insert a new hash, deactivate this row) before going live -- rotation is a direct m_api_client write, same as the seed itself, since POST /v1/apiclients stays disabled. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-29 17:01:07 +05:30
niteshandClaude Sonnet 5	1408bddf58	feat(security): auto-mint the first platform-operator API key on deploy, disable minting one over HTTP ... A fresh deployment's m_api_client table starts empty, and reaching #/platform-admin/menu-access requires a valid X-Api-Key -- with no key, every tenant 401s identically (this is by design, not tenant-specific). Add DefaultApiClientBootstrapper: an ApplicationRunner that mints exactly one random key on first startup (guarded by "table still empty", so later restarts are a no-op) and logs the raw value once to the server's own application log -- never to the database, never over HTTP. Disable ApiClientAdminApiResource's POST /v1/apiclients entirely: it only required ALL_FUNCTIONS, a per-tenant role grant, so any bank's own super user (or a misconfigured role, as "Clerk" was found to carry it in two tenants this session) could mint themselves a platform-wide operator key and bypass the exact ceiling TenantMenuAccessApiResource exists to enforce. New keys past the first are now a direct m_api_client insert only. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-29 15:36:18 +05:30
anshul	e02ab51ee1	Merge branch 'dev-latest' into feature/bugfix	2026-09-29 10:21:21 +05:30
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