Description of the documentation structure

General description of the structure

All SAFE X3 documentations are stored in the database.

• table ADOCUMENT for paragraph structure,
• table ADOCCLB for texts,
• table ADOCBLB for miscellaneous files,
• table ADOCFNC for links.
• table ADOCFLD for help fields.

The storage process for data is defined in the annex below.

Documentation generation

• A first generation function makes it possible to create, for each entity to be documented, the structure of the documentation, consisting in several standardized paragraphs.
• A second generation function uses these data and the entered text to generate the final documentation in the HTML format. Each record corresponds to a paragraph since the documentations are organized in a list of paragraphs.

Structure of a paragraph

• a language code,
• a document type: 
• The functional documentation (explanations on how to use the function) is identified by the AFC type.
• The documentations describing the parameters (parameters, activity codes, automatic journals, etc.) are identified by the code of the object managing them (ADP, ACV, GAU in previous examples).
• The miscellaneous documentations (annex, for instance, like this one) are identified by the code DI. Menus and sub-menus are defined by the APM code.
• a code used to identify the documentation, which corresponds to what is documented: for instance the function code, the setup code, the activity code, the automatic journal code, etc.
• A level and a sub-level which describe the overlapping of paragraphs.
  The title of the first paragraph of each level is reused in a table of contents making it possible to access directly the documentation sections. When more than one paragraph exists in a given sub-level, a sub-table of contents is created for the corresponding levels.
• A paragraph code determines the way the HTML text is to be generated.
• A screen code defines if it is necessary to insert in the corresponding paragraph an icon which makes it possible to unfold the field help related to the given screen.
• An activity code inherited from the dictionary upon regeneration makes it possible to distinguish notably the standard records from the specific records, but also to create documentations adapted to given folders by generating only the paragraphs and documentations corresponding to the activity codes activated on this folder.

 Note that a paragraph with a FAL activity code (always false) is never taken into account by the generation processing, even when a complete generation is requested. This makes it possible to deactivate generated paragraphs that should not be found in a documentation.

Once the generation process from the dictionary is coming to an end, it is possible to complete the created records in the ADOCUMENT table and to add others (notably of miscellaneous type). Deleting a record in the ADOCUMENT table means deleting the paragraph in the final documentation. However, if this paragraph is generated from the dictionary, launching a regeneration from the dictionary recreates the paragraph.

 It is important to note that the paragraphs are listed in the order according to which that must be displayed (the TIT paragraph being the first for instance). It is advised to comply with the order, except in particular cases and for generic paragraphs.

The existing paragraphs are linked to several categories.

The paragraphs generated automatically

Some paragraphs automatically recover elements from the dictionary or the link table, with a given layout.
These are called generated paragraphs. In this case, upon generation if the ADOCUMENT table, the paragraph is created without text if the elements of the dictionary or of the table justify it. It is not necessary to enter text since the dictionary elements are automatically displayed in the paragraph. 
If a text is entered in the record, it is automatically added at the end of the paragraph. In this case, the regeneration does not delete the paragraph, even if this paragraph is not justified anymore following the dictionary evolution.

The paragraphs created empty or usual paragraphs

Some paragraphs are created automatically upon generation from the dictionary, but without text because these are free paragraphs usually present in a given documentation type. The text entered in the ADOCUMENT table is then recovered in the final documentation without specific layout. Some paragraphs are not created automatically upon dictionary generation but they can be created afterwards. They are called free paragraphs later in this document.

Hypertext links

