Order types and fulfillment

Admin → Settings → Orders / POS → order entry. Tableless dine-in, whole-check method selection and optional customer prompts require compatible POS and API versions. Their Admin configuration also requires a compatible Admin version; an API update does not update either client.

Collect cash for a POS order type

Dine-in and counter pickup orders can be collected in cash only on an enrolled POS with an open cash drawer session. Open More → Reports → Cash drawer balance before taking the first cash payment, then settle the intended order or financial bill. A delivery or online pay-later order is not a recorded cash sale merely because cash is its intended tender; record only cash actually received. Card terminal deposits remain separate.

Review the by-weight authorization ceiling

For online by-weight orders, open Settings → Payments & VAT with settings.edit. Set Weight hold buffer % from 0 to 100 and save; the default for new restaurants is 20. A failed save keeps the draft. Zero still authorizes the estimate. Only the weight-priced subtotal gets a margin: 100 weighted + 50 fixed at 20% authorizes 170; delivery has no extra margin. Checkout shows the estimate, temporary ceiling and Confirm and authorize, in the restaurant theme. A changed ceiling requires customer review and another confirmation before payment; unknown policy blocks authorization. Existing reviewed checkouts and holds keep their ceiling. Staff confirm measured weights before capture and progression; excess beyond the hold is flagged for a separate payment, never automatically charged. Cash/pay-later makes no hold promise. Requires a configured authorize/capture provider, with partial capture, release and expiry validated before production. This neither changes the catering deposit/balance policy nor enables new-card saving with a CST weighted hold.

Dine-in and tables

Dine-in describes onsite consumption, not a required table number. On the POS, a new sale can use an eligible table or a named check without a table, when supported and open checks are enabled. A physical table keeps its own service session, covers and seats; a check without a table does not create them. Guest QR ordering retains its table/session requirements.

Pickup

Enable pickup in the restaurant settings, then check the offered date/time and preparation delay. The customer collects at the configured location.

Delivery

Require a usable delivery address and check zone, fee and fulfillment window. A delivery day can be saved before its final time window is confirmed.

Scheduled and batch orders

Review ordering windows, cutoff and fulfillment dates. With a batch calendar, use the restaurant-defined cycle instead of inventing a free date. Scheduled orders require a date, including today; the label does not mean future dates only. Restaurant service/preparation rules remain common. Each delivery zone separately defines advance-order and same-day time choice. Staff may test the saved basket, address and receiving date in Orders & availability → Simulate an order without creating a new order.

Authorized staff can explicitly accept a scheduled order before its slot. The restaurant workflow retains its stages; the date and slot stay unchanged. See the acceptance procedure.

Choose a stage attachment

In Admin, open Settings → Restaurant → Order workflow and the required pickup or delivery stage. With Notify customer enabled, choose the message type, an approved Meta photo/PDF model and its attachment: a fixed file, or that order’s receipt for a PDF. Choose the sending time and save the workflow. Manual stage entry or its configured event uses this binding. Selecting a file changes neither progression, payment rules nor delivery eligibility. Correct an incompatible or missing model/file before relying on delivery. The model library and creation controls are in Settings → Communications → WhatsApp.

Follow an assigned delivery’s departure

When the assigned courier starts their route in Admin, unfinished accepted, preparing and ready delivery orders change together to Out for delivery. Staff screens receive the updated statuses through their usual order refresh. This confirms actual departure; assigning a courier or choosing a fulfillment mode alone does not start a route. Held kitchen courses and unsettled weight orders must be resolved first. If starting fails, the previous statuses remain. The route action does not reopen finished or cancelled orders.

Make a one-order combo exception

For a one-order combo exception, an authorized Admin user opens the combo step and selects Choose another item. The replacement is included without a surcharge and is saved on that order only. Fulfillment, scheduling and delivery rules remain unchanged. Review the selected dish and portion in the order details. Guest and POS combo pickers retain the configured composition; arrange an exception through the internal Admin order editor. See the combo guide for quantities, eligibility and recovery.

Wait for counter card payment before kitchen preparation

For a new counter pickup order paid by card, choose Pay, then Pay by card. Wait for terminal approval and for Foody to record the payment before preparation and the kitchen ticket start. During collection the payment remains pending and is excluded from the live order board. After a refusal or cancellation, keep the same checkout and retry there; do not send it to the kitchen to bypass payment. If approval succeeded but synchronization failed, reconcile the existing payment before starting another charge. Orders deliberately sent for table service before collection keep their existing send-then-pay flow.

Use the original series stock pool

Predefined item stocks now have a journal under Items & menus → Stock history and on each product. A rotating carte can prepare initial allowances per series and publish them without restoring already committed units. Previous remaining counts are not carried forward. Order changes and pre-production releases use the original frozen pool; a produced item remains consumed. Ingredient/preparation quantities and recipe costs remain separate. See Availability for initial imports, corrections and history filters.

