Navigation
This function is used to parameterize the transfer of a context between the calling function and the function called by the tunnel. This context consists of both the possibility to define the default values and the additional filters in the different left lists.
The ADONIX X3 software makes it possible very simply to navigate from a function to a table managed in the form of an object, without having to open a secondary session. This is carried out using the notion of the tunnel.
A tunnel is called from outside the standard object menu by different means :
- either using the key (or by a contextual menu obtained via the right click) from a key for the object. This behaviour is standard in the software, provided that the navigation is not from a operating function to a parameterization or development function. For example, on order entry, for a field of the type customer code, the navigation is to the customer management, which makes it possible to view the record of the current customer or to create one on the fly. On the other hand, in analytical nature entry, it is not possible to tunnel to the pyramid management for the natures (which are considered as being part of the parameterization).
- or to use the key on the link shown in the link explorer.
- or by using navigation by right click on a workbench or an enquiry.
- or by the use, from an existing function, of an item in the Functions menu when this menu exists (this is notably the case in the database records and in the CRM module functions).
Important notes
it should be noted that the opening up of a function in a secondary session by combined use of the to key (function keys that can be parameterized by means of the user personalisation) is not considered as a tunnel and cannot be made the object of a context transfer.
In addition, the navigations are considered as specific/custom development, and not parameterization. This notably signifies that :
- the fields entered incorrectly can lead to a dysfunctioning of the function to which the navigation is applied.
- it is necessary to use an access code to protect it and standardize the naming of the keys related to the specific/custom navigations as described below, or risk losing the navigations created when changing the version or during folder revalidation.
Prerequisite
Refer to documentation Implementation
Screen management
Header
Presentation
The definition of a navigation condition is made in a record in two tabs Filters and Creation.
Close
Fields
The following fields are present on this tab :
Block number 1
| Identifier for the navigation. The standard navigation shipped as standard are identified by a code starting with 2 or 3 characters identifying the module to which the starting function is attached (these codes are standardised in miscellaneous table 901). Any specific/custom navigation must start with the one of the letters X, Y or Z and be protected by an activity code. |
|
|
Block number 2
| The name of the calling function (i.e. the one from which the tunnel is triggered). |
| The name of the object called by the tunnel. It should be noted that it is possible to define a navigation condition for an object XXX in itself, by identifying the calling function as the function GESXXX, and in the called object the code XXX. These navigation conditions are called if the object is called directly from a menu (excluding any tunnel). This is used to more easily define the default values during the creation of a record in an object outside the tunnel. |
| Select a Module for the setup. Use this field to specify whether the screen has to be created in the folder database or not. It is specified when the module linked to the screen is active in the folder. |
| Select this check box to activate the current record. Disabled records keep their content and setup but cannot be used (by recalling their code) on other records (documents, settings ...), or for mass processes. The authorizations to a given function can prohibit the creation of an active record. In this case, the check box is disabled by default. It can only be modified by an authorized user or through a signature Workflow. |
| An activity code is used to:
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. |
Close
Tab Filters
Presentation
The first tab is then used to define the contextual filters that are going to be applied to all the left lists in the object, in order to only display part of the records in the table managed by the object. In order to do this the conditions and the filters are entered in the first tab. Once the condition is met, the filter is applied.
Close
Fields
The following fields are present on this tab :
Grid
| Contextual filters applied to all the left lists for the object, in order to only display part of the records in the table managed by the object. Once the condition is met, the filter is applied. |
|
|
Close
Tab Creation
Presentation
The second tab is used to define the default values that will be used if creating a record in the tunnel context. Entered in this second tab are the variables to be entered (these are the variables coming from the mask, they are therefore defined using the syntax [M:xxx]VARIABLE) and a calculated expression that can include the variables coming from the context, the constants, the functions and operators.
The default values are assigned, in the logic of the object, just before the action RAZCRE. If the default values other than those defined in the object, they are the navigation values that have priority (the field being considered as initialised, the standard initialisation of the object has not taken place in these fields). Warning, it should also be noted that these default values can no longer be used for the fields entered in the grids with a variable number of lines.
Close
Fields
The following fields are present on this tab :
Grid
| Mask variables to be entered. They are therefore defined with the syntax [M:xxx]VARIABLE) |
| Calculated expression can intervene in the variables coming from the contexts, the constraints, the functions and the operators. Its value will load the field specified on the line, in record creation in the context of a tunnel, as a result of the navigation. |
Close
Other conditions
Parameterization context elements.
Certain context variable can be very useful :
The variable GNAVIG (1.. ) contains the stacked function codes. For example, this variable is to be tested to assign the default values, in addition to that defined by the navigation parameterization, when creating the record. Warning, the function triggering the menu occupies two lines ; this is used to define a navigation when coming from the menu (example : GESBPC => Object BPC).
The variable GPILNAV is the number of stacked functions.
The variable TUNNEL is set to 1 if in a tunnel context( this will normally always be the case if the navigation is not made from the function to its object)
The variable TUNCLE contains the code of the key at the time of launching the tunnel ; this field is always alphanumeric and of a maximum length equal to 30 (a numeric field has been converted by the function num$).
The variable GPILLNK, if it is not zero, indicates that the tunnel is made by the link explorer.
In the context of the object, the transaction code is found in the variable GFLAG, and the name in the window in GBOITE. This is used to link the navigation filters for the variant of the object.
The variables that are on line are all those coming from the calling context (that is to say as a minimum the on line mask variables).
The variable NAVIG can be loaded by the process in order to force a function in the stack. In fact, when the process triggering the navigations is not called by a function, a corresponding function will be created in the dictionary and this function will be assigned to the stack on starting this process. Example : navigation HDK00007, with start-up function FUNDSC1.
A practical example of the usage (not shipped as standard) could be as follows. A user TOTO, during entry of account postings must frequently create accounts. He/she enters the account number, confirms the field and obtains the message Account non existent. The user then selects a tunnel and wants to create as simply as possible the account that needs to be used. But in order to avoid creating by accident an account that already exists, it would be useful to display a left list that contains all the accounts with the same root as the one the user entered (the first 4 characters). This can easily be obtained by defining the following navigation :
code = X00001, an activity code XNA protects the record (for example).
calling function = GESGAS ; called object = GAC
filter triggered on the following condition : TUNCLE<>"" & GPILLNK=0 & GUSER="TOTO", with the following filter expression : ACC>=left$(TUNCLE,4) & ACC<=left$(TUNCLE+"000",4)+"999999"
assignment of [M:GAC0]ACC with the help of the formula string$(GUSER="TOTO" & GPILLNK=0,TUNCLE)
Another example of the usage (not shipped as standard) could be as follows. During order creation (not via the tunnel), the field Referencefor the order must be initialised with the name of the user that has created the order, followed by a dash and the date in the form YYMMDD. This can easily be obtained by defining the following navigation :
code = X00002, an activity code XNA protects the record (for example).
calling function = GESSOH ; called object = SOH
assignment of [M:AOH0]CUSORDREF with the help of the formula GUSER+"-"+format$("D :YYMMDD",date$)
Error messages
In addition to the generic error messages, the following messages can appear during the entry :
Function/object pair already defined under XXXXXXX
A navigation has already been entered for the function and the corresponding object (only one navigation can be entered).
Object type is incorrect
A navigation can only be made to and object of the type single or combined (the objects browser and tableau are excluded).