niteshandClaude Sonnet 5
dc0539d53d
- 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>