Setup > Usage > Imports / exports > Import/export templates 

This function is used to define the file formats used by the import and export functions for an object in order to integrate or extract data from the software database.

A file that can be used by the import module and generated by the export module is based on a file with one of the following structures :

  • flat file with fixed length fields.
  • flat file with separator between the fields (and records).
  • XML file.

The import/export module uses the notion of object in order to update the database. An object being defined by a group of tables and screens, as well as the standard actions associated with the fields and the update. In addition there is the guarantee that all the controls and actions necessary during the database update are carried out, because a single description for the object is used to both generate the code relative to an on-line update and an update by import.

When an object only updates a single table, the import template describes the list of fields from the table to be integrated, remembering that a block of data from the file to be imported or exported contains the data for a record When several tables are updated by an object (for example the header and the lines), several blocks of data will be found for an instance of the object to be integrated (for example a block defining the header and N blocks, one for each line).

It should be noted that it is also possible to import a table without associating the notion of an object with it. The empty object field is left for this purpose and the table and the fields concerned are entered in the grid in the second tab. The import is then made without any control apart from those deduced from the formats associated with the data types of the fields in the table.


SEEREFERTTO Refer to documentation Implementation

Screen management



An import/export template is identified by an alphanumeric code. Other than a title, two tabs are used to define the technical characteristics of the template.




The following fields are present on this tab :

This code identifies the import-export template.

  • Title (field INTIT)

It used to define a name associated with each record.

  • Active (field ENAFLG)

This check box is used to activate or deactivate the current record without losing its content.

A deactivated record cannot be used (by calling its code) in other records (documents, setups, etc.) or during mass processings.

The authorizations for a given function can prohibit the creation of an active record. In this case, the box is cleared by default and it can only be modified by an authorized user or via a signature circuit defined by Workflow.



Tab Header


This tab defines the general characteristics of the template, that is to say :

  • the data that must be exported
  • the general structure of the file (format, coding, data group definition)
  • the additional parameters




The following fields are present on this tab :


It Indicates the object code to be imported or exported. In the case of export, this field is optional; the main table name to be exported is indicated in the identifying block.

It is used to initialize the context (especially if the same object is used by several functions) and check the access rights. Indeed, users must have the appropriate rights to access the function to be able to use the template.

This field is mandatory.

  • Module (field MODULE)

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.

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.

This access code is used to to limit access to the current record for certain users.
If the field is entered, only the users having this access code in their profiles can view and modify this record.

The execution right associated with a user code is processed in a particular way in the case of the import-export templates : if a user has not been granted the execution right, they cannot use the template to import or export data.

  • Standard script (field TRTIMP)

It defines the standard process which includes the labels of those actions called in the import-export processes.

These processes are used to carry out initializations, additional controls and, if required, updates. The structure of such a programme can be found in the technical appendix. It should be noted that the standard processes usually named IMPXXX, XXX being the import code, are supplied for a certain number of imports.

For additional information on these actions, refer to the corresponding appended documentation.

  • Specific script (field SPEIMP)

It defines the specific/custom process which is called before the standard process, and which is used to carry out the same actions by de-activating if necessary what is carried out by the standard process.

The possible actions are, among others, initializations, additional controls and updates, if required.

For additional information on these actions, refer to the corresponding appended documentation.


  • File type (field TYPFIL)

It defines the structure used to manage the data in the file to be imported or exported. For further information, refer to the corresponding paragraph.

  • Field separator (field SEPFLD)

It defines the separator between two fields.

To enter a non-printable character, it is necessary to enter a '\' (back slash) followed by 3 numbers representing the ascii code of the character in decimal base.

  • Record separator (field SEPREC)

It defines the separator between two records (data groups).

To enter a non-printable character, it is necessary to enter a '\' (back slash) followed by 3 numbers representing the ascii code of the character in decimal base.

The following is often used :

  • the line feed character (\010), which corresponds to the end of the line in text files in Unix
  • the combination of the two characters carriage return, line feed (\013\010)n which corresponds to the end of the line in Windows text files.
  • Field delimiter (field FLDLIM)

