niteshandClaude Opus 5
c86e0d1cc2
Ticking "Close this account" previewed the payout with a dry run — assemble the account, call the same postInterest domain method close() will, roll the whole transaction back. The clerk asked for the actual thing: post the interest now, the same as "Post Interest As On" always did and the same basis FD uses at maturity, so the figure shown is the account's real balance rather than a simulation of one. Switched to calling SavingsAccountWritePlatformService#postInterest(SavingsAccount, boolean, LocalDate, boolean) directly -- the exact method close() itself calls -- instead of going through the ordinary POSTINTEREST command pipeline. That matters: POSTINTEREST_SAVINGSACCOUNT ships maker-checker-enabled in base Fineract, and a Clerk is not a checker for it. Routed through commandsSourceWritePlatformService, CommandSourceService#processCommand runs the handler first, then evaluates maker-checker and throws RollbackTransactionNotApprovedException -- which, thrown from inside that @Transactional method, rolls back everything the handler just did and drops the request into Fineract's own generic Checker Inbox. This feature already has its own maker-checker (submit here, approve in Closure Requests); the posting now rides inside that instead of opening a second, unrelated approval queue for the same click. Left uncommitted-to on purpose: unticking the box or a later rejection leaves the posting in place, since it is interest the member had genuinely earned either way. Re-ticking re-runs postInterest safely -- the domain layer finds today's posting already there and no-ops rather than posting twice. If manager approval lands on a later business date, close() tops up the extra days on top; it never re-posts what already matches the date it is closing on. Endpoint changed GET -> POST to match: it now mutates. The dry-run machinery (SavingsAccountAssembler kept, but PlatformTransactionManager/TransactionTemplate/ ConfigurationDomainService/MathContext all dropped) is gone with it -- the real service method already handles all of that internally, the same way it does for every other caller of postInterest. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>