Command code table

Below we present the possible values ​​for the parameter Comando and the action that the application should perform upon receiving it. It is important that the commercial automation handles all commands in this table.

Command	Description
0	It is returning a value to, if desired, be stored by the automation
1	Message for operator display
2	Message for the customer display
3	Message for both displays
4	Text that should be used as title in the menu presentation (see command 21)
11	You must remove the message displayed on the operator display (command 1)
12	You must remove the message displayed on the customer's display (command 2)
13	Must remove message displayed on operator and customer displays (command 3)
14	You must clear the text used as title in the menu presentation (command 4)
15	Header to be displayed by the application. Refers to the display of additional information that some transactions need to show on the screen.
	An example is the Bank Correspondent Loan transaction, which at a certain point requires information to be shown to the customer detailing the loan being contracted (such as Installment amount, due date, etc.).
16	You must remove the header presented by command 15.
20	You must present the text in Buffer, and obtain a YES/NO answer.
	In the return, the first character present in Buffer must contain 0 if confirmed and 1 if cancelled.
21	It should present a menu of options and allow the user to select one of them.
	In the call, the Buffer parameter contains options in the format 1:text;2:text;...i:Text;...
	The application routine must present the options in the way it wishes (it is not necessary to include the indices 1,2, ...).
	After the selection made by the user, return the index i chosen by the operator in Buffer (in ASCII)
22	You must display the message in Buffer, and wait for a key from the operator. It is used when you want the operator to be notified of a message displayed on the screen.
23	This command indicates that the routine is asking the application whether it wants to interrupt the data collection process or not. This code occurs when CliSiTef is accessing some peripheral and allows the automation to interrupt this access (for example: waiting for a card to be passed through the reader or for the customer to enter a password)
	Note: It is important that the “Commercial Automation Application” does not place “delays” when handling this command. At this point, some device (pinpad, barcode reader...) is carrying out some processing (reading card/barcode, collecting password) and a “delay” causes delays in accessing data from the device, which may not be more available, resulting in data loss and communication errors.
29	Analogous to command 30, however, a field must be collected that does not require intervention from the cashier, that is, it does not need to be typed/shown on the screen, but rather passed directly to the library by automation.
	An example is the payment methods that some transactions require to identify which type of payment is being used.
	The value to be collected refers to the field indicated in FieldType, whose size is between Minimum Size and Maximum Size. The field must be returned in Buffer.
30	A field whose size is between Minimum Size and Maximum Size must be read. The read field must be returned in Buffer.
31	The number of a check must be read. Collection can be done by reading the CMC-7, typing the CMC-7 or typing the first line of the check.
	On return, it must be returned in Buffer:
	“0:”(typing the first line of the check),
	“1:”(CMC-7 reading) or
	“2:”(CMC-7 Typing),
	followed by the number collected manually or by reading/typing the CMC-7, respectively.
	When the first line of the check is collected manually, the format is as follows: Clearing (3), Bank (3), Agency (4), C1 (1), Current Account (10), C2 (1), Account Number Check (6) and C3 (1), in that order. Note that these fields are those at the top of a check and in the order presented.
	We suggest that an interface be presented during the collection that allows the operator to identify and properly enter this information so that the query is not made with incorrect data, returning a check with problems as good.
34	A monetary field must be read, that is, it accepts the cent delimiter and returned in the Buffer parameter.
35	A bar code must be read or collected manually.
	The Buffer return must contain “0:” or “1:” followed by the barcode collected manually or by the reader, respectively.
	It is up to the application to decide whether the collection will be manual or through a reader. If manual collection is required, it is recommended to follow the procedure described in the ValidaCampoCodigoEmBarras[1] routine in order to treat a bar code in the most generic way possible, leaving the automation application independent of future changes that may arise in the bar formats.
	When returning from Buffer, “2:” can also be passed, indicating that the collection was canceled, but the flow will not be interrupted, so in the case of multiple payments, all documents previously collected will be maintained and the flow will be resumed, allowing making such payments.
41	Analogous to Command 30, but the field must be collected in a masked way.
42	Menu identified. It should present a menu of options and allow the user to select one of them.
	In the call, the Buffer parameter contains options in the format class
	The application routine must present the options in the way it wishes (it is not necessary to include the indexes 1,2, ..., nor field codes, type and class) and after the selection made by the user, return in Buffer the index i chosen by the operator (in ASCII).
	The option code is the identification (Table of payment method codes, settings and menus) of the option field, it can be used to identify the chosen option.
	Within each “class” there is coding of “types”, and each pair (class, type) indicates the nature of the option. Initially, only identification for payment methods was implemented. The idea is to add codes that identify menu options to enable the POS to identify these options without the operator's assistance.
	·       Classes:
	o   0: Class not defined
	o   1: Payment method, types below:
	§  1: Money
	§  2: Check
	§  3: Debit
	§  4: Credit
	§  5: Loot
	§  6: Another way
	The other menus are not identified. Unidentified menus receive a zero value in these fields, indicating that there has not yet been a need to classify them.
	Option classes are intended to define a context for which the code that identifies the type of option is determined. Thus, an option in the menu is always identified based on the option type and option class pair.
	This command is used when the additional parameter ItemMenuIdentificado is used (Enabling special configurations). In this case, command 21 (menu collection) will be replaced in most cases, and the application must be prepared to handle both commands when this parameter is enabled.