Use a global Restaurant administrator or active Owner, Manager or Employee for order operations. The restaurant must have valid customer locations and a published product offered for sale. Use the order verification route to check its setup before handling real orders.
Handle orders in Business > Orders. Check payment and the saved order contents before accepting the order.
1. Find the order#
Open Orders, select Active or History, and use the status/date filters when needed. Select the row/details action to load its full order details. The list is paginated; use the footer rather than assuming every order is on the first page.
Orders list and details showing Awaiting acceptance, saved product lines, payment held and Accept/Reject actions.
Business reads are on demand. Opening a view, changing a filter/page, pressing Refresh or completing an action loads the relevant data. An idle open list does not continuously refresh.
New actionable paid orders notify currently connected active staff1, including with the panel closed. They use the configured notification/sound provider2. The alert is not an offline backlog and does not grant unrelated administrators staff membership.
2. Accept or reject before preparation#
For a confirmed paid pending order, choose Accept order to accept the saved contents and prices. Acceptance settles the held customer funds into recognized restaurant revenue. An uncertain payment cannot be accepted as if it were confirmed.
Choose Reject order when the eligible pending order cannot be fulfilled. Its refund returns through the durable original-account path. A visible rejection is not proof the customer has already received the credit; inspect the payment/refund state.
Before acceptance, also consider whether you have the staff, ingredients and finished stock required. Checkout itself does not require finished stock.
3. Start preparing explicitly#
After accepting, use Start preparing when the kitchen begins the work. This status is an operational action; it does not automatically execute recipes or create products.
Staff still run the normal kitchen workflows, collect finished products and deposit them through Packaging Point > Storage. Raw materials and half-finished preparations cannot satisfy an order.
4. Prepare the exact stored contents#
Use Prepare order and select matching stored finished products, existing eligible delivery bags, or a combination. Quantities must match every saved order line exactly. The server automatically packs selected loose products and reserves the resulting bags for this order.
For example, an order for one Pizza and one Fries needs those exact logical contents. A bag containing an extra Soup is not an exact substitute. A partly consumed product is not a fresh full serving.
Prepared bags remain reserved in Restaurant Storage until pickup or staff collection. Packaging and Assignment explains the selection rules.
5. Approve readiness#
After complete preparation, use Approve for pickup. Packed and Ready are separate states. Changing/removing the allocation retires the old readiness approval; recheck contents and approve again when required.
Reserved bags cannot be withdrawn as general stock, opened mid-fulfillment or assigned to another order. To deliver, choose customer pickup or Collect for hand delivery and follow Delivery.
If an action is unavailable#
Check your role, the selected restaurant, payment, order status and the location of its bags. Refresh the order before repeating an unavailable action. Managers and employees can handle orders without gaining pricing or banking access.
For a failed or uncertain money/item operation, preserve the reference and use Recovery. Do not mark delivered to hide a failed inventory transfer.
Order state, payment and bags#
Use this table with the selected order's payment details. The visible order state is not proof of a completed external transfer.
| Order state | Payment / revenue | Stock and delivery meaning |
|---|---|---|
| Awaiting acceptance | Confirmed payment is held for the customer; an uncertain payment still needs review | No cooking or finished-stock reservation occurs at checkout |
| Accepted | Confirmed acceptance recognizes the saved sale and moves held funds into Restaurant funds | Staff have accepted the obligation; products still need preparation |
| Preparing | No second charge or extra sale is created | Staff explicitly began preparation; this button does not run recipes |
| Packed | Payment remains the accepted sale | Exact finished products/bags are allocated and reserved for this order; customer pickup still needs Ready approval |
| Ready for pickup | No additional payment | Readiness was approved for the current allocation; the original customer can collect at the menu point with enough inventory space |
| Staff hand delivery pending | No additional payment | Staff collected the actual assigned bags and retain custody until handover or return; partial return does not create a second full set |
| Delivered | No extra payment or product grant from handover acknowledgements | Customer pickup completed, or staff/customer acknowledged the actual hand delivery |
| Rejected / Cancelled | Check the separate refund state; a queued refund is not necessarily already credited | Pending order ended before acceptance; do not prepare it as an accepted sale |
| Failed | Read payment details; do not infer no charge solely from the status | No normal preparation is in progress; an uncertain external result requires review |
Changing the allocation invalidates its previous readiness approval. Delivery owns pickup, handover and returning all or part of the bags. Refunds owns pre-acceptance cancellation, rejection and expiry. For an unresolved external result, use Business Recovery.
Footnotes
-
A character with an active entry in the restaurant's staff list. Read the definition. ↩
-
An installed framework, inventory or interaction system used by Restaurant. Read the definition. ↩