# Dealer Claim Email Templates - Planning Document

## Overview
This document outlines all email templates required for the Dealer Claim Management workflow, including support for additional approvers.

---

## Workflow Steps & Email Templates

### 1. **Request Created** ✅ (Already Exists)
- **When**: Claim request is created by initiator
- **Recipients**: Initiator
- **Template**: `requestCreated.template.ts`
- **Status**: ✅ Implemented
- **Notes**: Generic template works for dealer claims

---

### 2. **Dealer Assignment - Proposal Required** ✅ (Uses Existing)
- **When**: Step 1 - Dealer is assigned to submit proposal
- **Recipients**: Dealer
- **Template**: `approvalRequest.template.ts` (single approver)
- **Status**: ✅ Uses existing template
- **Notification Type**: `assignment`
- **Notes**: 
  - Sent when request is created
  - Uses existing approval request template
  - May need dealer-specific customization

---

### 3. **Proposal Submitted** 🆕 (NEW - Recommended)
- **When**: Step 1 - Dealer submits proposal
- **Recipients**: 
  - Initiator (Requestor)
  - Next Approver (Step 2 - Requestor Evaluation)
- **Template**: `dealerProposalSubmitted.template.ts` (NEW)
- **Status**: ❌ Not Implemented
- **Notification Type**: `proposal_submitted`
- **Data Needed**:
  - Request details (number, title, activity name)
  - Dealer information
  - Proposal details (total budget, expected completion date)
  - Cost breakdown summary
  - Dealer comments
- **Notes**: 
  - Confirms to initiator that proposal was received
  - Notifies next approver (initiator) to review

---

### 4. **Proposal Approved** ✅ (Uses Existing)
- **When**: Step 2 - Requestor approves proposal
- **Recipients**: 
  - Initiator (confirmation)
  - Next Approver (Step 3 - Department Lead)
- **Template**: `approvalConfirmation.template.ts`
- **Status**: ✅ Uses existing template
- **Notification Type**: `approval`
- **Notes**: Generic approval confirmation works

---

### 5. **Proposal Rejected** ✅ (Uses Existing)
- **When**: Step 2 - Requestor rejects proposal
- **Recipients**: 
  - Initiator
  - Dealer
  - All participants
- **Template**: `rejectionNotification.template.ts`
- **Status**: ✅ Uses existing template
- **Notification Type**: `rejection`
- **Notes**: Generic rejection notification works

---

### 6. **Department Lead Approval** ✅ (Uses Existing)
- **When**: Step 3 - Department Lead approves and organizes IO
- **Recipients**: 
  - Initiator (confirmation)
  - Next approver (if any additional approvers before Activity Creation)
- **Template**: `approvalConfirmation.template.ts`
- **Status**: ✅ Uses existing template
- **Notification Type**: `approval`
- **Notes**: 
  - May want IO-specific details in email
  - IO details are shown in workflow tab

---

### 7. **Activity Created** 🆕 (NEW - Recommended)
- **When**: After Step 3 approval - Activity is created
- **Recipients**: 
  - Dealer
  - Initiator (Requestor)
  - Department Lead
- **Template**: `activityCreated.template.ts` (NEW)
- **Status**: ❌ Not Implemented (currently uses generic notification)
- **Notification Type**: `activity_created`
- **Data Needed**:
  - Activity name and type
  - Request number
  - Activity date
  - Location
  - IO number (if available)
  - Next steps information
- **Notes**: 
  - Currently sends generic notification (line 2141-2151 in dealerClaim.service.ts)
  - Should be a dedicated template with activity-specific information

---

### 8. **Completion Documents Submitted** 🆕 (NEW - Recommended)
- **When**: Step 4 - Dealer submits completion documents
- **Recipients**: 
  - Initiator (Requestor)
  - Next Approver (Step 5 - Requestor Claim Approval)