Except for the specific case described below, the creation of a paragraph creates an anchor with the same name in the text. It is thus possible to create an hypertext link to the paragraph in question (the link path being document.htm#anchor instead of document.htm in this case). Thus, in order to access directly the documentation of the 3rd tab of the function User management (GESAUS), it is necessary to use a link to GESAUS.htm#ON3.

The codes of the paragraphs that can be found in a documentation in several examples must have a link per paragraph. In that case, the link is displayed in the following form: PARAG_LEV_SLEV. PARAG is the code of the paragraph, LEV is the code of the level, and SLEV is the code of the sub-level. Thus, for a MIS paragraph situated at the level 140 and sub-level 40 of the ADO_FCT documentation, the link will be ADO_FCT#MIS_140_40.

The different documentation types

The field Documentation type defines what is going to be documented.

The grid below describes the possible types of documentation:

Type	Documented element	Generation	Source
ABF	BI Fact table	Yes	Fact table dictionary
ABI	BI Dimensions	Yes	BI dimension dictionary
ABM	BI Datamart	Yes	BI datamart dictionary
ABO	Business Intelligence reports	Yes	Business Object report dictionary
ABV	BI Synchronization rules	Yes	BI synchronization rule dictionary
ACN	Inquiry	Yes	Inquiry dictionary
ACT	Action code:	Yes	Action dictionary
ACV	Activity code	Yes	Activity code table
AD	Adonix 4GL	No	Language key words
ADC	Entry points	Yes	Processing dictionary
ADI	Miscellaneous table list	Yes	Miscellaneous table dictionary
ADM	Sizing variable	Yes	Variable table
ADP	Parameters	Yes	Parameter dictionary
Sales Management	Miscellaneous tables	No	Miscellaneous table dictionary
AFC	Functions of the software	Yes	Function table
AGB	Global variables	Yes	Variable dictionary
AHH	BI Hierarchy	Yes	BI hierarchy dictionary
AHI	Purge rules	Yes	Purge rule table
AM	Development templates	No
AML	Local menus	Yes	Message table
AOE	Import/export template	Yes	Template table
APM	Menus	Yes	Function table
ARP	Reports	Yes	Report dictionary
ASU	Sub-programs	Yes	Sub-program dictionary
ATB	Tables	Yes	Table dictionary
ATD	Table dictionary differences	No	Table dictionary
AT3	130 table dictionary differences	No	Table dictionary
ATY	Data types	Yes	Data type table
AWA	Workflow rules	Yes	Workflow rule table
CDA	Accounting destinations	Yes	Destinations table
CDE	Default dimensions	Yes	Default dimension table
CS	Console	No
DI	Miscellaneous documentations	No
DL	Development delta	No
FI	Linked files	No	Linked file tag
GAU	Automatic journals	Yes	Automatic journal table
IN	Installation	No
MC	MCD	No
PA	Patches	No
PLA	Payroll plan	No
PS1	Statistical triggers	Yes	Trigger table

 Details on some documentations

Documentations of AFC type

The documentation of AFC type is the most extensive. It is used to describe in details the function, its setup prerequisites (a set of automated sub-paragraphs), its user interface (tabs with field help, buttons, menu items) and appendixes (reports, error and managed table list).
A part of the paragraphs forming it is totally generated from the dictionary, but most of the paragraphs must be entered. The code associated to this documentation is the code of the function (as defined in the function dictionary). The name of the corresponding html file will be generated in the FCT sub-directory of the documentation directory.
It can be called from any screen of the function via the F1 key.

As regards the generated HTML documentation file and for AFC documentations only, all paragraphs that are regarded as parts of the function operation, are grouped in another HTML file, in order to clearly separate the functional part from the technical one. A link is created within the original HTML file to the operational HTML file for each type of paragraph.
Here are the paragraphs involved:

• All the paragraphs of level 30 (Prerequisites)
• All the paragraphs of level 100 (Tables used)

Documentations of DI type

The documentations of DI type are not linked to a dictionary element. They are used to create technical appendixes and general documentations. For instance, in standard documentation, GESAWA.htm is the documentation associated with the Workflow events. GES_AWA.htm, DI documentation, is the corresponding technical annex..
DI documentations are generated in the FCT directory.
In order to prevent the functional documentations from being mixed up with the DI documentations, it is necessary to insert at least the character '_' in the code.

ACV, ADM, ADP, AOE, ARP, AWA, CDA, CDE, GAU, PS1, ADC Documentations

ACV, ADM, ADP, AHI, AOE, ARP, AWA, CDA, CDE, GAU, PS1, ADC documentations are object-type documentations, and can be accessed by Alt + F1 from a setup function. They are used to describe the setup conditions of the current record. Usually, this type of documentation does not contain much text (mainly about on the use or description of the code, with potential notes). 
Some paragraph codes are specific to this type of documentation. The code associated to this documentation is the code of the corresponding record. The documentation file is generated in the OBJ sub-directory. It is formed of the object code followed by the record key.

Examples
- The BPA activity code is generated with the name ACV_BPA.htm.
- The BPR import export template is generated with the name AOE_BPR.htm. 

 Note that the setup key is a key in two parts including the corresponding chapter. For instance, the help on the ADMUSR setup (SUP chapter) is then generated under the name ADP_SUP_ADMUSR.htm.

Documentations of type AML, ATB, ATY

The documentations of type AML, ATB, ATY are documentations describing the data structure.
They can be accessed from the table of contents of the help.
This documentation type contains only one paragraph (the title paragraph which may be used to add a comment before the generated documentation). They are generated in the MCD directory and reuse the (non prefixed) table code, the code of the data type with the prefix ATY_ and the local menu number in the form form MEN####.htm (#### being the menu number with 4 numbers, with zeros added left).

Documentations of type APM

The documentations of type APM are the help menus.
These documentations are generated from the dictionary and there is only one paragraph in this type of documentation It is possible to create other documentations to describe the additional menus organizing the documentation (in this case, the paragraph contains the list of called documentations). It is also possible to add additional documentation links in the generated documentations of this type.

Documentations of type FI

FI-type documentations are simply used to extract documentations. The rule to name these documentations determines the place where the files are created. The detail is to be found in the corresponding paragraph.

The documentation menus

All the functions manage records which can be documented by the documentation management function under following conditions:

• Define in the miscellaneous table 910 the documentation code corresponding to the code of the object which record documentation is to be managed.
• The type of documentation corresponds to the type of object and the key corresponds to the main key of the record being documented (if it is a key in several parts, these are divided by the underlining character "_").
• Generate the documentations in HTML format (they are created by default in the OBJ directory, the directory for the object help).
• the help is called on a given record via Alt + F1.

Examples
AFC (functional help) corresponds to the function help and the AFC object manages functions. It is the same for ADP (parameters), ACT (actions) and ACV (activity codes, etc.) documentations.

As soon as the code of an object is present in the miscellaneous table 910, a menu Documentation is automatically displayed in the menu bar of the corresponding object.
The functions that can be accessed via the menu are described below.

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 link management. It is used to define the links between the current record and other records (for instance 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 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.

Preliminary paragraphs

These paragraphs introduce the functional documentation.

TIT code (title)

This chapter defines the title of the documentation in its title.

When the functional documentation is generated from the dictionary, this chapter is automatically created at level (10,10).

For dictionary documentations (tables, local menus, data types) for which it is the only paragraph, the entered text is a text to insert before the grids describing the technical structure of the dictionary.

For documentations describing a menu (type APM), it is possible to add links to other helps by identifying them with their codes. A line is then codified as follows:

• either the function code (functional help). Example: GESAUS
• or the code of the help with its type as prefix and the character "/" as separation. Example: DI/ADO_FCT
• either one of the previous syntaxes followed by the "#" character and a tag name to position oneself in the middle of the document. Example: GESAUS#ON3

For all other types of documentation, it is possible to put in the text only a series of words divided by commas which are inserted in the the keyword field (keywords for searches which are not displayed in the text). In this case, there is no associated paragraph (and no anchor as well) in the end HTML document.

This paragraph type is managed for all documentation types. If this paragraph has an activity code and when generating the documentation for a folder on which this activity code is not activated, the documentation is not generated.

Especially if this paragraph has the FAL activity code:

• the final documentation is never generated.
• regenerating the documentation structure does not result in a generation (the generation stops if the TIT paragraph has the FAL activity code).

If the title is not entered in the record, it is searched in the dictionary according to the context. This makes it possible to manage specific cases such as the field help on RPT* functions where the group name must be the dictionary name.

PRE code (presentation)

This paragraph defines the presentation of the documented entity (function, activity code, sizing setup, setup, etc. All documentations are concerned). This paragraph is automatically created empty at level (10,20).

This is the first paragraph displayed in the final functional documentation.

 It is not necessary to enter a text for the presentation of activity codes depending on another code (an automatic text is used if the text field is empty).

Paragraphs for the functional pre-requisites

These paragraphs describe the pre-requisites necessary to execute the function. They can thus be present in any functional documentation, even if some can also be present in other documentations (documentations on activity codes, on reports, on Workflow events, etc.).

NOTE on AFC documentations (only AFC): From now on, in the generated HTML documentation file, all the Pre-requisite paragraphs are written into an operational annex HTML file, in order to clearly separate the functional part from the technical one. A link is created within the original HTML file to the operational HTML file.

Paragraphs list:

PRQ code (pre-requisites)

This paragraph defining the pre-requisites is present in the documentations on function, reports, import/export templates.

This is an introduction paragraphcreated empty at level (30,10). In the documentation on function, this paragraph is only created if another pre-requisite paragraph is created (whereas is is always created for documentations on import/export and on reports).

The text is not mandatory (if there is no text, the paragraph exists as inter-title).

ACV code (activity codes)

This paragraph is present in the documentation on functions and on the documentation on parameters and on the documentation on activity codes. It is a paragraph generated at level (30,20) with the style 4:

• in the documentation on functions, it is generated from the dictionary as soon as at least one activity code can be found (they are searched in the function, in the window associated to the function, in the object, in the inquiry and in the associated tables). It is also possible to associate an activity code with a function via the ADOCFNC link table. This is then a sub-paragraph of the PRQ paragraph.
• in the documentation on parameters, it is generated via a search in the dictionary and via links between setup and activity code.
• In the documentations describing an activity code. It is generated by taking into account the activity codes depending on the documented activity code (this link is also present in the dictionary).

Upon generation of the final documentation, a search is carried out to find the activity codes with the same algorithm in the dictionary. They are displayed in the form of a grid with links to the documentation describing the activity code.

Note that the system automatically searches the whole dictionary and that this can return through cascade an important number of unrequested activity codes in the list. There is a specific functionality used to sort the list: The presence of the FAL (always false) activity code in the documentation links blocks the search for activity codes in the dictionary. Only the links to activity codes (FAL excluded) mentioned in the links remain.

ADP code (parameters)

This paragraph is present in the documentation on functions and on the documentation on parameters and on import/export templates. It is a paragraph generated at level (30.30) with the style 4:

• in the documentation on functions, this paragraph defines the list of parameters associated to the function and it is generated using the links between function and setup or setup and function (the reciprocal links are also analyzed). This is then a sub-paragraph of the PRQ paragraph.
• in the documentation on parameters, the paragraph is generated using a search in the dictionary (parameters from the same group and from the same chapter are included) and using associations between setup and link table setup.
• in documentations describing an import/export template, the paragraph describes linked parameters (searched by going through links between templates and parameters or reciprocally in the link table).

Upon generation of the final documentation, the parameters are sorted by group and displayed in lists with links to the documentation describing the general setup.

ANM code (sequence number counters)

This is a paragraph generated at level (30,40) with the style 4, which is present in the documentation on functions and gives the list of sequence number counters used by the function. It is generated as soon as at least one counter is found in the link table (it is possible to associate a counter to a function). This is a sub-paragraph of the PRQ paragraph.

Upon generation of the final documentation, the counters are displayed in a list.

GAU code (auto journals)

This is a paragraph generated at level (30.50) with the style 5, which is present in the documentation on functions and gives the list of automatic journals used by the function. It is generated as soon as at least one automatic journal is found in the link table (it is possible to associate an automatic journal to a function). A sub-paragraph of the PRQ paragraph introduces globally the GAU and CDE paragraphs. It is preceded by an additional inter-title with a style inferior to the paragraph style (4 by default), named accounting interface.

Upon generation of the final documentation, the automatic journals are displayed in a grid with a link to the documentation describing them.

CDE code (dimensions/default)

This is a paragraph generated at level (30.60) with the style 5, which is present in the documentation on functions and gives the list of dimension codes used by the function. It is generated as soon as at least one dimension code is found in the link table (it is possible to associate a dimension code to a function). A sub-paragraph of the PRQ paragraph introduces globally the GAU and CDE paragraphs. It is preceded by an additional inter-title with a style inferior to the paragraph style (4 by default), named accounting interface.

Upon generation of the final documentation, the dimension codes are displayed in a grid with a link to the documentation describing them. 

HAB code (authorizations)

In the functional documentation, this optional paragraph is usually a sub-paragraph of the PRQ paragraph.

This is a paragraph generated by default at level (30,70) with the style 4, as soon as one of the following conditions is verified:

• the function has access rights managed according to the site.
• there are authorization options in the dictionary for the function.
• the function is of object type (as such, there are default creation/deletion/modification options).
• an access code is declared at object level if the function is of object type.

Upon generation of the final documentation, a set of automatic texts is created depending on the context (management via access codes, authorization options for the dictionary, etc.)

TRS code (transactions)

In the functional documentation, this optional paragraph is usually a sub-paragraph of the PRQ paragraph. It is generated from links between functions and transactions (the link of type TRS associating a function to the function used to setup transactions). The generation is made at level (30,80) with the style 4.

Upon generation of the final documentation, the layout of the transactions is updated and links to the corresponding functional documentation are inserted.

ECC codes (inquiry screens)

In the functional documentation, this optional paragraph is usually a sub-paragraph of the PRQ paragraph. It is generated from the dictionary by searching a list of the inquiry codes found in the folder where the documentation is generated.

Note that this paragraph is generated with the same row as the TRS paragraph, which is logical since both of them cannot coexist (one of them is about inquiries, the other about objects) and since they both correspond to screen variants. The generation is made at level (30,80) with the style 4.

Upon generation of the final documentation, these screen codes are displayed in a grid.

PRD code (other pre-requisites)

This is a paragraph generated at level (30,90) with the style 4, which is present in the documentation on functions and gives a series of other pre-requisites displayed in the form of sub-paragraphs with inter-titles of style 5:

• the first of them gives the list of miscellaneous tables to update. It is loaded by the links between function and miscellaneous tables.
• the second gives the list of database tables to update. It is loaded by the links between the function and the tables (by the AT2 code, the ATB code loading the update tables).
• the third gives the list of local menus which it is necessary to enter. It is loaded by the links between function and local menus.
• the last sub-paragraph, named Miscellaneous pre-requisites, is present if a text was added to the documentation. If the text begins with a title (with a tag of type Hn, n being a number), the inter-title Miscellaneous pre-requisites is not inserted.

Description of the interface

These generated paragraphs describe the organization of the entry window associated to the function. They are only generated automatically if there is a window associated to the function. The final generation includes the functional help if the Screen field present in the record is entered.

The paragraphs are the following:

ECR code (screen description)

This paragraph is an introduction which makes it possible to define notably the number of tabs, to describe the specificities of the left list if any.

When the functional documentation is generated from the dictionary, this chapter is automatically created at level (40.50) with the style 3.

ENT code (screen header)

This paragraph describes the header fields of the window (if any). The text entered here is inserted as is in the final documentation. As soon as the screen code is entered in the setup, the title bar includes a small icon in the form of a bottom arrow, which unfolds automatically the list of header fields (and the corresponding helps). As a general rule, the text is used to give the detail of the fields forming the object key or the inquiry criteria.

When the functional documentation is generated from the dictionary, this chapter is automatically created at level (40,100) with the style 3, as soon as the window corresponding to the function uses a header mask.

Codes ON1 to ONF (tabs)

These paragraphs describe each of the tabs of the window associated to the function. The title bar includes a small icon in the form of a bottom arrow, which unfolds automatically the list of header fields (and the corresponding helps) if the screen field is entered in the record, which is not the case for an automatic generation.

As a general rule, this text is used to give information on the fields present in the tab (without necessarily giving the detail of the help for each field, since the online help by field is also available via unfolding). If no text is assigned, a generic text proposes to unfold the field help.

When the functional documentation is generated from the dictionary, this type of chapter is automatically created at level 40 from the description of the window associated to the function. The generation sub-levels are calculated from the row of the tab (field ROWMSK) in order to comply with the presentation order of the function tabs when adding specific tabs which have to be inserted between two existing tabs. The sub-level equals the rank multiplied by 200. So if the ranks are numbered in tens, the resulting ranks are 2000, 4000, 6000. The minimum rank is 200 and the maximum is 19800.

When generating the documentation, the paragraphs describing the actions Button on grids (right click) are created automatically following the paragraph linked to each tab. They are numbered by 5 in order to give the possibility to insert miscellaneous paragraphs.

BOT codes (clicks on grids)

These paragraphs describe each of the functions available via right click on a grid. There may be several of them (with the same code: the corresponding anchor is BOT_LEV_SLEV, where LEV is the level, and SLEV the sub-level). Each of these buttons must be inserted in the order of the paragraphs, just after the paragraph describing the tab on which it is placed.

When the functional documentation is generated from the dictionary, these paragraphs are automatically created at level 40 with a numbering range from 5 to 5 beginning with the tab number (2,005, 2,010, 2,015, etc. after the tab of row 10 for instance). The default style used is the number 6, and an inter-title named Functions available via right click on grid, of style 5, is used in the consecutive paragraphs of this type.

BOU codes (buttons)

These paragraphs describe each of the buttons that are available at the bottom of the screen. There may be several of them (with the same code: the corresponding anchor is BOT_LEV_SLEV, where LEV is the level, and SLEV the sub-level). These buttons are usually positioned after the paragraphs associated to the tabs. The first of them is an introduction paragraph which title uses a standard style (3 by default). The title of the following consecutive BOU chapters is displayed in a button framework, which means that the text must correspond to the button text. The corresponding text is then put on the right of each button.

When the functional documentation is generated from the dictionary, these paragraphs are automatically created at level 70 with a sub-level beginning with 19 (title of the chapter about buttons) and then going 10 by 10 (20 for the first button, 30 for the second, etc.).

BME codes (Menu bars)

These paragraphs describe each of the functions available via the menu bar. There may be several of them (with the same code: the corresponding anchor is BME_LEV_SLEV, where LEV is the level, and SLEV the sub-level). These paragraphs are positioned after the paragraphs. The first of them is an introduction paragraph which title uses a standard style (3 by default). The title of the consecutive chapters has the standard 4 style.

When the functional documentation is generated from the dictionary, these paragraphs are automatically created at level 80 with a sub-level beginning with 19 (title of the chapter about menus) and then going 10 by 10 (20 for the first button, 30 for the second, etc.).

Annex paragraphs

These conclusion paragraphs give annex information (list of errors, reports, batch tasks, etc.). These are the following:

RPT code (Reports)

This is a paragraph generated at level (50.10) with the style 4, which is present in the documentation on functions and gives the reports used by the function. It is generated from the dictionary (search from the print codes defined in the dictionary of functions for Print and List, by searching if reports are associated to them in the print code table). This report list is completed by the reports potentially found by searching for links between the function and the reports in the link table.

Upon generation of the final documentation, a grid is generated containing the reports launched from the function with hypertext links pointing to the corresponding documentations.

ABT code (batch tasks)

This is a paragraph generated at level (60.10) with the style 4, which is present in the documentation on functions and gives the list of batch tasks used to launch the function in batch mode. It is generated from the dictionary (search in the batch task table). This task list is completed by the tasks potentially found by searching for links between the function and the batch tasks in the link table.

Upon generation of the final documentation, a grid is generated containing the list of existing tasks.

ERR code (Errors)

This paragraph is dedicated to the list of errors which can be displayed when using the function. Its entered text is directly inserted in the document. Only errors specific to the function are inserted here. Indeed, generic errors are listed in a dedicated document and a link to this document is automatically inserted in this paragraph. Moreover, the paragraph is created empty.

This type of paragraph is also used in the documentation on import/export templates, with the same characteristics.

When the functional documentation is generated from the dictionary, this chapter is automatically created at level (80.10) with the style 3. If no text is associated to the paragraph, a message indicates that the only known errors are generic errors (which can be accessed using the link). Otherwise the text lists the errors and the corresponding explanation. It is advised to use the H5 style for the error text and the default paragraph style for the explanation, which gives the following result:

	Error text
	Detailed explanation

 It is possible to use the mess() 4GL syntax for the error text. This makes it possible to have a fixed translation for the error text.

For instance:

	mess( 23 , 100 , 1): xxx
	The selected record does not exist

which results in the following upon generation

	Non-existent record: xxx
	The selected record does not exist

ATB code (managed tables)

This paragraph is present in the documentation on functions and on the documentation on sizing parameters, on import/export templates, reports, workflow rules and events triggering statistics. It is a paragraph generated at level (100.10) with the style 3:

• in the documentation on functions, it is generated from the dictionary as soon as at least a table is found (tables are searched in the object inquiry). It is also possible to associate a table to a function via the link table.
  NOTE on AFC documentations (only AFC): From now on, in the generated HTML documentation file, this paragraph of Tables used is written into an operational annex HTML file, in order to clearly separate the functional part from the technical one. A link is created within the original HTML file to the operational HTML file.
• in other documentations the same principle is applied: the paragraph is generated if the dictionary is used to find tables, or if links are found.
• in the case of the documentation on sizing parameters, the listed tables are those which size depends on the setup.

Upon generation of the final documentation, the tables are displayed in a grid including a link to the table dictionary and to the object when it exists, which makes it possible to manage the table concerned. If there are tables common to all folders, they are isolated in a dedicated paragraph.

Specific paragraphs

These paragraphs can be inserted everywhere in the documentation in order to manage exceptions or unplanned additional paragraphs. They are also used to segment a paragraph when it is too long (the length of the text entered without a paragraph being limited by construction). Since the code used for these paragraphs can be repeated, there is no anchor having the same name on it (yet technical anchors are created, which are numbered with the paragraph code, followed by the level and sub-level and divided by the "_" character). The paragraphs are the following:

MIS codes (Miscellaneous)

This is a miscellaneous paragraph present in the table of contents linked to the corresponding level. A title, a style and a text to insert are entered.

Since several paragraphs of this type can exist in a documentation, the anchor corresponding to these paragraphs is MIS_LEV_SLEV, where LEV represents the level and SLEV the sub-level.

MIN codes (Miscellaneous)

This miscellaneous paragraph is not present in the table of contents linked with the corresponding level. A title, a style and a text to insert are entered.

Since several paragraphs of this type can exist in a documentation, the anchor corresponding to these paragraphs is MIS_LEV_SLEV, where LEV represents the level and SLEV the sub-level.

LNK codes (Links)

This type of paragraph is used to insert tables of contents in the form:

• either of the list of header links (located in the documentation title bar). This implies that the paragraph of type LNK is located at the same level as the TIT paragraph of the corresponding documentation. The title of the paragraph gives the title of the current document as defined in the link list.
• or of a list of links (as a table of contents) in the general case. This type of paragraph is used to insert links to documentations which cannot be directly accessed in the hierarchy of the document.

When the link defines a separated paragraph, the title and the style are not taken into account and no entry is displayed in the table of contents. When it is requested to add a title to this paragraph of links, it is sufficient to have before it a paragraph of type MIS or MIN.

Links are defined in the paragraph text under one of the following forms:

• CODE_FONCTION
• CODE_FONCTION#ancre
• TYPE/CODE
• TYPE/CODE#ancre

Here is the meaning of these elements:

• CODE_FONCTION is the code of a functional documentation (of AFC o DI type): the link points to the sub-directory FCT, where this type of documentation can be found.
• TYPE corresponds to the different types of documentation: for instance ADC, AD, ACV, etc. The code after it is the documentation code.
• anchor corresponds to a paragraph anchor, when it is requested to be directly placed on a given paragraph. The anchor is not taken into account if this is a header link.

Each link is explored upon generation: the corresponding documentation is searched in the ADOCUMENT table (if it does not exist, the link is not inserted) and the documentation title is inserted with the text carrying the link.

INC codes (Inclusion)

This paragraph is used to include such or such paragraph already present in another documentation.

Any paragraph can be included, except for paragraphs of type TIT. When it is requested to reuse a presentation paragraph associated to another documentation, the INC paragraph replacing it must be the first of this type in the documentation and must link to another paragraph of type PRE.

Since several INC paragraphs can exist in such documentation, the anchor corresponding to these paragraphs is INC_LEV_SLEV, where LEV represents the level and SLEV the sub-level.

The paragraph to reuse must then be identified in the text of the inclusion paragraph in one of the following forms:

• TYPE/CODE
• TYPE/CODE/NIVEAU/SOUS-NIVEAU

The level and the sub-level are not mandatory (the paragraph of same level and same sub-level being recovered by default in the linked documentation).

For instance, when it is requested to insert the paragraph relating to the first tab of the user record, which is defined at level 40 and sub-level 200, the text in the inclusion paragraph is the following:

AFC/GESAUS/40/200

Note that everything is recovered from the source paragraph (title, text, layout, field helps), except for the level and sub-level which remain the same as in the original paragraph (the breaks in the tables of contents are thus respected). The title of the table of contents corresponds to the title of the original INC paragraph; the created anchor can be used for links and corresponds to a generic INC_row_sub-row anchor.

Paragraphs reserved for the other documentation

These paragraphs are specific to documentation types other than documentations on functions. These are the following:

LEV code (level)

This paragraph is specific to documentations on parameters. It is generated from the dictionary at level (30,10).

Upon final generation, a text is generation specifying the setup definition level, as well as the name of the associated global variable if it exists. If no global variable can be found, a text saying that there is none is inserted, except if the text of the record is assigned (in this case, the text may refer to a variable not declared in the dictionary).

REM code (remarks)

This paragraph is specific to documentations on parameters, on automatic journals and on default dimension codes. It is created empty from the dictionary at level (70,10).

The text in the record is made available to enter miscellaneous remarks.

PAR code (parameters for the actions)

This paragraph is specific to documentations on actions. It is generated from the dictionary at level (30,10) in order to make possible the display of a list of action parameters.

Upon generation of the final documentation, an introduction sentence is created, followed by a grid displaying the parameters, their title and type of data. When there is no setup, a negative sentence is inserted.

UTI code (use of the action)

This paragraph is specific to documentations on actions. It is created empty from the dictionary at level (40,10).

The text entered in the record is supposed to describe the use of the action.

If this paragraph remained empty at the moment of the final documentation generation, it is not generated.

ACT code (actions associated to the actions)

This paragraph is specific to documentations on actions. It is generated at level (50,10) in order to make possible the display of the list of actions linked to the documented action. The generation is made from the links (and reciprocal links) found between action and action.

Upon generation of the final documentation, an introduction sentence is created, followed by a grid displaying the actions with a link to the corresponding documentation.

REC code (recommended values)

This paragraph is specific to documentations on parameters and on sizing parameters. It is created empty in the case of parameters and generated in the case of sizing variables (a default line is created if the paragraph is empty, containing the value found in the reference folder). The creation is made at level (30,10).

The text entered in the record is supposed to describe the advised values for the setup in question.

AFC code (functions concerned)

This paragraph is specific to documentations on activity codes, on general parameters and on reports. It is generated at level (40,10) for activity codes and reports, and at level (50,10) for general parameters in order to display:

• the list of functions concerned by the activity code. The generation is based on links reciprocal to the links between functions and activity codes, as well as on the activity codes found during a quick exploration of the dictionary (only the functions directly depending on the activity code are retrieved). Upon generation of the final documentation, an introduction sentence is created, followed by a function list with a link to the corresponding documentation.
• the way to access the report (print groups and list of the functions likely to launch the report). The generation is then made by analyzing the dictionary and by reading the links common to the links between functions and reports. Upon generation of the final documentation, an introduction sentence is created, followed by an automatic text specifying whether the report can or cannot be directly run, to which print group it belongs and a list of functions likely to launch the report with a link to the corresponding documentation.
• the functions impacted by the setup.

AT2 code (tables to be entered)

This paragraph is specific to documentations on import/export templates. It is generated at level (30,30) with the style 4 in order to display the list of tables that are supposed to be entered to be able to use the corresponding template. It is a sub-paragraph of the PRQ chapter. The generation is made from the links between import/export templates and table (of type AT2).

Upon generation of the final documentation, the tables are displayed in a grid and are preceded by an introduction sentence. A link is included pointing to the table dictionary and to the object when it exists, which makes it possible to manage the table in question. If there are tables common to all folders, they are isolated in a dedicated paragraph.

CHO code (mandatory fields)

This paragraph is specific to documentations on import/export templates. It is created empty at level (40,10) in order to display the list of fields supposed to be mandatory for the template to work.

CRI code (launch criteria)

This paragraph is specific to documentations on reports and documentations on sub-programs.

In the case of reports, this is a paragraph generated by default at level (30,30) with the style 4 using the data of the report dictionary in order to generate the following automatic texts:

• an introduction sentence followed by the list of report parameters (a negative sentence is displayed if there is no setup).
• a sentence specifying the specific behavior of start/end parameters if any.
• a sentence specifying that one of the parameters can be entered with several values if this is the case (segmentation of the report).
• a sentence specifying, if this is the case, that data are filtered according to the site depending on the user authorizations.
• a sentence specifying, if this is the case, that a report can only be printed on a specific type of printer.

In the case of sub-programs, this is a paragraph generated by default at level (20,30) with the style 4 using the data of the sub-program dictionary in order to list the parameters to transmit to the sub-program.

DES code (description of the report)

This paragraph is specific to documentations on reports. It is created empty at level (40,10) in order to describe the report content.

CTX code (context)

This paragraph is specific to documentations on Workflow, on events triggering statistics and on entry points.

For events triggering statistics and for the workflow, this paragraph is created empty at level (30,10) in order to describe the triggering context.

For entry points, there can be several paragraphs of this type. As a matter of fact, a documentation on entry point can integrate several entry points. Each time, an APE paragraph is created, defined at level 20 and sub-level 10, with an increment of 10 on all levels. An associated CTX paragraph is created at the same level as the corresponding APE paragraph, at sub-level 20. The anchor corresponding to these paragraphs is then BME_LEV_SLEV, where LEV represents the level, and SLEV the sub-level).

When generating the final documentation, this paragraph integrates automatic sentences saying:

• that there is or there is not a current transaction (link of type TRS from the processing dictionary; the associated value 1 means that there is no transaction, the value 2 that there is one).
• that there is or there is not an open log file (link of type TRA from the processing dictionary; the associated value 1 means that there is no open log file, the value 2 that there is one).

This paragraph also integrates a list of online tables in the form of a grid. This list is obtained using links from the processing dictionary to tables, a link of type ATB meaning that the table is open and entered in the context, a link of type AT2 meaning that the table is open. Note that these links can be entered in the form CODE_TABLE [ABBREVIATION] when the table is not opened under its main abbreviation.

APE code (entry point)

This paragraph is specific to documentations on entry points.

For entry points, there can be several paragraphs of this type. As a matter of fact, a documentation on entry point can integrate several entry points. Each time, an APE paragraph is created, defined at level 20 and sub-level 10, with an increment of 10 on all levels. the corresponding anchor is then APE_LEV_SLEV, where LEV represents the level, and SLEV the sub-level). An associated CTX paragraph is created at the same level as the corresponding APE paragraph, at sub-level 20.

