Web/Backend/2026

Multi-Store Fast Food Inventory Management

A mobile-first inventory system for a multi-location fried-chicken chain with FIFO costing, purchase orders, and auto-suggested reordering.

inventory-hero.png — 1600×900

Overview

Inventory is a full-stack inventory management system for a multi-store fried-chicken restaurant chain, covering items, vendors, purchase orders, receiving, FIFO issuing, adjustments, quick counts, and cross-store reporting. Each store can have multiple storages (e.g. dry storage, freezer), and every quantity change flows through an immutable transaction ledger rather than a stored stock column.

It's built mobile-first for handheld use on the floor: a bottom tab bar on small screens, large touch targets, decimal-friendly numeric inputs, and searchable bottom-sheet pickers, alongside a full desktop layout. The app supports English, Spanish, and Vietnamese via next-intl, with a store selector persisted in a cookie that scopes every business flow.

The problem

Small restaurant chains often track inventory in spreadsheets, which can't answer basic questions like true cost of goods sold, which store is wasting the most product, or when to reorder before running out — this system replaces that with a ledger-based inventory model that derives on-hand stock and COGS from FIFO cost layers, and turns purchasing into a guided, auto-suggested workflow instead of manual guesswork.

Architecture

A single Next.js App Router codebase serves both the UI and its own API routes, backed by SQLite through Prisma. Stock is never stored directly — it's always SUM(CostLayer.qtyRemaining) for an (item, storage) pair, computed at read time. Every RECEIVE, ISSUE, or ADJUST operation writes an immutable InventoryTransaction plus CostLayer/LayerConsumption rows inside a single DB transaction, so FIFO issuing consumes cost layers oldest-first, scoped per storage so stores never draw down each other's stock. Pure business logic (FIFO consumption, vendor price resolution with its MANUAL/RECEIVE fallback chain, and the suggested-order formula) lives in framework-free src/lib modules covered by Vitest unit tests that run without a database.

architecture-diagramUI/API routes → Prisma/SQLite → immutable transaction ledger → derived stock & FIFO cost layers

Highlights

  • FIFO costing with per-storage isolation Issues and outbound adjustments consume cost layers oldest-received-first, split independently per item/storage so multi-store stock and COGS never cross-contaminate.
  • Self-maintaining price resolution Every receiving transaction snapshots a vendor price automatically, so 'current price' falls back through manual effective-dated prices, last vendor receive, then last receive from any vendor, without manual upkeep.
  • Auto-suggested purchase orders A weekly/monthly reorder screen computes suggested quantities from 28-day usage trends plus min-stock buffers, then splits the confirmed order into draft POs per vendor automatically.
  • Mobile-first operational flows Receiving, issuing, adjusting, and quick-count screens are built for handheld use on the floor, with sticky submit buttons, bottom-sheet pickers, and state retained across repeated line-item entry.

Screenshots

dashboard-overview.pngitem-detail-cost-layers.pngpurchase-order-suggest.pngquick-count-mobile.png
Next project
Nepomuk
All projects