Warehouse Management System (WMS)
Enterprise warehouse management system featuring dynamic 3-level RBAC permissions, hierarchical location mapping, automated QR code labeling, and reflection-based relationship delete validation.
01 — Overview
Overview
a. Modernizing Warehouse Operations
Manual material tracking and physical layout mapping in logistics facilities often result in stock location errors, shipping delays, and inventory mismatch. Traditional spreadsheets lack active validation checks and role-based access parameters.
We engineered the WMS to address these operational inefficiencies. The platform provides logistics managers with real-time controls over inventory states, storage layouts, and material movement ledgers.
b. High-Level System Architecture
We built the system on a modern tech stack consisting of Laravel 12, Filament v4, and TailwindCSS v4. The platform leverages Filament's schema-driven architecture to assemble operational forms, datagrids, and filter elements dynamically.
We separated the system logic using a modular, decoupled resource structure. A customized authorization service (`MenuService`) builds navigation menus dynamically from the database, scoping administrative controls depending on the role's permission set.
- Designed a modular, database-driven navigation menu and permission engine mapping modules to user privileges
- Implemented reflection-based relationship checks in BaseResource to dynamically prevent deletion of active inventory references
- Developed automated QR code generators creating base64 SVG data URLs for physical rack and bin storage labeling
- Modeled warehouse hierarchies representing physical storage bins, racks, fields, and zones
- Coded structured inbound goods receipt (InvIn) and outbound services (InvOut) transaction management dashboards
- Integrated automated audit trail traits to record system activities and changes
02 — Problems & Challenges
Problems & Challenges
a. Preventing Inventory Discrepancies
Deleting active warehouse locations or material references while they are linked to current stock ledgers causes relational database errors and orphan records. Handlers must validate if an entity is referenced across other tables before executing deletes.
We resolved this vulnerability by writing an automated reference validation method inside `BaseResource.php`. When a user attempts to delete a record, the check leverages PHP's Reflection API (`ReflectionClass`) to dynamically inspect relationship definitions on the model. If active relationships exist, the system disables deletion, protecting relational integrity.
b. Structuring Complex Storage Hierarchies [Zone/Rack/Bin]
Representing physical warehouse structures (zones, racks, bins) requires a relational structure that supports flexible classifications while remaining simple for operators to browse.
We modeled this hierarchical layout using `wh_list` (representing physical facilities) and `wh_storages` (representing locations). Location classifications are defined via the `wh_storages_type` enum (supporting `Field`, `Rack`, `Zone`, or `Others`). We integrated QR code generators inside storage pages, generating base64 SVG data URLs for label printing.
c. Real-time Stock Mutation Logic
Warehouse movements involve complex updates across multiple entities: inbound goods receipts (`inv_in`), outbound services (`inv_out`), and internal movements (`inv_move`). Stock mutations must generate sequential transaction numbers and validate material entries without blocking database performance.
We programmed stock tracking logic inside individual Filament resources. For example, `MovementStockResource` generates movement numbers dynamically using sequence formatting (`WH-MOVE/{sequence}/{month}/{year}`). The system routes items through relation managers, saving records with activity logs.
03 — Project Goals
Project Goals
a. Operational Accuracy
We aimed to reduce pick-and-pack errors by introducing automated labeling. By integrating the QR code library, operators can print rack tags directly from location screens. Scanning the label loads the location grid, confirming inventory counts immediately.
b. Streamlining Inbound & Outbound Flows
Our goal was to consolidate inbound material intake and outbound dispatches into a single control panel. We built the `GrSrReportResource` reporting dashboard to execute combined queries, displaying Goods Receipts and Services dispatches inside a single timeline.
04 — Design Process
Design Process
a. Inventory Database Schema Modeling
We modeled the relational schema in MySQL to manage inventories. The database defines: `data_items` (storing item properties), `wh_list` (mapping warehouse facilities), `wh_storages` (mapping storage layout coordinates), and `inv_in`/`inv_out`/`inv_move` (recording stock mutation transactions).
The models include `HasAuditFields` and `HasActivityLog` traits to record system modifications.
b. Operator Dashboard UI/UX
We blueprinted the operator dashboard to prioritize transaction speed. Form structures organize header details, item tables, and remarks into collapsible sections.
The tables utilize compact cell padding, status badges, and color indicators to help managers identify active, pending, or deleted records quickly.
05 — Usability Testing & QA
Usability Testing & QA
a. Stock Logic Validation
Since the system is in active development, our QA focused on logic validation. We wrote unit tests to verify the permission service priority checks, verifying that users are restricted from executing CRUD actions unless explicitly permitted by their role's `privillages_det` record.
b. Concurrency Handling in Development
To prevent transaction errors, we tested concurrent stock movements. We verified that the soft delete logic (`softDelete`) modifies status columns cleanly without causing database locks, protecting transaction ledgers during high-frequency movements.
06 — Prototyping & Handoff
Prototyping & Handoff
a. CI/CD Setup & Development Environment
We established a local sandbox environment to simplify developer onboarding. We configured Composer script shortcuts (`composer run dev`) to start the Laravel server, Vite watcher, and queue listeners concurrently in a single command.
We wrote seeders (`ModulSeeder` and `PrivillagesSeeder`) to populate roles and navigation tables, letting developers test permissions immediately.
b. Feature Roadmap
The project roadmap defines future operational phases. The next development steps involve adding a barcode scanner integration for mobile browser checkouts, configuring MinIO bucket file uploads for invoice storage, and establishing email alerts for low-stock warnings.
07 — Key Takeaways
Key Takeaways
a. Architecting Scalable Supply Chain Tech
Logistics software demands strict relational integrity. Designing automated checks like dynamic reflection-based delete validation protects databases from orphan records, preventing transaction mismatches as the team adds new modules.
b. Building Robust Data Foundations
Building reusable base resources and audit logging systems early in the development cycle is essential. By establishing standardized model classes, permissions, and audit logs, our developers can add new inventory features without rewriting core infrastructure.