Site Specific Features

Complementary Sale Items (With management approval)

Create an Account Number for each Manager.
Create a number of Account Charge POS Keys on a special keypad and assign each POS Key to a specific account number.
Add a password for each Manager on the POS Key.

How it works

In the middle of a sale, the Manager can choose to charge off a portion of the sale value to his complementary charge account.

The SwiftPOS Back Office transaction history will show all the charges that each Manager has made.

An audit will show which staff member was serving the customer at the time that the complementary charges were done.

Hand over a Voucher and be entitled to $1 beers

You could setup a secondary price level and make certain Products sell at $1 and use a price change key on the till to alter the next sold item's price to the secondary Price Level. As you only want it to be for a specific list of Products I would set it up as a multi link key, that would do the price level shift for the next item only, then do a Filtered Search by Family to display a list of Products to choose from.

How to do a R/A (Received on Account)

This is a feature that old style Cash Registers did when they had no ability to track account balances. It is recommended to use Gift Cards as a better replacement for this feature in SwiftPOS.

Create a finaliser POS Key called R/A.

On this POS Key, you need to Allow Over Tender + Force Tender to bring up the numeric keypad.

How to use the R/A POS Key.

Sell a Product for zero value, if there is nothing else in the sale.

Select the R/A POS Key and enter a negative amount using the numeric keypad.

Select EFTPOS or CASH to finalise the sale depending on how the customer is paying.

All the reporting will give you the total of what was entered on R/A and the payment method.

Turnstile Interface

This has the option to convert AJL to TJL QUEST format. Just add the extension to the 'Create NetPOS Sales File' in the Connect settings in Touch POS Terminals in SwiftPOS Back Office. The first field of each line is converted to the relevant Quest Header field and if the line is not supported by QUEST then the field remains. They would only be dealing with Quest Lines anyway.

You should now also be able to scan into the string field with RS232 Barcode readers. Keyboard wedge is different as it is just a keyboard input and cannot be dealt with so please test with RS232 only.

All of the current loyalty and ride passes have the same Barcode format. All Barcode are 14 digits in length and are Interleave 2 of 5 Format.

8660301XXXXXXX where XXXXXXX is the card/wristband number and the 8660301 is the prefix.

Cards 86603010000001 to 86603011000000 currently validates to NetPOS and off to POS Magic SQL for loyalty purposes (annual pass holders) and once up and running for those who will make online purchases.

Cards 86603011000001 to 86603019999999 currently validates to a program that we had written that works the same as the member validation file and creates an in and out file. It validates to the ride pass database. It is called MTCClient.exe

So when 8660301XXXXXXX is scanned normally it would go off to validate against one of the above methods to find their details.

However, when a string PLU is sold and one of these Barcodes is scanned we need to drop the masking of 8660301 and input the XXXXXXX (7 character) number as the text of the string. Once you put this into the Quest AJL format and write back the AJL to the correct directory our ride pass database will ready it in.

All scanners at are currently RS232 scanners.

Regarding the scanning of data for a string PLU. All of the current loyalty and ride passes have the same Barcode format. All Barcode are 14 digits in length and are Interleave 2 of 5 Format.