Inventory management system Java project

The key facts

• The build order: domain classes → JDBC persistence → derived stock and reports → a thin console UI → (only then) a web layer.
• The classes: Product, Location, StockMovement (immutable, signed), Inventory (deriving on-hand), Order, PurchaseOrder — mirroring the real schema.
• The Java details that matter: BigDecimal for quantities and money, transactions around every invariant, immutable movements with no setters.
• What earns the marks: a stock figure derived from a movement history with an audit trail — not a CRUD form over a numbers table.
• Where it fits: this page is one branch of the inventory management guide.

The project, in build order

Domain classes first. Product and ProductVariant, Location, StockMovement (variant, location, signed quantity, timestamp, actor, reason — immutable, no setters), Order and OrderLine, PurchaseOrder. The discipline that separates a good project from a CRUD form: there is no quantityOnHand field on Product. On-hand is a method or query that sums movements — the schema the classes mirror explains why in full.

Persistence with JDBC. Plain JDBC over SQLite or Postgres teaches more than an ORM at this stage: real transactions around allocate-and-reserve and cancel-and-release, SELECT ... FOR UPDATE for the last-unit race, and BigDecimal with explicit scale for quantities and money — never double.

Derived stock and reports. A report class that produces on-hand by product and location, low-stock against reorder levels, and a movement history for any product. These three reports are the project's value; every one of them reads the movements.

A console UI last. A menu for receive, sell, adjust, count, report — validating at entry and refusing what the invariants refuse. A web layer is a fine extension, but a UI built before the record is true is decoration over an untrustworthy core.

The scenarios that earn the grade

Examiners and reviewers probe the same edge cases the real world does, so design for them deliberately. The oversell attempt: two concurrent sales of the last unit resolve to one sale and one clean rejection — serialised in the database, not hoped away in code. The correction: a wrong receipt is fixed by a new movement referencing the old, never by an edit — the audit trail survives. The stocktake: a count produces correction movements with reasons; the derived figure shifts and the history shows why. The backorder: a sale against zero stock creates a reserved line that feeds a purchase order — demand visible in the record, not in a sticky note.

A project that demonstrates these four paths is demonstrating the domain, which is the actual subject. The project-structure guide organises the write-up, and the worked example shows the behaviour the code should reproduce.

After the project: the honest next step

The project's deepest lesson arrives at the end: the code was the easy half, and the permanent tail — hosting, patches, multi-user discipline, every future requirement — is the cost of owning a record. That is the moment to know the alternative exists: maintained systems keep the same model alive as a product. We build BSimple, so weigh that — movements, reservations, deliberate invoice approval, per-customer pricing as cloud software from $180/month AUD, with a public REST API so your Java code can become a client of a maintained record rather than its owner. The trial is the full product, and it doubles as the reference implementation your project was reaching for.