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 Application Service
CATERMAN is constructed on a four-tier design, consisting of a user browser GUI (Microsoft Internet Explorer, Firefox, Opera, etc.) 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.
Access to CATERMAN is via a designated URL/webserver either on the internet or (for in-house installations) your LAN, a password and PIN, with each password assigned certain facilities. 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)
(f) Certain third-party access services.
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 bonafide 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).
The user interface via a standard browser may be tailored to each user. Every item of text may be replaced by user-chosen text and/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
Eucater 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 can be 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/$250/€400 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) 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 or sent to the customer's email if required.
A complete history of all transactions on the account is available to empowered passwords.
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. Greenfrog), 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:-
"greenfrog 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).
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