When the functional documentation is generated from the dictionary, this chapter is automatically created at level 20 with the style 10. The next ones are created by counting levels by tens. The entry point code is retrieved through an APE link, the associated name gives the entry point code. This link can be followed by links of type ATB, AT2, TRA, TRS. The declaration order is important: since there can be several APE links, the other links are supposed to refer to the last link declared.

The code of the entry point can also be found in the paragraph title. This code must remain in the title header (it can be completed by an explanation, separated from the code by a space or an opening bracket). If this precaution is not taken, the final documentation cannot be generated properly.

Upon generation of the final documentation, these paragraphs integrates automatic sentences saying:

• that there is or there is not a current transaction (link of type TRS from the processing dictionary; the associated value 1 means that there is no transaction, the value 2 that there is one).
• that there is or there is not an open log file (link of type TRA from the processing dictionary; the associated value 1 means that there is no open log file, the value 2 that there is one).

They also integrate a list of online tables in the form of a grid. This list is obtained using links from the processing dictionary to tables, a link of type ATB meaning that the table is open and entered in the context, a link of type AT2 meaning that the table is open. Note that these links can be entered in the form CODE_TABLE [ABBREVIATION] when the table is not opened under its main abbreviation.

OPM code (operation mode)

This paragraph is specific to documentations on automatic journals and on default dimension codes. It is created empty at level (30,10) in order to describe the operating mode.