Staff contact details and courier destination

Staff contact details are managed in Admin → Staff → employee → Edit contact details. The restaurant-scoped name and phone are used for courier assignment and upcoming delivery reminders; the sign-in email remains read-only. Couriers can save a default final destination or link it to their home address. New routes propose that destination and allow an explicit override or removal. It is the courier’s end-of-route destination, separate from the customer’s delivery address. Existing populated routes and completed delivery snapshots keep their saved data. See staff profiles for saving, permissions and recovery.

Recover a delivery after a test departure

Starting courier mode marks assigned orders Out for delivery. If this was a test departure, a user with order-management permission can open Orders → Deliveries, select the date and choose Undo departure while no arrival, delivery or skipped stop has been recorded. Out for delivery orders return to In preparation; the route returns to draft and can be unassigned and reallocated. This is a delivery correction, not a new order, refund or reprint. Payments and previously sent messages are preserved. See the dispatch procedure.

Check conditional item choices

An item configured with repeated positions requires one separate choice per position according to the selected format. For example, a two-character Number Cake accepts 11, AB or A7. The format price replaces the base price; modifiers add only their configured surcharges. Reducing the position count removes newly hidden choices. Positions remain distinct in the cart, orders and kitchen ticket; review them before confirming. These customizations do not change delivery, availability, recipe, discount or cancellation rules. Configuration requires compatible versions and menu editing permission. See Variants and sizes for setup and recovery after a rejected selection.

Open a dine-in check without a table

Requires compatible API/POS versions, orders.manage and open checks enabled for this POS mode. Select Dine-In for a new unassigned sale; this does not yet open a table or check. Complete any customer prompt and enter the items. At Send/Continue, choose Save check → New check → Custom check once: the name form opens directly, including when predefined names are enabled without a configured group. Enter the name, then Save. Back returns to destination selection without creating a check and preserves the source basket. The explicit Send then continues once with the fresh lines. A destination change during Pay does not automatically collect money: review and initiate payment explicitly. Cancel preserves the source basket. To create an empty check first on a compatible iPad, open Orders → Checks, then +; Menu → Actions → Open tickets leads to this same view. Phones/compact handhelds keep Actions → Open tickets → New ticket. The preselected service type follows the current sale’s still-valid method, otherwise the restaurant’s enabled default; it is not forced to Takeaway. Review it and select Dine-In for this sale where offered. Then choose a group/name or Custom check. Configured groups and available names are retained: choosing a name creates the check, while a custom name needs Save. Without confirmed settings, an eligible method or loaded group, wait or retry; do not create another check to bypass the block. This is real onsite consumption, not renamed pickup. Further sends keep one bill and create separate kitchen batches. Payment, preparation and closing remain separate; close only with no unsent items or unpaid live batches. Saved orders remain in Orders on POS and Admin. No artificial table/session, covers or numbered seats are created. Financial splitting or moving this named check to a table is not supported here. An uncertain creation keeps its request identity: Retry the same request instead of creating another check.

Choose the method for the whole POS check

For an unsent sale, open Actions → Fulfillment methods in the check, tap the intended row in Select fulfillment for this order. The current method is highlighted with a green Selected badge. Tapping a row continues immediately, without a separate Save button; closing before choosing leaves the sale unchanged. This is the check's overall method, not a choice for the selected item. Choices come from the restaurant's POS fulfillment settings. Items without an explicit choice follow the check; items with their own preparation choice keep it. Once the check is sent, its recorded overall method is retained. A table check remains attached to its table/session and a named check retains its dine-in, pickup or delivery type; the method selector is not a table-transfer, check-merge or financial-split tool. If the method requests customer information, confirm the optional name/phone form too; cancelling it cancels the staged mode choice. The Client tab shows the recorded contact. See customer information. For a new onsite sale, choose the method and any customer details before adding items; the table/check is requested only at Send/Continue. Save check provides search, sorting and sections. Choose an existing unpaid onsite check with no other unsent lines, or New check → section → free table. Required covers are requested only after that table choice. New check → Custom check or a configured group/name creates a named onsite check without a physical table, requiring open checks enabled and the matching API. A retry retains one creation identity; an uncertain response freezes that request. Cancellation keeps the source basket. An existing destination retains its customer, discounts and saved lines; only fresh lines become the next kitchen batch. Paid, pending-payment, allocated, uncertain-total or conflicting-customer checks are rejected without moving the source. Explicitly remove a source check-level discount before changing destination. A changed destination during Pay does not automatically charge: review it and initiate payment explicitly. For a sale already attached to a table without financial splitting, the normal flow uses its sole allowed method directly instead of showing a one-row choice. If that method requests customer information, its form still appears and must be completed or skipped; cancellation retains the draft. This simplification does not apply to counter sales, named or financial checks, or when multiple methods are available. Explicitly opening Actions → Fulfillment methods keeps the selector, even with one option.

