Aman-Mittal opened a new issue, #772:
URL: https://github.com/apache/fineract-backoffice-ui/issues/772
## Summary
The UI cannot record a loss on a Working Capital loan, and cannot record
recoveries on such a loan once it is written off. Fineract supports the whole
charge-off / write-off / recovery cycle for these loans.
## Evidence (`main` @ `8da1086f`)
- `wc-loan-action-form.component.ts` has no `chargeOff`, `undoChargeOff`,
`writeOff`, `undoWriteOff` or `recoveryPayment` branch.
- `wc-loan-view.component.ts` offers no such menu items.
## Platform support
`POST /v1/working-capital-loans/{loanId}/transactions?command=…`, with `GET
…/transactions/template?command=…` for defaults and reason codes:
| Command | Notes |
|---|---|
| `chargeOff` | takes a charge-off reason (code value); posts to the
product's charge-off GL mapping |
| `undoChargeOff` | reverses the latest charge-off |
| `writeOff` | takes a write-off reason; closes the loan as written off |
| `undoWriteOff` | allowed only while no recovery has been posted |
| `recoveryPayment` | records money recovered after a write-off |
## Proposed implementation
- Add the five actions to the loan's action menu, routed to
`wc-loan-action-form` with reason pickers sourced from the template.
- Show each action only in the status where it is valid:
- **Charge-off:** active, not yet charged off.
- **Undo charge-off:** charged off.
- **Write-off:** active.
- **Undo write-off:** written off with no recoveries.
- **Recovery payment:** written off.
- Use a destructive-styled `DialogService.confirm` before write-off and both
undo actions.
## RBAC
| Action | Permission code | Typically granted to |
|---|---|---|
| Charge-off | `CHARGEOFF_WORKINGCAPITALLOAN` | credit-risk manager, head of
collections |
| Undo charge-off | `UNDOCHARGEOFF_WORKINGCAPITALLOAN` | credit-risk manager
(not the maker) |
| Write-off | `WRITEOFF_WORKINGCAPITALLOAN` | credit committee / senior
manager |
| Undo write-off | `UNDOWRITEOFF_WORKINGCAPITALLOAN` | senior manager /
finance |
| Recovery payment | `RECOVERYPAYMENT_WORKINGCAPITALLOAN` | collections
officer, teller |
These are loss-recognition events. Institutions commonly put them under
maker-checker, so the UI must handle the "submitted for approval" response and
must never show these actions to a role that only holds
`REPAYMENT_WORKINGCAPITALLOAN` or `UPDATE_WORKINGCAPITALLOAN`.
### How Fineract evaluates these permissions
- A write passes with the exact code **or** `ALL_FUNCTIONS`. Reads pass with
`ALL_FUNCTIONS_READ`.
- Maker-checker queues the command for a `<CODE>_CHECKER` holder.
- All codes above are in `scripts/permission-codes.json`.
### UI expectations
- Use a per-command permission map, as `LOAN_COMMAND_PERMISSIONS` does for
regular loans.
- Guard the route per command.
- Gate each menu item with `[appRequiresPermission]`.
- Read-only roles see no enabled actions.
## Acceptance criteria
- [ ] Each action posts the right command with its reason, and the loan's
status and transactions update.
- [ ] Actions appear only in valid states. Undo write-off is blocked once a
recovery exists.
- [ ] Gating is per code, a direct URL without the code redirects to
`/forbidden`, and maker-checker responses are surfaced.
- [ ] Unit tests cover state visibility, payloads and permission gating.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