FLW code (Description of the information flow)

This paragraph is specific to documentations on reports. It is never created automatically, but it is advised to place it on (40,10). It is used to describe the Workflow sequences in which this event takes place.

Summary of the paragraph structures

There are for each type of documentation the generated paragraphs and their default structure presented below (paragraphs INC, LNK, MIS and MIN can be freely inserted).

AFC (documentation on the function)

This documentation, which is created in the FCT directory, can contain the following paragraphs:

TIT		10,10	Title
	PRE	10,20	Presentation
PRQ		30,10	Prerequisites
	ACV	30,20	Activity codes
	ADP	30,30	Parameters concerned
	ANM	30,40	Counters
	GAU	30,50	Automatic journals
	CDE	30,60	Default dimensions
	HAB	30,70	Authorizations
	TRS	30,80	Entry transactions
	GTC	30,80	Inquiry screens
	PRD	30,90	Miscellaneous prerequisites
ECR		40,50	Screen management
	ENT	40,100	Header
	ON1...	40,200*rank	Tab no. 1...
	BOT...	40,sniv préc+5...	Right clicks on grid lines
	BOU	70,10	Button introduction
	BOU	70,10+10*no	Buttons on window
	BME	80,10	Menu item introduction
	BME	80,10+10*no	Bar menu items
	INC	80.500 / 80.510 = 80.520	Menu item to manage the documentation (if the function is of type object and the object code is present in the miscellaneous table no. 910, a menu entry Documentation is automatically created. In order to take this entry into account, a link is created pointing to the 3 corresponding paragraphs as defined in the annex documentation ADO_FCT)
