Requisition and Procurement

Author(s)

• Ramit Ray

Last Updated Date

2025-05-07

---

SRS References

• 3.2.1
• 3.2.2
• 3.2.3

---

Version History

Version	Date	Changes	Author
1.0	2025-05-07	Initial draft	Ramit Ray

---

Feature Overview

Objective:
To manage material requisitions and procurement activities with a clear workflow from request initiation to vendor notification, ensuring traceability and timely execution.

Scope:
This module includes:

• Creation of material requisitions by employees.
• Approval process by designated authorities.
• Purchase order generation by the procurement team.
• Notification and dispatch coordination with vendors.

Dependencies:

• Vendor Master Data
• Item/Material Master Data
• Approver Mapping

---

Requirements

1. System must allow employees to create material requisitions.
2. Each requisition must have a unique system-generated Requisition Number.
3. Approval workflow must support approve, reject, and request modifications.
4. Approved requisitions should convert to Purchase Orders.
5. Vendors must be notified with PO details.
6. Requisition status must be tracked and stored for auditing.
7. Requisition closure should occur post PO issuance.

---

Design Specifications

• UI/UX Design:
  (To be added: Screens for Requisition Form, Approval Dashboard, PO Generation Page)

• Data Models:

  public record MaterialRequisition
  {
    public int Id { get; init; }
    public string RequisitionNumber { get; init; }
    public string ItemDescription { get; init; }
    public int Quantity { get; init; }
    public string Purpose { get; init; }
    public string DepartmentOrMachineId { get; init; }
    public string RequestedByUserId { get; init; }
    public string ApprovalStatus { get; set; }
    public DateTime CreatedDate { get; init; }
  }
  
  public record PurchaseOrder
  {
    public int Id { get; init; }
    public string PONumber { get; init; }
    public string VendorId { get; init; }
    public List<POItem> Items { get; init; }
    public string PaymentTerms { get; init; }
    public string DeliveryTerms { get; init; }
    public DateTime CreatedDate { get; init; }
  }

• API Interfaces:

  Endpoint	Method	Parameters	Response	Status Codes
  /api/v1/requisitions	POST	Requisition data	RequisitionNumber	201, 400, 500
  /api/v1/requisitions/{id}	PUT	Requisition ID, updated data	Updated Requisition	200, 404, 500
  /api/v1/requisitions/approve	POST	Approval decision	Status Message	200, 400, 500
  /api/v1/po	POST	PO data including items, vendor, terms	PONumber	201, 400, 500

• Third-Party Integrations:

  • Email service or Notification Gateway for Vendor communications.

• Workflow:

  1. Employee logs in and raises requisition.
  2. Approver gets notified and reviews the request.
  3. Based on decision, request is approved, rejected, or sent back.
  4. Procurement team converts approved requisition to PO.
  5. PO is sent to vendor; goods are dispatched.
  6. Requisition status is marked as Closed post PO issue.

---

Development Tasks & Estimates

No	Task Name	Estimate (Hours)	Dependencies	Notes
1	Requisition Form UI & Validation	8 hrs	Item Master Data
2	Approval Workflow Integration	10 hrs	Approver Mapping
3	PO Generation Logic & UI	12 hrs	Vendor Master Data
4	Notification Integration (Email/API)	6 hrs	SMTP/Notification Engine
5	Backend Models & DB Schema	8 hrs
6	Total	44 hrs

---

Testing & Quality Assurance

• Unit Tests:

  • Validate Requisition creation.
  • Validate PO generation.

• Integration Tests:

  • Approval flow end-to-end.
  • Email dispatch to vendor.

• Acceptance Criteria:

  • Requisitions can be created, approved, and closed properly.
  • POs must be generated only after valid approvals.
  • Audit trail must capture timestamps and user actions.

• Testing Tools:

  • Postman for API Testing
  • Selenium (optional) for UI flows
  • Xunit/NUnit for backend testing

---

Deployment Considerations

• Configuration Changes:

  • Add SMTP or Email Gateway configurations for vendor notifications.
  • Feature toggles for enabling/disabling procurement.

• Rollout Plan:

  • Deploy on staging with internal procurement team testing.
  • Move to production post user training and dry run.

---

Risks & Mitigations

Risk	Impact	Likelihood	Mitigation Strategy
Approval delays due to user SLA	Medium	High	Auto-reminders and escalation notification
Vendor email bounce/undelivered	High	Medium	Retry mechanism and alternate notification
Incomplete Master Data	Medium	High	Pre-checks and alerts during requisition flow

---

Review & Approval

• Reviewer: [Reviewer Name]

• Approval Date: [To be filled upon approval]

---

Notes

• Payment processing is handled in the separate Accounts Module.
• Vendor registration is managed via Vendor Management Module.