Folders

• Folder (field DOSSIER)

The name of the folder can take a maximum of 10 alphanumeric characters. The first letter must be alphanumeric.

• Name (field NOMDOS)

Destined notably to figure in the reports and the screens in which the record code can be entered or selected. This text is used to give a clear description to the record concerned.

• Database type (field TYPDBA)

Define the database used to create the folder. This database can be SQL SERVER or ORACLE. As a function of the license that is used, this choice may be possible or imposed.

• Volume (field VOLUME)

This "adonix" volume number corresponds to the directory from which the physical files (outside of the database) describing the objects in the folders are located on the process server. The adonix volumes are defined in the "adxvolumes" file in the installation directory (contained in the environment variable ADXDIR). BY default the volume is A, but others may have been defined during the installation of the software.

It is possible to select the volume using the key.

See the technical appendix volumes at the end of the folder management documentation.

• Database size (field SIZDAT)

These values are used to size the data files and the index in the database. The size is expressed in Mega-bytes.

These values are only interesting from the point of view of folder creation, and they are generally entered at the end of the definition of the folder parameters, just before the actual folder creation. In fact, to have available a correct estimate for the value, it is important to have previously sized the database tables by means of the sizing values ( Tables tab), and to have more importantly defined the table structure of the database by means of the activity codes (Options, Screens, Specifics).

• Index size (field SIZIDX)

• Format (field CODDBA)

Defines the character set used to store the character fields in the database (this can take the values ASCIIor UNICODE) :

• The ASCII format corresponds to the management of the European languages : each character is stored in a byte, the accented characters being store in values greater than 128.
• The UNICODE format is only of use when wanting to manage the languages where the character set requires more than 256 combinations. This is the case for Chinese, for example.

The X3 client is natively UNICODE and as a result can managed this type of text. It remains a user choice, at the level of the database, between using the UCS2 or UTF8 formats :

• The format UCS2 is a format originating with Microsoft(TM), in which all characters are stored in two bytes ; the normal ASCII characters have the same code (but one of the two bytes is coded with a blank). It is the only format of the UNICODE type supported by SQL server.
• On the other hand Oracle accepts other formats, and in particular the UTF8 format, which is the most common. It is a format in which the characters are stored in a variable number of bytes ( from 1 to 5 according to the case : the ASCII characters are stored in one byte, the accented characters use two, and above that are found the Asiatic languages). It should be noted that Oracle supports other coding standards (UCS3, UCS4, UTF16...) and these standards can be used (on the condition that they are created manually in the database).

Internally and independent of the database format (for its temporary variables), the Adonix execution engine uses the format UTF8 (the sources of the processes are coded in UTF8),and the Windows client uses the standard UCS2.

• File group (field GRPFIL)

This question is asked in the case of a SQL database server is used to define if separate files are created or not to store the indexes and the data (for the important databases this is the normal case).

• Reference folder (field DOSREF)

The "reference " folder must be an existing folder, where the data dictionary will be used during the intialization of the folder. A link is made between a folder and the reference folder. Thus, by default, if a resource (process, table, report) is not found in the current folder, it is looked for in the reference folder, by an inheritance mechanism.

This value is taken by default in the copy folder, the folder from which, during the creation of the folder, it is possible to copy certain data (parameters, accounting plan...) as well as indicated in the Init tab.

• Copy folder (field DOSCOP)

The copy folder, which must have been created previously, is the folder from which the data defined by the Init tab will be copied. This folder can be the reference folder, but equally another folder with an identical structure (for example, a parameterization folder in which the parameterization has been refined during the analysis phase, in which certain data can be introduced or recovered by import). It is important that the structure of the copy folder is identical (even if no control can be made, errors could be produced during the copy if this is not the case).

• Purge folder (field DOSHIS)

This folder cannot be entered directly in the management of the folder. It is entered when an archiving folder is created after the creation of the live folder, by the corresponding function.

The archiving folder is used to store the data considered as not changing, so that they can be consulted off-line.

• Start date (field STRDAT)

This date is used to define the date of the first financial year for a newly created folder.