ARP		50,10	Reports
ABT		60,10	Batch task
ERR		90,10	Errors
ATB		100,10	Updated Tables

ADP (documentation on setups)

This documentation, which is created in the OBJ directory, can contain the following paragraphs:

TIT		10,10	Title
	PRE	10,20	Presentation
LEV		30,10	Definition level
ADP		40,10	Linked parameters
AFC		50,10	Functions concerned
ACV		60,10	Concerned activity codes
REM		70,10	Remarks

ACT (documentation on actions)

This documentation, which is created in the OBJ directory, can contain the following paragraphs:

TIT		10,10	Title
	PRE	10,20	Presentation
LEV		30,10	Action parameters
UTI		40,10	Action usages
ACT		50,10	Linked actions

Concerning the PRE paragraph:

• its content can be directly viewed in the action dictionary and can be directly modified from this dictionary.
• a default text is generated in the paragraph if it is empty. This text specifies that this is an internal action not to be used in a specific development.

ACV (documentation on the activity codes)

This documentation, which is created in the OBJ directory, can contain the following paragraphs:

TIT		10,10	Title
	PRE	10,20	Presentation (empty if depends on activity code)
REC		30,10	Advised values (not generated if depends on activity code)
AFC		40,10	Functions concerned
ACV		50,10	Linked activity codes

