CATERMAN provides an internet-based
facility for creating and serving recipes for large-scale catering operations.
Primary targets are school/educational meals services, hospital hotel services,
large industrial staff restaurants/factory canteens, and any organisation
providing catering services on a large scale.
CATERMAN also provides for other services such as cleaning, servicing and maintaining - any activity which can be defined by a recipe/bill-of-materials plus operations based on definable quantifiable resources.
CATERMAN provides facilities for creating and maintaining supplier information, stock items, recipes, menus, menu cycles, resources, scheduling, ordering, receiving, invoicing, sales/purchase/nominal ledgers, and much more, in a multi-lingual multi-company multi-user real-time environment with targeted on-line help.
CATERMAN is delivered by a browser on any standard PC connected to the internet providing typical response times (dependent on internet connection) of approximately half a second, achieved by a minimal data technique combined with local content.
CATERMAN is constructed on a four-tier design, consisting of a user browser GUI on a PC (tier 1) connected over the internet to a web server (tier 2, any one of a number of designated web servers) which are supported by an application server (tier 3, any one of a number of application servers) maintaining the database on a number of data servers (tier 4, from one data server supporting the entire database up to multiple Linux servers each supporting a logical segment of the database). Tier 1 may be a desktop/laptop/notebook/thin client PC with either Windows or Linux and any standard browser. For point-of-sale (EPOS) situations, CATERMAN prefers a PC with a touch screen, a wedge magnetic stripe card reader, an IRIS bar-code/ numeric-character USB device, and a web-cam for recording transactions.
Access to CATERMAN is via a password and
PIN, with each password assigned certain facilities to which it allows access.
The user sees only those facilities he is authorised to use. Each password may
be constrained by any or all of the following additional conditions:-
(a) Access only from a designated IP Address
(b) An ID Certificate
(c) One-day-use sub-password
(d) Supervisor permission.
Depending on password parameters, access is also either completely or partially protected by encryption (strength dictated by browser capability). Passwords are given an expiry date, and also a time interval which ensures that, should a user screen be idle for this time period, the screen will timeout. The actual data itself may be held in encrypted form on the data servers. All activity by every user is logged and may be inspected subsequently by authorised password owners. All data is also logged under a technique usually known as after-look-journalising, so that the data may be restored to any point in time from a previous backup plus the transaction log. Audit trails are well defined and have been accepted by many major organisations.
The user interface via a standard browser may be tailored to each user. Every item of text may be replaced by user-chosen text or graphics, and positioned anywhere on the screen. The text may be of any supported size/colour/typeface, and the graphics may be local or delivered over the internet. In practice, local graphics provide for faster response times. Although much depends on restrictions inherent in the chosen browser, data fields may be set by the user to trigger several actions when chosen events take place, e.g. on click, double click, mouse over, content change, etc. For example, a stock item identifier may be set to be read out loud by Microsoft Speech when clicked, or bring up a picture of the stock item, etc. Other non-CATERMAN applications can be launched by this technique. Therefore, the user environment can be individually designed to be almost anything the user wants, in any language, with aids for assisting disadvantaged users. Depending on password parameters, the user environment may be exported to a holding database. Environments can be imported from this database by empowered users. Thus, a "class" of environment can be set up targeted at a specific group of users who can then import it either when a password is set-up or at a later date.
Typical CATERMAN Applications
School Meals/Tuck Shops
CATERMAN provides for a school meals
service by creating a menu cycle for any number of schools (and restaurants
therein) with menus scheduled for each day consisting of recipes classified by
type with facilities for healthy eating incentives and nutritional information.
The recipes consist of stock items and sub-recipes, and have cooking
instructions and resources required.
CATERMAN provides for automated suggested orders for stock from preferred suppliers, with goods receiving and invoice handling as well as stock control. Each recipe has dynamic costing based on a choice of methodologies (first-in first-out, average, contract prices, etc.) and multiple prices based on chosen formulae. All customers buying these recipes are associated with a charge band so that different prices are shown for different classes of customer. For example, some prices may include VAT.
At the restaurant EPOS level, customers are required to identify themselves by either a magnetic stripe card (or similar) or a bar-coded badge or similar, or a RFID tag, or a biometric parameter (fingerprint, retina scan, etc.), in short any mechanism which inserts a unique code into a browser field, or the EPOS operator may identify them on the database by entering information to an alpha-matching facility. When the customer is identified with an account, a picture of the customer is shown to confirm identity. The customer's account is set-up with multiple identifiers, for example the customer may have an existing magnetic stripe card which can be associated with the account without the cost of issuing purpose-designed cards. Each account is associated with one or more restaurants/outlets where it may be used.
The account may consist of several
elements, the main one being an amount of money residing on the account.
Other elements may be allowances, such as a daily free school meals allowance, or a weekly healthy eating incentive, or similar. Each allowance may be associated with a particular recipe type if necessary (each recipe can have several "types" such as "healthy eating", "high protein", "contains nuts", "eligible as free meal", etc.). Each customer account may have a maximum daily spend associated with it. In addition, the account may have a list of recipe types which are forbidden to the customer (e.g. "contains nuts") or a list of recipe types allowed to the customer (e.g. if the customer is a child, the parents who have paid into the account might stipulate that the account was to be used only for certain recipe types).
Money may be added to customer accounts by allocation from a fund or receipt of cash or a cheque by a cashier-type CATERMAN user, or a payment over the internet via a credit/debit card handler such as PayPal (provided as standard in CATERMAN, but subject to a commission - better to have your own PayPal account), or by submission of a voucher to the EPOS operator - the most cost effective way of doing this is by having one or more voucher issuing machines (car park ticket issuing machines are ideal for this, being sturdy, reliable, cheap and readily available from many manufacturers). CATERMAN keeps a record of all voucher numbers submitted (thus preventing multiple submissions of the same voucher) and checks voucher id against pre-entered parameters. Ideally, the voucher (or ticket) is machine read (bar-code or OCR, IRIS Executive pen works fine for this) and the value can be either pre-set to a certain figure or a value can be entered manually or machine read. The amount is added to the customer account, and the voucher invalidated and retained by the EPOS operator.
On customer identification, CATERMAN shows
on the screen the menu tailored for that customer in a form tailored for the
EPOS operator. For example, a customer who is forbidden to eat nuts would have
all recipes containing nuts removed from the menu. The EPOS operator would
enter the customer's selections either by touching the graphic of the item on
the colour-coded screen (if a touch screen PC was being used) or clicking on
the graphic, or entering the PLU number, or hitting the appropriate key on a
large keyboard (if a retail 100+key keyboard primed with PLU numbers for
labelled keys is being used), or reading the bar-code if present on the item
CATERMAN deducts the cost of the selection (as dictated by the customer classification against the appropriate recipe price band) from any appropriate allowance(s). Any excess remaining of the price is deducted from the main customer account. If either there is insufficient funds on the account, or the daily maximum spend of the account is exceeded, an appropriate message is shown to the operator (and customer if a customer-facing screen is present). The selections made are shown at the top of the screen with prices, and the cumulative spend. Any selection may be retracted at any time.
On completion of entries for the customer, the account is updated and the transactions finalised in the database. A receipt may be printed if required.
A complete history of all transactions on the account is available to empowered passwords.
For Tuck Shops, CATERMAN provides the means
for cost efficient cashless catering suitable for all age groups.
A pupil can be entered to the system as an Associate with affinity to any unit (tuck-shops, canteens/restaurants, clubs, etc.) and be identified only by a pupil number or similar.
A picture is taken and kept on a local resource (user's PC or local storage on the LAN), which is not accessible to external users. This picture's address is entered into the Associate record, together with one or more alternative identifiers.
The alternative identifiers may be any unique number-bearing object such as an old obsolete credit card or debit card, a library ticket, a piece of paper with a bar-code on it, anything with a unique number which can be read by a magnetic stripe card reader or an OCR wand or bar code reader or RFID tag scanner or unique reference supplied from a biometric scanner.
Any of the identifiers (student number, alternative id, alpha-matching on the name if it is entered, plus additional info such as school/college id, class id, etc.) can be used to select the Associate record at a PC or epos terminal (a PC with magstripe/barcode/OCR reader), whereupon a picture of the Associate is displayed together with pertinent information including amount of money available.
The amount of money available may be comprised of two or more components. For example, there may be a special allowance available to spend on a daily basis only on certain recipes (e.g. recipes allowed for free school meals, recipes coded as "healthy eating", etc.
General money may be available subject to a daily maximum or unrestricted.
Money arrives on the Associate record account by allocation from an authorised dispenser of funds or by entry into CATERMAN of vouchers or by payment onto the Associate account via a credit or debit card (subject to commission) using Paypal.
Vouchers may be issued from a variety of sources, but a particularly cost effective mechanism is the use of "Car Parking Ticket Dispensers", which are cheap, robust, and easily available from a large number of suppliers. Many public bodies are already users of such machines, albeit in a different environment, and already have in place a proven cash collection and accounting procedure.
The voucher is machine-readable (either barcode or OCR number) and is registered into CATERMAN so that it can be used only once.
CATERMAN provides consumption analysis by Associate and financial data in reports.
Additional features include healthy eating incentives, nutrition analysis, etc.
CATERMAN provides for not only the feeding of patients but also for their repetitive hotel services. A typical scenario may be that each patient is identified by a number of identifiers such as patient number, national insurance number, etc., and is associated with an account as in the School Meals Scenario above.
Each account is associated with one or
more service points such as the ward the patient is in, the linen service, the
catering service, etc. Each service has a cycle of menus so that a number of
"recipes" are available on each day. The patient may order or have
ordered for him a number of these available "recipes". Obviously, the
catering service is the easiest example to understand, wherein the patient
orders or has ordered for him a meal from each of the breakfast, lunch and
dinner menus available to him (under the constraints dictated by the account,
see School Meals above). These orders may be placed either by the patient over
the internet, or by a machine-read menu the patient has marked, or by a catering
assistant when collecting up from the previous meal (CATERMAN provides for
post-meal entry of portion percentages actually consumed to empower
nutritionist surveillance - the nutrition of every recipe portion is
accumulated on a date/time basis. This is becoming of greater importance with
the recognition that patient recovery is dependent on diet).
Increasingly, health staff are becoming equipped with hand-held PC-type devices supporting browsers and connected by secure Wi-Fi to the hospital LAN. The collection of more detailed patient information on diet/actual consumption of food will eventually become essential to patient care.
CATERMAN handles all of the production aspects of meal provision from chef and catering assistant time through equipment usage down to the labelling and container allocation for each delivery.
CATERMAN treats the linen service in a similar fashion to catering. Change of bed linen is subject to a cycle, and the patient "orders" a change consisting of clean sheets and pillow cases plus the time of two nursing assistants (resources). Similarly, bathing of bed-bound patients may be treated as a service. There are many other aspects of patient care which can be handled, and therefore COSTED and CHARGED, in the same way.
Faster Fast Food
Here’s the scenario:- Consider a typical fast-food set-up, where the customer walks in, picks up a tray, moves along the counter selecting pre-loaded dishes and putting them onto his tray. He arrives at the checkout where the EPOS operator then enters the selected items on the tray into the EPOS terminal by tapping a multi-key PLU keyboard or touching the screen to indicate an item on a displayed menu (list of dishes) or typing in a code or description, etc. (For pre-wrapped items it may be a barcode scan.) Eventually, a total is arrived at for the contents of the tray, and the customer then needs to pay, either cash, or by account - which means he has to identify himself by producing a card, etc., or satisfying a biometric scan (Fingerprint? Unhygienic! Retina scan? Only 95% accuracy in ideal circumstances, and expensive!).
The end result is always a queue at the checkout plus mistakes/inaccuracies by the EPOS operator, and dissatisfied customers.
Now, here’s a CATERMAN scenario:- The same fast-food set-up, but this time the customer walks in, picks up a tray, moves along the counter selecting pre-loaded dishes and putting them onto his tray. He arrives at the checkout – and is presented with the list of his purchases with a total plus a printed receipt if he wants one. He proceeds to a table for his meal.
End result? No queues, accurate billing, satisfied customers!
Whoa! Did we just miss something? How did the CATERMAN system know what the customer had bought and who he was (to identify his account)?
The answer is RFID tags (in standard CATERMAN RFID tags conforming to ISO 15693-2,-3 High Frequency 13.56 MHZ) embedded in the crockery (well, actually for our demo suite, we have TI laundry transponders superglued to the dishes/plates/bowls/mugs/cups etc., We would like to hear from any manufacturers who are interested in making plastic crockery with embedded RFID tags!). Each RFID tag is unique, and when dishes are filled in the kitchen or prior to putting on the fast-food counter shelves, they are passed over a RFID antenna to allow CATERMAN to assign each tag to a selected recipe. So, when a tray full of dishes containing Apple Tart is to be put on display, Apple Tart recipe is selected on CATERMAN, the tray (or container) is placed over the antenna, and the RFID tags are assigned to Apple Tart (numbers depending on antenna, but 30-plus works for standard antenna). Subsequently, when a customer picks one of those dishes, Apple Tart pops up on his bill when he arrives at the checkout (there is an antenna under the counter at the checkout). CATERMAN takes care to read tags only once, and caters for additional tags (dishes) being added. Anything without a tag (pre-wrapped items such as biscuits, chocolate, etc.) can still be bar-code scanned or manually entered/selected from a list/PLU keyed/touch screen/etc. The customer (if not paying cash which should be separated from the catering function for hygiene reasons) is identified by RFID tag (usually in the form of a card or key-fob) or by swipe card or barcode scan of a badge, or biometrics,etc., and his picture pops up on the CATERMAN screen for positive ID by the checkout operator. (In a trusted environment, a web cam on top of the CATERMAN terminal/PC recording activity, would allow complete automated operation without a checkout operator except on occasion when intervention is required.) If the customer is identified by RFID tag, the tag can be placed on his tray and read with the tags on his chosen dishes, or a separate smaller antenna can be available for ID only.
When dishes are collected after use, they are washed as normal (the laundry tags are unaffected by dishwashers, so presumably crockery with embedded RFID tags would also be immune to commercial washing/cleaning operations), and can then be used again to contain any recipe - CATERMAN re-assigns the unique tag identifier to the new recipe as it did for the Apple Tart above.
As CATERMAN retains all the information about the tag/recipe assignment, if the prepared dish or container is put into stock (for example, in a cook-chill or frozen meal environment) CATERMAN can subsequently identify the contents of freezers/chill-cabinets and provide data on creation dates and expiry dates.
However, if you want to do this on a large scale and also write the information to the tags themselves (for use by non-CATERMAN end users) you will need to discuss this with us.
Standard CATERMAN accommodates FEIG (www.feig.de) RFID scanner Mid Range Reader ID-ISC.MR100-A (RS232) on a COM port with antenna ID-ISC.ANT340/240 for RFID assignment to recipe and identification of recipes at checkout (and customer too, if using RFID tag customer identification). CATERMAN utilises REALTERM for accessing the RFID scanner so you need to download it from Sourceforge (it is FREE) and install it on the checkout PC and recipe assignment PC if a different terminal.
If you only want RFID tag customer ID, CATERMAN uses RFID99-DTR-01 USB Desk Top Reader Development Kit from RFID UK (www.rfid.co.uk).
Currently, CATERMAN uses RFID technology for customer ID and recipe ID only, but this is easily extended to stock control wherein a RFID tag is attached to incoming stock to assist with stock takes, stock picking, etc. However, as suppliers might soon be attaching RFID tags to their products anyway, we are awaiting developments.
Inspection and Monitoring
Finally, a future CATERMAN facility will be the Inspection and Monitoring System, which is designed to assist in the maintenance of high standards for all service areas.