This date is fundamental, because it cannot be changes at a later date. It corresponds to the start date of the first financial year from which the enterprise data will be managed with the software. Warning, it is advisable (for balances) to start from the previous financial year to the one that the installation will actually start with.

By default, the value of two supervisor parameters STRDAT and ENDDAT, which define the possible connection period, will be defined by :

• STRDAT = Entry date
• ENDDAT = max(STRDAT+ 12 months, Current date)

These parameters, which can be modified later, are used on the connection to the folder. It is controlled so that the entry date is contained between the dates defined by these 2 parameters.

• Folder currency (field RPTCUR)

Makes it possible to update the parameter SYSCUR in the folder. This parameter cannot be further modified by the folder management after the generation of the folder.

• Test folder (field TSTFLG)

The Test folder signifies that this folder is designed to receive a copy of the standard processes present in a patch, if this must be installed in the folder. If this flag is not set, the patch processes will only be integrated at the supervisor folder level. The fact of having this flag set makes it possible to carryout integration tests for patches in a folder. Once the patches in question have been fully integrated in this environment, it is advisable to "clean up" by deleting previously installed processes (if not, the next patch or version installation will not be taken into account by these processes, which risks the appearance of malfunctioning). A production folder must not have this flag set.

• Specific folder (field SPEFLG)

This check box signifies that the specific/custom processes present in a patch will be installed in the folder even if they did not previously exist. The specific processes are identified by their name : They start either by X, Y or Z, or else by SPE, else they start with CNS and finish with SPE. If this flag is not set, only the previously existing specific/custom processes will be replaced in the folder by the new version present in the patch.

• Title (field LIBMOD)

• Active (field MODULE)

This grid contains the modules retained for the folder to be generated. Only the functions and the tables associated with the activated modules will be usable in the folder once it has been created.

It is recommended to only enter the modules that are actually useful. In effect, this makes it possible to create only the tables and objects actually used and keep to a minimum the creation time and disk space taken. It is always possible to add modules at a later date. The list of modules and any constraints are given in an appendix at the end of the documentation describing the management of the folder.

• Image size (field BLBLNG)

This field determines the maximum size taken by default in the blob files (binary large objects) stored in the database. These fields correspond notably to the images stored in the database.

This field is defined as having the power 2 : 1 equivalent to 2 Kb, 2 to 4 Kb, 3 to 8 Kb and so on (the corresponding value is displayed up to 20, which corresponds to 1Gb).

It should be noted that each field of the type blob can be sized differently in the database (if the database type carries an explicit length, this default length is not used).

• field BLBTXT

• Text size (field CLBLNG)

This field determines the maximum size by default in the clob fields (character large objects) stored in the database. These fields corresponds notably to the texts stored in the database.

This field is defined to the power 2 : 1 equivalent to 2 Kb, 2 to 4 Kb, 3 to 8 Kb etc (the corresponding value is displayed, it can go up to 20, which corresponds to 1 Gb).

It should be noted that each field of the type clob can be sized differently in the database (if the data type carries the length explicitly, this default length is not used).

• field CLBTXT

• Code (field CODACT1)

An activity code is used to:

• make optional an element 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.

In this way, if the activity code is disabled, the marked element will not be useable, and the associated code (if any) will neither be generated nor can be activated.

• Title (field LIBACT1)

Title associated to the previous code.

• Module (field MODULE1)

Module to which the activity code is attached. If the module is not active, the activity code will not appear in this grid.

• Active (field FLACT1)

The fact of setting this field to Yes activates the tables, screens or the fields in the tables and the screens that belong to the option. Conversely, if the field is set to No, the screens, and the tables, or the fields that belong to it are no longer accessible and disappear.

• Code (field CODACT2)

An activity code is used to:

• make optional an element 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.

In this way, if the activity code is disabled, the marked element will not be useable, and the associated code (if any) will neither be generated nor can be activated.

• Title (field LIBACT2)

Title associated to the previous code.

• Module (field MODULE2)

Module to which the activity code is attached. If the module is not active, the activity code will not appear in this grid.

• Active (field FLACT2)

