Electronic Point Of Sale (EPOS)

The CATERMAN EPOS facility is best supported by a PC with a barcode or barcode/OCR reader, and/or a RFID scanner, and/or a magstripe or smartcard reader. A web-cam is also useful for recording all activity and providing a security aspect.
While a PC without these accessories functions adequately by the user typing-in data, the speed and accuracy of operation in a busy environment will be impacted.
It is STRONGLY recommended that the EPOS function has a default location for gifs/images/icons etc. on the user PC or LAN rather than the standard default server (see FONTS/Screen Layouts - Master Menu).
Images/icons loaded from the PC or a local storage on the LAN are faster than WAN loads.
Response times should be around half a second, if they usually exceed 1 second then make sure you are running with local image/icon source. EPOS Functionality
Essentially, the EPOS module provides for a customer to identify him/her self by presenting either a magstripe card or barcode-marked or OCR-readable document or RFID tag with a previously-registered unique identifying code.
The card/document can either be swiped by the customer or handed to the user operator for swiping. A RFID tag can be offered to the RFID scanner/antenna which may be a small antenna dedicated for customer identification or may be shared with recipe auto invocation, in which case the customer could place it on the tray with the selected dishes.
In the absence of such a card/document/tag (or if using a PC without these capabilities) the customer may be identified by the operator typing-in the customer identifier or alternate identifier or by alphamatching on the customer name (if entered during Associate Record creation/maintenance).
The Associate Record of the customer is identified, and the details displayed on the operator screen, including a picture of the customer (the picture should be loaded from a local source, such as the operator's PC or a LAN, see Associate Maintenance). If the operator is running in encrypted mode (see Password Maintenance) the picture will need to be loaded from a secure server.
Only Associate Records identified with the Unit in which the operator is working are accessible.
The Associate Record contains details of what allowances are available to the customer, how much money is on the cash account (if any), and which recipe charge band is applicable to the customer (see Recipe Maintenance).

If unknown cash customers are to be catered for, a special cash psuedo-associate record can be invoked.
Having assured that the customer is correctly identified by both possession of appropriate card or document and likeness of picture, the operator can select an option to enter money onto the account if the customer presents a voucher (or similar warrant). The voucher may have been purchased from a cash-handling facility or be an authorisation.
A list of previously entered vouchers for the customer is displayed.
Generally, money is paid onto the account by a central function which authorises allowances, etc., or by a credit/debit card payment via Paypal or similar by the customer or a representative of the customer, etc.
However, a cost efficient option is provided by one or more ticket-issuing machines which give a machine-readable (OCR) unique identifying number and value. These can be scanned into the PC via the OCR device (or manually input) and the ticket can then be invalidated by the operator (and kept for verification if necessary).
If the customer has previously bought items on this day, the transactions are displayed. The operator may make refunds by clicking the Refund Button and selecting the appropriate transaction to reverse.
Assuming that the customer is now ready to purchase items and has money to do so or credit on the account, the system moves on to entry of the items selected.

Entry of Customer Selections

When the operator first enters the EPOS module, the system checks which menus are present on the menu cycle for the day. The operator is then asked to choose which of the menus are applicable to the present EPOS session. The recipes present on all of the chosen menus which have a PLU upto 99 on the menu line (or occur in the first 99 lines of the menu) are displayed on the screen to allow the operator to enter them as customer selections by clicking the accompanying button. However, if the recipe has a barcode and no PLU, it is assigned a PLU starting at 10000001 and a does not appear on the screen (on the assumption that it will be referenced by barcode rather than PLU key).
Selections may be made by entering the PLU (or pressing the appropriate key if using a 100-key or multi-pad retail keyboard) providing the appropriate PLU has been entered against the menu line (see Menu Maintenance). If no PLU has been entered against a menu line, the first 99 items without a PLU are automatically assigned a PLU from 1 increasing by 1 as each PLU-less menu line is encountered. This allows a number to be entered to make the customer selection.
N.B. All actual PLUs assigned to keypad keys should be greater than 99 and the likely number of none-PLU menu lines. It is assumed that menu items to be selected by PLU need not be shown on the screen.
All menu lines shown as selectable for the customer have been checked against the customer Associate Record to be within any defined parameters for the customer. For example, if the Associate Record shows that only certain recipe types are allowed for the customer, only recipes of those types will be shown. If certain recipe types are forbidden for the customer, they will not be shown.
The operator can select recipes not present on the menus for the day or not available to the customer by alphamatching and then forcing them through. Thus, if a "special" item not usually present on the menu is unexpectedly made available, the operator can select it (providing it has a recipe!) and it will then be automatically added as a choice on today's menu. However, if the customer is not allowed that recipe, a message will be shown and the selection rejected. (For example, if the customer is forbidden recipes of a type containing nuts, then such recipe types cannot be selected for the customer).

If RFID tags are used for recipe identification (see Recipe Maintenance), recipes in RFID-enabled dishes assigned to recipes are automatically selected for the customer (but in accordance with the rules as above) and appear on the screen as selections already made.

Should the customer add further dishes after the initial RFID read, the RFID read may be re-run by operator request – each tag is only counted once.

Providing the Associate Record has sufficient funds or allowances available and no daily maximums have been exceeded, the selected menu item is added to the customer transaction.
A running balance is shown.
When all selections have been made (no further data is entered) CATERMAN asks if the transactions with the customer are to be concluded. If they are, the Associate Record and Sales Transactions are updated, and the next customer identifier is requested.

Full Auto Operation

In certain secure and trusted environments, full auto operation with RFID tags may be implemented by judicious use of focus/blur methods (see Fonts Facility). Extreme care must be taken when setting this up, as access to window/page operations will be impossible if a screen “submits” automatically on display.

The scenario for full auto requires only an operator in a supervisory capacity. Customers select dishes and place them on a tray (can be together with their RFID tag identification if scanner shared for customer id and recipe selection), identify themselves using a swipe card or bar code or RFID tag, and subject to the account having sufficient funds or credit, they are presented with an invoice printed or displayed – no operator intervention. Security is enhanced by using a webcam record of all activity, in the event of non-cooperation by a customer.

Customer Advance Ordering by Internet or Mobile Phone SMS Text Message

If a user's password has an associated telephone number (see Password Facilities) and an Associates record also has the same telephone number associated with it, or the user has set up the account on the internet utilising a mobile phone, the user may make advance orders for the account either over the internet or by sending a text message to a designated telephone number with a keyword as first word - the keyword has to be set up for the restaurant unit (see Unit Maintenance). The text of the message must contain valid recipe codes available for the date and time of the order. Using the internet, the account holder enters the date and time for the order, default (no entry) denoting an order for as soon as possible (now). CATERMAN then offers the recipes available at that date and time for selections to be made. The menus for each date with start and end times of availability must be present on the unit's menu cycle for the number of days in "Advance Ordering Days" setting of the unit (see Unit Maintenance) to use this facility. If the setting is 0, advance orders will be refused, a setting of 1 allows advance orders for today only, a setting of 2 allows orders for today and tomorrow, 7 for the week ahead.
On completing the selection, it is confirmed on screen, and a confirmation email is sent to the account holder and to the kitchen/restaurant (providing an email address is present - see Unit Maintenance) showing the account holder name, identification, address and delivery time if it is to be delivered, the date/time the order is required from the kitchen, and the recipes/quantities selected. Facilities are provided for an account holder to enquire/maintain advance orders, and for the restaurant/kitchen staff to enquire on all account holders advance orders upto a chosen date/time. (A PC in the kitchen with a running email system requesting new emails on a minute by minute basis could provide a copy of each order with audible alarm, and does not have to be logged in to CATERMAN).
The account holder may provide identification (magstripe card, barcode, optical characters, RFID tag, biometrics, etc.) and the order is presented on the EPOS screen (and can be amended or augmented), payment being made by deduction from the account (cash and/or allowances as appropriate) or payment may be made to the EPOS operator by cash, credit/debit card, or voucher (ticket, card, etc.) - cash should be discouraged in a catering environment. If the account holder quotes the order number, the same scenario ensues, but it is up to the EPOS operator to request suitable identification especially before serving an order paid for from the account rather than cash. Where a delivery service is available, and the account holder requests delivery, the account holder's post/zip code is compared with the post/zip codes entered on the restaurant unit (see Unit Maintenance). If it is in an entry's range i.e. the account holder's code starts with the same characters as entered in one of the unit's delivery post/zip codes, the appropriate delivery time is extracted and a delivery cost for the code associated with the value of the order. If a particular date/time was requested for the delivery of the order, the production time for the order is adjusted accordingly by the delivery time. If a production date/time falls before the present, the order is refused with an error message.
For advance orders placed by mobile phone text message, the message must be sent to the designated telephone number and must commence with the keyword associated with the restaurant/unit (see Unit Maintenance), followed by a space.
If delivery is available and required, the next entry must be a "d" followed by a space.
If a particular date/time is required, the date in the form dd/mm/yy is entered (the / are essential) followed by a space so that 07/07/07 denotes 7th. July, 2007, 07/07 denotes 7th. July this year, and 07/ denotes the 7th of this month. Generally, only dd/ is used, as an advance order for more than one month ahead must be unusual and requires the Unit Advance Order Days setting (see Unit Maintenance) to be longer than a month. If an entry of, for example, 07/ is made on the 28th. of a month, CATERMAN assumes the entry is actually 07/mm where mm is next month. (In December, it would also be next year.)
The next entry is for time in the form hh:mm (24 hour clock). The : is essential! Obviously, if a date is given, a time must also be provided. A time without a date is assumed to be today.
The remainder of the message consists of the recipes required, each denoted by the recipe code follwed by a space, for example:-
"bluefrog d 21/ 17:30 beanbb eggf sausp+2 bbb"
which asks for recipe code beanbb (could be beans on toast brown bread), egg fried, 2 pork sausages, brown bread and butter, to be delivered to the account holder's address at 5:30pm on the 21st. of this month.
The order will be refused with an error message if the account holder sends it after the 21st. of the month or before the 15th., or if any of the recipe codes cannot be found on the menus for that date and time.
Missing out the "d 21/ 17:30" means "I am coming to collect it now".
The "+2" on the end of sausp means "I want 2 of these", the other recipe codes have an implied "+1".
A confirmation text is returned to the phone. Forwarding the confirmation message back to the restaurant cancels the advance order.
The procedure is then the same as for advance orders placed by internet.


Return to CATERMAN Main Facilities List