Your screen and layout sets decimals are affected by :-

OY01 - Country Global Parameters -> Double click on the country code

SU01 - Maintain users -> Click Defaultsbutton

In the Decimal format section.

How to solve the Time Zone Definition Problems?

The Time zone is defined in table TTZCU(refer to note: 91667) for System wide and Client wide.

If you want it for individual user, go to SU01 under the default Personal Time zone sections.

Settings for individual users is done when you have global users in different time zone.

For Local users only, go to SM30 and change the table TTZCU. e.g. UTC+8

This is done when your Spool time is incorrect.

In "USER MAINTENANCE- SU01" --> in the "logon tab" there are 5 different "user type"

1. dialog
2. system
3. communication
4. service
5. reference

Kindly mention the function and role of all the above mentioned user types specifically and how is one user type different from another.

::Dialog (A)::

User type for exactly one interactive user (all logon types including Internet users):

During a dialog log on, the system checks whether the password has expired or is initial. The user can change his or her password himself or herself.

Multiple dialog logons are checked and, where appropriate, logged.

::System (B)::

User type for background processing and communication within a system (internal RFC calls).

A dialog logon is not possible.

The system does not check whether the password has expired or is initial.

Due to a lack of interaction, no request for a change of password occurs. (Only the user administrator can change the password.)

Multiple logons are permissible.

::Communication (C)::

User type for dialog-free communication between systems (such as RFC users for ALE, Workflow, TMS, and CUA):

A dialog logon is not possible.

Whether the system checks for expired or initial passwords depends on the logon method (interactive or not interactive). Due to a lack of interaction, no request for a change of password occurs.

::Service (S)::

User type that is a dialog user available to a larger, anonymous group of users. Assign only very restricted authorizations for this user type:

During a log on, the system does not check whether the password has expired or is initial. Only the user administrator can change the password (transaction SU01, Goto ® Change Password).

Multiple logons are permissible.

Service users are used, for example, for anonymous system accesses through an ITS service. After an individual authentication, an anonymous session begun with a service user can be continued as a person-related session with a dialog user.

::Reference (L)::

User type for general, non-person related users that allows the assignment of additional identical authorizations, such as for Internet users created with transactions SU01. You cannot log on to the system with a reference user.

To assign a reference user to a dialog user, specify it when maintaining the dialog user on the Roles tab page. In general, the application controls the assignment of reference users. This assignment is valid for all systems in a Central User Administration (CUA) landscape. If the assigned reference user does not exist in a CUA child system, the assignment is ignored.

You should be very cautious when creating reference users.

If you do not implement the reference user concept, you can deactivate this field in accordance with SAP Note 330067.

We also recommend that you set the value for the Customizing switch REF_USER_CHECK in table PRGN_CUST to "E". This means that only users of type REFERENCE can then be assigned. Changing the Customizing switch affects only new assignments of reference users. Existing assignments are retained.

We further recommend that you place all reference users in one particularly secure user group to protect them from changes to assigned authorizations and deletion.

Purpose

The user administrator performs all tasks that are relevant to user management and role assignments. In the portal, all user management functions related to users and groups are provided by the user management engine (UME). The UME is integrated in the SAP NetWeaver Application Server (AS) Java.

For more information about the administration functions of the UME, see Administration of Users and Roles.

In this section you can find information about concepts that need additional clarification in a SAP NetWeaver Portal context. These are:

● UME Actions in the Portal – a brief description of how UME actions are integrated in the portal.

● UME Roles and Portal Roles – an explanation of the difference between these two types of roles and how they are both used in the portal.

In addition, you can find information about administration functions that are specific to the portal. These are:

● Assigning roles to users and groups

● Mapping users – for Single Sign-On purposes

Features

● In a portal installation, the UME provides you with tools for performing user management tasks in a set of iViews and worksets integrated in the User Administration role in the portal

Use

The user management engine (UME) uses UME actions to enforce authorizations. An action is a collection of Java permissions that define which activities a user can perform. UME actions can be assigned to UME roles or portal roles. If a role with a UME action is assigned to a user, the user gains the authorizations provided by the action. The UME verifies that users have the appropriate UME actions assigned to them before granting them access to UME iViews and functions. Other applications can also define or check for actions.

The following table lists the UME actions assigned to portal roles by default.

Portal Roles with Default UME Actions

Portal Role	Assigned UME Actions
Delegated User Administrator	UME.Manage_Users UME.Manage_Role_Assignments
Every User Core Role	UME.Manage_My_Profile
Standard User Role	UME.Manage_My_Profile
Super Administrator	UME.AclSuperUser UME.Manage_All
System Admin	UME.System_Admin
User Administrator	UME.Manage_All