The fact of setting this field to Yes activates the tables, screens or the fields in the tables and the screens that belong to the option. Conversely, if the field is set to No, the screens, and the tables, or the fields that belong to it are no longer accessible and disappear.

• Code (field CODACT3)

An activity code is used to:

• make optional an element 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.

In this way, if the activity code is disabled, the marked element will not be useable, and the associated code (if any) will neither be generated nor can be activated.

• Title (field LIBACT3)

Title associated to the previous code.

• Module (field MODULE3)

Module to which the activity code is attached. If the module is not active, the activity code will not appear in this grid.

• Screen dim. (field DIME3)

Define the number of occurrences used in the screens and also in the tables involved, remembering that for a table, a minimum number (and a maximum number) can exist, all of which will lead to the use of the following formula to size the tables

min(max(MIN,SCREEN),MAX).

• Min extension (field DIMIN3)

Define the minimum number of columns stored in the database (independently of the number displayed in the screen, which can be lower). This is used to avoid the standard reports making reference to columns not likely to exist according to the parameterization.

• Max extension? (field DIMAX3)

Define the maximum possible dimension taken into account in the table structures in the database.

• Code (field DIMCOD)

The sizing elements are used in the sizing formulas calculations to estimate the number of lines planned for each table and from this are used to calculate the planned size of the tables.

• Title (field ZDIMCOD)

Title associated to the previous code.

• Module (field MODULE5)

Module belonging to the setup. This field is used to specify whether the screen has to be created in the folder database. It is specified when the module linked to the screen is active in the folder.

• Value (field NBR)

This number corresponds to the value associated with the sizing element of the line.

• Module (field MODTR)

Module belonging to the setup. This field is used to specify whether the screen has to be created in the folder database. It is specified when the module linked to the screen is active in the folder.

• Y/N (field TRVAL)

A positive response to the question leads to the validation of the transactions associated with the module.

• Languages (field LAN)

Grid used to enter the languages that may be used in a connection to the folder. The validation of the folder causes the entry screen generation in all these languages : this operation consumes a lot of system resources.

• Translation ref (field LANREF)

This check box can only be checked if the following two connections are met :

• the language is a language not shipped as standard by the editor.
• this language is not already checked for another folder in the current environment (also known as the solution).

It is used to specify that the current folder is the reference folder for the translation of the language in question, that is to say it is the folder that carries the most up to date translations for the language concerned.

By default for the languages shipped as standard, it is of course the root directory, which is explain that the box can no longer be checked in a standard folder; but for the "non standard" languages the user is free to define a translation reference folder.

A control verifies the uniqueness of the translation reference folder for a language, in order to change it, it is first necessary to un-check the folder previously set as the reference.

If for a language, there is no reference folder is checked, it is selected in the following order :

• the root folder (if the language concerned is defined in it)
• the first folder (in alphabetical order) that contains this language.

• Legislation (field DOSLEG)

• Copy options (field LIBCOP)

Each group corresponds to a coherent group of tables in the copy folder, tables where the contents can be copied in the folder currently being parameterized during its creation.

By right click on the field access is obtained to the list of tables where the contents can be copied if the response is Yes.

• Y/N (field OPTINI)

As a function of the response, the data is copied or not from the folder copy. This copy is only carried out during the creation of the folder or in the case of the creation of the tables following the activation of a new module.

• Default language (field LANDEF)

Makes it possible to update the parameter LANGAGE (main language) in the folder. This parameter is used to define a connection language when it is not specified for instance in the case of batch processes.

• Default country (field CRYDEF)

Used to update the CRYDEF parameter during the creation of the folder This parameter corresponds to the country proposed by default on entry of the addresses.

• Recoding list (field CHGCOD)

• Screen update (field CREMSK)

These fields are always checked in a normal delivery environment. They are used by the editor, in a development context, to re-validate a folder for testing avoiding the generation of the code corresponding to the options presented (screens, objects, windows, inquiries).

• Windows (field CREWIN)

• Object update (field CREOBJ)

• Inquiries (field CRECNS)

• Module (field MODTR)

