Setup Definitions
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
Refer to documentation Implementation
Screen management
Entry screen
Presentation
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.
Close
Fields
The following fields are present on this tab :
Block number 1
| The chapter, defined in miscellaneous table number 901, identifies the functional domain to which the parameter is attached. |
| A parameter is characterised by :
|
| Enter the description of the relevant record. This long description is used as a title in screens and reports. |
Block number 2
| 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
| 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 :
|
| Defined here is the internal type for the value and the local menu number if there is one. |
| An activity code is used to:
If the activity code is disabled:
|
| Defined here is the internal type for the value and the local menu number if there is one. |
| 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. |
|
|
|
|
| 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) 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. |
| 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 :
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 :
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.
|
Grid List of 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
| 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). |
| 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. |
| 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. |
| 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). |
| 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
| Used to enter a formula valuated when entering the setup values. The definition of the available variables and the setup examples are found in appendix. |
Close
Specific Buttons
This button is used to complete and compile 2 processings: AGLOBVAR and AGLOB+chapter |
This button is used to copy the activity code definition to another folder. Caution: there is no copy of the linked activity code. |
Menu Bar
Documentation / Paragraphs
This menu item allows access to the documentation management on the first paragraph of the documentation (if there is one) associated with the current record.
Documentation / Links
This menu item allows access to link management. It is used to define the links between the current record and other records (for example, the links between functions and parameters). These links are specific to the documentation and are used to load the generation of documentation structures.
Documentation / Generation
This menu item launches a documentation generation. You can also launch it from the Generation button at the bottom of the screen.
You can launch three types of generation one by one or simultaneously
- The generation of the documentation structure from the dictionary (ADOCUMENT, ADOCBLB, and ADOCCLB tables)
- The generation of the documentation from the previous tables
- The generation of the field documentation
The range suggested by default takes into account the current record, but you can modify it at launch time.
Error messages
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.
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