Used to enable/disable tipping while saving. To enable tipping on saving (not recommended), set to TRUE.

Modifies the Tip label on the Finalize dialog. Becomes a button that toggles through the specified values and automatically calculates the tip for the operator based on the percentage specified.

 

If TRUE, Sales will only perform an exact match on Table/Sale Recall if the field begins with a number. If the field begins with a letter, Sales will perform a partial (wildcard) match.

If ReservationHeaders and DiningHeaders are both set to TRUE, the salespoint uses Reservation Headers.

When TRUE, if one uses transfer table functionality, the eligible servers to whom transferring a table is possible is based only on the Group= value and not the SubGroup= setting. This allows transferring tables between venues (have different SubGroup= settings).

Specifies the number of hours to use to determine servers on the eligible server list. The eligible server list includes all servers who have logged into a salespoint at the current venue in the last X hours (the “venue” being defined with the [Preferences] Group= and SubGroup= settings).

Specifies whether or not to perform an automatic log-out after each sale, or, in a fine dining environment, after almost any action that completes any activity on a given sale (such as order, print sale, pay, closeout, etc.). If TRUE, automatic log-out occurs.

When set to TRUE, the number of characters allowed for the table description is increased to twenty-five, and the button for increasing the table number size (i.e., the 100+ button) is disabled.

Adds the ability to prepend text to standard modifiers and alters the Modifier dialog to accommodate this new functionality. If setting is absent, modifiers work as they did previously. The parameters are used to prefix the description of modifiers.

 

If the Extra premod button is pressed followed by the Cheese modifier, the description of the modifier item added to the sale is Extra Cheese.

If TRUE, entry of the number of guests is required in order to start a table.

 

Note: Even when set to FALSE (i.e., number of guests = 0 is accepted) the Server Banking Report still counts tables with no guests as having one guest. Therefore, a positive entry of number of guests ensures the accuracy of the Server Banking Report.

If TRUE, upon swiping a credit card, the operator can save or save and pay with a credit card holder name instead of finalizing the sale. If Sales is set to use QuickTips=TRUE, a warning displays and quick tips is disabled. This makes the credit card available as a form of payment for the tab/table.

Adds the ability to restrict salespoints from viewing the payment breakdown information. To enable viewing of the payment breakdown, set to TRUE.

If TRUE, shows seat numbers for line items.

 

Note: In order to print a seat # on a receipt, use:

This setting helps with check splitting.

Previous behavior: A table is split and the account is associated with both sales. While this is OK from a money standpoint, it is confusing to look at because it appears that the payment is applied to both tables. In fact, the same payment is associated with each sale, so that when the first split is paid off, the account is decremented and the second split no longer shows that payment.

 

Two steaks on a table at $10 each, a $10 payment is made. Table is split, each sale shows a payment of $10 on it. Split 1 is settled using the account payment. Split 2 now requires the rest of the $ ($10) to finalize.

New Behavior: Only one of the splits now remains associated with the account when the split is made. So, from our example above, after the split, only split 2 would show the $10 payment. Split 1 would be the one required to pay the remaining money.

Issue: If a $15 payment is made, split 2 shows the entire payment of $15. In order to move $5 to split 1, the operator needs to call up split 2, refund $5 to cash, and then call up split 1 and make a $5 payment and re-save.

Summary: Paying before splitting is complex. The old behavior did not reflect a defect in the system, but the new behavior (with this setting) makes it a bit clearer for the operators.

The new behavior is the default but the previous behavior can be restored by using TRUE.

When DiningHeaders=TRUE, this setting controls how tables are sorted on the Recall Table dialog. Tables are sorted by the sh_save.first_name field, which is where the table numbers are stored.

 

TableRecallOrderBy=first_name ASC,last_name,orig_dt. first_name can be followed by either ASC (for ascending) or DESC (for descending), followed by last_name (stores the split number or text description of the table up to four characters) and orig_dt (stores the original order date/time).

 

Note: The sh_save.first_name and sh_save.last_name fields are often used in receipt layouts – sh_save.last_name is especially useful to show what is owed by split numbers/name when tables are split.

If FALSE, then the Recall Table dialog functions as it always has, with all table buttons displayed in white and ordered by the original order date/time, with the newest tables displayed first on the dialog. If TRUE, then the Recall Table dialog incorporates table button colors as determined by the ActiveTableColor and InactiveTableColor settings.

By default, tables with a positive balance due display in the default blue color and are ordered by the original order date/time, followed by tables with a zero or negative balance displayed in white and ordered by the original order date/time. Can also be applied to AutoRecall.

Provides a daily cutoff for how far back Sales looks for open tables in a DiningHeaders=TRUE environment. If TableReset is not present in the .INI file, Sales recalls all open tables.

Specifies whether or not to use tipping feature. Triggers the Salespoint Close Out dialog to change mode for F&B close out.

If TRUE, Sales will only perform an exact match on Table/Sale Recall if the field begins with a number. If the field begins with a letter, Sales will perform a partial (wildcard) match.

If TRUE, allows the operator to recall tables without changing which operator “owns” the table and includes the ability to transfer ownership of a table from one operator to the other.

Used to assign certain table numbers or a range of numbers to a salespoint.

 

In this example, tables 1 through 10 (inclusive) and 99 would be valid entries.

 

This means for this specific salespoint, the operator can use only tables #11 through 20, #30, #45, # 60 through 69 and table #80. Any other entries, such as 21, 33 or 99 are considered invalid in this case.

If FALSE, adds the ability to prevent operators from voiding or reducing the quantity of a saved/recalled item without sufficient security. Used in conjunction with the security setting Sales-Allow Voiding Items that have been Saved.

Both the security and the .INI setting are required for this to work. Basically, you need the .INI setting to check if the salespoint is restricted from voiding a line item after it has been saved (you would want to do this in modules such as Food Service, but not Retail, Ticketing, etc.). Then, if the salespoint is restricted, the operator must have sufficient security to void the line item.

Used with SubGroup. For fine dining. If these are specified, all sales are saved with the criteria and only sales matching these criteria are recalled. To retrieve all sales, clear these fields from the Recall Sale dialog. Because the recall for fine dining recalls all sales for the operator, this limits the sales to only those done with the group and subgroup saved within the saved sale criteria. This helps in scenarios where an operator may work in various departments, so that when he recalls his tables, he doesn’t also get all the other sales he worked on at the call center, for example.

Used with Group. For fine dining. If these are specified, all sales are saved with the criteria and only sales matching these criteria are recalled. To retrieve all sales, clear these fields from the Recall Sale dialog. Because the recall for fine dining recalls all sales for the operator, this limits the sales to only those done with the group and subgroup saved within the saved sale criteria. This helps in scenarios where an operator may work in various departments, so that when he recalls his tables, he doesn’t also get all the other sales he worked on at the call center, for example.