Most of the screens used in the entry of movements in the ADONIX software packages can be set up by the user, by means of transactions. These transactions are used to define, among all the available standard fields, which fields will appear on the user's screen. This transaction generation is achieved by duplication then by modification of template screens.

Similarly, some setup functions result in the generation of code from setup elements (for example, this is the case for statistics, the variables associated with the setups).

This code generation is normally carried out during each setup operation, but it can happen that when a screen template has been modified, the regeneration of the code is necessary for all the transactions of a given type. This function is used to trigger this regeneration.

It should be noted that the transactions are from now on defined in a dedicated dictionary.

Screen management

Entry screen

On launching the function, a first screen, listing the modules, is used (by responding Yes) to globally define the required revalidations.

Block number 1

Folder (field APPLI)

Define the folder code, as it is defined in the folders table, in which the work will be carried out.
Deferred validation (field VALDIF)

This option disables the direct validation of windows and screens to optimize these objects' validation times.

If this check box is selected, the windows and screens are validated at their first use.

Grid Installed modules

Module (field MODULE)
Validation (field SELMOD)

Used to select or deselect the current line.

Grid Transactions

Code (field COD)
Validation (field SEL)

Used to select or deselect the current line.

Tab Transaction entry screen

Once the first screen is confirmed, the system displays the detail of the elements that can be revalidated in a second screen. It is then possible to define which specific elements must be revalidated. This revalidation is made for all the languages in the folder. According to the number of transactions to be revalidated and the number of languages, this phase can be long ; it is therefore recommended to be restrictive in selecting the elements to be revalidated.

There are two transaction types: Supervisor transactions and transactions linked to the various applications written in adonix technology.

Block number 1

Folder (field APPLI)

Define the folder code, as it is defined in the folders table, in which the work will be carried out.
Deferred validation (field VALDIF)

This option disables the direct validation of windows and screens to optimize these objects' validation times.

If this check box is selected, the windows and screens are validated at their first use.

Grid Installed modules

Module (field MODULE)
Validation (field SELMOD)

Used to select or deselect the current line.

Grid Transactions

Code (field COD)
Validation (field SEL)

Used to select or deselect the current line.

Supervisor transactions

The following Supervisor transactions can be re-validated:

Code

Definition of the specific code and screens

ACN

The code linked to the inquiries defined in development.

AMI

The code linked to the set up system transactions .

APCY

The tables by company. This does not concern all adonix software but only those which data key parts can be set up by company. The table structure is then generated again and the tables are revalidated if needed.

AWA

The code linked to the execution of Workflow rules.

AWW

Screens and windows of the Workflow Workbenches.

GLOBTYP

The code generated in order to define the variables associated with the data types (notably the variables named GLONXXX, which define the length of the alphanumeric code of type XXX).

GTC

The inquiry screens from their setups.

RQT

The code and the screens generated from the requester setups.

STAT

The code generated when setting up the statistics in order to perform the requested totals.

See the annex documentation for the detail on which application transactions can be revalidated.

Yes to all the rest

When faced with an entry grid with multiple choices and a Yes/No answer on each line, this function makes it possible to answer Yes to all the lines starting from the current line.
No to all the rest

When faced with an entry grid with multiple choices and a Yes/No answer on each line, this function makes it possible to answer No to all the lines starting from the current line.
Yes to all the rest
No to all the rest

Batch task

This function can be run in batch mode. The standard task GENMSKTRT is provided for that purpose.

Error messages

The only error messages are the generic ones.

Tables used

SEEREFERTTO Refer to documentation Implementation