Fineract E2E Tests / E2E Tests (Shard 9 of 10) (push) Canceled after 0s
Fineract Cargo & Unit- & Integration tests - PostgreSQL / test (test-core-1) (push) Canceled after 0s
Fineract Cargo & Unit- & Integration tests - MariaDB / test (test-core-3) (push) Canceled after 0s
Fineract Cargo & Unit- & Integration tests - MariaDB / test (test-core-4) (push) Canceled after 0s
Fineract Cargo & Unit- & Integration tests - MariaDB / test (test-core-5) (push) Canceled after 0s
Fineract Cargo & Unit- & Integration tests - MySQL / test (test-core-1) (push) Canceled after 0s
Fineract Cargo & Unit- & Integration tests - MySQL / test (test-core-3) (push) Canceled after 0s
Fineract Cargo & Unit- & Integration tests - MySQL / test (test-core-5) (push) Canceled after 0s
Fineract Cargo & Unit- & Integration tests - PostgreSQL / test (test-core-2) (push) Canceled after 0s
Fineract Cargo & Unit- & Integration tests - PostgreSQL / test (test-core-3) (push) Canceled after 0s
Fineract Cargo & Unit- & Integration tests - MariaDB / test (test-core-1) (push) Canceled after 0s
Fineract Build & Cucumber tests (without E2E tests) / verify (main, build-core) (push) Canceled after 0s
Fineract Build & Cucumber tests (without E2E tests) / verify (main, cucumber) (push) Canceled after 0s
Fineract Docker Builds / build (false, docker-compose-postgresql.yml, postgresql) (push) Canceled after 0s
Fineract Docker Builds / build (true, docker-compose.yml, mariadb) (push) Canceled after 0s
Fineract E2E Tests / E2E Tests (Shard 8 of 10) (push) Canceled after 0s
Fineract Cargo & Unit- & Integration tests - MySQL / test (test-core-2) (push) Canceled after 0s
Fineract Cargo & Unit- & Integration tests - MySQL / test (test-core-4) (push) Canceled after 0s
Fineract Cargo & Unit- & Integration tests - PostgreSQL / test (test-core-4) (push) Canceled after 0s
Fineract Cargo & Unit- & Integration tests - PostgreSQL / test (test-core-5) (push) Canceled after 0s
Fineract Build & Cucumber tests (without E2E tests) / verify (progressive-loan, build-progressive-loan) (push) Canceled after 0s
Fineract Cargo & Unit- & Integration tests - MariaDB / test (test-core-2) (push) Canceled after 0s
Fineract Documentation build / build (push) Canceled after 0s
Fineract E2E Tests / E2E Tests (Shard 1 of 10) (push) Canceled after 0s
Fineract E2E Tests / E2E Tests (Shard 10 of 10) (push) Canceled after 0s
Fineract E2E Tests / E2E Tests (Shard 2 of 10) (push) Canceled after 0s
Fineract E2E Tests / E2E Tests (Shard 3 of 10) (push) Canceled after 0s
Fineract E2E Tests / E2E Tests (Shard 4 of 10) (push) Canceled after 0s
Fineract E2E Tests / E2E Tests (Shard 5 of 10) (push) Canceled after 0s
Fineract E2E Tests / E2E Tests (Shard 6 of 10) (push) Canceled after 0s
Fineract E2E Tests / E2E Tests (Shard 7 of 10) (push) Canceled after 0s
Fineract Liquibase Only mode - PostgreSQL / test (push) Canceled after 0s
Fineract Messaging Smoke Tests / Smoke Test with ActiveMQ (push) Canceled after 0s
Fineract Messaging Smoke Tests / Smoke Test with Kafka (push) Canceled after 0s
WHAT THIS CHANGES
==================
Three related FD (Fixed Deposit) features, built incrementally in one session:
1. IN-PLACE RENEWAL -- when an FD matures with "Re-Invest Principal and
Interest", the SAME m_savings_account row is now reused across every
renewal (account number never changes) instead of closing the account
and opening a new one. FixedDepositAccount.renewInPlace() does this by
setting start_interest_calculation_date as a pivot: interest for terms
before the pivot is never recalculated, only the new term's window is
computed from there. A new one-to-many audit table m_fd_renewal_history
records one row per term (renewal_no 0,1,2...) with that term's own
principal, rate, dates, interest earned, maturity, and status. A
companion table m_fd_renewal_chart_slab_history archives each closing
term's full rate-by-tenure chart, captured just before renewInPlace
overwrites it.
2. SENIOR-CITIZEN RATE -- the CBS Base Interest Rate master
(m_cbs_base_interest_rate_slab_history) was the only place that ever
stored a senior-citizen premium. It is now also persisted on
m_savings_account_interest_rate_slab (new senior_citizen_rate column,
nullable, added only to this account-level table -- NOT to the shared
InterestRateChartSlabFields embeddable, so the product-level table
m_interest_rate_slab is untouched). Applied both at account creation
(DepositAccountAssembler now prices a new FD off the active CBS base
version when one exists for that FD type, falling back to the
product's own chart otherwise) and at renewal (renewInPlace refreshes
the chart from the same base version).
3. PAYMENT ACTION -- a new manual command, POST
/fixeddepositaccounts/{id}?command=payment, available whether the FD
is ACTIVE or MATURED, unlike Close (Matured-only) and Premature Close
(Active-only, no reinvest). Offers: Transfer to Savings, Re-Invest
Principal and Interest (via renewInPlace), Re-Invest Principal Only
(legacy close-and-reopen, now also transfers the leftover interest to
a chosen savings account instead of stranding it), and a new closure
type PARTIAL_REINVEST (500) -- part of the matured balance renews in
place on the same account, the remainder transfers to a savings
account picked at request time. Withdraw Deposit is deliberately
excluded from this command. New permission PAYMENT_FIXEDDEPOSITACCOUNT
plus its CHECKER twin were added in migration 0478.
KEY FILES
=========
- DepositAccountDomainServiceJpa.java: handleFDAccountPayment (new),
renewInPlace call sites, recordInPlaceRenewal, senior-citizen rate
matching with unit conversion across days/weeks and months/years
families.
- FixedDepositAccount.java: renewInPlace, validateRenewalDate,
isLockedOnDate, fdAccountNumber/renewalCycleNo chain tracking.
- SavingsAccount.java (SHARED with Savings and RD): added
findLastTransactionBefore -- the interest-posting opening balance for a
pivot-dated account now seeds from the last transaction strictly before
the pivot, not the one on it. This fixes a bug where a renewed term
could accrue zero interest, or double-subtract a same-day withdrawal,
depending on transaction list order. Also widened
calculateDateAccountIsLockedUntil to protected so renewInPlace can
refresh lock-in on each renewed term.
- DepositAccountTransactionDataValidator.java: new validatePayment.
validateClosing now explicitly rejects PARTIAL_REINVEST (500) so it can
never reach the Close or Premature-Close handlers, which have no branch
for it and would otherwise pay the whole balance out in cash. This
applies to both FD and RD, since they share validateClosing.
- DepositAccountReadPlatformServiceImpl.java: retrieveOneWithClosureTemplate
(Close and Premature Close, excludes PARTIAL_REINVEST) split from the
new retrieveOneWithPaymentTemplate (Payment, includes it), sharing one
private method with a flag. The renewal-history fallback query, for
chains that predate m_fd_renewal_history, was rewritten to emit the
exact same column shape as the primary query.
- New: FixedDepositRenewalHistory plus its repository,
FixedDepositRenewalChartSlabHistory plus its repository,
PaymentFixedDepositAccountCommandHandler.
- Migrations 0471 through 0478 under tenant/parts, each registered once
in changelog-tenant.xml.
RD AND SAVINGS IMPACT -- READ THIS IF SOMETHING BREAKS THERE
============================================================
RD and plain Savings share several of the touched files. Verified during
this work:
- handleRDAccountClosure and RecurringDepositAccount.java were not
modified.
- PARTIAL_REINVEST (500) is now rejected by validateClosing for both FD
and RD close and prematureClose commands, and excluded from their
template option lists. This was a real regression caught mid-session:
the enum value briefly leaked into RD's Close dropdown as a working
looking option that actually paid the whole RD balance out in cash.
It was found and fixed before this commit.
- The SavingsAccount.calculateInterestUsing opening-balance change only
affects accounts where start_interest_calculation_date differs from
activatedon_date. On the dev DB this was exactly two accounts, both
FD test accounts created this session. Before deploying, run:
SELECT deposit_type_enum, COUNT(*) FROM m_savings_account
WHERE start_interest_calculation_date IS NOT NULL
AND start_interest_calculation_date <> activatedon_date
GROUP BY deposit_type_enum;
Any non-FD rows (100 or 300) there mean a Savings or RD account will
get a different, corrected interest amount than before. This is
expected to be rare or zero, but confirm before deploy.
- DepositAccountAssembler's creation-time base-rate pricing is guarded
by depositAccountType.isFixedDeposit, so RD account creation is
unaffected.
- is_active on InterestRateChart (migration 0474) is read only by
FixedDepositProduct.activeChart, which only FD's renewInPlace and
reInvest call. RD's applicableChart path is untouched. Migration 0474
also retires (is_active = false) any chart whose end_date is already
past. On the dev DB this retired zero rows; check on the target DB
before deploy, since there is currently no API to reactivate a
retired chart.
KNOWN CAVEATS -- NOT YET DONE, FLAGGING RATHER THAN HIDING
============================================================
- Migrations 0471 through 0477, the DDL ones, have never actually
executed via Liquibase. They were mirrored by hand directly into the
dev DB (ADD COLUMN IF NOT EXISTS, CREATE TABLE IF NOT EXISTS) so
testing could proceed without a full rebuild each time. Liquibase
will mark them MARK_RAN via preConditions on the dev DB's next real
run, but their first genuine execution will be on whatever
environment does not already have these columns and tables, such as
a fresh QA or production database. Test a migration-from-scratch run
before relying on this in production.
- This code has not been compiled. Every new or changed method
signature, import, and call site was manually cross-checked with
grep against real declarations, but that is not a substitute for
gradle actually compiling it. Run a full build before deploying and
treat any compiler error as expected until confirmed clean.
- DepositAccountAssembler pricing every new FD off the active CBS base
rate master, instead of the product's own chart, whenever one exists
is a real behaviour change affecting all new FD accounts of a type
that has a base-rate version, not just senior-citizen ones. Flagging
this for explicit product sign-off, not assuming it in this commit.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>