Seats, courses, hold and fire
Open the active table bill. Course availability depends on the restaurant’s POS profile and deployed API capabilities.
Availability and access
Advanced actions appear only when the installed POS and API advertise the required capability and your role permits them. Refresh a changed bill before retrying; never create another charge to resolve an uncertain result.
Keep kitchen release separate from cash collection
Holding or firing a course changes kitchen timing, not payment status. A table may be served before collection; do not count it as cash until the money is received and confirmed on an enrolled POS with an open drawer session. A pending cash payment must be resolved before closing the drawer. The card terminal deposit is a separate end-of-day action.
Assign seats and courses
Before sending, assign items to Table or selected guests and choose their course. Check course order and required item options. Financial seat allocation can later change without rewriting already-sent kitchen seating. Course management must be enabled in the device’s assigned shared mode; there is no independent iPad override. With a newly selected onsite method, the first course starts the empty draft; an explicit Immediate send choice is not reset by confirming the same method or refreshing settings. Items whose internal library category is configured for immediate sending enter Immediate send; menu display groups do not define this routing. Send is still required: adding an item never fires or prints it automatically. Refresh retains selected courses and holds that remain valid. Disabling course management stops assigning courses to new items; saved kitchen history is not rewritten. After a confirmed reset, the next check gets its own initial course and does not inherit holds or pending fires from the previous check.
With compatible API and POS versions, editing a saved item’s places follows the same device-assigned mode as the initial send. Optional seats permits Table; Required seats requires a numbered place when covers are defined. Check the assigned mode and refresh its settings if the choice is rejected. Keep the item in its editor and reopen the correct check if the service has changed; do not resend food to correct its place. The API correction must be released before the POS that supplies this context: updating only one side does not guarantee this behavior.
Hold or fire a course
Review the held course and use Fire to release the selected eligible food. Shared physical units launch once even when their price is split. Refresh after uncertainty rather than sending the same food as a new sale. A historical shared batch can block a partial release. With the matching API and POS capability, already committed held food can still be fired after its bill has been paid. This does not reopen the bill, reoccupy a released table or change any collection. An authorization, pending payment or refund can make release unavailable: review the displayed state rather than create a new sale.
After merging bills, open and review the entire resulting bill before confirming Fire. An old batch must not silently fire food from other bills; shared pricing never multiplies physical quantities.
Repeat food as a new sale
Where Repeat is offered, review the copied food in the provisional cart and send through normal validation. The action does not copy a fractional charge or previous offering into a new payment. Stock changes only through the normal new-order flow.
Control courses on mobile
On the updated mobile POS, the bottom Menu strip selects the course for the next items. In Check, each course retains its state and controls: fire to release, stop to hold and ⋯ for other permitted actions. Buttons are separate and compact; selecting the active course does not send it. Send at the top uses the existing Foody workflow and pending release selections. A course shared across bills retains one physical production. Permissions, timing, submitted states and repeat restrictions still apply.
Review independent confirmations
A partial handoff preserves remaining units. Completing one required KDS station does not complete all preparation. Courier handoff and customer receipt are separate confirmations; a route departure does not prove a customer receipt time. See preparation and handoff.