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:
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.
Specify the parameter in the entry field — 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 Parameter in the Field 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. An example of the MCR algorithm for processing dishes sold by weight in a standard delivery.
Menu Item Code – 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 entered 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 in the entry field with the parameter
Interface – for this area's MCR algorithms it is particularly important to correctly define the parameter as it is the parameter that will be processed by the interface for connecting to other systems.
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:
function ( Device: byte; // Device Type DeviceID: word; // Device ID const Src: pChar; // Input Data Indicator (received line) ResBuffer: pchar // An indicator of the buffer for placing the processed parameter line ): integer; stdcall; |
Returned value:
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 makes sure that the input data starts with the sequence set in the Prefix field. The remaining part is transmitted as a parameter. For instance, 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 Processing Mask field. The processing rules are as follows: symbols 0123456789+-/=,A..Z are obligatory for the positions they are located in, a..f – text, i..n – numeral parts of the recognized text for the parameter, r – restaurant code, ? – ignored (taken into account for the duration), symbols after * are not taken into account. For instance, 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 which processes 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 instance, the
280aaaabbbbb?
data format means that the numbers 280 are control numbers, and that any symbol can replace the ? symbol – the symbol has been inserted to control the length. Such an algorithm is part of the standard delivery. Let's take a look at the following input line:
280aaaabbbbb?
According to the mask, the expression can be broken up as:
___019801500 Parameter = 0198;01500
0198 Dish Barcode (or Core 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 to process input devices only 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, make a request to the developers.
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:
function ( DeviceSignal: Integer; // Device Signal sgXXXX DeviceIdent: Integer; // Device Identifier, see Device identifier var Parameter: String // At input– all information, at output – parameter ): Boolean; |
Returned value:
If TRUE then 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 requested 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. You need to announce the external function in the following way in the script field of such an algorithm:
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 points to the call's specification.
You can now call the function from the algorithm script:
MessageBox(0, ‘Some Text’, ‘Some Caption’, 0); |