[
https://issues.apache.org/jira/browse/FINERACT-2681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18094559#comment-18094559
]
AMAN MITTAL commented on FINERACT-2681:
---------------------------------------
https://github.com/user-attachments/assets/9aebd8eb-2689-4c2a-93e1-2d5cb2cacda5
> [FINERACT-BACKOFFICE-UI] [FRONTEND] Loan module — implement
> Cumulative/Progressive schedules, payment/credit allocation editor, lifecycle
> actions, and transaction detail dialog
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: FINERACT-2681
> URL: https://issues.apache.org/jira/browse/FINERACT-2681
> Project: Apache Fineract
> Issue Type: Improvement
> Components: fineract-backoffice
> Reporter: AMAN MITTAL
> Priority: Major
>
> Note: Repo is *fineract-backoffice-ui*
>
> The backoffice UI currently lacks comprehensive loan servicing features
> required for advanced loan management. This work implements multiple
> loan-module enhancements in the UI to match updated product expectations and
> improve loan servicing workflows. The PR to implement these changes is:
> [https://github.com/apache/fineract-backoffice-ui/pull/93]
>
>
> * Scope
> ** Add two loan schedule calculation types: Cumulative and Progressive.
> ** Implement a Payment & Credit Allocation Editor component to adjust
> allocation of payments and credits across charge/fees/principal/interest.
> ** Add loan lifecycle actions to the UI (examples: Undo Disbursal, Write
> Off; ensure actions are available where applicable).
> ** Create a Loan Transaction Detail dialog with tabs: Details, Notes,
> Documents, Collaterals.
> ** Replace native confirm() dialogs with standard Material confirm dialogs
> across these flows.
> ** Provide end-to-end tests covering loan lifecycle actions, servicing
> flows, schedule types, and account actions.
> * Functional requirements (must)
> ## Schedule types
> *** Provide UI option(s) to select between Cumulative and Progressive
> schedule types when creating or reconfiguring loan schedules.
> *** Ensure schedule previews and calculated installments reflect the
> selected schedule type consistently in the UI.
> ## Payment & Credit Allocation Editor
> *** Provide a reusable component that shows current allocation (principal,
> interest, fees, penalties) and allows adjustments before applying payments or
> credits.
> *** Persist adjustments only after user confirmation.
> *** Validate allocations against allowable business rules (e.g., totals must
> equal payment amount).
> ## Loan lifecycle actions
> *** Expose lifecycle actions (Undo Disbursal, Write Off, and any other
> actions implemented) in the loan actions menu when the loan state permits.
> *** Ask for confirmation using the Material confirm dialog, showing the
> action, reason (if required), and consequences.
> *** Trigger the corresponding back-end API endpoints; show success/failure
> UI to the user and refresh loan details after completion.
> ## Transaction detail dialog
> *** Clicking a loan transaction opens a dialog showing transaction details.
> *** Dialog includes tabs for: Transaction Details, Notes, Documents,
> Collaterals.
> *** Notes tab allows viewing and adding notes; Documents tab lists and
> supports viewing attachments; Collaterals tab shows collateral forms/data if
> applicable.
> ## Confirm dialogs
> *** Replace any native window.confirm calls in the modified flows with the
> Material confirm dialog component used elsewhere in the app, maintaining
> consistent styling and behavior.
> ## Tests
> *** Add E2E tests that cover typical loan lifecycle flows: disbursal, undo
> disbursal, write off, payment allocation adjustments, switching schedule
> types, and verifying the transaction dialog tabs.
> * Non-functional requirements (should)
> ** UI/UX follows existing backoffice styling and accessibility patterns.
> ** All new components are responsive and localized (i18n).
> ** No blocking of existing loan workflows for users who do not opt into the
> new schedule types.
> ** Performance: schedule preview calculations must complete within a
> reasonable time (no UI freeze).
> * Acceptance criteria
> ## When creating/modifying a loan, the user can choose Cumulative or
> Progressive schedule types; the schedule preview and calculated installments
> reflect the chosen type.
> ## The Payment & Credit Allocation Editor opens where appropriate, allows
> valid adjustments, validates totals, and application of allocation triggers
> the expected API call and updates the loan account UI.
> ## Lifecycle actions appear only when appropriate for the loan state;
> choosing an action opens a Material confirm dialog; confirming calls the API
> and the UI shows success or failure and refreshes state.
> ## Clicking a transaction opens the transaction dialog with functional
> Details, Notes, Documents, and Collaterals tabs; adding a note or viewing a
> document works without JavaScript console errors.
> ## All replaced native confirm calls are removed from the modified flows and
> replaced with Material confirm dialogs.
> ## End-to-end tests added in the PR run successfully in CI (or locally) and
> cover the flows described above.
> ## No regressions in existing loan UI flows (smoke-tested).
> * Testing notes
> ** Manual test steps:
> ### Create a loan and choose Progressive schedule; confirm schedule preview
> and expected repayment amounts.
> ### Create another loan using Cumulative schedule; compare differences and
> verify calculation correctness.
> ### Make a payment and use the Allocation Editor to reallocate amounts;
> confirm totals validate correctly and payment applies as expected.
> ### Trigger lifecycle actions (e.g., Write Off) on a loan in appropriate
> state; confirm prompt and post-action UI state.
> ### Open transaction detail dialog and verify each tab (Notes: add a note;
> Documents: view an attached file; Collaterals: view/edit collateral
> information).
> ** Automated tests:
> *** Confirm E2E tests added in PR run and pass in CI. If tests are flaky,
> create follow-up tickets to stabilize them.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
