Brochure Extract
Overview
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 of less than one 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 magnetic stripe card reader and/or RFID reader, a
bar-code/numeric-character USB device, and a web-cam for recording
transactions. We have found that a HP TouchSmart IQ790 PC, with it's 19" touch screen, is ideal as an EPOS terminal,
but a dedicated-designed-for-the-task EPOS terminal is best, e.g. IBM SurePOS 500.
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 or range of IP Addresses
(b) An ID Certificate
(c) One-day-use sub-password
(d) Supervisor permission
(e) Mobile-phone-user account (PIN code supplied as SMS text)
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.
Passwords are assigned security levels from 0 to
99 depending on user attributes. Levels 90 upwards allow for special system
facilities, for example level 90 is the lowest level allowed to
create/amend/delete passwords. Mobile phone accounts are tied to a phone number
which is then tied to the user, and such accounts are normally created by the user
and may only have a zero security level. Any account may be associated with a mobile phone,
and any account may be allowed to place advance orders for meals either by internet or SMS text message.
Special attributes are assigned to password
security levels 0 and 1.
Level 0 is dedicated to Cashless Catering Account
Holders, and allows access only to view menus and menu
cycles, place advance orders by internet or SMS text for either as soon as possible
or for any stipulated date/time in the future upto one week ahead,
and access account holder information including
previous purchases, account payments, nutrition analysis of consumption, etc.
Payments may be credited to the account at an EPOS terminal by the EPOS operator (cash, cheque, voucher,
credit/debit card, etc.), or by the account holder by voucher or via PayPal provided the restaurant has
a bona fide verified PayPal account (CATERMAN does not provide bank accounts, merely the means to make
payments to them!). Vouchers are issued by the restaurant or group to which the restaurant belongs,
and may be in the form of cards similar to mobile phone top up cards, or tickets from a machine (car park
ticket machines are ideal), allowances (for example, a student food allowance) or promotions. Vouchers
may be restricted to only certain recipes (e.g. food only, no alcohol, etc.). Allowances are for a stated period
(they have a start and end date) and an amount of credit applicable to each day, week, fortnight, month or the whole
period.
An additional password is required
to access a particular account where the password holder controls more
than one cashless catering account (e.g. a parent with two children with accounts).
Advance orders are confirmed by email to the customer and optionally to the kitchen/restaurant
(also by return SMS text if placed by mobile phone SMS text). Where delivery service is available
to stipulated post/zip codes (detailed for each kitchen/restaurant with delivery time and additional
cost if applicable), the delivery time and cost is shown on the confirmation, plus the
production time.
Level 1 is dedicated to suppliers, and allows
access only to view data for a supplier (including orders placed on that
supplier) and to amend contract prices for future orders for items supplied by
that supplier. An additional password is required to access the particular
supplier account. Higher-level password holders may be assigned a facility
whereby alternative ingredients for recipes are shown with cost and other data
and the lowest cost (or preferred) ingredient (i.e. stock item to be purchased)
may then be ordered in place of the recipe-designated ingredient for the
operational unit (or substituted in all local or general recipes if the user is
so empowered).
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
Fast Food
Service/School Meals
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 (with or without a PIN) or a RFID tag or a
bar-coded badge or similar, 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 £/$/€250 charge for setting up your own PayPal
account), or by submission of a voucher to the EPOS operator or entry of the
voucher to an account via the internet with the voucher authorisation code
(similar to topping up a pre-paid mobile phone with a phone card). 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, for EPOS operator entered vouchers 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. For vouchers to be entered over
the internet, CATERMAN generates the data for printing on the voucher/ticket in
the form of a downloadable file (so you can print your own tickets/vouchers or
send the file to your voucher/ticket provider for printing). Any range of
voucher/ticket numbers can then be activated by an empowered CATERMAN password
holder (when they are inserted into the voucher/ticket issuing machine, for
example). Subsequently, any voucher/ticket or range of voucher/tickets that has
not already been used can be cancelled/de-activated by an empowered CATERMAN
user in the event of theft or loss of a roll of tickets, for example.
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,
or interrogating a RFID tag, or any combination of these methods.
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.
If RFID tags are used (see Recipe Maintenance) and
assigned to recipes, all customer selections on RFID-enabled and assigned
dishes are automatically selected for the customer and appear on the list of
selected dishes.
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.
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).
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.
Mobile Phones and SMS Texting
Mobile phone owners may set up their own accounts using the internet
with selected restaurants (the restaurant unit must have an entry code word - see Unit Maintenance).
A level zero password is created and the account may be accessed by entering the mobile phone number and the
code transmitted to the phone.
The account requires a name, an email address, an address and post/zip code if deliveries are available/required,
and some unique form of identification such as a number from a travel card, library card, student card, etc.
After set-up, the account holder may use the account to place advance orders for as soon as possible or any
future date/time within the advance ordering period stipulated by the restaurant/unit, providing menus for that
date/time are available.
Advance orders may be placed by internet or by SMS text message from the phone. SMS text messages must start with
the restaurant code word (usually the name of the restaurant, e.g. bluefrog), and be followed by d on its own (followed by a space)
if delivery is required, by the date for the order if not today in the form dd/ (for days later this month) or
dd/mm (for days next month) or dd/mm/yy, followed by a space. Similarly, if the order is not for asap,
the time must then follow in the form hh:mm (hours:minutes, 24 hour clock).
The / in the date and the : in the time are essential!.
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.
Depending on the setting of the restaurant/unit advance ordering days, the order date is ratified.
An advance days setting of zero indicates that the restaurant/unit does not accept advance orders, a setting
of 1 means orders will be accepted only for today.
Assuming the restaurant/unit advance days setting is 7,
the order will be refused with an error message if the account holder sends it after the 21st. of the month
(CATERMAN will assume it is for 21st. of next 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.
All advance orders result in a confirmation email to the account holder (if they have an email address) and to
the restaurant (if it has an email address, CATERMAN provides an email account if required)
showing the time for which the order is to be prepared (and the delivery time and address if it is to be delivered).
Account holders may view their own advance orders, and of course the restaurant/kitchen staff can enquire on all
advance orders for the resaurant. It is advantageous to set up a PC in kitchen with email access set to request
emails every minute, thus advance orders arrive within a minute of being placed usually with an audible alarm.
The PC does not have to be logged in to CATERMAN to perform this function.
Fast food outlets using this system would need to provide instructions on their menu cards, and every recipe
must have a recipe code. Menus with these recipes must be set up on the menu cycle with applicable
start and end times for each day. Menus must be finalised one week ahead where advance orders are accepted.
The Advance Order Spacing parameter may be entered on the restaurant/unit's definition, which allows for smoothing
of advance order times. The Advance Order Spacing parameter allows for the entry of a number of seconds (which should be equal or
slightly greater than the average time in seconds needed to fulfil an order at the Unit's busiest time)
which will be added to the customers order time at order placement (for internet customers,
before the customer accepts the order, for SMS text orders the customer has the option to cancel).
Thus, an entry of 10 (the average time for the Unit to serve a customer at the busiest time, say 30
seconds per customer at 3 EPOS terminals) will result in orders being rescheduled at 10 second intervals.
In the case where one hundred customers place orders for 12:30, the first 6 to place orders would have
order times of 12:30, the next 6 12:31, and so on. The last customer to place an order for 12:30 would be
rescheduled to 12:46, and of course may then not place the order. The alternative to order smoothing
is that the customer would be subjected to a queuing time of 16 minutes. In a worst case scenario, the customer
may have a rescheduled time which falls outside the opening hours of the Unit, and will then have the order
rejected (no menus will be available).
Future Developments
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.
Further Detailed Information
If further detail is required, the system help files may be found at Main Help Document