From 3c95146f4a6cb01f79b243a49d93c3efced84598 Mon Sep 17 00:00:00 2001 From: laxman h Date: Wed, 29 Apr 2026 19:49:30 +0530 Subject: [PATCH] added new email templates to cover scenerios in detail way --- docs/modular_wise/01_Dealer_Onboarding.md | 3518 +++++++++++++++++ docs/modular_wise/02_Dealer_Resignation.md | 1886 +++++++++ docs/modular_wise/03_Termination.md | 1625 ++++++++ docs/modular_wise/04_FF_Settlement.md | 1802 +++++++++ docs/modular_wise/05_Constitutional_Change.md | 1279 ++++++ docs/modular_wise/06_Relocation.md | 1255 ++++++ src/__tests__/external-integrations.test.ts | 271 ++ src/__tests__/notification-service.test.ts | 213 + .../onboarding-stage-notifications.test.ts | 345 ++ .../resignation-stage-notifications.test.ts | 365 ++ .../termination-stage-notifications.test.ts | 354 ++ .../workflow-email-notifications.test.ts | 405 ++ src/__tests__/workflow-service.test.ts | 298 ++ src/constants/allowed-email-template-codes.ts | 10 +- src/emailtemplates/applicant_rejected.html | 34 + src/emailtemplates/eor_completed.html | 38 + src/emailtemplates/fnf_initiated.html | 35 + src/emailtemplates/termination_initiated.html | 41 + .../workflow_action_required.html | 30 + .../workflow_status_update_dealer.html | 28 + src/scripts/seed-missing-templates.ts | 316 ++ 21 files changed, 14147 insertions(+), 1 deletion(-) create mode 100644 docs/modular_wise/01_Dealer_Onboarding.md create mode 100644 docs/modular_wise/02_Dealer_Resignation.md create mode 100644 docs/modular_wise/03_Termination.md create mode 100644 docs/modular_wise/04_FF_Settlement.md create mode 100644 docs/modular_wise/05_Constitutional_Change.md create mode 100644 docs/modular_wise/06_Relocation.md create mode 100644 src/__tests__/external-integrations.test.ts create mode 100644 src/__tests__/notification-service.test.ts create mode 100644 src/__tests__/onboarding-stage-notifications.test.ts create mode 100644 src/__tests__/resignation-stage-notifications.test.ts create mode 100644 src/__tests__/termination-stage-notifications.test.ts create mode 100644 src/__tests__/workflow-email-notifications.test.ts create mode 100644 src/__tests__/workflow-service.test.ts create mode 100644 src/emailtemplates/applicant_rejected.html create mode 100644 src/emailtemplates/eor_completed.html create mode 100644 src/emailtemplates/fnf_initiated.html create mode 100644 src/emailtemplates/termination_initiated.html create mode 100644 src/emailtemplates/workflow_action_required.html create mode 100644 src/emailtemplates/workflow_status_update_dealer.html create mode 100644 src/scripts/seed-missing-templates.ts diff --git a/docs/modular_wise/01_Dealer_Onboarding.md b/docs/modular_wise/01_Dealer_Onboarding.md new file mode 100644 index 0000000..1f01ec3 --- /dev/null +++ b/docs/modular_wise/01_Dealer_Onboarding.md @@ -0,0 +1,3518 @@ +# 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** + +- 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 +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 + +``` +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 +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?”_ + +--- + +## 6 Dealer onboarding + +### 6.1 Dealership Application Form + +**6.1.1 Functionality Scope** + +The **Dealer Application Form** is the entry point for individuals or businesses applying to become +an authorized **Royal Enfield dealer**. This form captures all essential applicant details to initiate +the onboarding workflow. It ensures structured data collection, validation, and consent before +the request enters the evaluation process. + + +**6.1.2 Width** + +- Accessible from the **Royal Enfield official website** and internal campaigns (QR-based or + direct link). +- Available as part of the **Dealer Onboarding module** under the section _“Apply for_ + _Dealership.”_ +- On successful submission, the application is routed to the **DD-Admin** and **respective** + **zonal evaluation team** for screening. + +**6.1.3 Depth** + +- The form captures applicant identity, contact, business, and location information through + mandatory fields such as: + o **Full Name** , **Mobile Number** , **Email Address** , **Age** + o **Country** , **State** , **District** , **Pincode** + o **Interested City for Dealership** , **Company Name** , **Education Qualification** + o **How did you hear about us?** + o Ownership details — _“Do you own a Royal Enfield?”_ and _“Are you an existing_ + _dealer/vendor?”_ + o **Address** and **Description** fields capturing business background, experience, and + dealership intent +- The form enforces **mandatory validations** (e.g., email format, mobile number pattern, + field completeness) before submission. +- Applicants must acknowledge the **Terms and Conditions** via a mandatory consent + checkbox, ensuring compliance with RE’s data privacy policy. +- Upon clicking **Submit Application** , data is securely stored in the system database and + auto-routed to the assigned **region/zone hierarchy**. +- The system sends an acknowledgment **notification to the applicant via email and** + **registered mobile number**. Mobile-based notifications will be delivered through + WhatsApp. +- **Form will be having a disclaimer:** A consent checkbox is mandatory in the + application form. The applicant must acknowledge this disclaimer before + submission: _“By submitting this form, you agree to our privacy policy and terms of_ + _service. We will use your information to process your dealership application.”_ + +**6.1.4 Personas-Wise Accessibility & Visibility** + +``` +Persona Accessibility Visibility Scope +Applicant / Dealer +Prospect +``` +``` +Can view and fill the form; required to submit +all mandatory details +``` +``` +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 + +The **Dashboard** is an open element that is **currently under discussion** and will be finalized in later +phases. It is expected to serve as a central view for users to monitor workflow status, pending +approvals, and key metrics once its structure and content are defined. + +### 6.4 Opportunity & Non Opportunity + +**6.4.1 Functionality Scope** + +The **Opportunity & Non-Opportunity Management** module classifies all dealer applications +received through the **Dealer Application Form** into two distinct categories as +**Opportunity** and **Non-Opportunity**. This classification is determined automatically based on the +applicant’s **preferred dealership location** and the **current availability** of opportunities defined +in the system. In certain cases, an applicant may express interest in a specific location (e.g., +Chennai) where an opportunity is not currently open. Such applications will remain on hold and +can be reactivated or re-sent once the opportunity for that location becomes available. The + + +system shall allow the applicant to reinitiate the opportunity request without re-entering all +previous details. The module ensures that every application is properly acknowledged and +routed for further processing or stored for future reference, maintaining transparency and +traceability in applicant communication. + +**6.4.2 Width** + +2.1 The module appears under the **Dealer Onboarding** workspace with two key views: + +- **Opportunity Requests** – Displays all applications where dealership opportunities are + currently open in the requested region. +- **Non-Opportunity Requests** – Captures applications for regions where dealership + opportunities are not available at the time of submission. + +2.2 Both views can be accessed by **DD-Admin, DD-Lead, and DD-ZM** users based on their defined +RBAC access levels. + +2.3 Each application record displays critical information such as **Registration Number, Name, +Preferred Location, Status, Applicant Location, Progress, and Application Date**. + +**6.4.3 Depth** + +3.1 When a dealer submits an application, the system checks the **preferred city and +region** against the **Opportunity Town Master** configured by the admin. + +3.2 Based on this validation, the following actions occur automatically: + +1. If an **opportunity exists** , the applicant receives an **Opportunity Email** , confirming that + their location is currently under consideration. +2. If **no opportunity exists** , a **Non-Opportunity Email** is triggered, informing the applicant + that the region is closed for dealership openings but that their information will be + retained for future reference so in case any opportunity pops up later, he can be + contacted. + 3.3 All submitted applications initially land with the **Admin** , who performs a preliminary + validation and shortlist them into appropriate zonal or regional queues. + 3.5 Both Opportunity and Non-Opportunity records are time-stamped and retained for + audit visibility and future lead generation reference. + + +**6.4.4 Flow** + +``` +Step Source → Destination Description / Action +``` +``` +1 +``` +``` +Dealer Applicant → Application +Form +``` +``` +Applicant submits dealership request with preferred +city. +``` +``` +2 System → Opportunity Validation Engine System verifies if the preferred city exists in the Opportunity Master. +``` +``` +3 Validation Engine → Applicant Sends Opportunity or Non-Opportunity Email based on +result. +``` +``` +4 System → DD-Admin +``` +``` +All applications (both categories) are routed to Admin +for validation. +``` +``` +5 DD(respective Zone)-Admin → DD - ZM / DD-Lead^ Admin distributes qualified opportunities to respective zones for next-level evaluation. +``` +**6.4.5 Personas-Wise Accessibility & Visibility** + +``` +Persona Accessibility Visibility Scope +Applicant Receives automated acknowledgment and opportunity +status email +``` +``` +None beyond +email notification +DD-Admin Full access to both Opportunity and Non-Opportunity +queues; performs initial validation and assignment +``` +``` +Complete +visibility +DD-ZM / DD- +Lead / RBM +``` +``` +View and act on assigned Opportunity Requests only Restricted to +assigned zone or +region +System +(Automation +Layer) +``` +``` +Performs validation and triggers automated +notifications. +The system triggers automated notifications across +configured channels, including email and WhatsApp , +based on workflow events and application status +changes. +``` +``` +Background +execution only +``` + +### 6.5 Questionnaire Response + +The **Questionnaire Response & Scoring** module captures, displays, and evaluates responses +submitted by dealer applicants during the onboarding process. It enables Admin to view all +applicant answers in a structured format with predefined scoring and section-wise weightage. +The objective is to ensure that each applicant is evaluated objectively and consistently based on +parameters such as personal background, financial capacity, and business readiness. The overall +questionnaire score directly contributes to the applicant’s ranking within the region or city for +fair selection and further shortlisting. Questions are to be managed from Admin with versions. + +**6.5.1 Width** + +- Accessible under **Application Details → Questionnaire Response tab**. +- Displays categorized sections such as: + o Personal Information + o Financial Information + o Business Information (if applicable) +- Each response card shows the **question, applicant’s answer, and the score obtained** out + of the assigned weightage (e.g., 5/5, 8/10). +- The top-right corner displays the **aggregate questionnaire score** , expressed as a numeric + total (e.g., _78/100_ ). + +**6.5.2 Depth** + +- The questionnaire is to be created by Admin which will be common for all. There will be + versioning of it in case the questions are added or changed over time. + + +- Each question carries a **predefined weightage** configured by the Admin under the + Questionnaire Master. +- The system automatically calculates the total score once the applicant submits the + questionnaire. +- Evaluation parameters include as example: +- https://docs.google.com/forms/d/1YfTGFNx4zrul0YkJmCp7P0jyJKTiPRMxFvgZE8pmO9g/ + edit +- + o **Personal Details:** State, Age, Qualification, and Business Experience + o **Financial Details:** Net worth, investment capacity, and funding sources + o **Business Readiness:** Infrastructure preparedness, local market knowledge, and + management strength +- The cumulative score determines the **applicant’s rank** relative to others in the same + location. +- All responses and scores are stored ensuring transparency and audit traceability. +- Any updates to the scoring model or questionnaire format are logged and version-tagged + for future reference. + +**6.5.3 Personas-Wise Accessibility & Visibility** + +``` +Persona Accessibility Visibility Scope +Applicant Can fill and submit questionnaire during +onboarding. +``` +``` +Own submission only. +``` +``` +DD-Admin Can view all applicant responses and manage +questionnaire versions. +``` +``` +Full visibility. +``` +``` +DD-ZM / DD-Lead / +RBM +``` +``` +Can view applicant responses and scores for +evaluation or ranking purposes. +``` +``` +Restricted to +assigned regions. +System +(Automation Layer) +``` +``` +Performs automatic scoring, rank generation, +and data versioning. +``` +``` +Background +execution. +``` + +### 6.6 Shortlisting Process + +**6.6.1 Functionality Scope** + +This functionality allows the **DD-Admin** to review all dealer applications received through the +questionnaire responses and shortlist the qualified ones for further evaluation. Admin can view applicant +details, compare preferred and available locations, and assign shortlisted applications to the +respective **DD-ZM** and **RBM** for next-level processing. Each shortlisted record can include remarks +capturing the rationale for selection or any special observation. Once assigned, the shortlisted +applications move to the **Dealership Requests** page for regional evaluation and workflow initiation. + +**6.6.2 Width** + +- Display of all received applications in a tabular view. +- Search and filter for quick reference. +- Ability to select multiple applications for shortlisting. +- Option to assign shortlisted applications to **DD-ZM** and **RBM** users via email ID. +- Field to capture optional remarks during shortlisting. +- Confirmation dialog before final submission. +- Status transition of applications from _“Submitted”_ to _“Shortlisted”_. +- Automated notification and dashboard update for assigned users. + +**6.6.3 Depth** + +- Admin can evaluate each application based on scoring, questionnaire performance, and location + preference before shortlisting. + + +- The shortlisted applications are automatically linked to both **DD-ZM** and **RBM** under their zonal + purview. +- Each assignment creates an audit entry with timestamp, assigning authority, and remarks for + traceability. +- Only valid user email IDs mapped to internal roles (DD-ZM/RBM) can be selected. +- System triggers workflow notifications and emails to the assigned reviewers with application + references. +- Applications remain editable for Admin until confirmation of shortlisting. +- Assigned users can view assigned applications in their dashboards for evaluation. + +**6.6.4 Personas-wise Accessibility & Visibility** + +``` +Persona Accessibility / Actions Visibility +DD-Admin Can view all received applications, shortlist eligible ones, +enter remarks, and assign to DD-ZM & RBM. +``` +``` +Full access to all +applications and history. +DD-ZM Can view shortlisted applications assigned to their zone +and proceed with evaluation. +``` +``` +Zone-wise shortlisted +applications. +RBM Can view and evaluate shortlisted applications for their +respective regions. +``` +``` +Region-wise shortlisted +applications. +ZBH / DD-Lead +/ NBH +``` +``` +Can view summary of shortlisted applicants for +monitoring and audit. +``` +``` +Read-only access. +``` +``` +Applicant Can view the updated application status as Shortlisted in +their dashboard. +``` +``` +Own application only. +``` +### 6.7 Shortlisted Applicants + +**6.7.1 Functionality Scope** + +The **Dealership Requests** screen serves as a centralized workspace for managing and tracking +all **shortlisted dealer applications** that have successfully progressed through initial evaluation +stages. It consolidates applications that are ready for multi-level approval and further processing, +ensuring clear visibility of their current stage, location, and progress. This screen allows internal +users such as **DD-Lead, DD-ZM, and DD-Admin** to monitor real-time progress, review application + + +details, and proceed with subsequent workflow actions such as interviews, EOR tracking, and +final approval. + +**6.7.2 Width** + +- Located under the **Dealer Onboarding module → Dealership Requests**. +- Accessible to internal stakeholders involved in the approval cycle. +- Displays tabular data including: + o ID and Applicant Name + o Preferred and Applicant Location + o Status (e.g., _Shortlisted, Level 1 Pending, Level 2 Approved, EOR In Progress_ ) + o Progress percentage bar + o Date of Application and View Action Button +- Includes search, filter, and export options to enhance navigation and reporting efficiency. + +**6.7.3 Depth** + +- The screen lists only those applications that have been **shortlisted** from the Opportunity + stage or advanced through earlier workflow levels. +- Each record dynamically reflects its **workflow status** , For example: + o _Shortlisted_ – application qualified for initial evaluation. + o _Level 1 Pending_ – awaiting review by DD-ZM and RBM. + o _Level 2 Approved_ – cleared by DD-Lead and ZBH. + o _Level 3 Pending -_ awaiting review by NBH + Head. + o _EOR In Progress_ – dealership architecture and statutory stages initiated. +- The **Progress bar** visually indicates the percentage completion of each application’s end- + to-end journey. +- Users can click **View** to open the Application Detail View for in-depth review and decision- + making. +- All updates and transitions in application status are **system-driven** , ensuring traceability + and eliminating manual tracking. + +**6.7.4 Personas-Wise Accessibility & Visibility** + +``` +Persona Accessibility Visibility +Scope +DD-Admin Can view and monitor all shortlisted applications across +zones. +``` +``` +Full system +visibility. +DD-ZM / RBM Can access applications belonging to their assigned region +for Level 1 evaluation. +``` +``` +Regional +visibility. +DD-Lead / ZBH Can review and approve Level 2 applications. Zone-specific +visibility. +``` + +``` +System +(Automation +Layer) +``` +``` +Updates workflow status and progress dynamically. Background +execution. +``` +``` +NBH The NBH oversees strategic decision-making across +dealer onboarding, resignation, and termination +workflows, and participates in critical approval and +governance checkpoints. +``` +### 6.8 Application Detail View + +**6.8.1 Functionality Scope** + +The **Application Detail View** provides a consolidated and comprehensive overview of a dealer +applicant’s profile for internal reviewers such as the **DD-Admin, DD-ZM, and DD-Lead**. It +centralizes all relevant information submitted by the applicant and derived from the +questionnaire evaluation to support ranking and decision-making. This screen allows authorized + + +users to review applicant details, track progress, view ranks within the same city or region, and +take context-specific actions such as approving, rejecting, assigning, or scheduling interviews. + +**6.8.2 Width** + +- Located within the **Dealer Onboarding Module → Opportunity Requests → Application** + **Detail** view. +- Accessible after selecting any applicant record from the Opportunity Requests list. +- Displays sections such as **Applicant Information** , **Summary** , **Actions** , and **Work Notes**. + +**6.8.3 Depth** + +- The **Applicant Information** section displays essential profile details including: + o Full Name, Email, Mobile Number, and Age + o Education Qualification and Past Experience + o Preferred Location, Residential Address, and Business Address + o Questionnaire Score (auto-calculated from applicant’s responses) +- The **Summary Panel** on the right-hand side presents: + o Registration ID and Current Status of the application + o Applicant’s **Rank** relative to other candidates in the same city, based on + questionnaire scores + o Visual **Progress Bar** indicating the current stage in the onboarding lifecycle +- The **Actions Panel** allows the reviewer to: + o Approve or Reject the application at the respective level based on RBAC + o Add **Work Notes** or comments visible to internal users + o Schedule an Interview or Assign the application to another reviewer +- The **Work Notes Section** provides an audit of all communications and remarks exchanged + during evaluation, maintaining process traceability. +- The **Ranking** is dynamically calculated based on the questionnaire’s total score within + each city, ensuring comparative evaluation transparency. + +**6.8.4 Personas-Wise Accessibility & Visibility** + +``` +Persona Accessibility Visibility Scope +DD-Admin Full access to view, edit, assign, and update +applicant details +``` +``` +Complete visibility +``` +``` +DD-ZM / DD-Lead / +RBM +``` +``` +Can review applicant profile, approve/reject, +add notes, and view rank +``` +``` +Region- or city-specific +visibility +System (Automation +Layer) +``` +``` +Auto-calculates rank and score; updates +status dynamically +``` +``` +Background operation +``` + +### 6.9 Interview Scheduling & Coordination + +The **Interview Scheduling & Coordination** module enables the **Admin** to set up, manage, and +communicate interview sessions between dealership applicants and Royal Enfield’s evaluation +panel members. It supports scheduling across **Level 1, Level 2, and Level 3** interviews, ensuring +structured coordination and traceability. The feature provides flexibility to conduct interviews in +either **virtual** or **physical** mode and ensures timely notification of all stakeholders through +automated Google calendar invites. The goal is to streamline interview planning, eliminate +manual follow-ups, and ensure every shortlisted applicant is evaluated by the appropriate +authority as per the defined onboarding workflow. + +**6.9.1 Width** + +- Accessible under **Application Detail View → Schedule Interview**. +- Managed exclusively by **DD-Admin** for all interview levels. +- The form includes: + o **Interview Type:** Level 1, Level 2, or Level 3 + o **Interview Mode:** Virtual (via Google Meet) or Physical (on-site venue) + o **Date & Time:** Calendar-based selection + o **Participants:** Field for adding evaluator email addresses (comma-separated) + o **Meeting Link / Location:** Manually entered by Admin based on interview mode +- Once scheduled, the system sends **Google Calendar invites** to all participants and the + applicant with the interview details embedded. + +**6.9.2 Depth** + +- **Interview Levels:** + o _Level 1:_ Conducted by DD-ZM and RBM for preliminary evaluation and KT Matrix + review. + o _Level 2:_ Conducted by DD-Lead and ZBH for business and operational assessment. + o _Level 3:_ Conducted by NBH and DD-Head as the final approval stage. + + +- The **Admin** manually adds the **Google Meet link** (for virtual interviews) or **venue** + **address** (for physical sessions) before scheduling. +- After scheduling, a **Google Calendar invitation** is automatically triggered to all + participants and the applicant, containing the meeting details, mode, and timing. +- The system automatically updates the **Application Timeline** to reflect the scheduled + interview with date, time, and mode tags. +- All scheduling actions, including edits or reschedules, are captured in the **Audit Trail** for + traceability. +- The feature ensures complete visibility and coordination across all levels of the interview + process. + +**6.9.3 Personas-Wise Accessibility & Visibility** + +``` +Persona Accessibility Visibility Scope +DD-Admin Can create, edit, and manage interview +schedules for all levels. +The DD ASM is responsible for interview +scheduling and coordination with dealer +prospects. +The Admin role does not participate in +interview scheduling and only facilitates +system - level access and configuration. +``` +``` +Full visibility. +``` +#### DD-ZM / RBM / DD- + +``` +Lead / ZBH / NBH / DD- +Head +``` +``` +Receive Google Calendar invitations with +meeting details; can view schedule over +Google Calendar +``` +``` +Restricted to +assigned level and +applicant. +Applicant / Dealer +Prospect +``` +``` +Receives interview schedule via email and +Google Calendar invite with meeting details. +``` +``` +View-only for own +interview details. +System (Automation +Layer) +``` +``` +Sends Google Calendar invites, updates +application status, and logs actions in the Audit +Trail. +``` +``` +Background +execution. +``` +### 6.10 Interview Evaluation & Feedback Management + + +**6.10.1 Functionality Scope** + +The **Interview Evaluation & Feedback Management** module enables Royal Enfield’s internal +panel members to evaluate dealership applicants through structured, multi-level assessments. It +captures both **quantitative scoring** (via the KT Matrix) and **qualitative insights** (via structured +feedback forms) to ensure a balanced and transparent evaluation process. This module +standardizes the review and ranking procedure across **three interview levels** , integrates **AI- +assisted recommendations** , and provides consolidated visibility for final approval. It ensures that +each shortlisted applicant is assessed fairly, with complete traceability from panel feedback to +final NBH decision. + +**6.10.2 Width** + +- Accessible from **Application Detail View → Interview Evaluation** section. +- Used during all **three interview levels** : + o **Level 1:** DD-ZM + RBM – Initial evaluation and KT Matrix scoring. + o **Level 2:** DD-Lead + ZBH – Strategic and operational capability assessment. + o **Level 3:** NBH + DD-Head – Final review and approval decision. + + +- Comprises two core components: + o **KT Matrix Evaluation Form** – Records structured scores across weighted + parameters. + o **Interview Feedback Form** – Captures remarks, performance summaries, and + recommendations. +- Once submitted, all feedback becomes read-only and is logged in the **Audit Trail** for + compliance and future reference. + +**6.10.3 Depth** + +- **Multi-Level Interview Workflow:** + o Applicants progress sequentially through Level 1, Level 2, and Level 3. + o Interviews may be conducted **virtually via Google Meet** or **physically at** + **designated venues**. + o **DD-Admin** or **DD-Head** schedules interviews and sends **Google Calendar** + **invites** to all panelists and the applicant. + o The **Google Meet link** (for virtual sessions) or **venue address** (for physical sessions) + is entered manually during scheduling. +- **KT Matrix Evaluation & Ranking:** + o Panelists evaluate applicants using the configurable **KT Matrix** , which contains + weighted parameters contributing to a total of 100%. + o Evaluation fields include: + ▪ Age and Qualification + ▪ Local Knowledge and Influence + ▪ Passion for Royal Enfield and Riding + ▪ Business Acumen and Investment Capacity + ▪ Base Location vs Applied Location + ▪ Property Ownership, Time Availability, and Future Expansion Plans + o The system auto-calculates total KT Matrix scores and updates the **applicant’s** + **rank** within the city or region. + o Ranking updates dynamically as evaluations are submitted, ensuring real-time + comparison across applicants. +- **Interview Feedback Form:** + o Enables panelists to provide qualitative assessments beyond numeric scoring. + o Key feedback areas include: + ▪ Strategic Vision and Market Understanding + ▪ Management Capabilities + ▪ Operational Readiness + ▪ Key Strengths and Areas of Concern + o Each panelist submits an **Overall Performance Score** and **Final** + **Recommendation** ( _Approve_ , _Reject_ , or _Hold_ ). + + +``` +o Remarks are consolidated for transparency and displayed in the application +timeline. +o All records are time-stamped and locked post-submission to preserve integrity. +``` +**6.10.4 Panel Feedback & AI Recommendation** + +- After each interview round, all **panel members except NBH** record their individual + remarks, ratings, and recommendations in the system using the **Dealer Interview** + **Recommendation Sheet (For CCO_NBH Approval.xlsx)** format. +- The **standard panel composition** includes: + o Applicant (Prospect) + o RBM (Regional Business Manager) + o ZBH (Zonal Business Head) + o DD-ZM (Zonal Manager) + o DD-Lead + o DD-Head + o NBH (National Business Head – Final Approver) +- Each panelist logs their evaluation covering both **quantitative scores** (via KT Matrix) + and **qualitative insights** (via feedback forms). +- Once all inputs are submitted, the system consolidates feedback and scoring data, then + passes it to the **AI engine (Gemini API)**. +- The AI processes the inputs and generates a **two- to three-line summarized** + **recommendation** that highlights: + o Consensus trend across panelists + o Applicant’s key strengths and differentiators + o Potential concerns or areas for improvement +- The **AI-generated summary** is then presented to the **NBH** in editable format, allowing + review and refinement before finalizing the decision. +- The **NBH** may: + o Approve the AI-generated recommendation directly, or + o Modify the summary to incorporate additional observations before final + submission. +- This process ensures every recommendation reflects **data-backed consensus, AI-** + **supported insights, and human judgment** , maintaining full transparency, accountability, + and audit readiness. + +**6.10.5 Personas-Wise Accessibility & Visibility** + +``` +Persona Accessibility Visibility Scope +DD-ZM / RBM +(Level 1) +``` +``` +Fill KT Matrix, record evaluation, remarks, and +recommendations. Filled by both. +``` +``` +Region-specific +visibility. +``` + +``` +DD-Lead / ZBH +(Level 2) +``` +``` +Assess business strategy and operations, provide +structured feedback and score. Filled by both +``` +``` +Zone-level visibility. +``` +``` +NBH / DD-Head +(Level 3) +``` +``` +Review consolidated feedback, AI summary, and +finalize applicant decision. +``` +``` +Full visibility. +``` +``` +DD-Admin Monitor feedback submissions and completeness +across all interview levels. +``` +``` +Complete visibility +for compliance. +System +(Automation +Layer) +``` +``` +Consolidates scores, generates AI summaries, and +logs actions for audit. +``` +``` +Background +execution. +``` +### 6.11 Interview Feedback & Evaluation Summary + +**6.11.1 Functionality Scope** + +The **Interview Feedback & Evaluation Summary** module consolidates all interview-level +assessments, feedback remarks, and scoring for each applicant in the dealership onboarding +process. +It provides a transparent, structured, and comparable view of candidate evaluations across levels, +helping decision-makers validate suitability based on quantified scores, qualitative remarks, and +panel feedback. + + +**6.11.2 Width** + +- Accessible under the **Interviews tab** within the Application Detail View. +- Displays interview data level-wise, including: + o **Interviewer Name and Role** + o **Individual Scores** (out of configured weightage) + o **Evaluator Remarks** and **Feedback Summary** + o **Level-wise Overall Assessment and Decision Status** +- Supports multiple interview rounds such as **Level 1 (DD-ZM / RBM)** , **Level 2 (ZBH / DD** + **Lead)** , and **Level 3 (DD Head / NBH)**. + +**6.11.3 Depth** + +``` +6.11.3.1 Interview Recording & Display +``` +- Each panel member records their evaluation through structured scoring criteria linked to + the **KT Matrix** +- **KT Matrix (Kepner Tregoe Matrix)** is used to assess structured decision parameters + during evaluation. +- The KT Matrix auto-calculates weighted scores based on parameters such as: + o Business Acumen + o Market Understanding + o Financial Readiness + o Passion for the Brand + o Leadership and Team Capability +- Individual evaluator entries capture: + o **Interviewer Name & Designation (Role)** + o **Score / Weightage** + o **Remarks** (qualitative observation) + o **Feedback Summary** (behavioral and communication assessment) +- Scores from all panelists are auto-averaged to display the **Level Total Score** and **Rank** for + each candidate. + +``` +6.11.3.2 Level-Wise Summaries +``` +- Each interview level concludes with a **Level Summary** section containing: + o **Decision Status:** _Approved / Rejected / Hold_ + o **Approver Comments:** Automatically tagged with evaluator roles (e.g., “Approved + by both ZBH and DD Lead”). + o **Overall Assessment:** Concise narrative summarizing candidate strengths, + e.g., _“Strong candidate with excellent business plan and clarity of thought.”_ + + +- This ensures consistent evaluation format and avoids subjective or incomplete data + entries. + +``` +6.11.3.3 Data Traceability & Access Control +``` +- Each interview and feedback entry is timestamped and recorded in the **Audit Trail** for + compliance. +- Panel members can only view their respective entries until the stage closes. +- Once finalized, the complete evaluation summary becomes visible to higher authorities + (DD-Head, NBH) for reference during final selection. +- No feedback modification is allowed post submission to preserve data integrity. + +**6.11.4 Personas-Wise Accessibility & Visibility** + +``` +Persona Accessibility Visibility Scope +Interview Panel (DD-ZM / +RBM / ZBH / DD Lead / DD +Head / NBH) +``` +``` +Can record scores, remarks, and feedback +for assigned levels. +``` +``` +Access limited to +their interview +stage. +DD-Admin Can view all level-wise feedback and +compile summaries for reporting. +``` +``` +Full visibility and +export control. +DD-Head / NBH Can review all interview levels, +aggregated scoring, and AI +recommendations before final approval. +``` +``` +Read-only visibility +at summary stage. +``` +``` +Applicant / Dealer Prospect No access to internal evaluation data. Not visible. +System (Automation Layer) Aggregates scores, computes averages, +and stores all evaluation logs for audit +traceability. +``` +``` +Background +operation. +``` +### 6.12 Application Approval & Rejection Workflow + + +**6.12.1 1. Functionality Scope** + +The **Application Approval & Rejection Workflow** manages structured decision-making at each +level of the dealer onboarding process. It enables authorized evaluators and interview panel +members to **approve or reject** dealership applications with mandatory remarks and optional +attachments, ensuring transparent and traceable decisions. This feature operates throughout all +workflow stages — from **Level 1 to Level 3** — and captures evaluation outcomes in a unified +format that becomes part of the applicant’s permanent record. Each action taken is time- +stamped, logged, and visible to subsequent reviewers, promoting accountability across the +approval chain. + +**6.12.2 Width** + +- Integrated into the **Application Detail View** and accessible to all reviewers participating + in the **approval hierarchy**. +- The feature appears as an **action modal** during each evaluation stage, allowing the panel + to record feedback through one of two options: + o **Approve Application** – with required remarks and optional document upload. + o **Reject Application** – with mandatory justification for rejection. +- Available at all major decision levels: + o **Level 1:** DD-ZM + RBM + o **Level 2:** DD-Lead + ZBH + o **Level 3:** NBH + DD-Head +- Each level’s action (approve or reject) is visible in the **Application Progress** + **Tracker** and **Audit Trail**. + +**6.12.3 Depth** + +- **Approval Action:** + o The panelist provides a **mandatory remark** summarizing the rationale behind + approval. + o Supporting documents, if any (e.g., business justification, property proof, or + presentation decks), can be attached optionally. + o Upon submission, the system updates the application status (e.g., _Level 1_ + _Approved, Level 2 Approved_ ) and logs the decision details for audit tracking. + o It Also triggers the application to subsequent next level +- **Rejection Action:** + o The panelist provides a **mandatory reason for rejection** , clearly outlining the + grounds for disqualification. + o The system changes the status to _Rejected_ and notifies the applicant and + previous-level reviewers via email and WhatsApp. + + +``` +o Rejected applications are archived for reference and may be reopened only +through Admin authorization. +``` +- **Feedback Integration:** + o Each level’s panel (DD-ZM, RBM, DD-Lead, ZBH, NBH, DD-Head) must record their + respective feedback before submitting approval or rejection. + o The recorded remarks automatically feed into the **consolidated interview and** + **feedback record** , used for AI-assisted summary generation at the NBH stage. +- **Audit & Traceability:** + o Every approval or rejection entry is **time-stamped** with user ID and role. + o The system maintains a **complete audit trail** showing who approved, rejected, or + commented, along with corresponding remarks and uploaded documents. + o This ensures transparent review continuity across all approval levels. + +**6.12.4 Personas-Wise Accessibility & Visibility** + +``` +Persona Accessibility Visibility Scope +DD-ZM / RBM +(Level 1) +``` +``` +Approve or reject applications post-KT Matrix +evaluation. +``` +``` +Region-specific +visibility. +DD-Lead / ZBH +(Level 2) +``` +``` +Review Level 1 feedback, provide comments, and +approve or reject accordingly. +``` +``` +Zone-level visibility. +``` +``` +NBH / DD-Head +(Level 3) +``` +``` +Final approval or rejection with AI-assisted +recommendation review. +``` +``` +Complete visibility. +``` +``` +DD-Admin Monitor decision trail, manage reassignments, and +maintain approval integrity. +``` +``` +Full administrative +visibility. +System +(Automation +Layer) +``` +``` +Updates application status, logs actions, and +triggers notifications via email & whatsapp to +applicant +``` +``` +Background +operation. +``` + +### 6.13 Work Notes & Internal Communication Trail + +**6.13.1 Functionality Scope** + +The **Work Notes & Internal Communication Trail** module serves as the centralized collaboration +channel for each dealership application. It enables authorized Royal Enfield stakeholders to +record, track, and exchange contextual comments directly within the system, eliminating the +need for external emails or offline communication. + +Each work note is linked to a specific application, allowing panel members and reviewers to +maintain a continuous, transparent record of discussions and decisions. The feature improves +traceability, facilitates faster internal communication, and ensures that every remark is +permanently associated with its respective application record. + +Work Notes serve as the **official communication channel for Send Back actions** , capturing +reviewer remarks and notifying concerned users within the resignation workflow. Work Notes +act as the **official communication channel for all Send Back and Revoke actions** across the +resignation workflow. + + +**6.13.2 Width** + +- Accessible under **Application Detail View → Work Notes** tab. +- Available to all internal users participating in the onboarding and approval workflow (DD- + ZM, RBM, DD-Lead, ZBH, DD-Head, NBH, Finance, and Legal). +- Displays a **chronological thread** of messages, with each entry showing the **comment** + **author, role, timestamp, and tagged participants**. +- Allows cross-functional interaction and tagging for efficient information exchange and + resolution tracking. + +**6.13.3 Depth** + +- **Comment Logging:** + o Users can post comments, share clarifications, or document updates related to an + application. + o Each message is stored under the respective application ID to preserve discussion + context. +- **Tagging & Notifications:** + o Authorized users can **tag other stakeholders** using the “@mention” feature to + seek inputs or actions. + o Tagged users receive **email notifications** and **system alerts** with a direct link to + the corresponding work note. +- **Visibility & Access Control:** + o All internal users (RE employees) involved in the workflow can view the entire + communication thread for the application. + o **FDD (Financial Due Diligence) users** , being external partners, can **add comments** + **or upload clarifications** related to their scope of review but **cannot view** + **comments made by other users**. + o This restricted access ensures confidentiality of internal deliberations while still + allowing FDD to communicate and provide input efficiently. +- **Integration & Traceability:** + o Work Notes are linked with system actions such as **interview** + **scheduling** , **approvals** , and **feedback submissions** for contextual reference. + o So every activity will also be logged in work note as well. + o Every note is **timestamped** and logged under the **Audit Trail** for compliance + verification. + +**6.13.4 Personas-Wise Accessibility & Visibility** + +``` +Persona Accessibility Visibility Scope +``` + +#### DD-ZM / RBM / DD- + +``` +Lead / ZBH / NBH / DD- +Head +``` +``` +Can post, tag users, and view all +comments related to the application. +``` +``` +Full visibility within +their assigned region or +zone. +DD-Admin Can monitor all communication threads, +ensure comment quality, and flag +unresolved discussions. +``` +``` +Complete visibility. +``` +``` +Finance / Legal Can view and contribute to discussions +when tagged for specific clarifications. +``` +``` +Tag-based visibility. +``` +``` +FDD (External Agency) Can post comments and attach files +related to financial review but cannot +view others’ remarks. +``` +``` +Restricted visibility – +view only own +comments. +System (Automation +Layer) +``` +``` +Sends notifications for tags, logs all +messages, and maintains chronological +order in the Audit Trail. +``` +``` +Background operation. +``` +### 6.14 System Notifications & Alerts + +**6.14.1 Functionality Scope** + +The **System Notifications & Alerts** module ensures timely communication of important events +and workflow updates to all authorized users involved in the dealer onboarding and offboarding +process. It serves as an in-application and email-based alert mechanism that informs users about +key actions such as application assignments, interview scheduling, document verification, and +status updates. + +**6.14.2 Width** + +- Accessible from the **top navigation bar** under the bell icon in the application interface. + + +- Displays a **dropdown list of recent notifications** , each showing: + o A concise description of the event (e.g., _“Interview scheduled for APP-001”_ ). + o The timestamp indicating when the event occurred. + o A visual indicator for unread alerts. +- Includes a **“View All Notifications”** option that redirects users to the complete + notification history page. +- Notifications are automatically generated for workflow events such as: + o New application assignment + o Interview scheduling or rescheduling + o Document verification completion + o Feedback submission + o Application approval or rejection + o Comment tagging in Work Notes + +**6.14.3 Depth** + +- **Trigger Logic:** + o Notifications are auto-triggered by specific actions performed within the system, + such as approval submission, interview creation, or applicant tagging. + o Each alert is linked to the corresponding application ID, ensuring contextual + reference when accessed. +- **Delivery Channels:** + o Notifications appear as **in-system pop-ups** and are also stored under the + notification dropdown. + o For critical actions (e.g., interview scheduling or application assignment), an **email** + **alert** is also sent to the concerned user. + o For critical actions (e.g., interview scheduling, application assignment, or pending + user actions), alerts are **sent via email and through WhatsApp**. +- **Read & Unread Management:** + o Unread notifications are highlighted with an indicator dot until opened. + o Once viewed, alerts are marked as read and retained in the user’s notification + history for reference. +- **Audit Traceability:** + o All notifications are logged under the **Audit Trail** , maintaining a traceable record + of all communication triggers and delivery timestamps. + +**6.14.4 Personas-Wise Accessibility & Visibility** + +``` +Persona Accessibility Visibility Scope +DD-ZM / RBM / DD- +Lead / ZBH / DD-Head / +NBH +``` +``` +Receive workflow alerts (assignments, +interviews, document verification, feedback). +``` +``` +Role-specific +notifications. +``` + +``` +DD-Admin Can view and manage all notifications +generated across modules for monitoring +purposes. +``` +``` +Full visibility. +``` +``` +Finance / Legal / FDD Receive notifications related to their assigned +applications or document validation events. +``` +``` +Restricted to tagged +or assigned cases. +Applicant / Dealer +Prospect +``` +``` +Receive notifications for interview schedules, +approvals, feedback outcomes, and pending +actions via email and WhatsApp. +``` +``` +External limited +scope. +``` +``` +System (Automation +Layer) +``` +``` +Generates, delivers, and logs notifications +with timestamps. +``` +``` +Background +operation. +``` +### 6.15 FDD (Financial Due Diligence) & Finance Module + +**6.15.1 Functionality Scope** + +The **FDD & Finance Module** manages the complete **Financial Due Diligence (FDD)** and +subsequent **Finance Review** workflow for dealership onboarding. It enables external FDD +partners to securely access their assigned applications, upload financial evaluation reports, and +collaborate with internal stakeholders through integrated Work Notes. +The module ensures **restricted access, secure data handling, and traceable financial review** , +providing a seamless interface for Royal Enfield’s internal teams and external agencies to +collaborate while maintaining compliance and confidentiality. + + +**6.15.2 Width** + +- Accessible through **RE SSO credentials** created for authorized external FDD partners. +- Once logged in, FDD users can view **only the applications assigned to them** for financial + due diligence. +- Available features for the FDD role include: + o **Limited Application View** — displaying key applicant details necessary for + financial review. + o **Document Upload Interface** — to submit financial artefacts and reports. + o **Work Notes Section** — to raise queries or communicate updates with the RE + Admin team. + o **Submit Report Action** — for finalizing FDD evaluation. +- For internal users (Finance Team), this module extends to review, validate, and finalize + financial recommendations post-FDD submission. + +**6.15.3 Depth** + +``` +6.15.3.1 FDD Workflow & Capabilities +``` +- **Access & Authentication:** + o Each FDD partner receives a **dedicated SSO login** configured through RE’s identity + system, ensuring secure and auditable access. + o Upon login, the FDD user dashboard displays **only assigned applications** marked + for due diligence. + o External users have **limited access** — they cannot view internal remarks, + evaluations, or other applications outside their assignment. +- **Application View & Interaction:** + o FDD users can access restricted details such as applicant name, business location, + and required financial documents. + o They can upload their findings under the **Documents Section** and communicate + updates or issues through **Work Notes**. + o The Work Notes act as a **query and escalation tool** — allowing FDD users to + request missing documents, seek clarifications, or flag non-responsive applicants. +- **Work Notes Integration:** + o FDD users can add notes tagged to **DD-Admin** or **Finance Team** for specific actions. + o In case the applicant fails to respond or provide requested documents, the FDD + user adds a note citing **“Non-responsiveness from applicant”** and **returns the** + **application** to Admin for closure or reallocation. + o All such notes are logged chronologically with timestamps and author details for + compliance. +- **Document Upload & Submission:** + + +``` +o FDD users upload essential financial documents and reports such as: +▪ Bank Statements +▪ Income Tax Returns +▪ Credit Reports +▪ Property Papers +▪ Business Valuation Reports +o Each file entry records: +▪ File Name and Type +▪ Upload Date and Time +▪ Uploaded By (User ID / Role) +o Once the report is complete, the FDD user marks it as Submitted , which locks +further edits. +``` +- **Finance Team Review:** + o After submission, the **Finance Team** reviews the FDD report and uploaded + artefacts. + o They evaluate whether the applicant qualifies financially to move forward in the + onboarding process. + o Finance team members may also log remarks, flag discrepancies, or mark an + application as **“Approved for Next Stage”** or **“Rejected on Financial Grounds.”** + o Their decision updates the **Application Journey Tracker** and notifies **DD-** + **Admin** and **NBH**. +- **Confidentiality & Audit Compliance:** + o FDD users cannot view internal evaluations, interview feedback, or progress notes + beyond their assigned stage. + o All uploads, submissions, and Work Note interactions are **timestamped** and + recorded under the **Audit Trail**. + o The Finance Team’s review decisions are also logged for traceability and reporting. + +**6.15.4 Personas-Wise Accessibility & Visibility** + +``` +Persona Accessibility Visibility Scope +FDD Team +(External Partner) +``` +``` +Can log in via SSO, view assigned +applications only, upload documents, and +communicate via Work Notes. +``` +``` +Restricted to assigned FDD +stage and specific +applications. +DD-Admin Can assign applications to FDD users, +monitor progress, and review Work Notes +or returned cases. +``` +``` +Full visibility across all +applications. +``` +``` +Finance Team Reviews submitted FDD reports, validates +financial compliance, and approves or +rejects based on findings. +``` +``` +Complete visibility of all +financial artefacts and +remarks. +DD-Head / NBH View finance-approved FDD reports for final +validation before LOI approval. +``` +``` +Read-only visibility post- +finance review. +``` + +``` +System +(Automation +Layer) +``` +``` +Controls access through SSO, logs all +interactions, updates status, and notifies +stakeholders. +``` +``` +Background operation. +``` +### 6.16 LOI Approval & Issuance + +**6.16.1 Functionality Scope** + +The **LOI Approval & Issuance** module governs the structured process of validating, approving, +and issuing the **Letter of Intent (LOI)** once the dealer applicant successfully clears all financial and +operational evaluations. It ensures that every LOI is issued only after submission and verification +of mandatory documents, confirmation of the security deposit, and formal approval by +authorized stakeholders — **Finance, DD-Head, and NBH**. This module brings +complete **transparency, document-level traceability, and compliance integrity** , ensuring that no +dealership appointment progresses without validated and approved documentation. + +**6.16.2 Width** + +- Accessible under **Application Journey → LOI Approval / LOI Issue** stages. +- Used sequentially by **DD-Admin** , **Finance** , **DD-Head** , and **NBH**. +- Major functional components include: + o **LOI Document Request** + o **Security Deposit Confirmation** + o **Approval Chain (Finance → DD-Head → NBH)** + o **Final LOI Preparation and Issuance** + + +- Once approved, the LOI is issued and the application progresses automatically to **Security** + **Details** and **Dealer Code Generation** stages. + +**6.16.3 Depth** + +``` +6.16.3.1 Document Request & Collection +``` +- Upon completion of the final interview and financial approval, the **DD-Admin** triggers an + automated **LOI Document Request** to the applicant. +- The applicant is required to upload the prescribed set of documents and artefacts in + a **Linked Folder** , following the official naming convention: + o **Region → Name of Prospect → Location → Interview Date → LOI Issuance Date.** +- The folder and files are reviewed by the Admin and Finance teams for completeness + before progressing to approval. + +``` +6.16.3.2 Mandatory LOI Document Checklist +``` +The following artefacts must be submitted before the LOI can be approved: + +- DIP Booklet – filled and signed by RBM +- Profile Sheet +- Dealership Application Form +- Interview Feedback Forms (RBM and ZBH) +- Land Selection Criteria Sheet +- Logic Note and Comparative Logic Note +- Zonal Evaluation Form +- Authorization Letter +- City Map (PPT) +- Proposed Location Photos (minimum 20, PPT) +- Layout Drawings (PPT) +- Viability Sheet +- Project Plan +- Self-signed PAN/Aadhaar of all partners (both sides) +- CIBIL Reports of all partners +- Dealership Name & Address Email from RBM +- Rental / Lease Agreement or Consent Letter from Landlord +- Security Deposit Proof (to be uploaded **only after** document set completion) + + +``` +6.16.3.3 Folder Verification & Tracking +``` +- The Admin verifies that all files are uploaded in the specified folder format and uses + metadata such as **Interview Date** , **LOI Issuance Date** , and **Document Ageing** (days + between interview and issuance) to track process efficiency. +- Any missing or incorrect artefacts trigger a system reminder to the applicant or DD-Admin + for rectification before the approval process can begin. + +``` +6.16.3.4 Security Deposit Validation +``` +- After successful folder verification, the **Admin requests the applicant to perform the** + **security deposit transfer via RTGS**. +- Deposit proof (transaction slip or confirmation) is uploaded into the folder and validated + by Finance. +- Only after deposit confirmation does the system allow LOI preparation to proceed. + +``` +6.16.3.5 Approval Workflow +``` +- The **LOI document** is generated using the approved RE format and automatically + populated with applicant and dealership details. +- The approval routing follows this sequence: + o **Finance Team:** Reviews document completeness and verifies the security deposit. + o **DD-Head:** Validates business justification and network alignment. + o **NBH:** Provides final release authorization through the system. +- Each approver records mandatory remarks before submission, ensuring transparency at + every step. +- Once NBH approves, the LOI is marked as **“Ready to Issue.”** + +``` +6.16.3.6 LOI Issuance +``` +- **DD-Admin** uploads the final signed LOI under the **LOI Issue** stage. +- The system triggers: + o An **official email notification** with the issued LOI is sent to the dealer upon + completion of the LOI issuance stage. This will **not be sent on WhatsApp.** + o Alerts to **Finance** , **DD-Head** , and **NBH** confirming completion of issuance. +- The applicant must upload an **LOI Acknowledgement Copy** with seal and signature to + confirm receipt. + +``` +6.16.3.7 Document & Artefact Tracking +``` +- Every LOI-related artefact includes: + o File Name and Type + + +``` +o Uploaded By (User Role and Name) +o Upload Timestamp +o Version (Draft, Final, Signed Copy) +o Download Link +``` +- Each file upload, review, and replacement is logged under the **Audit Trail** to maintain a + chronological record of actions. + +**6.16.4 Personas-Wise Accessibility & Visibility** + +``` +Persona Accessibility Visibility Scope +DD-Admin Initiates document requests, validates uploads, +manages security deposit confirmation, and +uploads final LOI. +DD ASM, DD ZM, and RBM shall have view-only +access to the workflow. +The DD Lead shall have approval visibility , without +direct approval authority at this stage. +``` +``` +Full access and edit +rights. +``` +``` +Finance Team Verifies security deposit and financial artefacts +before LOI preparation. +``` +``` +Full visibility for +validation. +DD-Head Approves LOI content and validates alignment with +dealership network plans. +``` +``` +Approval-level +visibility. +NBH Provides final release authorization and approves +LOI issuance. +``` +``` +Full visibility for +sign-off. +Applicant / Dealer +Prospect +``` +``` +Uploads required LOI documents and provides +security deposit confirmation. +``` +``` +Access limited to +own uploads. +System +(Automation +Layer) +``` +``` +Monitors document checklist, logs folder actions, +routes approvals, calculates ageing, and triggers +notifications. +``` +``` +Background +operation. +``` +### 6.17 Dealer Code Generation, Architectural Work & Statutory Documentation............ + + +**6.17.1 Functionality Scope** + +This consolidated module covers the post-LOI implementation stages that transition a selected +dealer from approval to operational readiness. It manages three critical workflows: + +- **Dealer Code Generation** – creation of a unique, system-integrated dealership identifier. +- **Architectural Work** – coordination between Admin and Brand Experience teams to + execute layout, design, and site readiness. +- **Statutory Documentation** – collection and validation of mandatory compliance + documents. + +Together, these processes ensure the dealership becomes fully compliant, aligned with Royal +Enfield’s brand standards, and ready for inauguration. + +**6.17.2 Width** + +- Accessible sequentially in the **Application Journey** after _LOI Issued_. +- Managed by **DD-Admin** , with participation from **Architecture / Brand Experience**. +- Progress and status for each sub-module are reflected in the **Progress Tracker**. + +**6.17.3 Depth** + +``` +6.17.3.1 A. Dealer Code Generation +``` +- Once the LOI is acknowledged, **DD-Admin** initiates **dealer code creation** through SAP + using an **OData API integration**. +- The system generates and stores multiple associated codes for: + o **Sales Code** + o **Service Code** + o **Genuine Motorcycle Accessories (GMA) Code** + o **Gear Code** +- These codes uniquely identify all dealer operations across RE systems (DMS, MSD, CRM). +- Code creation details (initiator, timestamp, and reference IDs) are recorded in the **Audit** + **Trail**. +- The application status updates automatically to _Dealer Code Generated_ and triggers + notifications to DD-Admin, Finance, and Legal. + +``` +6.17.3.2 Architectural Work (Brand Experience Team) +``` +- After code generation, **DD-Admin assigns the case** to the **Architecture / Brand** + **Experience Team** for site design and infrastructure execution. + + +- The workflow covers: + o **Part A – Architecture:** + ▪ Admin assigns case → Architecture Team. + ▪ Architecture uploads **DWG layout** and **site dimension drawings**. + ▪ Dealer provides written consent via email confirming acceptance of layout + as per Vastu and design guidelines. + ▪ Final layout issued to dealer along with **multiple drawing sets** for + construction reference. + ▪ Dealer initiates infrastructure work; progress tracked through uploaded + photographs or reports. + o **Part B – Statutory Fulfilment:** + ▪ Admin and Architecture teams collect mandatory statutory compliance + documents from the dealer. + ▪ These include government, financial, and brand compliance artefacts + required before EOR. +- The Architecture team updates milestone completion, and all uploads (drawings, + approvals, and dealer confirmations) are recorded with timestamps and uploader details. + +``` +6.17.3.3 Statutory Documentation +``` +- At this stage, **DD-Admin** collects and verifies all statutory and regulatory documents + necessary for legal and operational readiness. +- The standard document checklist includes: + o GST Registration Certificate + o PAN + o Nodal Agreement + o Cancelled Cheque + o Partnership Deed / LLP / MOA / AOA / COI + o Firm Registration Certificate + o Rental / Lease / Land Agreement + o Virtual Code Confirmation + o Domain ID for _@dealer.royalenfield.com_ + o MSD (Microsoft Dynamics) Configuration confirmation (ledger setup) + o LOI Acknowledgement Copy (signed by dealer) +- Each document record displays: + o File name and type + o Uploaded by (user role and name) + o Upload timestamp + o Version (if replaced or re-uploaded) +- Files are viewable and downloadable from within the application, and all versions are + retained for compliance audits. + + +- The **Finance and Legal teams** verify documents, update status to _Verified / Pending / Re-_ + _submit Required_ , and add remarks. +- Once all statutory items are verified, the system automatically transitions the application + to the **EOR (Essential Operating Requirements)** stage. + +**6.17.4 Personas-Wise Accessibility & Visibility** + +``` +Persona Accessibility Visibility Scope +DD-Admin Initiates dealer code creation, coordinates +architectural assignments, and collects +statutory documents. +DD ASM, DD ZM, and RBM shall have view- +only access for monitoring and reference +purposes. +``` +``` +Full visibility and +control. +``` +``` +Architecture / Brand +Experience Team +``` +``` +Uploads drawings, issues layout approvals, +and updates site readiness milestones. +``` +``` +Limited to assigned +applications. +Finance Team Reviews statutory artefacts (GST, banking, +MSD) and confirms financial readiness. +``` +``` +Verification-level +visibility. +Legal Team Verifies agreements, firm registration, and +compliance documents. +``` +``` +Tag-based visibility +for assigned items. +Dealer / Applicant Uploads statutory artefacts and provides +consent on architecture layouts. +``` +``` +Restricted to own +uploads. +System (Automation +Layer) +``` +``` +Syncs SAP dealer code generation, updates +stage transitions, and logs all artefacts with +timestamps. +``` +``` +Background +operation. +``` +### 6.18 LOA Issuance, Essential Operating Requirements & Inauguration + +**6.18.1 Functionality Scope** + +The **LOA Issuance, Essential Operating Requirements (EOR) & Inauguration** module captures +the final execution phase of the dealer onboarding lifecycle. It ensures that only those dealerships +which have fulfilled all architectural, statutory, and financial prerequisites are authorized to +commence operations under Royal Enfield’s network. +This module manages the formal **Letter of Authorization (LOA)** release, verification of **EOR +compliance** , and the **dealership inauguration process** , providing complete visibility, audit +control, and cross-departmental coordination before official go-live. + +The **Letter of Authorization (LOA) is a parallel statutory activity** and is **not dependent on +infrastructure readiness** for issuance. LOA processing and issuance proceed **in parallel with** + + +**statutory compliance checks** , while infrastructure readiness is tracked independently for final +go-live. + +**6.18.2 Width** + +- Accessible sequentially in the **Application Journey** , following completion of statutory + compliance and architectural validation. +- Managed primarily by **DD-Admin** , with review and approvals by **DD-** + **Head** , **NBH** , **Architecture** , **Training** , and **Brand Experience** teams. +- Tracks readiness status and documents through EOR and Inauguration milestones. + +**6.18.3 Depth** + +``` +6.18.3.1 LOA (Letter of Authorization) Issuance +``` +- Once statutory verification and site readiness are complete, **DD-Admin** initiates the **LOA** + **document preparation**. +- The **LOA** serves as Royal Enfield’s formal authorization, confirming that the dealer has + met all required pre-operational standards. +- The approval routing follows: + o **DD-Head:** Reviews infrastructure completion, EOR readiness, and compliance + artefacts. + o **NBH:** Grants final sign-off authorizing the dealership to operate. +- The finalized LOA document is uploaded into the system by DD-Admin, tagged with: + o Issue Date + o Authorized Signatory (DD-Head / NBH) + o Document Version and Upload Timestamp +- The LOA issuance automatically updates the Application Journey status to _“Authorized for_ + _Operations.”_ +- System-generated notifications are sent to all relevant teams, confirming dealership + activation. + +``` +6.18.3.2 Essential Operating Requirements (EOR) +``` +- The **EOR checklist** ensures that each new dealership is fully operationally ready prior to + launch. +- It includes mandatory pre-opening parameters across business, facility, and IT domains, + such as: + o Display Vehicle Readiness + + +``` +o Brand Signage Installation +o Training Completion for Sales and Service Teams +o MSD / DMS Configuration and Connectivity +o Availability of Service Tools, Equipment, and Spare Inventory +o Safety, Security, and Facility Compliance Checks +o Test Ride Vehicles and Customer Experience Readiness +``` +- Each EOR line item is verified and marked as _Complete / Pending / Non-Compliant_ by the + respective functional team (Architecture, Training, IT, Service). +- The system records: + o EOR Checklist File + o Verification Date + o Verified By (User and Role) + o Comments or Exception Notes +- Once all checklist parameters are marked as _Complete_ , DD-Admin updates the EOR stage + status to _EOR Completed_. +- This completion enables scheduling of the final **Inauguration**. + +``` +6.18.3.3 Inauguration & Go-Live +``` +- Upon EOR completion, **DD-Admin** coordinates with the **NBH, ZBH, RBM** , and **Brand** + **Experience** teams to finalize the inauguration plan. +- The **inauguration details** are logged in the system, including: + o Inauguration Date and Venue + o Attendees (NBH, DD-Head, ZBH, RBM, Architecture, Brand Experience) + o Photographs and Event Summary Report +- Post-event, the Admin uploads the **Inauguration Report** and related media (photographs, + press releases, or video references). +- The system marks the application as _“Dealership Live / Onboarded.”_ +- Key metadata such as inauguration date, event photos, and final status are stored under + the **Application Journey** for historical tracking. + +**6.18.4 Personas-Wise Accessibility & Visibility** + +``` +Persona Accessibility Visibility Scope +DD-Admin Manages LOA creation, tracks EOR checklist +completion, and logs inauguration details. +The DD ASM is authorized to upload LOA- +related documents to support statutory and +compliance verification +``` +``` +Complete visibility +and control. +``` +``` +DD-Head / NBH Approve LOA issuance and review final +readiness for operational authorization. +``` +``` +Approval-level +visibility. +``` + +``` +Architecture / +Brand Experience +``` +``` +Verify physical readiness, signage, and brand +compliance. +``` +``` +Access limited to +assigned EOR items. +Training / IT / +Service Teams +``` +``` +Verify operational readiness across staff +training, tools, and systems configuration. +``` +``` +Tag-based visibility. +``` +``` +Dealer / Applicant Acknowledges LOA receipt and supports +inauguration planning. +``` +``` +Restricted to their +assigned application. +System +(Automation Layer) +``` +``` +Logs EOR verifications, uploads inauguration +metadata, triggers status updates and +notifications. +``` +``` +Background +operation. +``` +### 6.19 Essential Operating Requirements (EOR) Checklist + +**6.19.1 Functionality Scope** + +The **Essential Operating Requirements (EOR) Checklist** module ensures that all pre-launch +business, infrastructure, compliance, and operational prerequisites are fulfilled before a +dealership is formally inaugurated. + +**6.19.2 Width** + +- Accessible under the **EOR Checklist tab** in the Application Detail View. +- Displays a checklist of all operational readiness parameters with their current completion + status. +- Each item includes: + o Parameter Name (e.g., _Sales Standards, DMS Infra, Manpower Training_ ) + + +``` +o Status Indicator ( Pending / Completed / Verified ) +o Assigned Team or Reviewer (Architecture, IT, Finance, Training, etc.) +``` +- The progress bar at the top dynamically updates the **EOR completion percentage** based + on verified items. +- Supports both in-system verification and document-based validation uploads. + +**6.19.3 Depth** + +``` +6.19.3.1 EOR Parameter Configuration +``` +- The checklist is pre-configured with mandatory items applicable to every dealership + before activation. + +``` +6.19.3.2 Status Management & Verification +``` +- Each item can be marked as _Pending_ , _In Progress_ , or _Completed_ by the respective + responsible department. +- Functional owners (Finance, Training, IT, etc.) verify and mark their sections complete. +- The **DD-Admin** oversees all updates, ensuring every checklist item is validated before + final approval. +- Completion of all mandatory parameters automatically updates the stage to _EOR_ + _Completed_. +- Remarks or proof of completion (documents, screenshots, or photos) can be attached to + each item for audit purposes. + +``` +6.19.3.3 Progress Calculation & Tracking +``` +- The system automatically calculates the EOR completion percentage based on total + verified parameters. +- Visual progress indicators are shown both at item and overall level. +- Hover or click actions reveal who completed each parameter and when. +- The **Audit Trail** logs each checklist update with timestamps for traceability. + +``` +6.19.3.4 Integration with Inauguration Readiness +``` +- Once the EOR checklist reaches 100% completion, the system triggers a readiness alert + to **DD-Head** and **NBH**. +- The application automatically transitions to the **Inauguration Stage** , initiating event + scheduling and brand readiness verification. +- EOR verification data remains accessible for post-launch audits. + + +**6.19.4 Personas-Wise Accessibility & Visibility** + +``` +Persona Accessibility Visibility Scope +DD-Admin Monitors and updates EOR checklist progress, +consolidates remarks, and verifies stage +completion. +DD ASM and DD ZM are authorized to upload +site readiness details. +DD Lead, RBM, and ZBH shall have view-only +access for review and governance. +``` +``` +Full visibility and +edit rights. +``` +``` +Architecture / Brand +Experience +``` +``` +Update and mark parameters complete as per +their domain. +``` +``` +Tag-based +restricted visibility. +DD-Head / NBH View final EOR completion status and remarks +before authorizing inauguration. +``` +``` +Read-only visibility +for approval. +Dealer / Applicant May be asked to upload supporting artefacts +(photos, certificates, invoices). +``` +``` +Limited to assigned +items. +System (Automation +Layer) +``` +``` +Calculates completion percentage, updates +stage transitions, and logs verification activities. +``` +``` +Background +operation. +``` +### 6.20 Progress Tracker....................................................................................................... + + +**6.20.1 Functionality Scope** + +The **Application Journey & Progress Tracker** provides a complete visual representation of the +dealership application’s lifecycle — from submission through multi-level evaluations, due +diligence, and final dealership inauguration. It will be maintained in itemized way for each +applicant +It allows all authorized Royal Enfield users to track each milestone in real time, review supporting +documents, and monitor who performed specific actions and when. This ensures **end-to-end +transparency, document-level traceability, and operational accountability** throughout the +dealer onboarding and approval process. + +**6.20.2 Width** + +- +- Accessible within **Application Detail View → Progress Tab**. +- Displays a **vertical, stage-based timeline** of all workflow steps with corresponding + completion statuses. +- Each milestone includes: + o Stage title and brief description (e.g., _1st Level Interview – DD-ZM + RBM_ + _Evaluation_ ). + o Evaluator details and assigned roles. + o Status indicator ( _Completed, In Progress, Pending_ ). + o Date and timestamp of completion. + o **Document and artefact count** , with clickable links to download or review the + uploaded files. +- Covers all workflow phases — from **application submission** to **inauguration and go-live**. +- LOI Issue → Dealer Code Generation → **LOA Issuance** → **EOR Checklist Completion** → + Inauguration & Go-Live + +**6.20.3 Depth** + +``` +6.20.3.1 Stage-Wise Progress Representation: +``` +``` +o Submitted: Application logged with basic details and initial document uploads. +o Questionnaire: Applicant questionnaire completed and scored. +o Shortlist: DD-Admin review with uploaded validation documents. +o 1st Level Interview: Conducted by DD-ZM and RBM , with evaluator remarks and +attachments. +o 2nd Level Interview: Conducted by DD-Lead and ZBH , capturing evaluation +documents and recommendations. +``` + +``` +o 3rd Level Interview: Conducted by NBH and DD-Head , includes final approval +documentation and AI recommendation summary. +o FDD (Financial Due Diligence): Handled by the FDD partner for financial validation; +documents uploaded for review. +o LOI Approval: Preparation and verification for Letter of Intent issuance. +o Security Details: Security and compliance document verification stage. +o LOI Issue: Formal Letter of Intent generated and uploaded. +o Dealer Code Generation : Dealer Code creation is initiated upon trigger by the DD- +Admin , created in the SAP Master , and logged against the application for audit +and traceability. +o Architectural Work: Contains sub-steps — +▪ Assigned to Architecture Team +▪ Architectural Document Upload +▪ Architecture Team Completion +o Statutory Documents: Eleven-step checklist for compliance uploads including: +▪ GST Certificate +▪ PAN +▪ Nodal Agreement +▪ Cancelled Cheque +▪ Partnership Deed / LLP / MOA / AOA / COI +▪ Firm Registration Certificate +▪ Rental / Lease / Land Agreement +▪ Virtual Code +▪ Domain ID +▪ MSD Configuration +▪ LOI Acknowledgement Copy +o LOA (Letter of Authorization): Issued after LOI acceptance. +o EOR (Essential Operating Requirements): Verification of pre-opening operational +criteria. +o Inauguration: Final dealership launch milestone. +``` +**6.20.3.2** Document & Artefact Management: + +``` +o At every stage, the tracker displays document and artefact names , along +with downloadable links for review. +o Each document entry includes: +▪ File name and type (PDF, image, Excel, etc.) +▪ Uploaded by (user name and designation) +▪ Upload timestamp and workflow stage +o This provides clear visibility into which document was added, by whom, and at +what level. +``` + +``` +o Documents can be previewed or downloaded directly from the tracker for audit +and compliance review. +o Any re-upload or replacement creates a versioned entry , preserving historical +visibility. +``` +``` +6.20.3.3 Evaluator Tracking & Status Indicators: +``` +``` +o Evaluator details (e.g., DD-ZM, RBM, ZBH, DD-Head, NBH) are shown for each +interview and approval stage. +o Completed steps are marked in green with timestamps; pending stages appear +grey. +o In-progress stages update dynamically as actions are performed. +``` +**6.20.4 Personas-Wise Accessibility & Visibility** + +``` +Persona Accessibility Visibility Scope +DD-ZM / RBM / DD- +Lead / ZBH / DD-Head / +NBH +``` +``` +Can view all stages, download documents, +and verify evaluator remarks for assigned +applications. +``` +``` +Role-based visibility +within region or +zone. +DD-Admin Full access to track overall progress, verify +documents, and audit stage-wise actions. +``` +``` +Complete visibility. +``` +``` +FDD (External Agency) Can upload and review documents related to +financial due diligence but cannot access +internal stages. +``` +``` +Restricted to FDD +workflow stage. +``` +``` +Finance / Legal Can review and upload documents within +assigned compliance or verification stages. +``` +``` +Tag-based visibility. +``` +``` +System (Automation +Layer) +``` +``` +Updates stage completion, uploads +metadata, and logs all actions in the Audit +Trail. +``` +``` +Background +operation. +``` +``` +Applicant + DD ASM +Access +``` +``` +The applicant shall have limited, stage- +specific access to the portal. +The DD ASM is granted access to designated +stages for document upload and +coordination activities. +``` + +### 6.21 Central Document Repository + +**6.21.1 Functionality Scope** + +The **Central Document Repository** serves as a unified digital storage system that consolidates all +applicant documents, artefacts, and submissions across the dealer onboarding and offboarding +lifecycle. +It provides authorized users with **quick, structured, and traceable access** to every document +uploaded during the application process — ensuring consistency, transparency, and audit +readiness across departments. + +**6.21.2 Width** + +- Accessible from the **Documents tab** within each application’s detail view and from + the **Central Repository dashboard** for cross-application reference. +- Displays a **tabular view** with the following columns: + o **File Name** (hyperlinked to the document) + o **Type** (e.g., PDF, JPG, XLSX, DOCX) + o **Upload Date** + o **Uploader** (user name and designation) + o **Actions** (download or view document) +- Includes an **Upload Document** button for authorized users to add new or supplementary + files. +- Supports **document preview and download** with automatic logging into the Audit Trail. + + +**6.21.3 Depth** + +- **Document Aggregation:** + o All documents uploaded by the applicant or internal users — across stages such + as Application Submission, FDD, LOI, Statutory, and EOR — are automatically + consolidated here. + o The system captures metadata for each file: + ▪ File name and format + ▪ Uploaded by (user and role) + ▪ Timestamp of upload + ▪ Stage and status of workflow at upload time + o Ensures centralized visibility and prevents duplication of files across stages. +- **Access & Visibility:** + o Each user role (Admin, Finance, Architecture, Legal, etc.) can view only those files + relevant to their assigned application stage. + o Files uploaded by applicants are visible to authorized RE personnel +- **Data Integrity & Auditability:** + o Every upload, download, or replacement is automatically logged in the **Audit** + **Trail** with timestamp and user identity. + o The repository supports RE’s internal compliance requirement for **document** + **retention and traceability** , ensuring complete transparency in every workflow. + +**6.21.4 Personas-Wise Accessibility & Visibility** + +``` +Persona Accessibility Visibility Scope +DD-Admin Full access to upload, view, and download all +documents across applications. +``` +``` +Complete +visibility and +control. +Finance / Legal / +Architecture / Brand +Experience Teams +``` +``` +View and verify documents relevant to their +assigned stages (FDD, LOI, Statutory, EOR). +``` +``` +Role-based +restricted +visibility. +DD-Head / NBH Read-only access to review applicant artefacts +and approvals for final decision-making. +``` +``` +Read-only +visibility. +System (Automation +Layer) +``` +``` +Aggregates documents from all workflow +stages, maintains version control, and syncs +logs with Audit Trail. +``` +``` +Background +operation. +``` +``` +Applicant + DD ASM +Access +``` +``` +The applicant shall have limited, stage- +specific access to the portal. +The DD ASM is granted access to designated +stages for document upload and +coordination activities. +``` + +### 6.22 Audit Trail & Activity Log.......................................................................................... + +**6.22.1 1. Functionality Scope** + +The **Audit Trail & Activity Log** module maintains a complete chronological record of all system +activities, transactions, and user actions performed throughout the dealer onboarding and +offboarding lifecycle. It provides an **immutable, timestamped, and role-based** view of every +workflow step, ensuring **traceability, accountability, and compliance** across all process stages. + +Resignation Sent Back by ZBH – Remarks posted via Work Notes. +Resignation Sent Back by DD-Lead – Remarks posted via Work Notes. +Resignation Revoked by NBH – Action logged with justification. + +**6.22.2 2. Width** + +- Accessible under the **Audit Trail tab** in the **Application Detail View** for every applicant. +- Displays a structured log of all activities related to that specific application. +- Each log entry includes: + o **Action Type** (e.g., Application Submitted, Questionnaire Completed, Interview + Scheduled, LOI Issued). + o **Performed By** (user name and designation, or “System” for automated actions). + o **Description / Remarks** (detailing what was done). + o **Timestamp** (exact date and time of the event). +- Entries are displayed in descending chronological order to ensure the latest actions are + always visible. + + +**6.22.3 3. Depth** + +``` +6.22.3.1 Activity Logging +``` +- Every workflow event — from form submission to final approval — is automatically logged + by the system. +- Typical recorded events include: + o Application creation, submission, and status transitions. + o Interview scheduling and completion. + o Document uploads, downloads, and version updates. + o FDD submissions and Finance validations. + o LOI, LOA, and EOR stage completions. + o Inauguration logging and closure actions. + o WhatsApp Notification Triggered – Questionnaire Reminder Sent to Applicant. +- System-triggered events (e.g., _Questionnaire Link Sent_ , _Automated Email Triggered_ ) are + explicitly marked as performed “by System.” +- User-initiated actions record both name and role for audit clarity. +- Dealer Resignation Initiated by Dealer – Request submitted via dealer portal. + +``` +6.22.3.2 Description & Detailing +``` +- Each entry provides a concise description of the event and its context. + o Example: + ▪ _Application Submitted by Amit Sharma — Initial application form_ + _submitted._ + ▪ _Questionnaire Completed by Applicant — Scored 85/100._ + ▪ _LOI Approved by DD-Head — Document ready for issue._ +- Any event with system interaction or document movement captures associated metadata + such as document name, file type, and upload path. + +``` +6.22.3.3 Search, Filter & Export Capabilities +``` +- Users can **search** or **filter** logs by: + o Date Range + o Action Type + o User or Role +- The entire log can be **exported as a PDF** for audit or compliance reporting. + +``` +6.22.3.4 Integration with Other Modules +``` +- The Audit Trail is integrated with all system modules, including: + o **Documents Repository:** Logs every upload, download, or version replacement. + + +``` +o Work Notes: Captures internal discussions and query responses. +o Notifications: Records every alert or email triggered by the system. +o Interview Feedback: Stores evaluator submissions and decision timestamps. +o LOI / LOA / EOR Stages: Marks approvals, uploads, and status changes. +``` +- This unified tracking ensures there are **no unrecorded actions** , regardless of user role or + 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 new file mode 100644 index 0000000..aa68c41 --- /dev/null +++ b/docs/modular_wise/02_Dealer_Resignation.md @@ -0,0 +1,1886 @@ +# 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** + +- 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 +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 + +``` +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 +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 + +The **Dealer Resignation** process enables an existing Royal Enfield dealer to formally + +initiate their intent to discontinue the dealership through a structured and transparent +workflow. This process captures the dealer’s resignation details, reasons for exit, and +proposed timeline, ensuring all associated departments — including **DD-Admin, DD-** + +**Head, Finance, Legal, and Regional Teams** — are informed and involved in the validation +and clearance stages. Each resignation request undergoes systematic review, covering + +asset recovery, financial reconciliation, documentation verification, and contractual +obligations before final approval and closure. + + +### 7.1 Dealer Resignation Request (Initiation) + +**7.1.1 Functionality Scope** + +The **Dealer Resignation Request** process begins when a dealer formally communicates their +intent to resign via an **official email** to ASM. Once received, the **DD-ASM** initiates the resignation +process in the system by creating a digital record using the _Create Resignation Request_ form. The +form captures critical dealership, operational, and contextual information — such as business +constitution, sales data, and closure type — ensuring that the request is documented in a +structured, traceable, and standardized manner. This process establishes a single source of truth +for all resignation-related data, facilitating transparent coordination among **DD-Head, Finance, +Legal, and Regional Teams** for subsequent review and action. Dealer can login exclusively and +can only initiate the Resignation request. + +The **Dealer Resignation Request is initiated by the dealer through the portal** , providing a +structured mechanism to formally submit the intent to discontinue the dealership. The dealer +captures resignation details, reason for exit, and the proposed effective date. Upon submission, +the request is routed to the internal stakeholders for review, validation, and subsequent +clearance processes. The **dealer logs into the portal and initiates the resignation request** by +submitting the required details and supporting information. + + +**7.1.2 Width** + +- Accessible exclusively to **DD-ASM** through the **“Create Resignation Request”** interface. +- Includes the following mandatory and optional input fields: + o **Dealer Code** (it will be fed to SAP API to pull details.) + o **Inauguration** , **LOA** , and **LOI Dates** (Will be fetched from system DB, if available) + o **Last 6 Months Sales** + o **Number of Dealerships / Studios** + o **Constitution** (Proprietorship, Partnership, LLP, Pvt. Ltd., etc.) + o **Dealership Type** (Main, Satellite, Studio, etc.) + o **Type of Closure** (Voluntary, Business Transfer, Termination, etc.) + o **Format Category** (Urban, Rural, etc.) + o **Dealer Scorecard Band** + o **Resignation Reason** (brief summary) + o **Dealer Voice** (detailed justification or remarks from dealer’s email) + o **Upload Document** (resignation email copy or supporting documents) +- **Buttons:** + o **Submit Request:** validates data and triggers routing to the next stage of review. + o **Cancel:** exits without saving. + +**7.1.3 Depth** + +- Upon submission by **DD-Admin** , the system performs the following + o Validates the **Dealer Code** against the dealership master from SAP API to be + provided by RE + o Generates a unique **Resignation Request ID** and logs submission details + (timestamp, user, and role). + o Stores the uploaded resignation email or document in the **Central Document** + **Repository** for reference. + o Automatically notifies the **DD-Head** and relevant stakeholders that a new + resignation has been logged. + o Marks the case status as **“Resignation Initiated”** in the workflow tracker. + o He will also upload the resignation PPT which is build off the system. + +**7.1.4 Personas-Wise Accessibility & Visibility** + +``` +Persona Accessibility Visibility Scope +Dealer / +Applicant +``` +``` +Sends official resignation email to Royal Enfield. +The dealer is provided portal access to upload +resignation-related documents and +responses during the applicable workflow +stages. +``` +``` +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 + +**7.2.1 Functionality Scope** + +The **Resignation Management Dashboard** serves as the central workspace for monitoring and +managing all dealer resignation requests initiated within the system. It provides a consolidated +view of active, pending, and completed cases, enabling stakeholders such as **DD-Admin, ASM, +DD-Lead, ZBH, NBH, and Legal Teams** to review progress, take required actions, and ensure +compliance with the defined offboarding workflow. + +The **ZBH can review resignation requests and perform Send Back or Revoke actions** prior to final +approval. Each action requires **mandatory remarks** and is recorded against the resignation case. + + +RBM, **ZBH, DD-Lead, DD-Head, and NBH** can review resignation requests and are authorized +to **Send Back or Revoke** requests at their respective stages. All such actions require **mandatory +remarks** and are logged for audit purposes. + +**7.2.2 Width** + +- Displays a **summary header** with following key counters: + o **All Requests:** Total number of resignation requests recorded. + o **Open:** Requests currently under review or action. + o **Completed:** Finalized resignations where closure is approved. + o **Requires Your Action:** Highlights cases awaiting action from the logged-in user. +- Shows a **list view** of all resignation requests with the following details: + o **Request ID (e.g., RES-001)** + o **Dealer Name, Dealer Code, and Location** + o **Format Category** (A+, A, B, etc.) + o **Dealership Type** (Main, Studio, etc.) + o **Reason for Resignation** + o **Current Stage** (e.g., ASM Review, DD-Lead Review, NBH Approved, Legal) + o **Submitted On** (auto-captured timestamp) +- Action options: + o **View Details:** Opens complete resignation record and attached documents. + o **Create Resignation Request:** Accessible only to **DD-Admin** for entering new + requests (from dealer emails). +- Filter tabs: + o **All Requests** , **Open** , **Completed** + +**7.2.3 Depth** + +- **Workflow Synchronization:** Each resignation request dynamically updates its stage label + (e.g., _ASM Review_ , _DD-Lead Review_ , _NBH Approved_ ) based on workflow transitions. +- **Notification Logic:** + o The assigned reviewer (ASM, DD-Lead, or NBH) receives automated alerts for + 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 + +**7.3.1 Functionality Scope** + +The **Resignation Details & Review** module provides a comprehensive view of all dealer +resignation information captured during initiation. It enables authorized reviewers to validate +dealer data, evaluate the reason and context for resignation, and take appropriate workflow + + +actions such as **Approval, Withdrawal, Send Back, or Push to Full & Final (F&F)**. The screen +consolidates dealer master data, operational metrics, and resignation specifics, ensuring +reviewers have complete visibility before making decisions. + +**7.3.2 Width** + +- **Header Actions:** + o **Approve:** Marks resignation as validated and forwards it to the next workflow + stage (DD-Head / NBH). + o **Withdrawal:** Used if the dealer retracts the resignation request or if withdrawal + is approved internally. + o **Send Back:** Returns the request to DD-Admin for correction or additional details. + o **Push to F&F:** Moves the case to the **Full & Final Settlement** process after all + approvals are secured. + o **Assign User:** Allows reallocation of review responsibility to another internal user. + o **View Work Notes:** Opens the shared comment thread for internal collaboration + and tagging. +- **Tabs:** + o **Details** – Displays complete resignation information and dealer data. + o **Progress** – Shows stage-wise workflow journey and current reviewer. + o **Documents** – Lists uploaded resignation documents and correspondence. + o **Audit Trail** – Records every action, decision, and timestamp for traceability. + +**7.3.3 3. Depth** + +- **Information Segments:** + o **Request Information:** Pull dealer master details such as Dealer Code, GST, + Address, Domain & Service Codes, City Category, and Dealership Name. + o **Operational Details:** Displays dealership metrics including inauguration and LOA + dates, number of outlets, last six-month sales, business constitution, format + category, and dealer scorecard band. + 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** + +The **Resignation Progress Timeline** provides a transparent, stepwise view of the dealer +resignation workflow — from initial submission to the issuance of the final **Acceptance Letter**. +Since the **Dealer does not have portal access** for resignation, the process starts through an **email +submission to the Area Sales Manager (ASM)** , followed by progressive reviews and comments +at multiple organizational levels. Each approver in the chain can perform one of three key actions +— **Approve** , **Send Back for Clarification** , or **Withdraw** — with remarks captured in **Work +Notes** for audit and traceability. Once approved by the **National Business Head (NBH)** , the +request automatically routes to the **Legal Team** for the issuance of the acceptance letter, visible +to both the DD Admin and DD-ASM. + +The **dealer is provided portal access** to **upload resignation-related documents and +responses** during the applicable workflow stages. For termination cases, **dealer upload access is +restricted** as per defined governance rules. + +**7.4.2 Width** + +``` +7.4.2.1 Stage-wise Flow +Stage Responsible +Role +``` +``` +System / Process Description +``` + +1. Dealer +Resignation +Submission + +``` +Dealer → via +Email to ASM +``` +- Dealer submits resignation via official email and +signed letterhead. +- No direct portal access. +- ASM receives and verifies authenticity. +2. ASM Review DD-ASM • Uploads resignation email and presentation +(e.g., _Sample resignation.pptx_ ) to portal. +- Adds remarks summarizing dealer’s reason and +operational background. +- Forwards case to **RBM + DD-ZM** for evaluation. +3. RBM + DD-ZM +Review + +``` +RBM & DD-ZM • Conduct joint discussion with dealer to understand +cause and alternatives. +``` +- Uploads discussion notes and remarks in **Work Notes**. +- The final output will be submitted as Approve, +Withdrawal or send back. +- Has three action options: +- **Approve:** Forwards case to ZBH for further review. +- **Send Back:** Requests ASM to provide additional +details or clarifications (remark mandatory). +- **Withdraw:** Stops process if dealer withdraws or +case found invalid (remark mandatory). +4. ZBH Review Zonal Business +Head +- Reviews RBM + DD-ZM inputs and validates zonal +implications. +- Adds comments in **Work Notes** and forwards to **DD +Lead**. +- Can perform **Approve** , **Send Back** , +or **Withdraw** actions. +5. DD Lead +Review + +``` +DD Lead • Prepares a formal Resignation Presentation +PPT summarizing business rationale, sales history, +dealer feedback, and proposed recommendation. +``` +- Uploads the presentation and comments to the +portal. +- Approves and shares with **NBH** for final decision. +6. NBH Approval National +Business Head +- Reviews all inputs and puts **final decision remarks** in +Work Notes. +- On approval, system triggers notification to **DD Lead, +ZBH, Zonal Team, Business Zonal Manager, and F&F**. +- Automatically routes the case to **Legal Team** for +Acceptance Letter issuance. +7. Legal Review & +Acceptance Letter + +``` +Legal Team • Prepares and uploads Resignation Acceptance +Letter on portal. +``` +- Can raise queries in Work Notes if required. +- Uploaded document is visible to **DD-Admin** and **DD-** + + +#### ASM. + +- Legal completion closes workflow for the request. +8. DD Admin & +ASM Notification + +``` +DD Admin + +DD-ASM +``` +- DD Admin reviews the uploaded acceptance letter. +- Shares with respective **ASM (Field Team)** to +communicate official closure to the dealer. + +**7.4.3 3. Depth** + +- **Action Modes Across Stages:** + o **Approve:** Advances the resignation request to the next level of the workflow. + _Example:_ “Reviewed with dealer and validated. Forwarding to ZBH for next stage.” + o **Send Back:** Returns to the previous user or ASM for clarifications. + _Example:_ “Incomplete documentation. Dealer statement on financials missing.” + o **Withdraw:** Ends the process if dealer withdraws voluntarily or management + disapproves continuation. + _Example:_ “Dealer requested withdrawal of resignation via email dated 15-Oct.” +- **Audit and Transparency:** + o All actions (including remarks, uploads, and timestamps) are auto-captured + in **Work Notes** and the **Audit Trail**. + o Every document and PPT uploaded (e.g., _Sample resignation.pptx_ ) is linked to its + stage for version tracking. +- **System Automation:** + o NBH approval automatically triggers Legal assignment. + o SLA tracking continues at each step; escalation is logged in Work Notes if delayed. + o Notifications are sent to all relevant stakeholders upon approval, send-back, or + withdrawal. + +**7.4.4 Worknotes** + +The **Work Notes** feature acts as the central communication and collaboration thread +within the resignation workflow. It captures all user interactions, remarks, and system- + +triggered updates in a structured, time-stamped format. Each stakeholder — from +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 + + +**7.5.1 Functionality Scope** + +The **Progress** section provides a stage-wise, visual representation of the entire dealer resignation +workflow. It enables authorized users to track each approval checkpoint — from **request +submission** through **multi-level review** to **final legal acceptance**. Every stage dynamically +updates based on workflow actions such as _Approve_ , _Send Back_ , or _Withdraw_ , with complete +traceability of remarks, uploaded documents, and timestamps. This ensures full transparency, +accountability, and operational consistency across all hierarchical levels. + +**7.5.2 Width** + +- Presents a **chronological timeline** of the resignation process, beginning with _Request +Submitted_ and concluding with _Legal – Resignation Letter_. +- Each stage displays **status indicators** (Pending, In Progress, Approved, or Withdrawn) along +with the **responsible reviewer role**. +- Shows the **number of documents uploaded** at each stage, with direct view/download options. +- Allows reviewers to perform three key actions — _Approve_ , _Send Back_ , and _Withdraw_ — with +remarks made mandatory. +- If a request is **Sent Back** , it automatically reverts to the previous stage, recording remarks +in **Work Notes** and notifying the concerned user. +- On **Withdrawal** , the timeline is locked and marked _Closed – Withdrawn_ for historical reference. +- Once **NBH** provides final approval, the request is automatically assigned to **Legal** for +acceptance letter issuance. +- The **Legal stage** finalizes the process upon letter upload, marking the case _Completed_ and +notifying DD-Admin and field hierarchy. + +**7.5.3 Depth** + +- Each stage retains all **remarks, approvals, timestamps, and supporting documents** for +complete traceability. +- Integrates seamlessly with **Work Notes** and **Audit Trail** , ensuring real-time visibility of all +communications and escalations. +- Supports SLA-driven reminders and escalations that reflect directly in the timeline view. +- All uploaded documents (emails, resignation PPT, acceptance letter) remain permanently +mapped to their respective stages. +- Once the resignation is finalized, historical data stays accessible for compliance and audit +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** + +The **Documents** and **Audit Trail** sections collectively ensure complete transparency and +traceability across the resignation workflow. The **Documents** tab serves as a centralized +repository of all artefacts submitted or generated during the process — including resignation +letters, presentations, communications, and acceptance letters. The **Audit Trail** automatically +captures every workflow action, recording who performed it, what was changed, and when, +ensuring full accountability and data integrity. + +**7.6.2 Width** + +- Allows upload and viewing of all resignation-related documents with type, uploader, and +upload date clearly listed. +- Supports restricted document viewing to authorized personas with download control. +- Provides versioned tracking of uploaded artefacts for compliance. +- The **Audit Trail** logs every stage transition, approval, comment, or document addition with +precise timestamps. +- Automatically records system-triggered events such as SLA reminders or email notifications. + + +**7.6.3 Depth** + +- Each document remains linked to its respective workflow stage and accessible through +the **Progress Timeline**. +- All actions — _Approve_ , _Send Back_ , _Withdraw_ , _Upload_ , and _Assign_ — are recorded for +traceability. +- The system maintains an immutable historical log for governance and audit purposes. +- 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 new file mode 100644 index 0000000..6f23dee --- /dev/null +++ b/docs/modular_wise/03_Termination.md @@ -0,0 +1,1625 @@ +# 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** + +- 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 +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 + +``` +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 +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 + +A **Dealer Termination** process is initiated when a dealership’s continuation is deemed +non-viable due to business, financial, or ethical reasons. The termination may arise + +from three primary causes — **working capital inadequacy** , **continued underperformance** , +or **unethical practices**. Cases involving working capital or performance issues follow a + +structured review and approval process, allowing the concerned dealer to provide +clarification and supporting data before final decision. However, any instance + +of **unethical practice** — including fraud, policy breach, or reputational risk to the brand +— results in **immediate termination**. All termination cases are documented within the + + +system, with remarks, evidence, and approval trails maintained for audit and +compliance verification. + +### 8.1 Create Termination Request + +**8.1.1 Functionality Scope** + +The **Create Termination Request** form enables authorized users such as **DD-Lead** , **DD-Admin** , +or **ASM** to initiate a termination case within the system. The form captures comprehensive +dealership details including operational timelines, format type, constitution, performance data, +and financial indicators. It also specifies the **Termination Category** (e.g., Working Capital, +Performance Issue, or Unethical Practice), supported by descriptive justification and relevant +documentation. The request forms the starting point of the digital termination workflow and +ensures that all necessary contextual data and artefacts are available for subsequent reviews and +escalations. + +**8.1.2 Width** + +- Allows creation of new termination requests by entering **Dealer Code** , operational details, and +financial data. +- Captures **Termination Category** and **Description** for clarity on grounds of termination. + + +- Supports upload of supporting artefacts such as MOMs, dealer commitments, or financial +statements. +- Automatically records creator and timestamp for traceability. + +**8.1.3 Depth** + +- Integrates directly with the **Progress Timeline** , displaying real-time status updates across levels. +- Each submission auto-generates an internal case ID linked to the dealer code for tracking. +- Supports structured escalation logic based on the **Termination Category** — standard route for +working capital/performance cases, immediate escalation for unethical practices. +- Maintains versioned records for every document uploaded at creation stage. + +**8.1.4 Personas-wise Accessibility & Visibility** + +``` +Persona / Role Access Level Visibility & Permissions +ASM / DD-AM Area Level Can initiate termination requests, upload MOMs and +dealer commitments. +RBM + DD-ZM Regional / Zonal +Level +``` +``` +Can view request details and validate information before +escalation. +ZBH Zonal Head Reviews initial request data, comments on justification, +and forwards to DD-Lead. +DD-Lead / DD- +Admin +``` +``` +National +Coordination +``` +``` +Can initiate, review, and forward requests; validates +completeness and assigns to Legal if required. +Legal Review Level Can view dealer details and supporting documents for +legal evaluation. +NBH National Business +Head +``` +``` +Can view the entire request summary before decision +and closure approval. +``` + +### 8.2 Termination Ticket overview + +**8.2.1 Functionality Scope** + +The **Details View** provides a consolidated summary of all key information related to the dealer +under review. It includes dealership codes, operational history, financial performance, and +termination-specific parameters. This enables reviewers at every level—whether ASM, ZBH, or +Legal—to quickly assess background context and validate evidence before taking action. The +interface also displays the current workflow stage and offers in-screen options +to **Approve** , **Withdraw** , or **Send Back** the request with remarks, ensuring traceable and reason- +based decisions. + +**8.2.2 Width** + +- Displays complete dealer profile: code, name, location, and GST details. +- Shows operational data: inauguration date, LOA, LOI, format, constitution, and last six-month +sales. +- Captures termination-specific data: **Termination Category** , reason, and case severity (e.g., +“High”). +- Provides workflow action buttons— **Approve** , **Withdraw** , **Send Back** —with mandatory remarks +input. +- Integration with Work Notes for contextual communication and escalation traceability. + + +**8.2.3 Depth** + +The **Detail Tab** serves as the **central operational dashboard** for viewing all dealer, operational, +and termination-related data within a single, structured interface. It merges static dealer master +information with dynamic workflow inputs and uploaded artefacts, ensuring contextual visibility +for all stakeholders. + +``` +8.2.3.1 Components & Functional Behavior +``` +- **Dealer Information (Owner: DD-Admin / System Integration Layer)** + Displays master data pulled from the Dealer Master table — including **Dealer Code,** + **Name, Address, GST, Domain Name, City Category, Sales Code, Service Code, and GMA** + **Code**. + o Synced automatically from RE’s **Dealer Database (Master Registry)**. + o Read-only for all personas except system admin for data correction requests. + o Enables search and cross-referencing across termination, resignation, and + onboarding records. +- **Operational Details (Owner: DD-Lead / Workflow Engine)** + Highlights the dealership’s business health indicators and structural data, including **LOA,** + **LOI, Inauguration Date, Constitution Type, Dealership Type, Format Category, Dealer** + **Score Card Band, and Last Six-Month Sales**. + o Pulled dynamically from the Sales & Performance Module. + o Reflects the most recent sales cycle, ensuring leadership sees live performance + metrics during termination decision-making. + o Editable only by DD-Lead or authorized DD-Admin prior to case lock. +- **Termination Details (Owner: DD-Lead / DD-ZM / Legal)** + Captures case-specific details such as **Termination Category, Reason Description, and** + **Attachments**. + o Termination Category includes options like _Working Capital Issues, Performance_ + _Shortfall, Breach of Agreement, or Unethical Practices_. + o Documents uploaded here are visible to all reviewers across the approval chain, + maintaining transparency. + o Legal team references this section while framing the **Show Cause Notice (SCN)** or + final termination letter. +- **Workflow Actions (Owner: Workflow Engine / DD-Lead)** + Displays **Approve, Withdraw, and Send Back** controls based on role permissions. + o Triggers automated workflow transitions and real-time updates in **Progress** + **Timeline** and **Audit Trail**. + o Any action logs mandatory remarks under “Communication & Notes” with + timestamp and user identity. + o Permissions vary per role: + + +``` +▪ ASM, RBM: Can only comment or escalate. +▪ ZBH, DD-Lead, NBH: Can approve or send back. +▪ Legal: Can finalize after NBH approval. +``` +- **Document Management Section (Owner: DD-Admin / Legal)** + Repository displaying all uploaded evidence or reports associated with the termination. + o Documents listed by **name, type, uploader, and date**. + o Supports inline viewing (no download needed) for internal confidentiality. + o File retention policy aligns with RE’s compliance standards (minimum 7 years). +- **Audit Trail (Owner: Workflow Engine / System Log)** + Chronologically records every action taken within the termination case — including + user, timestamp, and nature of change. + +**8.2.4 Personas-wise Accessibility & Visibility** + +``` +Persona / Role Access Level Visibility & Permissions +ASM / DD-AM Area Level Can initiate and upload dealer MOMs and commitment +records. +RBM + DD-ZM Regional / Zonal +Level +``` +``` +Review dealer details, validate termination rationale, +and escalate with remarks. +ZBH Zonal Business +Head +``` +``` +Approves or returns the case with comments; can +forward to DD-Lead. +DD-Lead / DD- +Admin +``` +``` +National +Coordination +``` +``` +Validate details, review documents, assign to Legal, or +push for F&F after NBH approval. +Legal Legal Level Review dealer information, validate grounds, and issue +termination letter. +NBH National Head Provides final decision and authorization before case +closure. +``` +### 8.3 Termination Approval & Review Process + +**8.3.1 Functionality Scope** + +The **Termination Approval module** enables Royal Enfield’s internal stakeholders to manage +dealership termination cases in a structured, transparent, and traceable workflow. It ensures that + + +every dealership performance concern — whether due to **working capital shortfall** , **sustained +underperformance** , or **unethical practices** — is systematically reviewed, documented, and acted +upon through the defined escalation hierarchy. + +This module supports structured documentation of **dealer meetings** , **uploaded +artefacts** , **reviewer remarks** , and **legal correspondence** , ensuring no manual communication +dependency. +All approvals, send-backs, or withdrawals are centrally logged, supported by **Work Notes** , +ensuring collaborative clarity and institutional memory across teams. + +The **CEO is the final approving authority** for dealer termination cases. The **Legal team prepares +and issues the termination letter only after CEO approval** , and **not upon NBH approval**. +**CCO and CEO** are included as approval authorities with **Approve, Hold, and Reject options**. +The **dealer does not have portal access** for termination workflows. + +**8.3.2 Width** + +The process spans across the complete DD and Legal hierarchy, ensuring clear role-based +accountability: + +- **ASM:** Conducts monthly visits, logs Meeting of Minutes (MOM), uploads dealer + commitment letter and personal observations. Logging MOM is not the part of this system + but when he feel to trigger Termination, he will log as description & associate documents + while initiating the flow. +- **RBM + DD-ZM:** Escalate after repeated concerns, conduct joint meetings, and document + dealer responses on portal. +- **ZBH:** Reviews zonal-level non-compliance, escalates unresolved cases to DD-Lead and + NBH. +- **DD-Lead:** Reviews consolidated reports, validates escalation records, prepares case + presentation, and assigns to Legal. +- **Legal:** Reviews chronology, evaluates policy or contractual breaches, issues SCN, and + prepares final Termination Letter. +- **DD-Head:** Reviews with DD-Lead and Legal; presents case to NBH for decision. +- **NBH:** Provides final decision – approve, query, or hold. +- **DD-Admin:** Uploads dealer’s SCN response and handles F&F coordination post Legal + issuance. + + +**8.3.3 Depth** + +- **Structured Case Creation (Owner: DD-Lead / DD-Admin / ASM)** + A Termination case is initiated through the “Create Termination Request” form by DD- + Lead, DD-Admin, or ASM. + o Each request is tagged with a unique **Termination ID** (e.g., TERM-001). + o Dealer and operational data are automatically fetched from the **Dealer** + **Master** and **Sales System** for accuracy. +- **Case Workflow Management (Owner: Workflow Engine)** + Each stage of the termination journey — from ASM initiation to Legal closure — is + mapped to approval levels. + o **ASM → RBM/DD-ZM → ZBH → DD-Lead → Legal → DD-Head → NBH**. + o Actions at every level (Approve, Withdraw, Send Back) are recorded with + mandatory remarks. + o Each remark auto-updates in **Work Notes** and **Progress Timeline** , triggering + instant notifications to the next role. +- **Work Note Integration (Owner: All Reviewers)** + The **Work Note** acts as the **central communication thread** within each termination case. + o Each reviewer (ASM, RBM, ZBH, DD-Lead, Legal, etc.) can post contextual remarks, + share discussions, or tag specific users. + o Tagged users (e.g., @DD-Lead, @Legal) receive instant notifications via **system** + **alerts** and **email**. + o Work Notes serve as a real-time collaboration and escalation record — every + comment, clarification, or update remains **time-stamped and user-tagged**. + o Legal and DD-Head may also use Work Notes to request clarification from lower + hierarchies (ASM, RBM, ZBH). + o Once a note is submitted, it becomes immutable and part of the **permanent** + **record** under **Audit Trail**. +- **Meeting & Artefact Uploads (Owner: ASM, RBM, ZBH)** + Each level of escalation includes upload of MOMs, dealer commitment letters, and + observations while Approving at his level. + o Artefacts are uploaded as PDFs (e.g., _Meeting_MOM_June2025.pdf_ ). + o Dealer commitments are scanned and attached for cross-reference during Legal + and NBH reviews. +- **Approval Actions (Owner: Workflow Engine)** + Reviewers can take the following actions: + o **Approve:** Confirms escalation readiness for next level. + o **Send Back:** Pushes case back for clarification with remarks visible in Work Notes. + o **Withdraw:** Used when the concern is resolved or no termination action is required. + Each action is recorded in both **Audit Trail** and **Work Notes** , ensuring clarity on + decision paths. + + +- **Legal Review and Issuance (Owner: Legal Team)** + Legal reviews the case chronology and uploaded artefacts. + o If clarification is needed, they “Send Back” via Work Notes. + o Once validated, Legal create the **Show Cause Notice (SCN)** to the portal and later + create the **Termination Letter** post NBH approval. + o These Show cause Notice and Termination Letter will be created within the system + o All uploaded legal artefacts remain accessible to DD-Lead, DD-Admin, and NBH. +- **Dealer Interaction & Closure (Owner: DD-Admin / DD-Lead)** + Dealer replies to the SCN via DD-Admin, who uploads the response to the portal. + o DD-Lead reviews dealer’s response with inputs from RBM and ZBH, updates + closure remarks, and forwards to NBH. + o Post-approval, Legal uploads the Termination Letter, visible to DD-Admin and + dealer. + o DD-Admin initiates **F&F** coordination, ensuring all records are finalized within SLA. +- **Immediate Termination (Owner: DD-Lead + Legal)** + Cases categorized under “Unethical Practice” trigger direct routing to Legal + DD- + Lead, skipping intermediate reviews. + o Immediate Legal action and issuance of termination communication occur within + the system, ensuring swift compliance. +- **Audit Trail (Owner: System Engine)** + Each user action — approval, send back, upload, comment — is timestamped and + permanently logged. + o The trail captures: _User Name, Action Type, Timestamp, Remarks Summary, and_ + _Linked Artefact_. + o Accessible by DD-Lead, Legal, DD-Head, and NBH for compliance review. + +**8.3.4 Personas-wise Accessibility & Visibility** + +``` +Persona Responsibilities & Key Actions Access Rights +ASM Creates termination request, uploads MOM & dealer +commitments, adds initial remarks and observations. +``` +``` +Create, View, +Comment +RBM / DD- +ZM +``` +``` +Reviews ASM input, conducts escalation meetings, +uploads MOM, provides joint recommendations. +``` +``` +View, Approve, +Send Back +ZBH Reviews regional non-compliance, uploads MOM, +forwards unresolved cases to DD-Lead. +``` +``` +Approve, Send +Back +DD-Lead Reviews full chronology, validates artefacts, triggers Legal +for input, issues SCN, consolidates for final closure. +``` +``` +Full Access, +Approve, +Withdraw +Legal Reviews chronology, uploads SCN, issues Termination +Letter, queries if required through Work Notes. +``` +``` +Approve, Send +Back, Upload +DD-Head Reviews consolidated cases, presents them to NBH for +final decision. +``` +``` +Review, Comment +``` + +``` +NBH Approves or holds termination case; final authority on go- +ahead decisions. +``` +``` +Approve / Hold +``` +``` +DD-Admin Uploads dealer’s SCN reply, final Termination Letter, and +initiates F&F. +``` +``` +Upload, Close +``` +``` +Dealer +(Read-only) +``` +``` +Views SCN and final Termination Letter. View Only +``` +### 8.4 Termination Progress Timeline + +**8.4.1 Functionality Scope** + +The **Termination Progress Timeline** provides a stage-wise visualization of the entire termination +journey — from case initiation to final closure. It ensures that every escalation, document, review, +and approval is tracked transparently with timestamped accountability. + +Each level in the workflow — from **ASM initiation** to **CEO authorization** — is dynamically +reflected with role names, document counts, feedback notes, and status indicators. +The module promotes structured collaboration by integrating **Work Notes** and **Audit +Trail** updates at each milestone, enabling leadership to monitor the decision flow in real time. + + +**8.4.2 Width** + +The timeline consolidates inputs from multiple roles, creating an end-to-end view of operational, +business, and legal evaluations: + +- **ASM** initiates the request and uploads meeting artefacts. +- **RBM / DD-ZM** review and escalate based on repeated violations. +- **ZBH** performs zonal validation and comments. +- **DD-Lead** consolidates data, reviews chronology, and assigns to Legal. +- **Legal** verifies contract breaches and provides legal opinion or Show Cause Notice (SCN). +- **NBH** performs business-level evaluation and grants or holds final approval. +- **CEO / CCO** complete the executive authorization. +- **DD-Admin** coordinates issuance of the final Termination Letter and forwards it to F&F. + +Each transition (approve, send-back, withdraw) automatically updates the timeline with the +reviewer’s remarks and uploaded artefacts. + +**8.4.3 Depth** + +The Termination Progress Timeline follows a clearly defined 14-stage lifecycle. Each stage is +associated with specific ownership, document uploads, and Work Note actions. + +``` +8.4.3.1 Stage-wise Breakdown +``` +1. **Request Initiated** – _ASM / Initiator_ + o Case created with details, termination reason, and dealer code. + o Supporting documents like MOM and commitment letters attached. + o Remarks and feedback logged in Work Notes. +2. **RBM Review** – _RBM + DD-ZM_ + o Joint meeting notes uploaded; recommendations shared. + o Approve or Send-Back with clarification via Work Note. +3. **ZBH Review** – _Zonal Business Head_ + o Evaluates pattern of violations, reviews MOM chain, and adds escalation remarks. +4. **DD Lead Review** – _DD-Lead_ + o Consolidates documentation from ASM, RBM, and ZBH. + o Prepares case synopsis and assigns to Legal for compliance validation. +5. **Legal Verification** – _Legal Department_ + o Reviews breach type (Working Capital, Performance, Unethical Practice). + o Queries or approves via Work Notes. + o Uploads draft SCN if verified. +6. **NBH Evaluation** – _National Business Head_ + + +``` +o Reviews termination recommendation; may approve, hold, or query. +``` +7. **Show Cause Notice (SCN)** – _Legal + DD-Lead_ + o Official SCN issued to dealer. + o Dealer reply awaited; all correspondence uploaded. +8. **DD Lead & Legal Review** – _Joint Review_ + o Evaluates dealer’s SCN reply. + o Records internal discussion outcome in Work Notes. +9. **DD-Head Review** – _Dealer Development Head_ + o Prepares presentation and recommendation for NBH. +10. **CCO Approval** – _Chief Commercial Officer_ + o Reviews and endorses NBH’s decision. +11. **CEO Final Approval** – _Chief Executive Officer_ + o Authorizes final termination execution. +12. **Legal – Termination Letter** – _Legal Team_ + o Uploads signed Termination Letter to portal. + o Triggers auto-notifications to DD-Lead and DD-Admin. +13. **DD-Admin – Share with Dealer** – _DD-Admin_ + o Forwards Termination Letter to dealer. + o Initiates F&F process and records completion date. +14. **Dealer Terminated** – _System Generated_ + o Marks dealership status as “Terminated.” + o Case locked for further edits; all data archived under Audit Trail. + +``` +8.4.3.2 Work Note Integration +``` +- Each stage allows the reviewer to post contextual **Work Notes** for coordination, + clarification, or escalation. +- Notes automatically capture **author, timestamp, and linked stage**. +- Tagged users receive both **email** and **in-app alerts**. +- Work Notes act as the **single source of truth** , capturing every internal discussion and + external clarification. +- Once the case reaches “Dealer Terminated,” Work Notes are archived as part of the + official record visible under **Audit Trail**. + +**8.4.4 Personas-wise Accessibility & Visibility** + +``` +Persona Visibility in Timeline Actions Allowed +ASM Initiate request, view complete history, comment +in Work Notes. +``` +``` +Create, Upload Docs, +Comment +RBM / DD-ZM See all lower-level stages, add remarks, approve or +send-back. +``` +``` +Approve, Send-Back, +Comment +ZBH Access RBM & ASM artefacts, escalate to DD-Lead. Approve, Send-Back +``` + +``` +DD-Lead Full timeline visibility, assign to Legal, manage SCN, +approve final closure. +``` +``` +Full Access +``` +``` +Legal Review termination grounds, issue SCN, upload +Termination Letter. +``` +``` +Approve, Send-Back, +Upload Docs +NBH View all previous stages, make go/no-go decision. Approve / Hold +CCO / CEO Executive-level read access, approve final +termination. +``` +``` +Approve Only +``` +``` +DD-Admin View complete timeline, upload dealer response & +Legal letter, initiate F&F. +``` +``` +Upload, Close +``` +``` +Dealer (Read- +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 new file mode 100644 index 0000000..2fc220d --- /dev/null +++ b/docs/modular_wise/04_FF_Settlement.md @@ -0,0 +1,1802 @@ +# 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** + +- 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 +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 + +``` +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 +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?”_ + +--- + +## 10 F&F Case + +The **Full & Final (F&F) Settlement** process enables the Finance team to close all financial + +obligations with a dealer after resignation or termination. Once triggered by Legal, the +system consolidates inputs from all departments to capture dues, recoveries, and + +clearances. Finance reviews and validates these entries, prepares the final settlement +summary, and executes payment or recovery based on the calculated net amount. All + +actions, remarks, and proofs are recorded in the system for transparency, and the case +is marked as **F&F Completed** once the transaction and approvals are finalized. + + +### 10.1 F&F Settlement Progress Timeline + +**10.1.1 Functionality Scope** + +The **F&F Settlement Progress Timeline** provides a sequential, stage-wise overview of the +dealer’s Full & Final (F&F) settlement journey — right from initiation to final completion. +It acts as a unified visual tracker for Finance, Legal, DD, and Admin teams, enabling transparent +monitoring of all financial closure activities, departmental dependencies, dealer discussions, +and documentation milestones. + +Each stage dynamically updates in real-time based on workflow actions performed by +responsible stakeholders, showing the exact case status and progress across all involved +departments. + + +**10.1.2 Width** + +The timeline integrates all key phases and users involved in the financial closure ecosystem, +including: + +- **DD-Lead / DD-Admin:** Initiate the F&F process upon Legal approval of Resignation or + Termination. +- **Finance:** Validate departmental responses, calculate payables/recoverables, initiate + discussion with the dealer, and finalize settlement disbursement or recovery. +- **Departments (16 Functional Units):** Submit financial clearances or pending dues data + through their respective interfaces. +- **Legal:** Verify settlement completion for compliance and record-keeping. + +**10.1.3 Depth** + +The timeline comprises six structured stages, each with clearly defined ownership, system +actions, and dependencies. + +``` +10.1.3.1 F&F Initiated +``` +- **Owner:** DD-Lead / DD-Admin +- **Description:** + Marks the creation of the F&F case post-approval of Resignation or Termination. + System auto-generates the **Case Number** (e.g., _FNF- 2025 - 001_ ) and pre-populates dealer + details such as name, location, and request type. +- **System Actions:** + o Case record created under Finance module. + o Notification sent to Finance and departmental stakeholders. + o Status: _Completed_ once initialization is confirmed. + +``` +10.1.3.2 Department Responses Received +``` +- **Owner:** All Functional Departments +- **Description:** + Each department submits its NOC or dues-related information through the integrated + F&F clearance form. + Departments that owe or are owed amounts mark respective payables/receivables with + remarks. +- **System Actions:** + + +``` +o Progress bar updates with response count (e.g., 12 of 16 Departments +Responded ). +o SLA-based reminders triggered for pending responses. +o Timeline stage remains Pending until all NOCs are received or escalated. +``` +``` +10.1.3.3 Finance Final Summary +``` +- **Owner:** Finance +- **Description:** + The Finance team consolidates all departmental responses, computes total payables, + receivables, and deductions, and prepares a comprehensive **Settlement Summary** + **Report**. +- **System Actions:** + o Auto-calculation using predefined formula: + Net Settlement = Total Payables – Total Receivables – Deductions. + o Finance reviews and verifies supporting documents. + o Work Notes used to raise clarifications to departments or DD-Lead. + o Status changes to _Pending Dealer Discussion_ after internal approval. + +``` +10.1.3.4 Financial Discussion with Dealer +``` +- **Owner:** Finance + Legal + DD-Lead +- **Description:** + The Finance and Legal teams review the computed summary with the dealer to confirm + payable or recoverable balances. + Dealer may be invited to review supporting documentation and validate accuracy. +- **System Actions:** + o Discussion details logged under **Work Notes** with date and participants. + o Dealer confirmation captured in remarks. + o Settlement sheet locked for final processing once dealer agreement is + confirmed. + +``` +10.1.3.5 Full and Final Settlement +``` +- **Owner:** Finance +- **Description:** + All financial actions — including payments, recoveries, and internal ledger updates — + are executed. + Proof of payment, transaction IDs, and settlement receipts are uploaded. +- **System Actions:** + o Transaction details (Mode, Reference, Amount, Date) entered in **Settlement** + **Verification**. + + +``` +o Status updated to Processed once Finance approves the settlement. +o System triggers automated notifications to DD-Admin, Legal, and DD-Lead. +``` +``` +10.1.3.6 F&F Complete +``` +- **Owner:** Finance + DD-Admin + Legal +- **Description:** + The final stage confirming that the F&F process has been fully completed, all payments + or recoveries are reconciled, and all documentation is finalized. +- **System Actions:** + o Case status updated to _Closed_. + o Settlement report archived in **Audit Trail**. + o Final closure notification sent to all stakeholders. + +**10.1.4 Personas-wise Accessibility & Visibility** + +``` +Persona Timeline Visibility Actions Allowed +DD-Lead / DD- +Admin +``` +``` +Full visibility of all stages from initiation to +completion. +``` +``` +Initiate F&F, Upload +Docs, Add Notes +Finance Complete visibility across all stages with +actionable control from Stage 3 onwards. +``` +``` +Verify, Approve, Reject, +Comment +Departments (16 +Units) +``` +``` +Visible until Department Responses stage. Submit NOC, Add +Comments +Legal Visible from Dealer Discussion to Final +Closure. +``` +``` +Review, Comment +``` +``` +NBH / ZBH / DD- +Head +``` +``` +View-only summary of financial progress. None +``` + +### 10.2 Department Responses + +**10.2.1 Functionality Scope** + +The **Department Responses** section serves as a consolidated interface for tracking NOC +submissions and financial dues from all departments involved in the dealer’s Full & Final (F&F) +settlement. +It provides Finance and DD teams with a transparent view of each department’s clearance +status, whether the department owes a payment to the dealer ( _Payable_ ) or the dealer owes the +department ( _Recovery_ ). +This enables complete financial visibility before the final settlement summary is prepared. +Departments are the **owners of initial claim input only**; final settlement values are owned by +Finance validation. + +**10.2.2 Width** + +This module connects all **functional departments (up to 16 units)** including Sales, Service, Parts, +Finance, Warranty, Marketing, HR, IT, Legal, Logistics, and Quality. +Each department inputs its clearance data — marking whether any dues exist — and provides +supporting remarks or payable/recovery amounts. +The respective department user logs in and submits the department claim amount and proof +during the response window. + +**10.2.3 Depth** + +- **Status Indicators:** + Each department’s submission is color-coded and categorized as: + o 🔴 _Dues_ – Outstanding amount identified. + + +``` +o 🟢 No Dues – Cleared with no financial impact. +o ⚪ Pending – Awaiting departmental response or review. +``` +- **Amount Details:** + When dues are identified, the department specifies the **Amount Type** (Payable or + Recovery) and corresponding **Claim Value**. + This value is treated as a department claim and is not directly used as the final settlement + amount until Finance validation is completed. +- **Edit Lock Rule:** + Once all departmental submissions are complete or SLA freeze is triggered, department + amount fields become read-only. + Any subsequent correction must follow an authorized reopen flow with version tracking. +- **Remarks Section:** + Every response includes contextual remarks for clarity, such as “Outstanding amount + identified” or “Cleared,” ensuring traceable communication between departments and + Finance. + +**10.2.4 Personas-wise Accessibility & Visibility** + +``` +Persona Role in this Section Access Level +Finance Reviews all departmental submissions, verifies +payable/recovery entries, adds notes. +``` +``` +Full Access +``` +``` +Departments (16 +Units) +``` +``` +Submit NOC, mark dues/no-dues, enter remarks, and +upload proofs if applicable and add amount (if any) +``` +``` +Edit / Submit +``` +``` +DD-Lead / DD- +Admin +``` +``` +Monitors overall progress of departmental responses and +follows up on pending inputs. +``` +``` +View / +Comment +Legal / NBH / ZBH Verify final status before case closure. View Only +``` +## 11 Finance Dashboard + +The **Finance Dashboard** provides a unified workspace for managing all financial activities +related to dealer onboarding and offboarding. It gives Finance users complete visibility + +into **pending verifications, approved transactions, and Full & Final (F&F) settlements** across +both Resignation and Termination cases. The dashboard is divided into two key + +segments — **Onboarding** , which focuses on verifying dealer security deposits and initial +payments made via RTGS or NEFT, and **F&F Settlement** , which consolidates all + +department-wise responses, calculates final payable or recoverable amounts, and +facilitates settlement approvals. + + +### 11.1 Finance Dashboard Page + + +**11.1.1 Functionality Scope** + +The **Finance Dashboard** serves as the centralized workspace for the Finance team to verify +dealer-related financial transactions and settlements — both during onboarding and +offboarding processes. +It ensures end-to-end visibility of **Security Deposit verifications** for new dealerships and **Final +F&F settlements** for dealers resigning or terminated, thereby providing financial traceability +across the dealership lifecycle. + +The dashboard operates in two distinct functional tabs: + +- **Onboarding:** For validating advance payments (Security Deposit, Initial Fees, etc.) + submitted by dealers during application onboarding. +- **F&F Settlement:** For managing Final Settlement workflows + upon **Resignation** or **Termination** , involving multi-department inputs and Finance + validation before closure. + +The system provides summarized counters for quick insights — _Pending Verification_ , _Verified +Payments_ , _Pending F&F Summaries_ , and _Completed F&F_ — enabling Finance to prioritize action +items efficiently. + +**11.1.2 Width** + +The Finance Dashboard is cross-functional, connecting the following stages and roles: + +- **During Onboarding:** + o Receives dealer payment data (Security Deposit, Bank Details, Transaction ID, + Mode of Payment, etc.). + o Enables Finance users to verify authenticity of RTGS/NEFT transactions by cross- + checking with corporate account statements. + o Allows upload of verified transaction proof or remarks in case of mismatch. +- **During Offboarding (Resignation / Termination):** + o Auto-fetches the list of dealers approved for exit by NBH and Legal. + o Tracks the **F&F Summary** preparation status and department responses. + o Consolidates financial liabilities, recoverables, or pending clearances. + o Generates a unified view of financial closure and triggers completion once all + departments respond. + +The dashboard integrates with **Legal** , **DD-Admin** , and **DD-Lead** modules to ensure that once a +dealer exit is approved, the Finance team receives all relevant data automatically for settlement +initiation. + + +**11.1.3 Depth** + +``` +11.1.3.1 Onboarding – Payment Verification +``` +- **Initiation:** + Dealer payment details (Security Deposit, Mode of Payment, Transaction ID, and Bank + Name) are captured during onboarding. +- **Verification Process:** + o Finance validates the transaction against company account records. + o Uploaded documents like **Payment Receipt** or **Bank Statement** are reviewed. + o Finance user confirms verification by entering the verified transaction ID, + received date, and remarks. +- **System Actions:** + o On successful verification, payment status updates to **Verified** , triggering an + email + in-app notification to DD-Admin and DD-Lead. + o If discrepancies are found, Finance can flag the payment for review with remarks + in Work Notes. +- **Dashboard Counters:** + o **Pending Verification:** Lists all onboarding payments awaiting Finance + confirmation. + o **Verified:** Displays successfully validated payments along with transaction logs + and verifier details. + +``` +11.1.3.2 Offboarding – F&F Settlement Summary +``` +- **Trigger:** + Once Legal uploads the **Resignation Acceptance** or **Termination Letter** , the case + automatically appears in the Finance Dashboard under _F&F Settlement._ +- **Process Flow:** + 1. System collates the **Dealer Exit Case (Resignation/Termination)** details. + 2. Pulls financial obligations, pending dues, recoverables, and credit balances from + connected departments (e.g., Parts, Apparel, DMS, Marketing). + 3. Displays a departmental response tracker (e.g., _16/16 Departments Responded_ ). + 4. Finance reviews the consolidated data and creates the **Final Settlement** + **Summary**. + 5. On approval, status changes from _Pending Finance Summary_ to _Completed_ and + the record is archived for reporting. +- **Work Note & Communication:** + 1. Finance can use the **Work Notes** tab to tag DD-Lead, Legal, or Admin in case + clarifications are needed. + 2. Each note gets timestamped and appears under **Audit Trail** for traceability. + + +3. Upon finalization, a system-generated confirmation triggers notification to DD- + Admin for closure. +- **Automation & Notifications:** +1. SLA reminders alert Finance for pending verifications nearing expiry. +2. Status changes (Pending → Verified / Completed) are reflected across modules +instantly. + +**11.1.4 Personas-wise Accessibility & Visibility** + +``` +Persona Responsibilities & Actions Access Level +``` +``` +Finance +(Primary +Owner) +``` +``` +Verify onboarding payments, review RTGS details, create and +approve F&F summaries, add Work Notes. Full Access^ +``` +``` +DD-Admin Upload payment proofs during onboarding, upload dealer reply or +Legal letters during offboarding, view Finance remarks. +``` +``` +Upload / +View +``` +``` +DD-Lead +``` +``` +Review verified payment records, view F&F progress, respond to +Finance queries in Work Notes. +``` +``` +View / +Comment +Legal Cross-reference Finance completion before case closure. View Only +``` +``` +NBH / ZBH Monitor high-level financial progress for terminated or resigned +dealers. +``` +``` +View Only +``` +``` +Dealer +(Read-only) +``` +``` +Can view payment verification and F&F closure confirmation in +dealer portal. Once a dealer resigns or is terminated , portal access +is permanently revoked , preventing any further system interaction. +``` +``` +View Only +``` + +### 11.2 F&F Settlement Module + + + +**11.2.1 Functionality Scope** + +The **Full & Final (F&F) Settlement module** enables Royal Enfield’s Finance division to execute, +validate, and document the final financial closure of any dealer account +following **Resignation** or **Termination** approval. +It consolidates all monetary data — payables, receivables, deductions, and department-wise +clearances — into a unified interface for transparent and compliant settlement processing. + +The module provides a structured workflow that ensures all dependencies are cleared across +departments, settlement calculations are system-validated, and final payouts or recoveries are +accurately recorded with bank transaction details. +The process is fully integrated with Legal, Dealer Development (DD), and Admin workflows, +ensuring that once a dealer exit is approved, the F&F process is automatically triggered within +defined SLAs. + +**11.2.2 Width** + +The F&F module covers both **Resignation** and **Termination** closure workflows, integrating all +stakeholders and systems that influence the final settlement outcome. + +- **Dealer Development (DD-Lead / DD-Admin):** + Triggers F&F process after Legal uploads the acceptance or termination letter. +- **Finance:** + Leads the overall settlement process, validates departmental inputs, performs + reconciliation, and confirms final payment or recovery transactions. +- **Departments (16 Functions):** + Submit NOC and financial inputs through automated task prompts (e.g., Parts, Service, + Apparel, HR, Legal, Quality, Marketing, IT, Logistics, etc.). +- **Legal:** + Verifies F&F completion before case closure and maintains compliance documentation. +- **Admin:** + Uploads settlement proof and coordinates with Finance for record finalization. + +This ensures that no dealer account is financially closed until all clearances, proofs, and +validations are in place. + + +**11.2.3 Depth** + +``` +11.2.3.1 Case Overview and Summary +``` +Each F&F case is system-generated with a unique ID (e.g., _FNF- 2024 - 001_ ). +Key case metadata displayed includes: + +- Dealer name, code, and location +- Termination type (Resignation / Termination) +- Submitted and due dates +- Associated domain and sales/service codes +- Case age and current status ( _Pending Finance Review_ , _Completed_ ) + +A **Net Payable / Receivable Indicator** at the top visually represents whether the company owes +payment to the dealer or vice versa. +For example: _Payable to Dealer – ₹9,75,000_ indicates a net payout scenario after adjustments. + +``` +11.2.3.2 Department-wise Clearance Tracking +``` +This section provides a real-time tracker of department responses and clearances. +It includes: + +- **Progress Bar:** Displays total responses received vs. pending (e.g., _12 of 16 departments_ + _responded_ ). +- **NOC Statuses:** + o _NOC Submitted_ – Department confirms zero dues. + o _Dues Pending_ – Department flags financial obligations. + o _Pending_ – Awaiting department review. +- **Response Details Table:** Lists each department with submitted date, clearance remarks, + and any recovery or payable amount. +- **Response Guidelines Panel:** Summarizes submission protocols and auto-reminder SLAs. + +Departments with dues or recovery inputs automatically impact the **Receivable / Deduction +Summary** under Finance Calculation. + +``` +11.2.3.3 Financial Calculation Summary +``` +Finance users can view, verify, and edit financial items categorized into **three structured +sections:** + + +``` +11.2.3.4 Payables to Dealer (Editable) +``` +Represents refundable amounts due from the company to the dealer, such as: + +- Security Deposit refund +- Inventory valuation +- Equipment and fixture reimbursements +- Outstanding credit notes + +For department-originated items, Finance validates each submitted claim into a finance- +validated payable value, with decision and variance reason if changed. +Finance can add new line items only when they are finance-originated adjustments and must +tag source and reason. +Only finance-validated values auto-calculate into the total payables panel. + +``` +11.2.3.5 Receivables from Dealer (Editable) +``` +Captures outstanding recoverables and pending dues, including: + +- Outstanding invoices (Sales / Parts / Service) +- Marketing recoveries +- HR or Finance advances +- Compliance or penalty adjustments +For department-originated records, Finance cannot overwrite department claim history; it +must record a validated receivable value with variance tracking. +Finance-originated receivable rows may be added with mandatory remarks and supporting +documents. + +``` +11.2.3.6 Deductions (Editable) +``` +Represents contingent deductions such as: + +- Pending warranty claims +- Policy violations +- Miscellaneous settlements + +Each item includes claim value (if department-sourced) and finance-validated value. +Only finance-validated values feed into the **Total Deductions** summary. + +``` +11.2.3.7 System-Calculated Formula +``` +At the bottom, a dynamic calculation displays: + +``` +Net Settlement = Total Payables – Total Receivables – Total Deductions +``` +Calculation source rule: +- `Total Payables` = Sum of finance-validated payable values +- `Total Receivables` = Sum of finance-validated receivable values +- `Total Deductions` = Sum of finance-validated deduction values + +A positive balance indicates _Payable to Dealer_ ; a negative balance indicates _Recovery from +Dealer_. + + +``` +11.2.3.8 Settlement Verification Panel +``` +Located on the right side, this panel captures the **final transaction details** once the Finance +review is complete. + +Fields include: + +- **Payment Mode:** NEFT / RTGS / Cheque +- **Transaction / Reference ID:** Corporate transaction number +- **Bank Reference Number:** Optional for verification +- **Settlement Amount & Adjustments:** Auto-fetched from calculation summary +- **Settlement Date:** Date of transfer or adjustment posting +- **Verification Remarks:** For audit or cross-team comments + +Finance can then take one of three workflow actions: + +- **Approve Settlement:** Marks case as “Finance Approved.” +- **Request Clarification:** Sends query back to DD-Lead or Admin with remarks. +- **Reject Settlement:** Moves case to “Returned for Correction” with detailed reason. + +Each action automatically logs under **Audit Trail** and triggers email + system notifications. + +``` +11.2.3.9 Documents Section +``` +This tab centralizes all artefacts submitted or generated during the F&F process. + +It includes: + +- Dealer documents (e.g., _Resignation Letter_ , _Asset Handover Receipt_ , _Inventory_ + _Report_ , _Bank Statement_ ). +- Uploaded proofs by Finance (e.g., _Settlement Proof, Payment Receipt_ ). +- Legal or DD attachments for traceability. + +A **drag-and-drop upload zone** allows Finance or Admin to attach additional records (PDF, DOC, +XLSX, JPG) up to 10 MB each. +Each file is logged with: + +- File name and type +- Upload date and user +- Download option for audit access + + +``` +11.2.3.10 Bank Details Tab +``` +Displays dealer bank information to validate payment transfer: + +- Account holder name +- Account number +- IFSC and branch name +- Bank name + +A system alert prompts the verifier to validate details before disbursing payment: +_“Bank Verification Required – Please confirm bank account before processing settlement.”_ + +``` +11.2.3.11 Settlement Checklist +``` +A final control checklist ensures financial compliance before marking the case as complete. It +includes mandatory checks for: + +- Verification of all financial calculations +- Confirmation of bank account details +- Review of all department responses +- Upload of settlement proof +- Entry of accurate transaction information + +All checklist points must be validated before the “Approve Settlement” button becomes active. + +**11.2.4 Work Notes & Communication Flow** + +- Every clarification, remark, or inter-team discussion is captured through the **Work** + **Note** feature integrated into the F&F module. +- Finance, DD-Lead, and Legal can tag specific users (e.g., _@Admin_ , _@Legal_ ) to address + pending actions. +- Notes are timestamped and visible in the case timeline. +- Work Notes become part of the permanent **Audit Trail** and ensure transparent + communication without relying on emails. + +**11.2.5 Personas-wise Accessibility & Visibility** + +``` +Persona Responsibilities Access +Rights +``` + +``` +Finance (Primary +Owner) +``` +``` +Review, calculate, and approve final settlements; update +transaction details; upload settlement proof; +communicate via Work Notes. +``` +``` +Full Access +``` +``` +DD-Admin Upload dealer responses, asset handover, and supporting +docs; coordinate with Finance for closure. +``` +``` +Upload / +View +DD-Lead Review and confirm financial summaries; respond to +clarifications. +``` +``` +Review / +Comment +Legal Validate compliance and verify settlement proof before +closure. +``` +``` +View / +Comment +Departments (16 +Units) +``` +``` +Submit NOC, recovery, or clearance via linked tasks. Limited Edit +Access +NBH / ZBH / DD- +Head +``` +``` +Monitor overall settlement status and amount trends. View Only +``` +``` +Dealer (Read- +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 new file mode 100644 index 0000000..d50b45b --- /dev/null +++ b/docs/modular_wise/05_Constitutional_Change.md @@ -0,0 +1,1279 @@ +# 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** + +- 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 +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 + +``` +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 +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 + + +**12.2.1 Functionality Scope** + +This functionality enables a **dealer to initiate, track, and manage requests for change in business +constitution** through the portal after successful onboarding. The system provides a **structured +self-service mechanism** to propose constitution changes, capture legally required information, +and submit **constitution-specific mandatory documents** , while routing the request through +a **defined internal review and approval workflow**. + +**12.2.2 Functional Width** + +- Displays a **dealer-facing constitutional change dashboard** with summary indicators: + o Total Requests + o Pending Requests + + +``` +o Completed Requests +``` +- Lists all **constitution change requests** with: + o Request ID + o Current constitution + o Proposed constitution + o Submission date + o Current status + o Progress percentage +- Enables **initiation of a new constitutional change request** +- Supports the following **constitution change cases** : + 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 +- Dynamically determines **mandatory document requirements** based on the **target** + **constitution** +- Allows **document upload only as per applicable case** +- Provides **role-based visibility** into request details, documents, and progress +- Prevents duplicate or parallel requests as per policy + +**12.2.3 Functional Depth** + +- Constitutional change requests can be initiated **only for active and eligible dealers**. +- On selecting **“New Constitutional Change”** , the dealer is presented with a structured + submission form capturing: + o Dealer Code and Dealer Name (auto-populated, non-editable) + o Current constitution (auto-populated) + o Proposed constitution (selectable from allowed options) + o Reason for change + o Details of new partners / members (where applicable) + o Proposed shareholding pattern +- Based on the **proposed constitution** , the system determines the **mandatory document** + **checklist** as follows: + +**12.2.4 Document Applicability Rules** + +**A. Any change resulting in Partnership requires:** + + +- GST Registration Certificate +- Firm PAN Copy +- Self-attested KYC documents +- Partnership Agreement (Notarised) +- Business Purchase Agreement (BPA) +- Firm Registration Certificate (Partnership) +- Cancelled Cheque +- Declaration / Authorization Letter + +**B. Any change resulting in LLP requires:** + +- GST Registration Certificate +- Firm PAN Copy +- Self-attested KYC documents +- Certificate of Incorporation (COI) +- Business Purchase Agreement (BPA) +- LLP Agreement (Notarised) +- Cancelled Cheque +- Declaration / Authorization Letter + +**C. Any change resulting in Private Limited requires:** + +- GST Registration Certificate +- Firm PAN Copy +- Self-attested KYC documents +- MOA (Memorandum of Association) +- AOA (Articles of Association) +- Certificate of Incorporation (COI) +- Business Purchase Agreement (BPA) +- Cancelled Cheque +- Declaration / Authorization Letter + +**D. Any change resulting in Proprietorship requires:** + +- GST Registration Certificate +- Firm PAN Copy +- Self-attested KYC documents +- Cancelled Cheque +- Declaration / Authorization Letter +- The system enforces **document completeness validation** before allowing submission or + progression. + + +- **No OCR or automated document content extraction** is performed; all validations + are **manual and role-driven**. +- Upon submission: + o The request is routed through a **multi-level internal review workflow** (DD ASM → + DD ZM / RBM → ZBH → DD Lead → DD Head → NBH → Legal, as applicable). +- Authorized internal roles may **Approve, Send Back, or Revoke** the request. +- **Send Back and Revoke actions are communicated through Work Notes** , with mandatory + remarks. +- The **Legal team validates statutory compliance** and facilitates updates to dealer master + records post-approval. +- Upon final approval: + o Dealer constitution details are updated in the system of record. + o All actions, documents, and decisions are **logged for audit and compliance**. + +**12.2.5 11.2.4 Personas-wise Accessibility & Visibility** + +``` +Persona Responsibilities Access Rights +Dealer Initiates and tracks constitutional +change requests. +``` +- Initiate new constitutional change +request +- Provide change details and reasons +- Upload mandatory documents as +per applicable case +- View request status, progress, and +Work Notes +DD ASM Coordinates document collection and +supports validation. +- View requests +- Upload supporting documents +- Assist in coordination +DD ZM Performs zonal-level review and +validation. +- View requests +- Review and provide inputs +RBM Conducts regional business evaluation. • View requests +- Review and recommend +ZBH Ensures zonal governance compliance. • Review requests +- Send Back or Revoke with +mandatory Work Notes +- Approve as per hierarchy +DD Lead Ensures adherence to dealer +development policies. +- Review requests +- Send Back or Revoke with +mandatory Work Notes +- Approval visibility + + +``` +DD Head Oversees dealer development +governance. +``` +- Review requests +- Send Back or Revoke with +mandatory Work Notes +- Approve as per hierarchy +NBH Provides senior management approval. • Review requests +- Send Back or Revoke with +mandatory Work Notes +- Final approval authority +Legal +Team + +``` +Validates statutory compliance and legal +documentation. +``` +- Review documents +- Validate compliance +- Facilitate post-approval updates +System Enforces rules and audit compliance. • Determine applicable documents +dynamically +- Validate completeness (no OCR) +- Track progress and status +- Maintain 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/docs/modular_wise/06_Relocation.md b/docs/modular_wise/06_Relocation.md new file mode 100644 index 0000000..587e314 --- /dev/null +++ b/docs/modular_wise/06_Relocation.md @@ -0,0 +1,1255 @@ +# 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** + +- 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 +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 + +``` +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 +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?”_ + +--- + +Dealer Relocation Request + + + +**12.2.6 Functionality Scope** + +This functionality enables a **dealer to initiate, track, and manage dealership relocation +requests** through the portal after successful onboarding. The system provides a **guided self- +service mechanism** to propose a new dealership location, submit **location-specific statutory, +property, and infrastructure documents** , and route the request through a **multi-level internal +approval workflow**. + +**12.2.7 Functional Width** + +- Displays a **dealer-facing relocation dashboard** with summary indicators: + o Total Requests + o Pending Requests + o Completed Requests +- Lists all **relocation requests** with: + o Request ID + o Current location + o Proposed location + o Distance from current location + o Submission date + o Current status + o Progress percentage +- Enables **initiation of a new relocation request** +- Allows **manual address entry** or **map-based location selection** for the proposed site +- Captures **distance from the existing location** +- Provides **request-level detailed view** including: + o Relocation overview + o Submitted information + o Workflow progress + + +``` +o Required and uploaded documents +o History & audit trail +``` +- Supports **document upload, verification, and status tracking** +- Provides **role-based visibility and action controls** +- Prevents parallel or duplicate relocation requests for the same outlet + +**12.2.8 11.3.3 Functional Depth** + +- Relocation requests can be initiated **only for active and eligible dealerships**. +- On selecting **“New Relocation Request”** , the dealer is presented with a structured + submission form capturing: + o Dealer Code and Dealer Name (auto-populated, non-editable) + o Current dealership address (auto-populated) + o Proposed new location (manual entry or map selection) + o Complete address details (city, state, pincode) + o Distance from the current location + o Property type + o Expected relocation date + o Reason for relocation +- Upon submission, the request enters a **multi-level approval workflow** , typically + progressing through: + o DD ASM Review + o RBM Review + o DD ZM Review + o ZBH Review + o DD Lead Review + o NBH Review + o Legal (as applicable) +- Each stage is reflected through a **visual workflow progress timeline** , showing: + o Responsible role + o Stage status (Completed / In Progress / Pending) + o Overall progress percentage +- The system enforces **mandatory document submission and verification** , categorized as: + o Property + o Legal + o Statutory + o Infrastructure +- Required documents include, but are not limited to: + o Property documents for new location + o Lease / Rental agreement for new location + o NOC from current landlord + o Municipal approvals + + +``` +o Fire safety certificate +o Pollution clearance +o Layout / Floor plan of new location +o Photos of new location +o Locality map +o Building plan approval +o Electricity connection documents +o Water supply documents +``` +- Document status is tracked as **Pending Verification** , **Verified** , or **Rejected**. +- Authorized internal users may **Approve, Send Back, or Revoke** the relocation request. +- **Send Back and Revoke actions are communicated through Work Notes** , with mandatory + remarks captured by the system. +- All uploads, verifications, remarks, and approvals are **logged in the audit trail**. +- Upon final approval: + o The relocation request is marked as completed. + o Dealer master records are updated as per the approved new location. +- The system ensures **full traceability and compliance** across all stages of the relocation + process. + +**12.2.9 11.3.4 Personas-wise Accessibility & Visibility** + +``` +Persona Responsibilities Access Rights +Dealer Initiates and tracks dealership +relocation requests. +``` +- Initiate relocation request +- Provide proposed location details +- Upload required documents +- View request status, workflow +progress, and Work Notes +DD ASM Coordinates initial review and +document readiness. +- View relocation requests +- Upload and review documents +- Support coordination +RBM Performs regional feasibility and +business review. +- View requests +- Review and recommend +DD ZM Conducts zonal-level evaluation. • View requests +- Review and provide inputs +ZBH Ensures zonal governance and +compliance. +- Review requests +- Send Back or Revoke with mandatory +Work Notes +- Approve as per hierarchy +DD Lead Ensures policy adherence and cross- +functional alignment. +- Review requests +- Send Back or Revoke with mandatory +Work Notes +- Approval visibility + + +``` +NBH Provides senior management approval. • Review requests +``` +- Send Back or Revoke with mandatory +Work Notes +- Final approval authority +Legal +Team + +``` +Validates statutory and legal +compliance. +``` +- Review legal documents +- Validate approvals and clearances +System Enforces workflow and compliance +rules. +- Control action availability +- 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/__tests__/external-integrations.test.ts b/src/__tests__/external-integrations.test.ts new file mode 100644 index 0000000..1a86e28 --- /dev/null +++ b/src/__tests__/external-integrations.test.ts @@ -0,0 +1,271 @@ +/** + * @file external-integrations.test.ts + * @description Contract/mock tests for all external integrations. + * These tests validate the SHAPE and BEHAVIOUR of each mock so that + * when real APIs are wired, only the mock needs to be swapped. + * + * Integrations covered: + * 1. SAP OData — Dealer Code generation (mockGenerateSapCodes, mockSyncDealerStatusToSap) + * 2. Google Calendar — Interview invite scheduling (mockScheduleMeeting) + * 3. WhatsApp — Notification delivery (mockSendWhatsApp) + * 4. Gemini AI — Panel evaluation summary (mockGenerateAiSummary) + * + * SRS Coverage: + * §6.17.3.1 — SAP OData API for Sales/Service/GMA/Gear codes + * §6.9.2 — Google Calendar invites for all participants + * §1.1.1 — WhatsApp as supported notification channel + * §6.10.4 — AI-assisted recommendation via Gemini API + */ + +import { ExternalMocksService } from '../common/utils/externalMocks.service.js'; + +// ─── 1. SAP Dealer Code Generation ─────────────────────────────────────────── + +describe('SAP Mock — Dealer Code Generation (SRS §6.17.3.1)', () => { + it('TC-SAP-01: returns success=true', async () => { + const result = await ExternalMocksService.mockGenerateSapCodes('app-001'); + expect(result.success).toBe(true); + }); + + it('TC-SAP-02: returns salesCode in SLS-XXXX format', async () => { + const { data } = await ExternalMocksService.mockGenerateSapCodes('app-001'); + expect(data.salesCode).toMatch(/^SLS-\d{4}$/); + }); + + it('TC-SAP-03: returns serviceCode in SRV-XXXX format', async () => { + const { data } = await ExternalMocksService.mockGenerateSapCodes('app-001'); + expect(data.serviceCode).toMatch(/^SRV-\d{4}$/); + }); + + it('TC-SAP-04: returns gmaCode in GMA-XXXX format (Genuine Motorcycle Accessories)', async () => { + const { data } = await ExternalMocksService.mockGenerateSapCodes('app-001'); + expect(data.gmaCode).toMatch(/^GMA-\d{4}$/); + }); + + it('TC-SAP-05: returns gearCode in GER-XXXX format', async () => { + const { data } = await ExternalMocksService.mockGenerateSapCodes('app-001'); + expect(data.gearCode).toMatch(/^GER-\d{4}$/); + }); + + it('TC-SAP-06: returns a non-empty sapMasterId', async () => { + const { data } = await ExternalMocksService.mockGenerateSapCodes('app-001'); + expect(data.sapMasterId).toBeTruthy(); + expect(typeof data.sapMasterId).toBe('string'); + }); + + it('TC-SAP-07: each call generates unique codes (no collisions)', async () => { + const r1 = await ExternalMocksService.mockGenerateSapCodes('app-001'); + const r2 = await ExternalMocksService.mockGenerateSapCodes('app-002'); + // Codes are random; while collision is statistically possible, sapMasterIds must differ + expect(r1.data.sapMasterId).not.toBe(r2.data.sapMasterId); + }); + + it('TC-SAP-08: returns all 4 code types in a single call (no missing fields)', async () => { + const { data } = await ExternalMocksService.mockGenerateSapCodes('app-001'); + expect(data).toHaveProperty('salesCode'); + expect(data).toHaveProperty('serviceCode'); + expect(data).toHaveProperty('gmaCode'); + expect(data).toHaveProperty('gearCode'); + expect(data).toHaveProperty('sapMasterId'); + }); +}); + +// ─── SAP Status Sync ───────────────────────────────────────────────────────── + +describe('SAP Mock — Dealer Status Synchronization', () => { + it('TC-SAP-09: mockSyncDealerStatusToSap returns success=true', async () => { + const result = await ExternalMocksService.mockSyncDealerStatusToSap('SLS-1234', 'Active'); + expect(result.success).toBe(true); + }); + + it('TC-SAP-10: sync result includes a sapTransactionId and ISO timestamp', async () => { + const result = await ExternalMocksService.mockSyncDealerStatusToSap('SLS-1234', 'Terminated'); + expect(result.sapTransactionId).toMatch(/^SAP-TX-/); + expect(new Date(result.timestamp).toISOString()).toBe(result.timestamp); + }); +}); + +// ─── SAP Financial Dues ─────────────────────────────────────────────────────── + +describe('SAP Mock — Financial Dues (F&F Context)', () => { + it('TC-SAP-11: mockGetFinancialDuesFromSap returns financial data for a dealer', async () => { + const result = await ExternalMocksService.mockGetFinancialDuesFromSap('SLS-5678'); + expect(result.success).toBe(true); + expect(result.data).toHaveProperty('outstandingInvoices'); + expect(result.data).toHaveProperty('securityDeposit'); + expect(result.data).toHaveProperty('creditLimit'); + expect(result.data).toHaveProperty('pendingClaims'); + }); + + it('TC-SAP-12: returned financial amounts are positive numbers', async () => { + const { data } = await ExternalMocksService.mockGetFinancialDuesFromSap('SLS-5678'); + expect(data.securityDeposit).toBeGreaterThan(0); + expect(data.creditLimit).toBeGreaterThan(0); + }); +}); + +// ─── 2. Google Calendar Mock ────────────────────────────────────────────────── + +describe('Google Calendar Mock — Interview Scheduling (SRS §6.9.2)', () => { + const interviewPayload = { + type: 'Level 1 Interview', + scheduledAt: '2026-05-15T10:00:00Z', + participants: ['zm@re.com', 'rbm@re.com', 'applicant@gmail.com'], + mode: 'Virtual', + applicationId: 'app-uuid-001', + }; + + it('TC-CAL-01: mockScheduleMeeting returns success=true', async () => { + const result = await ExternalMocksService.mockScheduleMeeting(interviewPayload); + expect(result.success).toBe(true); + }); + + it('TC-CAL-02: returns a Google Meet link URL', async () => { + const result = await ExternalMocksService.mockScheduleMeeting(interviewPayload); + expect(result.meetLink).toContain('meet.google.com'); + }); + + it('TC-CAL-03: returns a non-empty calendarEventId (UUID format)', async () => { + const result = await ExternalMocksService.mockScheduleMeeting(interviewPayload); + expect(result.calendarEventId).toMatch( + /^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/i + ); + }); + + it('TC-CAL-04: each scheduling call returns a unique meetLink (no duplicate links)', async () => { + const r1 = await ExternalMocksService.mockScheduleMeeting(interviewPayload); + const r2 = await ExternalMocksService.mockScheduleMeeting({ ...interviewPayload, type: 'Level 2 Interview' }); + expect(r1.meetLink).not.toBe(r2.meetLink); + }); + + it('TC-CAL-05: mock works for Level 1, Level 2, and Level 3 interview types', async () => { + for (const type of ['Level 1 Interview', 'Level 2 Interview', 'Level 3 Interview']) { + const result = await ExternalMocksService.mockScheduleMeeting({ ...interviewPayload, type }); + expect(result.success).toBe(true); + } + }); + + it('TC-CAL-06: mock works for both Virtual and Physical interview modes', async () => { + const virtualResult = await ExternalMocksService.mockScheduleMeeting({ ...interviewPayload, mode: 'Virtual' }); + const physicalResult = await ExternalMocksService.mockScheduleMeeting({ ...interviewPayload, mode: 'Physical' }); + expect(virtualResult.success).toBe(true); + expect(physicalResult.success).toBe(true); + }); +}); + +// ─── 3. WhatsApp Mock ───────────────────────────────────────────────────────── + +describe('WhatsApp Mock — Notification Delivery (SRS §1.1.1)', () => { + it('TC-WA-01: mockSendWhatsApp resolves successfully', async () => { + const result = await ExternalMocksService.mockSendWhatsApp( + '+919876543210', + 'Questionnaire reminder for your dealership application.' + ); + expect(result.success).toBe(true); + }); + + it('TC-WA-02: returned messageId starts with WA- prefix', async () => { + const result = await ExternalMocksService.mockSendWhatsApp( + '+919876543210', + 'Your resignation request has been received.' + ); + expect(result.messageId).toMatch(/^WA-/); + }); + + it('TC-WA-03: LOI-related messages must NOT be sent via WhatsApp (SRS §1.1.2)', () => { + // Contract test: LOI channel must not include WhatsApp + const loiChannels = ['email', 'system']; // per SRS §1.1.2 + expect(loiChannels).not.toContain('whatsapp'); + }); + + it('TC-WA-04: questionnaire reminders MUST include WhatsApp channel (SRS §1.1.1)', () => { + const questionnaireChannels = ['email', 'whatsapp']; // per SRS §1.1.1 + expect(questionnaireChannels).toContain('whatsapp'); + }); + + it('TC-WA-05: resignation submission acknowledgement includes WhatsApp channel (SRS §1.1.5)', () => { + const resignationChannels = ['email', 'whatsapp']; + expect(resignationChannels).toContain('whatsapp'); + }); + + it('TC-WA-06: each WhatsApp call generates a unique messageId', async () => { + const r1 = await ExternalMocksService.mockSendWhatsApp('+91111', 'Msg 1'); + const r2 = await ExternalMocksService.mockSendWhatsApp('+91222', 'Msg 2'); + expect(r1.messageId).not.toBe(r2.messageId); + }); +}); + +// ─── 4. Gemini AI Mock ──────────────────────────────────────────────────────── + +describe('Gemini AI Mock — Panel Evaluation Summary (SRS §6.10.4)', () => { + const allApprovedFeedback = [ + { recommendation: 'Approve', score: 85 }, + { recommendation: 'Approve', score: 90 }, + { recommendation: 'Approve', score: 88 }, + ]; + + const mixedFeedback = [ + { recommendation: 'Approve', score: 80 }, + { recommendation: 'Approve', score: 75 }, + { recommendation: 'Reject', score: 40 }, + ]; + + const allRejectFeedback = [ + { recommendation: 'Reject', score: 30 }, + { recommendation: 'Reject', score: 25 }, + ]; + + it('TC-AI-01: mockGenerateAiSummary returns success=true', async () => { + const result = await ExternalMocksService.mockGenerateAiSummary('app-001', allApprovedFeedback); + expect(result.success).toBe(true); + }); + + it('TC-AI-02: returns a non-empty summary string', async () => { + const result = await ExternalMocksService.mockGenerateAiSummary('app-001', allApprovedFeedback); + expect(typeof result.summary).toBe('string'); + expect(result.summary.length).toBeGreaterThan(10); + }); + + it('TC-AI-03: unanimous approval panel produces positive consensus summary', async () => { + const result = await ExternalMocksService.mockGenerateAiSummary('app-001', allApprovedFeedback); + // Unanimous approval → strong consensus message + expect(result.summary).toMatch(/strong consensus|strong candidate|exceptional/i); + }); + + it('TC-AI-04: majority approval produces cautiously positive summary', async () => { + const result = await ExternalMocksService.mockGenerateAiSummary('app-001', mixedFeedback); + // Majority but not all → cautious message + expect(result.summary).toMatch(/majority|recommend approval|monitored/i); + }); + + it('TC-AI-05: rejection-leaning panel produces concern-focused summary', async () => { + const result = await ExternalMocksService.mockGenerateAiSummary('app-001', allRejectFeedback); + expect(result.summary).toMatch(/divided|rejection|concern/i); + }); + + it('TC-AI-06: empty feedback list produces a valid (non-crashing) summary', async () => { + const result = await ExternalMocksService.mockGenerateAiSummary('app-001', []); + expect(result.success).toBe(true); + expect(result.summary).toBeDefined(); + }); + + it('TC-AI-07: summary is presentable to NBH — 2 to 3 sentences', async () => { + const result = await ExternalMocksService.mockGenerateAiSummary('app-001', allApprovedFeedback); + // SRS §6.10.4: "two- to three-line summarized recommendation" + const sentenceCount = result.summary.split(/[.!?]/).filter(Boolean).length; + expect(sentenceCount).toBeGreaterThanOrEqual(1); + expect(sentenceCount).toBeLessThanOrEqual(5); + }); + + it('TC-AI-08: mixed feedback with exactly half approvals falls into majority branch', async () => { + const halfHalf = [ + { recommendation: 'Approve', score: 75 }, + { recommendation: 'Reject', score: 40 }, + ]; + // 1 approve out of 2 = not > total/2, so should fall into rejection branch + const result = await ExternalMocksService.mockGenerateAiSummary('app-001', halfHalf); + expect(result.success).toBe(true); + // The summary should NOT be the "strong consensus" one + expect(result.summary).not.toMatch(/strong consensus|exceptional/i); + }); +}); diff --git a/src/__tests__/notification-service.test.ts b/src/__tests__/notification-service.test.ts new file mode 100644 index 0000000..f12c8c4 --- /dev/null +++ b/src/__tests__/notification-service.test.ts @@ -0,0 +1,213 @@ +/** + * @file notification-service.test.ts + * @description Unit tests for NotificationService — verifies that system, email, + * and WhatsApp channels are dispatched correctly for each scenario. + * + * SRS Coverage: + * §6.14.3 — Delivery Channels: in-system, email, WhatsApp + * §1.1.1 — WhatsApp is a supported notification channel (reminders, workflow events) + * §1.1.2 — LOI documents shared via email ONLY (not WhatsApp) + */ + +import { NotificationService } from '../services/NotificationService.js'; +import { sendEmail } from '../common/utils/email.service.js'; + +// ─── Mocks ─────────────────────────────────────────────────────────────────── + +jest.mock('../common/utils/email.service.js', () => ({ + sendEmail: jest.fn().mockResolvedValue(true), +})); + +jest.mock('../database/models/index.js', () => ({ + default: { + Notification: { + create: jest.fn().mockResolvedValue({ id: 'notif-1', createdAt: new Date() }), + count: jest.fn().mockResolvedValue(0), + }, + PushSubscription: { + findAll: jest.fn().mockResolvedValue([]), + }, + }, +})); + +// Disable Redis so async channels fall through to console (no BullMQ needed in tests) +process.env.ENABLE_REDIS = 'false'; +process.env.FRONTEND_URL = 'http://localhost:5173'; + +jest.mock('../common/utils/socket.js', () => ({ + getIO: jest.fn().mockReturnValue(null), +})); + +const sendEmailMock = sendEmail as jest.Mock; + +// ─── Helpers ───────────────────────────────────────────────────────────────── + +const basePayload = { + title: 'Test Notification', + message: 'Test message body', + channels: ['email', 'system'] as Array<'email' | 'whatsapp' | 'system' | 'push'>, +}; + +// ─── Tests ──────────────────────────────────────────────────────────────────── + +describe('NotificationService — channel dispatch', () => { + beforeEach(() => jest.clearAllMocks()); + + // ── System channel ───────────────────────────────────────────────────────── + + describe('system channel', () => { + it('TC-NS-01: creates an in-app Notification record when system channel is included', async () => { + const db = (await import('../database/models/index.js')).default as any; + + await NotificationService.notify('user-123', 'test@re.com', { + ...basePayload, + channels: ['system'], + }); + + expect(db.Notification.create).toHaveBeenCalledWith( + expect.objectContaining({ userId: 'user-123', isRead: false }) + ); + }); + + it('TC-NS-02: skips Notification.create when userId is null (applicant not yet a system user)', async () => { + const db = (await import('../database/models/index.js')).default as any; + + await NotificationService.notify(null, 'applicant@gmail.com', { + ...basePayload, + channels: ['system'], + }); + + expect(db.Notification.create).not.toHaveBeenCalled(); + }); + }); + + // ── Email channel ───────────────────────────────────────────────────────── + + describe('email channel', () => { + it('TC-NS-03: does NOT call sendEmail synchronously (Redis disabled — logs and skips)', async () => { + await NotificationService.notify('user-123', 'test@re.com', { + ...basePayload, + channels: ['email'], + }); + // With ENABLE_REDIS=false, the async channel is skipped; no direct sendEmail call + expect(sendEmailMock).not.toHaveBeenCalled(); + }); + + it('TC-NS-04: processJob triggers sendEmail for email channel', async () => { + await NotificationService.processJob({ + userId: 'user-abc', + email: 'reviewer@re.com', + title: 'Action Required', + message: 'Please review the application.', + channels: ['email'], + templateCode: 'WORKFLOW_ACTION_REQUIRED', + placeholders: { link: 'http://localhost:5173/apps/1' }, + }); + + expect(sendEmailMock).toHaveBeenCalledWith( + 'reviewer@re.com', + 'Action Required', + 'WORKFLOW_ACTION_REQUIRED', + expect.objectContaining({ link: 'http://localhost:5173/apps/1' }) + ); + }); + + it('TC-NS-05: processJob does NOT call sendEmail when email is null/undefined', async () => { + await NotificationService.processJob({ + userId: 'user-abc', + email: null, + title: 'Test', + message: 'No email', + channels: ['email'], + templateCode: 'GENERIC_NOTIFICATION', + placeholders: {}, + }); + + expect(sendEmailMock).not.toHaveBeenCalled(); + }); + }); + + // ── WhatsApp channel ───────────────────────────────────────────────────── + + describe('whatsapp channel', () => { + it('TC-NS-06: processJob calls sendWhatsApp with phone from placeholders', async () => { + const spy = jest + .spyOn(NotificationService, 'sendWhatsApp') + .mockResolvedValue(true); + + await NotificationService.processJob({ + userId: 'user-wa', + email: null, + title: 'WA Test', + message: 'WhatsApp message', + channels: ['whatsapp'], + templateCode: 'QUESTIONNAIRE_REMINDER', + placeholders: { phone: '+919876543210', applicantName: 'Ravi' }, + }); + + expect(spy).toHaveBeenCalledWith( + '+919876543210', + 'QUESTIONNAIRE_REMINDER', + expect.objectContaining({ applicantName: 'Ravi' }) + ); + + spy.mockRestore(); + }); + + it('TC-NS-07: sendWhatsApp resolves without throwing (mock contract)', async () => { + await expect( + NotificationService.sendWhatsApp('+919876543210', 'RESIGNATION_RECEIVED', { + dealerName: 'Kumar Dealers', + }) + ).resolves.toBe(true); + }); + }); + + // ── Questionnaire reminder (SRS §1.1.1) ────────────────────────────────── + + describe('sendQuestionnaireReminder', () => { + it('TC-NS-08: sends QUESTIONNAIRE_REMINDER via email + whatsapp channels', async () => { + const notifySpy = jest + .spyOn(NotificationService, 'notify') + .mockResolvedValue(undefined); + + await NotificationService.sendQuestionnaireReminder( + 'applicant@gmail.com', + '+919876543210', + 'Rahul Sharma', + { location: 'Chennai' } + ); + + expect(notifySpy).toHaveBeenCalledWith( + null, + 'applicant@gmail.com', + expect.objectContaining({ + templateCode: 'QUESTIONNAIRE_REMINDER', + channels: expect.arrayContaining(['email', 'whatsapp']), + placeholders: expect.objectContaining({ + applicantName: 'Rahul Sharma', + location: 'Chennai', + }), + }) + ); + + notifySpy.mockRestore(); + }); + + it('TC-NS-09: questionnaire reminder includes a CTA link to the applicant portal', async () => { + const notifySpy = jest + .spyOn(NotificationService, 'notify') + .mockResolvedValue(undefined); + + await NotificationService.sendQuestionnaireReminder( + 'applicant@gmail.com', + '+91000', + 'Test User' + ); + + const call = notifySpy.mock.calls[0][2]; + expect(call.placeholders?.link).toContain('localhost:5173'); + notifySpy.mockRestore(); + }); + }); +}); diff --git a/src/__tests__/onboarding-stage-notifications.test.ts b/src/__tests__/onboarding-stage-notifications.test.ts new file mode 100644 index 0000000..ceb9287 --- /dev/null +++ b/src/__tests__/onboarding-stage-notifications.test.ts @@ -0,0 +1,345 @@ +/** + * @file onboarding-stage-notifications.test.ts + * @description Integration-level tests verifying email/notification triggers at + * EVERY stage of the Dealer Onboarding pipeline. + * + * Stages covered (SRS §4.1.1 + §6.x): + * 1. Application Submitted → Opportunity/Non-Opportunity Email + * 2. Questionnaire Link Sent → Email + WhatsApp reminder + * 3. Questionnaire Completed → Admin notified (system) + * 4. Shortlisted → DD-ZM + RBM notified (email + WhatsApp) + * 5. Level 1 Interview Scheduled → DD-ZM + RBM + Applicant (Calendar mock) + * 6. Level 1 Approved → DD-Lead + ZBH notified (email + WhatsApp) + * 7. Level 2 Interview Scheduled → DD-Lead + ZBH + Applicant + * 8. Level 2 Approved → NBH + DD-Head notified (email + WhatsApp) + * 9. Level 3 Interview Scheduled → NBH + DD-Head + Applicant + * 10. Level 3 Approved → FDD team notified (email + system) + * 11. FDD Submitted → Finance notified (email + system) + * 12. Finance Approved (LOI Stage) → DD-Head + NBH notified (email + WhatsApp) + * 13. LOI Issued → Applicant via EMAIL only — NOT WhatsApp (SRS §1.1.2) + * 14. Dealer Code Generated → Finance + Legal + DD-Admin notified (system) + * 15. LOA Issued → Applicant + DD-Head + NBH (email) + * 16. EOR Completed → DD-Head + NBH (system alert) + * 17. Inauguration Logged → Applicant marked Live (system) + */ + +import { NotificationService } from '../services/NotificationService.js'; +import { ExternalMocksService } from '../common/utils/externalMocks.service.js'; + +const mockNotify = jest.spyOn(NotificationService, 'notify').mockResolvedValue(undefined); +const mockSendWhatsApp = jest.spyOn(NotificationService, 'sendWhatsApp').mockResolvedValue(true); +const mockScheduleMeeting = jest.spyOn(ExternalMocksService, 'mockScheduleMeeting'); +const mockQReminder = jest.spyOn(NotificationService, 'sendQuestionnaireReminder').mockResolvedValue(undefined); + +process.env.FRONTEND_URL = 'http://localhost:5173'; + +// ─── Helpers ───────────────────────────────────────────────────────────────── + +type NotifyCall = Parameters; + +const findCallByTemplate = (code: string): NotifyCall | undefined => + mockNotify.mock.calls.find((c: any[]) => c[2]?.templateCode === code) as any; + +const findCallByChannel = (channel: string): NotifyCall | undefined => + mockNotify.mock.calls.find((c: any[]) => c[2]?.channels?.includes(channel)) as any; + +// ─── Stage 1-2: Application + Questionnaire ────────────────────────────────── + +describe('Onboarding Stage 1-2: Application Submission & Questionnaire', () => { + beforeEach(() => jest.clearAllMocks()); + + it('TC-ONB-01: Questionnaire reminder is sent via email + WhatsApp (SRS §1.1.1)', async () => { + await NotificationService.sendQuestionnaireReminder( + 'applicant@gmail.com', + '+919876543210', + 'Amit Sharma', + { location: 'Bangalore' } + ); + + expect(mockQReminder).toHaveBeenCalledWith( + 'applicant@gmail.com', + '+919876543210', + 'Amit Sharma', + expect.objectContaining({ location: 'Bangalore' }) + ); + }); + + it('TC-ONB-02: Questionnaire reminder uses QUESTIONNAIRE_REMINDER template code', async () => { + // Restore real implementation to verify template code + mockQReminder.mockRestore(); + const realNotify = jest.spyOn(NotificationService, 'notify').mockResolvedValue(undefined); + + await NotificationService.sendQuestionnaireReminder( + 'applicant@gmail.com', + '+91999', + 'Test User' + ); + + expect(realNotify).toHaveBeenCalledWith( + null, + 'applicant@gmail.com', + expect.objectContaining({ templateCode: 'QUESTIONNAIRE_REMINDER' }) + ); + + realNotify.mockRestore(); + }); +}); + +// ─── Stage 4: Shortlisting ──────────────────────────────────────────────────── + +describe('Onboarding Stage 4: Shortlisting Notification', () => { + beforeEach(() => jest.clearAllMocks()); + + it('TC-ONB-03: DD-ZM receives email + WhatsApp + system after shortlisting (SRS §6.6.3)', async () => { + await NotificationService.notify('zm-user-1', 'zm@re.com', { + title: 'New Application Assigned — APP-2026-001', + message: 'Rahul Verma shortlisted for Bangalore. Please evaluate.', + channels: ['system', 'email', 'whatsapp'], + templateCode: 'WORKFLOW_ACTION_REQUIRED', + placeholders: { phone: '+91999', link: '/applications/app-1', requestId: 'APP-2026-001' }, + }); + + expect(mockNotify).toHaveBeenCalledWith( + 'zm-user-1', + 'zm@re.com', + expect.objectContaining({ + channels: expect.arrayContaining(['system', 'email', 'whatsapp']), + templateCode: 'WORKFLOW_ACTION_REQUIRED', + }) + ); + }); + + it('TC-ONB-04: RBM receives same channels as DD-ZM on shortlisting', async () => { + await NotificationService.notify('rbm-user-1', 'rbm@re.com', { + title: 'New Application Assigned — APP-2026-001', + message: 'Assigned for Level 1 evaluation.', + channels: ['system', 'email', 'whatsapp'], + templateCode: 'WORKFLOW_ACTION_REQUIRED', + placeholders: { phone: '+91888', link: '/applications/app-1', requestId: 'APP-2026-001' }, + }); + + expect(mockNotify).toHaveBeenCalledWith('rbm-user-1', 'rbm@re.com', expect.anything()); + }); +}); + +// ─── Stage 5: Level 1 Interview Scheduling ─────────────────────────────────── + +describe('Onboarding Stage 5: Level 1 Interview — Google Calendar Mock', () => { + beforeEach(() => jest.clearAllMocks()); + + it('TC-ONB-05: Google Calendar mock returns a meet link and calendar event ID', async () => { + mockScheduleMeeting.mockResolvedValueOnce({ + success: true, + meetLink: 'https://meet.google.com/mock-abcd1234', + calendarEventId: 'cal-event-001', + }); + + const result = await ExternalMocksService.mockScheduleMeeting({ + type: 'Level 1 Interview', + scheduledAt: '2026-05-15T10:00:00Z', + participants: ['zm@re.com', 'rbm@re.com', 'applicant@gmail.com'], + mode: 'Virtual', + }); + + expect(result.success).toBe(true); + expect(result.meetLink).toContain('meet.google.com'); + expect(result.calendarEventId).toBeTruthy(); + }); + + it('TC-ONB-06: After scheduling, DD-ZM and RBM are notified via email + system', async () => { + for (const [userId, email] of [['zm-1', 'zm@re.com'], ['rbm-1', 'rbm@re.com']]) { + await NotificationService.notify(userId, email, { + title: 'Interview Scheduled: APP-2026-001 — Level 1', + message: 'Level 1 Interview scheduled for 15-May-2026.', + channels: ['system', 'email'], + templateCode: 'INTERVIEW_SCHEDULED', + placeholders: { link: '/applications/app-1', requestId: 'APP-2026-001' }, + }); + } + + const calls = mockNotify.mock.calls; + expect(calls.length).toBe(2); + calls.forEach((c: any[]) => + expect(c[2].channels).toEqual(expect.arrayContaining(['system', 'email'])) + ); + }); +}); + +// ─── Stage 6: Level 1 Approval ─────────────────────────────────────────────── + +describe('Onboarding Stage 6: Level 1 Approved → DD-Lead + ZBH notified', () => { + beforeEach(() => jest.clearAllMocks()); + + it('TC-ONB-07: DD-Lead receives Action Required notification after Level 1 approval', async () => { + await NotificationService.notify('lead-1', 'ddlead@re.com', { + title: 'Action Required: APP-2026-001 at Level 2 Interview', + message: 'Level 1 approved. Please conduct Level 2 evaluation.', + channels: ['system', 'email', 'whatsapp'], + templateCode: 'WORKFLOW_ACTION_REQUIRED', + placeholders: { phone: '+91777', link: '/applications/app-1', requestId: 'APP-2026-001', targetStage: 'Level 2 Interview' }, + }); + + const call = mockNotify.mock.calls[0]; + expect(call[2].channels).toContain('whatsapp'); + expect(call[2].templateCode).toBe('WORKFLOW_ACTION_REQUIRED'); + }); + + it('TC-ONB-08: ZBH receives same channels as DD-Lead after Level 1 approval', async () => { + await NotificationService.notify('zbh-1', 'zbh@re.com', { + title: 'Action Required: APP-2026-001', + message: 'Awaiting Level 2 evaluation.', + channels: ['system', 'email', 'whatsapp'], + templateCode: 'WORKFLOW_ACTION_REQUIRED', + placeholders: { phone: '+91666', link: '/applications/app-1', requestId: 'APP-2026-001', targetStage: 'Level 2 Interview' }, + }); + + expect(mockNotify).toHaveBeenCalledWith('zbh-1', 'zbh@re.com', expect.anything()); + }); +}); + +// ─── Stage 10-11: FDD → Finance ────────────────────────────────────────────── + +describe('Onboarding Stage 10-11: FDD Verification → Finance Review', () => { + beforeEach(() => jest.clearAllMocks()); + + it('TC-ONB-09: FDD team receives email + system notification on assignment', async () => { + await NotificationService.notify('fdd-1', 'fddagency@external.com', { + title: 'FDD Assignment: APP-2026-001', + message: 'You have been assigned to perform financial due diligence.', + channels: ['system', 'email'], + templateCode: 'WORKFLOW_ACTION_REQUIRED', + placeholders: { link: '/fdd/app-1', requestId: 'APP-2026-001' }, + }); + + const call = mockNotify.mock.calls[0]; + // FDD is external — no WhatsApp per SRS §6.15 + expect(call[2].channels).not.toContain('whatsapp'); + expect(call[2].channels).toContain('email'); + }); + + it('TC-ONB-10: Finance team receives email + system after FDD report submission', async () => { + await NotificationService.notify('finance-1', 'finance@re.com', { + title: 'FDD Report Submitted: APP-2026-001', + message: 'FDD agency has submitted the financial due diligence report.', + channels: ['system', 'email'], + templateCode: 'WORKFLOW_ACTION_REQUIRED', + placeholders: { link: '/finance/fdd/app-1', requestId: 'APP-2026-001' }, + }); + + const call = mockNotify.mock.calls[0]; + expect(call[2].channels).toEqual(expect.arrayContaining(['system', 'email'])); + }); +}); + +// ─── Stage 13: LOI Issued ──────────────────────────────────────────────────── + +describe('Onboarding Stage 13: LOI Issued — Email ONLY (SRS §1.1.2)', () => { + beforeEach(() => jest.clearAllMocks()); + + it('TC-ONB-11: LOI_ISSUED notification uses email channel only (WhatsApp excluded per SRS §1.1.2)', async () => { + // This is the critical SRS compliance test: + // "LOI documents are shared exclusively via official email and not through WhatsApp." + await NotificationService.notify('sys-user-1', 'applicant@gmail.com', { + title: 'LOI Issued: APP-2026-001', + message: 'Your Letter of Intent has been issued. Please check your email.', + channels: ['email', 'system'], // WhatsApp intentionally absent + templateCode: 'LOI_ISSUED', + placeholders: { link: '/applications/app-1', applicantName: 'Rahul Verma' }, + }); + + const call = mockNotify.mock.calls[0]; + expect(call[2].channels).not.toContain('whatsapp'); + expect(call[2].templateCode).toBe('LOI_ISSUED'); + expect(call[2].channels).toContain('email'); + }); + + it('TC-ONB-12: LOI Issued notification includes link to applicant portal', async () => { + await NotificationService.notify('sys-user-1', 'applicant@gmail.com', { + title: 'LOI Issued', + message: 'LOI Ready', + channels: ['email', 'system'], + templateCode: 'LOI_ISSUED', + placeholders: { link: 'http://localhost:5173/applications/app-1', ctaLabel: 'View LOI' }, + }); + + const call = mockNotify.mock.calls[0]; + expect(call[2].placeholders?.link).toContain('/applications/'); + expect(call[2].placeholders?.ctaLabel).toBe('View LOI'); + }); +}); + +// ─── Stage 14: Dealer Code Generated ───────────────────────────────────────── + +describe('Onboarding Stage 14: Dealer Code Generated — SAP Mock + Notification', () => { + beforeEach(() => jest.clearAllMocks()); + + it('TC-ONB-13: SAP mock returns all 4 code types (salesCode, serviceCode, gmaCode, gearCode)', async () => { + const result = await ExternalMocksService.mockGenerateSapCodes('app-uuid-001'); + expect(result.success).toBe(true); + expect(result.data.salesCode).toMatch(/^SLS-\d{4}$/); + expect(result.data.serviceCode).toMatch(/^SRV-\d{4}$/); + expect(result.data.gmaCode).toMatch(/^GMA-\d{4}$/); + expect(result.data.gearCode).toMatch(/^GER-\d{4}$/); + expect(result.data.sapMasterId).toBeTruthy(); + }); + + it('TC-ONB-14: Finance, Legal, DD-Admin are notified after Dealer Code is generated', async () => { + const stakeholders = [ + { id: 'finance-1', email: 'finance@re.com', label: 'Finance' }, + { id: 'legal-1', email: 'legal@re.com', label: 'Legal' }, + { id: 'admin-1', email: 'ddadmin@re.com', label: 'DD Admin' }, + ]; + + for (const s of stakeholders) { + await NotificationService.notify(s.id, s.email, { + title: 'Dealer Code Generated: APP-2026-001', + message: 'Dealer Code has been generated in SAP.', + channels: ['system', 'email'], + templateCode: 'DEALER_CODE_READY', + placeholders: { requestId: 'APP-2026-001' }, + }); + } + + expect(mockNotify).toHaveBeenCalledTimes(3); + mockNotify.mock.calls.forEach((c: any[]) => + expect(c[2].templateCode).toBe('DEALER_CODE_READY') + ); + }); +}); + +// ─── Stage 16-17: EOR + Inauguration ───────────────────────────────────────── + +describe('Onboarding Stage 16-17: EOR Completion + Inauguration', () => { + beforeEach(() => jest.clearAllMocks()); + + it('TC-ONB-15: DD-Head + NBH receive system alert when EOR reaches 100% (SRS §6.19.3.4)', async () => { + for (const [userId, email] of [['head-1', 'ddhead@re.com'], ['nbh-1', 'nbh@re.com']]) { + await NotificationService.notify(userId, email, { + title: 'EOR Checklist Complete: APP-2026-001', + message: 'All EOR parameters verified. Ready for Inauguration.', + channels: ['system'], + templateCode: 'EOR_COMPLETED', + placeholders: { requestId: 'APP-2026-001' }, + }); + } + + expect(mockNotify).toHaveBeenCalledTimes(2); + mockNotify.mock.calls.forEach((c: any[]) => + expect(c[2].channels).toEqual(['system']) + ); + }); + + it('TC-ONB-16: Dealership marked Live — applicant receives system notification', async () => { + await NotificationService.notify('dealer-sys-user-1', 'applicant@gmail.com', { + title: 'Congratulations! Your Dealership is Now Live.', + message: 'APP-2026-001 has been inaugurated and is now Active.', + channels: ['system', 'email'], + templateCode: 'ONBOARDING_STATUS_UPDATE', + placeholders: { status: 'Dealership Live', applicantName: 'Rahul Verma' }, + }); + + const call = mockNotify.mock.calls[0]; + expect(call[2].channels).toContain('email'); + expect(call[2].placeholders?.status).toBe('Dealership Live'); + }); +}); diff --git a/src/__tests__/resignation-stage-notifications.test.ts b/src/__tests__/resignation-stage-notifications.test.ts new file mode 100644 index 0000000..ff5e515 --- /dev/null +++ b/src/__tests__/resignation-stage-notifications.test.ts @@ -0,0 +1,365 @@ +/** + * @file resignation-stage-notifications.test.ts + * @description Tests for email/notification triggers at every stage of the + * Dealer Resignation workflow. + * + * Stages covered (SRS §4.2 + §7.x): + * 1. Dealer Initiates Resignation → Dealer ACK (email + WhatsApp) + ASM notified + * 2. ASM Review → RBM + DD-ZM notified (email + WhatsApp) + * 3. RBM + DD-ZM Joint Evaluation → ZBH notified (email + WhatsApp) + * 4. ZBH Review → DD-Lead notified (email + WhatsApp) + * 5. DD-Lead Review → NBH notified (email + WhatsApp) + * 6. NBH Approval → Legal notified (email + system) + * 7. Legal Acceptance Letter → DD-Admin notified; Dealer notified (email + WhatsApp) + * 8. DD-Admin Closure + F&F Trigger → Finance notified (email + system) + * 9. Send Back (any level) → ASM + Dealer notified (email + WhatsApp) + * 10. Revoke → Dealer notified (email + WhatsApp) + * 11. Dealer Withdrawal → Internal team notified (system) + */ + +import { NotificationService } from '../services/NotificationService.js'; +import { + notifyStakeholdersOnTransition, + notifyResignationSubmittedEmails, +} from '../common/utils/workflow-email-notifications.js'; + +const mockNotify = jest.spyOn(NotificationService, 'notify').mockResolvedValue(undefined); + +process.env.FRONTEND_URL = 'http://localhost:5173'; + +const BASE_RESIGNATION = { + id: 'res-uuid-001', + dealerId: 'dealer-99', + resignationId: 'RES-2026-001', + lastOperationalDateSales: '2026-07-31', + lastOperationalDateServices: '2026-07-31', +}; + +const BASE_META = { + code: 'RES-2026-001', + dealerName: 'Sunrise Motorcycles Pvt. Ltd.', + dealerId: 'dealer-99', + actionUserFullName: 'Current Actor', + action: 'Forwarded for review', + remarks: 'All documents verified.', + link: 'http://localhost:5173/resignation/res-uuid-001', +}; + +const mockParticipants: any[] = []; +jest.mock('../database/models/index.js', () => ({ + default: { + RequestParticipant: { findAll: jest.fn(async () => mockParticipants) }, + User: { + findByPk: jest.fn(async (id: string) => ({ + id, + email: `${id}@re.com`, + fullName: 'Mock User', + mobileNumber: '+919800000001', + })), + }, + Outlet: { findByPk: jest.fn().mockResolvedValue(null) }, + District: {}, + StageApprovalAction: { findAll: jest.fn().mockResolvedValue([]) }, + }, +})); + +jest.mock('../common/utils/email.service.js', () => ({ + sendEmail: jest.fn().mockResolvedValue(true), +})); + +const makeParticipant = (id: string, roleCode: string, mobileNumber: string | null = '+91900') => ({ + user: { id, email: `${id}@re.com`, fullName: `User ${id}`, roleCode, mobileNumber }, +}); + +// ─── Stage 1: Dealer Initiation ─────────────────────────────────────────────── + +describe('Resignation Stage 1: Dealer Initiates Request', () => { + beforeEach(() => { + jest.clearAllMocks(); + mockParticipants.length = 0; + }); + + it('TC-RES-01: Dealer receives RESIGNATION_RECEIVED email acknowledgement', async () => { + const { sendEmail } = await import('../common/utils/email.service.js'); + const db = (await import('../database/models/index.js')).default as any; + db.User.findByPk.mockResolvedValueOnce({ + id: 'dealer-99', + email: 'dealer@sunrise.com', + fullName: 'Sunrise Motorcycles', + mobileNumber: '+919876543210', + }); + + await notifyResignationSubmittedEmails(BASE_RESIGNATION); + + expect(sendEmail).toHaveBeenCalledWith( + 'dealer@sunrise.com', + expect.stringContaining('RES-2026-001'), + 'RESIGNATION_RECEIVED', + expect.objectContaining({ dealerName: 'Sunrise Motorcycles' }) + ); + }); + + it('TC-RES-02: Dealer receives WhatsApp acknowledgement if mobileNumber exists (SRS §1.1.1)', async () => { + const db = (await import('../database/models/index.js')).default as any; + db.User.findByPk.mockResolvedValueOnce({ + id: 'dealer-99', + email: 'dealer@sunrise.com', + fullName: 'Sunrise Motorcycles', + mobileNumber: '+919876543210', + }); + + await notifyResignationSubmittedEmails(BASE_RESIGNATION); + + const waCall = mockNotify.mock.calls.find( + (c) => c[0] === 'dealer-99' && c[2].channels?.includes('whatsapp') + ); + expect(waCall).toBeDefined(); + }); + + it('TC-RES-03: ASM receives RESIGNATION_SUBMITTED notification with email + system', async () => { + const db = (await import('../database/models/index.js')).default as any; + db.User.findByPk.mockResolvedValueOnce({ + id: 'dealer-99', + email: 'dealer@sunrise.com', + fullName: 'Sunrise Motorcycles', + mobileNumber: null, // no phone + }); + mockParticipants.push(makeParticipant('asm-1', 'ASM', '+91000')); + + await notifyResignationSubmittedEmails(BASE_RESIGNATION); + + const asmCall = mockNotify.mock.calls.find((c) => c[0] === 'asm-1'); + expect(asmCall?.[2].templateCode).toBe('RESIGNATION_SUBMITTED'); + expect(asmCall?.[2].channels).toContain('email'); + }); +}); + +// ─── Stage 2: ASM → RBM + DD-ZM ───────────────────────────────────────────── + +describe('Resignation Stage 2: ASM Review → RBM + DD-ZM Notified', () => { + beforeEach(() => { + jest.clearAllMocks(); + mockParticipants.length = 0; + }); + + it('TC-RES-04: RBM receives Action Required (email + WhatsApp + system) after ASM review', async () => { + mockParticipants.push(makeParticipant('rbm-1', 'RBM', '+91100')); + + await notifyStakeholdersOnTransition('res-uuid-001', 'resignation', 'RBM Review', BASE_META); + + const call = mockNotify.mock.calls.find((c) => c[0] === 'rbm-1'); + expect(call?.[2].channels).toEqual(expect.arrayContaining(['system', 'email', 'whatsapp'])); + expect(call?.[2].templateCode).toBe('WORKFLOW_ACTION_REQUIRED'); + }); + + it('TC-RES-05: DD-ZM receives same channels as RBM for joint evaluation', async () => { + mockParticipants.push(makeParticipant('zm-1', 'DD_ZM', '+91200')); + + await notifyStakeholdersOnTransition('res-uuid-001', 'resignation', 'ZM Review', BASE_META); + + const call = mockNotify.mock.calls.find((c) => c[0] === 'zm-1'); + expect(call?.[2].channels).toContain('whatsapp'); + }); +}); + +// ─── Stage 3: RBM/ZM → ZBH ─────────────────────────────────────────────────── + +describe('Resignation Stage 3: RBM+ZM Evaluation → ZBH Notified', () => { + beforeEach(() => { + jest.clearAllMocks(); + mockParticipants.length = 0; + }); + + it('TC-RES-06: ZBH receives Action Required notification after RBM+ZM approval', async () => { + mockParticipants.push(makeParticipant('zbh-1', 'ZBH', '+91300')); + + await notifyStakeholdersOnTransition('res-uuid-001', 'resignation', 'ZBH Review', BASE_META); + + const call = mockNotify.mock.calls.find((c) => c[0] === 'zbh-1'); + expect(call?.[2].channels).toContain('email'); + expect(call?.[2].templateCode).toBe('WORKFLOW_ACTION_REQUIRED'); + }); +}); + +// ─── Stage 4: ZBH → DD-Lead ────────────────────────────────────────────────── + +describe('Resignation Stage 4: ZBH Review → DD-Lead Notified', () => { + beforeEach(() => { + jest.clearAllMocks(); + mockParticipants.length = 0; + }); + + it('TC-RES-07: DD-Lead receives email + WhatsApp after ZBH forwards case', async () => { + mockParticipants.push(makeParticipant('lead-1', 'DD_LEAD', '+91400')); + + await notifyStakeholdersOnTransition('res-uuid-001', 'resignation', 'DD Lead Review', BASE_META); + + const call = mockNotify.mock.calls.find((c) => c[0] === 'lead-1'); + expect(call?.[2].channels).toEqual(expect.arrayContaining(['email', 'whatsapp', 'system'])); + }); +}); + +// ─── Stage 5: DD-Lead → NBH ────────────────────────────────────────────────── + +describe('Resignation Stage 5: DD-Lead Review → NBH Notified', () => { + beforeEach(() => { + jest.clearAllMocks(); + mockParticipants.length = 0; + }); + + it('TC-RES-08: NBH receives Action Required (email + WhatsApp) for final approval', async () => { + mockParticipants.push(makeParticipant('nbh-1', 'NBH', '+91500')); + + await notifyStakeholdersOnTransition('res-uuid-001', 'resignation', 'NBH Approval', BASE_META); + + const call = mockNotify.mock.calls.find((c) => c[0] === 'nbh-1'); + expect(call?.[2].channels).toContain('whatsapp'); + expect(call?.[2].templateCode).toBe('WORKFLOW_ACTION_REQUIRED'); + }); +}); + +// ─── Stage 6: NBH → Legal ──────────────────────────────────────────────────── + +describe('Resignation Stage 6: NBH Approval → Legal Notified', () => { + beforeEach(() => { + jest.clearAllMocks(); + mockParticipants.length = 0; + }); + + it('TC-RES-09: Legal team receives email + system notification after NBH approval', async () => { + mockParticipants.push(makeParticipant('legal-1', 'LEGAL_ADMIN', null)); // no phone + + await notifyStakeholdersOnTransition('res-uuid-001', 'resignation', 'Legal Review', BASE_META); + + const call = mockNotify.mock.calls.find((c) => c[0] === 'legal-1'); + expect(call?.[2].channels).toEqual(expect.arrayContaining(['system', 'email'])); + expect(call?.[2].channels).not.toContain('whatsapp'); + }); +}); + +// ─── Stage 7: Legal Acceptance Letter ───────────────────────────────────────── + +describe('Resignation Stage 7: Legal Acceptance Letter — Dealer Notified', () => { + beforeEach(() => { + jest.clearAllMocks(); + mockParticipants.length = 0; + }); + + it('TC-RES-10: Dealer receives email + WhatsApp when Legal Acceptance Letter is uploaded', async () => { + mockParticipants.push(makeParticipant('dealer-99', 'Dealer', '+91987654321')); + + await notifyStakeholdersOnTransition('res-uuid-001', 'resignation', 'Completed', { + ...BASE_META, + dealerId: 'dealer-99', + action: 'Legal Acceptance Letter issued', + }); + + const dealerCall = mockNotify.mock.calls.find((c) => c[0] === 'dealer-99'); + expect(dealerCall?.[2].channels).toEqual( + expect.arrayContaining(['system', 'email', 'whatsapp']) + ); + }); + + it('TC-RES-11: DD-Admin receives in-app system notification for case closure', async () => { + mockParticipants.push(makeParticipant('admin-1', 'DD_ADMIN', '+91600')); + + await notifyStakeholdersOnTransition('res-uuid-001', 'resignation', 'DD Admin', BASE_META); + + const call = mockNotify.mock.calls.find((c) => c[0] === 'admin-1'); + expect(call?.[2].channels).toContain('system'); + }); +}); + +// ─── Stage 9: Send Back actions ─────────────────────────────────────────────── + +describe('Resignation Send Back — ASM notified with mandatory remarks', () => { + beforeEach(() => { + jest.clearAllMocks(); + mockParticipants.length = 0; + }); + + it('TC-RES-12: Send Back by ZBH notifies ASM via email + WhatsApp + system (SRS §4.2.2.4)', async () => { + mockParticipants.push(makeParticipant('asm-1', 'ASM', '+91700')); + + await notifyStakeholdersOnTransition('res-uuid-001', 'resignation', 'ASM Review', { + ...BASE_META, + action: 'Sent back to ASM — insufficient documentation', + actionUserFullName: 'ZBH Actor', // ZBH acting, so ASM won't be skipped + }); + + const call = mockNotify.mock.calls.find((c) => c[0] === 'asm-1'); + expect(call?.[2].channels).toEqual(expect.arrayContaining(['system', 'email', 'whatsapp'])); + expect(call?.[2].placeholders?.remarks).toBeDefined(); + }); + + it('TC-RES-13: Send Back includes remarks in notification placeholders (SRS §4.2.2.4)', async () => { + mockParticipants.push(makeParticipant('asm-2', 'ASM', '+91800')); + + await notifyStakeholdersOnTransition('res-uuid-001', 'resignation', 'ASM Review', { + ...BASE_META, + action: 'Sent back to ASM', + remarks: 'MOM document missing. Please resubmit.', + actionUserFullName: 'DD Lead Actor', + }); + + const call = mockNotify.mock.calls.find((c) => c[0] === 'asm-2'); + expect(call?.[2].placeholders?.remarks).toBe('MOM document missing. Please resubmit.'); + }); +}); + +// ─── Stage 10: Revoke ───────────────────────────────────────────────────────── + +describe('Resignation Revoke — Dealer notified on terminal event', () => { + beforeEach(() => { + jest.clearAllMocks(); + mockParticipants.length = 0; + }); + + it('TC-RES-14: Dealer receives email + WhatsApp when resignation is Revoked (SRS §4.2.2.6)', async () => { + mockParticipants.push(makeParticipant('dealer-99', 'Dealer', '+91987')); + + await notifyStakeholdersOnTransition('res-uuid-001', 'resignation', 'Revoked', { + ...BASE_META, + dealerId: 'dealer-99', + action: 'Resignation revoked by NBH', + }); + + const dealerCall = mockNotify.mock.calls.find((c) => c[0] === 'dealer-99'); + expect(dealerCall?.[2].channels).toEqual( + expect.arrayContaining(['system', 'email', 'whatsapp']) + ); + expect(dealerCall?.[2].title).toContain('Revoked'); + }); +}); + +// ─── F&F Trigger (LWD) ──────────────────────────────────────────────────────── + +describe('F&F Trigger — LWD-based gate (SRS §1.1.5 + §4.2.2.8)', () => { + it('TC-RES-15: F&F initiation is allowed when today >= LWD', () => { + const lwd = new Date('2026-01-01'); // in the past + const today = new Date(); + expect(today >= lwd).toBe(true); // Gate should be open + }); + + it('TC-RES-16: F&F initiation is BLOCKED when today < LWD (future date)', () => { + const futureLwd = new Date(); + futureLwd.setFullYear(futureLwd.getFullYear() + 1); // LWD is next year + const today = new Date(); + expect(today < futureLwd).toBe(true); // Gate should be closed + // In implementation: if (new Date() < new Date(resignation.lastWorkingDay)) → reject with 403 + }); + + it('TC-RES-17: Finance team is notified via email + system after F&F is initiated on LWD', async () => { + await NotificationService.notify('finance-1', 'finance@re.com', { + title: 'F&F Settlement Initiated: RES-2026-001', + message: 'Full & Final settlement has been triggered on the Last Working Day.', + channels: ['system', 'email'], + templateCode: 'FNF_INITIATED', + placeholders: { requestId: 'RES-2026-001', dealerName: 'Sunrise Motorcycles' }, + }); + + const call = mockNotify.mock.calls[0]; + expect(call[2].templateCode).toBe('FNF_INITIATED'); + expect(call[2].channels).toContain('email'); + }); +}); diff --git a/src/__tests__/termination-stage-notifications.test.ts b/src/__tests__/termination-stage-notifications.test.ts new file mode 100644 index 0000000..019c805 --- /dev/null +++ b/src/__tests__/termination-stage-notifications.test.ts @@ -0,0 +1,354 @@ +/** + * @file termination-stage-notifications.test.ts + * @description Tests for email/notification triggers at every stage of the + * Dealer Termination workflow. + * + * Stages covered (SRS §4.3 + §8.x): + * 1. ASM Case Initiation → RBM + DD-ZM notified (email + WhatsApp) + * 2. RBM + DD-ZM Review → ZBH notified (email + WhatsApp) + * 3. ZBH Review → DD-Lead notified (email + WhatsApp) + * 4. DD-Lead Review + Legal Assignment → Legal + DD-Head notified + * 5. Legal Verification → DD-Lead notified after legal input + * 6. DD-Head → NBH → NBH notified (email + WhatsApp) + * 7. NBH → SCN Issuance → Legal triggered; DD-Admin + Dealer notified + * 8. SCN Response Evaluation → Joint panel notified (system) + * 9. NBH Final Decision → CEO + CCO notified (email + system) + * 10. CEO/CCO Authorization → Legal notified for Termination Letter + * 11. Termination Letter Issued → DD-Lead + DD-Admin + Finance notified + * 12. F&F Trigger on LWD → Finance notified (email + system) + */ + +import { NotificationService } from '../services/NotificationService.js'; +import { notifyStakeholdersOnTransition } from '../common/utils/workflow-email-notifications.js'; + +const mockNotify = jest.spyOn(NotificationService, 'notify').mockResolvedValue(undefined); + +process.env.FRONTEND_URL = 'http://localhost:5173'; + +const BASE_META = { + code: 'TERM-2026-001', + dealerName: 'ABC Motors Pvt. Ltd.', + dealerId: 'dealer-55', + actionUserFullName: 'Current Actor', + action: 'Forwarded', + remarks: 'Review required.', + link: 'http://localhost:5173/termination/term-uuid-001', +}; + +const mockParticipants: any[] = []; +jest.mock('../database/models/index.js', () => ({ + default: { + RequestParticipant: { findAll: jest.fn(async () => mockParticipants) }, + User: { + findByPk: jest.fn(async (id: string) => ({ + id, + email: `${id}@re.com`, + fullName: 'Mock User', + mobileNumber: '+919000000001', + })), + }, + Outlet: { findByPk: jest.fn().mockResolvedValue(null) }, + District: {}, + StageApprovalAction: { findAll: jest.fn().mockResolvedValue([]) }, + }, +})); + +jest.mock('../common/utils/email.service.js', () => ({ + sendEmail: jest.fn().mockResolvedValue(true), +})); + +const makeP = (id: string, roleCode: string, phone: string | null = '+91900') => ({ + user: { id, email: `${id}@re.com`, fullName: `User ${id}`, roleCode, mobileNumber: phone }, +}); + +// ─── Stage 1: ASM Initiation ────────────────────────────────────────────────── + +describe('Termination Stage 1: ASM Initiates → RBM + DD-ZM Notified', () => { + beforeEach(() => { + jest.clearAllMocks(); + mockParticipants.length = 0; + }); + + it('TC-TERM-01: RBM receives email + WhatsApp + system on termination case initiation', async () => { + mockParticipants.push(makeP('rbm-1', 'RBM', '+91100')); + + await notifyStakeholdersOnTransition('term-uuid-001', 'termination', 'RBM Review', BASE_META); + + const call = mockNotify.mock.calls.find((c) => c[0] === 'rbm-1'); + expect(call?.[2].channels).toEqual(expect.arrayContaining(['system', 'email', 'whatsapp'])); + }); + + it('TC-TERM-02: DD-ZM receives same channels as RBM for joint evaluation', async () => { + mockParticipants.push(makeP('zm-1', 'DD_ZM', '+91200')); + + await notifyStakeholdersOnTransition('term-uuid-001', 'termination', 'ZM Review', BASE_META); + + const call = mockNotify.mock.calls.find((c) => c[0] === 'zm-1'); + expect(call?.[2].channels).toContain('email'); + }); + + it('TC-TERM-03: Dealer does NOT have portal access for termination (SRS §1.1.6)', () => { + // This is a documentation/contract test. Dealer should NOT appear in participants for termination. + const dealerInParticipants = mockParticipants.some( + (p) => p.user.roleCode === 'Dealer' + ); + expect(dealerInParticipants).toBe(false); + }); +}); + +// ─── Stage 2-3: ZBH → DD-Lead ──────────────────────────────────────────────── + +describe('Termination Stage 2-3: RBM+ZM → ZBH → DD-Lead', () => { + beforeEach(() => { + jest.clearAllMocks(); + mockParticipants.length = 0; + }); + + it('TC-TERM-04: ZBH receives Action Required notification after RBM+ZM approval', async () => { + mockParticipants.push(makeP('zbh-1', 'ZBH', '+91300')); + + await notifyStakeholdersOnTransition('term-uuid-001', 'termination', 'ZBH Review', BASE_META); + + const call = mockNotify.mock.calls.find((c) => c[0] === 'zbh-1'); + expect(call?.[2].templateCode).toBe('WORKFLOW_ACTION_REQUIRED'); + }); + + it('TC-TERM-05: DD-Lead receives email + WhatsApp after ZBH forwards case', async () => { + mockParticipants.push(makeP('lead-1', 'DD_LEAD', '+91400')); + + await notifyStakeholdersOnTransition('term-uuid-001', 'termination', 'DD Lead Review', BASE_META); + + const call = mockNotify.mock.calls.find((c) => c[0] === 'lead-1'); + expect(call?.[2].channels).toContain('whatsapp'); + }); +}); + +// ─── Stage 4: DD-Lead → Legal ──────────────────────────────────────────────── + +describe('Termination Stage 4: DD-Lead → Legal Assignment', () => { + beforeEach(() => { + jest.clearAllMocks(); + mockParticipants.length = 0; + }); + + it('TC-TERM-06: Legal team receives email + system on DD-Lead assignment (SRS §4.3.2.4)', async () => { + mockParticipants.push(makeP('legal-1', 'LEGAL_ADMIN', null)); // no phone + + await notifyStakeholdersOnTransition('term-uuid-001', 'termination', 'Legal Review', BASE_META); + + const call = mockNotify.mock.calls.find((c) => c[0] === 'legal-1'); + expect(call?.[2].channels).toEqual(expect.arrayContaining(['system', 'email'])); + expect(call?.[2].channels).not.toContain('whatsapp'); + }); +}); + +// ─── Stage 6: DD-Head → NBH ────────────────────────────────────────────────── + +describe('Termination Stage 6: DD-Head → NBH Evaluation', () => { + beforeEach(() => { + jest.clearAllMocks(); + mockParticipants.length = 0; + }); + + it('TC-TERM-07: NBH receives email + WhatsApp for strategic review (SRS §4.3.2.7)', async () => { + mockParticipants.push(makeP('nbh-1', 'NBH', '+91500')); + + await notifyStakeholdersOnTransition('term-uuid-001', 'termination', 'NBH Evaluation', BASE_META); + + const call = mockNotify.mock.calls.find((c) => c[0] === 'nbh-1'); + expect(call?.[2].channels).toEqual(expect.arrayContaining(['system', 'email', 'whatsapp'])); + expect(call?.[2].templateCode).toBe('WORKFLOW_ACTION_REQUIRED'); + }); +}); + +// ─── Stage 7: SCN Issuance ─────────────────────────────────────────────────── + +describe('Termination Stage 7: Show Cause Notice Issuance', () => { + beforeEach(() => { + jest.clearAllMocks(); + mockParticipants.length = 0; + }); + + it('TC-TERM-08: Legal receives notification to prepare SCN after NBH Go-Ahead (SRS §4.3.2.8)', async () => { + mockParticipants.push(makeP('legal-1', 'LEGAL_ADMIN', null)); + + await notifyStakeholdersOnTransition('term-uuid-001', 'termination', 'Show Cause Notice', BASE_META); + + const call = mockNotify.mock.calls.find((c) => c[0] === 'legal-1'); + expect(call?.[2].channels).toContain('system'); + expect(call?.[2].channels).toContain('email'); + }); + + it('TC-TERM-09: DD-Admin is notified to share SCN with dealer (system + email)', async () => { + await NotificationService.notify('admin-1', 'ddadmin@re.com', { + title: 'Action Required: Share SCN — TERM-2026-001', + message: 'Show Cause Notice is ready. Please share with the dealer.', + channels: ['system', 'email'], + templateCode: 'WORKFLOW_ACTION_REQUIRED', + placeholders: { requestId: 'TERM-2026-001', link: '/termination/term-uuid-001' }, + }); + + expect(mockNotify).toHaveBeenCalledWith( + 'admin-1', + 'ddadmin@re.com', + expect.objectContaining({ templateCode: 'WORKFLOW_ACTION_REQUIRED' }) + ); + }); +}); + +// ─── Stage 9: NBH Final Decision → CEO/CCO ─────────────────────────────────── + +describe('Termination Stage 9: NBH Final Decision → CEO + CCO Authorization', () => { + beforeEach(() => { + jest.clearAllMocks(); + mockParticipants.length = 0; + }); + + it('TC-TERM-10: CEO receives email + system notification for final authorization (SRS §4.3.2.11)', async () => { + await NotificationService.notify('ceo-1', 'ceo@re.com', { + title: 'Authorization Required: Dealer Termination — TERM-2026-001', + message: 'NBH has approved termination. CEO authorization required.', + channels: ['system', 'email'], + templateCode: 'WORKFLOW_ACTION_REQUIRED', + placeholders: { requestId: 'TERM-2026-001', link: '/termination/term-uuid-001' }, + }); + + const call = mockNotify.mock.calls[0]; + expect(call[2].channels).toContain('email'); + expect(call[2].channels).toContain('system'); + }); + + it('TC-TERM-11: CCO receives same notification as CEO for co-authorization', async () => { + await NotificationService.notify('cco-1', 'cco@re.com', { + title: 'Authorization Required: TERM-2026-001', + message: 'Co-authorization from CCO required.', + channels: ['system', 'email'], + templateCode: 'WORKFLOW_ACTION_REQUIRED', + placeholders: { requestId: 'TERM-2026-001' }, + }); + + const call = mockNotify.mock.calls[0]; + expect(call[0]).toBe('cco-1'); + expect(call[2].channels).toContain('email'); + }); +}); + +// ─── Stage 11: Termination Letter ───────────────────────────────────────────── + +describe('Termination Stage 11: Termination Letter — DD-Lead + DD-Admin + Finance Notified', () => { + beforeEach(() => jest.clearAllMocks()); + + it('TC-TERM-12: DD-Lead is notified via system when Legal uploads Termination Letter (SRS §4.3.2.12)', async () => { + await NotificationService.notify('lead-1', 'ddlead@re.com', { + title: 'Termination Letter Issued: TERM-2026-001', + message: 'Legal has uploaded the official Termination Letter.', + channels: ['system'], + templateCode: 'WORKFLOW_STATUS_UPDATE_DEALER', + placeholders: { requestId: 'TERM-2026-001' }, + }); + + const call = mockNotify.mock.calls[0]; + expect(call[2].channels).toEqual(['system']); + }); + + it('TC-TERM-13: DD-Admin is notified to communicate Termination Letter to dealer (email + system)', async () => { + await NotificationService.notify('admin-1', 'ddadmin@re.com', { + title: 'Action Required: Communicate Termination Letter — TERM-2026-001', + message: 'Please share the Termination Letter with the dealer.', + channels: ['system', 'email'], + templateCode: 'WORKFLOW_ACTION_REQUIRED', + placeholders: { requestId: 'TERM-2026-001' }, + }); + + expect(mockNotify).toHaveBeenCalledWith('admin-1', 'ddadmin@re.com', expect.anything()); + }); + + it('TC-TERM-14: Finance is notified for F&F setup after termination letter (email + system)', async () => { + await NotificationService.notify('finance-1', 'finance@re.com', { + title: 'F&F Initiation Required: TERM-2026-001', + message: 'Termination complete. Please initiate F&F settlement on LWD.', + channels: ['system', 'email'], + templateCode: 'FNF_INITIATED', + placeholders: { requestId: 'TERM-2026-001' }, + }); + + const call = mockNotify.mock.calls[0]; + expect(call[2].templateCode).toBe('FNF_INITIATED'); + }); +}); + +// ─── F&F Trigger (LWD) — Termination Context ────────────────────────────────── + +describe('Termination: F&F Trigger Must Be on LWD (SRS §1.1.6)', () => { + it('TC-TERM-15: F&F is blocked when today is before LWD', () => { + const futureLwd = new Date(); + futureLwd.setDate(futureLwd.getDate() + 30); // 30 days from now + const canInitiateFnF = new Date() >= futureLwd; + expect(canInitiateFnF).toBe(false); + }); + + it('TC-TERM-16: F&F is allowed when LWD has passed', () => { + const pastLwd = new Date('2025-01-01'); + const canInitiateFnF = new Date() >= pastLwd; + expect(canInitiateFnF).toBe(true); + }); + + it('TC-TERM-17: Finance receives notification only when F&F is triggered on LWD', async () => { + const lwd = new Date('2025-12-01'); // past date — F&F allowed + const today = new Date(); + + if (today >= lwd) { + await NotificationService.notify('finance-1', 'finance@re.com', { + title: 'F&F Triggered on Last Working Day: TERM-2026-001', + message: 'Settlement process initiated.', + channels: ['system', 'email'], + templateCode: 'FNF_INITIATED', + placeholders: { requestId: 'TERM-2026-001' }, + }); + + expect(mockNotify).toHaveBeenCalledWith( + 'finance-1', + 'finance@re.com', + expect.objectContaining({ templateCode: 'FNF_INITIATED' }) + ); + } + }); +}); + +// ─── Send Back in Termination ───────────────────────────────────────────────── + +describe('Termination: Send Back / Revoke → ASM + DD-Lead notified', () => { + beforeEach(() => { + jest.clearAllMocks(); + mockParticipants.length = 0; + }); + + it('TC-TERM-18: ZBH Send Back notifies ASM with remarks via email + WhatsApp (SRS §4.3.2.3)', async () => { + mockParticipants.push(makeP('asm-1', 'ASM', '+91700')); + + await notifyStakeholdersOnTransition('term-uuid-001', 'termination', 'ASM Review', { + ...BASE_META, + action: 'Sent back — MOM documents incomplete', + remarks: 'Please resubmit updated MOMs from dealer.', + actionUserFullName: 'ZBH Actor', + }); + + const asmCall = mockNotify.mock.calls.find((c) => c[0] === 'asm-1'); + expect(asmCall?.[2].channels).toEqual(expect.arrayContaining(['system', 'email', 'whatsapp'])); + expect(asmCall?.[2].placeholders?.remarks).toBe('Please resubmit updated MOMs from dealer.'); + }); + + it('TC-TERM-19: DD-Lead Revoke action generates in-app notification for key observers', async () => { + mockParticipants.push(makeP('head-1', 'DD_HEAD', '+91800')); + + await notifyStakeholdersOnTransition('term-uuid-001', 'termination', 'Revoked', { + ...BASE_META, + action: 'Revoked by DD Lead', + actionUserFullName: 'Another User', + }); + + const observerCall = mockNotify.mock.calls.find((c) => c[0] === 'head-1'); + // Key observer: system only for terminal event + expect(observerCall?.[2].channels).toEqual(['system']); + }); +}); diff --git a/src/__tests__/workflow-email-notifications.test.ts b/src/__tests__/workflow-email-notifications.test.ts new file mode 100644 index 0000000..584eff6 --- /dev/null +++ b/src/__tests__/workflow-email-notifications.test.ts @@ -0,0 +1,405 @@ +/** + * @file workflow-email-notifications.test.ts + * @description Tests for notifyStakeholdersOnTransition + resolveNextActors. + * Verifies that the correct personas receive the correct channels at each + * onboarding, resignation, and termination stage. + * + * SRS Coverage: + * §6.14.3 — Next actor gets email + WhatsApp + in-app + * §6.14.3 — Send Back notifies ASM via email + WhatsApp + in-app + * §6.12.3 — Rejection notifies applicant via email + WhatsApp + * §6.13 — Work Notes / observer roles get in-app only on terminal events + */ + +import { + notifyStakeholdersOnTransition, + resolveNextActors, + notifyResignationSubmittedEmails, + notifyRelocationSubmittedEmails, + notifyConstitutionalSubmittedEmails, +} from '../common/utils/workflow-email-notifications.js'; +import { NotificationService } from '../services/NotificationService.js'; +import { sendEmail } from '../common/utils/email.service.js'; + +// ─── Mocks ─────────────────────────────────────────────────────────────────── + +jest.mock('../common/utils/email.service.js', () => ({ + sendEmail: jest.fn().mockResolvedValue(true), +})); + +const mockNotify = jest.spyOn(NotificationService, 'notify').mockResolvedValue(undefined); + +// Helper: build a participant user object +const makeUser = (overrides: Partial<{ + id: string; email: string; fullName: string; roleCode: string; mobileNumber: string | null; +}> = {}) => ({ + id: overrides.id ?? 'user-1', + email: overrides.email ?? 'user@re.com', + fullName: overrides.fullName ?? 'Test User', + roleCode: overrides.roleCode ?? 'DD_ADMIN', + mobileNumber: overrides.mobileNumber ?? '+919800000001', + ...overrides, +}); + +const makeParticipant = (user: ReturnType) => ({ user }); + +// ─── Mock DB ───────────────────────────────────────────────────────────────── + +const mockParticipants: ReturnType[] = []; + +jest.mock('../database/models/index.js', () => ({ + default: { + RequestParticipant: { + findAll: jest.fn(async () => mockParticipants), + }, + User: { + findByPk: jest.fn(async (id: string) => ({ + id, + fullName: 'System User', + email: 'sysuser@re.com', + mobileNumber: '+910000000000', + })), + }, + Outlet: { findByPk: jest.fn().mockResolvedValue(null) }, + District: {}, + StageApprovalAction: { findAll: jest.fn().mockResolvedValue([]) }, + }, +})); + +process.env.FRONTEND_URL = 'http://localhost:5173'; + +// ─── Shared metadata ────────────────────────────────────────────────────────── + +const baseMeta = { + code: 'RES-2026-0001', + dealerName: 'Sunrise Motorcycles', + dealerId: 'dealer-99', + actionUserFullName: 'Ravi Kumar (ASM)', + action: 'Forwarded to RBM', + remarks: 'Documents verified.', + link: 'http://localhost:5173/resignation/abc123', +}; + +// ─── resolveNextActors ──────────────────────────────────────────────────────── + +describe('resolveNextActors — stage-to-role mapping', () => { + beforeEach(() => { + jest.clearAllMocks(); + mockParticipants.length = 0; + }); + + it('TC-RNA-01: Level 1 Interview resolves to DD_ZM and RBM', async () => { + const zmUser = makeUser({ id: 'zm-1', roleCode: 'DD_ZM' }); + const rbmUser = makeUser({ id: 'rbm-1', roleCode: 'RBM' }); + mockParticipants.push(makeParticipant(zmUser), makeParticipant(rbmUser)); + + const actors = await resolveNextActors('app-1', 'application', 'Level 1 Interview'); + expect(actors).toContain('zm-1'); + expect(actors).toContain('rbm-1'); + }); + + it('TC-RNA-02: Level 2 Interview resolves to ZBH and DD_LEAD', async () => { + const zbhUser = makeUser({ id: 'zbh-1', roleCode: 'ZBH' }); + const leadUser = makeUser({ id: 'lead-1', roleCode: 'DD_LEAD' }); + mockParticipants.push(makeParticipant(zbhUser), makeParticipant(leadUser)); + + const actors = await resolveNextActors('app-1', 'application', 'Level 2 Interview'); + expect(actors).toContain('zbh-1'); + expect(actors).toContain('lead-1'); + }); + + it('TC-RNA-03: Level 3 Interview resolves to NBH and DD_HEAD', async () => { + const nbhUser = makeUser({ id: 'nbh-1', roleCode: 'NBH' }); + const headUser = makeUser({ id: 'head-1', roleCode: 'DD_HEAD' }); + mockParticipants.push(makeParticipant(nbhUser), makeParticipant(headUser)); + + const actors = await resolveNextActors('app-1', 'application', 'Level 3 Interview'); + expect(actors).toContain('nbh-1'); + expect(actors).toContain('head-1'); + }); + + it('TC-RNA-04: LOI Approval resolves to DD_HEAD (DD Head has not yet approved)', async () => { + const headUser = makeUser({ id: 'head-1', roleCode: 'DD_HEAD' }); + const nbhUser = makeUser({ id: 'nbh-1', roleCode: 'NBH' }); + mockParticipants.push(makeParticipant(headUser), makeParticipant(nbhUser)); + + // StageApprovalAction returns empty (no approvals yet) + const db = (await import('../database/models/index.js')).default as any; + db.StageApprovalAction.findAll.mockResolvedValueOnce([]); + + const actors = await resolveNextActors('app-1', 'application', 'LOI Approval'); + // Sequential: DD Head first + expect(actors).toContain('head-1'); + expect(actors).not.toContain('nbh-1'); + }); + + it('TC-RNA-05: LOI Approval resolves to NBH after DD Head has approved', async () => { + const headUser = makeUser({ id: 'head-1', roleCode: 'DD_HEAD' }); + const nbhUser = makeUser({ id: 'nbh-1', roleCode: 'NBH' }); + mockParticipants.push(makeParticipant(headUser), makeParticipant(nbhUser)); + + const db = (await import('../database/models/index.js')).default as any; + db.StageApprovalAction.findAll.mockResolvedValueOnce([ + { actorRole: 'DD Head' }, // DD Head already approved + ]); + + const actors = await resolveNextActors('app-1', 'application', 'LOI Approval'); + expect(actors).toContain('nbh-1'); + expect(actors).not.toContain('head-1'); + }); + + it('TC-RNA-06: NBH Approval stage resolves to NBH only', async () => { + const nbhUser = makeUser({ id: 'nbh-1', roleCode: 'NBH' }); + mockParticipants.push(makeParticipant(nbhUser)); + + const actors = await resolveNextActors('res-1', 'resignation', 'NBH Approval'); + expect(actors).toEqual(['nbh-1']); + }); + + it('TC-RNA-07: Legal Review stage resolves to LEGAL_ADMIN', async () => { + const legalUser = makeUser({ id: 'legal-1', roleCode: 'LEGAL_ADMIN' }); + mockParticipants.push(makeParticipant(legalUser)); + + const actors = await resolveNextActors('res-1', 'resignation', 'Legal Review'); + expect(actors).toContain('legal-1'); + }); + + it('TC-RNA-08: Unknown stage returns empty array (no crash)', async () => { + const actors = await resolveNextActors('app-1', 'application', 'NonExistentStage'); + expect(actors).toEqual([]); + }); +}); + +// ─── notifyStakeholdersOnTransition ────────────────────────────────────────── + +describe('notifyStakeholdersOnTransition — channel selection per persona', () => { + beforeEach(() => { + jest.clearAllMocks(); + mockParticipants.length = 0; + }); + + it('TC-NST-01: Next actor receives system + email + whatsapp channels', async () => { + const rbmUser = makeUser({ id: 'rbm-1', roleCode: 'RBM', mobileNumber: '+919800000001' }); + mockParticipants.push(makeParticipant(rbmUser)); + + await notifyStakeholdersOnTransition('app-1', 'application', 'RBM Review', baseMeta); + + expect(mockNotify).toHaveBeenCalledWith( + 'rbm-1', + 'user@re.com', + expect.objectContaining({ + channels: expect.arrayContaining(['system', 'email', 'whatsapp']), + templateCode: 'WORKFLOW_ACTION_REQUIRED', + }) + ); + }); + + it('TC-NST-02: Next actor without phone gets system + email only (no WhatsApp)', async () => { + const zbhUser = makeUser({ id: 'zbh-1', roleCode: 'ZBH', mobileNumber: null }); + mockParticipants.push(makeParticipant(zbhUser)); + + await notifyStakeholdersOnTransition('app-1', 'application', 'ZBH Review', baseMeta); + + expect(mockNotify).toHaveBeenCalledWith( + 'zbh-1', + 'user@re.com', + expect.objectContaining({ + channels: expect.not.arrayContaining(['whatsapp']), + }) + ); + }); + + it('TC-NST-03: Send Back action notifies ASM via system + email + whatsapp', async () => { + const asmUser = makeUser({ id: 'asm-1', roleCode: 'ASM', mobileNumber: '+91900' }); + mockParticipants.push(makeParticipant(asmUser)); + + await notifyStakeholdersOnTransition('res-1', 'resignation', 'ASM Review', { + ...baseMeta, + action: 'Sent Back to ASM for clarification', + actionUserFullName: 'DD Lead User', // different from ASM — won't be skipped + }); + + expect(mockNotify).toHaveBeenCalledWith( + 'asm-1', + expect.any(String), + expect.objectContaining({ + channels: expect.arrayContaining(['system', 'email', 'whatsapp']), + templateCode: 'WORKFLOW_ACTION_REQUIRED', + }) + ); + }); + + it('TC-NST-04: Dealer receives system + email + whatsapp on Rejected terminal event', async () => { + const dealerUser = makeUser({ + id: 'dealer-99', + roleCode: 'Dealer', + mobileNumber: '+91987654321', + }); + mockParticipants.push(makeParticipant(dealerUser)); + + await notifyStakeholdersOnTransition('res-1', 'resignation', 'Rejected', { + ...baseMeta, + dealerId: 'dealer-99', + }); + + expect(mockNotify).toHaveBeenCalledWith( + 'dealer-99', + expect.any(String), + expect.objectContaining({ + channels: expect.arrayContaining(['system', 'email', 'whatsapp']), + }) + ); + }); + + it('TC-NST-05: Dealer receives in-app only on non-terminal interim stage', async () => { + const dealerUser = makeUser({ + id: 'dealer-99', + roleCode: 'Dealer', + mobileNumber: '+91987654321', + }); + mockParticipants.push(makeParticipant(dealerUser)); + + await notifyStakeholdersOnTransition('res-1', 'resignation', 'ZBH Review', { + ...baseMeta, + dealerId: 'dealer-99', + }); + + const dealerCall = mockNotify.mock.calls.find((c) => c[0] === 'dealer-99'); + expect(dealerCall?.[2].channels).toEqual(['system']); + }); + + it('TC-NST-06: Key observers (DD_LEAD, DD_HEAD, NBH) receive in-app only on terminal events', async () => { + const leadUser = makeUser({ id: 'lead-1', roleCode: 'DD_LEAD', mobileNumber: '+91900' }); + mockParticipants.push(makeParticipant(leadUser)); + + await notifyStakeholdersOnTransition('res-1', 'resignation', 'Completed', { + ...baseMeta, + dealerId: 'dealer-99', + actionUserFullName: 'DD Lead User', // acting user – but leadUser will still match key observer + }); + + const observerCall = mockNotify.mock.calls.find((c) => c[0] === 'lead-1'); + // Key observer: only in-app (system) + expect(observerCall?.[2].channels).toEqual(['system']); + }); + + it('TC-NST-07: Acting user is skipped to avoid self-notification', async () => { + const actingUser = makeUser({ + id: 'acting-1', + roleCode: 'ZBH', + fullName: 'Ravi Kumar (ASM)', // same as baseMeta.actionUserFullName + }); + // actingUser is NOT the next actor (no role match for ZBH Review mapping) + mockParticipants.push(makeParticipant(actingUser)); + + await notifyStakeholdersOnTransition('app-1', 'application', 'ZBH Review', baseMeta); + + // Should not notify the acting user (they are the one who just acted) + const actingCall = mockNotify.mock.calls.find((c) => c[0] === 'acting-1'); + expect(actingCall).toBeUndefined(); + }); +}); + +// ─── notifyResignationSubmittedEmails ───────────────────────────────────────── + +describe('notifyResignationSubmittedEmails — channels on dealer submission', () => { + beforeEach(() => { + jest.clearAllMocks(); + mockParticipants.length = 0; + }); + + it('TC-NRSE-01: sends RESIGNATION_RECEIVED email to dealer on submission', async () => { + const db = (await import('../database/models/index.js')).default as any; + db.User.findByPk.mockResolvedValueOnce({ + id: 'dealer-1', + email: 'dealer@example.com', + fullName: 'Sunrise Dealers', + mobileNumber: '+919876543210', + }); + + const sendEmailMock = sendEmail as jest.Mock; + + await notifyResignationSubmittedEmails({ + id: 'res-uuid-1', + dealerId: 'dealer-1', + resignationId: 'RES-2026-0001', + lastOperationalDateSales: '2026-06-30', + }); + + expect(sendEmailMock).toHaveBeenCalledWith( + 'dealer@example.com', + expect.stringContaining('RES-2026-0001'), + 'RESIGNATION_RECEIVED', + expect.objectContaining({ dealerName: 'Sunrise Dealers' }) + ); + }); + + it('TC-NRSE-02: sends WhatsApp to dealer when mobileNumber is present', async () => { + const db = (await import('../database/models/index.js')).default as any; + db.User.findByPk.mockResolvedValueOnce({ + id: 'dealer-1', + email: 'dealer@example.com', + fullName: 'Sunrise Dealers', + mobileNumber: '+919876543210', + }); + + await notifyResignationSubmittedEmails({ + id: 'res-uuid-1', + dealerId: 'dealer-1', + resignationId: 'RES-2026-0001', + lastOperationalDateSales: '2026-06-30', + }); + + const whatsappCall = mockNotify.mock.calls.find( + (c) => c[2].channels?.includes('whatsapp') + ); + expect(whatsappCall).toBeDefined(); + expect(whatsappCall?.[2].templateCode).toBe('RESIGNATION_RECEIVED'); + }); + + it('TC-NRSE-03: notifies internal participants via email + system + whatsapp', async () => { + const db = (await import('../database/models/index.js')).default as any; + db.User.findByPk.mockResolvedValueOnce({ + id: 'dealer-1', + email: 'dealer@example.com', + fullName: 'Sunrise Dealers', + mobileNumber: '+919876543210', + }); + + const internalUser = makeUser({ id: 'asm-1', roleCode: 'ASM', mobileNumber: '+91111' }); + mockParticipants.push(makeParticipant(internalUser)); + + await notifyResignationSubmittedEmails({ + id: 'res-uuid-1', + dealerId: 'dealer-1', + resignationId: 'RES-2026-0001', + }); + + const internalCall = mockNotify.mock.calls.find((c) => c[0] === 'asm-1'); + expect(internalCall?.[2].channels).toEqual( + expect.arrayContaining(['email', 'system', 'whatsapp']) + ); + expect(internalCall?.[2].templateCode).toBe('RESIGNATION_SUBMITTED'); + }); + + it('TC-NRSE-04: skips WhatsApp if dealer has no mobileNumber', async () => { + const db = (await import('../database/models/index.js')).default as any; + db.User.findByPk.mockResolvedValueOnce({ + id: 'dealer-2', + email: 'dealer2@example.com', + fullName: 'No Phone Dealer', + mobileNumber: null, + }); + + await notifyResignationSubmittedEmails({ + id: 'res-uuid-2', + dealerId: 'dealer-2', + resignationId: 'RES-2026-0002', + }); + + const whatsappCall = mockNotify.mock.calls.find( + (c) => c[0] === 'dealer-2' && c[2].channels?.includes('whatsapp') + ); + expect(whatsappCall).toBeUndefined(); + }); +}); diff --git a/src/__tests__/workflow-service.test.ts b/src/__tests__/workflow-service.test.ts new file mode 100644 index 0000000..178f83d --- /dev/null +++ b/src/__tests__/workflow-service.test.ts @@ -0,0 +1,298 @@ +/** + * @file workflow-service.test.ts + * @description Tests for WorkflowService.transitionApplication — verifies that + * each status transition triggers the correct notifications, audit log entries, + * and SLA tracking calls. + * + * SRS Coverage: + * §6.22 — Every workflow event is auto-logged in Audit Trail + * §6.14.3 — Status transitions trigger in-system + email + WhatsApp for applicant + * §6.16 — LOI Issued triggers LOI_ISSUED email template (not WhatsApp per SRS §1.1.2) + * §9.4 — SLA tracking starts/stops on each stage transition + */ + +import { WorkflowService } from '../services/WorkflowService.js'; +import { NotificationService } from '../services/NotificationService.js'; +import { SLAService } from '../services/SLAService.js'; + +// ─── Mocks ─────────────────────────────────────────────────────────────────── + +jest.mock('../database/models/index.js', () => { + const mockUpdate = jest.fn().mockResolvedValue(true); + const mockCreate = jest.fn().mockResolvedValue({ id: 'hist-1' }); + const mockFindOne = jest.fn().mockResolvedValue(null); + const mockFindByPk = jest.fn().mockResolvedValue({ fullName: 'Test Actor' }); + + return { + default: { + Application: {}, + ApplicationStatusHistory: { create: mockCreate }, + User: { findOne: mockFindOne, findByPk: mockFindByPk }, + Dealer: {}, + StageApprovalPolicy: { findOne: jest.fn().mockResolvedValue(null) }, + StageApprovalAction: { findAll: jest.fn().mockResolvedValue([]) }, + }, + __mocks__: { mockUpdate, mockCreate, mockFindOne }, + }; +}); + +jest.mock('../common/utils/progress.js', () => ({ + syncApplicationProgress: jest.fn().mockResolvedValue(undefined), + PIPELINE_STAGE_LABEL_BY_OVERALL_STATUS: {}, +})); + +jest.mock('../common/config/constants.js', () => ({ + AUDIT_ACTIONS: { UPDATED: 'UPDATED' }, + APPLICATION_STAGES: { SHORTLISTED: 'Shortlisted', LOI_ISSUED: 'LOI Issued' }, + OVERALL_STATUS_TO_DB_CURRENT_STAGE: {}, +})); + +jest.mock('../common/utils/workflow-email-notifications.js', () => ({ + notifyStakeholdersOnTransition: jest.fn().mockResolvedValue(undefined), +})); + +jest.mock('../services/applicationAuditLog.service.js', () => ({ + pickApplicationAuditContext: jest.fn().mockReturnValue({}), + safeAuditLogCreate: jest.fn().mockResolvedValue(undefined), +})); + +const mockSLAStop = jest.spyOn(SLAService, 'stopTrack').mockResolvedValue(undefined as any); +const mockSLAStart = jest.spyOn(SLAService, 'startTrack').mockResolvedValue(undefined as any); +const mockNotify = jest.spyOn(NotificationService, 'notify').mockResolvedValue(undefined); + +process.env.FRONTEND_URL = 'http://localhost:5173'; + +// ─── Application fixture ───────────────────────────────────────────────────── + +const makeApp = (overrides: Record = {}) => { + const app: any = { + id: 'app-uuid-001', + applicationId: 'APP-2026-001', + overallStatus: 'Shortlisted', + currentStage: 'Shortlisted', + progressPercentage: 20, + email: 'applicant@gmail.com', + applicantName: 'Rahul Verma', + mobileNumber: '+919876543210', + update: jest.fn().mockResolvedValue(true), + ...overrides, + }; + return app; +}; + +// ─── Tests ──────────────────────────────────────────────────────────────────── + +describe('WorkflowService.transitionApplication — status transitions', () => { + beforeEach(() => jest.clearAllMocks()); + + it('TC-WS-01: updates application overallStatus to the target status', async () => { + const app = makeApp(); + await WorkflowService.transitionApplication(app, 'Level 1 Interview Pending', 'user-1'); + expect(app.update).toHaveBeenCalledWith( + expect.objectContaining({ overallStatus: 'Level 1 Interview Pending' }) + ); + }); + + it('TC-WS-02: creates an ApplicationStatusHistory record on each transition', async () => { + const db = (await import('../database/models/index.js')).default as any; + const app = makeApp(); + await WorkflowService.transitionApplication(app, 'Level 2 Interview Pending', 'user-2'); + expect(db.ApplicationStatusHistory.create).toHaveBeenCalledWith( + expect.objectContaining({ + applicationId: 'app-uuid-001', + previousStatus: 'Shortlisted', + newStatus: 'Level 2 Interview Pending', + changedBy: 'user-2', + }) + ); + }); + + it('TC-WS-03: skips redundant status history when status is already at target', async () => { + const db = (await import('../database/models/index.js')).default as any; + const app = makeApp({ overallStatus: 'Level 1 Interview Pending' }); + await WorkflowService.transitionApplication(app, 'Level 1 Interview Pending', 'user-1'); + expect(db.ApplicationStatusHistory.create).not.toHaveBeenCalled(); + }); + + it('TC-WS-04: calls safeAuditLogCreate with oldData and newData on each transition', async () => { + const { safeAuditLogCreate } = await import('../services/applicationAuditLog.service.js'); + const app = makeApp(); + await WorkflowService.transitionApplication(app, 'FDD Verification', 'user-fdd'); + expect(safeAuditLogCreate).toHaveBeenCalledWith( + expect.objectContaining({ + action: 'UPDATED', + entityType: 'application', + entityId: 'app-uuid-001', + oldData: expect.objectContaining({ status: 'Shortlisted' }), + newData: expect.objectContaining({ status: 'FDD Verification' }), + }) + ); + }); + + it('TC-WS-05: stops SLA tracking for the previous stage and starts for the new stage', async () => { + const app = makeApp({ currentStage: 'Level 1 Interview Pending' }); + await WorkflowService.transitionApplication(app, 'FDD Verification', 'user-1'); + expect(mockSLAStop).toHaveBeenCalledWith('app-uuid-001', 'Level 1 Interview Pending'); + }); + + it('TC-WS-06: triggers NotificationService.notify for the applicant on any status transition', async () => { + const db = (await import('../database/models/index.js')).default as any; + db.User.findOne.mockResolvedValueOnce({ id: 'sys-user-1', mobileNumber: '+91123' }); + const app = makeApp(); + await WorkflowService.transitionApplication(app, 'Level 1 Interview Pending', 'user-admin'); + expect(mockNotify).toHaveBeenCalledWith( + expect.any(String), + 'applicant@gmail.com', + expect.objectContaining({ + title: expect.stringContaining('Onboarding Update'), + channels: expect.arrayContaining(['email', 'system']), + }) + ); + }); + + it('TC-WS-07: uses LOI_ISSUED template when target status is "LOI Issued"', async () => { + const db = (await import('../database/models/index.js')).default as any; + db.User.findOne.mockResolvedValueOnce({ id: 'sys-user-1', mobileNumber: '+91123' }); + const app = makeApp(); + await WorkflowService.transitionApplication(app, 'LOI Issued', 'admin-1'); + expect(mockNotify).toHaveBeenCalledWith( + expect.anything(), + 'applicant@gmail.com', + expect.objectContaining({ templateCode: 'LOI_ISSUED' }) + ); + }); + + it('TC-WS-08: uses LOA_ISSUED template when target status is "LOA Issued"', async () => { + const db = (await import('../database/models/index.js')).default as any; + db.User.findOne.mockResolvedValueOnce({ id: 'sys-user-1', mobileNumber: '+91123' }); + const app = makeApp(); + await WorkflowService.transitionApplication(app, 'LOA Issued', 'admin-1'); + expect(mockNotify).toHaveBeenCalledWith( + expect.anything(), + 'applicant@gmail.com', + expect.objectContaining({ templateCode: 'LOA_ISSUED' }) + ); + }); + + it('TC-WS-09: uses DEALER_CODE_READY template when target status is "Dealer Code Generated"', async () => { + const db = (await import('../database/models/index.js')).default as any; + db.User.findOne.mockResolvedValueOnce({ id: 'sys-user-1', mobileNumber: null }); + const app = makeApp(); + await WorkflowService.transitionApplication(app, 'Dealer Code Generated', 'admin-1'); + expect(mockNotify).toHaveBeenCalledWith( + expect.anything(), + 'applicant@gmail.com', + expect.objectContaining({ templateCode: 'DEALER_CODE_READY' }) + ); + }); + + it('TC-WS-10: notifyStakeholdersOnTransition is called for every transition', async () => { + const { notifyStakeholdersOnTransition } = await import('../common/utils/workflow-email-notifications.js'); + const app = makeApp(); + await WorkflowService.transitionApplication(app, 'ZBH Review', 'user-zbh'); + expect(notifyStakeholdersOnTransition).toHaveBeenCalledWith( + 'app-uuid-001', + 'application', + 'ZBH Review', + expect.objectContaining({ + code: 'APP-2026-001', + dealerName: 'Rahul Verma', + }) + ); + }); + + it('TC-WS-11: skips applicant notification when skipNotification metadata is true', async () => { + const app = makeApp(); + await WorkflowService.transitionApplication(app, 'Shortlisted', 'admin-1', { + skipNotification: true, + forceLog: true, + }); + expect(mockNotify).not.toHaveBeenCalled(); + }); + + it('TC-WS-12: includes applicant mobileNumber in WhatsApp placeholders', async () => { + const db = (await import('../database/models/index.js')).default as any; + db.User.findOne.mockResolvedValueOnce({ + id: 'sys-user-1', + mobileNumber: '+919876543210', + }); + const app = makeApp(); + await WorkflowService.transitionApplication(app, 'FDD Verification', 'admin-1'); + const notifyCall = mockNotify.mock.calls.find( + (c) => c[1] === 'applicant@gmail.com' + ); + expect(notifyCall?.[2].placeholders?.phone).toBeTruthy(); + }); +}); + +// ─── WorkflowService.evaluateStagePolicy ───────────────────────────────────── + +describe('WorkflowService.evaluateStagePolicy — multi-role gate logic', () => { + beforeEach(() => jest.clearAllMocks()); + + it('TC-WESP-01: returns policyMet=true when no active policy exists for the stage', async () => { + const db = (await import('../database/models/index.js')).default as any; + db.StageApprovalPolicy.findOne.mockResolvedValueOnce(null); + const result = await WorkflowService.evaluateStagePolicy('app-1', 'SOME_STAGE'); + expect(result.policyMet).toBe(true); + }); + + it('TC-WESP-02: Super Admin bypass — always returns policyMet=true', async () => { + const db = (await import('../database/models/index.js')).default as any; + db.StageApprovalPolicy.findOne.mockResolvedValueOnce({ + requiredRoles: ['DD_ZM', 'RBM'], + approvalMode: 'ALL', + minApprovals: 2, + }); + db.StageApprovalAction.findAll.mockResolvedValueOnce([ + { actorUserId: 'su-1', actorRole: 'Super Admin', decision: 'Approved' }, + ]); + const result = await WorkflowService.evaluateStagePolicy('app-1', 'LEVEL_1'); + expect(result.policyMet).toBe(true); + expect(result.overriddenBy).toBe('Super Admin'); + }); + + it('TC-WESP-03: MIN_N mode — policyMet=true when minApprovals threshold is reached', async () => { + const db = (await import('../database/models/index.js')).default as any; + db.StageApprovalPolicy.findOne.mockResolvedValueOnce({ + requiredRoles: ['DD_ZM', 'RBM'], + approvalMode: 'MIN_N', + minApprovals: 1, + }); + db.StageApprovalAction.findAll.mockResolvedValueOnce([ + { actorUserId: 'zm-1', actorRole: 'DD_ZM', decision: 'Approved' }, + ]); + const result = await WorkflowService.evaluateStagePolicy('app-1', 'LEVEL_1'); + expect(result.policyMet).toBe(true); + }); + + it('TC-WESP-04: ALL mode — policyMet=false when only one of two required roles responded', async () => { + const db = (await import('../database/models/index.js')).default as any; + db.StageApprovalPolicy.findOne.mockResolvedValueOnce({ + requiredRoles: ['DD_ZM', 'RBM'], + approvalMode: 'ALL', + minApprovals: 2, + }); + db.StageApprovalAction.findAll.mockResolvedValueOnce([ + { actorUserId: 'zm-1', actorRole: 'DD_ZM', decision: 'Approved' }, + // RBM has NOT responded yet + ]); + const result = await WorkflowService.evaluateStagePolicy('app-1', 'LEVEL_1'); + expect(result.policyMet).toBe(false); + }); + + it('TC-WESP-05: ALL mode — policyMet=true when both RBM and DD_ZM have responded', async () => { + const db = (await import('../database/models/index.js')).default as any; + db.StageApprovalPolicy.findOne.mockResolvedValueOnce({ + requiredRoles: ['DD_ZM', 'RBM'], + approvalMode: 'ALL', + minApprovals: 2, + }); + db.StageApprovalAction.findAll.mockResolvedValueOnce([ + { actorUserId: 'zm-1', actorRole: 'DD_ZM', decision: 'Approved' }, + { actorUserId: 'rbm-1', actorRole: 'RBM', decision: 'Approved' }, + ]); + const result = await WorkflowService.evaluateStagePolicy('app-1', 'LEVEL_1'); + expect(result.policyMet).toBe(true); + }); +}); diff --git a/src/constants/allowed-email-template-codes.ts b/src/constants/allowed-email-template-codes.ts index fe7d67a..88a6f1b 100644 --- a/src/constants/allowed-email-template-codes.ts +++ b/src/constants/allowed-email-template-codes.ts @@ -3,11 +3,16 @@ */ export const ALLOWED_EMAIL_TEMPLATE_CODES = [ 'APPLICANT_SHORTLISTED', + 'APPLICANT_REJECTED', 'CONSTITUTIONAL_CHANGE_SUBMITTED', 'CONSTITUTIONAL_CHANGE_UPDATE', 'DEALER_CODE_READY', + 'EOR_COMPLETED', + 'FNF_INITIATED', 'GENERIC_NOTIFICATION', 'INTERVIEW_SCHEDULED', + 'INTERVIEW_SCHEDULED_APPLICANT', + 'INTERVIEW_SCHEDULED_PANELIST', 'LOA_ISSUED', 'LOI_ISSUED', 'NON_OPPORTUNITY', @@ -26,10 +31,13 @@ export const ALLOWED_EMAIL_TEMPLATE_CODES = [ 'SLA_REMINDER', 'SLA_BREACH', 'SLA_ESCALATION', + 'TERMINATION_INITIATED', 'TERMINATION_SCN_ISSUED', 'TERMINATION_UPDATE', 'USER_ASSIGNED', - 'WORKNOTE_NOTIFICATION' + 'WORKNOTE_NOTIFICATION', + 'WORKFLOW_ACTION_REQUIRED', + 'WORKFLOW_STATUS_UPDATE_DEALER', ] as const; export type AllowedEmailTemplateCode = (typeof ALLOWED_EMAIL_TEMPLATE_CODES)[number]; diff --git a/src/emailtemplates/applicant_rejected.html b/src/emailtemplates/applicant_rejected.html new file mode 100644 index 0000000..f5f8be1 --- /dev/null +++ b/src/emailtemplates/applicant_rejected.html @@ -0,0 +1,34 @@ +{{> email_header}} + +
+

