User Allocation and Allotment

Author(s)

• Reshmi Karan
• Sayan Mukherjee
• Saptarshi Mukherjee

Last Updated Date

2024-10-23

---

SRS References

---

Version History

Version	Date	Changes	Author
1.0	2024-10-21	Initial draft	Reshmi Karan, Sayan Mukherjee, Saptarshi Mukherjee

---

Feature Overview

Objective:

The objective of the User Allocation and Allotment feature is to efficiently manage the distribution of products among users and dealers, ensuring optimal utilization of inventory while maintaining accurate records of allocation and remaining stock. Key Goals: Track the inventory count of products received in batches. Allow admins to allocate products to users based on predefined criteria. Enable users to allocate products to dealers based on needs and requests. Ensure visibility of allocated and available inventory to all stakeholders(owner).

Scope:
This feature is specifically tailored for the Fleeto platform, focusing on the internal management of product distribution to enhance operational efficiency.

Dependencies:
(List any external dependencies, libraries, or other features that this feature depends on.)

---

Requirements

(List all the functional and non-functional requirements that the feature must meet.)

Functional Requirements

1. Batch Management: Ability to add product count based on batches.
2. User Allocation: admin must be able to provide allocation of products from available batches to sales person(user).
3. Dealer Allotment: Sales person(user)must be able to provide allotment products to dealers based on their needs and requests.

Batch Management:

Admins must have the capability to add product counts based on received batches. The system should allow viewing of batch details including total counts and allocated counts. User Allocation:

Admins should be able to allocate products from available batches to users with appropriate validation. The system must log each allocation event for auditing purposes. Dealer Allotment:

Users (salespersons) must be able to allocate products to dealers based on their requests. There must be a mechanism to track and view all allocations made to dealers.

Security: Ensure that only authorized users can perform allocations and access sensitive data. Implement role-based access control to manage permissions effectively.

Performance: The system should be able to handle concurrent allocations without performance degradation. Queries for batch and allocation data must return results within a reasonable time frame.

---

Design Specifications

(Provide detailed design specifications, including UI/UX designs, API interfaces, and any other relevant architectural details.)

• UI/UX Design:
  (Include wireframes, mockups, or links to design files.)

• Data Models:
  (Detail the data structures, including database schemas or objects.)

  public record BatchResource
  {
      public Guid BatchResourceId { get; set; }
      public Guid BatchId { get; set; }
      public Guid CatelogProductId { get; set; }          // Foreign key to the ProductCatelog
      public int Count { get; set; }                      // Total count of this product in this batch
      public int AllocatedCount { get; set; } = 0;        // How many units have been allocated from this batch
      public string? LogUserName { get; set; }
      public System.DateTime? LogDts { get; set; }
  
      // Calculate how many are available for allocation
      public int AvailableCount => Count - AllocatedCount;
  }
  public class UserAllocation
  {
      public Guid AllocationId { get; set; }              // Unique ID for this allocation entry
      public Guid UserId { get; set; }                    // Foreign key to the User
      public Guid UserName { get; set; }                  // Foreign key to the User
      public Guid CatelogProductId { get; set; }          // Foreign key to the ProductCatelog
      public Guid BatchResourceId { get; set; }           // Foreign key to the BatchResource
      public int AllocatedCount { get; set; }             // Number of products allocated
      public System.DateTime AllocationDts { get; set; }  // Allocation date and time
      public string? LogUserName { get; set; }
  }
  public class DealerAllotment
  {
      public Guid AllotmentId { get; set; }               // Unique ID for this allocation entry
      public Guid UserId { get; set; }                    // Foreign key to the User
      public Guid UserName { get; set; }                  // Foreign key to the User
      public Guid DealerId { get; set; }                  // Foreign key to the dealer
      public Guid CatelogProductId { get; set; }          // Foreign key to the ProductCatelog
      public int AllocatedCount { get; set; }             // Number of products allocated
      public System.DateTime AllocationDts { get; set; }  // Allocation date and time
      public string? LogUserName { get; set; }
  }

• API Interfaces:
  (Define the APIs required for this feature, including endpoints, methods, request/response formats.)

  Endpoint	Method	Parameters	Response	Response Status Codes
  /product/batch_resource_add	POST	BatchResource (required)	String (Message)	200, 204, 500
  /product/batch_resource_get	GET	Filter (optional)	List<BatchResource>	200, 204, 500
  /product/userallocation	POST	UserAllocation (required)	String (Message)	200, 204, 500
  /product/get_userallocation	GET	Filter (optional)	List<UserAllocation>	200, 204, 500
  /product/dealerallotment	POST	DealerAllotment (required)	String (Message)	200, 204, 500
  /product/get_dealerallotment	GET	Filter (optional)	List<DealerAllotment>	200, 204, 500

• Third-Party Integrations:
  (List any third-party services or tools that need to be integrated.)

• Workflow:
  (Describe the end-to-end workflow of the feature, detailing how different components interact, including the sequence of events, data flow, and the user journey.)

  1. Admin logs into the system and accesses the batch management interface.
  2. Admin adds new batches and updates counts.
  3. Admin allocates products to salespersons, logging each transaction.
  4. Salespersons receive notifications of allocations and can view their product counts.
  5. Salespersons allot products to dealers based on requests, logging dealer allocations.
  6. All allocation and allotment events are recorded for reporting and auditing

---

Development Tasks & Estimates

