Inventory & Sales Management

Problem

Stock and sales tracked separately can't answer the questions that actually decide a day's work: what is at or below its reorder point, which sales are still unpaid, and what the inventory on hand is currently worth. Each answer lives in a different place, so none of them is current at the same time.

Approach

Selling, buying and counting stock are one application over a single catalogue rather than separate tools: a sale through point of sale, a purchase order to a supplier and a stock adjustment all move the same product record. The dashboard is built around the questions above — reorder points, unpaid and partly paid balances, and inventory value are surfaced as standing figures rather than reports someone has to go and run.

Visual Showcase

Technical Architecture

• One product record is shared by point of sale, catalogue, inventory and purchasing, so selling and restocking move the same stock rather than two counts that have to be reconciled.
• Reorder points are per-product, which is what turns "low stock" into a computed state (on-hand against reorder point) rather than a judgement call — and separates it from "out of stock", which blocks selling entirely.
• Payment state is a property of a sale rather than a separate ledger: partly paid is a first-class state alongside paid, which is what lets one outstanding figure cover both.
• Inventory is valued two ways at once — at cost and at retail — because the two answer different questions (what is tied up, versus what it should realise).
• Suppliers and purchase orders sit on the same customer/trade model as sales, so an open purchase order is visible next to the stock it will replenish.
• Administration is its own surface (users, settings, activity log) — accounts are administrator-issued, and the activity log is what makes stock changes attributable after the fact.