One model, several sizes.
Products carry a SKU, size, price and stock count. The sales form looks up the chosen product and size, then checks the requested quantity together with the quantity already in the cart.
Archived desktop screenshots from the course report. Simulated data, not actual sales or a live application session.
A sale is only part of the system.
A shoe store needs to know more than what sold: which size is available, where stock came from, and what happens when an item is returned. POS Z Shoes brings those operations into a C# WinForms application.
The decisions behind it.
Check the size, not just the shoe.
The same shoe can have different availability in each size. The cart checks stock against the selected SKU and includes items already added, so a repeated selection cannot bypass that form-level check.
Separate a refund from an exchange.
The customer-return form changes with the selected resolution: refund amount for Refund, replacement product and size for Exchange. Both start from an original transaction item and a reason for return.
Give each role a relevant workspace.
Owner, Admin and Staff have separate dashboard and navigation paths in the source. That is a course-level workflow distinction, not a claim of independently audited access control.
From business flow to desktop build.
I built the application independently; classmates helped prepare the sample data. The build connects product management, supplier purchases, customer sales, returns, dashboards and reports, beyond a collection of CRUD screens.
- C#
- WinForms
This is an academic Windows desktop build, not a hosted web demo or a claim of commercial deployment. The archived screens still contain placeholder product photos. This portfolio pass reviews the source and report; it does not rerun the POS database, validate sales figures, or certify production readiness.