This transaction is used to maintain user profiles.

To select a user, either the user code is entered or the user in question is searched for by clicking the icon.

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

• Adding a User Profile
• Modifying User Profile
• Deleting User Profile
• printing user profile(s).
• creating User Profile List
• showing Version Log of the modifications to the user profile(s).
• Limited Modification of User Profile
• Assign Users Entity Access

The icons to block and release are used to change to the “Releasing User” transaction. This allows blocked users to be reset. If a user has been blocked, his/her password can be reset by a user who has access to user maintenance even though this user may not have security administration rights. Clicking only resets the password status, but does not allow any other fields to be modified.

This function helps to keep the circle of users with the highest access rights as small as possible.

Information on how to administer passwords can be found in “Maintaining TradeDesign Rights”.

Details on the usage of the “Security Administrator” and “Designer” checkboxes can be found in “Administration of Users” under “General Information”.

Although it is possible to integrate the application user profiles concerning user mnemos and login procedures in other system logins (customizations required are built in when the system is implemented), it is also necessary to provide the application system with all user information so that the system can access the required information for processing business transactions.

The following status levels are used in the administration of passwords:

User Status	Definition
Normal	Valid user with valid password (not displayed)
Expired	Valid user but the password (not displayed) has expired. At the next login using a valid password, the user will be asked to change his/her password.
Blocked	The user has been blocked. This function is used if a user leaves the bank or the department and is no longer to have access to the application. If a wrong password has been entered into the system (3 attempts), the system automatically sets the status of the user to Blocked. The system administrator either can Reset the user (with new password set by the system administrator) or set the status to Expired or to New Password
Reset	The user has been blocked (either manually or automatically). The system administrator may Reset and has to enter the new password (displayed as **). After clicking the user profile automatically changes to 'Normal'. The password last used is now enabled again.
New Password	The user has been blocked or has forgotten his/her current password. The system administrator may set the status to 'New Password' and enters the new password (displayed with **) for the first login. After clicking the user profile automatically changes to 'Expired', so that the user has to enter again a new password on the first login.

The 'Reset' option should only be used in special situations, since the system administrator knows the current password of respective user. Using the option 'New Password' is in most cases the best option since only the password for the first login is entered by the system administrator and the respective user must change his/her password on the first login.

The “Status” will be displayed as previously selected and saved within the system. If no “Status” is available (i.e. there is no corresponding record in file TDRIGHTS.INI), then a 'New Password' will be defaulted.

When adding users to a multi-entity system, the login status is only set to 'New Password' when the user is first defined. Please ensure that the name of user groups is unique throughout the system.

The processing of the data elements is only possible in the default entity of the user. When processing user entries in the other entities, these data elements are only displayed and cannot be modified.

Users can only be completely removed from the system when they are no longer contained in an Entity or Entity Group (see “Entity and Entity Groups”) . Only then is a user deleted from the TDRIGHTS.INI file.

TFaaS administrators can only change or remove other TFaaS users.

There are two ways to prevent a user from logging in to the system:

Within the TradeDesign Login System a Blocked Flag is set, so that a future login is not possible when using the TradeDesign Login System. This function is enabled via the “Status” combobox and the 'Blocked' option.

This function is used to lock a user temporarily e.g. in case a password has been found out.

The entry for this user ID within the TradeDesign Login System is deleted. In doing so, all information about the last used passwords, last login etc. are removed and a new login is also not possible any more. The profile cannot be enabled easily, but the user has to be set up again in the TradeDesign Login System by enabling the login profile.

This function is used to refuse a user's login permanently without removing him/her technically from the system, so that his/her name and other data will not be lost. As a result, a user ID can still be used. This function should be used if a user has left a department, for example, and thus may not have any access to the system. Via the function “Replacement of Responsible User”, those contracts in which this user was entered as a responsible person can be transferred to another user.

The other data of the user profile will not be changed by the actions mentioned above.

The “System Login / Logout Control” transaction allows the system to block all users temporarily. This might be necessary during system maintenance work, for example.

Background processing usually runs under a special User ID. This User ID is not assigned to any regular user, but still has a wide range of access options.

