diff --git a/Re_New_Dealer_Onboard.md b/Re_New_Dealer_Onboard.md new file mode 100644 index 0000000..a77689c --- /dev/null +++ b/Re_New_Dealer_Onboard.md @@ -0,0 +1,6293 @@ +## RE Onboarding & Offboarding System Requirements + +``` +System Requirements Specifications +``` +``` +16 - Oct- 2025 +Version 1. 0 +``` + +## Contents + + +- RE Onboarding & Offboarding System Requirements +- 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 Shortlisted Applicants + - 6.7 Application Detail View + - 6.8 Interview Scheduling & Coordination + - 6.9 Interview Evaluation & Feedback Management + - 6.10 Interview Feedback & Evaluation Summary + - 6.11 Application Approval & Rejection Workflow + - 6.12 Work Notes & Internal Communication Trail + - 6.13 System Notifications & Alerts + - 6.14 FDD (Financial Due Diligence) & Finance Module + - 6.15 LOI Approval & Issuance + - 6.16 Dealer Code Generation, Architectural Work & Statutory Documentation............ + - 6.17 LOA Issuance, Essential Operating Requirements & Inauguration + - 6.18 Essential Operating Requirements (EOR) Checklist + - 6.19 Progress Tracker....................................................................................................... + - 6.20 Central Document Repository + - 6.21 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 Non-Functional Requirements +- 13 Technology Matrix +- 14 Infra requirements & System Hygiene +- 15 Not in scope + + +## 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** + +- **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.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**. + +``` +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**. + +``` +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 sent over email and + whatsapp to the applicant. +- Notification emails are triggered to all relevant stakeholders. + +``` +4.1.1.7 Dealer Code Generation & Setup +``` +- After LOI issuance, a **Dealer Code** is generated automatically by the system and mapped + to the applicant. +- 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 system automatically transitions the application to **Inauguration Readiness** once EOR + is complete. + +``` +4.1.1.11 LOA (Letter of Authorization) & Final Go-Live +``` +- Upon full EOR completion, the **LOA** is generated and approved by **NBH** and **DD-Head**. +- 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. +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). +- No portal access is provided to the dealer for resignation initiation. + +``` +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. + +``` +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. + +``` +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. + + +``` +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. + +``` +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. + +### 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. + +``` +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). + +``` +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. + +``` +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) +``` +- The system automatically calculates: + - Net Settlement = Total Payables – Total Receivables – Total Deductions +- Finance reviews and adjusts entries as needed, attaching relevant proofs for + transparency. +- 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 or + registered mobile number. +- **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 Nonresult. - Opportunity Email based on +``` +``` +4 System → DD-Admin All applications (both categories) are routed to Admin +for validation. +``` +``` +5 +``` +``` +DD-Admin → DD-ZM / DD-Lead +(respective Zone) +``` +``` +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 +``` +``` +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.6 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. +``` +### 6.7 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.8 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. +``` +``` +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.9 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.10 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** (Knowledge Transfer Matrix). +- 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.11 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.12 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. + +**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.13 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. +- **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 email notifications for interview +schedules, approvals, or feedback +outcomes only. +``` +``` +External limited +scope. +``` +``` +System (Automation +Layer) +``` +``` +Generates, delivers, and logs notifications +with timestamps. +``` +``` +Background +operation. +``` +### 6.14 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.15 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 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 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 **Email & whatsapp notification** to the dealer for the issued LOI. + 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 4. Personas-Wise Accessibility & Visibility** + +``` +Persona Accessibility Visibility Scope +``` + +``` +DD-Admin Initiates document requests, validates uploads, +manages security deposit confirmation, and +uploads final LOI. +``` +``` +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.16 Dealer Code Generation, Architectural Work & Statutory Documentation............ + +Documentation + +**6.17.1 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 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 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. +``` +``` +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.17 LOA Issuance, Essential Operating Requirements & Inauguration + +**6.18.1 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. + +**6.18.2 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 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. +``` +``` +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.18 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. +``` +``` +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 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 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**. + +**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: Unique code created and logged post-approval. +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. +``` +### 6.20 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 Readand approvals for final decision-only access to review applicant artefacts -making. Readvisibility.-only +``` +``` +System (Automation Layer) +``` +``` +Aggregates documents from all workflow +stages, maintains version control, and syncs +logs with Audit Trail. +``` +``` +Background +operation. +``` + +### 6.21 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. + +**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. +``` +- 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. + +``` +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. +``` +## 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. + +**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. +``` +``` +Email communication only +(no direct system access). +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. + +**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. +``` + +### 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. + +**7.4.2 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 +``` +``` +Gains access only after NBH +approval; visible to DD- +Admin upon upload. +``` + +``` +the case; can add queries via +Work Notes. +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. +``` + +## 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. + +**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 +``` + +## 9 Admin Section + +### 9.1 Master Configuration – Organization + +**9.1.1 1. Functionality Scope** + +The **Master Configuration** module forms the foundation of the system’s administrative and +organizational setup. Within this, the **Regional Hierarchy & Zone Management** section enables +the **System Administrator** to define, structure, and maintain Royal Enfield’s official **Dealer +Development (DD) hierarchy** , ensuring every dealer, outlet, and user is correctly mapped to their +respective **Zone, Region, and Area**. This configuration drives workflow routing, approval +ownership, SLA tracking, and reporting alignment across all dealer-facing processes such as +onboarding, resignation, and F&F closure. + +**9.1.2 2. Width** + +- **Regional Hierarchy Overview:** + o Displays five zones — **North, South, East, West, and Central** — each summarizing: + ▪ Total **Regions** under the zone + ▪ Number of **Zonal Managers (ZMs)** , **Regional Business Managers (RBMs),** + **Area Sale Manager (ASM) & DD-AM (DD-Area Manager)** + ▪ + o **Zone Management** grid provides: + ▪ **Zone Code** , **Zone Name** , and **Region** + + +``` +▪ States and Areas Covered +▪ DD / ZM / RBM / ASM / DD-AM Counts +▪ Action controls — Edit , Delete +▪ Add Zone option for creating new records +``` +- **Add/Edit Zone Form:** + o Input fields available for setup: + ▪ **Zone Code** – e.g., _N-Z1_ + ▪ **Zone Name** – e.g., _North Zone_ + ▪ **Region** – Select from dropdown ( _UP, Punjab & others_ ) + ▪ **States Covered** – Multi-select dropdown populated from the Location + Master + ▪ **Areas Covered** – Multi-select dropdown (district- or city-level sub- + mapping) + o **Save Zone:** Validates and commits configuration changes. + o **Cancel:** Closes form without saving. + +**9.1.3 3. Depth** + +- **Definition of Hierarchy:** + o The Royal Enfield network is structured as: + **Zone → Region → Area → Dealer / Showroom** + o Each level has clear administrative and operational ownership, ensuring + traceability and accountability across the dealer ecosystem. + o **Example – North Zone Structure:** + o North Zone ( 900 Dealers) + o ├── UP Region ( 180 Dealers) + o │ ├── Lucknow Area ( 8 Dealers) + o │ │ ├── Pushp Auto (Alambagh Showroom) + o │ │ ├── Rishabh Motors (Gomti Nagar) + o │ │ └── 6 More Local Outlets + o │ ├── Kanpur Area ( 10 Dealers) + o │ └── 13 Other Areas + o ├── Punjab Region ( 150 Dealers) + o └── 5 Other Regions + o This hierarchical configuration ensures that every **Dealer** , **Studio** , or **Outlet** is + mapped under a defined **Area** , which rolls up into a **Region** , and subsequently into + a **Zone**. +- **Data Mapping & Validation Logic:** + o Each **Zone** is assigned a unique identifier and linked to its parent **Region** and **Area**. + o **Dealer Development (DD)** resources are mapped to their respective areas for + process routing. + o State–Area relationships are validated to prevent overlapping coverage or + duplicate entries. + + +``` +o Automatic recalculation of counts occurs when dealers or managers are +reassigned. +``` +**9.1.4 Dealer Development Hierarchy & Responsibility Mapping** + +``` +Hierarch +y Level +``` +``` +Example from North +Zone Structure +``` +``` +Approx. +Dealer +Coverag +e +``` +``` +Responsible +Roles +``` +``` +Scope of +Oversight / +Visibility +``` +``` +Operational +Responsibilitie +s +``` +``` +National +Level +``` +``` +Pan-India – All Zones +(North, South, etc) +``` +#### ~3,000+ + +``` +Dealers +``` +``` +DD-Lead , DD- +Head , NBH , DD +``` +**- Admin** + +``` +End-to-end +national +governanc +e across all +Zones, +Regions, +and Areas +``` +- Oversee all +onboarding, +resignation, +and F&F +workflows +- Monitor SLA +adherence and +performance +metrics +- Approve +escalated cases +or exceptions +Zone +Level + +``` +North Zone (e.g., +900 Dealers) +``` +#### 700 – + +#### 1,000 + +``` +Dealers +per Zone +``` +``` +DD-ZM , ZBH Zonal +oversight +covering +multiple +Regions +and their +assigned +RBMs +``` +- Review zonal +performance +- Coordinate +between +Regional and +National teams +- Validate +dealer +onboarding, +closure, and +SLA metrics +- Escalate +financial and +compliance +matters to DD- +Lead +Region +Level + +``` +UP Region , Punjab +Region , etc. +``` +#### 100 – 200 + +``` +Dealers +per +Region +``` +``` +RBM (Regional +Business +Manager) +``` +``` +Regional +oversight +covering +multiple +Areas +``` +- Supervise +Area Managers +- Approve +dealer-level +operational +activities + + +``` +under one +Region +``` +- Ensure +adherence to +regional sales, +service, and +brand +standards +- Review and +forward +approvals to +DD-ZM or +higher +Area +Level + +``` +Lucknow Area (8 +Dealers), Kanpur +Area (10 Dealers) +``` +#### 5 – 15 + +``` +Dealers +per Area +``` +``` +DD-AM (Area +Manager) , ASM +(Area Sales +Manager) +``` +``` +Area-level +operations +covering +dealers and +sub- +dealers +``` +- Manage +direct dealer +interactions +and field audits +- Validate +dealer data, +documents, +and site +activities +- Report +progress, +feedback, and +resignation +inputs +upstream +- First point of +verification for +dealer +submissions +Dealer / +Outlet +Level + +``` +Pushp Auto +(Alambagh) , Rishab +h Motors (Gomti +Nagar) +``` +``` +1 Dealer +(Main / +Studio / +Service +Outlet) +``` +``` +DD-AM (Area +Manager) , ASM +(Area Sales +Manager) +``` +``` +Dealer +operations +reporting +into Area- +level roles +``` +- Submit +onboarding, +resignation, or +compliance +documentation +- Coordinate +with DD-AM / +ASM for all +operational +requests + + +### 9.2 Zone, Region & Area Configuration + + +**9.2.1 Functionality Scope** + +The **Zone, Region & Area Configuration** module defines the geographical and managerial +hierarchy governing Royal Enfield’s entire dealer network. It empowers the **Admin** to configure +the structural mapping of **Zones** , **Regions** , and **Areas** , thereby aligning operational +responsibilities and approval flows across Dealer Development (DD), Sales, and Business teams. +Each **Zone** is led by a **Zonal Business Head (ZBH)** and comprises multiple **Regions** managed +by **Regional Business Managers (RBMs)**. Within each region, **Area Sales Managers +(ASMs)** and **Dealer Development Area Managers (DD-AMs)** oversee localized dealer +operations. Above these field roles, the hierarchy extends to **Dealer Development Zonal +Managers (DD-ZM)** , **DD-Lead** , **DD-Head** , and finally the **National Business Head (NBH)** , +ensuring visibility and governance across all levels. +This structure serves as the foundation for all workflows — including **Onboarding, Resignation, +Termination, and F&F Settlements** — ensuring automated routing, escalation, and +performance tracking aligned to the correct operational hierarchy. + +**9.2.2 Width** + +This module spans the full organizational hierarchy and covers all geographic and managerial +relationships that define how workflows are routed and governed: + +- **Zone Configuration** + + +``` +o Define zone code, name, and description (e.g., North Zone, South Zone). +o Assign the Zonal Business Head (ZBH) & DD-ZM with name, contact, and email. +o Select all states and union territories falling under the zone’s jurisdiction. +``` +- **Regional Configuration** + o Create one or multiple regions (Sates) under each zone. + o Assign a **Regional Business Manager (RBM)** and link them with contact details. + o Map states and districts under the region. + o Specify the total **Regional Officers** and **Area Managers** working under the region. +- **Area Configuration (ASM / DD-AM Assignment)** + o Configure **Area Sales Managers (ASM)** and **Dealer Development Area Managers** + **(DD-AM)** with designated city or district coverage. + o Link each ASM/DD-AM to their corresponding Region and Zone. + o Set contact details, status, and operational scope (Active/Inactive). +- **Hierarchy Linkage Across Levels** + o Each region and area automatically link upward to **DD-ZM** , **ZBH** , and **DD-Lead** , + ensuring system-level routing alignment. + o National roles such as **DD-Head** and **NBH** inherit macro-level visibility across all + configured territories. + +**9.2.3 Depth** + +- **Organizational Mapping:** + Each dealer request or case — whether onboarding, resignation, or termination — + inherits its routing chain from this hierarchy (e.g., ASM → RBM → ZBH → DD-Lead → + NBH). This ensures consistent reporting and accountability. +- **Role Interlinking:** + o **ASM & DD-AM** : Manage dealer operations, visit tracking, and initial-level data + inputs. + o **RBM & DD-ZM** : Conduct mid-level evaluations and provide regional performance + oversight. + o **ZBH** : Supervises zonal dealer network health and strategic decisions. + o **DD-Lead & DD-Head** : Manage pan-India dealer policies, escalations, and + workflow resolutions. + o **NBH** : Holds final oversight and decision authority for national-level approvals. +- **Geographic Traceability:** + Every configuration entry — from zone to district — enables traceable linkage of dealer + location, responsible officers, and workflow approvals. +- **Dynamic Updates & Scalability:** + Admins can modify or reassign any role or coverage area without disrupting ongoing + workflows. The system auto-updates workflow routing, escalation hierarchy, and + reports in real time. +- **There can be multiple users mapped at same role.** For example, there can be 2 ZBH or 3 + DD-ZM at a same Zone. + + +- **Data Consistency & Integration:** + Each change reflects across dependent modules like **Role & Permissions** , **SLA** + **Management** , and **Email Notifications** , ensuring all updates remain synchronized. + +**9.2.4 Personas-wise Accessibility & Visibility** + +``` +Persona Responsibilities in Module Access Level +Admin Creates, edits, and manages the entire hierarchy — +zones, regions, and ASMs. Assigns officers and +maintains real-time linkage between geographic and +managerial structures. +``` +``` +Full Access +``` +``` +DD-AM (Dealer +Development Area +Manager) +``` +``` +Views assigned area (district/city), local dealers, and +reporting managers. +``` +``` +View Only +``` +``` +ASM (Area Sales +Manager) +``` +``` +View assigned territory’s dealer operations, monitors +requests, and coordinates with RBM. +``` +``` +View & +Comment +RBM (Regional +Business Manager) +``` +``` +View regional offices, assigns ASMs, and validates +dealer-level data. +``` +``` +Edit within +assigned +region +DD-ZM (Dealer +Development Zonal +Manager) +``` +``` +Reviews dealer development operations within the +zone and collaborates with RBMs. +``` +``` +View & +Comment +``` +``` +ZBH (Zonal Business +Head) +``` +``` +Monitors zone-level performance and ensures +escalation or workflow alignment with DD-Lead. +``` +``` +View & +Comment +DD-Lead Reviews configuration consistency, ensures correct +routing for all workflows, and validates escalation +logic. +``` +``` +View Only +``` +``` +DD-Head Reviews national-level structure, oversees zonal and +regional performance, and approves any +configuration realignment. +``` +``` +View Only +``` +``` +NBH (National +Business Head) +``` +``` +Holds complete top-level visibility for all zones, +oversees configuration for governance and reporting +accuracy. +``` +``` +View Only +``` + +### 9.3 Roles & permissions + + +**9.3.1 Functionality Scope** + +The **Roles & Permissions** module governs how users across Royal Enfield’s Dealer Development +and allied departments (Finance, Legal, FDD) interact with the system. +It ensures each role has controlled access to relevant workflows, reports, and actions within +the **Dealer Lifecycle** — from opportunity creation and onboarding, through evaluation and FDD, +to resignation and closure. The module supports **multi-level permission granularity** , allowing +both **role-based** and **user-specific** privilege configurations. This provides flexibility to assign +additional or restricted access based on operational necessity while maintaining organizational +compliance and hierarchy alignment. + +**9.3.2 Width** + +- **Role Management Dashboard:** + o Displays every configured role along with its assigned permissions and mapped + users. + o Columns include: + ▪ **Role Name** + ▪ **Permissions** (summary + expandable list) + ▪ **User Count** + ▪ **Actions** ( _Edit_ , _Delete_ ) +- **Add/Edit Role:** + o **Role Name** – unique identifier (e.g., _DD-ZM_ , _Finance_ , _Legal_ ). + o **Description** – outlines the role’s scope (e.g., _Manages Zonal Operations & Level- 1_ + _Evaluation_ ). + o **Permission Toggles:** + ▪ View / Review / Approve / Reject Applications + ▪ Upload Documents + ▪ Schedule Interviews + ▪ Manage Users + ▪ View Reports + ▪ Configure SLA + ▪ Manage Templates + ▪ View / Verify Payments +- **Save Role / Cancel** – commits or discards changes. + +**9.3.3 Depth** + +``` +9.3.3.1 Role Responsibilities & Hierarchy Mapping +Level / Function Roles Involved Scope of Responsibility Core Permissions +``` + +Area Level +(Field +Operations) + +``` +DD-AM (Dealer +Development +Executive / Area +Manager) +``` +``` +Identifies new dealership +opportunities on-ground, +interacts with prospects, +validates field data, and +supports documentation +readiness. +``` +``` +View & upload +applications, update +opportunity details, +add work notes. +``` +Level- 1 +Evaluation +(Zonal / +Regional +Assessment) + +``` +DD-ZM + RBM Conducts initial evaluation +using KT Matrix , reviewing +applicant credentials, +financial potential, and local +market understanding. +``` +View, review, and +approve Level- 1 +applications; record KT +scores; schedule +interviews. +Level- 2 +Evaluation +(Strategic +Assessment) + +``` +DD-Lead + ZBH Reviews shortlisted +applications for business +alignment, operational +readiness, and strategic fit. +Approves or forwards for +final evaluation. +``` +``` +Approve/Reject +applications, review +interview feedback, +upload evaluation +documents. +``` +Level- 3 +Evaluation +(National +Approval) + +``` +NBH + DD-Head Conducts final decision- +making for dealership +onboarding or closure, +ensuring alignment with +brand growth and financial +feasibility. +``` +``` +Full visibility of all +applications, approve +or reject at final stage, +review all attachments +and reports. +``` +Financial Due +Diligence (FDD) + +``` +FDD Team Performs external financial +due diligence for assigned +applications. Limited view of +assigned cases only. Can +upload FDD reports and raise +work notes for queries. +``` +``` +Upload FDD report, add +comments in work +notes, mark +completion. +``` +Finance **Finance Team** Manages payment-related +verifications, security deposit +validations, and refund +approvals for resignations. + +View and verify +payments, upload +supporting documents, +confirm receipts. +Legal **Legal +Department** + +``` +Reviews LOI, LOA, dealership +termination letters, and +agreement documents for +compliance. +``` +View legal documents, +upload vetted files, +provide legal remarks, +approve or return for +correction. +National +Governance + +``` +DD-Lead, DD- +Head, NBH, DD- +Admin +``` +``` +Central oversight for all +zones; monitors workflows, +SLA compliance, and +manages role/user +configurations. +``` +``` +Full system visibility, +manage roles, +configure SLA, access +reports and audit logs. +``` + +``` +9.3.3.2 Customizable Permission Framework +``` +- **Role-Level Permissions:** + Define the baseline privileges for all users under a given role (e.g., all DD-ZMs can _view_ + _applications_ , _review_ , and _approve_ Level-1). +- **User-Level Overrides:** + Allow case-specific adjustments for individuals. + o Example: Two DD-ZMs under different zones — one may have additional + permission to _view reports_ , while another may be limited to _review and approve_ + _applications_ only. +- This layered model ensures consistency in role design while supporting operational + adaptability. + +``` +9.3.3.3 Audit & Security Controls +``` +- Every permission change (at both role and user levels) is logged under **Audit Trail** with + timestamp, actor ID, and before-after states. +- Ensures traceability of configuration changes for compliance with Royal Enfield’s data- + governance framework. +- System auto-validates access inheritance to prevent privilege conflicts between + dependent modules. + +**9.3.4 4. Personas-Wise Access Summary** + +``` +Persona / +Role +``` +``` +Level Operational Focus Permission Highlights +``` +``` +DD-AM Area Ground opportunity +identification, field +validation +``` +``` +Add work notes +``` +``` +RBM Regional Regional evaluation & KT +Matrix scoring +``` +``` +Review documents, add remarks, +shortlist +DD-ZM Zonal Zonal evaluation & Level- 1 +approval +``` +``` +Approve Level-1, manage users +``` +``` +ZBH Zonal Strategic oversight & Level- 2 +evaluation +``` +``` +Approve Level-2, upload summary, +finalize recommendations +DD-Lead National Governance & performance +oversight +``` +``` +Manage users, approve Level- 2 +evaluations +DD-Head National Final authorization Full system access, finalize +decisions +NBH National Strategic business head Joint Level- 3 evaluation, +approve/reject final decision +``` + +``` +FDD External Financial due diligence Upload FDD reports, query via work +notes +Finance Cross- +functional +``` +``` +Payment validation & +security deposit checks +``` +``` +View/verify payments, upload +receipts +Legal Cross- +functional +``` +``` +Legal document review Upload & verify legal documents, +add remarks +DD-Admin National Configuration management Manage roles, SLA, locations, +templates, schedule interviews +``` +### 9.4 SLA Configuration & Escalation Management + + +**9.4.1 Functionality Scope** + +The **SLA Configuration** module enables Admin to define, monitor, and enforce **Turnaround Time +(TAT)** for every activity across the dealer lifecycle (onboarding, interviews, FDD, legal, payments, +resignation, F&F, LOI/LOA, EOR, etc.). The system supports **three-level escalation** , **pre-TAT +reminders** , and **post-TAT breach notifications**. All reminders and escalations are **auto-logged in +Work Notes** and **trigger email + in-app notifications** , ensuring traceability, transparency, and +timely closure. + +**9.4.2 Width** + +- **SLA Templates** + o Activity/Stage (e.g., _Level-1 Interview Feedback_ , _FDD Report Upload_ , _Payment_ + _Verification_ , _LOI Approval_ , _Resignation Review_ ). + o Owner Role (e.g., **DD-ZM** , **RBM** , **ZBH** , **DD-Lead** , **Finance** , **Legal** , **FDD** ). + + +``` +o TAT Unit & Calendar: hours/days, working days +o Pre-TAT Reminders: schedule one or more reminders (e.g., T-48h , T-24h , T-2h ). +o Escalation Matrix (3 levels): +▪ L1: After breach +X hours → Escalate to immediate supervisor (e.g., RBM +→ DD-ZM). +▪ L2: If still open +Y hours → Escalate to zonal authority (e.g., ZBH / DD-Lead). +▪ L3: If still open +Z hours → Escalate to national authority (e.g., DD-Head / +NBH ). +o Notification Channels: email, in-app notification, optional SMS. +o Work Notes Posting: auto-post reminder/escalation entries with timestamp, SLA +name, and due metrics. +o Repeat Overdue Reminders: configurable cadence (e.g., every 24h until closure). +o Pause Rules (optional): pause SLA when status is On Hold / Waiting for +Applicant / Awaiting External (e.g., FDD). +o Scope Rules: by Zone/Region/Area, by Role, by Activity Type, and by Application +Category. +``` +- **Dashboards & Views** + o **My SLA Queue:** due soon, breached, and escalated items for the logged-in user. + o **Aging Buckets:** 0 – 25%, 26–75%, 76–99%, Breached. + o **SLA Badges** on list cards and detail pages (green/amber/red) with remaining time. + o **Reports:** breach rate, average resolution time, top delayed activities, escalations + by level/role/region. + +**9.4.3 Depth** + +- **Clock Start/Stop Logic** + o SLA starts when the activity is **created/assigned** to the owner role. + o SLA **pauses** on configured statuses (e.g., _Waiting for Applicant / FDD /_ + _Legal_ ), **resumes** on return to active. + o SLA **stops** on closure states (e.g., _Approved/Rejected/Completed_ ). +- **Reminder & Escalation Execution** + o At each pre-TAT checkpoint the system: + ▪ Sends **email + in-app reminder** to the activity owner. + ▪ **Posts an automated Work Note** (e.g., “T-24h: Reminder sent to RBM for + Level-1 Feedback”). + o On TAT breach: + ▪ Marks item **Breached (red)** , posts **Work Note** with elapsed time. + ▪ Triggers **Escalation L1** to the mapped role; if not resolved within L1 + window, cascades to **L2** then **L3**. + ▪ Each escalation includes assignee, timestamp, reason, and a link to the + record. + + +**9.4.4 Personas-Wise Accessibility & Visibility** + +``` +Persona Accessibility Visibility +System Admin Create/edit/activate/deactivate SLA templates; +define calendars, holidays, pause rules; set +escalation roles and notification schedules. +``` +``` +Global. +``` +``` +DD-Admin Map activities to templates; monitor SLA status; +initiate corrective routing. +``` +``` +National/regional +(as allowed). +Owners (DD-AM, +RBM, DD-ZM, ZBH, +DD-Lead, Finance, +Legal, FDD) +``` +``` +Receive reminders; act on assigned items; view +timers, badges, and Work Notes; acknowledge +escalations. +``` +``` +Assigned records +and queues. +``` +``` +DD-Head / NBH Receive L3 escalations; view breach dashboards; +intervene/realign ownership. +``` +``` +Pan-India. +``` +``` +System (Automation) Runs timers, posts Work Notes, sends +notifications, cascades L1→L2→L3 escalations, +updates dashboards. +``` +``` +Background. +``` +**9.4.5 Example SLA (illustrative)** + +- **Activity:** _Level-1 Interview Feedback (KT Matrix)_ +- **Owner: DD-ZM + RBM** +- **TAT:** 2 working days; Business hours 9:00–18:00; weekends excluded. +- **Reminders:** T-24h and T-4h to owners. +- **Escalations:** + o **L1 (T+4h):** to **ZBH** + o **L2 (T+12h):** to **DD-Lead** + o **L3 (T+24h):** to **DD-Head/NBH** +- **System Actions:** badges on record; Work Notes for every reminder/escalation; email + in- + app notifications at each step. + + +### 9.5 Email & Letter Templates Management + +**9.5.1 Functionality Scope** + +The **Email & Letter Templates** module enables system administrators to configure and automate +communication across all dealer lifecycle workflows — including onboarding, interviews, +payments, FDD, approvals, and resignation stages. Each template defines **trigger-based +notifications** , ensuring timely and consistent communication between internal users (DD roles, +RBM, ZBH, etc.) and external applicants. Templates can dynamically pull context-specific details +using **system variables** and can be activated, edited, or versioned at any time. + +This module ensures communication uniformity across regions and roles while +supporting **automation triggers** , **personalized content** , and **multi-channel delivery** (email + in- +app notifications). + + +**9.5.2 2. Width** + +``` +9.5.2.1 Template Management Dashboard +``` +- Displays all active and inactive templates with details such as: + o **Template Name** – e.g., _Application Received_ , _Interview Scheduled_ , _SLA Breach_ + _Warning_. + o **Subject Line** – dynamic subject that appears in email notifications. + o **Trigger Event** – specifies when the email is auto-sent (e.g., on approval, rejection, + or SLA breach). + o **Last Modified Date** – timestamp of latest changes for version control. + o **Actions** – _Edit_ , _Duplicate_ , _Delete_. + +``` +9.5.2.2 Add / Edit Template +``` +Each email template includes configurable fields: + +- **Template Name:** Internal label for easy identification (e.g., _Application Approved_ ). +- **Email Subject:** Subject line used for recipients (e.g., _Congratulations! Your Application_ + _Has Been Approved_ ). +- **Trigger Event:** Selects the system action that will initiate the email (dropdown includes): + o On Application Submission + o On Approval + o On Rejection + o Interview Scheduled + o Document Request + o Payment Required + o SLA Breach Warning + o Payment Reminder +- **Template Body:** Rich-text editor (HTML support) with system variable placeholders for + dynamic insertion. +- **Active Template Toggle:** Enables or disables template without deletion. +- **Save / Cancel Buttons:** Commit or discard edits. + + +**9.5.3 3. Depth** + +``` +9.5.3.1 Trigger Mechanism +``` +Each configured template is mapped to an **event listener** within the workflow. When a user or +system action matches the trigger condition, an automated email and in-app notification are +generated and dispatched to the intended recipients. + +For example: + +- When an applicant submits a form → triggers _Application Received_ template. +- When DD-ZM schedules an interview → triggers _Interview Scheduled_ template. +- When SLA for an activity nears breach → triggers _SLA Breach Warning_ template. + +``` +9.5.3.2 Dynamic Data Population +``` +Templates leverage **predefined system variables** to automatically populate relevant data, +ensuring contextual accuracy. Available variables include: + +``` +Variable Description +``` +{{applicant_name}} (^) Applicant’s full name +{{application_id}} Unique application identifier +{{application_date}} (^) Submission date +{{interview_date}} (^) Scheduled interview date +{{interview_time}} Scheduled interview time +{{status}} (^) Current application status +{{reason}} (^) Reason for rejection or remark +{{company_name}} Dealer firm or business entity name +{{location}} (^) Preferred / applied dealership location +{{reviewer_name}} (^) Approver or interviewer name +{{payment_amount}} Amount due or verified +{{due_date}} (^) Payment / response deadline +{{support_email}} (^) Official support or contact email +Variables are replaced dynamically at runtime, ensuring personalized and accurate +communications without manual edits. + + +``` +9.5.3.3 Trigger Linkage & Workflow Integration +``` +- The module is fully integrated with system workflows — **Dealer Onboarding, Interview** + **Evaluation, FDD, Finance, Legal, and Resignation**. +- Templates can be reused across similar workflows and roles, minimizing duplication. +- Each workflow can have multiple templates mapped to distinct sub-events (e.g., _Interview_ + _Scheduled_ vs _Interview Rescheduled_ ). + +``` +9.5.3.4 Escalation & SLA Communication Integration +``` +- SLA reminders and escalations leverage the same template framework. +- Templates like _SLA Breach Warning_ and _Pending Action Reminder_ automatically pull + escalation hierarchy and timestamps. +- Escalations are simultaneously logged in **Work Notes** to maintain an auditable + communication trail. + +**9.5.4 4. Personas & Permissions** + +``` +Role Access Type Description +System Admin / DD-Admin Full Access Create, edit, activate, deactivate, or delete +templates; map triggers; modify variables. +DD-Lead / ZBH / DD-Head Limited +View +``` +``` +Can preview active templates relevant to their +workflow. +All Other Roles (RBM, DD- +ZM, Finance, FDD, Legal) +``` +``` +Execution- +Only +``` +``` +Receive or trigger templates automatically; no +edit rights. +``` +**9.5.5 5. Example Template Configuration** + +``` +Field Value +Template +Name +``` +``` +Interview Scheduled +``` +``` +Subject Interview Scheduled – Royal Enfield Dealership +Trigger When Interview Scheduled +Body Dear {{applicant_name}}, +``` +``` +Your interview for the Royal Enfield Dealership has been scheduled +on {{interview_date}} at {{interview_time}}. +``` +``` +Location: {{location}} +Reviewer: {{reviewer_name}} +``` +``` +Please ensure timely attendance. +``` + +``` +Regards, +Royal Enfield Dealer Development Team +Active Yes +``` +### 9.6 Opportunity Management (Geography & Window Setup) + +**9.6.1 Functionality Scope** + +The **Opportunity Management** module allows Admin to define where and when dealership +opportunities are open. Admin can create opportunities at **Zone → Region → Area** granularity, +specify **From / To dates** , and manage the status ( **Active / Inactive / Closed** ). The module also +provides **date-range filters** and reports to view **historical opportunity windows** , ensuring +transparency, traceability, and controlled intake of applications. + + +**9.6.2 Width** + +- **Create / Edit Opportunity** + 1. **Geography:** Zone → Region → Area (cascading drop-downs), plus **State / City /** + **District**. + 2. **Opportunity Details:** Opportunity Type (Main / Studio / Service), **Capacity** (no. of + dealer slots), **Priority** , Notes/Justification. + 3. **Open Window: From Date** and **To Date** (business calendar), optional **Auto-close** + **on end date**. + 4. **Ownership:** Responsible Role (e.g., DD-ZM / RBM) for visibility and SLA routing. + 5. **Status:** Draft / Active / Inactive / Closed. + 6. **Attachments (optional):** Market study, demand assessment, approvals. +- **List & Search** + 1. Columns: State, City, District, Zone, Region, Area, Opportunity Type, Capacity, + Status, Open From, Open To, Last Updated. + 2. Quick actions: **Edit** + 3. Global search and multi-facet filters (Zone/Region/Area, State/City/District, Type, + Status). +- **Date-Range & Historical View** + 1. **Filter by From–To Date** to see which locations were open within a selected + window. + 2. Toggle **“Show only open during range”** or **“Show all with overlap”**. + 3. Export results (CSV/XLS) for audits and leadership review. + +**9.6.3 Depth** + +1. **Cascading Geography:** Selecting a **Zone** filters **Regions** ; selecting + a **Region** filters **Areas** ; **State/City/District** lists are bound to the chosen Area. +2. **Window Logic:** An opportunity is **Active** only within its **From–To** dates; the system auto- + marks **Closed** on expiry if _Auto-close_ is enabled. +3. **Status Lifecycle:** + o **Draft → Active → Inactive/Closed**. Inactive hides the location from the public + form; Closed retains history. +4. **Notifications:** When a window is **activated** or **closed** , notify mapped **DD-ZM/RBM** +5. **Historical Reporting:** + o Date filter computes **effective windows** (open or overlapping) within the selected + range and shows **who created/edited** , timestamps, and notes. + + +**9.6.4 Personas-wise Accessibility & Visibility** + +``` +Persona Accessibility Visibility +Admin / DD- +Admin +``` +``` +Create, edit, activate/deactivate, archive opportunities; +bulk upload; run exports; manage conflicts and capacity. Nationwide.^ +DD-Lead / DD- +Head / NBH +``` +``` +View dashboards and historical reports; download +exports. Nationwide.^ +ZBH / DD-ZM / +RBM +``` +``` +View opportunities for their Zone/Region ; receive +activation/closure notifications; capacity view. +``` +``` +Scoped to assigned +geographies. +ASM / DD-AM Read-only list for assigned Areas to plan ground activities. Area-level. +System (Public +Apply Form) +``` +``` +Shows only Active opportunities within current date and +capacity; hides inactive/closed ones. N/A^ +``` +**9.6.5 Validation & UX Notes** + +1. **Required:** Zone, Region, Area, Opportunity Type, From Date, To Date, Status. +2. **Date Checks:** _From_ must be ≤ _To_ ; warn if window is in the past; prevent zero-length + windows unless explicitly allowed. +3. **Timezone & Calendar:** Respect business calendar; holidays can be referenced for SLA tie- + ins. +4. **Inline Status Chips: Active (green)** , **Inactive (gray)** , **Closed (blue)** for quick scanning in the + list. +5. **Filter Presets:** _Currently Open_ , _Upcoming_ , _Expired_ , _My Zone_ for fast navigation. + +## 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. + +**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 person will login and fill his respective amount. + +**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 **Value** , which directly contributes to the Finance team’s + final calculation matrix. +- They will login with there respective account and fill the details. +- **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. 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 + +Finance users can add new line items with department tags and descriptions. +Each editable record auto-calculates 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 + Each record can be added, edited, or deleted before final review. + +``` +11.2.3.6 Deductions (Editable) +``` +Represents contingent deductions such as: + +- Pending warranty claims +- Policy violations +- Miscellaneous settlements + + +Each item’s description, department, and value 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 +``` +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 +``` +## 12 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. +``` +## 13 Technology Matrix + +``` +Component Specification +Database PGSQL (Managed or local instance) +Application Stack Node.js (Backend) + React.js (Frontend) +Authentication RE SSO Bridge +``` + +## 14 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. + +## 15 Not in scope + +Anything which comes beyond the scope defined above in terms of Width and depth + + diff --git a/backend/RE_Workflow_Backend_Setup.md b/backend/RE_Workflow_Backend_Setup.md new file mode 100644 index 0000000..795eb0d --- /dev/null +++ b/backend/RE_Workflow_Backend_Setup.md @@ -0,0 +1,1149 @@ +# RE Workflow Management System - Backend Setup Guide +**Version:** 1.0 +**Date:** October 16, 2025 +**Technology Stack:** Node.js 22 LTS + TypeScript 5.7 + Express.js 4.21 + PostgreSQL 16 + +--- + +## Table of Contents +1. [Backend Architecture Overview](#backend-architecture-overview) +2. [Technology Stack](#technology-stack) +3. [Project Folder Structure](#project-folder-structure) +4. [Database Schema Design](#database-schema-design) +5. [API Endpoints Structure](#api-endpoints-structure) +6. [Authentication & Security](#authentication-security) +7. [Configuration Management](#configuration-management) +8. [Deployment Architecture](#deployment-architecture) +9. [Development Setup Instructions](#development-setup-instructions) + +--- + +## 1. Backend Architecture Overview + +### High-Level Architecture + +``` +┌─────────────────────────────────────────────────────────────┐ +│ APPLICATION LAYER (Node.js) │ +│ - Express.js REST API Server │ +│ - Business Logic & Controllers │ +│ - Service Layer (Workflow, Notification, Document) │ +│ - AI Integration (Conclusion Generation) │ +│ - Authentication Middleware (JWT + SSO) │ +│ - Validation Layer (Zod) │ +└─────────────────────────────────────────────────────────────┘ + ↕ +┌─────────────────────────────────────────────────────────────┐ +│ DATA LAYER (PostgreSQL) │ +│ - Relational Database │ +│ - Stored Procedures & Functions │ +│ - Triggers for Activity Logging │ +│ - Indexes for Performance │ +└─────────────────────────────────────────────────────────────┘ + ↕ +┌─────────────────────────────────────────────────────────────┐ +│ STORAGE LAYER │ +│ - Cloud Storage (GCP Cloud Storage) │ +│ - Document Repository │ +│ - Backup & Recovery System │ +└─────────────────────────────────────────────────────────────┘ + ↕ +┌─────────────────────────────────────────────────────────────┐ +│ EXTERNAL SERVICES │ +│ - SSO Authentication Provider │ +│ - Email Service (SMTP) │ +│ - AI Service (OpenAI) │ +└─────────────────────────────────────────────────────────────┘ +``` + +--- + +## 2. Technology Stack + +| Component | Technology | Version | Purpose | +|-----------|-----------|---------|---------| +| **Backend Runtime** | Node.js | 22.x LTS | Server-side JavaScript runtime | +| **Backend Language** | TypeScript | 5.7.x | Type-safe backend development | +| **Backend Framework** | Express.js | 4.21.x | RESTful API framework | +| **Database** | PostgreSQL | 16.x | Primary relational database | +| **ORM** | Sequelize + TypeScript | 6.37.x | Database ORM with TypeScript support | +| **Authentication** | Passport.js | 0.7.x | SSO integration middleware | +| **Validation** | Zod | 3.24.x | TypeScript-first schema validation | +| **File Upload** | Multer | 1.4.x | Multipart file handling | +| **Logging** | Winston | 3.17.x | Application logging | +| **API Documentation** | Swagger/OpenAPI | 3.1 | API documentation | +| **Testing** | Jest + Supertest + ts-jest | 29.x | Unit & integration testing | +| **Process Manager** | PM2 | 5.4.x | Production process management | +| **Code Quality** | ESLint + Prettier + TypeScript ESLint | 9.x/3.x | Code linting & formatting | + +--- + +## 3. Project Folder Structure + +### Backend Repository (`re-workflow-backend`) + +``` +re-workflow-backend/ +│ +├── src/ # Source code +│ ├── app.ts +│ ├── server.ts +│ ├── types/ # TypeScript type definitions +│ │ ├── index.ts +│ │ ├── express.d.ts +│ │ ├── user.types.ts +│ │ ├── workflow.types.ts +│ │ ├── approval.types.ts +│ │ ├── document.types.ts +│ │ ├── notification.types.ts +│ │ └── common.types.ts +│ │ +│ ├── config/ # Configuration files +│ │ ├── database.ts +│ │ ├── jwt.ts +│ │ ├── sso.ts +│ │ ├── storage.ts +│ │ ├── email.ts +│ │ └── constants.ts +│ │ +│ ├── controllers/ # Request handlers +│ │ ├── auth.controller.ts +│ │ ├── workflow.controller.ts +│ │ ├── approval.controller.ts +│ │ ├── document.controller.ts +│ │ ├── notification.controller.ts +│ │ ├── workNote.controller.ts +│ │ ├── participant.controller.ts +│ │ ├── dashboard.controller.ts +│ │ └── user.controller.ts +│ │ +│ ├── services/ # Business logic layer +│ │ ├── auth.service.ts +│ │ ├── workflow.service.ts +│ │ ├── approval.service.ts +│ │ ├── tat.service.ts +│ │ ├── notification.service.ts +│ │ ├── document.service.ts +│ │ ├── workNote.service.ts +│ │ ├── participant.service.ts +│ │ ├── activity.service.ts +│ │ ├── ai.service.ts +│ │ ├── email.service.ts +│ │ └── storage.service.ts +│ │ +│ ├── models/ # Sequelize models (ORM) +│ │ ├── index.ts +│ │ ├── User.ts +│ │ ├── WorkflowRequest.ts +│ │ ├── ApprovalLevel.ts +│ │ ├── Approver.ts +│ │ ├── Participant.ts +│ │ ├── Spectator.ts +│ │ ├── Document.ts +│ │ ├── WorkNote.ts +│ │ ├── Activity.ts +│ │ ├── Notification.ts +│ │ ├── TATTracking.ts +│ │ └── ConclusionRemark.ts +│ │ +│ ├── routes/ # API route definitions +│ │ ├── index.ts +│ │ ├── auth.routes.ts +│ │ ├── workflow.routes.ts +│ │ ├── approval.routes.ts +│ │ ├── document.routes.ts +│ │ ├── notification.routes.ts +│ │ ├── workNote.routes.ts +│ │ ├── participant.routes.ts +│ │ ├── dashboard.routes.ts +│ │ └── user.routes.ts +│ │ +│ ├── middlewares/ # Express middlewares +│ │ ├── auth.middleware.ts +│ │ ├── sso.middleware.ts +│ │ ├── validate.middleware.ts +│ │ ├── upload.middleware.ts +│ │ ├── rateLimiter.middleware.ts +│ │ ├── errorHandler.middleware.ts +│ │ ├── logger.middleware.ts +│ │ └── cors.middleware.ts +│ │ +│ ├── validators/ # Request validation schemas (Zod) +│ │ ├── auth.validator.ts +│ │ ├── workflow.validator.ts +│ │ ├── approval.validator.ts +│ │ ├── document.validator.ts +│ │ ├── workNote.validator.ts +│ │ └── participant.validator.ts +│ │ +│ ├── utils/ # Utility functions +│ │ ├── logger.ts +│ │ ├── responseHandler.ts +│ │ ├── errorHandler.ts +│ │ ├── dateCalculator.ts +│ │ ├── fileValidator.ts +│ │ ├── emailTemplate.ts +│ │ └── helpers.ts +│ │ +│ ├── jobs/ # Background jobs & schedulers +│ │ ├── tatMonitor.job.ts +│ │ ├── reminderSender.job.ts +│ │ ├── dataCleanup.job.ts +│ │ └── reportGenerator.job.ts +│ │ +│ └── seeders/ # Database seed data +│ ├── admin.seeder.ts +│ └── testData.seeder.ts +│ +├── dist/ # Compiled JavaScript output +│ +├── tests/ # Test suites +│ ├── unit/ +│ │ ├── services/ +│ │ ├── controllers/ +│ │ └── utils/ +│ ├── integration/ +│ │ ├── api/ +│ │ └── database/ +│ └── setup.js +│ +├── database/ # Database Scripts & Migrations +│ ├── migrations/ +│ ├── seeders/ +│ ├── schema/ +│ │ └── schema.sql +│ └── README.md +│ +├── logs/ # Application logs +│ ├── error.log +│ ├── combined.log +│ └── access.log +│ +├── uploads/ # Temporary upload directory +│ └── .gitkeep +│ +├── docs/ # API Documentation +│ ├── swagger/ +│ └── postman/ +│ +├── scripts/ # Deployment & Utility Scripts +│ ├── deploy.sh +│ ├── backup.sh +│ ├── setup.sh +│ └── seed-db.sh +│ +├── .env.example +├── .env.development +├── .env.production +├── .eslintrc.json +├── .prettierrc +├── .gitignore +├── .dockerignore +├── Dockerfile +├── docker-compose.yml +├── jest.config.js +├── tsconfig.json +├── nodemon.json +├── package.json +├── package-lock.json +└── README.md +``` + +--- + +## 4. Key Backend Files + +### 4.1 TypeScript Configuration + +#### `tsconfig.json` +```json +{ + "compilerOptions": { + "target": "ES2021", + "module": "commonjs", + "lib": ["ES2021"], + "outDir": "./dist", + "rootDir": "./src", + "strict": true, + "esModuleInterop": true, + "skipLibCheck": true, + "forceConsistentCasingInFileNames": true, + "resolveJsonModule": true, + "moduleResolution": "node", + "declaration": true, + "declarationMap": true, + "sourceMap": true, + "noImplicitAny": true, + "strictNullChecks": true, + "strictFunctionTypes": true, + "noUnusedLocals": true, + "noUnusedParameters": true, + "noImplicitReturns": true, + "noFallthroughCasesInSwitch": true, + "types": ["node", "jest"], + "typeRoots": ["./node_modules/@types", "./src/types"], + "baseUrl": "./src", + "paths": { + "@/*": ["./*"], + "@controllers/*": ["controllers/*"], + "@services/*": ["services/*"], + "@models/*": ["models/*"], + "@middlewares/*": ["middlewares/*"], + "@utils/*": ["utils/*"], + "@types/*": ["types/*"], + "@config/*": ["config/*"] + } + }, + "include": ["src/**/*"], + "exclude": ["node_modules", "dist", "tests"] +} +``` + +### 4.2 Express Application + +#### `src/app.ts` +```typescript +import express, { Application, Request, Response } from 'express'; +import helmet from 'helmet'; +import cors from 'cors'; +import morgan from 'morgan'; +import routes from './routes'; +import errorHandler from './middlewares/errorHandler.middleware'; +import logger from './utils/logger'; + +const app: Application = express(); + +// Security middleware +app.use(helmet()); +app.use(cors()); + +// Body parsing middleware +app.use(express.json({ limit: '10mb' })); +app.use(express.urlencoded({ extended: true, limit: '10mb' })); + +// Logging middleware +app.use(morgan('combined', { stream: logger.stream })); + +// API routes +app.use('/api/v1', routes); + +// Health check endpoint +app.get('/health', (req: Request, res: Response) => { + res.status(200).json({ status: 'OK', timestamp: new Date() }); +}); + +// Error handling middleware (must be last) +app.use(errorHandler); + +export default app; +``` + +### 4.3 Server Entry Point + +#### `src/server.ts` +```typescript +import app from './app'; +import { sequelize } from './models'; +import logger from './utils/logger'; + +const PORT: number = parseInt(process.env.PORT || '5000', 10); + +// Database connection and server start +const startServer = async (): Promise => { + try { + // Test database connection + await sequelize.authenticate(); + logger.info('Database connection established successfully'); + + // Sync models (in development only) + if (process.env.NODE_ENV === 'development') { + await sequelize.sync({ alter: true }); + logger.info('Database models synchronized'); + } + + // Start server + app.listen(PORT, () => { + logger.info(`Server running on port ${PORT}`); + logger.info(`Environment: ${process.env.NODE_ENV}`); + }); + } catch (error) { + logger.error('Unable to start server:', error); + process.exit(1); + } +}; + +// Graceful shutdown +process.on('SIGTERM', async () => { + logger.info('SIGTERM signal received: closing HTTP server'); + await sequelize.close(); + process.exit(0); +}); + +startServer(); +``` + +### 4.4 Type Definitions + +#### `src/types/express.d.ts` +```typescript +import { JwtPayload } from 'jsonwebtoken'; + +declare global { + namespace Express { + interface Request { + user?: { + userId: string; + email: string; + employeeId: string; + role?: string; + }; + file?: Express.Multer.File; + files?: Express.Multer.File[]; + } + } +} +``` + +#### `src/types/common.types.ts` +```typescript +export enum Priority { + STANDARD = 'STANDARD', + EXPRESS = 'EXPRESS' +} + +export enum WorkflowStatus { + DRAFT = 'DRAFT', + PENDING = 'PENDING', + IN_PROGRESS = 'IN_PROGRESS', + APPROVED = 'APPROVED', + REJECTED = 'REJECTED', + CLOSED = 'CLOSED' +} + +export enum ApprovalStatus { + PENDING = 'PENDING', + IN_PROGRESS = 'IN_PROGRESS', + APPROVED = 'APPROVED', + REJECTED = 'REJECTED', + SKIPPED = 'SKIPPED' +} + +export enum ParticipantType { + SPECTATOR = 'SPECTATOR', + INITIATOR = 'INITIATOR', + APPROVER = 'APPROVER', + CONSULTATION = 'CONSULTATION' +} + +export enum TATStatus { + ON_TRACK = 'ON_TRACK', + APPROACHING = 'APPROACHING', + BREACHED = 'BREACHED' +} + +export interface ApiResponse { + success: boolean; + message: string; + data?: T; + error?: string; + timestamp: Date; +} + +export interface PaginationParams { + page: number; + limit: number; + sortBy?: string; + sortOrder?: 'ASC' | 'DESC'; +} + +export interface PaginatedResponse { + data: T[]; + pagination: { + page: number; + limit: number; + total: number; + totalPages: number; + }; +} +``` + +--- + +## 5. Database Schema Design + +[See Full Database Schema Section from Original Document] + +The database schema includes: +- `users` - User information from SSO +- `workflow_requests` - Main workflow requests +- `approval_levels` - Approval hierarchy +- `participants` - Spectators and participants +- `documents` - Document metadata +- `work_notes` - Communication within workflow +- `activities` - Activity log +- `notifications` - User notifications +- `tat_tracking` - TAT monitoring +- `conclusion_remarks` - AI-generated conclusions +- `audit_logs` - System audit trail +- `system_settings` - Application configuration + +--- + +## 6. API Endpoints Structure + +### Base URL: `http://api.re-workflow.com/api/v1` + +### 6.1 Authentication APIs +``` +POST /auth/login +POST /auth/callback +POST /auth/logout +GET /auth/me +POST /auth/refresh +``` + +### 6.2 Workflow Management APIs +``` +GET /workflows +POST /workflows +GET /workflows/:id +PUT /workflows/:id +DELETE /workflows/:id +PATCH /workflows/:id/submit +PATCH /workflows/:id/close +GET /workflows/my-requests +GET /workflows/open +GET /workflows/closed +GET /workflows/assigned-to-me +``` + +### 6.3 Approval APIs +``` +GET /workflows/:id/approvals +POST /workflows/:id/approvals +PATCH /workflows/:id/approvals/:levelId/approve +PATCH /workflows/:id/approvals/:levelId/reject +GET /workflows/:id/approvals/current +``` + +### 6.4 Participant APIs +``` +GET /workflows/:id/participants +POST /workflows/:id/participants +DELETE /workflows/:id/participants/:participantId +GET /workflows/:id/spectators +``` + +### 6.5 Document APIs +``` +GET /workflows/:id/documents +POST /workflows/:id/documents +GET /documents/:documentId +GET /documents/:documentId/download +DELETE /documents/:documentId +GET /documents/:documentId/preview +``` + +### 6.6 Work Notes APIs +``` +GET /workflows/:id/work-notes +POST /workflows/:id/work-notes +PUT /work-notes/:noteId +DELETE /work-notes/:noteId +POST /work-notes/:noteId/reactions +POST /work-notes/:noteId/attachments +``` + +### 6.7 Activity Log APIs +``` +GET /workflows/:id/activities +GET /workflows/:id/activities/:type +``` + +### 6.8 Notification APIs +``` +GET /notifications +GET /notifications/unread +PATCH /notifications/:id/read +PATCH /notifications/mark-all-read +DELETE /notifications/:id +``` + +### 6.9 TAT Tracking APIs +``` +GET /workflows/:id/tat +GET /tat/breached +GET /tat/approaching +``` + +### 6.10 Dashboard APIs +``` +GET /dashboard/stats +GET /dashboard/recent +GET /dashboard/pending-actions +``` + +### 6.11 User Management APIs +``` +GET /users +GET /users/search +GET /users/:id +GET /users/:id/requests +``` + +### 6.12 Conclusion APIs +``` +POST /workflows/:id/conclusion/generate +PUT /workflows/:id/conclusion +GET /workflows/:id/conclusion +``` + +--- + +## 7. Authentication & Security + +### 7.1 SSO Integration Configuration + +```typescript +// src/config/sso.ts +export interface SSOConfig { + ssoProvider: string; + authorizationURL: string; + tokenURL: string; + userInfoURL: string; + clientID: string; + clientSecret: string; + callbackURL: string; + scope: string[]; + sessionSecret: string; + jwtSecret: string; + jwtExpiry: string; + refreshTokenExpiry: string; +} + +const ssoConfig: SSOConfig = { + ssoProvider: 'RE_SSO_BRIDGE', + authorizationURL: process.env.SSO_AUTHORIZATION_URL || '', + tokenURL: process.env.SSO_TOKEN_URL || '', + userInfoURL: process.env.SSO_USERINFO_URL || '', + clientID: process.env.SSO_CLIENT_ID || '', + clientSecret: process.env.SSO_CLIENT_SECRET || '', + callbackURL: process.env.SSO_CALLBACK_URL || '', + scope: ['openid', 'profile', 'email'], + sessionSecret: process.env.SESSION_SECRET || '', + jwtSecret: process.env.JWT_SECRET || '', + jwtExpiry: '24h', + refreshTokenExpiry: '7d' +}; + +export default ssoConfig; +``` + +### 7.2 Security Measures + +| Security Layer | Implementation | +|----------------|----------------| +| **Transport Security** | HTTPS/TLS 1.3 | +| **Authentication** | SSO + JWT tokens | +| **Authorization** | Role-based access control (RBAC) | +| **Password Encryption** | bcrypt (cost factor 12) | +| **Token Storage** | HTTP-only cookies + Local storage | +| **CSRF Protection** | CSRF tokens on state-changing operations | +| **XSS Protection** | Input sanitization + Content Security Policy | +| **SQL Injection** | Parameterized queries (Sequelize ORM) | +| **Rate Limiting** | Express rate limiter (100 req/15min) | +| **File Upload Security** | Type validation, size limits, virus scanning | +| **Audit Logging** | All actions logged with user context | +| **Data Encryption** | At-rest (database) and in-transit (TLS) | + +--- + +## 8. Configuration Management + +### 8.1 Environment Variables + +```bash +# backend/.env.example + +# Application +NODE_ENV=development +PORT=5000 +API_VERSION=v1 +BASE_URL=http://localhost:5000 + +# Database +DB_HOST=localhost +DB_PORT=5432 +DB_NAME=re_workflow_db +DB_USER=workflow_user +DB_PASSWORD=secure_password +DB_SSL=false +DB_POOL_MIN=2 +DB_POOL_MAX=10 + +# SSO Configuration +SSO_AUTHORIZATION_URL=https://sso.royalenfield.com/oauth/authorize +SSO_TOKEN_URL=https://sso.royalenfield.com/oauth/token +SSO_USERINFO_URL=https://sso.royalenfield.com/oauth/userinfo +SSO_CLIENT_ID=re_workflow_client +SSO_CLIENT_SECRET=your_sso_client_secret +SSO_CALLBACK_URL=http://localhost:5000/api/v1/auth/callback + +# JWT Configuration +JWT_SECRET=your_jwt_secret_key_here_min_32_chars +JWT_EXPIRY=24h +REFRESH_TOKEN_SECRET=your_refresh_token_secret_here +REFRESH_TOKEN_EXPIRY=7d + +# Session +SESSION_SECRET=your_session_secret_here_min_32_chars + +# Cloud Storage (GCP) +GCP_PROJECT_ID=re-workflow-project +GCP_BUCKET_NAME=re-workflow-documents +GCP_KEY_FILE=./config/gcp-key.json + +# Email Service (Optional) +SMTP_HOST=smtp.gmail.com +SMTP_PORT=587 +SMTP_SECURE=false +SMTP_USER=notifications@royalenfield.com +SMTP_PASSWORD=your_smtp_password +EMAIL_FROM=RE Workflow System + +# AI Service (for conclusion generation) +AI_API_KEY=your_ai_api_key +AI_MODEL=gpt-4 +AI_MAX_TOKENS=500 + +# Logging +LOG_LEVEL=info +LOG_FILE_PATH=./logs + +# CORS +CORS_ORIGIN=http://localhost:3000 + +# Rate Limiting +RATE_LIMIT_WINDOW_MS=900000 +RATE_LIMIT_MAX_REQUESTS=100 + +# File Upload +MAX_FILE_SIZE_MB=10 +ALLOWED_FILE_TYPES=pdf,doc,docx,xls,xlsx,ppt,pptx,jpg,jpeg,png,gif + +# TAT Monitoring +TAT_CHECK_INTERVAL_MINUTES=30 +TAT_REMINDER_THRESHOLD_1=50 +TAT_REMINDER_THRESHOLD_2=80 +``` + +--- + +## 9. Deployment Architecture + +### 9.1 Docker Compose for Local Development + +```yaml +# docker-compose.yml +version: '3.8' + +services: + postgres: + image: postgres:16-alpine + container_name: re_workflow_db + environment: + POSTGRES_USER: ${DB_USER:-workflow_user} + POSTGRES_PASSWORD: ${DB_PASSWORD:-secure_password} + POSTGRES_DB: ${DB_NAME:-re_workflow_db} + ports: + - "5432:5432" + volumes: + - postgres_data:/var/lib/postgresql/data + - ./database/schema:/docker-entrypoint-initdb.d + networks: + - re_workflow_network + restart: unless-stopped + healthcheck: + test: ["CMD-SHELL", "pg_isready -U ${DB_USER:-workflow_user}"] + interval: 10s + timeout: 5s + retries: 5 + + backend: + build: + context: . + dockerfile: Dockerfile + container_name: re_workflow_backend + environment: + NODE_ENV: development + DB_HOST: postgres + DB_PORT: 5432 + DB_USER: ${DB_USER:-workflow_user} + DB_PASSWORD: ${DB_PASSWORD:-secure_password} + DB_NAME: ${DB_NAME:-re_workflow_db} + PORT: 5000 + ports: + - "5000:5000" + depends_on: + postgres: + condition: service_healthy + volumes: + - ./logs:/app/logs + - ./uploads:/app/uploads + networks: + - re_workflow_network + restart: unless-stopped + +volumes: + postgres_data: + +networks: + re_workflow_network: + driver: bridge +``` + +### 9.2 Dockerfile + +```dockerfile +# Dockerfile + +FROM node:22-alpine AS builder + +WORKDIR /app + +# Copy package files +COPY package*.json ./ +COPY tsconfig.json ./ + +# Install all dependencies (including devDependencies for build) +RUN npm ci + +# Copy source code +COPY src ./src + +# Build TypeScript to JavaScript +RUN npm run build + +# ===================================== +# Production Image +# ===================================== +FROM node:22-alpine + +WORKDIR /app + +# Install PM2 globally +RUN npm install -g pm2 + +# Copy package files +COPY package*.json ./ + +# Install only production dependencies +RUN npm ci --only=production + +# Copy compiled JavaScript from builder +COPY --from=builder /app/dist ./dist + +# Create logs and uploads directories +RUN mkdir -p logs uploads + +# Expose port +EXPOSE 5000 + +# Health check +HEALTHCHECK --interval=30s --timeout=10s --start-period=40s --retries=3 \ + CMD node -e "require('http').get('http://localhost:5000/health', (r) => {process.exit(r.statusCode === 200 ? 0 : 1)})" + +# Start with PM2 +CMD ["pm2-runtime", "start", "dist/server.js", "--name", "re-workflow-api"] +``` + +### 9.3 CI/CD Pipeline (GitHub Actions) + +```yaml +# .github/workflows/backend-deploy.yml + +name: Backend CI/CD + +on: + push: + branches: [main, develop] + pull_request: + branches: [main] + +jobs: + test-and-build: + runs-on: ubuntu-latest + steps: + - uses: actions/checkout@v4 + + - name: Setup Node.js + uses: actions/setup-node@v4 + with: + node-version: '22' + + - name: Install dependencies + run: npm ci + + - name: Run linter + run: npm run lint + + - name: Run tests + run: npm test + + - name: Build TypeScript + run: npm run build + + - name: Build Docker image + run: docker build -t gcr.io/re-project/re-workflow-backend:${{ github.sha }} . + + - name: Push to GCR + run: docker push gcr.io/re-project/re-workflow-backend:${{ github.sha }} +``` + +--- + +## 10. Development Setup Instructions + +### 10.1 Prerequisites + +- **Node.js:** v22.x LTS +- **PostgreSQL:** v16.x +- **npm:** v10.x or higher +- **TypeScript:** v5.7.x (installed globally or as dev dependency) +- **Git:** Latest version +- **Docker & Docker Compose** (Optional) +- **GCP Account** (for cloud storage in production) + +### 10.2 Local Development Setup + +#### Step 1: Clone Repository + +```bash +git clone https://github.com/royalenfield/re-workflow-backend.git +cd re-workflow-backend +``` + +#### Step 2: Setup Database + +```bash +# Install PostgreSQL (if not installed) +# For Ubuntu/Debian: +# sudo apt-get install postgresql-16 + +# For macOS: +# brew install postgresql@16 + +# Create database +createdb re_workflow_db + +# Or using psql: +psql -U postgres +CREATE DATABASE re_workflow_db; +\q + +# Run schema +psql -U postgres -d re_workflow_db -f database/schema/schema.sql +``` + +#### Step 3: Configure Environment + +```bash +# Copy environment file +cp .env.example .env + +# Edit .env with your configurations +nano .env # or use your preferred editor + +# Required variables: +# - Database credentials +# - JWT secrets +# - SSO configuration +# - GCP storage keys +``` + +#### Step 4: Install Dependencies & Run + +```bash +# Install dependencies +npm install + +# Run TypeScript type checking +npm run type-check + +# Run migrations (if using Sequelize CLI) +npx sequelize-cli db:migrate + +# Seed data (optional) +npx sequelize-cli db:seed:all + +# Start development server (with hot reload) +npm run dev + +# Backend will run on: http://localhost:5000 +# API Documentation: http://localhost:5000/api-docs +``` + +### 10.3 Docker Setup + +```bash +# From backend repository root +cd re-workflow-backend + +# Copy environment file +cp .env.example .env + +# Edit .env if needed +nano .env + +# Build and start services (backend + PostgreSQL) +docker-compose up --build -d + +# Check logs +docker-compose logs -f + +# Access backend: http://localhost:5000 + +# Stop services +docker-compose down + +# Stop and remove volumes (clean state) +docker-compose down -v +``` + +### 10.4 Running Tests + +```bash +# From backend repository +cd re-workflow-backend + +npm test # Run all tests (Jest + ts-jest) +npm run test:unit # Unit tests only +npm run test:integration # Integration tests only +npm run test:watch # Watch mode for development +npm run test:coverage # With coverage report + +# Coverage report will be in: coverage/ +# View HTML report: open coverage/lcov-report/index.html +``` + +### 10.5 Code Quality Checks + +```bash +# From backend repository +cd re-workflow-backend + +npm run lint # ESLint check (TypeScript rules) +npm run lint:fix # Auto-fix issues +npm run format # Prettier formatting +npm run type-check # TypeScript type checking only (no compilation) + +# Run all quality checks together +npm run lint && npm run type-check && npm test +``` + +--- + +## 11. Package.json + +```json +{ + "name": "re-workflow-backend", + "version": "1.0.0", + "description": "Royal Enfield Workflow Management System - Backend API (TypeScript)", + "main": "dist/server.js", + "scripts": { + "start": "node dist/server.js", + "dev": "nodemon --exec ts-node src/server.ts", + "build": "tsc", + "build:watch": "tsc --watch", + "start:prod": "NODE_ENV=production node dist/server.js", + "test": "jest --coverage", + "test:unit": "jest --testPathPattern=tests/unit", + "test:integration": "jest --testPathPattern=tests/integration", + "test:watch": "jest --watch", + "lint": "eslint src/**/*.ts", + "lint:fix": "eslint src/**/*.ts --fix", + "format": "prettier --write \"src/**/*.ts\"", + "type-check": "tsc --noEmit", + "db:migrate": "sequelize-cli db:migrate", + "db:migrate:undo": "sequelize-cli db:migrate:undo", + "db:seed": "sequelize-cli db:seed:all", + "clean": "rm -rf dist" + }, + "dependencies": { + "express": "^4.21.2", + "pg": "^8.13.1", + "pg-hstore": "^2.3.4", + "sequelize": "^6.37.5", + "bcryptjs": "^2.4.3", + "jsonwebtoken": "^9.0.2", + "passport": "^0.7.0", + "passport-jwt": "^4.0.1", + "zod": "^3.24.1", + "multer": "^1.4.5-lts.1", + "winston": "^3.17.0", + "cors": "^2.8.5", + "helmet": "^8.0.0", + "dotenv": "^16.4.7", + "express-rate-limit": "^7.5.0", + "morgan": "^1.10.0", + "@google-cloud/storage": "^7.14.0", + "axios": "^1.7.9", + "node-cron": "^3.0.3" + }, + "devDependencies": { + "@types/express": "^5.0.0", + "@types/node": "^22.10.5", + "@types/bcryptjs": "^2.4.6", + "@types/jsonwebtoken": "^9.0.7", + "@types/passport": "^1.0.16", + "@types/passport-jwt": "^4.0.1", + "@types/multer": "^1.4.12", + "@types/cors": "^2.8.17", + "@types/morgan": "^1.9.9", + "@types/jest": "^29.5.14", + "@types/supertest": "^6.0.2", + "typescript": "^5.7.2", + "ts-node": "^10.9.2", + "ts-node-dev": "^2.0.0", + "nodemon": "^3.1.9", + "jest": "^29.7.0", + "ts-jest": "^29.2.5", + "supertest": "^7.0.0", + "eslint": "^9.17.0", + "@typescript-eslint/eslint-plugin": "^8.19.1", + "@typescript-eslint/parser": "^8.19.1", + "prettier": "^3.4.2", + "sequelize-cli": "^6.6.2", + "sequelize-typescript": "^2.1.7" + }, + "engines": { + "node": ">=22.0.0", + "npm": ">=10.0.0" + } +} +``` + +--- + +## Summary + +This backend documentation provides: + +✅ **Complete Backend Architecture** - Server structure, layers, and components +✅ **Technology Stack** - Node.js 22 LTS + TypeScript 5.7 + PostgreSQL 16 +✅ **Folder Structure** - Detailed organization with TypeScript conventions +✅ **Type Definitions** - Comprehensive type safety with interfaces and enums +✅ **Database Schema** - Full PostgreSQL schema with tables, indexes, triggers +✅ **API Specification** - RESTful endpoints for all features +✅ **Security Implementation** - SSO, JWT, encryption, audit trails +✅ **Configuration Management** - Environment variables and settings +✅ **Deployment Architecture** - Docker, docker-compose, CI/CD pipelines +✅ **Development Setup** - Step-by-step installation and configuration +✅ **Testing Strategy** - Unit and integration testing with ts-jest +✅ **Code Quality** - ESLint, Prettier, TypeScript best practices + +**Technology Stack:** Node.js 22 LTS + TypeScript 5.7 + Express.js 4.21 + PostgreSQL 16 +**Repository:** `re-workflow-backend` (Independent Repository) +**Status:** ✅ Ready for Implementation + diff --git a/backend/dealer_onboard_backend_schema.mermaid b/backend/dealer_onboard_backend_schema.mermaid new file mode 100644 index 0000000..f442038 --- /dev/null +++ b/backend/dealer_onboard_backend_schema.mermaid @@ -0,0 +1,947 @@ +erDiagram + %% ============================================ + %% DEALER ONBOARDING BACKEND SCHEMA + %% Based on Re_New_Dealer_Onboard.md + %% Comprehensive Database Schema Design + %% ============================================ + + %% ============================================ + %% USER MANAGEMENT & AUTHENTICATION + %% ============================================ + USERS { + uuid user_id PK + string employee_id UK + string email UK + string full_name + string mobile_number + string department + string designation + string role_code FK + uuid zone_id FK + uuid region_id FK + uuid area_id FK + boolean is_active + boolean is_external + string sso_provider + string sso_user_id + timestamp last_login + timestamp created_at + timestamp updated_at + } + + ROLES { + uuid role_id PK + string role_code UK + string role_name + string description + string category + boolean is_active + timestamp created_at + timestamp updated_at + } + + PERMISSIONS { + uuid permission_id PK + string permission_code UK + string permission_name + string module + string action + string description + timestamp created_at + } + + ROLE_PERMISSIONS { + uuid role_permission_id PK + uuid role_id FK + uuid permission_id FK + boolean can_view + boolean can_create + boolean can_edit + boolean can_delete + boolean can_approve + timestamp created_at + } + + USER_ROLES { + uuid user_role_id PK + uuid user_id FK + uuid role_id FK + uuid zone_id FK + uuid region_id FK + uuid area_id FK + timestamp assigned_at + uuid assigned_by FK + timestamp created_at + } + + %% ============================================ + %% ORGANIZATIONAL HIERARCHY + %% ============================================ + ZONES { + uuid zone_id PK + string zone_code UK + string zone_name + string description + boolean is_active + timestamp created_at + timestamp updated_at + } + + REGIONS { + uuid region_id PK + uuid zone_id FK + string region_code UK + string region_name + string state + string description + boolean is_active + timestamp created_at + timestamp updated_at + } + + AREAS { + uuid area_id PK + uuid region_id FK + string area_code UK + string area_name + string district + string city + string pincode + boolean is_active + timestamp created_at + timestamp updated_at + } + + ZONE_MANAGERS { + uuid zone_manager_id PK + uuid zone_id FK + uuid user_id FK + string manager_type + boolean is_active + timestamp assigned_at + timestamp created_at + } + + REGION_MANAGERS { + uuid region_manager_id PK + uuid region_id FK + uuid user_id FK + string manager_type + boolean is_active + timestamp assigned_at + timestamp created_at + } + + AREA_MANAGERS { + uuid area_manager_id PK + uuid area_id FK + uuid user_id FK + string manager_type + boolean is_active + timestamp assigned_at + timestamp created_at + } + + %% ============================================ + %% OPPORTUNITY MANAGEMENT + %% ============================================ + OPPORTUNITIES { + uuid opportunity_id PK + uuid zone_id FK + uuid region_id FK + uuid area_id FK + string state + string city + string district + string opportunity_type + integer capacity + string priority + date open_from + date open_to + string status + text notes + uuid created_by FK + timestamp created_at + timestamp updated_at + } + + %% ============================================ + %% DEALER APPLICATION + %% ============================================ + APPLICATIONS { + uuid application_id PK + string registration_number UK + string applicant_name + string email UK + string mobile_number + integer age + string country + string state + string district + string pincode + string interested_city + string company_name + string education_qualification + boolean owns_re_bike + boolean is_existing_dealer + text address + text description + string preferred_location + string application_status + string opportunity_status + uuid zone_id FK + uuid region_id FK + uuid area_id FK + uuid assigned_dd_zm FK + uuid assigned_rbm FK + timestamp submitted_at + timestamp created_at + timestamp updated_at + } + + %% ============================================ + %% QUESTIONNAIRE MANAGEMENT + %% ============================================ + QUESTIONNAIRES { + uuid questionnaire_id PK + string questionnaire_code UK + string version + string title + text description + boolean is_active + uuid created_by FK + timestamp created_at + timestamp updated_at + } + + QUESTIONNAIRE_SECTIONS { + uuid section_id PK + uuid questionnaire_id FK + string section_name + string section_type + integer section_order + decimal section_weightage + boolean is_active + timestamp created_at + } + + QUESTIONNAIRE_QUESTIONS { + uuid question_id PK + uuid section_id FK + string question_text + string question_type + integer question_order + decimal question_weightage + json options + boolean is_mandatory + boolean is_active + timestamp created_at + timestamp updated_at + } + + QUESTIONNAIRE_RESPONSES { + uuid response_id PK + uuid application_id FK + uuid questionnaire_id FK + uuid question_id FK + text response_text + json response_data + decimal score_obtained + decimal max_score + timestamp submitted_at + timestamp created_at + timestamp updated_at + } + + QUESTIONNAIRE_SCORES { + uuid score_id PK + uuid application_id FK + uuid questionnaire_id FK + decimal total_score + decimal max_score + decimal percentage_score + integer rank_in_city + integer rank_in_region + timestamp calculated_at + timestamp created_at + timestamp updated_at + } + + %% ============================================ + %% INTERVIEW MANAGEMENT + %% ============================================ + INTERVIEWS { + uuid interview_id PK + uuid application_id FK + integer interview_level + string interview_type + string interview_mode + date interview_date + time interview_time + string meeting_link + string venue_address + string status + uuid scheduled_by FK + timestamp scheduled_at + timestamp created_at + timestamp updated_at + } + + INTERVIEW_PARTICIPANTS { + uuid participant_id PK + uuid interview_id FK + uuid user_id FK + string participant_role + boolean is_required + boolean has_attended + timestamp created_at + } + + INTERVIEW_EVALUATIONS { + uuid evaluation_id PK + uuid interview_id FK + uuid application_id FK + uuid evaluator_id FK + integer interview_level + decimal kt_matrix_score + decimal feedback_score + decimal overall_score + string recommendation + text remarks + text feedback_summary + timestamp submitted_at + timestamp created_at + timestamp updated_at + } + + KT_MATRIX_SCORES { + uuid kt_score_id PK + uuid evaluation_id FK + string parameter_name + decimal parameter_weightage + decimal score_obtained + text remarks + timestamp created_at + } + + INTERVIEW_FEEDBACK { + uuid feedback_id PK + uuid evaluation_id FK + string feedback_category + text feedback_text + decimal category_score + timestamp created_at + } + + AI_SUMMARIES { + uuid summary_id PK + uuid application_id FK + integer interview_level + text ai_generated_summary + text nbh_edited_summary + boolean is_approved + uuid approved_by FK + timestamp generated_at + timestamp approved_at + timestamp created_at + timestamp updated_at + } + + %% ============================================ + %% WORK NOTES & COMMUNICATION + %% ============================================ + WORK_NOTES { + uuid work_note_id PK + uuid application_id FK + uuid created_by FK + text note_content + json tagged_users + json attachments + string note_type + uuid parent_note_id FK + boolean is_internal + boolean is_deleted + timestamp created_at + timestamp updated_at + } + + WORK_NOTE_TAGS { + uuid tag_id PK + uuid work_note_id FK + uuid tagged_user_id FK + boolean is_notified + timestamp notified_at + timestamp created_at + } + + WORK_NOTE_ATTACHMENTS { + uuid attachment_id PK + uuid work_note_id FK + uuid document_id FK + timestamp created_at + } + + %% ============================================ + %% DOCUMENT MANAGEMENT + %% ============================================ + DOCUMENTS { + uuid document_id PK + uuid application_id FK + uuid uploaded_by FK + string document_type + string document_category + string file_name + string file_type + bigint file_size + string file_path + string storage_url + string mime_type + integer version + string status + uuid verified_by FK + timestamp verified_at + boolean is_deleted + timestamp uploaded_at + timestamp created_at + timestamp updated_at + } + + DOCUMENT_VERSIONS { + uuid version_id PK + uuid document_id FK + integer version_number + string file_path + string storage_url + uuid uploaded_by FK + timestamp uploaded_at + timestamp created_at + } + + LOI_DOCUMENTS { + uuid loi_doc_id PK + uuid application_id FK + string document_name + string document_type + uuid document_id FK + boolean is_mandatory + boolean is_uploaded + boolean is_verified + timestamp required_at + timestamp uploaded_at + timestamp verified_at + } + + STATUTORY_DOCUMENTS { + uuid statutory_doc_id PK + uuid application_id FK + string document_name + string document_type + uuid document_id FK + boolean is_mandatory + boolean is_uploaded + boolean is_verified + uuid verified_by FK + timestamp verified_at + timestamp created_at + } + + %% ============================================ + %% FDD PROCESS + %% ============================================ + FDD_ASSIGNMENTS { + uuid fdd_assignment_id PK + uuid application_id FK + uuid fdd_user_id FK + string assignment_status + date assigned_at + date due_date + timestamp created_at + timestamp updated_at + } + + FDD_REPORTS { + uuid fdd_report_id PK + uuid fdd_assignment_id FK + uuid application_id FK + string report_type + string report_level + uuid document_id FK + text remarks + string status + timestamp submitted_at + timestamp created_at + timestamp updated_at + } + + %% ============================================ + %% LOI PROCESS + %% ============================================ + LOI_REQUESTS { + uuid loi_request_id PK + uuid application_id FK + string request_status + date document_request_date + date security_deposit_request_date + boolean documents_complete + boolean security_deposit_verified + timestamp created_at + timestamp updated_at + } + + LOI_APPROVALS { + uuid loi_approval_id PK + uuid loi_request_id FK + uuid application_id FK + integer approval_level + uuid approver_id FK + string approval_status + text approval_remarks + timestamp approved_at + timestamp created_at + timestamp updated_at + } + + LOI_DOCUMENTS_GENERATED { + uuid loi_doc_gen_id PK + uuid application_id FK + uuid loi_request_id FK + uuid document_id FK + date issue_date + uuid authorized_signatory FK + string document_version + timestamp generated_at + timestamp uploaded_at + } + + LOI_ACKNOWLEDGEMENTS { + uuid loi_ack_id PK + uuid application_id FK + uuid loi_doc_gen_id FK + uuid document_id FK + timestamp acknowledged_at + timestamp created_at + } + + %% ============================================ + %% SECURITY DEPOSIT + %% ============================================ + SECURITY_DEPOSITS { + uuid deposit_id PK + uuid application_id FK + decimal deposit_amount + string payment_mode + string transaction_id + date transaction_date + string bank_name + string account_number + uuid proof_document_id FK + string verification_status + uuid verified_by FK + timestamp verified_at + text verification_remarks + timestamp created_at + timestamp updated_at + } + + %% ============================================ + %% DEALER CODE GENERATION + %% ============================================ + DEALER_CODES { + uuid dealer_code_id PK + uuid application_id FK + string dealer_code UK + string sales_code + string service_code + string gma_code + string gear_code + string sap_dealer_id + boolean is_active + timestamp generated_at + uuid generated_by FK + timestamp created_at + timestamp updated_at + } + + %% ============================================ + %% ARCHITECTURAL WORK + %% ============================================ + ARCHITECTURAL_ASSIGNMENTS { + uuid arch_assignment_id PK + uuid application_id FK + uuid assigned_to_team FK + string assignment_status + date assigned_at + date due_date + timestamp created_at + timestamp updated_at + } + + ARCHITECTURAL_DOCUMENTS { + uuid arch_doc_id PK + uuid arch_assignment_id FK + uuid application_id FK + string document_type + uuid document_id FK + string layout_type + boolean dealer_consent_received + date consent_date + timestamp uploaded_at + timestamp created_at + } + + CONSTRUCTION_PROGRESS { + uuid progress_id PK + uuid application_id FK + string progress_type + text progress_description + uuid document_id FK + integer progress_percentage + timestamp reported_at + timestamp created_at + } + + %% ============================================ + %% EOR CHECKLIST + %% ============================================ + EOR_CHECKLISTS { + uuid eor_checklist_id PK + uuid application_id FK + string checklist_name + string status + integer total_items + integer completed_items + integer percentage_complete + timestamp created_at + timestamp updated_at + } + + EOR_CHECKLIST_ITEMS { + uuid eor_item_id PK + uuid eor_checklist_id FK + string item_name + string item_category + string responsible_team + string status + text remarks + uuid verified_by FK + timestamp verified_at + timestamp created_at + timestamp updated_at + } + + %% ============================================ + %% LOA PROCESS + %% ============================================ + LOA_REQUESTS { + uuid loa_request_id PK + uuid application_id FK + string request_status + boolean eor_complete + timestamp created_at + timestamp updated_at + } + + LOA_APPROVALS { + uuid loa_approval_id PK + uuid loa_request_id FK + uuid application_id FK + uuid approver_id FK + string approval_status + text approval_remarks + timestamp approved_at + timestamp created_at + timestamp updated_at + } + + LOA_DOCUMENTS_GENERATED { + uuid loa_doc_gen_id PK + uuid application_id FK + uuid loa_request_id FK + uuid document_id FK + date issue_date + uuid authorized_signatory FK + string document_version + timestamp generated_at + timestamp uploaded_at + } + + %% ============================================ + %% INAUGURATION + %% ============================================ + INAUGURATIONS { + uuid inauguration_id PK + uuid application_id FK + date inauguration_date + string venue + text event_summary + uuid organized_by FK + string status + timestamp created_at + timestamp updated_at + } + + INAUGURATION_ATTENDEES { + uuid attendee_id PK + uuid inauguration_id FK + uuid user_id FK + string attendee_role + boolean is_confirmed + timestamp created_at + } + + INAUGURATION_DOCUMENTS { + uuid inauguration_doc_id PK + uuid inauguration_id FK + uuid document_id FK + string document_type + timestamp uploaded_at + } + + %% ============================================ + %% NOTIFICATIONS + %% ============================================ + NOTIFICATIONS { + uuid notification_id PK + uuid user_id FK + uuid application_id FK + string notification_type + string title + text message + string priority + boolean is_read + json metadata + timestamp read_at + timestamp created_at + } + + EMAIL_LOGS { + uuid email_log_id PK + uuid application_id FK + uuid user_id FK + string email_type + string recipient_email + string subject + text email_body + string status + text error_message + timestamp sent_at + timestamp created_at + } + + WHATSAPP_LOGS { + uuid whatsapp_log_id PK + uuid application_id FK + string recipient_number + string message_type + text message_content + string status + text error_message + timestamp sent_at + timestamp created_at + } + + %% ============================================ + %% SLA & TAT TRACKING + %% ============================================ + SLA_CONFIGURATIONS { + uuid sla_config_id PK + string activity_name + string owner_role + integer tat_hours + string tat_unit + json pre_tat_reminders + json escalation_levels + boolean is_active + timestamp created_at + timestamp updated_at + } + + SLA_TRACKING { + uuid sla_tracking_id PK + uuid application_id FK + uuid sla_config_id FK + string activity_name + uuid owner_id FK + timestamp start_time + timestamp due_time + timestamp completed_time + string status + integer completion_percentage + timestamp created_at + timestamp updated_at + } + + SLA_ESCALATIONS { + uuid escalation_id PK + uuid sla_tracking_id FK + integer escalation_level + uuid escalated_to FK + text escalation_reason + timestamp escalated_at + timestamp resolved_at + } + + %% ============================================ + %% EMAIL TEMPLATES + %% ============================================ + EMAIL_TEMPLATES { + uuid template_id PK + string template_name UK + string template_code UK + string subject + text template_body + string trigger_event + json system_variables + boolean is_active + string version + timestamp created_at + timestamp updated_at + } + + %% ============================================ + %% AUDIT TRAIL + %% ============================================ + AUDIT_LOGS { + uuid audit_log_id PK + uuid application_id FK + uuid user_id FK + string action_type + string entity_type + uuid entity_id + text description + json before_state + json after_state + json metadata + string ip_address + string user_agent + timestamp created_at + } + + ACTIVITY_LOGS { + uuid activity_id PK + uuid application_id FK + uuid user_id FK + string activity_type + text activity_description + json activity_data + timestamp created_at + } + + %% ============================================ + %% APPLICATION STATUS TRACKING + %% ============================================ + APPLICATION_STATUS_HISTORY { + uuid status_history_id PK + uuid application_id FK + string previous_status + string new_status + uuid changed_by FK + text change_reason + timestamp changed_at + } + + APPLICATION_PROGRESS { + uuid progress_id PK + uuid application_id FK + string stage_name + integer stage_order + string status + integer completion_percentage + timestamp stage_started_at + timestamp stage_completed_at + timestamp created_at + timestamp updated_at + } + + %% ============================================ + %% RELATIONSHIPS + %% ============================================ + USERS ||--o{ USER_ROLES : "has" + ROLES ||--o{ USER_ROLES : "assigned_to" + ROLES ||--o{ ROLE_PERMISSIONS : "has" + PERMISSIONS ||--o{ ROLE_PERMISSIONS : "granted_in" + + ZONES ||--o{ REGIONS : "contains" + REGIONS ||--o{ AREAS : "contains" + ZONES ||--o{ ZONE_MANAGERS : "managed_by" + REGIONS ||--o{ REGION_MANAGERS : "managed_by" + AREAS ||--o{ AREA_MANAGERS : "managed_by" + USERS ||--o{ ZONE_MANAGERS : "is" + USERS ||--o{ REGION_MANAGERS : "is" + USERS ||--o{ AREA_MANAGERS : "is" + + ZONES ||--o{ OPPORTUNITIES : "has" + REGIONS ||--o{ OPPORTUNITIES : "has" + AREAS ||--o{ OPPORTUNITIES : "has" + + ZONES ||--o{ APPLICATIONS : "belongs_to" + REGIONS ||--o{ APPLICATIONS : "belongs_to" + AREAS ||--o{ APPLICATIONS : "belongs_to" + USERS ||--o{ APPLICATIONS : "assigned_to" + + APPLICATIONS ||--o{ QUESTIONNAIRE_RESPONSES : "has" + QUESTIONNAIRES ||--o{ QUESTIONNAIRE_RESPONSES : "used_in" + QUESTIONNAIRE_QUESTIONS ||--o{ QUESTIONNAIRE_RESPONSES : "answered_by" + APPLICATIONS ||--o{ QUESTIONNAIRE_SCORES : "has" + + APPLICATIONS ||--o{ INTERVIEWS : "has" + INTERVIEWS ||--o{ INTERVIEW_PARTICIPANTS : "includes" + INTERVIEWS ||--o{ INTERVIEW_EVALUATIONS : "evaluated_in" + INTERVIEW_EVALUATIONS ||--o{ KT_MATRIX_SCORES : "contains" + INTERVIEW_EVALUATIONS ||--o{ INTERVIEW_FEEDBACK : "has" + APPLICATIONS ||--o{ AI_SUMMARIES : "has" + + APPLICATIONS ||--o{ WORK_NOTES : "has" + WORK_NOTES ||--o{ WORK_NOTE_TAGS : "tags" + WORK_NOTES ||--o{ WORK_NOTE_ATTACHMENTS : "has" + DOCUMENTS ||--o{ WORK_NOTE_ATTACHMENTS : "attached_to" + + APPLICATIONS ||--o{ DOCUMENTS : "has" + DOCUMENTS ||--o{ DOCUMENT_VERSIONS : "has" + APPLICATIONS ||--o{ LOI_DOCUMENTS : "requires" + APPLICATIONS ||--o{ STATUTORY_DOCUMENTS : "requires" + + APPLICATIONS ||--o{ FDD_ASSIGNMENTS : "assigned_to" + FDD_ASSIGNMENTS ||--o{ FDD_REPORTS : "generates" + FDD_REPORTS ||--o{ DOCUMENTS : "stored_as" + + APPLICATIONS ||--o{ LOI_REQUESTS : "has" + LOI_REQUESTS ||--o{ LOI_APPROVALS : "requires" + LOI_REQUESTS ||--o{ LOI_DOCUMENTS_GENERATED : "generates" + LOI_DOCUMENTS_GENERATED ||--o{ LOI_ACKNOWLEDGEMENTS : "acknowledged_by" + + APPLICATIONS ||--o{ SECURITY_DEPOSITS : "has" + SECURITY_DEPOSITS ||--o{ DOCUMENTS : "proof_document" + + APPLICATIONS ||--o{ DEALER_CODES : "has" + + APPLICATIONS ||--o{ ARCHITECTURAL_ASSIGNMENTS : "assigned_to" + ARCHITECTURAL_ASSIGNMENTS ||--o{ ARCHITECTURAL_DOCUMENTS : "has" + APPLICATIONS ||--o{ CONSTRUCTION_PROGRESS : "tracks" + + APPLICATIONS ||--o{ EOR_CHECKLISTS : "has" + EOR_CHECKLISTS ||--o{ EOR_CHECKLIST_ITEMS : "contains" + + APPLICATIONS ||--o{ LOA_REQUESTS : "has" + LOA_REQUESTS ||--o{ LOA_APPROVALS : "requires" + LOA_REQUESTS ||--o{ LOA_DOCUMENTS_GENERATED : "generates" + + APPLICATIONS ||--o{ INAUGURATIONS : "has" + INAUGURATIONS ||--o{ INAUGURATION_ATTENDEES : "includes" + INAUGURATIONS ||--o{ INAUGURATION_DOCUMENTS : "has" + + USERS ||--o{ NOTIFICATIONS : "receives" + APPLICATIONS ||--o{ NOTIFICATIONS : "triggers" + APPLICATIONS ||--o{ EMAIL_LOGS : "triggers" + APPLICATIONS ||--o{ WHATSAPP_LOGS : "triggers" + + SLA_CONFIGURATIONS ||--o{ SLA_TRACKING : "tracks" + APPLICATIONS ||--o{ SLA_TRACKING : "monitored_by" + SLA_TRACKING ||--o{ SLA_ESCALATIONS : "escalates" + + APPLICATIONS ||--o{ AUDIT_LOGS : "logged_in" + USERS ||--o{ AUDIT_LOGS : "performed_by" + APPLICATIONS ||--o{ ACTIVITY_LOGS : "logged_in" + APPLICATIONS ||--o{ APPLICATION_STATUS_HISTORY : "tracks" + APPLICATIONS ||--o{ APPLICATION_PROGRESS : "tracks" + diff --git a/frontend/RE_Workflow_Frontend_Setup.md b/frontend/RE_Workflow_Frontend_Setup.md new file mode 100644 index 0000000..a53b117 --- /dev/null +++ b/frontend/RE_Workflow_Frontend_Setup.md @@ -0,0 +1,969 @@ +# RE Workflow Management System - Frontend Setup Guide +**Version:** 1.0 +**Date:** October 16, 2025 +**Technology Stack:** React 19 + TypeScript 5.7 + Vite 6.0 + Redux Toolkit 2.5 + Material-UI 6.3 + +--- + +## Table of Contents +1. [Frontend Architecture Overview](#frontend-architecture-overview) +2. [Technology Stack](#technology-stack) +3. [Project Folder Structure](#project-folder-structure) +4. [TypeScript Configuration](#typescript-configuration) +5. [State Management (Redux Toolkit)](#state-management-redux-toolkit) +6. [Component Structure](#component-structure) +7. [Configuration Management](#configuration-management) +8. [Deployment Architecture](#deployment-architecture) +9. [Development Setup Instructions](#development-setup-instructions) + +--- + +## 1. Frontend Architecture Overview + +### High-Level Architecture + +``` +┌─────────────────────────────────────────────────────────────┐ +│ CLIENT LAYER │ +│ React.js SPA (Single Page Application) │ +│ - Material-UI / Ant Design Components │ +│ - Redux Toolkit for State Management │ +│ - React Router for Navigation │ +│ - Axios for API Communication │ +│ - Vite for Build & Development │ +└─────────────────────────────────────────────────────────────┘ + ↕ HTTPS/REST API +┌─────────────────────────────────────────────────────────────┐ +│ BACKEND API LAYER │ +│ Express.js REST API Server │ +│ - Node.js + TypeScript │ +│ - PostgreSQL Database │ +└─────────────────────────────────────────────────────────────┘ +``` + +--- + +## 2. Technology Stack + +| Component | Technology | Version | Purpose | +|-----------|-----------|---------|---------| +| **Frontend Library** | React.js | 19.0.x | UI component library | +| **Frontend Language** | TypeScript (TSX) | 5.7.x | Type-safe frontend development | +| **UI Framework** | Material-UI (MUI) | 6.3.x | Component design system | +| **Build Tool** | Vite | 6.0.x | Ultra-fast build & dev server | +| **State Management** | Redux Toolkit | 2.5.x | Application state management | +| **Routing** | React Router DOM | 7.1.x | Client-side routing | +| **HTTP Client** | Axios | 1.7.x | API communication | +| **Form Management** | Formik | 2.4.x | Form state management | +| **Form Validation** | Yup | 1.6.x | Schema validation | +| **Date Utilities** | date-fns | 4.1.x | Date manipulation | +| **Charts** | Recharts | 2.15.x | Data visualization | +| **Notifications** | React Toastify | 11.0.x | Toast notifications | +| **File Upload** | React Dropzone | 14.3.x | File upload UI | +| **Testing** | Vitest + React Testing Library | 2.1.x/16.1.x | Component testing | +| **Code Quality** | ESLint + Prettier | 9.x/3.x | Code linting & formatting | + +--- + +## 3. Project Folder Structure + +### Frontend Repository (`re-workflow-frontend`) + +``` +re-workflow-frontend/ +│ +├── public/ # Static assets +│ ├── index.html +│ ├── favicon.ico +│ ├── robots.txt +│ └── manifest.json +│ +├── src/ # Source code +│ ├── index.tsx # Application entry point +│ ├── App.tsx # Root component +│ ├── App.css +│ ├── react-app-env.d.ts # React TypeScript declarations +│ │ +│ ├── types/ # TypeScript type definitions +│ │ ├── index.ts # Main types export +│ │ ├── user.types.ts # User types +│ │ ├── workflow.types.ts # Workflow types +│ │ ├── approval.types.ts # Approval types +│ │ ├── document.types.ts # Document types +│ │ ├── notification.types.ts # Notification types +│ │ ├── common.types.ts # Common types +│ │ └── api.types.ts # API response types +│ │ +│ ├── assets/ # Static assets +│ │ ├── images/ +│ │ ├── icons/ +│ │ ├── fonts/ +│ │ └── styles/ +│ │ ├── global.css +│ │ ├── variables.css +│ │ └── theme.ts +│ │ +│ ├── components/ # Reusable components +│ │ ├── common/ # Generic components +│ │ │ ├── Button/ +│ │ │ │ ├── Button.tsx +│ │ │ │ ├── Button.module.css +│ │ │ │ ├── Button.types.ts +│ │ │ │ └── Button.test.tsx +│ │ │ ├── Input/ +│ │ │ ├── Dropdown/ +│ │ │ ├── Modal/ +│ │ │ ├── Card/ +│ │ │ ├── Table/ +│ │ │ ├── Tabs/ +│ │ │ ├── Pagination/ +│ │ │ ├── Loader/ +│ │ │ ├── Notification/ +│ │ │ └── ErrorBoundary/ +│ │ │ +│ │ ├── layout/ # Layout components +│ │ │ ├── Header/ +│ │ │ │ ├── Header.tsx +│ │ │ │ ├── Header.module.css +│ │ │ │ └── Header.types.ts +│ │ │ ├── Sidebar/ +│ │ │ ├── Footer/ +│ │ │ ├── Navigation/ +│ │ │ └── PageLayout/ +│ │ │ +│ │ ├── workflow/ # Workflow-specific components +│ │ │ ├── TemplateSelector/ +│ │ │ ├── BasicInformation/ +│ │ │ ├── ApprovalWorkflow/ +│ │ │ │ ├── ApprovalWorkflow.tsx +│ │ │ │ ├── ApproverLevel.tsx +│ │ │ │ ├── TATCalculator.tsx +│ │ │ │ ├── ApprovalSummary.tsx +│ │ │ │ └── types.ts +│ │ │ ├── ParticipantAccess/ +│ │ │ │ ├── ParticipantAccess.tsx +│ │ │ │ ├── SpectatorList.tsx +│ │ │ │ ├── UserTagging.tsx +│ │ │ │ └── types.ts +│ │ │ ├── DocumentUpload/ +│ │ │ │ ├── DocumentUpload.tsx +│ │ │ │ ├── FilePreview.tsx +│ │ │ │ ├── GoogleDocsLink.tsx +│ │ │ │ └── types.ts +│ │ │ ├── ReviewSubmit/ +│ │ │ └── WizardStepper/ +│ │ │ +│ │ ├── request/ # Request management components +│ │ │ ├── RequestCard/ +│ │ │ ├── RequestList/ +│ │ │ ├── RequestDetail/ +│ │ │ │ ├── RequestOverview.tsx +│ │ │ │ ├── WorkflowTab.tsx +│ │ │ │ ├── DocumentTab.tsx +│ │ │ │ ├── ActivityTab.tsx +│ │ │ │ ├── TATProgressBar.tsx +│ │ │ │ └── types.ts +│ │ │ ├── StatusBadge/ +│ │ │ └── PriorityIndicator/ +│ │ │ +│ │ ├── approval/ # Approval action components +│ │ │ ├── ApprovalModal/ +│ │ │ ├── RejectionModal/ +│ │ │ ├── ApprovalHistory/ +│ │ │ └── ConclusionRemark/ +│ │ │ +│ │ ├── workNote/ # Work notes / chat components +│ │ │ ├── WorkNoteChat/ +│ │ │ ├── MessageItem/ +│ │ │ ├── MessageComposer/ +│ │ │ ├── FileAttachment/ +│ │ │ └── UserMention/ +│ │ │ +│ │ ├── notification/ # Notification components +│ │ │ ├── NotificationBell/ +│ │ │ ├── NotificationList/ +│ │ │ ├── NotificationItem/ +│ │ │ └── NotificationSettings/ +│ │ │ +│ │ └── dashboard/ # Dashboard components +│ │ ├── DashboardCard/ +│ │ ├── StatisticsWidget/ +│ │ ├── RecentRequests/ +│ │ └── QuickActions/ +│ │ +│ ├── pages/ # Page components (routes) +│ │ ├── Auth/ +│ │ │ ├── Login.tsx +│ │ │ └── SSOCallback.tsx +│ │ ├── Dashboard/ +│ │ │ └── Dashboard.tsx +│ │ ├── CreateRequest/ +│ │ │ └── CreateRequest.tsx +│ │ ├── MyRequests/ +│ │ │ └── MyRequests.tsx +│ │ ├── OpenRequests/ +│ │ │ └── OpenRequests.tsx +│ │ ├── ClosedRequests/ +│ │ │ └── ClosedRequests.tsx +│ │ ├── RequestDetail/ +│ │ │ └── RequestDetail.tsx +│ │ ├── NotFound/ +│ │ │ └── NotFound.tsx +│ │ └── Unauthorized/ +│ │ └── Unauthorized.tsx +│ │ +│ ├── redux/ # Redux state management +│ │ ├── store.ts # Redux store configuration +│ │ ├── hooks.ts # Typed Redux hooks +│ │ ├── slices/ +│ │ │ ├── authSlice.ts +│ │ │ ├── workflowSlice.ts +│ │ │ ├── approvalSlice.ts +│ │ │ ├── notificationSlice.ts +│ │ │ ├── documentSlice.ts +│ │ │ ├── workNoteSlice.ts +│ │ │ ├── participantSlice.ts +│ │ │ └── uiSlice.ts +│ │ └── middleware/ +│ │ └── apiMiddleware.ts +│ │ +│ ├── services/ # API service layer +│ │ ├── api.ts # Axios instance configuration +│ │ ├── auth.service.ts +│ │ ├── workflow.service.ts +│ │ ├── approval.service.ts +│ │ ├── document.service.ts +│ │ ├── notification.service.ts +│ │ ├── workNote.service.ts +│ │ ├── participant.service.ts +│ │ ├── dashboard.service.ts +│ │ └── user.service.ts +│ │ +│ ├── hooks/ # Custom React hooks +│ │ ├── useAuth.ts +│ │ ├── useWorkflow.ts +│ │ ├── useNotification.ts +│ │ ├── useDebounce.ts +│ │ ├── useInfiniteScroll.ts +│ │ ├── useLocalStorage.ts +│ │ └── useWebSocket.ts +│ │ +│ ├── utils/ # Utility functions +│ │ ├── constants.ts +│ │ ├── validators.ts +│ │ ├── formatters.ts +│ │ ├── dateUtils.ts +│ │ ├── fileUtils.ts +│ │ ├── errorHandler.ts +│ │ └── helpers.ts +│ │ +│ ├── routes/ # React Router configuration +│ │ ├── AppRoutes.tsx +│ │ ├── PrivateRoute.tsx +│ │ └── PublicRoute.tsx +│ │ +│ └── config/ # Frontend configuration +│ ├── api.config.ts +│ ├── theme.config.ts +│ └── constants.config.ts +│ +├── dist/ # Build output (Vite) +│ +├── tests/ # Test files +│ ├── components/ +│ ├── pages/ +│ ├── redux/ +│ ├── services/ +│ └── setup.js +│ +├── docs/ # Component documentation +│ └── storybook/ +│ +├── nginx/ # Nginx configuration for production +│ └── default.conf +│ +├── .env.example +├── .env.development +├── .env.production +├── .eslintrc.json +├── .prettierrc +├── .gitignore +├── .dockerignore +├── Dockerfile +├── vite.config.ts # Vite configuration +├── tsconfig.json # TypeScript configuration +├── package.json +├── package-lock.json +└── README.md +``` + +--- + +## 4. TypeScript Configuration + +### `tsconfig.json` + +```json +{ + "compilerOptions": { + "target": "ES2020", + "lib": ["ES2020", "DOM", "DOM.Iterable"], + "jsx": "react-jsx", + "module": "esnext", + "moduleResolution": "node", + "resolveJsonModule": true, + "allowJs": true, + "strict": true, + "esModuleInterop": true, + "skipLibCheck": true, + "forceConsistentCasingInFileNames": true, + "noImplicitAny": true, + "strictNullChecks": true, + "strictFunctionTypes": true, + "noUnusedLocals": true, + "noUnusedParameters": true, + "noImplicitReturns": true, + "noFallthroughCasesInSwitch": true, + "allowSyntheticDefaultImports": true, + "isolatedModules": true, + "noEmit": true, + "baseUrl": "./src", + "paths": { + "@/*": ["./*"], + "@components/*": ["components/*"], + "@pages/*": ["pages/*"], + "@services/*": ["services/*"], + "@redux/*": ["redux/*"], + "@hooks/*": ["hooks/*"], + "@utils/*": ["utils/*"], + "@types/*": ["types/*"], + "@config/*": ["config/*"], + "@assets/*": ["assets/*"] + } + }, + "include": ["src"], + "exclude": ["node_modules", "build", "dist"] +} +``` + +### `vite.config.ts` + +```typescript +import { defineConfig } from 'vite'; +import react from '@vitejs/plugin-react'; +import path from 'path'; + +export default defineConfig({ + plugins: [react()], + resolve: { + alias: { + '@': path.resolve(__dirname, './src'), + '@components': path.resolve(__dirname, './src/components'), + '@pages': path.resolve(__dirname, './src/pages'), + '@services': path.resolve(__dirname, './src/services'), + '@redux': path.resolve(__dirname, './src/redux'), + '@hooks': path.resolve(__dirname, './src/hooks'), + '@utils': path.resolve(__dirname, './src/utils'), + '@types': path.resolve(__dirname, './src/types'), + '@config': path.resolve(__dirname, './src/config'), + '@assets': path.resolve(__dirname, './src/assets'), + }, + }, + server: { + port: 3000, + proxy: { + '/api': { + target: 'http://localhost:5000', + changeOrigin: true, + }, + }, + }, + build: { + outDir: 'dist', + sourcemap: true, + }, +}); +``` + +--- + +## 5. State Management (Redux Toolkit) + +### Redux Store Configuration + +#### `src/redux/store.ts` + +```typescript +import { configureStore } from '@reduxjs/toolkit'; +import authReducer from './slices/authSlice'; +import workflowReducer from './slices/workflowSlice'; +import approvalReducer from './slices/approvalSlice'; +import notificationReducer from './slices/notificationSlice'; +import documentReducer from './slices/documentSlice'; +import workNoteReducer from './slices/workNoteSlice'; +import participantReducer from './slices/participantSlice'; +import uiReducer from './slices/uiSlice'; + +export const store = configureStore({ + reducer: { + auth: authReducer, + workflow: workflowReducer, + approval: approvalReducer, + notification: notificationReducer, + document: documentReducer, + workNote: workNoteReducer, + participant: participantReducer, + ui: uiReducer, + }, + middleware: (getDefaultMiddleware) => + getDefaultMiddleware({ + serializableCheck: { + ignoredActions: ['persist/PERSIST'], + }, + }), +}); + +export type RootState = ReturnType; +export type AppDispatch = typeof store.dispatch; +``` + +### Typed Redux Hooks + +#### `src/redux/hooks.ts` + +```typescript +import { useDispatch, useSelector } from 'react-redux'; +import type { TypedUseSelectorHook } from 'react-redux'; +import type { RootState, AppDispatch } from './store'; + +// Use throughout your app instead of plain `useDispatch` and `useSelector` +export const useAppDispatch: () => AppDispatch = useDispatch; +export const useAppSelector: TypedUseSelectorHook = useSelector; +``` + +### Type Definitions + +#### `src/types/common.types.ts` + +```typescript +export enum Priority { + STANDARD = 'STANDARD', + EXPRESS = 'EXPRESS' +} + +export enum WorkflowStatus { + DRAFT = 'DRAFT', + PENDING = 'PENDING', + IN_PROGRESS = 'IN_PROGRESS', + APPROVED = 'APPROVED', + REJECTED = 'REJECTED', + CLOSED = 'CLOSED' +} + +export interface ApiResponse { + success: boolean; + message: string; + data?: T; + error?: string; + timestamp: string; +} + +export interface PaginatedResponse { + data: T[]; + pagination: { + page: number; + limit: number; + total: number; + totalPages: number; + }; +} +``` + +--- + +## 6. Component Structure + +### Example: Button Component + +#### `src/components/common/Button/Button.tsx` + +```typescript +import React from 'react'; +import styles from './Button.module.css'; + +interface ButtonProps { + label: string; + onClick: () => void; + variant?: 'primary' | 'secondary' | 'danger'; + disabled?: boolean; + fullWidth?: boolean; +} + +const Button: React.FC = ({ + label, + onClick, + variant = 'primary', + disabled = false, + fullWidth = false, +}) => { + return ( + + ); +}; + +export default Button; +``` + +#### `src/components/common/Button/Button.types.ts` + +```typescript +export interface ButtonProps { + label: string; + onClick: () => void; + variant?: 'primary' | 'secondary' | 'danger'; + disabled?: boolean; + fullWidth?: boolean; +} +``` + +--- + +## 7. Configuration Management + +### Environment Variables + +#### `.env.example` + +```bash +# frontend/.env.example + +# Application +REACT_APP_ENV=development +REACT_APP_NAME=RE Workflow Management +REACT_APP_VERSION=1.0.0 + +# API Configuration +REACT_APP_API_BASE_URL=http://localhost:5000/api/v1 +REACT_APP_API_TIMEOUT=30000 + +# SSO Configuration +REACT_APP_SSO_LOGIN_URL=http://localhost:5000/api/v1/auth/login +REACT_APP_SSO_LOGOUT_URL=http://localhost:5000/api/v1/auth/logout + +# Feature Flags +REACT_APP_ENABLE_NOTIFICATIONS=true +REACT_APP_ENABLE_EMAIL_NOTIFICATIONS=false +REACT_APP_ENABLE_ANALYTICS=true + +# File Upload +REACT_APP_MAX_FILE_SIZE_MB=10 +REACT_APP_ALLOWED_FILE_TYPES=pdf,doc,docx,xls,xlsx,ppt,pptx,jpg,jpeg,png,gif + +# Google Integration +REACT_APP_GOOGLE_API_KEY=your_google_api_key + +# UI Configuration +REACT_APP_THEME_PRIMARY_COLOR=#1976d2 +REACT_APP_ITEMS_PER_PAGE=20 +``` + +### API Configuration + +#### `src/config/api.config.ts` + +```typescript +export const API_CONFIG = { + baseURL: import.meta.env.VITE_API_BASE_URL || 'http://localhost:5000/api/v1', + timeout: parseInt(import.meta.env.VITE_API_TIMEOUT || '30000'), + headers: { + 'Content-Type': 'application/json', + }, +}; + +export const API_ENDPOINTS = { + auth: { + login: '/auth/login', + logout: '/auth/logout', + me: '/auth/me', + }, + workflows: { + getAll: '/workflows', + create: '/workflows', + getById: (id: string) => `/workflows/${id}`, + update: (id: string) => `/workflows/${id}`, + submit: (id: string) => `/workflows/${id}/submit`, + }, + // ... more endpoints +}; +``` + +--- + +## 8. Deployment Architecture + +### Dockerfile + +#### `Dockerfile` + +```dockerfile +# re-workflow-frontend/Dockerfile + +FROM node:22-alpine AS builder + +WORKDIR /app + +# Copy package files +COPY package*.json ./ + +# Install dependencies +RUN npm ci + +# Copy source code +COPY . . + +# Build application with Vite +RUN npm run build + +# ===================================== +# Production Image with Nginx +# ===================================== +FROM nginx:alpine + +# Copy custom nginx config +COPY nginx/default.conf /etc/nginx/conf.d/default.conf + +# Copy built files from builder (Vite outputs to 'dist' by default) +COPY --from=builder /app/dist /usr/share/nginx/html + +# Expose port +EXPOSE 80 + +# Health check +HEALTHCHECK --interval=30s --timeout=3s \ + CMD wget --quiet --tries=1 --spider http://localhost/ || exit 1 + +CMD ["nginx", "-g", "daemon off;"] +``` + +### Nginx Configuration + +#### `nginx/default.conf` + +```nginx +server { + listen 80; + server_name localhost; + root /usr/share/nginx/html; + index index.html; + + # Gzip compression + gzip on; + gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript; + + # Security headers + add_header X-Frame-Options "SAMEORIGIN" always; + add_header X-Content-Type-Options "nosniff" always; + add_header X-XSS-Protection "1; mode=block" always; + + # React Router support + location / { + try_files $uri $uri/ /index.html; + } + + # Cache static assets + location /assets/ { + expires 1y; + add_header Cache-Control "public, immutable"; + } + + # Health check endpoint + location /health { + access_log off; + return 200 "healthy\n"; + add_header Content-Type text/plain; + } +} +``` + +### CI/CD Pipeline (GitHub Actions) + +#### `.github/workflows/frontend-deploy.yml` + +```yaml +# .github/workflows/frontend-deploy.yml + +name: Frontend CI/CD + +on: + push: + branches: [main, develop] + pull_request: + branches: [main] + +jobs: + test-and-build: + runs-on: ubuntu-latest + steps: + - uses: actions/checkout@v4 + + - name: Setup Node.js + uses: actions/setup-node@v4 + with: + node-version: '22' + + - name: Install dependencies + run: npm ci + + - name: Run linter + run: npm run lint + + - name: Run tests + run: npm test + + - name: Build application + run: npm run build + + - name: Build Docker image + run: docker build -t gcr.io/re-project/re-workflow-frontend:${{ github.sha }} . + + - name: Push to GCR + run: docker push gcr.io/re-project/re-workflow-frontend:${{ github.sha }} +``` + +--- + +## 9. Development Setup Instructions + +### 9.1 Prerequisites + +- **Node.js:** v22.x LTS +- **npm:** v10.x or higher +- **Git:** Latest version +- **TypeScript:** v5.7.x (installed as dev dependency) +- **Backend API:** Running on `http://localhost:5000` (see backend documentation) + +### 9.2 Local Development Setup + +#### Step 1: Clone Frontend Repository + +```bash +git clone https://github.com/royalenfield/re-workflow-frontend.git +cd re-workflow-frontend +``` + +#### Step 2: Configure Frontend Environment + +```bash +# Copy environment file +cp .env.example .env + +# Edit .env with backend API URL +nano .env # or use your preferred editor + +# Set REACT_APP_API_BASE_URL=http://localhost:5000/api/v1 +``` + +#### Step 3: Install Dependencies & Run Frontend + +```bash +# Install dependencies +npm install + +# Run TypeScript type checking +npm run type-check + +# Start development server (Vite with hot reload) +npm run dev + +# Frontend will run on: http://localhost:3000 +``` + +#### Step 4: Access Application + +- **Frontend:** http://localhost:3000 +- **Backend API:** http://localhost:5000 +- **API Documentation:** http://localhost:5000/api-docs +- **Health Check:** http://localhost:5000/health + +### 9.3 Docker Setup + +```bash +# From frontend repository root +cd re-workflow-frontend + +# Copy environment file +cp .env.example .env + +# Build Docker image +docker build -t re-workflow-frontend . + +# Run frontend container +docker run -d -p 3000:80 --name frontend re-workflow-frontend + +# Access frontend: http://localhost:3000 + +# Stop container +docker stop frontend +docker rm frontend +``` + +### 9.4 Running Tests + +```bash +# From frontend repository +cd re-workflow-frontend + +npm test # Run all tests (Vitest) +npm run test:ui # Interactive UI mode (Vitest) +npm run test:coverage # With coverage report + +# Coverage report will be in: coverage/ +``` + +### 9.5 Code Quality Checks + +```bash +# From frontend repository +cd re-workflow-frontend + +npm run lint # ESLint check (React + TypeScript rules) +npm run lint:fix # Auto-fix issues +npm run format # Prettier formatting +npm run type-check # TypeScript type checking only (no build) + +# Run all quality checks together +npm run lint && npm run type-check && npm test +``` + +### 9.6 Git Workflow + +```bash +# Feature branch workflow +git checkout -b feature/your-feature-name +git add . +git commit -m "feat: add your feature description" +git push origin feature/your-feature-name + +# Create Pull Request on GitHub/GitLab +# After approval and merge: +git checkout main +git pull origin main +``` + +**Branch Strategy:** +- `main` - Production-ready code +- `develop` - Integration branch for features +- `feature/*` - New features +- `bugfix/*` - Bug fixes +- `hotfix/*` - Production hotfixes + +**Commit Message Convention (Conventional Commits):** +- `feat:` - New feature +- `fix:` - Bug fix +- `docs:` - Documentation changes +- `style:` - Code style changes (formatting) +- `refactor:` - Code refactoring +- `test:` - Test additions or changes +- `chore:` - Build process or tool changes + +--- + +## 10. Package.json + +```json +{ + "name": "re-workflow-frontend", + "version": "1.0.0", + "description": "Royal Enfield Workflow Management System - Frontend (TypeScript)", + "private": true, + "dependencies": { + "react": "^19.0.0", + "react-dom": "^19.0.0", + "react-router-dom": "^7.1.1", + "@reduxjs/toolkit": "^2.5.0", + "react-redux": "^9.2.0", + "@mui/material": "^6.3.0", + "@mui/icons-material": "^6.3.0", + "@emotion/react": "^11.14.0", + "@emotion/styled": "^11.14.0", + "axios": "^1.7.9", + "formik": "^2.4.6", + "yup": "^1.6.3", + "zod": "^3.24.1", + "react-dropzone": "^14.3.5", + "date-fns": "^4.1.0", + "recharts": "^2.15.0", + "react-toastify": "^11.0.2" + }, + "devDependencies": { + "@types/react": "^19.0.6", + "@types/react-dom": "^19.0.2", + "@types/node": "^22.10.5", + "typescript": "^5.7.2", + "vite": "^6.0.7", + "@vitejs/plugin-react": "^4.3.4", + "@testing-library/react": "^16.1.0", + "@testing-library/jest-dom": "^6.6.3", + "@testing-library/user-event": "^14.5.2", + "eslint": "^9.17.0", + "@typescript-eslint/eslint-plugin": "^8.19.1", + "@typescript-eslint/parser": "^8.19.1", + "prettier": "^3.4.2", + "vitest": "^2.1.8" + }, + "scripts": { + "dev": "vite", + "build": "tsc && vite build", + "preview": "vite preview", + "test": "vitest", + "test:ui": "vitest --ui", + "test:coverage": "vitest --coverage", + "lint": "eslint src/**/*.{ts,tsx}", + "lint:fix": "eslint src/**/*.{ts,tsx} --fix", + "format": "prettier --write \"src/**/*.{ts,tsx,css}\"", + "type-check": "tsc --noEmit" + }, + "eslintConfig": { + "extends": ["react-app", "react-app/jest"] + }, + "browserslist": { + "production": [">0.2%", "not dead", "not op_mini all"], + "development": ["last 1 chrome version", "last 1 firefox version", "last 1 safari version"] + }, + "engines": { + "node": ">=22.0.0", + "npm": ">=10.0.0" + } +} +``` + +--- + +## Summary + +This frontend documentation provides: + +✅ **Complete Frontend Architecture** - React SPA with Vite, Redux Toolkit, TypeScript +✅ **Technology Stack** - React 19 + TypeScript 5.7 + Vite 6.0 + Material-UI 6.3 +✅ **Folder Structure** - Detailed organization with TypeScript conventions +✅ **Type Definitions** - Comprehensive type safety with interfaces and enums +✅ **Redux Toolkit Setup** - Fully typed state management +✅ **Component Structure** - Reusable, testable components +✅ **Configuration Management** - Environment variables and settings +✅ **Deployment Architecture** - Docker, Nginx, CI/CD pipelines +✅ **Development Setup** - Step-by-step installation and configuration +✅ **Testing Strategy** - Vitest and React Testing Library +✅ **Code Quality** - ESLint, Prettier, TypeScript best practices + +**Technology Stack:** React 19 + TypeScript 5.7 + Vite 6.0 + Redux Toolkit 2.5 + Material-UI 6.3 +**Repository:** `re-workflow-frontend` (Independent Repository) +**Status:** ✅ Ready for Implementation + diff --git a/mermaids/dealer_onboard.mermaid b/mermaids/dealer_onboard.mermaid index 0118f0f..49ef50a 100644 --- a/mermaids/dealer_onboard.mermaid +++ b/mermaids/dealer_onboard.mermaid @@ -7,53 +7,152 @@ graph TB CheckLocation -->|Yes| AckEmail[Send Acknowledgement Email] AckEmail --> SendQuestionnaire[Send Opportunity Email with Questionnaire Link] - SendQuestionnaire --> WaitResponse{Response Received?} + SendQuestionnaire --> WaitResponse{Questionnaire Response Received?} - WaitResponse -->|No - D+2| Reminder1[Send Reminder Email] - Reminder1 --> WaitResponse2{Response Received?} - WaitResponse2 -->|No - D+5| Reminder2[Send Final Reminder] - Reminder2 --> WaitResponse3{Response Received?} - WaitResponse3 -->|No - D+20| ExpireLink[Close Questionnaire - Expired] + WaitResponse -->|No| SendReminder[Send Reminder Email
SLA-based Auto-Trigger] + SendReminder --> WaitResponse + WaitResponse -->|Yes| ProcessResponse[Calculate Weighted Rank & Score] - WaitResponse -->|Yes| ProcessResponse[Calculate Weighted Rank] - WaitResponse2 -->|Yes| ProcessResponse - WaitResponse3 -->|Yes| ProcessResponse + ProcessResponse --> DDShortlist[DD-Admin Reviews & Shortlists Applications] + DDShortlist --> WorkNotes1[Work Notes: DD-Admin adds remarks
& assigns to zones] + WorkNotes1 --> AssignZM[Assign to DD-ZM & RBM] - ProcessResponse --> DDShortlist[DD Team Reviews & Shortlists Top 10] - DDShortlist --> AssignZM[Assign to Zonal Manager ZM-DD] + AssignZM --> ScheduleL1[DD-Admin Schedules Level 1 Interview
Mode: Virtual Google Meet or Physical
Adds Date, Time, Participants, Link/Venue] + ScheduleL1 --> SendCalendarL1[System: Send Google Calendar Invites
to DD-ZM, RBM & Applicant] + SendCalendarL1 --> Level1Interview[Level 1 Interview Conducted
DD-ZM + RBM with Applicant] + Level1Interview --> Level1Eval[Level 1 Evaluation Process] + Level1Eval --> KTMatrixL1[DD-ZM & RBM Fill KT Matrix
Age, Qualification, Local Knowledge,
Passion, Business Acumen, etc.] + KTMatrixL1 --> FeedbackL1[DD-ZM & RBM Submit Feedback Forms
Qualitative Remarks & Recommendations] + FeedbackL1 --> WorkNotesL1[Work Notes: Panelists add comments
@tag users for clarifications] + WorkNotesL1 --> Level1Decision{Level 1 Decision
Approve or Reject} + Level1Decision -->|Rejected| Level1Reject[Store Rejection Reason
Work Notes: Log decision & Notify] + Level1Decision -->|Approved| AssignLevel2[Auto-Assign to DD-Lead + ZBH
Work Notes: Status update logged] - AssignZM --> ZMEval{ZM-DD KT Evaluation} - ZMEval -->|Rejected| ZMReject[Store Rejection Reason] - ZMEval -->|Shortlisted| AssignRBM[Auto-Assign to RBM] + AssignLevel2 --> ScheduleL2[DD-Admin Schedules Level 2 Interview
Mode: Virtual Google Meet or Physical
Adds Date, Time, Participants, Link/Venue] + ScheduleL2 --> SendCalendarL2[System: Send Google Calendar Invites
to DD-Lead, ZBH & Applicant] + SendCalendarL2 --> Level2Interview[Level 2 Interview Conducted
DD-Lead + ZBH with Applicant] + Level2Interview --> Level2Eval[Level 2 Evaluation Process] + Level2Eval --> FeedbackL2[DD-Lead & ZBH Submit Feedback Forms
Business Strategy & Operational Assessment] + FeedbackL2 --> WorkNotesL2[Work Notes: Panelists add comments
@tag users for clarifications] + WorkNotesL2 --> Level2Decision{Level 2 Decision
Approve or Reject} + Level2Decision -->|Rejected| Level2Reject[Store Rejection Reason
Work Notes: Log decision & Notify] + Level2Decision -->|Approved| AssignLevel3[Auto-Assign to NBH + DD-Head
Work Notes: Status update logged] - AssignRBM --> RBMEval{RBM Evaluation} - RBMEval -->|Rejected| RBMReject[Store Rejection Reason] - RBMEval -->|Approved| AssignDDL[Auto-Assign to DDL Team] + AssignLevel3 --> ScheduleL3[DD-Admin Schedules Level 3 Interview
Mode: Virtual Google Meet or Physical
Adds Date, Time, Participants, Link/Venue] + ScheduleL3 --> SendCalendarL3[System: Send Google Calendar Invites
to NBH, DD-Head & Applicant] + SendCalendarL3 --> Level3Interview[Level 3 Interview Conducted
NBH + DD-Head with Applicant] + Level3Interview --> Level3Eval[Level 3 Evaluation Process] + Level3Eval --> CollectFeedbackL3[Collect All Panel Feedback
RBM, ZBH, DD-ZM, DD-Lead, DD-Head] + CollectFeedbackL3 --> AISummary[AI Engine Gemini API:
Generate 2-3 Line Summary
Consensus, Strengths, Concerns] + AISummary --> NBHReview[NBH Reviews AI Summary
Editable Format - Can Modify] + NBHReview --> WorkNotesL3[Work Notes: NBH adds final remarks
@tag stakeholders if needed] + WorkNotesL3 --> Level3Decision{Level 3 Final Decision
Approve or Reject} + Level3Decision -->|Rejected| Level3Reject[Store Rejection Reason
Work Notes: Log decision & Notify] + Level3Decision -->|Approved| AssignFDD[Auto-Assign to FDD Team
Work Notes: Status update logged] - AssignDDL --> FDD[Send OTP-Protected Link for Financial Due Diligence] - FDD --> UploadFDD[External Agency Uploads FDD Report L1/L2] - UploadFDD --> SubmitNBH[DD Team Submits to NBH] + AssignFDD --> FDDProcess[FDD: Send OTP-Protected Link
to External FDD Agency] + FDDProcess --> FDDWorkNotes[Work Notes: FDD can raise queries
@DD-Admin or @Finance for clarifications
Flag non-responsive applicants] + FDDWorkNotes --> UploadFDD[External FDD Agency Uploads Report
FDD Report L1/L2 with Remarks] + UploadFDD --> FinanceReview[Finance Team Reviews FDD Report] + FinanceReview --> FinanceWorkNotes[Work Notes: Finance adds review comments
@DD-Lead for clarifications if needed] + FinanceWorkNotes --> FinanceDecision{Finance Decision
Approve or Reject} + FinanceDecision -->|Rejected| FinanceReject[Store Rejection & Notify
Work Notes: Log rejection reason] + FinanceDecision -->|Approved| LOIDocRequest[LOI: Request Documents from Applicant
Work Notes: Status update logged] - SubmitNBH --> NBHApproval{NBH Approval} - NBHApproval -->|Rejected| NBHReject[Store Rejection & Notify] - NBHApproval -->|Approved| IssueLOI[Generate & Send LOI] + LOIDocRequest --> CollectDocs[Collect Mandatory LOI Documents
DIP Booklet, Profile Sheet, PAN/Aadhaar,
CIBIL Reports, Layout Drawings, etc.] + CollectDocs --> VerifyDocs[DD-Admin Verifies Document Completeness] + VerifyDocs --> VerifyWorkNotes[Work Notes: DD-Admin adds verification remarks
@Finance if clarification needed] + VerifyWorkNotes --> DocsComplete{Documents Complete?} + DocsComplete -->|No| RequestMoreDocs[Request Missing Documents
Work Notes: Log missing items] + RequestMoreDocs --> CollectDocs + DocsComplete -->|Yes| SecurityDeposit[Request Security Deposit via RTGS/NEFT
Work Notes: Status update] - IssueLOI --> UploadLOI[Upload LOI to System] - UploadLOI --> IssueLOA[Generate & Send LOA] - IssueLOA --> UploadLOA[Upload LOA to System] + SecurityDeposit --> UploadDepositProof[Applicant Uploads Deposit Proof
Transaction Slip/Confirmation] + UploadDepositProof --> FinanceVerify[Finance Verifies Security Deposit
Cross-check with Corporate Account] + FinanceVerify --> FinanceVerifyNotes[Work Notes: Finance adds verification remarks
@DD-Admin if discrepancy found] + FinanceVerifyNotes --> DepositDecision{Deposit Verified?} + DepositDecision -->|No| DepositReject[Flag Discrepancy & Notify
Work Notes: Log discrepancy details] + DepositDecision -->|Yes| LOIApproval[LOI Approval Workflow
Work Notes: Status update logged] - UploadLOA --> ScheduleEOR[Regional DD Schedules EOR Audit] - ScheduleEOR --> UploadEOR[Upload EOR Audit Report] - UploadEOR --> EORApproval{NBH EOR Approval} + LOIApproval --> FinanceApproval[Finance Reviews LOI Documents
Work Notes: Finance adds approval remarks] + FinanceApproval --> FinanceLOIDecision{Finance Approval} + FinanceLOIDecision -->|Rejected| LOIReject1[Store Rejection & Notify
Work Notes: Log rejection reason] + FinanceLOIDecision -->|Approved| DDHeadApproval[DD-Head Reviews LOI
Validates Business Justification
Work Notes: DD-Head adds remarks] + DDHeadApproval --> DDHeadLOIDecision{DD-Head Approval} + DDHeadLOIDecision -->|Rejected| LOIReject2[Store Rejection & Notify
Work Notes: Log rejection reason] + DDHeadLOIDecision -->|Approved| NBHLOIApproval[NBH Reviews LOI
Final Release Authorization
Work Notes: NBH adds final remarks] - EORApproval -->|Rejected| EORReject[Store Rejection & Notify] - EORApproval -->|Approved| UpdateDealer[Update Dealer Info: Inauguration Date, Codes] + NBHLOIApproval --> NBHLOIDecision{NBH Final Approval} + NBHLOIDecision -->|Rejected| LOIReject3[Store Rejection & Notify
Work Notes: Log rejection reason] + NBHLOIDecision -->|Approved| GenerateLOI[Generate & Send LOI
Email & WhatsApp to Applicant
Work Notes: LOI issuance logged] + GenerateLOI --> UploadLOI[Upload LOI to System
Work Notes: Document upload logged] + UploadLOI --> LOIAck[Applicant Uploads LOI Acknowledgement Copy
Signed with Seal] + + LOIAck --> GenerateDealerCode[Generate Dealer Code via SAP OData API] + GenerateDealerCode --> AssignArchitecture[Assign to Architecture/Brand Experience Team] + + AssignArchitecture --> ArchWork[Architectural Work: Upload DWG Layout & Drawings] + ArchWork --> DealerConsent{Dealer Provides Layout Consent} + DealerConsent -->|Rejected| ReviseLayout[Revise Layout] + ReviseLayout --> ArchWork + DealerConsent -->|Approved| StatutoryDocs[Collect Statutory Documents] + + StatutoryDocs --> UploadStatutory[Upload: GST, PAN, Nodal Agreement,
Partnership Deed, Firm Registration,
Rental Agreement, Virtual Code,
Domain ID, MSD Config, etc.] + UploadStatutory --> VerifyStatutory[Finance & Legal Verify Documents
Work Notes: Verifiers add comments
@DD-Admin if issues found] + VerifyStatutory --> StatutoryDecision{Documents Verified?} + StatutoryDecision -->|No| RequestStatutory[Request Re-submission
Work Notes: Log missing/invalid items] + RequestStatutory --> UploadStatutory + StatutoryDecision -->|Yes| EORChecklist[EOR: Essential Operating Requirements Checklist
Work Notes: Status update logged] + + EORChecklist --> VerifyEOR[All Teams Verify EOR Parameters:
Sales, Service, IT, Finance,
Training, Architecture, etc.
Work Notes: Teams add verification comments] + VerifyEOR --> EORWorkNotes[Work Notes: DD-Admin monitors progress
@tag teams for pending items] + EORWorkNotes --> EORComplete{EOR 100% Complete?} + EORComplete -->|No| ContinueEOR[Continue EOR Verification
Work Notes: Track pending items] + ContinueEOR --> VerifyEOR + EORComplete -->|Yes| LOARequest[LOA: Request Preparation
Work Notes: EOR completion logged] + + LOARequest --> LOAApproval[LOA Approval: DD-Head + NBH Review
Work Notes: Reviewers add approval remarks] + LOAApproval --> LOAApproved{LOA Approved?} + LOAApproved -->|Rejected| LOAReject[Store Rejection & Notify
Work Notes: Log rejection reason] + LOAApproved -->|Approved| GenerateLOA[Generate & Send LOA
Email & WhatsApp to Applicant
Work Notes: LOA issuance logged] + GenerateLOA --> UploadLOA[Upload LOA to System
Work Notes: Document upload logged] + + UploadLOA --> ScheduleInauguration[Schedule Inauguration Event] + ScheduleInauguration --> UploadInauguration[Upload Inauguration Report & Photos] + UploadInauguration --> UpdateDealer[Update Dealer Info:
Inauguration Date, Status, Codes] UpdateDealer --> ActiveDealer[Active Dealer] - ActiveDealer --> End[Onboarding Complete] + ActiveDealer --> End([Onboarding Complete]) style Start fill:#90EE90 style End fill:#FFB6C1 style ActiveDealer fill:#87CEEB - style NBHApproval fill:#FFD700 - style EORApproval fill:#FFD700 + style ScheduleL1 fill:#E6F3FF + style ScheduleL2 fill:#E6F3FF + style ScheduleL3 fill:#E6F3FF + style SendCalendarL1 fill:#E6F3FF + style SendCalendarL2 fill:#E6F3FF + style SendCalendarL3 fill:#E6F3FF + style Level1Decision fill:#FFE4B5 + style Level2Decision fill:#FFE4B5 + style Level3Decision fill:#FFD700 + style AISummary fill:#FFE4B5 + style FinanceReview fill:#FFE4B5 + style FinanceDecision fill:#FFE4B5 + style FinanceVerify fill:#FFE4B5 + style DepositDecision fill:#FFE4B5 + style FinanceLOIDecision fill:#FFE4B5 + style DDHeadLOIDecision fill:#FFD700 + style NBHLOIDecision fill:#FFD700 + style DocsComplete fill:#FFE4B5 + style StatutoryDecision fill:#FFE4B5 + style EORComplete fill:#FFE4B5 + style LOAApproved fill:#FFD700 + style WorkNotes1 fill:#FFF8DC + style WorkNotesL1 fill:#FFF8DC + style WorkNotesL2 fill:#FFF8DC + style WorkNotesL3 fill:#FFF8DC + style FDDWorkNotes fill:#FFF8DC + style FinanceWorkNotes fill:#FFF8DC + style VerifyWorkNotes fill:#FFF8DC + style FinanceVerifyNotes fill:#FFF8DC diff --git a/mermaids/dealer_onboard_comprehensive.mermaid b/mermaids/dealer_onboard_comprehensive.mermaid new file mode 100644 index 0000000..175efeb --- /dev/null +++ b/mermaids/dealer_onboard_comprehensive.mermaid @@ -0,0 +1,300 @@ +graph TB + %% ============================================ + %% DEALER ONBOARDING COMPREHENSIVE WORKFLOW + %% Based on Re_New_Dealer_Onboard.md + %% ============================================ + + Start([Dealer Inquiry Received]) --> SubmitForm[Applicant Submits
'Become a Dealer' Form
Captures: Name, Mobile, Email, Age,
Country, State, District, Pincode,
Interested City, Company Name,
Education, Ownership Details, Address] + + SubmitForm --> StoreApp[System Stores Application
in Database & Shows in Listing] + StoreApp --> CheckOpportunity{System Checks Location
Against Opportunity Master
Has Vacancy?} + + CheckOpportunity -->|No Opportunity| NonOppEmail[Send Non-Opportunity Email
Informs: Region Closed
Info Retained for Future Reference] + CheckOpportunity -->|Opportunity Exists| OppEmail[Send Opportunity Email
with Login Credentials
& Questionnaire Link] + + OppEmail --> AccessQuestionnaire[Applicant Accesses
Questionnaire Portal] + AccessQuestionnaire --> FillQuestionnaire[Applicant Fills Comprehensive
Questionnaire:
Personal Information
Financial Information
Business Information] + + FillQuestionnaire --> AutoScore[System Auto-Scores Responses
Calculates Weighted Rank
Generates Questionnaire Score
e.g., 78/100] + AutoScore --> AdminBucket[Application Moves to
Admin Review Bucket] + + AdminBucket --> DDAdminReview[DD-Admin Reviews Application
Validates Details & Documents
Work Notes: Adds Remarks] + DDAdminReview --> AdminDecision{Admin Decision:
Shortlist or Archive?} + + AdminDecision -->|Archive| ArchiveApp[Archive for Future
Opportunities] + AdminDecision -->|Shortlist| AssignZone[Assign to Respective
Zone/Region
Work Notes: Assignment logged] + + AssignZone --> AssignZM[Auto-Assign to
DD-ZM & RBM] + + %% ============================================ + %% LEVEL 1 INTERVIEW PROCESS + %% ============================================ + AssignZM --> ScheduleL1[DD-Admin Schedules Level 1 Interview
Interview Type: Level 1
Mode: Virtual Google Meet OR Physical Venue
Date & Time: Calendar Selection
Participants: DD-ZM, RBM, Applicant
Meeting Link/Venue: Admin Enters] + + ScheduleL1 --> SendCalL1[System Sends Google Calendar Invites
to DD-ZM, RBM & Applicant
Contains: Date, Time, Mode, Link/Venue] + SendCalL1 --> ConductL1[Level 1 Interview Conducted
DD-ZM + RBM with Applicant
Virtual via Google Meet OR Physical] + + ConductL1 --> EvalL1[Level 1 Evaluation Process] + EvalL1 --> KTMatrixL1[DD-ZM & RBM Fill KT Matrix
Quantitative Scoring:
- Age & Qualification
- Local Knowledge & Influence
- Passion for Royal Enfield & Riding
- Business Acumen & Investment Capacity
- Base Location vs Applied Location
- Property Ownership
- Time Availability
- Future Expansion Plans
Total: 100% Weighted] + + KTMatrixL1 --> FeedbackL1[DD-ZM & RBM Submit
Interview Feedback Form
Qualitative Assessment:
- Strategic Vision & Market Understanding
- Management Capabilities
- Operational Readiness
- Key Strengths & Areas of Concern
Overall Performance Score
Final Recommendation: Approve/Reject/Hold] + + FeedbackL1 --> WorkNotesL1[Work Notes: Panelists Add Comments
@tag Users for Clarifications
Time-Stamped Communication Trail] + WorkNotesL1 --> RankL1[System Auto-Calculates
Total KT Matrix Score
Updates Applicant Rank
within City/Region] + + RankL1 --> DecisionL1{Level 1 Decision
Approve or Reject} + DecisionL1 -->|Rejected| RejectL1[Store Rejection Reason
Work Notes: Log Decision
Notify Applicant via Email & WhatsApp
Audit Trail: Action Logged] + DecisionL1 -->|Approved| AssignL2[Auto-Assign to
DD-Lead + ZBH
Work Notes: Status Update Logged] + + %% ============================================ + %% LEVEL 2 INTERVIEW PROCESS + %% ============================================ + AssignL2 --> ScheduleL2[DD-Admin Schedules Level 2 Interview
Interview Type: Level 2
Mode: Virtual Google Meet OR Physical Venue
Date & Time: Calendar Selection
Participants: DD-Lead, ZBH, Applicant
Meeting Link/Venue: Admin Enters] + + ScheduleL2 --> SendCalL2[System Sends Google Calendar Invites
to DD-Lead, ZBH & Applicant
Contains: Date, Time, Mode, Link/Venue] + SendCalL2 --> ConductL2[Level 2 Interview Conducted
DD-Lead + ZBH with Applicant
Virtual via Google Meet OR Physical] + + ConductL2 --> EvalL2[Level 2 Evaluation Process] + EvalL2 --> FeedbackL2[DD-Lead & ZBH Submit
Interview Feedback Form
Business Strategy & Operational Assessment:
- Strategic Alignment
- Business Viability
- Operational Capability
- Market Understanding
Final Recommendation: Approve/Reject/Hold] + + FeedbackL2 --> WorkNotesL2[Work Notes: Panelists Add Comments
@tag Users for Clarifications
Time-Stamped Communication Trail] + WorkNotesL2 --> DecisionL2{Level 2 Decision
Approve or Reject} + + DecisionL2 -->|Rejected| RejectL2[Store Rejection Reason
Work Notes: Log Decision
Notify Applicant via Email & WhatsApp
Audit Trail: Action Logged] + DecisionL2 -->|Approved| AssignL3[Auto-Assign to
NBH + DD-Head
Work Notes: Status Update Logged] + + %% ============================================ + %% LEVEL 3 INTERVIEW PROCESS WITH AI + %% ============================================ + AssignL3 --> ScheduleL3[DD-Admin Schedules Level 3 Interview
Interview Type: Level 3
Mode: Virtual Google Meet OR Physical Venue
Date & Time: Calendar Selection
Participants: NBH, DD-Head, Applicant
Meeting Link/Venue: Admin Enters] + + ScheduleL3 --> SendCalL3[System Sends Google Calendar Invites
to NBH, DD-Head & Applicant
Contains: Date, Time, Mode, Link/Venue] + SendCalL3 --> ConductL3[Level 3 Interview Conducted
NBH + DD-Head with Applicant
Virtual via Google Meet OR Physical] + + ConductL3 --> EvalL3[Level 3 Evaluation Process] + EvalL3 --> CollectAllFeedback[Collect All Panel Feedback
RBM, ZBH, DD-ZM, DD-Lead, DD-Head
Quantitative Scores + Qualitative Insights
Using Dealer Interview Recommendation Sheet] + + CollectAllFeedback --> AIGenerate[AI Engine Gemini API
Processes All Inputs
Generates 2-3 Line Summary:
- Consensus Trend Across Panelists
- Applicant Key Strengths & Differentiators
- Potential Concerns or Areas for Improvement] + + AIGenerate --> NBHReview[NBH Reviews AI Summary
Editable Format
Can Modify or Approve Directly] + NBHReview --> WorkNotesL3[Work Notes: NBH Adds Final Remarks
@tag Stakeholders if Needed
Time-Stamped Communication Trail] + + WorkNotesL3 --> DecisionL3{Level 3 Final Decision
Approve or Reject} + DecisionL3 -->|Rejected| RejectL3[Store Rejection Reason
Work Notes: Log Decision
Notify Applicant via Email & WhatsApp
Audit Trail: Action Logged] + DecisionL3 -->|Approved| AssignFDD[Auto-Assign to FDD Team
External Agency
Work Notes: Status Update Logged] + + %% ============================================ + %% FDD PROCESS + %% ============================================ + AssignFDD --> SendFDDLink[System Sends OTP-Protected Link
to External FDD Agency
SSO Credentials for Access] + + SendFDDLink --> FDDAccess[FDD Team Accesses
Restricted Interface
Views Assigned Applications Only] + FDDAccess --> FDDWorkNotes[Work Notes: FDD Can Raise Queries
@DD-Admin or @Finance
Request Missing Documents
Flag Non-Responsive Applicants] + + FDDWorkNotes --> FDDUpload[FDD Team Uploads FDD Report
L1/L2 Reports with Remarks:
- Bank Statements
- Income Tax Returns
- Credit Reports
- Property Papers
- Business Valuation Reports] + + FDDUpload --> FDDSubmit[FDD Marks Report as Submitted
Locks Further Edits
Work Notes: Submission Logged] + + FDDSubmit --> FinanceReview[Finance Team Reviews FDD Report
Validates Financial Compliance
Work Notes: Finance Adds Review Comments
@DD-Lead for Clarifications if Needed] + + FinanceReview --> FinanceFDDDecision{Finance Decision
Approve or Reject} + FinanceFDDDecision -->|Rejected| RejectFDD[Store Rejection & Notify
Work Notes: Log Rejection Reason
Notify DD-Admin & Applicant] + FinanceFDDDecision -->|Approved| LOIDocRequest[LOI: Request Documents
from Applicant
Work Notes: Status Update Logged] + + %% ============================================ + %% LOI DOCUMENT COLLECTION + %% ============================================ + LOIDocRequest --> RequestLOIDocs[DD-Admin Requests LOI Documents
Automated Request to Applicant
Linked Folder Structure:
Region → Prospect Name → Location →
Interview Date → LOI Issuance Date] + + RequestLOIDocs --> CollectLOIDocs[Applicant Uploads Mandatory Documents:
- DIP Booklet filled & signed by RBM
- Profile Sheet
- Dealership Application Form
- Interview Feedback Forms RBM & ZBH
- Land Selection Criteria Sheet
- Logic Note & Comparative Logic Note
- Zonal Evaluation Form
- Authorization Letter
- City Map PPT
- Proposed Location Photos min 20 PPT
- Layout Drawings PPT
- Viability Sheet
- Project Plan
- Self-signed PAN/Aadhaar all partners both sides
- CIBIL Reports all partners
- Dealership Name & Address Email from RBM
- Rental/Lease Agreement or Consent Letter] + + CollectLOIDocs --> VerifyLOIDocs[DD-Admin Verifies Document Completeness
Checks Folder Format & Metadata
Interview Date, LOI Issuance Date,
Document Ageing Tracking] + + VerifyLOIDocs --> VerifyWorkNotes[Work Notes: DD-Admin Adds
Verification Remarks
@Finance if Clarification Needed] + VerifyWorkNotes --> DocsComplete{Documents Complete?} + + DocsComplete -->|Incomplete| RequestMoreDocs[Request Missing Documents
Work Notes: Log Missing Items
System Reminder to Applicant] + RequestMoreDocs --> CollectLOIDocs + + DocsComplete -->|Complete| RequestSecurityDeposit[Request Security Deposit
via RTGS/NEFT
Work Notes: Status Update] + + %% ============================================ + %% SECURITY DEPOSIT VERIFICATION + %% ============================================ + RequestSecurityDeposit --> UploadDeposit[Applicant Uploads Deposit Proof
Transaction Slip or Confirmation] + + UploadDeposit --> FinanceVerifyDeposit[Finance Verifies Security Deposit
Cross-Checks with Corporate Account
Validates Transaction ID, Amount, Bank Record] + + FinanceVerifyDeposit --> FinanceDepositNotes[Work Notes: Finance Adds
Verification Remarks
@DD-Admin if Discrepancy Found] + FinanceDepositNotes --> DepositDecision{Deposit Verified?} + + DepositDecision -->|Rejected| RejectDeposit[Flag Discrepancy & Notify
Work Notes: Log Discrepancy Details
Request Correct Proof] + RejectDeposit --> UploadDeposit + + DepositDecision -->|Approved| LOIApprovalWorkflow[LOI Approval Workflow
Work Notes: Status Update Logged] + + %% ============================================ + %% LOI APPROVAL WORKFLOW + %% ============================================ + LOIApprovalWorkflow --> FinanceLOIReview[Finance Reviews LOI Documents
Verifies Document Completeness
Validates Security Deposit
Work Notes: Finance Adds Approval Remarks] + + FinanceLOIReview --> FinanceLOIDecision{Finance Approval} + FinanceLOIDecision -->|Rejected| RejectLOI1[Store Rejection & Notify
Work Notes: Log Rejection Reason
Notify DD-Admin & Applicant] + + FinanceLOIDecision -->|Approved| DDHeadLOIReview[DD-Head Reviews LOI
Validates Business Justification
Network Alignment
Work Notes: DD-Head Adds Remarks] + + DDHeadLOIReview --> DDHeadLOIDecision{DD-Head Approval} + DDHeadLOIDecision -->|Rejected| RejectLOI2[Store Rejection & Notify
Work Notes: Log Rejection Reason
Notify Finance & Applicant] + + DDHeadLOIDecision -->|Approved| NBHLOIReview[NBH Reviews LOI
Final Release Authorization
Work Notes: NBH Adds Final Remarks] + + NBHLOIReview --> NBHLOIDecision{NBH Final Approval} + NBHLOIDecision -->|Rejected| RejectLOI3[Store Rejection & Notify
Work Notes: Log Rejection Reason
Notify DD-Head, Finance & Applicant] + + NBHLOIDecision -->|Approved| GenerateLOI[Generate LOI Document
Auto-Populated with Applicant Details
Approved RE Format] + + GenerateLOI --> UploadLOI[DD-Admin Uploads LOI to System
Tagged: Issue Date, Authorized Signatory,
Document Version, Upload Timestamp
Work Notes: Document Upload Logged] + + UploadLOI --> SendLOI[System Sends LOI
via Email & WhatsApp
to Applicant
Notification to All Stakeholders] + + SendLOI --> LOIAcknowledgement[Applicant Uploads
LOI Acknowledgement Copy
Signed with Seal & Signature] + + %% ============================================ + %% DEALER CODE GENERATION + %% ============================================ + LOIAcknowledgement --> GenerateDealerCode[DD-Admin Initiates
Dealer Code Creation
via SAP OData API Integration] + + GenerateDealerCode --> CreateCodes[System Generates & Stores Codes:
- Sales Code
- Service Code
- GMA Genuine Motorcycle Accessories Code
- Gear Code
Links to DMS, MSD, CRM Systems] + + CreateCodes --> CodeComplete[Dealer Code Generated
Status: Dealer Code Generated
Notifications: DD-Admin, Finance, Legal
Audit Trail: Code Creation Logged] + + %% ============================================ + %% ARCHITECTURAL WORK + %% ============================================ + CodeComplete --> AssignArchitecture[DD-Admin Assigns Case
to Architecture/Brand Experience Team] + + AssignArchitecture --> ArchUpload[Architecture Team Uploads:
- DWG Layout
- Site Dimension Drawings
- Multiple Drawing Sets] + + ArchUpload --> DealerConsent[Dealer Provides Written Consent
via Email Confirming Acceptance
of Layout as per Vastu & Design Guidelines] + + DealerConsent --> ConsentDecision{Dealer Consent
Approved?} + ConsentDecision -->|Rejected| ReviseLayout[Revise Layout
Work Notes: Log Revision Request] + ReviseLayout --> ArchUpload + + ConsentDecision -->|Approved| IssueLayout[Final Layout Issued to Dealer
Multiple Drawing Sets for Construction
Work Notes: Layout Issuance Logged] + + IssueLayout --> DealerConstruction[Dealer Initiates Infrastructure Work
Progress Tracked via Uploaded
Photographs or Reports] + + %% ============================================ + %% STATUTORY DOCUMENTATION + %% ============================================ + DealerConstruction --> CollectStatutory[Collect Statutory Documents
Admin & Architecture Teams Coordinate] + + CollectStatutory --> UploadStatutory[Applicant Uploads Statutory Documents:
- GST Registration Certificate
- PAN
- Nodal Agreement
- Cancelled Cheque
- Partnership Deed / LLP / MOA / AOA / COI
- Firm Registration Certificate
- Rental / Lease / Land Agreement
- Virtual Code Confirmation
- Domain ID for @dealer.royalenfield.com
- MSD Microsoft Dynamics Configuration
- LOI Acknowledgement Copy Signed] + + UploadStatutory --> VerifyStatutory[Finance & Legal Verify Documents
Update Status: Verified / Pending /
Re-submit Required
Add Remarks] + + VerifyStatutory --> StatutoryWorkNotes[Work Notes: Verifiers Add Comments
@DD-Admin if Issues Found
Time-Stamped Trail] + StatutoryWorkNotes --> StatutoryDecision{All Documents Verified?} + + StatutoryDecision -->|Rejected| RequestStatutory[Request Re-submission
Work Notes: Log Missing/Invalid Items
Notify Applicant] + RequestStatutory --> UploadStatutory + + StatutoryDecision -->|Approved| EORChecklist[EOR: Essential Operating
Requirements Checklist
Work Notes: Status Update Logged] + + %% ============================================ + %% EOR CHECKLIST VERIFICATION + %% ============================================ + EORChecklist --> EORVerify[All Functional Teams Verify
EOR Parameters:
- Sales Team: Sales Standards
- Service Team: Service Tools & Equipment
- IT Team: DMS/MSD Configuration & Connectivity
- Finance Team: Financial Readiness
- Training Team: Staff Training Completion
- Architecture Team: Brand Signage & Facility
- Display Vehicle Readiness
- Spare Inventory Availability
- Safety & Security Compliance
- Test Ride Vehicles Ready] + + EORVerify --> EORWorkNotes[Work Notes: DD-Admin Monitors Progress
@tag Teams for Pending Items
Time-Stamped Updates] + + EORWorkNotes --> EORProgress[System Tracks Progress Bar
Shows Completion Percentage
e.g., 12/16 Items Complete] + + EORProgress --> EORComplete{EOR 100% Complete?} + EORComplete -->|No| ContinueEOR[Continue EOR Verification
Work Notes: Track Pending Items
SLA Reminders if Needed] + ContinueEOR --> EORVerify + + EORComplete -->|Yes| EORReady[EOR Completed
System Auto-Transitions to
Inauguration Readiness
Work Notes: Completion Logged
Notifications: DD-Head, NBH] + + %% ============================================ + %% LOA ISSUANCE + %% ============================================ + EORReady --> LOARequest[LOA: Request Preparation
DD-Admin Initiates LOA Document] + + LOARequest --> LOAReview[DD-Head Reviews:
- Infrastructure Completion
- EOR Readiness
- Compliance Artefacts
Work Notes: DD-Head Adds Remarks] + + LOAReview --> NBHLOAReview[NBH Reviews:
- Final Sign-Off Authorization
- Brand Readiness Assessment
- Site Validation & Inspection
Work Notes: NBH Adds Final Remarks] + + NBHLOAReview --> LOADecision{LOA Approved?} + LOADecision -->|Rejected| RejectLOA[Store Rejection & Notify
Work Notes: Log Rejection Reason
Notify DD-Head & DD-Admin] + + LOADecision -->|Approved| GenerateLOA[Generate LOA Document
Official Authorization to Operate
under Royal Enfield] + + GenerateLOA --> UploadLOA[DD-Admin Uploads LOA to System
Tagged: Issue Date, Authorized Signatory,
Document Version, Upload Timestamp
Work Notes: Document Upload Logged] + + UploadLOA --> SendLOA[System Sends LOA
via Email & WhatsApp
to Applicant
Notification to All Stakeholders] + + %% ============================================ + %% INAUGURATION + %% ============================================ + SendLOA --> ScheduleInauguration[DD-Admin Coordinates
Inauguration Event
with NBH, ZBH, RBM,
Brand Experience Teams] + + ScheduleInauguration --> InaugurationEvent[Inauguration Event Conducted
Date & Venue Logged
Attendees: NBH, DD-Head, ZBH, RBM,
Architecture, Brand Experience] + + InaugurationEvent --> UploadInauguration[Upload Inauguration Report:
- Event Summary Report
- Photographs
- Press Releases
- Video References] + + UploadInauguration --> UpdateDealerStatus[Update Dealer Info:
- Inauguration Date
- Status: Active Dealer
- All Codes Mapped
- Operational Status: Live] + + UpdateDealerStatus --> ActiveDealer[Active Dealer Created
Dealership Live / Onboarded
System Status: Active] + + ActiveDealer --> End([Onboarding Complete
Dealership Operational]) + + %% ============================================ + %% AUDIT TRAIL & SYSTEM GOVERNANCE + %% ============================================ + Start -.->|All Actions Logged| AuditTrail[Audit Trail & Activity Log
Chronological Record:
- User Action & Timestamp
- Uploaded Artefacts & Version Control
- Notifications Sent
- Approvals Received
- Work Notes Entries
- System Events] + + AuditTrail -.-> End + + %% ============================================ + %% STYLING + %% ============================================ + style Start fill:#90EE90,stroke:#006400,stroke-width:3px + style End fill:#FFB6C1,stroke:#8B0000,stroke-width:3px + style ActiveDealer fill:#87CEEB,stroke:#000080,stroke-width:3px + + style ScheduleL1 fill:#E6F3FF,stroke:#0066CC,stroke-width:2px + style ScheduleL2 fill:#E6F3FF,stroke:#0066CC,stroke-width:2px + style ScheduleL3 fill:#E6F3FF,stroke:#0066CC,stroke-width:2px + style SendCalL1 fill:#E6F3FF,stroke:#0066CC,stroke-width:2px + style SendCalL2 fill:#E6F3FF,stroke:#0066CC,stroke-width:2px + style SendCalL3 fill:#E6F3FF,stroke:#0066CC,stroke-width:2px + + style DecisionL1 fill:#FFE4B5,stroke:#FF8C00,stroke-width:2px + style DecisionL2 fill:#FFE4B5,stroke:#FF8C00,stroke-width:2px + style DecisionL3 fill:#FFD700,stroke:#FF8C00,stroke-width:3px + style AIGenerate fill:#FFE4B5,stroke:#FF8C00,stroke-width:2px + + style FinanceFDDDecision fill:#FFE4B5,stroke:#FF8C00,stroke-width:2px + style FinanceLOIDecision fill:#FFE4B5,stroke:#FF8C00,stroke-width:2px + style DDHeadLOIDecision fill:#FFD700,stroke:#FF8C00,stroke-width:2px + style NBHLOIDecision fill:#FFD700,stroke:#FF8C00,stroke-width:3px + style DepositDecision fill:#FFE4B5,stroke:#FF8C00,stroke-width:2px + style DocsComplete fill:#FFE4B5,stroke:#FF8C00,stroke-width:2px + style StatutoryDecision fill:#FFE4B5,stroke:#FF8C00,stroke-width:2px + style EORComplete fill:#FFE4B5,stroke:#FF8C00,stroke-width:2px + style LOADecision fill:#FFD700,stroke:#FF8C00,stroke-width:3px + + style WorkNotesL1 fill:#FFF8DC,stroke:#DAA520,stroke-width:2px + style WorkNotesL2 fill:#FFF8DC,stroke:#DAA520,stroke-width:2px + style WorkNotesL3 fill:#FFF8DC,stroke:#DAA520,stroke-width:2px + style FDDWorkNotes fill:#FFF8DC,stroke:#DAA520,stroke-width:2px + style FinanceWorkNotes fill:#FFF8DC,stroke:#DAA520,stroke-width:2px + style VerifyWorkNotes fill:#FFF8DC,stroke:#DAA520,stroke-width:2px + style FinanceDepositNotes fill:#FFF8DC,stroke:#DAA520,stroke-width:2px + style StatutoryWorkNotes fill:#FFF8DC,stroke:#DAA520,stroke-width:2px + style EORWorkNotes fill:#FFF8DC,stroke:#DAA520,stroke-width:2px + + style AuditTrail fill:#F0F0F0,stroke:#808080,stroke-width:2px,stroke-dasharray: 5 5 +