first commit mermaid files and project flow added
This commit is contained in:
yashwin-foxy
commit
bf8ea82b08
631
Mermaid_Selector.html
Normal file
631
Mermaid_Selector.html
Normal file
@ -0,0 +1,631 @@
|
||||
<!DOCTYPE html>
|
||||
<html lang="en">
|
||||
<head>
|
||||
<meta charset="UTF-8">
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
<title>Mermaid Diagram Viewer</title>
|
||||
<script src="https://cdnjs.cloudflare.com/ajax/libs/mermaid/10.6.1/mermaid.min.js"></script>
|
||||
<style>
|
||||
* {
|
||||
margin: 0;
|
||||
padding: 0;
|
||||
box-sizing: border-box;
|
||||
}
|
||||
|
||||
body {
|
||||
font-family: 'Segoe UI', Tahoma, Geneva, Verdana, sans-serif;
|
||||
background: linear-gradient(135deg, #667eea 0%, #764ba2 100%);
|
||||
min-height: 100vh;
|
||||
padding: 20px;
|
||||
color: #333;
|
||||
}
|
||||
|
||||
.container {
|
||||
max-width: 1400px;
|
||||
margin: 0 auto;
|
||||
background: white;
|
||||
border-radius: 20px;
|
||||
box-shadow: 0 20px 60px rgba(0, 0, 0, 0.3);
|
||||
overflow: hidden;
|
||||
}
|
||||
|
||||
.header {
|
||||
background: linear-gradient(135deg, #667eea 0%, #764ba2 100%);
|
||||
padding: 30px;
|
||||
text-align: center;
|
||||
color: white;
|
||||
}
|
||||
|
||||
.header h1 {
|
||||
font-size: 2.5em;
|
||||
margin-bottom: 10px;
|
||||
font-weight: 600;
|
||||
}
|
||||
|
||||
.header p {
|
||||
font-size: 1.1em;
|
||||
opacity: 0.9;
|
||||
}
|
||||
|
||||
.content {
|
||||
display: grid;
|
||||
grid-template-columns: 400px 1fr;
|
||||
gap: 30px;
|
||||
padding: 30px;
|
||||
}
|
||||
|
||||
.panel {
|
||||
background: #f8f9fa;
|
||||
border-radius: 15px;
|
||||
padding: 25px;
|
||||
box-shadow: 0 4px 6px rgba(0, 0, 0, 0.1);
|
||||
}
|
||||
|
||||
.panel h2 {
|
||||
color: #667eea;
|
||||
margin-bottom: 20px;
|
||||
font-size: 1.5em;
|
||||
display: flex;
|
||||
align-items: center;
|
||||
gap: 10px;
|
||||
}
|
||||
|
||||
.tabs {
|
||||
display: flex;
|
||||
gap: 10px;
|
||||
margin-bottom: 20px;
|
||||
}
|
||||
|
||||
.tab-btn {
|
||||
flex: 1;
|
||||
padding: 12px 20px;
|
||||
border: none;
|
||||
background: white;
|
||||
color: #667eea;
|
||||
border-radius: 10px;
|
||||
cursor: pointer;
|
||||
font-size: 1em;
|
||||
font-weight: 600;
|
||||
transition: all 0.3s ease;
|
||||
box-shadow: 0 2px 4px rgba(0, 0, 0, 0.1);
|
||||
}
|
||||
|
||||
.tab-btn:hover {
|
||||
transform: translateY(-2px);
|
||||
box-shadow: 0 4px 8px rgba(0, 0, 0, 0.15);
|
||||
}
|
||||
|
||||
.tab-btn.active {
|
||||
background: linear-gradient(135deg, #667eea 0%, #764ba2 100%);
|
||||
color: white;
|
||||
}
|
||||
|
||||
.tab-content {
|
||||
display: none;
|
||||
}
|
||||
|
||||
.tab-content.active {
|
||||
display: block;
|
||||
}
|
||||
|
||||
.upload-area {
|
||||
border: 3px dashed #667eea;
|
||||
border-radius: 15px;
|
||||
padding: 40px;
|
||||
text-align: center;
|
||||
cursor: pointer;
|
||||
transition: all 0.3s ease;
|
||||
background: white;
|
||||
}
|
||||
|
||||
.upload-area:hover {
|
||||
border-color: #764ba2;
|
||||
background: #f0f4ff;
|
||||
}
|
||||
|
||||
.upload-area.dragover {
|
||||
border-color: #764ba2;
|
||||
background: #e8ecff;
|
||||
transform: scale(1.02);
|
||||
}
|
||||
|
||||
.upload-icon {
|
||||
font-size: 3em;
|
||||
margin-bottom: 15px;
|
||||
color: #667eea;
|
||||
}
|
||||
|
||||
.upload-area p {
|
||||
color: #666;
|
||||
font-size: 1.1em;
|
||||
}
|
||||
|
||||
#fileInput {
|
||||
display: none;
|
||||
}
|
||||
|
||||
textarea {
|
||||
width: 100%;
|
||||
min-height: 300px;
|
||||
padding: 15px;
|
||||
border: 2px solid #e0e0e0;
|
||||
border-radius: 10px;
|
||||
font-family: 'Courier New', monospace;
|
||||
font-size: 0.95em;
|
||||
resize: vertical;
|
||||
transition: border-color 0.3s ease;
|
||||
background: white;
|
||||
}
|
||||
|
||||
textarea:focus {
|
||||
outline: none;
|
||||
border-color: #667eea;
|
||||
}
|
||||
|
||||
.btn {
|
||||
width: 100%;
|
||||
padding: 15px;
|
||||
margin-top: 15px;
|
||||
border: none;
|
||||
background: linear-gradient(135deg, #667eea 0%, #764ba2 100%);
|
||||
color: white;
|
||||
border-radius: 10px;
|
||||
font-size: 1.1em;
|
||||
font-weight: 600;
|
||||
cursor: pointer;
|
||||
transition: all 0.3s ease;
|
||||
box-shadow: 0 4px 15px rgba(102, 126, 234, 0.4);
|
||||
}
|
||||
|
||||
.btn:hover {
|
||||
transform: translateY(-2px);
|
||||
box-shadow: 0 6px 20px rgba(102, 126, 234, 0.6);
|
||||
}
|
||||
|
||||
.btn:active {
|
||||
transform: translateY(0);
|
||||
}
|
||||
|
||||
#diagramOutput {
|
||||
background: white;
|
||||
border-radius: 10px;
|
||||
padding: 20px;
|
||||
min-height: 400px;
|
||||
display: flex;
|
||||
align-items: center;
|
||||
justify-content: center;
|
||||
overflow: hidden;
|
||||
position: relative;
|
||||
cursor: grab;
|
||||
}
|
||||
|
||||
#diagramOutput.grabbing {
|
||||
cursor: grabbing;
|
||||
}
|
||||
|
||||
#diagramOutput svg {
|
||||
transition: transform 0.2s ease;
|
||||
}
|
||||
|
||||
#diagramWrapper {
|
||||
display: flex;
|
||||
align-items: center;
|
||||
justify-content: center;
|
||||
width: 100%;
|
||||
height: 100%;
|
||||
}
|
||||
|
||||
.zoom-controls {
|
||||
position: absolute;
|
||||
top: 20px;
|
||||
right: 20px;
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
gap: 10px;
|
||||
z-index: 100;
|
||||
}
|
||||
|
||||
.zoom-btn {
|
||||
width: 45px;
|
||||
height: 45px;
|
||||
border: none;
|
||||
background: linear-gradient(135deg, #667eea 0%, #764ba2 100%);
|
||||
color: white;
|
||||
border-radius: 10px;
|
||||
font-size: 1.5em;
|
||||
font-weight: bold;
|
||||
cursor: pointer;
|
||||
transition: all 0.3s ease;
|
||||
box-shadow: 0 4px 15px rgba(102, 126, 234, 0.4);
|
||||
display: flex;
|
||||
align-items: center;
|
||||
justify-content: center;
|
||||
}
|
||||
|
||||
.zoom-btn:hover {
|
||||
transform: scale(1.1);
|
||||
box-shadow: 0 6px 20px rgba(102, 126, 234, 0.6);
|
||||
}
|
||||
|
||||
.zoom-btn:active {
|
||||
transform: scale(0.95);
|
||||
}
|
||||
|
||||
.zoom-level {
|
||||
background: rgba(102, 126, 234, 0.9);
|
||||
color: white;
|
||||
padding: 8px 12px;
|
||||
border-radius: 8px;
|
||||
font-size: 0.9em;
|
||||
font-weight: 600;
|
||||
text-align: center;
|
||||
box-shadow: 0 4px 15px rgba(102, 126, 234, 0.4);
|
||||
}
|
||||
|
||||
.placeholder {
|
||||
text-align: center;
|
||||
color: #999;
|
||||
font-size: 1.2em;
|
||||
}
|
||||
|
||||
.placeholder-icon {
|
||||
font-size: 4em;
|
||||
margin-bottom: 15px;
|
||||
opacity: 0.3;
|
||||
}
|
||||
|
||||
.error {
|
||||
background: #fee;
|
||||
border: 2px solid #fcc;
|
||||
color: #c33;
|
||||
padding: 15px;
|
||||
border-radius: 10px;
|
||||
margin-top: 15px;
|
||||
}
|
||||
|
||||
.success {
|
||||
background: #efe;
|
||||
border: 2px solid #cfc;
|
||||
color: #3c3;
|
||||
padding: 15px;
|
||||
border-radius: 10px;
|
||||
margin-top: 15px;
|
||||
}
|
||||
|
||||
@media (max-width: 968px) {
|
||||
.content {
|
||||
grid-template-columns: 1fr;
|
||||
}
|
||||
}
|
||||
</style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="container">
|
||||
<div class="header">
|
||||
<h1>🎨 Mermaid Diagram Viewer</h1>
|
||||
<p>Upload a file or paste your Mermaid code to visualize beautiful diagrams</p>
|
||||
</div>
|
||||
|
||||
<div class="content">
|
||||
<div class="panel">
|
||||
<h2>📝 Input</h2>
|
||||
|
||||
<div class="tabs">
|
||||
<button class="tab-btn active" onclick="switchTab('paste')">Paste Code</button>
|
||||
<button class="tab-btn" onclick="switchTab('upload')">Upload File</button>
|
||||
</div>
|
||||
|
||||
<div id="pasteTab" class="tab-content active">
|
||||
<textarea id="mermaidCode" placeholder="Paste your Mermaid diagram code here...
|
||||
|
||||
Example:
|
||||
graph TD
|
||||
A[Start] --> B{Decision}
|
||||
B -->|Yes| C[Option 1]
|
||||
B -->|No| D[Option 2]
|
||||
C --> E[End]
|
||||
D --> E"></textarea>
|
||||
<button class="btn" onclick="renderFromTextarea()">🎨 Render Diagram</button>
|
||||
</div>
|
||||
|
||||
<div id="uploadTab" class="tab-content">
|
||||
<div class="upload-area" id="uploadArea" onclick="document.getElementById('fileInput').click()">
|
||||
<div class="upload-icon">📁</div>
|
||||
<p><strong>Click to upload</strong> or drag and drop</p>
|
||||
<p style="font-size: 0.9em; margin-top: 10px; opacity: 0.7;">Supports .mmd, .mermaid, .txt files</p>
|
||||
</div>
|
||||
<input type="file" id="fileInput" accept=".mmd,.mermaid,.txt" onchange="handleFile(event)">
|
||||
</div>
|
||||
|
||||
<div id="message"></div>
|
||||
</div>
|
||||
|
||||
<div class="panel">
|
||||
<h2>🖼️ Preview</h2>
|
||||
<div id="diagramOutput">
|
||||
<div class="placeholder">
|
||||
<div class="placeholder-icon">📊</div>
|
||||
<p>Your diagram will appear here</p>
|
||||
</div>
|
||||
<div class="zoom-controls" id="zoomControls" style="display: none;">
|
||||
<button class="zoom-btn" onclick="zoomIn()" title="Zoom In">+</button>
|
||||
<div class="zoom-level" id="zoomLevel">100%</div>
|
||||
<button class="zoom-btn" onclick="zoomOut()" title="Zoom Out">−</button>
|
||||
<button class="zoom-btn" onclick="resetZoom()" title="Reset Zoom" style="font-size: 1.2em;">⟲</button>
|
||||
<button class="zoom-btn" onclick="fitToScreen()" title="Fit to Screen" style="font-size: 1.2em;">⛶</button>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<script>
|
||||
mermaid.initialize({
|
||||
startOnLoad: false,
|
||||
theme: 'default',
|
||||
securityLevel: 'loose'
|
||||
});
|
||||
|
||||
let currentTab = 'paste';
|
||||
let diagramCounter = 0;
|
||||
let zoomScale = 1;
|
||||
let panX = 0;
|
||||
let panY = 0;
|
||||
let isDragging = false;
|
||||
let startX = 0;
|
||||
let startY = 0;
|
||||
let panAndZoomSetup = false;
|
||||
|
||||
function switchTab(tab) {
|
||||
currentTab = tab;
|
||||
document.querySelectorAll('.tab-btn').forEach(btn => btn.classList.remove('active'));
|
||||
document.querySelectorAll('.tab-content').forEach(content => content.classList.remove('active'));
|
||||
|
||||
if (tab === 'paste') {
|
||||
document.querySelector('.tab-btn:first-child').classList.add('active');
|
||||
document.getElementById('pasteTab').classList.add('active');
|
||||
} else {
|
||||
document.querySelector('.tab-btn:last-child').classList.add('active');
|
||||
document.getElementById('uploadTab').classList.add('active');
|
||||
}
|
||||
}
|
||||
|
||||
function showMessage(message, type) {
|
||||
const messageDiv = document.getElementById('message');
|
||||
messageDiv.innerHTML = `<div class="${type}">${message}</div>`;
|
||||
setTimeout(() => {
|
||||
messageDiv.innerHTML = '';
|
||||
}, 5000);
|
||||
}
|
||||
|
||||
function renderDiagram(code) {
|
||||
const output = document.getElementById('diagramOutput');
|
||||
|
||||
if (!code.trim()) {
|
||||
showMessage('Please provide Mermaid code', 'error');
|
||||
return;
|
||||
}
|
||||
|
||||
diagramCounter++;
|
||||
const graphId = 'mermaid-graph-' + diagramCounter;
|
||||
|
||||
// Create a wrapper for the diagram
|
||||
const diagramWrapper = document.createElement('div');
|
||||
diagramWrapper.id = 'diagramWrapper';
|
||||
diagramWrapper.innerHTML = `<div id="${graphId}"></div>`;
|
||||
|
||||
// Clear output but keep zoom controls
|
||||
const zoomControls = document.getElementById('zoomControls');
|
||||
output.innerHTML = '';
|
||||
output.appendChild(diagramWrapper);
|
||||
output.appendChild(zoomControls);
|
||||
|
||||
try {
|
||||
mermaid.render(graphId, code).then(result => {
|
||||
diagramWrapper.innerHTML = result.svg;
|
||||
|
||||
// Wait a bit for DOM to update
|
||||
setTimeout(() => {
|
||||
resetZoom();
|
||||
zoomControls.style.display = 'flex';
|
||||
if (!panAndZoomSetup) {
|
||||
setupPanAndZoom();
|
||||
panAndZoomSetup = true;
|
||||
}
|
||||
showMessage('✅ Diagram rendered successfully!', 'success');
|
||||
}, 100);
|
||||
}).catch(error => {
|
||||
diagramWrapper.innerHTML = '<div class="placeholder"><div class="placeholder-icon">❌</div><p>Failed to render diagram</p></div>';
|
||||
zoomControls.style.display = 'none';
|
||||
showMessage('❌ Error: ' + error.message, 'error');
|
||||
});
|
||||
} catch (error) {
|
||||
diagramWrapper.innerHTML = '<div class="placeholder"><div class="placeholder-icon">❌</div><p>Failed to render diagram</p></div>';
|
||||
zoomControls.style.display = 'none';
|
||||
showMessage('❌ Error: ' + error.message, 'error');
|
||||
}
|
||||
}
|
||||
|
||||
function updateTransform() {
|
||||
const output = document.getElementById('diagramOutput');
|
||||
const svg = output.querySelector('svg');
|
||||
if (svg) {
|
||||
svg.style.transform = `translate(${panX}px, ${panY}px) scale(${zoomScale})`;
|
||||
document.getElementById('zoomLevel').textContent = Math.round(zoomScale * 100) + '%';
|
||||
}
|
||||
}
|
||||
|
||||
function zoomIn() {
|
||||
zoomScale = Math.min(zoomScale + 0.2, 10);
|
||||
updateTransform();
|
||||
}
|
||||
|
||||
function zoomOut() {
|
||||
zoomScale = Math.max(zoomScale - 0.2, 0.2);
|
||||
updateTransform();
|
||||
}
|
||||
|
||||
function resetZoom() {
|
||||
zoomScale = 1;
|
||||
panX = 0;
|
||||
panY = 0;
|
||||
updateTransform();
|
||||
}
|
||||
|
||||
function fitToScreen() {
|
||||
const output = document.getElementById('diagramOutput');
|
||||
if (!output) return;
|
||||
|
||||
const svg = output.querySelector('svg');
|
||||
if (!svg) return;
|
||||
|
||||
try {
|
||||
const outputRect = output.getBoundingClientRect();
|
||||
const svgRect = svg.getBBox();
|
||||
|
||||
if (svgRect.width === 0 || svgRect.height === 0) return;
|
||||
|
||||
const scaleX = (outputRect.width - 40) / svgRect.width;
|
||||
const scaleY = (outputRect.height - 40) / svgRect.height;
|
||||
|
||||
zoomScale = Math.min(scaleX, scaleY, 1);
|
||||
panX = 0;
|
||||
panY = 0;
|
||||
updateTransform();
|
||||
} catch (error) {
|
||||
console.warn('Could not fit to screen:', error);
|
||||
}
|
||||
}
|
||||
|
||||
function setupPanAndZoom() {
|
||||
const output = document.getElementById('diagramOutput');
|
||||
if (!output) return;
|
||||
|
||||
// Mouse wheel zoom
|
||||
const handleWheel = (e) => {
|
||||
e.preventDefault();
|
||||
const delta = e.deltaY > 0 ? -0.1 : 0.1;
|
||||
zoomScale = Math.max(0.2, Math.min(10, zoomScale + delta));
|
||||
updateTransform();
|
||||
};
|
||||
output.addEventListener('wheel', handleWheel, { passive: false });
|
||||
|
||||
// Pan functionality
|
||||
const handleMouseDown = (e) => {
|
||||
if (e.target.closest('.zoom-controls')) return;
|
||||
isDragging = true;
|
||||
startX = e.clientX - panX;
|
||||
startY = e.clientY - panY;
|
||||
output.classList.add('grabbing');
|
||||
};
|
||||
output.addEventListener('mousedown', handleMouseDown);
|
||||
|
||||
const handleMouseMove = (e) => {
|
||||
if (!isDragging) return;
|
||||
panX = e.clientX - startX;
|
||||
panY = e.clientY - startY;
|
||||
updateTransform();
|
||||
};
|
||||
document.addEventListener('mousemove', handleMouseMove);
|
||||
|
||||
const handleMouseUp = () => {
|
||||
isDragging = false;
|
||||
output.classList.remove('grabbing');
|
||||
};
|
||||
document.addEventListener('mouseup', handleMouseUp);
|
||||
|
||||
// Touch support for mobile
|
||||
let touchStartX = 0, touchStartY = 0;
|
||||
let touchStartDistance = 0;
|
||||
let initialScale = 1;
|
||||
|
||||
const handleTouchStart = (e) => {
|
||||
if (e.touches.length === 1) {
|
||||
touchStartX = e.touches[0].clientX - panX;
|
||||
touchStartY = e.touches[0].clientY - panY;
|
||||
} else if (e.touches.length === 2) {
|
||||
touchStartDistance = Math.hypot(
|
||||
e.touches[0].clientX - e.touches[1].clientX,
|
||||
e.touches[0].clientY - e.touches[1].clientY
|
||||
);
|
||||
initialScale = zoomScale;
|
||||
}
|
||||
};
|
||||
output.addEventListener('touchstart', handleTouchStart);
|
||||
|
||||
const handleTouchMove = (e) => {
|
||||
e.preventDefault();
|
||||
if (e.touches.length === 1) {
|
||||
panX = e.touches[0].clientX - touchStartX;
|
||||
panY = e.touches[0].clientY - touchStartY;
|
||||
updateTransform();
|
||||
} else if (e.touches.length === 2) {
|
||||
const distance = Math.hypot(
|
||||
e.touches[0].clientX - e.touches[1].clientX,
|
||||
e.touches[0].clientY - e.touches[1].clientY
|
||||
);
|
||||
zoomScale = Math.max(0.2, Math.min(10, initialScale * (distance / touchStartDistance)));
|
||||
updateTransform();
|
||||
}
|
||||
};
|
||||
output.addEventListener('touchmove', handleTouchMove, { passive: false });
|
||||
}
|
||||
|
||||
function renderFromTextarea() {
|
||||
const code = document.getElementById('mermaidCode').value;
|
||||
renderDiagram(code);
|
||||
}
|
||||
|
||||
function handleFile(event) {
|
||||
const file = event.target.files[0];
|
||||
if (!file) return;
|
||||
|
||||
const reader = new FileReader();
|
||||
reader.onload = function(e) {
|
||||
const content = e.target.result;
|
||||
document.getElementById('mermaidCode').value = content;
|
||||
renderDiagram(content);
|
||||
showMessage('✅ File loaded: ' + file.name, 'success');
|
||||
};
|
||||
reader.onerror = function() {
|
||||
showMessage('❌ Error reading file', 'error');
|
||||
};
|
||||
reader.readAsText(file);
|
||||
}
|
||||
|
||||
const uploadArea = document.getElementById('uploadArea');
|
||||
|
||||
uploadArea.addEventListener('dragover', (e) => {
|
||||
e.preventDefault();
|
||||
uploadArea.classList.add('dragover');
|
||||
});
|
||||
|
||||
uploadArea.addEventListener('dragleave', () => {
|
||||
uploadArea.classList.remove('dragover');
|
||||
});
|
||||
|
||||
uploadArea.addEventListener('drop', (e) => {
|
||||
e.preventDefault();
|
||||
uploadArea.classList.remove('dragover');
|
||||
|
||||
const file = e.dataTransfer.files[0];
|
||||
if (file) {
|
||||
const reader = new FileReader();
|
||||
reader.onload = function(event) {
|
||||
const content = event.target.result;
|
||||
document.getElementById('mermaidCode').value = content;
|
||||
renderDiagram(content);
|
||||
showMessage('✅ File loaded: ' + file.name, 'success');
|
||||
};
|
||||
reader.readAsText(file);
|
||||
}
|
||||
});
|
||||
|
||||
document.getElementById('mermaidCode').addEventListener('keydown', function(e) {
|
||||
if (e.ctrlKey && e.key === 'Enter') {
|
||||
renderFromTextarea();
|
||||
}
|
||||
});
|
||||
</script>
|
||||
</body>
|
||||
</html>
|
||||
Binary file not shown.
758
RE Dealer onboarding preliminary Syastem.md
Normal file
758
RE Dealer onboarding preliminary Syastem.md
Normal file
@ -0,0 +1,758 @@
|
||||
RE Workflow Solutions
|
||||
Preliminary System Design, Security & Technical
|
||||
Document
|
||||
Preliminary Approach & Solution Analysis Document
|
||||
25 - August- 2025
|
||||
Version 1. 0
|
||||
Contents
|
||||
1 Objective
|
||||
2 Problem Statement
|
||||
3 System Requirements
|
||||
3.1 Functional Requirements
|
||||
3.2 Non-Functional Requirements
|
||||
4 Bird Eye View
|
||||
5 System Design
|
||||
6 System Design Explanation
|
||||
6.1 User Authentication & Access Flow
|
||||
6.1.1 Step-by-Step Authentication Flow
|
||||
6.2 API Driven Framework
|
||||
6.3 Frontend Layer (React.js)
|
||||
6.4 Backend Service (Node.js)
|
||||
6.5 Data Handling & Storage
|
||||
7 Scalability & Performance
|
||||
8 DPDP Act Compliance
|
||||
9 Security Requirements and Technical Implementation
|
||||
9.1 Input Validation and Sanitization
|
||||
9.2 Secure File Handling
|
||||
9.3 DDoS and API Rate Limiting
|
||||
10 Monitoring & Maintenance
|
||||
11 Camunda Support
|
||||
1 Objective
|
||||
Automate the Dealer Development process to streamline prospect applications, vacancy checks,
|
||||
approvals, and LOI issuance. Enhance efficiency and scalability for 1,000 users, ensuring a
|
||||
seamless dealer onboarding experience. Maintain DPDP compliance with secure, reliable
|
||||
processes, reducing manual effort and improving decision-making for stakeholders.
|
||||
|
||||
Additionally, the review and approval process differs from scenario to scenario, so the system
|
||||
should be dynamically capable enough to cater this need.
|
||||
|
||||
2 Problem Statement
|
||||
The absence of a Dealer Development automation system creates significant challenges in
|
||||
managing the dealer onboarding process efficiently and securely. Currently, manual processes
|
||||
for handling prospect applications, vacancy checks, approvals, and LOI issuance are time-
|
||||
consuming, error-prone, and lack scalability.
|
||||
|
||||
This leads to delays in processing applications, inconsistent data handling, and difficulties in
|
||||
generating timely reports, such as daily web lead summaries and location-wise details.
|
||||
Additionally, the lack of automated security measures increases the security risk of non-
|
||||
compliance with Digital Personal Data Protection (DPDP) regulations, particularly for sensitive
|
||||
prospect data. Without a centralized system, stakeholder coordination (DD Lead, RBM, ZBH,
|
||||
NBH) is fragmented, hindering decision-making and impacting the overall dealer onboarding
|
||||
experience.
|
||||
|
||||
3 System Requirements
|
||||
3.1 Functional Requirements
|
||||
Dealer Onboarding Workflow
|
||||
Capture enquiries via form, validate against opportunity list.
|
||||
Automated emails, reminders, scoring, and top-candidate shortlisting.
|
||||
Multi-level approvals (ASM → ZM → RBM → ZBH → NBH).
|
||||
Profile sheet submission, KT evaluations, and final LOI issuance.
|
||||
Custom Approval Workflows: Admin can configure different approval chains
|
||||
depending on region size (e.g., simpler workflows for smaller regions, extended
|
||||
hierarchies for larger regions).
|
||||
Dealer Exit Workflow
|
||||
Resignation: Letter submission, ASM template, approvals (ZBH → DD Lead → NBH),
|
||||
legal concurrence, dealer acknowledgment.
|
||||
Termination: Record reasons, prepare docs, legal show-cause notice (15-day timer),
|
||||
approvals (ZBH → DD Lead → NBH → CCO → CEO), final termination letter.
|
||||
Full & Final Settlement: Coordinate with stakeholders, reconcile dues, block
|
||||
SAP/MSD codes, Finance AR calculates F&F, dealer acceptance or legal escalation.
|
||||
Automation
|
||||
Automated notifications (acknowledgments, reminders, approvals, LOI, F&F).
|
||||
SLA-driven reminders (Day 2, Day 5, 15-day cutoffs).
|
||||
Reminders can be customized in terms of duration frequency vs levels.
|
||||
Reporting
|
||||
Every user can login and view the Dashboard & quick reports
|
||||
Access Control
|
||||
Role-based access for Admin, ASM, ZM, RBM, ZBH, NBH, CCO.
|
||||
Regional scoping and complete audit logs.
|
||||
3.2 Non-Functional Requirements
|
||||
Scalability : Support 1 0 ,000 total users and 200 concurrent users.
|
||||
Performance : Achieve <2s latency for most operations during peak hours (9 AM–5 PM
|
||||
IST).
|
||||
Availability : Ensure 99.9% uptime.
|
||||
Security : Comply with DPDP Act, 2023, with encryption and RBAC.
|
||||
Reliability : Maintain data consistency and fault tolerance across workflows.
|
||||
4 Bird Eye View
|
||||
|
||||
The Bird Eye View provides a high-level architectural overview of the RE Workflow Application, illustrating the key components, user interactions, and data flow patterns that form the foundation of the entire system.
|
||||
|
||||
## 4.1 System Architecture Overview
|
||||
|
||||
The RE Workflow App follows a centralized, secure, and scalable architecture designed to serve multiple user roles while maintaining strict security protocols and efficient data management.
|
||||
|
||||
### 4.1.1 User Ecosystem
|
||||
The system serves a diverse range of stakeholders across the Royal Enfield dealer development hierarchy:
|
||||
|
||||
**Primary User Roles:**
|
||||
- **Super Admin**: System administrators with full access and configuration rights
|
||||
- **ASM (Area Sales Manager)**: Regional sales management and dealer oversight
|
||||
- **ZM (Zone Manager)**: Zone-level management and approval authority
|
||||
- **RBM (Regional Business Manager)**: Regional business strategy and decision-making
|
||||
- **DD (Dealer Development)**: Dealer development specialists and coordinators
|
||||
- **NBH (National Business Head)**: Strategic oversight and final approvals
|
||||
- **Finance**: Financial approval and settlement processing
|
||||
|
||||
### 4.1.2 Authentication & Authorization Flow
|
||||
|
||||
**RE Bridge Centralised SSO Integration**
|
||||
- Single Sign-On (SSO) authentication through Royal Enfield's centralized identity management system
|
||||
- Seamless integration with existing corporate Active Directory infrastructure
|
||||
- Role-based access control (RBAC) ensuring users access only authorized functions
|
||||
- Session management with automatic timeout and security token refresh
|
||||
|
||||
**Authentication Process:**
|
||||
1. User initiates login through RE Bridge Centralised SSO
|
||||
2. Credentials validated against corporate Active Directory
|
||||
3. Role-based permissions assigned and validated
|
||||
4. Secure session established with appropriate access levels
|
||||
5. User redirected to RE Workflow App with authenticated access
|
||||
|
||||
## 4.2 Core System Components
|
||||
|
||||
### 4.2.1 Security Layer
|
||||
The security layer serves as the primary gatekeeper for all system access:
|
||||
|
||||
**Security Functions:**
|
||||
- **Authentication Verification**: Validates user credentials and session tokens
|
||||
- **Authorization Control**: Enforces role-based access permissions
|
||||
- **Session Management**: Maintains secure user sessions with timeout controls
|
||||
- **Audit Logging**: Records all access attempts and security events
|
||||
- **Data Protection**: Ensures compliance with DPDP Act requirements
|
||||
|
||||
**Security Protocols:**
|
||||
- TLS 1.3 encryption for all data transmission
|
||||
- Multi-factor authentication for sensitive operations
|
||||
- Regular security token rotation and validation
|
||||
- Comprehensive audit trails for compliance reporting
|
||||
|
||||
### 4.2.2 Core Business & Services Modules
|
||||
The heart of the application where all business logic and workflow processing occurs:
|
||||
|
||||
**Primary Modules:**
|
||||
- **Dealer Onboarding Management**: Complete lifecycle management from application to LOI issuance
|
||||
- **Custom Workflow Engine**: Dynamic workflow configuration and execution
|
||||
- **Dealer Resignation Processing**: Structured resignation and termination workflows
|
||||
- **Full & Final Settlement**: Financial settlement calculation and processing
|
||||
- **Dashboard & Analytics**: Real-time reporting and performance metrics
|
||||
- **Document Management**: Secure document storage, retrieval, and version control
|
||||
|
||||
**Business Process Integration:**
|
||||
- Automated workflow orchestration
|
||||
- Multi-level approval chain management
|
||||
- SLA tracking and enforcement
|
||||
- Real-time status updates and notifications
|
||||
- Integration with external systems (SAP, DMS, Email)
|
||||
|
||||
### 4.2.3 Database Layer (PostgreSQL)
|
||||
|
||||
**Primary Database Functions:**
|
||||
- **Transactional Data Storage**: ACID-compliant data persistence for all business operations
|
||||
- **User Management**: User profiles, roles, and permission storage
|
||||
- **Workflow State Management**: Process instance tracking and state persistence
|
||||
- **Document Metadata**: File references and metadata storage
|
||||
- **Audit Trail Storage**: Comprehensive logging of all system activities
|
||||
|
||||
**Database Architecture:**
|
||||
- **Primary Instance**: Handles all write operations and critical transactions
|
||||
- **Read Replica**: Optimizes reporting and analytics queries
|
||||
- **Backup & Recovery**: Automated backup with point-in-time recovery capability
|
||||
- **Performance Optimization**: Query optimization and indexing strategies
|
||||
|
||||
### 4.2.4 Supporting Services
|
||||
|
||||
**Monitoring Services:**
|
||||
- **System Health Monitoring**: Real-time system performance tracking
|
||||
- **Business Metrics Tracking**: KPI monitoring and alerting
|
||||
- **Capacity Planning**: Resource utilization monitoring and forecasting
|
||||
- **SLA Compliance**: Service level agreement monitoring and reporting
|
||||
|
||||
**Logging Services:**
|
||||
- **Application Logging**: Comprehensive application event logging
|
||||
- **Security Logging**: Authentication, authorization, and security event logging
|
||||
- **Performance Logging**: System performance and bottleneck identification
|
||||
- **Compliance Logging**: DPDP Act compliance and audit trail maintenance
|
||||
|
||||
### 4.2.5 Cloud Storage Integration
|
||||
|
||||
**Storage Functions:**
|
||||
- **Document Archive**: Secure storage for all business documents and files
|
||||
- **Backup Storage**: Automated backup storage for disaster recovery
|
||||
- **Media Storage**: Image and document storage for dealer applications
|
||||
- **Compliance Storage**: Long-term storage for audit and compliance records
|
||||
|
||||
**Storage Features:**
|
||||
- **Encryption at Rest**: AES-256 encryption for all stored data
|
||||
- **Access Control**: Role-based access to stored documents
|
||||
- **Version Control**: Document versioning and change tracking
|
||||
- **Retention Policies**: Automated data retention and archival policies
|
||||
|
||||
## 4.3 Data Flow Architecture
|
||||
|
||||
### 4.3.1 User Interaction Flow
|
||||
1. **Authentication**: User → RE Bridge Centralised SSO → Security Layer
|
||||
2. **Authorization**: Security Layer validates permissions and grants access
|
||||
3. **Business Processing**: User interacts with Core Business & Services Modules
|
||||
4. **Data Operations**: Business modules interact with PostgreSQL Database
|
||||
5. **Document Management**: File operations handled through Cloud Storage
|
||||
6. **Monitoring & Logging**: All activities logged and monitored continuously
|
||||
|
||||
### 4.3.2 System Integration Flow
|
||||
1. **External System Integration**: SAP, DMS, and third-party system connectivity
|
||||
2. **Data Synchronization**: Real-time data sync between systems
|
||||
3. **Notification Delivery**: Email, SMS, and push notification processing
|
||||
4. **Report Generation**: Automated report creation and distribution
|
||||
5. **Backup & Recovery**: Continuous backup and disaster recovery processes
|
||||
|
||||
## 4.4 Scalability and Performance Considerations
|
||||
|
||||
### 4.4.1 Horizontal Scaling
|
||||
- **Load Distribution**: Multiple instances of Core Business & Services Modules
|
||||
- **Database Scaling**: Read replica distribution for improved query performance
|
||||
- **Storage Scaling**: Cloud storage auto-scaling based on demand
|
||||
- **Caching Strategy**: Redis caching for frequently accessed data
|
||||
|
||||
### 4.4.2 Performance Optimization
|
||||
- **Connection Pooling**: Optimized database connection management
|
||||
- **Query Optimization**: Efficient database query design and indexing
|
||||
- **CDN Integration**: Content delivery network for static assets
|
||||
- **Asynchronous Processing**: Background job processing for non-critical operations
|
||||
|
||||
## 4.5 Security and Compliance
|
||||
|
||||
### 4.5.1 Data Protection
|
||||
- **Encryption**: End-to-end encryption for all data transmission and storage
|
||||
- **Access Control**: Multi-layered access control with role-based permissions
|
||||
- **Audit Trails**: Comprehensive logging for compliance and security monitoring
|
||||
- **Data Localization**: Compliance with data residency requirements
|
||||
|
||||
### 4.5.2 DPDP Act Compliance
|
||||
- **Data Minimization**: Collection of only necessary personal data
|
||||
- **Consent Management**: Explicit consent tracking and management
|
||||
- **Data Subject Rights**: User access and data portability capabilities
|
||||
- **Breach Notification**: Automated breach detection and notification systems
|
||||
|
||||
## 4.6 System Dependencies and Integration Points
|
||||
|
||||
### 4.6.1 External Dependencies
|
||||
- **RE Bridge Centralised SSO**: Authentication and authorization services
|
||||
- **Active Directory**: User identity and role management
|
||||
- **SAP System**: Dealer master data and financial processing
|
||||
- **DMS System**: Document management and archival services
|
||||
- **Cloud Storage**: Scalable document and file storage
|
||||
|
||||
### 4.6.2 Internal Dependencies
|
||||
- **PostgreSQL Database**: Primary data storage and transaction management
|
||||
- **Monitoring Services**: System health and performance monitoring
|
||||
- **Logging Services**: Application and security event logging
|
||||
- **Notification Services**: Multi-channel communication capabilities
|
||||
|
||||
This Bird Eye View establishes the foundation for the detailed system design, ensuring that all architectural decisions align with the high-level requirements for security, scalability, and user experience.
|
||||
|
||||
5 System Design
|
||||
|
||||
The RE Workflow Solution follows a modern, scalable microservices architecture designed to handle high-volume dealer onboarding processes with enterprise-grade security and performance. The system is built on a multi-layered architecture that ensures separation of concerns, scalability, and maintainability.
|
||||
|
||||
## 5.1 Architecture Overview
|
||||
|
||||
The system architecture consists of the following key layers:
|
||||
|
||||
### 5.1.1 Access and Authentication Layer
|
||||
- **Admin Web App**: Browser-based access portal for all users
|
||||
- **WAF Firewall**: Web Application Firewall providing DDoS protection and security filtering
|
||||
- **API Gateway (Kong)**: Centralized entry point handling authentication, rate limiting, and request routing
|
||||
|
||||
### 5.1.2 Core Business Services Layer
|
||||
- **Schedulers**: Task scheduling and automation services
|
||||
- **Core Business Modules**: Main application logic for dealer processes
|
||||
- **Logstash**: Log collection and processing
|
||||
|
||||
### 5.1.3 Data and Storage Layer
|
||||
- **PostgreSQL Database**: Primary data store with read replicas
|
||||
- **Redis Cache**: Session management and performance optimization
|
||||
- **Object Storage**: Document and file management
|
||||
|
||||
### 5.1.4 Monitoring and Operations Layer
|
||||
- **Grafana & Prometheus**: Metrics collection and visualization
|
||||
- **ELK Stack**: Logging, search, and analytics
|
||||
- **Message Queue**: Asynchronous processing and notifications
|
||||
|
||||
### 5.1.5 External Integration Layer
|
||||
- **Notification Services**: Email, SMS, and push notifications
|
||||
- **External APIs**: SAP, DMS, and third-party integrations
|
||||
|
||||
## 5.2 Detailed Component Architecture
|
||||
|
||||
### 5.2.1 API Gateway (Kong) Configuration
|
||||
|
||||
The API Gateway serves as the single entry point and implements:
|
||||
|
||||
**Rate Limiting**
|
||||
- IP-based rate limiting: 100 requests/minute per IP
|
||||
- User-based rate limiting: 500 requests/minute per authenticated user
|
||||
- Whitelist support for trusted sources
|
||||
|
||||
**Metric Collection**
|
||||
- Request/response metrics
|
||||
- Performance monitoring
|
||||
- User activity tracking
|
||||
- API usage analytics
|
||||
|
||||
**Header Transformation**
|
||||
- Security header injection
|
||||
- Request/response header standardization
|
||||
- CORS policy enforcement
|
||||
|
||||
**Error Handling**
|
||||
- Centralized error response formatting
|
||||
- Error code standardization
|
||||
- Detailed logging for debugging
|
||||
|
||||
### 5.2.2 Authentication Flow Architecture
|
||||
|
||||
**SSO Integration Flow:**
|
||||
1. User accesses portal via browser
|
||||
2. WAF validates and filters request
|
||||
3. API Gateway checks for active session
|
||||
4. If no session, redirect to Identity Provider (MS AD/Okta)
|
||||
5. IdP validates credentials against Active Directory
|
||||
6. Authorization code returned to portal
|
||||
7. Portal exchanges code for access/refresh tokens
|
||||
8. Local session created with secure cookie
|
||||
9. User granted access to application
|
||||
|
||||
**Session Management:**
|
||||
- Secure HTTP-only cookies with SameSite protection
|
||||
- Session timeout: 8 hours of inactivity
|
||||
- Automatic token refresh using refresh tokens
|
||||
- Multi-device session tracking
|
||||
|
||||
### 5.2.3 Core Business Modules
|
||||
|
||||
**Dealer Application & Onboarding Module**
|
||||
- Application form processing and validation
|
||||
- Automated scoring and ranking algorithms
|
||||
- Multi-level approval workflow management
|
||||
- Document collection and verification
|
||||
- LOI/LOA generation and distribution
|
||||
|
||||
**Custom Workflow Module**
|
||||
- Dynamic workflow configuration
|
||||
- Template-based workflow creation
|
||||
- Regional customization support
|
||||
- Approval chain management
|
||||
- SLA tracking and enforcement
|
||||
|
||||
**Dealer Resignation Module**
|
||||
- Resignation request processing
|
||||
- Template-based letter generation
|
||||
- Multi-level approval workflows
|
||||
- Legal concurrence management
|
||||
- Dealer acknowledgment tracking
|
||||
|
||||
**Full & Final Settlement Module**
|
||||
- F&F calculation engine
|
||||
- Stakeholder coordination
|
||||
- SAP integration for code blocking
|
||||
- Finance AR integration
|
||||
- Legal escalation management
|
||||
|
||||
**Dashboard, Reports & Analytics Module**
|
||||
- Real-time dashboard updates
|
||||
- Custom report generation
|
||||
- Performance metrics and KPIs
|
||||
- Export functionality (PDF, Excel, CSV)
|
||||
- Data visualization and charts
|
||||
|
||||
### 5.2.4 Database Architecture (PostgreSQL)
|
||||
|
||||
**Primary Database Instance**
|
||||
- Write operations and transactions
|
||||
- ACID compliance
|
||||
- Data integrity enforcement
|
||||
- Backup and recovery
|
||||
|
||||
**Read Replica Instance**
|
||||
- Read-only queries for reporting
|
||||
- Load distribution
|
||||
- Performance optimization
|
||||
- Real-time synchronization
|
||||
|
||||
**Write-Ahead Logging (WAL)**
|
||||
- Transaction durability
|
||||
- Point-in-time recovery
|
||||
- Replication support
|
||||
- Crash recovery
|
||||
|
||||
**Database Access Layer (DAL)**
|
||||
- Connection pooling (max 100 connections)
|
||||
- Query builder with SQL injection protection
|
||||
- Database error handling and retry logic
|
||||
- Performance monitoring and optimization
|
||||
|
||||
### 5.2.5 Caching Strategy (Redis)
|
||||
|
||||
**Session Cache**
|
||||
- User session storage
|
||||
- Authentication tokens
|
||||
- Permission and role caching
|
||||
- TTL: 8 hours
|
||||
|
||||
**Application Cache**
|
||||
- Frequently accessed data (towns, dealer codes)
|
||||
- Master data caching
|
||||
- Report result caching
|
||||
- TTL: 24 hours
|
||||
|
||||
**Performance Cache**
|
||||
- API response caching
|
||||
- Database query result caching
|
||||
- Static content caching
|
||||
- TTL: 1 hour
|
||||
|
||||
### 5.2.6 Outbound Network Layer
|
||||
|
||||
**External API Integration**
|
||||
- SAP system integration for dealer creation
|
||||
- DMS integration for document management
|
||||
- Third-party service integrations
|
||||
|
||||
**Circuit Breaker Pattern**
|
||||
- Automatic failure detection
|
||||
- Fallback mechanisms
|
||||
- Recovery testing
|
||||
- Service degradation handling
|
||||
|
||||
**Retry Logic**
|
||||
- Exponential backoff for failed requests
|
||||
- Maximum retry count: 3
|
||||
- Timeout configuration: 30 seconds
|
||||
- Network error handling
|
||||
|
||||
**Response Validation**
|
||||
- Schema validation for external responses
|
||||
- Data integrity checks
|
||||
- Error response handling
|
||||
- Logging and monitoring
|
||||
|
||||
### 5.2.7 Monitoring and Alerting
|
||||
|
||||
**Metrics Collection (Prometheus)**
|
||||
- System performance metrics
|
||||
- Application performance indicators
|
||||
- Business process metrics
|
||||
- Custom KPI tracking
|
||||
|
||||
**Visualization (Grafana)**
|
||||
- Real-time dashboards
|
||||
- Historical trend analysis
|
||||
- Alert visualization
|
||||
- Custom metric displays
|
||||
|
||||
**Alerting System**
|
||||
- Threshold-based alerts
|
||||
- Anomaly detection
|
||||
- Escalation procedures
|
||||
- Integration with notification services
|
||||
|
||||
### 5.2.8 Logging and Analytics (ELK Stack)
|
||||
|
||||
**Log Collection (Logstash)**
|
||||
- Application log aggregation
|
||||
- System log collection
|
||||
- Error log processing
|
||||
- Performance log analysis
|
||||
|
||||
**Search and Analytics (ElasticSearch)**
|
||||
- Log indexing and search
|
||||
- Performance analytics
|
||||
- Error pattern analysis
|
||||
- Compliance audit trails
|
||||
|
||||
**Visualization (Kibana)**
|
||||
- Log visualization dashboards
|
||||
- Performance trend analysis
|
||||
- Error investigation tools
|
||||
- Compliance reporting
|
||||
|
||||
### 5.2.9 Notification Services
|
||||
|
||||
**Email Notifications**
|
||||
- SMTP gateway integration
|
||||
- Template-based email generation
|
||||
- Delivery tracking and retry
|
||||
- Bounce handling
|
||||
|
||||
**SMS Notifications**
|
||||
- SMS gateway integration
|
||||
- Bulk SMS capabilities
|
||||
- Delivery confirmation
|
||||
- Cost optimization
|
||||
|
||||
**Push Notifications**
|
||||
- Firebase integration
|
||||
- Mobile app notifications
|
||||
- Web push notifications
|
||||
- Delivery analytics
|
||||
|
||||
## 5.3 Data Flow Architecture
|
||||
|
||||
### 5.3.1 Request Processing Flow
|
||||
|
||||
1. **User Request**: Browser → WAF → API Gateway
|
||||
2. **Authentication**: API Gateway → IdP → Active Directory
|
||||
3. **Authorization**: Role validation → Permission check
|
||||
4. **Routing**: Load balancer → Core business modules
|
||||
5. **Processing**: Business logic → Database operations
|
||||
6. **Response**: Data retrieval → Cache check → Response formatting
|
||||
7. **Delivery**: API Gateway → Browser
|
||||
|
||||
### 5.3.2 Asynchronous Processing Flow
|
||||
|
||||
1. **Event Trigger**: Business process completion
|
||||
2. **Message Queue**: Event queuing for processing
|
||||
3. **Background Jobs**: Email sending, report generation
|
||||
4. **External Integration**: SAP updates, document processing
|
||||
5. **Notification**: User notifications via multiple channels
|
||||
|
||||
### 5.3.3 Data Synchronization Flow
|
||||
|
||||
1. **Primary Write**: Database write operation
|
||||
2. **WAL Generation**: Write-ahead log creation
|
||||
3. **Replica Sync**: Real-time synchronization to read replica
|
||||
4. **Cache Update**: Redis cache invalidation/update
|
||||
5. **Index Update**: Search index refresh
|
||||
|
||||
## 5.4 Security Architecture
|
||||
|
||||
### 5.4.1 Network Security
|
||||
- WAF protection against common attacks
|
||||
- TLS 1.3 encryption for all communications
|
||||
- Network segmentation and firewall rules
|
||||
- VPN access for administrative functions
|
||||
|
||||
### 5.4.2 Application Security
|
||||
- Input validation and sanitization
|
||||
- SQL injection prevention
|
||||
- XSS protection
|
||||
- CSRF token implementation
|
||||
|
||||
### 5.4.3 Data Security
|
||||
- AES-256 encryption for data at rest
|
||||
- Field-level encryption for sensitive data
|
||||
- Secure key management
|
||||
- Data masking for non-production environments
|
||||
|
||||
### 5.4.4 Access Control
|
||||
- Role-based access control (RBAC)
|
||||
- Principle of least privilege
|
||||
- Multi-factor authentication for sensitive roles
|
||||
- Session management and timeout
|
||||
|
||||
## 5.5 Scalability and Performance
|
||||
|
||||
### 5.5.1 Horizontal Scaling
|
||||
- Load balancer distribution
|
||||
- Database read replicas
|
||||
- Microservice architecture
|
||||
- Container orchestration support
|
||||
|
||||
### 5.5.2 Performance Optimization
|
||||
- Redis caching strategy
|
||||
- Database query optimization
|
||||
- CDN integration for static assets
|
||||
- Connection pooling
|
||||
|
||||
### 5.5.3 Monitoring and Metrics
|
||||
- Real-time performance monitoring
|
||||
- Capacity planning metrics
|
||||
- SLA tracking and reporting
|
||||
- Performance bottleneck identification
|
||||
|
||||
## 5.6 Disaster Recovery and Backup
|
||||
|
||||
### 5.6.1 Backup Strategy
|
||||
- Daily automated backups
|
||||
- Point-in-time recovery capability
|
||||
- Cross-region backup replication
|
||||
- Backup testing and validation
|
||||
|
||||
### 5.6.2 High Availability
|
||||
- Multi-AZ deployment
|
||||
- Database failover automation
|
||||
- Service redundancy
|
||||
- Health check monitoring
|
||||
|
||||
### 5.6.3 Recovery Procedures
|
||||
- RTO: 4 hours maximum
|
||||
- RPO: 1 hour maximum
|
||||
- Automated recovery testing
|
||||
- Documentation and runbooks
|
||||
|
||||
6 System Design Explanation
|
||||
6.1 User Authentication & Access Flow
|
||||
The system leverages Royal Enfield’s existing Active Directory (AD) via an Identity Provider
|
||||
(IdP) (Azure AD / ADFS) for authentication. This means that user identity and credentials are not
|
||||
managed within the portal but by AD, ensuring consistency with corporate policies.
|
||||
|
||||
6.1.1 Step-by-Step Authentication Flow
|
||||
First-Time Access
|
||||
|
||||
A user navigates to the portal (e.g., https://dd-portal.re.com/).
|
||||
The portal checks for an active application session (secure session cookie sid). If
|
||||
absent/expired, the user is redirected to the IdP’s /authorize endpoint.
|
||||
The IdP validates the user credentials against AD
|
||||
Upon successful authentication, the IdP (Identity Provider) redirects back to the portal’s
|
||||
callback URL with an authorization code.
|
||||
The portal backend exchanges the authorization code with the IdP’s /token endpoint
|
||||
over HTTPS. Response includes: ID Token (identity claims), Access Token, and Refresh
|
||||
Token.
|
||||
The ID Token is validated using IdP’s public keys and claims are extracted (user, roles,
|
||||
groups).
|
||||
A secure application session is created (stored locally), and an opaque sid cookie is set in
|
||||
the user’s browser.
|
||||
User gains access to the portal and their dashboard.
|
||||
Subsequent Access
|
||||
|
||||
On the next request, the browser presents the sid cookie.
|
||||
If the session is still valid, the request is allowed directly.
|
||||
If expired, the portal redirects to the IdP.
|
||||
If the IdP SSO session is still valid, a new token is issued silently via Refresh Token (no
|
||||
login prompt).
|
||||
If IdP SSO is also expired, the user must re-enter credentials.
|
||||
6.2 API Driven Framework
|
||||
Expose all business capabilities (Applications, Evaluations, Approvals, Documents, Notifications,
|
||||
F&F, Reports) as versioned, secure APIs. This decouples frontends (web portal today, mobile app
|
||||
tomorrow) from backend services and enables internal/partner integrations without
|
||||
re-engineering.
|
||||
|
||||
6.3 Frontend Layer (React.js)
|
||||
The frontend of the Dealer Development Automation system will be a web portal accessible to
|
||||
applicants and internal staff. It will provide intuitive forms for dealer applications ,
|
||||
interactive dashboards for approvals and evaluations , and comprehensive reporting
|
||||
views (daily summaries, location-wise performance, F&F status). The portal will communicate
|
||||
exclusively with backend services through the API Gateway , ensuring a clean separation of
|
||||
concerns and enabling an API-driven architecture.
|
||||
The frontend will be developed using ReactJS , chosen for its strong ecosystem and wide
|
||||
community support available. React allows us to build highly responsive UIs where approval
|
||||
workflows, reminders, and multi-level evaluation forms can be represented as reusable
|
||||
components, reducing development effort and improving maintainability.
|
||||
|
||||
6.4 Backend Service (Node.js)
|
||||
Node.js has become one of the most widely adopted backend technologies because of its API
|
||||
First, event-driven, non-blocking I/O architecture , which makes it highly efficient at handling
|
||||
thousands of concurrent API calls, webhooks, and real-time events with minimal resource usage.
|
||||
The combination of performance, developer productivity, ecosystem maturity, and platform
|
||||
support makes Node.js not just a trending choice, but a future-proof technology for building
|
||||
scalable, API-driven enterprise systems like the Dealer Development Automation platform
|
||||
|
||||
6.5 Data Handling & Storage
|
||||
PostgreSQL : Database: Primary transactional store; read replica for reporting.
|
||||
Redis Cache : Session storage, rate limiting, reminder state.
|
||||
Object Storage : Legal and operational document archive over cloud storage
|
||||
Audit Logs : Immutable records of all approvals, actions, and data changes for
|
||||
compliance.
|
||||
Monitoring & Logging : Prometheus/Grafana for metrics, ELK/Cloud Logging for logs.
|
||||
7 Scalability & Performance
|
||||
Load Handling : 1,000 requests/minute (200 users × 5 calls/minute).
|
||||
API Gateway : Handles rate limiting, load balancing, routing.
|
||||
Database :
|
||||
PostgreSQL: Read replicas for queries.
|
||||
Object Storage: Scalable for documents.
|
||||
Caching : Redis for frequent queries (e.g., user roles, town lists).
|
||||
Asynchronous Processing : Message Queue for emails and integrations.
|
||||
Microservice-ready design allows scaling each service independently.
|
||||
Event-driven architecture ensures async notifications and workflows.
|
||||
Configurable workflows support regional customization.
|
||||
Mobile-ready design with JWT support for future app extensions.
|
||||
Libraries & Dependencies We ensure to use the libraries which are having healthy
|
||||
cadence & footprint, check known issues on it’s GIT, Licence, ran by foundation or single
|
||||
person & GIT Insights
|
||||
8 DPDP Act Compliance
|
||||
The system adheres to the Digital Personal Data Protection Act, 2023 , with the following measures:
|
||||
|
||||
Data Minimization : Collect only necessary data (e.g., dealer name, contact, financial
|
||||
details).
|
||||
Consent Management : Obtain explicit consent via web forms, stored in a DB
|
||||
Data Subject Rights : Provide interface for dealers to access their data.
|
||||
Data Security : Use TLS 1.3 for data in transit and AES-256 for data at rest.
|
||||
Data Localization : Deploy databases and storage in India-based cloud regions.
|
||||
Breach Notification : Alerts within 72 hours of a data breach.
|
||||
Audit Trails : Log all data access and modifications for compliance audits.
|
||||
9 Security Requirements and Technical Implementation
|
||||
DPDP-Specific :
|
||||
Data Localization : Deploy in India-based regions.
|
||||
Consent Management : Store consent records, provide opt-out.
|
||||
Breach Notification : Alerts within 72 hours
|
||||
Audit Trails : Log data access in ELK Stack.
|
||||
General Security :
|
||||
Encryption : TLS 1.3, AES-256.
|
||||
WAF : Deploy cloud specific WAF.
|
||||
MFA : Enforce for sensitive roles.
|
||||
Secure APIs : Use API keys, OAuth tokens, rate limiting.
|
||||
API Gateway / Reverse Proxy: TLS termination, rate limiting, request validation,
|
||||
and routing.
|
||||
Network Firewall: Ensures only HTTPS (443) is exposed externally; internal DBs
|
||||
remain private.
|
||||
Secrets Management: All API keys, DB credentials, and OAuth secrets stored in
|
||||
KMS/Vault.
|
||||
9.1 Input Validation and Sanitization
|
||||
Requirement : Mitigate injection attacks (e.g., SQL injection, Cross-Site Scripting [XSS])
|
||||
on user inputs such as questionnaire responses, comments, and custom flow
|
||||
configurations.
|
||||
Rationale : Malicious inputs could execute unauthorized scripts or corrupt data,
|
||||
particularly in the platform’s interactive forms and dynamic workflows.
|
||||
Risk Level : Medium
|
||||
Implementation Strategy :
|
||||
Validation : Enforce input schemas in Node.js, validating data types (e.g., email
|
||||
regex, numeric scores) before processing.
|
||||
9.2 Secure File Handling
|
||||
Requirement : Safeguard uploaded files (e.g., business plans, financial documents, legal
|
||||
papers) against unauthorized access, tampering, or malware.
|
||||
Rationale : Exposure of confidential business data could disrupt the onboarding process
|
||||
or lead to legal liabilities, given the platform’s document-centric nature.
|
||||
Risk Level : High
|
||||
Implementation Strategy :
|
||||
Storage : Utilize a secure object storage service (e.g., AWS S3 with SSE-KMS) with
|
||||
private access policies and server-side encryption.
|
||||
Access : Generate time-bound pre-signed URLs (e.g., 300-second expiration) via
|
||||
Node.js routes, authenticated with user tokens.
|
||||
9.3 DDoS and API Rate Limiting
|
||||
Requirement : Defend against Distributed Denial of Service (DDoS) attacks and API abuse
|
||||
during peak onboarding activity.
|
||||
Rationale : High-traffic features (e.g., report downloads, progress sharing) are vulnerable
|
||||
to overload, potentially disrupting service availability.
|
||||
Risk Level : Medium
|
||||
Implementation Strategy :
|
||||
Rate Limiting : Configure express-rate-limit in Node.js to cap API requests at 100
|
||||
per minute per IP, with whitelisting for trusted sources.
|
||||
DDoS Mitigation : Integrate a CDN with Web Application Firewall (WAF)
|
||||
capabilities (e.g., Cloudflare) to filter malicious traffic and distribute load.
|
||||
10 Monitoring & Maintenance
|
||||
Monitoring : Prometheus for metrics, Grafana for dashboards.
|
||||
Logging : ELK Stack for DPDP-compliant audits.
|
||||
Maintenance : CI/CD pipeline with Jenkins/GitHub Actions.
|
||||
11 Camunda Support
|
||||
Camunda provides APIs to let external applications start, advance, and complete workflow steps.
|
||||
In Camunda 7 , this is done via the REST API
|
||||
(e.g., POST /process-definition/key/dealer_application/start to start a new dealer
|
||||
application flow). In Camunda 8 (Zeebe engine) , APIs are available as gRPC client libraries (Java,
|
||||
Node.js, Go) or via a REST gateway ; for example, a Node.js service can
|
||||
call zbc.createProcessInstance({ bpmnProcessId: "dealer_application_v1",
|
||||
variables: { applicantId: "APP123" } }) whenever a dealer submits an application form.
|
||||
This integration allows the process instance to flow through approval tasks (ASM → ZM → NBH),
|
||||
with each stage visible in Camunda Operate , and bottlenecks/heatmaps available in Camunda
|
||||
Optimize. Camunda offers a free Community Edition (open source) for self-managed setups, and
|
||||
a SaaS version (Camunda 8) with usage-based pricing; as of 2025, SaaS plans start with a free
|
||||
tier (up to 5 users and limited usage) , then scale to Team/Enterprise plans based on process
|
||||
instance volume, storage, and enterprise features like Optimize, Tasklist, and SLA support.
|
||||
BIN
RE-Workflow-Management-System-Project-KickoffV1.1.pdf
Normal file
BIN
RE-Workflow-Management-System-Project-KickoffV1.1.pdf
Normal file
Binary file not shown.
93
RE_Abbrevations.txt
Normal file
93
RE_Abbrevations.txt
Normal file
@ -0,0 +1,93 @@
|
||||
# ROYAL ENFIELD WORKFLOW PORTAL - ABBREVIATIONS & ACRONYMS
|
||||
|
||||
## Business Roles & Designations
|
||||
DDL : Dealer Development Lead
|
||||
ZBH : Zonal Business Head
|
||||
NBH : National Business Head
|
||||
CCO : Chief Commercial Officer
|
||||
CEO : Chief Executive Officer
|
||||
ASM : Area Sales Manager
|
||||
ZM : Zone Manager
|
||||
RBM : Regional Business Manager
|
||||
DD : Dealer Development
|
||||
SPOC : Single Point of Contact
|
||||
SME : Subject Matter Expert
|
||||
|
||||
## Business Processes & Documents
|
||||
LOI : Letter of Intent
|
||||
LOA : Letter of Agreement
|
||||
FDD : Financial Due Diligence
|
||||
KT : Knowledge Transfer
|
||||
F&F : Full & Final Settlement
|
||||
FJC : Field Journey Calendar
|
||||
MOM : Minutes of Meeting
|
||||
TAT : Turnaround Time
|
||||
SLA : Service Level Agreement
|
||||
CX : Customer Experience
|
||||
GMA : Gear & Merchandise Accessories
|
||||
CNR : Customer & Network Relations
|
||||
|
||||
## Technical Terms & Systems
|
||||
API : Application Programming Interface
|
||||
SSO : Single Sign-On
|
||||
RBAC : Role-Based Access Control
|
||||
SAP : Systems, Applications & Products in Data Processing
|
||||
DMS : Document Management System
|
||||
MSD : Master Service Directory
|
||||
AR : Accounts Receivable
|
||||
IO : Internal Order
|
||||
PR : Purchase Request
|
||||
PO : Purchase Order
|
||||
|
||||
## Security & Compliance
|
||||
DPDP : Digital Personal Data Protection
|
||||
MFA : Multi-Factor Authentication
|
||||
WAF : Web Application Firewall
|
||||
JWT : JSON Web Token
|
||||
JWE : JSON Web Encryption
|
||||
SSL : Secure Sockets Layer
|
||||
XSS : Cross-Site Scripting
|
||||
CSRF : Cross-Site Request Forgery
|
||||
HSTS : HTTP Strict Transport Security
|
||||
HPKP : HTTP Public Key Pinning
|
||||
CORS : Cross-Origin Resource Sharing
|
||||
MIME : Multipurpose Internet Mail Extensions
|
||||
|
||||
## Database & Infrastructure
|
||||
PGSQL : PostgreSQL
|
||||
DAL : Database Access Layer
|
||||
WAL : Write-Ahead Logging
|
||||
ELK : Elasticsearch, Logstash, Kibana
|
||||
CDN : Content Delivery Network
|
||||
TTL : Time To Live
|
||||
RTO : Recovery Time Objective
|
||||
RPO : Recovery Point Objective
|
||||
HA : High Availability
|
||||
|
||||
## Development & Testing
|
||||
UAT : User Acceptance Testing
|
||||
SRS : Software Requirements Specification
|
||||
CR : Change Request
|
||||
MIS : Management Information System
|
||||
AMS : Annual Maintenance and Support
|
||||
CI : Continuous Integration
|
||||
CD : Continuous Deployment
|
||||
|
||||
## Workflow & BPM
|
||||
BPM : Business Process Management
|
||||
BPMN : Business Process Model and Notation
|
||||
OCR : Optical Character Recognition
|
||||
|
||||
## Cloud & Platforms
|
||||
SaaS : Software as a Service
|
||||
PaaS : Platform as a Service
|
||||
IaaS : Infrastructure as a Service
|
||||
|
||||
## Compliance & Standards
|
||||
GDPR : General Data Protection Regulation
|
||||
HIPAA : Health Insurance Portability and Accountability Act
|
||||
OWASP : Open Web Application Security Project
|
||||
|
||||
|
||||
|
||||
|
||||
969
RE_FULLSCOPE_AND PROJECT_STRUCTURE.md
Normal file
969
RE_FULLSCOPE_AND PROJECT_STRUCTURE.md
Normal file
@ -0,0 +1,969 @@
|
||||
# Royal Enfield Workflow Portal - Project Setup Guide
|
||||
|
||||
## 📁 Frontend Folder Structure (React.js)
|
||||
|
||||
```
|
||||
re-workflow-portal-frontend/
|
||||
├── public/
|
||||
│ ├── assets/
|
||||
│ │ ├── images/
|
||||
│ │ ├── icons/
|
||||
│ │ └── fonts/
|
||||
│ └── favicon.ico
|
||||
├── src/
|
||||
│ ├── pages/
|
||||
│ │ ├── auth/
|
||||
│ │ │ ├── Login.jsx
|
||||
│ │ │ └── Register.jsx
|
||||
│ │ ├── dashboard/
|
||||
│ │ │ └── Dashboard.jsx
|
||||
│ │ ├── dealer-onboarding/
|
||||
│ │ │ ├── DealerOnboarding.jsx
|
||||
│ │ │ ├── applications/
|
||||
│ │ │ │ └── Applications.jsx
|
||||
│ │ │ ├── evaluation/
|
||||
│ │ │ │ └── Evaluation.jsx
|
||||
│ │ │ └── details/
|
||||
│ │ │ └── DealerDetails.jsx
|
||||
│ │ ├── dealer-offboarding/
|
||||
│ │ │ ├── DealerOffboarding.jsx
|
||||
│ │ │ ├── resignation/
|
||||
│ │ │ │ ├── ResignationForm.jsx
|
||||
│ │ │ │ ├── ResignationTracking.jsx
|
||||
│ │ │ │ └── ResignationApproval.jsx
|
||||
│ │ │ ├── termination/
|
||||
│ │ │ │ ├── TerminationForm.jsx
|
||||
│ │ │ │ ├── TerminationProcess.jsx
|
||||
│ │ │ │ └── TerminationApproval.jsx
|
||||
│ │ │ ├── full-final/
|
||||
│ │ │ │ ├── FFTracking.jsx
|
||||
│ │ │ │ ├── FFSettlement.jsx
|
||||
│ │ │ │ └── FFStakeholderTracking.jsx
|
||||
│ │ │ └── documents/
|
||||
│ │ │ ├── ResignationLetter.jsx
|
||||
│ │ │ ├── TerminationNotice.jsx
|
||||
│ │ │ └── DocumentGeneration.jsx
|
||||
│ │ ├── field-visit/
|
||||
│ │ │ ├── FieldVisit.jsx
|
||||
│ │ │ ├── planning/
|
||||
│ │ │ │ └── Planning.jsx
|
||||
│ │ │ ├── execution/
|
||||
│ │ │ │ └── Execution.jsx
|
||||
│ │ │ └── mom/
|
||||
│ │ │ └── MOM.jsx
|
||||
│ │ ├── dealer-claim/
|
||||
│ │ │ ├── DealerClaim.jsx
|
||||
│ │ │ ├── requests/
|
||||
│ │ │ │ └── Requests.jsx
|
||||
│ │ │ ├── proposals/
|
||||
│ │ │ │ └── Proposals.jsx
|
||||
│ │ │ └── approvals/
|
||||
│ │ │ └── Approvals.jsx
|
||||
│ │ ├── reports/
|
||||
│ │ │ └── Reports.jsx
|
||||
│ │ ├── masters/
|
||||
│ │ │ ├── Masters.jsx
|
||||
│ │ │ ├── towns/
|
||||
│ │ │ │ └── Towns.jsx
|
||||
│ │ │ ├── dealer-codes/
|
||||
│ │ │ │ └── DealerCodes.jsx
|
||||
│ │ │ ├── evaluation-criteria/
|
||||
│ │ │ │ └── EvaluationCriteria.jsx
|
||||
│ │ │ └── workflow-templates/
|
||||
│ │ │ └── WorkflowTemplates.jsx
|
||||
│ │ ├── workflow-engine/
|
||||
│ │ │ ├── WorkflowEngine.jsx
|
||||
│ │ │ ├── templatized/
|
||||
│ │ │ │ └── TemplatizedWorkflow.jsx
|
||||
│ │ │ ├── non-templatized/
|
||||
│ │ │ │ └── NonTemplatizedWorkflow.jsx
|
||||
│ │ │ └── template-builder/
|
||||
│ │ │ └── TemplateBuilder.jsx
|
||||
│ │ ├── user-management/
|
||||
│ │ │ ├── UserManagement.jsx
|
||||
│ │ │ ├── roles/
|
||||
│ │ │ │ └── Roles.jsx
|
||||
│ │ │ ├── permissions/
|
||||
│ │ │ │ └── Permissions.jsx
|
||||
│ │ │ └── regional-scoping/
|
||||
│ │ │ └── RegionalScoping.jsx
|
||||
│ │ └── NotFound.jsx
|
||||
│ ├── components/
|
||||
│ │ ├── common/
|
||||
│ │ │ ├── Button/
|
||||
│ │ │ │ └── Button.jsx
|
||||
│ │ │ ├── Input/
|
||||
│ │ │ │ └── Input.jsx
|
||||
│ │ │ ├── Modal/
|
||||
│ │ │ │ └── Modal.jsx
|
||||
│ │ │ ├── Table/
|
||||
│ │ │ │ └── Table.jsx
|
||||
│ │ │ ├── Loader/
|
||||
│ │ │ │ └── Loader.jsx
|
||||
│ │ │ └── Notification/
|
||||
│ │ │ └── Notification.jsx
|
||||
│ │ ├── layout/
|
||||
│ │ │ ├── Header/
|
||||
│ │ │ │ └── Header.jsx
|
||||
│ │ │ ├── Sidebar/
|
||||
│ │ │ │ └── Sidebar.jsx
|
||||
│ │ │ ├── Footer/
|
||||
│ │ │ │ └── Footer.jsx
|
||||
│ │ │ └── Breadcrumb/
|
||||
│ │ │ └── Breadcrumb.jsx
|
||||
│ │ ├── forms/
|
||||
│ │ │ ├── DealerApplicationForm/
|
||||
│ │ │ │ └── DealerApplicationForm.jsx
|
||||
│ │ │ ├── QuestionnaireForm/
|
||||
│ │ │ │ └── QuestionnaireForm.jsx
|
||||
│ │ │ ├── EvaluationForm/
|
||||
│ │ │ │ └── EvaluationForm.jsx
|
||||
│ │ │ ├── ClaimForm/
|
||||
│ │ │ │ └── ClaimForm.jsx
|
||||
│ │ │ ├── ResignationForm/
|
||||
│ │ │ │ └── ResignationForm.jsx
|
||||
│ │ │ ├── TerminationForm/
|
||||
│ │ │ │ └── TerminationForm.jsx
|
||||
│ │ │ └── FFSettlementForm/
|
||||
│ │ │ └── FFSettlementForm.jsx
|
||||
│ │ ├── workflow/
|
||||
│ │ │ ├── WorkflowViewer/
|
||||
│ │ │ │ └── WorkflowViewer.jsx
|
||||
│ │ │ ├── ApprovalFlow/
|
||||
│ │ │ │ └── ApprovalFlow.jsx
|
||||
│ │ │ ├── StatusTracker/
|
||||
│ │ │ │ └── StatusTracker.jsx
|
||||
│ │ │ ├── TemplateBuilder/
|
||||
│ │ │ │ └── TemplateBuilder.jsx
|
||||
│ │ │ ├── WorkflowEngine/
|
||||
│ │ │ │ └── WorkflowEngine.jsx
|
||||
│ │ │ ├── DynamicWorkflow/
|
||||
│ │ │ │ └── DynamicWorkflow.jsx
|
||||
│ │ │ ├── OCRProcessor/
|
||||
│ │ │ │ └── OCRProcessor.jsx
|
||||
│ │ │ └── DigitalSignature/
|
||||
│ │ │ └── DigitalSignature.jsx
|
||||
│ │ ├── user-management/
|
||||
│ │ │ ├── RoleManager/
|
||||
│ │ │ │ └── RoleManager.jsx
|
||||
│ │ │ ├── PermissionMatrix/
|
||||
│ │ │ │ └── PermissionMatrix.jsx
|
||||
│ │ │ ├── RegionalScoping/
|
||||
│ │ │ │ └── RegionalScoping.jsx
|
||||
│ │ │ └── UserProfile/
|
||||
│ │ │ └── UserProfile.jsx
|
||||
│ │ ├── masters/
|
||||
│ │ │ ├── MasterDataManager/
|
||||
│ │ │ │ └── MasterDataManager.jsx
|
||||
│ │ │ ├── TownManager/
|
||||
│ │ │ │ └── TownManager.jsx
|
||||
│ │ │ ├── DealerCodeManager/
|
||||
│ │ │ │ └── DealerCodeManager.jsx
|
||||
│ │ │ └── EvaluationCriteriaManager/
|
||||
│ │ │ └── EvaluationCriteriaManager.jsx
|
||||
│ │ ├── offboarding/
|
||||
│ │ │ ├── ResignationManager/
|
||||
│ │ │ │ └── ResignationManager.jsx
|
||||
│ │ │ ├── TerminationManager/
|
||||
│ │ │ │ └── TerminationManager.jsx
|
||||
│ │ │ ├── FFSettlementManager/
|
||||
│ │ │ │ └── FFSettlementManager.jsx
|
||||
│ │ │ ├── DocumentGenerator/
|
||||
│ │ │ │ └── DocumentGenerator.jsx
|
||||
│ │ │ └── StakeholderTracker/
|
||||
│ │ │ └── StakeholderTracker.jsx
|
||||
│ │ └── dashboard/
|
||||
│ │ ├── StatCard/
|
||||
│ │ │ └── StatCard.jsx
|
||||
│ │ ├── ChartWidget/
|
||||
│ │ │ └── ChartWidget.jsx
|
||||
│ │ └── RecentActivity/
|
||||
│ │ └── RecentActivity.jsx
|
||||
│ ├── hooks/
|
||||
│ │ ├── useAuth.js
|
||||
│ │ ├── useWorkflow.js
|
||||
│ │ ├── useDealer.js
|
||||
│ │ ├── useNotification.js
|
||||
│ │ ├── useTemplate.js
|
||||
│ │ ├── useOCR.js
|
||||
│ │ ├── useDigitalSignature.js
|
||||
│ │ ├── useUserManagement.js
|
||||
│ │ ├── useMasterData.js
|
||||
│ │ ├── useOffboarding.js
|
||||
│ │ ├── useResignation.js
|
||||
│ │ ├── useTermination.js
|
||||
│ │ └── useFFSettlement.js
|
||||
│ ├── lib/
|
||||
│ │ ├── api/
|
||||
│ │ │ ├── axios-config.js
|
||||
│ │ │ ├── endpoints.js
|
||||
│ │ │ └── interceptors.js
|
||||
│ │ ├── utils/
|
||||
│ │ │ ├── validation.js
|
||||
│ │ │ ├── formatters.js
|
||||
│ │ │ └── helpers.js
|
||||
│ │ └── constants/
|
||||
│ │ ├── roles.js
|
||||
│ │ ├── status.js
|
||||
│ │ └── routes.js
|
||||
│ ├── services/
|
||||
│ │ ├── auth.service.js
|
||||
│ │ ├── dealer.service.js
|
||||
│ │ ├── workflow.service.js
|
||||
│ │ ├── field-visit.service.js
|
||||
│ │ ├── claim.service.js
|
||||
│ │ ├── report.service.js
|
||||
│ │ ├── template.service.js
|
||||
│ │ ├── ocr.service.js
|
||||
│ │ ├── digital-signature.service.js
|
||||
│ │ ├── user-management.service.js
|
||||
│ │ ├── master-data.service.js
|
||||
│ │ ├── sms.service.js
|
||||
│ │ ├── push-notification.service.js
|
||||
│ │ ├── offboarding.service.js
|
||||
│ │ ├── resignation.service.js
|
||||
│ │ ├── termination.service.js
|
||||
│ │ └── ff-settlement.service.js
|
||||
│ ├── store/
|
||||
│ │ ├── slices/
|
||||
│ │ │ ├── authSlice.js
|
||||
│ │ │ ├── dealerSlice.js
|
||||
│ │ │ ├── workflowSlice.js
|
||||
│ │ │ ├── templateSlice.js
|
||||
│ │ │ ├── userManagementSlice.js
|
||||
│ │ │ ├── masterDataSlice.js
|
||||
│ │ │ ├── notificationSlice.js
|
||||
│ │ │ ├── offboardingSlice.js
|
||||
│ │ │ ├── resignationSlice.js
|
||||
│ │ │ ├── terminationSlice.js
|
||||
│ │ │ └── ffSettlementSlice.js
|
||||
│ │ └── index.js
|
||||
│ ├── types/
|
||||
│ │ ├── auth.types.js
|
||||
│ │ ├── dealer.types.js
|
||||
│ │ ├── workflow.types.js
|
||||
│ │ ├── template.types.js
|
||||
│ │ ├── user-management.types.js
|
||||
│ │ ├── master-data.types.js
|
||||
│ │ ├── notification.types.js
|
||||
│ │ ├── offboarding.types.js
|
||||
│ │ ├── resignation.types.js
|
||||
│ │ ├── termination.types.js
|
||||
│ │ ├── ff-settlement.types.js
|
||||
│ │ └── common.types.js
|
||||
│ ├── App.js
|
||||
│ ├── index.js
|
||||
│ └── setupTests.js
|
||||
├── .env.local
|
||||
├── .env.development
|
||||
├── .env.production
|
||||
├── webpack.config.js
|
||||
├── tailwind.config.js
|
||||
├── babel.config.js
|
||||
├── package.json
|
||||
├── package-lock.json
|
||||
└── README.md
|
||||
```
|
||||
|
||||
## 📁 Backend Folder Structure (Node.js)
|
||||
|
||||
```
|
||||
re-workflow-portal-backend/
|
||||
├── src/
|
||||
│ ├── config/
|
||||
│ │ ├── database.config.ts
|
||||
│ │ ├── app.config.ts
|
||||
│ │ ├── camunda.config.ts
|
||||
│ │ ├── email.config.ts
|
||||
│ │ └── ad.config.ts
|
||||
│ ├── controllers/
|
||||
│ │ ├── auth.controller.ts
|
||||
│ │ ├── dealer.controller.ts
|
||||
│ │ ├── workflow.controller.ts
|
||||
│ │ ├── field-visit.controller.ts
|
||||
│ │ ├── claim.controller.ts
|
||||
│ │ ├── report.controller.ts
|
||||
│ │ ├── master.controller.ts
|
||||
│ │ ├── template.controller.ts
|
||||
│ │ ├── ocr.controller.ts
|
||||
│ │ ├── digital-signature.controller.ts
|
||||
│ │ ├── user-management.controller.ts
|
||||
│ │ └── notification.controller.ts
|
||||
│ ├── services/
|
||||
│ │ ├── auth/
|
||||
│ │ │ ├── auth.service.ts
|
||||
│ │ │ ├── ad.service.ts
|
||||
│ │ │ └── jwt.service.ts
|
||||
│ │ ├── dealer/
|
||||
│ │ │ ├── dealer.service.ts
|
||||
│ │ │ ├── onboarding.service.ts
|
||||
│ │ │ ├── offboarding.service.ts
|
||||
│ │ │ └── evaluation.service.ts
|
||||
│ │ ├── workflow/
|
||||
│ │ │ ├── camunda.service.ts
|
||||
│ │ │ ├── approval.service.ts
|
||||
│ │ │ └── notification.service.ts
|
||||
│ │ ├── field-visit/
|
||||
│ │ │ └── field-visit.service.ts
|
||||
│ │ ├── claim/
|
||||
│ │ │ └── claim.service.ts
|
||||
│ │ ├── email/
|
||||
│ │ │ ├── email.service.ts
|
||||
│ │ │ └── template.service.ts
|
||||
│ │ ├── report/
|
||||
│ │ │ └── report.service.ts
|
||||
│ │ └── integration/
|
||||
│ │ ├── sap.service.ts
|
||||
│ │ ├── dms.service.ts
|
||||
│ │ ├── website-integration.service.ts
|
||||
│ │ └── third-party-auditor.service.ts
|
||||
│ │ ├── workflow/
|
||||
│ │ │ ├── templatized-workflow.service.ts
|
||||
│ │ │ ├── non-templatized-workflow.service.ts
|
||||
│ │ │ └── template-builder.service.ts
|
||||
│ │ ├── ocr/
|
||||
│ │ │ └── ocr.service.ts
|
||||
│ │ ├── digital-signature/
|
||||
│ │ │ └── digital-signature.service.ts
|
||||
│ │ ├── user-management/
|
||||
│ │ │ ├── user-management.service.ts
|
||||
│ │ │ ├── role-management.service.ts
|
||||
│ │ │ └── regional-scoping.service.ts
|
||||
│ │ ├── master-data/
|
||||
│ │ │ └── master-data.service.ts
|
||||
│ │ └── notification/
|
||||
│ │ ├── sms.service.ts
|
||||
│ │ └── push-notification.service.ts
|
||||
│ ├── models/
|
||||
│ │ ├── user.model.ts
|
||||
│ │ ├── dealer.model.ts
|
||||
│ │ ├── application.model.ts
|
||||
│ │ ├── workflow.model.ts
|
||||
│ │ ├── approval.model.ts
|
||||
│ │ ├── field-visit.model.ts
|
||||
│ │ ├── claim.model.ts
|
||||
│ │ ├── document.model.ts
|
||||
│ │ ├── master.model.ts
|
||||
│ │ ├── template.model.ts
|
||||
│ │ ├── workflow-template.model.ts
|
||||
│ │ ├── ocr-result.model.ts
|
||||
│ │ ├── digital-signature.model.ts
|
||||
│ │ ├── role.model.ts
|
||||
│ │ ├── permission.model.ts
|
||||
│ │ ├── regional-scope.model.ts
|
||||
│ │ └── notification.model.ts
|
||||
│ ├── routes/
|
||||
│ │ ├── auth.routes.ts
|
||||
│ │ ├── dealer.routes.ts
|
||||
│ │ ├── workflow.routes.ts
|
||||
│ │ ├── field-visit.routes.ts
|
||||
│ │ ├── claim.routes.ts
|
||||
│ │ ├── report.routes.ts
|
||||
│ │ ├── master.routes.ts
|
||||
│ │ ├── template.routes.ts
|
||||
│ │ ├── ocr.routes.ts
|
||||
│ │ ├── digital-signature.routes.ts
|
||||
│ │ ├── user-management.routes.ts
|
||||
│ │ └── notification.routes.ts
|
||||
│ ├── middleware/
|
||||
│ │ ├── auth.middleware.ts
|
||||
│ │ ├── role.middleware.ts
|
||||
│ │ ├── validation.middleware.ts
|
||||
│ │ ├── error.middleware.ts
|
||||
│ │ └── logging.middleware.ts
|
||||
│ ├── validators/
|
||||
│ │ ├── dealer.validator.ts
|
||||
│ │ ├── workflow.validator.ts
|
||||
│ │ ├── claim.validator.ts
|
||||
│ │ └── common.validator.ts
|
||||
│ ├── utils/
|
||||
│ │ ├── logger.ts
|
||||
│ │ ├── response.ts
|
||||
│ │ ├── error-handler.ts
|
||||
│ │ ├── file-upload.ts
|
||||
│ │ └── date-helper.ts
|
||||
│ ├── jobs/
|
||||
│ │ ├── email-reminder.job.ts
|
||||
│ │ ├── application-expiry.job.ts
|
||||
│ │ └── ff-notification.job.ts
|
||||
│ ├── types/
|
||||
│ │ ├── express.d.ts
|
||||
│ │ └── custom.types.ts
|
||||
│ └── app.ts
|
||||
├── bpmn/
|
||||
│ ├── dealer-onboarding.bpmn
|
||||
│ ├── dealer-offboarding.bpmn
|
||||
│ ├── field-visit.bpmn
|
||||
│ └── claim-settlement.bpmn
|
||||
├── tests/
|
||||
│ ├── unit/
|
||||
│ ├── integration/
|
||||
│ └── e2e/
|
||||
├── scripts/
|
||||
│ ├── seed-data.ts
|
||||
│ └── deploy-bpmn.ts
|
||||
├── .env
|
||||
├── .env.development
|
||||
├── .env.production
|
||||
├── tsconfig.json
|
||||
├── package.json
|
||||
└── README.md
|
||||
```
|
||||
|
||||
## 🗂️ Database Structure (PostgreSQL)
|
||||
|
||||
**Note:** Updated from MongoDB to PostgreSQL for better ACID compliance, complex queries, and enterprise integration requirements.
|
||||
|
||||
```
|
||||
Tables:
|
||||
├── users
|
||||
├── roles
|
||||
├── permissions
|
||||
├── regional_scopes
|
||||
├── dealers
|
||||
├── applications
|
||||
├── questionnaires
|
||||
├── evaluations
|
||||
├── approvals
|
||||
├── workflows
|
||||
├── workflow_templates
|
||||
├── template_instances
|
||||
├── field_visits
|
||||
├── claims
|
||||
├── documents
|
||||
├── ocr_results
|
||||
├── digital_signatures
|
||||
├── notifications
|
||||
├── audit_logs
|
||||
├── masters
|
||||
│ ├── towns
|
||||
│ ├── dealer_codes
|
||||
│ ├── evaluation_criteria
|
||||
│ └── workflow_definitions
|
||||
├── reports_cache
|
||||
├── sms_logs
|
||||
├── push_notifications
|
||||
└── website_integrations
|
||||
```
|
||||
|
||||
## 📅 Sprint-wise Breakdown (16-18 Weeks)
|
||||
|
||||
### **Sprint 0: Setup & Infrastructure (1 Week)**
|
||||
**Duration:** Week 1
|
||||
|
||||
**Frontend Tasks:**
|
||||
- [ ] Initialize React.js project with Create React App or Vite
|
||||
- [ ] Setup Tailwind CSS
|
||||
- [ ] Configure folder structure
|
||||
- [ ] Setup Redux Toolkit for state management
|
||||
- [ ] Configure Axios interceptors
|
||||
- [ ] Setup React Router DOM for routing
|
||||
- [ ] Configure authentication scaffolding
|
||||
|
||||
**Backend Tasks:**
|
||||
- [ ] Initialize Node.js/Express project
|
||||
- [ ] Setup PostgreSQL connection with Prisma ORM
|
||||
- [ ] Configure Camunda/Newgen integration
|
||||
- [ ] Setup JWT authentication
|
||||
- [ ] Configure email service (SMTP)
|
||||
- [ ] Setup logging middleware
|
||||
- [ ] Configure CORS and security headers
|
||||
|
||||
**DevOps:**
|
||||
- [ ] Setup Git repository
|
||||
- [ ] Configure CI/CD pipeline
|
||||
- [ ] Setup development environment
|
||||
|
||||
---
|
||||
|
||||
### **Sprint 1: Authentication & User Management (2 Weeks)**
|
||||
**Duration:** Week 2-3
|
||||
|
||||
**Frontend Tasks:**
|
||||
- [ ] Login page with AD integration using React Router
|
||||
- [ ] User registration form with React Hook Form
|
||||
- [ ] Role management UI with Material-UI components
|
||||
- [ ] User profile page with responsive design
|
||||
- [ ] Dashboard layout with sidebar/header navigation
|
||||
|
||||
**Backend Tasks:**
|
||||
- [ ] Implement AD authentication
|
||||
- [ ] JWT token generation and validation
|
||||
- [ ] User CRUD operations
|
||||
- [ ] Role-based access control (RBAC)
|
||||
- [ ] User profile management APIs
|
||||
|
||||
**Integration Points:**
|
||||
- Login API → Frontend auth flow
|
||||
- User registration → Email notification
|
||||
- Role assignment → Permission matrix
|
||||
|
||||
**Deliverable:** Fully functional authentication system
|
||||
|
||||
---
|
||||
|
||||
### **Sprint 2: Master Data Management (1 Week)**
|
||||
**Duration:** Week 4
|
||||
|
||||
**Frontend Tasks:**
|
||||
- [ ] Master data management UI (towns, dealer codes, evaluation criteria, workflow definitions)
|
||||
- [ ] CRUD forms for masters with validation
|
||||
- [ ] Data tables with advanced filters and search
|
||||
- [ ] Bulk upload functionality with progress tracking
|
||||
- [ ] Master data versioning and audit trail
|
||||
|
||||
**Backend Tasks:**
|
||||
- [ ] Master data APIs (CRUD with proper validation)
|
||||
- [ ] Data validation and business rules
|
||||
- [ ] Bulk upload processing with error handling
|
||||
- [ ] Master data synchronization with external systems
|
||||
- [ ] Audit logging for all master data changes
|
||||
|
||||
**Integration Points:**
|
||||
- Master data APIs → Frontend forms
|
||||
- File upload → Backend processing with validation
|
||||
- External system sync → Master data updates
|
||||
|
||||
---
|
||||
|
||||
### **Sprint 2.5: Custom Workflow Engine (1 Week)**
|
||||
**Duration:** Week 4.5
|
||||
|
||||
**Frontend Tasks:**
|
||||
- [ ] Templatized workflow builder UI
|
||||
- [ ] Non-templatized workflow creation interface
|
||||
- [ ] Template selection and configuration
|
||||
- [ ] Dynamic role assignment interface
|
||||
- [ ] Workflow visualization and monitoring
|
||||
- [ ] Exception handling and escalation UI
|
||||
|
||||
**Backend Tasks:**
|
||||
- [ ] Templatized workflow engine implementation
|
||||
- [ ] Non-templatized workflow engine implementation
|
||||
- [ ] Template builder service with validation
|
||||
- [ ] Dynamic role assignment logic
|
||||
- [ ] Exception handling and escalation matrix
|
||||
- [ ] Workflow state management and persistence
|
||||
|
||||
**Integration Points:**
|
||||
- Workflow templates → Business process automation
|
||||
- Dynamic workflows → Ad-hoc process handling
|
||||
- Template builder → Workflow configuration
|
||||
|
||||
**Deliverable:** Fully functional custom workflow engine supporting both templatized and non-templatized workflows
|
||||
|
||||
---
|
||||
|
||||
### **Sprint 3-5: Dealer Onboarding Module (Phase 1) (3 Weeks)**
|
||||
**Duration:** Week 5-7
|
||||
|
||||
#### **Sprint 3: Application Capture**
|
||||
|
||||
**Frontend Tasks:**
|
||||
- [ ] "Become a Dealer" form integration
|
||||
- [ ] Application listing with filters
|
||||
- [ ] Application detail view
|
||||
- [ ] Questionnaire web form
|
||||
|
||||
**Backend Tasks:**
|
||||
- [ ] Website form integration API ("Become a Dealer" form capture)
|
||||
- [ ] Real-time/hourly data synchronization from RE website
|
||||
- [ ] Application capture and storage with validation
|
||||
- [ ] Auto-acknowledgment email with template engine
|
||||
- [ ] Opportunity/Non-opportunity email logic with vacancy checking
|
||||
- [ ] Questionnaire generation and scoring with weighted ranking
|
||||
- [ ] D+2 and D+5 reminder emails (cron job with configurable TAT)
|
||||
- [ ] Third-party FDD auditor integration with OTP-protected links
|
||||
|
||||
**Integration:**
|
||||
- Form submission → Backend processing → Email trigger
|
||||
- Questionnaire link → Form submission → Scoring
|
||||
|
||||
#### **Sprint 4: Evaluation & Assignment**
|
||||
|
||||
**Frontend Tasks:**
|
||||
- [ ] Shortlisting interface for DD team
|
||||
- [ ] Evaluation form for ZM-DD
|
||||
- [ ] Assignment workflow UI
|
||||
- [ ] Approval tracking dashboard
|
||||
|
||||
**Backend Tasks:**
|
||||
- [ ] Ranking algorithm implementation
|
||||
- [ ] Assignment workflow (DD → ZM-DD → RBM → DDL)
|
||||
- [ ] Approval logic with rejection handling
|
||||
- [ ] Camunda workflow integration
|
||||
|
||||
**Integration:**
|
||||
- Assignment actions → Workflow engine → Email notifications
|
||||
- Status updates → Real-time dashboard refresh
|
||||
|
||||
#### **Sprint 5: Financial & Legal Approvals**
|
||||
|
||||
**Frontend Tasks:**
|
||||
- [ ] FDD report upload interface
|
||||
- [ ] NBH approval UI
|
||||
- [ ] Document management interface
|
||||
|
||||
**Backend Tasks:**
|
||||
- [ ] OTP-protected link generation
|
||||
- [ ] FDD report processing
|
||||
- [ ] NBH approval workflow
|
||||
- [ ] Document storage (DMS integration)
|
||||
|
||||
---
|
||||
|
||||
### **Sprint 5.5: OCR & Digital Signature Integration (1 Week)**
|
||||
**Duration:** Week 7.5
|
||||
|
||||
**Frontend Tasks:**
|
||||
- [ ] Document upload interface with OCR preview
|
||||
- [ ] Digital signature capture and validation UI
|
||||
- [ ] OCR result display and verification
|
||||
- [ ] Document comparison and validation interface
|
||||
- [ ] Signature verification and audit trail
|
||||
|
||||
**Backend Tasks:**
|
||||
- [ ] OCR service integration (third-party API)
|
||||
- [ ] Document processing and text extraction
|
||||
- [ ] Digital signature validation and storage
|
||||
- [ ] Document verification and comparison logic
|
||||
- [ ] Audit trail for all document operations
|
||||
- [ ] Secure document storage with encryption
|
||||
|
||||
**Integration Points:**
|
||||
- Document upload → OCR processing → Validation
|
||||
- Digital signatures → Secure storage → Audit trail
|
||||
- Document verification → Workflow automation
|
||||
|
||||
**Deliverable:** Complete OCR and digital signature functionality for document processing workflows
|
||||
|
||||
---
|
||||
|
||||
### **Sprint 6-7: Dealer Onboarding (Phase 2) (2 Weeks)**
|
||||
**Duration:** Week 8-9
|
||||
|
||||
**Frontend Tasks:**
|
||||
- [ ] LOI/LOA generation UI
|
||||
- [ ] EOR audit scheduling interface
|
||||
- [ ] Dealer information capture form
|
||||
- [ ] Onboarding completion dashboard
|
||||
|
||||
**Backend Tasks:**
|
||||
- [ ] LOI/LOA auto-generation
|
||||
- [ ] Email automation with CC
|
||||
- [ ] EOR audit workflow
|
||||
- [ ] Dealer code assignment
|
||||
- [ ] Integration with SAP (dealer creation)
|
||||
|
||||
**Integration:**
|
||||
- Document generation → Email → Storage
|
||||
- SAP API integration → Dealer code sync
|
||||
|
||||
---
|
||||
|
||||
### **Sprint 8-9: Dealer Offboarding (2 Weeks)**
|
||||
**Duration:** Week 10-11
|
||||
|
||||
**Frontend Tasks:**
|
||||
- [ ] Resignation submission form
|
||||
- [ ] Termination process UI
|
||||
- [ ] F&F tracking dashboard
|
||||
- [ ] Multi-level approval interface
|
||||
|
||||
**Backend Tasks:**
|
||||
- [ ] Resignation workflow (ZBH → DD Lead → NBH)
|
||||
- [ ] Termination workflow (ZBH → DD Lead → NBH → CCO → CEO)
|
||||
- [ ] Resignation acceptance letter generation
|
||||
- [ ] Termination notice generation
|
||||
- [ ] F&F process tracking
|
||||
- [ ] Stakeholder notification system
|
||||
- [ ] Dealer blocking logic
|
||||
|
||||
**Integration:**
|
||||
- Resignation/Termination → Approval workflow → F&F initiation
|
||||
- F&F tracking → Email reminders → Status updates
|
||||
|
||||
---
|
||||
|
||||
### **Sprint 10-11: Field Visit Report Module (2 Weeks)**
|
||||
**Duration:** Week 12-13
|
||||
|
||||
**Frontend Tasks:**
|
||||
- [ ] FJC planning interface
|
||||
- [ ] Visit execution forms
|
||||
- [ ] Discussion management UI
|
||||
- [ ] MOM creation and tracking
|
||||
- [ ] Document sharing interface
|
||||
|
||||
**Backend Tasks:**
|
||||
- [ ] FJC planning APIs
|
||||
- [ ] Visit scheduling and re-planning logic
|
||||
- [ ] Discussion capture and storage
|
||||
- [ ] MOM generation
|
||||
- [ ] Approval workflow
|
||||
- [ ] Document archiving
|
||||
|
||||
**Integration:**
|
||||
- Planning → Execution → MOM → Approval → Archive
|
||||
|
||||
---
|
||||
|
||||
### **Sprint 12-13: Dealer Claim Settlement Module (2 Weeks)**
|
||||
**Duration:** Week 14-15
|
||||
|
||||
**Frontend Tasks:**
|
||||
- [ ] Activity request form
|
||||
- [ ] Proposal submission interface
|
||||
- [ ] Evaluation and approval UI
|
||||
- [ ] Claim approval workflow
|
||||
- [ ] Budget tracking dashboard
|
||||
|
||||
**Backend Tasks:**
|
||||
- [ ] Request initiation workflow
|
||||
- [ ] Proposal evaluation logic
|
||||
- [ ] Multi-level approval (Requestor → Dept Lead)
|
||||
- [ ] Budget blocking (IO integration)
|
||||
- [ ] Activity creation automation
|
||||
- [ ] Claim approval logic
|
||||
- [ ] E-invoice and credit note generation
|
||||
|
||||
**Integration:**
|
||||
- Request → Proposal → Approval → Budget → Activity → Claim
|
||||
|
||||
---
|
||||
|
||||
### **Sprint 14: Reports & Analytics (1 Week)**
|
||||
**Duration:** Week 16
|
||||
|
||||
**Frontend Tasks:**
|
||||
- [ ] Report listing with advanced filters and search
|
||||
- [ ] Interactive dashboard widgets with real-time updates
|
||||
- [ ] Excel/PDF export functionality with custom formatting
|
||||
- [ ] Real-time metrics display with WebSocket integration
|
||||
- [ ] Report scheduling and automated delivery
|
||||
- [ ] Custom report builder interface
|
||||
|
||||
**Backend Tasks:**
|
||||
- [ ] **Dealer-wise Report API** - Comprehensive dealer performance and status reports
|
||||
- [ ] **MIS Report API** - Management Information System reports with KPIs
|
||||
- [ ] **Pending Request Report API** - All pending requests with aging analysis
|
||||
- [ ] **F&F Tracking Report API** - Full & Final settlement tracking by stakeholder
|
||||
- [ ] **Application Summary Report API** - Application pipeline and conversion metrics
|
||||
- [ ] Dashboard metrics API with real-time data
|
||||
- [ ] Excel/PDF generation logic with custom templates
|
||||
- [ ] Report caching and performance optimization
|
||||
|
||||
---
|
||||
|
||||
### **Sprint 15: Notifications & Cron Jobs (1 Week)**
|
||||
**Duration:** Week 17
|
||||
|
||||
**Frontend Tasks:**
|
||||
- [ ] Notification preferences management UI
|
||||
- [ ] Real-time notification display with toast messages
|
||||
- [ ] Notification history and tracking interface
|
||||
- [ ] Multi-channel notification configuration
|
||||
|
||||
**Backend Tasks:**
|
||||
- [ ] **Email Notification Service** - Template-based email with delivery tracking
|
||||
- [ ] **SMS Notification Service** - Bulk SMS with delivery confirmation
|
||||
- [ ] **Push Notification Service** - Firebase integration for mobile/web push
|
||||
- [ ] Email reminder cron jobs with configurable schedules
|
||||
- [ ] Application expiry job with escalation
|
||||
- [ ] F&F reminder job with stakeholder notifications
|
||||
- [ ] Approval pending reminder job with aging alerts
|
||||
- [ ] Multi-channel notification orchestration
|
||||
- [ ] Notification delivery tracking and analytics
|
||||
|
||||
---
|
||||
|
||||
### **Sprint 16: Testing & Bug Fixes (1 Week)**
|
||||
**Duration:** Week 18
|
||||
|
||||
**Tasks:**
|
||||
- [ ] Unit testing
|
||||
- [ ] Integration testing
|
||||
- [ ] UAT support
|
||||
- [ ] Bug fixes
|
||||
- [ ] Performance optimization
|
||||
|
||||
---
|
||||
|
||||
## 🔄 Frontend-Backend Integration Strategy
|
||||
|
||||
### **Parallel Development Approach**
|
||||
|
||||
```
|
||||
Week 1: Setup (Both teams working on infrastructure)
|
||||
├── Frontend: Project setup, authentication UI
|
||||
└── Backend: Project setup, authentication APIs
|
||||
|
||||
Week 2-3: Authentication Module
|
||||
├── Frontend builds login → Backend provides APIs → Integration
|
||||
└── Daily sync meetings for API contract review
|
||||
|
||||
Week 4: Master Data
|
||||
├── Frontend builds CRUD UI → Backend provides APIs → Integration
|
||||
└── Mock data used initially, then real API integration
|
||||
|
||||
Week 5-7: Dealer Onboarding (Phase 1)
|
||||
├── Frontend builds forms → Backend builds workflow → Integration
|
||||
├── Mock APIs used for frontend development
|
||||
└── Real integration after backend APIs are ready
|
||||
|
||||
... (Pattern continues for all sprints)
|
||||
```
|
||||
|
||||
### **Integration Milestones**
|
||||
|
||||
1. **End of Sprint 1:** Authentication working end-to-end
|
||||
2. **End of Sprint 2:** Master data management working
|
||||
3. **End of Sprint 5:** Dealer onboarding (Phase 1) fully integrated
|
||||
4. **End of Sprint 7:** Complete onboarding cycle working
|
||||
5. **End of Sprint 9:** Offboarding workflows integrated
|
||||
6. **End of Sprint 11:** Field visit module integrated
|
||||
7. **End of Sprint 13:** Claim settlement module integrated
|
||||
8. **End of Sprint 14:** All reports working
|
||||
|
||||
### **Daily Integration Workflow**
|
||||
|
||||
```
|
||||
Morning Standup (15 mins)
|
||||
├── Frontend team shares progress
|
||||
├── Backend team shares API status
|
||||
└── Identify integration blockers
|
||||
|
||||
Mid-day Sync (as needed)
|
||||
├── API contract review
|
||||
├── Mock data alignment
|
||||
└── Quick integration tests
|
||||
|
||||
End of Day
|
||||
├── Code push to develop branch
|
||||
├── Integration testing on dev environment
|
||||
└── Bug logging in ZOHO
|
||||
```
|
||||
|
||||
### **API Development Process**
|
||||
|
||||
```
|
||||
1. Backend team creates API documentation (Swagger/Postman)
|
||||
2. Frontend team reviews and provides feedback
|
||||
3. Backend implements APIs
|
||||
4. Frontend uses mock APIs during development
|
||||
5. Integration happens when backend APIs are ready
|
||||
6. Testing on dev environment
|
||||
7. Bug fixes and optimization
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🛠️ Technology Stack
|
||||
|
||||
### Frontend
|
||||
- **Framework:** React.js 18+ (Create React App / Vite)
|
||||
- **Language:** JavaScript (ES6+) - Updated from TypeScript for simplicity
|
||||
- **Styling:** Tailwind CSS
|
||||
- **State Management:** Redux Toolkit / Zustand
|
||||
- **API Client:** Axios
|
||||
- **Form Handling:** React Hook Form + Yup
|
||||
- **UI Components:** Material-UI / Ant Design
|
||||
- **Charts:** Recharts / Chart.js
|
||||
- **Date Handling:** date-fns
|
||||
- **Routing:** React Router DOM
|
||||
- **Build Tool:** Webpack / Vite
|
||||
|
||||
### Backend
|
||||
- **Runtime:** Node.js 20+
|
||||
- **Framework:** Express.js
|
||||
- **Language:** TypeScript
|
||||
- **Database:** PostgreSQL (Updated from MongoDB for better ACID compliance and enterprise integration)
|
||||
- **ORM:** Prisma (Updated from Mongoose for PostgreSQL compatibility)
|
||||
- **Authentication:** JWT + Passport.js
|
||||
- **BPM Platform:** Camunda Zeebe (or Newgen)
|
||||
- **Email:** Nodemailer
|
||||
- **Validation:** Joi / Zod
|
||||
- **Logging:** Winston
|
||||
- **Cron Jobs:** node-cron
|
||||
|
||||
### DevOps
|
||||
- **Version Control:** Git (GitLab)
|
||||
- **Project Management:** ZOHO PMS
|
||||
- **CI/CD:** GitLab CI or Jenkins
|
||||
- **Hosting:** TBD (AWS/Azure)
|
||||
|
||||
---
|
||||
|
||||
|
||||
|
||||
## 📝 Key Integration Points
|
||||
|
||||
1. **Authentication Flow**
|
||||
- AD login → JWT token → Protected routes → Role-based access
|
||||
|
||||
2. **Website Integration**
|
||||
- "Become a Dealer" form → Real-time sync → Application processing
|
||||
|
||||
3. **Dealer Onboarding Flow**
|
||||
- Form submission → Workflow engine → Multi-level approvals → Multi-channel notifications
|
||||
|
||||
4. **Custom Workflow Engine**
|
||||
- Template selection → Dynamic role assignment → Process execution → Exception handling
|
||||
|
||||
5. **Document Management**
|
||||
- File upload → OCR processing → Digital signature → Secure storage → DMS integration
|
||||
|
||||
6. **SAP Integration**
|
||||
- Dealer creation → Budget blocking → Invoice generation → Code synchronization
|
||||
|
||||
7. **Multi-Channel Notifications**
|
||||
- Workflow events → Template engine → Email/SMS/Push dispatch → Delivery tracking
|
||||
|
||||
8. **Third-Party Integrations**
|
||||
- FDD auditor links → OTP validation → Document upload → Processing
|
||||
|
||||
9. **Real-time Updates**
|
||||
- WebSocket/SSE for dashboard updates → Live notifications → Status tracking
|
||||
|
||||
10. **Reporting Integration**
|
||||
- Data aggregation → Report generation → Export functionality → Scheduled delivery
|
||||
|
||||
---
|
||||
|
||||
## ✅ Best Practices
|
||||
|
||||
1. **API Versioning:** Use `/api/v1/` prefix
|
||||
2. **Error Handling:** Consistent error response format
|
||||
3. **Logging:** Log all API calls and errors
|
||||
4. **Documentation:** Keep API documentation updated
|
||||
5. **Code Reviews:** Mandatory for all PRs
|
||||
6. **Testing:** Minimum 70% code coverage
|
||||
7. **Security:** Input validation, SQL injection prevention, XSS protection
|
||||
|
||||
## 🔒 Enhanced Security & Compliance Features
|
||||
|
||||
### **DPDP Act Compliance**
|
||||
- Data minimization and purpose limitation
|
||||
- Explicit consent management with audit trails
|
||||
- Data subject rights (access, portability, deletion)
|
||||
- Data localization within India
|
||||
- Breach notification within 72 hours
|
||||
- Privacy by design implementation
|
||||
|
||||
### **Advanced Security Measures**
|
||||
- WAF (Web Application Firewall) protection
|
||||
- MFA (Multi-Factor Authentication) for sensitive roles
|
||||
- JWT token management with secure rotation
|
||||
- Field-level encryption for sensitive data
|
||||
- Secure document storage with AES-256 encryption
|
||||
- Comprehensive audit logging for compliance
|
||||
|
||||
### **Access Control & Authorization**
|
||||
- Role-based access control (RBAC) with granular permissions
|
||||
- Regional scoping for data access
|
||||
- Principle of least privilege implementation
|
||||
- Session management with automatic timeout
|
||||
- API rate limiting and abuse prevention
|
||||
|
||||
---
|
||||
|
||||
@ -0,0 +1,649 @@
|
||||
|
||||
|
||||
|
||||
Revision History
|
||||
Project
|
||||
Workflow Management and dealer onboarding
|
||||
Deliverable
|
||||
Proposal document
|
||||
|
||||
Executive Summary
|
||||
Royal Enfield is an Indian multinational motorcycle manufacturing company headquartered in Chennai, Tamil Nadu, India. The Royal Enfield brand, The oldest motorcycle brand in continuous production, Royal Enfield made its first motorcycle in 1901. A division of Eicher Motors Limited, Royal Enfield has created the mid-size motorcycle segment in India with its unique and distinctive modern classic motorcycles. The company operates manufacturing plants in Chennai in India.
|
||||
Softude is a global IT consulting and services company established in 2005, specializing in digital transformation and software product engineering. With over 4000 successful projects delivered, our innovative software solutions are used in 32+ countries, connecting audiences across various industries. Our highly skilled team delivers exceptional digital solutions that accelerate our clients' digital-first journey.
|
||||
Our team has extensive expertise in the development and implementation of customised solutions specifically designed for the automotive industry. We have a deep understanding of the unique challenges and requirements faced by automotive operation teams, allowing us to provide highly specialized and effective solutions.
|
||||
In developing our response, we have considered our experiences associated with:
|
||||
With 30years + experience in automotive industry and having good expertise encompasses various aspects of the industry.
|
||||
Scope
|
||||
Approach: Custom Platform development through BPM Platforms
|
||||
1. Camunda Zeebe (Opensource) or
|
||||
2. Newgen (Saas)
|
||||
The scope of this project includes the design, development, testing, and deployment of a workflow platform using BPM Platforms (Saas), Customizable with the following key features:
|
||||
* Front-end Development: Build a user-friendly interface using Next.js
|
||||
* Back-end Development: Implement robust back-end services using technologies compatible with MongoDB.
|
||||
* Database Management: Utilize MongoDB for data storage and retrieval.
|
||||
* Enterprise Integration: Develop integration capabilities with SAP and DMS systems.
|
||||
* User Management: Implement secure user authentication and authorization with Single Sign-On (SSO).
|
||||
* Workflow Automation: Create tools for designing, automating, and adding new workflows.
|
||||
* Access Control: Implement role-based access control to manage user permissions.
|
||||
Reporting and Analytics: Provide reporting dashboards to monitor workflow performance.
|
||||
Note: Considering 5 reports and one Dashboard with
|
||||
Develop a workflow platform for below mentioned services. The platform will use Next.js for the front-end, MongoDB for data storage, and provide back-end interfacing capabilities with enterprise applications like SAP and DMS.
|
||||
Current Scope:
|
||||
The initial scope of this project includes the development of the following workflows:
|
||||
* Dealer Onboarding/Offboarding Process
|
||||
* Field Visit Report & Action Plan
|
||||
* Dealer Claim Management
|
||||
|
||||
|
||||
Project 1: Dealer Onboarding and Offboarding
|
||||
Below is the feature listing we have considered based on our discussion on the requirements
|
||||
1. Master Module: This module includes the master data that is used in various stages of the process. It includes data such as prospect details, evaluation criteria, town list, dealer codes, etc. The role of this module is to maintain and update the master data as required.
|
||||
2. Workflow Module: This module defines the workflow of the entire process, including the sequence of activities, approvals, and notifications. It ensures that the process flows smoothly from one stage to another. The role of this module is to automate and manage the workflow of the process. Implementation based on the proposed document
|
||||
3. Onboarding Process Module: This module focuses on the onboarding process of the selected candidates. It includes activities such as LOI issuance, document submission, evaluation, final interview presentation, etc. this module is to facilitate and track the onboarding process of the selected candidates.
|
||||
* Sending opportunity link emails to applicants in vacant locations. (manual)
|
||||
* Create the application form and collecting dealer application responses through a form and calculating scores based on predefined criteria.
|
||||
* Providing alerts for non-respondents to the dealer application form at different stages based on the defined TAT
|
||||
* Sharing top candidate lists for further evaluation
|
||||
* Sending reminder emails to non-respondents of the dealer application form.
|
||||
* Data Collection: Creating forms or input fields to collect data from users
|
||||
* Data Storage: Storing collected data in a database or file system, Document Management: Uploading, organizing, and hold documents within the software.
|
||||
* Retrieving and displaying stored data based on user queries or filters. And roles and access.
|
||||
* Enforcing data validation rules to ensure data integrity and accuracy.
|
||||
* Task Assignment and Tracking: Assigning tasks to users and tracking their progress.
|
||||
* Feedback and marks: Allowing users to provide feedback or reviews(marks) on certain stages from respective role.
|
||||
* Plan and conducting face-to-face interviews and evaluations with prospects. And provide option to input marks
|
||||
* Manual process: Conducting ASM first interactions, RBM and ZM-DD interviews, DD Lead and ZBH interviews.
|
||||
|
||||
4. Role Module: This module defines the roles and access rights of different users involved in the process, list of role is defined are Admin ID, DD Lead, IT Team, ZM DD, RBM, ZBH, NBH. It ensures that each user has the appropriate access and permissions to perform their tasks.
|
||||
The role of this module is to manage and assign roles to the users. Please note that the specific details and functionalities of each module may vary based on the actual implementation and system requirements.
|
||||
Access Control: Implementing different levels of access for users based on their roles and permissions.
|
||||
Role-based Dashboards: Creating customized dashboards for different user roles to display relevant information.
|
||||
|
||||
5. Reporting module
|
||||
Reporting and Analytics: Generating reports and conducting data analysis on the collected data. We will create list of 5 reports which will provide the data in defined format with filer and excel export.
|
||||
#
|
||||
Module
|
||||
Task
|
||||
Subtask
|
||||
1
|
||||
Database design
|
||||
Create database tables
|
||||
1) Database and tables creation
|
||||
2
|
||||
Inquiry capture and initial response
|
||||
Automate "Become a Dealer" Form Capture.
|
||||
1) Integrate with RE official website to fetch form data in real-time or on an hourly basis.
|
||||
|
||||
|
||||
|
||||
2) Store data in the system for record-keeping and show the listing on the system along with the filers
|
||||
|
||||
|
||||
Automated Acknowledgement Email
|
||||
1)Configure an email template with placeholders for applicant details.
|
||||
|
||||
|
||||
|
||||
2) Send an automated email to acknowledge the enquiry.
|
||||
|
||||
|
||||
Automated Non-Opportunity Email
|
||||
1) Identify locations with no vacancy and send a rejection email.
|
||||
|
||||
|
||||
|
||||
2) Configure email templates with dynamic placeholders
|
||||
|
||||
|
||||
Opportunity Email with Questionnaire
|
||||
1) Create a web link for the questionnaire with:
|
||||
Objective questions.
|
||||
- Fill-in-the-blank responses.
|
||||
- File upload options.
|
||||
- Free text boxes.
|
||||
|
||||
|
||||
|
||||
2) Configure and send email containing the web link
|
||||
3
|
||||
Questionnaire Processing
|
||||
Assign Weightage to Questionnaire Responses
|
||||
1) Develop logic to calculate rank based on weighted responses
|
||||
|
||||
|
||||
Automate Notifications for Incomplete Responses
|
||||
1) Configure email reminders at D+2 and D+5 days for pending responses
|
||||
|
||||
|
||||
Close Questionnaire on Expiry
|
||||
1) Allow configurable expiration date for the web link (default: 20 days).
|
||||
|
||||
|
||||
|
||||
2) Disable further responses after expiry.
|
||||
4
|
||||
Enquiry Shortlisting and Assignment
|
||||
Shortlisting by DD Team
|
||||
1) Enable manual assignment of top 10 prospects to Zonal Manager (ZM-DD) based on rank.
|
||||
|
||||
|
||||
|
||||
2) Capture reasons for shortlisting during assignment
|
||||
|
||||
|
||||
KT Evaluation by ZM-DD
|
||||
1) Allow ZM-DD to evaluate and mark prospects as shortlisted or rejected.
|
||||
|
||||
|
||||
Assign to Regional Business Manager (RBM)
|
||||
1) After evaluation leads comes to RBMs post-evaluation automatically. Allow RBM for evalution
|
||||
|
||||
|
||||
|
||||
2) Capture reasons for the assignment and store in the database
|
||||
|
||||
|
||||
Assign to DDL team
|
||||
1) Lead automatically assign to DDL team after approval of RBM.
|
||||
|
||||
|
||||
|
||||
2) Capture reason for the assignment and store in the database
|
||||
5
|
||||
Financial and Legal Approvals
|
||||
Upload Financial Due Diligence Reports
|
||||
1) Provide an upload option for third-party financial reports through link, link will be OTP protected over email and that will be expire after getting the response.
|
||||
2) FDD auditor for L1 and L2 , email for external agencies will be configured
|
||||
|
||||
|
||||
Submit Approval to NBH
|
||||
1) Allow DD Team to submit financial due diligence reports to NBH for approval
|
||||
|
||||
|
||||
|
||||
2) Store NBH approvals in the system
|
||||
6
|
||||
Dealer Onboarding
|
||||
Issue LOI (Letter of Intent)
|
||||
1) Automate LOI generation and email to prospects with CC to relevant teams
|
||||
|
||||
|
||||
|
||||
2) Enable file upload for LOI storage
|
||||
|
||||
|
||||
Issue LOA (Letter of Agreement)
|
||||
1) Automate LOA generation and email to prospects with CC to relevant teams
|
||||
|
||||
|
||||
|
||||
2) Enable file upload for LOA storage.
|
||||
|
||||
|
||||
Schedule EOR Audit
|
||||
1) Allow Regional DD Team to schedule and complete the audit.
|
||||
|
||||
|
||||
|
||||
2) Provide format and upload option for audit reports.
|
||||
|
||||
|
||||
EOR Approval
|
||||
1) Capture NBH approval for EOR audit with a file upload option
|
||||
|
||||
|
||||
Update Dealer Information
|
||||
1) Capture and store inauguration date, dealer codes for sales, service, GMA, and Gear.
|
||||
7
|
||||
Dealer Resignation Handling
|
||||
Resignation Submission
|
||||
1) Dealer will send email to ZBH and ZBH will take it forward and record in the system. we will manage the tracking of each activity.
|
||||
|
||||
|
||||
Approval Workflow
|
||||
1) Approval work flow work same as we are doing during onboarding, below are the level where we need to manage the approval/rejection flow.
|
||||
- Zonal Business Head (ZBH).
|
||||
- Dealer Development Lead (DD Lead).
|
||||
- National Business Head (NBH).
|
||||
|
||||
2) If request rejected at any level , the request will go back to its previous level automatically and there will be a mail notification for the same to the responsible person.
|
||||
|
||||
|
||||
Generate Resignation Acceptance Letter
|
||||
1) Automate legal format generation for resignation acceptance after final NBH approval
|
||||
|
||||
|
||||
|
||||
2) Enable NBH to approve and share the letter with predefined format with the dealer.
|
||||
8
|
||||
Dealer Termination Process
|
||||
Identify Termination Reasons
|
||||
1) Create categories: Business, CX Issues, Ethical Issues, and Unforeseen Circumstances
|
||||
2) Types of termination - a) Immediate termination b) Termination by convenience
|
||||
|
||||
|
||||
Collect and Upload Documentation
|
||||
1) Allow ASM to collect and upload all communication documents
|
||||
|
||||
|
||||
Prepare Termination Notes
|
||||
1) Automate generation of termination notes in pdf format
|
||||
|
||||
|
||||
Approval Workflow
|
||||
1) Approval work flow work same as we are doing during onboarding, below are the level where we need to manage the approval/rejection flow.
|
||||
- Zonal Business Head (ZBH).
|
||||
- Dealer Development Lead (DD Lead).
|
||||
- Dealer Development Lead (NBH).
|
||||
- Chief Commercial Officer (CCO).
|
||||
- Chief Executive Officer (CEO).
|
||||
|
||||
2) If request rejected at any level , the request will go back to its previous level automatically and there will be a mail notification for the same to the responsible person.
|
||||
|
||||
|
||||
Issue Termination Notice
|
||||
1) Automate show cause notice generation with legal concurrence.
|
||||
|
||||
|
||||
|
||||
2) Notify dealers with 15-day response deadlines
|
||||
|
||||
|
||||
Upload Signed Termination Letter
|
||||
1) Allow DD Lead to upload signed termination documents to the portal
|
||||
9
|
||||
Notifications and Reminders
|
||||
Automated Email Reminders
|
||||
1) Configure reminders for pending tasks (KT evaluations, approvals, Termination request pending, resignation request pending).
|
||||
2) Mail need to be configured for the same.
|
||||
3) Cron jobs need to be configured
|
||||
#
|
||||
Dashboard
|
||||
Dashboard for Process Monitoring
|
||||
1) Real-time dashboard showing the status of enquiries, approvals, and onboarding
|
||||
2) Displays a high-level overview of all ongoing processes and key metrics such as total inquiries, pending approvals, and current statuses
|
||||
#
|
||||
User Login Module
|
||||
Develop Login Interface
|
||||
1) Design a secure login page, which allow user to redirect to AD, System user login thorugh AD
|
||||
#
|
||||
System user management/registration
|
||||
Develop Registration Interface
|
||||
1) Design a user-friendly registration form
|
||||
|
||||
|
||||
|
||||
2) Collect user details:
|
||||
- Name.
|
||||
- Email.
|
||||
- Contact number.
|
||||
- Role (dropdown: Admin, Dealer Development, Regional Manager, etc.).
|
||||
Password (with complexity rules)
|
||||
3) Basic validation will be there.
|
||||
#
|
||||
Role Management Module
|
||||
|
||||
1) Role creation form along with the permission
|
||||
|
||||
|
||||
|
||||
2) Role Active/Inactive and listing with the filters
|
||||
#
|
||||
User Profile Management
|
||||
Design user profile page
|
||||
1) Need to create page for user profile , where user can see the information associated with him
|
||||
#
|
||||
Super admin access managment
|
||||
Master management and configurations
|
||||
1) Dealership vacancy management, Link expire configuration, All access by default, User listing, Role listing with filters.
|
||||
|
||||
|
||||
Multilevel actions
|
||||
1) Super admin can see all the activities and take any action of any role at any stage
|
||||
2) Masters management
|
||||
|
||||
|
||||
Approval flow configuration
|
||||
1) Provision to configure the approval flow for the below three activities
|
||||
- Onboarding approval flow
|
||||
- Resignation approval flow
|
||||
- Termination approval flow
|
||||
|
||||
Ex. in case of termination, process usually start with ZBH than DD Lead than NBH and so on, but it can be change later, RE can introduce new role in future or shuffle the approval flow and that can be configurable from the system only.
|
||||
|
||||
2) System will have an option to add stakeholders or roles for the F&F process from the system only and that can be configurable.
|
||||
#
|
||||
Reports
|
||||
Report listing with filters and download option
|
||||
1) We will provide below 4 report with filters
|
||||
|
||||
- Dealer wise report
|
||||
|
||||
-MIS report
|
||||
|
||||
-Pending request report dealer wise
|
||||
|
||||
- F&F tracking report stakeholder wise.
|
||||
|
||||
|
||||
2) Provide download option in excel.
|
||||
#
|
||||
F&F
|
||||
Notification of Resignation/Termination and start the F&F process
|
||||
1) Design mail template and circulate resignation/termination notification to all the stakeholders along with last working day of the dealer.
|
||||
2) Need to create cron job for the same
|
||||
3) DD team circulate the email to all the respective stakeholders for getting the F&F process concluded as per the defined TAT
|
||||
|
||||
Auto email notification for the same through system
|
||||
|
||||
|
||||
F&F request tracking
|
||||
1) Need to implement web page for the tracking the F&F process
|
||||
|
||||
|
||||
|
||||
2) need to manage stakeholder along with their task
|
||||
|
||||
|
||||
|
||||
3) set reminder mails if someone not doing their job in defined TAT
|
||||
|
||||
|
||||
|
||||
4) Provide an option for each role to update the status of their task
|
||||
5) When the respective stakeholder logs into the system, they can see their pending request. These requests will be segregated based on respective roles.
|
||||
6) Each role have their own forms and field which they will update from the system. Ex. finance team will see settlement related form, legal team will see clearance related forms etc.
|
||||
Note: couple of points are open ended
|
||||
|
||||
|
||||
Block dealer from the system
|
||||
1) Provide option to block the dealer from the system (This action will taken place after all the stakeholder status)
|
||||
|
||||
|
||||
|
||||
2) Email notification to all the stakeholders
|
||||
|
||||
Project 2: Field Visit Report & Action Plan
|
||||
Feature Listing
|
||||
Application Module
|
||||
Description
|
||||
FJC Planning
|
||||
- Document preparation
|
||||
|
||||
- Review and approval flow
|
||||
|
||||
- Dealer coordination
|
||||
Visit Execution
|
||||
- Field visit as per plan
|
||||
|
||||
- Re-plan if changes occur
|
||||
|
||||
- Dealer discussion
|
||||
Discussion Management
|
||||
- Capture actionable insights
|
||||
|
||||
- Record feedback and performance metrics
|
||||
MOM Creation
|
||||
- Structured documentation
|
||||
|
||||
- Action item tracking and delegation
|
||||
Closure & Sharing
|
||||
- Document submission and archiving
|
||||
|
||||
- Stakeholder communication
|
||||
Approval Workflow
|
||||
- Manage approval workflow as per managed hierarchy
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Project 3: Dealer Claim settlement:
|
||||
Feature Listing
|
||||
Process Step
|
||||
Scope Details
|
||||
1. Request Initiation
|
||||
Requestor (Marketing / Service / CNR) submits an activity request with:
|
||||
Activity type, dealer info, date/location, details, and period
|
||||
2. Proposal Submission
|
||||
Dealer submits a proposal with:
|
||||
Cost breakup
|
||||
Timeline for closure
|
||||
Supporting documents
|
||||
3. Request Evaluation
|
||||
Requestor reviews the proposal, adds comments, and either:
|
||||
Requests clarification or
|
||||
Confirms to proceed
|
||||
4. Dept. Lead Approval
|
||||
Department lead reviews the confirmed request and either:
|
||||
Approves it or
|
||||
Requests clarification
|
||||
5. Budgeting
|
||||
Upon approval, budget is blocked under respective IO (Internal Order)
|
||||
6. Activity Creation
|
||||
System creates the activity and sends auto-confirmation email to requestor, dealer, and lead
|
||||
7. Activity Execution
|
||||
Dealer executes the activity and submits required documents
|
||||
8. Claim Approval
|
||||
Requestor reviews documents and either
|
||||
Approves the claim (fully or partially)
|
||||
Requests more info
|
||||
9. E-Invoicing
|
||||
Upon approval:
|
||||
E-invoice is generated
|
||||
Credit note is issued
|
||||
|
||||
Roles involved managed and maintained in the masters
|
||||
Role & Persona:
|
||||
Requestors: Raise activity request, evaluate proposals, approve claims
|
||||
Dealers: Submit proposal and post-activity documents
|
||||
Dept. Lead: Approve activity requests
|
||||
Automation Handle system-level triggers (e.g., activity creation, Email Notofication)
|
||||
Out of scope:
|
||||
* Integrating with third-party systems or APIs to exchange data or functionality.
|
||||
* Dealer Offboarding process
|
||||
* Data collection form external system for old existing dealer
|
||||
* Any functionality which is not a part of shared PPT document can be consider as a new requirement or change request and not a part of current proposal and commercials.
|
||||
* Interface Layer (MSD/SAP) Interface with external systems for budgeting, invoicing, and credit note
|
||||
* Dealer Persona
|
||||
|
||||
Note: we considered the scope based on the shared BRD document attached (PPT)and the detailed discussion.
|
||||
Project Assumptions
|
||||
1. Royal Enfield will align and limit its requirements to adopt the Out of Box practice processes and features as delivered by the solution. No changes are expected to be made to the existing or dependent product.
|
||||
2. Royal Enfield will provide a team of business experts who will work with the Softude team and will respond to the queries, conduct the reviews, and give necessary signoffs within agreed timelines.
|
||||
3. Royal Enfield will take the responsibility of business readiness to achieve the proposed go-live milestone for the modules in scope of this statement of work.
|
||||
4. Royal Enfield will ensure availability of its project documentation, Subject Matter Experts (SMEs) and Process Owners for workshops, discussions, and clarifications for the Softude project team as per calendar (inclusive of any local holidays) published by Softude at project start.
|
||||
5. Project plan will be reviewed after the end of finalized Design (Modelling) phase with due consideration of any scope changes/ deviations. Any change that might have an impact on the scope, timeline, resources plan and any changes in the assumptions will be handled through a scope change management process (Change Order process).
|
||||
6. Change Management is a shared responsibility as per the Roles and Responsibility section and the success of this track will depend on both the parties delivering as per expectations.
|
||||
7. All interfaces for the new product have been identified in the scope. If any additional interfaces apart from identified needs to be developed, then additional effort would be considered and will be handled through a scope change management process (Change Order process).
|
||||
8. Any timeline delays not directly attributable to Softude (such as product procurement, any business constraints, delay from source or target systems providing required details, connectivity issues, firewall issues) potentially could have an impact on the overall schedule resulting in Change Order process.
|
||||
9. Any third-party access & authorizations will be made available to the Softude team within the first two weeks of project start.
|
||||
10. Any scope changes are assumed to follow the defined Change Order processes including approvals.
|
||||
11. The solution outlined in this document is based on current features or details shared by client in their scope document. Configuration of future enhancements, or enhancements released during the duration of the project, are not included. Any features which are going to be part of any new releases during the life cycle of the project will not be considered for implementation unless agreed upon as direction from product vendor/roadmap.
|
||||
12. Negotiations and Procuring the Software Licenses for any third party (if required), and any other applicable Systems and third-party Tools is the responsibility of Royal Enfield.
|
||||
Security Measures
|
||||
Most secure app infrastructure in the market where security extends from the mobile app to the API's.
|
||||
1. All APIs are secured with a wildcard SSL certificate.
|
||||
2. As a Best Practices we should use of JWT and JWE for securing all API's.
|
||||
3. Rate limit API and controller access to minimize the harm from automated attack tooling.
|
||||
4. App secured from any DB injection.
|
||||
5. App protected from clickjacking protection, XSS, MIME-Sniffing, HSTS, HPKP or set the CORS settings.
|
||||
6. Security headers are enabled.
|
||||
7. Code is not deployed with default credentials, particularly for admin users and even for mobile users.
|
||||
8. As a best practices, uses a server-side, secure, built-in session manager that generates a new random session ID with high entropy after login. Session IDs should not be in the URL. Ids should also be securely stored and invalidated after logout, idle, and absolute timeouts.
|
||||
9. As a best practices, JWT tokens are invalidated on the server after logout.
|
||||
Testing
|
||||
We put everything we make through rigorous user, compatibility, and functional testing to ensure it's bug-free on Day 1 and will continue to perform for you into the future.
|
||||
As standard, we implement the following tests in a controlled environment before the web application is launched:
|
||||
* Functionality Testing
|
||||
* Usability testing
|
||||
* Compatibility testing
|
||||
* Interface Testing
|
||||
* Performance Testing (Basic)
|
||||
* Security testing (Basic)
|
||||
* UAT Support
|
||||
We also continue testing and monitoring the application over the 2 weeks to ensure it's working as promised.
|
||||
Communication Plan
|
||||
Regular Update
|
||||
<EFBFBD> Softude will provide the regular update to the client bi-weekly as well as on the completion of the milestone, which will be mapped with the milestone plan.
|
||||
<EFBFBD> Softude will test the system before the delivery of every milestone delivery and then would provide the update to the client.
|
||||
Regular Meeting
|
||||
<EFBFBD> Softude would be available for the regular meeting to provide the demo at the completion of every milestone and to give a walkthrough.
|
||||
<EFBFBD> If needed, we can also plan a regular meeting as and when required.
|
||||
<EFBFBD> If required, the client can also visit our Indore (India) based headquarter for a personal meeting with the team.
|
||||
Communication Medium
|
||||
<EFBFBD> Updates will be provided via email.
|
||||
<EFBFBD> Meetings can be done using MS Teams/Zoom/Hangout or any of the preferred medium.
|
||||
<EFBFBD> Softude will use Zoho as a project management tool, if needed we also add the client to our system where they can also track regular progress.
|
||||
Technology stake and version
|
||||
Technology Usage
|
||||
Technology
|
||||
Licensed / Open Source
|
||||
User Experience (UX Design)
|
||||
Adobe XD
|
||||
Licensed
|
||||
User Interface (UI)
|
||||
React, View JS
|
||||
MIT License
|
||||
|
||||
HTML5/CSS/JS
|
||||
Standard
|
||||
|
||||
|
||||
|
||||
API Gateway
|
||||
Node Js
|
||||
Open Source
|
||||
Databases (RDBMS & NoSQL)
|
||||
MYSQL / postgresql
|
||||
VM setup
|
||||
Containers / App Servers
|
||||
Webserver
|
||||
Apache License 2.0
|
||||
Project Management / Collaboration Tool
|
||||
ZOHO PMS
|
||||
Licensed
|
||||
|
||||
Microsoft Teams
|
||||
Licensed
|
||||
Code Repo
|
||||
Gitlab
|
||||
Code Repository and Version Control
|
||||
|
||||
Assumptions
|
||||
* Customer will provide SAP APIs for integration.
|
||||
* Inputs provided from the customer in any terms will be assumed to be accurate.
|
||||
* Necessary approvals and timely review of submissions.
|
||||
* Customer will complete testing & UAT before handover.
|
||||
* Softude's timely and adequate performance of the services and provision of the deliverables shall depend upon full access to appropriate customer personal and to customer information and documentation.
|
||||
* Softude is not responsible for inaccurate or incomplete information that is obtained from customer.
|
||||
* Customer would provide needed documentation and information that would be crucial for execution of the task provided as applicable from time to time.
|
||||
* All the organizational or technical changes which may affect any services will be communicated in writing to Softude at least 1 week prior to changes.
|
||||
* Support of services that are outside scope, all such activities would be identified and discussed with Customer and will be owned with invoking required changed/configuration orders.
|
||||
* We assume for business-critical applications necessary HA architecture in place to meet the requirements.
|
||||
Out of Scope
|
||||
We include those items which are not considered in the budget that is defined in this proposal. Items like purchasing of third-party APIs, hosting, domain name, etc. Also, the list of items may vary depending on the communication you have with the client. Below are some references which you can use.
|
||||
1. Implementation of any module other than the modules mentioned in scope section.
|
||||
2. Implementation of any third party other than mentioned in the scope section.
|
||||
3. Any configuration and development work in existing on-premises systems or any interface development from On premise to On premise/third party vendors are not considered in scope
|
||||
4. Data cleansing, Data Quality related validation activities
|
||||
5. Purchase of any 3rd party controls/software licenses, if required during development
|
||||
6. Data creation is not in the scope.
|
||||
7. Data migration to the proposed application
|
||||
8. Any requirement which is not mentioned in the scope of work spreadsheet.
|
||||
Client Responsibilities
|
||||
We believe that successful partnerships are built on mutual trust and collaboration. As such, we would like to outline the responsibilities that we expect from our clients to ensure that we can deliver the best possible service. By fulfilling these responsibilities, our clients can help us to achieve our shared goals and ensure a successful outcome for all parties involved.
|
||||
Below are the client's responsibilities:
|
||||
1. Designate a project coordinator(s) at your end. This person should be helping us to understand the exact requirement in detail so that we can draft specifications and later on coordinating points for application support. (It may be one or multiple persons based on expertise in their function)
|
||||
2. Logic and business rules for all functionality
|
||||
3. Timely responses/feedback (within 3 days from submission) for
|
||||
a. Queries
|
||||
b. Document (like SRS/Screen design etc.)
|
||||
c. Demo
|
||||
d. UAT
|
||||
e. Implementation
|
||||
4. Change Control approval (within 7 days from submission)
|
||||
5. Provide hosting server (Deployment server)
|
||||
6. Licenses software, external components, or any tool. (If any)
|
||||
7. Make the server available with the required environment.
|
||||
8. Support required for coordination with third parties such as payment gateway, or other application developers involved for getting APIs.
|
||||
Proposed Methodology
|
||||
Waterfall Development Approach
|
||||
The Waterfall methodology-also known as the Waterfall model-is a sequential development process that flows like a waterfall through all phases of a project (analysis, design, development, and testing, for example), with each phase completely wrapping up before the next phase begins.
|
||||
The project is broken down into a sequence of tasks, with the highest level grouping referred to as phases. A true waterfall approach requires phases that are completed in sequence and have formal exit criteria, typically a sign-off by the project stakeholders. A typical list of waterfall tasks would include:
|
||||
* Scope and plan project
|
||||
* Gather and document requirements.
|
||||
* Design application
|
||||
* Develop application and perform unit tests.
|
||||
* Conduct system testing.
|
||||
* Perform UAT
|
||||
* Fix application as appropriate
|
||||
* Deploy application.
|
||||
|
||||
|
||||
Requirement
|
||||
The Waterfall methodology depends on the belief that all project requirements can be gathered and understood upfront. The Business Analyst does their best to get a detailed understanding of the project sponsor's requirements. Written requirements, usually contained in a single document, are used to describe each stage of the project, including the costs, assumptions, risks, dependencies, success metrics, and timelines for completion.
|
||||
Design
|
||||
Here, software developers design a technical solution to the problems set out by the product requirements, including scenarios, layouts, and data models. First, a higher-level or logical design is created that describes the purpose and scope of the project, the general traffic flow of each component, and the integration points. Once this is complete, it is transformed into a physical design using specific hardware and software technologies.
|
||||
Implementation
|
||||
Once the design is complete, technical implementation starts. This might be the shortest phase of the Waterfall process, because painstaking research and design have already been done. In this phase, programmers code applications based on project requirements and specifications, with some testing and implementation taking place as well. If significant changes are required during this stage, this may mean going back to the design phase.
|
||||
Verification or testing
|
||||
Before a product can be released to customers, testing needs to be done to ensure the product has no errors and all of the requirements have been completed, ensuring a good user experience with the software. The testing team will turn to the design documents, personas, and user case scenarios supplied by the product manager to create their test cases.
|
||||
|
||||
|
||||
Deployment and maintenance
|
||||
Once the software has been deployed in the market or released to customers, the maintenance phase begins. As defects are found and change requests come in from users, a team will be assigned to take care of updates and release new versions of the software.
|
||||
Governance Setup
|
||||
Sr.
|
||||
Name
|
||||
Description
|
||||
Attendees
|
||||
Duration(mins)
|
||||
1.
|
||||
Daily Scrum Call
|
||||
|
||||
10 minutes call where we discuss what we did in the previous day and what is today's plan and challenges (if any).
|
||||
Development Team, Team Heads, Project Manager
|
||||
|
||||
10
|
||||
2.
|
||||
Weekly Review Meeting
|
||||
A 30 minute meeting to share the current project status vis-a-viz as per the defined project plan and discuss dependencies, hurdles and resolutions.
|
||||
Team Heads, Project Manager, Client's coordinator
|
||||
30
|
||||
3.
|
||||
Monthly Governance Meeting
|
||||
A 60 minute meeting to share the progress as per the define milestone. Any anticipated hurdles in the future deliverables, challenges faced in the previous month and ensuing these are not repeated in the future.?
|
||||
Project Manager, Client's coordinator, Project Owner, Solution Consultant, Client IT and Business SPOC
|
||||
60
|
||||
|
||||
|
||||
Part 3: Agreement for Support and Maintenance Services
|
||||
Annual Maintenance and Support Services
|
||||
Support during AMS would be offsite services. This will be decided mutually depending on the nature of the issue reported by ROYAL ENFIELD
|
||||
Maintenance and support will be provided on working weekdays between 10:00 A.M. and 6:00 P.M. IST, excluding Public Holidays. For support requests received beyond the stipulated hours above, SOFTUDE INFOTECH PVT LTD will make reasonable efforts to ensure that these requests are attended to, promptly. ROYAL ENFIELD can contact SOFTUDE INFOTECH PVT LTD for maintenance and support at the phone number(s) and email addresses provided to them.
|
||||
Annual Maintenance and Support includes:
|
||||
|
||||
Type of support
|
||||
Support Description
|
||||
#1
|
||||
Bug Fixing
|
||||
* Any error, flaw, fault occurred in a developed software, an incorrect or unexpected result, or behave in unintended ways. should be considered in bug fixing. This process does not include any logical or process change in system (Code change).
|
||||
* Softude is not responsible in mal function of platform (Zoho Creator) or any error on the platform.
|
||||
* SOFTUDE is not responsible for any Third-Party API Issue, backend API issue, and efforts related to that we will not consider in support (Log hours billed as per actual).
|
||||
* If issue arises due to application and it is creating issue in backend, then it will fall under bugs/errors.
|
||||
* If the issue is related to third party platform and impacting the application/backend or vice versa than the solution efforts do not consider in support.
|
||||
#2
|
||||
Support Request or Query
|
||||
Any query or request shared by ROYAL ENFIELD business or IT that may not require any development efforts but may require devoting time such as any request for review and validation of the current functionality or any requirement analysis and Investigation will be considered as Support Request or Query.
|
||||
#3
|
||||
CR Request in existing system under Support contract
|
||||
Any change or upgrade in the software, that is required by the business or process to improve the quality or capabilities beyond original specifications will be considered as change request.
|
||||
* In case of any new module or new functionality development request where it requires major change or entirely new development then it is considered as change request.
|
||||
#4
|
||||
MIS Data from backend
|
||||
At any point of time if business or IT function need any information updates or data sheet from the backend system, which can be created by the developer and directly generated from the simple SQL query is considered in MIS data or simple query report request.
|
||||
|
||||
|
||||
|
||||
|
||||
BIN
User guide Steps to Create a Custom Workflow.docx
Normal file
BIN
User guide Steps to Create a Custom Workflow.docx
Normal file
Binary file not shown.
90
Workflow Document - Templatized_ Non Templatized.txt
Normal file
90
Workflow Document - Templatized_ Non Templatized.txt
Normal file
@ -0,0 +1,90 @@
|
||||
Workflow Management Requirements
|
||||
|
||||
|
||||
1. Templatized Workflow
|
||||
|
||||
Objective:
|
||||
To standardize and streamline recurring business processes, enhancing efficiency, consistency, compliance, and traceability.
|
||||
|
||||
Key Requirements:
|
||||
|
||||
- Workflow Templates:
|
||||
Ability to define reusable templates for routine processes (e.g., vendor code creation, dealer onboarding, PR/PO creation in SAP).
|
||||
|
||||
- Roles & Responsibilities:
|
||||
Clearly defined owners for each workflow step, ensuring accountability and smooth handovers.
|
||||
|
||||
- Automation Triggers:
|
||||
Support for event-based initiation of workflows (e.g., status change, form submission).
|
||||
|
||||
- SLAs & Timelines:
|
||||
Configurable turnaround times for each step to enforce timely execution and escalation.
|
||||
|
||||
- Integration Points:
|
||||
Seamless data exchange with external systems (e.g., DMS ? SAP), with standard API options available while defining workflows (e.g., for vendor/dealer code or PO creation).
|
||||
|
||||
- Exception Handling:
|
||||
Defined escalation matrix or alternate flows for handling deviations or process failures.
|
||||
|
||||
- Role-Based Template Visibility:
|
||||
Templates should be visible only to relevant user roles to ensure access control, reduce clutter, and improve process efficiency.
|
||||
|
||||
- Document Upload & Digital Signatures:
|
||||
Users should be able to upload supporting documents with an option for digital signing within the workflow.
|
||||
|
||||
- OCR Integration:
|
||||
Optical Character Recognition (OCR) capability to auto-validate and extract key data from uploaded documents for verification.
|
||||
|
||||
Trigger ? Template Selection ? Role Assignment ? Task Execution ? Integration/API Call ? Document Upload (with Digital Signature + OCR) ? SLA Tracking ? Completion/Closure
|
||||
|
||||
Steps:
|
||||
1. Trigger Event (e.g., status change, user action)
|
||||
2. Select Workflow Template (based on user role)
|
||||
3. Auto-assign Roles & Tasks
|
||||
4. Execute Steps as per SLA
|
||||
5. API Call to External System (e.g., SAP for PR/PO, vendor creation)
|
||||
6. Document Upload with Digital Signature
|
||||
7. OCR validation (auto-read documents for key info)
|
||||
8. Exception Handling if any deviation
|
||||
9. Workflow Closure after final approval
|
||||
|
||||
|
||||
|
||||
|
||||
2. Non-Templatized Workflow
|
||||
|
||||
Objective:
|
||||
To support flexible, ad-hoc processes that do not conform to predefined workflows, enabling users to handle exceptions, one-off requests, or case-specific scenarios.
|
||||
|
||||
Key Requirements:
|
||||
|
||||
- Flexible Workflow Initiation:
|
||||
Allow users to create workflows from scratch without relying on templates.
|
||||
|
||||
- Dynamic Role Assignment:
|
||||
Ability to assign roles/tasks dynamically based on the situation.
|
||||
|
||||
- Ad-hoc Approvals:
|
||||
Support for custom approval flows that can be configured during workflow initiation.
|
||||
|
||||
- Manual Task Handling:
|
||||
Users can add or skip steps manually as needed, without automation constraints.
|
||||
|
||||
- Case-by-Case Logic:
|
||||
Workflows can follow unique paths based on individual judgment or specific business context.
|
||||
|
||||
- Integration Points:
|
||||
Enable data exchange between systems (e.g., DMS ? SAP), with access to standard API options for actions like vendor/dealer code creation or PR/PO processing.
|
||||
|
||||
Trigger ? Manual Workflow Creation ? Dynamic Role Assignment ? Task Execution ? Integration/API Call ? Document Upload (if any) ? Approval ? Closure
|
||||
|
||||
Steps:
|
||||
1. User Initiates Ad-hoc Workflow
|
||||
2. Define Custom Steps & Tasks
|
||||
3. Manually Assign Approvers/Stakeholders
|
||||
4. Execute Steps Manually
|
||||
5. Optional API Call to External Systems (SAP, etc.)
|
||||
6. Optional Document Upload
|
||||
7. Ad-hoc Approvals
|
||||
8. Workflow Completion
|
||||
|
||||
371
complete_workflow_diagram.mermaid
Normal file
371
complete_workflow_diagram.mermaid
Normal file
@ -0,0 +1,371 @@
|
||||
graph TD
|
||||
%% START - User Access
|
||||
Start([User Access Portal]) --> Login[Login via RE Bridge Centralised SSO]
|
||||
Login --> AuthCheck{Authentication Success?}
|
||||
AuthCheck -->|No| LoginError[Authentication Failed]
|
||||
AuthCheck -->|Yes| Dashboard[User Dashboard]
|
||||
|
||||
%% DASHBOARD ROUTING
|
||||
Dashboard --> UserType{User Role}
|
||||
UserType -->|Dealer| DealerPortal[Dealer Portal]
|
||||
UserType -->|Internal Staff| StaffPortal[Staff Portal]
|
||||
UserType -->|Admin| AdminAuthCheck{Admin Permission Level}
|
||||
|
||||
%% ADMIN ROLE HIERARCHY
|
||||
AdminAuthCheck -->|Super Admin| AdminPortal[Full Admin Portal]
|
||||
AdminAuthCheck -->|System Admin| SystemAdminView[System Admin View]
|
||||
AdminAuthCheck -->|Workflow Admin| WorkflowAdminView[Workflow Admin View]
|
||||
AdminAuthCheck -->|Reports Admin| ReportsAdminView[Reports Admin View]
|
||||
AdminAuthCheck -->|Regional Admin| RegionalAdminView[Regional Admin View]
|
||||
|
||||
%% ROUTE TO ADMIN ACTIONS
|
||||
SystemAdminView --> AdminActions{Admin Actions}
|
||||
WorkflowAdminView --> AdminActions
|
||||
ReportsAdminView --> AdminActions
|
||||
RegionalAdminView --> AdminActions
|
||||
|
||||
%% DEALER PORTAL - BECOME A DEALER FLOW
|
||||
DealerPortal --> DealerAction{Dealer Action}
|
||||
DealerAction -->|New Application| NewApp[Submit 'Become a Dealer' Form]
|
||||
DealerAction -->|Existing Application| TrackApp[Track Application Status]
|
||||
DealerAction -->|Claims| ClaimProcess[Submit Claim Request]
|
||||
|
||||
%% NEW DEALER APPLICATION FLOW
|
||||
NewApp --> CaptureForm[Frontend: Capture Form Data]
|
||||
CaptureForm --> ValidateForm[Frontend: Form Validation]
|
||||
ValidateForm --> SubmitForm[Frontend: Submit to Backend API]
|
||||
SubmitForm --> StoreData[Backend: Store in Database]
|
||||
StoreData --> CheckLocation{Backend: Location Has Vacancy?}
|
||||
|
||||
CheckLocation -->|No| RejectEmail[Backend: Send Non-Opportunity Email]
|
||||
CheckLocation -->|Yes| AckEmail[Backend: Send Acknowledgement Email]
|
||||
|
||||
AckEmail --> SendQuestionnaire[Backend: Send Questionnaire Link]
|
||||
SendQuestionnaire --> WaitResponse{Backend: Response Received?}
|
||||
|
||||
WaitResponse -->|No - D+2| Reminder1[Backend: Send Reminder Email]
|
||||
Reminder1 --> WaitResponse2{Backend: Response Received?}
|
||||
WaitResponse2 -->|No - D+5| Reminder2[Backend: Send Final Reminder]
|
||||
Reminder2 --> WaitResponse3{Backend: Response Received?}
|
||||
WaitResponse3 -->|No - D+20| ExpireLink[Backend: Close Questionnaire]
|
||||
|
||||
WaitResponse -->|Yes| ProcessResponse[Backend: Calculate Weighted Rank]
|
||||
WaitResponse2 -->|Yes| ProcessResponse
|
||||
WaitResponse3 -->|Yes| ProcessResponse
|
||||
|
||||
ProcessResponse --> DDShortlist[Staff Portal: DD Team Reviews & Shortlists Top 10]
|
||||
DDShortlist --> AssignZM[Backend: Assign to Zonal Manager DD]
|
||||
|
||||
AssignZM --> ZMEval{Staff Portal: ZM-DD KT Evaluation}
|
||||
ZMEval -->|Rejected| ZMReject[Backend: Store Rejection Reason]
|
||||
ZMEval -->|Shortlisted| AssignRBM[Backend: Auto-Assign to RBM]
|
||||
|
||||
AssignRBM --> RBMEval{Staff Portal: RBM Evaluation}
|
||||
RBMEval -->|Rejected| RBMReject[Backend: Store Rejection Reason]
|
||||
RBMEval -->|Approved| AssignDDL[Backend: Auto-Assign to DDL Team]
|
||||
|
||||
AssignDDL --> FDD[Backend: Send OTP-Protected Link for FDD]
|
||||
FDD --> UploadFDD[External Agency: Upload FDD Report L1/L2]
|
||||
UploadFDD --> SubmitNBH[Staff Portal: DD Team Submits to NBH]
|
||||
|
||||
SubmitNBH --> NBHApproval{Staff Portal: NBH Approval}
|
||||
NBHApproval -->|Rejected| NBHReject[Backend: Store Rejection & Notify]
|
||||
NBHApproval -->|Approved| IssueLOI[Backend: Generate & Send LOI]
|
||||
|
||||
IssueLOI --> UploadLOI[Staff Portal: Upload LOI to System]
|
||||
UploadLOI --> IssueLOA[Backend: Generate & Send LOA]
|
||||
IssueLOA --> UploadLOA[Staff Portal: Upload LOA to System]
|
||||
|
||||
UploadLOA --> ScheduleEOR[Staff Portal: Regional DD Schedules EOR Audit]
|
||||
ScheduleEOR --> UploadEOR[Staff Portal: Upload EOR Audit Report]
|
||||
UploadEOR --> EORApproval{Staff Portal: NBH EOR Approval}
|
||||
|
||||
EORApproval -->|Rejected| EORReject[Backend: Store Rejection & Notify]
|
||||
EORApproval -->|Approved| UpdateDealer[Backend: Update Dealer Info]
|
||||
|
||||
UpdateDealer --> ActiveDealer([Active Dealer Created])
|
||||
|
||||
%% DEALER CLAIM PROCESS
|
||||
ClaimProcess --> ClaimForm[Frontend: Claim Request Form]
|
||||
ClaimForm --> ValidateClaim[Frontend: Form Validation]
|
||||
ValidateClaim --> SubmitClaim[Frontend: Submit to Backend API]
|
||||
SubmitClaim --> RI[Backend: Request Initiation]
|
||||
|
||||
RI --> RI1[Backend: Store Request Details]
|
||||
RI1 --> PS[Backend: Proposal Submission]
|
||||
PS --> PS1[Frontend: Dealer Submits Proposal]
|
||||
PS1 --> PS2[Frontend: Cost Breakup]
|
||||
PS1 --> PS3[Frontend: Timeline for Closure]
|
||||
PS1 --> PS4[Frontend: Supporting Documents]
|
||||
|
||||
PS2 --> RE[Backend: Request Evaluation]
|
||||
PS3 --> RE
|
||||
PS4 --> RE
|
||||
|
||||
RE --> RE1{Staff Portal: Requestor Reviews}
|
||||
RE1 -->|Needs Clarification| RE2[Backend: Request More Info]
|
||||
RE2 --> PS1
|
||||
RE1 -->|Approved| RE3[Backend: Confirm to Proceed]
|
||||
|
||||
RE3 --> DLA[Staff Portal: Dept. Lead Approval]
|
||||
DLA --> DLA1{Staff Portal: Lead Reviews Request}
|
||||
DLA1 -->|Needs Clarification| DLA2[Backend: Request Clarification]
|
||||
DLA2 --> RE
|
||||
DLA1 -->|Approved| DLA3[Backend: Approve Request]
|
||||
|
||||
DLA3 --> BUD[Backend: Budgeting]
|
||||
BUD --> BUD1[Backend: Block Budget]
|
||||
BUD1 --> BUD2[Backend: Assign to IO]
|
||||
|
||||
BUD2 --> AC[Backend: Activity Creation]
|
||||
AC --> AC1[Backend: System Creates Activity]
|
||||
AC1 --> AC2[Backend: Auto-Email Confirmation]
|
||||
AC2 --> AC3[Backend: Notify Requestor]
|
||||
AC2 --> AC4[Backend: Notify Dealer]
|
||||
AC2 --> AC5[Backend: Notify Lead]
|
||||
|
||||
AC3 --> AE[Frontend: Activity Execution Interface]
|
||||
AC4 --> AE
|
||||
AC5 --> AE
|
||||
|
||||
AE --> AE1[Frontend: Dealer Executes Activity]
|
||||
AE1 --> AE2[Frontend: Submit Required Documents]
|
||||
|
||||
AE2 --> CA[Backend: Claim Approval]
|
||||
CA --> CA1{Staff Portal: Requestor Reviews Documents}
|
||||
CA1 -->|More Info Needed| CA2[Backend: Request Additional Info]
|
||||
CA2 --> AE2
|
||||
CA1 -->|Approved| CA3{Staff Portal: Approval Type}
|
||||
|
||||
CA3 -->|Full Approval| EI[Backend: E-Invoicing]
|
||||
CA3 -->|Partial Approval| EI
|
||||
EI --> EI1[Backend: Generate E-Invoice]
|
||||
EI1 --> EI2[Backend: Issue Credit Note]
|
||||
EI2 --> ClaimSettled([Claim Settled])
|
||||
|
||||
%% DEALER OFFBOARDING - RESIGNATION
|
||||
ActiveDealer --> DealerOps{Staff Portal: Dealer Operations}
|
||||
DealerOps -->|Resignation Request| ResignStart[Frontend: Dealer Sends Email to ZBH]
|
||||
ResignStart --> ResignRecord[Staff Portal: ZBH Records in System]
|
||||
ResignRecord --> ResignZBH{Staff Portal: ZBH Approval}
|
||||
|
||||
ResignZBH -->|Rejected| ResignRejectZBH[Backend: Return to Previous Level & Notify]
|
||||
ResignZBH -->|Approved| ResignDDL{Staff Portal: DD Lead Approval}
|
||||
|
||||
ResignDDL -->|Rejected| ResignRejectDDL[Backend: Return to ZBH & Notify]
|
||||
ResignDDL -->|Approved| ResignNBH{Staff Portal: NBH Approval}
|
||||
|
||||
ResignNBH -->|Rejected| ResignRejectNBH[Backend: Return to DD Lead & Notify]
|
||||
ResignNBH -->|Approved| GenResignLetter[Backend: Generate Resignation Acceptance Letter]
|
||||
GenResignLetter --> SendResignLetter[Staff Portal: NBH Approves & Shares Letter]
|
||||
SendResignLetter --> StartFF1[Backend: Start F&F Process]
|
||||
|
||||
%% DEALER OFFBOARDING - TERMINATION
|
||||
DealerOps -->|Termination Initiated| TermStart[Staff Portal: Identify Termination Reason]
|
||||
TermStart --> TermType{Staff Portal: Termination Type}
|
||||
TermType -->|Immediate| TermDocs1[Staff Portal: ASM Collects Documentation]
|
||||
TermType -->|By Convenience| TermDocs2[Staff Portal: ASM Collects Documentation]
|
||||
|
||||
TermDocs1 --> PrepNotes[Backend: Generate Termination Notes PDF]
|
||||
TermDocs2 --> PrepNotes
|
||||
|
||||
PrepNotes --> TermZBH{Staff Portal: ZBH Approval}
|
||||
TermZBH -->|Rejected| TermRejectZBH[Backend: Return & Notify]
|
||||
TermZBH -->|Approved| TermDDL{Staff Portal: DD Lead Approval}
|
||||
|
||||
TermDDL -->|Rejected| TermRejectDDL[Backend: Return to ZBH & Notify]
|
||||
TermDDL -->|Approved| TermNBH{Staff Portal: NBH Approval}
|
||||
|
||||
TermNBH -->|Rejected| TermRejectNBH[Backend: Return to DD Lead & Notify]
|
||||
TermNBH -->|Approved| TermCCO{Staff Portal: CCO Approval}
|
||||
|
||||
TermCCO -->|Rejected| TermRejectCCO[Backend: Return to NBH & Notify]
|
||||
TermCCO -->|Approved| TermCEO{Staff Portal: CEO Approval}
|
||||
|
||||
TermCEO -->|Rejected| TermRejectCEO[Backend: Return to CCO & Notify]
|
||||
TermCEO -->|Approved| IssueNotice[Backend: Generate Show Cause Notice]
|
||||
|
||||
IssueNotice --> Send15Day[Backend: Send Notice with 15-Day Deadline]
|
||||
Send15Day --> WaitDealer{Frontend: Dealer Response?}
|
||||
|
||||
WaitDealer -->|Response Received| ReviewResponse[Staff Portal: Review Response]
|
||||
WaitDealer -->|No Response| UploadTermLetter[Staff Portal: DD Lead Uploads Signed Termination Letter]
|
||||
ReviewResponse --> FinalDecision{Staff Portal: Final Decision}
|
||||
|
||||
FinalDecision -->|Proceed| UploadTermLetter
|
||||
FinalDecision -->|Withdraw| TermWithdraw[Backend: Termination Withdrawn]
|
||||
|
||||
UploadTermLetter --> StartFF2[Backend: Start F&F Process]
|
||||
|
||||
%% FULL & FINAL SETTLEMENT PROCESS
|
||||
StartFF1 --> FFNotify[Backend: Send F&F Notification to All Stakeholders]
|
||||
StartFF2 --> FFNotify
|
||||
|
||||
FFNotify --> FFTrack[Frontend: F&F Tracking System Activated]
|
||||
FFTrack --> FFStakeholders[Backend: Each Stakeholder Receives Task]
|
||||
|
||||
FFStakeholders --> FFFinance[Frontend: Finance - Settlement Forms]
|
||||
FFStakeholders --> FFLegal[Frontend: Legal - Clearance Forms]
|
||||
FFStakeholders --> FFOthers[Frontend: Other Stakeholders - Respective Forms]
|
||||
|
||||
FFFinance --> FFUpdate1[Frontend: Update Status in System]
|
||||
FFLegal --> FFUpdate2[Frontend: Update Status in System]
|
||||
FFOthers --> FFUpdate3[Frontend: Update Status in System]
|
||||
|
||||
FFUpdate1 --> FFCheck{Backend: All Tasks Complete?}
|
||||
FFUpdate2 --> FFCheck
|
||||
FFUpdate3 --> FFCheck
|
||||
|
||||
FFCheck -->|No| FFReminder[Backend: Send Reminder if TAT Exceeded]
|
||||
FFReminder --> FFCheck
|
||||
|
||||
FFCheck -->|Yes| BlockDealer[Backend: Block Dealer from System]
|
||||
BlockDealer --> FFComplete[Backend: Send Completion Email to All Stakeholders]
|
||||
|
||||
FFComplete --> End([Process Complete])
|
||||
|
||||
%% FIELD VISIT REPORT MODULE
|
||||
StaffPortal --> FieldVisit[Field Visit Report Module]
|
||||
FieldVisit --> FJC[Frontend: FJC Planning Interface]
|
||||
FJC --> FJC1[Frontend: Document Preparation]
|
||||
FJC --> FJC2[Frontend: Review & Approval Flow]
|
||||
FJC --> FJC3[Frontend: Dealer Coordination]
|
||||
|
||||
FJC1 --> VE[Frontend: Visit Execution Module]
|
||||
FJC2 --> VE
|
||||
FJC3 --> VE
|
||||
|
||||
VE --> VE1{Staff Portal: Field Visit As Per Plan?}
|
||||
VE1 -->|Yes| VE2[Frontend: Execute Visit]
|
||||
VE1 -->|No| VE3[Frontend: Re-plan Changes]
|
||||
VE3 --> VE2
|
||||
VE2 --> VE4[Frontend: Dealer Discussion]
|
||||
|
||||
VE4 --> DM[Frontend: Discussion Management Module]
|
||||
DM --> DM1[Frontend: Capture Actionable Insights]
|
||||
DM --> DM2[Frontend: Record Feedback]
|
||||
DM --> DM3[Frontend: Performance Metrics]
|
||||
|
||||
DM1 --> MOM[Frontend: MOM Creation Module]
|
||||
DM2 --> MOM
|
||||
DM3 --> MOM
|
||||
|
||||
MOM --> MOM1[Frontend: Structured Documentation]
|
||||
MOM --> MOM2[Frontend: Action Item Tracking]
|
||||
MOM --> MOM3[Frontend: Task Delegation]
|
||||
|
||||
MOM1 --> CS[Backend: Closure & Sharing Module]
|
||||
MOM2 --> CS
|
||||
MOM3 --> CS
|
||||
|
||||
CS --> CS1[Backend: Document Submission]
|
||||
CS1 --> CS2[Backend: Archiving]
|
||||
CS2 --> CS3[Backend: Stakeholder Communication]
|
||||
|
||||
CS3 --> AW[Backend: Approval Workflow]
|
||||
AW --> AW1{Staff Portal: Hierarchy-Based Approval}
|
||||
AW1 -->|Approved| FieldVisitComplete([Field Visit Completed & Archived])
|
||||
AW1 -->|Rejected| Feedback[Backend: Feedback to Team]
|
||||
Feedback --> FJC
|
||||
|
||||
%% ADMIN PORTAL FEATURES WITH PERMISSION CHECKS
|
||||
AdminPortal --> AdminActions{Admin Actions}
|
||||
AdminActions -->|User Management| CheckUserMgmt{Backend: Has Permission?}
|
||||
AdminActions -->|Master Data| CheckMasterData{Backend: Has Permission?}
|
||||
AdminActions -->|Workflow Engine| CheckWorkflow{Backend: Has Permission?}
|
||||
AdminActions -->|Reports| CheckReports{Backend: Has Permission?}
|
||||
|
||||
%% USER MANAGEMENT PERMISSIONS
|
||||
CheckUserMgmt -->|Yes - Super Admin/System Admin| UserMgmt[Frontend: User Management Interface]
|
||||
CheckUserMgmt -->|No| AccessDenied1[Frontend: Access Denied - Insufficient Permissions]
|
||||
|
||||
UserMgmt --> RoleMgmt[Frontend: Role Management]
|
||||
UserMgmt --> PermissionMgmt[Frontend: Permission Matrix]
|
||||
UserMgmt --> RegionalScoping[Frontend: Regional Scoping]
|
||||
|
||||
%% MASTER DATA PERMISSIONS
|
||||
CheckMasterData -->|Yes - Super Admin/System Admin/Regional Admin| MasterData[Frontend: Master Data Management]
|
||||
CheckMasterData -->|No| AccessDenied2[Frontend: Access Denied - Insufficient Permissions]
|
||||
|
||||
MasterData --> CheckRegionalScope{Backend: Is Regional Admin?}
|
||||
CheckRegionalScope -->|Yes| RegionalMasterData[Frontend: Regional Scoped Data Only]
|
||||
CheckRegionalScope -->|No| FullMasterData[Frontend: Full Master Data Access]
|
||||
|
||||
RegionalMasterData --> TownMgmtRegional[Frontend: Town Management - Regional]
|
||||
RegionalMasterData --> DealerCodeMgmtRegional[Frontend: Dealer Code Management - Regional]
|
||||
|
||||
FullMasterData --> TownMgmt[Frontend: Town Management]
|
||||
FullMasterData --> DealerCodeMgmt[Frontend: Dealer Code Management]
|
||||
FullMasterData --> EvaluationCriteria[Frontend: Evaluation Criteria Management]
|
||||
|
||||
%% WORKFLOW ENGINE PERMISSIONS
|
||||
CheckWorkflow -->|Yes - Super Admin/Workflow Admin| WorkflowEngine[Frontend: Custom Workflow Engine]
|
||||
CheckWorkflow -->|No| AccessDenied3[Frontend: Access Denied - Insufficient Permissions]
|
||||
|
||||
WorkflowEngine --> TemplateBuilder[Frontend: Template Builder]
|
||||
WorkflowEngine --> DynamicWorkflow[Frontend: Dynamic Workflow Creation]
|
||||
WorkflowEngine --> WorkflowMonitoring[Frontend: Workflow Monitoring]
|
||||
|
||||
%% REPORTS PERMISSIONS
|
||||
CheckReports -->|Yes - All Admin Roles| Reports[Frontend: Reports & Analytics]
|
||||
CheckReports -->|No| AccessDenied4[Frontend: Access Denied - Insufficient Permissions]
|
||||
|
||||
Reports --> CheckReportScope{Backend: Determine Report Scope}
|
||||
CheckReportScope -->|Regional Admin| RegionalReports[Frontend: Regional Reports Only]
|
||||
CheckReportScope -->|Other Admins| AllReports[Frontend: All Reports]
|
||||
|
||||
RegionalReports --> DealerWiseReportRegional[Frontend: Dealer-wise Report - Regional]
|
||||
RegionalReports --> PendingRequestReportRegional[Frontend: Pending Request Report - Regional]
|
||||
|
||||
AllReports --> DealerWiseReport[Frontend: Dealer-wise Report]
|
||||
AllReports --> MISReport[Frontend: MIS Report]
|
||||
AllReports --> PendingRequestReport[Frontend: Pending Request Report]
|
||||
AllReports --> FFTrackingReport[Frontend: F&F Tracking Report]
|
||||
AllReports --> ApplicationSummaryReport[Frontend: Application Summary Report]
|
||||
|
||||
%% ACCESS DENIED ENDPOINTS
|
||||
AccessDenied1 --> AdminActions
|
||||
AccessDenied2 --> AdminActions
|
||||
AccessDenied3 --> AdminActions
|
||||
AccessDenied4 --> AdminActions
|
||||
|
||||
%% END POINTS
|
||||
RejectEmail --> End
|
||||
ExpireLink --> End
|
||||
ZMReject --> End
|
||||
RBMReject --> End
|
||||
NBHReject --> End
|
||||
EORReject --> End
|
||||
TermWithdraw --> End
|
||||
LoginError --> Login
|
||||
|
||||
%% STYLING
|
||||
style Start fill:#90EE90
|
||||
style End fill:#FFB6C1
|
||||
style ActiveDealer fill:#87CEEB
|
||||
style ClaimSettled fill:#87CEEB
|
||||
style FieldVisitComplete fill:#87CEEB
|
||||
style NBHApproval fill:#FFD700
|
||||
style EORApproval fill:#FFD700
|
||||
style ResignNBH fill:#FFD700
|
||||
style TermCEO fill:#FFD700
|
||||
style BlockDealer fill:#FF6B6B
|
||||
style Dashboard fill:#E6E6FA
|
||||
style StaffPortal fill:#F0F8FF
|
||||
style DealerPortal fill:#F5F5DC
|
||||
style AdminPortal fill:#FFE4E1
|
||||
style AdminAuthCheck fill:#DDA0DD
|
||||
style SystemAdminView fill:#F0E68C
|
||||
style WorkflowAdminView fill:#F0E68C
|
||||
style ReportsAdminView fill:#F0E68C
|
||||
style RegionalAdminView fill:#F0E68C
|
||||
style AccessDenied1 fill:#FFA07A
|
||||
style AccessDenied2 fill:#FFA07A
|
||||
style AccessDenied3 fill:#FFA07A
|
||||
style AccessDenied4 fill:#FFA07A
|
||||
style CheckUserMgmt fill:#ADD8E6
|
||||
style CheckMasterData fill:#ADD8E6
|
||||
style CheckWorkflow fill:#ADD8E6
|
||||
style CheckReports fill:#ADD8E6
|
||||
style CheckRegionalScope fill:#ADD8E6
|
||||
style CheckReportScope fill:#ADD8E6
|
||||
147
dealer_mgmt_flow.mermaid
Normal file
147
dealer_mgmt_flow.mermaid
Normal file
@ -0,0 +1,147 @@
|
||||
graph TB
|
||||
Start([Dealer Inquiry Received]) --> CaptureForm[Capture 'Become a Dealer' Form]
|
||||
CaptureForm --> StoreData[Store in Database & Show Listing]
|
||||
StoreData --> CheckLocation{Location Has Vacancy?}
|
||||
|
||||
CheckLocation -->|No| RejectEmail[Send Non-Opportunity Email]
|
||||
CheckLocation -->|Yes| AckEmail[Send Acknowledgement Email]
|
||||
|
||||
AckEmail --> SendQuestionnaire[Send Opportunity Email with Questionnaire Link]
|
||||
SendQuestionnaire --> WaitResponse{Response Received?}
|
||||
|
||||
WaitResponse -->|No - D+2| Reminder1[Send Reminder Email]
|
||||
Reminder1 --> WaitResponse2{Response Received?}
|
||||
WaitResponse2 -->|No - D+5| Reminder2[Send Final Reminder]
|
||||
Reminder2 --> WaitResponse3{Response Received?}
|
||||
WaitResponse3 -->|No - D+20| ExpireLink[Close Questionnaire - Expired]
|
||||
|
||||
WaitResponse -->|Yes| ProcessResponse[Calculate Weighted Rank]
|
||||
WaitResponse2 -->|Yes| ProcessResponse
|
||||
WaitResponse3 -->|Yes| ProcessResponse
|
||||
|
||||
ProcessResponse --> DDShortlist[DD Team Reviews & Shortlists Top 10]
|
||||
DDShortlist --> AssignZM[Assign to Zonal Manager DD]
|
||||
|
||||
AssignZM --> ZMEval{ZM-DD KT Evaluation}
|
||||
ZMEval -->|Rejected| ZMReject[Store Rejection Reason]
|
||||
ZMEval -->|Shortlisted| AssignRBM[Auto-Assign to RBM]
|
||||
|
||||
AssignRBM --> RBMEval{RBM Evaluation}
|
||||
RBMEval -->|Rejected| RBMReject[Store Rejection Reason]
|
||||
RBMEval -->|Approved| AssignDDL[Auto-Assign to DDL Team]
|
||||
|
||||
AssignDDL --> FDD[Send OTP-Protected Link for Financial Due Diligence]
|
||||
FDD --> UploadFDD[External Agency Uploads FDD Report L1/L2]
|
||||
UploadFDD --> SubmitNBH[DD Team Submits to NBH]
|
||||
|
||||
SubmitNBH --> NBHApproval{NBH Approval}
|
||||
NBHApproval -->|Rejected| NBHReject[Store Rejection & Notify]
|
||||
NBHApproval -->|Approved| IssueLOI[Generate & Send LOI]
|
||||
|
||||
IssueLOI --> UploadLOI[Upload LOI to System]
|
||||
UploadLOI --> IssueLOA[Generate & Send LOA]
|
||||
IssueLOA --> UploadLOA[Upload LOA to System]
|
||||
|
||||
UploadLOA --> ScheduleEOR[Regional DD Schedules EOR Audit]
|
||||
ScheduleEOR --> UploadEOR[Upload EOR Audit Report]
|
||||
UploadEOR --> EORApproval{NBH EOR Approval}
|
||||
|
||||
EORApproval -->|Rejected| EORReject[Store Rejection & Notify]
|
||||
EORApproval -->|Approved| UpdateDealer[Update Dealer Info: Inauguration Date, Codes]
|
||||
|
||||
UpdateDealer --> ActiveDealer([Active Dealer])
|
||||
|
||||
ActiveDealer --> DealerOps{Dealer Operations}
|
||||
|
||||
DealerOps -->|Resignation Request| ResignStart[Dealer Sends Email to ZBH]
|
||||
ResignStart --> ResignRecord[ZBH Records in System]
|
||||
ResignRecord --> ResignZBH{ZBH Approval}
|
||||
|
||||
ResignZBH -->|Rejected| ResignRejectZBH[Return to Previous Level & Notify]
|
||||
ResignZBH -->|Approved| ResignDDL{DD Lead Approval}
|
||||
|
||||
ResignDDL -->|Rejected| ResignRejectDDL[Return to ZBH & Notify]
|
||||
ResignDDL -->|Approved| ResignNBH{NBH Approval}
|
||||
|
||||
ResignNBH -->|Rejected| ResignRejectNBH[Return to DD Lead & Notify]
|
||||
ResignNBH -->|Approved| GenResignLetter[Generate Resignation Acceptance Letter]
|
||||
GenResignLetter --> SendResignLetter[NBH Approves & Shares Letter]
|
||||
SendResignLetter --> StartFF1[Start F&F Process]
|
||||
|
||||
DealerOps -->|Termination Initiated| TermStart[Identify Termination Reason]
|
||||
TermStart --> TermType{Termination Type}
|
||||
TermType -->|Immediate| TermDocs1[ASM Collects Documentation]
|
||||
TermType -->|By Convenience| TermDocs2[ASM Collects Documentation]
|
||||
|
||||
TermDocs1 --> PrepNotes[Generate Termination Notes PDF]
|
||||
TermDocs2 --> PrepNotes
|
||||
|
||||
PrepNotes --> TermZBH{ZBH Approval}
|
||||
TermZBH -->|Rejected| TermRejectZBH[Return & Notify]
|
||||
TermZBH -->|Approved| TermDDL{DD Lead Approval}
|
||||
|
||||
TermDDL -->|Rejected| TermRejectDDL[Return to ZBH & Notify]
|
||||
TermDDL -->|Approved| TermNBH{NBH Approval}
|
||||
|
||||
TermNBH -->|Rejected| TermRejectNBH[Return to DD Lead & Notify]
|
||||
TermNBH -->|Approved| TermCCO{CCO Approval}
|
||||
|
||||
TermCCO -->|Rejected| TermRejectCCO[Return to NBH & Notify]
|
||||
TermCCO -->|Approved| TermCEO{CEO Approval}
|
||||
|
||||
TermCEO -->|Rejected| TermRejectCEO[Return to CCO & Notify]
|
||||
TermCEO -->|Approved| IssueNotice[Generate Show Cause Notice]
|
||||
|
||||
IssueNotice --> Send15Day[Send Notice with 15-Day Deadline]
|
||||
Send15Day --> WaitDealer{Dealer Response?}
|
||||
|
||||
WaitDealer -->|Response Received| ReviewResponse[Review Response]
|
||||
WaitDealer -->|No Response| UploadTermLetter[DD Lead Uploads Signed Termination Letter]
|
||||
ReviewResponse --> FinalDecision{Final Decision}
|
||||
|
||||
FinalDecision -->|Proceed| UploadTermLetter
|
||||
FinalDecision -->|Withdraw| TermWithdraw[Termination Withdrawn]
|
||||
|
||||
UploadTermLetter --> StartFF2[Start F&F Process]
|
||||
|
||||
StartFF1 --> FFNotify[Send F&F Notification to All Stakeholders]
|
||||
StartFF2 --> FFNotify
|
||||
|
||||
FFNotify --> FFTrack[F&F Tracking System Activated]
|
||||
FFTrack --> FFStakeholders[Each Stakeholder Receives Task]
|
||||
|
||||
FFStakeholders --> FFFinance[Finance: Settlement Forms]
|
||||
FFStakeholders --> FFLegal[Legal: Clearance Forms]
|
||||
FFStakeholders --> FFOthers[Other Stakeholders: Respective Forms]
|
||||
|
||||
FFFinance --> FFUpdate1[Update Status in System]
|
||||
FFLegal --> FFUpdate2[Update Status in System]
|
||||
FFOthers --> FFUpdate3[Update Status in System]
|
||||
|
||||
FFUpdate1 --> FFCheck{All Tasks Complete?}
|
||||
FFUpdate2 --> FFCheck
|
||||
FFUpdate3 --> FFCheck
|
||||
|
||||
FFCheck -->|No| FFReminder[Send Reminder if TAT Exceeded]
|
||||
FFReminder --> FFCheck
|
||||
|
||||
FFCheck -->|Yes| BlockDealer[Block Dealer from System]
|
||||
BlockDealer --> FFComplete[Send Completion Email to All Stakeholders]
|
||||
|
||||
FFComplete --> End([Process Complete])
|
||||
RejectEmail --> End
|
||||
ExpireLink --> End
|
||||
ZMReject --> End
|
||||
RBMReject --> End
|
||||
NBHReject --> End
|
||||
EORReject --> End
|
||||
TermWithdraw --> End
|
||||
|
||||
style Start fill:#90EE90
|
||||
style End fill:#FFB6C1
|
||||
style ActiveDealer fill:#87CEEB
|
||||
style NBHApproval fill:#FFD700
|
||||
style EORApproval fill:#FFD700
|
||||
style ResignNBH fill:#FFD700
|
||||
style TermCEO fill:#FFD700
|
||||
style BlockDealer fill:#FF6B6B
|
||||
54
field_visit_mermaid.mermaid
Normal file
54
field_visit_mermaid.mermaid
Normal file
@ -0,0 +1,54 @@
|
||||
graph TD
|
||||
Start([Start: Field Visit Planning]) --> FJC[FJC Planning Module]
|
||||
|
||||
FJC --> FJC1[Document Preparation]
|
||||
FJC --> FJC2[Review & Approval Flow]
|
||||
FJC --> FJC3[Dealer Coordination]
|
||||
|
||||
FJC1 --> VE[Visit Execution Module]
|
||||
FJC2 --> VE
|
||||
FJC3 --> VE
|
||||
|
||||
VE --> VE1{Field Visit<br/>As Per Plan?}
|
||||
VE1 -->|Yes| VE2[Execute Visit]
|
||||
VE1 -->|No| VE3[Re-plan Changes]
|
||||
VE3 --> VE2
|
||||
VE2 --> VE4[Dealer Discussion]
|
||||
|
||||
VE4 --> DM[Discussion Management Module]
|
||||
|
||||
DM --> DM1[Capture Actionable Insights]
|
||||
DM --> DM2[Record Feedback]
|
||||
DM --> DM3[Performance Metrics]
|
||||
|
||||
DM1 --> MOM[MOM Creation Module]
|
||||
DM2 --> MOM
|
||||
DM3 --> MOM
|
||||
|
||||
MOM --> MOM1[Structured Documentation]
|
||||
MOM --> MOM2[Action Item Tracking]
|
||||
MOM --> MOM3[Task Delegation]
|
||||
|
||||
MOM1 --> CS[Closure & Sharing Module]
|
||||
MOM2 --> CS
|
||||
MOM3 --> CS
|
||||
|
||||
CS --> CS1[Document Submission]
|
||||
CS1 --> CS2[Archiving]
|
||||
CS2 --> CS3[Stakeholder Communication]
|
||||
|
||||
CS3 --> AW[Approval Workflow]
|
||||
|
||||
AW --> AW1{Hierarchy-Based<br/>Approval}
|
||||
AW1 -->|Approved| End1([Completed & Archived])
|
||||
AW1 -->|Rejected| Feedback[Feedback to Team]
|
||||
Feedback --> FJC
|
||||
|
||||
style FJC fill:#e1f5ff
|
||||
style VE fill:#fff4e1
|
||||
style DM fill:#f0e1ff
|
||||
style MOM fill:#e1ffe1
|
||||
style CS fill:#ffe1f5
|
||||
style AW fill:#ffe1e1
|
||||
style Start fill:#90EE90
|
||||
style End1 fill:#90EE90
|
||||
80
settlment_diagram.mermaid
Normal file
80
settlment_diagram.mermaid
Normal file
@ -0,0 +1,80 @@
|
||||
graph TD
|
||||
Start([Start: Dealer Claim Process]) --> RI[1.Request Initiation]
|
||||
|
||||
RI --> RI1[Requestor Submits Request]
|
||||
RI1 --> RI2[Activity Type]
|
||||
RI1 --> RI3[Dealer Info]
|
||||
RI1 --> RI4[Date/Location]
|
||||
RI1 --> RI5[Activity Details & Period]
|
||||
|
||||
RI2 --> PS[2.Proposal Submission]
|
||||
RI3 --> PS
|
||||
RI4 --> PS
|
||||
RI5 --> PS
|
||||
|
||||
PS --> PS1[Dealer Submits Proposal]
|
||||
PS1 --> PS2[Cost Breakup]
|
||||
PS1 --> PS3[Timeline for Closure]
|
||||
PS1 --> PS4[Supporting Documents]
|
||||
|
||||
PS2 --> RE[3.Request Evaluation]
|
||||
PS3 --> RE
|
||||
PS4 --> RE
|
||||
|
||||
RE --> RE1{Requestor Reviews}
|
||||
RE1 -->|Needs Clarification| RE2[Request More Info]
|
||||
RE2 --> PS1
|
||||
RE1 -->|Approved| RE3[Confirm to Proceed]
|
||||
|
||||
RE3 --> DLA[4.Dept.Lead Approval]
|
||||
|
||||
DLA --> DLA1{Lead Reviews Request}
|
||||
DLA1 -->|Needs Clarification| DLA2[Request Clarification]
|
||||
DLA2 --> RE
|
||||
DLA1 -->|Approved| DLA3[Approve Request]
|
||||
|
||||
DLA3 --> BUD[5.Budgeting]
|
||||
|
||||
BUD --> BUD1[Block Budget]
|
||||
BUD1 --> BUD2[Assign to IO<br/>Internal Order]
|
||||
|
||||
BUD2 --> AC[6.Activity Creation]
|
||||
|
||||
AC --> AC1[System Creates Activity]
|
||||
AC1 --> AC2[Auto-Email Confirmation]
|
||||
AC2 --> AC3[Notify Requestor]
|
||||
AC2 --> AC4[Notify Dealer]
|
||||
AC2 --> AC5[Notify Lead]
|
||||
|
||||
AC3 --> AE[7.Activity Execution]
|
||||
AC4 --> AE
|
||||
AC5 --> AE
|
||||
|
||||
AE --> AE1[Dealer Executes Activity]
|
||||
AE1 --> AE2[Submit Required Documents]
|
||||
|
||||
AE2 --> CA[8.Claim Approval]
|
||||
|
||||
CA --> CA1{Requestor Reviews<br/>Documents}
|
||||
CA1 -->|More Info Needed| CA2[Request Additional Info]
|
||||
CA2 --> AE2
|
||||
CA1 -->|Approved| CA3{Approval Type}
|
||||
|
||||
CA3 -->|Full Approval| EI[9.E-Invoicing]
|
||||
CA3 -->|Partial Approval| EI
|
||||
|
||||
EI --> EI1[Generate E-Invoice]
|
||||
EI1 --> EI2[Issue Credit Note]
|
||||
EI2 --> End([Claim Settled])
|
||||
|
||||
style RI fill:#e3f2fd
|
||||
style PS fill:#f3e5f5
|
||||
style RE fill:#fff3e0
|
||||
style DLA fill:#ffebee
|
||||
style BUD fill:#e8f5e9
|
||||
style AC fill:#fce4ec
|
||||
style AE fill:#e0f2f1
|
||||
style CA fill:#fff9c4
|
||||
style EI fill:#e1bee7
|
||||
style Start fill:#90EE90
|
||||
style End fill:#90EE90
|
||||
Loading…
Reference in New Issue
Block a user