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.
ACADEMIC TEAM PROJECT
PHP · Laravel · Blade · MySQL · BCMath · Tailwind CSS · Vite · PHPUnit
An academic team project modeling cash sales, inventory, purchasing and reporting for an assumed single-location hardware-store scenario.
PHP · Laravel · Blade01 / 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