Introduction of applications.
1. User Creation and Maintenance
1.1. Defining Application Users.
1.2. Navigation.
1.3. User Screen.
1.4. Disabling a user.
2. Responsibilities
2.1. Responsibility definition.
2.2. Navigation.
2.3. Responsibilities screen.
2.4. Disabling a Responsibility.
3. Menus.
3.1. Menu.
3.2. Navigation.
3.3. Menus Screen.
4. Concurrent Programs.
4.1. Definitions.
4.2. Limiting Active Requests by User.
4.3. Stages.
4.4 Request Sets as Concurrent Programs.
4.5. Request set and Owners.
4.6. Concurrent Programs screen shots.
4.7. Request Set screen shot.
4.8. Request Groups screen shot.
5. Profiles.
5.1. Overview.
5.2. Assigning a profile to user.
5.3. How to Define a Profile?
5.4. Setting up Profiles.
6. Printers
6.1. Definitions.
6.2. Printer Types.
6.3. Printer Register.
6.4. Printer Driver.
7. Concurrent Manager.
7.1 Defining new managers.
7.2 Concurrent Managers Window.
7.3. Work shift Window.
7.4. Specialization Rules Window.
8. Businesses and Instances.
9. Support Central.
10. Cases / Solutions.
Oracle Applications System Administration
Oracle application modules integrate corporate data across functional departments such as finance, human resources, supply chain management, manufacturing, e-business, and customer relationship management.
A System Administrator is a person responsible for controlling access to Oracle Applications and assuring smooth ongoing operation.
The tasks performed by System Administrator
Security Control and its management: Responsible for assigning the access of each application and in each application forms, functions, reports etc to the users.
Defining new users: Includes registering new Oracle Application users and giving them access to the required forms, function and reports to do their jobs.
Auditing users activities: Monitoring the user activities and to choose user and type of data to audit.
Setting user profiles: To set user profile values at site, application, responsibility and user levels.
Oracle Application System Administrator vs. Oracle DBA
An Oracle Applications System Administrator administers the user interface or applications side of Oracle Applications.
An Oracle Database Administrator (DBA) administers the data that users enter, update, and delete while using Oracle Applications.
1. User Creation and Maintenance
An application user is an authorized user of Oracle Applications who is uniquely identified by an application username. Once defined, a new application user can sign on to Oracle Applications and access data through Oracle Applications windows.
1.1. Defining Application Users
The system administrator allows a new user to sign-on to Oracle Applications by defining an application user. An application user has a username and a password. An initial password should be defined, and then the first time the application user signs on, they must enter a new password.
When an application user is defined, the system administrator assigns one or more responsibilities to the user. If only one responsibility is assigned, the user, after signing on, immediately enters an application.
If two or more responsibilities are assigned, the user, after signing on, sees a window listing available responsibilities.
1.2. Navigation: SecurityUsersDefine
1.3. User Screen:
User Name:
The earlier convention that was followed to identify the users was last name followed by their first initials (6+2). But now the SS0 is used to identify the users.
Password:
The system administrator assigns the initial password for the user. The first time an application user signs on, they must change the password.
If the user forgets the password, then the system administrator can reassign the password.
Password Expiration
Days
The maximum number of days between password changes should be entered here. A pop–up window prompts an application user to change her or his password after the maximum number of days a system administrator specified has elapsed.
Accesses
The maximum allowed number of sign–ons to Oracle Applications allowed between password changes. A pop–up window prompts an application user to change her or his password after the maximum number of accesses a system administrator specified has elapsed.
Effective Dates:
From/To:
The user is active only between the effective dates. The default for the start date is current date and if the end time is not mentioned then the user is active indefinitely.
Responsibilities Block:
Responsibility:
Select a responsibility, which is to be assigned to the user.
1.4. Disabling a user:
To disable a user, end date a user.
2. RESPONSIBILITIES
2.1. Responsibility:
A responsibility is a level of authority in Oracle Applications that lets users access only those Oracle Applications functions and data appropriate to their roles in an organization.
A user has at least one or more responsibilities and several users can share the same responsibility. A system administrator can assign users any of the standard responsibilities provided with Oracle Applications, or create new custom responsibilities.
2.2. Navigation: SecurityResponsibilityDefine
2.3. Responsibilities screen:
Responsibilities block:
Responsibility Name: The name of the responsibility is to be mentioned here.
Application: The application under which the responsibility is to be assigned has to be mentioned here.
Responsibility Key: This is a unique name for a responsibility.
Effective Dates:
From/to: Enter the start/end dates on which the responsibility becomes active/inactive. The default value for the start date is current date and if the end date is not entered then the responsibility is valid indefinitely.
Data Group: The data group defines the pairing of application and Oracle username.
Menu: Select a menu name, which is already defined with Oracle Applications.
Menu Exclusions Block: Define function and menu exclusion rules to restrict the application functionality accessible to a responsibility.
Type: Select either function or menu as the type of exclusion rule to apply against the responsibility.
Name: Select the name of function or menu that is to be excluded from the responsibility.
The function or menu specified must already be defined in Oracle Applications.
2.4. Disabling a Responsibility: A responsibility cannot be deleted. It can be deactivated at any time by setting the end date to current date. If a responsibility is to be reactivated then set end date to a date after current date or clear the end date.
3.MENUS
3.1. Menu:
A menu is a hierarchical arrangement of functions and menus of functions. Each responsibility has a menu assigned to it. A system administrator can restrict the functionality a responsibility provides by defining rules to exclude specific functions
or menus of functions.
Define the lowest–level submenus first. A submenu must be defined before it can be called by another menu.
3.2. Navigation: ApplicationMenu
3.3. Menus Screen:
Menus Block
Menu
Choose a name that describes the purpose of the menu. Users do not see this menu name.
View Tree: Once a menu is defined, its hierarchical structure can be seen using the ”View Tree...” button.
User Menu Name: User menu name is used when a responsibility calls a menu or when one menu calls another.
Menu Entries Block :
Sequence: Enter a sequence number to specify where a menu entry appears relative to other menu entries in a menu. A menu entry with a lower sequence number appears before a menu entry with a higher sequence number.
Navigator Prompt:
The prompt entered here is seen in the hierarchy list of the navigator window.
Submenu:
Call another menu and allow a user to select menu entries from that menu.
Function:
Call a function which is to be included in the menu.
Description:
Descriptions appear in a field at the top of the Navigate window when a menu entry is highlighted.
Grant:
If grant is enabled, only then the prompt will be visible on the navigator window.
4. Concurrent Programs
4.1. Definitions:
A concurrent program is an executable file that runs simultaneously with other concurrent programs.
When a user runs a report, a request to run the report is generated. The command to run the report is a concurrent request. The program that generates the report is a concurrent program.
Request group is a collection of reports or concurrent programs. A System Administrator defines report groups in order to control user access to reports and concurrent programs. Only a System Administrator can create a request group.
Request sets define run and print options, and possibly, parameter values, for a collection of reports or concurrent program. End users and System Administrators can define request sets. A System Administrator has request set privileges beyond those of an end user.
Standard Request Submission is an Oracle Applications feature that allows selecting and running all the reports and other concurrent programs from a single, standard form. The standard submission form is called Submit Request.
The reports and concurrent programs that may be selected from the Submit Requests form belong to a request security group, which is a request group assigned to a responsibility.
The reports and concurrent programs that may be selected from a customized Submit Request form belong to a request group that uses a code.
4.2. Limiting Active Requests by User:
A System Administrator can limit the number of requests that may be active (status of Running) for an individual user. This ensures that a user cannot monopolize the request queue. For example, if a user with an Active Request Limit of 5 submits 20 requests, only 5 requests will be run at the same time. The remaining requests will be run when the number of active requests for the user drops below 5. Use the Profile Options window to set the Concurrent: Active Request Limit profile. To set a global limit for all users, set this option at the site level. You can then modify limits for individual users by setting this profile option at the User level.
4.3. Stages:
Organizing Request Sets into Stages
Request sets are divided into one or more ”stages” which are linked to determine the sequence in which requests are run. Each stage consists of one or more requests that you want to run in parallel (at the same Time in any order).
To run requests in sequence, assign requests to different stages, and then link the stages in the order as user wants the requests to run.
The concurrent manager allows only one stage in a request set to run at a time. When one stage is complete, the following stage is submitted. A stage is not considered to be complete until all of the requests in the stage are complete.
One advantage of using stages is the ability to run several requests in parallel and then move sequentially to the next stage. This allows for a more versatile and efficient request set.
.
Using Stage Status
Like request sets and concurrent requests, stages can complete with different statuses. Each stage can complete with a status of Success, Warning, or Error.
For example: a request set always begins with Stage 1. If Stage 1 completes with the status Success, then the Success link is followed, and Stage 2 is submitted. After Stage 2 completes, the set ends. If Stage 1 completes with Warning, then the Warning link is followed, and Stage 3 is submitted. After Stage 3 completes, the set ends. If Stage 1 completes with Error, then the Error link is followed, and Stage 4 is submitted. After Stage 4 completes, the request set ends.
Linking of Stages
There are no restrictions on linking stages within a request set. Any stage may be linked to any other stage, including itself. Two or more links can point to the same stage. For example, Stage 1 can link to Stage 2 if the completion status of Stage 1 is Success or Warning, and link to Stage 3 if the status is Error.
Stage Evaluation Function
The completion status of a stage is determined by a predefined function. The Oracle Applications Standard Stage Evaluation function uses the completion status of the requests it contains. Use this function to determine the status of a stage.
Request Set Completion Status
When a stage completes with a status for which there is no link defined, the request set ends. The completion status for the request set is determined by one of the following methods:
Using the completion status of the last stage run in the request set. This method is used by default.
The user can override the default behavior by defining a specific stage within the set to be”critical”. If the request set runs a critical stage, then the completion status of the set will be the same as the completion status of the most recently run critical stage. This can be useful if the final stage of the set is a ”clean up” stage and is not considered important to the overall status of the set.
Note: If a printer is defined for a concurrent program using the Concurrent Programs form, then that value cannot be updated, either by a user profile option setting, a request set definition, or when running the program or request set.
4.4 Request Sets as Concurrent Programs
When a user define a request set or a stage within a request set that allows incompatibilities, a concurrent program is created to run the requests in the request set according to the instructions you enter. All concurrent programs that run request sets are titled Request Set
A request to run the request set concurrent program or the request set stage concurrent program is a Parent request, while the requests to run the programs and reports are Child requests.
The status of a request set can be reviewed and the programs it contains using the Concurrent Requests form. The following table displays request phase and status information that pertains to request sets.
Modifying Request Sets
A System Administrator can only modify by its owner or a request set. To make modifications, query the request set that has to be modified in the Request Set window.
Note: If modifications to request sets provided by Oracle application during upgrades is to be retained, then rename or recreate the request set using a different name before upgrade. If a user modifies a predefined request set without changing the name, then modifications are overwritten while upgrading Oracle Applications.
4.5. Request Sets and Owners
There are significant differences between end user and System Administrator privileges when defining or editing request sets.
End users own the request sets they create
An end user can create a request set by selecting reports, other request sets, or concurrent programs that are part of the report security group assigned to his responsibility.
When an end user creates a request set, the user automatically becomes the “owner” of the request set.
End users use the Request Set form to create a new request set, or to query and update any request sets they own. End users can only edit request sets they own.
Other users cannot access your private request sets using the Submit Requests window unless the System Administrator assigns that request set to a request security group.
When a user signs on to Oracle Applications, the user can run requests, request sets, and concurrent programs included in:
their responsibility’s request security group
any request sets they own.
When User does not own request set:
All users can submit request sets that are added to a their request security group even if they contain requests that are not in the request security group. If the user does not own the request set, they:
cannot edit the request set.
cannot run an individual report by itself, but can only run the entire request set.
When User owns request set:
If the user owns the request set, they:
Can add any other requests in their request security group to the request set.
Can delete any request from the request set, regardless of whether that report is in their request security group.
Can update print options or parameters for an individual report in the request set, if the report is in their request security group.
Cannot run an individual report by itself, but can only run the entire request set.
4.6. Concurrent Programs screen shots:
Step 1: Define Executable
Navigation: Concurrent -> Program -> Executable
Execution File Name – Is the name of the actual executable file in the Top Directory.
Step 2: Define Concurrent Program:
Navigation: Concurrent -> Program -> Define
See the Screen Shot below:
Enter Executable Short Name as the Executable Name for the concurrent program.
To disable the concurrent program uncheck the Enable options.
To enable trace check the Enable Trace option.
To enter parameters click on the Parameters button.
4.7. Request set screen shots
When we use the same set of concurrent program regularly we define a request set. Request Sets are divided into ‘stages’ which are linked to determine the sequence in which the request are run.
Navigation: Concurrent -> Set
Click on Define Stages & then define Stages.
Click on Request & specify the concurrent program.
Click on Parameter to view the parameters of the program.
Request stage status:
To submit a request:
1. Navigate to the Submit a New Request window (Other -> Requests -> Run).
2. Check the Request option to submit single requests, or choose to submit a predefined group of requests by checking Request Set.
3. Choose OK.
Submitting requests
4. Use the Copy... button to take advantage of previously entered request submissions.
5. Select the Name of the request (report or program), which is to be run from the list of available requests.
Note: Responsibility's request group determines which requests appear in the list.
To see the status of submitted request
4.8. Request Groups screen shot
Once the concurrent programs & request sets are defined they need to assigned to the request group. The request group is intern assigned to the responsibility & thus the users can submit the programs.
Navigation: Security -> Responsibility -> Request.
5. Profiles
5.1. Overview:
A User profile is a set of changeable options that affect the way the application looks and behaves. A system administrator has to control how oracle applications operate by setting user profile options to the value that is desired.
Profile can be set at four levels:
Site Level.
Application Level.
Responsibility Level.
User level.
Site level profile: The site level profile is an option settings pertain to all users at an installation site.
Application level profile: The Application level profile is an option settings pertain to all users of any responsibility associated with the application.
Responsibility level profile: The Responsibility level profile is an option settings pertain to all users at an installation site.
User level profile: The User level profile is an option settings pertain to an individual user.
The system administrator can set default option values at any of these levels.
5.2. Assigning a profile to the user:
A system administrator uses the system profile values window to set profile options for the user community. If an administrator changes a user profile option value changes takes effect as soon as users log on again or change responsibilities.
Navigation:
If only specific user profile options is to be displayed,
1. First choose Enter from the View, Query by Example menu to enter search criteria in the Profile Name field, and then choose Run from the View, Query by Example menu to run the search.
The name of the user profile option appears in the Profile Name field while the Default Value field displays the run-time value of that option. The System Administrator sets default values for many of the profile options. Some profile options may not display a default value.
2. Move the cursor to the User Value field of the option whose value is to be modified..
3. Enter a new value for the option if it is updatable, or if the
- lamp appears, choose a value from the list of available values.
If the profile option is not updatable, the message "Item is protected against update," appears on the message line when the value is changed. Most of the user profile options can be changed; values entered in the User Value field override values preset by the System Administrator. A few profile options cannot be changed, but are displayed for informational purposes only.
For most personal profile options, Oracle Applications automatically checks the value entered to ensure it is valid.
Attention: Number or date values are not validated, therefore, it is to be made sure that a valid value is entered for profile options that require a number or date; otherwise, the personal profile option may not work as expected.
Though a profile option cannot be deleted from personal profile, its value (if it is updatable) can be cleared by highlighting the field and pressing [Backspace] or by choosing Clear, Field from the Edit menu. If the value is cleared, the change does not take effect until relogin or responsibilities are changed.
4. Choose Save from the File menu to save the change.
The change will take effect when either responsibility are changed or log out and log back in
5.3. How to Define a Profile?
Responsibility: Application Developer
Navigation: Profile.
5.4. Setting up of Profiles
Profiles are set at four levels, viz
Site
Application
Responsibility
User
Responsibility: System Administrator
Navigation: Profile -> System
Click on Find.
6. Printers
The Printer setup is normally performed by the system administrator (responsibility).
6.1. Definitions:
Print Styles: The dimensions of a report are determined by the column and row values in the print style defined in the Print Styles form that overrides the width and height values in the SRW driver.
Printer Drivers: A printer driver includes the initialization and reset strings. A defined printer driver is needed for each print style that will be used with a specific printer type on a specific platform.
Navigation: Install printer
The following steps to setup printer(s) should be performed in the following order:
6.2. Printer Types: Install printer Types
The printer types must be defined if it is not predefined with Oracle Applications. Any name can be chosen. It is on this form on which the print style is being associated with a printer driver for the particular printer type.
Printer Types Form Screen
An example for a line printer, it can be named as LINE. This name will be associated to the actual printer name when the printer is registered to Oracle Applications.
6.3. Printer Register
The Printer type should be defined before registering a new printer.
The value for printer name will be the operating system printer name, and then choose the appropriate printer type.
Printer Types
Associate the required printer style and printer driver to the printer type from this form.
Print Styles
To define new print styles, this form is used. The sample print styles are Portrait, Landscape, A4, etc.
6.4. Printer Driver
To define new printer driver, this form is used.
NOTE:
Many printers can be registered as the same printer type.
A printer type can support multiple print styles.
A printer driver must be assigned to a printer type for each print style.
Many printer drivers can support the same print style.
Many printer drivers can support the same printer type.
7. Concurrent Manager
A concurrent manager is itself a concurrent program that starts other concurrent programs running. When an application user submits a request to run a program, the request is entered into a database table that lists all of the requests.
Concurrent managers read requests from the table and start programs running.
7.1 Defining new managers
While defining new managers:
Assign a predefined library of immediate concurrent programs to the manager. Immediate concurrent programs are subroutines associated with concurrent managers.
Assign work shifts to the manager, which determines what days and times the manager works.
For each work shift, define the maximum number of operating system processes the manager can run concurrently to read requests (start programs) during the work shift.
Specialize the manager to read only certain kinds of requests.
The Internal Concurrent Manager:
It functions as the "boss" of all the other managers. The Internal Concurrent Manager starts up, verifies the status of, resets, and shuts down the individual managers.
The Standard manager:
It accepts any and all requests and has no specialization. The Standard manager is active all the time; it works 365 days a year, 24 hours a day.
Transaction Managers
Transaction managers support synchronous processing of particular requests from client machines. They are implemented as immediate concurrent programs. At runtime, concurrent processing starts a number of these managers. Rather than polling the concurrent requests table to determine what to do, a transaction manager waits to be signaled by a client program.
Each transaction manager can process only the programs contained in its program library.
A transaction manager is associated with a particular data group, and uses that data group to connect to the database.
7.2 Concurrent Managers Window:
Concurrent Managers Block
The combination of an application and the name defined for manager uniquely identifies the manager. To restrict a manager to only running programs associated with certain applications, go to the Specialization Rules window.
Type
The type of manager (concurrent manager, internal monitor, transaction manager) is selected here.
Cache Size (Concurrent Manager only)
The number of requests the manager remembers each time it reads which requests to run is entered here. In reading requests, the managers will only put requests it is allowed run into its cache.
Data Group (Transaction Manager only)
The data group the transaction manager uses to connect to the database. Transaction managers only run programs submitted from responsibilities that use the same data group as the transaction manager.
Program Library
Concurrent managers can run only those immediate concurrent programs listed in their program library. They can also run concurrent programs that use any other type of concurrent program executable as long as the specialization rules include them. Transaction Managers can only run programs listed in their program library.
Work shifts:
A work shift defines the dates and times the manager is enabled. The number of programs the manager can run simultaneously can be varied with each work shift.
7.3. Work shift Window
Work shifts are defined using the Work Shifts form.
Work Shift
The work shift that has to be assigned to the manager is selected here.
Processes
The number of operating system processes the work shift has to run simultaneously is entered here. Each process can run a concurrent request.
Sleep Seconds
Sleep time is the number of seconds the manager waits between checking the list of pending concurrent requests. The default value is 60 (seconds).
Specialization Rules:
These rules are used to define what kinds of requests the manager has to read. Without specialization rules, a manager accepts requests to start any concurrent program.
7.4. Specialization Rules Window
Include/Exclude
Select from the pop list whether or not to include or exclude those requests that are based on the rule to run.
Type
The type of specialization rule that is to be assigned to the manager is selected.
8. Businesses and Instances
11.0.3
gepsesd38
gepsese38
gepsesp39
gepsest37
gepsord38
gepsorp39
gepsort37
CMF (Customer master file/Support master file)
CMF Prod-gpsorc77
CMF Prod-gpsorc40
gpsorc81-dev
FRMT (Field Resource Management tool)
Dev
frp82-frmtprod
SIT-test instance-gpsrt117
NRS (Network reliability services ERP)
apd40-NRPSDEV8
ASCP (patch)-gpsamx79
ASCP(SIT)-gpsamd79
ASCP(test)-gpsamt79
ASCPProd-gpsasp10
Dev-gpsemd40
gpsed140-Dev instance
gpspt117
NRS Prod gpsnsp11
Patch-gpsemx40
SIT-gpsme120
Test-gpsms120
Parts-CPG
gpsapa79
gpsapi79-Ascp sit
gpsapi79
gpsapm79
gpsapt79
GPSCSX40
gpses117
gpsesd81
gpsesd81-oltp Dev
gpsesm81
gpsesp76
gpsesp82
gpset117
T117
Products-BOP (Balance of power)
General Integrated Dev-gpsord81
GL Team Dev-gpsgld81
GPSAPX81
gpshxe40
gpspad81
Hungary Integrated Test-gpsort40
Hungary Prod-gpsorp77-GL
Hungary Prod Support-gpsore40
Manufacturing Dev-gpsmfd81
Wind
gpswdd81-Dev
gpswdp82
gpswds40
gpswdt40-Test1
gpswdt40
Aero
*
*
*
*
Instance details site: http://3.235.168.71:7777/dba/main.htm
Note:
All the instances end with d development instances.
All the instances end with e, s, t, m, x and c Test instances.
All the instances end with p Production instances
9. SUPPORT CENTRAL
Support central is the tool used by System Administration team to receive cases.
After getting into support central, we can choose any of the seven options available under show depending on the requirement.
The seven options are:
All cases
Open cases
New cases
Pending [Expert]
Pending [User]
Closed cases
Archived cases
ALL CASES:
This gives the information of all the cases like open cases, pending cases, new cases etc.
Details available in all cases:
Case#: A unique number identifies every case.
Logged by: This gives the name of the person who has submitted the case.
Case owner: This gives the name of the system administrator who has opted to attend the case.
Date: This gives the date of submission of the case.
Subject: This gives the subject of the case like user management, profile management, etc.
Case description: This gives the description of the case in brief.
Status: This gives the status of the case whether new, closed or pending.
Severity: Based on the severity the system administrator has to prioritize the case. Severity of the case may be normal, urgent or business critical (First priority).
Mode: This gives the mode through which the case has been received (like email).
The screen shot for all cases:
Open Cases: This gives the information of all the opened cases.
New Cases: This gives the information of all the new cases.
Pending [EXPERT] Cases: This gives the information of all the cases that has been forwarded to another expert.
Pending [USER] Cases: This gives the information of all the cases that needs more information from the user in order to solve the case. The system administrator asks the user to update the case with the missing information.
Closed Cases: This gives the information of all the closed cases.
Archived cases: All the cases that are required for future reference are stored here
.
How to go about Support Central:
Go to new cases and check for a case that has not been owned.
While taking up a case give first priority to business critical cases.
Check for the subject and know what type of case it is.
Open the case and understand the case by going to the request link.
If the case can be solved then take ownership by clicking on take ownership option, which appears on right side of the screen when a new case is opened.
Check for the information required to solve the case. If all the information is available then solve the case.
Else ask the user to update the case by providing all the missing information (by replying to the user in the reply box and clicking the send button on the left side). This case now comes under pending [user] cases.
Once the case is solved, then update the user about the same by giving a reply in the reply box.
Note down the case# which has been solved in excel sheet.
Close the case by clicking the send/close button on the right side.
If the case cannot be solved under any circumstances then pass it on to another expert by clicking on Check to keep the case in "Pending (Expert) " Queue. Write a comment in the comment box about the proceedings of the case for the other expert to understand. Then send it by clicking the send button on the left side. This case now comes under pending [expert] cases.
Notes:
All the GL cases are notified in the mailbox (not in support central).
Take up a case based on severity and act accordingly.
Always case escalations are to be avoided.
If a case cannot be solved before the expected closure date then modify the expected closure date (this will save the case from escalation).
Always try to solve escalated cases.
If any information is required from the user then try to ping (same time) him or contact him through DC (dial comm. incase of Employee) or mail and get the details.
If case is needed for future reference, then put it under archived cases.
It is always advisable to maintain a checklist of all the cases you solved.
10. Cases / Solutions
10.1. User Management Cases:
New User Creation:
If there is a case for new user creation, then first the employee is created in the Oracle Application and then the user is created with the requested responsibilities. Here it is very important to know last name and first name of the user, email id, SS0 and the employment type i.e. whether the user is an employee of GE or a contractor. If these informations are not provided, then the user is asked to update the case with required information.
10.1.1. Employee Creation in CPG – gpsesp76:
Responsibility – CS US Purchasing Super User
Navigation – Setup -> Personnel -> Employees
10.1.2. Employee Creation in Product (BOP) – gpsorp77
Responsibility – Global HR Manager
Navigation – People -> Enter and Maintain
To find an employee enter the Employee Number & click find. To create a new employee record click on new.
If there is already a user with user id in the form of 6+2 and he wants his id to be changed to SSO form, then first delete the employee details; save it and end date the user (6+2 form). Now create a new employee with the mentioned details and create the user as requested (employee details has to be unique for every employee).
Password Reset:
If a user requests for an account creation, but his id already exists in the application and he has been end dated. Then the end date is to be removed and password has to be reset to the default i.e. oracle. The user id and the password have to be updated to the user.
Disabling a user:
If a user account is to be closed, then the user is to be end dated in the user form.
10.2. Responsibility Management Cases:
Assigning Responsibilities to a user:
Add the requested responsibilities in the user form and update the user about the same.
If a user already has few responsibilities but wants more responsibilities to be added, then those responsibilities are to be added without making any changes to the previous responsibilities.
If a user requests for a responsibility that has been end dated from his account, then modify the end date from the user form and update the user about the change.
If a user requests for a responsibility that itself has been end dated, then update the user about the same without making any change to the responsibility.
No comments:
Post a Comment