1626 lines
66 KiB
Markdown
1626 lines
66 KiB
Markdown
# RE Onboarding & Offboarding System
|
||
|
||
# Requirements
|
||
|
||
```
|
||
System Requirements Specifications
|
||
```
|
||
## 16 - Oct- 2025
|
||
|
||
## Version 1. 4
|
||
|
||
|
||
## Contents
|
||
|
||
|
||
- Change Log
|
||
- 1.1 Change Log – Version 2.0
|
||
- 1.2 Change Log – Dealer Self-Service Enablement
|
||
- 1 System Overview & Problem Statement
|
||
- 2 Intended Audience
|
||
- 2.1 Business & Functional Users
|
||
- 2.2 External & Integrated Stakeholders
|
||
- 3 Definitions and Acronyms
|
||
- 4 HiFi Wireframes & Flow of Application
|
||
- 4.1 Dealer onboarding - Process Flow Overview
|
||
- 4.2 Dealer Resignation – Process Flow Overview
|
||
- 4.3 Dealer Termination – Process Flow Overview
|
||
- 4.4 Dealer Full & Final (F&F) Settlement – Process Flow
|
||
- 4.5 Finance Team – Process Flow
|
||
- 5 System Features & Requirements
|
||
- 6 Dealer onboarding
|
||
- 6.1 Dealership Application Form
|
||
- 6.2 SSO Login
|
||
- 6.3 Dashboard
|
||
- 6.4 Opportunity & Non Opportunity
|
||
- 6.5 Questionnaire Response
|
||
- 6.6 Shortlisting Process
|
||
- 6.7 Shortlisted Applicants
|
||
- 6.8 Application Detail View
|
||
- 6.9 Interview Scheduling & Coordination
|
||
- 6.10 Interview Evaluation & Feedback Management
|
||
- 6.11 Interview Feedback & Evaluation Summary
|
||
- 6.12 Application Approval & Rejection Workflow
|
||
- 6.13 Work Notes & Internal Communication Trail
|
||
- 6.14 System Notifications & Alerts
|
||
- 6.15 FDD (Financial Due Diligence) & Finance Module
|
||
- 6.16 LOI Approval & Issuance
|
||
- 6.17 Dealer Code Generation, Architectural Work & Statutory Documentation............
|
||
- 6.18 LOA Issuance, Essential Operating Requirements & Inauguration
|
||
- 6.19 Essential Operating Requirements (EOR) Checklist
|
||
- 6.20 Progress Tracker.......................................................................................................
|
||
- 6.21 Central Document Repository
|
||
- 6.22 Audit Trail & Activity Log..........................................................................................
|
||
- 7 Dealer Resignation
|
||
- 7.1 Dealer Resignation Request (Initiation)
|
||
- 7.2 Resignation Management Dashboard
|
||
- 7.3 Resignation Details & Review
|
||
- 7.4 Resignation Request Review & Action Management
|
||
- 7.5 Resignation Progress Tracker
|
||
- 7.6 Documents & Audit Trail
|
||
- 8 Termination
|
||
- 8.1 Create Termination Request
|
||
- 8.2 Termination Ticket overview
|
||
- 8.3 Termination Approval & Review Process
|
||
- 8.4 Termination Progress Timeline
|
||
- 9 Admin Section
|
||
- 9.1 Master Configuration – Organization
|
||
- 9.2 Zone, Region & Area Configuration
|
||
- 9.3 Roles & permissions
|
||
- 9.4 SLA Configuration & Escalation Management
|
||
- 9.5 Email & Letter Templates Management
|
||
- 9.6 Opportunity Management (Geography & Window Setup)
|
||
- 10 F&F Case
|
||
- 10.1 F&F Settlement Progress Timeline
|
||
- 10.2 Department Responses
|
||
- 11 Finance Dashboard
|
||
- 11.1 Finance Dashboard Page
|
||
- 11.2 F&F Settlement Module
|
||
- 12 Dealer Persona
|
||
- 12.1 Dealer Resignation
|
||
- 12.2 Dealer Constitutional Change Management
|
||
- 13 Non-Functional Requirements
|
||
- 14 Technology Matrix
|
||
- 15 Infra requirements & System Hygiene
|
||
- 16 Not in scope
|
||
|
||
|
||
## Change Log
|
||
|
||
### 1.1 Change Log – Version 2.0
|
||
|
||
**Module:** Dealer Onboarding & Offboarding System
|
||
**Change Type:** Clarifications, Role Alignment & Access Control Enhancements
|
||
**Scope Enhancement :** Dealer Role and Access control
|
||
**Change demarcation** : Highlighted in Yellow
|
||
**Changes suggested by** : Ashok & Tariq
|
||
**Changed performed by** : Rohit Mandiwal
|
||
**Changes done on** : 31 - Dec- 2025
|
||
|
||
**1.1.1 Notification Channel Enhancement**
|
||
|
||
- Added **WhatsApp as a supported notification channel** for reminders and workflow
|
||
communications (e.g., questionnaire completion and status updates), while restricting
|
||
sensitive document sharing to email only.
|
||
|
||
**1.1.2 LOI Governance & Communication Clarifications**
|
||
|
||
- Clarified that the **Finance team is not the decision-making authority** for LOI issuance
|
||
and is responsible only for financial validation.
|
||
- Confirmed that **LOI documents are shared exclusively via official email** and not through
|
||
WhatsApp.
|
||
- Clarified that **LOA issuance is a parallel statutory activity** and is **not dependent on**
|
||
**infrastructure readiness**.
|
||
|
||
**1.1.3 Dealer Code Creation Control**
|
||
|
||
- Clarified that **Dealer Codes (SAP Master) are created only upon explicit trigger by the**
|
||
**DD Admin** , and not through automatic system generation.
|
||
|
||
**1.1.4 LOA & EOR Sequencing Correction**
|
||
|
||
- Corrected the workflow sequence to ensure that **LOA is issued prior to initiating the**
|
||
**EOR checklist** , with EOR serving as the final readiness validation before go-live.
|
||
|
||
**1.1.5 Dealer Resignation Access & Workflow Enhancements**
|
||
|
||
- Enabled **dealer portal access** for initiating resignation requests and uploading required
|
||
information.
|
||
|
||
|
||
- Clarified that the **Legal team issues the Resignation Acceptance Letter** in all cases.
|
||
- Expanded review authority to allow **ZBH, DD Lead, DD Head, and NBH** to **Send Back or**
|
||
**Revoke resignation requests** , with communication routed through **Work Notes**.
|
||
- Confirmed that **Full & Final (F&F) settlement is triggered strictly on the Last Working**
|
||
**Day (LWD)** and not based on approval date.
|
||
|
||
**1.1.6 Termination Workflow Governance Updates**
|
||
|
||
- Clarified that **CEO is the final approving authority** for dealer termination cases.
|
||
- Included **CCO and CEO** as approval authorities with **Approve / Hold / Reject** options.
|
||
- Confirmed that the **Legal team issues termination letters only after CEO approval**.
|
||
- Removed **dealer portal access** from termination workflows.
|
||
- Extended **Send Back / Revoke** authority to **ZBH and DD Lead** for termination reviews.
|
||
- Aligned **F&F trigger for termination** to occur strictly on the **Last Working Day (LWD)**.
|
||
|
||
**1.1.7 Role & Persona Alignment**
|
||
|
||
- Added **NBH** to the personas section.
|
||
- Added **RBM** to applicable review and approval tables.
|
||
- Clarified that **DD ASM is responsible for interview scheduling and coordination** , with
|
||
no Admin involvement.
|
||
|
||
**1.1.8 Access Control & Visibility Refinements**
|
||
|
||
- Defined **view-only access** for DD ASM, DD ZM, and RBM at relevant workflow stages.
|
||
- Granted **approval visibility** to DD Lead where applicable.
|
||
- Enabled **DD ASM and DD ZM** to upload site readiness and LOA-related documents,
|
||
with **DD Lead, RBM, and ZBH** having view access.
|
||
- Limited applicant and dealer portal access to **stage-specific and context-specific**
|
||
**scenarios only**.
|
||
- Confirmed that **dealer portal access is revoked after resignation or termination**.
|
||
|
||
**1.1.9 Terminology & Documentation Corrections**
|
||
|
||
- Clarified **KT Matrix as Kepner Tregoe Matrix** for consistency and correctness.
|
||
|
||
**1.1.10 Super Admin Role Introduction**
|
||
|
||
- Introduced a **Super Admin (Master Role)** with end-to-end access and workflow control
|
||
across modules.
|
||
- Defined segregation of duties by splitting Super Admin into **two DD Admin roles** with
|
||
clearly scoped responsibilities.
|
||
|
||
|
||
### 1.2 Change Log – Dealer Self-Service Enablement
|
||
|
||
**Version:** v2.
|
||
**Section Impacted:** Section 12 – Dealer Portal (12.1 onwards)
|
||
**Module:** Dealer Onboarding & Offboarding System
|
||
**Change Type:** Dealer Feature Enablement (Section 12 onwards)
|
||
**Scope Enhancement :** Dealer Role and Access control
|
||
**Change demarcation** : Highlighted in Yellow
|
||
**Changes suggested by** : Ashok & Tariq
|
||
**Changed performed by** : Rohit Mandiwal
|
||
**Changes done on** : 5 - Jan- 2026
|
||
|
||
**1.2.1 Introduction of Dealer Portal**
|
||
|
||
- Introduced a **Dealer Portal capability** enabling onboarded dealers to initiate and track
|
||
post-onboarding lifecycle requests through the portal.
|
||
- Dealer actions are governed by **role-based access controls** , approval hierarchies, and
|
||
audit mechanisms.
|
||
|
||
**1.2.2 Dealer Resignation Enablement**
|
||
|
||
- Enabled **dealer-initiated resignation requests** at outlet level via the portal.
|
||
- Added structured resignation submission with:
|
||
o Last Operational Date (Sales & Services)
|
||
o Reason for resignation
|
||
o Mandatory document readiness guidance
|
||
- Enabled **dealer withdrawal option** for resignation requests **only until the case is**
|
||
**pending with NBH**.
|
||
- Clarified that **Legal team issues the Resignation Acceptance Letter** post approvals.
|
||
- Ensured **F&F settlement is triggered based on Last Working Day (LWD)** and not
|
||
approval date.
|
||
- Restricted dealer portal access **post resignation closure**.
|
||
|
||
**1.2.3 Dealer Relocation Request Enablement**
|
||
|
||
- Enabled dealers to **initiate and track relocation requests** through a guided workflow.
|
||
- Added support for:
|
||
o Manual or map-based location entry
|
||
o Distance calculation from existing location
|
||
o Property type selection and expected relocation date
|
||
|
||
|
||
- Introduced **document-driven relocation validation** , including statutory, legal, property,
|
||
and infrastructure documents.
|
||
- Implemented **multi-level approval workflow** with Work Notes–based communication
|
||
and audit trail.
|
||
- Ensured dealer has **view and upload access only** , with approvals retained by RE
|
||
stakeholders.
|
||
|
||
**1.2.4 Dealer Constitutional Change Enablement**
|
||
|
||
- Enabled dealers to **initiate constitutional change requests** post onboarding.
|
||
- Supported all approved constitution change scenarios:
|
||
o Proprietorship, Partnership, LLP, and Private Limited permutations
|
||
- Implemented **dynamic document requirement determination** based on target
|
||
constitution.
|
||
- Explicitly confirmed **no OCR-based document validation** ; all validations are manual and
|
||
role-driven.
|
||
- Ensured statutory compliance via Legal review before master data updates.
|
||
|
||
**1.2.5 Post-Exit Access Control**
|
||
|
||
- Enforced system rule to **revoke dealer portal access** once resignation or termination is
|
||
completed.
|
||
|
||
|
||
## 1 System Overview & Problem Statement
|
||
|
||
**1.1.1 System Overview**
|
||
|
||
The **Dealer Onboarding and Offboarding System** for **Royal Enfield (RE)** is designed to **digitize,
|
||
standardize, and streamline** the complete dealer lifecycle — from **application and
|
||
evaluation** to **approval, resignation, termination, and full-and-final (F&F) settlement**.
|
||
|
||
At present, the process operates through **manual coordination** , involving **emails, spreadsheets,
|
||
and physical documentation** , which makes it difficult to maintain visibility, accountability, and
|
||
consistency across teams.
|
||
|
||
The proposed solution introduces a **centralized digital platform** that brings all stakeholders onto
|
||
a single workflow. It ensures that every stage — **onboarding, operational approvals, financial
|
||
diligence, legal validation, and final closure** — follows a **structured and traceable process**.
|
||
|
||
The system integrates seamlessly with existing RE applications such as **SSO** , **SAP** , and **Finance
|
||
modules** , providing **role-based access** , **real-time tracking** , and **secure document management**.
|
||
It also offers **automated workflows** , **configurable approval hierarchies** , and **AI-assisted decision
|
||
support** to improve efficiency and reduce turnaround time.
|
||
|
||
By moving to a digital workflow, Royal Enfield will achieve higher levels of **process
|
||
efficiency** , **data accuracy** , and **transparency** , ensuring faster decision-making and stronger
|
||
control over the dealer network lifecycle.
|
||
|
||
## 2 Intended Audience
|
||
|
||
This document is intended for all stakeholders involved in the **design, implementation, approval,
|
||
and operational use** of the **Dealer Onboarding and Offboarding System** at **Royal Enfield (RE)**.
|
||
|
||
The following user personas and roles are part of the system:
|
||
|
||
### 2.1 Business & Functional Users
|
||
|
||
**2.1.1 Dealer Development (DD) Team**
|
||
|
||
- **Super Admin (Master Role):**
|
||
The **Super Admin has unrestricted access** across all modules and workflows, with
|
||
authority to **configure, override, and influence workflow behavior** at every level.
|
||
|
||
|
||
```
|
||
The Super Admin role is segregated into two DD Admin roles , each with clearly defined
|
||
scopes to ensure segregation of duties and governance control.
|
||
```
|
||
- **DD-Admin:** System administrator responsible for user setup, role mapping, hierarchy
|
||
configuration, and workflow management.
|
||
- **DD-AM (Area Manager):** Reviews and manages applications within assigned regions;
|
||
performs preliminary screening.
|
||
- **DD-ZM (Zonal Manager):** Conducts the first level of dealer evaluation along with RBM;
|
||
prepares presentation decks for final interviews.
|
||
- **DD-Lead:** Reviews zonal evaluations, validates recommendations, and forwards
|
||
shortlisted applicants for senior-level approval.
|
||
- **DD-Head: DD Head** is engaged in the **final review and approval** of shortlisted dealer
|
||
applications before the **NBH interview** , and later **oversees final verification and LOI**
|
||
**issuance** after all evaluations are complete.
|
||
|
||
**2.1.2 Regional Sales & Business Team**
|
||
|
||
- **RBM (Regional Business Manager):** Participates in early-stage evaluations, provides
|
||
ground-level business insights, and recommends suitable candidates.
|
||
- **ZBH (Zonal Business Head):** Conducts the second-level review along with DD-Lead;
|
||
provides strategic feedback on market and location viability.
|
||
- **NBH (National Business Head):** Holds final authority for approval or rejection of dealer
|
||
onboarding; reviews consolidated feedback from all levels.
|
||
|
||
**2.1.3 Supporting Departments**
|
||
|
||
- **Finance Team:** Reviews financial due diligence reports, validates F&F (Full and Final)
|
||
settlements, and manages monetary closure during offboarding.
|
||
- **Legal Team:** Reviews agreements, issues **Letters of Intent (LOI)** or **Termination Letters** ,
|
||
and ensures all documentation aligns with company policy.
|
||
- **Brand Experience / Architecture Team:** Manages **EOR (Essential Operating**
|
||
**Requirements)** and ensures adherence to brand and infrastructure standards.
|
||
|
||
**2.1.4 Dealers**
|
||
|
||
Once a dealer is **successfully onboarded and activated in the system** , the Dealer role is enabled
|
||
with controlled, role-based access to initiate and track select lifecycle requests. This
|
||
enhancement introduces **structured self-service capabilities for dealers** , while ensuring all
|
||
actions remain governed by defined validations, internal reviews, and approval workflows as per
|
||
RE standards.
|
||
|
||
The Dealer role is enabled to perform the following activities:
|
||
|
||
|
||
- **Resignation Initiation**
|
||
|
||
```
|
||
The dealer can initiate the resignation process directly through the portal , submit the
|
||
reason for exit, and track the status of the request across the defined review, clearance,
|
||
and closure stages.
|
||
```
|
||
- **Relocation Request Submission**
|
||
|
||
```
|
||
The dealer can submit a relocation request in scenarios where there is an intent to shift
|
||
the dealership from the current location to a new proposed location. The request is
|
||
routed for internal feasibility assessment, validation, and management approval before
|
||
execution.
|
||
```
|
||
- **Change in Constitution Request**
|
||
|
||
```
|
||
The dealer can initiate a Change in Constitution request to seek approval from RE
|
||
management for ownership or structural changes within the dealership. Upon approval,
|
||
the dealer may proceed with the legally compliant transition.
|
||
```
|
||
```
|
||
Supported Change in Constitution scenarios include:
|
||
```
|
||
```
|
||
o Proprietorship (Single Owner) → Partnership
|
||
o Proprietorship → LLP (Limited Liability Partnership)
|
||
o Proprietorship → Private Limited
|
||
o Partnership → LLP
|
||
o Partnership → Private Limited
|
||
o Private Limited → LLP
|
||
o Private Limited → Partnership
|
||
```
|
||
All dealer-initiated requests are subject to **defined validations, mandatory document
|
||
submissions, role-based reviews, and approvals**. The dealer’s access is **restricted to initiation,
|
||
document upload, and status visibility** , with **final decision-making authority retained by
|
||
authorized internal stakeholders of RE**
|
||
|
||
### 2.2 External & Integrated Stakeholders
|
||
|
||
**2.2.1 FDD (Financial Due Diligence Partner)**
|
||
|
||
External agency responsible for assessing the applicant’s financial health, verifying credentials,
|
||
and uploading due diligence reports into the system.
|
||
|
||
|
||
**2.2.2 Dealer / Applicant**
|
||
External user who applies for dealership, uploads required documents, participates in
|
||
interviews, and later accesses the portal for resignation or closure status.
|
||
|
||
## 3 Definitions and Acronyms
|
||
|
||
```
|
||
Acronym Full Form / Description
|
||
RE Royal Enfield
|
||
DD Dealer Development
|
||
DD-AM Dealer Development – Area Manager
|
||
DD-ZM Dealer Development – Zonal Manager
|
||
DD-Lead Dealer Development – Lead
|
||
DD-Head Dealer Development – Head
|
||
RBM Regional Business Manager
|
||
ZBH Zonal Business Head
|
||
NBH National Business Head
|
||
ASM Area Sales Manager
|
||
FDD Financial Due Diligence (External Partner/Agency)
|
||
LOI Letter of Intent
|
||
EOR Essential Operating Requirements
|
||
LOA Letter of Appointment
|
||
F&F Full and Final (Dealer Settlement)
|
||
KT Matrix Evaluation Matrix used for scoring applicants
|
||
```
|
||
## 4 HiFi Wireframes & Flow of Application
|
||
|
||
HiFi Wireframes : https://mono-human-93592950.figma.site
|
||
|
||
### 4.1 Dealer onboarding - Process Flow Overview
|
||
|
||
The **Dealer Onboarding Workflow** outlines the end-to-end sequence through which a dealership
|
||
application progresses — from initial registration to final inauguration and operational readiness.
|
||
|
||
|
||
**4.1.1 Step-by-Step Process Flow**
|
||
|
||
```
|
||
4.1.1.1 Application Initiation
|
||
```
|
||
- The **applicant (dealer prospect)** submits an online application through the Dealer
|
||
Onboarding Portal.
|
||
- The system checks the **location’s availability** in the Royal Enfield dealership network:
|
||
o If the location has **no open opportunity** , a **Non-Opportunity Email** is triggered
|
||
automatically.
|
||
o If an opportunity exists, the applicant receives an **Opportunity Email** with login
|
||
credentials and a link to the **Dealer Questionnaire**.
|
||
|
||
```
|
||
4.1.1.2 Questionnaire Completion
|
||
```
|
||
- The applicant fills out the **comprehensive questionnaire** covering business, infrastructure,
|
||
and financial readiness.
|
||
- The system auto-scores responses, generating a **Questionnaire Score** and **initial**
|
||
**ranking** for that applicant.
|
||
|
||
|
||
- Completed applications move to the **Admin review bucket**.
|
||
- The system shall trigger automated reminders to users for completing the
|
||
questionnaire. These **reminders will be sent through WhatsApp** , to ensure timely
|
||
submission. Reminder needs to be configured from Admin.
|
||
|
||
```
|
||
4.1.1.3 Admin Validation & Shortlisting
|
||
```
|
||
- **DD-Admin** reviews all submitted applications and validates details and attached
|
||
documents.
|
||
- Based on eligibility, applications are either **shortlisted** for evaluation or **archived** for
|
||
future opportunities.
|
||
- Shortlisted applications are distributed to respective **zones or regions** for further
|
||
assessment.
|
||
|
||
```
|
||
4.1.1.4 Interview Evaluation (Multi-Level Process)
|
||
```
|
||
- Admin schedules interviews in **Level 1** , **Level 2** , and **Level 3** , as applicable.
|
||
- Each interview can be **Virtual or Physical** , with calendar invites sent via Google Calendar.
|
||
- Evaluators at each level (DD-ZM, RBM, DD-Lead, ZBH, NBH, DD-Head) record their
|
||
feedback through:
|
||
o **KT Matrix Scoring** (quantitative)
|
||
o **Interview Feedback Form** (qualitative)
|
||
- The system consolidates panel feedback and generates an **AI-driven summary and**
|
||
**ranking** for decision support.
|
||
|
||
```
|
||
4.1.1.5 Financial Due Diligence (FDD) & Finance Review
|
||
```
|
||
- Upon shortlisting, the application is assigned to the **FDD Team (external agency)** for
|
||
financial validation.
|
||
- FDD users, using SSO credentials, can:
|
||
o View assigned applications in a restricted interface.
|
||
o Upload FDD reports and add remarks in the **Work Notes** section.
|
||
o Flag cases of **non-responsiveness** or incomplete data, returning them to Admin.
|
||
- The **Finance team** reviews submitted FDD reports, validates findings, and decides
|
||
whether the application proceeds to **LOI approval**. The finance team is not the decision
|
||
maker for LOI Issuance.
|
||
|
||
```
|
||
4.1.1.6 LOI (Letter of Intent) Approval & Issuance
|
||
```
|
||
- Based on Finance clearance, **DD-Head and NBH** review and approve the **LOI request**.
|
||
- The system tracks document approvals, timestamps, and supporting artefacts.
|
||
|
||
|
||
- Once approved, the LOI document is generated, uploaded, and shared **with the**
|
||
**applicant via official email communication** and not on WhatsApp
|
||
- Notification emails are triggered to all relevant stakeholders.
|
||
|
||
```
|
||
4.1.1.7 Dealer Code Generation & Setup
|
||
```
|
||
- After LOI issuance, the **DD-Admin triggers** the Dealer Code creation process. Based on
|
||
this trigger, the **Dealer Code is created in the SAP Master** and **mapped to the applicant**
|
||
within the system.
|
||
- The code links all downstream modules, including Architectural, Statutory, and EOR
|
||
checklists.
|
||
|
||
```
|
||
4.1.1.8 Architectural Work & Statutory Documentation
|
||
```
|
||
- Architectural activities are initiated (site plans, layout approvals, branding elements).
|
||
- The applicant and assigned Architecture Team upload documents, drawings, and
|
||
blueprints.
|
||
- In parallel, the applicant uploads **Statutory Documents** such as:
|
||
o GST certificate, PAN, Partnership Deed, Firm Registration, Rental/Lease
|
||
Agreement, etc.
|
||
- Each upload is timestamped and visible with file name, uploader, and document type.
|
||
|
||
```
|
||
4.1.1.9 Payment Verification & Finance Validation
|
||
```
|
||
- Applicant uploads proof of advance payment or security deposit.
|
||
- The **Finance team** verifies payment details (transaction ID, amount, and bank record).
|
||
- Status is updated to **Verified** once the payment is reconciled.
|
||
- Verified payment triggers readiness for final operational setup.
|
||
|
||
```
|
||
4.1.1.10 Essential Operating Requirements (EOR) Checklist
|
||
```
|
||
- All functional teams (Sales, Service, IT, Finance, Training, Architecture) verify their
|
||
respective readiness parameters.
|
||
- Progress is tracked through a **completion bar** until 100% EOR compliance is achieved.
|
||
- The **EOR checklist is initiated only after LOA issuance**. All functional teams verify their
|
||
respective readiness parameters, and progress is tracked until **100% EOR compliance** is
|
||
achieved.
|
||
|
||
```
|
||
4.1.1.11 LOA (Letter of Authorization) & Final Go-Live
|
||
```
|
||
- After LOI issuance and Dealer Code generation, the **Letter of Authorization (LOA) is**
|
||
**generated and approved by NBH and DD-Head**. Upon successful LOA issuance, the
|
||
|
||
|
||
```
|
||
application proceeds to the Essential Operating Requirements (EOR) checklist for final
|
||
readiness verification.
|
||
```
|
||
- Final verification includes:
|
||
|
||
```
|
||
o EOR document review
|
||
o Brand readiness assessment
|
||
o Site validation and inspection
|
||
```
|
||
- The **LOA** officially authorizes the dealership to operate under Royal Enfield.
|
||
|
||
```
|
||
4.1.1.12 Inauguration & Closure
|
||
```
|
||
- Post-authorization, the **Inauguration** event is scheduled and logged.
|
||
- Completion of inauguration marks the dealership as **Active** in the system.
|
||
|
||
```
|
||
4.1.1.13 System-Driven Governance & Audit
|
||
```
|
||
- Each stage automatically logs:
|
||
o User action, timestamp, and remarks
|
||
o Uploaded artefacts and version control
|
||
o Notifications sent and approvals received
|
||
- The entire lifecycle remains accessible under **Audit Trail** for future reference, compliance,
|
||
or offboarding workflows.
|
||
|
||
### 4.2 Dealer Resignation – Process Flow Overview
|
||
|
||
**4.2.1.1 Overview**
|
||
|
||
```
|
||
The Dealer Resignation Process manages the structured offboarding of a dealership initiated
|
||
by the dealer. The process begins when a dealer formally submits their resignation via
|
||
email to the Area Sales Manager (ASM) , after which the workflow transitions into the
|
||
system-managed approval sequence.
|
||
```
|
||
```
|
||
Dealer resignation requests are initiated by the dealer through the portal and subsequently
|
||
reviewed and processed by Admin, Finance, Legal, and relevant business stakeholders.
|
||
```
|
||
```
|
||
This flow ensures that each resignation is verified, discussed, and approved across all
|
||
required levels — maintaining proper documentation, compliance, and traceability until the
|
||
final Legal Acceptance Letter is issued.
|
||
```
|
||
|
||
**4.2.2 Step-by-Step Process Flow**
|
||
|
||
```
|
||
4.2.2.1 Dealer Initiation
|
||
```
|
||
- The dealer submits a **formal resignation email** on the dealership’s official letterhead to
|
||
the **ASM**.
|
||
- The resignation reason must be clearly stated (e.g., personal, financial, business
|
||
restructuring).
|
||
- The **dealer is provided portal access** to initiate the resignation request directly through
|
||
the system. The dealer submits resignation details, reason for exit, and proposed
|
||
timeline via the portal, after which the request enters the internal review and clearance
|
||
workflow.
|
||
|
||
```
|
||
4.2.2.2 ASM Review
|
||
```
|
||
- The **ASM** reviews the dealer’s resignation request and supporting letter.
|
||
- Uploads the **resignation email** and **dealer’s letterhead document** onto the portal.
|
||
- Adds remarks summarizing the discussion and reason for resignation.
|
||
- Forwards the request to **RBM + DD-ZM** for evaluation.
|
||
|
||
```
|
||
4.2.2.3 RBM + DD-ZM Joint Evaluation
|
||
```
|
||
- The **Regional Business Manager (RBM)** and **Dealer Development Zonal Manager (DD-**
|
||
**ZM)** review the uploaded documents.
|
||
- Conduct a joint discussion with the dealer to confirm the intent and understand any
|
||
issues.
|
||
- Uploads the **Minutes of Meeting (MOM)** or discussion summary.
|
||
- Adds comments and recommendations before forwarding to **Zonal Business Head**
|
||
**(ZBH)**.
|
||
- Actions available at this stage:
|
||
o **Approve** → Send forward for next-level review
|
||
o **Send Back for Clarification** → Returns to ASM
|
||
o **Withdraw** → Cancels the request (with remarks logged)
|
||
|
||
```
|
||
4.2.2.4 ZBH Review
|
||
```
|
||
- The **Zonal Business Head (ZBH)** reviews the resignation summary and all remarks.
|
||
- Adds their comments and recommendations.
|
||
- Forwards the request to **DD-Lead** through the system.
|
||
- Worknote is updated automatically to reflect action and timestamp.
|
||
- The resignation request is reviewed by authorized business stakeholders,
|
||
including **RBM, ZBH, and DD-Head**. During the review stage, the **ZBH is authorized to**
|
||
|
||
|
||
```
|
||
Send Back or Revoke the resignation request for clarification or correction. Send Back
|
||
actions are communicated to the dealer and internal teams through Work Notes , with
|
||
mandatory remarks captured for traceability.
|
||
```
|
||
```
|
||
4.2.2.5 DD-Lead Review
|
||
```
|
||
- The **DD-Lead** consolidates all discussions, documents, and feedback.
|
||
- Prepares a **Resignation Presentation** with recommendations and supporting data.
|
||
- Uploads the presentation to the portal.
|
||
- Forwards the case to **NBH** for final decision.
|
||
- The resignation request is reviewed by the **DD-Lead and DD-Head**. At this stage, both
|
||
roles are authorized to **Send Back or Revoke** the resignation request for clarification,
|
||
correction, or reconsideration. **Send Back actions are communicated through Work**
|
||
**Notes** , with **mandatory remarks** recorded for audit and traceability.
|
||
|
||
```
|
||
4.2.2.6 NBH Final Approval
|
||
```
|
||
- The **National Business Head (NBH)** reviews the entire resignation dossier.
|
||
- Adds final remarks with one of the following outcomes:
|
||
o **Approve** → Case moves automatically to Legal for letter issuance.
|
||
o **Send Back for Clarification** → Returns to DD-Lead or ZBH for revalidation.
|
||
o **Hold** → Temporarily pauses the process pending further discussion.
|
||
- Upon approval, the system triggers a **Worknote Notification** to DD-Lead, RBM, ZBH, and
|
||
Finance teams.
|
||
- The resignation request is reviewed by the **NBH** , who may **Approve, Send Back, or**
|
||
**Revoke** the request based on business considerations. Any **Send Back or Revoke action**
|
||
**must be accompanied by remarks recorded in Work Notes** , ensuring transparent
|
||
communication and governance.
|
||
|
||
```
|
||
4.2.2.7 Legal Acceptance Letter
|
||
```
|
||
- Once approved by **NBH** , the request is **auto-assigned to the Legal team**.
|
||
- Legal verifies the uploaded resignation and issues a **Resignation Acceptance Letter**.
|
||
- The letter is uploaded to the portal, visible to all relevant personas including **DD-**
|
||
**Admin** and **DD-AM**.
|
||
- Legal can also raise clarifications through worknotes if required.
|
||
- Upon completion of all approvals, the **Legal team issues the official Resignation**
|
||
**Acceptance Letter** and shares it with the dealer through authorized communication
|
||
channels.
|
||
|
||
|
||
```
|
||
4.2.2.8 DD-Admin Closure
|
||
```
|
||
- The **DD-Admin** downloads and shares the final **Resignation Acceptance Letter** with the
|
||
dealer.
|
||
- Marks the resignation as completed and triggers the **F&F (Full and Final) process** by
|
||
forwarding the case to the Finance team.
|
||
- The **Full & Final (F&F) settlement process is initiated only on the Last Working Day**
|
||
**(LWD) of the dealership**. The system shall **enable and trigger the F&F workflow strictly**
|
||
**based on the LWD date** , and **not based on the resignation approval date**.
|
||
|
||
### 4.3 Dealer Termination – Process Flow Overview
|
||
|
||
```
|
||
4.3.1.1 Overview
|
||
```
|
||
```
|
||
The Dealer Termination Process governs the structured offboarding of a dealership initiated
|
||
internally by Royal Enfield due to operational, contractual, or ethical concerns.
|
||
It ensures that any termination—whether due to working-capital issues, poor performance,
|
||
or unethical practices —is investigated, documented, reviewed at multiple managerial levels,
|
||
and legally validated before final execution. The process maintains full transparency and
|
||
traceability through digital records, comments, and worknotes until the Termination
|
||
Letter is issued and the Full & Final (F&F) settlement begins.
|
||
```
|
||
**4.3.2 Step-by-Step Process Flow**
|
||
|
||
```
|
||
4.3.2.1 ASM – Case Initiation
|
||
```
|
||
- The **Area Sales Manager (ASM)** regularly visits dealers and records **Minutes of Meeting**
|
||
**(MOM)** for performance or compliance concerns.
|
||
- After two consecutive unsatisfactory commitments or escalations, the ASM initiates
|
||
a **Termination Request** in the portal.
|
||
- Fills all operational details (Dealer Code, LOI, LOA, Sales Data, etc.), selects
|
||
a **Termination Category** (Working Capital, Performance, Unethical Practice), and
|
||
uploads supporting documents (MOMs, commitments, dealer letters).
|
||
- Submits the case to **RBM + DD-ZM** for review.
|
||
|
||
```
|
||
4.3.2.2 RBM + DD-ZM Review
|
||
```
|
||
- The **Regional Business Manager (RBM)** and **Dealer Development Zonal Manager (DD-**
|
||
**ZM)** jointly evaluate the case.
|
||
|
||
|
||
- Conduct a meeting with the dealer and record fresh MOMs; upload dealer
|
||
commitments on letterhead.
|
||
- Provide remarks and supporting evidence.
|
||
- Actions available:
|
||
o **Approve** → Forward to ZBH
|
||
o **Send Back for Clarification** → Returns to ASM with comments
|
||
o **Withdraw** → Terminates workflow with justification
|
||
|
||
```
|
||
4.3.2.3 ZBH Review
|
||
```
|
||
- The **Zonal Business Head (ZBH)** reviews the full chronology (ASM visits, RBM/DD-ZM
|
||
remarks, uploaded MOMs).
|
||
- Validates escalation authenticity and dealer communication record.
|
||
- Adds remarks and forwards to **DD-Lead** for deeper review.
|
||
- The termination request is reviewed by the **ZBH** , who is authorized to **Approve, Send**
|
||
**Back, or Revoke** the termination request. **Send Back actions are communicated**
|
||
**through Work Notes** , with **mandatory remarks** recorded for traceability.
|
||
|
||
```
|
||
4.3.2.4 DD-Lead Review & Legal Assignment
|
||
```
|
||
- The **DD-Lead** cross-verifies case chronology with all stakeholders (ASM, RBM, ZBH).
|
||
- Prepares a **Termination Presentation** summarizing facts, dealer history, and
|
||
recommendations.
|
||
- Assigns the case to **Legal Team** for inputs through the system (visible in worknotes).
|
||
- The termination request is reviewed by the **DD-Lead** , who is authorized to **Send Back or**
|
||
**Revoke** the termination request for clarification or reconsideration. All such actions
|
||
require **mandatory remarks captured in Work Notes**.
|
||
|
||
```
|
||
4.3.2.5 Legal Verification
|
||
```
|
||
- The **Legal Team** reviews documentation, ensures contractual breaches are well-
|
||
supported, and checks all precedents.
|
||
- May raise queries via **Worknotes** or **Send Back** the case to DD-Lead for clarification.
|
||
- Once satisfied, forwards the verified case back to **DD-Lead** for next action.
|
||
|
||
```
|
||
4.3.2.6 DD-Lead → DD-Head Review
|
||
```
|
||
- The **DD-Lead** attaches Legal’s feedback and forwards the case to **DD-Head** for strategic
|
||
review.
|
||
- **DD-Head** validates the case, evaluates impact, and presents it to **National Business**
|
||
**Head (NBH)** for final business decision.
|
||
|
||
|
||
```
|
||
4.3.2.7 NBH Evaluation
|
||
```
|
||
- The **NBH** reviews all documentation and Legal remarks.
|
||
- May choose one of three actions:
|
||
o **Go Ahead** → Approve for issuance of **Show Cause Notice (SCN)**
|
||
o **Hold Decision** → Pause temporarily for further monitoring or negotiation
|
||
o **Raise Query** → Sends back to DD-Lead for additional input
|
||
|
||
```
|
||
4.3.2.8 Show Cause Notice (SCN) Issuance
|
||
```
|
||
- Upon NBH approval, the system triggers Legal to prepare and issue the **SCN**.
|
||
- The **DD-Lead** formally shares the SCN with the dealer through **DD-Admin**.
|
||
- Dealer replies to the SCN by email or letter, which **DD-Admin uploads** to the portal.
|
||
- For termination cases, the **F&F settlement process is triggered only on the Last**
|
||
**Working Day (LWD)**. The system shall **control the F&F trigger based on the LWD date** ,
|
||
irrespective of the termination approval date.
|
||
|
||
```
|
||
4.3.2.9 Evaluation of Dealer Response
|
||
```
|
||
- The **DD-Lead** , **ZBH** , **RBM** , and **DD-Head** jointly review the dealer’s SCN response.
|
||
- Uploads internal comments, Legal feedback, and recommendation for NBH’s final
|
||
decision.
|
||
|
||
```
|
||
4.3.2.10 NBH Final Decision
|
||
```
|
||
- The **NBH** reviews the compiled case with Legal advice and decides among:
|
||
o **Approve Termination** → Moves to CEO/CCO for confirmation
|
||
o **Reconsider** → Allow additional time or corrective action
|
||
o **Reject** → Case closed without termination
|
||
|
||
```
|
||
4.3.2.11 11. CEO & CCO Authorization
|
||
```
|
||
- **CEO** and **Chief Commercial Officer (CCO)** review the NBH-approved termination.
|
||
- Provide authorization on the portal.
|
||
- Once signed off, the decision becomes final.
|
||
|
||
```
|
||
4.3.2.12 12. Legal Termination Letter
|
||
```
|
||
- The **Legal Team** generates the **Termination Letter** to the portal.
|
||
- The letter is auto-visible to **DD-Lead** , **DD-Admin** , and **Finance**.
|
||
- A system notification is triggered to all linked personas.
|
||
|
||
|
||
```
|
||
4.3.2.13 13. DD-Admin Communication & F&F Trigger
|
||
```
|
||
- The **DD-Admin** shares the official **Termination Letter** with the dealer and field team.
|
||
- Marks the case as “Terminated” in the portal.
|
||
- Forwards the case to **Finance** for **Full & Final Settlement** initiation.
|
||
- Updates the worknote with final remarks and due-date for settlement.
|
||
|
||
### 4.4 Dealer Full & Final (F&F) Settlement – Process Flow
|
||
|
||
```
|
||
4.4.1.1 Overview
|
||
```
|
||
The **Full & Final (F&F) Settlement Process** governs the financial closure of a dealership
|
||
following **Resignation** or **Termination**.
|
||
It ensures that all financial obligations between Royal Enfield and the dealer —
|
||
including **security deposits, recoveries, payables, and department-wise dues** — are
|
||
transparently reconciled, verified, and documented before closure.
|
||
|
||
**4.4.2 Step-by-Step Process Flow**
|
||
|
||
```
|
||
4.4.2.1 F&F Initiation
|
||
```
|
||
- Triggered automatically once the **Resignation Acceptance Letter** or **Termination**
|
||
**Letter** is uploaded by **Legal**.
|
||
- The **DD-Admin** or **DD-Lead** initiates the F&F case in the **Finance Dashboard** , which
|
||
creates a unique **FNF Case ID** linked to the dealer code.
|
||
- The system auto-fetches dealer details, associated documents, resignation/termination
|
||
date, and due dates.
|
||
- Notification is sent to the **Finance Team** and all functional departments to begin the
|
||
clearance process.
|
||
|
||
```
|
||
4.4.2.2 Department-wise Response Collection
|
||
```
|
||
- The system automatically prompts all mapped **functional departments (16 in total)** to
|
||
submit their clearance inputs — including NOC, payables, recoveries, and remarks.
|
||
- Each department updates:
|
||
o Financial dues (if any)
|
||
o Clearance confirmation (NOC)
|
||
o Supporting document uploads (e.g., debit note, invoice copy)
|
||
- The system dynamically updates progress (e.g., _12/16 Departments Responded_ ) with
|
||
color-coded indicators:
|
||
o 🟢 **No Dues** – Cleared
|
||
|
||
|
||
```
|
||
o 🔴 Dues Pending – Outstanding financial liability
|
||
o ⚪ Pending – Awaiting department input
|
||
```
|
||
- SLA-based reminders are auto-triggered for pending responses nearing the deadline.
|
||
|
||
```
|
||
4.4.2.3 Finance Summary Consolidation
|
||
```
|
||
- Once all departments respond, the **DD-Admin Team** consolidates inputs into the **Final**
|
||
**F&F Summary Sheet** , which consists of:
|
||
o **Payables to Dealer** (e.g., refundable deposits, reimbursements)
|
||
o **Receivables from Dealer** (e.g., outstanding invoices, recoveries)
|
||
o **Deductions** (policy penalties, non-compliance adjustments)
|
||
- At this stage, **department-claimed amounts are frozen** and become read-only for
|
||
departments.
|
||
- Finance does **not overwrite department claim values**. Instead, Finance validates each row
|
||
in a dedicated validation layer by recording:
|
||
- Finance decision (Accepted / Partially Accepted / Rejected / Under Clarification)
|
||
- Finance-validated amount
|
||
- Variance amount and mandatory variance reason (if changed)
|
||
- Supporting proof/document
|
||
- The system automatically calculates:
|
||
- Net Settlement = Total Payables – Total Receivables – Total Deductions
|
||
- Final totals are computed from **finance-validated values only**.
|
||
- Status updates to _Finance Summary Prepared_ once complete.
|
||
|
||
```
|
||
4.4.2.4 Internal Review & Clarification
|
||
```
|
||
- The **Finance Team** may use the **Work Note** section to raise clarifications to **DD-**
|
||
**Lead** , **Legal** , or concerned departments.
|
||
- If discrepancies exist (e.g., mismatched values or missing NOCs), the case remains _Under_
|
||
_Clarification_ until resolved.
|
||
- Once validated, Finance locks the summary for further edits.
|
||
|
||
```
|
||
4.4.2.5 Dealer Discussion & Acknowledgment
|
||
```
|
||
- The **Finance Team** , along with **Legal** and **DD-Lead** , discusses the settlement summary
|
||
with the dealer.
|
||
- Dealer acknowledgment is captured either via written confirmation or attached email
|
||
communication.
|
||
- The case then proceeds for **Final Finance Approval**.
|
||
|
||
```
|
||
4.4.2.6 Final Finance Approval & Payment Processing
|
||
```
|
||
- The **Finance Team** reviews the approved summary and enters payment or recovery
|
||
details:
|
||
o **Transaction Type:** RTGS / NEFT / Cheque
|
||
o **Transaction ID & Date**
|
||
o **Bank Name & Account Details** (auto-fetched from dealer profile)
|
||
o **Settlement Remarks**
|
||
- Finance takes one of three actions:
|
||
|
||
|
||
```
|
||
o Approve Settlement → Marks the case as “Finance Approved.”
|
||
o Request Clarification → Sends query to DD-Lead or Admin.
|
||
o Reject Summary → Returns for re-verification.
|
||
```
|
||
- Upon approval, notifications are sent to DD-Admin and Legal for record update.
|
||
|
||
```
|
||
4.4.2.7 F&F Completion & Closure
|
||
```
|
||
- Once approved, the case is automatically marked **Completed** , and the **Finance**
|
||
**Dashboard** updates status as _F&F Closed_.
|
||
- The **Settlement Proof** (e.g., payment confirmation or recovery adjustment) is uploaded
|
||
by Finance.
|
||
- The **DD-Admin** communicates official closure to the dealer and archives all artefacts.
|
||
- System triggers final alerts to DD-Lead, NBH, and Legal confirming completion.
|
||
- The case is archived in the **Audit Trail** for future reference.
|
||
|
||
### 4.5 Finance Team – Process Flow
|
||
|
||
```
|
||
4.5.1.1 Overview
|
||
```
|
||
The **Finance Team Process Flow** governs all financial activities related to dealer lifecycle
|
||
management — from **security deposit validation at onboarding** to **final settlement at
|
||
resignation or termination**.
|
||
It ensures complete financial traceability, proper verification of payments, and compliance with
|
||
Royal Enfield’s financial governance standards.
|
||
The process flow integrates with **Admin, Legal, Dealer Development (DD)** , and **Departmental
|
||
Modules** , ensuring accurate financial updates and timely closure of all financial transactions.
|
||
|
||
**4.5.2 Step-by-Step Process Flow**
|
||
|
||
```
|
||
4.5.2.1 Security Deposit Validation (Onboarding Stage)
|
||
```
|
||
- **Trigger:**
|
||
Initiated when a new dealer’s onboarding application reaches the Finance stage after
|
||
DD approval.
|
||
- **Action:**
|
||
The **Finance Team** verifies the **Security Deposit** payment made by the dealer
|
||
via **RTGS/NEFT** or other approved channels.
|
||
- **Outcome:**
|
||
o Verified deposits are marked as _Approved_ , triggering system notifications to DD-
|
||
Admin and DD-Lead.
|
||
|
||
|
||
```
|
||
o The verified payment data is stored permanently in the dealer’s financial profile
|
||
for audit and reference.
|
||
```
|
||
```
|
||
4.5.2.2 Financial Summary Preparation
|
||
```
|
||
- **Action:**
|
||
Once departmental inputs are received, Finance consolidates all data into the **F&F**
|
||
**Summary Sheet**.
|
||
- **System Steps:**
|
||
o Segregates entries under:
|
||
▪ **Payables to Dealer** (e.g., refundable deposits, reimbursements)
|
||
▪ **Receivables from Dealer** (e.g., outstanding payments, penalties)
|
||
▪ **Deductions** (e.g., policy recoveries, warranty holdbacks)
|
||
o The system auto-calculates:
|
||
o Net Settlement = Total Payables – Total Receivables – Deductions
|
||
o Finance validates each record, uploads supporting documents (receipts, invoices,
|
||
credit notes), and adds remarks.
|
||
- **Outcome:**
|
||
The computed **Net Settlement Amount** is reflected in the dashboard, categorized
|
||
as _Payable to Dealer_ or _Recoverable from Dealer_.
|
||
|
||
```
|
||
4.5.2.3 Internal Clarification & Approval
|
||
```
|
||
- **Action:**
|
||
Finance initiates clarification rounds with departments or DD-Lead for mismatched data.
|
||
- **System Steps:**
|
||
o Uses the **Work Notes** section for comments, tagging users like _@DD-_
|
||
_Lead_ , _@Legal_ , or _@Admin_.
|
||
o Tracks status as _Pending Clarification_ until resolved.
|
||
o After reconciliation, Finance locks the summary and updates case status
|
||
to _Ready for Approval_.
|
||
|
||
```
|
||
4.5.2.4 Final Review & Dealer Confirmation
|
||
```
|
||
- **Action:**
|
||
Finance conducts an internal review of the consolidated settlement and initiates a
|
||
financial discussion with the dealer.
|
||
- **System Steps:**
|
||
o Reviews summary details on-screen with Legal and DD-Lead.
|
||
o Records dealer’s acknowledgment via Work Note or attached email
|
||
confirmation.
|
||
o Once confirmed, proceeds to payment verification.
|
||
|
||
|
||
```
|
||
4.5.2.5 Payment Processing & Record Update
|
||
```
|
||
- **Action:**
|
||
Finance executes the financial transaction (payment to or recovery from dealer).
|
||
- **System Steps:**
|
||
o Enters **Mode of Payment** , **Transaction Reference Number** , **Date** , and **Remarks**.
|
||
o Uploads proof of payment (RTGS confirmation or bank statement).
|
||
o Marks case as _Finance Approved_ and sends completion notification to DD-Admin
|
||
and Legal.
|
||
o System automatically updates the **Progress Timeline** and **Audit Trail**.
|
||
|
||
```
|
||
4.5.2.6 F&F Completion & Closure
|
||
```
|
||
- **Action:**
|
||
Finance reviews all entries, confirms ledger reconciliations, and marks case
|
||
as **Completed**.
|
||
- **System Steps:**
|
||
o Locks financial data and supporting artefacts.
|
||
o Status changes to _Closed – F&F Completed_.
|
||
o Final confirmation sent to all stakeholders — DD-Lead, NBH, DD-Head, Legal, and
|
||
DD-Admin.
|
||
o Finance Dashboard updates counters under “Completed Cases.”
|
||
|
||
## 5 System Features & Requirements
|
||
|
||
Here, we describe the **system features** along with their respective **Width** and **Depth** to provide
|
||
complete visibility of each requirement.
|
||
|
||
The **Width** defines the **functional coverage** of a feature — outlining what the feature does,
|
||
its **boundaries, use cases, and user interactions**. It answers the question: _“What scenarios and
|
||
actions are covered by this feature?”_
|
||
|
||
The **Depth** captures the **operational and behavioral details** — describing how the feature
|
||
behaves through its **logic, workflow, system responses, and edge-case handling**. It answers the
|
||
question: _“How does the system execute and respond in these scenarios?”_
|
||
|
||
---
|
||
|
||
## 8 Termination
|
||
|
||
A **Dealer Termination** process is initiated when a dealership’s continuation is deemed
|
||
non-viable due to business, financial, or ethical reasons. The termination may arise
|
||
|
||
from three primary causes — **working capital inadequacy** , **continued underperformance** ,
|
||
or **unethical practices**. Cases involving working capital or performance issues follow a
|
||
|
||
structured review and approval process, allowing the concerned dealer to provide
|
||
clarification and supporting data before final decision. However, any instance
|
||
|
||
of **unethical practice** — including fraud, policy breach, or reputational risk to the brand
|
||
— results in **immediate termination**. All termination cases are documented within the
|
||
|
||
|
||
system, with remarks, evidence, and approval trails maintained for audit and
|
||
compliance verification.
|
||
|
||
### 8.1 Create Termination Request
|
||
|
||
**8.1.1 Functionality Scope**
|
||
|
||
The **Create Termination Request** form enables authorized users such as **DD-Lead** , **DD-Admin** ,
|
||
or **ASM** to initiate a termination case within the system. The form captures comprehensive
|
||
dealership details including operational timelines, format type, constitution, performance data,
|
||
and financial indicators. It also specifies the **Termination Category** (e.g., Working Capital,
|
||
Performance Issue, or Unethical Practice), supported by descriptive justification and relevant
|
||
documentation. The request forms the starting point of the digital termination workflow and
|
||
ensures that all necessary contextual data and artefacts are available for subsequent reviews and
|
||
escalations.
|
||
|
||
**8.1.2 Width**
|
||
|
||
- Allows creation of new termination requests by entering **Dealer Code** , operational details, and
|
||
financial data.
|
||
- Captures **Termination Category** and **Description** for clarity on grounds of termination.
|
||
|
||
|
||
- Supports upload of supporting artefacts such as MOMs, dealer commitments, or financial
|
||
statements.
|
||
- Automatically records creator and timestamp for traceability.
|
||
|
||
**8.1.3 Depth**
|
||
|
||
- Integrates directly with the **Progress Timeline** , displaying real-time status updates across levels.
|
||
- Each submission auto-generates an internal case ID linked to the dealer code for tracking.
|
||
- Supports structured escalation logic based on the **Termination Category** — standard route for
|
||
working capital/performance cases, immediate escalation for unethical practices.
|
||
- Maintains versioned records for every document uploaded at creation stage.
|
||
|
||
**8.1.4 Personas-wise Accessibility & Visibility**
|
||
|
||
```
|
||
Persona / Role Access Level Visibility & Permissions
|
||
ASM / DD-AM Area Level Can initiate termination requests, upload MOMs and
|
||
dealer commitments.
|
||
RBM + DD-ZM Regional / Zonal
|
||
Level
|
||
```
|
||
```
|
||
Can view request details and validate information before
|
||
escalation.
|
||
ZBH Zonal Head Reviews initial request data, comments on justification,
|
||
and forwards to DD-Lead.
|
||
DD-Lead / DD-
|
||
Admin
|
||
```
|
||
```
|
||
National
|
||
Coordination
|
||
```
|
||
```
|
||
Can initiate, review, and forward requests; validates
|
||
completeness and assigns to Legal if required.
|
||
Legal Review Level Can view dealer details and supporting documents for
|
||
legal evaluation.
|
||
NBH National Business
|
||
Head
|
||
```
|
||
```
|
||
Can view the entire request summary before decision
|
||
and closure approval.
|
||
```
|
||
|
||
### 8.2 Termination Ticket overview
|
||
|
||
**8.2.1 Functionality Scope**
|
||
|
||
The **Details View** provides a consolidated summary of all key information related to the dealer
|
||
under review. It includes dealership codes, operational history, financial performance, and
|
||
termination-specific parameters. This enables reviewers at every level—whether ASM, ZBH, or
|
||
Legal—to quickly assess background context and validate evidence before taking action. The
|
||
interface also displays the current workflow stage and offers in-screen options
|
||
to **Approve** , **Withdraw** , or **Send Back** the request with remarks, ensuring traceable and reason-
|
||
based decisions.
|
||
|
||
**8.2.2 Width**
|
||
|
||
- Displays complete dealer profile: code, name, location, and GST details.
|
||
- Shows operational data: inauguration date, LOA, LOI, format, constitution, and last six-month
|
||
sales.
|
||
- Captures termination-specific data: **Termination Category** , reason, and case severity (e.g.,
|
||
“High”).
|
||
- Provides workflow action buttons— **Approve** , **Withdraw** , **Send Back** —with mandatory remarks
|
||
input.
|
||
- Integration with Work Notes for contextual communication and escalation traceability.
|
||
|
||
|
||
**8.2.3 Depth**
|
||
|
||
The **Detail Tab** serves as the **central operational dashboard** for viewing all dealer, operational,
|
||
and termination-related data within a single, structured interface. It merges static dealer master
|
||
information with dynamic workflow inputs and uploaded artefacts, ensuring contextual visibility
|
||
for all stakeholders.
|
||
|
||
```
|
||
8.2.3.1 Components & Functional Behavior
|
||
```
|
||
- **Dealer Information (Owner: DD-Admin / System Integration Layer)**
|
||
Displays master data pulled from the Dealer Master table — including **Dealer Code,**
|
||
**Name, Address, GST, Domain Name, City Category, Sales Code, Service Code, and GMA**
|
||
**Code**.
|
||
o Synced automatically from RE’s **Dealer Database (Master Registry)**.
|
||
o Read-only for all personas except system admin for data correction requests.
|
||
o Enables search and cross-referencing across termination, resignation, and
|
||
onboarding records.
|
||
- **Operational Details (Owner: DD-Lead / Workflow Engine)**
|
||
Highlights the dealership’s business health indicators and structural data, including **LOA,**
|
||
**LOI, Inauguration Date, Constitution Type, Dealership Type, Format Category, Dealer**
|
||
**Score Card Band, and Last Six-Month Sales**.
|
||
o Pulled dynamically from the Sales & Performance Module.
|
||
o Reflects the most recent sales cycle, ensuring leadership sees live performance
|
||
metrics during termination decision-making.
|
||
o Editable only by DD-Lead or authorized DD-Admin prior to case lock.
|
||
- **Termination Details (Owner: DD-Lead / DD-ZM / Legal)**
|
||
Captures case-specific details such as **Termination Category, Reason Description, and**
|
||
**Attachments**.
|
||
o Termination Category includes options like _Working Capital Issues, Performance_
|
||
_Shortfall, Breach of Agreement, or Unethical Practices_.
|
||
o Documents uploaded here are visible to all reviewers across the approval chain,
|
||
maintaining transparency.
|
||
o Legal team references this section while framing the **Show Cause Notice (SCN)** or
|
||
final termination letter.
|
||
- **Workflow Actions (Owner: Workflow Engine / DD-Lead)**
|
||
Displays **Approve, Withdraw, and Send Back** controls based on role permissions.
|
||
o Triggers automated workflow transitions and real-time updates in **Progress**
|
||
**Timeline** and **Audit Trail**.
|
||
o Any action logs mandatory remarks under “Communication & Notes” with
|
||
timestamp and user identity.
|
||
o Permissions vary per role:
|
||
|
||
|
||
```
|
||
▪ ASM, RBM: Can only comment or escalate.
|
||
▪ ZBH, DD-Lead, NBH: Can approve or send back.
|
||
▪ Legal: Can finalize after NBH approval.
|
||
```
|
||
- **Document Management Section (Owner: DD-Admin / Legal)**
|
||
Repository displaying all uploaded evidence or reports associated with the termination.
|
||
o Documents listed by **name, type, uploader, and date**.
|
||
o Supports inline viewing (no download needed) for internal confidentiality.
|
||
o File retention policy aligns with RE’s compliance standards (minimum 7 years).
|
||
- **Audit Trail (Owner: Workflow Engine / System Log)**
|
||
Chronologically records every action taken within the termination case — including
|
||
user, timestamp, and nature of change.
|
||
|
||
**8.2.4 Personas-wise Accessibility & Visibility**
|
||
|
||
```
|
||
Persona / Role Access Level Visibility & Permissions
|
||
ASM / DD-AM Area Level Can initiate and upload dealer MOMs and commitment
|
||
records.
|
||
RBM + DD-ZM Regional / Zonal
|
||
Level
|
||
```
|
||
```
|
||
Review dealer details, validate termination rationale,
|
||
and escalate with remarks.
|
||
ZBH Zonal Business
|
||
Head
|
||
```
|
||
```
|
||
Approves or returns the case with comments; can
|
||
forward to DD-Lead.
|
||
DD-Lead / DD-
|
||
Admin
|
||
```
|
||
```
|
||
National
|
||
Coordination
|
||
```
|
||
```
|
||
Validate details, review documents, assign to Legal, or
|
||
push for F&F after NBH approval.
|
||
Legal Legal Level Review dealer information, validate grounds, and issue
|
||
termination letter.
|
||
NBH National Head Provides final decision and authorization before case
|
||
closure.
|
||
```
|
||
### 8.3 Termination Approval & Review Process
|
||
|
||
**8.3.1 Functionality Scope**
|
||
|
||
The **Termination Approval module** enables Royal Enfield’s internal stakeholders to manage
|
||
dealership termination cases in a structured, transparent, and traceable workflow. It ensures that
|
||
|
||
|
||
every dealership performance concern — whether due to **working capital shortfall** , **sustained
|
||
underperformance** , or **unethical practices** — is systematically reviewed, documented, and acted
|
||
upon through the defined escalation hierarchy.
|
||
|
||
This module supports structured documentation of **dealer meetings** , **uploaded
|
||
artefacts** , **reviewer remarks** , and **legal correspondence** , ensuring no manual communication
|
||
dependency.
|
||
All approvals, send-backs, or withdrawals are centrally logged, supported by **Work Notes** ,
|
||
ensuring collaborative clarity and institutional memory across teams.
|
||
|
||
The **CEO is the final approving authority** for dealer termination cases. The **Legal team prepares
|
||
and issues the termination letter only after CEO approval** , and **not upon NBH approval**.
|
||
**CCO and CEO** are included as approval authorities with **Approve, Hold, and Reject options**.
|
||
The **dealer does not have portal access** for termination workflows.
|
||
|
||
**8.3.2 Width**
|
||
|
||
The process spans across the complete DD and Legal hierarchy, ensuring clear role-based
|
||
accountability:
|
||
|
||
- **ASM:** Conducts monthly visits, logs Meeting of Minutes (MOM), uploads dealer
|
||
commitment letter and personal observations. Logging MOM is not the part of this system
|
||
but when he feel to trigger Termination, he will log as description & associate documents
|
||
while initiating the flow.
|
||
- **RBM + DD-ZM:** Escalate after repeated concerns, conduct joint meetings, and document
|
||
dealer responses on portal.
|
||
- **ZBH:** Reviews zonal-level non-compliance, escalates unresolved cases to DD-Lead and
|
||
NBH.
|
||
- **DD-Lead:** Reviews consolidated reports, validates escalation records, prepares case
|
||
presentation, and assigns to Legal.
|
||
- **Legal:** Reviews chronology, evaluates policy or contractual breaches, issues SCN, and
|
||
prepares final Termination Letter.
|
||
- **DD-Head:** Reviews with DD-Lead and Legal; presents case to NBH for decision.
|
||
- **NBH:** Provides final decision – approve, query, or hold.
|
||
- **DD-Admin:** Uploads dealer’s SCN response and handles F&F coordination post Legal
|
||
issuance.
|
||
|
||
|
||
**8.3.3 Depth**
|
||
|
||
- **Structured Case Creation (Owner: DD-Lead / DD-Admin / ASM)**
|
||
A Termination case is initiated through the “Create Termination Request” form by DD-
|
||
Lead, DD-Admin, or ASM.
|
||
o Each request is tagged with a unique **Termination ID** (e.g., TERM-001).
|
||
o Dealer and operational data are automatically fetched from the **Dealer**
|
||
**Master** and **Sales System** for accuracy.
|
||
- **Case Workflow Management (Owner: Workflow Engine)**
|
||
Each stage of the termination journey — from ASM initiation to Legal closure — is
|
||
mapped to approval levels.
|
||
o **ASM → RBM/DD-ZM → ZBH → DD-Lead → Legal → DD-Head → NBH**.
|
||
o Actions at every level (Approve, Withdraw, Send Back) are recorded with
|
||
mandatory remarks.
|
||
o Each remark auto-updates in **Work Notes** and **Progress Timeline** , triggering
|
||
instant notifications to the next role.
|
||
- **Work Note Integration (Owner: All Reviewers)**
|
||
The **Work Note** acts as the **central communication thread** within each termination case.
|
||
o Each reviewer (ASM, RBM, ZBH, DD-Lead, Legal, etc.) can post contextual remarks,
|
||
share discussions, or tag specific users.
|
||
o Tagged users (e.g., @DD-Lead, @Legal) receive instant notifications via **system**
|
||
**alerts** and **email**.
|
||
o Work Notes serve as a real-time collaboration and escalation record — every
|
||
comment, clarification, or update remains **time-stamped and user-tagged**.
|
||
o Legal and DD-Head may also use Work Notes to request clarification from lower
|
||
hierarchies (ASM, RBM, ZBH).
|
||
o Once a note is submitted, it becomes immutable and part of the **permanent**
|
||
**record** under **Audit Trail**.
|
||
- **Meeting & Artefact Uploads (Owner: ASM, RBM, ZBH)**
|
||
Each level of escalation includes upload of MOMs, dealer commitment letters, and
|
||
observations while Approving at his level.
|
||
o Artefacts are uploaded as PDFs (e.g., _Meeting_MOM_June2025.pdf_ ).
|
||
o Dealer commitments are scanned and attached for cross-reference during Legal
|
||
and NBH reviews.
|
||
- **Approval Actions (Owner: Workflow Engine)**
|
||
Reviewers can take the following actions:
|
||
o **Approve:** Confirms escalation readiness for next level.
|
||
o **Send Back:** Pushes case back for clarification with remarks visible in Work Notes.
|
||
o **Withdraw:** Used when the concern is resolved or no termination action is required.
|
||
Each action is recorded in both **Audit Trail** and **Work Notes** , ensuring clarity on
|
||
decision paths.
|
||
|
||
|
||
- **Legal Review and Issuance (Owner: Legal Team)**
|
||
Legal reviews the case chronology and uploaded artefacts.
|
||
o If clarification is needed, they “Send Back” via Work Notes.
|
||
o Once validated, Legal create the **Show Cause Notice (SCN)** to the portal and later
|
||
create the **Termination Letter** post NBH approval.
|
||
o These Show cause Notice and Termination Letter will be created within the system
|
||
o All uploaded legal artefacts remain accessible to DD-Lead, DD-Admin, and NBH.
|
||
- **Dealer Interaction & Closure (Owner: DD-Admin / DD-Lead)**
|
||
Dealer replies to the SCN via DD-Admin, who uploads the response to the portal.
|
||
o DD-Lead reviews dealer’s response with inputs from RBM and ZBH, updates
|
||
closure remarks, and forwards to NBH.
|
||
o Post-approval, Legal uploads the Termination Letter, visible to DD-Admin and
|
||
dealer.
|
||
o DD-Admin initiates **F&F** coordination, ensuring all records are finalized within SLA.
|
||
- **Immediate Termination (Owner: DD-Lead + Legal)**
|
||
Cases categorized under “Unethical Practice” trigger direct routing to Legal + DD-
|
||
Lead, skipping intermediate reviews.
|
||
o Immediate Legal action and issuance of termination communication occur within
|
||
the system, ensuring swift compliance.
|
||
- **Audit Trail (Owner: System Engine)**
|
||
Each user action — approval, send back, upload, comment — is timestamped and
|
||
permanently logged.
|
||
o The trail captures: _User Name, Action Type, Timestamp, Remarks Summary, and_
|
||
_Linked Artefact_.
|
||
o Accessible by DD-Lead, Legal, DD-Head, and NBH for compliance review.
|
||
|
||
**8.3.4 Personas-wise Accessibility & Visibility**
|
||
|
||
```
|
||
Persona Responsibilities & Key Actions Access Rights
|
||
ASM Creates termination request, uploads MOM & dealer
|
||
commitments, adds initial remarks and observations.
|
||
```
|
||
```
|
||
Create, View,
|
||
Comment
|
||
RBM / DD-
|
||
ZM
|
||
```
|
||
```
|
||
Reviews ASM input, conducts escalation meetings,
|
||
uploads MOM, provides joint recommendations.
|
||
```
|
||
```
|
||
View, Approve,
|
||
Send Back
|
||
ZBH Reviews regional non-compliance, uploads MOM,
|
||
forwards unresolved cases to DD-Lead.
|
||
```
|
||
```
|
||
Approve, Send
|
||
Back
|
||
DD-Lead Reviews full chronology, validates artefacts, triggers Legal
|
||
for input, issues SCN, consolidates for final closure.
|
||
```
|
||
```
|
||
Full Access,
|
||
Approve,
|
||
Withdraw
|
||
Legal Reviews chronology, uploads SCN, issues Termination
|
||
Letter, queries if required through Work Notes.
|
||
```
|
||
```
|
||
Approve, Send
|
||
Back, Upload
|
||
DD-Head Reviews consolidated cases, presents them to NBH for
|
||
final decision.
|
||
```
|
||
```
|
||
Review, Comment
|
||
```
|
||
|
||
```
|
||
NBH Approves or holds termination case; final authority on go-
|
||
ahead decisions.
|
||
```
|
||
```
|
||
Approve / Hold
|
||
```
|
||
```
|
||
DD-Admin Uploads dealer’s SCN reply, final Termination Letter, and
|
||
initiates F&F.
|
||
```
|
||
```
|
||
Upload, Close
|
||
```
|
||
```
|
||
Dealer
|
||
(Read-only)
|
||
```
|
||
```
|
||
Views SCN and final Termination Letter. View Only
|
||
```
|
||
### 8.4 Termination Progress Timeline
|
||
|
||
**8.4.1 Functionality Scope**
|
||
|
||
The **Termination Progress Timeline** provides a stage-wise visualization of the entire termination
|
||
journey — from case initiation to final closure. It ensures that every escalation, document, review,
|
||
and approval is tracked transparently with timestamped accountability.
|
||
|
||
Each level in the workflow — from **ASM initiation** to **CEO authorization** — is dynamically
|
||
reflected with role names, document counts, feedback notes, and status indicators.
|
||
The module promotes structured collaboration by integrating **Work Notes** and **Audit
|
||
Trail** updates at each milestone, enabling leadership to monitor the decision flow in real time.
|
||
|
||
|
||
**8.4.2 Width**
|
||
|
||
The timeline consolidates inputs from multiple roles, creating an end-to-end view of operational,
|
||
business, and legal evaluations:
|
||
|
||
- **ASM** initiates the request and uploads meeting artefacts.
|
||
- **RBM / DD-ZM** review and escalate based on repeated violations.
|
||
- **ZBH** performs zonal validation and comments.
|
||
- **DD-Lead** consolidates data, reviews chronology, and assigns to Legal.
|
||
- **Legal** verifies contract breaches and provides legal opinion or Show Cause Notice (SCN).
|
||
- **NBH** performs business-level evaluation and grants or holds final approval.
|
||
- **CEO / CCO** complete the executive authorization.
|
||
- **DD-Admin** coordinates issuance of the final Termination Letter and forwards it to F&F.
|
||
|
||
Each transition (approve, send-back, withdraw) automatically updates the timeline with the
|
||
reviewer’s remarks and uploaded artefacts.
|
||
|
||
**8.4.3 Depth**
|
||
|
||
The Termination Progress Timeline follows a clearly defined 14-stage lifecycle. Each stage is
|
||
associated with specific ownership, document uploads, and Work Note actions.
|
||
|
||
```
|
||
8.4.3.1 Stage-wise Breakdown
|
||
```
|
||
1. **Request Initiated** – _ASM / Initiator_
|
||
o Case created with details, termination reason, and dealer code.
|
||
o Supporting documents like MOM and commitment letters attached.
|
||
o Remarks and feedback logged in Work Notes.
|
||
2. **RBM Review** – _RBM + DD-ZM_
|
||
o Joint meeting notes uploaded; recommendations shared.
|
||
o Approve or Send-Back with clarification via Work Note.
|
||
3. **ZBH Review** – _Zonal Business Head_
|
||
o Evaluates pattern of violations, reviews MOM chain, and adds escalation remarks.
|
||
4. **DD Lead Review** – _DD-Lead_
|
||
o Consolidates documentation from ASM, RBM, and ZBH.
|
||
o Prepares case synopsis and assigns to Legal for compliance validation.
|
||
5. **Legal Verification** – _Legal Department_
|
||
o Reviews breach type (Working Capital, Performance, Unethical Practice).
|
||
o Queries or approves via Work Notes.
|
||
o Uploads draft SCN if verified.
|
||
6. **NBH Evaluation** – _National Business Head_
|
||
|
||
|
||
```
|
||
o Reviews termination recommendation; may approve, hold, or query.
|
||
```
|
||
7. **Show Cause Notice (SCN)** – _Legal + DD-Lead_
|
||
o Official SCN issued to dealer.
|
||
o Dealer reply awaited; all correspondence uploaded.
|
||
8. **DD Lead & Legal Review** – _Joint Review_
|
||
o Evaluates dealer’s SCN reply.
|
||
o Records internal discussion outcome in Work Notes.
|
||
9. **DD-Head Review** – _Dealer Development Head_
|
||
o Prepares presentation and recommendation for NBH.
|
||
10. **CCO Approval** – _Chief Commercial Officer_
|
||
o Reviews and endorses NBH’s decision.
|
||
11. **CEO Final Approval** – _Chief Executive Officer_
|
||
o Authorizes final termination execution.
|
||
12. **Legal – Termination Letter** – _Legal Team_
|
||
o Uploads signed Termination Letter to portal.
|
||
o Triggers auto-notifications to DD-Lead and DD-Admin.
|
||
13. **DD-Admin – Share with Dealer** – _DD-Admin_
|
||
o Forwards Termination Letter to dealer.
|
||
o Initiates F&F process and records completion date.
|
||
14. **Dealer Terminated** – _System Generated_
|
||
o Marks dealership status as “Terminated.”
|
||
o Case locked for further edits; all data archived under Audit Trail.
|
||
|
||
```
|
||
8.4.3.2 Work Note Integration
|
||
```
|
||
- Each stage allows the reviewer to post contextual **Work Notes** for coordination,
|
||
clarification, or escalation.
|
||
- Notes automatically capture **author, timestamp, and linked stage**.
|
||
- Tagged users receive both **email** and **in-app alerts**.
|
||
- Work Notes act as the **single source of truth** , capturing every internal discussion and
|
||
external clarification.
|
||
- Once the case reaches “Dealer Terminated,” Work Notes are archived as part of the
|
||
official record visible under **Audit Trail**.
|
||
|
||
**8.4.4 Personas-wise Accessibility & Visibility**
|
||
|
||
```
|
||
Persona Visibility in Timeline Actions Allowed
|
||
ASM Initiate request, view complete history, comment
|
||
in Work Notes.
|
||
```
|
||
```
|
||
Create, Upload Docs,
|
||
Comment
|
||
RBM / DD-ZM See all lower-level stages, add remarks, approve or
|
||
send-back.
|
||
```
|
||
```
|
||
Approve, Send-Back,
|
||
Comment
|
||
ZBH Access RBM & ASM artefacts, escalate to DD-Lead. Approve, Send-Back
|
||
```
|
||
|
||
```
|
||
DD-Lead Full timeline visibility, assign to Legal, manage SCN,
|
||
approve final closure.
|
||
```
|
||
```
|
||
Full Access
|
||
```
|
||
```
|
||
Legal Review termination grounds, issue SCN, upload
|
||
Termination Letter.
|
||
```
|
||
```
|
||
Approve, Send-Back,
|
||
Upload Docs
|
||
NBH View all previous stages, make go/no-go decision. Approve / Hold
|
||
CCO / CEO Executive-level read access, approve final
|
||
termination.
|
||
```
|
||
```
|
||
Approve Only
|
||
```
|
||
```
|
||
DD-Admin View complete timeline, upload dealer response &
|
||
Legal letter, initiate F&F.
|
||
```
|
||
```
|
||
Upload, Close
|
||
```
|
||
```
|
||
Dealer (Read-
|
||
only)
|
||
```
|
||
```
|
||
View SCN and Termination Letter post-issuance. View Only
|
||
```
|
||
|
||
---
|
||
|
||
## 13 Non-Functional Requirements
|
||
|
||
```
|
||
Category Requirement
|
||
Performance Average response time < 3 seconds for standard operations.
|
||
Scalability Should scale horizontally on GCP.
|
||
Security JWT tokens, encrypted passwords, HTTPS enforced.
|
||
Usability Intuitive UI, consistent icons, and simple navigation.
|
||
Reliability 99% uptime target.
|
||
Backup & Recovery Daily database backup and weekly full snapshot.
|
||
Compliance Follows RE IT data privacy guidelines.
|
||
```
|
||
## 14 Technology Matrix
|
||
|
||
```
|
||
Component Specification
|
||
Database PGSQL (Managed or local instance)
|
||
Application Stack Node.js (Backend) + React.js (Frontend)
|
||
Authentication RE SSO Bridge
|
||
```
|
||
## 15 Infra requirements & System Hygiene
|
||
|
||
```
|
||
Component Specification
|
||
Environment QA / Testing
|
||
# of Virtual Machines (VMs) 1
|
||
CPU Configuration 4 - Core
|
||
Memory (RAM) 16 GB
|
||
Disk Size 500 GB
|
||
Operating System Ubuntu 24.04 LTS
|
||
```
|
||
|
||
```
|
||
Storage Type Cloud
|
||
```
|
||
Backup and Recovery
|
||
|
||
- Daily incremental and weekly full backups.
|
||
- Restore process must not exceed 2 hours.
|
||
|
||
## 16 Not in scope
|
||
|
||
Anything which comes beyond the scope defined above in terms of Width and depth
|