Maintaining Office Menu

The following transactions can be started from here by clicking the icons in the list below for:

• Adding an Office-menu
• Modifying Office Menu
• Deleting Office Menu
• printing office menu(s).
• creating List of System Menus
• showing Version Log of the modifications to the office menu(s).

Applicable restriction: Menu items need to be typed matched, i.e. any one menu can only contain submenu entries “or” transactions, not a mixture of both. This constraint applies when creating a new menu, as well as modifying an existing one. If a menu, newly created or existing, contains entries of one type, trying to add an item of the other type will throw an error at Save time. Analogously, if your menu contains (say) several transactions, it will not be possible to convert one of them to a submenu. In order to preserve type consistency, either have transactions (as before) or convert all of them to become submenus.

The screenshots reproduced below illustrate the constraint and its outcomes. In the first scenario, we attempt to convert a convert a menu to a transaction, when all other items are menus. Using the same example source, in the second case we undertake to add a transaction (when again all other items are menus). The results are identical in either situation: The system reports an error, and the changes made prevent saving.

The Office menu consists of

• Menu and
• Transaction profile

The term menu refers to the left-hand side of the screen, which provides users with quick and direct access to all the transactions. The menu itself is displayed permanently. Transactions can be group into a maximum of 4 levels. However, the transactions listed in the menu vary depending on a user's access rights and on the business/commercial context of a loaded contract. At least one (or any number of menus xxx) must exist, and they are stored in the sysmnu_xxx.ini file.

The menu entries can be spread over multiple rows by typing '\n' as a line break command. This will adjust the height on the menu entry automatically.

The transaction profile governs whether a specific transaction can be executed or not. For so-called “Top Level Menus” at least one *.tdp file must exist under a name that is identical to that of the menu.

The transaction allows various Office menus to be created for accessing the transactions in the menu. The creation of Office menus facilitates the organization and the regulation of access to the various parts of the application, since the access concept for each individual bank can be defined via the Office menus.

Such an access profile must be assigned to every user via his user profile (see Maintaining User Profiles).

The “Default transaction” field specifies the transaction to be started whenever a user logs on to whom this profile was assigned. The following options are available

• DOKA-NG - The Next Generation Trade Finance Solution
• Dashboard Office - Teamleader - with the display of various charts
• Dashboard Office - Manager Information - with the display of various charts.

If a new language has to be added in the application, then it has to be added both in TDPARA.INI (through DBxTDP in “Language” panel) and in “UILTXT” codetable (through SYSTBL). In order to have a consistent language set, the new language will only be visible in the dropdown when it is added at both TDPARA.INI and “UILTXT”. Adjustments of menu entries for a particular language should be done in “Menu” panel by selecting required option in “Language” dropdown field.

An existing menu can be selected via the “Menu” field. In the MyModelbank, menus for clerks (do5clerk), officers (do5off), administrators (do5adm) have been already defined as examples. Selecting the menu for the clerk will display the entire menu tree to assist visualization. In the menu tree, clicking on the arrows alongside the directory structure will display additional or fewer levels of the tree structure.

If a specific menu is to be changed, it can be selected by double-clicking it, and then editing using .

Existing profiles can be copied using the icon. The icon is visible when creating a new profile using the icon , i.e creating a new profile.

There are 4 types:

• Menu (defines the menu item; a sysmnu_<Menu name>.ini file with the same name must exist.
• Transaction (defines transactions that can always be accessed, regardless of the current context, e.g., the static data transactions DBIxxx)
• Optional transactions (defined transactions that are displayed depending on context, e.g., amendment transactions that can only be executed if a contract already exists)
• Function (not yet supported)

Entries inside one menu can be moved up or down with the icons or .

With icon two check functions are available:

• For one transaction can be checked, in which menus this transaction is registered.
• With button [Check Menu] a list of those (sub-) menus is shown, which are not used in any menu.

Access profiles consist of several parts that are saved to the application's INI directory.

The TradeDesign section is MAC-protected, which means it cannot be changed outside the application. It is saved under <profile name>.tdp. The profile file contains the information about the default transaction and other executable transactions previously entered via the “Transaction profile” panel.

Menu Tree
TDP Profile
Menu

Clicking the button 'Grant' will grant access rights to transactions, pressing the button 'Revoke' will revoke access rights for transactions. The pattern for which transactions the action will be be executed, must be defined in the field 'Transaction Pattern.
Allowed wildcards are '?' and '*'

Clicking the button 'Load' will add missing transactions to the transaction grid. The directories “frame”, “ttolib” and table “ATP” are scanned. The execution flag will automatically be set to the value defined in the checkbox 'Execution flag'.