The order system splits the customer experience from the kitchen workflow across two separate points, persists every paid order so nothing is lost to a restart, and gives staff a live ticket widget so they can work orders from anywhere in the venue.
Two-vector order counters
Orders flow through two distinct points you place in the setup tool:
| Point | Who uses it | What happens |
|---|
| Order counter | Customers | Place and pay for an order. Has a configurable handover distance for collecting the finished order. |
| Queue terminal | Employees | View the pending order queue, mark orders ready, and hand them over. |
The order lifecycle
- A customer places an order at the order counter and pays (cash or bank).
- The order is inserted into the queue with status
pending.
- An employee prepares the items at the assigned stations, then marks the order ready at the queue terminal (status flips to
ready).
- The employee hands the order over at the counter within the handover distance. The order row is then deleted.
A customer’s stable identity is their character id, so their order is tied to them even across sessions; their current session source is re-resolved at handover time.
Persisted orders
Customer orders are written to the nex_businesses_orders table the moment a customer pays. This means a paid order survives resource restarts and ensure cycles — the in-memory queue used to be wiped on every restart, leaving customers with no way to recover what they paid for. With persistence, money is never lost to a reboot, and employees can complete pending orders after the server comes back up.
An order row is inserted on payment, updated to ready when an employee marks it ready, and deleted on handover or cancel.
Society auto-deposit
Payments deposit directly into the business’s society account through whichever banking backend you configured in Config.Society. The offline shop applies the same atomic stock-and-money handling with society auto-deposit. See Configuration for the banking options.
The order ticket widget is a docked panel on the left edge of the screen — a live, in-restaurant dispatch view for staff. It subscribes to the same order broadcasts as the in-store queue terminal, so it stays in sync automatically.
The widget applies only when the player is standing in the business and clocked into its job. Leaving the zone hides the panel and tears down the local mirror; re-entering rebuilds it.
Tickets color-ramp by age, so the longer an order sits unfulfilled, the more it stands out — stale tickets are easy to spot at a glance.
Keybinds
All keybinds are rebindable from FiveM’s keymap menu under the nex_businesses resource, and their defaults come from Config.UI.dispatch in cfg.lua.
| Default | Action |
|---|
U | Toggle the ticket widget visible/hidden. |
I | Same — alternate toggle key. |
← | Previous ticket. |
→ | Next ticket. |
Config.UI.dispatch.autoShowOnNewOrder = true). Set that to false to require staff to open it manually with U / I. Set Config.UI.dispatch.enabled = false to disable the widget entirely.