ADM (documentation on sizing variables)

This documentation, which is created in the OBJ directory, can contain the following paragraphs:

TIT		10,10	Title
	PRE	10,20	Presentation
REC		30,10	Recommended values
ATB		100,10	Tables concerned

AOE (documentation on import/export templates)

This documentation, which is created in the OBJ directory, can contain the following paragraphs:

TIT		10,10	Title
	PRE	10,20	Presentation
PRQ		30,10	Prerequisites
	ADP	30,20	Parameters to enter
	AT2	30,30	Tables to enter
CHO		40,10	Mandatory fields
ERR		90,10	Errors
ATB		100,10	Tables concerned

ARP (documentation on reports)

This documentation, which is created in the OBJ directory, can contain the following paragraphs:

TIT		10,10	Title
	PRE	10,20	Presentation
PRQ		30,10	Prerequisites
	AFC	30,20	Access to the report
	CRI	30,30	Criteria
DES		40,10	Description
ATB		100,10	Tables concerned

AWA (documentation on Workflow)

This documentation, which is created in the OBJ directory, can contain the following paragraphs:

TIT		10,10	Title
	PRE	10,20	Presentation
CTX		30,10	Context
FLW		40,10	Description of the flow
ATB		100,10	Tables concerned

CDE (documentation on dimension codes)