Start an onsite sale without a method prompt

On compatible API/POS versions, turn off the staff fulfillment prompt and keep the intended onsite method first among the enabled methods in Admin. Start a new sale in Menu: that enabled default applies without selecting Takeaway merely because no table has been chosen yet. If customer details are configured for the method, its optional form still applies. With courses enabled, the first configured named course receives ordinary new items; items from the configured immediate-send library categories use Straight fire. An explicit later course choice remains selected. Add the items, then tap Send, or Continue when the mode offers it. Save check asks for the real destination: select an eligible existing onsite check, or New check → section → free table. Open checks enabled also permits a supported named check without a table; disabling that module does not disable sending an onsite sale to a physical table. Cancelling the destination preserves the draft and sends nothing. Saved checks retain their recorded method, and restoring a draft does not replace an explicit method choice with a newly changed default. A new-sale reset clears only that sale’s provisional course/hold/fire choices, not another open check. Review the destination before any payment; choosing it does not collect automatically.

Give one item a different preparation instruction

In the item sheet's Options → Fulfillment methods, choose an enabled method and confirm the item with Done. For example, an item marked takeaway in a dine-in check indicates how that item should be prepared or packed; it does not move the check away from its table. Selecting Delivery on one line does not create another delivery, recipient, address, charge or courier task. Use a separate Delivery order when goods must actually go to another destination. Staff POS customer name/phone remain optional; this form does not require a street/city address. Guest online ordering retains its own delivery validation. The available methods are restaurant-wide; there is no separate matrix of allowed item choices for each parent service. These choices do not change printer assignments or category rules: verify printer routing separately.

Change an unassigned draft's service safely

An unpaid, wholly unsent anonymous draft can change pickup/delivery lifecycle or be assigned to an eligible onsite destination at Send/Continue. Empty destinations keep their own table/session identity. A saved, unpaid, unsplit onsite check can accept fresh lines only if it has no other unsent work, confirmed totals and a compatible guest snapshot; its saved lines, customer and discount policy remain unchanged. No paid/pending, allocated, uncertain or conflicting destination is overwritten. A source check-level discount must be removed explicitly before moving to a table/named check; do not silently discard or transfer that policy. On cancellation or a changed restaurant, permission, configuration, source or target, keep the source and review the error instead of recreating or paying for the same food twice. Source consumption occurs only after the destination local draft is confirmed. The explicit Send continues once after a successful choice; changing destination in Pay requires another explicit payment initiation. Table services with financial allocations are not silently converted by this flow.

Keep private guest context on the check

In the customer screen offered after fulfillment selection, first name, last name, guest identifier and note describe the whole check, not an item or a separate delivery. These details remain staff-only and are retained across successive sends on that check. They do not create a customer account and are not included in public tracking/payment responses or notification variables. Private fields require a compatible API version; if the POS requests an update, retain the check and have the server updated before continuing, without repeating a payment.

Control weekly ordering manually

Weekly batch restaurants can choose Manual opening under Settings → Ordering & delivery → Orders & availability, with settings.edit. Save, then explicitly open or pause online orders using the pause control. Automatic opening/cutoff times do not control intake in this mode. Delivery days/windows, the restaurant timezone, preparation and stock rules remain in effect; existing orders are untouched. The website stays browsable during a pause. Active temporary test access must be disabled before reopening publicly. See the fulfillment settings guide for the complete procedure.

Check operational progress for each order type

For dine-in, pickup or delivery, review preparation and the actual recorded service, pickup or delivery separately from payment. A prepaid order can still be held or in preparation. Do not confirm handoff to settle a payment. QR customers at one table retain separate orders and payments. See the four order axes.

Prepared Sumit checkout integration

With compatible Sumit internal checkout, staff choose pickup or delivery and the service date before creating the private basket link. The recipient completes contacts; delivery checks the address, fee, minimum and date before payment. See Sumit prepared orders.

Review independent confirmations

In a saved order’s actions, review preparation and handoff separately from payment. Handoff review selects the actual physical units; financial splitting does not multiply them. Before closure, review the exact check or financial portion and its confirmed balance. A closed scope refuses new commercial changes; another open batch is not closed by that action. See tracking and confirmations.

Test when an order is placed

In Orders & availability → Simulate an order, select Order date and time in the displayed timezone, then the receiving date and basket. Now reloads the server time. Preparation and same-day rules are evaluated at this reference using current saved settings and ready stock. A past date does not reconstruct history; this test neither reserves a courier nor creates an order. Customer orders retain the real server clock. See the simulation procedure.

Respect a pending card collection

An unresolved native card collection keeps its original order and terminal reserved. Do not change its financial contents or start another tender; kitchen progression and fulfillment settings remain independent. See Mini/Portable selection and recovery.