CATERMAN System Main Help Document
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.
Internet Bureau
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.
Security
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.
User Interface
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
selected.
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.
Hospital Patients
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.