To avoid the possibility of this User ID being used for foreground processing, the ID should not be stored in user static data. The configuration of this User ID is described in the “Background Processing of Transactions” section in the developer documentation.

If the “Manager for interactive Queue Entries” (QUETSK) is used for automated workload distribution (Queue System) to distribute the workload to be handled to the employee resources still available or if Service Level Agreements are to be supported, the working times should be known.

Based on the office hours recorded in the Entity Group (see Maintaining Entity Groups), different times may be defined for the Entity (see Maintaining Entities).

For users whose working times differ from the office hours of the Entity, these departures should be entered in the “User Working Times” panel. Only those days need to be entered on which the times differ.

For the user selected, the usual working times can be defined for each weekday. If the fields “Time from” and “Time until” are filled for specific days, then the difference in hours is automatically calculated on the basis of the working hours capable of being planned. For weekdays on which the user does not work, the “Closed” checkbox is to be checked.

In the field “Share of working hours capable of being planned ahead”, a percentage between 0 and 100 can be entered, which is incorporated in the calculation of hours and via which it can be specified whether an employee is available 100% for the processing and settlement of business or only temporarily, as applicable.

The Application Profile field is used to specify which queue entries can be assigned to the user. A selection can be made from the list of *.tda files in the ini folder of the application.

Whether a certain queue type can be assigned is defined by means of a semi-colon in the *.tda file, with “;” representing the type that can be assigned. For example:

• If a user is not to be assigned any incoming items (Type INC), this must be defined by 'INC= X'.
• If a user is to be assigned diary dates (Type DIA), then this must be defined by ';DIA=X'.

If no user profile is selected for a user, he or she can have all types of queue entries assigned.

Model files exist in the demo database.

In connection with the Management Dashboard module, it is helpful if the user's color scheme can be configured. Before a color setting is possible for the individual user in the “Color” field, first of all a color family needs to be assigned to the user group. This setting is to be made in the Maintaining User Groups transaction in the “Color for Charts” field for the user's user group.

After that, in this transaction a color variant may be selected in the “Color” field from the color defined for the user group. This setting causes all queue entries assigned to the user to be displayed in the defined color in the Dashboard diagrams.

If no color has been defined for a user, then these entries will be displayed in the diagrams in gray.

The Assigned Entity panel displays the list of entities the user is assigned to and the user's home entity. It also specifies if the user has access granted to those entities or not, with reason for the same.

If a user is marked as designer he is able to change sources in the development tool TRADE2. He also gets some additional debug information in case of problems. If a dump occured designer have the chance to continue processing after the dump file was created.

In addition he has some special rights in the installation. Designer are allowed to

• start transactions directly with 'launch transaction'
• edit codetable entries
• edit report definitions
• edit document rules
• convert character set of a file during copy in SYSIXU, if user is also system administrator
• create manual dumps, see the field inspector and save screen images from context menu

If a user is marked as system administrator he has some additional rights compared to a standard user. In addition he is launched to system administration (SYSADM) in case there is a technical problem during his login. If a dump occured system administrators have the chance to continue processing after the dump file was created. He also gets some additional debug information in case of problems.

System administrator are allowed to

• edit codetable entries
• run BIC update for more than the configured number of entries at once
• create and edit user
• edit TradeDesign configuration via DBITDR
• handle transactions from all entities in DBWTRN
• delete all types of pending entries
• edit print configuration in rerouting of incoming messages
• cleanup message archives with SYSCLN
• convert character set of a file during copy in SYSIXU, if user is also designer
• shut down the whole system from SYSMGR
• edit incoming SMC entries in SMCTSK and update their status manually

If a user is tagged with this flag he is allowed to change XML literals with the document editor module within business transactions. Full document editor functionality including change of rule text is only available for Designers.

If a user is allowed to change user data he can only handle other SaaS users if he is tagged as SaaS user. A user with empty SaaS user flag can edit all users including the SaaS user.

User Profile
User Authorization
Printer configuration
User Working Time
Assigned Entity Access
Obscure Password