This documentation, which is created in the OBJ directory, can contain the following paragraphs:

TIT		10,10	Title
	PRE	10,20	Presentation
OPM		30,10	Operating mode
REM		70,10	Remarks

CDA (documentation on destinations)

This documentation, which is created in the OBJ directory, can contain the following paragraphs:

TIT		10,10	Title
	PRE	10,20	Presentation
OPM		30,10	Operating mode
REM		70,10	Remarks

GAU (documentation on automatic journals)

This documentation, which is created in the OBJ directory, can contain the following paragraphs:

TIT		10,10	Title
	PRE	10,20	Presentation
OPM		30,10	Operating mode
ECG		40,10	Generated entries
REM		70,10	Remarks

PS1 (documentation on triggering statistics)

This documentation, which is created in the OBJ directory, can contain the following paragraphs:

TIT		10,10	Title
	PRE	10,20	Presentation
CTX		30,10	Context
REM		70,10	Remarks
ATB		100,10	Tables concerned

ATB (dictionary for the tables)

There is only one paragraph for this type of documentation, which is created in the MCD directory:

TIT

10,10

Title

AML (dictionary for local menus)

There is only one paragraph for this type of documentation, which is created in the MCD directory:

TIT

10,10

Title

ATY (dictionary for data types)

There is only one paragraph for this type of documentation, which is created in the MCD directory:

TIT

10,10

Title

ADC (dictionary for entry points)

This documentation, which is created in the OBJ directory, can contain the following paragraphs:

TIT		10,10	Title
APE		10+10*no,10	Entry point description
	CTX	10+10*no,20	Context

ASU (documentation on sub-programs)

This documentation, which is created in the OBJ directory, can contain the following paragraphs:

TIT		10,10	Title
	PRE	10,20	Presentation
CRI		20,10	Criteria list

Concerning the PRE paragraph:

• its content can be directly viewed in the sub-program dictionary and can be directly modified from this dictionary.
• a default text is generated in the paragraph if it is empty. This text specifies that this is an internal sub-program not to be used in a specific development.

AGB (documentation on variables)

This documentation, which is created in the OBJ directory, can contain the following paragraphs:

TIT		10,10	Title
	PRE	10,20	Presentation

Concerning the PRE paragraph:

• its content can be directly viewed in the variable dictionary and can be directly modified from this dictionary.
• a default text is generated in the paragraph if it is empty. This text specifies that this is an internal variable not to be used in a specific development.

APM (intermediate menus)

This documentation, which is created in the OBJ directory, can contain the following paragraphs:

TIT		10,10	Title
	PRE	10,20	Presentation
REM		70,10	Remarks

AD (On-line help for the language)

This type of documentation is used in two cases:

