MCR algorithms ensure that the signals from different input devices are processed. The device's driver sends the data on the device's signal (DeviceSignal), the device's identifier (DeviceIdent), and the received input data line. DeviceIdent is set in the Device Identifier driver parameter. There are five types of DeviceSignal: sgMagCard(Magnetic Card), sgBarCode(Barcode), sgDallas(Dallas), sgKBDInterface(Keyboard), sgNoTouch(No Touch). A set of MCR algorithms, that recognize this signal, is formed as a result of the signal processing. At the same time, each of these algorithms singles out a parameter — the information to be processed further — from the whole scope of received information. The parameter's meaning depends on the area. The method for extracting the parameter from the original information depends on the algorithm type.
There are several algorithm types that are distinguished by the data processing method. Not all of them use all the information provided by the driver, for example, only the input line can be analyzed. There is a form used for checking the MCR algorithm operation which sets the input actions and displays their results (a list of applied algorithms and issued parameters and objects).
The following properties are set for all MCR algorithms:
- Algorithm Type
- Device Type — the type of devices, the signals from which will be processed using this algorithm
- Area — a method for further processing the MCR algorithm or object type.
The object is filled in for all areas except employee, access card, menu item barcode, and menu item code. The selected object will be sent to the cash station after processing the input device signal.
Fill Edit By Parameter — the field is visible only with the object field.! For processing many objects the entry field in the order edit form is used. For example, when processing a menu item, the quantity is expected to be specified in the entry field. If this property is ticked, then the parameter, received at the time of processing the MCR algorithms, will be processed as if this information has been entered into the entry field. For example, 1234 is written on a magnetic strip; there is a MCR algorithm in the form of a prefix with the 123 prefix, with a Menu Item area, and a ticked Fill Edit By Parameter box. When swiping the card the parameter will be designated as 4 (as a result of cutting off the 123 prefix). As a result, four portions of the dish will be added.
The area is a method for further processing the MCR algorithm or object type. Processing methods without an object specified are Employee, Access Card, Menu Item Barcode, and Menu Item Code. In other cases, the object is specified directly in the MCR algorithm.
Employee means registering an employee in the system (including for confirming an operation). The parameter received after processing the MCR algorithm is compared to the Card Code employee property (see the Account property) and the matching employee is found.
Access Card means processing the card at the time of entry.
Menu Item Barcode means searching for a dish using the barcode and adding it to the order. The parameter received after processing the MCR algorithm is compared to the Barcodes menu item attributes and a match is found. The barcode can also include the information about the weight which should also be added to the parameter divided by a semicolon. There is an example of the MCR algorithm for processing dishes sold by weight in a standard delivery.
Menu Item Code means searching for the dish using the code and adding it to the order. The parameter received after processing the MCR algorithm is compared to the Code menu item attribute and a match is found.
Currency, Menu Item, Order Type, and Discount: the respective object is specified for these areas. As a rule, when processing such MCR algorithms, the parameter is not important, but it can be used as the entry field information. See Fill Edit By Parameter.
Interface: for this area's MCR algorithms it is particularly important to correctly specify the parameter, as it is the parameter that will be processed by the interface for connecting to other systems.
MCR Algorithm Types
DLL version 7.0
DLL (library) whose name is set in the DLL Name field is responsible for processing the input data.
The following is the function's prototype:
Device: byte; // Device Type
DeviceID: word; // Device ID
const Src: pChar; // Input Data Indicator (received line)
ResBuffer: pchar // Indicator of buffer for placing processed parameter line
): integer; stdcall;
If the input data is of the right kind, the function will return a number between 0 and 255. In this case this number is the length of the ResBuffer result. Numbers outside the 0...255 range indicate that the data does not fit into the algorithm.
The algorithm checks if the input data starts with the sequence set in the Prefix field. The remaining part is transmitted as a parameter. For example, the 32167 input data will be correct for the 321 prefix, and the resulting parameter will be 67.
The processing is based on the mask set in the Input Mask field. The processing rules are as follows: symbols 0123456789+-/=,A..Z are obligatory for the positions they are located in. a..f are for text, i..n — numeral parts of the recognized text for the parameter, r — restaurant code, ? — ignored (necessary to control the length), symbols after * are not taken into account. For example, for the ?bbb=jjj=aaa/iii* mask and Q456=000=123/789SOMEINFO data the mask will work and the resulting parameter will be 123;456;789;000.
To process items sold by weight, an algorithm processing by mask and the Menu Item Barcode (or Menu Item Code) object type should be added. There is a preset item that you can edit. For example, the 280aaaabbbbb? data format means that the numbers 280 are control numbers, and that any symbol can replace the ? symbol — this symbol has been inserted to control the length. Such an algorithm is a part of the standard delivery. Let's take a look at the following input line:
According to the mask, the expression means the following:
___019801500 Parameter = 0198;01500
0198 Dish Barcode (or Code if the object type is Menu Item Code)
01500 Dish Weight. The dish weight will be divided into the value stated in the BarcodeDivisor parameter (Items Sold By Weight parameter group).
Therefore, if the Menu Item Code or Menu Item Barcode object type is selected, the parameter contains an identity code (barcode) and the dish weight if necessary. If the barcode is for an item sold by weight, the Quantity Coefficient property is ignored.
If there are no identifiers in the input line, that should be transmitted to the parameter, then if the input line matches the mask, the entire input line is transmitted, for example:
Mask: 992=?A??, input: 992=BAYZ. As the input matches the mask, the parameter is 992=BAYZ.
An interface is responsible for sorting the incoming data. An interface (except internal interfaces) is a DLL meeting certain specifications. Using an interface only to process input devices is unfeasible. If you have an interface used with a system provided by a third party, and you would like the possibility of processing input devices included in it, make a request to the developers.
Script Version 7.0
Enables making a script for processing within the program's interface, so there is no need for compiling own DLL. The processing is based on Innerfuse Pascal Script. The syntax is identical to that of Pascal, but the number of functions is limited and will be listed below. The agent supports the following:
1. Standard types: Byte, Shortint, Char, Word, SmallInt, Cardinal, Longint, Integer, String, Real, Double, Single, Extended, Comp, Boolean, Array, Record, Variant
2. Variables, constants
3. Standard expressions: Begin/End, If/Then/Else, For/To/Downto/Do, Case x Of, Repeat/Until, While, With, Uses, Try/Except/Finally Exit, Continue, Break
4. Functions, procedures, parameters Array of Const, Var.
Each script has a heading of the following type:
DeviceSignal: Integer; // Device Signal sgXXXX
DeviceIdent: Integer; // Device Identifier
var Parameter: String // At input — all information, at output — parameter
If TRUE, the script is considered to have worked correctly, and the parameter is taken from the Parameter variable.
The list of supported functions is given in the RK7Scripts.doc file.
Functions can also be called from DLL. To do so it is necessary to create a MCR algorithm of the Script ver.7.0 type and a Script Header area. Such algorithms are not recognition algorithms and are used to set headers for other algorithms. In this case, the Device Type property indicates that this header will be added only to the script of the algorithms, supporting at least one device type from the list supported by the algorithm with the Script Header area. In the script field of such an algorithm, it is necessary to specify the external function declaration in the following way :
function MessageBox(hWnd: Longint; lpText, lpCaption: PChar; uType: Longint): Longint; external 'MessageBoxA@user32.dll stdcall';
In this example:
MessageBox is the Function Name for calling from the external script. It indicates that the function is external
MessageBoxA is the Function Name in DLL
user32.dll is the DLL Name
Stdcall means call's specification.
Now the function can be called from the algorithm script:
MessageBox(0, ‘Some Text’, ‘Some Caption’, 0);