Re_Figma_Code/Dealer_Claim_Managment.md

RE Workflow – Dealer Claim Management

System Requirements Specifications

8 - Nov- 2025

Version 1. 0

Contents

• 1 System Overview & Problem Statement
• 2 Use case scenarios
• 3 Intended Audience
• 4 HiFi Wireframe
• 5 Integration with RE Workflow
• 6 Flow of Application
• 7 System Features & Requirements
  • 7.1 SSO Login
  • 7.2 Side Navigation Menu
  • 7.3 Create New Request
  • 7.4 Create New Request – Basic Information
  • 7.5 Request Overview
  • 7.6 Claims Requests Overview
  • 7.7 Request Detail Page
  • 7.8 Workflow..................................................................................................................
  • 7.9 Dealer – Proposal Submission – Step 1....................................................................
  • 7.10 Request Evaluation & Confirmation – Step
  • 7.11 Department Lead Review – Step
  • 7.12 Activity Creation – Step
  • 7.13 Dealer Completion Documents – Step
  • 7.14 Request Claim Approval
  • 7.15 e-Invoice & Credit Note – Step 7 &
  • 7.16 Document Section
  • 7.17 Activity Tab...............................................................................................................
  • 7.18 Claim Request Overview Tab
  • 7.19 Notifications
  • 7.20 Add Work Note
  • 7.21 Add Spectator
  • 7.22 Dashboard
• 8 Non-Functional Requirements
• 9 Technology Matrix
• 10 Infra requirements & System Hygiene
• 11 Not in scope

1 System Overview & Problem Statement

The Dealer Claims Management System aims to streamline and digitize the existing claim submission and approval process currently handled through manual workflows and Google Forms. The new web-based platform will serve as a unified interface for both Royal Enfield (RE) stakeholders and dealers, ensuring structured data capture, transparent tracking, automated validations, and seamless collaboration. The system will integrate with SAP for IO (Internal Order) validation and budget blocking, and interaction with existing DMS system. Through a centralized dashboard and role-based access, it will enable end-to-end visibility, improved turnaround time, and standardized claim lifecycle management.

2 Use case scenarios

Below are the sample scenarios represent typical use cases where the system will streamline submissions, validations, and approvals through a standardized digital process.

A few illustrative examples include:

• 10 - Day Trial of Bike to RE Employees – where a dealer provides trial vehicles to RE employees, and the claim for reimbursement is initiated, approved, and settled through the system.
• Campaign Activities – where marketing or promotional campaigns executed at the dealership level are proposed, approved, and reimbursed through a defined workflow with IO validation and document-based claim settlement.
• Vehicle Service Initiatives – where dealers submit claims related to service drives, warranty campaigns, or maintenance programs, supported by digital documentation, approval tracking, and automated credit note generation.

These scenarios demonstrate how the system will bring structure, visibility, and automation to dealer-related financial claim processes across departments.

3 Intended Audience

The Dealer Claims Management System will be used by multiple internal and external stakeholders involved in the claim initiation, evaluation, and settlement process. Each audience plays a distinct role in ensuring that claims are validated, approved, and reimbursed in a structured and transparent manner.

• Initiator – An internal Royal Enfield employee who creates a new request in the system for any dealer-related activity such as marketing, service, or trial programs. The initiator

is responsible for defining the activity details, associating the appropriate Internal Order
(IO) , and submitting it for departmental review.

• Dealer – The Royal Enfield dealer who initiates the claim process against a request raised by the initiator. The dealer submits proposals, cost break-ups, and post-activity documentation through the system to seek reimbursement or credit note issuance.
• Department Lead – The authorized reviewer responsible for evaluating the request and associated documents. The department lead validates the activity scope, approves or rejects the claim, and facilitates IO budget blocking and fund confirmation.
• DMS (System Integration) – The existing Dealer Management System (DMS) that will interface with the new application to coordinate e-Invoice generation and Credit Note creation. This integration ensures that financial documents are automatically generated and synchronized with downstream systems such as SAP.

Together, these audiences form the core user ecosystem of the Dealer Claims Management System, enabling an end-to-end, role-based, and automated claim management process across the Royal Enfield network.

4 HiFi Wireframe

Hi-Fi Wireframe: https://start-flop-42215693.figma.site

5 Integration with RE Workflow

When the user log in to the RE Work flow and clicks on it will give following options.

1. Tile : Non templated (anyone) & templated (Admin generated) 2. Tile : Custom workflow (where ever form fields needs to be saved separately in DB). a. Dealer Claim Management (This application) 3. Tile : Digital app a. Dealer onboarding (separate application with it’s own SRS)

6 Flow of Application

This section describes the end-to-end flow of the Workflow Management – Non-Templatized application. It outlines how users interact with the system, how approvals move through different stages, and how data transitions between modules until final closure.

7 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 behavioural details — describing how the feature behaves through its logic, workflow, system responses, and edge-case handling. It answers the question: “How does the system execute and respond in these scenarios?”

7.1 SSO Login

The system will integrate with the existing RE SSO Bridge to enable secure, seamless login for all authorized Royal Enfield employees. This ensures unified authentication, eliminating the need for separate credentials and maintaining compliance with RE’s security standards.

Width:

• Integrates with the existing RE SSO Bridge for secure authentication.
• Allows access only to authorized Royal Enfield employees.
• Automatically retrieves user details ( name, employee ID, department ).

Depth:

• Uses token-based authentication and HTTPS for secure sessions.
• Handles session timeout and re-authentication per RE’s IT security policy.

Dependency

• SSO implementation guide and sample users are required.

7.2 Side Navigation Menu

The Side Menu provides users with quick and consistent navigation across the application. It includes the following primary sections:

• Dashboard: Overview of workflow activities, key metrics, and pending actions.
• My Requests: Displays all workflow requests created by the logged-in user.
• Open Requests: Lists all active or in-progress workflows requiring action. These may include requests initiated by or assigned to the logged-in user.
• Closed Requests: Shows all completed or approved workflows for reference. These may include requests created by or processed by the logged-in user.
• Raise New Request: Allows users to initiate and submit a new workflow request.

