This function is used to define a database of setups used by the software. Each setup is identified by its name; it is attached to a functional module, and within each module it is classified by group. It has characteristics such as the type, the definition level and the possible values. It is possible to associate it with a global variable; this makes it possible for the Supervisor to load this global variable via the setup value upon connection to the folder or a user change.

In the case of a context change (company, site), or when no variable is associated with the setup, the value of the setup can be read in any program via one of the following calls:

Call PARAM(SITE,PARAM,VALEUR) From ADOVAL

Call PARAMUTIL(PARAM,VALEUR,USER,"") From SUBAUS

It is important to note that the corresponding sub-programmed uses a data type that is always of the character string type; when the source setup is of the type date or numeric, remember to transcode the returned value if necessary. When it is a date, a simple assignment is sufficient: in fact the Safe X3 engine manages the assignment of the date type variable with a value of the character string type. In the numeric case, it is necessary to write VALNUM=val(VALUE).

Prerequisites

SEEREFERTTO Refer to documentation Implementation

Screen management

Entry screen

The entry of the setups is made in a tab, the selection window being a window with keys made up of 3 sections (the chapter, the group, and then the setup code).

It is possible to add new setups in the case of specific/custom developments. Warning, to save these setups in the case of version change or folder revalidation, it is essential to protect them with a specific/custom activity code (starting with X, Y or Z). To avoid conflicts with any added setups, it is necessary to use the standard naming convention (start the names of these setups with X, Y or Z).

It is possible to add these specific setups to the existing standard chapters or to a specific chapter created beforehand. In order to add a specific chapter it is necessary to add a code starting with X, Y or Z in the miscellaneous table no. 901.

The different setups that exist for all the functional modules are explained in the Prerequisite chapters in the documentation for the functions that use them. Each setup has a descriptive record that can be called by the definition of the setup or the entry of the setup value.

Block number 1

Chapter (field CHAPITRE)

The chapter, defined in miscellaneous table number 901, identifies the functional domain to which the parameter is attached.
Parameter (field PARAM)

A parameter is characterised by :

  • A chapter (miscellaneous table no 901).
  • A code (10 alphanumeric).
Description (field NAME)

Enter the description of the relevant record.

This long description is used as a title in screens and reports.

Block number 2

Group (field GRPPAR)

The group code, defined by miscellaneous table number 903, is used to group the parameters of a single chapter, in order to organize them and to facilitate their parameterization. In fact, there is the possibility to define the values sets by group of parameters.

Characteristics

Definition level (field NIVDEF)

The definition level is used to characterized the deepest level of detail possible to associate a value for each parameter. If, in a given context, no value exists at the defined level, ascend up successive levels until a value is found. It is therefore possible to define a default value for the levels above the bottom level of the definition, in order to only manage the specific cases of the lowest level.

The definition levels possible, defined by the local menu 987, are, in descending order :

  • Folder : a single global value is then defined for all the folder.
  • Legislation : a value is defined by legislation. This supposes that in the parameter usage context, a current legislation can be defined (it is carried out in practice by means of the current company in the usage context).
  • Company : a value is defined by company. This supposes that in the parameter usage context, a current company can be defined.
  • Site: a value is defined by site. This supposes that in the parameter usage context, a site can be defined.
  • User : a value for each user (and defined at the time of the connection, remembering that if it does not exist, a search is mad for the value associated by default with the user for the module to which the parameter is attached).
Value type (field TYPVAL)

Defined here is the internal type for the value and the local menu number if there is one.
Activity code (field CODACT)

An activity code is used to:

  • Make an element optional in the dictionary if the value associated with the activity code is null
  • Identify the specific/custom elements if they are marked with a code starting with X, Y, or Z
  • Size a maximum number of lines when the activity code marks elements from a grid

If the activity code is disabled:

  • The marked element will not be useable
  • The associated code will not be generated nor activated
Local menu no. (field NOLIB)

Defined here is the internal type for the value and the local menu number if there is one.
Object (field OBJET)

A parameter can be the key to a record managed by an OBJect (for example, a country code, a customer code, a sequence number counter, a product group, a user, etc.). If this is the case, a code for the object is given here ; this is used to automatically make available all the controls associated with the entry of the parameter.

In addition, it is possible to specify the parameter to be passed to the object management, when this is manages a table with a key of two components. The parameter CCEDSP1 "Dimension axis 1 for distribution" uses this field to indicate the number of the analytical axis.

In addition, it is possible to specify one or more selection options to filter the possible values for the parameter. These options are defined in the object in the "Selection" tab. The CPTRES parameter uses the filter option on the account OBJect to authorized only the general accounts.
Parameter (field PAROBJ)
Selection options (field SELOPT)
Control processing (field TRAIT)

The process section is used to define the name of a process that will be called to make additional controls on the validity of the entry of the parameters. If this process is defined, then a sub-program must exist defined as follows in the process :

Subprog VERF_PARAM(PARAM,VALEUR,OK)
Value Char PARAM     # Name of the parameter being entered
Value Char VALEUR    # Entered value to be controlled
Variable Integer OK    # 1 if the control is satisfactory, 0 if the entry is incorrect
                                 # If OK=0, enter the variable GMESSAGE with the error message
…
End

An example of its use is given for the sequence number type variables in the documents. When they should not exceed a length of 15 characters, a SUBANM process can be called.
Global variable (field CODVAR)

To facilitate usage, it can be useful to store the parameter value in a global variable. for standard reasons, the name of this variable starts with the letter "G" for the standard, with one of the letters "X", "Y" or "Z" for specific/custom. This variable belongs to the class [V].

