laxmanhalaki/Re_Figma_Code
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
ca936cc8d8
Re_Figma_Code/Dealer_Claim_Managment.md

1278 lines
62 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# 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
Reference in New Issue View Git Blame Copy Permalink