Customer Management System

Author(s)

• Arpita Dey

Last Updated Date

2024-10-03

---

SRS References

• 2.1.1

---

Version History

Version	Date	Changes	Author
1.0	2024-10-03	Initial draft	Arpita Dey

---

Feature Overview

Objective:
Extend the current User Management system to manage additional customer activities. This includes handling wallet transactions, sending emails to customers, viewing customer details, and client/case breakdowns based on roles.

Scope:
The feature will introduce new APIs for refunding and debiting wallet balances, sending emails, and viewing customer details. Additionally, superadmin, admin, and standalone users will have varying levels of access to client and case data.

Dependencies:

• Existing User Management system.
• Client Management System for client and case breakdown.
• APIs for wallet transactions, customer emails, and customer data retrieval.

---

Requirements

1. Implement an API for refunding wallet balances.
2. Implement an API for debiting wallet balances.
3. Create a new API for emailing customers (admin/superadmin only).
4. Add functionality to view customer details.
5. Provide a client and case breakdown API based on user roles.

---

Design Specifications

• UI/UX Design:
  No changes in the UI. All changes are related to API functionality.

• Data Models:
  The following models will be used for the new APIs:

  public record WalletRefundData
  {
      public Guid JobId { get; set; }
      public required string UserEmail { get; set; }
      public string? Reason { get; set; }
      public float Amount { get; set; } = 0f;
      public string? LogUser { get; set; }
  }
  
  public record WalletDebitData
  {
      public Guid JobId { get; set; }
      public required string UserEmail { get; set; }
      public float Amount { get; set; } = 0f;
      public string? Description { get; set; }
      public string? LogUser { get; set; }
  }
  
  public class UserDetails
  {
      public string? FirstName { get; set; }
      public string? LastName { get; set; }
      [Required(ErrorMessage = "Email is required")]
      [EmailAddress]
      public required string Email { get; set; }
      [Phone]
      public string? Phone { get; set; }
      [Required(ErrorMessage = "User role is required")]
      public required string Role { get; set; }
      public UserRole? Type { get; set; }
      public UserStatus Status { get; set; } = UserStatus.Uninitialized;
      [DataType(DataType.DateTime)]
      public DateTime? Created { get; set; }
      [DataType(DataType.DateTime)]
      public DateTime? Updated { get; set; }
  }
  
  public class CustomerDetails : UserDetails
  {
      public int TotalClients { get; set; }
      public int TotalCases { get; set; }
      public int TotalJobs { get; set; }
  }
  
  public class ClientFilter
  {
      public ClientQueryType QueryType { get; set; } = ClientQueryType.Unset;
      public Guid? ClientId { get; set; } = null;
      public string ClientName { get; set; } = string.Empty;
      public string ClientState { get; set; } = string.Empty;
      public string ClientZip { get; set; } = string.Empty;
      public bool? ActiveStatus { get; set; } = null;
      public Guid? UserId { get; set; } = null;
      public Guid? SubscriberId { get; set; } = null;
      public string? LogUser { get; set; } = null;
  }
  
  public class ClientStruct
  {
      public Guid ClientId { get; set; }
      public string? ClientName { get; set; }
      public Guid? SubscriptionId { get; set; }
      public Guid? UserId { get; set; }
      public bool IsActive { get; set; } = true;
      public ClientMetaData? ClientMetaData { get; set; } = null;
      public ClientCompanyDetails? ClientCompanyDetails { get; set; } = null;
      public string? CreatedBy { get; set; }
      public DateTime? CreatedOn { get; set; }
  }
  
  public class CaseStruct
  {
      public Guid CaseId { get; set; }
      public string? CaseName { get; set; }
      public string Description { get; set; } = string.Empty;
  }
  public class SendMailToCustomer
  {
      public required string EmailId { get; set; }
      public string CC { get; set; }
      public string BCC { get; set; }
      public string? Subject { get; set; }
      public string? Body { get; set; } = string.Empty;
  }

• API Interfaces:

  Endpoint	Method	Parameters	Response	Response Status Codes
  /wallet/refund	POST	WalletRefundData (body)	String (Message)	200, 204, 500
  /wallet/debit	POST	WalletDebitData (body)	String (Message)	200, 204, 500
  /customer/send/mail	POST	SendMailToCustomer	String (Message)	200, 204, 500
  /customer/details	GET	None	CustomerDetails	200, 204, 500
  /client/list	POST	ClientFilter (body)	List<ClientStruct>	200, 204, 500
  /case/mappedlist	POST	None	List<CaseStruct>	200, 204, 500

• Third-Party Integrations:
  None.

• Workflow:

  1. Wallet operations are performed using refund and debit APIs.
  2. Admin and superadmin can send emails to customers.
  3. Customer details can be retrieved using the new customer/details API.
  4. Client and case breakdowns are based on the Client Management System, where superadmin has full access, admin sees only their claimed jobs, and standalone users see only their own.

---

Development Tasks & Estimates

No	Task Name	Estimate (Hours)	Dependencies	Notes
1	Define Wallet Refund API	0 hours	Existing wallet logic
2	Define Wallet Debit API	0 hours	Existing wallet logic
3	Implement Mail API for Admins	1.5 hours
4	Implement Customer Details API	3 hours
5	Implement Client/Case Breakdown APIs	0 hours	Client Management System
4	Integration Testing	1hr
6	Total	5.5hours

---

Testing & Quality Assurance

• Unit Tests:
  Test cases for wallet refund, wallet debit, email, customer details, and client/case breakdown.

• Integration Tests:
  Integration testing will be performed to validate interaction between APIs and the Client Management System.

• Acceptance Criteria:

  • Wallet refund and debit operations work as expected.
  • Only admins and superadmins can use the mail API.
  • Customer details API returns correct data.
  • Client and case breakdowns display based on user roles.

• Testing Tools:
  Postman for API testing.

---

Deployment Considerations

• Configuration Changes:
  None.

• Rollout Plan:
  Feature will be rolled out in phases starting with wallet operations, followed by customer details and client/case breakdown.

---

Risks & Mitigations

Risk	Impact	Likelihood	Mitigation Strategy
Incorrect wallet transactions	High	Medium	Thorough testing of wallet API operations
Data leakage in client/case APIs	High	Low	Ensure role-based access control is strictly enforced
Mail API failure	Medium	Medium	Email service failover strategy

---

Review & Approval

• Reviewer:
  Rupanjan Hari

• Approval Date:
  2024-10-16

---

Notes

• Feature is dependent on the Client Management System for client/case data.

---

Let me know if you'd like any further modifications!