Module belonging to the setup. This field is used to specify whether the screen has to be created in the folder database. It is specified when the module linked to the screen is active in the folder.

• Y/N (field TRVAL)

A positive response to the question leads to the validation of the transactions associated with the module.

• Languages (field LAN)

Grid used to enter the languages that may be used in a connection to the folder. The validation of the folder causes the entry screen generation in all these languages : this operation consumes a lot of system resources.

• Translation ref (field LANREF)

This check box can only be checked if the following two connections are met :

• the language is a language not shipped as standard by the editor.
• this language is not already checked for another folder in the current environment (also known as the solution).

It is used to specify that the current folder is the reference folder for the translation of the language in question, that is to say it is the folder that carries the most up to date translations for the language concerned.

By default for the languages shipped as standard, it is of course the root directory, which is explain that the box can no longer be checked in a standard folder; but for the "non standard" languages the user is free to define a translation reference folder.

A control verifies the uniqueness of the translation reference folder for a language, in order to change it, it is first necessary to un-check the folder previously set as the reference.

If for a language, there is no reference folder is checked, it is selected in the following order :

• the root folder (if the language concerned is defined in it)
• the first folder (in alphabetical order) that contains this language.

• Legislation (field DOSLEG)

• Copy options (field LIBCOP)

Each group corresponds to a coherent group of tables in the copy folder, tables where the contents can be copied in the folder currently being parameterized during its creation.

By right click on the field access is obtained to the list of tables where the contents can be copied if the response is Yes.

• Y/N (field OPTINI)

As a function of the response, the data is copied or not from the folder copy. This copy is only carried out during the creation of the folder or in the case of the creation of the tables following the activation of a new module.

• Default language (field LANDEF)

Makes it possible to update the parameter LANGAGE (main language) in the folder. This parameter is used to define a connection language when it is not specified for instance in the case of batch processes.

• Default country (field CRYDEF)

Used to update the CRYDEF parameter during the creation of the folder This parameter corresponds to the country proposed by default on entry of the addresses.

• Recoding list (field CHGCOD)

• Screen update (field CREMSK)

These fields are always checked in a normal delivery environment. They are used by the editor, in a development context, to re-validate a folder for testing avoiding the generation of the code corresponding to the options presented (screens, objects, windows, inquiries).

• Windows (field CREWIN)

• Object update (field CREOBJ)

• Inquiries (field CRECNS)

• Code (field CODACT4)

Defines the custom/specific activity codes (i.e. starting with X, Y, or Z), which can be activated in the folder.

• Title (field LIBACT4)

Title associated to the previous code.

• Module (field MODULE4)

Module belonging to the setup. This field is used to specify whether the screen has to be created in the folder database. It is specified when the module linked to the screen is active in the folder.

• Active (field FLACT4)

If this field is set to Yes, the fields marked by the activity code in the dictionary are activated.

• Dimension (field DIME4)

This dimension associated with a specific/custom activity code is used to size the grids and multi-occurrence fields marked by the activity code in question.

• Vertical (field COP)

This indicator must be set to Yes in the case where :

• a three level folder architecture is being used (reference folder, development folder, live folder).
• the associated specifics are expected to be defined at the intermediate level and will be automatically transferred to the lowest level folder in the case of revalidation or of the patch, including in the case of update.

If the indicator is set to No, the specific/customizations will not be updated when a revalidation is carried out if they exist already.

This flag is used to distinguish the vertical developments that are likely to be installed in a group of folders and updated by revalidation at three levels, and the developments made in the folder at the lowest level (developments carried out by the customer for example).

For more information, it is advisable to refer to the corresponding technical annex.

• Engine process memory (MB) (field MEM)

This parameter corresponds to the memory size used for the local data during the execution of the server process. By default, 16 Mb is proposed, this is a reasonable value even if the minimum value possible is 4 Mb. It is possible to increase it as a function of the maximum number of lines used for the large tables in memory (orders, invoices, postings). The higher the given values in the Screens tab, the greater the need to increase the necessary memory size. The system variable maxmem is used to identify the current value during a session.

• field MEM1

• Database process memory (MB) (field MSA)

