A transactional form consists of a header table (apps_wms_formath) and up to N fields (apps_wms_formatl) grouped together (apps_wms_formatg). In addition, a form can use buttons (apps_wms_formatg_buttons) to perform actions.
When a form is executed, the system prompts each input field on the form one by one. Each field has a type, belongs to a group, can have validation conditions, viewing conditions, and can launch a process, among other options.
Once the system reaches the end of the form, it can perform a programmed action. Actions are defined in the Actions (form_action) field. Some possible options include Insert Fields into Table, Launch Process, Execute a List, etc. The full set of possible actions is described below.
If the Exit field is checked after performing the action, the system will exit the form and return to the menu. Otherwise, the form will restart with the cursor located at the first field of the last group. Fields from previous groups will keep their values, whereas the rest will be reset to their defaults.
This behavior is highly useful for inserting master-child data while using a single form. Indeed, the first groups can be mapped to the master table, and the last group can be used to insert N registers into the child by repeatedly looping the form over the last group.
The system can also launch processes when a form is interrupted before reaching its end. This allows us to undo any possible change that may have been performed after modifying a field.
|Name and description||Description of the form (shown as a title)
|Classification||Classification code for forms. This code is used to group forms and perform productivity analysis.|
|Exit||When active, the form will exit once all fields have been filled in. Otherwise, the form will restart and loop through the last group.
|Hide groups||Do not show groups after execution
The Action field determines whether the system must execute an event when ending a loop of the form.
The code of an apps_wms_formath form, used to preset environment variables. The Settings Form is launched before the execution of other forms, and each of its fields is stored in memory and can be referenced form this form.
The form referenced in this field must be SETTINGS type.
|Confirmation||Request confirmation before executing the action
When indicated, the system will prompt for confirmation before executing the defined Action, showing the string defined in this field.
When layout is set as Vertical, the label will be located above the input field. If not, it will be located to the left of the field, as long as the device is wide enough.
|Error message||Error message|
|Table||Name of the table on which an action is performed|
|Where condition (UPDATE / DELETE)||Where condition (UPDATE / DELETE)|
|Statements||SQL statement to execute processes once all form fields have been filled in
|SQL statement||SQL COUNT Statement that will be used to display a counter in the menu.|
|Interrupt||Execute or cancel statement when a form interrupts
|Created by||User who created the form
|Date created||Date form was downloaded
|Updated by||Last user to modify the form
|Date updated||Date of most recent form modification
|BUT_COPIAR||Copy||Copy the current form to new form|
This button will check the consistency of the form.
Some validations like:
2 Form Groups
Form groups are freely-defined sets of fields. A form may contain several groups. By default, the program iterates the last group when it reaches the end.
|Group code||Group code|
|Description||Description of group code|
2.1 Group Example
The program always iterates the last group.
3 Form Fields
This object stores the definitions of a form's fields. When a form is executed, the system prompts its fields one by one, according to the column order (col_seqno). No two fields in a form can have the same field code (col_name).