POS behavior, courses and adjustments

Open Settings → POS, then the appropriate mode/profile. Legacy Full service settings redirect to the default profile. Custom fulfillment editing and optional customer prompts below require compatible Admin, POS and API versions. Updating the API alone does not update Admin or the installed POS; an absent control is not proof of incorrect configuration.

Set menu behavior

Open Menu behavior and choose the options offered for item selection, modifiers and navigation. Assign the intended profile to the POS device. Test with an item that has a required choice so staff cannot accidentally skip it. A checkout-mode profile does not assign a kitchen printer. Configure the shared printing profile separately for this POS installation; see printer assignments and pending documents.

Keep Admin and the assigned POS mode synchronized

With compatible API and POS versions, compare the restaurant and assigned mode shown in POS → More → Settings → Checkout with that mode in Admin. Course activation, Send and stay and open-check options belong to the shared assigned mode, not an independent local iPad switch. Devices without an assigned mode use the restaurant defaults. Save changes once with the required settings permission. A foreground POS checks for updates about every 30 seconds and on resume, navigation and completion of a sale action. Updates are deferred during an in-flight payment, send or item edit and read again at the next safe boundary; they never restart that action. You can use Refresh in Checkout to request a fresh read. A failed read retains the last confirmed configuration and does not prove that Admin’s change was applied. When another editor changed the same setting or the device assignment, the API rejects the conflicting save instead of overwriting it. Refresh, verify the current mode and values, then reapply only the intended change. Do not reactivate all modules locally or repeat payments to force synchronization. Kitchen printer assignments remain separate.

Retry a failed settings refresh safely

If the POS shows the settings refresh warning, check the connection and use Retry in the banner, or Refresh in Checkout. The last confirmed settings remain in use; the warning does not mean that courses or open checks were intentionally disabled. Retry is unavailable while a sale action is in progress. Let the current action finish, then verify the assigned mode and recheck its values before continuing. Reading settings does not resend food, collect payment or change terminal deposits. If saving a setting was rejected because another editor changed it, refresh before reapplying only your intended edit; repeating the old complete snapshot can never be a recovery procedure.

Configure service courses

Open Services and maintain the restaurant’s course names and order. Enable course management and any permitted hold/fire or Send and stay options in the POS device’s assigned mode. In Straight fire, select the intended library categories, apply and save. This mapping uses each item’s restaurant-wide library category, not its display/menu group or a matching group name. An item in an immediate-send category enters Straight fire when added to an onsite sale, even while a named course is selected. Ordinary new items use the selected course. Check a freshly added line after a catalogue change; existing saved lines are not moved retroactively. Straight fire means the next explicit Send dispatches those pending lines immediately: simply adding the article does not send or print it. Named course Hold/Fire choices remain provisional until Send/Continue succeeds. Continue is available only when the assigned mode permits it and stays on the check; it does not automatically fire the next course. Courses organize kitchen release; they are distinct from financial splits, QR payment ownership and customer-facing menu groups. Check shared-mode synchronization if Admin and POS show different activation states.

Review allowed adjustments

Open Adjustments and review the available reasons and behavior for reductions, offerings and cancellation. Staff still need the corresponding permissions. Library POS discounts and online promotion codes are maintained in their own modules.

Save settings after a device was forgotten or replaced

An old POS-mode assignment to a device already forgotten in this restaurant should not block saving another setting, such as when to ask for a fulfillment method. This recovery requires an API version that includes forgotten-device cleanup; it is not guaranteed on older installations. Saving removes only the old assignment to that forgotten device. It does not reactivate the device or assign its replacement automatically. After registering a replacement, open the intended POS mode in Admin, choose Assigned devices, select the current device, then Apply and Save. Check the resulting assignment; printer profiles remain separate. If saving still fails, keep the draft, retain the error message and check the installed API version before retrying. Do not delete other modes or repeatedly reactivate devices to bypass the error. A new assignment to a missing, forgotten or foreign device remains invalid.

Keep terminal deposits separate from POS behavior

Terminal batch actions do not change the POS service profile, staff shift or cash drawer. A manager with payments.manage opens More → Reports → Terminal deposits on a configured Victa Portable or iPad/Victa Mini. Follow the dedicated POS payment guide for end-of-day confirmation and uncertain-result recovery; do not use menu behavior or adjustment settings to settle a batch.

If the restaurant, sign-in or terminal changes, reopen confirmation in the correct context.

Configure POS fulfillment methods

With settings-edit permission, open Settings → Fulfillment → Point of sale. The catalogue shows cards for all methods, including hidden methods. Open a card to edit its display text, order type and optional customer prompt, then Save explicitly. A failed or unconfirmed save keeps the editor and values. Manage by location sets restaurant-wide availability, order/default and prompt timing, not a separate catalogue per device. Inside that nested editor, Save on a method stages it only: Save again in Manage by location persists the whole configuration. Closing a changed editor asks before discarding. Keep at least one method enabled and at most ten; reorder with arrows or the drag handle. The first enabled method becomes the default. Delete requires confirmation and cannot remove the last active method. For new sales, configure preparation tracking and handoff tracking separately on each method. The saved policy remains attached to the order; an older order without that evidence stays unknown. Existing orders keep their recorded method. An incompatible API disables unsupported editing.