- **Template**: `completionDocumentsSubmitted.template.ts` (NEW)
- **Status**: ❌ Not Implemented
- **Notification Type**: `completion_submitted`
- **Data Needed**:
  - Request details
  - Activity completion date
  - Number of participants
  - Total closed expenses
  - Expense breakdown summary
  - Documents submitted count
- **Notes**: 
  - Confirms to initiator that completion docs were received
  - Notifies next approver to review completion

---

### 9. **Requestor Claim Approval** ✅ (Uses Existing)
- **When**: Step 5 - Requestor approves claim
- **Recipients**: 
  - Initiator (confirmation)
  - Next step (DMS push)
- **Template**: `approvalConfirmation.template.ts`
- **Status**: ✅ Uses existing template
- **Notification Type**: `approval`
- **Notes**: Generic approval confirmation works

---

### 10. **E-Invoice Generated** 🆕 (NEW - Recommended)
- **When**: Step 6 - E-Invoice is generated via DMS
- **Recipients**: 
  - Initiator
  - Dealer
  - Finance team (if applicable)
- **Template**: `einvoiceGenerated.template.ts` (NEW)
- **Status**: ❌ Not Implemented
- **Notification Type**: `einvoice_generated`
- **Data Needed**:
  - E-Invoice number
  - Invoice date
  - DMS number
  - Invoice amount
  - Request details
  - Download link (if available)
- **Notes**: 
  - Currently logged as activity only (line 1856-1863 in dealerClaim.service.ts)
  - Should notify relevant parties when invoice is ready

---

### 11. **Credit Note Sent to Dealer** 🆕 (NEW - Recommended)
- **When**: Step 8 - Credit note is sent to dealer
- **Recipients**: 
  - Dealer (primary)
  - Initiator (for record)
  - Finance team
- **Template**: `creditNoteSent.template.ts` (NEW)
- **Status**: Required implementation
- **Notification Type**: `credit_note_sent`
- **Data Needed**:
  - Credit note number
  - Credit note date
  - Credit note amount
  - Request number
  - Activity name
  - Dealer information
  - Reason for credit note
  - Download link (if available)
- **Notes**: 
  - Planned for email implementation
  - Critical for dealer notification

---

### 12. **Additional Approver Assignment** ✅ (Uses Existing)
- **When**: Additional approver is added between any steps
- **Recipients**: Additional Approver
- **Template**: `approvalRequest.template.ts` or `multiApproverRequest.template.ts`
- **Status**: ✅ Uses existing template
- **Notification Type**: `assignment`
- **Notes**: 
  - Can use existing approval request templates
  - Should show approval chain if multiple approvers

---

### 13. **Additional Approver Approval** ✅ (Uses Existing)
- **When**: Additional approver approves/rejects
- **Recipients**: 
  - Initiator
  - Next approver
- **Template**: `approvalConfirmation.template.ts` or `rejectionNotification.template.ts`
- **Status**: ✅ Uses existing template
- **Notification Type**: `approval` or `rejection`
- **Notes**: Generic templates work for additional approvers

---

## Summary

### ✅ Already Implemented (Using Existing Templates)
1. Request Created
2. Dealer Assignment (Proposal Required)
3. Proposal Approved
4. Proposal Rejected
5. Department Lead Approval
6. Requestor Claim Approval
7. Additional Approver Assignment/Approval

### 🆕 New Templates Needed
1. **Proposal Submitted** (`dealerProposalSubmitted.template.ts`)
   - Priority: Medium
   - When: Dealer submits proposal (Step 1)
   
2. **Activity Created** (`activityCreated.template.ts`)
   - Priority: High
   - When: Activity is created after Step 3 approval
   - Currently uses generic notification
   
3. **Completion Documents Submitted** (`completionDocumentsSubmitted.template.ts`)
   - Priority: Medium
   - When: Dealer submits completion docs (Step 4)
   
4. **E-Invoice Generated** (`einvoiceGenerated.template.ts`)
   - Priority: High
   - When: E-Invoice is generated via DMS (Step 6)
   - Currently only logged as activity
   