• when a function of type Menu exists, the generation creates a documentation of type APM, with only one paragraph of type TIT. The final generation searches the list of functions associated to the menu in order to list the corresponding functions. The links can be directly added in the paragraph in this specific case (same syntax as for LNK paragraphs) in order to add menu lines below these found elsewhere in the dictionary.
• all the intermediary menus associated to miscellaneous documentations (activity codes, Workflow event, etc.) are of type APM, with a name beginning with the code associated to the documentation type, followed by a "_" character and a qualifier (module, group) if necessary to have available intermediary menus, the main menu having the code TYPE_0. For instance:
• the intermediary menus associated to activity codes are: ACV_0 (root), ACV_1 (activity codes associated to the module number 1, ACV_2, etc.
• the intermediary menus associated to the parameters are: ADP_0 (root), ADP_TC (parameters of the TC category), ADP_SUP (parameters of the SUP category), etc.

Note that the creation of another documentation enabling intermediary menus, must be created as a DI documentation including the following paragraphs: a TIT paragraph on (10,10), a PRE paragraph on (10,20), which can be empty, possibly a first LNK paragraph on row (10,30) in order to enter navigation links in the title bar, and a LNK paragraph with a row superior or equal to 20 to list the menu link items.

FI (Files to be extracted)

This type of documentation is created in the 4GL directory. This documentation has a free structure. The only mandatory paragraph is:

TIT

10,10

Title

When this is the only paragraph, no file linked to the record can be generated, but the linked file, if present, is extracted under the documentation name. This functionality was designed to allow a full recovery of the existing 4GL doc, each document being seen as a file in the base.

As soon as there is more than one paragraph (notably when adding paragraphs of type MIS or MIN), the documentation is created according to the usual rules.

Note that a documentation which code ends with the characters _D is created with a file ending with character $. As a matter of fact, in order to prevent the creation of keys containing special characters, this renaming rule is applied. Thus, the functions seg$, chr$ and getenv$ are represented by the records SEG_D, CHR_D and GETENV_D.

Other types of documentation

This is a specific type: this is only a tag for files to extract. The naming principles are the following:

• a documentation of type FI and of code XXXXX_nnn is a tag for files to extract in the XXXXX directory (any standard directory can be thus defined). It is possible to create as many paragraphs as needed to defined for instance different file groups.
• a _nnn documentation is a tag for files to extract in all XXXXX directories for which there is a documentation of type FI and with code XXXXX_nnn. Basically, upon generation of the documentation of type FI and of code XXXXX_nnn, there is a control to verify if there are paragraphs of same level and same sub-level in the corresponding documentation of type FI and of code _nnn (the number must be the same). If there are, these files are extracted first. The files linked to the documentation of code XXXXX_nnn can be extracted only after. It is thus possible to define in such a documentation common files, some of which can be overwritten upon extraction of the corresponding documentation of code XXXXX_nnn.
• the documentation of type FI and of code _ (only one character "underscore") is a tag for files which generation triggers the creation of files in the help root directory. When this documentation is generated, all the files attached to documentations of type FI and of code _nnn are extracted if the first number of the code is 0 (and if the level and sub-level correspond).

Other types of documentation

The other types of documentation (DI, IN, CS, DL, AM) are documentations which structure is not defined (but whose generation directories are defined with respect to the type). The only mandatory paragraph is the TIT paragraph.

When this is the only paragraph, no file linked to the record can be generated, but the linked file, if present, is extracted under the documentation name.

As soon as there is more than one paragraph (notably when adding paragraphs of type MIS or MIN), the documentation is created according to the usual rules.

The generation directories are specified in the grid below:

TYPE OF DOCUMENTATION	GENERATION DIRECTORY
DI   (miscellaneous documentations)	AFC
IN   (installation documentations)	INSTALLATION
CS  (console documentations)	CONSOLE
DL  (delta development documentations)	DLT
AM  (development template documentations)	MODEL

Documentation tables of contents

The tables of contents forming the documentation are linked to the APM documentation types. There is usually only one paragraph in this case:

TIT

10,10

Title

This paragraph can contain a list of documentation codes in the form of a text. In this case, each item of the list is added as a link to the documentation in question (the title of the linked documentation being reused in the documentation in question). This makes it possible to create tables of contents manually or to add additional links to an existing table of contents.

As a matter of fact, upon generation of the documentation from the dictionary, documentations of type APM are automatically generated with only the TIT paragraph. The grid below describes the codes of the created documentations and the tables of contents generated in the documents created upon final generation:

Type of table of content	Generation code	Content of the table of content
Function table of contents	The code of the menu is ADMIN	List of the menu functions
Setup table of contents	ADP_chapter, where chapter is the chapter to which the setup belongs. The dictionary is generated when launching the dictionary generation for a chapter setup. ADP_0 is the table of contents at superior level. The dictionary is generated as soon as a dictionary is generated for a setup.	List of the chapter parameters grouped by group (ADP_chapter), and list of the chapters (ADP_0)
Sizing variable table of contents	ADM_module, where module is the module number (local menu 14) to which the sizing variable belongs. The dictionary is generated when launching the dictionary generation for a module variable. ADM_0 is the table of contents at superior level. The dictionary is generated as soon as a dictionary is generated for a sizing variable.	List of variables for the module (ADM_module), and list of the modules (ADM_0)
Report table of contents	ARP_group, where group is the group to which the report belongs. The dictionary is generated when launching the dictionary generation for a group report. ARP_0 is the table of contents at superior level. The dictionary is generated as soon as a dictionary is generated for a report.	List of group reports (ARP_group), and list of the groups (ARP_0)
Activity code table of contents	ACV_module, where module is the module number (local menu 14) to which the activity code belongs. The dictionary is generated when launching the dictionary generation for a module activity code. ACV_0 is the table of contents at superior level. The dictionary is generated as soon as a dictionary is generated for an activity code.	List of the activity codes of the module (ACV_module), and list of the modules (ACV_0)
Action table of contents	ACT_module, where module is the module number (local menu 14) to which the action belongs. The dictionary is generated when launching the dictionary generation for a module action code. ACT_0 is the table of contents at superior level. The dictionary is generated as soon as a dictionary is generated for an action code.	List of the action codes of the module (ACT_module), and list of the modules (ACV_0)
Import/export template table of contents	AOE_module, where module is the module number (local menu 14) to which the template belongs. The dictionary is generated when launching the dictionary generation for a module template. AOE_0 is the table of contents at superior level. The dictionary is generated as soon as a dictionary is generated for an import/export template.	List of the import/export templates of the module (AOE_module), and list of the modules (AOE_0)
Workflow rule table of contents	AWA_category, where category is the code of the category to which the rule belongs. The dictionary is generated when launching the dictionary generation for a category rule. AWA_0 is the table of contents at superior level. The dictionary is generated as soon as a dictionary is generated for a Workflow rule.	List of the Workflow rules of the category (AWA_category), and list of the categories (AWA_0)
Automatic journal table of contents	GAU_module, where module is the module number (local menu 14) to which the automatic journal belongs. The dictionary is generated when launching the dictionary generation for a module journal. GAU_0 is the table of contents at superior level. The dictionary is generated as soon as a dictionary is generated for an automatic journal.	List of the automatic journal of the module (GAU_module), and list of the modules (GAU_0)
Dimension code table of contents	CDE_module, where module is the module number (local menu 14) to which the dimension code belongs. The dictionary is generated when launching the dictionary generation for a module code. CDE_0 is the table of contents at superior level. The dictionary is generated as soon as a dictionary is generated for a dimension code.	List of the dimension codes of the module  (CDE_module), and list of the modules (CDE_0)
Payment attributes table of contents	CDA_0 is the table of contents (at one level only). The dictionary is generated as soon as a dictionary is generated for a payment attribute.	List of payment attributes (CDA_0)
Entry point table of contents	ADC_module, where module is the module number (local menu 14) to which the processing belongs. The dictionary is generated when launching the dictionary generation for a module processing. ADC_0 is the table of contents at superior level. The dictionary is generated as soon as a dictionary is generated for a processing.	List of processings for the module (ADC_module), and list of the modules (ADC_0)
Purge rule table	AHI_module, where module is the module number (local menu 14) to which the automatic journal belongs. The dictionary is generated when launching the dictionary generation for a module rule. AHI_0 is the table of contents at superior level. The dictionary is generated as soon as a dictionary is generated for a purge rule.	List of the import/export templates of the module (AHI_module), and list of the modules (AHI_0)
Table of contents of events triggering statistics	PS1_module, where module is the module number (local menu 14) to which the event belongs. The dictionary is generated when launching the dictionary generation for a module event. PS1_0 is the table of contents at superior level. The dictionary is generated as soon as a dictionary is generated for an event triggering statistics.	List of events for the module (PS1_module), and list of the modules (PS1_0)

For all types of documentations other than those listed above, it is possible to create a documentation which code is INDEX. If this documentation exists, a link is created directly from each documentation of this type in the title bar. Documentations of type IN, DL for instance use an index of this type.

Management of documentation tables

The documentation structure is stored in ADOCUMENT table. For each paragraph and sub-paragraph, this table stores their characteristics (level, sub-level, title, activity code...).

The paragraph text is stored aside in ADOCCLB table. This table only contains the elements of the paragraph keys, and the text itself.

Here is the point of this structure:

• all standard paragraphs of the documentation are stored in the supervisor root folder.
• When a folder is created, the ADOCUMENT table folder is duplicated which is never the case for the document texts.
• Any specific paragraph addition is to be performed within the child folder, as the associated texts are stored in the same folder.
• Any modification to a standard paragraph triggers its copy to the ADOCCLB table from the root folder to the child one.

Actually, only the specific texts are stored in the child folder.

This is the same thing for the texts linked to field help: the standard texts are stored in ADOCFLD table of the root folder, the specific texts are stored in the folder itself.

When the documentation is generated, the stored structure is searched in the local folder and for each paragraph, the text of the local folder is retained. If the folder does not contain text, then the text from the root folder is retained.