This field is used to define the memory size allocated to the process accessing the database (it is named sadoraor sadossaccording to the database).

The default value is set to 20Mb, which only needs changing on rare occasions. The system variable sadmem is used to identify the current value in a session in execution.

• field MSA1

• Programs (field MPR)

This parameter is used to define the maximum number of processes open simultaneously in a software session. The default value is 200, the minimum value being 100. A higher number will improve the performances by limiting the reloading of processes. The system variable adxmpr is used to identify the current value during a session.

• field MPR1

• Open tables (field MTO)

This parameter is used to define the maximum number of tables in the database simultaneously on line in a software session. The default value is 150 and it is appropriate in most cases. The system variable adxmto is used to know the current value during a session.

• field MTO1

• Sequential files (field MSO)

This field is used to define the maximum number of sequential files open simultaneously in a software session (by the instructions Openi, Openo, Openio). The default value is 10, the minimum value being 10. Except to very specific cases linked to these instructions, this value has no reason to be modified. The system variable adxmso is used to identify the current value during a session.

• field MSO1

• Class memory (field MST)

• field MST1

• Folder (field CDOSSIER)

This field, display only, corresponds to the code for the folder being worked on.

• Application server (field CSERVEUR)

Corresponds to the name or the network address of the application server, that is to say the server one which is stored the reference for the folder (notably the directories for the different folders in the solution).

• Port (field CPORT)

Defines the TCP/IP port in which the connection server expects the connection requests from the folder.

• Access path (field CPATH)

Display only, this field corresponds to the root directory of the folder as it is defined on the application server. It is defined as a function of the volume entered in the first tab of the folder record.

When connected to the folder itself, this information can be found by entering the instruction :

filpath("","","")

• Process server (field CSERVTRT)

Corresponds to the name or the network address of the process proposed by default (there may be more than one and by default it can be the application server). A process server is a server on which the application code transmitted by the application server is executed.

• Publication directory (field CPUB)

Corresponds to the applications server directory from which the XML elements defining the user interface are created. This field is not displayed, its value being defined as a function of the installation.

• Solution folder (field SOLDOS)

• Authorization granted for the current folder (field SOLAUZ)

• Link type (field LTYPLIEN)

Define the type of link :

• either it is a Miscellaneouslink, which must be managed as specific/custom in the processes.
• or it is a characterized link (To Accounting, To Fixed Assets, To Pay, To Logistics...). This type of link is manage by the software when required. A single link for each type may exist for a given folder.

• Active link (field LLIENACT)

Field only displayed if the link is identified as active. This field is stored in the table of folders, but an existence control on the remote directory is made on the active when the tab is displayed.

• Machine (field LMAC)

Network path defining the remote server to be connected to.

• Service (field LSERV)

Number of the remote server to which a connection is made.

• Directory (field LREP)

Installation disk address for the remote solution. It is this location that the directory that is used in the remote connection will be created if a folder of the same code as the current folder does not exist.

This address corresponds to a database directory (volume 0 in adxvolumes) on the application server.

• Type of OS (field LTYPOS)

Defines the operating system of the server to which the link is made.

• Linked folder (field LDOSTARG)

Define the linked folder to be connected to. This information is mandatory when the link is characterized, but not for a miscellaneous link.

• Solution (field LSOL)

This field (display only) gives the name of the solution (in the Adonix sense of the term), if this can be found in the file configuration.xml (i.e. if connecting to a version greater than or equal to 140).

• Database type (field LTYPDBA)

Define the database type to which the user is to be connected.

• Name of the database (field LDBA)

Corresponds to the name of the remote database. This information is recovered in the solutions.xml file if the link points to an environment for a version greater than or equal to 140.

• Data source (field LSRC)

This field (display only) gives the name of the ODBC data source if this can be found in the configuration.xml file (i.e. if connecting to an environment where the version is greater than or equal to 140).

• DBMS user (field LUSR)

Defines the user code (in the database sense) used for the connection.

• Password (field LPWD1)

Defines the password (in the database sense) for the user to be used to connect to the remote database.

• System user (field LUSRJAV)

• Password (field LPWDJAV)