The field delimiter (usually the character ") is added in the first and last position for alphanumeric fields. For numeric and date fields there is no requirement for a delimiter.

It is usually one of the following characters :

  • 'simple quote'
  • "double quote"
  • File format (field CODDBA)

It defines the format of the characters used in the file :

  • ascii is the standard format where a character is equivalent to a byte in the file. This type of format is used to deal with traditional occidental characters, with different possible character sets, defined in the corresponding field.
  • utf8 corresponds to a UNICODE format where the number of characters varies (from 1 to 4, 1 corresponding to the non-accentuated latin character set). This format makes it possible to deal with all types of characters, for instance the Chinese characters.
  • ucs2 corresponds to Microsoft's standard format where characters are systematically stored on 2 bytes.


  • Export (field EXPORT)

If this field is checked, it will be possible to use this template in the export of data.

  • Export sequence no. (field CHRNUM)

This field, only displayed, stores the value of the sequence number when the last export took place. When performing chronological exports, this is useful to process only what has been modified since the last export took place.


  • Character set (field OPTCHA)

When the ascii character set is being used, it is possible to use various standardized formats :

  • The ISO 8859 code (which is also Adonix internal set when using the ascii format)
  • The IBM PC code
  • The ASCII 7 bits code (without accents : The accentuated letters are converted into the corresponding minuscule.)
  • Decimal separator (field SEPDEC)

It defines the decimal separator used for numbers. If this field is empty, the system will consider that the decimal separator is '.' (full stop).

  • Date format (field OPTDAT)

It defines how the date type fields are coded (order and number of characters for the year).

Only the order of characters and the number of characters in the year can be specified. On the import, any separation characters between fields are filtered ; in this way, the dates in the form 29-05-59 or 09/04/1991 are correctly decoded.

The decoding sub-program takes into account the engine adxdcs variable, doucmented via the DCS parameter that is found in the general parameters in order to define the manner in which a year is decoded over two characters. DCS represents the "pivot" year that defines the century change.

For instance, if DCS is set to 1940, any year made up of two numbers less than or equal to 40 will be considered to be part of the 21st century and any year greater than 40 will be considered to be part of the 20th century. It will therefore be possible to express the years between 1940 and 2039 with two numbers.

  • field LIBDAT

Title associated to the previous code.

  • Local menu format (field OPTMNL)

The fields of type "local menu" are stored under the form of a number representing their rank in the table.

According to the value of this field the template will export (or expect to find in import).

  • 0 : 0 : in this case, the choice is in the form of a number that indicates the rank of the menu in the table : 1 for the first choice, 2 for the second etc. This also corresponds to the internal format under which the local menu is stored in the database.
  • 1 : 1 : the choice is entered using the code (on one character) associated with each choice of local menu. This code is not visible in local menu management. It can be defined in the development functions in message management : there is the possibility to enter this internal code (which is only used for that purpose, unlike for earlier character versions, when it was used as an entry accelerator).
  • n : (n>1) the first n characters of the label displayed in entry. When using this option, the search algorithm searches for the first character, then the second and so on, until a single corresponding title exists. Thus if a search is carried out to find CHQ in a local menu where the titles are Cash, Transfer, Check, Draft, Bank/credit card, the algorithm will find Check (the only title whose first two letters correspond).

Taking into account the fact that the local menu titles are only the labels used in display, the value stored in the database being the rank in the table, it is entirely possible to change the title of the local menus at the time of an import, in order for the search algorithm to operate correctly. However be aware that the fact of changing the local menu titles can only be made in single user mode, also it is not designed for regular or automatic transfers.

  • field LIBMNL

Title associated to the previous code.


  • Import (field IMPORT)

If this field is checked, it will be possible to use this template for the import of data.

  • Update allowed (field OPTUPD)

It makes it possible to modify an already existing record during import.

  • Temp storage space (field AOWSTA)

When this box is checked, the data import feeds the import-export storage space with the wrong data. The fact that the storage space is fed does not prevent the creation of an error file.

  • Special import (field OPTSPE)

It indicates that the data integration into the database is made using specific/custom actions defined in the process whose name is given in the Import process field. This specific/custom process includes a restricted number of entry points and therefore requires the writing of a process including all the controls that should be carried out.

Its use resides in the fact that it is possible to group the controls in order to optimize the import program. The structure of the specific/custom imports is described in appendix. The following actions, among others, should be found :

  • a label $RAZCRE that is directly called by the import.
  • a label $SAIMSK that is directly called by import for each record read and replaces the standard Call SAIMSK (allocation and control of the mask fields starting from class [F]).
  • Workflow (field ENAWRK)

Table Identifiers

  • No. (field NUMFLG)


  • Level (field FLGLEV)

It defines the group's overlapping level. Level 1 is the main level, a N+1 level defines a sub-level of the preceding N level.

  • Indicator (field FLGREC)

It identifies the group by a code containing a maximum of 5 characters, this code will be mentioned in the field grid of the following tab, and in the file itself, as group header.

This indicator grid defines the structure of the record groups. Refer to the corresponding paragraph.

  • Key (field FLGKEY)

It defines the key of the linked table used to access the detail of the group records, from values of the upper level tables used in the link expression.

  • Link (field FLGLNK)

It defines the link expression, in other words, a series of values separated by a semicolon which gives the key values linking the detail table to the header record.

  • Length (field RECLEN)

In the case of a file with fixed length, it is necessary to indicate the number of characters for each record.



Tab Fields


The different fields to be imported are defined in this grid, organised in groups identified by the Code column, in which is found one of the codes defined in the indicators grid from the first tab (the field can remain empty if no table has been defined).

This tab contains the grid defining the detailed structure of the groups existing in the first tab. It should be noted :

  • That it is not mandatory to define the fields in all the groups (in fact, some can only be "technical groups" defining the links). Imagine for example that the fields from the order header and the fields from the pay-by customer record are to be exported and all this in a single group of data (no separator for the data group). In this case it will be necessary to define two groups (the first defining the orders, the second associated with the customer with the appropriate link). However, only the lines associated with the second group are entered in the field tab. These lines can include both the information extracted from the customer and from the order header (because both are on line).
  • That it is imperative to define for each group the position where the group separator is found when it is a template that can be used for imports and where there are several groups. It is the pseudo field/ (slash) that makes it possible to define it.
  • That the blocks must be ordered sequentially : when a block for a lower level exists, it must follow the block to which it is linked.




The following fields are present on this tab :

Table Fields

  • No. (field NUMLIG)


  • Indicator (field TYP)

This field is only entered if the group indicator grid in the previous tab is not empty. It is used to attach the information to be exported or imported to a group of data.

Defined here is the database table where the data to be imported or exported is defined. It should be noted that:

  •  This field is mandatory even if it of no particular use (if in the export template and a calculated expression is defined, this can reference fields coming from several tables).
  • The table in question is not necessarily the main table associated with the group, but it can be a table linked to the main table in this group or one of the previous groups in the superior level. If no link is found, a warning message is displayed : Automatic link no managed. This means that for the import or export process (entered in the first tab) it is necessary to carry out this link manually (by declaring for instance the table in the IMP_OUVRE action, and the read of the table in the IMP_LIENS action).
  • Field (field FLD)

It is used to indicate the name of the field of the table to be imported or exported. Different syntaxes are possible here in order to define the information to be extracted or integrated :

  • The character / (slash) means that a group indicator is written upon export or searched for during import. In a template used for the import, when several groups exist, this separator is mandatory for each group. The group separator is supposed to be a normal field (enclosed by field separators and delimiters if the template type Delimited is used).
  • The most simple syntax is FIELD(index), when a field coming from the table declared in the previous column is imported or exported. A selection window is used to display the possible fields.
  • If a constant string of characters enclosed between double-quotes ( " ) is entered here, the field will be written as it is in the file to be exported and ignored in the import.
  • If nothing is entered, it means that there will be an empty field in the exported file (enclosed by field delimiters if the template is of the type Delimited). In import mode, it means that the corresponding field must be ignored.
  • The syntax *N, where N is a number between 1 and 99, is also possible. This can be used to assign (in import) or to read (in export) the GIMP(N) variable. GIMP is a global variable, of the character string type, with a maximum length equal to 100, that must be assigned in a specific/custom process associated with the import or export.
  • The last possibility, only used in export, consists in defining any calculated expression preceded with the sign equal ( = ). This expression, which can call constants, functions, variables, operators and fields coming from on-line tables, is syntaxically verified upon entry (the control of the context, in particular the fact that the variables exist, cannot obviously be verified).
  • Title (field COM)

Add a comment to make it easier to understand parameterization.

  • Range (field SEL)

Three choices are possible in this field :

  • Not enteredmeans that no start-end range will be entered for this field when launching the export.
  • Enteredmeans that a start-end range will be entered for this field when launching the export.
  • Not transferredmeans that a start-end range can be entered for this field when launching the export, but that the field will not be transferred during an import or an export.
  • Position (field LOC)

This column is only useful in the case of a fixed length format ; in this case, the position gives the gap with respect to the start of the block or the record (positions given in number of bytes, 1 signifying that it is the start of the section or record). The positions must be compatible with the size of the record.

  • Length (field LNG)

This field determines the length of the field for a sequential file.

  • Format (field FMT)

This column is only entered if the format is fixed length. For numeric amounts, the format entered is defined in the form of nnn or nnn.mmm, remembering that these numbers can be prefixed by < or > (left or right framing being completed with zeros, the right alignment must be used by default), prefixed or suffixed by the character + (mandatory sign before/after the number), and prefixed by the character * (the decimal separator must not appear). The grid below displays examples of the formatting for a given amount (the spaces are replaced here by #).



Result of the formatting






### -123.45












- 123.45###




>6 .2+






For an alphanumeric format, the only formatting directives that are possible are < or > (left or right alignment, remembering that the character strings are completed with spaces).

  • Pattern (field PATTERN)
  • Tag (field BAL)
  • Mandatory (field OBL)

This number, if it exists, refers to a transcoding table used to transcode the field that is read and make it comply with the expected format.

File generation

  • field TYPEXP


  • Data file (field FILEXT)

It is used to define the path of a default data file that will be proposed during the launch of the import or export (and used in automatic fashion when launching an import or export chain). This file path can be relative, in this case, the database directory is supposed to be the database directory for the installation of the software).

The path can include the character #. If this is the case, there will be a sequential number management :

  • In import mode, this means that all the files where the template corresponds to the path will be searched, with # representing 5 numbers (the files are integrated in increasing order of the numbers)
  • In export mode, this means that a file is created integrating the formatted value of the sequence number counter [C]EXPORT on 5 numbers. This normally goes with checking the Sequence Number Management box during the launch of the export function.

For instance, if the export sequence number is equal to 156, /u/tmp/fil# makes it possible to generate the /u/tmp/fil156 file.

  • Final directory (field REPFIN)

It is used to force a final directory to which the file will be transferred after having been imported. Should there be no value, the directory mentioned in the import/export general parameters is used.



Functions accessed by right click on the grid

Select a Field


The following fields are present in this window :

Block number 1

It defines the table for which the fields to be inserted must be selected.


  • No. (field NUMLIG)


  • Field (field CODZONE)

In this column the field name for the table is defined as it will be expressed in the software (a field with the name NOMCHAMP defined in an ABV abbreviation table can be accessed using the syntax [F:ABV]NOMCHAMP ).

For custom/specific fields, the field name must start with X_, Y_ or Z_.

In the database, each zone corresponds to one or more fields (according to whether or not the zone is sized : the corresponding fields are called NOMCHAMP_0, NOMCHAMP_1, NOMCHAMP_2…)

To enter and display the corresponding field on a screen, it is given the same name in the screen dictionary and the screen and the table will be used simultaneously in object management.

  • Title (field INTITCOURT)

Title associated to the previous code.

  • Selection (field SELECT)

If the field is equal to Yes it is inserted into the main table. By default, the fields that are not in the main table are proposed to be set to Yes, and those that are in the main table are proposed to be set to No.


This is used to globally insert from the current line in the grid, a group of fields coming from a table in a template.

Indicator position re-calculation

This function is only present for templates with a fixed field length types. It is used to re-calculate the position of each of the fields in the current data group (having the same line indicator). The re-calculation is carried out from position 1 in the first field of the group and by adding the length of each field, the position of the next field is obtained.





By default, the following reports are associated to the function :

 PRTSCR : Screen print

This can be changed by a different setup.

Specific Buttons

The following fields are present on the window opened through this button :

Block number 1

  • field OBJET


  • field CLES


Block number 2

  • From folder (field DOSORG)

This field is used to define the folder from which the record is going be copied. The possible syntaxes are described in the dedicated appendix.

  • All folders (field TOUDOS)

This option is used to copy the record to all the folders defined in the dictionary (ADOSSIER table from the current solution).

  • To folder (field DOSDES)

This field used to define the folder in which the record is going be copied. The possible syntaxes are described in the dedicated appendix.


This button is used to copy the record definition from or to another folder.

The following fields are present on the window opened through this button :

Table Range

  • Field (field BNOM)

It defines the name of the field for which a range can be entered

  • First value (field BDEB)

It is used to enter start and end ranges for each field defined as an entered or not displayed criterion in the field grid. If an empty field is documented, ranges are considered to be unavailable. These ranges will be suggested by default during export.

  • Final value (field BFIN)


Table Criteria

The tables used in the import/export template are listed here in order to enable any filtering of the exported data.

  • Criterion (field FLGEXP)

It is used to define a logical condition using the table fields. Only those lines meeting this condition will be exported.


This button gives access to a screen in which it is possible to define the default values for the criteria to filter the exported data. When the export is launched, the criteria are displayed and can be modified ; when a chain of exports is launched, the criteria are automatically applied without entry, for each of the templates in which they have been defined.

Menu Bar

Options / Export schema of a template

Documentation / Paragraphs

This function is used to access the documentation management on the first paragraph of the documentation (if there is one) associated to the current record.

Documentation / Links

This function is used to access the links management. It is used to define the links between the current and other records (for example the links between functions and setups). These links are specific to the documentation and are used to load the generation of documentation structures.

Documentation / Generation

This menu is used to launch a documentation generation. The generation can also be launched from the [Generation] button at the bottom of the window.

Three types of generation can be launched one by one or simultaneously:

  • the generation of the documentation structure from the dictionary (tables ADOCUMENT, ADOCBLB, ADOCCLB).
  • 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 it can be modified upon launch.

Error messages

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

Import not possible for this object

The object has not been defined as importable (tick box Import not ticked in the tab Miscellaneous).

Code already exists in line nnn

The same code associated with different codes has already been entered.

ZZZ field non existent (XXXXXX, YYYYY, ... )

This message is displayed when a link has been expressed in the groups grid using a field ZZZ that is not referenced in any of the tables (XXXXX, YYYYY, ...) defined in the previous lines.

G separator (/) not referenced in the fields. Prohibited in an import template

In the fields grid, for the G group, there is no line indicating the place where the group identifier is found (syntax /).

Link not possible. Prohibited in an import template

An attempt has been made in the lines describing the fields, to insert a field coming from a table that has not been linked to the main table in the group.

Incorrect length nnn<>mmm

The length defined by the numeric format (mmm) is different from the length of the field defined in the previous column (nnn).

Note :

No directory existence test is made on the file path defined by default in the template (the directory may not yet exist: this test is only made on launching an import or export).

Tables used

SEEREFERTTO Refer to documentation Implementation

Implementation advice

Basic principles

When an import template is parameterised, it is necessary to consider the following principles :

  • The import allows creation and modification actions.
  • To determine the action to be carried out on the imported record, the system carries out an existence test of the object to be processed. This test is carried out by loading the primary key for the object with the information in the imported record.
  • As a consequence, if the principal key is not parameterized, all the records will switch to creation mode (and only function if the key for the object to be created can be assigned automatically, for example by means of a sequence number counter).
  • An import corresponds to an entry simulation for all the screens linked to the imported object.
  • It processes all the fields in the screen by carrying out the same checks as an interactive entry.
  • It does not take into account the fields that cannot be entered in the screen. (except in specific and referenced cases). As a consequence, the fields parameterised in a template corresponding to a field that cannot be entered are not imported.
  • The order in which the fields are parameterised within the record has no importance. The import loads all the fields in the field then imports them in the order of the fields in the screens.

Standard templates supplied

Any number of data exports is always possible irrespective of the object, but this is not always the case for the import. The automatic mechanisms for decoding the data flow and the call to the conditions linked to the object greatly automate the import, but this is not sufficient for an automatic import of complex objects. Thus, not all objects can be imported.

In the reference folder, an import template (modifiable) is supplied for each object where the import is possible. There can nevertheless be peculiarities linked to this import : this is defined with the help of the on-line help associated with the import templates for which the specific cases exist (this aid is accessible by Alt + F1 when the template is loaded).

The list of corresponding helps (sorted by module) can be found from the next link.

Indicators grid

The choice of the structure of the files to be imported or exported depends on the extraction or integration possibilities that are found in the external software.

In all cases, the data must be organized in logical groups of lines, which can be of different types (e.g. header, detail, sub-detail) or a single type. The organization of these groups is defined in the identifiers grid located in the first tab of the template.

Each group is associated with one of the tables in the database (the first being the main table of the object, the others are defined by the links from the previous tables). When using the template to carry out an object export, it is possible to define the links with any table in the database in which a theoretic link exists, in order to extract the linked data. On the other hand for an import template, only the tables updated by the object are actually usable : it is for instance not possible to simultaneously import the order and the customer, the order object was not designed for this.

It is important to note that this grid can be empty if a data structure to be imported or exported is based on the use of only the main table (in this case, the Code column for the next page will remain empty). it is also not necessary to create several data groups if several linked tables must be exported simultaneously In fact, if fields extracted from different tables are displayed in a single data group, the export process will attempt to resolve the links between tables by using the link structure described in the dictionary. This supposes that there is only one link possible from the main table in the group to the described table (if not, the first link encountered will be used and even if it is not the correct one).

There is specific case where it is necessary to create at least a group : if the template is defined with a fixed length (in this case, it is in fact necessary to define the record length somewhere and this is done in the group of tables). If the group indicator is not required to be present in the list of fields, it is sufficient to define this group with an empty code : only one group can then be defined and the Code column will no longer be entered in the next tab.

The identifier grid is only accessible if the object is of the single type. If group indicators are defined, each is associated with a level, a table and the link conditons that make it possible to create the link between them.

The main table is set to level 1 for import or export (this table is not entered in the grid, but is deduced from the object associated with the template).

For any table linked to a previous table, the level is equal to the level of the previous table if a one-to-one link exists between the two tables, and to this level plus one if several records are linked to a record in the previous table. The link is characterized by the key for the destination table to be read and by the key segment expression whose value defines the linked lines.

Imagine for instance that groups are defined according to the following example :











Overlapping will then be obtained according to the information :

Group A record 1




Group B record 1.1



Group B record 1.2






Group B record 1.N



Group C record 1.1




Group D record 1.1.1



Group D record 1.1.2






Group D record 1.1.M


Group C record 1.2




Group D record 1.2.1





Group C record 1.Q




Group D record 1.Q.1






Group D records 1.Q.R

Group A record 2




Group B record 2.1





Group example

To illustrate this parameterization the following example takes a template (export only) bringing into play the companies and sites :

  • The main table COMPANY is level 1.
  • Imagine that information linked to the accounting currency (ACCCUR field) is required in the exported file. In this case, it is not necessary to define a new group linked to the company table, but simply to define the fields of the TABCUR table in the group. The export engine will then run through the dictionary to search for the link between the COMPANY and TABCUR tables. Where there are several, it is the first link that will be used (in this case, it is the one required).
  • If the purpose had been to export information connected with the currency of the company's stock capital (RGCCUR field), it would have been necessary to create a second block of data, also of level 1, based on the TABCUR table, and showing RGCCUR in the link column. It is also what would have to be achieved if the link was not explicit. For instance, the CREUSR field, which corresponds to the code of the user having created the record, uses a generic type (A) which does not allow the link to be made automatically. As a consequence, if information concerning the user having created the record had to be displayed, it would have been necessary to define the link by a group.
  • Then, suppose that the list of the sites linked with the company needs to be displayed. A level 2 group is then created, using the FACILITY table, with a link based on the FCY index and whose value will be the CPY field of the main table.
  • Eventually, if the parameter values directly related to each company need to be extracted, a second level 2 group of data will be created, using the ADOVAL table, with a link based on the ADW0 index and whose value will be the CPY field of the main table.

The grid below summarizes the Identifiers grid as they would be entered :











main group record






1 linked record






N linked records






M linked records

The various file formats

The file formats are determined by the type, which can take one of the values below :

Ascii 1 format

This is a field with variable length, where all the fields are separated by a separator (the separator field being SC).

Field 1 record 1


Field 2 record 1



Field N record 1


Field 1 record 2


Field 2 record 2



Field N record 2


Ascii 2 format

This is a file with variable length, where all the fields are separated by a separator (the field separator). When the record is complete, another separator (the line separator SL) replaces the field separator.

Field 1 record 1


Field 2 record 1



Field N record 1


Field 1 record 2


Field 2 record 2



Field N record 2


Delimited format

This is a file with variable length of the same type as the ASCII2 file (two distinct separators). But in addition, the fields of character string type are contained by a field delimiter (called DC, in the example below, the second field is of alphanumeric type ).

Field 1 record 1



Field 2 record 1




Field N record 1


Field 1 record 2



Field 2 record 2




Field N record 2


Fixed length format

This is a file where the fields are defined with a fixed length, without a field separator. The total length of the record must therefore be given in a parameter. There may be a line separator. In this case, its length must not be counted in the record length.

In the same way, the length of each group is defined when blocks of data are defined in the indicators grid.

Fld 1 rec 1

< ---------Field 2 record 1------------ >


< --Field N record 1-- >


Fld 1 rec 2

< ---------Field 2 record 2------------ >


< --Field N record 2-- >


XML format

It is a format where data are defined in XML tags.

Upon export, the file contains a large number of information related both to the model and the extraction. Upon import, the useful data are less important, it is thus possible to limit them in the file to be imported.

After the xml header, an initial tag is used to determine the export conditions :

 <EXP MOD="model" OBJ="object" FOL="folder" DAT="date" TIM="time" USR="user" CHR="sequence number">

model, object being respectively the model code and the relative object, folder the file code, date, time, and user being specific to the extraction conditions.

Upon import, the initial tag can simply be <EXP>.

Then, for each group of data, there is a header which is as follows :

 <GRP LEV="level" TAB="table" KEY="key" LNK="link">

GRPbeing the group code, level the level of this group, table, key, and linkbeing the other elements entered in the links grid.

Each field is defined by a line of the type :

 <FLD NAM="name_field" TYP="type_data" LEN="length" VAL="value" </FLD>

name_fieldbeing the name of the field which is exported, type_dataand length its characteristics, value which defines its value.

Obviously each group ends with the tag </GRP>, and a tag </EXP> must end the file.

Technical appendices

Further information can be obtained in the following technical appendices :