# Offboarding Requirements vs Implementation Gap Report

Date: 2026-04-17  
Source baseline: `backend/docs/Re_New_Dealer_Onboard_TWO.md`

## Purpose
This report captures:
1. What the SRS requires for offboarding-related modules.
2. What is implemented in the current codebase.
3. What is still missing or needs standardization.

---

## 1) SRS Requirements (What document asks)

## 1.1 Common cross-module requirements
- Role-driven stage workflow across Resignation, Termination, Constitutional Change, Relocation, and F&F.
- Stage actions include combinations of `Approve`, `Send Back`, `Revoke`, and module-specific decisions such as `Hold`, `Reject`, `Reconsider`, `Raise Query`.
- `Send Back` and `Revoke` must be recorded through **Work Notes** with **mandatory remarks**.
- Every action, upload, and transition must be logged in **Audit Trail**.
- Visibility and actionability must follow persona-based access control.

## 1.2 Resignation (SRS sections `4.2.2.x`, `12.1.x`)
- Multi-stage review with business hierarchy and Legal closure.
- Authorized users can `Approve`, `Send Back`, `Revoke` per stage authority.
- Dealer withdrawal allowed only up to NBH-pending state.
- F&F must trigger strictly on Last Working Day (LWD), not approval date.

## 1.3 Termination (SRS sections `4.3.2.x`)
- Escalation workflow from business review to legal process and final authorization.
- NBH stage includes `Go Ahead`, `Hold Decision`, `Raise Query`.
- NBH final decision includes `Approve Termination`, `Reconsider`, `Reject`.
- CEO/CCO authorization before legal termination letter and closure.
- F&F trigger aligned to LWD rule.

## 1.4 Constitutional Change (SRS section `12.2.x`)
- Dealer-initiated request with scenario-based mandatory documents.
- Internal review stages support `Approve`, `Send Back`, `Revoke`.
- Work Notes + mandatory remarks for send-back/revoke.
- Compliance verification and final master update by Legal stage.

## 1.5 Relocation (SRS relocation section under `12.2.x`)
- Dealer-initiated relocation with document checklist and verification.
- Internal stages support `Approve`, `Send Back`, `Revoke`.
- Work Notes and audit logging for all reviewer actions.

## 1.6 F&F Settlement (SRS sections `10.x`, `11.2.x`)
- Department-wise responses feed Finance summary and settlement decision.
- Finance actions include `Approve Settlement`, `Request Clarification`, `Reject Settlement`.
- Checklist-gated approval and complete auditability.
- Work Notes as official internal communication channel.

---

## 2) Implemented in Current Codebase

## 2.1 F&F conflict-free ownership and UX improvements
- Department claim vs finance validated layering is implemented in settlement flow.
- Auto-seeding of finance draft line items from department claims is implemented.
- Finance detail UI supports local draft editing and save-based API update pattern.
- Reconciliation table for department vs finance amounts added in internal F&F views.

## 2.2 Resignation and termination role visibility fixes
- Sidebar and route access expanded for roles such as RBM, ZBH, DD Head, Legal Admin where required.
- Role checks normalized around `role` and `roleCode` usage.
- `RoleGuard` matching made case-insensitive and more robust.

## 2.3 Termination workflow and API wiring
- Termination creation now starts at `RBM Review` stage.
- SCN APIs implemented (`/scn`, `/scn-response`) with stage transition handling.
- Finalize API implemented (`/:id/finalize`) for NBH/CCO/CEO related final decisions.
- Timeline rendering logic corrected to map remarks to correct stage entries.
- Stage progression and status rendering improved (including terminated-state completion).

## 2.4 Constitutional joint approval (ZM+RBM)
- Joint approval logic implemented in backend for `ZM/RBM Review` stage using approval policy.
- Seed policy added for `CONSTITUTIONAL_ZM_RBM_REVIEW` with required roles and two approvals.
- Frontend updated to show `ZM+RBM` labeling and prevent duplicate self-approval actions.
- Progress UI now reflects both RBM and DD-ZM comments and "Approved by you" state.

## 2.5 Dealer and detail data correctness
- Active dealer filtering introduced for dropdown usage.
- Dealer email exposure fixed in related detail screens (termination/resignation context).

---

## 3) Missing / Gap Analysis (What is still pending)

## 3.1 Send-back standardization across modules (High priority)
Current state is partially aligned but not fully standardized.

Missing standard contract across modules:
- Unified action contract (for example: `action=sendBack` with mandatory `remarks`).
- Deterministic previous-stage routing logic shared across modules.
- Consistent role-guard enforcement for send-back by stage owner/authorized roles.
- Consistent work note + audit payload structure for each send-back/revoke action.

## 3.2 Termination send-back hardening (Highest gap)
- Termination supports major transitions, but send-back behavior still needs full standard handling parity with other modules.
- Need explicit, centrally testable behavior for stage rollback and notifications on send-back paths.

## 3.3 Constitutional send-back to joint stage reset behavior
- If a case is sent back to `ZM+RBM` from later stage, joint approvals must be reset for a fresh cycle.
- This reset behavior should be explicit and deterministic in controller/service layer.

## 3.4 Remaining UX consistency tasks
- Add explicit final summary label in F&F: "Final settlement uses Finance Validated values."
- Add first-time "auto-seeded" badge for finance prefilled rows.
- Apply smooth edit pattern consistency to non-finance F&F detail editing where applicable.
- Improve timeline labels in termination to distinguish stage initiation vs stage action (if required by UX acceptance).

## 3.5 Policy and admin-config visibility
- Approval policy UI should expose the constitutional joint-review policy label for admin maintenance.
- Legal Admin read-scope definitions across modules should be formalized if strict SRS interpretation is required.

---

## 4) Recommended Next Execution Order
1. Standardize send-back contract and validations in backend services (start with Termination).
2. Add shared rollback resolver for previous stage routing.
3. Add module-specific send-back hooks (including joint-approval reset for Constitutional).
4. Align frontend action payloads and button guards to shared contract.
5. Add regression tests for send-back/revoke in each module.
6. Complete UX consistency items in F&F and timelines.

---

## 5) Status Snapshot
- **SRS intent coverage:** Medium-High
- **Core flow implementation:** High in Resignation/F&F, Medium-High in Termination/Constitutional/Relocation
- **Main risk:** inconsistent send-back behavior across modules
- **Immediate focus:** send-back standardization + deterministic rollback behavior