Lab Equipment Issue & Return Tracker for a Polytechnic (React + Spring Boot + MySQL)

Lab Equipment Issue & Return Tracker (LEIRT) is a full-stack web application for the laboratories of a Government or aided polytechnic. In most polytechnic labs, oscilloscopes, digital multimeters, function generators, breadboard trainer kits, soldering stations and hand tools are issued to student batches against a paper register. At the end of the week nobody can say with confidence which batch still holds the second DSO, which multimeter came back with a broken probe, or why the lab has only three working trainer kits left before the practical exam.

LEIRT replaces the register with a simple, role-based system. The lab-in-charge approves issue requests and records returns, the lab assistant maintains the equipment master and stock, and students (one batch leader per batch) raise requests from their phone. Every issue has a due date; overdue items are highlighted, damage and fines are logged against the batch, and the dashboard warns when working stock of any item drops below a set threshold.

The project is built on the 20CS52I Full-Stack pathway stack: a React single-page front end, a Spring Boot REST API with Spring Data JPA, and a MySQL database, built with Maven, unit-tested with JUnit 5 and API-tested with Postman. It is designed for a three-member team doing the 16-week 20CS61P Internship / Project under the DTE Karnataka C-20 curriculum, with each member owning a clear layer of the system so that individual accountability is easy to show during reviews.

Abstract

Polytechnic laboratories hold equipment worth several lakh rupees, yet issue and return are usually tracked in a handwritten register. This makes it hard to find who holds an item, to enforce return dates, to recover the cost of damage and to plan purchases before exams. This project develops the Lab Equipment Issue & Return Tracker, a web application with a React front end, a Spring Boot REST API and a MySQL database. It supports equipment and stock management, batch-wise issue requests with lab-in-charge approval, due-date tracking, returns with condition checks, a damage and fine log, and low-stock alerts. The system is tested with JUnit unit tests, Postman collections and manual test cases.

Introduction

Under the C-20 curriculum, students of the Computer Science and Engineering diploma spend the sixth semester on a 16-week internship or project. Our team studied the Electronics and Digital labs of a polytechnic, where one lab assistant manages around 150 items for more than 20 batches a week. We observed double issues, missing probes and fine amounts decided from memory.

Existing system

• A bound issue register with columns for date, batch, item and signature; no running stock count.
• Damage is noted in the margin; fines are collected in cash with no linked record.
• The lab-in-charge learns about low stock only when a batch cannot be served.
• Reports for the Head of Section are prepared by counting pages at the end of the semester.

Proposed system

• A central equipment master with asset tag, category, lab, total quantity and working quantity.
• Issue requests raised by batch leaders and approved or rejected by the lab-in-charge.
• Automatic due dates, an overdue list and a batch-wise history.
• Return entry with condition (good, minor damage, major damage, lost) that updates stock and opens a fine record.
• Low-stock alerts when working quantity falls below the reorder level set for the item.
• Reports exportable as CSV for audits and the stock-verification register.

Feasibility

• Technical: React, Spring Boot and MySQL are taught in the 20CS52I pathway and run on the lab's existing Windows PCs.
• Economic: all tools are free and open source; no hardware is purchased.
• Operational: screens mirror the register columns the lab staff already know, so training takes under an hour.
• Schedule: the 16-week slot comfortably fits requirement study, three development increments, testing and documentation.

The Electronics and Digital laboratories of a typical polytechnic issue oscilloscopes, digital multimeters, trainer kits and tools to student batches every day, but the only record is a paper register. There is no running stock count, so staff cannot tell at a glance which items are out, which batch holds them or when they are due back. Items are returned late or with missing accessories, and damage is either ignored or fined inconsistently because there is no linked history. The lab-in-charge discovers shortages only when a batch cannot be served during a practical session, and semester-end stock verification takes days of manual counting.

The problem is to design and build a simple, reliable web application that records every issue and return against a batch, enforces approval and due dates, keeps an accurate working-stock count, logs damage and fines with evidence, and alerts staff before stock runs low, while remaining easy enough for lab assistants to use daily.

In scope

• One polytechnic with several labs (Electronics, Digital, Hardware and Networking, Programming).
• Three roles: Lab-in-charge (approver and administrator), Lab Assistant (stock and returns) and Batch Leader (requests on behalf of a batch).
• Equipment master with asset tag, category, quantity, working quantity and reorder level.
• Issue request, approval or rejection, issue, return with condition, damage record and fine.
• Overdue list, low-stock alerts on the dashboard and CSV reports.

Out of scope (v1)

• Online fine payment; fines are marked paid when the receipt number from the college office is entered.
• Barcode or RFID scanning (listed under future scope).
• Purchase orders and vendor management.
• Integration with the college ERP or attendance system.

We follow an Incremental SDLC model. The system is built in three working increments, each reviewed by the internal guide, which fits the C-20 practice of continuous internal evaluation during the 16-week slot.

Working practice: each member keeps a weekly diary of tasks done, code files touched and problems solved. We use a shared Git repository with one branch per member and merge only after the guide's weekly review. This gives clear evidence of individual accountability, which the C-20 scheme expects when projects are done in teams of two or three.