- Cash Exchange Entry: customer details with PAN (mandatory above Rs 50,000), cashier card,
denomination-wise validation against the master and real-time impact preview.
- Inter-Cashier Transfer: sender fixed to the logged-in cashier, both sides' details and
denomination holdings shown, blocked until both are allocated cash.
- Reconciliation, exchange and inter-cashier operate on the logged-in cashier only.
- New Branch Cash Position screen (vault + cashier drawers, denomination-wise).
- Customer search dialog shows the KYC PAN.
- Cashier menu cleanup: Excess/Closing report and Exchange Detail removed, nav compacted to one row.
- Reverse actions removed from cash transfer, settlement, exchange and inter-cashier.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Brings the FD interest posting approval UI and the latest UI work into
dev-latest:
- FD interest posting approval screens, posting period and
GL-reconciled maturity interest
- FD maturity approval UI added and then reverted (maturity now runs
directly through the scheduler, no approval step)
- "mybank" tenant registered in the UI tenant list
- Animated boot splash and reusable loading screen
- Compact navigation with grouped mega menus and branded loaders
Conflict resolved:
- src/environments/.env.ts: kept dev-latest's generated version/hash;
the file is regenerated by `npm start` anyway.
Also: prettier formatting of toolbar.component.html (already
unformatted on dev-latest; formatting only, required by the
pre-commit hook).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Removes the FD Maturity Reports screen, its route and nav entry, and
the maturing-today section on Branch Day Closing — the backend report
and approval gate behind them are gone, and a matured deposit's final
interest already surfaces under FD Interest Posting Reports'
"Posted outside approval".
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Adds the FD Maturity Reports screen (due-without-report, generate/
approve, branch and head-office scope, detail with closure instruction
and estimated interest per deposit), a nav entry, the route, and
Branch Day Closing's maturing-today section and approval-pending
warning banner.
Adds "Matured automatically" to the maturity screen: deposits that
settled via their own Transfer-to-Savings or Reinvest instruction,
needing no approval, listed for visibility with product totals and
per-deposit detail.
Adds "Product summary" to the FD Interest Posting Reports screen
(head office): interest by product and scheme — posted through the
report, still pending, and posted directly at maturity instead — added
up to what each product has paid out in total over a period.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Adds the FD Interest Posting Reports screen (due-without-report,
generate/approve, branch and head-office scope, posting detail,
live preview, head-office summary), a nav entry under Reports, the
route, and Branch Day Closing's fixed-deposit-due section and
approval-pending warning banner that blocks closing the day.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The Clerk Dashboard's standalone Share Withdrawal Request form never offered a
GL settlement destination -- it always submitted SAVINGS, silently, while the
Cashier's Transaction Entry screen already let a clerk pick any postable GL
account on its CR row. Added the same "Settlement Destination" choice (Savings
/ GL Account) with a searchable GL selector here too, so both entry points to
the same backend endpoint behave the same way.
Both share-withdrawal confirm dialogs (savings settlement and GL settlement, in
transaction-entry.component.ts) now call the backend's new preview-validate
endpoint before showing the confirm dialog, so a clerk sees the same checklist
a manager will see on approval -- a missing GL mapping, an unverified KYC, an
open AML alert -- before committing to the request, not after a manager has
already spent time reviewing it. A failing check is shown, not blocked: real
hard rules are still enforced server-side at approve(). Guarded with a 5s
timeout and a fallback message so a slow or unavailable check can never leave
the dialog looking stuck.
error-handler.interceptor.ts: a document/signature attachment whose row
survives but whose file is missing from the content store now resolves to a
silent 404 (matching the existing image-fetch handling) instead of surfacing a
raw error. Background GET failures (500/501/503) on calls a component already
recovers from (photo, attachment, notes, standing instructions, ...) now
surface as a corner toast instead of a blocking modal that has to be dismissed
-- a write action's failure (POST/PUT/DELETE) still gets the centred,
must-acknowledge dialog, since that is the one thing the user was waiting on.
Also surfaces the backend's real message on a 500 instead of a hardcoded
generic sentence.
Backend counterpart: ClerkShareWithdrawalRequestApiResource (preview-validate
endpoint, shared buildShareWithdrawalChecks()) and
DocumentReadPlatformServiceImpl (missing-file 404) land separately.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
- Reports > Interest Posting Reports: per branch and product, generate/regenerate
at any time, approve; branch column, HO-on-behalf marker, posted txn per account
- Reports > Interest Posting Summary (branch-wise) for the head office, with Excel export
- Day Close warns and disables Close Day while the branch's interest report is unapproved
- Savings product accounting: Interest On Savings (expense), Savings Interest Payable
and Paid (liability rows, required)
- RBI Form 1 statutory and Form 9 return screens, reserve config updates
- Interest posting report GETs exempted from the response cache
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
- Manager withdrawal-review screen always searched the Savings account
type regardless of the request's actual account_type, so reviewing a
Current-account withdrawal failed with "Account not found". Reuse the
existing SEARCH_ACCOUNT_TYPE_TO_AC_TYP mapping (already used by the
cashier lookup path) instead of a hardcoded 'SD'.
- Point the UI tenant id at utkarshbank (was lincpay) to match the new
backend tenant.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
SYMPTOM
A cashier could credit an FD or RD account with cash from Transaction
Entry and the money moved in instantly, with no Manager approval -
unlike a Savings/Current deposit from the same screen, which correctly
creates a PENDING request under Approvals.
ROOT CAUSE
confirmSubmit()'s maker-checker branch for a cashier deposit only
matched row.acTyp in ('SD','CA','CB','GL'):
if (!this.isClerk && !this.reviewMode && isDeposit &&
(row.acTyp === 'SD' || row.acTyp === 'CA' || row.acTyp === 'CB' || row.acTyp === 'GL')) {
this.submitCashierDepositRequest(row, ...);
return;
}
'FD' and 'RD' are their own distinct account-type codes in this
component (see creditEntryAccountType(): 'FD' -> 'FIXED_DEPOSIT', 'RD'
-> 'RECURRING_DEPOSIT', separate from 'SD'/'CA'/'CB') and were simply
never in this list, so a deposit into either fell through every later
branch (all of which are withdrawal/disbursement-only) straight to the
generic, unguarded direct POST at the bottom of confirmSubmit().
Found by tracing why a real FD funding deposit never showed up under
Branch Ops -> Approvals: it had posted directly, no request record
ever existed for it, and it later showed up as an unexplained cash
"Excess" in the Branch Day Register close (the money was physically
counted by the cashier via denominationBreakdown in the same direct
POST, but the approved-requests-only "book" total never counted it -
see the paired backend commit for the matching approve()-side fix and
how that stale data artifact was cleaned up).
FIX
Added 'FD' and 'RD' to the account-type list in that gate, so a
cashier's FD/RD deposit now creates a PENDING
m_cashier_deposit_request via submitCashierDepositRequest() exactly
like SD/CA/CB/GL already did. buildDepositPayload() needed no changes
- it already resolves accountType via creditEntryAccountType() and
sets savingsAccountId to the FD/RD account's own id correctly; only
this one gate condition excluded them.
SCOPE
This one condition, in this one method. Every other account type's
existing deposit/withdrawal behavior on this screen is unchanged.
IF THIS BREAKS SOMETHING LATER
- A cashier FD/RD deposit posting instantly again (no PENDING request
created) -> check this gate's account-type list still includes
'FD'/'RD', and that isClerk/reviewMode aren't being set unexpectedly
for a cashier session.
- The backend rejecting or misrouting the resulting APPROVED request
-> see the paired fix in CashierDepositRequestApiResource
(cbsnexora-backend), resolveDepositAccountCategory() /
executeFixedDepositDeposit() / executeRecurringDepositDeposit().
- A "Vault + Cashiers" vs "book" Excess reappearing in Branch Day
Register close for a specific FD/RD deposit -> that combination
(physically counted denomination with no approved request) should be
impossible with this fix in place; if it recurs, this fix (or its
backend half) has regressed.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Apply Collection and Apply Additional Shares settle the same Share Collection
receipts for the same member, so they are now deliberately the same screen.
Apply Collection takes exactly two receipts and no more: one for the share value,
one for the entry fee, in two separate slots. They are different things -- the
share receipt is money moving into share capital, while the fee receipt only
proves the fee was already collected and is never posted a second time -- and
picking both out of one ticked list made that distinction invisible.
Apply Additional Shares moves from its own route to a dialog. It was a full page
a clerk had to leave the account for and come back from, to fill in a short form
with the member standing at the counter. Its old route, resolver case and action-
host branch are removed rather than left behind as dead paths.
Both screens now draw their receipts from a single pool, whether a receipt
already names the member or is a voucher paid straight into a GL account; an
unattributed one is attached at the moment it is picked, so what used to be an
Attach in one table and a tick in another is one deliberate click. The by-voucher
search and the GL-entry detail both sit behind buttons, as exceptions rather than
permanent furniture.
Dialog chrome and the receipt shape are shared (share-dialog.shared.scss,
share-receipt-option.ts) so the two cannot drift apart again.
Also fixes content being clipped at the dialog edges: the wrapper cancelled a
24px surface padding that the panel class had already zeroed, pushing every edge
outside the surface where overflow:hidden cut it off, and the height cap sat on
the scrolling body rather than the wrapper, letting the footer stack past the
bottom of the viewport.
Adds the product-wise share summary report (authorised, issued, available and
unpaid shares, distinctive range and account count per product).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
- Add the full Share Reports surface (final balance, account statement,
issued/status/nominal/share-wise/guarantor/member-interest reports, enquiry,
payment certificate, share detail, dividend statement, folio statement,
distinctive numbers, area-wise, mailing labels/letters, share transfer) as
standalone routed components, wired into the Share menu
- Wire the unattributed Share Collection receipt list into Apply Collection
and Apply Additional Shares, with an Attach action independent of
account/client
- Sync the GL Account and Voucher No fields to whichever receipt is ticked or
found, and surface the receipt's real Dr/Cr GL entries in its detail popup
- Block Apply Additional Shares until the account's original application is
settled
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Adds an Entry Type field to Transaction Entry's GL-crediting rows (Receipt / Collection),
fetched from the backend's GLEntryType code, so the counter can flag what a GL credit is
actually for (General / Share Collection / DD Issue) instead of leaving every GL account
picker throughout Share Advance Collection guessing from the whole chart of accounts.
Apply Share / Additional Share screens:
- GL Account picker narrowed to accounts that actually have an eligible receipt, and only
auto-selected when exactly one candidate exists -- no more defaulting to whichever account
sorts first (Cash at Vault).
- Voucher tables show Description and Collected By, and a Detail view exposes the receipt's
real Dr/Cr GL legs instead of the GL Account dropdown's current unrelated selection.
- Additional Share funds from a single voucher (radio-style selection); ticking a receipt
syncs the GL Account picker to its own actual account.
- Checker's Additional Share Request review dialog gets the same Description + real GL entry
detail, expandable per voucher, so approval is never a guess about what will post.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Share Products:
- "Share Reference (Cash Vault or Suspense)" removed from the accounting step (create, edit,
preview and the read-only view tab) -- every register now books a share transaction against the
account the money actually reached, so no product needs a placeholder asset mapping any more.
The field is now optional server-side, not required.
Cashier:
- Removed the Share Collection screen and its three service methods. It read
m_share_account.cashier_collected, a column that has never existed in this schema, and no other
screen ever called it -- it could not have produced a working entry.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Transaction Entry (clerk):
- Route a two-row Fund Transfer of Dr SHR / Cr GL to the share-withdrawal
request with settlementMode GL, so a clerk can settle a share withdrawal
into any GL account instead of the member's linked savings account.
- Offer GL as an account type for Demand Draft funding, and submit it as a
GL debit (no client or savings/current account is involved).
My Work:
- Add a voucher detail dialog so a clerk can open a raised voucher from the
request list and see its GL lines.
Closing Cash Report:
- Fix the total row so it reflects the corrected opening balance.
DD Leaflet Registry and DD Inventory:
- Redesign both pages onto the shared usr-* visual language: gradient header
badge, status filter chips with counts, card-wrapped sticky-header table,
and one primary action per row with the rest behind an overflow menu.
Filtering, pagination and every action condition are unchanged.
- Register faHandPaper, needed by the new Stop Payment menu item.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
- Transaction Entry's manual GL-entry screen was recording its denomination
breakdown against whichever GL account the teller selected, not the vault
account whose physical notes actually moved -- resolve and use the Cash
Vault GL's own code/name dynamically instead
- Closing Cash Report's GL Entries table showed only the one account its
denomination row knew about; now shows both the debit and credit account
of each voucher (backend now returns debitParty/creditParty), matching
what My Vouchers already shows for the same entries
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- Add Balance Sheet report and disabled-features accounting config
- Point menu-access tenant header and env.js/environment.ts tenant identifier
at env config instead of hardcoded 'default'/'lincpay' literals
- Surface the real backend error (not a generic "no reference id") when an
OTP send fails in contact-otp-block
- Fix branch-day "₹null" display bug (null vs undefined) and add a guard
blocking a branch's first-ever day open before cash denomination migration
- Dynamically size the denomination count input and block re-opening an
already-open business day from Migrate Cash Denomination
- Lock the denomination-managed cash GL row in Migrate Opening Balances
(read-only, with a link back to Migrate Cash Denomination)
- Remove duplicate Cancel/Submit action bars on the Share Product and
Savings Account creation preview steps; align Previous into the same row
- Hide "Apply Collection" on a share account once its advance collection
is already settled (further purchases go through Apply Additional Shares)
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
my-work.component (My Vouchers):
- The five summary tiles (Received/Payments/Journal/Entered/Approved) were
bound directly to the server's day-total fields, so they stayed fixed at
the combined "entered + approved" figure no matter what the Side/My part
dropdowns were set to. They're now pinned to this user's own entered rows
only (enteredRows), independent of both filters, so "how much did I
personally put through today" reads correctly regardless of what the table
below happens to be filtered to. The table and its dropdowns are unchanged
and still default to showing everything.
transaction-entry.component (Fund Transfer):
- onSave()'s plain bank-transfer branch (SD/CA/CB only) was catching every
'Fund Transfer' row before the GL-aware Disbursement/Collection branch
below it could see them, so a Fund Transfer against a GL account was always
rejected with "Invalid Account Type" even though that branch already
supports it under the same label. Fund Transfer rows that include a GL leg
now skip the plain-transfer branch and fall through correctly.
my-disbursement-requests.component (Disbursements & Transfer list):
- getCreditEntries() only read the stored credit_entries JSON, which holds
the full picture for Collection (its GL leg is one of the entries) but not
for Disbursement/Fund Transfer, whose GL is the request's own top-level
source (gl_account_no/dr_amount) and was never in that array. The DR/CR
breakdown for those two types showed only the credit side, looking like
half the entry was missing. The GL leg is now synthesised back in as the
first row for those two types, matching what actually posted.
- Renamed the clerk's "My Disbursements" / "My Disbursement Requests" screen
to "Disbursements & Transfer" throughout (nav tab, dropdown menu, route
title/breadcrumb, cashier counter link, page header) — the register covers
Disbursement, Collection, Fund Transfer and Bank Transfer requests, and the
old name read as disbursement-only. "My Requests" (Withdrawal Slip
requests, a separate register) is renamed to "Withdrawal Request" for the
same reason: neither name said what was actually inside.
Ticking "Close this account" on the Transaction Entry Action popup called
GET /clerk/closure-requests/preview/{id} -- a dry run that computed the
payout and immediately rolled it back, so the account's own balance stayed
unchanged until a manager later approved the closure.
Wired to the new POST /clerk/closure-requests/post-interest/{id} instead
(see the matching backend commit), which posts the interest for real and
returns the account's actual resulting balance. Renamed
ClerkClosureRequestService#preview to #postClosureInterest to match, and
reworded the popup copy and loading state so it no longer implies posting
happens later at Save ("posted to the account as of ..." instead of
"calculated to ... and posted the moment you press Save").
Also corrected a stale comment on the balance-check bypass for a pending
closure: it used to justify the bypass by saying interest was NOT YET
posted, which stopped being true the moment the checkbox itself started
posting it for real.
The whole DD-against-cash path was already written and reachable only by a
cashier -- isDdCashGlRow() gates on a cash payment type against a GL account,
onSave() makes the cashier count Face Value + Charges + GST exactly and
enforces the admin DD limit at intake, and buildDepositPayload() persists that
breakdown so the Sponsor DD issuance screen reads it back after approval. None
of it could be selected, because DD was missing from cashierTypOptions.
Also adds the DD case to onTypChange, without which selecting DD set no
defaults at all: it needs Cr (a draft is bought with cash, so money comes in),
a cash payment type, and AC.TP = GL, which are the three things isDdCashGlRow()
looks for. Missing any of them, the DD Charges & GST panel never appears and
the row posts as an ordinary entry with the charges silently dropped.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Replaces the one-click Close action on the savings account page (removed from
the Danger Zone menu) with a maker-checker flow, since closing an account pays
real cash out of a teller's drawer.
Clerk: an Action button on Transaction Entry, shown once an ACTIVE savings
account is loaded. Ticking "Close this account" previews the payout -- balance
plus interest calculated to today by the same code the closure itself runs --
and Save drops that figure into the slip's AMOUNT. The clerk then fills
TOK. NO. on the slip and presses Save, which raises the request. Token and
narration deliberately live on the slip, not in the popup, so the closure is
entered like any other transaction.
Manager: a Closure Requests tab in the Approval Center, reviewed in a popup
dialog (matching Disbursement Requests) rather than a separate route.
Cashier: the closure token is recognised at the counter alongside withdrawal
and dividend tokens, auto-filling the rounded cash figure, locking it, and
closing the account once the denomination is counted.
Save-path fixes, all of which silently blocked a valid closure:
- amount came from the denomination total whenever clerkMode was false --
which it is for any route other than the Clerk Dashboard wrapper -- so the
calculated payout was replaced by zero
- the balance check rejected the payout because it legitimately exceeds
today's withdrawable amount: it includes interest close() posts before
withdrawing. Min-balance, withdrawal-facility and clerk-side denomination
checks do not apply to a closure either
- on the cashier side the account is already CLOSED, so accountDetails is a
stub with no balance and the same check reported "Withdrawable 0.00"
- the closure branch had to precede the plain clerk-withdrawal branch: a
closure is a full-balance withdrawal, so that branch would have swallowed
it and the account would never have closed
- onSave's one silent return now says what is missing, instead of leaving
Save looking like a broken button
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
- Register the missing edit-details route so the Share Account "Edit Details"
maker-checker screen (already built) is actually reachable, and remove the
stale hardcoded disable on its menu entry.
- Fix Terms step race: Default Savings Account, Total Shares and Application
Date now display correctly in edit mode instead of racing an async
product-template fetch or reusing pending-application-only fields.
- Show a client's linked share account number on the Savings Account General
tab.
- Replace the inline diff panel on Pending Share Account Edits with a popup
compare dialog (mirrors the savings equivalent), showing only fields that
actually changed.
- Redesign Pending Share/Savings Account Edits, Share Withdrawal Requests,
Dividend Requests and Share Addition Requests with a consistent header,
search box and (where the data supports it) date-range filters, matching
the existing Withdrawal Requests screen.
- Savings account creation shows a required "Default Share Account" picker once Share Linking is
enabled, populated from the client's active share accounts; submits shareAccountId alongside it.
- Fixes a real data-loss bug on Share Account creation: the Charges step re-seeded its table from
the product's default charges on every ngOnChanges firing (e.g. stepping back to Details and
forward again), silently discarding a charge the clerk had already added, edited, or removed - a
pristine guard existed for exactly this but wasn't checked in ngOnChanges. Now it is.
- Removes the hard "required" on Share Account creation's Default Savings Account field, matching
the backend now accepting a share account with no linked savings account.
- New /accounting/migrate-cash-denomination screen: counts a branch's opening cash into notes and
coins, checks it against (or defines, if unset) the Cash GL account's balance, and opens the
branch's first business day with that same count - the vault-side counterpart to Migrate Opening
Balances, kept under Accounting rather than Branch Ops/Cashier so it isn't reachable by mistake.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
'Fund Transfer' and 'Enter Bank Transfer' are the same flow under two TYPE labels -- onTypChange()
already defaults them identically and the auto-mirror-row logic already treats them as equivalent --
but the Resolution No./Meeting Date fields and onSave()'s clerk-transfer submission gate only checked
'Enter Bank Transfer'. Picking 'Fund Transfer' for a Share row silently hid the board-resolution
fields and skipped submitShareRedemptionTransfer() entirely, falling through to the wrong save path.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- Add Approval Center tab "Share Addition Requests": lists every pending additional-share tranche
across all accounts (backed by the new /v1/shareadditionrequests endpoint), with a detail popup
showing the board resolution and the route-specific proof of funding (voucher(s) for cash, or the
linked savings account for savings). Approve/Reject call the same native
approveadditionalshares/rejectadditionalshares commands the account-page buttons already used.
- Remove "Debit from Savings" dialog/button and the "Share Savings Debit" Checker Inbox tab -- zero
rows ever recorded on either tenant since it was built.
- Remove "Approve Additional Shares"/"Reject Additional Shares" from the account-page menu now that
every tranche is reviewed from the centralized queue instead.
- Harden SharesButtonsConfiguration.removeButton(): a not-found name fed to splice(-1, 1) was quietly
deleting the LAST button in the array instead of doing nothing -- removing the two menu entries
above would otherwise have silently broken the rest of the Active-account button bar.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- Apply Collection dialog: replace product-config auto-resolved GL account with a required GL +
voucher search (mirrored for Share and Entry Fee receipts). The entry-fee receipt is tracked
separately from the share receipts and sent as its own field so its amount is never swept into the
Sundry-side total or double-posted — it only verifies the fee was paid, since that money already
sits wherever the cashier deposited it.
- Shows the account's required total (share value + entry fee) and live coverage up front, instead of
only after a failed apply.
- Apply Additional Shares: same mandatory GL + voucher pattern for its by-voucher lookup, plus a GL
account picker fed by the new /shareadvancecollection/glaccounts endpoint.
- shares-account-charges-step: fixed a race where the currency-control subscription (meant only for
the edit-an-existing-application flow) wiped out product charges that ngOnChanges had just seeded
from the same product-selection event, leaving new accounts with no charges.
- shares-account-view: hide "Share Certificate" until collection_applied is true, so a certificate
can't be printed for shares nobody has actually paid for yet.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Account Statement is no longer a jsPDF file that downloads the moment the
dialog opens. It now shows a live, on-screen preview styled the same way
the working Passbook screen already is (bank header, branch line,
account-details band, balance strip, transaction table), with its own
date-range filter, and only prints via the browser's print dialog on an
explicit click -- exactly the same clone-into-a-popup-window mechanism
Passbook already uses, so "Save as PDF" is the reader's own choice rather
than something forced on open.
Both Passbook and the new Statement preview pull the bank name, license
number, and branch name/address/IFSC/MICR from Institution Profile and
Branch Profile instead of a hardcoded bank name -- a printed passbook or
statement now actually identifies which bank and branch issued it. Cheque
Book's own issuance detail screen gets a matching "Print" action, laying
out a one-page issuance-slip PDF from data already on that screen (which
book/series, leaf range, issued-to account, issue date).
Cash Hold and Clearing Hold on the Transaction Entry balance strip were
both hardcoded 0.00 placeholders; they now read the account's real
hold-category breakdown, and a stray "Freeze Amount" placeholder a few
rows up is wired to the working getter that was already sitting right
next to it.
A clerk withdrawal's own terminal status is WITHDRAWN, not APPROVED --
the Day Book screen had the same status-string gap the backend GL report
did: neither its running CR/DR totals nor its status badge recognized a
completed withdrawal, so real money that had gone out never moved the
totals off zero. The Closing Cash Report's GL Entries panel also never
refreshed for a newly picked date once it had already been opened once --
"Load" hid the panel instead of refreshing it, leaving a stale, wrong-date
table under a header that had already relabelled itself correctly.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The Day Open form's note/coin table started at zero even though the
branch's own closing count from the day before was already on record --
whoever opened the day had to re-key numbers that were already known.
It now auto-fills from that closing count, flags any row a manual edit
moves away from it, and shows a live Tallied/Short/Excess comparison
against it -- so a short or excess opening count is visible before the
day is opened, not discovered later. A reason is required once a mismatch
exists, matching the new backend enforcement.
Also fixes the register table's date chip wrapping onto two lines when
the column narrows.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Branch Day open/close now captures a denomination-wise count (carried
forward automatically to the next day), and shows an auto-fetched EOD
summary at close time -- vault + every cashier's position, a branch-total
reconciliation against the book figure, and each cashier's
reconciliation/settlement status and transaction count -- so closing the day
no longer means separately checking Vault Position and every cashier's own
screen by hand. New Vault Position screen (branch-ops menu) mirrors Cashier
Position for the teller/vault. Cash Transfer now shows the vault's live
per-denomination availability while counting a handout, with a client-side
warning before it can be over-counted.
New Organization screens for Bank Profile, Branch Profile and Clearing GL
Configuration, wired into the Organization landing page and the
previously-dead "Bank Profile" admin menu button.
Cashier Transaction Entry: TYPE is now Receipt/Payment only (cash-only TXN
TP.) on the cashier side, with no change to the clerk dashboard's own
Withdrawal Slip/Cheque/Disbursement/Enter Bank Transfer/DD flow beyond
adding a new Fund Transfer type alongside Disbursement for a GL credit that
isn't a loan payout. Neither TYPE nor TXN TP. offers a blank placeholder
option anymore -- a new row starts on a real default instead. Footer no
longer polls the business-date config for cashier/clerk roles, who never
have permission to read it.
Disbursement & Transfer Requests: "Review" now opens the review screen as a
popup instead of navigating to a separate route, refreshing the list on
close; the review screen recognises the new Fund Transfer request type
too, and its non-functional "+ Disbursement Review" tab-styled label is now
a plain heading.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Adds a Products > Facility Charge Mappings screen so each of the 16 facility
toggles can be pointed at a real charge, backing the mapped-charge validation
added on the backend. Bulk-approve on the pending accounts screen now chains
straight into activation (matching the single-account approve flow) instead
of leaving accounts sitting in Approved; the same screen's Confirm button no
longer stays disabled on pre-filled but untouched dialogs. Add Charge is
hidden on not-yet-active savings accounts, and Transfer Funds is disabled
entirely pending a proper transfer flow. The pending savings-account edit
"Proposed Changes" panel is now a MatDialog showing only the fields that
actually changed, replacing the old always-open inline diff table. The teller
transaction-entry Payment Type dropdown is filtered to Cash/Transfer only,
mirroring the backend's retirement of the other system-defined payment types
so share withdrawal and GL transfers now settle the same way real transfers
do.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Four independent, self-contained changes bundled from this session's work:
1. Auto-derive Senior Citizen / Minor / Customer Segment instead of manual entry
Senior Citizen was a manual, staff-editable checkbox on FD/RD account
creation with no validation against the client's actual age -- this let
non-senior clients get the senior-citizen interest rate by mistake (found
twice on live test accounts, where m_savings_account.is_senior_citizen
was true despite the client being confirmed non-senior at the client
record level). Likewise "minor" client classification was hardcoded to
the age-18 threshold with no single source of truth, and FD/RD account
creation's "Customer Segment" (Individual / Non-Individual) had no
connection to the Individual/Non-Individual Legal Form already captured
at client creation.
- New src/app/clients/shared/client-age.util.ts centralises age/DOB
derivation: MINOR_AGE_THRESHOLD (now 10, was 18), SENIOR_CITIZEN_AGE_
THRESHOLD (60), AGE_OF_MAJORITY (18, kept separate from the minor
threshold -- majority date math is unrelated to the minor/adult
classification threshold), calculateAge/isMinorAge/isSeniorCitizenAge/
isIndividualClient/deriveSeniorCitizenStatus.
- FD/RD interest-rate-chart steps: Senior Citizen checkbox is now derived
from the client's DOB (age >= 60, individual clients only) and
disabled for manual editing; a hint explains why it is checked/
unchecked.
- Client general step and all four account-details-steps (savings,
current, FD, RD): replaced hardcoded 18/60 literals with the shared
helpers; "Must be below 18" hints now read the actual threshold.
- FD/RD account-details-steps: Customer Segment auto-selects to match
the client's Legal Form (exact match, not substring -- a substring
match would misclassify "Individual" as matching "Non-Individual").
- RD preview step: fixed a pre-existing display bug that always showed
the product's default Customer Segment instead of what was actually
selected on the account.
2. Fix wrong Account Name / Account Type on Disbursement Review screens
Clerk disbursement review and "My Disbursement Requests" showed the
account NUMBER instead of the holder's name, and always labelled the
account type "SAVINGS" regardless of the real account type (FD/RD/
Share/Loan), because transaction-entry.component.ts's account-type
mapping only checked for CA/CB and its account-name fallback chain
never tried clientName. Added creditEntryAccountType() covering
GL/CA/CB/FD/RD/SHR/LA, and accountTypeLabel() display helpers on both
review screens.
3. Stop reversed transactions from distorting displayed running balances
Passbook and Transactions tabs were including reversed transactions in
their client-side running-balance recalculation, so a reversed posting
(visible struck-through) still shifted the balance shown for every
transaction after it. Both now filter out txn.reversed before computing
running balances; Transactions tab also defaults "Hide Reversed" to on.
4. New Interest Schedule dialog on the FD account view
Added custom-dialogs/interest-schedule-dialog, opened from the FD
General tab, showing the account's period-by-period interest schedule.
Excludes src/environments/.env.ts (auto-generated build version/hash
stamp, regenerated on every build -- not meaningful to hand-commit).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Cash claims now require a token at claim submission; a cashier redeems
it at Transaction Entry to record physical hand-over, mirroring the
existing clerk-withdrawal-request flow -- no double-disbursement, and
the manager never hands over cash directly at approval time.
Also: dividend-claim tokens fall back through the same TOK. NO. lookup
used for withdrawal requests, silenced against the global error
interceptor since the caller already handles every outcome; the account
summary card now shows "Dividend Claim" instead of a misleading "A/c
Savings" label when resolving one; and cash amounts are floored to
whole rupees client-side to match cash's whole-rupee denominations.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Frontend counterpart to the backend dividend rework:
- Create Dividend screen auto-computes the amount from real bank profit x officer
percentage, blocks overlapping declaration periods, and adds a Total Dividend Paid
summary card.
- View Dividend page modernized and reusable as an embedded popup from the new
cross-product "Dividend Requests" approval-center tab.
- New consolidated Dividend Dashboard: summary stats, every declaration and its
status, locked-dividend-vs-overdue-EMI matching with a proactive apply-to-loan
action, full 3-year lock history, and a maker-checker claim panel letting a clerk
split a member's unclaimed dividend across an overdue loan, savings credit, or
cash for a manager to approve.
- Menu/routing consolidated under Share > Dividend Management; removed the
now-unreachable Failed Dividend Payouts page and its home-dashboard alert once the
backend stopped needing a retry path for stuck payouts.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Replaces the auto-submit-closure-request behavior with an immediate
account close, in the same approval action, when a withdrawal brings
shares to zero — matching the backend's new single-step close-on-
approval flow. Removes the now-unneeded Share Closure Request feature
entirely: dedicated create/list components (Clerk Dashboard + Approval
Center), routes, nav links, and the "eligible for closure" banner on
the Share Account view.
Also adds a clear "this will close the account" notice wherever a
withdrawal would zero out the account's shares — the standalone Share
Withdrawal Request page (submit + review) and Transaction Entry's
Share Redemption Transfer confirm dialog — styled as an amber warning
callout rather than a plain info line. Trims that confirm dialog to
just the required details (dropped the redundant ECS A/C No. line and
the validation-checklist block) and compacts its overall size.
This entire feature — submitting a governed Share Withdrawal Request
directly from a Bank Transfer's DR(Share)/CR(linked savings) row pair
— was silently dropped from demo-backup during the dev merge's auto-
resolve, even though the feature files it depends on (clerk-share-
withdrawal.service.ts) were present. Restores: paymentTypesForRow()
(hides cash payment types for Share rows and their settlement CR
row), the SHARE NO./RESOLUTION NO./MEETING DATE fields (replacing
AMOUNT/CHEQUE NO./CHEQ. DATE for Share rows), rowSharePrices/
rowClientIds/rowLinkedSavingsAcNo tracking, submitShareRedemptionTransfer()
+ its confirm/submit flow, syncShareLinkedAmounts() auto-fill, the
Share-aware ecsAcNo/currentBalance logic, the Other Information panel's
Share-specific fields (No. of Shares Held, Market Price/Share,
Resolution No., Linked Savings A/C No.), and the SHR guard blocking
the generic Deposit/Withdrawal Slip flow for Share accounts.
Share accounts have no /accounts/share/{id}/transactions REST
sub-resource (transactions come embedded via ?associations=all) and
Share isn't a valid standing-instruction source account type on the
backend — hitting either endpoint 404s / errors. Restores the
txnFetchUnsupported/siFetchUnsupported config flags (present on dev,
lost in the earlier dev-merge's silent auto-resolve) that skip both
calls for Share, fixing the 404 seen when opening a Share account in
Transaction Entry.
anshul
niteshandClaude Sonnet 5.5
keshav