9779 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
niteshandClaude Sonnet 5.5	6be32272c1	feat(cashier): maker-checker on cash transfer ... Cash no longer leaves the vault on one person's say-so. The allocation to a cashier is raised as a request and posted only when a different manager or head cashier approves it. - POST /cashtransfer/requests raises the request after every vault check (total and note by note); the same checks run again at approval, since the vault can change in between. - Approve posts the transfer exactly as the direct one did and records it against the maker; reject needs a reason; the maker cannot approve their own request. - An identical request from the same maker is refused while the first is still pending. - The direct POST /cashtransfer is closed so the approval cannot be bypassed. - Migration 0603 adds m_cash_transfer_request; m_cash_transfer and every position query are unchanged. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>	2026-10-15 12:27:22 +05:30
niteshandClaude Sonnet 5.5	b47a34b5ef	feat(vouchers): voucher correction for cash deposits posted to the wrong account ... A cash deposit posted to the wrong savings account is corrected without ever undoing it behind anyone's back: the voucher is unpassed (admin or clerk), a manager approves, the cashier enters the correct account, and a manager approves again. Only the final approval moves money: the deposit is reversed on the wrong account, the same cash is deposited into the right one under a new voucher, and the cashier's denominations follow it. - VoucherCorrectionApiResource: eligible list, unpass, approve/reject unpass, account lookup, correction, approve/reject correction, close request, voided transactions. - The wrong account's balance is checked when the cashier enters the correction and again at approval. - A cashier whose customer has already used the money closes the request and deposits separately. - Roles are enforced on the server: unpass for admin/clerk, correction and close for a cashier, approvals for a manager or head cashier other than the maker. - Migration 0601 adds m_voucher_correction; 0602 drops the status columns an earlier draft put on m_voucher, since the correction status is read from m_voucher_correction alone. - Voucher registers (register, My Vouchers, day book, voucher detail) report each voucher's correction status and leave a revoked voucher out of their totals, so its cash is not counted twice. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>	2026-10-15 12:27:21 +05:30
niteshandClaude Sonnet 5.5	04d1eb20f0	feat(clerk-withdrawal): GL withdrawal slips through request, approval and cashier payment ... A GL withdrawal slip (e.g. Sundry Creditors paid out in cash) now follows the same maker-checker path as a savings withdrawal: - the request carries gl_account_id, contra_gl_id, office_id and currency_code (new nullable columns, changeset 0600) instead of a savings account; - at submit it is validated: the paying GL must be a mapped cash vault GL and the slip's own GL must not be a cash GL; - at manager approval it posts Dr the GL / Cr the cash vault GL as a journal entry; - the cashier pays it against its token, and the denomination and voucher lines are recorded under the journal entry's id. KYC debit checks are skipped for GL requests. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>	2026-10-14 13:51:01 +05:30
niteshandClaude Sonnet 5.5	da1e21f2ca	feat(security): block undo/reverse of posted transactions at API level ... Rejects journal entry reverse, savings/current undo and reverse, fixed and recurring deposit undo, and loan transaction undo (adjust with zero amount) with a clear error, so posted entries cannot be reversed by calling the API directly. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>	2026-10-13 18:42:01 +05:30
niteshandClaude Sonnet 5.5	b1eea68b17	feat(cashier): cashier-only cash operations, exchange PAN/denomination checks and branch position API ... - Cash exchange: customer name/mobile/PAN (PAN mandatory above Rs 50,000), denomination validation against m_denomination_master, cashier required; Liquibase 0599 adds the three columns. - Inter-cashier: sender must be the logged-in cashier, cash-allocated validation, new cashier-summary endpoint. - Reconciliation restricted to the logged-in cashier's own records. - New cashreport/branch-position endpoint (vault + cashier drawers, denomination-wise). - Customer search returns the KYC PAN. - Reverse endpoints removed from cash transfer, settlement, exchange and inter-cashier. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>	2026-10-13 18:42:00 +05:30
niteshandClaude Opus 5.5	539f6cd0f4	fix(accounting): allow unbalanced legs when defining opening balances ... Defining opening balances was rejected by the debit/credit balance check that ordinary journal entries go through. For opening balances that check does not hold: every leg is posted against the opening balance contra account, so the books always balance, and the submitted legs legitimately differ by the opening balance of the locked, denomination-managed cash account, which is already posted and can never be part of the request. - validateBusinessRulesForJournalEntries takes a requireBalanced flag. Ordinary journal entries keep the full check (requireBalanced = true). - defineOpeningBalance passes false: it still needs at least one leg and an account and amount on every leg, but no longer requires debits and credits to be present on both sides or to add up. Verified with :fineract-provider:compileJava. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-13 11:00:39 +05:30
niteshandClaude Opus 5.5	0afcf059a8	Merge latest feature/advanceLoanProduct into feature/merge-dds-advance-loan-into-dev-latest ... Brings Sonali's four new commits (7-12 Oct): - Loans A/C extension fields (collateral, eligibility, repayment, rate source, prepayment) - Maker-checker for Delinquency Ranges and Buckets - Loan interest rate register product master and GL account seeding - Her merge of dev-latest (7 Oct) Conflict resolved: - changelog-tenant.xml: kept both. 0594_loan_rate_register_product_ master, 0595_seed_loan_rate_register_gl_accounts, 0596_enable_delinquency_maker_checker and 0597_add_loan_product_ loans_ext_fields go with the earlier advance loan changelogs, before the DDS block that stays last. No file name is shared with dev-latest's 0594-0597 files. 0581_enable_loan_rate_register_maker_checker.xml: taken as on feature/advanceLoanProduct. It edits the existing 0581a/0581b changesets (CBSLOANBASEINTERESTRATE -> LOANBASEINTERESTRATE) and adds 0581c to rename rows already seeded; all three carry <validCheckSum>ANY</validCheckSum>, so databases that ran the old version still validate. CommandSourceService: Sonali's LOANBASEINTERESTRATE, DELINQUENCY_BUCKET and DELINQUENCY_RANGE checks sit alongside the DDS isDdsEntity check. Nothing from dev-latest, DDS or Sonali is removed; no file deleted; no DB password change. Verified with :fineract-provider:compileJava. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-12 16:29:42 +05:30
sonaliandClaude Sonnet 5	2d10ec60f8	feat(loan-products): add Loans A/C extension fields (collateral, eligibility, repayment, rate source, prepayment) ... Stores the Loans A/C (EMI) wizard's fields that have no home in Fineract's core loan-product schema on the same per-product satellite used for Advances: collateral/guarantor rules, borrower eligibility, disbursement, repayment mode, rate source / floating reset, and part-prepayment/foreclosure. Columns are loan_-prefixed so they never collide with the Advances columns on the shared table. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-10-12 15:50:47 +05:30
sonaliandClaude Sonnet 5	14973dfd5e	feat(delinquency): add maker-checker for Delinquency Ranges and Buckets ... Range/bucket create, update and delete now route through the standard command-source approval pipeline, since a bucket drives the SMA/NPA classification of every loan product linked to it. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-10-12 15:50:29 +05:30
niteshandClaude Opus 5.5	f96705baa4	Merge branch 'feature/advanceLoanProduct' into merge/dds-advance-loan-into-dev-latest ... Adds the Advance Loan Product backend on top of the DDS merge of dev-latest: - Advance loan product ext entity, API and Liquibase (LoanProductAdvanceExtService; loan product API accepts and returns "advanceExtensions") - Fees-Penalty-Interest-Principal repayment transaction processor, enabled by fineract.loan.transactionprocessor. fees-penalties-interest-principal.enabled (default true) - Loan interest rate register backend Conflict resolved: - changelog-tenant.xml: kept both. The four advance loan changelogs (0571_create_loan_product_advance_ext, 0572_add_loan_product_advance_ ext_fields, 0580_create_loan_rate_register_tables, 0581_enable_loan_rate_register_maker_checker) go just before the DDS block, which its comment says stays last. Their numbers overlap dev-latest files but no file name is shared. Not taken from feature/advanceLoanProduct: - Commit b72657703 changed the default DB password in application.properties to a UAT database password. That merged without a conflict; the dev-latest password lines are kept so local setups keep working and the UAT password does not go into the repository. The new transaction processor property from the same file is kept. Nothing from dev-latest or DDS is removed: no file deleted; only LoanProductsApiResource (one supported parameter added), LoanProductConfiguration (one constructor argument added) and application.properties change existing lines. CommandWrapperBuilder, changed on both sides, has no duplicate methods. Verified with :fineract-provider:compileJava. Branch renamed from merge/dds-into-dev-latest, since it now carries both DDS and Advance Loan Product. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-12 15:29:13 +05:30
niteshandClaude Opus 5.5	9d6ef18929	Merge branch 'feature/dds' into merge/dds-into-dev-latest ... Brings the DDS (Daily Deposit Scheme) backend from feature/dds onto the current dev-latest: - Agent settlement (Agent Tran), Close Party account, reports (Supplementary-DDS, Master Data Export, Close Register), Party-Savings link, savings product category field - Collection entries held before posting, per-agent GL accounts, maturity auto close - Vouchers, maker-checker approvals, payout & close, Sundry GL, closure tab and fixes - POST_DDS_INTEREST job No content conflicts. No dev-latest file is removed; only three dev-latest lines are extended with a DDS condition: - CommandSourceService: DDS entities join ROLE in the maker-checker entity check (isDdsEntity). - PortfolioCommandSourceWritePlatformServiceImpl: a DDS entry can never be approved by the user who made it, even a checker super user. The rule for every other entity is unchanged. - SavingsProductDataValidator: productCategory accepted as a savings product parameter. Files changed on both branches and auto-merged: CommandWrapperBuilder, CommandSourceService, JobName, SavingsApiConstants, SavingsProductData, SavingsProduct, FixedDepositProductData, RecurringDepositProductData, DepositProductReadPlatformServiceImpl. Checked for duplicate methods, fields and enum names. Liquibase: 55 DDS changelogs (0470-0525) included as one block at the end of changelog-tenant.xml. Their numbers overlap dev-latest's files but no file name is shared, and Liquibase tracks changesets by file path, so nothing clashes. They keep their names so databases that already ran them do not run them again. No permission code, job name or configuration name is inserted by both branches. Verified with :fineract-provider:compileJava. The full compileJava fails only in fineract-client (generated CKYC, committee meeting and election APIs), which feature/dds does not touch. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-12 15:11:14 +05:30
niteshandClaude Opus 5.5	936e21dcf6	Merge branch 'feature/fd-interest-posting' into dev-latest ... Brings the FD interest posting work into dev-latest: - FD interest posting approval with pooled GL postings, posting period shown per line, maturity postings surfaced, double-posting guard - FD maturity approval report added and then reverted (maturity now runs directly through the scheduler, no approval step) - Pending user approval encodes the password and emails it - New-tenant user personalisation, with the 'system' username kept so scheduler jobs and COB can still find the system user Conflicts resolved: - SavingsAccountReadPlatformServiceImpl#retrieveAllSavingsDataForInterestPosting: kept both exclusions. Recurring deposits (deposit_type_enum 300) stay out of the generic interest posting job (dev-latest), and fixed deposits are also left out when FD interest posting approval is enabled (feature branch), so FD interest is not paid twice. Comments from both sides merged. - final-changelog-tenant.xml: kept dev-latest's 0592-0598 TDS and recurring deposit changelogs and added 0593_fd_interest_posting_approval.xml after them. The file keeps its name although its number clashes with 0593_tds_...: Liquibase tracks changesets by file path, so renaming it would re-run it on databases that already applied it. Changeset ids in the two files differ. Verified with :fineract-provider:compileJava. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-12 12:23:55 +05:30
niteshandClaude Opus 5.5	aceea89c5c	fix(tenants): keep the 'system' username when provisioning a new tenant ... Problem Commit 3d3ce92e9 personalised the three users seeded into a brand-new tenant database and renamed user id 2 from 'system' to '<tenant>_system' (for example 'default_system'). Fineract looks this user up by the fixed name AppUserConstants.SYSTEM_USER_NAME ('system') through AppUserRepositoryWrapper.fetchSystemUser(), so on every fresh tenant: - every scheduler job failed once a minute with "UserNotFoundException: User with name 'system' does not exist" (seen with the Send Asynchronous Events job); - COB initialisation, savings escheat, current account closure and the stuck-job listener would fail in the same way. Existing tenants were not affected because the provisioner only runs right after the very first migration of a new tenant. Fix - TenantInitialUserProvisioner now sets user id 2's username to AppUserConstants.SYSTEM_USER_NAME and only replaces its password. - Admin and interop users are still personalised as '<tenant>_admin' and '<tenant>_interop'. - Javadoc and the startup log line now say the system user keeps its name and why. Resulting users on a new tenant - <tenant>_admin (password: initial-user-password or built-in default) - system (same password, name unchanged) - <tenant>_interop (same password) Tenants already created with '<tenant>_system' need a one-off fix: UPDATE m_appuser SET username = 'system' WHERE id = 2; Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-12 11:55:18 +05:30
keshav	99ef5edfd8	Merge branch 'dev-latest' of https://git.lincpay.tech/CBSNexora/cbsnexora-backend into dev-latest	2026-10-12 10:25:19 +05:30
keshav	9df8e924a1	feat: recurring deposit product rules, lien, auto debit, missed installment penalty, and jobs	2026-10-12 10:25:12 +05:30
niteshandClaude Sonnet 5	1fd94615a9	revert(fixed-deposits): remove FD maturity approval report ... A fixed deposit's maturity is settled directly by the nightly updateMaturityDetails job again, unconditionally, for every deposit type and every closure instruction — the approval gate this introduced turned out to risk more than it protected and is being removed before it ever shipped enabled by default. Removes the fdmaturity package entire (report service, orchestrator, API resource, noon-generation job), its migration and global configuration, the day-close integration in BranchDayRegisterApiResource, and FixedDepositAccount#previewMaturityInterestPeriods, which existed only for this report's preview and has no other caller. The periodic FD interest posting approval report (0593) is untouched — a matured deposit's final interest, paid directly by the nightly job, already surfaces there under "Posted outside approval", same as it did before this report existed. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-10-09 12:50:11 +05:30
niteshandClaude Sonnet 5	3d3ce92e93	feat(tenants): personalise seeded user credentials for a brand-new tenant ... Adds TenantInitialUserProvisioner: right after the very first Liquibase migration of a tenant that was never on Flyway, renames the three seeded users (ids 1-3, otherwise shipping as mifos/system/interopUser with the public default password) to <tenantIdentifier>_admin/_system/ _interop, with a password from fineract.tenant.initial-user-password or a built-in default. An existing (Flyway-era) tenant already has its real users and is left untouched. Wired through TenantDatabaseUpgradeService and its two test configurations. Also fixes the two pooled interest-posting services' system-user lookup, which read username = 'system' — now wrong since that username is personalised per tenant — to find the seeded system user by its fixed id (2) instead. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-10-08 22:41:25 +05:30
niteshandClaude Sonnet 5	1a914a3de0	feat(fixed-deposits): maturity approval report, scoped to deposits with no closure instruction ... Adds the FD maturity approval workflow: a deposit with no closure instruction of its own (Maturity Instructions left "Not selected") waits — status, final interest and whatever renewal is later chosen from the FD Dashboard all run together in one real maturity run, only once a second user approves the report, as the branch closes its day. A deposit that already named Transfer to Savings or a Reinvest option settles itself the moment it matures, unchanged — a decision the customer already made in writing needs no second approval. The nightly job is narrowed to skip only the undecided ones; FixedDepositAccount#previewMaturityInterestPeriods reads the same maturity-interest calculation the real posting uses, without writing anything down, so the report's figure is never a guess. Posting an approved report calls the existing, unchanged DepositAccountWritePlatformService#updateMaturityDetails per deposit, each in its own transaction — one with a bad closure target does not hold up the others, and a retry only touches what did not post last time. Adds a reconciliation view (outside-approval) listing deposits that matured via their own closure instruction, same reasoning as the interest report's: found by what has no report line, not by naming the instruction, so a future direct path is caught here too. Day-close integration mirrors the interest report exactly: blocks on a pending maturity report, posts approved ones alongside approved interest reports, independently so one failing does not stop the other. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-10-08 19:06:40 +05:30
niteshandClaude Opus 5	6e7eb94776	fix(users): encode password and email it when approving a pending user creation ... finalizeCreateUser() (run when a checker approves a CREATE_USER request queued in m_user_pending_request) saved AppUser.fromJson()'s result straight to m_appuser via appUserRepository.saveAndFlush() with no encoding step for the password AppUser.fromJson() auto-generates when the maker ticks "send password to email" -- AppUser's constructor stores whatever string it is given verbatim, so that random password was landing in m_appuser.password as plain text. Only the maker-chosen-password case (request.getPasswordHash() != null) was ever hashed, because that happens earlier, at submitCreateUser() time. It also never called the email service at all, in either case. The live create-user flow (JpaUserDomainService.create()) captures the unencoded password, encodes it, saves, then emails the welcome message -- finalizeCreateUser() duplicates everything up to the save but stops there, so a user created through this maker-checker flow never received their credentials regardless of what sendPasswordToEmail said in the submitted payload. Fix: capture the auto-generated plaintext right after AppUser.fromJson(), encode it with this class's own PasswordEncoder bean (already used the same way for the maker-chosen-password branch, consistent within the file) before saving, and call PlatformEmailService.sendToUserAccount() afterwards when sendPasswordToEmail was true and no maker-chosen password overrides it. A maker-chosen password is unrecoverable by approval time (submitCreateUser() redacts it to "[PROTECTED]" immediately), so that case still cannot be emailed, and isn't -- there is nothing wrong to fix there. Found by manually submitting a CREATE_USER request locally and reading both AppUser.fromJson() and the approval path end to end; no existing approved user was re-created to verify in place, since doing so would need resetting a real password. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-10-08 19:03:17 +05:30
sonali	a127710442	feat(loan-products): add product master table and GL account seeding for loan interest rate registe	2026-10-08 17:29:39 +05:30
niteshandClaude Sonnet 5	6fbc3a85a8	feat(fixed-deposits): show the period each posting covers, surface maturity postings, guard against double-posting ... Adds interest_period_from to the report line so each posting shows the span it covers (e.g. "01 Oct - 31 Dec, Quarterly"), not just the date it ends on, and a postingPeriodLabel on the report itself. Adds a reconciliation endpoint (outside-approval) that lists fixed deposit interest posted without this report's approval — chiefly a deposit that matured before its own posting cycle completed, whose last period the maturity job settles directly. Read-only, so a branch can see every rupee of deposit interest it has paid, approved or not. Guards posting itself against the same situation: before crediting a line, checks whether its deposit already carries an interest posting for that exact date (raised by the maturity job in the window between this report being generated and being posted). If so, the line is linked to what actually paid it instead of being paid again, and its amount is reconciled off the report's approved total rather than failing the whole posting. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-10-08 00:06:14 +05:30
niteshandClaude Sonnet 5	949f45c4cd	feat(fixed-deposits): FD interest posting approval with pooled GL postings ... Adds a maker-checker approval report in front of fixed deposit interest posting, mirroring the existing savings interest posting report: a report is generated per branch and product (SINGLE/DOUBLE/SPECIAL), a second user approves it, and it posts when the branch closes its day. Day close is blocked until deposit interest due that day is approved. Ledger entries are pooled per the report's interestPostingDate rather than raised per deposit: Dr Interest Expense and the Payable/Paid legs are each raised once for the group's total, and only the final leg crediting each deposit's own GL is per account — the same pattern the savings interest posting report already uses, instead of repeating the full three-stage chain for every deposit. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-10-08 00:06:00 +05:30
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
nitesh	1922455996	Merge branch 'dev-latest' of https://git.lincpay.tech/CBSNexora/cbsnexora-backend into dev-latest	2026-10-07 10:18:27 +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	ac7873a51e	feat(shares): add preview-validate endpoint, fix document attachment 500 ... ClerkShareWithdrawalRequestApiResource: extracted validate(Long)'s checklist logic into buildShareWithdrawalChecks(Map<?, ?>) and added a new POST /preview-validate endpoint that runs it against a draft submission (same fields submit() accepts, same Sundry-downgrade rule applied first) instead of an already-persisted request. Lets the clerk see the exact checklist a manager will see on approval before the request is even submitted, with zero risk of the two checklists drifting apart, since both now call the same method. The one check validate() runs that a draft cannot -- "Maker and Checker are different users" -- is reported as a fixed reminder instead of silently dropped, since the clerk previewing this is necessarily the maker and no checker has been chosen yet. DocumentReadPlatformServiceImpl.retrieveDocumentContent(): a document/signature whose m_document row survives but whose underlying file is missing from the content store (the usual cause is a database copied between environments without its file store) was throwing an uncaught ContentStoreException, surfacing as a raw 500 on every fetch. Now caught and converted to the same DocumentNotFoundException (404) ImageReadPlatformServiceImpl already uses for the identical situation on client photos, so the frontend's existing graceful-fallback handling for a missing attachment applies here too. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-10-06 22:40:12 +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
tarunmalviya	b0e3c0ac8b	DDS: vouchers, maker-checker approvals, payout & close, Sundry GL, closure tab, fixes	2026-10-01 12:47:48 +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