Case study / ACADEMIC TEAM PROJECT

3A TrackPro System.

An academic team project modeling cash sales, inventory, purchasing and reporting for an assumed single-location hardware-store scenario.

Project context

ACADEMIC TEAM PROJECT

Technologies

PHP · Laravel · Blade · MySQL · BCMath · Tailwind CSS · Vite · PHPUnit

PROJECT OVERVIEW3A TrackPro System

An academic team project modeling cash sales, inventory, purchasing and reporting for an assumed single-location hardware-store scenario.

PHP · Laravel · Blade

01 / Purpose

The problem

An assumed hardware-store scenario needs consistent sales, stock and purchasing records while preserving transaction history and Admin/Staff boundaries.

02 / People

Role & context

The project tracker records my responsibilities in business rules, database design, checkout, stock workflows, sale voiding, account controls and integration review. My Git account is associated with implementation and testing checkpoints across these areas; this is not proof of sole authorship.

Academic team project by The Visionaries. Product and UI work, reporting, testing and documentation also have documented team assignments; application-wide outcomes are not attributed to one person.

Planning, coding and testing used AI-assisted workflows. Recorded Codex browser work supports testing history; exact generated-code episodes and individual human decisions are not inferred from Git ownership.

03 / The work

What it does

  • Cash-only POS, historical receipts and controlled cash-register workflows
  • Product variants, stock thresholds and movement history
  • Purchase orders, partial receiving, follow-up orders and separate damaged-receiving evidence
  • Admin-only full sale voiding with stock restoration
  • Role-restricted reports, account management and audit views

04 / Implementation

How it works

Traditional Laravel and Blade architecture uses focused services, Eloquent models and report queries. Transactional stock workflows use row locks, exact BCMath arithmetic and duplicate-submission controls.

Repository documentation records core feature freeze and separate academic verification. The selected revision contains the described business workflows; no production adoption or quantified business improvement is established.

05 / Evidence

Testing & limitations

Separate historical runs: FT15 recorded 30 PASS / 0 FAIL; FT17 remains paused at 8 PASS / 1 FAIL / 0 BLOCKED / 28 REMAINING, with TC-AUTH-006 formally FAIL and controlled retest deferred; FT18 recorded 19 PASS / 0 FAIL; WST2 recorded 19 PASS / 0 FAIL. FT18 pre-verification separately recorded 220 focused tests / 2,604 assertions and 558 SQLite tests / 6,112 assertions. Guarded MySQL evidence was retained, not rerun in FT18. These totals are not combined into a new all-PASS result.

Sale voiding is a full reversal with retained evidence, not refunds or cash-out. Supplier master-data management, credit sales, discounts and profit accounting are excluded. SQLite tests do not establish MySQL constraint or concurrency correctness. Accessibility and device coverage remain limited; final presentation completion and current deployment are unverified.

Next project

Interactive Gift Engine
Get in touch ↗