Width:

• Offers persistent navigation to Dashboard , My Requests , Open Requests , Closed Requests , and Raise New Request.
• Ensures consistent access throughout the system.

Depth:

• Implements active route highlighting and role-based visibility.
• Includes search, sort, and filter capabilities.
• Supports pagination and stable ID-based navigation to detail screens.

7.3 Create New Request

This screen appears when the user clicks “Raise New Request” > “Custom Workflow” > “Claim Management” It introduces a wizard-style navigation that guides users through the request creation process in sequential steps.

Width:

• Gateway to initiate the process.
• Displays wizard navigation with progress indicator.

Depth:

• Enforces mandatory selection before proceeding.

7.4 Create New Request – Basic Information

7.4.1 Functionality Scope

The Claim Details screen serves as the first step in initiating a New Claim Request within the Dealer Claims Management workflow. It allows the Initiator to capture complete contextual information related to the proposed activity or claim before routing it for review. The screen includes fields to define the Activity Name , select from predefined Activity Types , and identify the relevant Dealer Code / Dealer Name. The Date field captures the request initiation date , while Location specifies the place of activity. The Request in Detail section enables the initiator to provide a descriptive overview of the claim requirement, referencing scenarios such as trial bikes, campaign execution, or service initiatives. An optional Period field records the tentative start and end dates of the activity to define its operational duration. This screen standardizes data entry at the initiation stage, ensuring structured information capture and consistency across all claim categories.

7.4.2 Width

• Captures activity metadata such as Activity Name, Type, Dealer, Date, and Location for all claim categories.
• Supports a predefined set of Activity Types , including: o Riders Mania Claims o Marketing Cost – Bike to Vendor o Media Bike Service o ARAI Motorcycle Liquidation o ARAI Certification – STA Approval CNR o Procurement of Spares/Apparel/GMA for Events o Fuel for Media Bike Used for Event o Motorcycle Buyback and Goodwill Support o Liquidation of Used Motorcycle o Motorcycle Registration CNR (Owned or Gifted by RE) o Legal Claims Reimbursement o Service Camp Claims o Corporate Claims – Institutional Sales PDI
• Provides a guided input format to minimize errors and support validation at the data- entry level.

7.4.3 Depth

• Enforces mandatory field validations for Activity Name, Type, Dealer, Date, Location, and Detailed Requirement.

• Delears will be fetched from existing SAP system.

• Allows dynamic single selection of predefined Activity Types from the system’s configuration layer.

• Records request initiation timestamp for SLA and audit tracking.

• Accepts free-text inputs for detailed descriptions with configurable character limits.

• Supports optional period capture to define project or activity timelines.

• Integrates with subsequent workflow stages to prefill information for IO validation , budget blocking , and document submission.

7.5 Request Overview

7.5.1 Functionality Scope

The Review & Submit screen represents the final stage in creating a New Claim Request within the Dealer Claims Management workflow. It enables the Initiator to review all captured information — including Activity Details , Dealer Information , Date & Location , Request Details , and Activity Period — before final submission. This screen consolidates the entered data into a structured, read-only summary, allowing the initiator to validate the accuracy and completeness of the claim details. Upon confirmation, the initiator submits the request, transitioning it into the approval workflow for departmental review and IO validation. This functionality ensures data integrity, eliminates manual resubmissions, and acts as a verification checkpoint before claim activation.

7.5.2 Width

• Displays a comprehensive preview of all information entered in Step 1, including: o Activity Information: Name and Type of activity. o Dealer Information: Code, Name, Contact details, and Address. o Date & Location: Date of request initiation and activity location. o Request Details: Brief requirement and objective of the claim. o Period: Start and End dates defining the tentative activity duration.
• Provides a read-only confirmation view for initiators before submission.
• Supports navigation control (Previous / Submit) to allow review and correction if required.
• Acts as the handover point from request creation to the automated approval and budget validation stages.

7.5.3 Depth

• Implements field mapping from Step 1 to auto-populate the review interface.
• Performs front-end validation checks to ensure all mandatory information is captured before submission.
• Enables single-click submission that triggers claim registration and generates a unique claim ID.
• Initiates the approval workflow involving the Department Lead and subsequent system validations.
• Logs submission timestamp and initiator credentials for audit tracking.
• Displays contextual confirmation messages such as “Ready to Submit” to guide users and reduce input errors.
• Integrates seamlessly with backend APIs to store claim details and mark the record status as “Pending Approval.”

7.6 Claims Requests Overview

7.6.1 Functionality Scope

The My Requests screen serves as a centralized tracking dashboard for both the Initiator and the Dealer involved in a claim process which will appear upon respective role’s login. It displays all claim requests that have been created, submitted, or are currently under review within the system. Each request is visible to the Initiator who raised it and simultaneously to the respective Dealer on whom the request has been created. The screen provides a consolidated view of claim progress, approval status, and associated details such as activity name , claim type , submission date , dealer information , and workflow level.

7.6.2 Width

• Displays all claim requests accessible to both: o Initiator: Requests created and submitted by the logged-in RE employee. o Dealer: Requests raised against the dealer’s code, available for action or tracking upon his login.
• Categorizes records by workflow status — Total , In Progress , Approved , Rejected , and Draft (not visible to Dealers).
• Presents summary-level details for each claim, including: o Activity Name and Claim Type o Brief Description / Requirement Summary o Claim ID , Submission Date , and Workflow Level