5. **Credit Note Sent** (`creditNoteSent.template.ts`)
   - Priority: High
   - When: Credit note is sent to dealer (Step 8)
   - Planned for implementation

---

## Implementation Priority

### High Priority (Critical for Workflow)
1. **Activity Created** - Currently using generic notification, should be branded
2. **E-Invoice Generated** - Important for financial tracking
3. **Credit Note Sent** - Critical for dealer notification

### Medium Priority (Nice to Have)
4. **Proposal Submitted** - Better UX, but existing approval request works
5. **Completion Documents Submitted** - Better UX, but existing approval request works

---

## Template Design Considerations

### 1. Support for Additional Approvers
- All templates should handle dynamic approval chains
- Show approval chain when multiple approvers exist
- Use `multiApproverRequest.template.ts` pattern for multi-level scenarios

### 2. Dealer-Specific Information
- Include dealer name, code, email prominently
- Show activity name and type
- Include dealer-specific fields (dealer comments, etc.)

### 3. Financial Information
- Show budget/amount information clearly
- Include currency formatting (INR)
- Show expense breakdowns where relevant

### 4. Document Links
- Include links to view/download documents
- Link to request detail page
- Include document counts where relevant

### 5. Next Steps
- Clearly indicate what happens next
- Show who needs to take action
- Include deadlines/TAT information

---

## Integration Points

### Notification Service Integration
All new templates need to be integrated in:
- `Re_Backend/src/services/notification.service.ts`
  - Add to `emailTypeMap`
  - Add case in `triggerEmailByType` switch statement

### Email Notification Service Integration
All new templates need methods in:
- `Re_Backend/src/services/emailNotification.service.ts`
  - Add `sendXXX` methods for each template
  - Import template functions
  - Handle data preparation

### Type Definitions
Add interfaces in:
- `Re_Backend/src/emailtemplates/types.ts`
  - Define data interfaces for each template

### Email Preferences
Add notification types in:
- `Re_Backend/src/emailtemplates/emailPreferences.helper.ts`
  - Add to `EmailNotificationType` enum

---

## Example Template Structure

Each new template should follow the pattern:

```typescript
// types.ts
export interface DealerProposalSubmittedData extends BaseEmailData {
  dealerName: string;
  activityName: string;
  activityType: string;
  proposalBudget: number;
  expectedCompletionDate: string;
  dealerComments?: string;
  costBreakupSummary?: string; // Summary of cost items
  // ... other fields
}

// dealerProposalSubmitted.template.ts
export function getDealerProposalSubmittedEmail(data: DealerProposalSubmittedData): string {
  // HTML template with Royal Enfield branding
  // Responsive design
  // Rich text support for descriptions
  // Table support for cost breakdown
}

// emailNotification.service.ts
async sendDealerProposalSubmitted(
  requestData: any,
  dealerData: any,
  initiatorData: any,
  proposalData: any
): Promise<void> {
  // Prepare data
  // Check preferences
  // Send email
}

// notification.service.ts
case 'proposal_submitted':
  await emailNotificationService.sendDealerProposalSubmitted(...);
  break;
```

---

## Testing Checklist

For each new template:
- [ ] Template renders correctly
- [ ] All dynamic fields populate correctly
- [ ] Mobile responsive
- [ ] Tables display correctly (if applicable)
- [ ] Links work correctly
- [ ] Email preferences respected
- [ ] Works with additional approvers
- [ ] Handles missing optional data gracefully
- [ ] Branding consistent with other templates

---

## Notes

1. **Additional Approvers**: All templates should work seamlessly when additional approvers are added between fixed steps. The approval chain should be shown when relevant.

2. **System Steps**: Activity Creation, E-Invoice Generation, and Credit Note Confirmation are now activity logs only (not approval steps), but they still need email notifications.

3. **Dealer vs Internal Users**: Dealer may not be in the system initially - templates should handle this gracefully.

4. **Financial Data**: All financial amounts should be formatted as INR currency with proper decimal places.

5. **Document Links**: Include links to view/download documents where applicable, especially for proposals and completion documents.