The fact of giving the name to a variable provokes the automatic generation of a declaration process :

  • WWAGLOBVAR for folder, company, site or legislation parameter
  • WWAGLOBUSR for user parameter

Thus when connected to the older, the global variable is loaded with the parameter value.

If the variable is defined at a lower level (site, company, legislation), it is likely to change value when the site, company or legislation changes ; it is in this case the responsibility of the developer to re-read the parameter values and to modify the values of the corresponding variables. A sub-programme for each module is available for this, which can be called by :

           Call GLOBVAR(SITE) From WWGLOBXXX

In parameter creation, in the case where the variable is not yet created in the standard dictionary, the supervisor proposes to create it.

In parameter update, the variable is not modifiable. However, there is the possibility to intervene in this field from the variables dictionary :

  • to assign a variable to the parameter, by assigning the parameter code, in the global variable record.
  • to delete a variable associated with the parameter, by deleting the parameter code, in the global variable record.

Note : the deletion of a global variable associated with a parameter is possible. In this case, the parameter is no longer linked to a global variable.

  • to assign a variable to the parameter, by assigning the parameter code, in the global variable record.

Grid List of values

Values (field VALUES)

It is possible to define a list of values that will be proposed during the entry of the parameter with the help of the selection function, accessible from the right click of the mouse.

Properties

Changeable (field MODIF)

Used to define if a value can be manually modified by the user with the function parameter values. If this is not the case, only a program is for modifying ; for example, the TYPDBA parameter, which defines the database used, only reflects that it has been defined during the creation or update of a folder : it can therefore not be manually modified).
Off value (field VALFLG)

When the Off value check box is selected, you can enter values that fall outside the displayed list (considered as "suggested values"). When the check box is cleared, a strict selection applies.
Modify by user (field AUSMODIF)

This indicator, modifiable only if the variable has been defined at the User level, is used to identify if a user can modify the value themselves(via the personal choices management function), or if a user other than the general administrator can modify this parameter in user management.
Folder default value (field VALDEF)

This indicator, only modifiable if the variable has been defined at the User level, is used to identify if an inheritance is authorised from a superior level or if a value is imposed that can only be entered at the user level (in this case, its non assignment in the user record will be interpreted as an absence of the value).
Access code (field ACS)

This access code makes it possible to prohibit access to the current record for some users.

If the field is populated, only users that have this access code with read access rights (and write access rights respectively) can view (or with write access rights, modify) the record.

Condition

Modification condition (field CNDMOD)

Used to enter a formula valuated when entering the setup values.
If the result of the formula is null, the setup cannot be modified.

The definition of the available variables and the setup examples are found in appendix.

Specific Buttons

Copy

This button is used to complete and compile 2 processings: AGLOBVAR and AGLOB+chapter

Copy

This button is used to copy the activity code definition to another folder. Caution: there is no copy of the linked activity code.

Error messages

[<<<
[>>>>MENU_FLOTTANT_DIV]

In addition to the generic error messages, the following messages can appear during the entry :

Parameter exists already

An attempt has been made to create a setup that exists already under the same name in another chapter.

The variable must start with G

The global variables are standardized and must start with the letter G.

Variable exists already

The global variable is already initialized by another setup.

Incorrect value

A value incompatible with the data type has been entered in the values table.

Non-existent processing

The name of a non-existent processing control has been entered.

Tables used

SEEREFERTTO Refer to documentation Implementation

Technical annex: formulas that can be used to lock the entry

The formula entered in this field used to control the modification is very important when it is required to lock the setup values at a given level, even if this setup can still be modified.

This condition is notably interesting for some legislation which limit the possible setups.

At this stage, the following variables are notably available:

  • LEG is the current legislation. This value is empty when entering a setup value at general level. In all other cases, it is assigned, either by entering the setup at legislation level, or by defining it at company level (a company is attached to a legislation) or at site level (a site is attached to a company which is attached to a legislation) or at user level (attached to a default site for the corresponding module).
  • SOC is the current company. This value is empty when entering a setup value at general or legislation level, otherwise it is assigned according to the same principle described above.
  • SIT is the current site. This value is empty when entering a setup value at general, company or legislation level, otherwise it is assigned according to the same principle described above.
  • USR is the user for which the authorizations are to be entered (not the same as GUSER, which is the current user entering the authorizations).

The variable GNBLEG is available. It gives the number of active legislations in the folder. These active legislations are given by the GDOSLEG grid (indexes vary from 1 to GNBLEG).

Here are some examples of conditions which help understand how to lock the setups:

When it is required to enter a setup value, no matter the definition level, if the German legislation is used in this folder, the formula is:
find("GER",GDOSLEG(1..GNBLEG))=0
As a matter of fact, if "GER" is found in the legislation grid, the find function sends a value different from zero, which means that the condition is false and that no entry is possible.

For Italian and Spanish legislations, when it is required that a setup normally defined at the level of each site cannot have different values by site, following formula is to be used:
find(LEG,"ITA","SPA")=0 or SIT=""
If LEG is defined and has the value "ITA" or "SPA", the first part of the condition is false; SIT must then be empty (that is that the current level is company or above) for the setup to be modified.

When it is required that a setup that can be defined at user level can be modified only at general level or only for the administrator, following formula is to be used:
LEG="" or USR=GSUPER
If LEG is empty, the current level is the general one. If USR is defined and has value GSUPER (super-user), the value of the general administrator is to be entered. In both cases, the formula is true and the setup can be entered.

If only the administrator is authorized to modify a user value, following formula is to be used:
GUSER=GSUPER