539 Commits

Include renames

Author	SHA1	Message	Date
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	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
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	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
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	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
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
Sonali Likhitkar	d1e94fd6a3	Add Fees-Penalty-Interest-Principal repayment transaction processor	2026-10-05 16:13:35 +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	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	2afd4aaf83	Enforce same-user maker-checker restriction	2026-09-30 17:07:16 +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	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	cebba87864	Merge branch 'dev-latest' into feature/bugfix	2026-09-25 11:24:24 +05:30
anshul	7eabaf2542	Merge branch 'dev-latest' into feature/bugfix	2026-09-24 18:09:48 +05:30
keshav	4b9093007f	feat: update TDS config, RBI reserve, current products, OSS returns, and dormancy services	2026-09-24 18:06:29 +05:30
anshul	9beae3df28	Implement organization maker-checker workflows	2026-09-24 17:22:39 +05:30
niteshandClaude Sonnet 5	ecfe8aa76a	feat(fd): add Renewal Grace Period product field, both storage paths ... New per-FD-product "Renewal Grace Period (Days)" term field: null/0 (every existing product) keeps today's instant, same-night auto-renewal; a positive value is later read by the nightly maturity job and the manual Renew action to decide whether/how a matured FD waits for staff to act instead of renewing itself. Wired into the live product path end-to-end -- DepositsApiConstants param, DepositTermDetail column + diffing, DepositProductAssembler (create and update), DepositProductReadPlatformServiceImpl, FixedDepositProductData -- migration 0572 adds the column. Also wired into the maker-checker pending-edit mirror (m_saving_product_temp / FixedDepositEditFields / ProductPendingEditFieldMapper), a second, independent storage path a governed product edit uses -- without this the field silently dropped out of a checker's "Proposed changes" review even though it was submitted. Migration 0573 adds its column. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-24 15:55:11 +05:30
niteshandClaude Sonnet 5	bc38216ca3	fix(deposits): FD Single Rate Calculator crashed for tenures under 30 days ... SYMPTOM Opening the FD account create screen for a "SINGLE" (Days < 1 Year) product, entering a Deposit Tenure under 30 days (e.g. 27), and clicking "Find Rate" returned a 400: "The parameter `tenureInMonths` must be greater than 0." ROOT CAUSE The Rate Calculator preview always converted the entered tenure to months before calling GET /fixeddepositaccounts/calculate-fd-interest (fixed-deposits.service.ts -> fixed-deposit-account-interest-rate- chart-step.component.ts, calculateRate()): tenureInMonths = Math.floor(enteredDays / 30) For any tenure under 30 days this floors to 0, and DepositAccountDataValidator.validateForInterestCalc() requires tenureInMonths > 0 unconditionally, so the request was rejected before it ever reached the calculation service. FIX Added `tenureInDays` as an alternative to `tenureInMonths` for this one calculator endpoint only (DepositsApiConstants. FIXED_DEPOSIT_ACCOUNT_INTEREST_CALCULATION_PARAMETERS) - not a general-purpose FD field, not touched anywhere else: - DepositAccountDataValidator: tenureInMonths is required unless tenureInDays is a positive value (either satisfies the check). - FixedDepositAccountsApiResource#calculateFixedDepositInterest: accepts the optional tenureInDays query param. - FixedDepositAccountInterestCalculationServiceImpl#calculateInterest: when tenureInDays > 0, the exact-calendar maturityDate is computed via submittedOnDate.plusDays(tenureInDays) instead of plusMonths(tenureInMonths) (which would silently compute a 0-day maturity window for a sub-month tenure). - Frontend (separate commit) now sends tenureInDays instead of a truncated-to-zero tenureInMonths whenever the entered tenure is under 30 days. SCOPE / WHAT THIS DOES NOT TOUCH Only the interest-preview calculator endpoint above. Real FD/RD account submission still uses depositPeriod + depositPeriodFrequencyId (Days=0) exactly as before; this commit does not change how an actual account's maturity date/amount gets computed at activation. IF THIS BREAKS SOMETHING LATER - "tenureInMonths must be greater than 0" reappearing for a SHORT FD tenure -> check the frontend is actually sending tenureInDays (network tab on the Find Rate call); the validator's OR-logic is in DepositAccountDataValidator.validateForInterestCalc(). - A wrong preview maturity amount for a sub-month FD Single -> check FixedDepositAccountInterestCalculationServiceImpl#calculateInterest's branch choosing plusDays vs plusMonths for maturityDate. - This bug and fix were previously implemented once, then fully reverted mid-session at the user's request (unrelated Deposit Account Link regression got tangled up with it), then reapplied cleanly here as a standalone, narrowly-scoped fix. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-23 14:20:38 +05:30
tarunmalviya	fa8e5f3f16	Merge remote-tracking branch 'origin/dev-latest' into feature/dds-agent-settlement-reports ... # Conflicts: # fineract-core/src/main/java/org/apache/fineract/commands/service/CommandWrapperBuilder.java # fineract-core/src/main/java/org/apache/fineract/infrastructure/jobs/service/JobName.java # fineract-provider/src/main/resources/db/changelog/tenant/changelog-tenant.xml	2026-09-23 10:23:37 +05:30
tarunmalviyaandClaude Opus 5	12fdf035ca	DDS: collection entries held before posting, per-agent GL accounts, maturity auto close ... Collections used to reach a customer the moment they were typed, on the reasoning that the money is theirs from the moment the agent takes it. That holds until the agent does not arrive - and then the books say a customer was credited with notes the bank never held, and there was nothing to count the agent's bag against when they did. An agent now records their own round. Those entries sit in m_dds_collection_entry and move nothing: no balance, no ledger, no agent cash. A clerk counts the cash against what they add up to and settles the day, and what that writes is an ordinary collection - posted through the counter's own code rather than a copy of it, so the two cannot drift apart. Each agent may also hold their own ledger account now, one agent to an account. Both sides of the entry, their direction and the amount are unchanged; only which account plays the agent's part differs, and only for agents that name one. What is left standing on an agent's own account is the cash they are holding and have not brought in - a question nobody could answer while every agent shared a single account. A scheme can close its own accounts on maturity, for accounts whose customer named where the proceeds go. The run is generated and reviewed before anything moves, and an account that named no destination is simply not on the list and is paid out by hand as before. Also: the payment mode is a fixed set and stored one way; an agent's birth date must be in the past and of age; a maturity credit account is checked whenever it is written rather than only when the Adv Code happened to arrive beside it; and two report columns stop printing money ungrouped. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-22 22:16:14 +05:30
keshav	fde2699957	feat: sponsor bank DD payable GL, AML stale review release, and dividend updates	2026-09-21 10:23:52 +05:30
keshav	c1e6e036d0	feat(aml): enforce review locking and sync STR case conclusions to linked alerts	2026-09-18 10:29:17 +05:30
keshav	521d61d6b7	feat: AML alert rule disposition, Client Behaviour Window evaluation, Risk Policy parameters & Board Resolution register	2026-09-16 12:50:43 +05:30
keshav	1c6ac9d77f	feat: AML direction/entity scoping, Sponsor DD revoke workflow, Dividend GL resolution & TDS module	2026-09-14 11:46:16 +05:30
keshav	3d196276c8	feat(savings): support rounding adjustment GL mapping and floor rounding on clerk closure	2026-09-11 10:48:50 +05:30
keshav	5cc5d680f2	feat: separate kyc/aml risk rules, dormancy clock, and savings daily interest fixes	2026-09-10 18:27:50 +05:30
niteshandClaude Sonnet 5	05bceea2d4	feat(office): maker-checker delete for offices; fix DB password leak, migration ordering, job id drift ... Adds the missing DELETE /offices/{officeId} endpoint -- the UI's "Remove" action called it already, but no backend route existed, so every attempt failed with a generic error regardless of how empty the office was. Wired the standard command-handler chain (CommandWrapperBuilder.deleteOffice -> DeleteOfficeCommandHandler -> OfficeWritePlatformService.deleteOffice), which pre-checks sub-offices/staff/clients/groups/users before deleting, and catches any remaining FK violation on delete itself. The new DELETE_OFFICE permission (0537) is seeded maker-checker-enabled (0538), since this app runs with the global maker-checker switch on and office deletion is irreversible -- 0538 is a separate changeset rather than 0537 itself because 0537 had already executed on local tenants by the time that requirement surfaced, and editing an already-run changeset's content breaks Liquibase's checksum validation on every tenant that ran it. Also bundles a few DB/startup fixes found while getting this feature running across local and a remote environment: - application.properties: restores the tenant DB password default that a teammate's own local password had overwritten in a previous push, and adds server.error.include-message=always so a servlet-level rejection (e.g. TenantAwareBasicAuthenticationFilter on a missing/invalid Fineract-Platform-TenantId header) carries a real message instead of a bare {timestamp,status,error,path}. - changelog-tenant.xml / final-changelog-tenant.xml: moves the 0517/0518 table-creation includes ahead of 0525-0527/0533, which read/write those tables but previously ran first per db.changelog-master.xml's include order -- caused "relation ... does not exist" on any tenant reaching that point for the first time. - 0536_sync_job_identity_sequence.xml: job.id is GENERATED BY DEFAULT AS IDENTITY; explicit-id job-seed inserts never advanced the backing sequence, so a later identity-generated insert could collide with an earlier explicit id ("duplicate key value violates ... job_pkey"). - ClientAllAccountsApiResource: NotFoundException(String) only sets the exception's own message for logs, it never reaches the response body, so a "client not found" 404 always came back empty; now built as a proper JSON error body. Also collapsed the message/defaultUserMessage/ errors[0].defaultUserMessage triple down to one message field -- this endpoint never raises more than one error at a time, so the repetition added nothing. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-08 15:16:07 +05:30
keshav	e33e0f23fe	feat: cashier reports, daily interest enhancements and business date sync	2026-09-08 10:45:04 +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
niteshandClaude Opus 5	5a9a103832	Merge branch 'maker-checker' into dev ... Brings in maker-checker for GL accounts, charges, product creation (loan, savings, current, share, FD), admin users/roles and base interest rates, plus the UserPendingRequest domain and AppUserPreference. Two resolutions: changelog-tenant.xml — both branches appended <include> lines at the end of the file, so the conflict was append-vs-append with no semantic overlap. Kept both sets in order: dev's 0470-0499 followed by maker-checker's eight. Liquibase runs in <include> order, not filename order, so the reused 0466-0476 numbers change nothing (dev already carries duplicate numbers in that range). application.properties — the branch carried another developer's local database password, which would have stopped this backend connecting at startup. Restored ours; the file is now byte-identical to its pre-merge state. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-01 18:07:24 +05:30
nitesh	c4a99fea5d	feat(savings,clerkwithdrawal): expose linked share account on savings read, add search filter to withdrawal request lists ... Surfaces shareAccountId/shareAccountNo on the savings account read API so the UI can display and auto-select an already-linked share account; adds an optional search query param to the clerk cash and share withdrawal request list endpoints for the Approval Center's new search boxes.	2026-09-01 07:40:39 +05:30
niteshandClaude Sonnet 5	dc0539d53d	feat(savings,shares): bidirectional savings/share account linking, optional savings link on share create ... - Savings account creation validates and stores a required "shareAccountId" once Share Linking is enabled, checked against the client's own active share accounts (raw SQL - fineract-savings has no dependency on the shareaccounts domain). On save, mirrors the link back onto the share account's own savings_account_id, the same way that field already gets set from the share side. - New GET /clients/{id}/activeshareaccounts - a client's active share accounts, for the savings creation screen's picker (kept separate from the shared Savings/FD/RD/Current template DTO). - ShareAccountDataSerializer.validateAndCreate no longer requires savingsAccountId on create - the DB column and domain relationship were already nullable, only this validation blocked it. fix(branchday): stop the denomination carry-forward preview from doubling yesterday's closing count GET /branchday/denominations classified every detail row that wasn't literally leg='OPENING' as "closing" - which, once CLOSING_VAULT rows existed alongside CLOSING (single-teller offices record the same breakdown under both), silently doubled every count shown as "yesterday's closing" when opening the next business day. Filters to leg IN ('OPENING','CLOSING') explicitly instead of an else-catches-everything branch. feat(accounting): seed missing Income/Expense/Transfers-Suspense/Escheat-Liability accounts The Basoda-derived chart of accounts (0523) carried none of these - a balance sheet has no P&L heads, and Transfers Suspense/Escheat Liability aren't balance-sheet line items either - so a Savings Product's accounting mapping had nowhere to point those required fields. Same guard as 0523: only seeds a Basoda-derived tenant that hasn't already gotten it, never touches a tenant with its own chart of accounts. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-31 22:17:54 +05:30
niteshandClaude Sonnet 5	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