(Break down the development process into smaller tasks and provide time estimates for each.)

No	Task Name	Estimate (Hours)	Dependencies	Notes
1	Backend Model create	1 hours
2	Backend Database schema create	1 hours
3	Backend Set API: Implement Batch Management	3 hours
4	Backend Get API: Implement Batch Management	4 hours
5	Backend Set API: Implement User Allocation	4.5 hour
6	Backend Get API: Implement User Allocation	4 hours
7	Backend Send allocation email to user	2 hours
8	Backend Set API: Implement Dealer Allotment	4 hours
9	Backend Get API: Implement Dealer Allotment	4 hours
10	Backend Testing	5 hours
11	Backend Integration Testing	5 hours
12	Total	37.5 hour

---

Testing & Quality Assurance

(Outline the testing strategy and quality assurance measures for the feature.)

• Unit Tests:
  (List the unit tests that will be written for this feature.)

  Test cases for each method in the BatchResource, UserAllocation, and DealerAllotment classes. Verify allocation counts are correctly updated.

  Key Areas for Unit Testing:

  Batch Management:

  Test Cases: Verify adding a new batch with valid product data. Validate retrieval of existing batches from the database. Ensure proper error handling for invalid data inputs (e.g., negative product counts).

  User Allocation:

  Test Cases: Test product allocation to users from an available batch. Verify allocation logging (user ID, product ID, allocation time). Ensure handling of edge cases (e.g., allocating more products than available in the batch). Validate responses for both successful and failed allocations.

  Dealer Allotment:

  Test Cases: Ensure proper allotment of products to dealers based on requests. Check that the allotted quantity is correctly deducted from the user’s allocation. Verify tracking and logging of dealer allotments.

  Security and Access Control:

  Test Cases: Confirm only authorized users can allocate or allot products. Verify access control restrictions for various roles (admins, salespersons, etc.).

• Integration Tests:
  (Describe how integration testing will be conducted.)

• Acceptance Criteria:
  (Define the criteria that must be met for the feature to be considered complete.)

• Testing Tools:
  (List any tools that will be used for testing.)

---

Deployment Considerations

(Describe any deployment considerations, including environment configurations, feature toggles, or migration steps.)

• Configuration Changes:

  CREATE TABLE BatchResource (
    BatchResourceId UUID PRIMARY KEY,       -- Unique identifier for the batch resource
    BatchId UUID NOT NULL,                   -- Identifier for the batch
    CatalogProductId UUID NOT NULL,          -- Foreign key to ProductCatalog
    Count INT NOT NULL,                      -- Total count of this product in this batch
    AllocatedCount INT DEFAULT 0,            -- Count of allocated products
    LogUserName VARCHAR(255),                -- Username of the user who logged this entry
    LogDts TIMESTAMP DEFAULT CURRENT_TIMESTAMP,  -- Timestamp of the log entry
    FOREIGN KEY (CatalogProductId) REFERENCES ProductCatalog(CatalogProductId)
  );
  CREATE TABLE UserAllocation (
    AllocationId UUID PRIMARY KEY,           -- Unique identifier for the allocation
    UserId UUID NOT NULL,                    -- Foreign key to the user
    UserName string NOT NULL,                    -- Foreign key to the user
    CatalogProductId UUID NOT NULL,          -- Foreign key to ProductCatalog
    BatchResourceId UUID NOT NULL,           -- Foreign key to BatchResource
    AllocatedCount INT NOT NULL,             -- Number of products allocated
    AllocationDts TIMESTAMP DEFAULT CURRENT_TIMESTAMP,  -- Allocation date and time
    LogUserName VARCHAR(255),                -- Username of the user who made the allocation
    FOREIGN KEY (CatalogProductId) REFERENCES ProductCatalog(CatalogProductId),
    FOREIGN KEY (BatchResourceId) REFERENCES BatchResource(BatchResourceId),
    FOREIGN KEY (UserId) REFERENCES tblUser(UserId)
  );
  CREATE TABLE DealerAllotment (
    AllotmentId UUID PRIMARY KEY,            -- Unique identifier for the allotment
    UserId UUID NOT NULL,                    -- Foreign key to the user
    UserName string NOT NULL,                    -- Foreign key to the user
    DealerId UUID NOT NULL,                  -- Foreign key to the dealer
    CatalogProductId UUID NOT NULL,          -- Foreign key to ProductCatalog
    AllocatedCount INT NOT NULL,             -- Number of products allocated
    AllocationDts TIMESTAMP DEFAULT CURRENT_TIMESTAMP,  -- Allocation date and time
    LogUserName VARCHAR(255),                -- Username of the user who made the allotment
    FOREIGN KEY (CatalogProductId) REFERENCES ProductCatalog(CatalogProductId),
    FOREIGN KEY (UserId) REFERENCES tblUser(UserId)

);

- **Rollout Plan**:  
(Outline the plan for rolling out the feature, including any phased releases.)

---

## **Risks & Mitigations**
(Identify potential risks and the strategies to mitigate them.)

| **Risk**                 | **Impact** | **Likelihood** | **Mitigation Strategy**                  |
|--------------------------|------------|----------------|------------------------------------------|

---

## **Review & Approval**
(Include a section for review and approval by stakeholders.)

- **Reviewer**:  
(Name and role of the person reviewing the document.)

- **Approval Date**:  
(Date when the feature is approved for development.)

---

**Notes**  
(Add any additional notes or considerations related to the feature development here.)