diff --git a/docs/RE_Dealer_System_TestStories.md b/docs/RE_Dealer_System_TestStories.md index 6c61b2c..2dc3369 100644 --- a/docs/RE_Dealer_System_TestStories.md +++ b/docs/RE_Dealer_System_TestStories.md @@ -1726,39 +1726,40 @@ Centralized workspace for Finance. Two tabs: **Onboarding** (security deposit ve ## Notification / Email Trigger Summary — All Modules -| Trigger Event | Channel | Recipients | -|---|---|---| -| Application Submitted (Opportunity) | Email + WhatsApp | Applicant (credentials + questionnaire link) | -| Application Submitted (Non-Opportunity) | Email | Applicant (non-opportunity notice) | -| Application Shortlisted | Email + In-app | DD-ZM, RBM | -| Application Rejected | Email + WhatsApp | Applicant | -| Interview Scheduled | Google Calendar + Email + WhatsApp | All evaluators + Applicant | -| Questionnaire Completion Reminder | WhatsApp | Applicant | -| FDD Report Submitted | In-app + Email | Finance, DD-Admin | -| Finance Verified (Deposit) | In-app + Email | DD-Admin, DD-Lead | -| LOI Document Request | Email (NOT WhatsApp) | Applicant | -| LOI Issued | Official Email (NOT WhatsApp) | Applicant | -| LOI Issuance Confirmed | Email + In-app | Finance, DD-Head, NBH | -| Dealer Code Generated | In-app | DD-Admin, Finance, Legal | -| Statutory Verification Complete | In-app | DD-Admin | -| EOR 100% Complete | In-app | DD-Head, NBH | -| Dealership Live (Onboarded) | In-app | All stakeholders | -| Resignation Request Submitted | In-app | DD-Admin, DD-ASM, DD-Head, ZBH, NBH | -| Resignation Send Back / Revoke | Work Notes + In-app + Email | Dealer + Internal teams | -| NBH Resignation Approved | In-app | DD-Lead, RBM, ZBH, Finance, Legal | -| Resignation Acceptance Letter Uploaded | In-app | DD-Admin, DD-ASM | -| Resignation Withdrawn | In-app | DD-ASM, DD-Admin, stakeholders | -| Termination Request Created | In-app | RBM + DD-ZM | -| SCN Issued | Email (via DD-Admin) | Dealer | -| CEO + CCO Authorization | In-app | Legal, DD-Lead, DD-Admin, Finance | -| Termination Letter Uploaded | In-app | DD-Lead, DD-Admin, Finance (all linked personas) | -| F&F Initiated | In-app + Email | Finance, all 16 departments | -| Department Clearance SLA Reminder | In-app + Email | Respective department | -| Finance Approved Settlement | In-app + Email | DD-Admin, Legal | -| F&F Closed | In-app | DD-Lead, NBH, Legal, DD-Admin | -| SLA Breach | In-app + Email | Activity owner + escalation chain | -| Work Note @mention | In-app + Email | Tagged user | -| Opportunity Window Activated | In-app | DD-ZM, RBM for assigned area | +| Trigger Event | Channel | Recipients | Template Code (Master Seeder) | +|---|---|---|---| +| Application Submitted (Opportunity) | Email + WhatsApp | Applicant (credentials + questionnaire link) | `OPPORTUNITY` | +| Application Submitted (Non-Opportunity) | Email | Applicant (non-opportunity notice) | `NON_OPPORTUNITY` | +| Application Shortlisted | Email + In-app | DD-ZM, RBM | `APPLICANT_SHORTLISTED` | +| Application Rejected | Email + WhatsApp | Applicant | `APPLICANT_REJECTED` | +| Interview Scheduled | Google Calendar + Email + WhatsApp | All evaluators + Applicant | `INTERVIEW_SCHEDULED` | +| Questionnaire Completion Reminder | WhatsApp | Applicant | `QUESTIONNAIRE_REMINDER` | +| FDD Report Submitted | In-app + Email | Finance, DD-Admin | `GENERIC_NOTIFICATION` | +| Finance Verified (Payment/Deposit) | In-app + Email | DD-Admin, DD-Lead | `ONBOARDING_PAYMENT_VERIFIED` | +| LOI Document Request | Email | Applicant | `LOI_ISSUED` | +| LOI Issued | Official Email | Applicant | `LOI_ISSUED` | +| LOI Issuance Confirmed | Email + In-app | Finance, DD-Head, NBH | `LOI_ISSUANCE_CONFIRMED` | +| Dealer Code Generated | In-app + Email | DD-Admin, Finance, Legal | `DEALER_CODE_READY` | +| EOR 100% Complete | In-app | DD-Head, NBH | `EOR_COMPLETED` | +| Dealership Live (Inauguration) | In-app + Email | All stakeholders | `INAUGURATION_COMPLETED` | +| Resignation Request Received | Email | Dealer (Acknowledgement) | `RESIGNATION_RECEIVED` | +| Resignation Request Submitted | In-app + Email | DD-Admin, DD-ASM, DD-Head, ZBH, NBH | `RESIGNATION_SUBMITTED` | +| Resignation Send Back / Revoke | Work Notes + Email | Dealer + Internal teams | `RESIGNATION_UPDATE` | +| Resignation Approved (NBH) | In-app + Email | DD-Lead, RBM, ZBH, Finance, Legal | `RESIGNATION_APPROVED` | +| Termination Request Created | In-app + Email | RBM + DD-ZM | `TERMINATION_INITIATED` | +| SCN Issued | Email (via DD-Admin) | Dealer | `TERMINATION_SCN_ISSUED` | +| Legal Letter Generated | In-app + Email | Legal, DD-Lead, DD-Admin, Finance | `TERMINATION_LETTER_ISSUED` | +| Termination Final Closure | Email | Dealer (Access Revoked) | `TERMINATION_FINAL_CLOSURE_DEALER` | +| F&F Initiated | In-app + Email | Finance, all 16 departments | `FNF_INITIATED` | +| F&F Summary Prepared | In-app + Email | Finance Review Team | `FNF_SUMMARY_PREPARED` | +| F&F Settlement Approved | In-app + Email | DD-Admin, Legal, DD-Lead | `FNF_SETTLEMENT_APPROVED` | +| Constitutional Change Submitted | In-app + Email | ASM, RBM | `CONSTITUTIONAL_CHANGE_SUBMITTED` | +| Constitutional Change Approved | Email | Dealer | `CONSTITUTIONAL_CHANGE_APPROVED` | +| Relocation Request Received | Email | Dealer (Acknowledgement) | `RELOCATION_RECEIVED` | +| Relocation Request Submitted | In-app + Email | ASM, RBM | `RELOCATION_SUBMITTED` | +| Relocation Approved | Email | Dealer | `RELOCATION_APPROVED` | +| SLA Breach / Reminder | In-app + Email + WhatsApp | Activity owner + escalation chain | `SLA_REMINDER` | +| Work Note @mention | In-app + Email | Tagged user | `WORKNOTE_NOTIFICATION` | --- diff --git a/docs/modular_wise/01_Dealer_Onboarding.md b/docs/modular_wise/01_Dealer_Onboarding.md index 1f01ec3..2c3ebfa 100644 --- a/docs/modular_wise/01_Dealer_Onboarding.md +++ b/docs/modular_wise/01_Dealer_Onboarding.md @@ -1,89 +1,6 @@ -# RE Onboarding & Offboarding System - -# Requirements +# RE Onboarding ``` -System Requirements Specifications -``` -## 16 - Oct- 2025 - -## Version 1. 4 - - -## Contents - - -- Change Log - - 1.1 Change Log – Version 2.0 - - 1.2 Change Log – Dealer Self-Service Enablement -- 1 System Overview & Problem Statement -- 2 Intended Audience - - 2.1 Business & Functional Users - - 2.2 External & Integrated Stakeholders -- 3 Definitions and Acronyms -- 4 HiFi Wireframes & Flow of Application - - 4.1 Dealer onboarding - Process Flow Overview - - 4.2 Dealer Resignation – Process Flow Overview - - 4.3 Dealer Termination – Process Flow Overview - - 4.4 Dealer Full & Final (F&F) Settlement – Process Flow - - 4.5 Finance Team – Process Flow -- 5 System Features & Requirements -- 6 Dealer onboarding - - 6.1 Dealership Application Form - - 6.2 SSO Login - - 6.3 Dashboard - - 6.4 Opportunity & Non Opportunity - - 6.5 Questionnaire Response - - 6.6 Shortlisting Process - - 6.7 Shortlisted Applicants - - 6.8 Application Detail View - - 6.9 Interview Scheduling & Coordination - - 6.10 Interview Evaluation & Feedback Management - - 6.11 Interview Feedback & Evaluation Summary - - 6.12 Application Approval & Rejection Workflow - - 6.13 Work Notes & Internal Communication Trail - - 6.14 System Notifications & Alerts - - 6.15 FDD (Financial Due Diligence) & Finance Module - - 6.16 LOI Approval & Issuance - - 6.17 Dealer Code Generation, Architectural Work & Statutory Documentation............ - - 6.18 LOA Issuance, Essential Operating Requirements & Inauguration - - 6.19 Essential Operating Requirements (EOR) Checklist - - 6.20 Progress Tracker....................................................................................................... - - 6.21 Central Document Repository - - 6.22 Audit Trail & Activity Log.......................................................................................... -- 7 Dealer Resignation - - 7.1 Dealer Resignation Request (Initiation) - - 7.2 Resignation Management Dashboard - - 7.3 Resignation Details & Review - - 7.4 Resignation Request Review & Action Management - - 7.5 Resignation Progress Tracker - - 7.6 Documents & Audit Trail -- 8 Termination - - 8.1 Create Termination Request - - 8.2 Termination Ticket overview - - 8.3 Termination Approval & Review Process - - 8.4 Termination Progress Timeline -- 9 Admin Section - - 9.1 Master Configuration – Organization - - 9.2 Zone, Region & Area Configuration - - 9.3 Roles & permissions - - 9.4 SLA Configuration & Escalation Management - - 9.5 Email & Letter Templates Management - - 9.6 Opportunity Management (Geography & Window Setup) -- 10 F&F Case - - 10.1 F&F Settlement Progress Timeline - - 10.2 Department Responses -- 11 Finance Dashboard - - 11.1 Finance Dashboard Page - - 11.2 F&F Settlement Module -- 12 Dealer Persona - - 12.1 Dealer Resignation - - 12.2 Dealer Constitutional Change Management -- 13 Non-Functional Requirements -- 14 Technology Matrix -- 15 Infra requirements & System Hygiene -- 16 Not in scope - ## Change Log @@ -122,26 +39,7 @@ System Requirements Specifications - Corrected the workflow sequence to ensure that **LOA is issued prior to initiating the** **EOR checklist** , with EOR serving as the final readiness validation before go-live. -**1.1.5 Dealer Resignation Access & Workflow Enhancements** -- Enabled **dealer portal access** for initiating resignation requests and uploading required - information. - - -- Clarified that the **Legal team issues the Resignation Acceptance Letter** in all cases. -- Expanded review authority to allow **ZBH, DD Lead, DD Head, and NBH** to **Send Back or** - **Revoke resignation requests** , with communication routed through **Work Notes**. -- Confirmed that **Full & Final (F&F) settlement is triggered strictly on the Last Working** - **Day (LWD)** and not based on approval date. - -**1.1.6 Termination Workflow Governance Updates** - -- Clarified that **CEO is the final approving authority** for dealer termination cases. -- Included **CCO and CEO** as approval authorities with **Approve / Hold / Reject** options. -- Confirmed that the **Legal team issues termination letters only after CEO approval**. -- Removed **dealer portal access** from termination workflows. -- Extended **Send Back / Revoke** authority to **ZBH and DD Lead** for termination reviews. -- Aligned **F&F trigger for termination** to occur strictly on the **Last Working Day (LWD)**. **1.1.7 Role & Persona Alignment** @@ -172,70 +70,7 @@ System Requirements Specifications clearly scoped responsibilities. -### 1.2 Change Log – Dealer Self-Service Enablement -**Version:** v2. -**Section Impacted:** Section 12 – Dealer Portal (12.1 onwards) -**Module:** Dealer Onboarding & Offboarding System -**Change Type:** Dealer Feature Enablement (Section 12 onwards) -**Scope Enhancement :** Dealer Role and Access control -**Change demarcation** : Highlighted in Yellow -**Changes suggested by** : Ashok & Tariq -**Changed performed by** : Rohit Mandiwal -**Changes done on** : 5 - Jan- 2026 - -**1.2.1 Introduction of Dealer Portal** - -- Introduced a **Dealer Portal capability** enabling onboarded dealers to initiate and track - post-onboarding lifecycle requests through the portal. -- Dealer actions are governed by **role-based access controls** , approval hierarchies, and - audit mechanisms. - -**1.2.2 Dealer Resignation Enablement** - -- Enabled **dealer-initiated resignation requests** at outlet level via the portal. -- Added structured resignation submission with: - o Last Operational Date (Sales & Services) - o Reason for resignation - o Mandatory document readiness guidance -- Enabled **dealer withdrawal option** for resignation requests **only until the case is** - **pending with NBH**. -- Clarified that **Legal team issues the Resignation Acceptance Letter** post approvals. -- Ensured **F&F settlement is triggered based on Last Working Day (LWD)** and not - approval date. -- Restricted dealer portal access **post resignation closure**. - -**1.2.3 Dealer Relocation Request Enablement** - -- Enabled dealers to **initiate and track relocation requests** through a guided workflow. -- Added support for: - o Manual or map-based location entry - o Distance calculation from existing location - o Property type selection and expected relocation date - - -- Introduced **document-driven relocation validation** , including statutory, legal, property, - and infrastructure documents. -- Implemented **multi-level approval workflow** with Work Notes–based communication - and audit trail. -- Ensured dealer has **view and upload access only** , with approvals retained by RE - stakeholders. - -**1.2.4 Dealer Constitutional Change Enablement** - -- Enabled dealers to **initiate constitutional change requests** post onboarding. -- Supported all approved constitution change scenarios: - o Proprietorship, Partnership, LLP, and Private Limited permutations -- Implemented **dynamic document requirement determination** based on target - constitution. -- Explicitly confirmed **no OCR-based document validation** ; all validations are manual and - role-driven. -- Ensured statutory compliance via Legal review before master data updates. - -**1.2.5 Post-Exit Access Control** - -- Enforced system rule to **revoke dealer portal access** once resignation or termination is - completed. ## 1 System Overview & Problem Statement @@ -323,45 +158,8 @@ RE standards. The Dealer role is enabled to perform the following activities: +``` -- **Resignation Initiation** - -``` -The dealer can initiate the resignation process directly through the portal , submit the -reason for exit, and track the status of the request across the defined review, clearance, -and closure stages. -``` -- **Relocation Request Submission** - -``` -The dealer can submit a relocation request in scenarios where there is an intent to shift -the dealership from the current location to a new proposed location. The request is -routed for internal feasibility assessment, validation, and management approval before -execution. -``` -- **Change in Constitution Request** - -``` -The dealer can initiate a Change in Constitution request to seek approval from RE -management for ownership or structural changes within the dealership. Upon approval, -the dealer may proceed with the legally compliant transition. -``` -``` -Supported Change in Constitution scenarios include: -``` -``` -o Proprietorship (Single Owner) → Partnership -o Proprietorship → LLP (Limited Liability Partnership) -o Proprietorship → Private Limited -o Partnership → LLP -o Partnership → Private Limited -o Private Limited → LLP -o Private Limited → Partnership -``` -All dealer-initiated requests are subject to **defined validations, mandatory document -submissions, role-based reviews, and approvals**. The dealer’s access is **restricted to initiation, -document upload, and status visibility** , with **final decision-making authority retained by -authorized internal stakeholders of RE** ### 2.2 External & Integrated Stakeholders @@ -553,395 +351,8 @@ o Site validation and inspection - The entire lifecycle remains accessible under **Audit Trail** for future reference, compliance, or offboarding workflows. -### 4.2 Dealer Resignation – Process Flow Overview - -**4.2.1.1 Overview** - -``` -The Dealer Resignation Process manages the structured offboarding of a dealership initiated -by the dealer. The process begins when a dealer formally submits their resignation via -email to the Area Sales Manager (ASM) , after which the workflow transitions into the -system-managed approval sequence. -``` -``` -Dealer resignation requests are initiated by the dealer through the portal and subsequently -reviewed and processed by Admin, Finance, Legal, and relevant business stakeholders. -``` -``` -This flow ensures that each resignation is verified, discussed, and approved across all -required levels — maintaining proper documentation, compliance, and traceability until the -final Legal Acceptance Letter is issued. -``` - -**4.2.2 Step-by-Step Process Flow** - -``` -4.2.2.1 Dealer Initiation -``` -- The dealer submits a **formal resignation email** on the dealership’s official letterhead to - the **ASM**. -- The resignation reason must be clearly stated (e.g., personal, financial, business - restructuring). -- The **dealer is provided portal access** to initiate the resignation request directly through - the system. The dealer submits resignation details, reason for exit, and proposed - timeline via the portal, after which the request enters the internal review and clearance - workflow. - -``` -4.2.2.2 ASM Review -``` -- The **ASM** reviews the dealer’s resignation request and supporting letter. -- Uploads the **resignation email** and **dealer’s letterhead document** onto the portal. -- Adds remarks summarizing the discussion and reason for resignation. -- Forwards the request to **RBM + DD-ZM** for evaluation. - -``` -4.2.2.3 RBM + DD-ZM Joint Evaluation -``` -- The **Regional Business Manager (RBM)** and **Dealer Development Zonal Manager (DD-** - **ZM)** review the uploaded documents. -- Conduct a joint discussion with the dealer to confirm the intent and understand any - issues. -- Uploads the **Minutes of Meeting (MOM)** or discussion summary. -- Adds comments and recommendations before forwarding to **Zonal Business Head** - **(ZBH)**. -- Actions available at this stage: - o **Approve** → Send forward for next-level review - o **Send Back for Clarification** → Returns to ASM - o **Withdraw** → Cancels the request (with remarks logged) - -``` -4.2.2.4 ZBH Review -``` -- The **Zonal Business Head (ZBH)** reviews the resignation summary and all remarks. -- Adds their comments and recommendations. -- Forwards the request to **DD-Lead** through the system. -- Worknote is updated automatically to reflect action and timestamp. -- The resignation request is reviewed by authorized business stakeholders, - including **RBM, ZBH, and DD-Head**. During the review stage, the **ZBH is authorized to** -``` -Send Back or Revoke the resignation request for clarification or correction. Send Back -actions are communicated to the dealer and internal teams through Work Notes , with -mandatory remarks captured for traceability. -``` -``` -4.2.2.5 DD-Lead Review -``` -- The **DD-Lead** consolidates all discussions, documents, and feedback. -- Prepares a **Resignation Presentation** with recommendations and supporting data. -- Uploads the presentation to the portal. -- Forwards the case to **NBH** for final decision. -- The resignation request is reviewed by the **DD-Lead and DD-Head**. At this stage, both - roles are authorized to **Send Back or Revoke** the resignation request for clarification, - correction, or reconsideration. **Send Back actions are communicated through Work** - **Notes** , with **mandatory remarks** recorded for audit and traceability. - -``` -4.2.2.6 NBH Final Approval -``` -- The **National Business Head (NBH)** reviews the entire resignation dossier. -- Adds final remarks with one of the following outcomes: - o **Approve** → Case moves automatically to Legal for letter issuance. - o **Send Back for Clarification** → Returns to DD-Lead or ZBH for revalidation. - o **Hold** → Temporarily pauses the process pending further discussion. -- Upon approval, the system triggers a **Worknote Notification** to DD-Lead, RBM, ZBH, and - Finance teams. -- The resignation request is reviewed by the **NBH** , who may **Approve, Send Back, or** - **Revoke** the request based on business considerations. Any **Send Back or Revoke action** - **must be accompanied by remarks recorded in Work Notes** , ensuring transparent - communication and governance. - -``` -4.2.2.7 Legal Acceptance Letter -``` -- Once approved by **NBH** , the request is **auto-assigned to the Legal team**. -- Legal verifies the uploaded resignation and issues a **Resignation Acceptance Letter**. -- The letter is uploaded to the portal, visible to all relevant personas including **DD-** - **Admin** and **DD-AM**. -- Legal can also raise clarifications through worknotes if required. -- Upon completion of all approvals, the **Legal team issues the official Resignation** - **Acceptance Letter** and shares it with the dealer through authorized communication - channels. - - -``` -4.2.2.8 DD-Admin Closure -``` -- The **DD-Admin** downloads and shares the final **Resignation Acceptance Letter** with the - dealer. -- Marks the resignation as completed and triggers the **F&F (Full and Final) process** by - forwarding the case to the Finance team. -- The **Full & Final (F&F) settlement process is initiated only on the Last Working Day** - **(LWD) of the dealership**. The system shall **enable and trigger the F&F workflow strictly** - **based on the LWD date** , and **not based on the resignation approval date**. - -### 4.3 Dealer Termination – Process Flow Overview - -``` -4.3.1.1 Overview -``` -``` -The Dealer Termination Process governs the structured offboarding of a dealership initiated -internally by Royal Enfield due to operational, contractual, or ethical concerns. -It ensures that any termination—whether due to working-capital issues, poor performance, -or unethical practices —is investigated, documented, reviewed at multiple managerial levels, -and legally validated before final execution. The process maintains full transparency and -traceability through digital records, comments, and worknotes until the Termination -Letter is issued and the Full & Final (F&F) settlement begins. -``` -**4.3.2 Step-by-Step Process Flow** - -``` -4.3.2.1 ASM – Case Initiation -``` -- The **Area Sales Manager (ASM)** regularly visits dealers and records **Minutes of Meeting** - **(MOM)** for performance or compliance concerns. -- After two consecutive unsatisfactory commitments or escalations, the ASM initiates - a **Termination Request** in the portal. -- Fills all operational details (Dealer Code, LOI, LOA, Sales Data, etc.), selects - a **Termination Category** (Working Capital, Performance, Unethical Practice), and - uploads supporting documents (MOMs, commitments, dealer letters). -- Submits the case to **RBM + DD-ZM** for review. - -``` -4.3.2.2 RBM + DD-ZM Review -``` -- The **Regional Business Manager (RBM)** and **Dealer Development Zonal Manager (DD-** - **ZM)** jointly evaluate the case. - - -- Conduct a meeting with the dealer and record fresh MOMs; upload dealer - commitments on letterhead. -- Provide remarks and supporting evidence. -- Actions available: - o **Approve** → Forward to ZBH - o **Send Back for Clarification** → Returns to ASM with comments - o **Withdraw** → Terminates workflow with justification - -``` -4.3.2.3 ZBH Review -``` -- The **Zonal Business Head (ZBH)** reviews the full chronology (ASM visits, RBM/DD-ZM - remarks, uploaded MOMs). -- Validates escalation authenticity and dealer communication record. -- Adds remarks and forwards to **DD-Lead** for deeper review. -- The termination request is reviewed by the **ZBH** , who is authorized to **Approve, Send** - **Back, or Revoke** the termination request. **Send Back actions are communicated** - **through Work Notes** , with **mandatory remarks** recorded for traceability. - -``` -4.3.2.4 DD-Lead Review & Legal Assignment -``` -- The **DD-Lead** cross-verifies case chronology with all stakeholders (ASM, RBM, ZBH). -- Prepares a **Termination Presentation** summarizing facts, dealer history, and - recommendations. -- Assigns the case to **Legal Team** for inputs through the system (visible in worknotes). -- The termination request is reviewed by the **DD-Lead** , who is authorized to **Send Back or** - **Revoke** the termination request for clarification or reconsideration. All such actions - require **mandatory remarks captured in Work Notes**. - -``` -4.3.2.5 Legal Verification -``` -- The **Legal Team** reviews documentation, ensures contractual breaches are well- - supported, and checks all precedents. -- May raise queries via **Worknotes** or **Send Back** the case to DD-Lead for clarification. -- Once satisfied, forwards the verified case back to **DD-Lead** for next action. - -``` -4.3.2.6 DD-Lead → DD-Head Review -``` -- The **DD-Lead** attaches Legal’s feedback and forwards the case to **DD-Head** for strategic - review. -- **DD-Head** validates the case, evaluates impact, and presents it to **National Business** - **Head (NBH)** for final business decision. - - -``` -4.3.2.7 NBH Evaluation -``` -- The **NBH** reviews all documentation and Legal remarks. -- May choose one of three actions: - o **Go Ahead** → Approve for issuance of **Show Cause Notice (SCN)** - o **Hold Decision** → Pause temporarily for further monitoring or negotiation - o **Raise Query** → Sends back to DD-Lead for additional input - -``` -4.3.2.8 Show Cause Notice (SCN) Issuance -``` -- Upon NBH approval, the system triggers Legal to prepare and issue the **SCN**. -- The **DD-Lead** formally shares the SCN with the dealer through **DD-Admin**. -- Dealer replies to the SCN by email or letter, which **DD-Admin uploads** to the portal. -- For termination cases, the **F&F settlement process is triggered only on the Last** - **Working Day (LWD)**. The system shall **control the F&F trigger based on the LWD date** , - irrespective of the termination approval date. - -``` -4.3.2.9 Evaluation of Dealer Response -``` -- The **DD-Lead** , **ZBH** , **RBM** , and **DD-Head** jointly review the dealer’s SCN response. -- Uploads internal comments, Legal feedback, and recommendation for NBH’s final - decision. - -``` -4.3.2.10 NBH Final Decision -``` -- The **NBH** reviews the compiled case with Legal advice and decides among: - o **Approve Termination** → Moves to CEO/CCO for confirmation - o **Reconsider** → Allow additional time or corrective action - o **Reject** → Case closed without termination - -``` -4.3.2.11 11. CEO & CCO Authorization -``` -- **CEO** and **Chief Commercial Officer (CCO)** review the NBH-approved termination. -- Provide authorization on the portal. -- Once signed off, the decision becomes final. - -``` -4.3.2.12 12. Legal Termination Letter -``` -- The **Legal Team** generates the **Termination Letter** to the portal. -- The letter is auto-visible to **DD-Lead** , **DD-Admin** , and **Finance**. -- A system notification is triggered to all linked personas. - - -``` -4.3.2.13 13. DD-Admin Communication & F&F Trigger -``` -- The **DD-Admin** shares the official **Termination Letter** with the dealer and field team. -- Marks the case as “Terminated” in the portal. -- Forwards the case to **Finance** for **Full & Final Settlement** initiation. -- Updates the worknote with final remarks and due-date for settlement. - -### 4.4 Dealer Full & Final (F&F) Settlement – Process Flow - -``` -4.4.1.1 Overview -``` -The **Full & Final (F&F) Settlement Process** governs the financial closure of a dealership -following **Resignation** or **Termination**. -It ensures that all financial obligations between Royal Enfield and the dealer — -including **security deposits, recoveries, payables, and department-wise dues** — are -transparently reconciled, verified, and documented before closure. - -**4.4.2 Step-by-Step Process Flow** - -``` -4.4.2.1 F&F Initiation -``` -- Triggered automatically once the **Resignation Acceptance Letter** or **Termination** - **Letter** is uploaded by **Legal**. -- The **DD-Admin** or **DD-Lead** initiates the F&F case in the **Finance Dashboard** , which - creates a unique **FNF Case ID** linked to the dealer code. -- The system auto-fetches dealer details, associated documents, resignation/termination - date, and due dates. -- Notification is sent to the **Finance Team** and all functional departments to begin the - clearance process. - -``` -4.4.2.2 Department-wise Response Collection -``` -- The system automatically prompts all mapped **functional departments (16 in total)** to - submit their clearance inputs — including NOC, payables, recoveries, and remarks. -- Each department updates: - o Financial dues (if any) - o Clearance confirmation (NOC) - o Supporting document uploads (e.g., debit note, invoice copy) -- The system dynamically updates progress (e.g., _12/16 Departments Responded_ ) with - color-coded indicators: - o 🟢 **No Dues** – Cleared - - -``` -o 🔴 Dues Pending – Outstanding financial liability -o ⚪ Pending – Awaiting department input -``` -- SLA-based reminders are auto-triggered for pending responses nearing the deadline. - -``` -4.4.2.3 Finance Summary Consolidation -``` -- Once all departments respond, the **DD-Admin Team** consolidates inputs into the **Final** - **F&F Summary Sheet** , which consists of: - o **Payables to Dealer** (e.g., refundable deposits, reimbursements) - o **Receivables from Dealer** (e.g., outstanding invoices, recoveries) - o **Deductions** (policy penalties, non-compliance adjustments) -- At this stage, **department-claimed amounts are frozen** and become read-only for - departments. -- Finance does **not overwrite department claim values**. Instead, Finance validates each row - in a dedicated validation layer by recording: - - Finance decision (Accepted / Partially Accepted / Rejected / Under Clarification) - - Finance-validated amount - - Variance amount and mandatory variance reason (if changed) - - Supporting proof/document -- The system automatically calculates: - - Net Settlement = Total Payables – Total Receivables – Total Deductions - - Final totals are computed from **finance-validated values only**. -- Status updates to _Finance Summary Prepared_ once complete. - -``` -4.4.2.4 Internal Review & Clarification -``` -- The **Finance Team** may use the **Work Note** section to raise clarifications to **DD-** - **Lead** , **Legal** , or concerned departments. -- If discrepancies exist (e.g., mismatched values or missing NOCs), the case remains _Under_ - _Clarification_ until resolved. -- Once validated, Finance locks the summary for further edits. - -``` -4.4.2.5 Dealer Discussion & Acknowledgment -``` -- The **Finance Team** , along with **Legal** and **DD-Lead** , discusses the settlement summary - with the dealer. -- Dealer acknowledgment is captured either via written confirmation or attached email - communication. -- The case then proceeds for **Final Finance Approval**. - -``` -4.4.2.6 Final Finance Approval & Payment Processing -``` -- The **Finance Team** reviews the approved summary and enters payment or recovery - details: - o **Transaction Type:** RTGS / NEFT / Cheque - o **Transaction ID & Date** - o **Bank Name & Account Details** (auto-fetched from dealer profile) - o **Settlement Remarks** -- Finance takes one of three actions: - - -``` -o Approve Settlement → Marks the case as “Finance Approved.” -o Request Clarification → Sends query to DD-Lead or Admin. -o Reject Summary → Returns for re-verification. -``` -- Upon approval, notifications are sent to DD-Admin and Legal for record update. - -``` -4.4.2.7 F&F Completion & Closure -``` -- Once approved, the case is automatically marked **Completed** , and the **Finance** - **Dashboard** updates status as _F&F Closed_. -- The **Settlement Proof** (e.g., payment confirmation or recovery adjustment) is uploaded - by Finance. -- The **DD-Admin** communicates official closure to the dealer and archives all artefacts. -- System triggers final alerts to DD-Lead, NBH, and Legal confirming completion. -- The case is archived in the **Audit Trail** for future reference. - -### 4.5 Finance Team – Process Flow - -``` -4.5.1.1 Overview -``` -The **Finance Team Process Flow** governs all financial activities related to dealer lifecycle -management — from **security deposit validation at onboarding** to **final settlement at -resignation or termination**. -It ensures complete financial traceability, proper verification of payments, and compliance with -Royal Enfield’s financial governance standards. -The process flow integrates with **Admin, Legal, Dealer Development (DD)** , and **Departmental -Modules** , ensuring accurate financial updates and timely closure of all financial transactions. **4.5.2 Step-by-Step Process Flow** @@ -959,55 +370,7 @@ Modules** , ensuring accurate financial updates and timely closure of all financ Admin and DD-Lead. -``` -o The verified payment data is stored permanently in the dealer’s financial profile -for audit and reference. -``` -``` -4.5.2.2 Financial Summary Preparation -``` -- **Action:** - Once departmental inputs are received, Finance consolidates all data into the **F&F** - **Summary Sheet**. -- **System Steps:** - o Segregates entries under: - ▪ **Payables to Dealer** (e.g., refundable deposits, reimbursements) - ▪ **Receivables from Dealer** (e.g., outstanding payments, penalties) - ▪ **Deductions** (e.g., policy recoveries, warranty holdbacks) - o The system auto-calculates: - o Net Settlement = Total Payables – Total Receivables – Deductions - o Finance validates each record, uploads supporting documents (receipts, invoices, - credit notes), and adds remarks. -- **Outcome:** - The computed **Net Settlement Amount** is reflected in the dashboard, categorized - as _Payable to Dealer_ or _Recoverable from Dealer_. -``` -4.5.2.3 Internal Clarification & Approval -``` -- **Action:** - Finance initiates clarification rounds with departments or DD-Lead for mismatched data. -- **System Steps:** - o Uses the **Work Notes** section for comments, tagging users like _@DD-_ - _Lead_ , _@Legal_ , or _@Admin_. - o Tracks status as _Pending Clarification_ until resolved. - o After reconciliation, Finance locks the summary and updates case status - to _Ready for Approval_. - -``` -4.5.2.4 Final Review & Dealer Confirmation -``` -- **Action:** - Finance conducts an internal review of the consolidated settlement and initiates a - financial discussion with the dealer. -- **System Steps:** - o Reviews summary details on-screen with Legal and DD-Lead. - o Records dealer’s acknowledgment via Work Note or attached email - confirmation. - o Once confirmed, proceeds to payment verification. - - -``` 4.5.2.5 Payment Processing & Record Update ``` - **Action:** @@ -1020,17 +383,6 @@ for audit and reference. o System automatically updates the **Progress Timeline** and **Audit Trail**. ``` -4.5.2.6 F&F Completion & Closure -``` -- **Action:** - Finance reviews all entries, confirms ledger reconciliations, and marks case - as **Completed**. -- **System Steps:** - o Locks financial data and supporting artefacts. - o Status changes to _Closed – F&F Completed_. - o Final confirmation sent to all stakeholders — DD-Lead, NBH, DD-Head, Legal, and - DD-Admin. - o Finance Dashboard updates counters under “Completed Cases.” ## 5 System Features & Requirements @@ -1110,88 +462,6 @@ Full visibility for own submission ``` -### 6.2 SSO Login - -**6.2.1 Functionality Scope** - -The **User Authentication & Secure Login** module ensures controlled access to the **Dealer -Onboarding and Offboarding System** through **Royal Enfield’s Single Sign-On (SSO) -bridge** integrated with **Active Directory (AD)**. This guarantees that only **authorized RE -employees** can access the platform while maintaining identity consistency across all RE -applications. The feature upholds organizational standards of **security, traceability, and role- -based access control (RBAC)**. - -**6.2.2 Width** - -- The login interface is the **entry point** to the system and is accessible via the internal RE - portal or direct system URL. -- It contains the following key fields and actions: - o **Email Address** (RE domain-based ID) - o **Password** (validated via Active Directory) - o **Remember Me** (optional session retention) - o **Forgot Password** (redirects to RE’s password reset service via SSO) -- Once authenticated, users are redirected to their **personalized dashboard** based on role - and access level defined in RBAC. - - -**6.2.3 Depth** - -- The system leverages **RE’s enterprise SSO framework** for identity validation and token- - based session management. -- User credentials are not stored within the application; authentication tokens are - validated through **Active Directory** integration. -- Upon successful login, the system fetches user metadata (name, department, role, region, - and zone) to determine module visibility and permissions. -- **Role-Based Access Control (RBAC)** defines feature-level authorization for each user - category (e.g., DD-Admin, DD-ZM, RBM, Finance, Legal). -- Unauthorized users or non-RE email domains are denied access and redirected to an error - page stating: _“Access restricted to authorized Royal Enfield personnel only.”_ -- User sessions are automatically logged out after 30 mins of inactivity period - -**6.2.4 Flow** - -``` -Step Source → Destination Description / Action -1 User → Login Screen User enters RE email ID and password. -``` -``` -2 -``` -``` -Login Screen → SSO -Bridge Credentials validated via Active Directory.^ -3 SSO → System Authentication token passed back to the application. -4 System → RBAC Engine User role and permissions are identified. -``` -``` -5 System → User Dashboard User redirected to personalized dashboard based on access -level. -``` -**6.2.5 Personas-Wise Accessibility & Visibility** - -``` -Persona Accessibility Visibility Scope -All RE Employees Login access via SSO -bridge -``` -``` -Limited to assigned modules post-login -``` -``` -External Users (Dealers, -FDD Partners) -``` -``` -No direct access via -RE SSO -``` -``` -Access provided through secure external -login URLs when applicable -``` -**Dependency** - -- SSO implementation guide and sample users are required. ### 6.3 Dashboard @@ -3445,74 +2715,5 @@ o LOI / LOA / EOR Stages: Marks approvals, uploads, and status changes. stage. ``` -6.22.3.5 Security & Data Integrity -``` -- Audit logs are **read-only and non-editable** to preserve authenticity. -**6.22.4 Personas-Wise Accessibility & Visibility** -``` -Persona Accessibility Visibility Scope -RE User except -FDD -``` -``` -Full access to view all logs and export reports. Complete visibility and -export control. -System -(Automation -Layer) -``` -``` -Automatically records all workflow events and -triggers background logging for system actions. -``` -``` -Background operation. -``` - ---- - -## 13 Non-Functional Requirements - -``` -Category Requirement -Performance Average response time < 3 seconds for standard operations. -Scalability Should scale horizontally on GCP. -Security JWT tokens, encrypted passwords, HTTPS enforced. -Usability Intuitive UI, consistent icons, and simple navigation. -Reliability 99% uptime target. -Backup & Recovery Daily database backup and weekly full snapshot. -Compliance Follows RE IT data privacy guidelines. -``` -## 14 Technology Matrix - -``` -Component Specification -Database PGSQL (Managed or local instance) -Application Stack Node.js (Backend) + React.js (Frontend) -Authentication RE SSO Bridge -``` -## 15 Infra requirements & System Hygiene - -``` -Component Specification -Environment QA / Testing -# of Virtual Machines (VMs) 1 -CPU Configuration 4 - Core -Memory (RAM) 16 GB -Disk Size 500 GB -Operating System Ubuntu 24.04 LTS -``` - -``` -Storage Type Cloud -``` -Backup and Recovery - -- Daily incremental and weekly full backups. -- Restore process must not exceed 2 hours. - -## 16 Not in scope - -Anything which comes beyond the scope defined above in terms of Width and depth diff --git a/docs/modular_wise/02_Dealer_Resignation.md b/docs/modular_wise/02_Dealer_Resignation.md index aa68c41..4ff5468 100644 --- a/docs/modular_wise/02_Dealer_Resignation.md +++ b/docs/modular_wise/02_Dealer_Resignation.md @@ -1,126 +1,7 @@ -# RE Onboarding & Offboarding System +# RE Offboarding System # Requirements -``` -System Requirements Specifications -``` -## 16 - Oct- 2025 - -## Version 1. 4 - - -## Contents - - -- Change Log - - 1.1 Change Log – Version 2.0 - - 1.2 Change Log – Dealer Self-Service Enablement -- 1 System Overview & Problem Statement -- 2 Intended Audience - - 2.1 Business & Functional Users - - 2.2 External & Integrated Stakeholders -- 3 Definitions and Acronyms -- 4 HiFi Wireframes & Flow of Application - - 4.1 Dealer onboarding - Process Flow Overview - - 4.2 Dealer Resignation – Process Flow Overview - - 4.3 Dealer Termination – Process Flow Overview - - 4.4 Dealer Full & Final (F&F) Settlement – Process Flow - - 4.5 Finance Team – Process Flow -- 5 System Features & Requirements -- 6 Dealer onboarding - - 6.1 Dealership Application Form - - 6.2 SSO Login - - 6.3 Dashboard - - 6.4 Opportunity & Non Opportunity - - 6.5 Questionnaire Response - - 6.6 Shortlisting Process - - 6.7 Shortlisted Applicants - - 6.8 Application Detail View - - 6.9 Interview Scheduling & Coordination - - 6.10 Interview Evaluation & Feedback Management - - 6.11 Interview Feedback & Evaluation Summary - - 6.12 Application Approval & Rejection Workflow - - 6.13 Work Notes & Internal Communication Trail - - 6.14 System Notifications & Alerts - - 6.15 FDD (Financial Due Diligence) & Finance Module - - 6.16 LOI Approval & Issuance - - 6.17 Dealer Code Generation, Architectural Work & Statutory Documentation............ - - 6.18 LOA Issuance, Essential Operating Requirements & Inauguration - - 6.19 Essential Operating Requirements (EOR) Checklist - - 6.20 Progress Tracker....................................................................................................... - - 6.21 Central Document Repository - - 6.22 Audit Trail & Activity Log.......................................................................................... -- 7 Dealer Resignation - - 7.1 Dealer Resignation Request (Initiation) - - 7.2 Resignation Management Dashboard - - 7.3 Resignation Details & Review - - 7.4 Resignation Request Review & Action Management - - 7.5 Resignation Progress Tracker - - 7.6 Documents & Audit Trail -- 8 Termination - - 8.1 Create Termination Request - - 8.2 Termination Ticket overview - - 8.3 Termination Approval & Review Process - - 8.4 Termination Progress Timeline -- 9 Admin Section - - 9.1 Master Configuration – Organization - - 9.2 Zone, Region & Area Configuration - - 9.3 Roles & permissions - - 9.4 SLA Configuration & Escalation Management - - 9.5 Email & Letter Templates Management - - 9.6 Opportunity Management (Geography & Window Setup) -- 10 F&F Case - - 10.1 F&F Settlement Progress Timeline - - 10.2 Department Responses -- 11 Finance Dashboard - - 11.1 Finance Dashboard Page - - 11.2 F&F Settlement Module -- 12 Dealer Persona - - 12.1 Dealer Resignation - - 12.2 Dealer Constitutional Change Management -- 13 Non-Functional Requirements -- 14 Technology Matrix -- 15 Infra requirements & System Hygiene -- 16 Not in scope - - -## Change Log - -### 1.1 Change Log – Version 2.0 - -**Module:** Dealer Onboarding & Offboarding System -**Change Type:** Clarifications, Role Alignment & Access Control Enhancements -**Scope Enhancement :** Dealer Role and Access control -**Change demarcation** : Highlighted in Yellow -**Changes suggested by** : Ashok & Tariq -**Changed performed by** : Rohit Mandiwal -**Changes done on** : 31 - Dec- 2025 - -**1.1.1 Notification Channel Enhancement** - -- Added **WhatsApp as a supported notification channel** for reminders and workflow - communications (e.g., questionnaire completion and status updates), while restricting - sensitive document sharing to email only. - -**1.1.2 LOI Governance & Communication Clarifications** - -- Clarified that the **Finance team is not the decision-making authority** for LOI issuance - and is responsible only for financial validation. -- Confirmed that **LOI documents are shared exclusively via official email** and not through - WhatsApp. -- Clarified that **LOA issuance is a parallel statutory activity** and is **not dependent on** - **infrastructure readiness**. - -**1.1.3 Dealer Code Creation Control** - -- Clarified that **Dealer Codes (SAP Master) are created only upon explicit trigger by the** - **DD Admin** , and not through automatic system generation. - -**1.1.4 LOA & EOR Sequencing Correction** - -- Corrected the workflow sequence to ensure that **LOA is issued prior to initiating the** - **EOR checklist** , with EOR serving as the final readiness validation before go-live. **1.1.5 Dealer Resignation Access & Workflow Enhancements** @@ -134,15 +15,6 @@ System Requirements Specifications - Confirmed that **Full & Final (F&F) settlement is triggered strictly on the Last Working** **Day (LWD)** and not based on approval date. -**1.1.6 Termination Workflow Governance Updates** - -- Clarified that **CEO is the final approving authority** for dealer termination cases. -- Included **CCO and CEO** as approval authorities with **Approve / Hold / Reject** options. -- Confirmed that the **Legal team issues termination letters only after CEO approval**. -- Removed **dealer portal access** from termination workflows. -- Extended **Send Back / Revoke** authority to **ZBH and DD Lead** for termination reviews. -- Aligned **F&F trigger for termination** to occur strictly on the **Last Working Day (LWD)**. - **1.1.7 Role & Persona Alignment** - Added **NBH** to the personas section. @@ -160,9 +32,6 @@ System Requirements Specifications **scenarios only**. - Confirmed that **dealer portal access is revoked after resignation or termination**. -**1.1.9 Terminology & Documentation Corrections** - -- Clarified **KT Matrix as Kepner Tregoe Matrix** for consistency and correctness. **1.1.10 Super Admin Role Introduction** @@ -172,25 +41,6 @@ System Requirements Specifications clearly scoped responsibilities. -### 1.2 Change Log – Dealer Self-Service Enablement - -**Version:** v2. -**Section Impacted:** Section 12 – Dealer Portal (12.1 onwards) -**Module:** Dealer Onboarding & Offboarding System -**Change Type:** Dealer Feature Enablement (Section 12 onwards) -**Scope Enhancement :** Dealer Role and Access control -**Change demarcation** : Highlighted in Yellow -**Changes suggested by** : Ashok & Tariq -**Changed performed by** : Rohit Mandiwal -**Changes done on** : 5 - Jan- 2026 - -**1.2.1 Introduction of Dealer Portal** - -- Introduced a **Dealer Portal capability** enabling onboarded dealers to initiate and track - post-onboarding lifecycle requests through the portal. -- Dealer actions are governed by **role-based access controls** , approval hierarchies, and - audit mechanisms. - **1.2.2 Dealer Resignation Enablement** - Enabled **dealer-initiated resignation requests** at outlet level via the portal. @@ -205,70 +55,12 @@ System Requirements Specifications approval date. - Restricted dealer portal access **post resignation closure**. -**1.2.3 Dealer Relocation Request Enablement** - -- Enabled dealers to **initiate and track relocation requests** through a guided workflow. -- Added support for: - o Manual or map-based location entry - o Distance calculation from existing location - o Property type selection and expected relocation date - - -- Introduced **document-driven relocation validation** , including statutory, legal, property, - and infrastructure documents. -- Implemented **multi-level approval workflow** with Work Notes–based communication - and audit trail. -- Ensured dealer has **view and upload access only** , with approvals retained by RE - stakeholders. - -**1.2.4 Dealer Constitutional Change Enablement** - -- Enabled dealers to **initiate constitutional change requests** post onboarding. -- Supported all approved constitution change scenarios: - o Proprietorship, Partnership, LLP, and Private Limited permutations -- Implemented **dynamic document requirement determination** based on target - constitution. -- Explicitly confirmed **no OCR-based document validation** ; all validations are manual and - role-driven. -- Ensured statutory compliance via Legal review before master data updates. - **1.2.5 Post-Exit Access Control** - Enforced system rule to **revoke dealer portal access** once resignation or termination is completed. -## 1 System Overview & Problem Statement - -**1.1.1 System Overview** - -The **Dealer Onboarding and Offboarding System** for **Royal Enfield (RE)** is designed to **digitize, -standardize, and streamline** the complete dealer lifecycle — from **application and -evaluation** to **approval, resignation, termination, and full-and-final (F&F) settlement**. - -At present, the process operates through **manual coordination** , involving **emails, spreadsheets, -and physical documentation** , which makes it difficult to maintain visibility, accountability, and -consistency across teams. - -The proposed solution introduces a **centralized digital platform** that brings all stakeholders onto -a single workflow. It ensures that every stage — **onboarding, operational approvals, financial -diligence, legal validation, and final closure** — follows a **structured and traceable process**. - -The system integrates seamlessly with existing RE applications such as **SSO** , **SAP** , and **Finance -modules** , providing **role-based access** , **real-time tracking** , and **secure document management**. -It also offers **automated workflows** , **configurable approval hierarchies** , and **AI-assisted decision -support** to improve efficiency and reduce turnaround time. - -By moving to a digital workflow, Royal Enfield will achieve higher levels of **process -efficiency** , **data accuracy** , and **transparency** , ensuring faster decision-making and stronger -control over the dealer network lifecycle. - -## 2 Intended Audience - -This document is intended for all stakeholders involved in the **design, implementation, approval, -and operational use** of the **Dealer Onboarding and Offboarding System** at **Royal Enfield (RE)**. - -The following user personas and roles are part of the system: ### 2.1 Business & Functional Users @@ -330,53 +122,6 @@ The Dealer role is enabled to perform the following activities: The dealer can initiate the resignation process directly through the portal , submit the reason for exit, and track the status of the request across the defined review, clearance, and closure stages. -``` -- **Relocation Request Submission** - -``` -The dealer can submit a relocation request in scenarios where there is an intent to shift -the dealership from the current location to a new proposed location. The request is -routed for internal feasibility assessment, validation, and management approval before -execution. -``` -- **Change in Constitution Request** - -``` -The dealer can initiate a Change in Constitution request to seek approval from RE -management for ownership or structural changes within the dealership. Upon approval, -the dealer may proceed with the legally compliant transition. -``` -``` -Supported Change in Constitution scenarios include: -``` -``` -o Proprietorship (Single Owner) → Partnership -o Proprietorship → LLP (Limited Liability Partnership) -o Proprietorship → Private Limited -o Partnership → LLP -o Partnership → Private Limited -o Private Limited → LLP -o Private Limited → Partnership -``` -All dealer-initiated requests are subject to **defined validations, mandatory document -submissions, role-based reviews, and approvals**. The dealer’s access is **restricted to initiation, -document upload, and status visibility** , with **final decision-making authority retained by -authorized internal stakeholders of RE** - -### 2.2 External & Integrated Stakeholders - -**2.2.1 FDD (Financial Due Diligence Partner)** - -External agency responsible for assessing the applicant’s financial health, verifying credentials, -and uploading due diligence reports into the system. - - -**2.2.2 Dealer / Applicant** -External user who applies for dealership, uploads required documents, participates in -interviews, and later accesses the portal for resignation or closure status. - -## 3 Definitions and Acronyms - ``` Acronym Full Form / Description RE Royal Enfield @@ -395,154 +140,6 @@ EOR Essential Operating Requirements LOA Letter of Appointment F&F Full and Final (Dealer Settlement) KT Matrix Evaluation Matrix used for scoring applicants -``` -## 4 HiFi Wireframes & Flow of Application - -HiFi Wireframes : https://mono-human-93592950.figma.site - -### 4.1 Dealer onboarding - Process Flow Overview - -The **Dealer Onboarding Workflow** outlines the end-to-end sequence through which a dealership -application progresses — from initial registration to final inauguration and operational readiness. - - -**4.1.1 Step-by-Step Process Flow** - -``` -4.1.1.1 Application Initiation -``` -- The **applicant (dealer prospect)** submits an online application through the Dealer - Onboarding Portal. -- The system checks the **location’s availability** in the Royal Enfield dealership network: - o If the location has **no open opportunity** , a **Non-Opportunity Email** is triggered - automatically. - o If an opportunity exists, the applicant receives an **Opportunity Email** with login - credentials and a link to the **Dealer Questionnaire**. - -``` -4.1.1.2 Questionnaire Completion -``` -- The applicant fills out the **comprehensive questionnaire** covering business, infrastructure, - and financial readiness. -- The system auto-scores responses, generating a **Questionnaire Score** and **initial** - **ranking** for that applicant. - - -- Completed applications move to the **Admin review bucket**. -- The system shall trigger automated reminders to users for completing the - questionnaire. These **reminders will be sent through WhatsApp** , to ensure timely - submission. Reminder needs to be configured from Admin. - -``` -4.1.1.3 Admin Validation & Shortlisting -``` -- **DD-Admin** reviews all submitted applications and validates details and attached - documents. -- Based on eligibility, applications are either **shortlisted** for evaluation or **archived** for - future opportunities. -- Shortlisted applications are distributed to respective **zones or regions** for further - assessment. - -``` -4.1.1.4 Interview Evaluation (Multi-Level Process) -``` -- Admin schedules interviews in **Level 1** , **Level 2** , and **Level 3** , as applicable. -- Each interview can be **Virtual or Physical** , with calendar invites sent via Google Calendar. -- Evaluators at each level (DD-ZM, RBM, DD-Lead, ZBH, NBH, DD-Head) record their - feedback through: - o **KT Matrix Scoring** (quantitative) - o **Interview Feedback Form** (qualitative) -- The system consolidates panel feedback and generates an **AI-driven summary and** - **ranking** for decision support. - -``` -4.1.1.5 Financial Due Diligence (FDD) & Finance Review -``` -- Upon shortlisting, the application is assigned to the **FDD Team (external agency)** for - financial validation. -- FDD users, using SSO credentials, can: - o View assigned applications in a restricted interface. - o Upload FDD reports and add remarks in the **Work Notes** section. - o Flag cases of **non-responsiveness** or incomplete data, returning them to Admin. -- The **Finance team** reviews submitted FDD reports, validates findings, and decides - whether the application proceeds to **LOI approval**. The finance team is not the decision - maker for LOI Issuance. - -``` -4.1.1.6 LOI (Letter of Intent) Approval & Issuance -``` -- Based on Finance clearance, **DD-Head and NBH** review and approve the **LOI request**. -- The system tracks document approvals, timestamps, and supporting artefacts. - - -- Once approved, the LOI document is generated, uploaded, and shared **with the** - **applicant via official email communication** and not on WhatsApp -- Notification emails are triggered to all relevant stakeholders. - -``` -4.1.1.7 Dealer Code Generation & Setup -``` -- After LOI issuance, the **DD-Admin triggers** the Dealer Code creation process. Based on - this trigger, the **Dealer Code is created in the SAP Master** and **mapped to the applicant** - within the system. -- The code links all downstream modules, including Architectural, Statutory, and EOR - checklists. - -``` -4.1.1.8 Architectural Work & Statutory Documentation -``` -- Architectural activities are initiated (site plans, layout approvals, branding elements). -- The applicant and assigned Architecture Team upload documents, drawings, and - blueprints. -- In parallel, the applicant uploads **Statutory Documents** such as: - o GST certificate, PAN, Partnership Deed, Firm Registration, Rental/Lease - Agreement, etc. -- Each upload is timestamped and visible with file name, uploader, and document type. - -``` -4.1.1.9 Payment Verification & Finance Validation -``` -- Applicant uploads proof of advance payment or security deposit. -- The **Finance team** verifies payment details (transaction ID, amount, and bank record). -- Status is updated to **Verified** once the payment is reconciled. -- Verified payment triggers readiness for final operational setup. - -``` -4.1.1.10 Essential Operating Requirements (EOR) Checklist -``` -- All functional teams (Sales, Service, IT, Finance, Training, Architecture) verify their - respective readiness parameters. -- Progress is tracked through a **completion bar** until 100% EOR compliance is achieved. -- The **EOR checklist is initiated only after LOA issuance**. All functional teams verify their - respective readiness parameters, and progress is tracked until **100% EOR compliance** is - achieved. - -``` -4.1.1.11 LOA (Letter of Authorization) & Final Go-Live -``` -- After LOI issuance and Dealer Code generation, the **Letter of Authorization (LOA) is** - **generated and approved by NBH and DD-Head**. Upon successful LOA issuance, the - - -``` -application proceeds to the Essential Operating Requirements (EOR) checklist for final -readiness verification. -``` -- Final verification includes: - -``` -o EOR document review -o Brand readiness assessment -o Site validation and inspection -``` -- The **LOA** officially authorizes the dealership to operate under Royal Enfield. - -``` -4.1.1.12 Inauguration & Closure -``` -- Post-authorization, the **Inauguration** event is scheduled and logged. -- Completion of inauguration marks the dealership as **Active** in the system. - ``` 4.1.1.13 System-Driven Governance & Audit ``` @@ -677,375 +274,8 @@ mandatory remarks captured for traceability. **(LWD) of the dealership**. The system shall **enable and trigger the F&F workflow strictly** **based on the LWD date** , and **not based on the resignation approval date**. -### 4.3 Dealer Termination – Process Flow Overview +``` -``` -4.3.1.1 Overview -``` -``` -The Dealer Termination Process governs the structured offboarding of a dealership initiated -internally by Royal Enfield due to operational, contractual, or ethical concerns. -It ensures that any termination—whether due to working-capital issues, poor performance, -or unethical practices —is investigated, documented, reviewed at multiple managerial levels, -and legally validated before final execution. The process maintains full transparency and -traceability through digital records, comments, and worknotes until the Termination -Letter is issued and the Full & Final (F&F) settlement begins. -``` -**4.3.2 Step-by-Step Process Flow** - -``` -4.3.2.1 ASM – Case Initiation -``` -- The **Area Sales Manager (ASM)** regularly visits dealers and records **Minutes of Meeting** - **(MOM)** for performance or compliance concerns. -- After two consecutive unsatisfactory commitments or escalations, the ASM initiates - a **Termination Request** in the portal. -- Fills all operational details (Dealer Code, LOI, LOA, Sales Data, etc.), selects - a **Termination Category** (Working Capital, Performance, Unethical Practice), and - uploads supporting documents (MOMs, commitments, dealer letters). -- Submits the case to **RBM + DD-ZM** for review. - -``` -4.3.2.2 RBM + DD-ZM Review -``` -- The **Regional Business Manager (RBM)** and **Dealer Development Zonal Manager (DD-** - **ZM)** jointly evaluate the case. - - -- Conduct a meeting with the dealer and record fresh MOMs; upload dealer - commitments on letterhead. -- Provide remarks and supporting evidence. -- Actions available: - o **Approve** → Forward to ZBH - o **Send Back for Clarification** → Returns to ASM with comments - o **Withdraw** → Terminates workflow with justification - -``` -4.3.2.3 ZBH Review -``` -- The **Zonal Business Head (ZBH)** reviews the full chronology (ASM visits, RBM/DD-ZM - remarks, uploaded MOMs). -- Validates escalation authenticity and dealer communication record. -- Adds remarks and forwards to **DD-Lead** for deeper review. -- The termination request is reviewed by the **ZBH** , who is authorized to **Approve, Send** - **Back, or Revoke** the termination request. **Send Back actions are communicated** - **through Work Notes** , with **mandatory remarks** recorded for traceability. - -``` -4.3.2.4 DD-Lead Review & Legal Assignment -``` -- The **DD-Lead** cross-verifies case chronology with all stakeholders (ASM, RBM, ZBH). -- Prepares a **Termination Presentation** summarizing facts, dealer history, and - recommendations. -- Assigns the case to **Legal Team** for inputs through the system (visible in worknotes). -- The termination request is reviewed by the **DD-Lead** , who is authorized to **Send Back or** - **Revoke** the termination request for clarification or reconsideration. All such actions - require **mandatory remarks captured in Work Notes**. - -``` -4.3.2.5 Legal Verification -``` -- The **Legal Team** reviews documentation, ensures contractual breaches are well- - supported, and checks all precedents. -- May raise queries via **Worknotes** or **Send Back** the case to DD-Lead for clarification. -- Once satisfied, forwards the verified case back to **DD-Lead** for next action. - -``` -4.3.2.6 DD-Lead → DD-Head Review -``` -- The **DD-Lead** attaches Legal’s feedback and forwards the case to **DD-Head** for strategic - review. -- **DD-Head** validates the case, evaluates impact, and presents it to **National Business** - **Head (NBH)** for final business decision. - - -``` -4.3.2.7 NBH Evaluation -``` -- The **NBH** reviews all documentation and Legal remarks. -- May choose one of three actions: - o **Go Ahead** → Approve for issuance of **Show Cause Notice (SCN)** - o **Hold Decision** → Pause temporarily for further monitoring or negotiation - o **Raise Query** → Sends back to DD-Lead for additional input - -``` -4.3.2.8 Show Cause Notice (SCN) Issuance -``` -- Upon NBH approval, the system triggers Legal to prepare and issue the **SCN**. -- The **DD-Lead** formally shares the SCN with the dealer through **DD-Admin**. -- Dealer replies to the SCN by email or letter, which **DD-Admin uploads** to the portal. -- For termination cases, the **F&F settlement process is triggered only on the Last** - **Working Day (LWD)**. The system shall **control the F&F trigger based on the LWD date** , - irrespective of the termination approval date. - -``` -4.3.2.9 Evaluation of Dealer Response -``` -- The **DD-Lead** , **ZBH** , **RBM** , and **DD-Head** jointly review the dealer’s SCN response. -- Uploads internal comments, Legal feedback, and recommendation for NBH’s final - decision. - -``` -4.3.2.10 NBH Final Decision -``` -- The **NBH** reviews the compiled case with Legal advice and decides among: - o **Approve Termination** → Moves to CEO/CCO for confirmation - o **Reconsider** → Allow additional time or corrective action - o **Reject** → Case closed without termination - -``` -4.3.2.11 11. CEO & CCO Authorization -``` -- **CEO** and **Chief Commercial Officer (CCO)** review the NBH-approved termination. -- Provide authorization on the portal. -- Once signed off, the decision becomes final. - -``` -4.3.2.12 12. Legal Termination Letter -``` -- The **Legal Team** generates the **Termination Letter** to the portal. -- The letter is auto-visible to **DD-Lead** , **DD-Admin** , and **Finance**. -- A system notification is triggered to all linked personas. - - -``` -4.3.2.13 13. DD-Admin Communication & F&F Trigger -``` -- The **DD-Admin** shares the official **Termination Letter** with the dealer and field team. -- Marks the case as “Terminated” in the portal. -- Forwards the case to **Finance** for **Full & Final Settlement** initiation. -- Updates the worknote with final remarks and due-date for settlement. - -### 4.4 Dealer Full & Final (F&F) Settlement – Process Flow - -``` -4.4.1.1 Overview -``` -The **Full & Final (F&F) Settlement Process** governs the financial closure of a dealership -following **Resignation** or **Termination**. -It ensures that all financial obligations between Royal Enfield and the dealer — -including **security deposits, recoveries, payables, and department-wise dues** — are -transparently reconciled, verified, and documented before closure. - -**4.4.2 Step-by-Step Process Flow** - -``` -4.4.2.1 F&F Initiation -``` -- Triggered automatically once the **Resignation Acceptance Letter** or **Termination** - **Letter** is uploaded by **Legal**. -- The **DD-Admin** or **DD-Lead** initiates the F&F case in the **Finance Dashboard** , which - creates a unique **FNF Case ID** linked to the dealer code. -- The system auto-fetches dealer details, associated documents, resignation/termination - date, and due dates. -- Notification is sent to the **Finance Team** and all functional departments to begin the - clearance process. - -``` -4.4.2.2 Department-wise Response Collection -``` -- The system automatically prompts all mapped **functional departments (16 in total)** to - submit their clearance inputs — including NOC, payables, recoveries, and remarks. -- Each department updates: - o Financial dues (if any) - o Clearance confirmation (NOC) - o Supporting document uploads (e.g., debit note, invoice copy) -- The system dynamically updates progress (e.g., _12/16 Departments Responded_ ) with - color-coded indicators: - o 🟢 **No Dues** – Cleared - - -``` -o 🔴 Dues Pending – Outstanding financial liability -o ⚪ Pending – Awaiting department input -``` -- SLA-based reminders are auto-triggered for pending responses nearing the deadline. - -``` -4.4.2.3 Finance Summary Consolidation -``` -- Once all departments respond, the **DD-Admin Team** consolidates inputs into the **Final** - **F&F Summary Sheet** , which consists of: - o **Payables to Dealer** (e.g., refundable deposits, reimbursements) - o **Receivables from Dealer** (e.g., outstanding invoices, recoveries) - o **Deductions** (policy penalties, non-compliance adjustments) -- At this stage, **department-claimed amounts are frozen** and become read-only for - departments. -- Finance does **not overwrite department claim values**. Instead, Finance validates each row - in a dedicated validation layer by recording: - - Finance decision (Accepted / Partially Accepted / Rejected / Under Clarification) - - Finance-validated amount - - Variance amount and mandatory variance reason (if changed) - - Supporting proof/document -- The system automatically calculates: - - Net Settlement = Total Payables – Total Receivables – Total Deductions - - Final totals are computed from **finance-validated values only**. -- Status updates to _Finance Summary Prepared_ once complete. - -``` -4.4.2.4 Internal Review & Clarification -``` -- The **Finance Team** may use the **Work Note** section to raise clarifications to **DD-** - **Lead** , **Legal** , or concerned departments. -- If discrepancies exist (e.g., mismatched values or missing NOCs), the case remains _Under_ - _Clarification_ until resolved. -- Once validated, Finance locks the summary for further edits. - -``` -4.4.2.5 Dealer Discussion & Acknowledgment -``` -- The **Finance Team** , along with **Legal** and **DD-Lead** , discusses the settlement summary - with the dealer. -- Dealer acknowledgment is captured either via written confirmation or attached email - communication. -- The case then proceeds for **Final Finance Approval**. - -``` -4.4.2.6 Final Finance Approval & Payment Processing -``` -- The **Finance Team** reviews the approved summary and enters payment or recovery - details: - o **Transaction Type:** RTGS / NEFT / Cheque - o **Transaction ID & Date** - o **Bank Name & Account Details** (auto-fetched from dealer profile) - o **Settlement Remarks** -- Finance takes one of three actions: - - -``` -o Approve Settlement → Marks the case as “Finance Approved.” -o Request Clarification → Sends query to DD-Lead or Admin. -o Reject Summary → Returns for re-verification. -``` -- Upon approval, notifications are sent to DD-Admin and Legal for record update. - -``` -4.4.2.7 F&F Completion & Closure -``` -- Once approved, the case is automatically marked **Completed** , and the **Finance** - **Dashboard** updates status as _F&F Closed_. -- The **Settlement Proof** (e.g., payment confirmation or recovery adjustment) is uploaded - by Finance. -- The **DD-Admin** communicates official closure to the dealer and archives all artefacts. -- System triggers final alerts to DD-Lead, NBH, and Legal confirming completion. -- The case is archived in the **Audit Trail** for future reference. - -### 4.5 Finance Team – Process Flow - -``` -4.5.1.1 Overview -``` -The **Finance Team Process Flow** governs all financial activities related to dealer lifecycle -management — from **security deposit validation at onboarding** to **final settlement at -resignation or termination**. -It ensures complete financial traceability, proper verification of payments, and compliance with -Royal Enfield’s financial governance standards. -The process flow integrates with **Admin, Legal, Dealer Development (DD)** , and **Departmental -Modules** , ensuring accurate financial updates and timely closure of all financial transactions. - -**4.5.2 Step-by-Step Process Flow** - -``` -4.5.2.1 Security Deposit Validation (Onboarding Stage) -``` -- **Trigger:** - Initiated when a new dealer’s onboarding application reaches the Finance stage after - DD approval. -- **Action:** - The **Finance Team** verifies the **Security Deposit** payment made by the dealer - via **RTGS/NEFT** or other approved channels. -- **Outcome:** - o Verified deposits are marked as _Approved_ , triggering system notifications to DD- - Admin and DD-Lead. - - -``` -o The verified payment data is stored permanently in the dealer’s financial profile -for audit and reference. -``` -``` -4.5.2.2 Financial Summary Preparation -``` -- **Action:** - Once departmental inputs are received, Finance consolidates all data into the **F&F** - **Summary Sheet**. -- **System Steps:** - o Segregates entries under: - ▪ **Payables to Dealer** (e.g., refundable deposits, reimbursements) - ▪ **Receivables from Dealer** (e.g., outstanding payments, penalties) - ▪ **Deductions** (e.g., policy recoveries, warranty holdbacks) - o The system auto-calculates: - o Net Settlement = Total Payables – Total Receivables – Deductions - o Finance validates each record, uploads supporting documents (receipts, invoices, - credit notes), and adds remarks. -- **Outcome:** - The computed **Net Settlement Amount** is reflected in the dashboard, categorized - as _Payable to Dealer_ or _Recoverable from Dealer_. - -``` -4.5.2.3 Internal Clarification & Approval -``` -- **Action:** - Finance initiates clarification rounds with departments or DD-Lead for mismatched data. -- **System Steps:** - o Uses the **Work Notes** section for comments, tagging users like _@DD-_ - _Lead_ , _@Legal_ , or _@Admin_. - o Tracks status as _Pending Clarification_ until resolved. - o After reconciliation, Finance locks the summary and updates case status - to _Ready for Approval_. - -``` -4.5.2.4 Final Review & Dealer Confirmation -``` -- **Action:** - Finance conducts an internal review of the consolidated settlement and initiates a - financial discussion with the dealer. -- **System Steps:** - o Reviews summary details on-screen with Legal and DD-Lead. - o Records dealer’s acknowledgment via Work Note or attached email - confirmation. - o Once confirmed, proceeds to payment verification. - - -``` -4.5.2.5 Payment Processing & Record Update -``` -- **Action:** - Finance executes the financial transaction (payment to or recovery from dealer). -- **System Steps:** - o Enters **Mode of Payment** , **Transaction Reference Number** , **Date** , and **Remarks**. - o Uploads proof of payment (RTGS confirmation or bank statement). - o Marks case as _Finance Approved_ and sends completion notification to DD-Admin - and Legal. - o System automatically updates the **Progress Timeline** and **Audit Trail**. - -``` -4.5.2.6 F&F Completion & Closure -``` -- **Action:** - Finance reviews all entries, confirms ledger reconciliations, and marks case - as **Completed**. -- **System Steps:** - o Locks financial data and supporting artefacts. - o Status changes to _Closed – F&F Completed_. - o Final confirmation sent to all stakeholders — DD-Lead, NBH, DD-Head, Legal, and - DD-Admin. - o Finance Dashboard updates counters under “Completed Cases.” - -## 5 System Features & Requirements - -Here, we describe the **system features** along with their respective **Width** and **Depth** to provide -complete visibility of each requirement. - -The **Width** defines the **functional coverage** of a feature — outlining what the feature does, -its **boundaries, use cases, and user interactions**. It answers the question: _“What scenarios and -actions are covered by this feature?”_ - -The **Depth** captures the **operational and behavioral details** — describing how the feature -behaves through its **logic, workflow, system responses, and edge-case handling**. It answers the -question: _“How does the system execute and respond in these scenarios?”_ - ---- ## 7 Dealer Resignation @@ -1137,44 +367,17 @@ Email communication only (no direct system access). ``` - -``` -For termination cases, dealer upload access is -restricted as per defined governance rules. -DD-Admin/DD- -ASM -``` ``` Creates resignation request in system, uploads dealer’s email, validates data, and submits for approval. ``` ``` -Full access for initiation. -``` -``` -DD-Head / ZBH -/ NBH -``` -``` Receives system notification upon submission; can view request details and attached resignation communication. ``` ``` -Read-only visibility at -initiation stage. -``` -``` -System -(Automation) -``` -``` -Validates dealer code, generates request ID, logs -submission details, and triggers workflow -routing. -``` -``` Background operation. ``` ### 7.2 Resignation Management Dashboard @@ -1226,52 +429,7 @@ remarks** and are logged for audit purposes. action items. o Status changes trigger notifications to the next role in sequence. -**7.2.4 Personas-Wise Accessibility & Visibility** -``` -Persona Accessibility Visibility Scope -DD-Admin/DD-ASM Can create new resignation requests, view all -regional cases, and track progress. -``` -``` -Full access -within Area. -``` - -``` -ASM / DD-Lead Can review, comment, and forward resignation -requests to next approver. -``` -``` -Assigned -requests only. -ZBH / NBH / Legal / -Finance -``` -``` -Can view status, add remarks, and take action at -their respective workflow stage. -``` -``` -Role-based -access by stage. -System -(Automation) -``` -``` -Updates request stages, triggers notifications, and -logs all workflow events. -``` -``` -Background -process. -Regional Business -Manager (RBM) -``` -``` -The RBM reviews and validates dealer lifecycle -requests , and has review, send back, and -escalation authority as per workflow stage. ``` ### 7.3 Resignation Details & Review @@ -1316,40 +474,6 @@ reviewers have complete visibility before making decisions. o **Resignation Details:** Summarizes the **Resignation Reason** and **Dealer Voice** **(Customer Description)** derived from the dealer’s email submission. -**7.3.4 4. Personas-Wise Accessibility & Visibility** - -``` -Persona Accessibility Visibility Scope -DD-Admin Read-only at this stage; may receive “Send -Back” tasks for correction. -``` -``` -Region-specific -requests. -``` - -``` -ASM / DD-Lead / DD- -Head / ZBH / NBH -``` -``` -Can review, approve, withdraw, or forward -resignations to next stage; can add remarks -and push to F&F. -``` -``` -Requests assigned to -their hierarchy. -``` -``` -System (Automation) Logs workflow actions, timestamps, and user -activity; triggers stage transitions and -notifications. -``` -``` -Background -operation. -``` ### 7.4 Resignation Request Review & Action Management **7.4.1 Functionality Scope** @@ -1496,93 +620,6 @@ ASM to NBH and Legal — uses Work Notes to record discussions, queries, clarifications, and final decisions related to the resignation case will be submitted from Approval, Withdrawal or send back action. -**7.4.5 Personas-wise Accessibility & Visibility** - -``` -Role / Persona Responsibilities System Access & Actions -``` - -``` -Dealer (External) Submits resignation via email on company -letterhead. -``` -``` -No portal access; -communicates via email -only. -DD-ASM (Area -Sales Manager) -``` -``` -Initiates workflow by uploading resignation -documents, adding dealer background, and -forwarding case. -``` -``` -Create, view, and -comment rights. -``` -``` -RBM + DD-ZM Conduct discussion with dealer, upload -remarks, and validate reasons. -``` -``` -Approve, Send Back, -Withdraw, upload -documents. -ZBH (Zonal -Business Head) -``` -``` -Validate business impact; forward decision -to DD Lead. -``` -``` -Approve, Send Back, -Withdraw rights. -DD Lead Consolidates inputs; prepares final -presentation with recommendations for -NBH. -``` -``` -Approve, Send Back, -Withdraw, upload -presentation. -NBH (National -Business Head) -``` -``` -Takes final decision; puts remarks in system; -triggers Legal action. -``` -``` -Final Approval rights. -``` -``` -Legal Uploads Resignation Acceptance Letter ; -communicates queries in Work Notes. -``` -``` -Upload and comment -rights; visible to DD Admin -& ASM. -DD Admin Reviews uploaded acceptance letter; shares -with ASM for final dealer communication. -``` -``` -Read & Download access. -``` -``` -System -(Automation) -``` -``` -Triggers notifications, maintains SLA -counters, logs Work Notes & Audit history. -``` -``` -Automated access only. -``` ### 7.5 Resignation Progress Tracker @@ -1625,138 +662,6 @@ mapped to their respective stages. review. -**7.5.4 Personas-wise Accessibility & Visibility** - -``` -Persona / -Role -``` -``` -Access Level Permissions / Actions Visibility -``` -``` -DD-ASM / -AM -``` -``` -Area Level Uploads the dealer’s resignation -email and supporting PPT; -initiates forwarding for ASM -review. -``` -``` -Can view current stage and -all preceding -remarks/documents. -``` -``` -RBM + DD- -ZM -``` -``` -Regional / Zonal -Level -``` -``` -Reviews and discusses -resignation with the dealer; -provides comments and -forwards to ZBH; can send back -or withdraw. -``` -``` -Can view all area-level -details, remarks, and -uploaded documents. -``` -``` -ZBH Zonal Business -Head -``` -``` -Reviews RBM and DD-ZM -inputs; adds zonal remarks and -forwards to DD-Lead for review. -``` -``` -Can view complete case -details up to current stage. -``` -``` -DD-Lead National -Coordination -Level -``` -``` -Consolidates information; -prepares resignation -presentation with -recommendations; forwards to -NBH. -``` -``` -Can view entire history, -remarks, and document -trail. -``` -``` -NBH National -Business Head -``` -``` -Reviews final presentation; adds -decision remarks; approves -resignation for legal processing. -``` -``` -Can view and comment on -all prior approvals and -documents. -Legal Post-Approval -Level -``` -``` -Uploads the Resignation -Acceptance Letter and closes -the case; can add queries via -Work Notes. -``` -``` -Gains access only after NBH -approval; visible to DD- -Admin upon upload. -``` -``` -DD-Admin Administrative -Level -``` -``` -Reviews and distributes -acceptance letter internally; -ensures completion record -update. -``` -``` -Can view full progress -history and all final -documentation. -``` -``` -All Higher -Roles -(Read- -only) -``` -``` -Oversight Access for viewing status, -remarks, and uploaded files for -compliance or reporting. -``` -``` -View-only access for all -resignation-related data. -``` - ### 7.6 Documents & Audit Trail **7.6.1 Functionality Scope** @@ -1789,98 +694,3 @@ traceability. - Entries in the Audit Trail display both user-driven and automated actions to ensure comprehensive visibility. -**7.6.4 Personas-wise Accessibility & Visibility** - -``` -Persona / -Role -``` -``` -Access Level Visibility & Permissions -``` -``` -DD-ASM / -AM -``` -``` -Area Level Can upload resignation email and initial supporting -documents which is the resignation PPT -RBM + DD- -ZM -``` -``` -Regional / Zonal -Level -``` -``` -Can view all uploaded artefacts and upload discussion or -dealer communication documents. -ZBH Zonal Head Can review attached documents and see all prior uploads -with remarks. -DD-Lead National -Coordination -``` -``` -Can upload resignation presentation and verify uploaded -PPT files for completeness. -NBH National Business -Head -``` -``` -Can view all documents and approval history before -finalizing decision. -Legal Post-Approval Level Uploads final Acceptance Letter , visible to DD-Admin and -field teams. -DD-Admin Administrative -Oversight -``` -``` -Has full view and download access to all documents and -audit logs for closure verification. -``` - ---- - -## 13 Non-Functional Requirements - -``` -Category Requirement -Performance Average response time < 3 seconds for standard operations. -Scalability Should scale horizontally on GCP. -Security JWT tokens, encrypted passwords, HTTPS enforced. -Usability Intuitive UI, consistent icons, and simple navigation. -Reliability 99% uptime target. -Backup & Recovery Daily database backup and weekly full snapshot. -Compliance Follows RE IT data privacy guidelines. -``` -## 14 Technology Matrix - -``` -Component Specification -Database PGSQL (Managed or local instance) -Application Stack Node.js (Backend) + React.js (Frontend) -Authentication RE SSO Bridge -``` -## 15 Infra requirements & System Hygiene - -``` -Component Specification -Environment QA / Testing -# of Virtual Machines (VMs) 1 -CPU Configuration 4 - Core -Memory (RAM) 16 GB -Disk Size 500 GB -Operating System Ubuntu 24.04 LTS -``` - -``` -Storage Type Cloud -``` -Backup and Recovery - -- Daily incremental and weekly full backups. -- Restore process must not exceed 2 hours. - -## 16 Not in scope - -Anything which comes beyond the scope defined above in terms of Width and depth diff --git a/docs/modular_wise/03_Termination.md b/docs/modular_wise/03_Termination.md index 6f23dee..f400487 100644 --- a/docs/modular_wise/03_Termination.md +++ b/docs/modular_wise/03_Termination.md @@ -1,138 +1,4 @@ -# RE Onboarding & Offboarding System - -# Requirements - -``` -System Requirements Specifications -``` -## 16 - Oct- 2025 - -## Version 1. 4 - - -## Contents - - -- Change Log - - 1.1 Change Log – Version 2.0 - - 1.2 Change Log – Dealer Self-Service Enablement -- 1 System Overview & Problem Statement -- 2 Intended Audience - - 2.1 Business & Functional Users - - 2.2 External & Integrated Stakeholders -- 3 Definitions and Acronyms -- 4 HiFi Wireframes & Flow of Application - - 4.1 Dealer onboarding - Process Flow Overview - - 4.2 Dealer Resignation – Process Flow Overview - - 4.3 Dealer Termination – Process Flow Overview - - 4.4 Dealer Full & Final (F&F) Settlement – Process Flow - - 4.5 Finance Team – Process Flow -- 5 System Features & Requirements -- 6 Dealer onboarding - - 6.1 Dealership Application Form - - 6.2 SSO Login - - 6.3 Dashboard - - 6.4 Opportunity & Non Opportunity - - 6.5 Questionnaire Response - - 6.6 Shortlisting Process - - 6.7 Shortlisted Applicants - - 6.8 Application Detail View - - 6.9 Interview Scheduling & Coordination - - 6.10 Interview Evaluation & Feedback Management - - 6.11 Interview Feedback & Evaluation Summary - - 6.12 Application Approval & Rejection Workflow - - 6.13 Work Notes & Internal Communication Trail - - 6.14 System Notifications & Alerts - - 6.15 FDD (Financial Due Diligence) & Finance Module - - 6.16 LOI Approval & Issuance - - 6.17 Dealer Code Generation, Architectural Work & Statutory Documentation............ - - 6.18 LOA Issuance, Essential Operating Requirements & Inauguration - - 6.19 Essential Operating Requirements (EOR) Checklist - - 6.20 Progress Tracker....................................................................................................... - - 6.21 Central Document Repository - - 6.22 Audit Trail & Activity Log.......................................................................................... -- 7 Dealer Resignation - - 7.1 Dealer Resignation Request (Initiation) - - 7.2 Resignation Management Dashboard - - 7.3 Resignation Details & Review - - 7.4 Resignation Request Review & Action Management - - 7.5 Resignation Progress Tracker - - 7.6 Documents & Audit Trail -- 8 Termination - - 8.1 Create Termination Request - - 8.2 Termination Ticket overview - - 8.3 Termination Approval & Review Process - - 8.4 Termination Progress Timeline -- 9 Admin Section - - 9.1 Master Configuration – Organization - - 9.2 Zone, Region & Area Configuration - - 9.3 Roles & permissions - - 9.4 SLA Configuration & Escalation Management - - 9.5 Email & Letter Templates Management - - 9.6 Opportunity Management (Geography & Window Setup) -- 10 F&F Case - - 10.1 F&F Settlement Progress Timeline - - 10.2 Department Responses -- 11 Finance Dashboard - - 11.1 Finance Dashboard Page - - 11.2 F&F Settlement Module -- 12 Dealer Persona - - 12.1 Dealer Resignation - - 12.2 Dealer Constitutional Change Management -- 13 Non-Functional Requirements -- 14 Technology Matrix -- 15 Infra requirements & System Hygiene -- 16 Not in scope - - -## Change Log - -### 1.1 Change Log – Version 2.0 - -**Module:** Dealer Onboarding & Offboarding System -**Change Type:** Clarifications, Role Alignment & Access Control Enhancements -**Scope Enhancement :** Dealer Role and Access control -**Change demarcation** : Highlighted in Yellow -**Changes suggested by** : Ashok & Tariq -**Changed performed by** : Rohit Mandiwal -**Changes done on** : 31 - Dec- 2025 - -**1.1.1 Notification Channel Enhancement** - -- Added **WhatsApp as a supported notification channel** for reminders and workflow - communications (e.g., questionnaire completion and status updates), while restricting - sensitive document sharing to email only. - -**1.1.2 LOI Governance & Communication Clarifications** - -- Clarified that the **Finance team is not the decision-making authority** for LOI issuance - and is responsible only for financial validation. -- Confirmed that **LOI documents are shared exclusively via official email** and not through - WhatsApp. -- Clarified that **LOA issuance is a parallel statutory activity** and is **not dependent on** - **infrastructure readiness**. - -**1.1.3 Dealer Code Creation Control** - -- Clarified that **Dealer Codes (SAP Master) are created only upon explicit trigger by the** - **DD Admin** , and not through automatic system generation. - -**1.1.4 LOA & EOR Sequencing Correction** - -- Corrected the workflow sequence to ensure that **LOA is issued prior to initiating the** - **EOR checklist** , with EOR serving as the final readiness validation before go-live. - -**1.1.5 Dealer Resignation Access & Workflow Enhancements** - -- Enabled **dealer portal access** for initiating resignation requests and uploading required - information. - - -- Clarified that the **Legal team issues the Resignation Acceptance Letter** in all cases. -- Expanded review authority to allow **ZBH, DD Lead, DD Head, and NBH** to **Send Back or** - **Revoke resignation requests** , with communication routed through **Work Notes**. -- Confirmed that **Full & Final (F&F) settlement is triggered strictly on the Last Working** - **Day (LWD)** and not based on approval date. +# Offboarding System **1.1.6 Termination Workflow Governance Updates** @@ -160,77 +26,8 @@ System Requirements Specifications **scenarios only**. - Confirmed that **dealer portal access is revoked after resignation or termination**. -**1.1.9 Terminology & Documentation Corrections** - -- Clarified **KT Matrix as Kepner Tregoe Matrix** for consistency and correctness. - -**1.1.10 Super Admin Role Introduction** - -- Introduced a **Super Admin (Master Role)** with end-to-end access and workflow control - across modules. -- Defined segregation of duties by splitting Super Admin into **two DD Admin roles** with - clearly scoped responsibilities. -### 1.2 Change Log – Dealer Self-Service Enablement - -**Version:** v2. -**Section Impacted:** Section 12 – Dealer Portal (12.1 onwards) -**Module:** Dealer Onboarding & Offboarding System -**Change Type:** Dealer Feature Enablement (Section 12 onwards) -**Scope Enhancement :** Dealer Role and Access control -**Change demarcation** : Highlighted in Yellow -**Changes suggested by** : Ashok & Tariq -**Changed performed by** : Rohit Mandiwal -**Changes done on** : 5 - Jan- 2026 - -**1.2.1 Introduction of Dealer Portal** - -- Introduced a **Dealer Portal capability** enabling onboarded dealers to initiate and track - post-onboarding lifecycle requests through the portal. -- Dealer actions are governed by **role-based access controls** , approval hierarchies, and - audit mechanisms. - -**1.2.2 Dealer Resignation Enablement** - -- Enabled **dealer-initiated resignation requests** at outlet level via the portal. -- Added structured resignation submission with: - o Last Operational Date (Sales & Services) - o Reason for resignation - o Mandatory document readiness guidance -- Enabled **dealer withdrawal option** for resignation requests **only until the case is** - **pending with NBH**. -- Clarified that **Legal team issues the Resignation Acceptance Letter** post approvals. -- Ensured **F&F settlement is triggered based on Last Working Day (LWD)** and not - approval date. -- Restricted dealer portal access **post resignation closure**. - -**1.2.3 Dealer Relocation Request Enablement** - -- Enabled dealers to **initiate and track relocation requests** through a guided workflow. -- Added support for: - o Manual or map-based location entry - o Distance calculation from existing location - o Property type selection and expected relocation date - - -- Introduced **document-driven relocation validation** , including statutory, legal, property, - and infrastructure documents. -- Implemented **multi-level approval workflow** with Work Notes–based communication - and audit trail. -- Ensured dealer has **view and upload access only** , with approvals retained by RE - stakeholders. - -**1.2.4 Dealer Constitutional Change Enablement** - -- Enabled dealers to **initiate constitutional change requests** post onboarding. -- Supported all approved constitution change scenarios: - o Proprietorship, Partnership, LLP, and Private Limited permutations -- Implemented **dynamic document requirement determination** based on target - constitution. -- Explicitly confirmed **no OCR-based document validation** ; all validations are manual and - role-driven. -- Ensured statutory compliance via Legal review before master data updates. **1.2.5 Post-Exit Access Control** @@ -238,142 +35,6 @@ System Requirements Specifications completed. -## 1 System Overview & Problem Statement - -**1.1.1 System Overview** - -The **Dealer Onboarding and Offboarding System** for **Royal Enfield (RE)** is designed to **digitize, -standardize, and streamline** the complete dealer lifecycle — from **application and -evaluation** to **approval, resignation, termination, and full-and-final (F&F) settlement**. - -At present, the process operates through **manual coordination** , involving **emails, spreadsheets, -and physical documentation** , which makes it difficult to maintain visibility, accountability, and -consistency across teams. - -The proposed solution introduces a **centralized digital platform** that brings all stakeholders onto -a single workflow. It ensures that every stage — **onboarding, operational approvals, financial -diligence, legal validation, and final closure** — follows a **structured and traceable process**. - -The system integrates seamlessly with existing RE applications such as **SSO** , **SAP** , and **Finance -modules** , providing **role-based access** , **real-time tracking** , and **secure document management**. -It also offers **automated workflows** , **configurable approval hierarchies** , and **AI-assisted decision -support** to improve efficiency and reduce turnaround time. - -By moving to a digital workflow, Royal Enfield will achieve higher levels of **process -efficiency** , **data accuracy** , and **transparency** , ensuring faster decision-making and stronger -control over the dealer network lifecycle. - -## 2 Intended Audience - -This document is intended for all stakeholders involved in the **design, implementation, approval, -and operational use** of the **Dealer Onboarding and Offboarding System** at **Royal Enfield (RE)**. - -The following user personas and roles are part of the system: - -### 2.1 Business & Functional Users - -**2.1.1 Dealer Development (DD) Team** - -- **Super Admin (Master Role):** - The **Super Admin has unrestricted access** across all modules and workflows, with - authority to **configure, override, and influence workflow behavior** at every level. - - -``` -The Super Admin role is segregated into two DD Admin roles , each with clearly defined -scopes to ensure segregation of duties and governance control. -``` -- **DD-Admin:** System administrator responsible for user setup, role mapping, hierarchy - configuration, and workflow management. -- **DD-AM (Area Manager):** Reviews and manages applications within assigned regions; - performs preliminary screening. -- **DD-ZM (Zonal Manager):** Conducts the first level of dealer evaluation along with RBM; - prepares presentation decks for final interviews. -- **DD-Lead:** Reviews zonal evaluations, validates recommendations, and forwards - shortlisted applicants for senior-level approval. -- **DD-Head: DD Head** is engaged in the **final review and approval** of shortlisted dealer - applications before the **NBH interview** , and later **oversees final verification and LOI** - **issuance** after all evaluations are complete. - -**2.1.2 Regional Sales & Business Team** - -- **RBM (Regional Business Manager):** Participates in early-stage evaluations, provides - ground-level business insights, and recommends suitable candidates. -- **ZBH (Zonal Business Head):** Conducts the second-level review along with DD-Lead; - provides strategic feedback on market and location viability. -- **NBH (National Business Head):** Holds final authority for approval or rejection of dealer - onboarding; reviews consolidated feedback from all levels. - -**2.1.3 Supporting Departments** - -- **Finance Team:** Reviews financial due diligence reports, validates F&F (Full and Final) - settlements, and manages monetary closure during offboarding. -- **Legal Team:** Reviews agreements, issues **Letters of Intent (LOI)** or **Termination Letters** , - and ensures all documentation aligns with company policy. -- **Brand Experience / Architecture Team:** Manages **EOR (Essential Operating** - **Requirements)** and ensures adherence to brand and infrastructure standards. - -**2.1.4 Dealers** - -Once a dealer is **successfully onboarded and activated in the system** , the Dealer role is enabled -with controlled, role-based access to initiate and track select lifecycle requests. This -enhancement introduces **structured self-service capabilities for dealers** , while ensuring all -actions remain governed by defined validations, internal reviews, and approval workflows as per -RE standards. - -The Dealer role is enabled to perform the following activities: - - -- **Resignation Initiation** - -``` -The dealer can initiate the resignation process directly through the portal , submit the -reason for exit, and track the status of the request across the defined review, clearance, -and closure stages. -``` -- **Relocation Request Submission** - -``` -The dealer can submit a relocation request in scenarios where there is an intent to shift -the dealership from the current location to a new proposed location. The request is -routed for internal feasibility assessment, validation, and management approval before -execution. -``` -- **Change in Constitution Request** - -``` -The dealer can initiate a Change in Constitution request to seek approval from RE -management for ownership or structural changes within the dealership. Upon approval, -the dealer may proceed with the legally compliant transition. -``` -``` -Supported Change in Constitution scenarios include: -``` -``` -o Proprietorship (Single Owner) → Partnership -o Proprietorship → LLP (Limited Liability Partnership) -o Proprietorship → Private Limited -o Partnership → LLP -o Partnership → Private Limited -o Private Limited → LLP -o Private Limited → Partnership -``` -All dealer-initiated requests are subject to **defined validations, mandatory document -submissions, role-based reviews, and approvals**. The dealer’s access is **restricted to initiation, -document upload, and status visibility** , with **final decision-making authority retained by -authorized internal stakeholders of RE** - -### 2.2 External & Integrated Stakeholders - -**2.2.1 FDD (Financial Due Diligence Partner)** - -External agency responsible for assessing the applicant’s financial health, verifying credentials, -and uploading due diligence reports into the system. - - -**2.2.2 Dealer / Applicant** -External user who applies for dealership, uploads required documents, participates in -interviews, and later accesses the portal for resignation or closure status. ## 3 Definitions and Acronyms @@ -396,286 +57,7 @@ LOA Letter of Appointment F&F Full and Final (Dealer Settlement) KT Matrix Evaluation Matrix used for scoring applicants ``` -## 4 HiFi Wireframes & Flow of Application -HiFi Wireframes : https://mono-human-93592950.figma.site - -### 4.1 Dealer onboarding - Process Flow Overview - -The **Dealer Onboarding Workflow** outlines the end-to-end sequence through which a dealership -application progresses — from initial registration to final inauguration and operational readiness. - - -**4.1.1 Step-by-Step Process Flow** - -``` -4.1.1.1 Application Initiation -``` -- The **applicant (dealer prospect)** submits an online application through the Dealer - Onboarding Portal. -- The system checks the **location’s availability** in the Royal Enfield dealership network: - o If the location has **no open opportunity** , a **Non-Opportunity Email** is triggered - automatically. - o If an opportunity exists, the applicant receives an **Opportunity Email** with login - credentials and a link to the **Dealer Questionnaire**. - -``` -4.1.1.2 Questionnaire Completion -``` -- The applicant fills out the **comprehensive questionnaire** covering business, infrastructure, - and financial readiness. -- The system auto-scores responses, generating a **Questionnaire Score** and **initial** - **ranking** for that applicant. - - -- Completed applications move to the **Admin review bucket**. -- The system shall trigger automated reminders to users for completing the - questionnaire. These **reminders will be sent through WhatsApp** , to ensure timely - submission. Reminder needs to be configured from Admin. - -``` -4.1.1.3 Admin Validation & Shortlisting -``` -- **DD-Admin** reviews all submitted applications and validates details and attached - documents. -- Based on eligibility, applications are either **shortlisted** for evaluation or **archived** for - future opportunities. -- Shortlisted applications are distributed to respective **zones or regions** for further - assessment. - -``` -4.1.1.4 Interview Evaluation (Multi-Level Process) -``` -- Admin schedules interviews in **Level 1** , **Level 2** , and **Level 3** , as applicable. -- Each interview can be **Virtual or Physical** , with calendar invites sent via Google Calendar. -- Evaluators at each level (DD-ZM, RBM, DD-Lead, ZBH, NBH, DD-Head) record their - feedback through: - o **KT Matrix Scoring** (quantitative) - o **Interview Feedback Form** (qualitative) -- The system consolidates panel feedback and generates an **AI-driven summary and** - **ranking** for decision support. - -``` -4.1.1.5 Financial Due Diligence (FDD) & Finance Review -``` -- Upon shortlisting, the application is assigned to the **FDD Team (external agency)** for - financial validation. -- FDD users, using SSO credentials, can: - o View assigned applications in a restricted interface. - o Upload FDD reports and add remarks in the **Work Notes** section. - o Flag cases of **non-responsiveness** or incomplete data, returning them to Admin. -- The **Finance team** reviews submitted FDD reports, validates findings, and decides - whether the application proceeds to **LOI approval**. The finance team is not the decision - maker for LOI Issuance. - -``` -4.1.1.6 LOI (Letter of Intent) Approval & Issuance -``` -- Based on Finance clearance, **DD-Head and NBH** review and approve the **LOI request**. -- The system tracks document approvals, timestamps, and supporting artefacts. - - -- Once approved, the LOI document is generated, uploaded, and shared **with the** - **applicant via official email communication** and not on WhatsApp -- Notification emails are triggered to all relevant stakeholders. - -``` -4.1.1.7 Dealer Code Generation & Setup -``` -- After LOI issuance, the **DD-Admin triggers** the Dealer Code creation process. Based on - this trigger, the **Dealer Code is created in the SAP Master** and **mapped to the applicant** - within the system. -- The code links all downstream modules, including Architectural, Statutory, and EOR - checklists. - -``` -4.1.1.8 Architectural Work & Statutory Documentation -``` -- Architectural activities are initiated (site plans, layout approvals, branding elements). -- The applicant and assigned Architecture Team upload documents, drawings, and - blueprints. -- In parallel, the applicant uploads **Statutory Documents** such as: - o GST certificate, PAN, Partnership Deed, Firm Registration, Rental/Lease - Agreement, etc. -- Each upload is timestamped and visible with file name, uploader, and document type. - -``` -4.1.1.9 Payment Verification & Finance Validation -``` -- Applicant uploads proof of advance payment or security deposit. -- The **Finance team** verifies payment details (transaction ID, amount, and bank record). -- Status is updated to **Verified** once the payment is reconciled. -- Verified payment triggers readiness for final operational setup. - -``` -4.1.1.10 Essential Operating Requirements (EOR) Checklist -``` -- All functional teams (Sales, Service, IT, Finance, Training, Architecture) verify their - respective readiness parameters. -- Progress is tracked through a **completion bar** until 100% EOR compliance is achieved. -- The **EOR checklist is initiated only after LOA issuance**. All functional teams verify their - respective readiness parameters, and progress is tracked until **100% EOR compliance** is - achieved. - -``` -4.1.1.11 LOA (Letter of Authorization) & Final Go-Live -``` -- After LOI issuance and Dealer Code generation, the **Letter of Authorization (LOA) is** - **generated and approved by NBH and DD-Head**. Upon successful LOA issuance, the - - -``` -application proceeds to the Essential Operating Requirements (EOR) checklist for final -readiness verification. -``` -- Final verification includes: - -``` -o EOR document review -o Brand readiness assessment -o Site validation and inspection -``` -- The **LOA** officially authorizes the dealership to operate under Royal Enfield. - -``` -4.1.1.12 Inauguration & Closure -``` -- Post-authorization, the **Inauguration** event is scheduled and logged. -- Completion of inauguration marks the dealership as **Active** in the system. - -``` -4.1.1.13 System-Driven Governance & Audit -``` -- Each stage automatically logs: - o User action, timestamp, and remarks - o Uploaded artefacts and version control - o Notifications sent and approvals received -- The entire lifecycle remains accessible under **Audit Trail** for future reference, compliance, - or offboarding workflows. - -### 4.2 Dealer Resignation – Process Flow Overview - -**4.2.1.1 Overview** - -``` -The Dealer Resignation Process manages the structured offboarding of a dealership initiated -by the dealer. The process begins when a dealer formally submits their resignation via -email to the Area Sales Manager (ASM) , after which the workflow transitions into the -system-managed approval sequence. -``` -``` -Dealer resignation requests are initiated by the dealer through the portal and subsequently -reviewed and processed by Admin, Finance, Legal, and relevant business stakeholders. -``` -``` -This flow ensures that each resignation is verified, discussed, and approved across all -required levels — maintaining proper documentation, compliance, and traceability until the -final Legal Acceptance Letter is issued. -``` - -**4.2.2 Step-by-Step Process Flow** - -``` -4.2.2.1 Dealer Initiation -``` -- The dealer submits a **formal resignation email** on the dealership’s official letterhead to - the **ASM**. -- The resignation reason must be clearly stated (e.g., personal, financial, business - restructuring). -- The **dealer is provided portal access** to initiate the resignation request directly through - the system. The dealer submits resignation details, reason for exit, and proposed - timeline via the portal, after which the request enters the internal review and clearance - workflow. - -``` -4.2.2.2 ASM Review -``` -- The **ASM** reviews the dealer’s resignation request and supporting letter. -- Uploads the **resignation email** and **dealer’s letterhead document** onto the portal. -- Adds remarks summarizing the discussion and reason for resignation. -- Forwards the request to **RBM + DD-ZM** for evaluation. - -``` -4.2.2.3 RBM + DD-ZM Joint Evaluation -``` -- The **Regional Business Manager (RBM)** and **Dealer Development Zonal Manager (DD-** - **ZM)** review the uploaded documents. -- Conduct a joint discussion with the dealer to confirm the intent and understand any - issues. -- Uploads the **Minutes of Meeting (MOM)** or discussion summary. -- Adds comments and recommendations before forwarding to **Zonal Business Head** - **(ZBH)**. -- Actions available at this stage: - o **Approve** → Send forward for next-level review - o **Send Back for Clarification** → Returns to ASM - o **Withdraw** → Cancels the request (with remarks logged) - -``` -4.2.2.4 ZBH Review -``` -- The **Zonal Business Head (ZBH)** reviews the resignation summary and all remarks. -- Adds their comments and recommendations. -- Forwards the request to **DD-Lead** through the system. -- Worknote is updated automatically to reflect action and timestamp. -- The resignation request is reviewed by authorized business stakeholders, - including **RBM, ZBH, and DD-Head**. During the review stage, the **ZBH is authorized to** - - -``` -Send Back or Revoke the resignation request for clarification or correction. Send Back -actions are communicated to the dealer and internal teams through Work Notes , with -mandatory remarks captured for traceability. -``` -``` -4.2.2.5 DD-Lead Review -``` -- The **DD-Lead** consolidates all discussions, documents, and feedback. -- Prepares a **Resignation Presentation** with recommendations and supporting data. -- Uploads the presentation to the portal. -- Forwards the case to **NBH** for final decision. -- The resignation request is reviewed by the **DD-Lead and DD-Head**. At this stage, both - roles are authorized to **Send Back or Revoke** the resignation request for clarification, - correction, or reconsideration. **Send Back actions are communicated through Work** - **Notes** , with **mandatory remarks** recorded for audit and traceability. - -``` -4.2.2.6 NBH Final Approval -``` -- The **National Business Head (NBH)** reviews the entire resignation dossier. -- Adds final remarks with one of the following outcomes: - o **Approve** → Case moves automatically to Legal for letter issuance. - o **Send Back for Clarification** → Returns to DD-Lead or ZBH for revalidation. - o **Hold** → Temporarily pauses the process pending further discussion. -- Upon approval, the system triggers a **Worknote Notification** to DD-Lead, RBM, ZBH, and - Finance teams. -- The resignation request is reviewed by the **NBH** , who may **Approve, Send Back, or** - **Revoke** the request based on business considerations. Any **Send Back or Revoke action** - **must be accompanied by remarks recorded in Work Notes** , ensuring transparent - communication and governance. - -``` -4.2.2.7 Legal Acceptance Letter -``` -- Once approved by **NBH** , the request is **auto-assigned to the Legal team**. -- Legal verifies the uploaded resignation and issues a **Resignation Acceptance Letter**. -- The letter is uploaded to the portal, visible to all relevant personas including **DD-** - **Admin** and **DD-AM**. -- Legal can also raise clarifications through worknotes if required. -- Upon completion of all approvals, the **Legal team issues the official Resignation** - **Acceptance Letter** and shares it with the dealer through authorized communication - channels. - - -``` -4.2.2.8 DD-Admin Closure -``` -- The **DD-Admin** downloads and shares the final **Resignation Acceptance Letter** with the - dealer. -- Marks the resignation as completed and triggers the **F&F (Full and Final) process** by - forwarding the case to the Finance team. -- The **Full & Final (F&F) settlement process is initiated only on the Last Working Day** - **(LWD) of the dealership**. The system shall **enable and trigger the F&F workflow strictly** - **based on the LWD date** , and **not based on the resignation approval date**. ### 4.3 Dealer Termination – Process Flow Overview @@ -841,211 +223,6 @@ transparently reconciled, verified, and documented before closure. - Notification is sent to the **Finance Team** and all functional departments to begin the clearance process. -``` -4.4.2.2 Department-wise Response Collection -``` -- The system automatically prompts all mapped **functional departments (16 in total)** to - submit their clearance inputs — including NOC, payables, recoveries, and remarks. -- Each department updates: - o Financial dues (if any) - o Clearance confirmation (NOC) - o Supporting document uploads (e.g., debit note, invoice copy) -- The system dynamically updates progress (e.g., _12/16 Departments Responded_ ) with - color-coded indicators: - o 🟢 **No Dues** – Cleared - - -``` -o 🔴 Dues Pending – Outstanding financial liability -o ⚪ Pending – Awaiting department input -``` -- SLA-based reminders are auto-triggered for pending responses nearing the deadline. - -``` -4.4.2.3 Finance Summary Consolidation -``` -- Once all departments respond, the **DD-Admin Team** consolidates inputs into the **Final** - **F&F Summary Sheet** , which consists of: - o **Payables to Dealer** (e.g., refundable deposits, reimbursements) - o **Receivables from Dealer** (e.g., outstanding invoices, recoveries) - o **Deductions** (policy penalties, non-compliance adjustments) -- At this stage, **department-claimed amounts are frozen** and become read-only for - departments. -- Finance does **not overwrite department claim values**. Instead, Finance validates each row - in a dedicated validation layer by recording: - - Finance decision (Accepted / Partially Accepted / Rejected / Under Clarification) - - Finance-validated amount - - Variance amount and mandatory variance reason (if changed) - - Supporting proof/document -- The system automatically calculates: - - Net Settlement = Total Payables – Total Receivables – Total Deductions - - Final totals are computed from **finance-validated values only**. -- Status updates to _Finance Summary Prepared_ once complete. - -``` -4.4.2.4 Internal Review & Clarification -``` -- The **Finance Team** may use the **Work Note** section to raise clarifications to **DD-** - **Lead** , **Legal** , or concerned departments. -- If discrepancies exist (e.g., mismatched values or missing NOCs), the case remains _Under_ - _Clarification_ until resolved. -- Once validated, Finance locks the summary for further edits. - -``` -4.4.2.5 Dealer Discussion & Acknowledgment -``` -- The **Finance Team** , along with **Legal** and **DD-Lead** , discusses the settlement summary - with the dealer. -- Dealer acknowledgment is captured either via written confirmation or attached email - communication. -- The case then proceeds for **Final Finance Approval**. - -``` -4.4.2.6 Final Finance Approval & Payment Processing -``` -- The **Finance Team** reviews the approved summary and enters payment or recovery - details: - o **Transaction Type:** RTGS / NEFT / Cheque - o **Transaction ID & Date** - o **Bank Name & Account Details** (auto-fetched from dealer profile) - o **Settlement Remarks** -- Finance takes one of three actions: - - -``` -o Approve Settlement → Marks the case as “Finance Approved.” -o Request Clarification → Sends query to DD-Lead or Admin. -o Reject Summary → Returns for re-verification. -``` -- Upon approval, notifications are sent to DD-Admin and Legal for record update. - -``` -4.4.2.7 F&F Completion & Closure -``` -- Once approved, the case is automatically marked **Completed** , and the **Finance** - **Dashboard** updates status as _F&F Closed_. -- The **Settlement Proof** (e.g., payment confirmation or recovery adjustment) is uploaded - by Finance. -- The **DD-Admin** communicates official closure to the dealer and archives all artefacts. -- System triggers final alerts to DD-Lead, NBH, and Legal confirming completion. -- The case is archived in the **Audit Trail** for future reference. - -### 4.5 Finance Team – Process Flow - -``` -4.5.1.1 Overview -``` -The **Finance Team Process Flow** governs all financial activities related to dealer lifecycle -management — from **security deposit validation at onboarding** to **final settlement at -resignation or termination**. -It ensures complete financial traceability, proper verification of payments, and compliance with -Royal Enfield’s financial governance standards. -The process flow integrates with **Admin, Legal, Dealer Development (DD)** , and **Departmental -Modules** , ensuring accurate financial updates and timely closure of all financial transactions. - -**4.5.2 Step-by-Step Process Flow** - -``` -4.5.2.1 Security Deposit Validation (Onboarding Stage) -``` -- **Trigger:** - Initiated when a new dealer’s onboarding application reaches the Finance stage after - DD approval. -- **Action:** - The **Finance Team** verifies the **Security Deposit** payment made by the dealer - via **RTGS/NEFT** or other approved channels. -- **Outcome:** - o Verified deposits are marked as _Approved_ , triggering system notifications to DD- - Admin and DD-Lead. - - -``` -o The verified payment data is stored permanently in the dealer’s financial profile -for audit and reference. -``` -``` -4.5.2.2 Financial Summary Preparation -``` -- **Action:** - Once departmental inputs are received, Finance consolidates all data into the **F&F** - **Summary Sheet**. -- **System Steps:** - o Segregates entries under: - ▪ **Payables to Dealer** (e.g., refundable deposits, reimbursements) - ▪ **Receivables from Dealer** (e.g., outstanding payments, penalties) - ▪ **Deductions** (e.g., policy recoveries, warranty holdbacks) - o The system auto-calculates: - o Net Settlement = Total Payables – Total Receivables – Deductions - o Finance validates each record, uploads supporting documents (receipts, invoices, - credit notes), and adds remarks. -- **Outcome:** - The computed **Net Settlement Amount** is reflected in the dashboard, categorized - as _Payable to Dealer_ or _Recoverable from Dealer_. - -``` -4.5.2.3 Internal Clarification & Approval -``` -- **Action:** - Finance initiates clarification rounds with departments or DD-Lead for mismatched data. -- **System Steps:** - o Uses the **Work Notes** section for comments, tagging users like _@DD-_ - _Lead_ , _@Legal_ , or _@Admin_. - o Tracks status as _Pending Clarification_ until resolved. - o After reconciliation, Finance locks the summary and updates case status - to _Ready for Approval_. - -``` -4.5.2.4 Final Review & Dealer Confirmation -``` -- **Action:** - Finance conducts an internal review of the consolidated settlement and initiates a - financial discussion with the dealer. -- **System Steps:** - o Reviews summary details on-screen with Legal and DD-Lead. - o Records dealer’s acknowledgment via Work Note or attached email - confirmation. - o Once confirmed, proceeds to payment verification. - - -``` -4.5.2.5 Payment Processing & Record Update -``` -- **Action:** - Finance executes the financial transaction (payment to or recovery from dealer). -- **System Steps:** - o Enters **Mode of Payment** , **Transaction Reference Number** , **Date** , and **Remarks**. - o Uploads proof of payment (RTGS confirmation or bank statement). - o Marks case as _Finance Approved_ and sends completion notification to DD-Admin - and Legal. - o System automatically updates the **Progress Timeline** and **Audit Trail**. - -``` -4.5.2.6 F&F Completion & Closure -``` -- **Action:** - Finance reviews all entries, confirms ledger reconciliations, and marks case - as **Completed**. -- **System Steps:** - o Locks financial data and supporting artefacts. - o Status changes to _Closed – F&F Completed_. - o Final confirmation sent to all stakeholders — DD-Lead, NBH, DD-Head, Legal, and - DD-Admin. - o Finance Dashboard updates counters under “Completed Cases.” - -## 5 System Features & Requirements - -Here, we describe the **system features** along with their respective **Width** and **Depth** to provide -complete visibility of each requirement. - -The **Width** defines the **functional coverage** of a feature — outlining what the feature does, -its **boundaries, use cases, and user interactions**. It answers the question: _“What scenarios and -actions are covered by this feature?”_ - -The **Depth** captures the **operational and behavioral details** — describing how the feature -behaves through its **logic, workflow, system responses, and edge-case handling**. It answers the -question: _“How does the system execute and respond in these scenarios?”_ - ---- ## 8 Termination @@ -1577,49 +754,3 @@ only) ``` View SCN and Termination Letter post-issuance. View Only ``` - ---- - -## 13 Non-Functional Requirements - -``` -Category Requirement -Performance Average response time < 3 seconds for standard operations. -Scalability Should scale horizontally on GCP. -Security JWT tokens, encrypted passwords, HTTPS enforced. -Usability Intuitive UI, consistent icons, and simple navigation. -Reliability 99% uptime target. -Backup & Recovery Daily database backup and weekly full snapshot. -Compliance Follows RE IT data privacy guidelines. -``` -## 14 Technology Matrix - -``` -Component Specification -Database PGSQL (Managed or local instance) -Application Stack Node.js (Backend) + React.js (Frontend) -Authentication RE SSO Bridge -``` -## 15 Infra requirements & System Hygiene - -``` -Component Specification -Environment QA / Testing -# of Virtual Machines (VMs) 1 -CPU Configuration 4 - Core -Memory (RAM) 16 GB -Disk Size 500 GB -Operating System Ubuntu 24.04 LTS -``` - -``` -Storage Type Cloud -``` -Backup and Recovery - -- Daily incremental and weekly full backups. -- Restore process must not exceed 2 hours. - -## 16 Not in scope - -Anything which comes beyond the scope defined above in terms of Width and depth diff --git a/docs/modular_wise/04_FF_Settlement.md b/docs/modular_wise/04_FF_Settlement.md index 2fc220d..97cf031 100644 --- a/docs/modular_wise/04_FF_Settlement.md +++ b/docs/modular_wise/04_FF_Settlement.md @@ -1,107 +1,6 @@ # RE Onboarding & Offboarding System -# Requirements -``` -System Requirements Specifications -``` -## 16 - Oct- 2025 - -## Version 1. 4 - - -## Contents - - -- Change Log - - 1.1 Change Log – Version 2.0 - - 1.2 Change Log – Dealer Self-Service Enablement -- 1 System Overview & Problem Statement -- 2 Intended Audience - - 2.1 Business & Functional Users - - 2.2 External & Integrated Stakeholders -- 3 Definitions and Acronyms -- 4 HiFi Wireframes & Flow of Application - - 4.1 Dealer onboarding - Process Flow Overview - - 4.2 Dealer Resignation – Process Flow Overview - - 4.3 Dealer Termination – Process Flow Overview - - 4.4 Dealer Full & Final (F&F) Settlement – Process Flow - - 4.5 Finance Team – Process Flow -- 5 System Features & Requirements -- 6 Dealer onboarding - - 6.1 Dealership Application Form - - 6.2 SSO Login - - 6.3 Dashboard - - 6.4 Opportunity & Non Opportunity - - 6.5 Questionnaire Response - - 6.6 Shortlisting Process - - 6.7 Shortlisted Applicants - - 6.8 Application Detail View - - 6.9 Interview Scheduling & Coordination - - 6.10 Interview Evaluation & Feedback Management - - 6.11 Interview Feedback & Evaluation Summary - - 6.12 Application Approval & Rejection Workflow - - 6.13 Work Notes & Internal Communication Trail - - 6.14 System Notifications & Alerts - - 6.15 FDD (Financial Due Diligence) & Finance Module - - 6.16 LOI Approval & Issuance - - 6.17 Dealer Code Generation, Architectural Work & Statutory Documentation............ - - 6.18 LOA Issuance, Essential Operating Requirements & Inauguration - - 6.19 Essential Operating Requirements (EOR) Checklist - - 6.20 Progress Tracker....................................................................................................... - - 6.21 Central Document Repository - - 6.22 Audit Trail & Activity Log.......................................................................................... -- 7 Dealer Resignation - - 7.1 Dealer Resignation Request (Initiation) - - 7.2 Resignation Management Dashboard - - 7.3 Resignation Details & Review - - 7.4 Resignation Request Review & Action Management - - 7.5 Resignation Progress Tracker - - 7.6 Documents & Audit Trail -- 8 Termination - - 8.1 Create Termination Request - - 8.2 Termination Ticket overview - - 8.3 Termination Approval & Review Process - - 8.4 Termination Progress Timeline -- 9 Admin Section - - 9.1 Master Configuration – Organization - - 9.2 Zone, Region & Area Configuration - - 9.3 Roles & permissions - - 9.4 SLA Configuration & Escalation Management - - 9.5 Email & Letter Templates Management - - 9.6 Opportunity Management (Geography & Window Setup) -- 10 F&F Case - - 10.1 F&F Settlement Progress Timeline - - 10.2 Department Responses -- 11 Finance Dashboard - - 11.1 Finance Dashboard Page - - 11.2 F&F Settlement Module -- 12 Dealer Persona - - 12.1 Dealer Resignation - - 12.2 Dealer Constitutional Change Management -- 13 Non-Functional Requirements -- 14 Technology Matrix -- 15 Infra requirements & System Hygiene -- 16 Not in scope - - -## Change Log - -### 1.1 Change Log – Version 2.0 - -**Module:** Dealer Onboarding & Offboarding System -**Change Type:** Clarifications, Role Alignment & Access Control Enhancements -**Scope Enhancement :** Dealer Role and Access control -**Change demarcation** : Highlighted in Yellow -**Changes suggested by** : Ashok & Tariq -**Changed performed by** : Rohit Mandiwal -**Changes done on** : 31 - Dec- 2025 - -**1.1.1 Notification Channel Enhancement** - -- Added **WhatsApp as a supported notification channel** for reminders and workflow - communications (e.g., questionnaire completion and status updates), while restricting - sensitive document sharing to email only. **1.1.2 LOI Governance & Communication Clarifications** @@ -112,24 +11,7 @@ System Requirements Specifications - Clarified that **LOA issuance is a parallel statutory activity** and is **not dependent on** **infrastructure readiness**. -**1.1.3 Dealer Code Creation Control** - -- Clarified that **Dealer Codes (SAP Master) are created only upon explicit trigger by the** - **DD Admin** , and not through automatic system generation. - -**1.1.4 LOA & EOR Sequencing Correction** - -- Corrected the workflow sequence to ensure that **LOA is issued prior to initiating the** - **EOR checklist** , with EOR serving as the final readiness validation before go-live. - -**1.1.5 Dealer Resignation Access & Workflow Enhancements** - -- Enabled **dealer portal access** for initiating resignation requests and uploading required - information. - - -- Clarified that the **Legal team issues the Resignation Acceptance Letter** in all cases. -- Expanded review authority to allow **ZBH, DD Lead, DD Head, and NBH** to **Send Back or** +**Send Back or** **Revoke resignation requests** , with communication routed through **Work Notes**. - Confirmed that **Full & Final (F&F) settlement is triggered strictly on the Last Working** **Day (LWD)** and not based on approval date. @@ -164,155 +46,6 @@ System Requirements Specifications - Clarified **KT Matrix as Kepner Tregoe Matrix** for consistency and correctness. -**1.1.10 Super Admin Role Introduction** - -- Introduced a **Super Admin (Master Role)** with end-to-end access and workflow control - across modules. -- Defined segregation of duties by splitting Super Admin into **two DD Admin roles** with - clearly scoped responsibilities. - - -### 1.2 Change Log – Dealer Self-Service Enablement - -**Version:** v2. -**Section Impacted:** Section 12 – Dealer Portal (12.1 onwards) -**Module:** Dealer Onboarding & Offboarding System -**Change Type:** Dealer Feature Enablement (Section 12 onwards) -**Scope Enhancement :** Dealer Role and Access control -**Change demarcation** : Highlighted in Yellow -**Changes suggested by** : Ashok & Tariq -**Changed performed by** : Rohit Mandiwal -**Changes done on** : 5 - Jan- 2026 - -**1.2.1 Introduction of Dealer Portal** - -- Introduced a **Dealer Portal capability** enabling onboarded dealers to initiate and track - post-onboarding lifecycle requests through the portal. -- Dealer actions are governed by **role-based access controls** , approval hierarchies, and - audit mechanisms. - -**1.2.2 Dealer Resignation Enablement** - -- Enabled **dealer-initiated resignation requests** at outlet level via the portal. -- Added structured resignation submission with: - o Last Operational Date (Sales & Services) - o Reason for resignation - o Mandatory document readiness guidance -- Enabled **dealer withdrawal option** for resignation requests **only until the case is** - **pending with NBH**. -- Clarified that **Legal team issues the Resignation Acceptance Letter** post approvals. -- Ensured **F&F settlement is triggered based on Last Working Day (LWD)** and not - approval date. -- Restricted dealer portal access **post resignation closure**. - -**1.2.3 Dealer Relocation Request Enablement** - -- Enabled dealers to **initiate and track relocation requests** through a guided workflow. -- Added support for: - o Manual or map-based location entry - o Distance calculation from existing location - o Property type selection and expected relocation date - - -- Introduced **document-driven relocation validation** , including statutory, legal, property, - and infrastructure documents. -- Implemented **multi-level approval workflow** with Work Notes–based communication - and audit trail. -- Ensured dealer has **view and upload access only** , with approvals retained by RE - stakeholders. - -**1.2.4 Dealer Constitutional Change Enablement** - -- Enabled dealers to **initiate constitutional change requests** post onboarding. -- Supported all approved constitution change scenarios: - o Proprietorship, Partnership, LLP, and Private Limited permutations -- Implemented **dynamic document requirement determination** based on target - constitution. -- Explicitly confirmed **no OCR-based document validation** ; all validations are manual and - role-driven. -- Ensured statutory compliance via Legal review before master data updates. - -**1.2.5 Post-Exit Access Control** - -- Enforced system rule to **revoke dealer portal access** once resignation or termination is - completed. - - -## 1 System Overview & Problem Statement - -**1.1.1 System Overview** - -The **Dealer Onboarding and Offboarding System** for **Royal Enfield (RE)** is designed to **digitize, -standardize, and streamline** the complete dealer lifecycle — from **application and -evaluation** to **approval, resignation, termination, and full-and-final (F&F) settlement**. - -At present, the process operates through **manual coordination** , involving **emails, spreadsheets, -and physical documentation** , which makes it difficult to maintain visibility, accountability, and -consistency across teams. - -The proposed solution introduces a **centralized digital platform** that brings all stakeholders onto -a single workflow. It ensures that every stage — **onboarding, operational approvals, financial -diligence, legal validation, and final closure** — follows a **structured and traceable process**. - -The system integrates seamlessly with existing RE applications such as **SSO** , **SAP** , and **Finance -modules** , providing **role-based access** , **real-time tracking** , and **secure document management**. -It also offers **automated workflows** , **configurable approval hierarchies** , and **AI-assisted decision -support** to improve efficiency and reduce turnaround time. - -By moving to a digital workflow, Royal Enfield will achieve higher levels of **process -efficiency** , **data accuracy** , and **transparency** , ensuring faster decision-making and stronger -control over the dealer network lifecycle. - -## 2 Intended Audience - -This document is intended for all stakeholders involved in the **design, implementation, approval, -and operational use** of the **Dealer Onboarding and Offboarding System** at **Royal Enfield (RE)**. - -The following user personas and roles are part of the system: - -### 2.1 Business & Functional Users - -**2.1.1 Dealer Development (DD) Team** - -- **Super Admin (Master Role):** - The **Super Admin has unrestricted access** across all modules and workflows, with - authority to **configure, override, and influence workflow behavior** at every level. - - -``` -The Super Admin role is segregated into two DD Admin roles , each with clearly defined -scopes to ensure segregation of duties and governance control. -``` -- **DD-Admin:** System administrator responsible for user setup, role mapping, hierarchy - configuration, and workflow management. -- **DD-AM (Area Manager):** Reviews and manages applications within assigned regions; - performs preliminary screening. -- **DD-ZM (Zonal Manager):** Conducts the first level of dealer evaluation along with RBM; - prepares presentation decks for final interviews. -- **DD-Lead:** Reviews zonal evaluations, validates recommendations, and forwards - shortlisted applicants for senior-level approval. -- **DD-Head: DD Head** is engaged in the **final review and approval** of shortlisted dealer - applications before the **NBH interview** , and later **oversees final verification and LOI** - **issuance** after all evaluations are complete. - -**2.1.2 Regional Sales & Business Team** - -- **RBM (Regional Business Manager):** Participates in early-stage evaluations, provides - ground-level business insights, and recommends suitable candidates. -- **ZBH (Zonal Business Head):** Conducts the second-level review along with DD-Lead; - provides strategic feedback on market and location viability. -- **NBH (National Business Head):** Holds final authority for approval or rejection of dealer - onboarding; reviews consolidated feedback from all levels. - -**2.1.3 Supporting Departments** - -- **Finance Team:** Reviews financial due diligence reports, validates F&F (Full and Final) - settlements, and manages monetary closure during offboarding. -- **Legal Team:** Reviews agreements, issues **Letters of Intent (LOI)** or **Termination Letters** , - and ensures all documentation aligns with company policy. -- **Brand Experience / Architecture Team:** Manages **EOR (Essential Operating** - **Requirements)** and ensures adherence to brand and infrastructure standards. - **2.1.4 Dealers** Once a dealer is **successfully onboarded and activated in the system** , the Dealer role is enabled @@ -331,342 +64,7 @@ The dealer can initiate the resignation process directly through the portal , su reason for exit, and track the status of the request across the defined review, clearance, and closure stages. ``` -- **Relocation Request Submission** -``` -The dealer can submit a relocation request in scenarios where there is an intent to shift -the dealership from the current location to a new proposed location. The request is -routed for internal feasibility assessment, validation, and management approval before -execution. -``` -- **Change in Constitution Request** - -``` -The dealer can initiate a Change in Constitution request to seek approval from RE -management for ownership or structural changes within the dealership. Upon approval, -the dealer may proceed with the legally compliant transition. -``` -``` -Supported Change in Constitution scenarios include: -``` -``` -o Proprietorship (Single Owner) → Partnership -o Proprietorship → LLP (Limited Liability Partnership) -o Proprietorship → Private Limited -o Partnership → LLP -o Partnership → Private Limited -o Private Limited → LLP -o Private Limited → Partnership -``` -All dealer-initiated requests are subject to **defined validations, mandatory document -submissions, role-based reviews, and approvals**. The dealer’s access is **restricted to initiation, -document upload, and status visibility** , with **final decision-making authority retained by -authorized internal stakeholders of RE** - -### 2.2 External & Integrated Stakeholders - -**2.2.1 FDD (Financial Due Diligence Partner)** - -External agency responsible for assessing the applicant’s financial health, verifying credentials, -and uploading due diligence reports into the system. - - -**2.2.2 Dealer / Applicant** -External user who applies for dealership, uploads required documents, participates in -interviews, and later accesses the portal for resignation or closure status. - -## 3 Definitions and Acronyms - -``` -Acronym Full Form / Description -RE Royal Enfield -DD Dealer Development -DD-AM Dealer Development – Area Manager -DD-ZM Dealer Development – Zonal Manager -DD-Lead Dealer Development – Lead -DD-Head Dealer Development – Head -RBM Regional Business Manager -ZBH Zonal Business Head -NBH National Business Head -ASM Area Sales Manager -FDD Financial Due Diligence (External Partner/Agency) -LOI Letter of Intent -EOR Essential Operating Requirements -LOA Letter of Appointment -F&F Full and Final (Dealer Settlement) -KT Matrix Evaluation Matrix used for scoring applicants -``` -## 4 HiFi Wireframes & Flow of Application - -HiFi Wireframes : https://mono-human-93592950.figma.site - -### 4.1 Dealer onboarding - Process Flow Overview - -The **Dealer Onboarding Workflow** outlines the end-to-end sequence through which a dealership -application progresses — from initial registration to final inauguration and operational readiness. - - -**4.1.1 Step-by-Step Process Flow** - -``` -4.1.1.1 Application Initiation -``` -- The **applicant (dealer prospect)** submits an online application through the Dealer - Onboarding Portal. -- The system checks the **location’s availability** in the Royal Enfield dealership network: - o If the location has **no open opportunity** , a **Non-Opportunity Email** is triggered - automatically. - o If an opportunity exists, the applicant receives an **Opportunity Email** with login - credentials and a link to the **Dealer Questionnaire**. - -``` -4.1.1.2 Questionnaire Completion -``` -- The applicant fills out the **comprehensive questionnaire** covering business, infrastructure, - and financial readiness. -- The system auto-scores responses, generating a **Questionnaire Score** and **initial** - **ranking** for that applicant. - - -- Completed applications move to the **Admin review bucket**. -- The system shall trigger automated reminders to users for completing the - questionnaire. These **reminders will be sent through WhatsApp** , to ensure timely - submission. Reminder needs to be configured from Admin. - -``` -4.1.1.3 Admin Validation & Shortlisting -``` -- **DD-Admin** reviews all submitted applications and validates details and attached - documents. -- Based on eligibility, applications are either **shortlisted** for evaluation or **archived** for - future opportunities. -- Shortlisted applications are distributed to respective **zones or regions** for further - assessment. - -``` -4.1.1.4 Interview Evaluation (Multi-Level Process) -``` -- Admin schedules interviews in **Level 1** , **Level 2** , and **Level 3** , as applicable. -- Each interview can be **Virtual or Physical** , with calendar invites sent via Google Calendar. -- Evaluators at each level (DD-ZM, RBM, DD-Lead, ZBH, NBH, DD-Head) record their - feedback through: - o **KT Matrix Scoring** (quantitative) - o **Interview Feedback Form** (qualitative) -- The system consolidates panel feedback and generates an **AI-driven summary and** - **ranking** for decision support. - -``` -4.1.1.5 Financial Due Diligence (FDD) & Finance Review -``` -- Upon shortlisting, the application is assigned to the **FDD Team (external agency)** for - financial validation. -- FDD users, using SSO credentials, can: - o View assigned applications in a restricted interface. - o Upload FDD reports and add remarks in the **Work Notes** section. - o Flag cases of **non-responsiveness** or incomplete data, returning them to Admin. -- The **Finance team** reviews submitted FDD reports, validates findings, and decides - whether the application proceeds to **LOI approval**. The finance team is not the decision - maker for LOI Issuance. - -``` -4.1.1.6 LOI (Letter of Intent) Approval & Issuance -``` -- Based on Finance clearance, **DD-Head and NBH** review and approve the **LOI request**. -- The system tracks document approvals, timestamps, and supporting artefacts. - - -- Once approved, the LOI document is generated, uploaded, and shared **with the** - **applicant via official email communication** and not on WhatsApp -- Notification emails are triggered to all relevant stakeholders. - -``` -4.1.1.7 Dealer Code Generation & Setup -``` -- After LOI issuance, the **DD-Admin triggers** the Dealer Code creation process. Based on - this trigger, the **Dealer Code is created in the SAP Master** and **mapped to the applicant** - within the system. -- The code links all downstream modules, including Architectural, Statutory, and EOR - checklists. - -``` -4.1.1.8 Architectural Work & Statutory Documentation -``` -- Architectural activities are initiated (site plans, layout approvals, branding elements). -- The applicant and assigned Architecture Team upload documents, drawings, and - blueprints. -- In parallel, the applicant uploads **Statutory Documents** such as: - o GST certificate, PAN, Partnership Deed, Firm Registration, Rental/Lease - Agreement, etc. -- Each upload is timestamped and visible with file name, uploader, and document type. - -``` -4.1.1.9 Payment Verification & Finance Validation -``` -- Applicant uploads proof of advance payment or security deposit. -- The **Finance team** verifies payment details (transaction ID, amount, and bank record). -- Status is updated to **Verified** once the payment is reconciled. -- Verified payment triggers readiness for final operational setup. - -``` -4.1.1.10 Essential Operating Requirements (EOR) Checklist -``` -- All functional teams (Sales, Service, IT, Finance, Training, Architecture) verify their - respective readiness parameters. -- Progress is tracked through a **completion bar** until 100% EOR compliance is achieved. -- The **EOR checklist is initiated only after LOA issuance**. All functional teams verify their - respective readiness parameters, and progress is tracked until **100% EOR compliance** is - achieved. - -``` -4.1.1.11 LOA (Letter of Authorization) & Final Go-Live -``` -- After LOI issuance and Dealer Code generation, the **Letter of Authorization (LOA) is** - **generated and approved by NBH and DD-Head**. Upon successful LOA issuance, the - - -``` -application proceeds to the Essential Operating Requirements (EOR) checklist for final -readiness verification. -``` -- Final verification includes: - -``` -o EOR document review -o Brand readiness assessment -o Site validation and inspection -``` -- The **LOA** officially authorizes the dealership to operate under Royal Enfield. - -``` -4.1.1.12 Inauguration & Closure -``` -- Post-authorization, the **Inauguration** event is scheduled and logged. -- Completion of inauguration marks the dealership as **Active** in the system. - -``` -4.1.1.13 System-Driven Governance & Audit -``` -- Each stage automatically logs: - o User action, timestamp, and remarks - o Uploaded artefacts and version control - o Notifications sent and approvals received -- The entire lifecycle remains accessible under **Audit Trail** for future reference, compliance, - or offboarding workflows. - -### 4.2 Dealer Resignation – Process Flow Overview - -**4.2.1.1 Overview** - -``` -The Dealer Resignation Process manages the structured offboarding of a dealership initiated -by the dealer. The process begins when a dealer formally submits their resignation via -email to the Area Sales Manager (ASM) , after which the workflow transitions into the -system-managed approval sequence. -``` -``` -Dealer resignation requests are initiated by the dealer through the portal and subsequently -reviewed and processed by Admin, Finance, Legal, and relevant business stakeholders. -``` -``` -This flow ensures that each resignation is verified, discussed, and approved across all -required levels — maintaining proper documentation, compliance, and traceability until the -final Legal Acceptance Letter is issued. -``` - -**4.2.2 Step-by-Step Process Flow** - -``` -4.2.2.1 Dealer Initiation -``` -- The dealer submits a **formal resignation email** on the dealership’s official letterhead to - the **ASM**. -- The resignation reason must be clearly stated (e.g., personal, financial, business - restructuring). -- The **dealer is provided portal access** to initiate the resignation request directly through - the system. The dealer submits resignation details, reason for exit, and proposed - timeline via the portal, after which the request enters the internal review and clearance - workflow. - -``` -4.2.2.2 ASM Review -``` -- The **ASM** reviews the dealer’s resignation request and supporting letter. -- Uploads the **resignation email** and **dealer’s letterhead document** onto the portal. -- Adds remarks summarizing the discussion and reason for resignation. -- Forwards the request to **RBM + DD-ZM** for evaluation. - -``` -4.2.2.3 RBM + DD-ZM Joint Evaluation -``` -- The **Regional Business Manager (RBM)** and **Dealer Development Zonal Manager (DD-** - **ZM)** review the uploaded documents. -- Conduct a joint discussion with the dealer to confirm the intent and understand any - issues. -- Uploads the **Minutes of Meeting (MOM)** or discussion summary. -- Adds comments and recommendations before forwarding to **Zonal Business Head** - **(ZBH)**. -- Actions available at this stage: - o **Approve** → Send forward for next-level review - o **Send Back for Clarification** → Returns to ASM - o **Withdraw** → Cancels the request (with remarks logged) - -``` -4.2.2.4 ZBH Review -``` -- The **Zonal Business Head (ZBH)** reviews the resignation summary and all remarks. -- Adds their comments and recommendations. -- Forwards the request to **DD-Lead** through the system. -- Worknote is updated automatically to reflect action and timestamp. -- The resignation request is reviewed by authorized business stakeholders, - including **RBM, ZBH, and DD-Head**. During the review stage, the **ZBH is authorized to** - - -``` -Send Back or Revoke the resignation request for clarification or correction. Send Back -actions are communicated to the dealer and internal teams through Work Notes , with -mandatory remarks captured for traceability. -``` -``` -4.2.2.5 DD-Lead Review -``` -- The **DD-Lead** consolidates all discussions, documents, and feedback. -- Prepares a **Resignation Presentation** with recommendations and supporting data. -- Uploads the presentation to the portal. -- Forwards the case to **NBH** for final decision. -- The resignation request is reviewed by the **DD-Lead and DD-Head**. At this stage, both - roles are authorized to **Send Back or Revoke** the resignation request for clarification, - correction, or reconsideration. **Send Back actions are communicated through Work** - **Notes** , with **mandatory remarks** recorded for audit and traceability. - -``` -4.2.2.6 NBH Final Approval -``` -- The **National Business Head (NBH)** reviews the entire resignation dossier. -- Adds final remarks with one of the following outcomes: - o **Approve** → Case moves automatically to Legal for letter issuance. - o **Send Back for Clarification** → Returns to DD-Lead or ZBH for revalidation. - o **Hold** → Temporarily pauses the process pending further discussion. -- Upon approval, the system triggers a **Worknote Notification** to DD-Lead, RBM, ZBH, and - Finance teams. -- The resignation request is reviewed by the **NBH** , who may **Approve, Send Back, or** - **Revoke** the request based on business considerations. Any **Send Back or Revoke action** - **must be accompanied by remarks recorded in Work Notes** , ensuring transparent - communication and governance. - -``` -4.2.2.7 Legal Acceptance Letter -``` -- Once approved by **NBH** , the request is **auto-assigned to the Legal team**. -- Legal verifies the uploaded resignation and issues a **Resignation Acceptance Letter**. -- The letter is uploaded to the portal, visible to all relevant personas including **DD-** - **Admin** and **DD-AM**. -- Legal can also raise clarifications through worknotes if required. -- Upon completion of all approvals, the **Legal team issues the official Resignation** - **Acceptance Letter** and shares it with the dealer through authorized communication - channels. - - -``` 4.2.2.8 DD-Admin Closure ``` - The **DD-Admin** downloads and shares the final **Resignation Acceptance Letter** with the @@ -677,136 +75,6 @@ mandatory remarks captured for traceability. **(LWD) of the dealership**. The system shall **enable and trigger the F&F workflow strictly** **based on the LWD date** , and **not based on the resignation approval date**. -### 4.3 Dealer Termination – Process Flow Overview - -``` -4.3.1.1 Overview -``` -``` -The Dealer Termination Process governs the structured offboarding of a dealership initiated -internally by Royal Enfield due to operational, contractual, or ethical concerns. -It ensures that any termination—whether due to working-capital issues, poor performance, -or unethical practices —is investigated, documented, reviewed at multiple managerial levels, -and legally validated before final execution. The process maintains full transparency and -traceability through digital records, comments, and worknotes until the Termination -Letter is issued and the Full & Final (F&F) settlement begins. -``` -**4.3.2 Step-by-Step Process Flow** - -``` -4.3.2.1 ASM – Case Initiation -``` -- The **Area Sales Manager (ASM)** regularly visits dealers and records **Minutes of Meeting** - **(MOM)** for performance or compliance concerns. -- After two consecutive unsatisfactory commitments or escalations, the ASM initiates - a **Termination Request** in the portal. -- Fills all operational details (Dealer Code, LOI, LOA, Sales Data, etc.), selects - a **Termination Category** (Working Capital, Performance, Unethical Practice), and - uploads supporting documents (MOMs, commitments, dealer letters). -- Submits the case to **RBM + DD-ZM** for review. - -``` -4.3.2.2 RBM + DD-ZM Review -``` -- The **Regional Business Manager (RBM)** and **Dealer Development Zonal Manager (DD-** - **ZM)** jointly evaluate the case. - - -- Conduct a meeting with the dealer and record fresh MOMs; upload dealer - commitments on letterhead. -- Provide remarks and supporting evidence. -- Actions available: - o **Approve** → Forward to ZBH - o **Send Back for Clarification** → Returns to ASM with comments - o **Withdraw** → Terminates workflow with justification - -``` -4.3.2.3 ZBH Review -``` -- The **Zonal Business Head (ZBH)** reviews the full chronology (ASM visits, RBM/DD-ZM - remarks, uploaded MOMs). -- Validates escalation authenticity and dealer communication record. -- Adds remarks and forwards to **DD-Lead** for deeper review. -- The termination request is reviewed by the **ZBH** , who is authorized to **Approve, Send** - **Back, or Revoke** the termination request. **Send Back actions are communicated** - **through Work Notes** , with **mandatory remarks** recorded for traceability. - -``` -4.3.2.4 DD-Lead Review & Legal Assignment -``` -- The **DD-Lead** cross-verifies case chronology with all stakeholders (ASM, RBM, ZBH). -- Prepares a **Termination Presentation** summarizing facts, dealer history, and - recommendations. -- Assigns the case to **Legal Team** for inputs through the system (visible in worknotes). -- The termination request is reviewed by the **DD-Lead** , who is authorized to **Send Back or** - **Revoke** the termination request for clarification or reconsideration. All such actions - require **mandatory remarks captured in Work Notes**. - -``` -4.3.2.5 Legal Verification -``` -- The **Legal Team** reviews documentation, ensures contractual breaches are well- - supported, and checks all precedents. -- May raise queries via **Worknotes** or **Send Back** the case to DD-Lead for clarification. -- Once satisfied, forwards the verified case back to **DD-Lead** for next action. - -``` -4.3.2.6 DD-Lead → DD-Head Review -``` -- The **DD-Lead** attaches Legal’s feedback and forwards the case to **DD-Head** for strategic - review. -- **DD-Head** validates the case, evaluates impact, and presents it to **National Business** - **Head (NBH)** for final business decision. - - -``` -4.3.2.7 NBH Evaluation -``` -- The **NBH** reviews all documentation and Legal remarks. -- May choose one of three actions: - o **Go Ahead** → Approve for issuance of **Show Cause Notice (SCN)** - o **Hold Decision** → Pause temporarily for further monitoring or negotiation - o **Raise Query** → Sends back to DD-Lead for additional input - -``` -4.3.2.8 Show Cause Notice (SCN) Issuance -``` -- Upon NBH approval, the system triggers Legal to prepare and issue the **SCN**. -- The **DD-Lead** formally shares the SCN with the dealer through **DD-Admin**. -- Dealer replies to the SCN by email or letter, which **DD-Admin uploads** to the portal. -- For termination cases, the **F&F settlement process is triggered only on the Last** - **Working Day (LWD)**. The system shall **control the F&F trigger based on the LWD date** , - irrespective of the termination approval date. - -``` -4.3.2.9 Evaluation of Dealer Response -``` -- The **DD-Lead** , **ZBH** , **RBM** , and **DD-Head** jointly review the dealer’s SCN response. -- Uploads internal comments, Legal feedback, and recommendation for NBH’s final - decision. - -``` -4.3.2.10 NBH Final Decision -``` -- The **NBH** reviews the compiled case with Legal advice and decides among: - o **Approve Termination** → Moves to CEO/CCO for confirmation - o **Reconsider** → Allow additional time or corrective action - o **Reject** → Case closed without termination - -``` -4.3.2.11 11. CEO & CCO Authorization -``` -- **CEO** and **Chief Commercial Officer (CCO)** review the NBH-approved termination. -- Provide authorization on the portal. -- Once signed off, the decision becomes final. - -``` -4.3.2.12 12. Legal Termination Letter -``` -- The **Legal Team** generates the **Termination Letter** to the portal. -- The letter is auto-visible to **DD-Lead** , **DD-Admin** , and **Finance**. -- A system notification is triggered to all linked personas. - ``` 4.3.2.13 13. DD-Admin Communication & F&F Trigger @@ -1753,50 +1021,3 @@ only) ``` ``` View F&F confirmation and settlement proof post-closure. View Only -``` - ---- - -## 13 Non-Functional Requirements - -``` -Category Requirement -Performance Average response time < 3 seconds for standard operations. -Scalability Should scale horizontally on GCP. -Security JWT tokens, encrypted passwords, HTTPS enforced. -Usability Intuitive UI, consistent icons, and simple navigation. -Reliability 99% uptime target. -Backup & Recovery Daily database backup and weekly full snapshot. -Compliance Follows RE IT data privacy guidelines. -``` -## 14 Technology Matrix - -``` -Component Specification -Database PGSQL (Managed or local instance) -Application Stack Node.js (Backend) + React.js (Frontend) -Authentication RE SSO Bridge -``` -## 15 Infra requirements & System Hygiene - -``` -Component Specification -Environment QA / Testing -# of Virtual Machines (VMs) 1 -CPU Configuration 4 - Core -Memory (RAM) 16 GB -Disk Size 500 GB -Operating System Ubuntu 24.04 LTS -``` - -``` -Storage Type Cloud -``` -Backup and Recovery - -- Daily incremental and weekly full backups. -- Restore process must not exceed 2 hours. - -## 16 Not in scope - -Anything which comes beyond the scope defined above in terms of Width and depth diff --git a/docs/modular_wise/05_Constitutional_Change.md b/docs/modular_wise/05_Constitutional_Change.md index d50b45b..d89ffce 100644 --- a/docs/modular_wise/05_Constitutional_Change.md +++ b/docs/modular_wise/05_Constitutional_Change.md @@ -1,225 +1,3 @@ -# RE Onboarding & Offboarding System - -# Requirements - -``` -System Requirements Specifications -``` -## 16 - Oct- 2025 - -## Version 1. 4 - - -## Contents - - -- Change Log - - 1.1 Change Log – Version 2.0 - - 1.2 Change Log – Dealer Self-Service Enablement -- 1 System Overview & Problem Statement -- 2 Intended Audience - - 2.1 Business & Functional Users - - 2.2 External & Integrated Stakeholders -- 3 Definitions and Acronyms -- 4 HiFi Wireframes & Flow of Application - - 4.1 Dealer onboarding - Process Flow Overview - - 4.2 Dealer Resignation – Process Flow Overview - - 4.3 Dealer Termination – Process Flow Overview - - 4.4 Dealer Full & Final (F&F) Settlement – Process Flow - - 4.5 Finance Team – Process Flow -- 5 System Features & Requirements -- 6 Dealer onboarding - - 6.1 Dealership Application Form - - 6.2 SSO Login - - 6.3 Dashboard - - 6.4 Opportunity & Non Opportunity - - 6.5 Questionnaire Response - - 6.6 Shortlisting Process - - 6.7 Shortlisted Applicants - - 6.8 Application Detail View - - 6.9 Interview Scheduling & Coordination - - 6.10 Interview Evaluation & Feedback Management - - 6.11 Interview Feedback & Evaluation Summary - - 6.12 Application Approval & Rejection Workflow - - 6.13 Work Notes & Internal Communication Trail - - 6.14 System Notifications & Alerts - - 6.15 FDD (Financial Due Diligence) & Finance Module - - 6.16 LOI Approval & Issuance - - 6.17 Dealer Code Generation, Architectural Work & Statutory Documentation............ - - 6.18 LOA Issuance, Essential Operating Requirements & Inauguration - - 6.19 Essential Operating Requirements (EOR) Checklist - - 6.20 Progress Tracker....................................................................................................... - - 6.21 Central Document Repository - - 6.22 Audit Trail & Activity Log.......................................................................................... -- 7 Dealer Resignation - - 7.1 Dealer Resignation Request (Initiation) - - 7.2 Resignation Management Dashboard - - 7.3 Resignation Details & Review - - 7.4 Resignation Request Review & Action Management - - 7.5 Resignation Progress Tracker - - 7.6 Documents & Audit Trail -- 8 Termination - - 8.1 Create Termination Request - - 8.2 Termination Ticket overview - - 8.3 Termination Approval & Review Process - - 8.4 Termination Progress Timeline -- 9 Admin Section - - 9.1 Master Configuration – Organization - - 9.2 Zone, Region & Area Configuration - - 9.3 Roles & permissions - - 9.4 SLA Configuration & Escalation Management - - 9.5 Email & Letter Templates Management - - 9.6 Opportunity Management (Geography & Window Setup) -- 10 F&F Case - - 10.1 F&F Settlement Progress Timeline - - 10.2 Department Responses -- 11 Finance Dashboard - - 11.1 Finance Dashboard Page - - 11.2 F&F Settlement Module -- 12 Dealer Persona - - 12.1 Dealer Resignation - - 12.2 Dealer Constitutional Change Management -- 13 Non-Functional Requirements -- 14 Technology Matrix -- 15 Infra requirements & System Hygiene -- 16 Not in scope - - -## Change Log - -### 1.1 Change Log – Version 2.0 - -**Module:** Dealer Onboarding & Offboarding System -**Change Type:** Clarifications, Role Alignment & Access Control Enhancements -**Scope Enhancement :** Dealer Role and Access control -**Change demarcation** : Highlighted in Yellow -**Changes suggested by** : Ashok & Tariq -**Changed performed by** : Rohit Mandiwal -**Changes done on** : 31 - Dec- 2025 - -**1.1.1 Notification Channel Enhancement** - -- Added **WhatsApp as a supported notification channel** for reminders and workflow - communications (e.g., questionnaire completion and status updates), while restricting - sensitive document sharing to email only. - -**1.1.2 LOI Governance & Communication Clarifications** - -- Clarified that the **Finance team is not the decision-making authority** for LOI issuance - and is responsible only for financial validation. -- Confirmed that **LOI documents are shared exclusively via official email** and not through - WhatsApp. -- Clarified that **LOA issuance is a parallel statutory activity** and is **not dependent on** - **infrastructure readiness**. - -**1.1.3 Dealer Code Creation Control** - -- Clarified that **Dealer Codes (SAP Master) are created only upon explicit trigger by the** - **DD Admin** , and not through automatic system generation. - -**1.1.4 LOA & EOR Sequencing Correction** - -- Corrected the workflow sequence to ensure that **LOA is issued prior to initiating the** - **EOR checklist** , with EOR serving as the final readiness validation before go-live. - -**1.1.5 Dealer Resignation Access & Workflow Enhancements** - -- Enabled **dealer portal access** for initiating resignation requests and uploading required - information. - - -- Clarified that the **Legal team issues the Resignation Acceptance Letter** in all cases. -- Expanded review authority to allow **ZBH, DD Lead, DD Head, and NBH** to **Send Back or** - **Revoke resignation requests** , with communication routed through **Work Notes**. -- Confirmed that **Full & Final (F&F) settlement is triggered strictly on the Last Working** - **Day (LWD)** and not based on approval date. - -**1.1.6 Termination Workflow Governance Updates** - -- Clarified that **CEO is the final approving authority** for dealer termination cases. -- Included **CCO and CEO** as approval authorities with **Approve / Hold / Reject** options. -- Confirmed that the **Legal team issues termination letters only after CEO approval**. -- Removed **dealer portal access** from termination workflows. -- Extended **Send Back / Revoke** authority to **ZBH and DD Lead** for termination reviews. -- Aligned **F&F trigger for termination** to occur strictly on the **Last Working Day (LWD)**. - -**1.1.7 Role & Persona Alignment** - -- Added **NBH** to the personas section. -- Added **RBM** to applicable review and approval tables. -- Clarified that **DD ASM is responsible for interview scheduling and coordination** , with - no Admin involvement. - -**1.1.8 Access Control & Visibility Refinements** - -- Defined **view-only access** for DD ASM, DD ZM, and RBM at relevant workflow stages. -- Granted **approval visibility** to DD Lead where applicable. -- Enabled **DD ASM and DD ZM** to upload site readiness and LOA-related documents, - with **DD Lead, RBM, and ZBH** having view access. -- Limited applicant and dealer portal access to **stage-specific and context-specific** - **scenarios only**. -- Confirmed that **dealer portal access is revoked after resignation or termination**. - -**1.1.9 Terminology & Documentation Corrections** - -- Clarified **KT Matrix as Kepner Tregoe Matrix** for consistency and correctness. - -**1.1.10 Super Admin Role Introduction** - -- Introduced a **Super Admin (Master Role)** with end-to-end access and workflow control - across modules. -- Defined segregation of duties by splitting Super Admin into **two DD Admin roles** with - clearly scoped responsibilities. - - -### 1.2 Change Log – Dealer Self-Service Enablement - -**Version:** v2. -**Section Impacted:** Section 12 – Dealer Portal (12.1 onwards) -**Module:** Dealer Onboarding & Offboarding System -**Change Type:** Dealer Feature Enablement (Section 12 onwards) -**Scope Enhancement :** Dealer Role and Access control -**Change demarcation** : Highlighted in Yellow -**Changes suggested by** : Ashok & Tariq -**Changed performed by** : Rohit Mandiwal -**Changes done on** : 5 - Jan- 2026 - -**1.2.1 Introduction of Dealer Portal** - -- Introduced a **Dealer Portal capability** enabling onboarded dealers to initiate and track - post-onboarding lifecycle requests through the portal. -- Dealer actions are governed by **role-based access controls** , approval hierarchies, and - audit mechanisms. - -**1.2.2 Dealer Resignation Enablement** - -- Enabled **dealer-initiated resignation requests** at outlet level via the portal. -- Added structured resignation submission with: - o Last Operational Date (Sales & Services) - o Reason for resignation - o Mandatory document readiness guidance -- Enabled **dealer withdrawal option** for resignation requests **only until the case is** - **pending with NBH**. -- Clarified that **Legal team issues the Resignation Acceptance Letter** post approvals. -- Ensured **F&F settlement is triggered based on Last Working Day (LWD)** and not - approval date. -- Restricted dealer portal access **post resignation closure**. - -**1.2.3 Dealer Relocation Request Enablement** - -- Enabled dealers to **initiate and track relocation requests** through a guided workflow. -- Added support for: - o Manual or map-based location entry - o Distance calculation from existing location - o Property type selection and expected relocation date - - -- Introduced **document-driven relocation validation** , including statutory, legal, property, - and infrastructure documents. -- Implemented **multi-level approval workflow** with Work Notes–based communication - and audit trail. -- Ensured dealer has **view and upload access only** , with approvals retained by RE - stakeholders. **1.2.4 Dealer Constitutional Change Enablement** @@ -238,107 +16,7 @@ System Requirements Specifications completed. -## 1 System Overview & Problem Statement -**1.1.1 System Overview** - -The **Dealer Onboarding and Offboarding System** for **Royal Enfield (RE)** is designed to **digitize, -standardize, and streamline** the complete dealer lifecycle — from **application and -evaluation** to **approval, resignation, termination, and full-and-final (F&F) settlement**. - -At present, the process operates through **manual coordination** , involving **emails, spreadsheets, -and physical documentation** , which makes it difficult to maintain visibility, accountability, and -consistency across teams. - -The proposed solution introduces a **centralized digital platform** that brings all stakeholders onto -a single workflow. It ensures that every stage — **onboarding, operational approvals, financial -diligence, legal validation, and final closure** — follows a **structured and traceable process**. - -The system integrates seamlessly with existing RE applications such as **SSO** , **SAP** , and **Finance -modules** , providing **role-based access** , **real-time tracking** , and **secure document management**. -It also offers **automated workflows** , **configurable approval hierarchies** , and **AI-assisted decision -support** to improve efficiency and reduce turnaround time. - -By moving to a digital workflow, Royal Enfield will achieve higher levels of **process -efficiency** , **data accuracy** , and **transparency** , ensuring faster decision-making and stronger -control over the dealer network lifecycle. - -## 2 Intended Audience - -This document is intended for all stakeholders involved in the **design, implementation, approval, -and operational use** of the **Dealer Onboarding and Offboarding System** at **Royal Enfield (RE)**. - -The following user personas and roles are part of the system: - -### 2.1 Business & Functional Users - -**2.1.1 Dealer Development (DD) Team** - -- **Super Admin (Master Role):** - The **Super Admin has unrestricted access** across all modules and workflows, with - authority to **configure, override, and influence workflow behavior** at every level. - - -``` -The Super Admin role is segregated into two DD Admin roles , each with clearly defined -scopes to ensure segregation of duties and governance control. -``` -- **DD-Admin:** System administrator responsible for user setup, role mapping, hierarchy - configuration, and workflow management. -- **DD-AM (Area Manager):** Reviews and manages applications within assigned regions; - performs preliminary screening. -- **DD-ZM (Zonal Manager):** Conducts the first level of dealer evaluation along with RBM; - prepares presentation decks for final interviews. -- **DD-Lead:** Reviews zonal evaluations, validates recommendations, and forwards - shortlisted applicants for senior-level approval. -- **DD-Head: DD Head** is engaged in the **final review and approval** of shortlisted dealer - applications before the **NBH interview** , and later **oversees final verification and LOI** - **issuance** after all evaluations are complete. - -**2.1.2 Regional Sales & Business Team** - -- **RBM (Regional Business Manager):** Participates in early-stage evaluations, provides - ground-level business insights, and recommends suitable candidates. -- **ZBH (Zonal Business Head):** Conducts the second-level review along with DD-Lead; - provides strategic feedback on market and location viability. -- **NBH (National Business Head):** Holds final authority for approval or rejection of dealer - onboarding; reviews consolidated feedback from all levels. - -**2.1.3 Supporting Departments** - -- **Finance Team:** Reviews financial due diligence reports, validates F&F (Full and Final) - settlements, and manages monetary closure during offboarding. -- **Legal Team:** Reviews agreements, issues **Letters of Intent (LOI)** or **Termination Letters** , - and ensures all documentation aligns with company policy. -- **Brand Experience / Architecture Team:** Manages **EOR (Essential Operating** - **Requirements)** and ensures adherence to brand and infrastructure standards. - -**2.1.4 Dealers** - -Once a dealer is **successfully onboarded and activated in the system** , the Dealer role is enabled -with controlled, role-based access to initiate and track select lifecycle requests. This -enhancement introduces **structured self-service capabilities for dealers** , while ensuring all -actions remain governed by defined validations, internal reviews, and approval workflows as per -RE standards. - -The Dealer role is enabled to perform the following activities: - - -- **Resignation Initiation** - -``` -The dealer can initiate the resignation process directly through the portal , submit the -reason for exit, and track the status of the request across the defined review, clearance, -and closure stages. -``` -- **Relocation Request Submission** - -``` -The dealer can submit a relocation request in scenarios where there is an intent to shift -the dealership from the current location to a new proposed location. The request is -routed for internal feasibility assessment, validation, and management approval before -execution. -``` - **Change in Constitution Request** ``` @@ -363,17 +41,6 @@ submissions, role-based reviews, and approvals**. The dealer’s access is **res document upload, and status visibility** , with **final decision-making authority retained by authorized internal stakeholders of RE** -### 2.2 External & Integrated Stakeholders - -**2.2.1 FDD (Financial Due Diligence Partner)** - -External agency responsible for assessing the applicant’s financial health, verifying credentials, -and uploading due diligence reports into the system. - - -**2.2.2 Dealer / Applicant** -External user who applies for dealership, uploads required documents, participates in -interviews, and later accesses the portal for resignation or closure status. ## 3 Definitions and Acronyms @@ -396,656 +63,6 @@ LOA Letter of Appointment F&F Full and Final (Dealer Settlement) KT Matrix Evaluation Matrix used for scoring applicants ``` -## 4 HiFi Wireframes & Flow of Application - -HiFi Wireframes : https://mono-human-93592950.figma.site - -### 4.1 Dealer onboarding - Process Flow Overview - -The **Dealer Onboarding Workflow** outlines the end-to-end sequence through which a dealership -application progresses — from initial registration to final inauguration and operational readiness. - - -**4.1.1 Step-by-Step Process Flow** - -``` -4.1.1.1 Application Initiation -``` -- The **applicant (dealer prospect)** submits an online application through the Dealer - Onboarding Portal. -- The system checks the **location’s availability** in the Royal Enfield dealership network: - o If the location has **no open opportunity** , a **Non-Opportunity Email** is triggered - automatically. - o If an opportunity exists, the applicant receives an **Opportunity Email** with login - credentials and a link to the **Dealer Questionnaire**. - -``` -4.1.1.2 Questionnaire Completion -``` -- The applicant fills out the **comprehensive questionnaire** covering business, infrastructure, - and financial readiness. -- The system auto-scores responses, generating a **Questionnaire Score** and **initial** - **ranking** for that applicant. - - -- Completed applications move to the **Admin review bucket**. -- The system shall trigger automated reminders to users for completing the - questionnaire. These **reminders will be sent through WhatsApp** , to ensure timely - submission. Reminder needs to be configured from Admin. - -``` -4.1.1.3 Admin Validation & Shortlisting -``` -- **DD-Admin** reviews all submitted applications and validates details and attached - documents. -- Based on eligibility, applications are either **shortlisted** for evaluation or **archived** for - future opportunities. -- Shortlisted applications are distributed to respective **zones or regions** for further - assessment. - -``` -4.1.1.4 Interview Evaluation (Multi-Level Process) -``` -- Admin schedules interviews in **Level 1** , **Level 2** , and **Level 3** , as applicable. -- Each interview can be **Virtual or Physical** , with calendar invites sent via Google Calendar. -- Evaluators at each level (DD-ZM, RBM, DD-Lead, ZBH, NBH, DD-Head) record their - feedback through: - o **KT Matrix Scoring** (quantitative) - o **Interview Feedback Form** (qualitative) -- The system consolidates panel feedback and generates an **AI-driven summary and** - **ranking** for decision support. - -``` -4.1.1.5 Financial Due Diligence (FDD) & Finance Review -``` -- Upon shortlisting, the application is assigned to the **FDD Team (external agency)** for - financial validation. -- FDD users, using SSO credentials, can: - o View assigned applications in a restricted interface. - o Upload FDD reports and add remarks in the **Work Notes** section. - o Flag cases of **non-responsiveness** or incomplete data, returning them to Admin. -- The **Finance team** reviews submitted FDD reports, validates findings, and decides - whether the application proceeds to **LOI approval**. The finance team is not the decision - maker for LOI Issuance. - -``` -4.1.1.6 LOI (Letter of Intent) Approval & Issuance -``` -- Based on Finance clearance, **DD-Head and NBH** review and approve the **LOI request**. -- The system tracks document approvals, timestamps, and supporting artefacts. - - -- Once approved, the LOI document is generated, uploaded, and shared **with the** - **applicant via official email communication** and not on WhatsApp -- Notification emails are triggered to all relevant stakeholders. - -``` -4.1.1.7 Dealer Code Generation & Setup -``` -- After LOI issuance, the **DD-Admin triggers** the Dealer Code creation process. Based on - this trigger, the **Dealer Code is created in the SAP Master** and **mapped to the applicant** - within the system. -- The code links all downstream modules, including Architectural, Statutory, and EOR - checklists. - -``` -4.1.1.8 Architectural Work & Statutory Documentation -``` -- Architectural activities are initiated (site plans, layout approvals, branding elements). -- The applicant and assigned Architecture Team upload documents, drawings, and - blueprints. -- In parallel, the applicant uploads **Statutory Documents** such as: - o GST certificate, PAN, Partnership Deed, Firm Registration, Rental/Lease - Agreement, etc. -- Each upload is timestamped and visible with file name, uploader, and document type. - -``` -4.1.1.9 Payment Verification & Finance Validation -``` -- Applicant uploads proof of advance payment or security deposit. -- The **Finance team** verifies payment details (transaction ID, amount, and bank record). -- Status is updated to **Verified** once the payment is reconciled. -- Verified payment triggers readiness for final operational setup. - -``` -4.1.1.10 Essential Operating Requirements (EOR) Checklist -``` -- All functional teams (Sales, Service, IT, Finance, Training, Architecture) verify their - respective readiness parameters. -- Progress is tracked through a **completion bar** until 100% EOR compliance is achieved. -- The **EOR checklist is initiated only after LOA issuance**. All functional teams verify their - respective readiness parameters, and progress is tracked until **100% EOR compliance** is - achieved. - -``` -4.1.1.11 LOA (Letter of Authorization) & Final Go-Live -``` -- After LOI issuance and Dealer Code generation, the **Letter of Authorization (LOA) is** - **generated and approved by NBH and DD-Head**. Upon successful LOA issuance, the - - -``` -application proceeds to the Essential Operating Requirements (EOR) checklist for final -readiness verification. -``` -- Final verification includes: - -``` -o EOR document review -o Brand readiness assessment -o Site validation and inspection -``` -- The **LOA** officially authorizes the dealership to operate under Royal Enfield. - -``` -4.1.1.12 Inauguration & Closure -``` -- Post-authorization, the **Inauguration** event is scheduled and logged. -- Completion of inauguration marks the dealership as **Active** in the system. - -``` -4.1.1.13 System-Driven Governance & Audit -``` -- Each stage automatically logs: - o User action, timestamp, and remarks - o Uploaded artefacts and version control - o Notifications sent and approvals received -- The entire lifecycle remains accessible under **Audit Trail** for future reference, compliance, - or offboarding workflows. - -### 4.2 Dealer Resignation – Process Flow Overview - -**4.2.1.1 Overview** - -``` -The Dealer Resignation Process manages the structured offboarding of a dealership initiated -by the dealer. The process begins when a dealer formally submits their resignation via -email to the Area Sales Manager (ASM) , after which the workflow transitions into the -system-managed approval sequence. -``` -``` -Dealer resignation requests are initiated by the dealer through the portal and subsequently -reviewed and processed by Admin, Finance, Legal, and relevant business stakeholders. -``` -``` -This flow ensures that each resignation is verified, discussed, and approved across all -required levels — maintaining proper documentation, compliance, and traceability until the -final Legal Acceptance Letter is issued. -``` - -**4.2.2 Step-by-Step Process Flow** - -``` -4.2.2.1 Dealer Initiation -``` -- The dealer submits a **formal resignation email** on the dealership’s official letterhead to - the **ASM**. -- The resignation reason must be clearly stated (e.g., personal, financial, business - restructuring). -- The **dealer is provided portal access** to initiate the resignation request directly through - the system. The dealer submits resignation details, reason for exit, and proposed - timeline via the portal, after which the request enters the internal review and clearance - workflow. - -``` -4.2.2.2 ASM Review -``` -- The **ASM** reviews the dealer’s resignation request and supporting letter. -- Uploads the **resignation email** and **dealer’s letterhead document** onto the portal. -- Adds remarks summarizing the discussion and reason for resignation. -- Forwards the request to **RBM + DD-ZM** for evaluation. - -``` -4.2.2.3 RBM + DD-ZM Joint Evaluation -``` -- The **Regional Business Manager (RBM)** and **Dealer Development Zonal Manager (DD-** - **ZM)** review the uploaded documents. -- Conduct a joint discussion with the dealer to confirm the intent and understand any - issues. -- Uploads the **Minutes of Meeting (MOM)** or discussion summary. -- Adds comments and recommendations before forwarding to **Zonal Business Head** - **(ZBH)**. -- Actions available at this stage: - o **Approve** → Send forward for next-level review - o **Send Back for Clarification** → Returns to ASM - o **Withdraw** → Cancels the request (with remarks logged) - -``` -4.2.2.4 ZBH Review -``` -- The **Zonal Business Head (ZBH)** reviews the resignation summary and all remarks. -- Adds their comments and recommendations. -- Forwards the request to **DD-Lead** through the system. -- Worknote is updated automatically to reflect action and timestamp. -- The resignation request is reviewed by authorized business stakeholders, - including **RBM, ZBH, and DD-Head**. During the review stage, the **ZBH is authorized to** - - -``` -Send Back or Revoke the resignation request for clarification or correction. Send Back -actions are communicated to the dealer and internal teams through Work Notes , with -mandatory remarks captured for traceability. -``` -``` -4.2.2.5 DD-Lead Review -``` -- The **DD-Lead** consolidates all discussions, documents, and feedback. -- Prepares a **Resignation Presentation** with recommendations and supporting data. -- Uploads the presentation to the portal. -- Forwards the case to **NBH** for final decision. -- The resignation request is reviewed by the **DD-Lead and DD-Head**. At this stage, both - roles are authorized to **Send Back or Revoke** the resignation request for clarification, - correction, or reconsideration. **Send Back actions are communicated through Work** - **Notes** , with **mandatory remarks** recorded for audit and traceability. - -``` -4.2.2.6 NBH Final Approval -``` -- The **National Business Head (NBH)** reviews the entire resignation dossier. -- Adds final remarks with one of the following outcomes: - o **Approve** → Case moves automatically to Legal for letter issuance. - o **Send Back for Clarification** → Returns to DD-Lead or ZBH for revalidation. - o **Hold** → Temporarily pauses the process pending further discussion. -- Upon approval, the system triggers a **Worknote Notification** to DD-Lead, RBM, ZBH, and - Finance teams. -- The resignation request is reviewed by the **NBH** , who may **Approve, Send Back, or** - **Revoke** the request based on business considerations. Any **Send Back or Revoke action** - **must be accompanied by remarks recorded in Work Notes** , ensuring transparent - communication and governance. - -``` -4.2.2.7 Legal Acceptance Letter -``` -- Once approved by **NBH** , the request is **auto-assigned to the Legal team**. -- Legal verifies the uploaded resignation and issues a **Resignation Acceptance Letter**. -- The letter is uploaded to the portal, visible to all relevant personas including **DD-** - **Admin** and **DD-AM**. -- Legal can also raise clarifications through worknotes if required. -- Upon completion of all approvals, the **Legal team issues the official Resignation** - **Acceptance Letter** and shares it with the dealer through authorized communication - channels. - - -``` -4.2.2.8 DD-Admin Closure -``` -- The **DD-Admin** downloads and shares the final **Resignation Acceptance Letter** with the - dealer. -- Marks the resignation as completed and triggers the **F&F (Full and Final) process** by - forwarding the case to the Finance team. -- The **Full & Final (F&F) settlement process is initiated only on the Last Working Day** - **(LWD) of the dealership**. The system shall **enable and trigger the F&F workflow strictly** - **based on the LWD date** , and **not based on the resignation approval date**. - -### 4.3 Dealer Termination – Process Flow Overview - -``` -4.3.1.1 Overview -``` -``` -The Dealer Termination Process governs the structured offboarding of a dealership initiated -internally by Royal Enfield due to operational, contractual, or ethical concerns. -It ensures that any termination—whether due to working-capital issues, poor performance, -or unethical practices —is investigated, documented, reviewed at multiple managerial levels, -and legally validated before final execution. The process maintains full transparency and -traceability through digital records, comments, and worknotes until the Termination -Letter is issued and the Full & Final (F&F) settlement begins. -``` -**4.3.2 Step-by-Step Process Flow** - -``` -4.3.2.1 ASM – Case Initiation -``` -- The **Area Sales Manager (ASM)** regularly visits dealers and records **Minutes of Meeting** - **(MOM)** for performance or compliance concerns. -- After two consecutive unsatisfactory commitments or escalations, the ASM initiates - a **Termination Request** in the portal. -- Fills all operational details (Dealer Code, LOI, LOA, Sales Data, etc.), selects - a **Termination Category** (Working Capital, Performance, Unethical Practice), and - uploads supporting documents (MOMs, commitments, dealer letters). -- Submits the case to **RBM + DD-ZM** for review. - -``` -4.3.2.2 RBM + DD-ZM Review -``` -- The **Regional Business Manager (RBM)** and **Dealer Development Zonal Manager (DD-** - **ZM)** jointly evaluate the case. - - -- Conduct a meeting with the dealer and record fresh MOMs; upload dealer - commitments on letterhead. -- Provide remarks and supporting evidence. -- Actions available: - o **Approve** → Forward to ZBH - o **Send Back for Clarification** → Returns to ASM with comments - o **Withdraw** → Terminates workflow with justification - -``` -4.3.2.3 ZBH Review -``` -- The **Zonal Business Head (ZBH)** reviews the full chronology (ASM visits, RBM/DD-ZM - remarks, uploaded MOMs). -- Validates escalation authenticity and dealer communication record. -- Adds remarks and forwards to **DD-Lead** for deeper review. -- The termination request is reviewed by the **ZBH** , who is authorized to **Approve, Send** - **Back, or Revoke** the termination request. **Send Back actions are communicated** - **through Work Notes** , with **mandatory remarks** recorded for traceability. - -``` -4.3.2.4 DD-Lead Review & Legal Assignment -``` -- The **DD-Lead** cross-verifies case chronology with all stakeholders (ASM, RBM, ZBH). -- Prepares a **Termination Presentation** summarizing facts, dealer history, and - recommendations. -- Assigns the case to **Legal Team** for inputs through the system (visible in worknotes). -- The termination request is reviewed by the **DD-Lead** , who is authorized to **Send Back or** - **Revoke** the termination request for clarification or reconsideration. All such actions - require **mandatory remarks captured in Work Notes**. - -``` -4.3.2.5 Legal Verification -``` -- The **Legal Team** reviews documentation, ensures contractual breaches are well- - supported, and checks all precedents. -- May raise queries via **Worknotes** or **Send Back** the case to DD-Lead for clarification. -- Once satisfied, forwards the verified case back to **DD-Lead** for next action. - -``` -4.3.2.6 DD-Lead → DD-Head Review -``` -- The **DD-Lead** attaches Legal’s feedback and forwards the case to **DD-Head** for strategic - review. -- **DD-Head** validates the case, evaluates impact, and presents it to **National Business** - **Head (NBH)** for final business decision. - - -``` -4.3.2.7 NBH Evaluation -``` -- The **NBH** reviews all documentation and Legal remarks. -- May choose one of three actions: - o **Go Ahead** → Approve for issuance of **Show Cause Notice (SCN)** - o **Hold Decision** → Pause temporarily for further monitoring or negotiation - o **Raise Query** → Sends back to DD-Lead for additional input - -``` -4.3.2.8 Show Cause Notice (SCN) Issuance -``` -- Upon NBH approval, the system triggers Legal to prepare and issue the **SCN**. -- The **DD-Lead** formally shares the SCN with the dealer through **DD-Admin**. -- Dealer replies to the SCN by email or letter, which **DD-Admin uploads** to the portal. -- For termination cases, the **F&F settlement process is triggered only on the Last** - **Working Day (LWD)**. The system shall **control the F&F trigger based on the LWD date** , - irrespective of the termination approval date. - -``` -4.3.2.9 Evaluation of Dealer Response -``` -- The **DD-Lead** , **ZBH** , **RBM** , and **DD-Head** jointly review the dealer’s SCN response. -- Uploads internal comments, Legal feedback, and recommendation for NBH’s final - decision. - -``` -4.3.2.10 NBH Final Decision -``` -- The **NBH** reviews the compiled case with Legal advice and decides among: - o **Approve Termination** → Moves to CEO/CCO for confirmation - o **Reconsider** → Allow additional time or corrective action - o **Reject** → Case closed without termination - -``` -4.3.2.11 11. CEO & CCO Authorization -``` -- **CEO** and **Chief Commercial Officer (CCO)** review the NBH-approved termination. -- Provide authorization on the portal. -- Once signed off, the decision becomes final. - -``` -4.3.2.12 12. Legal Termination Letter -``` -- The **Legal Team** generates the **Termination Letter** to the portal. -- The letter is auto-visible to **DD-Lead** , **DD-Admin** , and **Finance**. -- A system notification is triggered to all linked personas. - - -``` -4.3.2.13 13. DD-Admin Communication & F&F Trigger -``` -- The **DD-Admin** shares the official **Termination Letter** with the dealer and field team. -- Marks the case as “Terminated” in the portal. -- Forwards the case to **Finance** for **Full & Final Settlement** initiation. -- Updates the worknote with final remarks and due-date for settlement. - -### 4.4 Dealer Full & Final (F&F) Settlement – Process Flow - -``` -4.4.1.1 Overview -``` -The **Full & Final (F&F) Settlement Process** governs the financial closure of a dealership -following **Resignation** or **Termination**. -It ensures that all financial obligations between Royal Enfield and the dealer — -including **security deposits, recoveries, payables, and department-wise dues** — are -transparently reconciled, verified, and documented before closure. - -**4.4.2 Step-by-Step Process Flow** - -``` -4.4.2.1 F&F Initiation -``` -- Triggered automatically once the **Resignation Acceptance Letter** or **Termination** - **Letter** is uploaded by **Legal**. -- The **DD-Admin** or **DD-Lead** initiates the F&F case in the **Finance Dashboard** , which - creates a unique **FNF Case ID** linked to the dealer code. -- The system auto-fetches dealer details, associated documents, resignation/termination - date, and due dates. -- Notification is sent to the **Finance Team** and all functional departments to begin the - clearance process. - -``` -4.4.2.2 Department-wise Response Collection -``` -- The system automatically prompts all mapped **functional departments (16 in total)** to - submit their clearance inputs — including NOC, payables, recoveries, and remarks. -- Each department updates: - o Financial dues (if any) - o Clearance confirmation (NOC) - o Supporting document uploads (e.g., debit note, invoice copy) -- The system dynamically updates progress (e.g., _12/16 Departments Responded_ ) with - color-coded indicators: - o 🟢 **No Dues** – Cleared - - -``` -o 🔴 Dues Pending – Outstanding financial liability -o ⚪ Pending – Awaiting department input -``` -- SLA-based reminders are auto-triggered for pending responses nearing the deadline. - -``` -4.4.2.3 Finance Summary Consolidation -``` -- Once all departments respond, the **DD-Admin Team** consolidates inputs into the **Final** - **F&F Summary Sheet** , which consists of: - o **Payables to Dealer** (e.g., refundable deposits, reimbursements) - o **Receivables from Dealer** (e.g., outstanding invoices, recoveries) - o **Deductions** (policy penalties, non-compliance adjustments) -- At this stage, **department-claimed amounts are frozen** and become read-only for - departments. -- Finance does **not overwrite department claim values**. Instead, Finance validates each row - in a dedicated validation layer by recording: - - Finance decision (Accepted / Partially Accepted / Rejected / Under Clarification) - - Finance-validated amount - - Variance amount and mandatory variance reason (if changed) - - Supporting proof/document -- The system automatically calculates: - - Net Settlement = Total Payables – Total Receivables – Total Deductions - - Final totals are computed from **finance-validated values only**. -- Status updates to _Finance Summary Prepared_ once complete. - -``` -4.4.2.4 Internal Review & Clarification -``` -- The **Finance Team** may use the **Work Note** section to raise clarifications to **DD-** - **Lead** , **Legal** , or concerned departments. -- If discrepancies exist (e.g., mismatched values or missing NOCs), the case remains _Under_ - _Clarification_ until resolved. -- Once validated, Finance locks the summary for further edits. - -``` -4.4.2.5 Dealer Discussion & Acknowledgment -``` -- The **Finance Team** , along with **Legal** and **DD-Lead** , discusses the settlement summary - with the dealer. -- Dealer acknowledgment is captured either via written confirmation or attached email - communication. -- The case then proceeds for **Final Finance Approval**. - -``` -4.4.2.6 Final Finance Approval & Payment Processing -``` -- The **Finance Team** reviews the approved summary and enters payment or recovery - details: - o **Transaction Type:** RTGS / NEFT / Cheque - o **Transaction ID & Date** - o **Bank Name & Account Details** (auto-fetched from dealer profile) - o **Settlement Remarks** -- Finance takes one of three actions: - - -``` -o Approve Settlement → Marks the case as “Finance Approved.” -o Request Clarification → Sends query to DD-Lead or Admin. -o Reject Summary → Returns for re-verification. -``` -- Upon approval, notifications are sent to DD-Admin and Legal for record update. - -``` -4.4.2.7 F&F Completion & Closure -``` -- Once approved, the case is automatically marked **Completed** , and the **Finance** - **Dashboard** updates status as _F&F Closed_. -- The **Settlement Proof** (e.g., payment confirmation or recovery adjustment) is uploaded - by Finance. -- The **DD-Admin** communicates official closure to the dealer and archives all artefacts. -- System triggers final alerts to DD-Lead, NBH, and Legal confirming completion. -- The case is archived in the **Audit Trail** for future reference. - -### 4.5 Finance Team – Process Flow - -``` -4.5.1.1 Overview -``` -The **Finance Team Process Flow** governs all financial activities related to dealer lifecycle -management — from **security deposit validation at onboarding** to **final settlement at -resignation or termination**. -It ensures complete financial traceability, proper verification of payments, and compliance with -Royal Enfield’s financial governance standards. -The process flow integrates with **Admin, Legal, Dealer Development (DD)** , and **Departmental -Modules** , ensuring accurate financial updates and timely closure of all financial transactions. - -**4.5.2 Step-by-Step Process Flow** - -``` -4.5.2.1 Security Deposit Validation (Onboarding Stage) -``` -- **Trigger:** - Initiated when a new dealer’s onboarding application reaches the Finance stage after - DD approval. -- **Action:** - The **Finance Team** verifies the **Security Deposit** payment made by the dealer - via **RTGS/NEFT** or other approved channels. -- **Outcome:** - o Verified deposits are marked as _Approved_ , triggering system notifications to DD- - Admin and DD-Lead. - - -``` -o The verified payment data is stored permanently in the dealer’s financial profile -for audit and reference. -``` -``` -4.5.2.2 Financial Summary Preparation -``` -- **Action:** - Once departmental inputs are received, Finance consolidates all data into the **F&F** - **Summary Sheet**. -- **System Steps:** - o Segregates entries under: - ▪ **Payables to Dealer** (e.g., refundable deposits, reimbursements) - ▪ **Receivables from Dealer** (e.g., outstanding payments, penalties) - ▪ **Deductions** (e.g., policy recoveries, warranty holdbacks) - o The system auto-calculates: - o Net Settlement = Total Payables – Total Receivables – Deductions - o Finance validates each record, uploads supporting documents (receipts, invoices, - credit notes), and adds remarks. -- **Outcome:** - The computed **Net Settlement Amount** is reflected in the dashboard, categorized - as _Payable to Dealer_ or _Recoverable from Dealer_. - -``` -4.5.2.3 Internal Clarification & Approval -``` -- **Action:** - Finance initiates clarification rounds with departments or DD-Lead for mismatched data. -- **System Steps:** - o Uses the **Work Notes** section for comments, tagging users like _@DD-_ - _Lead_ , _@Legal_ , or _@Admin_. - o Tracks status as _Pending Clarification_ until resolved. - o After reconciliation, Finance locks the summary and updates case status - to _Ready for Approval_. - -``` -4.5.2.4 Final Review & Dealer Confirmation -``` -- **Action:** - Finance conducts an internal review of the consolidated settlement and initiates a - financial discussion with the dealer. -- **System Steps:** - o Reviews summary details on-screen with Legal and DD-Lead. - o Records dealer’s acknowledgment via Work Note or attached email - confirmation. - o Once confirmed, proceeds to payment verification. - - -``` -4.5.2.5 Payment Processing & Record Update -``` -- **Action:** - Finance executes the financial transaction (payment to or recovery from dealer). -- **System Steps:** - o Enters **Mode of Payment** , **Transaction Reference Number** , **Date** , and **Remarks**. - o Uploads proof of payment (RTGS confirmation or bank statement). - o Marks case as _Finance Approved_ and sends completion notification to DD-Admin - and Legal. - o System automatically updates the **Progress Timeline** and **Audit Trail**. - -``` -4.5.2.6 F&F Completion & Closure -``` -- **Action:** - Finance reviews all entries, confirms ledger reconciliations, and marks case - as **Completed**. -- **System Steps:** - o Locks financial data and supporting artefacts. - o Status changes to _Closed – F&F Completed_. - o Final confirmation sent to all stakeholders — DD-Lead, NBH, DD-Head, Legal, and - DD-Admin. - o Finance Dashboard updates counters under “Completed Cases.” - -## 5 System Features & Requirements - -Here, we describe the **system features** along with their respective **Width** and **Depth** to provide -complete visibility of each requirement. - -The **Width** defines the **functional coverage** of a feature — outlining what the feature does, -its **boundaries, use cases, and user interactions**. It answers the question: _“What scenarios and -actions are covered by this feature?”_ - -The **Depth** captures the **operational and behavioral details** — describing how the feature -behaves through its **logic, workflow, system responses, and edge-case handling**. It answers the -question: _“How does the system execute and respond in these scenarios?”_ - ---- ### 12.2 Dealer Constitutional Change Management @@ -1233,47 +250,3 @@ dynamically --- - -## 13 Non-Functional Requirements - -``` -Category Requirement -Performance Average response time < 3 seconds for standard operations. -Scalability Should scale horizontally on GCP. -Security JWT tokens, encrypted passwords, HTTPS enforced. -Usability Intuitive UI, consistent icons, and simple navigation. -Reliability 99% uptime target. -Backup & Recovery Daily database backup and weekly full snapshot. -Compliance Follows RE IT data privacy guidelines. -``` -## 14 Technology Matrix - -``` -Component Specification -Database PGSQL (Managed or local instance) -Application Stack Node.js (Backend) + React.js (Frontend) -Authentication RE SSO Bridge -``` -## 15 Infra requirements & System Hygiene - -``` -Component Specification -Environment QA / Testing -# of Virtual Machines (VMs) 1 -CPU Configuration 4 - Core -Memory (RAM) 16 GB -Disk Size 500 GB -Operating System Ubuntu 24.04 LTS -``` - -``` -Storage Type Cloud -``` -Backup and Recovery - -- Daily incremental and weekly full backups. -- Restore process must not exceed 2 hours. - -## 16 Not in scope - -Anything which comes beyond the scope defined above in terms of Width and depth diff --git a/docs/modular_wise/06_Relocation.md b/docs/modular_wise/06_Relocation.md index 587e314..24e720a 100644 --- a/docs/modular_wise/06_Relocation.md +++ b/docs/modular_wise/06_Relocation.md @@ -13,89 +13,12 @@ System Requirements Specifications ## Contents -- Change Log - - 1.1 Change Log – Version 2.0 - - 1.2 Change Log – Dealer Self-Service Enablement -- 1 System Overview & Problem Statement -- 2 Intended Audience - - 2.1 Business & Functional Users - - 2.2 External & Integrated Stakeholders -- 3 Definitions and Acronyms -- 4 HiFi Wireframes & Flow of Application - - 4.1 Dealer onboarding - Process Flow Overview - - 4.2 Dealer Resignation – Process Flow Overview - - 4.3 Dealer Termination – Process Flow Overview - - 4.4 Dealer Full & Final (F&F) Settlement – Process Flow - - 4.5 Finance Team – Process Flow -- 5 System Features & Requirements -- 6 Dealer onboarding - - 6.1 Dealership Application Form - - 6.2 SSO Login - - 6.3 Dashboard - - 6.4 Opportunity & Non Opportunity - - 6.5 Questionnaire Response - - 6.6 Shortlisting Process - - 6.7 Shortlisted Applicants - - 6.8 Application Detail View - - 6.9 Interview Scheduling & Coordination - - 6.10 Interview Evaluation & Feedback Management - - 6.11 Interview Feedback & Evaluation Summary - - 6.12 Application Approval & Rejection Workflow - - 6.13 Work Notes & Internal Communication Trail - - 6.14 System Notifications & Alerts - - 6.15 FDD (Financial Due Diligence) & Finance Module - - 6.16 LOI Approval & Issuance - - 6.17 Dealer Code Generation, Architectural Work & Statutory Documentation............ - - 6.18 LOA Issuance, Essential Operating Requirements & Inauguration - - 6.19 Essential Operating Requirements (EOR) Checklist - - 6.20 Progress Tracker....................................................................................................... - - 6.21 Central Document Repository - - 6.22 Audit Trail & Activity Log.......................................................................................... -- 7 Dealer Resignation - - 7.1 Dealer Resignation Request (Initiation) - - 7.2 Resignation Management Dashboard - - 7.3 Resignation Details & Review - - 7.4 Resignation Request Review & Action Management - - 7.5 Resignation Progress Tracker - - 7.6 Documents & Audit Trail -- 8 Termination - - 8.1 Create Termination Request - - 8.2 Termination Ticket overview - - 8.3 Termination Approval & Review Process - - 8.4 Termination Progress Timeline -- 9 Admin Section - - 9.1 Master Configuration – Organization - - 9.2 Zone, Region & Area Configuration - - 9.3 Roles & permissions - - 9.4 SLA Configuration & Escalation Management - - 9.5 Email & Letter Templates Management - - 9.6 Opportunity Management (Geography & Window Setup) -- 10 F&F Case - - 10.1 F&F Settlement Progress Timeline - - 10.2 Department Responses -- 11 Finance Dashboard - - 11.1 Finance Dashboard Page - - 11.2 F&F Settlement Module -- 12 Dealer Persona - - 12.1 Dealer Resignation - - 12.2 Dealer Constitutional Change Management -- 13 Non-Functional Requirements -- 14 Technology Matrix -- 15 Infra requirements & System Hygiene -- 16 Not in scope - +- ## Change Log ### 1.1 Change Log – Version 2.0 -**Module:** Dealer Onboarding & Offboarding System -**Change Type:** Clarifications, Role Alignment & Access Control Enhancements -**Scope Enhancement :** Dealer Role and Access control -**Change demarcation** : Highlighted in Yellow -**Changes suggested by** : Ashok & Tariq -**Changed performed by** : Rohit Mandiwal -**Changes done on** : 31 - Dec- 2025 **1.1.1 Notification Channel Enhancement** @@ -103,52 +26,8 @@ System Requirements Specifications communications (e.g., questionnaire completion and status updates), while restricting sensitive document sharing to email only. -**1.1.2 LOI Governance & Communication Clarifications** - -- Clarified that the **Finance team is not the decision-making authority** for LOI issuance - and is responsible only for financial validation. -- Confirmed that **LOI documents are shared exclusively via official email** and not through - WhatsApp. -- Clarified that **LOA issuance is a parallel statutory activity** and is **not dependent on** - **infrastructure readiness**. - -**1.1.3 Dealer Code Creation Control** - -- Clarified that **Dealer Codes (SAP Master) are created only upon explicit trigger by the** - **DD Admin** , and not through automatic system generation. - -**1.1.4 LOA & EOR Sequencing Correction** - -- Corrected the workflow sequence to ensure that **LOA is issued prior to initiating the** - **EOR checklist** , with EOR serving as the final readiness validation before go-live. - -**1.1.5 Dealer Resignation Access & Workflow Enhancements** - -- Enabled **dealer portal access** for initiating resignation requests and uploading required - information. -- Clarified that the **Legal team issues the Resignation Acceptance Letter** in all cases. -- Expanded review authority to allow **ZBH, DD Lead, DD Head, and NBH** to **Send Back or** - **Revoke resignation requests** , with communication routed through **Work Notes**. -- Confirmed that **Full & Final (F&F) settlement is triggered strictly on the Last Working** - **Day (LWD)** and not based on approval date. - -**1.1.6 Termination Workflow Governance Updates** - -- Clarified that **CEO is the final approving authority** for dealer termination cases. -- Included **CCO and CEO** as approval authorities with **Approve / Hold / Reject** options. -- Confirmed that the **Legal team issues termination letters only after CEO approval**. -- Removed **dealer portal access** from termination workflows. -- Extended **Send Back / Revoke** authority to **ZBH and DD Lead** for termination reviews. -- Aligned **F&F trigger for termination** to occur strictly on the **Last Working Day (LWD)**. - -**1.1.7 Role & Persona Alignment** - -- Added **NBH** to the personas section. -- Added **RBM** to applicable review and approval tables. -- Clarified that **DD ASM is responsible for interview scheduling and coordination** , with - no Admin involvement. **1.1.8 Access Control & Visibility Refinements** @@ -172,17 +51,7 @@ System Requirements Specifications clearly scoped responsibilities. -### 1.2 Change Log – Dealer Self-Service Enablement -**Version:** v2. -**Section Impacted:** Section 12 – Dealer Portal (12.1 onwards) -**Module:** Dealer Onboarding & Offboarding System -**Change Type:** Dealer Feature Enablement (Section 12 onwards) -**Scope Enhancement :** Dealer Role and Access control -**Change demarcation** : Highlighted in Yellow -**Changes suggested by** : Ashok & Tariq -**Changed performed by** : Rohit Mandiwal -**Changes done on** : 5 - Jan- 2026 **1.2.1 Introduction of Dealer Portal** @@ -191,19 +60,6 @@ System Requirements Specifications - Dealer actions are governed by **role-based access controls** , approval hierarchies, and audit mechanisms. -**1.2.2 Dealer Resignation Enablement** - -- Enabled **dealer-initiated resignation requests** at outlet level via the portal. -- Added structured resignation submission with: - o Last Operational Date (Sales & Services) - o Reason for resignation - o Mandatory document readiness guidance -- Enabled **dealer withdrawal option** for resignation requests **only until the case is** - **pending with NBH**. -- Clarified that **Legal team issues the Resignation Acceptance Letter** post approvals. -- Ensured **F&F settlement is triggered based on Last Working Day (LWD)** and not - approval date. -- Restricted dealer portal access **post resignation closure**. **1.2.3 Dealer Relocation Request Enablement** @@ -221,21 +77,7 @@ System Requirements Specifications - Ensured dealer has **view and upload access only** , with approvals retained by RE stakeholders. -**1.2.4 Dealer Constitutional Change Enablement** -- Enabled dealers to **initiate constitutional change requests** post onboarding. -- Supported all approved constitution change scenarios: - o Proprietorship, Partnership, LLP, and Private Limited permutations -- Implemented **dynamic document requirement determination** based on target - constitution. -- Explicitly confirmed **no OCR-based document validation** ; all validations are manual and - role-driven. -- Ensured statutory compliance via Legal review before master data updates. - -**1.2.5 Post-Exit Access Control** - -- Enforced system rule to **revoke dealer portal access** once resignation or termination is - completed. ## 1 System Overview & Problem Statement @@ -272,28 +114,6 @@ The following user personas and roles are part of the system: ### 2.1 Business & Functional Users -**2.1.1 Dealer Development (DD) Team** - -- **Super Admin (Master Role):** - The **Super Admin has unrestricted access** across all modules and workflows, with - authority to **configure, override, and influence workflow behavior** at every level. - - -``` -The Super Admin role is segregated into two DD Admin roles , each with clearly defined -scopes to ensure segregation of duties and governance control. -``` -- **DD-Admin:** System administrator responsible for user setup, role mapping, hierarchy - configuration, and workflow management. -- **DD-AM (Area Manager):** Reviews and manages applications within assigned regions; - performs preliminary screening. -- **DD-ZM (Zonal Manager):** Conducts the first level of dealer evaluation along with RBM; - prepares presentation decks for final interviews. -- **DD-Lead:** Reviews zonal evaluations, validates recommendations, and forwards - shortlisted applicants for senior-level approval. -- **DD-Head: DD Head** is engaged in the **final review and approval** of shortlisted dealer - applications before the **NBH interview** , and later **oversees final verification and LOI** - **issuance** after all evaluations are complete. **2.1.2 Regional Sales & Business Team** @@ -304,33 +124,6 @@ scopes to ensure segregation of duties and governance control. - **NBH (National Business Head):** Holds final authority for approval or rejection of dealer onboarding; reviews consolidated feedback from all levels. -**2.1.3 Supporting Departments** - -- **Finance Team:** Reviews financial due diligence reports, validates F&F (Full and Final) - settlements, and manages monetary closure during offboarding. -- **Legal Team:** Reviews agreements, issues **Letters of Intent (LOI)** or **Termination Letters** , - and ensures all documentation aligns with company policy. -- **Brand Experience / Architecture Team:** Manages **EOR (Essential Operating** - **Requirements)** and ensures adherence to brand and infrastructure standards. - -**2.1.4 Dealers** - -Once a dealer is **successfully onboarded and activated in the system** , the Dealer role is enabled -with controlled, role-based access to initiate and track select lifecycle requests. This -enhancement introduces **structured self-service capabilities for dealers** , while ensuring all -actions remain governed by defined validations, internal reviews, and approval workflows as per -RE standards. - -The Dealer role is enabled to perform the following activities: - - -- **Resignation Initiation** - -``` -The dealer can initiate the resignation process directly through the portal , submit the -reason for exit, and track the status of the request across the defined review, clearance, -and closure stages. -``` - **Relocation Request Submission** ``` @@ -339,600 +132,13 @@ the dealership from the current location to a new proposed location. The request routed for internal feasibility assessment, validation, and management approval before execution. ``` -- **Change in Constitution Request** -``` -The dealer can initiate a Change in Constitution request to seek approval from RE -management for ownership or structural changes within the dealership. Upon approval, -the dealer may proceed with the legally compliant transition. -``` -``` -Supported Change in Constitution scenarios include: -``` -``` -o Proprietorship (Single Owner) → Partnership -o Proprietorship → LLP (Limited Liability Partnership) -o Proprietorship → Private Limited -o Partnership → LLP -o Partnership → Private Limited -o Private Limited → LLP -o Private Limited → Partnership -``` All dealer-initiated requests are subject to **defined validations, mandatory document submissions, role-based reviews, and approvals**. The dealer’s access is **restricted to initiation, document upload, and status visibility** , with **final decision-making authority retained by authorized internal stakeholders of RE** -### 2.2 External & Integrated Stakeholders -**2.2.1 FDD (Financial Due Diligence Partner)** - -External agency responsible for assessing the applicant’s financial health, verifying credentials, -and uploading due diligence reports into the system. - - -**2.2.2 Dealer / Applicant** -External user who applies for dealership, uploads required documents, participates in -interviews, and later accesses the portal for resignation or closure status. - -## 3 Definitions and Acronyms - -``` -Acronym Full Form / Description -RE Royal Enfield -DD Dealer Development -DD-AM Dealer Development – Area Manager -DD-ZM Dealer Development – Zonal Manager -DD-Lead Dealer Development – Lead -DD-Head Dealer Development – Head -RBM Regional Business Manager -ZBH Zonal Business Head -NBH National Business Head -ASM Area Sales Manager -FDD Financial Due Diligence (External Partner/Agency) -LOI Letter of Intent -EOR Essential Operating Requirements -LOA Letter of Appointment -F&F Full and Final (Dealer Settlement) -KT Matrix Evaluation Matrix used for scoring applicants -``` -## 4 HiFi Wireframes & Flow of Application - -HiFi Wireframes : https://mono-human-93592950.figma.site - -### 4.1 Dealer onboarding - Process Flow Overview - -The **Dealer Onboarding Workflow** outlines the end-to-end sequence through which a dealership -application progresses — from initial registration to final inauguration and operational readiness. - - -**4.1.1 Step-by-Step Process Flow** - -``` -4.1.1.1 Application Initiation -``` -- The **applicant (dealer prospect)** submits an online application through the Dealer - Onboarding Portal. -- The system checks the **location’s availability** in the Royal Enfield dealership network: - o If the location has **no open opportunity** , a **Non-Opportunity Email** is triggered - automatically. - o If an opportunity exists, the applicant receives an **Opportunity Email** with login - credentials and a link to the **Dealer Questionnaire**. - -``` -4.1.1.2 Questionnaire Completion -``` -- The applicant fills out the **comprehensive questionnaire** covering business, infrastructure, - and financial readiness. -- The system auto-scores responses, generating a **Questionnaire Score** and **initial** - **ranking** for that applicant. - - -- Completed applications move to the **Admin review bucket**. -- The system shall trigger automated reminders to users for completing the - questionnaire. These **reminders will be sent through WhatsApp** , to ensure timely - submission. Reminder needs to be configured from Admin. - -``` -4.1.1.3 Admin Validation & Shortlisting -``` -- **DD-Admin** reviews all submitted applications and validates details and attached - documents. -- Based on eligibility, applications are either **shortlisted** for evaluation or **archived** for - future opportunities. -- Shortlisted applications are distributed to respective **zones or regions** for further - assessment. - -``` -4.1.1.4 Interview Evaluation (Multi-Level Process) -``` -- Admin schedules interviews in **Level 1** , **Level 2** , and **Level 3** , as applicable. -- Each interview can be **Virtual or Physical** , with calendar invites sent via Google Calendar. -- Evaluators at each level (DD-ZM, RBM, DD-Lead, ZBH, NBH, DD-Head) record their - feedback through: - o **KT Matrix Scoring** (quantitative) - o **Interview Feedback Form** (qualitative) -- The system consolidates panel feedback and generates an **AI-driven summary and** - **ranking** for decision support. - -``` -4.1.1.5 Financial Due Diligence (FDD) & Finance Review -``` -- Upon shortlisting, the application is assigned to the **FDD Team (external agency)** for - financial validation. -- FDD users, using SSO credentials, can: - o View assigned applications in a restricted interface. - o Upload FDD reports and add remarks in the **Work Notes** section. - o Flag cases of **non-responsiveness** or incomplete data, returning them to Admin. -- The **Finance team** reviews submitted FDD reports, validates findings, and decides - whether the application proceeds to **LOI approval**. The finance team is not the decision - maker for LOI Issuance. - -``` -4.1.1.6 LOI (Letter of Intent) Approval & Issuance -``` -- Based on Finance clearance, **DD-Head and NBH** review and approve the **LOI request**. -- The system tracks document approvals, timestamps, and supporting artefacts. - - -- Once approved, the LOI document is generated, uploaded, and shared **with the** - **applicant via official email communication** and not on WhatsApp -- Notification emails are triggered to all relevant stakeholders. - -``` -4.1.1.7 Dealer Code Generation & Setup -``` -- After LOI issuance, the **DD-Admin triggers** the Dealer Code creation process. Based on - this trigger, the **Dealer Code is created in the SAP Master** and **mapped to the applicant** - within the system. -- The code links all downstream modules, including Architectural, Statutory, and EOR - checklists. - -``` -4.1.1.8 Architectural Work & Statutory Documentation -``` -- Architectural activities are initiated (site plans, layout approvals, branding elements). -- The applicant and assigned Architecture Team upload documents, drawings, and - blueprints. -- In parallel, the applicant uploads **Statutory Documents** such as: - o GST certificate, PAN, Partnership Deed, Firm Registration, Rental/Lease - Agreement, etc. -- Each upload is timestamped and visible with file name, uploader, and document type. - -``` -4.1.1.9 Payment Verification & Finance Validation -``` -- Applicant uploads proof of advance payment or security deposit. -- The **Finance team** verifies payment details (transaction ID, amount, and bank record). -- Status is updated to **Verified** once the payment is reconciled. -- Verified payment triggers readiness for final operational setup. - -``` -4.1.1.10 Essential Operating Requirements (EOR) Checklist -``` -- All functional teams (Sales, Service, IT, Finance, Training, Architecture) verify their - respective readiness parameters. -- Progress is tracked through a **completion bar** until 100% EOR compliance is achieved. -- The **EOR checklist is initiated only after LOA issuance**. All functional teams verify their - respective readiness parameters, and progress is tracked until **100% EOR compliance** is - achieved. - -``` -4.1.1.11 LOA (Letter of Authorization) & Final Go-Live -``` -- After LOI issuance and Dealer Code generation, the **Letter of Authorization (LOA) is** - **generated and approved by NBH and DD-Head**. Upon successful LOA issuance, the - - -``` -application proceeds to the Essential Operating Requirements (EOR) checklist for final -readiness verification. -``` -- Final verification includes: - -``` -o EOR document review -o Brand readiness assessment -o Site validation and inspection -``` -- The **LOA** officially authorizes the dealership to operate under Royal Enfield. - -``` -4.1.1.12 Inauguration & Closure -``` -- Post-authorization, the **Inauguration** event is scheduled and logged. -- Completion of inauguration marks the dealership as **Active** in the system. - -``` -4.1.1.13 System-Driven Governance & Audit -``` -- Each stage automatically logs: - o User action, timestamp, and remarks - o Uploaded artefacts and version control - o Notifications sent and approvals received -- The entire lifecycle remains accessible under **Audit Trail** for future reference, compliance, - or offboarding workflows. - -### 4.2 Dealer Resignation – Process Flow Overview - -**4.2.1.1 Overview** - -``` -The Dealer Resignation Process manages the structured offboarding of a dealership initiated -by the dealer. The process begins when a dealer formally submits their resignation via -email to the Area Sales Manager (ASM) , after which the workflow transitions into the -system-managed approval sequence. -``` -``` -Dealer resignation requests are initiated by the dealer through the portal and subsequently -reviewed and processed by Admin, Finance, Legal, and relevant business stakeholders. -``` -``` -This flow ensures that each resignation is verified, discussed, and approved across all -required levels — maintaining proper documentation, compliance, and traceability until the -final Legal Acceptance Letter is issued. -``` - -**4.2.2 Step-by-Step Process Flow** - -``` -4.2.2.1 Dealer Initiation -``` -- The dealer submits a **formal resignation email** on the dealership’s official letterhead to - the **ASM**. -- The resignation reason must be clearly stated (e.g., personal, financial, business - restructuring). -- The **dealer is provided portal access** to initiate the resignation request directly through - the system. The dealer submits resignation details, reason for exit, and proposed - timeline via the portal, after which the request enters the internal review and clearance - workflow. - -``` -4.2.2.2 ASM Review -``` -- The **ASM** reviews the dealer’s resignation request and supporting letter. -- Uploads the **resignation email** and **dealer’s letterhead document** onto the portal. -- Adds remarks summarizing the discussion and reason for resignation. -- Forwards the request to **RBM + DD-ZM** for evaluation. - -``` -4.2.2.3 RBM + DD-ZM Joint Evaluation -``` -- The **Regional Business Manager (RBM)** and **Dealer Development Zonal Manager (DD-** - **ZM)** review the uploaded documents. -- Conduct a joint discussion with the dealer to confirm the intent and understand any - issues. -- Uploads the **Minutes of Meeting (MOM)** or discussion summary. -- Adds comments and recommendations before forwarding to **Zonal Business Head** - **(ZBH)**. -- Actions available at this stage: - o **Approve** → Send forward for next-level review - o **Send Back for Clarification** → Returns to ASM - o **Withdraw** → Cancels the request (with remarks logged) - -``` -4.2.2.4 ZBH Review -``` -- The **Zonal Business Head (ZBH)** reviews the resignation summary and all remarks. -- Adds their comments and recommendations. -- Forwards the request to **DD-Lead** through the system. -- Worknote is updated automatically to reflect action and timestamp. -- The resignation request is reviewed by authorized business stakeholders, - including **RBM, ZBH, and DD-Head**. During the review stage, the **ZBH is authorized to** - - -``` -Send Back or Revoke the resignation request for clarification or correction. Send Back -actions are communicated to the dealer and internal teams through Work Notes , with -mandatory remarks captured for traceability. -``` -``` -4.2.2.5 DD-Lead Review -``` -- The **DD-Lead** consolidates all discussions, documents, and feedback. -- Prepares a **Resignation Presentation** with recommendations and supporting data. -- Uploads the presentation to the portal. -- Forwards the case to **NBH** for final decision. -- The resignation request is reviewed by the **DD-Lead and DD-Head**. At this stage, both - roles are authorized to **Send Back or Revoke** the resignation request for clarification, - correction, or reconsideration. **Send Back actions are communicated through Work** - **Notes** , with **mandatory remarks** recorded for audit and traceability. - -``` -4.2.2.6 NBH Final Approval -``` -- The **National Business Head (NBH)** reviews the entire resignation dossier. -- Adds final remarks with one of the following outcomes: - o **Approve** → Case moves automatically to Legal for letter issuance. - o **Send Back for Clarification** → Returns to DD-Lead or ZBH for revalidation. - o **Hold** → Temporarily pauses the process pending further discussion. -- Upon approval, the system triggers a **Worknote Notification** to DD-Lead, RBM, ZBH, and - Finance teams. -- The resignation request is reviewed by the **NBH** , who may **Approve, Send Back, or** - **Revoke** the request based on business considerations. Any **Send Back or Revoke action** - **must be accompanied by remarks recorded in Work Notes** , ensuring transparent - communication and governance. - -``` -4.2.2.7 Legal Acceptance Letter -``` -- Once approved by **NBH** , the request is **auto-assigned to the Legal team**. -- Legal verifies the uploaded resignation and issues a **Resignation Acceptance Letter**. -- The letter is uploaded to the portal, visible to all relevant personas including **DD-** - **Admin** and **DD-AM**. -- Legal can also raise clarifications through worknotes if required. -- Upon completion of all approvals, the **Legal team issues the official Resignation** - **Acceptance Letter** and shares it with the dealer through authorized communication - channels. - - -``` -4.2.2.8 DD-Admin Closure -``` -- The **DD-Admin** downloads and shares the final **Resignation Acceptance Letter** with the - dealer. -- Marks the resignation as completed and triggers the **F&F (Full and Final) process** by - forwarding the case to the Finance team. -- The **Full & Final (F&F) settlement process is initiated only on the Last Working Day** - **(LWD) of the dealership**. The system shall **enable and trigger the F&F workflow strictly** - **based on the LWD date** , and **not based on the resignation approval date**. - -### 4.3 Dealer Termination – Process Flow Overview - -``` -4.3.1.1 Overview -``` -``` -The Dealer Termination Process governs the structured offboarding of a dealership initiated -internally by Royal Enfield due to operational, contractual, or ethical concerns. -It ensures that any termination—whether due to working-capital issues, poor performance, -or unethical practices —is investigated, documented, reviewed at multiple managerial levels, -and legally validated before final execution. The process maintains full transparency and -traceability through digital records, comments, and worknotes until the Termination -Letter is issued and the Full & Final (F&F) settlement begins. -``` -**4.3.2 Step-by-Step Process Flow** - -``` -4.3.2.1 ASM – Case Initiation -``` -- The **Area Sales Manager (ASM)** regularly visits dealers and records **Minutes of Meeting** - **(MOM)** for performance or compliance concerns. -- After two consecutive unsatisfactory commitments or escalations, the ASM initiates - a **Termination Request** in the portal. -- Fills all operational details (Dealer Code, LOI, LOA, Sales Data, etc.), selects - a **Termination Category** (Working Capital, Performance, Unethical Practice), and - uploads supporting documents (MOMs, commitments, dealer letters). -- Submits the case to **RBM + DD-ZM** for review. - -``` -4.3.2.2 RBM + DD-ZM Review -``` -- The **Regional Business Manager (RBM)** and **Dealer Development Zonal Manager (DD-** - **ZM)** jointly evaluate the case. - - -- Conduct a meeting with the dealer and record fresh MOMs; upload dealer - commitments on letterhead. -- Provide remarks and supporting evidence. -- Actions available: - o **Approve** → Forward to ZBH - o **Send Back for Clarification** → Returns to ASM with comments - o **Withdraw** → Terminates workflow with justification - -``` -4.3.2.3 ZBH Review -``` -- The **Zonal Business Head (ZBH)** reviews the full chronology (ASM visits, RBM/DD-ZM - remarks, uploaded MOMs). -- Validates escalation authenticity and dealer communication record. -- Adds remarks and forwards to **DD-Lead** for deeper review. -- The termination request is reviewed by the **ZBH** , who is authorized to **Approve, Send** - **Back, or Revoke** the termination request. **Send Back actions are communicated** - **through Work Notes** , with **mandatory remarks** recorded for traceability. - -``` -4.3.2.4 DD-Lead Review & Legal Assignment -``` -- The **DD-Lead** cross-verifies case chronology with all stakeholders (ASM, RBM, ZBH). -- Prepares a **Termination Presentation** summarizing facts, dealer history, and - recommendations. -- Assigns the case to **Legal Team** for inputs through the system (visible in worknotes). -- The termination request is reviewed by the **DD-Lead** , who is authorized to **Send Back or** - **Revoke** the termination request for clarification or reconsideration. All such actions - require **mandatory remarks captured in Work Notes**. - -``` -4.3.2.5 Legal Verification -``` -- The **Legal Team** reviews documentation, ensures contractual breaches are well- - supported, and checks all precedents. -- May raise queries via **Worknotes** or **Send Back** the case to DD-Lead for clarification. -- Once satisfied, forwards the verified case back to **DD-Lead** for next action. - -``` -4.3.2.6 DD-Lead → DD-Head Review -``` -- The **DD-Lead** attaches Legal’s feedback and forwards the case to **DD-Head** for strategic - review. -- **DD-Head** validates the case, evaluates impact, and presents it to **National Business** - **Head (NBH)** for final business decision. - - -``` -4.3.2.7 NBH Evaluation -``` -- The **NBH** reviews all documentation and Legal remarks. -- May choose one of three actions: - o **Go Ahead** → Approve for issuance of **Show Cause Notice (SCN)** - o **Hold Decision** → Pause temporarily for further monitoring or negotiation - o **Raise Query** → Sends back to DD-Lead for additional input - -``` -4.3.2.8 Show Cause Notice (SCN) Issuance -``` -- Upon NBH approval, the system triggers Legal to prepare and issue the **SCN**. -- The **DD-Lead** formally shares the SCN with the dealer through **DD-Admin**. -- Dealer replies to the SCN by email or letter, which **DD-Admin uploads** to the portal. -- For termination cases, the **F&F settlement process is triggered only on the Last** - **Working Day (LWD)**. The system shall **control the F&F trigger based on the LWD date** , - irrespective of the termination approval date. - -``` -4.3.2.9 Evaluation of Dealer Response -``` -- The **DD-Lead** , **ZBH** , **RBM** , and **DD-Head** jointly review the dealer’s SCN response. -- Uploads internal comments, Legal feedback, and recommendation for NBH’s final - decision. - -``` -4.3.2.10 NBH Final Decision -``` -- The **NBH** reviews the compiled case with Legal advice and decides among: - o **Approve Termination** → Moves to CEO/CCO for confirmation - o **Reconsider** → Allow additional time or corrective action - o **Reject** → Case closed without termination - -``` -4.3.2.11 11. CEO & CCO Authorization -``` -- **CEO** and **Chief Commercial Officer (CCO)** review the NBH-approved termination. -- Provide authorization on the portal. -- Once signed off, the decision becomes final. - -``` -4.3.2.12 12. Legal Termination Letter -``` -- The **Legal Team** generates the **Termination Letter** to the portal. -- The letter is auto-visible to **DD-Lead** , **DD-Admin** , and **Finance**. -- A system notification is triggered to all linked personas. - - -``` -4.3.2.13 13. DD-Admin Communication & F&F Trigger -``` -- The **DD-Admin** shares the official **Termination Letter** with the dealer and field team. -- Marks the case as “Terminated” in the portal. -- Forwards the case to **Finance** for **Full & Final Settlement** initiation. -- Updates the worknote with final remarks and due-date for settlement. - -### 4.4 Dealer Full & Final (F&F) Settlement – Process Flow - -``` -4.4.1.1 Overview -``` -The **Full & Final (F&F) Settlement Process** governs the financial closure of a dealership -following **Resignation** or **Termination**. -It ensures that all financial obligations between Royal Enfield and the dealer — -including **security deposits, recoveries, payables, and department-wise dues** — are -transparently reconciled, verified, and documented before closure. - -**4.4.2 Step-by-Step Process Flow** - -``` -4.4.2.1 F&F Initiation -``` -- Triggered automatically once the **Resignation Acceptance Letter** or **Termination** - **Letter** is uploaded by **Legal**. -- The **DD-Admin** or **DD-Lead** initiates the F&F case in the **Finance Dashboard** , which - creates a unique **FNF Case ID** linked to the dealer code. -- The system auto-fetches dealer details, associated documents, resignation/termination - date, and due dates. -- Notification is sent to the **Finance Team** and all functional departments to begin the - clearance process. - -``` -4.4.2.2 Department-wise Response Collection -``` -- The system automatically prompts all mapped **functional departments (16 in total)** to - submit their clearance inputs — including NOC, payables, recoveries, and remarks. -- Each department updates: - o Financial dues (if any) - o Clearance confirmation (NOC) - o Supporting document uploads (e.g., debit note, invoice copy) -- The system dynamically updates progress (e.g., _12/16 Departments Responded_ ) with - color-coded indicators: - o 🟢 **No Dues** – Cleared - - -``` -o 🔴 Dues Pending – Outstanding financial liability -o ⚪ Pending – Awaiting department input -``` -- SLA-based reminders are auto-triggered for pending responses nearing the deadline. - -``` -4.4.2.3 Finance Summary Consolidation -``` -- Once all departments respond, the **DD-Admin Team** consolidates inputs into the **Final** - **F&F Summary Sheet** , which consists of: - o **Payables to Dealer** (e.g., refundable deposits, reimbursements) - o **Receivables from Dealer** (e.g., outstanding invoices, recoveries) - o **Deductions** (policy penalties, non-compliance adjustments) -- At this stage, **department-claimed amounts are frozen** and become read-only for - departments. -- Finance does **not overwrite department claim values**. Instead, Finance validates each row - in a dedicated validation layer by recording: - - Finance decision (Accepted / Partially Accepted / Rejected / Under Clarification) - - Finance-validated amount - - Variance amount and mandatory variance reason (if changed) - - Supporting proof/document -- The system automatically calculates: - - Net Settlement = Total Payables – Total Receivables – Total Deductions - - Final totals are computed from **finance-validated values only**. -- Status updates to _Finance Summary Prepared_ once complete. - -``` -4.4.2.4 Internal Review & Clarification -``` -- The **Finance Team** may use the **Work Note** section to raise clarifications to **DD-** - **Lead** , **Legal** , or concerned departments. -- If discrepancies exist (e.g., mismatched values or missing NOCs), the case remains _Under_ - _Clarification_ until resolved. -- Once validated, Finance locks the summary for further edits. - -``` -4.4.2.5 Dealer Discussion & Acknowledgment -``` -- The **Finance Team** , along with **Legal** and **DD-Lead** , discusses the settlement summary - with the dealer. -- Dealer acknowledgment is captured either via written confirmation or attached email - communication. -- The case then proceeds for **Final Finance Approval**. - -``` -4.4.2.6 Final Finance Approval & Payment Processing -``` -- The **Finance Team** reviews the approved summary and enters payment or recovery - details: - o **Transaction Type:** RTGS / NEFT / Cheque - o **Transaction ID & Date** - o **Bank Name & Account Details** (auto-fetched from dealer profile) - o **Settlement Remarks** -- Finance takes one of three actions: - - -``` -o Approve Settlement → Marks the case as “Finance Approved.” -o Request Clarification → Sends query to DD-Lead or Admin. -o Reject Summary → Returns for re-verification. -``` -- Upon approval, notifications are sent to DD-Admin and Legal for record update. - -``` -4.4.2.7 F&F Completion & Closure -``` -- Once approved, the case is automatically marked **Completed** , and the **Finance** - **Dashboard** updates status as _F&F Closed_. -- The **Settlement Proof** (e.g., payment confirmation or recovery adjustment) is uploaded - by Finance. -- The **DD-Admin** communicates official closure to the dealer and archives all artefacts. -- System triggers final alerts to DD-Lead, NBH, and Legal confirming completion. -- The case is archived in the **Audit Trail** for future reference. - -### 4.5 Finance Team – Process Flow - -``` 4.5.1.1 Overview ``` The **Finance Team Process Flow** governs all financial activities related to dealer lifecycle @@ -945,42 +151,6 @@ Modules** , ensuring accurate financial updates and timely closure of all financ **4.5.2 Step-by-Step Process Flow** -``` -4.5.2.1 Security Deposit Validation (Onboarding Stage) -``` -- **Trigger:** - Initiated when a new dealer’s onboarding application reaches the Finance stage after - DD approval. -- **Action:** - The **Finance Team** verifies the **Security Deposit** payment made by the dealer - via **RTGS/NEFT** or other approved channels. -- **Outcome:** - o Verified deposits are marked as _Approved_ , triggering system notifications to DD- - Admin and DD-Lead. - - -``` -o The verified payment data is stored permanently in the dealer’s financial profile -for audit and reference. -``` -``` -4.5.2.2 Financial Summary Preparation -``` -- **Action:** - Once departmental inputs are received, Finance consolidates all data into the **F&F** - **Summary Sheet**. -- **System Steps:** - o Segregates entries under: - ▪ **Payables to Dealer** (e.g., refundable deposits, reimbursements) - ▪ **Receivables from Dealer** (e.g., outstanding payments, penalties) - ▪ **Deductions** (e.g., policy recoveries, warranty holdbacks) - o The system auto-calculates: - o Net Settlement = Total Payables – Total Receivables – Deductions - o Finance validates each record, uploads supporting documents (receipts, invoices, - credit notes), and adds remarks. -- **Outcome:** - The computed **Net Settlement Amount** is reflected in the dashboard, categorized - as _Payable to Dealer_ or _Recoverable from Dealer_. ``` 4.5.2.3 Internal Clarification & Approval @@ -994,44 +164,9 @@ for audit and reference. o After reconciliation, Finance locks the summary and updates case status to _Ready for Approval_. -``` -4.5.2.4 Final Review & Dealer Confirmation -``` -- **Action:** - Finance conducts an internal review of the consolidated settlement and initiates a - financial discussion with the dealer. -- **System Steps:** - o Reviews summary details on-screen with Legal and DD-Lead. - o Records dealer’s acknowledgment via Work Note or attached email - confirmation. - o Once confirmed, proceeds to payment verification. +` -``` -4.5.2.5 Payment Processing & Record Update -``` -- **Action:** - Finance executes the financial transaction (payment to or recovery from dealer). -- **System Steps:** - o Enters **Mode of Payment** , **Transaction Reference Number** , **Date** , and **Remarks**. - o Uploads proof of payment (RTGS confirmation or bank statement). - o Marks case as _Finance Approved_ and sends completion notification to DD-Admin - and Legal. - o System automatically updates the **Progress Timeline** and **Audit Trail**. - -``` -4.5.2.6 F&F Completion & Closure -``` -- **Action:** - Finance reviews all entries, confirms ledger reconciliations, and marks case - as **Completed**. -- **System Steps:** - o Locks financial data and supporting artefacts. - o Status changes to _Closed – F&F Completed_. - o Final confirmation sent to all stakeholders — DD-Lead, NBH, DD-Head, Legal, and - DD-Admin. - o Finance Dashboard updates counters under “Completed Cases.” - ## 5 System Features & Requirements Here, we describe the **system features** along with their respective **Width** and **Depth** to provide @@ -1207,49 +342,3 @@ rules. - Track document status and progress - Maintain history and audit trail - ---- - -## 13 Non-Functional Requirements - -``` -Category Requirement -Performance Average response time < 3 seconds for standard operations. -Scalability Should scale horizontally on GCP. -Security JWT tokens, encrypted passwords, HTTPS enforced. -Usability Intuitive UI, consistent icons, and simple navigation. -Reliability 99% uptime target. -Backup & Recovery Daily database backup and weekly full snapshot. -Compliance Follows RE IT data privacy guidelines. -``` -## 14 Technology Matrix - -``` -Component Specification -Database PGSQL (Managed or local instance) -Application Stack Node.js (Backend) + React.js (Frontend) -Authentication RE SSO Bridge -``` -## 15 Infra requirements & System Hygiene - -``` -Component Specification -Environment QA / Testing -# of Virtual Machines (VMs) 1 -CPU Configuration 4 - Core -Memory (RAM) 16 GB -Disk Size 500 GB -Operating System Ubuntu 24.04 LTS -``` - -``` -Storage Type Cloud -``` -Backup and Recovery - -- Daily incremental and weekly full backups. -- Restore process must not exceed 2 hours. - -## 16 Not in scope - -Anything which comes beyond the scope defined above in terms of Width and depth diff --git a/src/common/config/constants.ts b/src/common/config/constants.ts index a00a92e..a9c152c 100644 --- a/src/common/config/constants.ts +++ b/src/common/config/constants.ts @@ -176,7 +176,7 @@ export const OVERALL_STATUS_TO_DB_CURRENT_STAGE: Record< // Termination Stages export const TERMINATION_STAGES = { SUBMITTED: 'Submitted', - RBM_REVIEW: 'RBM Review', + RBM_REVIEW: 'RBM + DD-ZM Review', ZBH_REVIEW: 'ZBH Review', DD_LEAD_REVIEW: 'DD Lead Review', LEGAL_VERIFICATION: 'Legal Verification', @@ -496,6 +496,7 @@ export const RESIGNATION_DOCUMENT_TYPES = [ 'Legal Communication', 'Handover Document', 'Settlement Supporting Document', + 'PPT Presentation', 'Other' ] as const; @@ -523,7 +524,7 @@ export const TERMINATION_DOCUMENT_TYPES = [ export const TERMINATION_DOCUMENT_STAGES = [ 'Submitted', - 'RBM Review', + 'RBM + DD-ZM Review', 'ZBH Review', 'DD Lead Review', 'Legal Verification', @@ -569,5 +570,5 @@ export const STAGES_MAP = { 'RESIGNATION': ['Submission', 'Regional Review', 'ZM Review', 'ZBH Review', 'Finance Review', 'DDL Review', 'Approved'], 'RELOCATION': ['Initiated', 'ASM Review', 'ZM Review', 'ZBH Review', 'Completed'], 'CONSTITUTIONAL_CHANGE': ['Draft', 'Legal Review', 'Approved'], - 'TERMINATION': ['Hearing', 'Review', 'Closed'] + 'TERMINATION': ['Submitted', 'RBM + DD-ZM Review', 'ZBH Review', 'DD Lead Review', 'Legal Verification', 'NBH Evaluation', 'SCN', 'Personal Hearing', 'Completed'] } as const; diff --git a/src/common/middleware/upload.ts b/src/common/middleware/upload.ts index d7a2420..1047d63 100644 --- a/src/common/middleware/upload.ts +++ b/src/common/middleware/upload.ts @@ -48,7 +48,9 @@ const fileFilter = (req: Request, file: Express.Multer.File, cb: FileFilterCallb 'application/msword', 'application/vnd.openxmlformats-officedocument.wordprocessingml.document', 'application/vnd.ms-excel', - 'application/vnd.openxmlformats-officedocument.spreadsheetml.sheet' + 'application/vnd.openxmlformats-officedocument.spreadsheetml.sheet', + 'application/vnd.ms-powerpoint', + 'application/vnd.openxmlformats-officedocument.presentationml.presentation' ]; if (allowedTypes.includes(file.mimetype)) { diff --git a/src/common/utils/handlebars-email.ts b/src/common/utils/handlebars-email.ts index cf34176..7e821e2 100644 --- a/src/common/utils/handlebars-email.ts +++ b/src/common/utils/handlebars-email.ts @@ -61,7 +61,8 @@ export function registerEmailPartials(h: typeof handlebars = handlebars): void { const map: Record = { email_header: 'email_header.html', email_footer: 'email_footer.html', - primary_cta: 'primary_cta.html' + primary_cta: 'primary_cta.html', + cta_button: 'primary_cta.html' }; let loaded = 0; diff --git a/src/common/utils/workflow-email-notifications.ts b/src/common/utils/workflow-email-notifications.ts index 1c8eacb..52df323 100644 --- a/src/common/utils/workflow-email-notifications.ts +++ b/src/common/utils/workflow-email-notifications.ts @@ -2,7 +2,14 @@ import db from '../../database/models/index.js'; import { Op } from 'sequelize'; import { sendEmail } from './email.service.js'; import { NotificationService } from '../../services/NotificationService.js'; -import { REQUEST_TYPES, ROLES } from '../config/constants.js'; +import { + APPLICATION_STAGES, + TERMINATION_STAGES, + CONSTITUTIONAL_STAGES, + RELOCATION_STAGES, + REQUEST_TYPES, + ROLES +} from '../config/constants.js'; const { RequestParticipant, User, Outlet, District } = db; @@ -134,7 +141,8 @@ export async function notifyRelocationSubmittedEmails( dealerName, requestId: code, link: `${base}/relocation-requests/${request.id}`, - ctaLabel: 'View request' + ctaLabel: 'View request', + distance: request.distance || '0' } ).catch((err) => console.error('[notifyRelocationSubmittedEmails] dealer:', err)); } @@ -157,9 +165,10 @@ export async function notifyRelocationSubmittedEmails( placeholders: { dealerName, requestId: code, - outletCode: outlet?.code || '', + outletCode: outlet?.code || 'N/A', link: `${base}/relocation-requests/${request.id}`, - ctaLabel: 'Review relocation', + ctaLabel: 'Review request', + distance: request.distance || '0', phone: asmPhone || '' } }).catch((err) => console.error('[notifyRelocationSubmittedEmails] ASM:', err)); @@ -184,7 +193,7 @@ export async function resolveNextActors(requestId: string, requestType: string, 'ASM': [ROLES.ASM], 'ASM Review': [ROLES.ASM], 'RBM': [ROLES.RBM], - 'RBM Review': [ROLES.RBM], + 'RBM + DD-ZM Review': [ROLES.RBM, ROLES.DD_ZM], 'ZM Review': [ROLES.DD_ZM], 'DD ZM Review': [ROLES.DD_ZM], 'ZBH': [ROLES.ZBH], @@ -239,10 +248,12 @@ export async function resolveNextActors(requestId: string, requestType: string, 'Service Clearance': [ROLES.SERVICE_MANAGER], 'Accounts Clearance': [ROLES.ACCOUNTS_MANAGER], 'F&F Initiated': [ROLES.DD_ADMIN], + // SRS §7.5.2 — Legal acceptance letter upload triggers notification to DD-Admin + ASM + 'Resignation Legal Closure': [ROLES.DD_ADMIN, ROLES.ASM], // --- Termination Specific --- - 'Show Cause Notice': [ROLES.NBH], - 'Personal Hearing': [ROLES.NBH], + 'Show Cause Notice': [ROLES.LEGAL_ADMIN], + 'Personal Hearing': [ROLES.NBH, ROLES.DD_LEAD, ROLES.ZBH, ROLES.RBM, ROLES.DD_HEAD], 'Legal - Termination Letter': [ROLES.LEGAL_ADMIN] }; @@ -376,39 +387,67 @@ export async function notifyStakeholdersOnTransition( } else if (isDealer) { // ── Dealer: in-app always; email + WhatsApp only on terminal events ── - // SRS §2052: rejection notifies dealer/applicant via email & WhatsApp - // SRS §2324: approvals/outcomes delivered via email & WhatsApp const terminalChannels: Array<'system' | 'email' | 'whatsapp'> = ['system', 'email']; if (phone) terminalChannels.push('whatsapp'); + let templateCode = 'WORKFLOW_STATUS_UPDATE_DEALER'; + const placeholders: any = { + requestId: metadata.code, + link: metadata.link, + targetStage, + dealerName: metadata.dealerName, + phone: phone || '' + }; + + // Override for Termination Final Closure + if (targetStage === TERMINATION_STAGES.TERMINATED) { + templateCode = 'TERMINATION_FINAL_CLOSURE_DEALER'; + placeholders.terminationDate = new Date().toLocaleDateString('en-IN', { dateStyle: 'medium' }); + } + + // Override for Constitutional Change Completion + if (targetStage === CONSTITUTIONAL_STAGES.COMPLETED && requestType === REQUEST_TYPES.CONSTITUTIONAL) { + templateCode = 'CONSTITUTIONAL_CHANGE_APPROVED'; + placeholders.proposedConstitution = metadata.remarks || 'Approved Structure'; // Remarks often contain the final structure or approval note + } + + // Override for Relocation Completion + if (targetStage === RELOCATION_STAGES.COMPLETED && requestType === REQUEST_TYPES.RELOCATION) { + templateCode = 'RELOCATION_APPROVED'; + placeholders.newLocation = metadata.remarks || 'Approved Location'; // Remarks usually contain the site address + } + await NotificationService.notify(u.id, u.email, { title: isTerminalEvent ? `Application ${isRejected ? 'Rejected' : isRevoked ? 'Revoked' : 'Completed'}: ${metadata.code}` : `Application Update: ${metadata.code}`, message: `Your request is now at "${targetStage}". ${metadata.action}`, channels: isTerminalEvent ? terminalChannels : ['system'], - templateCode: 'WORKFLOW_STATUS_UPDATE_DEALER', - placeholders: { - requestId: metadata.code, - link: metadata.link, - targetStage, - dealerName: metadata.dealerName, - phone: phone || '' - } + templateCode, + placeholders }).catch(e => console.error('[notifyStakeholders] dealer:', e)); } else if (isTerminalEvent && isKeyObserverRole) { - // ── Key observers (DD Lead, DD Head, NBH, DD Admin) on terminal events — in-app only ── + // ── Key observers (DD Lead, DD Head, NBH, DD Admin) on terminal events ── + let templateCode = 'WORKFLOW_STATUS_UPDATE_DEALER'; + const placeholders: any = { + requestId: metadata.code, + link: metadata.link, + targetStage, + recipientName: u.fullName || 'Team' + }; + + // Override for Internal Notification of Legal Letter + if (targetStage === TERMINATION_STAGES.LEGAL_LETTER) { + templateCode = 'TERMINATION_LETTER_ISSUED'; + } + await NotificationService.notify(u.id, u.email, { title: `Case Closed: ${metadata.code}`, message: `${metadata.code} has been ${isRejected ? 'rejected' : isRevoked ? 'revoked' : 'completed'} at stage "${targetStage}".`, - channels: ['system'], - templateCode: 'WORKFLOW_STATUS_UPDATE_DEALER', - placeholders: { - requestId: metadata.code, - link: metadata.link, - targetStage - } + channels: ['system', 'email'], // Internal teams get email too on closure + templateCode, + placeholders }).catch(e => console.error('[notifyStakeholders] observer:', e)); } } diff --git a/src/constants/allowed-email-template-codes.ts b/src/constants/allowed-email-template-codes.ts index 88a6f1b..bbb9137 100644 --- a/src/constants/allowed-email-template-codes.ts +++ b/src/constants/allowed-email-template-codes.ts @@ -5,23 +5,33 @@ export const ALLOWED_EMAIL_TEMPLATE_CODES = [ 'APPLICANT_SHORTLISTED', 'APPLICANT_REJECTED', 'CONSTITUTIONAL_CHANGE_SUBMITTED', + 'CONSTITUTIONAL_CHANGE_APPROVED', 'CONSTITUTIONAL_CHANGE_UPDATE', 'DEALER_CODE_READY', 'EOR_COMPLETED', 'FNF_INITIATED', + 'FNF_SUMMARY_PREPARED', + 'FNF_SETTLEMENT_APPROVED', 'GENERIC_NOTIFICATION', + 'INAUGURATION_COMPLETED', 'INTERVIEW_SCHEDULED', 'INTERVIEW_SCHEDULED_APPLICANT', 'INTERVIEW_SCHEDULED_PANELIST', + 'INTERVIEW_RESCHEDULED_APPLICANT', + 'INTERVIEW_RESCHEDULED_PANELIST', + 'INTERVIEW_CANCELLED_APPLICANT', + 'INTERVIEW_CANCELLED_PANELIST', 'LOA_ISSUED', 'LOI_ISSUED', 'NON_OPPORTUNITY', + 'ONBOARDING_PAYMENT_VERIFIED', 'ONBOARDING_STATUS_UPDATE', 'OPPORTUNITY', 'QUESTIONNAIRE_REMINDER', 'QUESTIONNAIRE_SUBMITTED', 'RELOCATION_RECEIVED', 'RELOCATION_SUBMITTED', + 'RELOCATION_APPROVED', 'RELOCATION_UPDATE', 'RESIGNATION_APPROVED', 'RESIGNATION_RECEIVED', @@ -33,6 +43,8 @@ export const ALLOWED_EMAIL_TEMPLATE_CODES = [ 'SLA_ESCALATION', 'TERMINATION_INITIATED', 'TERMINATION_SCN_ISSUED', + 'TERMINATION_LETTER_ISSUED', + 'TERMINATION_FINAL_CLOSURE_DEALER', 'TERMINATION_UPDATE', 'USER_ASSIGNED', 'WORKNOTE_NOTIFICATION', diff --git a/src/emailtemplates/constitutional_change_approved.html b/src/emailtemplates/constitutional_change_approved.html new file mode 100644 index 0000000..ff7edb6 --- /dev/null +++ b/src/emailtemplates/constitutional_change_approved.html @@ -0,0 +1,31 @@ +{{> email_header}} + +
+

Constitutional Change Approved — {{requestId}}

+

Dear {{dealerName}},

+

+ We are pleased to inform you that your request for a **Change in Constitution** (Request ID: {{requestId}}) + has been officially approved by the Royal Enfield management. +

+ +
+ New Constitution: {{proposedConstitution}}
+ Status: Approved & Updated +
+ +

+ The system records have been updated to reflect this change. You can now proceed with the legally compliant transition + as per the approved structure. +

+ +
+ View Request Details +
+ +

+ Best Regards,
+ Royal Enfield Dealer Development Team +

+
+ +{{> email_footer}} diff --git a/src/emailtemplates/fnf_settlement_approved.html b/src/emailtemplates/fnf_settlement_approved.html new file mode 100644 index 0000000..d63de27 --- /dev/null +++ b/src/emailtemplates/fnf_settlement_approved.html @@ -0,0 +1,29 @@ +{{> email_header}} + +
+

F&F Settlement Approved — {{fnfId}}

+

Dear Team,

+

+ The final Full & Final (F&F) settlement for dealer {{dealerName}} + (F&F ID: {{fnfId}}) has been Approved by Finance. +

+ +
+ Settlement Amount: ₹{{settlementAmount}}
+ Status: Approved & Closed +
+ +

+ The DD-Admin and Legal teams are requested to update their records and proceed with final account closure. +

+ +
+ {{> cta_button}} +
+ +

+ All financial transactions related to this dealership exit are now finalized. +

+
+ +{{> email_footer}} diff --git a/src/emailtemplates/fnf_summary_prepared.html b/src/emailtemplates/fnf_summary_prepared.html new file mode 100644 index 0000000..6776538 --- /dev/null +++ b/src/emailtemplates/fnf_summary_prepared.html @@ -0,0 +1,29 @@ +{{> email_header}} + +
+

F&F Settlement Summary Prepared — {{fnfId}}

+

Dear Finance Team,

+

+ The initial Full & Final (F&F) settlement summary has been prepared for + {{dealerName}} (F&F ID: {{fnfId}}). +

+ +
+ Calculated Net Amount: ₹{{netAmount}}
+ Status: Pending Final Approval +
+ +

+ Please review the consolidated departmental responses and the settlement summary to proceed with final approval and payment processing. +

+ +
+ {{> cta_button}} +
+ +

+ Confidential: This summary contains sensitive financial data. Review only via authorized portal access. +

+
+ +{{> email_footer}} diff --git a/src/emailtemplates/inauguration_completed.html b/src/emailtemplates/inauguration_completed.html new file mode 100644 index 0000000..70b1808 --- /dev/null +++ b/src/emailtemplates/inauguration_completed.html @@ -0,0 +1,22 @@ +{{> email_header}} + +
+

Dealership Inauguration Logged — {{applicationId}}

+

Dear Team,

+

+ We are pleased to inform you that the inauguration for dealer + {{dealerName}} (Application ID: {{applicationId}}) + at {{location}} has been successfully logged on {{date}}. +

+ +

+ The dealership is now marked as Active in the system. All relevant teams are requested to + update their records accordingly. +

+ +

+ This is an automated notification confirming the completion of the onboarding lifecycle. +

+
+ +{{> email_footer}} diff --git a/src/emailtemplates/onboarding_payment_verified.html b/src/emailtemplates/onboarding_payment_verified.html new file mode 100644 index 0000000..a4967d3 --- /dev/null +++ b/src/emailtemplates/onboarding_payment_verified.html @@ -0,0 +1,29 @@ +{{> email_header}} + +
+

Payment Verified — {{applicationId}}

+

Dear Team,

+

+ Finance has successfully verified the {{paymentType}} for + {{dealerName}} (Application ID: {{applicationId}}). +

+ +
+ Verified Amount: ₹{{amount}}
+ Status: Verified & Approved +
+ +

+ The onboarding process can now proceed to the next stage. +

+ +
+ View Application +
+ +

+ This is an automated notification from the Royal Enfield Dealer Onboarding System. +

+
+ +{{> email_footer}} diff --git a/src/emailtemplates/relocation_approved.html b/src/emailtemplates/relocation_approved.html new file mode 100644 index 0000000..f28f815 --- /dev/null +++ b/src/emailtemplates/relocation_approved.html @@ -0,0 +1,31 @@ +{{> email_header}} + +
+

Relocation Approved — {{requestId}}

+

Dear {{dealerName}},

+

+ We are pleased to inform you that your request for **Dealership Relocation** (Request ID: {{requestId}}) + has been officially approved by the Royal Enfield management. +

+ +
+ New Location: {{newLocation}}
+ Status: Approved & Records Updated +
+ +

+ Our team will coordinate with you for the physical transition and site readiness audit. You can track the next steps + via the portal. +

+ +
+ View Request Details +
+ +

+ Best Regards,
+ Royal Enfield Dealer Development Team +

+
+ +{{> email_footer}} diff --git a/src/emailtemplates/relocation_received.html b/src/emailtemplates/relocation_received.html index 9a2342b..7636066 100644 --- a/src/emailtemplates/relocation_received.html +++ b/src/emailtemplates/relocation_received.html @@ -1,6 +1,33 @@ {{> email_header}} -

Hi {{dealerName}},

-

Your outlet relocation request {{requestId}} has been received.

-

You will receive email updates as the request moves through approvals.

-{{> primary_cta}} + +
+

Relocation Request Received — {{requestId}}

+

Dear {{dealerName}},

+

+ We have received your request for dealership relocation (Request ID: {{requestId}}). +

+ +

+ The internal feasibility assessment and multi-level review process have been initiated. + You will be notified of any document requirements or status updates via the portal and email. +

+ +
+ Current Status: ASM Review (In Progress) +
+ +
+ {{> cta_button}} +
+ +

+ You can track the real-time progress of your request by logging into the Dealer Portal. +

+ +

+ Best Regards,
+ Royal Enfield Dealer Development Team +

+
+ {{> email_footer}} diff --git a/src/emailtemplates/relocation_submitted.html b/src/emailtemplates/relocation_submitted.html index 62e8897..9ebfe41 100644 --- a/src/emailtemplates/relocation_submitted.html +++ b/src/emailtemplates/relocation_submitted.html @@ -1,7 +1,31 @@ {{> email_header}} -

New relocation request

-

A dealer has submitted an outlet relocation request.

-

Request ID: {{requestId}}
Outlet: {{outletCode}}

-

Please review in the Dealer Development portal.

-{{> primary_cta}} + +
+

New Relocation Request: {{requestId}}

+

Dear Team,

+

+ A new dealership relocation request has been submitted by {{dealerName}} + for outlet {{outletCode}}. +

+ +
+ Request ID: {{requestId}}
+ Outlet Code: {{outletCode}}
+ Distance from Existing Site: {{distance}} km +
+ +

+ Please log in to the Dealer Development portal to review the proposed location, property documents, + and feasibility details. +

+ +
+ {{> cta_button}} +
+ +

+ This is an internal workflow notification. Audit logs and case chronology are available on the portal. +

+
+ {{> email_footer}} diff --git a/src/emailtemplates/termination_final_closure.html b/src/emailtemplates/termination_final_closure.html new file mode 100644 index 0000000..cb42cc2 --- /dev/null +++ b/src/emailtemplates/termination_final_closure.html @@ -0,0 +1,30 @@ +{{> email_header}} + +
+

Notice of Termination — {{requestId}}

+

Dear {{dealerName}},

+

+ This is the official notification that your dealership agreement with Royal Enfield (Request ID: {{requestId}}) + has been formally terminated effective {{terminationDate}}. +

+ +

+ The final Termination Letter is available for your reference in the dealer portal. Your portal access will remain active + for a limited period to allow you to download relevant documents and track the Full & Final (F&F) settlement progress. +

+ +
+ {{> cta_button}} +
+ +

+ For any clarifications regarding the settlement process, please contact the Dealer Development Admin team. +

+ +

+ Best Regards,
+ Royal Enfield Dealer Development Team +

+
+ +{{> email_footer}} diff --git a/src/emailtemplates/termination_letter_issued.html b/src/emailtemplates/termination_letter_issued.html new file mode 100644 index 0000000..b371e69 --- /dev/null +++ b/src/emailtemplates/termination_letter_issued.html @@ -0,0 +1,25 @@ +{{> email_header}} + +
+

Termination Letter Generated — {{requestId}}

+

Dear {{recipientName}},

+

+ The official Termination Letter has been generated and uploaded to the portal for dealer + {{dealerName}} (Request ID: {{requestId}}). +

+ +

+ This letter is now visible to the DD-Lead, DD-Admin, and Finance teams. Please proceed with the necessary + administrative and financial closure steps. +

+ +
+ {{> cta_button}} +
+ +

+ This is an internal system notification. Detailed case chronology and audit logs are available on the portal. +

+
+ +{{> email_footer}} diff --git a/src/modules/assessment/assessment.controller.ts b/src/modules/assessment/assessment.controller.ts index dda231c..0b9588b 100644 --- a/src/modules/assessment/assessment.controller.ts +++ b/src/modules/assessment/assessment.controller.ts @@ -20,6 +20,18 @@ const getLocationAncestors = async (locationId: string): Promise => { const interviewStageCode = (level: number) => `INTERVIEW_LEVEL_${level}`; +const formatIST = (date: Date) => { + return new Intl.DateTimeFormat('en-IN', { + timeZone: 'Asia/Kolkata', + day: '2-digit', + month: 'short', + year: 'numeric', + hour: '2-digit', + minute: '2-digit', + hour12: true + }).format(date); +}; + const normalizeRoleCode = (value: unknown) => String(value || '') .trim() @@ -567,8 +579,9 @@ export const scheduleInterview = async (req: AuthRequest, res: Response) => { applicantName: application.applicantName, applicationId: application.applicationId, type, - scheduledAt: scheduledAtIso, - link: meetLink, + scheduledAt: formatIST(scheduledDateObj), + meetLink, + appLink: `${process.env.FRONTEND_URL || 'http://localhost:5173'}/onboarding/application/${application.id}`, phone: applicantPhone, ctaLabel: 'View Schedule' } @@ -682,8 +695,9 @@ export const scheduleInterview = async (req: AuthRequest, res: Response) => { applicantName: application?.applicantName || 'Applicant', applicationId: application?.applicationId || '', type, - scheduledAt: scheduledAtIso, - link: meetLink, + scheduledAt: formatIST(scheduledDateObj), + meetLink, + appLink: `${process.env.FRONTEND_URL || 'http://localhost:5173'}/onboarding/application/${application.id}`, phone: pPhone || '', ctaLabel: 'Open Assessment' } @@ -749,11 +763,81 @@ export const updateInterview = async (req: AuthRequest, res: Response) => { } await interview.update(updatePayload); + await interview.reload({ + include: [ + { + model: InterviewParticipant, + as: 'participants', + include: [{ model: User, as: 'user' }] + } + ] + }); const isCancelled = String(status || '').toLowerCase() === 'cancelled' && String(oldStatus || '').toLowerCase() !== 'cancelled'; const isRescheduled = typeof scheduledAt !== 'undefined' && String(status || '').toLowerCase() !== 'cancelled'; const eventType = isCancelled ? 'interview_cancelled' : (isRescheduled ? 'interview_rescheduled' : 'interview_updated'); + if (isRescheduled || isCancelled) { + const application = await db.Application.findByPk(interview.applicationId); + if (application) { + const scheduledAtIso = interview.scheduleDate.toISOString(); + const type = interview.interviewType; + const meetLink = interview.linkOrLocation; + const notificationPromises: Promise[] = []; + + // Notify Applicant + notificationPromises.push( + NotificationService.notify(null, application.email, { + title: isCancelled ? `Interview Cancelled: ${application.applicationId}` : `Interview Rescheduled: ${application.applicationId}`, + message: isCancelled + ? `Dear ${application.applicantName}, your ${type} has been cancelled.` + : `Dear ${application.applicantName}, your ${type} has been rescheduled to ${formatIST(interview.scheduleDate)}.`, + channels: application.mobileNumber ? ['email', 'whatsapp', 'system'] : ['email', 'system'], + templateCode: isCancelled ? 'INTERVIEW_CANCELLED_APPLICANT' : 'INTERVIEW_RESCHEDULED_APPLICANT', + placeholders: { + applicantName: application.applicantName, + applicationId: application.applicationId, + type, + scheduledAt: formatIST(interview.scheduleDate), + meetLink, + appLink: `${process.env.FRONTEND_URL || 'http://localhost:5173'}/onboarding/application/${application.id}`, + phone: application.mobileNumber || '', + ctaLabel: 'View Schedule' + } + }).catch(err => console.error('Failed to notify applicant of reschedule/cancellation:', err)) + ); + + // Notify Panelists + const participants = (interview as any).participants || []; + for (const p of participants) { + const panelist = p.user; + if (panelist?.email) { + notificationPromises.push( + NotificationService.notify(panelist.id, panelist.email, { + title: isCancelled ? `Interview Cancelled: ${application.applicationId}` : `Interview Rescheduled: ${application.applicationId}`, + message: isCancelled + ? `The ${type} for ${application.applicantName} has been cancelled.` + : `The ${type} for ${application.applicantName} has been rescheduled to ${formatIST(interview.scheduleDate)}.`, + channels: panelist.mobileNumber ? ['email', 'system', 'whatsapp'] : ['email', 'system'], + templateCode: isCancelled ? 'INTERVIEW_CANCELLED_PANELIST' : 'INTERVIEW_RESCHEDULED_PANELIST', + placeholders: { + panelistName: panelist.fullName, + applicantName: application.applicantName, + applicationId: application.applicationId, + type, + scheduledAt: formatIST(interview.scheduleDate), + meetLink, + appLink: `${process.env.FRONTEND_URL || 'http://localhost:5173'}/onboarding/application/${application.id}`, + phone: panelist.mobileNumber || '', + ctaLabel: 'Open Assessment' + } + }).catch(err => console.error(`Failed to notify panelist (${panelist.id}) of reschedule/cancellation:`, err)) + ); + } + } + await Promise.all(notificationPromises); + } + } await db.AuditLog.create({ userId: req.user?.id || null, action: AUDIT_ACTIONS.INTERVIEW_UPDATED, diff --git a/src/modules/audit/audit.controller.ts b/src/modules/audit/audit.controller.ts index 8b827ba..a79ea88 100644 --- a/src/modules/audit/audit.controller.ts +++ b/src/modules/audit/audit.controller.ts @@ -208,9 +208,11 @@ const getNormalizedAuditPayload = (logData: any, entityType: string, entityId: s (payload?.context as any)?.currentStage || null, actor: { + id: logData.userId || logData.actorId || logData.user?.id || null, name: actorName, email: logData.user?.email || logData.userEmail || null }, + actorId: logData.userId || logData.actorId || logData.user?.id || null, userName: actorName, userEmail: logData.user?.email || logData.userEmail || null, remarks: logData.remarks || payload?.remarks || '', diff --git a/src/modules/eor/eor.controller.ts b/src/modules/eor/eor.controller.ts index 3bee83f..c2b576f 100644 --- a/src/modules/eor/eor.controller.ts +++ b/src/modules/eor/eor.controller.ts @@ -3,6 +3,8 @@ import { Op } from 'sequelize'; import db from '../../database/models/index.js'; const { EorChecklist, EorChecklistItem, OnboardingDocument, RelocationDocument } = db; import { AuthRequest } from '../../types/express.types.js'; +import { NotificationService } from '../../services/NotificationService.js'; +import { ROLES } from '../../common/config/constants.js'; /** Default EOR rows for relocation (SRS 12.2.8) — must stay aligned with relocation required-doc labels. */ export const RELOCATION_EOR_DEFAULT_ITEMS = [ @@ -338,6 +340,27 @@ export const submitAudit = async (req: AuthRequest, res: Response) => { const { updateApplicationProgress } = await import('../../common/utils/progress.js'); await updateApplicationProgress(checklist.applicationId, 'EOR Complete', 'completed', 100); await updateApplicationProgress(checklist.applicationId, 'Inauguration', 'active', 50); + + // SRS §6.19.3.4 — Readiness alert to DD-Head and NBH on EOR 100% completion + const app = await db.Application.findByPk(checklist.applicationId); + const eorAlertRoles = [ROLES.DD_HEAD, ROLES.NBH, ROLES.DD_ADMIN]; + for (const role of eorAlertRoles) { + const roleUsers = await db.User.findAll({ where: { roleCode: role } }); + for (const u of roleUsers) { + NotificationService.notify(u.id, u.email, { + title: `EOR Completed: ${app?.applicationId || checklist.applicationId}`, + message: `EOR checklist is 100% complete for ${app?.applicantName || 'the applicant'}. Dealership is ready for inauguration.`, + channels: ['system', 'email'], + templateCode: 'EOR_COMPLETED', + placeholders: { + applicantName: app?.applicantName || '', + applicationId: app?.applicationId || '', + link: `${process.env.FRONTEND_URL || 'http://localhost:5173'}/applications/${checklist.applicationId}`, + ctaLabel: 'View Application' + } + }).catch((e: any) => console.error('[EOR] Completion notify failed:', e)); + } + } } else if (checklist.relocationId) { await db.RelocationRequest.update({ status: 'Completed', @@ -345,7 +368,22 @@ export const submitAudit = async (req: AuthRequest, res: Response) => { currentStage: 'Completed' }, { where: { id: checklist.relocationId } }); - // The workflow service can handle timeline/audit but here we just finalized the status + // SRS §6.19.3.4 — Relocation EOR complete — notify DD-Admin + const adminUsers = await db.User.findAll({ where: { roleCode: ROLES.DD_ADMIN } }); + for (const u of adminUsers) { + NotificationService.notify(u.id, u.email, { + title: `Relocation EOR Completed`, + message: `The EOR checklist for relocation ${checklist.relocationId} has been fully verified.`, + channels: ['system', 'email'], + templateCode: 'EOR_COMPLETED', + placeholders: { + applicantName: '', + applicationId: checklist.relocationId, + link: `${process.env.FRONTEND_URL || 'http://localhost:5173'}/relocation-requests/${checklist.relocationId}`, + ctaLabel: 'View Request' + } + }).catch((e: any) => console.error('[EOR] Relocation notify failed:', e)); + } } } } diff --git a/src/modules/fdd/fdd.controller.ts b/src/modules/fdd/fdd.controller.ts index 0c84fba..c5cba6c 100644 --- a/src/modules/fdd/fdd.controller.ts +++ b/src/modules/fdd/fdd.controller.ts @@ -3,9 +3,10 @@ import { Op } from 'sequelize'; import db from '../../database/models/index.js'; const { FddAssignment, FddReport, Application } = db; import { AuthRequest } from '../../types/express.types.js'; -import { AUDIT_ACTIONS, APPLICATION_STATUS, APPLICATION_STAGES } from '../../common/config/constants.js'; +import { AUDIT_ACTIONS, APPLICATION_STATUS, APPLICATION_STAGES, ROLES } from '../../common/config/constants.js'; import { WorkflowService } from '../../services/WorkflowService.js'; import { pickApplicationAuditContext, safeAuditLogCreate } from '../../services/applicationAuditLog.service.js'; +import { NotificationService } from '../../services/NotificationService.js'; export const getAssignment = async (req: Request, res: Response) => { try { @@ -88,6 +89,25 @@ export const assignAgency = async (req: AuthRequest, res: Response) => { }, }); + // SRS §6.15.3.1 — Notify assigned FDD agency user of their assignment + const fddUser = await db.User.findByPk(assignedToAgency); + if (fddUser) { + const phone = (fddUser as any).mobileNumber || null; + NotificationService.notify(fddUser.id, fddUser.email, { + title: `FDD Assignment: ${application.applicationId}`, + message: `You have been assigned to conduct Financial Due Diligence for application ${application.applicationId}.`, + channels: phone ? ['system', 'email', 'whatsapp'] : ['system', 'email'], + templateCode: 'USER_ASSIGNED', + placeholders: { + applicantName: application.applicantName || '', + applicationId: application.applicationId, + link: `${process.env.FRONTEND_URL || 'http://localhost:5173'}/applications/${application.id}`, + ctaLabel: 'View Assignment', + phone: phone || '' + } + }).catch((e: any) => console.error('[FDD] Agency notify failed:', e)); + } + res.status(201).json({ success: true, message: 'FDD Agency assigned', data: assignment }); } catch (error) { console.error('Assign FDD agency error:', error); @@ -158,6 +178,27 @@ export const uploadReport = async (req: AuthRequest, res: Response) => { reason: 'FDD Report uploaded. Pending review to proceed to LOI stage.', forceLog: true // Log even if status is same }); + + // SRS §6.15.3.1 — Notify Finance + DD-Admin that FDD report is submitted + const fddReportRoles = [ROLES.FINANCE, ROLES.DD_ADMIN]; + for (const role of fddReportRoles) { + const roleUsers = await db.User.findAll({ where: { roleCode: role } }); + for (const u of roleUsers) { + NotificationService.notify(u.id, u.email, { + title: `FDD Report Submitted: ${application.applicationId}`, + message: `The FDD agency has submitted their financial due diligence report for ${application.applicationId}. Review is required before LOI stage.`, + channels: ['system', 'email'], + templateCode: 'WORKFLOW_ACTION_REQUIRED', + placeholders: { + dealerName: application.applicantName || '', + requestId: application.applicationId, + targetStage: 'FDD Review', + link: `${process.env.FRONTEND_URL || 'http://localhost:5173'}/applications/${application.id}`, + phone: '' + } + }).catch((e: any) => console.error('[FDD] Finance/Admin notify failed:', e)); + } + } } } diff --git a/src/modules/loa/loa.controller.ts b/src/modules/loa/loa.controller.ts index 7c3ccfb..a074b5a 100644 --- a/src/modules/loa/loa.controller.ts +++ b/src/modules/loa/loa.controller.ts @@ -2,8 +2,9 @@ import { Request, Response } from 'express'; import db from '../../database/models/index.js'; const { LoaRequest, LoaApproval, LoaDocumentGenerated, SecurityDeposit, AuditLog, StageApprovalPolicy, StageApprovalAction, User } = db; import { AuthRequest } from '../../types/express.types.js'; -import { AUDIT_ACTIONS, APPLICATION_STATUS, APPLICATION_STAGES } from '../../common/config/constants.js'; +import { AUDIT_ACTIONS, APPLICATION_STATUS, APPLICATION_STAGES, ROLES } from '../../common/config/constants.js'; import { WorkflowService } from '../../services/WorkflowService.js'; +import { NotificationService } from '../../services/NotificationService.js'; const LOA_STAGE_CODE = 'LOA_APPROVAL'; @@ -86,6 +87,25 @@ export const createRequest = async (req: AuthRequest, res: Response) => { progressPercentage: 92 }); + // SRS §6.18.3.1 — Notify DD-Head that LOA needs their approval + const ddHeadUsers = await User.findAll({ where: { roleCode: ROLES.DD_HEAD } }); + for (const ddHead of ddHeadUsers) { + const phone = (ddHead as any).mobileNumber || null; + NotificationService.notify(ddHead.id, ddHead.email, { + title: `Action Required: LOA Approval for ${application.applicationId}`, + message: `LOA request has been initiated for ${application.applicationId}. Your approval is required.`, + channels: phone ? ['system', 'email', 'whatsapp'] : ['system', 'email'], + templateCode: 'WORKFLOW_ACTION_REQUIRED', + placeholders: { + dealerName: application.applicantName || application.applicationId, + requestId: application.applicationId, + targetStage: 'LOA Approval', + link: `${process.env.FRONTEND_URL || 'http://localhost:5173'}/applications/${application.id}`, + phone: phone || '' + } + }).catch((e: any) => console.error('[LOA] DD-Head notify failed:', e)); + } + res.status(201).json({ success: true, message: 'LOA Request initiated with DD Head approval', data: request }); } catch (error) { console.error('Create LOA request error:', error); @@ -207,6 +227,28 @@ export const approveRequest = async (req: AuthRequest, res: Response) => { progressPercentage: 97 }); } + + // SRS §6.18.3.1 — LOA issued: notify all relevant teams (System + Email) + const app = await db.Application.findByPk(request.applicationId); + const loaTeamRoles = [ROLES.DD_ADMIN, ROLES.FINANCE, ROLES.LEGAL_ADMIN, ROLES.DD_HEAD, ROLES.NBH]; + for (const role of loaTeamRoles) { + const roleUsers = await User.findAll({ where: { roleCode: role } }); + for (const u of roleUsers) { + NotificationService.notify(u.id, u.email, { + title: `LOA Issued: ${app?.applicationId || request.applicationId}`, + message: `Letter of Appointment fully approved and issued for ${app?.applicantName || 'the applicant'}. EOR process may now begin.`, + channels: ['system', 'email'], + templateCode: 'LOA_ISSUED', + placeholders: { + applicantName: app?.applicantName || '', + applicationId: app?.applicationId || '', + link: `${process.env.FRONTEND_URL || 'http://localhost:5173'}/applications/${request.applicationId}`, + ctaLabel: 'View Application' + } + }).catch((e: any) => console.error('[LOA] team notify failed:', e)); + } + } + res.json({ success: true, message: 'LOA fully approved and issued' }); } else { // SEQUENTIAL APPROVAL BRIDGE: @@ -225,6 +267,27 @@ export const approveRequest = async (req: AuthRequest, res: Response) => { } }); console.log(`[LOA] Generated sequential approval record for Level ${nextLevel}: ${nextRole}`); + + // SRS §6.18.3.1 — Sequential: DD-Head approved → notify NBH + if (req.user.roleCode === ROLES.DD_HEAD) { + const nbhUsers = await User.findAll({ where: { roleCode: ROLES.NBH } }); + for (const nbh of nbhUsers) { + const phone = (nbh as any).mobileNumber || null; + NotificationService.notify(nbh.id, nbh.email, { + title: `Action Required: LOA Final Approval`, + message: `DD Head has approved LOA request ${requestId}. Your final sign-off is required.`, + channels: phone ? ['system', 'email', 'whatsapp'] : ['system', 'email'], + templateCode: 'WORKFLOW_ACTION_REQUIRED', + placeholders: { + dealerName: '', + requestId, + targetStage: 'NBH LOA Approval', + link: `${process.env.FRONTEND_URL || 'http://localhost:5173'}/applications/${request.applicationId}`, + phone: phone || '' + } + }).catch((e: any) => console.error('[LOA] NBH notify failed:', e)); + } + } } res.json({ diff --git a/src/modules/loi/loi.controller.ts b/src/modules/loi/loi.controller.ts index bdcb181..541e5c0 100644 --- a/src/modules/loi/loi.controller.ts +++ b/src/modules/loi/loi.controller.ts @@ -2,8 +2,10 @@ import { Request, Response } from 'express'; import db from '../../database/models/index.js'; const { LoiRequest, LoiApproval, LoiDocumentGenerated, LoiAcknowledgement, AuditLog, StageApprovalPolicy, StageApprovalAction, User } = db; import { AuthRequest } from '../../types/express.types.js'; -import { AUDIT_ACTIONS, APPLICATION_STATUS } from '../../common/config/constants.js'; +import { AUDIT_ACTIONS, APPLICATION_STATUS, ROLES } from '../../common/config/constants.js'; import { WorkflowService } from '../../services/WorkflowService.js'; +import { NotificationService } from '../../services/NotificationService.js'; +import { sendEmail } from '../../common/utils/email.service.js'; const LOI_STAGE_CODE = 'LOI_APPROVAL'; @@ -125,6 +127,25 @@ export const createRequest = async (req: AuthRequest, res: Response) => { progressPercentage: 75 }); + // SRS §6.16.3.5 — Notify DD-Head that LOI needs their approval (System + Email + WhatsApp) + const ddHeadUsers = await User.findAll({ where: { roleCode: ROLES.DD_HEAD } }); + for (const ddHead of ddHeadUsers) { + const phone = (ddHead as any).mobileNumber || null; + NotificationService.notify(ddHead.id, ddHead.email, { + title: `Action Required: LOI Approval for ${application.applicationId}`, + message: `LOI request initiated for application ${application.applicationId}. Your approval is required.`, + channels: phone ? ['system', 'email', 'whatsapp'] : ['system', 'email'], + templateCode: 'WORKFLOW_ACTION_REQUIRED', + placeholders: { + dealerName: application.applicantName || application.applicationId, + requestId: application.applicationId, + targetStage: 'LOI Approval', + link: `${process.env.FRONTEND_URL || 'http://localhost:5173'}/applications/${application.id}`, + phone: phone || '' + } + }).catch((e: any) => console.error('[LOI] DD-Head notify failed:', e)); + } + res.status(201).json({ success: true, message: 'LOI Request initiated for DD Head approval', data: request }); } catch (error) { console.error('Create LOI request error:', error); @@ -259,8 +280,48 @@ export const approveRequest = async (req: AuthRequest, res: Response) => { }); } + // SRS §6.16.3.5 — Notify Finance + DD-Admin that LOI is fully approved + const notifyRoles = [ROLES.FINANCE, ROLES.DD_ADMIN]; + const application2 = await db.Application.findByPk(request.applicationId); + for (const role of notifyRoles) { + const roleUsers = await User.findAll({ where: { roleCode: role } }); + for (const u of roleUsers) { + NotificationService.notify(u.id, u.email, { + title: `LOI Fully Approved: ${application2?.applicationId || request.applicationId}`, + message: `LOI request has been approved by all required stakeholders and is ready to issue.`, + channels: ['system', 'email'], + templateCode: 'ONBOARDING_STATUS_UPDATE', + placeholders: { + dealerName: application2?.applicantName || '', + requestId: application2?.applicationId || '', + link: `${process.env.FRONTEND_URL || 'http://localhost:5173'}/applications/${request.applicationId}`, + ctaLabel: 'View Application' + } + }).catch((e: any) => console.error('[LOI] finance/admin notify failed:', e)); + } + } res.json({ success: true, message: 'LOI Request fully approved and document generated' }); } else { + // SRS §6.16.3.5 — Sequential: DD-Head approved → now notify NBH + if (action === 'Approved' && req.user.roleCode === ROLES.DD_HEAD) { + const nbhUsers = await User.findAll({ where: { roleCode: ROLES.NBH } }); + for (const nbh of nbhUsers) { + const phone = (nbh as any).mobileNumber || null; + NotificationService.notify(nbh.id, nbh.email, { + title: `Action Required: LOI Final Approval`, + message: `DD Head has approved the LOI for ${request.applicationId}. Your final sign-off is required.`, + channels: phone ? ['system', 'email', 'whatsapp'] : ['system', 'email'], + templateCode: 'WORKFLOW_ACTION_REQUIRED', + placeholders: { + dealerName: '', + requestId: String(request.applicationId), + targetStage: 'NBH LOI Approval', + link: `${process.env.FRONTEND_URL || 'http://localhost:5173'}/applications/${request.applicationId}`, + phone: phone || '' + } + }).catch((e: any) => console.error('[LOI] NBH notify failed:', e)); + } + } res.json({ success: true, message: 'Approval recorded. Waiting for remaining required approvers.', @@ -359,6 +420,41 @@ export const generateDocument = async (req: AuthRequest, res: Response) => { reason: 'LOI Document issued. Proceeding to Dealer Code Generation.', progressPercentage: 85 }); + + // SRS §6.16.3.6 — LOI issued: email ONLY to applicant (explicitly NO WhatsApp per SRS) + if (application.email) { + sendEmail( + application.email, + `Letter of Intent Issued: ${application.applicationId}`, + 'LOI_ISSUED', + { + applicantName: application.applicantName || 'Applicant', + applicationId: application.applicationId, + link: `${process.env.FRONTEND_URL || 'http://localhost:5173'}/prospect-login`, + ctaLabel: 'View Your Application' + } + ).catch((e: any) => console.error('[LOI] Applicant email failed:', e)); + } + + // SRS §6.16.3.6 — Alert Finance, DD-Head, NBH confirming LOI issuance (System + Email) + const stakeholderRoles = [ROLES.FINANCE, ROLES.DD_HEAD, ROLES.NBH]; + for (const role of stakeholderRoles) { + const roleUsers = await User.findAll({ where: { roleCode: role } }); + for (const u of roleUsers) { + NotificationService.notify(u.id, u.email, { + title: `LOI Issued: ${application.applicationId}`, + message: `Letter of Intent has been issued for ${application.applicantName || application.applicationId}. Dealer code generation is now pending.`, + channels: ['system', 'email'], + templateCode: 'LOI_ISSUED', + placeholders: { + applicantName: application.applicantName || '', + applicationId: application.applicationId, + link: `${process.env.FRONTEND_URL || 'http://localhost:5173'}/applications/${application.id}`, + ctaLabel: 'View Application' + } + }).catch((e: any) => console.error('[LOI] stakeholder notify failed:', e)); + } + } } } diff --git a/src/modules/onboarding/onboarding.controller.ts b/src/modules/onboarding/onboarding.controller.ts index b6ff165..aaf12fb 100644 --- a/src/modules/onboarding/onboarding.controller.ts +++ b/src/modules/onboarding/onboarding.controller.ts @@ -13,6 +13,7 @@ import { WorkflowIntegrityService } from '../../services/WorkflowIntegrityServic import { NomenclatureService } from '../../common/utils/nomenclature.js'; import { pickApplicationAuditContext, safeAuditLogCreate } from '../../services/applicationAuditLog.service.js'; import { isAutoAssignmentEnabled } from '../../services/AutoAssignmentConfigService.js'; +import { NotificationService } from '../../services/NotificationService.js'; const { DocumentStageConfig } = db; @@ -195,6 +196,27 @@ export const submitApplication = async (req: AuthRequest, res: Response) => { entityId: application.id }); + // SRS §6.1.3 — WhatsApp acknowledgement to applicant on submission (alongside email) + // The email is handled above; now send WhatsApp if phone is available + if (phone) { + NotificationService.notify(null, email, { + title: isOpportunityAvailable + ? `Your Royal Enfield Dealership Application: ${applicationId}` + : `We received your interest: ${applicationId}`, + message: isOpportunityAvailable + ? `Hi ${displayApplicantName}, your application for ${displayLocation} has been received. We will contact you soon.` + : `Hi ${displayApplicantName}, we have noted your interest for ${displayLocation}. We'll reach out when an opportunity arises.`, + channels: ['whatsapp'], + templateCode: isOpportunityAvailable ? 'OPPORTUNITY' : 'NON_OPPORTUNITY', + placeholders: { + applicantName: displayApplicantName, + location: displayLocation, + applicationId, + phone + } + }).catch((err: any) => console.error('[Onboarding] WhatsApp ack failed:', err)); + } + res.status(201).json({ success: true, message: 'Application submitted successfully', diff --git a/src/modules/self-service/resignation.controller.ts b/src/modules/self-service/resignation.controller.ts index 77bc20c..dd7d0d2 100644 --- a/src/modules/self-service/resignation.controller.ts +++ b/src/modules/self-service/resignation.controller.ts @@ -1,4 +1,4 @@ -import { Response, NextFunction } from 'express'; +import { Response, NextFunction } from 'express'; // Triggering reload to pick up constants changes import db from '../../database/models/index.js'; import logger from '../../common/utils/logger.js'; import { @@ -17,7 +17,7 @@ import ExternalMocksService from '../../common/utils/externalMocks.service.js'; import { ResignationWorkflowService } from '../../services/ResignationWorkflowService.js'; import { NomenclatureService } from '../../common/utils/nomenclature.js'; import { ParticipantService } from '../../services/ParticipantService.js'; -import { notifyResignationSubmittedEmails } from '../../common/utils/workflow-email-notifications.js'; +import { notifyResignationSubmittedEmails, notifyStakeholdersOnTransition } from '../../common/utils/workflow-email-notifications.js'; import { getResignationStatusForStage, normalizeClearanceStatus } from '../../common/utils/offboardingStatus.js'; import { resolveEntityUuidByType } from '../../common/utils/requestResolver.js'; import { OFFBOARDING_ACTIONS } from '../../common/config/constants.js'; @@ -113,13 +113,13 @@ export const getResignations = async (req: AuthRequest, res: Response, next: Nex try { if (!req.user) throw new Error('Unauthorized'); const where: any = {}; - + if (req.user.roleCode === ROLES.DEALER) { where.dealerId = req.user.id; } else { // For administrative users, filter by status or assignment if requested const { status, onlyMine } = req.query; - + if (status) { if (String(status).includes(',')) { where.status = { [Op.in]: String(status).split(',') }; @@ -133,7 +133,7 @@ export const getResignations = async (req: AuthRequest, res: Response, next: Nex if (onlyMine === 'true') { // This would involve a subquery on RequestParticipants or assignedTo field // Assuming currentStage context or RequestParticipants - where.currentStage = { [Op.like]: `%${req.user.roleCode}%` }; + where.currentStage = { [Op.like]: `%${req.user.roleCode}%` }; } } @@ -145,9 +145,9 @@ export const getResignations = async (req: AuthRequest, res: Response, next: Nex where, include: [ { model: db.Outlet, as: 'outlet' }, - { - model: db.User, - as: 'dealer', + { + model: db.User, + as: 'dealer', attributes: ['fullName'], include: [ { model: db.Dealer, as: 'dealerProfile', include: [{ model: db.DealerCode, as: 'dealerCode' }] } @@ -159,8 +159,8 @@ export const getResignations = async (req: AuthRequest, res: Response, next: Nex offset, distinct: true }); - res.json({ - success: true, + res.json({ + success: true, resignations, meta: { total: count, @@ -190,9 +190,9 @@ export const getResignationById = async (req: AuthRequest, res: Response, next: where: { id: resolvedId }, include: [ { model: db.Outlet, as: 'outlet' }, - { - model: db.User, - as: 'dealer', + { + model: db.User, + as: 'dealer', attributes: ['id', 'fullName', 'email', 'roleCode'], include: [ { @@ -213,21 +213,21 @@ export const getResignationById = async (req: AuthRequest, res: Response, next: } ] }, - { - model: db.ResignationDocument, + { + model: db.ResignationDocument, as: 'uploadedDocuments', include: [{ model: db.User, as: 'uploader', attributes: ['fullName'] }] }, - { - model: db.FnF, + { + model: db.FnF, as: 'settlement', include: [ { model: db.FnFLineItem, as: 'lineItems' }, { model: db.FffClearance, as: 'clearances' } ] }, - { - model: db.RequestParticipant, + { + model: db.RequestParticipant, as: 'participants', include: [{ model: db.User, as: 'user', attributes: ['id', 'fullName', 'email', 'roleCode'] }] } @@ -309,6 +309,30 @@ export const uploadResignationDocument = async (req: AuthRequest, res: Response, await resignation.update({ timeline }, { transaction }); await transaction.commit(); + + // SRS §7.5.2 — When Legal uploads the acceptance letter, notify DD-Admin and ASM + // so they can communicate official closure to the dealer (field hierarchy). + if (stage === RESIGNATION_STAGES.LEGAL && resignation.currentStage === RESIGNATION_STAGES.LEGAL) { + const portalBase = process.env.FRONTEND_URL || 'http://localhost:5173'; + const resignationCode = resignation.resignationId || resignation.id; + setImmediate(() => + notifyStakeholdersOnTransition( + resignation.id, + REQUEST_TYPES.RESIGNATION, + 'Resignation Legal Closure', // synthetic stage key mapped to DD_ADMIN + ASM in resolveNextActors + { + code: resignationCode, + dealerName: 'Dealer', // enriched below if needed + dealerId: resignation.dealerId, + actionUserFullName: req.user!.fullName || 'Legal Team', + action: 'Legal acceptance letter uploaded — ready for DD-Admin review and ASM communication', + remarks: `Document: ${req.file!.originalname}`, + link: `${portalBase}/dealer-resignation/${resignation.id}` + } + ).catch((err: any) => logger.error('[uploadResignationDocument] legal-closure notify:', err)) + ); + } + res.status(201).json({ success: true, message: 'Document uploaded successfully', document }); } catch (error) { await transaction.rollback(); @@ -354,11 +378,9 @@ export const approveResignation = async (req: AuthRequest, res: Response, next: [RESIGNATION_STAGES.RBM]: RESIGNATION_STAGES.ZBH, [RESIGNATION_STAGES.ZBH]: RESIGNATION_STAGES.DD_LEAD, [RESIGNATION_STAGES.DD_LEAD]: RESIGNATION_STAGES.NBH, - [RESIGNATION_STAGES.NBH]: RESIGNATION_STAGES.DD_ADMIN, - [RESIGNATION_STAGES.DD_ADMIN]: RESIGNATION_STAGES.LEGAL, - // Legal approval should complete only the Legal stage. - // F&F initiation is explicitly triggered via `pushfnf` action (with LWD/force gates). - [RESIGNATION_STAGES.LEGAL]: RESIGNATION_STAGES.LEGAL, + [RESIGNATION_STAGES.NBH]: RESIGNATION_STAGES.LEGAL, + [RESIGNATION_STAGES.LEGAL]: RESIGNATION_STAGES.DD_ADMIN, + [RESIGNATION_STAGES.DD_ADMIN]: RESIGNATION_STAGES.FNF_INITIATED, // DD Admin approval moves to F&F initiation [RESIGNATION_STAGES.FNF_INITIATED]: RESIGNATION_STAGES.COMPLETED }; @@ -504,7 +526,7 @@ export const approveResignation = async (req: AuthRequest, res: Response, next: })), { transaction } ); - + fnfId = fnf.id; } @@ -587,18 +609,18 @@ export const withdrawResignation = async (req: AuthRequest, res: Response, next: } const restrictedStages = [ - RESIGNATION_STAGES.NBH, - RESIGNATION_STAGES.DD_ADMIN, - RESIGNATION_STAGES.LEGAL, - RESIGNATION_STAGES.FNF_INITIATED, + RESIGNATION_STAGES.NBH, + RESIGNATION_STAGES.DD_ADMIN, + RESIGNATION_STAGES.LEGAL, + RESIGNATION_STAGES.FNF_INITIATED, RESIGNATION_STAGES.COMPLETED ]; - + if (restrictedStages.includes(resignation.currentStage as any)) { await transaction.rollback(); - return res.status(400).json({ - success: false, - message: `Withdrawal not allowed after NBH evaluation stage. Current stage: ${resignation.currentStage}` + return res.status(400).json({ + success: false, + message: `Withdrawal not allowed after NBH evaluation stage. Current stage: ${resignation.currentStage}` }); } @@ -727,7 +749,7 @@ export const assignResignation = async (req: AuthRequest, res: Response, next: N // If assignTo is a UUID, it's a direct user assignment const isUUID = /^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$/.test(assignTo); - + if (isUUID) { targetUserId = assignTo; } else { @@ -753,7 +775,7 @@ export const assignResignation = async (req: AuthRequest, res: Response, next: N else if (assignTo === 'zbh') targetUserId = d.zone?.zbhId; } } - + // Fallback for national roles if (!targetUserId) { const roleIdMap: Record = { @@ -771,9 +793,9 @@ export const assignResignation = async (req: AuthRequest, res: Response, next: N } if (!targetUserId) { - return res.status(400).json({ - success: false, - message: `Could not resolve a unique user for assignment: ${assignTo}. Please ensure the underlying master data (District/Region/Zone) is correctly mapped.` + return res.status(400).json({ + success: false, + message: `Could not resolve a unique user for assignment: ${assignTo}. Please ensure the underlying master data (District/Region/Zone) is correctly mapped.` }); } @@ -820,23 +842,23 @@ export const updateClearance = async (req: AuthRequest, res: Response, next: Nex clearanceType === 'payable' ? 'Payable' : clearanceType === 'deduction' - ? 'Deduction' - : clearanceType === 'recovery' || clearanceType === 'receivable' - ? 'Receivable' - : type === 'Payable' || type === 'Deduction' - ? type - : type === 'Recovery' + ? 'Deduction' + : clearanceType === 'recovery' || clearanceType === 'receivable' ? 'Receivable' - : type === 'Receivable' - ? 'Receivable' - : 'Receivable'; + : type === 'Payable' || type === 'Deduction' + ? type + : type === 'Recovery' + ? 'Receivable' + : type === 'Receivable' + ? 'Receivable' + : 'Receivable'; const clearanceStoredType: 'Payable' | 'Receivable' | 'Deduction' = resolvedItemType === 'Payable' ? 'Payable' : resolvedItemType === 'Deduction' - ? 'Deduction' - : 'Receivable'; + ? 'Deduction' + : 'Receivable'; const resolvedId = await resolveResignationUuid(String(id)); const resignation = await db.Resignation.findOne({ @@ -852,17 +874,17 @@ export const updateClearance = async (req: AuthRequest, res: Response, next: Nex const normalizedDeptStatus = normalizeClearanceStatus(status, normalizedAmount); const documentUrl = req.file ? `/uploads/documents/${req.file.filename}` : (currentClearances[department]?.supportingDocument || null); - const clearances = { - ...currentClearances, - [department]: { - status: normalizedDeptStatus, - remarks, - amount: normalizedAmount, + const clearances = { + ...currentClearances, + [department]: { + status: normalizedDeptStatus, + remarks, + amount: normalizedAmount, type: clearanceStoredType, supportingDocument: documentUrl, updatedAt: new Date().toISOString(), updatedBy: req.user.fullName - } + } }; await resignation.update({ @@ -890,7 +912,7 @@ export const updateClearance = async (req: AuthRequest, res: Response, next: Nex if (fnf) { const numAmount = normalizedAmount; const fnfStatus = normalizeClearanceStatus(status, numAmount); - + const existingClearance = await db.FffClearance.findOne({ where: { fnfId: fnf.id, department }, transaction @@ -970,14 +992,14 @@ export const updateClearance = async (req: AuthRequest, res: Response, next: Nex let totalPayables = 0; let totalReceivables = 0; let totalDeductions = 0; - + calculationItems.forEach((item: any) => { const val = Math.abs(parseFloat(item.amount) || 0); if (item.itemType === 'Payable') totalPayables += val; else if (item.itemType === 'Receivable' || item.itemType === 'Recovery') totalReceivables += val; else if (item.itemType === 'Deduction') totalDeductions += val; }); - + await fnf.update({ totalPayables, totalReceivables, @@ -998,10 +1020,10 @@ export const updateClearance = async (req: AuthRequest, res: Response, next: Nex export const updateResignationStatus = async (req: AuthRequest, res: Response, next: NextFunction) => { try { const { action } = req.body; - + // Normalize to lowercase alphanumeric for robust comparison (handles "Send Back", "sendBack", "send-back") const actionNode = String(action || '').toLowerCase().trim().replace(/[^a-z0-9]/g, ''); - + switch (actionNode) { case 'approve': return approveResignation(req, res, next); @@ -1057,9 +1079,9 @@ export const updateResignationStatus = async (req: AuthRequest, res: Response, n return assignResignation(req, res, next); default: - return res.status(400).json({ - success: false, - message: `Invalid or unsupported resignation action: ${action}` + return res.status(400).json({ + success: false, + message: `Invalid or unsupported resignation action: ${action}` }); } } catch (error) { diff --git a/src/modules/settlement/settlement.controller.ts b/src/modules/settlement/settlement.controller.ts index 50f35b5..b3655fe 100644 --- a/src/modules/settlement/settlement.controller.ts +++ b/src/modules/settlement/settlement.controller.ts @@ -10,6 +10,9 @@ import { safeAuditLogCreate } from '../../services/applicationAuditLog.service.j import { writeWorkflowActivityWorknote } from '../../common/utils/workflowWorknote.js'; import { resolveEntityUuidByType } from '../../common/utils/requestResolver.js'; import { NomenclatureService } from '../../common/utils/nomenclature.js'; +import { NotificationService } from '../../services/NotificationService.js'; + +const portalBase = process.env.FRONTEND_URL || 'http://localhost:5173'; const LINE_ITEM_DESCRIPTION_PREFIX = { DEPARTMENT_CLAIM: '[DEPARTMENT_CLAIM]', @@ -202,6 +205,31 @@ export const updatePayment = async (req: AuthRequest, res: Response) => { }, }); + // SRS §11.1.3.1 — Notify DD-Admin and DD-Lead when payment is verified + if (isVerifying && status === 'Paid') { + const notifyRoles = [ROLES.DD_ADMIN, ROLES.DD_LEAD]; + + + for (const role of notifyRoles) { + const roleUsers = await User.findAll({ where: { roleCode: role } }); + for (const u of roleUsers) { + NotificationService.notify(u.id, u.email, { + title: `Payment Verified: ${p.application?.applicationId || 'New Dealer'}`, + message: `Finance has verified the ${p.paymentType || 'Security Deposit'} for ${p.application?.applicantName || 'Dealer'}.`, + channels: ['system', 'email'], + templateCode: 'ONBOARDING_PAYMENT_VERIFIED', + placeholders: { + applicationId: p.application?.applicationId || 'N/A', + dealerName: p.application?.applicantName || 'Dealer', + paymentType: p.paymentType || 'Security Deposit', + amount: p.amount, + link: `${portalBase}/applications/${p.applicationId}` + } + }).catch((e: any) => console.error('[Finance] Payment verification notify failed:', e)); + } + } + } + res.json({ success: true, message: 'Payment updated successfully', data: updatedPayment }); } catch (error) { console.error('Update payment error:', error); @@ -258,6 +286,48 @@ export const updateFnF = async (req: AuthRequest, res: Response) => { }); } } + + // SRS §4.4.2.7 — F&F Completed: final alerts to DD-Lead, NBH, Legal + const completionRoles = [ROLES.DD_LEAD, ROLES.NBH, ROLES.LEGAL_ADMIN, ROLES.DD_ADMIN]; + for (const role of completionRoles) { + const roleUsers = await User.findAll({ where: { roleCode: role } }); + for (const u of roleUsers) { + NotificationService.notify(u.id, u.email, { + title: `F&F Settlement Completed: ${fnf.fnfId || id}`, + message: `Full & Final Settlement has been completed and closed. All departmental clearances confirmed.`, + channels: ['system', 'email'], + templateCode: 'FNF_SETTLEMENT_APPROVED', + placeholders: { + fnfId: fnf.fnfId || id, + dealerName: 'Dealer', // Can be refined if dealer info is fetched + settlementAmount: fnf.settlementAmount || fnf.netAmount, + link: `${portalBase}/fnf/${id}` + } + }).catch((e: any) => console.error('[FnF] Completion notify failed:', e)); + } + } + } + + // SRS §4.4.2.6 — Finance approval reached: notify DD-Admin + Legal + if (normalizedStatus === FNF_STATUS.FINANCE_APPROVAL) { + const financeApprovalRoles = [ROLES.DD_ADMIN, ROLES.LEGAL_ADMIN]; + for (const role of financeApprovalRoles) { + const roleUsers = await User.findAll({ where: { roleCode: role } }); + for (const u of roleUsers) { + NotificationService.notify(u.id, u.email, { + title: `F&F Finance Approval Stage: ${fnf.fnfId || id}`, + message: `All departments have submitted their clearances. F&F is now pending Finance approval.`, + channels: ['system', 'email'], + templateCode: 'FNF_INITIATED', + placeholders: { + dealerName: '', + fnfId: fnf.fnfId || id, + link: `${portalBase}/fnf/${id}`, + ctaLabel: 'Review Settlement' + } + }).catch((e: any) => console.error('[FnF] Finance approval notify failed:', e)); + } + } } res.json({ success: true, message: 'F&F settlement updated successfully', data: fnf }); diff --git a/src/modules/termination/termination.controller.ts b/src/modules/termination/termination.controller.ts index 424a835..012110f 100644 --- a/src/modules/termination/termination.controller.ts +++ b/src/modules/termination/termination.controller.ts @@ -20,6 +20,8 @@ import { getTerminationStatusForStage, normalizeClearanceStatus } from '../../co import { resolveEntityUuidByType } from '../../common/utils/requestResolver.js'; import { OFFBOARDING_ACTIONS, REQUEST_TYPES } from '../../common/config/constants.js'; import { validateOffboardingAction, getPreviousStage } from '../../common/utils/offboardingWorkflow.utils.js'; +import { NotificationService } from '../../services/NotificationService.js'; +import { sendEmail } from '../../common/utils/email.service.js'; const resolveTerminationUuid = async (id: string) => { const { resolvedId } = await resolveEntityUuidByType(db as any, id, 'termination'); @@ -68,6 +70,29 @@ export const createTermination = async (req: AuthRequest, res: Response, next: N ParticipantService.assignTerminationParticipants(termination.id) .catch(err => logger.error('Error assigning participants to termination:', err)); + // SRS §4.3.2.1 — Notify RBM + DD-ZM that a new termination has been initiated + const notifyOnCreateRoles = [ROLES.RBM, ROLES.DD_ZM]; + for (const role of notifyOnCreateRoles) { + const roleUsers = await db.User.findAll({ where: { roleCode: role } }); + for (const u of roleUsers) { + const phone = (u as any).mobileNumber || null; + NotificationService.notify(u.id, u.email, { + title: `New Termination Request: ${termination.requestId}`, + message: `A termination request has been initiated by ${req.user!.fullName || 'Admin'}. Your review is required.`, + channels: phone ? ['system', 'email', 'whatsapp'] : ['system', 'email'], + templateCode: 'TERMINATION_INITIATED', + placeholders: { + dealerName: '', + requestId: termination.requestId, + reason: reason || '', + link: `${process.env.FRONTEND_URL || 'http://localhost:5173'}/termination/${termination.id}`, + ctaLabel: 'Review Request', + phone: phone || '' + } + }).catch((e: any) => logger.error('[Termination] Create notify failed:', e)); + } + } + res.status(201).json({ success: true, message: 'Termination request created', termination }); } catch (error) { if (transaction) await transaction.rollback(); @@ -257,11 +282,11 @@ export const uploadTerminationDocument = async (req: AuthRequest, res: Response, }, { transaction }); const timeline = [...(termination.timeline || []), { - stage: termination.currentStage, + stage: stage || termination.currentStage, timestamp: new Date(), user: req.user.fullName, action: `Document uploaded: ${documentType}`, - remarks: req.file.originalname + remarks: `Attachment: ${req.file.originalname}` }]; await termination.update({ timeline }, { transaction }); @@ -384,18 +409,86 @@ export const updateTerminationStatus = async (req: AuthRequest, res: Response, n [TERMINATION_STAGES.LEGAL_LETTER]: TERMINATION_STAGES.TERMINATED }; - const nextStage = stageFlow[termination.currentStage]; - logger.info(`[TerminationController] transitioning from ${termination.currentStage} to ${nextStage}`); + const sourceStage = termination.currentStage; + const nextStage = stageFlow[sourceStage]; + logger.info(`[TerminationController] attempting transition from ${sourceStage} to ${nextStage}`); + if (!nextStage) { await transaction.rollback(); return res.status(400).json({ success: false, message: 'Cannot approve from current stage' }); } + // SRS §4.3.2.2 — JOINT APPROVAL LOGIC FOR RBM STAGE + if (sourceStage === TERMINATION_STAGES.RBM_REVIEW && req.user.roleCode !== ROLES.SUPER_ADMIN) { + // Prevent duplicate approval from same user + const existingUserApproval = await db.TerminationAudit.findOne({ + where: { + terminationRequestId: termination.id, + userId: req.user.id, + action: 'PARTIAL_APPROVE', + 'details.stage': sourceStage + }, + transaction + }); + + if (existingUserApproval) { + await transaction.rollback(); + return res.status(400).json({ success: false, message: 'You have already recorded your approval for this stage.' }); + } + + // 1. Record this partial approval in Audit Logs + await db.TerminationAudit.create({ + userId: req.user.id, + terminationRequestId: termination.id, + action: 'PARTIAL_APPROVE', + remarks: `Partial approval by ${req.user.roleCode}${remarks ? ': ' + remarks : ''}`, + details: { roleCode: req.user.roleCode, stage: sourceStage } + }, { transaction }); + + + // 2. Check for both RBM and DD_ZM approvals in this stage + const requiredRoles = [ROLES.RBM, ROLES.DD_ZM]; + const partialLogs = await db.TerminationAudit.findAll({ + where: { + terminationRequestId: termination.id, + action: 'PARTIAL_APPROVE', + 'details.stage': sourceStage + }, + transaction + }); + + const approvedRoles = partialLogs.map(log => (log as any).details?.roleCode); + const isComplete = requiredRoles.every(role => approvedRoles.includes(role)); + + if (!isComplete) { + // Record partial approval in timeline ONLY if not complete yet + // (The final approver's entry will be handled by transitionTermination) + const partialTimeline = [...(termination.timeline || []), { + stage: sourceStage, + timestamp: new Date(), + user: req.user.fullName, + action: 'Partial Approved', + remarks: remarks || `Partial approval recorded by ${req.user.roleCode}` + }]; + await termination.update({ timeline: partialTimeline }, { transaction }); + + await transaction.commit(); + return res.json({ + success: true, + message: `Partial approval recorded. Waiting for ${requiredRoles.find(r => !approvedRoles.includes(r))} approval to proceed to ZBH Review.`, + isPartial: true + }); + } + + logger.info(`[TerminationController] Joint approval complete for ${termination.requestId}. Moving to ${nextStage}.`); + } + approvedToStage = nextStage; await TerminationWorkflowService.transitionTermination(termination, nextStage, req.user.id, { - remarks, - status: getTerminationStatusForStage(nextStage) + remarks: remarks || `Jointly approved by RBM & DD-ZM`, + status: getTerminationStatusForStage(nextStage), + transaction }); // If Terminated, trigger F&F initiation via Workflow Service @@ -472,6 +565,45 @@ export const issueScn = async (req: AuthRequest, res: Response, next: NextFuncti status: 'Show Cause Notice', remarks: remarks || 'Show Cause Notice issued' }); + + // SRS §4.3.2.8 — SCN issued: send official email to dealer (no WhatsApp) + const dealer = await db.Dealer.findByPk(termination.dealerId, { + include: [{ model: db.User, as: 'user', attributes: ['email', 'mobileNumber', 'fullName'] }] + }); + const dealerUser = (dealer as any)?.user; + if (dealerUser?.email) { + sendEmail( + dealerUser.email, + `Show Cause Notice: ${termination.requestId}`, + 'TERMINATION_SCN_ISSUED', + { + dealerName: dealerUser.fullName || 'Dealer', + requestId: termination.requestId, + link: `${process.env.FRONTEND_URL || 'http://localhost:5173'}/dealer-termination/${termination.id}`, + ctaLabel: 'View Notice' + } + ).catch((e: any) => logger.error('[Termination] SCN email to dealer failed:', e)); + } + + // Notify DD-Admin + Legal of SCN issuance + const scnAlertRoles = [ROLES.DD_ADMIN, ROLES.LEGAL_ADMIN]; + for (const role of scnAlertRoles) { + const roleUsers = await db.User.findAll({ where: { roleCode: role } }); + for (const u of roleUsers) { + NotificationService.notify(u.id, u.email, { + title: `SCN Issued: ${termination.requestId}`, + message: `Show Cause Notice has been issued for termination case ${termination.requestId}.`, + channels: ['system', 'email'], + templateCode: 'TERMINATION_SCN_ISSUED', + placeholders: { + dealerName: dealerUser?.fullName || '', + requestId: termination.requestId, + link: `${process.env.FRONTEND_URL || 'http://localhost:5173'}/termination/${termination.id}`, + ctaLabel: 'View Case' + } + }).catch((e: any) => logger.error('[Termination] SCN admin/legal notify failed:', e)); + } + } } await transaction.commit(); diff --git a/src/scripts/seed-interview-templates.ts b/src/scripts/seed-interview-templates.ts index 9709735..552e390 100644 --- a/src/scripts/seed-interview-templates.ts +++ b/src/scripts/seed-interview-templates.ts @@ -14,13 +14,16 @@ const seedInterviewTemplates = async () => {

Dear {{applicantName}},

Your {{type}} for Royal Enfield Dealership Application ({{applicationId}}) has been scheduled.

Scheduled Time: {{scheduledAt}}

-

Meeting Link/Location: {{link}}

+

Meeting Link/Location: {{meetLink}}

Please ensure you are available at the scheduled time.

-

Join Interview / View Details

+
+ Join Meeting + View Application +

Best Regards,
Royal Enfield Onboarding Team

`, - placeholders: ['applicantName', 'applicationId', 'type', 'scheduledAt', 'link'] + placeholders: ['applicantName', 'applicationId', 'type', 'scheduledAt', 'meetLink', 'appLink'] }, { templateCode: 'INTERVIEW_SCHEDULED_PANELIST', @@ -32,13 +35,84 @@ const seedInterviewTemplates = async () => {

You have been assigned as a panelist for {{type}} with {{applicantName}}.

Application ID: {{applicationId}}

Scheduled Time: {{scheduledAt}}

-

Meeting Link/Location: {{link}}

-

Open Assessment Dashboard

+

Meeting Link/Location: {{meetLink}}

+
+ Join Meeting + Open Assessment Dashboard +

Please review the applicant's profile before the session.

Regards,
System Administrator

`, - placeholders: ['panelistName', 'applicantName', 'applicationId', 'type', 'scheduledAt', 'link'] + placeholders: ['panelistName', 'applicantName', 'applicationId', 'type', 'scheduledAt', 'meetLink', 'appLink'] + }, + { + templateCode: 'INTERVIEW_RESCHEDULED_APPLICANT', + description: 'Notification sent to the applicant when an interview is rescheduled', + subject: 'Interview Rescheduled: {{applicationId}}', + body: ` + +

Dear {{applicantName}},

+

Your {{type}} for Royal Enfield Dealership Application ({{applicationId}}) has been rescheduled.

+

New Scheduled Time: {{scheduledAt}}

+

Meeting Link/Location: {{meetLink}}

+

Please ensure you are available at the new scheduled time.

+
+ Join Meeting + View Application +
+

Best Regards,
Royal Enfield Onboarding Team

+ + `, + placeholders: ['applicantName', 'applicationId', 'type', 'scheduledAt', 'meetLink', 'appLink'] + }, + { + templateCode: 'INTERVIEW_RESCHEDULED_PANELIST', + description: 'Notification sent to the panelist when an interview is rescheduled', + subject: 'Interview Rescheduled: {{applicationId}}', + body: ` + +

Hi {{panelistName}},

+

The {{type}} for {{applicantName}} ({{applicationId}}) has been rescheduled.

+

New Scheduled Time: {{scheduledAt}}

+

Meeting Link/Location: {{meetLink}}

+
+ Join Meeting + Open Assessment Dashboard +
+

Please update your calendar accordingly.

+

Regards,
System Administrator

+ + `, + placeholders: ['panelistName', 'applicantName', 'applicationId', 'type', 'scheduledAt', 'meetLink', 'appLink'] + }, + { + templateCode: 'INTERVIEW_CANCELLED_APPLICANT', + description: 'Notification sent to the applicant when an interview is cancelled', + subject: 'Interview Cancelled: {{applicationId}}', + body: ` + +

Dear {{applicantName}},

+

We inform you that your {{type}} for Royal Enfield Dealership Application ({{applicationId}}) has been cancelled.

+

Our team will reach out to you if a new session is required.

+

Best Regards,
Royal Enfield Onboarding Team

+ + `, + placeholders: ['applicantName', 'applicationId', 'type'] + }, + { + templateCode: 'INTERVIEW_CANCELLED_PANELIST', + description: 'Notification sent to the panelist when an interview is cancelled', + subject: 'Interview Cancelled: {{applicationId}}', + body: ` + +

Hi {{panelistName}},

+

The {{type}} for {{applicantName}} ({{applicationId}}) has been cancelled.

+

You no longer need to attend this session.

+

Regards,
System Administrator

+ + `, + placeholders: ['panelistName', 'applicantName', 'applicationId', 'type'] }, { templateCode: 'WORKFLOW_ACTION_REQUIRED', diff --git a/src/scripts/seed-master-emails.ts b/src/scripts/seed-master-emails.ts index 097f10d..c1aaeef 100644 --- a/src/scripts/seed-master-emails.ts +++ b/src/scripts/seed-master-emails.ts @@ -87,6 +87,13 @@ const seedTemplates = async () => { fileName: 'onboarding_status_update.html', placeholders: ['applicantName', 'applicationId', 'status', 'reason', 'salesCode', 'serviceCode'] }, + { + templateCode: 'EOR_COMPLETED', + description: 'Notification when EOR readiness is 100% complete', + subject: 'EOR Readiness 100% Completed: {{applicationId}}', + fileName: 'eor_completed.html', + placeholders: ['applicantName', 'applicationId', 'location'] + }, { templateCode: 'RESIGNATION_SUBMITTED', description: 'Notification for new Resignation submission', @@ -101,12 +108,47 @@ const seedTemplates = async () => { fileName: 'resignation_approved.html', placeholders: ['dealerName', 'resignationId', 'lwd'] }, + { + templateCode: 'TERMINATION_INITIATED', + description: 'Notification for new Termination request initiation', + subject: 'Dealer Termination Case Initiated — {{requestId}}', + fileName: 'termination_initiated.html', + placeholders: ['recipientName', 'dealerName', 'requestId', 'category', 'initiatedBy', 'currentStage', 'remarks', 'link', 'ctaLabel'] + }, { templateCode: 'TERMINATION_SCN_ISSUED', description: 'Notification for Show Cause Notice issuance', subject: 'URGENT: Show Cause Notice Issued: {{terminationId}}', fileName: 'termination_scn.html', - placeholders: ['dealerName', 'terminationId', 'deadline'] + placeholders: ['dealerName', 'terminationId', 'deadline', 'link', 'ctaLabel'] + }, + { + templateCode: 'FNF_INITIATED', + description: 'Notification for F&F Settlement initiation', + subject: 'F&F Settlement Initiated — {{requestId}}', + fileName: 'fnf_initiated.html', + placeholders: ['recipientName', 'dealerName', 'requestId', 'initiatedBy', 'lwd', 'link', 'ctaLabel'] + }, + { + templateCode: 'FNF_SUMMARY_PREPARED', + description: 'Notification to Finance team when F&F summary is ready for review', + subject: 'F&F Settlement Summary Prepared: {{fnfId}}', + fileName: 'fnf_summary_prepared.html', + placeholders: ['fnfId', 'dealerName', 'netAmount', 'link', 'ctaLabel'] + }, + { + templateCode: 'FNF_SETTLEMENT_APPROVED', + description: 'Notification when Finance approves the final settlement', + subject: 'F&F Settlement Approved: {{fnfId}}', + fileName: 'fnf_settlement_approved.html', + placeholders: ['fnfId', 'dealerName', 'settlementAmount', 'link', 'ctaLabel'] + }, + { + templateCode: 'ONBOARDING_PAYMENT_VERIFIED', + description: 'Notification when security deposit or initial payment is verified', + subject: 'Payment Verified: {{applicationId}}', + fileName: 'onboarding_payment_verified.html', + placeholders: ['applicationId', 'dealerName', 'paymentType', 'amount', 'link'] }, { templateCode: 'WORKNOTE_NOTIFICATION', @@ -143,6 +185,20 @@ const seedTemplates = async () => { fileName: 'resignation_update.html', placeholders: ['dealerName', 'status', 'remarks'] }, + { + templateCode: 'TERMINATION_LETTER_ISSUED', + description: 'Internal alert to DD-Lead, Admin, and Finance when termination letter is generated', + subject: 'Termination Letter Generated: {{requestId}}', + fileName: 'termination_letter_issued.html', + placeholders: ['recipientName', 'dealerName', 'requestId', 'link', 'ctaLabel'] + }, + { + templateCode: 'TERMINATION_FINAL_CLOSURE_DEALER', + description: 'Final closure notification sent to the dealer upon termination completion', + subject: 'Official Notice: Termination of Dealership — {{requestId}}', + fileName: 'termination_final_closure.html', + placeholders: ['dealerName', 'requestId', 'terminationDate', 'link', 'ctaLabel'] + }, { templateCode: 'TERMINATION_UPDATE', description: 'General status update for Termination', @@ -150,6 +206,20 @@ const seedTemplates = async () => { fileName: 'termination_update.html', placeholders: ['dealerName', 'status', 'remarks'] }, + { + templateCode: 'INAUGURATION_COMPLETED', + description: 'Notification to relevant teams when a dealership inauguration is logged', + subject: 'Dealership Inauguration Logged: {{applicationId}}', + fileName: 'inauguration_completed.html', + placeholders: ['dealerName', 'applicationId', 'location', 'date'] + }, + { + templateCode: 'CONSTITUTIONAL_CHANGE_APPROVED', + description: 'Final approval notification for Constitutional Change', + subject: 'Constitutional Change Approved — {{requestId}}', + fileName: 'constitutional_change_approved.html', + placeholders: ['dealerName', 'requestId', 'proposedConstitution', 'link'] + }, { templateCode: 'CONSTITUTIONAL_CHANGE_UPDATE', description: 'General status update for Constitutional Change', @@ -178,6 +248,13 @@ const seedTemplates = async () => { fileName: 'relocation_submitted.html', placeholders: ['dealerName', 'requestId', 'outletCode'] }, + { + templateCode: 'RELOCATION_APPROVED', + description: 'Final approval notification for Relocation', + subject: 'Relocation Approved — {{requestId}}', + fileName: 'relocation_approved.html', + placeholders: ['dealerName', 'requestId', 'newLocation', 'link'] + }, { templateCode: 'RELOCATION_UPDATE', description: 'Dealer-visible status updates during relocation workflow', @@ -212,6 +289,20 @@ const seedTemplates = async () => { subject: 'SLA ESCALATION [L{{level}}]: {{applicationId}} — {{stageName}}', fileName: 'sla_escalation.html', placeholders: ['applicationId', 'stageName', 'level', 'timeValue', 'timeUnit', 'link'] + }, + { + templateCode: 'WORKFLOW_ACTION_REQUIRED', + description: 'Turn-based notification for next reviewer/actor in any workflow', + subject: 'Action Required: {{requestId}} — {{targetStage}}', + fileName: 'workflow_action_required.html', + placeholders: ['requestId', 'dealerName', 'targetStage', 'remarks', 'link', 'ctaLabel'] + }, + { + templateCode: 'WORKFLOW_STATUS_UPDATE_DEALER', + description: 'Status update notification sent to dealer for interim workflow stages', + subject: 'Update on Your Request — {{requestId}}', + fileName: 'workflow_status_update_dealer.html', + placeholders: ['dealerName', 'requestId', 'targetStage', 'remarks', 'link', 'ctaLabel'] } ]; diff --git a/src/services/ResignationWorkflowService.ts b/src/services/ResignationWorkflowService.ts index 7aa0d26..e49e1f3 100644 --- a/src/services/ResignationWorkflowService.ts +++ b/src/services/ResignationWorkflowService.ts @@ -131,9 +131,9 @@ export class ResignationWorkflowService { [RESIGNATION_STAGES.RBM]: 30, [RESIGNATION_STAGES.ZBH]: 40, [RESIGNATION_STAGES.DD_LEAD]: 50, - [RESIGNATION_STAGES.NBH]: 60, - [RESIGNATION_STAGES.DD_ADMIN]: 75, - [RESIGNATION_STAGES.LEGAL]: 85, + [RESIGNATION_STAGES.NBH]: 65, + [RESIGNATION_STAGES.LEGAL]: 80, + [RESIGNATION_STAGES.DD_ADMIN]: 90, [RESIGNATION_STAGES.FNF_INITIATED]: 95, [RESIGNATION_STAGES.COMPLETED]: 100, [RESIGNATION_STAGES.REJECTED]: 100 @@ -154,8 +154,8 @@ export class ResignationWorkflowService { [RESIGNATION_STAGES.ZBH]: ROLES.ZBH, [RESIGNATION_STAGES.DD_LEAD]: ROLES.DD_LEAD, [RESIGNATION_STAGES.NBH]: ROLES.NBH, - [RESIGNATION_STAGES.DD_ADMIN]: ROLES.DD_ADMIN, [RESIGNATION_STAGES.LEGAL]: ROLES.LEGAL_ADMIN, + [RESIGNATION_STAGES.DD_ADMIN]: ROLES.DD_ADMIN, [RESIGNATION_STAGES.FNF_INITIATED]: ROLES.DD_ADMIN }; diff --git a/src/services/TerminationWorkflowService.ts b/src/services/TerminationWorkflowService.ts index 9933613..be82559 100644 --- a/src/services/TerminationWorkflowService.ts +++ b/src/services/TerminationWorkflowService.ts @@ -16,7 +16,7 @@ export class TerminationWorkflowService { * Standardized method to transition a termination request status */ static async transitionTermination(termination: any, targetStage: string, userId: string | null = null, metadata: any = {}) { - const { action, remarks, status } = metadata; + const { action, remarks, status, transaction } = metadata; const sourceStage = termination.currentStage; const updateData: any = { @@ -45,7 +45,7 @@ export class TerminationWorkflowService { await termination.update({ ...updateData, timeline: updatedTimeline - }); + }, transaction ? { transaction } : undefined); // 4. Create Audit Log using standardized mapper const { actionType } = metadata; @@ -57,7 +57,7 @@ export class TerminationWorkflowService { action: formatOffboardingAction(auditAction), remarks: remarks || '', details: { status: updateData.status, stage: sourceStage, targetStage: formatOffboardingAction(targetStage) } - }); + }, transaction ? { transaction } : undefined); // 5. Create Worknote for standardized communication trail if (remarks && userId) { @@ -227,7 +227,7 @@ export class TerminationWorkflowService { placeholders: { dealerName: dealerUser?.fullName || 'Dealer', requestId: termination.requestId, - link: `${portalBase}/fnf-settlements/${fnf.id}`, + link: `${portalBase}/fnf/${fnf.id}`, phone: phone || '' } }); @@ -308,4 +308,33 @@ export class TerminationWorkflowService { remarks: summary }); } + /** + * Checks if a user is authorized to perform an action based on their role and current stage + */ + static async canUserAction(termination: any, user: any) { + if (!user) return false; + if (user.roleCode === ROLES.SUPER_ADMIN) return true; + + const stageToRole: Record = { + [TERMINATION_STAGES.SUBMITTED]: ROLES.ASM, + [TERMINATION_STAGES.RBM_REVIEW]: [ROLES.RBM, ROLES.DD_ZM], + [TERMINATION_STAGES.ZBH_REVIEW]: ROLES.ZBH, + [TERMINATION_STAGES.DD_LEAD_REVIEW]: ROLES.DD_LEAD, + [TERMINATION_STAGES.LEGAL_VERIFICATION]: ROLES.LEGAL_ADMIN, + [TERMINATION_STAGES.DD_HEAD_REVIEW]: ROLES.DD_HEAD, + [TERMINATION_STAGES.NBH_EVALUATION]: ROLES.NBH, + [TERMINATION_STAGES.SCN_ISSUED]: [ROLES.LEGAL_ADMIN, ROLES.DD_ADMIN], + [TERMINATION_STAGES.PERSONAL_HEARING]: [ROLES.NBH, ROLES.DD_LEAD], + [TERMINATION_STAGES.NBH_FINAL_APPROVAL]: ROLES.NBH, + [TERMINATION_STAGES.CCO_APPROVAL]: ROLES.CCO, + [TERMINATION_STAGES.CEO_APPROVAL]: ROLES.CEO, + [TERMINATION_STAGES.LEGAL_LETTER]: ROLES.LEGAL_ADMIN + }; + + const requiredRole = stageToRole[termination.currentStage]; + if (Array.isArray(requiredRole)) { + return requiredRole.includes(user.roleCode); + } + return user.roleCode === requiredRole; + } } diff --git a/trigger-termination.js b/trigger-termination.js index dddb705..312e903 100644 --- a/trigger-termination.js +++ b/trigger-termination.js @@ -93,7 +93,7 @@ async function run() { console.log(`[INFO] Current stage before progression: ${currentStage}`); const approvals = [ - { name: 'RBM Review', email: EMAILS.RBM, remarks: 'Performance concerns validated on-ground. Proceed with termination.' }, + { name: 'RBM + DD-ZM Review', email: EMAILS.RBM, remarks: 'Performance concerns validated on-ground. Proceed with termination.' }, { name: 'ZBH Review', email: EMAILS.ZBH, remarks: 'Strategic decision aligned with regional growth targets. Approved.' }, { name: 'DD Lead Review', email: EMAILS.DD_LEAD, remarks: 'Contractual breaches documented. Verified.' }, { name: 'Legal Verification', email: EMAILS.LEGAL, remarks: 'Legal audit complete. Case is legally sound.' }, @@ -110,7 +110,7 @@ async function run() { const stageOrder = [ - 'Submitted', 'RBM Review', 'ZBH Review', 'DD Lead Review', 'Legal Verification', 'DD Head Review', + 'Submitted', 'RBM + DD-ZM Review', 'ZBH Review', 'DD Lead Review', 'Legal Verification', 'DD Head Review', 'NBH Evaluation', 'Show Cause Notice', 'Personal Hearing', 'NBH Final Approval', 'CCO Approval', 'CEO Final Approval', 'Legal - Termination Letter', 'Terminated' ];