Orders and service states

RestaurantOrder is the center of Openfront Restaurant. Storefront checkout, POS, service floor, KDS, payments, reporting, and inventory all read or write it.

Order statuses

open
sent_to_kitchen
in_progress
ready
dispatched (delivery only)
served
completed
cancelled

Allowed moves are checked on the server:

From	To
`open`	`sent_to_kitchen`
`sent_to_kitchen`	`in_progress`
`in_progress`	`ready`
`ready`	`served`, or `dispatched` for delivery
`dispatched`	`served` or back to `ready` (delivery only)
`served`	`completed`

Moving a delivery order to dispatched or served needs a courier handoff or delivery reference. Moving to served or completed needs the kitchen work done. Moving to completed needs full payment with no uncertain tenders. Cancelling goes through voidOrder with manager approval.

Order types are dine_in, takeout, and delivery. Order sources are pos, online, kiosk, and phone. The app itself only creates pos and online orders.

What an order holds

order number, type, source, and status
tables for dine-in, guest count, server, and creator
special instructions, urgency, and hold state with a reason
customer link, name, email, phone, and delivery address fields
subtotal, tax, tip, discount, total, and currency code
secretKey for guest orders
table seated and freed times and course completion percentage
courses, order items, payments, discounts, and gift cards

Each OrderItem keeps snapshots of the item name, thumbnail, menu item ID, kitchen station, modifiers, and price. Later menu edits do not change past orders. Items also carry course and seat numbers, kitchen status, and void details.

How orders move through service

The order is created

Orders come from storefront checkout (completeActiveCart), the POS (createPOSOrder), or the service floor (addServiceFloorItem).

Kitchen work begins

Orders in sent_to_kitchen, in_progress, or ready get kitchen tickets per station.

The kitchen and floor update it

KDS ticket updates and transitionRestaurantOrder move the order through in_progress, ready, and served. When an order moves to served or dispatched, any ready tickets are marked served.

Payment closes the order

When the check is paid and served, it moves to completed.

Follow-up work runs

On completed or cancelled, the app syncs kitchen tickets, depletes recipe ingredients, and releases tables. Each step is logged. A failed step is logged as needing recovery and shows on the Ingredients page under operations recovery (restaurantOperationsRecovery, retryRestaurantOperations).

Order screens

/dashboard/platform/orders lists orders. Views: Kitchen (open, sent to kitchen, in progress, ready), Expedite (ready, dispatched, served), and Cashier (served, completed). It also has status tabs and a source filter (all, online, in-store).
/dashboard/platform/orders/[id] shows order detail, including split-check allocation when the order is part of an equal split.
/dashboard/platform/orders/[id]/fulfill is the "Service Management" page. It steps the order to its next status with TransitionRestaurantOrder.

Example query

query KitchenOrders {
  restaurantOrders(
    where: { status: { in: ["open", "sent_to_kitchen", "in_progress", "ready"] } }
    orderBy: { createdAt: desc }
  ) {
    id
    orderNumber
    status
    orderType
    isUrgent
    tables {
      tableNumber
    }
  }
}

Audit trail

Status changes, POS creation, checkout completion, voids, and many other actions write AuditEvent rows with the actor, before and after values, and a reason. Voids, comps, splits, and corrections also write OrderAdjustment rows.

When debugging, start with the order record and its audit events. They tie together guest ordering, staff service, kitchen work, and payment.

Orders and service states

On this page