Choose when staff select a method

In the same editor, enable the staff selection prompt and choose At the start of each new order or After tapping Pay or Send, then Save explicitly. Switching the prompt off and back on while editing retains the selected timing. With start prompting, entering Menu asks for a method on an unsent sale, including a retained draft when returning from another page. Closing this entry selector by its cross or background accepts the configured enabled default without opening optional customer collection or a table. Adding items, removing the last item, and Pay/Send in that same visit do not reopen the method selector. A new-sale reset or leaving and returning to Menu asks again. A saved check is not a new sale and retains its recorded method. Tapping a method explicitly continues immediately and opens its optional customer form when enabled; the onsite destination remains deferred until Send/Continue. Closing a selector opened manually from Actions or at checkout cancels that action without changing the sale. Checkout-only prompting does not open on Menu entry. With prompting disabled, new unassigned sales take the default while a restored explicitly selected method is retained; if disabled since then, choose an available method explicitly through Actions. Customer-information options remain per method, but all saved orders are tracked through Orders → All on POS and Admin subject to restaurant scope, access and filters. Payment and preparation remain independent. See whole-check fulfillment.

Enable the existing open-check workflow for onsite sales

There is no separate tableless-dine-in switch. Keep a dine-in method available in the restaurant fulfillment catalogue. In the POS mode assigned to this device, open Open checks, enable Use on this mode and save if needed. Predefined ticket names remain optional. Compatible API/POS versions then offer New check without a table. If unavailable, check the capability message and effective device mode; do not enable unrelated seat or delivery settings. This uses no artificial table and does not change online/QR order rules. Admin Orders can display the resulting dine-in orders without a table; Admin's manual new-order form remains pickup/delivery only.

Ask for customer details for a method

Requires matching API and POS versions. Enable Show customer information screen in the method editor and Save (also save Manage by location if editing there). Immediately after choosing this whole-check mode, the optional details form appears before adding items, including for the default with selection prompts off. Enter first/last name or use Add new or existing customer to search the restaurant directory or Enter contact for this order only. Search requires customers.view; order contact requires orders.manage. Done confirms mode and contact together. Skip retains the previous contact without applying typed changes. Back reopens mode selection; closing the flow leaves the sale unchanged. Full name: at most 80 characters. Nonblank phone: at most 32 characters, with 7–15 digits and ordinary separators. A matching guest-details API capability enables a private identifier (255 characters) and staff note (500); otherwise those fields are disabled with an explanation. Private context stays on staff order data, not public views, receipts or notification text. No customer account, marketing consent, contacts import or cash authorization is created. Configured notifications may use the saved phone. Subsequent batches inherit coherent check details; mixed-customer or allocated bills cannot adopt a replacement contact. For a table constrained to one fulfillment method, selection may be implicit without showing the picker, while this form, compatibility checks and joint confirmation of method and contact remain in place. Closing or a changed context does not save a partial choice.

Choose an existing contact or enter order-only details

In the optional fulfillment details form, open Add new or existing customer. The Customers search requires customers.view and searches the active restaurant only after two characters. Selecting a result returns its existing name and phone without updating a profile. Enter contact is available with orders.manage even without directory access: enter separate first/last names and an optional phone, then Done. The combined trimmed name is limited to 80 Unicode code points; a nonblank phone requires 7–15 digits and at most 32 characters. Back retains these edits locally when returning to search; closing the picker applies nothing. A restaurant, permission or order-context change blocks selection, including a late search response. The details form still requires its own Done to apply the mode and contact together. This is not the creation of a persistent CRM profile: email, address, marketing consent, contacts import, groups and tax fields are not collected here.

Configure checkout on a compact screen

On mobile, settings use one page stack. Back first leaves the current subpage, then its section. Headers, fields and switches use the same terminal controls. Checkout preferences retain their existing permissions and persistence. Printer options remain a draft until Save in the profile editor. Under Appearance, mobile retains neutral surfaces and blue actions; custom colors remain available on tablets. Light/dark theme and language remain configurable on the terminal.

Navigate the terminal

The handheld terminal has three unlabeled buttons: the signed-in user’s initials open More, the house opens Overview and the receipt opens Checks, subject to permissions. iPad keeps its configured navigation destinations. In Checks, the selector offers All checks and available floor plans; selecting a radio option changes the view immediately. Drag the floor plan when it extends beyond the screen. Overview contains collapsible cards for permitted availability, orders and tables. The full list supports item search; Not provided means availability was not supplied, not that an item is available. Refresh retries a failed read. These views change neither the assigned checkout mode nor printing profiles. The bar stays above Android navigation and hides while typing. Inside a sale, Menu/Check/Actions and the return to checks retain their own controls.

Find terminal deposit in the end-of-day flow

When the compatible API offers End of day, Terminal deposits opens that combined flow before any transmission. With an older API, the separate deposit screen remains available according to actual terminal capabilities. A provisioning change after display requires another review before reserving cash. An old card approval without verifiable provenance remains pending reconciliation: it permits neither another collection nor adoption by another restaurant. See closing and recovery.