o Dealer Name and Curren`t Status (Pending, Approved, etc.)

• Supports search and filter options by status, priority, or keyword.
• Allows direct navigation to detailed claim views for further action or review.
• Highlights template tags (e.g., Template: Claim Management ) for request type identification. So if a request if for any other claim template like Non-Templatized, it will be shown with respective tag “Non-Templatized”.

7.6.3 Depth

• Implements role-based visibility ensuring that: o The Initiator can view and monitor requests they have created. o The Dealer can view all requests linked to their dealership code.
• Updates claim progress in real time , reflecting approvals, clarifications, or pending actions.
• Enables workflow-level tracking , showing the current stage and responsible party.
• Maintains audit logs for every status transition to ensure transparency and compliance.
• Integrates search indexing for faster retrieval of records by title, ID, or description.
• Supports automated notifications to both initiator and dealer when the request status changes.
• Ensures data segregation and access control so users can only view authorized records relevant to their role.

7.7 Request Detail Page

7.7.1 Functionality Scope

The Request Detail Page provides a comprehensive view of an individual claim request and acts as the central workspace for users involved in its processing. It displays complete contextual information — including Activity Information , Dealer Information , Initiator Details , and SLA Progress — along with navigation tabs for Workflow , IO , Documents , and Activity Log. This screen allows authorized users to review , act , and communicate on the request at any workflow stage. Actions such as Add WorkNote , Add Spectator , Approve Step , or Reject Step are available to approvers based on role permissions. The page also displays current workflow status , step level , and claim progress duration to ensure visibility and traceability.

7.7.2 Width

• Provides a unified claim summary , including: o Activity Information: Name, Type, Location, Date, Period, and Estimated Budget. o Dealer Information: Code, Name, Contact details, and Address. o Initiator Information: Name, Department, Email, and Contact.
• Displays SLA progress bar showing remaining duration against configured TAT for the overall request
• Offers Quick Actions for role-based interactions: o Add WorkNote – to record internal comments or clarifications. o Add Spectator – to grant view-only access to additional stakeholders. o Approve Step / Reject Step – to execute workflow decisions.
• Includes modular tabs for: o Workflow (8-Steps) – to view process flow and current level. o IO – to check internal order details, balance, and budget status. Nothing related to the IO will be ever visible to Dealer o Documents – to access uploaded proposals, invoices, or completion reports. o Activity – to review action history and status logs.
• Accessible to all users linked with the claim, including Initiator , Dealer , and Department Lead.

7.7.3 Depth

• Fetches real-time workflow data and SLA metrics from the process engine.
• Displays step-specific actions dynamically based on the user’s role and node ownership.
• Records every decision and comment (approve, reject, clarification) with timestamp for auditability.
• Allows spectator addition without altering workflow sequence, maintaining visibility for oversight roles.
• Enables WorkNotes to be tagged with visibility levels (internal-only or shared) for contextual communication.
• Updates claim status and workflow progression instantly upon approval or rejection.
• Ensures role-based data security , showing only relevant tabs and actions to authorized users.
• Maintains complete traceability through an integrated audit trail across all sub-modules (IO, Documents, Workflow).

7.8 Workflow..................................................................................................................

Functionality Scope

The Workflow (8-Steps) module defines the end-to-end approval structure for Dealer Claim Management , guiding each claim through a fixed and standardized sequence of actions. This workflow ensures that every claim—once initiated—progresses systematically through dealer submission, internal validations, budget confirmation, and final credit-note generation. Each workflow step have defined TAT at admin level, responsible role, and decision outcomes. The system manages status transitions automatically, updates SLA progress, and triggers notifications at each approval or rejection point. The module incorporates WorkNotes and Spectator functionality for collaboration, enables real- time SLA tracking with visual indicators, and maintains a complete Activity Log for audit and compliance.

Width

• Covers the complete 8 - step dealer claim process , including:
  1. Dealer – Proposal Submission
  2. Requestor – Evaluation & Confirmation
  3. Department Lead – Approval & Budget Blocking
  4. System – Activity Creation (Auto Process)
  5. Dealer – Completion Document Submission
  6. Requestor – Claim Approval
  7. System – e-Invoice Generation (via DMS)
  8. Finance/SAP – Credit Note Confirmation
• Each step have its own TAT and decision options.
• Supports actions: Approve , Reject , and Request Clarification (operated via worknotes), with mandatory remarks at every decision point.
• Displays SLA progress in hours or days with color-coded indicators (Green – Within TAT, Yellow – Approaching, Red – Breached).
• Spectator addition for view-only participation.
• Auto-notifies concerned users on every state transition or SLA breach.
• Keeps IO and budget details restricted to internal RE roles (Requestor, Dept Lead, Finance); dealers have no visibility of IO data.

Depth

• Implements fixed eight-step flow where transitions are automated and linear—no manual rearrangement or dynamic node insertion allowed.
• Each step runs its own TAT timer, isolated from preceding or subsequent levels.
• SLA Progress Bar updates in real-time; thresholds (e.g., 70%, 90%) trigger auto-reminders to pending actors.
• Every action, comment, and document upload is captured in the Activity Log for traceability and audit.
• Automatic system transitions: o Step 4 (Activity Creation) auto-triggers confirmation email to dealer and lead. o Step 7 (e-Invoice Generation) initiates DMS integration for invoice creation. o Step 8 (Credit Note Confirmation) syncs with DMS to mark claim closure.
• Integrates with the Notification Engine to send in-app and email alerts on task assignment, SLA breach, or decision update.

7.9 Dealer – Proposal Submission – Step 1....................................................................

7.9.1 Functionality Scope

The Dealer Proposal Submission step is the first stage of the dealer claim workflow, accessible only to the Dealer through their login panel. This interface enables the dealer to upload a detailed proposal document for the activity, submit a cost-wise breakup , define a tentative timeline for closure , and provide supporting remarks or comments describing the execution plan.

The submitted proposal serves as the formal input for internal review by the Requestor and Department Lead , forming the financial and operational base for IO validation and budget blocking in subsequent steps.

7.9.2 Width

• Available exclusively to the Dealer once a claim request is assigned.
• Captures and validates the following mandatory fields: o Proposal Document (PDF, DOC, DOCX) – main activity proposal. All the documents can be downloaded further to review. o Cost Breakup – itemized expense list with amount and automatic total calculation. o Timeline for Closure – selectable as a specific date or number of days. o Dealer Comments / Details – descriptive text including rationale, activity plan, or special notes.
• Displays the Estimated Budget dynamically, based on cost breakup entries.
• Provides real-time validation and error alerts (e.g., Missing Required Information ).
• Enables a single action — Submit Documents — to complete this stage and route the claim to the next step.

7.9.3 Depth

• The screen becomes visible only when the Dealer is the active user for the current workflow stage.
• Supports multiple file uploads with type and size validation.
• Auto-calculates the Estimated Budget and locks the value once submitted for initiator review.
• Performs mandatory field validation for proposal document, cost breakup, timeline, and dealer comments before enabling submission.
• Stores all data securely and passes it forward to the Requestor Evaluation & Confirmation stage for review.
• Prevents re-submission after completion to maintain data integrity.
• The dealer’s uploaded documents and entered values become read-only for all subsequent roles (Requestor, Department Lead, Finance).
• Maintains an audit trail capturing: upload timestamps, file metadata, dealer identity, and remarks.
• Automatically triggers a system notification to the Requestor and Department Lead once the proposal is submitted.
• IO details and budget validations are handled only in later internal steps — they are not visible to the Dealer at any stage.

7.10 Request Evaluation & Confirmation – Step

7.10.1 Functionality Scope

The Requestor Evaluation & Confirmation step is performed by the Requestor (Initiator) immediately after the dealer submits the proposal. In this stage, the requestor reviews all the documents uploaded by the dealer in the previous step, including the proposal document , cost breakup , and any supporting attachments. The requestor validates the feasibility, relevance, and completeness of the dealer’s submission and provides remarks or clarifications as needed. Based on this assessment, the requestor either confirms the request for departmental approval or rejects it with justification. He may also need some additional clarification which he can connect with dealer over to Worknotes and ask for details. Dealer will submit the documents and clarification over work notes itself.

Upon confirmation, the workflow transitions automatically to the Department Lead Approval step. This action acts as an internal validation layer before budget blocking and IO processing.

7.10.2 Width

• Accessible only to the Requestor (the user who initiated the claim).
• Displays the following data for review: o Dealer Submission Summary – proposal document, cost breakup, timeline, and dealer comments. o Uploaded Attachments – viewable or downloadable from the Documents tab. o Activity Log – showing dealer submission date and remarks.
• Provides two decision options: o Confirm Request (Approve) – forwards claim to the Department Lead for approval. o Reject Request – cancels the claim with mandatory remarks.
• Requires comments and remarks before submission for both approval and rejection actions.
• Displays visual progression within the workflow (Dealer step turns green once approved).
• Integrates with notification system to alert the next approver or the dealer based on the decision outcome.

7.10.3 Depth

• This step becomes active only after the Dealer Proposal Submission is marked as approved.

• Fetches dealer-uploaded proposal, cost details, and attachments automatically from Step 1.

• Allows the requestor to download & view and validate files (PDF, Word, Excel, image) directly within the Documents section.

• Enforces mandatory remarks during approval or rejection using the “Approve Request” dialog box.

• On approval , the system: o Marks the step as Approved with timestamp and approver identity. o Moves the workflow to Step 3 – Department Lead Approval. o Sends notifications to both Department Lead and Dealer.

• On rejection , the system: o Marks the claim as Rejected and closes the workflow. o Sends rejection remarks to the Dealer and Requestor for visibility.

• The Requestor may seek additional clarification from the Dealer before confirming the request. Such communication is handled through the WorkNotes section, where the Requestor can post specific queries, tag the dealer, and request additional documents or explanations.

• The Dealer can respond within the same WorkNotes thread , attaching the required files or clarifications directly in the conversation.

• All exchanges between the Requestor and Dealer in the WorkNotes are time- stamped , role-tagged , and preserved in the Activity Log for full traceability.

• Once the clarification is received and verified, the Requestor can proceed to either confirm or reject the claim based on the updated information.

• No separate upload or resubmission process is required — all additional files shared through WorkNotes automatically link to the claim’s Documents tab for unified access and audit continuity.

• All comments, uploaded files, and status changes are automatically logged in the Activity Tab for audit tracking.

• The Requestor can also attach additional reference files (if required) in the Documents Tab.

• Ensures data integrity and prevents further modification of dealer entries after review submission.

7.11 Department Lead Review – Step

7.11.1 Functionality Scope

The Department Lead Approval step is the internal financial validation point of the claim workflow. After the Requestor confirms the dealer proposal, the Department Lead reviews the request details, supporting documents, and discussion threads through WorkNotes. This step ensures that sufficient funds are available under the relevant Internal Order (IO) and that the proposed activity is financially viable. The Department Lead enters the IO number , retrieves the available budget from the SAP system, and determines the amount to block. The entered amount is a free-text field , allowing the requestor to include a buffer over the dealer’s estimated cost to accommodate potential overages. Once verified, the Department Lead approves the claim, triggering the IO budget block within SAP. The approval moves the workflow automatically to the Activity Creation stage.

7.11.2 Width

• Accessible only to the Department Lead after Requestor approval.
• Displays: o Activity and Dealer details for contextual reference. o Documents and WorkNotes for reviewing the proposal and clarifications. o IO Budget Management section for validation.
• Supports: o Manual IO Number entry. o Fetch Amount action to retrieve the live IO balance from SAP. o Amount to Block input (free-text) for specifying the claim amount plus optional buffer. o Block IO in SAP action to reserve the approved amount.
• Displays calculated summary fields:

o Available in IO , Amount to Block , and Remaining After Block.

• Provides approval actions: Approve and Organise IO , Reject , or Request Clarification (all with mandatory remarks).
• Sends system notifications to relevant users after each decision.

7.11.3 Depth

• The IO balance is fetched directly from SAP via a real-time integration once the IO number is entered and Fetch Amount is executed.
• Dealers have no visibility of any IO data; this screen is strictly for internal RE users.
• The Amount to Block field allows entry of a value higher than the dealer estimate (as an operational buffer).
• On approval , the system: o Validates the entered amount against the available IO balance. o Executes an automated “Block IO in SAP” transaction, reserving the budget. o Captures details such as IO Number, SAP Document Number, Blocked Amount, Remaining Amount, Blocked By, and Timestamp. o Marks the step as Approved and transitions to Step 4 – Activity Creation.
• On rejection , the workflow is closed with the reason logged in the Activity Tab and notified to the Requestor and Dealer.
• If clarification is required, the Department Lead uses WorkNotes to interact with the Requestor or Dealer; files shared there are auto-linked to the Documents Tab.
• The system enforces validations for: o Missing or invalid IO numbers. o Attempting to block more than the available balance (error shown). o Duplicate block attempts (disallowed).
• Every action, fetch, and block event is timestamped and logged in the Activity Trail for audit and compliance.
• Ensures role-based security — IO details remain visible only to internal RE users (Requestor, Department Lead, Finance).

7.12 Activity Creation – Step

7.12.1 Functionality Scope

The Activity Creation step is a system-driven automation stage triggered immediately after the Department Lead approves the claim and successfully blocks the IO amount. Once triggered, the system automatically generates an Activity Record linked to the corresponding claim and sends out automated email notifications to all stakeholders — Dealer , Requestor , and Department Lead — informing them that the activity has been approved and is ready to commence.

7.12.2 Width

• Operates as a fully automated background process ; no manual action is required.
• Automatically: o Creates an Activity Record associated with the claim ID. o Sends email notifications to the Dealer, Requestor, and Department Lead. o Updates workflow status to Approved and marks Step 4 as completed.
• The email notification includes: o Subject: “Activity Created – [Claim ID]”. o Body: Confirmation message indicating successful creation of the activity. o Stakeholder list: All related users of the workflow (Dealer, Requestor, Department Lead).
• Enables users to click the email icon to view the complete notification template from within the system.
• Displays visual confirmation (“Activity created automatically”) and logs timestamp of completion.

7.12.3 Depth

• System logic auto-initiates once IO blocking confirmation is received from SAP.

• Generates an Activity Reference ID and associates it with the parent claim for traceability.

• Triggers notification engine to dispatch pre-configured email templates from the Royal Enfield Claims Portal.

• Email content is standardized and retrieved from the Notification Template Repository to ensure brand consistency.

• Marks Step 4 as Approved with automatic timestamp, approver identity (System Auto- Process), and SLA status.

• Logs all generated notifications and activity metadata in the Activity Tab for audit compliance.

• Prevents duplicate creation by validating claim ID uniqueness prior to execution.

• Ensures read-only visibility — users cannot modify or resend auto-triggered notifications.

• Integrates with the Document Repository and Workflow Engine to maintain a complete digital record of event history.

7.13 Dealer Completion Documents – Step

7.13.1 Functionality Scope

The Dealer Completion Documents step provides the Dealer with the exclusive access to submit post-activity documentation and financial details after completing the approved activity. The dealer uploads the final completion documents , activity photographs , and an expense breakup reflecting actual costs incurred during execution. This step enables the dealer to record the Activity Completion Date , specify the number of participants , and upload all proofs of execution such as reports, certificates, invoices, and media files. All submitted information is used by internal stakeholders for verification and claim validation in the subsequent approval step. The system automatically calculates the Total Closed Expenses based on the entered breakup and ensures all mandatory fields and documents are provided before submission.

7.13.2 Width

• Accessible only to the Dealer after activity creation (Step 4).
• Captures the following key details: o Activity Completion Date – mandatory for marking the completion timeline. o Number of Participants (if applicable) – optional field for activity reporting. o Closed Expenses – cost heads with editable amount fields and automatic total calculation. o Completion Documents (Required) – allows upload of multiple files or a compressed ZIP folder (reports, invoices, certificates, etc.). o Activity Photos (Required) – upload images of the completed event, installation, or service activity.
• Displays computed Total Closed Expenses in real time.
• Validates that all required fields are populated before enabling submission.
• Supports multiple file formats – PDF, DOC, ZIP, JPG, PNG – with size and type validation. PDF & Images can be view on the web page, rest needs to be downloaded and reviewed.
• Submissions automatically move the workflow to the Requestor Claim Approval stage.

7.13.3 Depth

• The step becomes available only after Activity Creation (Step 4) is successfully completed.
• Dealers can enter actual expenses incurred and upload corresponding documentation for verification.
• Each uploaded document and photo is time-stamped and linked to the claim ID for traceability.
• The system automatically calculates Total Closed Expenses , and stores each cost item for audit reference.
• Prevents incomplete submissions by enforcing mandatory uploads for completion documents and photos.
• All dealer inputs and uploads are locked once submitted, ensuring no alteration during review stages.
• Sends automatic notifications to the Requestor and Department Lead once submission is completed.
• Uploaded documents are stored in the central Documents Tab , accessible to internal users for verification.
• The dealer’s submitted information becomes read-only for subsequent steps, ensuring transparency and compliance.
• The system maintains a detailed activity log , recording submission time, dealer identity, and file metadata for audit control.

7.14 Request Claim Approval

7.14.1 Functionality Scope

The Requestor Claim Approval step allows the Requestor (Initiator) to review and validate all completion documents, expenses, and evidence submitted by the Dealer in Step 5. At this stage, the requestor examines the closed expense breakup , supporting invoices, and activity completion proofs to verify that they align with the initially approved proposal and IO-blocked amount. If everything is found satisfactory, the requestor proceeds to push the claim to existing DMS , where the system automatically triggers e-Invoice generation and initiates the credit note process through SAP. In case of discrepancies or additional information requirements, the requestor can communicate directly with the dealer via WorkNotes , requesting clarifications or additional documentation before approval.

7.14.2 Width

• Accessible only to the Requestor after the dealer completes Step 5.
• Displays the following information for review: o Dealer’s completion documents , expense breakup , and activity photographs. o The Total Closed Expenses against the approved IO-blocked amount. o Remarks and attachments provided by the dealer.
• Allows the requestor to:

o Approve the claim and push it to DMS for financial processing.
o Request Clarification through WorkNotes (looping back to the dealer).
o Reject the claim, if the supporting documentation is non-compliant.

• Provides a clear action button — Push to DMS — to initiate e-Invoice and credit note processing.
• Tracks workflow status and timestamps upon approval.
• Automatically sends notifications to the Department Lead and Dealer after approval or clarification request.

7.14.3 Depth

• The step activates only when the dealer’s completion documents have been successfully submitted and verified for completeness.
• All uploaded documents and cost data are fetched dynamically from Step 5 and displayed in read-only mode for the requestor.
• The Requestor validates: o Document authenticity and completeness. o Expense consistency with the pre-approved IO budget. o Alignment between activity execution and initial plan.
• On approval: o The system executes the “Push to DMS” operation, transferring claim details and approved financials to the integrated DMS portal. o The DMS system then handles e-Invoice generation and credit note creation through SAP integration. o The workflow automatically transitions to Step 7 – e-Invoice Generation.
• If clarification is required: o The requestor uses WorkNotes to communicate directly with the dealer. o The dealer responds within the same WorkNotes thread, optionally attaching revised or missing documents. o All exchanges are time-stamped , stored in the Activity Log , and automatically linked to the claim record.
• The system restricts duplicate pushes to DMS, ensuring data consistency and transactional integrity.
• Once pushed to DMS, the claim details become read-only for the requestor and are handed over to automated processing.

7.15 e-Invoice & Credit Note – Step 7 &

7.15.1 Functionality Scope

The e-Invoice Generation step is an automated process that takes place within the DMS (Dealer Management System) after the requestor pushes the claim data from Step 6. Once the claim details reach DMS, the system automatically generates an e-Invoice based on the approved claim amount, activity, and dealer information. This process ensures complete synchronization between the Claim Management System and the DMS without requiring any manual intervention. The generated e-Invoice is then linked back to the corresponding claim record and displayed in the workflow interface for visibility. A system-triggered notification is automatically sent to all stakeholders — Dealer , Requestor , and Department Lead — confirming successful invoice generation.

7.15.2 Width

• Operates as a fully automated process triggered when the Requestor pushes the claim to DMS.
• Pushes required financial and claim details (dealer info, claim ID, IO reference, approved amount) for invoice creation.
• Automatically generates and links the e-Invoice document to the claim record.
• Provides read-only access to the e-Invoice for internal users (Requestor, Department Lead, Finance).
• Sends system notifications to: o Dealer – for invoice visibility and acknowledgment. o Requestor and Department Lead – for status tracking and confirmation.
• Displays message confirmation: “E-Invoice automatically generated from DMS.”
• Captures system timestamp, claim ID, and processing status for audit purposes.

7.15.3 Depth

• e-Invoice generation is initiated through DMS integration API based on the data pushed from Claim Management.
• System validates required parameters before invoice creation (claim ID, dealer code, amount, and approval status).
• Once created, the invoice is digitally signed and stored in DMS; only the reference and view link are available in Claim Management.
• The e-Invoice file is automatically linked to the Documents Tab for authorized users.
• Workflow status is updated to Approved , marking the successful completion of Step 7.
• Sends automated email and in-app notifications to all stakeholders.
• Ensures immutability — e-Invoice cannot be modified from the Claim Management interface.
• Automatically transitions workflow to Step 8 – Credit Note from DMS.

7.15.4 Credit Note from DMS

7.15.5 Functionality Scope

The Credit Note from DMS step is the final stage of the claim workflow, handled by the Finance Team / System Integration. After the e-Invoice is generated, the DMS automatically creates a Credit Note based on the same claim data and SAP synchronization. This credit note reflects the final reimbursement amount payable to the dealer and marks the financial closure of the claim. The generated credit note is visible in the Claim Management System, where users can view, download , or send it to the dealer. The system sends an automated notification to all stakeholders upon issuance, confirming successful claim settlement.

7.15.6 Width

• Accessible as read-only to Requestor and Dealer.
• Displays: o Credit Note Number (auto-generated from DMS). o Issue Date and Credit Note Amount. o Dealer Information – name and dealer code. o Activity and Reference Details – request ID and due date.
• Provides user actions: o Download Credit Note – saved automatically to the Documents Tab. o Send to Dealer – dispatches the credit note via email to the dealer with a PDF attachment.
• Sends system notifications to Dealer , Requestor , and Department Lead confirming completion.
• Marks the claim workflow as Closed after credit note issuance.

7.15.7 Depth

• Credit Note is automatically generated in DMS after successful e-Invoice processing and visible to download and view to Requestor & Dealer.
• The document includes unique identifiers: o Credit Note Number , Issue Date , and SAP Reference Document Number.
• Once created, the note is attached to the claim and becomes available for: o Download (PDF). o View via Documents Tab. o Automatic Email Dispatch to Dealer.
• All transmission details — including timestamps, sender, recipients, and acknowledgment — are logged in the Activity Trail.
• The credit note data is immutable within the Claim Management interface and can only be modified at the DMS/SAP source.
• After successful dispatch, the workflow automatically updates claim status to Closed , signaling process completion.
• All related documents (proposal, e-Invoice, credit note) remain stored in the Documents Repository for audit and reference.

7.16 Document Section

7.16.1 Functionality Scope

The Documents Tab functions as the central repository for all files and attachments uploaded during the claim workflow. It consolidates every document, image, and supporting file submitted by the Dealer , Requestor , or Department Lead across all workflow steps — from proposal submission to credit note generation. The tab ensures that all claim-related evidence and correspondence remain accessible in one secure location for internal review, audit, and traceability. Documents are stored chronologically with metadata such as uploader name , upload date , and file size , allowing users to identify and validate the source of each file.

7.16.2 Width

• Serves as the common document repository across all workflow stages.
• Displays: o File Name , File Type , and File Size. o Uploader Name and Timestamp.
• Allows users to: o Upload new documents (based on role permissions). o View files directly within the portal (PDF, DOC, XLS, JPG, PNG, ZIP). o Download files for offline review or record-keeping.
• Supports multi-file uploads with real-time progress indication.

7.16.3 Depth

• Acts as the single source of truth for all claim-related files, ensuring consistent visibility and auditability.
• Each upload is linked to a claim ID and tagged with workflow context (e.g., “Step 5 – Dealer Completion Documents”).
• Upload rights are role-based: o Dealer: can upload proposal and completion documents. o Requestor / Department Lead / Finance: can upload internal review or approval attachments. o Spectators: have view-only access; cannot upload or delete.
• All approved financial documents (e-Invoice and Credit Note) from DMS are auto- synced to this tab for permanent record storage.

7.17 Activity Tab...............................................................................................................

7.17.1 Functionality Scope

The Activity Tab provides a complete chronological record of all activities, approvals, and automated system actions associated with a claim request. It acts as the central audit trail , allowing stakeholders to track every event — from claim creation and document uploads to IO blocking, e-Invoice generation, and credit note issuance. This section ensures process transparency and compliance by recording who performed what action, when, and with what remarks. Each activity entry includes the event description,

timestamp, associated user, and workflow step reference, ensuring that every stage of the claim lifecycle remains verifiable and traceable.

7.17.2 Width

• Displays a timeline view of all actions related to the claim in descending order (most recent on top).
• Captures and lists: o Event Description (e.g., “Dealer Proposal Submitted,” “Step 3 Approved,” “E- Invoice Generated”). o Performer Details – name of the user or system responsible. o Date and Time Stamp for each action. o Remarks or Comments provided during approvals or clarifications.
• Logs both manual actions (by users such as Dealer, Requestor, Dept Lead, or Finance) and system-generated events (e.g., Auto Activity Creation, e-Invoice Generation).
• Automatically categorizes events with appropriate icons and color indicators for clarity (e.g., approved, submitted, or automated).
• Read-only view available to all authorized stakeholders for monitoring and review.

7.17.3 Depth

• Each workflow step automatically pushes a record to the Activity Tab when completed, approved, or auto-triggered.
• Entries include: o Action Type (Created, Approved, Submitted, Uploaded, or Auto-Generated). o Step Reference (e.g., “Step 3 – Dept Lead Approval”). o User Identity and associated role. o Timestamp (date and precise system time). o Optional Remarks or Comments captured from approval modals.
• Automated system actions (e.g., Activity Creation, e-Invoice Generation, Credit Note Sync) are tagged as System (Automated) for differentiation.
• Tracks all document submissions (including filenames and file count) linked to the Documents Tab.
• Provides immutable audit logging — entries cannot be deleted, edited, or reordered by users.

7.18 Claim Request Overview Tab

7.18.1 Functionality Scope

The Overview Tab provides a comprehensive summary view of an individual claim request, consolidating all critical details — activity, financials, dealer information, IO and DMS references, and claim progression. It allows stakeholders to quickly assess the overall claim context, including the estimated and actual expenses, requestor-dealer communication details, and key approval identifiers.

7.18.2 Width

• Displays key claim details grouped under structured sections: o Activity Information – Activity name, type, location, requested date, estimated and closed expenses, and duration/period. o Closed Expenses Breakdown – Tabular representation of actual cost heads submitted by the dealer during completion. o Description – Summary of the activity purpose or execution notes entered during initiation. o Dealer Information – Dealer code, name, contact details, and registered address. o Proposal Details – Dealer-submitted cost breakup, timeline for closure, and total estimated budget. o Request Initiator – Name, department, email, and contact of the initiator who raised the request. o Process Details – Workflow reference numbers including IO Number , DMS Number , remarks, claim amount, and system-generated identifiers. o Budget Comparison Panels – Parallel display of Estimated Budget Breakdown and Closed Expenses Breakdown for transparent financial evaluation.

• Displays total Claim Amount and allows inline edit/update (where permitted) by authorized users.

• Provides Quick Actions such as: o Add Work Note – for internal clarifications or communication. o Add Spectator – to include additional viewers without granting edit privileges. o Approve/Reject Step – visible to users assigned to the current workflow stage.

• Ensures consistent visibility of workflow reference details like IO and DMS identifiers for traceability.

7.18.3 Depth

• The Overview Tab auto-syncs data dynamically from all workflow steps (dealer submission, IO blocking, DMS updates).
• Displays live updates for: o IO Details – IO number, budget block remarks, and system timestamp. o DMS Details – DMS transaction ID and invoice generation remarks. o Claim Amount – derived from the dealer proposal but editable before DMS push (role-restricted).
• The system auto-calculates variance between Estimated and Closed Expenses for internal tracking.
• Access permissions are role-based: o Initiator & Approver: Full view and comment privileges. o Dealer: Can only view approved data relevant to their claim. o Spectator: Read-only visibility.

7.19 Notifications

The system provides real-time notifications to keep users informed about workflow activities and pending actions. Notifications appear through a bell icon in the application header with a visible count of unread alerts.

7.20 Add Work Note

The Work Notes section enables participants to communicate and collaborate directly within a workflow request , ensuring that all discussions, clarifications, and shared files remain tied to the request record. This eliminates dependency on external email threads and improves traceability.

Width:

• Displays a chronological chat-style conversation between workflow participants.
• Supports @mentions to tag users for feedback or updates.
• Allows file sharing within messages — uploaded files appear as inline attachments with download options.
• Each message displays the sender’s name, role, timestamp, and message content.
• Offers reaction options
• Includes a message composer at the bottom with: o Text box for entering messages (max 2000 characters).
• Automatically differentiates roles using colored badges (e.g., Initiator, Approver, Spectator ).

Depth:

• Messages are displayed in reverse chronological order , preserving a clear dialogue history.
• @mentions trigger system notifications to the tagged users.
• Each message is time-stamped, immutable, and stored as part of the request’s permanent record.
• Inline attachments are linked to the Documents Tab for centralized access.
• Priority tags (e.g., P – Priority ) appear inline when approvers mark messages as urgent.
• The chat interface automatically refreshes upon page load to reflect the latest messages and reactions.
• Chat data remains available throughout the workflow lifecycle and is archived upon closure.
• If there is a query at any level, user will mention it here and ask additional details.

7.21 Add Spectator

This feature allows users to add new participants as Spectators —to an ongoing workflow request. It provides flexibility for dynamically updating the workflow hierarchy or visibility list during the approval process.

Width:

• Displays a modal popup titled “Add Spectator,” depending on the selected action.
• Provides a single input field for email address entry using the @ mention convention.
• Allows users to search and add participants by email or username.
• Includes two action buttons: Confirm (Add) and Cancel.
• Spectators: Gain view-only access with the ability to comment and receive notifications.
• Both participant types receive automated notifications upon being added.

Depth:

• All additions are recorded in the activity timeline for audit and transparency.
• Notifications are sent automatically to the newly added users via the system’s alert service.
• The popup closes automatically upon successful addition, refreshing the request view to reflect the change.

7.22 Dashboard

7.22.1 Functionality Scope

The Dashboard acts as the central operational view for users to monitor and manage all claim- related activities. It provides real-time analytics and visual summaries of claims raised, in progress, approved, rejected, or pending actions, along with SLA/TAT performance. The dashboard ensures each stakeholder — whether Dealer, Initiator, or Department Lead — can quickly identify workload distribution, financial commitments, and process bottlenecks without navigating into individual requests. It also allows drill-down navigation to claim-level details, giving a unified view of claims lifecycle, IO utilization, and e-invoice/credit note status.

7.22.2 Width

The dashboard layout will include the following key widgets and metrics (customized by user role):

7.22.2.1 1. Claim Overview Widgets

• Total Claims – overall count of all claims initiated.
• In Progress – requests currently under workflow review.
• Approved Claims – successfully processed and credit-noted claims.
• Rejected Claims – declined or cancelled requests.

7.22.2.2 2. Financial Snapshot

• Total Claimed Amount – cumulative value of all claims raised.
• Total Approved Amount – value successfully processed through DMS.
• Pending IO Block Amount – total unblocked or pending IO budgets.
• Amount Under Review – sum of ongoing claims in evaluation.

7.22.2.3 4. Claims by Status / Type Visualization

• Pie or Donut Chart – distribution of claims by type (e.g., Riders Mania, Media Bike Service, Legal Claims, etc.).
• Bar Graph – monthly trend of claims raised and approved.
• Filterable by: o Date range o Activity Type o Region / Zone o Dealer Name

o Department

7.22.2.4 5. User-Specific Sections

• Dealer Dashboard: shows claim requests submitted, pending approvals, and final status with e-invoice/credit note visibility.
• Requestor Dashboard: shows all initiated claims, their progress by step, IO status, and communication log.
• Department Lead / Finance Dashboard: includes IO utilization summary, approval queue, and high-value claim alerts.

7.22.2.5 6. Quick Action Panel

• Create New Claim Request
• View My Requests
• Download Reports (Excel / PDF)
• Pending Actions / Approvals
• Notifications & Alerts (SLA reminders, claim updates, DMS sync alerts)

7.22.3 Available Filters

• Date Range: Filter claims based on creation date, approval date, or completion period (e.g., Current Month, Last Quarter, Custom Range).

• Claim Status: View claims by workflow status — Draft, In Progress, Approved, Rejected, Closed, or Awaiting IO Block.

• Activity Type: Narrow down data by specific claim types such as: o Riders Mania Claims o Marketing Cost – Bike to Vendor o Media Bike Service o ARAI Certification / Liquidation o Service Camp Claims o Corporate / Institutional PDI Claims (Configurable by Admin)

• Dealer / Dealer Code: Filter data for specific dealer(s) or dealer codes to analyze claim submissions, performance, or payment status.

• Department / Region / Zone: For internal users, enables filtering claims by business unit, region, or reporting hierarchy.

• Claim Amount Range: Allows entry of minimum and maximum claim value to analyze financial exposure.

• IO Number / Budget Reference: Enables internal users to view claims linked to a specific IO for reconciliation and audit tracking.

• Requestor / Initiator Name: Filters claims created or managed by a particular initiator.

• SLA Status: Highlights claims approaching or breaching SLA/TAT timelines — categorized as Within SLA , At Risk , or Breached.

• Claim Template / Workflow Type: Helps Admins or Leads distinguish between standard and special claim workflows or templates.

7.22.4 Depth

• Dashboard data auto-refreshes based on system events and workflow changes.
• All summary numbers and visuals are role-driven , ensuring each user only sees authorized data.
• Integrates with SLA Engine to highlight any step or claim breaching defined time limits.
• Clicking any metric drills down to filtered claim lists with pagination and quick search.
• Metrics are fetched in real-time from the workflow database and DMS sync logs for accurate financial reporting.
• The dashboard honors user permissions: o Dealers: can view only their own claims. o Internal users: can view claims by department, zone, or entire region.

8 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.

9 Technology Matrix

Component Specification
Database PGSQL (Managed or local instance)
Application Stack Node.js (Backend) + React.js (Frontend)
Authentication RE SSO Bridge

10 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.

11 Not in scope

Anything which comes beyond the scope defined above in terms of Width and depth