Some UME actions are defined specifically for the portal environment:

· UME.AclSuperUser

· UME.Manage_Role_Assignments

· UME.Remote_Producer_Read_Access

· UME.Remote_Producer_Write_Access

Integration

In the portal, you can assign UME actions to portal roles with the Role Editor. Each UME action is listed as a property in the Property Editor for roles. Set an action to Yes to assign it to the portal role and change the role's authorizations. This information is recorded in the Portal Content Directory (PCD), which is why you cannot use the delete function of identity management to remove actions from a portal role. When try to delete the role with identity management, the UME only removes the user and group assignments. You must edit the role manually either in identity management or the Role Editor.

In the portal, you can manage both user management engine (UME) roles and portal roles. Both types of roles determine what users can do, but each with a different focus. The following table lists the main differences between these two types of roles.

Comparison of UME and Portal Roles

UME Roles	Portal Roles
Are a container for UME actions (actions are sets of Java permissions).	Are a container for portal content (iViews, worksets, folders, and so on).
Define a set of authorizations. By assigning a UME role, you define what authorizations a user has to run applications on the J2EE engine. The authorizations are defined by the UME actions in the role.	Defines how content is grouped together and how it is displayed in the portal. By assigning a portal role, you define which content a user sees in the portal. Like UME roles, you can assign UME actions to portal roles.
Are stored in the user management tables of the J2EE database.	Are stored in the Portal Content Directory (PCD) tables of the J2EE database.
Are created with identity management.	Are created in the Role Editor of the Portal Content Studio.
Protect access to applications on the J2EE engine.	Constitute a small part of the authorization concept of the portal. When you assign a portal role to a user or group, they get end user permission on the role. You can define role assigner permission on a portal role. Users or groups that are granted role assigner permission on a portal role can assign the portal role to users or groups.

Tools

The tools need to manage UME and portal roles are identity management and the Portal Content Studio. The following table lists the main differences in use of these tools.

Comparison of Identity Management and Portal Content Studio

Activity	Identity Management	Portal Content Studio
Create and edit roles	UME roles	Portal roles
Assign UME actions	UME roles and portal roles	Portal roles
Assign roles to users and groups	UME roles and portal roles	None. Can assign portal permissions for PCD objects to users and groups.

To perform these activities you need the required permissions.

More Information:

● Managing Users, Groups, and Roles

● Role Assignment

Example

Carmen Fernandez is assigned to the UME role Administrator and no other role. She has full administrator authorizations on the J2EE Engine, but does not see any content in the portal. In contrast, Oleg Semenov is assigned to the portal Super Administrator role. He can see all the administrator functions when he logs on to the portal, and he has the corresponding authorizations on the J2EE Engine.

With active Central User Administration, you still use transaction SU01 to maintain users, however user maintenance is somewhat different:

· Whether fields are ready for input or not depends on the distribution attributes that you assigned to the field in transaction SCUM. For more information, see Setting Distribution Parameters for Fields.

Only the fields that may be maintained in the system are ready for input.


You can only change a field that is to be maintained globally in the central system. This field does not accept input in the child systems.

· In the central system, the user maintenance transaction also displays the tab page Systems. Here you enter the systems to which users are to be distributed. To display the systems for the corresponding distribution model, use the possible entries help. Each time you save, the system distributes the user data to these listed systems.

· The Roles and Profiles tab pages each contain an additional column for each entry, specifying the system for which the user is assigned the role and/or profile.

With the Text comparison from child sys. Pushbutton on the Roles and Profiles tab pages, you can update the texts for roles/profiles that you have changed, for example, in the child systems. The texts in the child systems are stored temporarily so that they are available in the central system. As the comparison requires some time, it is performed asynchronously and the current texts may not be available immediately.

You can only assign profiles to users for the systems in which they are distributed. If you enter a new system when you assign profiles to users, the system displays a warning that the user was assigned a new system. The entry is automatically transferred into the tab page Systems. After this, the user master record is also distributed in the new system.

During text comparisons from child systems, the names of the generated profiles for the role are not copied to the central system, that is, only assigned profiles are displayed on the Profiles tab page (such as SAP_ALL or SAP_NEW), but no generated profiles of the roles.

All user master records are created in the user master records. Users can then only log onto the central system if the central system itself is entered in Systems tab page of the corresponding user master record.


You can display the global user data from a child system in the User Information System.

Contains

• User Management Overview
• Central User Administration (CUA)
• SAP LDAP Connector
• Portal User Management
• Role Integration Scenario
• Summary

Download from Rapidshare