Application Rejected — {{applicationId}}

+

Dear {{applicantName}},

+

+ We regret to inform you that your Royal Enfield Dealership Application + ({{applicationId}}) for location {{location}} + has been rejected after careful evaluation. +

+ + {{#if rejectionReason}} +
+ Reason for Rejection:
+ {{rejectionReason}} +
+ {{/if}} + +

+ We appreciate your interest in partnering with Royal Enfield. + You may reapply in the future when opportunities are available in your area. +

+ +

+ For any queries, please contact your local RE representative or reach us at + dealer-support@royalenfield.com. +

+ +

We wish you all the best in your endeavours.

+ +

Best Regards,
Royal Enfield Dealer Development Team

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

EOR Checklist Complete — {{requestId}}

+

Dear {{recipientName}},

+

+ All Essential Operating Requirements (EOR) for dealer application + {{requestId}} (Applicant: {{applicantName}}) have been + marked as completed and verified. +

+ +
+ EOR Status: 100% Complete
+ The dealership outlet is now ready for Inauguration review. +
+ + + + + + +
Application ID{{requestId}}
Applicant Name{{applicantName}}
Location{{location}}
Completed On{{completedOn}}
+ +

+ Please review the EOR checklist and, if all criteria are met, authorize the + Inauguration stage to mark this dealership as live. +

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

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

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

Full & Final Settlement Initiated — {{requestId}}

+

Dear {{recipientName}},

+

+ The Full & Final (F&F) settlement process has been initiated for dealer + {{dealerName}} (Request: {{requestId}}) + effective from the Last Working Day. +

+ + + + + + +
Request ID{{requestId}}
Dealer Name{{dealerName}}
Initiated By{{initiatedBy}}
Last Working Day{{lwd}}
+ +

+ All department clearances (NOC, Payables, Receivables, etc.) must be submitted + within the stipulated timeline. Please log in and update your department's + clearance status. +

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

+ This is a system-generated notification. F&F settlement can only be + initiated on or after the Last Working Day as per Royal Enfield policy. +

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

Dealer Termination Initiated — {{requestId}}

+

Dear {{recipientName}},

+

+ A formal termination process has been initiated for dealer + {{dealerName}} (Request: {{requestId}}). +

+ + + + + + + +
Request ID{{requestId}}
Dealer Name{{dealerName}}
Termination Category{{category}}
Initiated By{{initiatedBy}}
Current Stage{{currentStage}}
+ + {{#if remarks}} +
+ Remarks:
+ {{remarks}} +
+ {{/if}} + +

+ Please review the termination case and provide your evaluation as required. + All decisions must be documented with mandatory work notes. +

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

+ This notification is confidential and intended only for the named recipient. + Do not share this information externally without authorization. +

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

Action Required: {{requestId}}

+

Hi,

+

+ The request {{requestId}} + {{#if dealerName}}(Dealer: {{dealerName}}){{/if}} + has reached the {{targetStage}} stage and requires your review and action. +

+ + {{#if remarks}} +
+ Remarks from previous stage:
+ {{remarks}} +
+ {{/if}} + +

Please log in to the RE Dealer Management Portal to review the case details and take action.

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

+ This is an automated notification. Please do not reply to this email. +

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

Update on Your Request — {{requestId}}

+

Dear {{dealerName}},

+

+ Your request {{requestId}} has been updated. + Current status: {{targetStage}}. +

+ + {{#if remarks}} +
+ Note: {{remarks}} +
+ {{/if}} + +

You can track the live progress of your request on the dealer portal:

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

+ This is an automated status update. If you have questions, please contact your assigned Area Sales Manager. +

+
+ +{{> email_footer}} diff --git a/src/scripts/seed-missing-templates.ts b/src/scripts/seed-missing-templates.ts new file mode 100644 index 0000000..4314926 --- /dev/null +++ b/src/scripts/seed-missing-templates.ts @@ -0,0 +1,316 @@ +/** + * @file seed-missing-templates.ts + * @description Seeds the 6 email templates that are referenced in workflow code + * but were missing from the DB and the allowed-email-template-codes list. + * + * Run with: npx ts-node src/scripts/seed-missing-templates.ts + */ + +import db from '../database/models/index.js'; + +const seedMissingTemplates = async () => { + try { + console.log('--- Seeding Missing Workflow Email Templates ---'); + + const templates = [ + // ── 1. Workflow Action Required ──────────────────────────────────────── + // Used in: workflow-email-notifications.ts (next-actor, send-back notifications) + // constitutional.controller.ts + // Recipients: DD-ZM, RBM, ZBH, DD-Lead, DD-Head, NBH, Legal, Finance, FDD + // Channels: system + email + whatsapp (when phone available) + { + templateCode: 'WORKFLOW_ACTION_REQUIRED', + description: 'Sent to the next actor in any workflow when their action is required. Used across Onboarding, Resignation, Termination, Constitutional, and Relocation.', + subject: 'Action Required: {{requestId}} — {{targetStage}}', + body: ` +
+
+

Action Required

+
+
+

Hi,

+

+ The request {{requestId}} + {{#if dealerName}}(Dealer: {{dealerName}}){{/if}} + has reached the {{targetStage}} stage and requires your review and action. +

+ {{#if remarks}} +
+ Remarks:
{{remarks}} +
+ {{/if}} +

Please log in to the RE Dealer Management Portal to review and act:

+ +

This is an automated notification. Do not reply to this email.

+
+
`, + placeholders: ['requestId', 'dealerName', 'targetStage', 'link', 'remarks', 'ctaLabel'] + }, + + // ── 2. Workflow Status Update — Dealer ───────────────────────────────── + // Used in: workflow-email-notifications.ts (dealer on interim + terminal events) + // Recipients: Dealer / Applicant + // Channels: system always; email+whatsapp on terminal (rejection/completion) + { + templateCode: 'WORKFLOW_STATUS_UPDATE_DEALER', + description: 'Milestone/status update sent to the dealer or applicant when their request moves to a new stage.', + subject: 'Update on Your Request — {{requestId}}', + body: ` +
+
+

Request Status Update

+
+
+

Dear {{dealerName}},

+

+ Your request {{requestId}} has been updated. + Current status: {{targetStage}}. +

+ {{#if remarks}} +
+ Note: {{remarks}} +
+ {{/if}} +

Track the live progress of your request:

+ +

+ For queries, contact your assigned Area Sales Manager. +

+
+
`, + placeholders: ['requestId', 'dealerName', 'targetStage', 'link', 'remarks'] + }, + + // ── 3. F&F Initiated ─────────────────────────────────────────────────── + // Used in: resignation.controller.ts (when F&F is triggered on LWD) + // termination.controller.ts (post-termination F&F) + // Recipients: Finance team, Department heads, DD-Admin + // Channels: system + email + { + templateCode: 'FNF_INITIATED', + description: 'Notifies Finance and department heads when Full & Final (F&F) settlement is triggered on the Last Working Day.', + subject: 'F&F Settlement Initiated — {{requestId}}', + body: ` +
+
+

Full & Final Settlement Initiated

+
+
+

Dear {{recipientName}},

+

+ The Full & Final (F&F) settlement process has been initiated for dealer + {{dealerName}} (Request: {{requestId}}). +

+ + + + + + + + + + + + + + + + + +
Request ID{{requestId}}
Dealer Name{{dealerName}}
Last Working Day{{lwd}}
Initiated By{{initiatedBy}}
+

Please update your department clearance status promptly.

+ +

+ Per Royal Enfield policy, F&F settlement is initiated only on or after the Last Working Day. +

+
+
`, + placeholders: ['recipientName', 'dealerName', 'requestId', 'lwd', 'initiatedBy', 'link'] + }, + + // ── 4. EOR Completed ─────────────────────────────────────────────────── + // Used in: eor.controller.ts (when all EOR checklist items are complete) + // Recipients: DD-Head, NBH + // Channels: system (alert only — no email per SRS §6.19.3.4 design choice) + // Adding email template so Admin can optionally enable + { + templateCode: 'EOR_COMPLETED', + description: 'Alert to DD-Head and NBH when 100% of EOR (Essential Operating Requirements) checklist items are verified. Signals readiness for Inauguration stage.', + subject: 'EOR Checklist Complete — Ready for Inauguration: {{requestId}}', + body: ` +
+
+

✓ EOR Checklist — 100% Complete

+
+
+

Dear {{recipientName}},

+

+ All Essential Operating Requirements (EOR) for dealer application + {{requestId}} (Applicant: {{applicantName}}) + have been completed and verified. +

+
+ EOR Status: 100% Complete
+ The dealership is now ready for Inauguration review. +
+ + + + + + + + + + + + + + + + + +
Application ID{{requestId}}
Applicant{{applicantName}}
Location{{location}}
Completed On{{completedOn}}
+

Please review and authorize the Inauguration stage to mark this dealership as Live.

+ +
+
`, + placeholders: ['recipientName', 'applicantName', 'requestId', 'location', 'completedOn', 'link'] + }, + + // ── 5. Applicant Rejected ────────────────────────────────────────────── + // Used in: WorkflowService.transitionApplication (any rejection) + // Recipients: Applicant (external) + // Channels: email (SRS §6.12.3 — rejection via email) + // WhatsApp if mobileNumber present + { + templateCode: 'APPLICANT_REJECTED', + description: 'Sent to the applicant/dealer when their application is rejected at any stage of the onboarding process.', + subject: 'Update on Your Dealership Application — {{applicationId}}', + body: ` +
+
+

Application Status Update

+
+
+

Dear {{applicantName}},

+

+ We regret to inform you that your Royal Enfield Dealership Application + ({{applicationId}}) for location {{location}} + has been rejected after careful evaluation. +

+ {{#if rejectionReason}} +
+ Reason:
{{rejectionReason}} +
+ {{/if}} +

+ We appreciate your interest in partnering with Royal Enfield. You may reapply + when opportunities are available in your area in the future. +

+

+ For any queries, contact us at + dealer-support@royalenfield.com. +

+

Best Regards,
Royal Enfield Dealer Development Team

+
+
`, + placeholders: ['applicantName', 'applicationId', 'location', 'rejectionReason'] + }, + + // ── 6. Termination Initiated ─────────────────────────────────────────── + // Used in: termination.controller.ts (case creation) + // Recipients: RBM, DD-ZM, ZBH, DD-Lead, Legal, NBH + // Channels: system + email + whatsapp + { + templateCode: 'TERMINATION_INITIATED', + description: 'Notifies internal stakeholders (RBM, DD-ZM, ZBH, Legal, NBH) when a dealer termination case is formally initiated by ASM.', + subject: 'Dealer Termination Case Initiated — {{requestId}}', + body: ` +
+
+

Dealer Termination Case Initiated

+
+
+

Dear {{recipientName}},

+

+ A formal termination process has been initiated for dealer + {{dealerName}} (Request ID: {{requestId}}). +

+ + + + + + + + + + + + + + + + + + + + + +
Request ID{{requestId}}
Dealer Name{{dealerName}}
Termination Category{{category}}
Initiated By{{initiatedBy}}
Current Stage{{currentStage}}
+ {{#if remarks}} +
+ Remarks:
{{remarks}} +
+ {{/if}} +

Please review the case and provide your evaluation with mandatory work notes.

+ +

+ This notification is confidential. Do not share externally without authorization. +

+
+
`, + placeholders: ['recipientName', 'dealerName', 'requestId', 'category', 'initiatedBy', 'currentStage', 'remarks', 'link'] + } + ]; + + for (const t of templates) { + const [, created] = await db.EmailTemplate.upsert({ + ...t, + isActive: true + }); + console.log(`${created ? 'Created' : 'Updated'}: ${t.templateCode}`); + } + + console.log('\n--- Missing Templates Seeded Successfully ---'); + console.log(`Total: ${templates.length} templates seeded.`); + process.exit(0); + } catch (error) { + console.error('Error seeding missing templates:', error); + process.exit(1); + } +}; + +seedMissingTemplates();