Associate Record Maintenance and Reporting

Creation, amendment, deletion and enquiry/report facilities for Associates

An Associate Record is part of a mechanism which allows individuals to have cashless accounts available for spending at designated operational units.
The accounts may be comprised of monies paid into the accounts by whatever method and allowances assigned to the accounts according to certain conditions.
There may be restrictions on use of the accounts, such as daily maximums, use of certain designated monies or allowances only on certain recipe types, restriction of the accounts to certain recipe types or proscription of certain recipe types.
The account record provides a link to CATERMAN and other systems, and, whilst it can contain certain data, it should be viewed as a gateway to data rather than a source in itself.

Creation of an Associate Record

An Associate record first of all requires a unique identifying code of up to 15 characters.
This could be a student reference number comprised of school identifier, class, id number, etc.
A name is then requested, which may or may not be the name of the individual to whom the Associate Record refers - it depends on who will be seeing it.
For example, the name could be a job title, a special account, etc. If the Associate Record is to be accessible from outside the LAN, it may be better not to name individuals.
The type of associate is then selected from the proffered list (see Code Maintenance). e.g. Student, Visitor, etc.
A number of information fields may be entered, including:-
The External Access password is used for certain enquiries and for paying money on to the account over the internet. Providing the accessing user is signed-on with a public access password to the appropriate operational unit and correctly enters the Associate id and this password, individual Associate consumption data and financial transactions may be viewed and money paid to the account from credit/debit cards via Paypal or similar.

Alternate Identifiers - up to five (on the standard system) may be entered followed in each case by a description, e.g. "Old Credit Card", "Student Union Card", "National insurance Number", “RFID Tag”, “Telephone Number”, etc.
These are unique identifiers which will bring up the Associate information when input from EPOS etc. Each identifier should be a barcode or magstripe or chipcard or OCR-readable code or RFID tag scanned into the field. Old obsolete credit cards (suitably written on in permanent marker), library tickets, student union cards, bus/transport pass, etc., anything with a unique readable code on it which can be carried by the individual is suitable. Any item with an RFID tag could be used (every RFID tag is unique)(on the standard system High Frequency ISO15693 tags are supported).
Because they already exist, they cost nothing to re-use. Alternatively, a piece of paper or card with a number on it, and a picture of the Associate, may be used.
While these Alternate Identifiers will speed up service at an EPOS or when enrolling for something, they are not absolutely essential. An Associate can be identified by manually keying in the identifier or any alternate identifier or by alphamatching on the associate name.

Units Associated with this Associate Record are chosen from the list, which includes all operational units to which the user password has access. The Associate Record may then be used at all selected units. For example, a password empowered at site level could allow the Associate to use any restaurant, shop or other site facility in any combination. The Unit in which the operator creates the record is entered by default, but may be removed.

A recipe charge band is assigned to the Associate, so that each recipe purchased is correctly priced. For example, a student might pay a different price for a lunch item than a teacher.

Allowances are selected from the proffered list (see Code Maintenance), the amount of the allowance is entered, and start and end dates are given.
The amount of the allowance remaining at time of entry and the period for which it is applicable (daily, weekly, monthly, a period of time) are also entered – it is essential to enter the amount remaining at the time of entry. The allowance will be allocated against purchase of recipes that have an identical type code, e.g. if the allowance is “FSM” then any recipe allowed against it must also have a type code of “FSM”. Allowances are “used up” in the order they appear on the Associate record. If the Associate has allowances for “FSM” and “HE” in that order for example, and a recipe is purchased with type codes “HP”, “HE” and “FSM” in any order, then the allowance for “FSM” will be depleted. In the case where the Associate allowances are in the order “HE” followed by “FSM” then the “HE” allowance would be depleted. Where an Operational Unit has the appropriate setting (see Unit File Maintenance in “Others” on Main Screen) allowance codes starting with “*” are available for all recipes irrespective of recipe type codes, and should therefore always be last in the Associate’s allowance list – for example, “*FSM” appearing last in the list of Associate’s allowances will be used for purchase of any recipe not already allocated against an allowance appearing before it in the list.  

The Associate may then be restricted in which recipes are available by selecting recipe types from a list (see Code Maintenance). The selected recipes are either the only ones available to the associate or are forbidden to the Associate, e.g. "Contains Nuts" could be forbidden.

An Identifier File is then provided for the Associate. Usually this is a passport-type picture of the Associate, which is displayed when the associate is invoked at EPOS for example. The file should be on the local LAN (or server, if running encrypted), and should not be accessible to external users (over the internet, for example). The file name should not contain any special characters.

The Current Account Running Total cannot be entered/amended directly.

The maximum total amount that can be spent in one day may be entered if necessary.

Amendment of an Associate Record

Associate record amendment is similar to creation, except that the Associate Record may be invoked by entering its id, an alternate id, or by alphamatching.

Deletion of an Associate Record

The Associate Record is displayed as for the Display Option below.
The user may then delete the Associate Record if required.
The Associate Record may not be deleted if money remains on it. Only high-level passwords should be allowed this function.

Display of an Associate Record

To display an Associate Record, enter the id, an alternate id, or alphamatch.
The Associate Record will then be displayed in full.
Options are given to list vouchers and /or sales for the Associate if any are present.

Access by Mobile Phone Utilising 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, the user may make enquiries on the account by sending a text message to a designated telephone number. The text of the message must contain the type of request, on the standard system this is "B" for current balance and amounts spent and paid-in today and on recent previous dates, or "D" followed immediately (no space) by a date (ddmmyy or mmddyy depending on password parameter for preferred date format) which returns amounts spent and paid in on that date and previous dates, or "T" followed by a date which will return a text message showing for that date the product-codes/quantities/cost of purchases made and voucher numbers/amounts paid into the account.
For example, "t070707" would show all transactions which took place on the account on 7th. July, 2007.

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), and the Advance Ordering Days setting must be greater than zero to signify that the unit accepts advance orders.
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 to use this facility.
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. CATERMAN assumes that 07/ is next month if the current date is later than the 7th. of the month. 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.
Assuming that the unit Advance Order 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 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 Main CATERMAN Facilities List