01 / PROJECT

ORDER OPERATIONS SYSTEM

One order, multiple fulfillment paths.

SYSTEMFull Stack Engineer2026
ORDER OPERATIONS SYSTEM - cover visual
PROJECT ARTIFACTPRIMARY VISUAL

An order-centric operations platform connecting sales, purchasing, warehouse, inventory, and finance around a single operational lifecycle.

02 / THE CHALLENGE

Orders were simple on paper.
Fulfillment was fragmented.

In multi-department operations, a single customer order rarely follows a simple linear path. Some items are already on warehouse shelves, while others must be requested from external suppliers with different lead times. When sales, purchasing, warehouse, inventory, and finance rely on fragmented communication, orders lose tracking. Stock gets double-promised, goods arrive at the dock without clear assignment, and deliveries leave before credit terms are verified. The system needed to model these divergent paths explicitly while keeping inventory and financial approvals strictly synchronized.

KEY FAILURE MODES ADDRESSED
01

A single customer order contains items available in warehouse inventory alongside items requiring third-party procurement.

02

Without transactional state synchrony, stock gets double-promised and shipments leave before credit and physical verification.

03

Fragmented departmental handoffs obscure accountability between purchasing lead times and customer delivery promises.

03 / SYSTEM FLOW & DECISIONS

One order. Multiple fulfillment paths.

Explore how the system splits each line item into independent operational branches while enforcing strict transactional convergence before dispatch.

Direct Stock Path

Immediate inventory reservation bypassing procurement chains entirely.

In-Stock Items
STEP 01Sales

Sales Order Confirmed

Line item confirmed & live stock reservation triggered

STEP 02Warehouse

Atomic Stock Hold

Row-level hold in database transaction locks allocated quantity

STEP 03Warehouse & Finance

Dual-Gate Sign-off

Physical readiness check + financial credit terms verified

STEP 04Delivery

Delivery Order Released

Official dispatch notice created and warehouse balance debited

KEY ARCHITECTURAL DECISIONS & TRADE-OFFS
01

PER-ITEM FULFILLMENT SPLIT

Evaluates each line item within a Sales Order independently, routing in-stock items to reservation and backordered items to procurement.

RATIONALE

Customer orders frequently contain both immediately available goods and items requiring vendor procurement. Forcing an entire order into a single fulfillment track creates unnecessary customer delays.

02

DIRECT GOODS RECEIPT TO INVENTORY

Increments inventory availability directly upon physical warehouse Goods Receipt confirmation.

RATIONALE

Separates physical receiving from vendor invoicing schedules, ensuring warehouse inventory reflects actual floor availability without administrative delay.

03

DUAL-ROLE DISPATCH APPROVAL

Requires sequential authorizations from Warehouse (physical inspection) and Finance (credit and payment standing) before generating a Delivery Order.

RATIONALE

Prevents goods from leaving the loading dock before both physical readiness is verified and customer credit terms are validated.

04

TRANSACTIONAL ROLE BOUNDARIES

Enforces all cross-department handoffs through database transactions and role-based permissions spanning nine operational roles.

RATIONALE

Prevents race conditions during simultaneous stock reservations and maintains an auditable chain of custody across departmental transitions.

04 / ARCHITECTURE & STACK

Engineered for relational integrity.

The platform is built on PostgreSQL and Prisma with relational constraints enforcing state integrity across all operational tables. Business logic and status changes are wrapped in database transactions to prevent race conditions during concurrent stock reservations. A role-based access control layer with nine distinct roles restricts actions to authorized personnel across Sales, Purchasing, Warehouse, Finance, and Administration. Input validation is centralized with Zod schemas on both client and server, while file attachments such as physical goods receipts and delivery notes are stored in MinIO object storage.

ARCHITECTURE TIERS
01|

CLIENT LAYER

  • Next.js App Router
  • React 19
  • TanStack Query
  • Zod Schema Validation
  • Tailwind CSS
02|

BUSINESS & DOMAIN

  • Server Actions
  • Transactional State Machine
  • Role-Based Access Control (9 Roles)
  • Audit Trail Engine
03|

DATA & INFRASTRUCTURE

  • PostgreSQL
  • Prisma ORM
  • MinIO Object Storage
  • Database Transactions
CORE PRODUCTION STACK
TypeScriptNext.jsPostgreSQLPrismaNextAuthZodTanStack QueryMinIOTailwind CSS
OPERATIONAL OUTCOME & RESULT

The system establishes a single, deterministic operational backbone across five departments. Sales teams track fulfillment status per line item, warehouse staff verify inventory against physical goods receipts rather than manual logs, and deliveries require verified sign-offs from both operations and finance before dispatch. By replacing fragmented manual coordination with an explicit state machine, the platform enforces accountability and consistency across the entire order lifecycle.

✓Per-item state machine supporting independent reservation and procurement paths per order line.
✓Direct Goods Receipt to inventory ingestion keeping stock availability synchronized with physical receiving.
✓Role-gated dual approval requiring both Warehouse and Finance authorization prior to dispatch.
✓Transactional state handling and role-based access control spanning nine operational roles.
NEXT WORK

More systems worth exploring.

Explore another project where software, business processes, and practical engineering meet.

BACK TO WORKS