Re_Figma_Code/SEPARATION_IMPLEMENTATION.md

Request Type Separation Implementation

Overview

Successfully implemented complete separation between Custom Requests and Claim Management Requests to ensure independent processes, databases, and components.

Architecture

1. Separate Databases

Custom Request Database

• Location: /utils/customRequestDatabase.ts
• Purpose: Stores all custom requests created via NewRequestWizard
• Export: CUSTOM_REQUEST_DATABASE
• API Endpoints: CUSTOM_REQUEST_API_ENDPOINTS
• Features:
  • User-defined workflow
  • Custom approvers added during creation
  • Spectators and tagged participants
  • Category/subcategory fields
  • Flexible approval steps

Claim Management Database

• Location: /utils/claimManagementDatabase.ts
• Purpose: Stores all claim management requests created via ClaimManagementWizard
• Export: CLAIM_MANAGEMENT_DATABASE
• API Endpoints: CLAIM_MANAGEMENT_API_ENDPOINTS
• Features:
  • Fixed 8-step workflow process
  • Dealer information (code, name, contact, address)
  • Activity details (name, type, location, date)
  • Budget tracking
  • Specialized modals (DealerDocumentModal, InitiatorVerificationModal)

2. Separate Detail Components

Request Detail Component

• Location: /components/RequestDetail.tsx
• Purpose: Display custom/standard requests only
• Database: Uses CUSTOM_REQUEST_DATABASE
• Features:
  • Standard initiator information
  • Category and subcategory display
  • Approvers shown from request creation
  • General description and specifications
  • Flexible workflow steps
  • Standard action buttons

Claim Management Detail Component

• Location: /components/ClaimManagementDetail.tsx
• Purpose: Display claim management requests only
• Database: Uses CLAIM_MANAGEMENT_DATABASE
• Features:
  • Dealer information prominently displayed
  • Activity information section
  • 8-step workflow with specific actions per step
  • Budget/amount tracking
  • Claim-specific modals (dealer docs, verification)
  • Purple theme for claim management branding
  • Step-specific action buttons (Upload Documents, Verify Amount, etc.)

3. App.tsx Routing Logic

The main App component now includes intelligent routing:

case 'request-detail':
  const isClaimRequest = CLAIM_MANAGEMENT_DATABASE[selectedRequestId];
  const isCustomRequest = CUSTOM_REQUEST_DATABASE[selectedRequestId];
  
  if (isClaimRequest) {
    return <ClaimManagementDetail ... />;
  } else if (isCustomRequest) {
    return <RequestDetail ... />;
  }

4. API Endpoint Separation

Each database file includes its own API endpoint constants:

Custom Request Endpoints

• /api/v1/custom-request/*
• Includes: create, update, get, list, approve, reject, add approver/spectator/tagged, documents, work notes, etc.

Claim Management Endpoints

• /api/v1/claim-management/*
• Includes: create, update, get, list, dealer document upload, initiator evaluate, generate IO, department approval, completion docs, verify, e-invoice, credit note, etc.

Benefits

1. Complete Independence

• Changes to claim management don't affect custom requests
• Changes to custom requests don't affect claim management
• Each process has its own data structure and business logic

2. Future-Proof

• Easy to add new template types (e.g., Budget Approval, Travel Requests)
• Each new template gets its own database and detail component
• No cross-contamination between processes

3. API Ready

• Separate endpoints allow different backend services
• Different authentication/authorization per process type
• Different data validation and business rules

4. Maintainability

• Clear separation of concerns
• Easy to debug issues (know which system to check)
• Independent testing for each process type

Data Flow

Custom Request Flow

1. User clicks "Custom Request" in NewRequestWizard
2. Fills out form with custom approvers, spectators, etc.
3. Submitted to CUSTOM_REQUEST_DATABASE
4. Clicking on request triggers RequestDetail component
5. All actions use CUSTOM_REQUEST_API_ENDPOINTS

Claim Management Flow

1. User clicks "Existing Template" → "Claim Management"
2. Navigates to ClaimManagementWizard
3. Fills out claim-specific form (dealer, activity, budget)
4. Submitted to CLAIM_MANAGEMENT_DATABASE
5. Clicking on claim triggers ClaimManagementDetail component
6. All actions use CLAIM_MANAGEMENT_API_ENDPOINTS

Database Schema Differences

Custom Request

{
  id: string
  title: string
  description: string
  category: string
  subcategory: string
  status: string
  priority: string
  template: 'custom'
  approvalFlow: [...] // User-defined
  // No claimDetails
}

Claim Management Request

{
  id: string
  title: string
  template: 'claim-management'
  claimDetails: {
    activityName: string
    activityType: string
    location: string
    dealerCode: string
    dealerName: string
    dealerEmail: string
    dealerPhone: string
    dealerAddress: string
    estimatedBudget: string
    // ... more claim-specific fields
  }
  approvalFlow: [...] // Fixed 8-step process
}

Visual Differences

Request Detail (Custom)

• Blue theme
• Standard file icon
• Category/Subcategory displayed
• "Request Detail" terminology
• Generic approval buttons

Claim Management Detail (Purple)

• Purple theme throughout
• Receipt/claim icon
• "Claim Management" badge
• Dealer and Activity sections
• "Claim Amount" instead of "Total Amount"
• Step-specific buttons (Upload Documents, Verify Amount, etc.)
• "Claim Activity Timeline" instead of "Activity Timeline"

Migration Notes

Legacy Database

• Old REQUEST_DATABASE in App.tsx is now marked as LEGACY_REQUEST_DATABASE
• Combined export REQUEST_DATABASE = custom + claim for backward compatibility
• Will be removed in future once all components updated

Components to Update (Future)

• Dashboard.tsx - update to use both databases
• RequestsList.tsx - update to use both databases
• MyRequests.tsx - update to use both databases

Testing Checklist

• Custom request creation works
• Custom request detail page displays correctly
• Custom request actions (approve/reject) work
• Claim management creation works
• Claim management detail page displays correctly
• Claim-specific actions work (dealer upload, verification)
• No cross-contamination between types
• Routing correctly identifies request type
• Proper error handling for missing requests

Future Enhancements

1. Add more template types (Budget Approval, Travel Request, etc.)
2. Create utility functions for database operations
3. Add TypeScript interfaces for better type safety
4. Implement actual API integration
5. Add request type indicators in lists
6. Create admin panel for template management