This chapter contains information on how to configure modules that provide common, low-level functionality used in many of the higher-level functions described in later chapters.
The common modules are:
Enter Process
Actions Page
Return for Correction
Release Employee Information
Review and Confirm
Dates
Save for Later
Document Management
New User Registration
SSHR includes a number of common functions which are not associated with any particular area of Oracle HRMS. These functions are useful in the everyday operation of SSHR and are intended to improve your self-service processes. An example of a common function is the Enter Person process which is used in the manager self-service functions to select an employee or worker for a transaction.
No. If you select the Manager Actions function from the self-service menu, you select your employee or worker first and can then select the required function from a list of all available functions for the person. The list is context-sensitive. If you are an employee or worker, you can select the Personal Actions function from the menu and you can select the required function from a list of available functions. Again, this list is context-sensitive.
Yes. Before you submit a transaction to the database (as an employee or manager), you can check your data on the Review page. This page shows a summary of any new or changed information and enables you to make any last-minute changes before submitting the transaction to the database. You can also enter comments for approvers in this page.
If you need to provide additional information for an approver, you can add comments in the Review and Confirm page. Also, if the Attachments region is enabled in the Review and Confirm page, you can add an attachment, for example, a file, URL or piece of text.
Yes. You can use the Save for Later button on the Review page to save a transaction to be completed at a later point. Approvers can also use this functionality to return transactions to the initiator for additional information or correction. Suspended and returned transactions are accessed from the All Actions Awaiting Your Attention table on the Actions page.
Yes. The Document Management functionality enables you to automatically generate business documents and notifications using the data from self-service transactions. For example, you could use this functionality to create a Notification of Change or a standard letter. You define which fields are included in the documents using the PDF Forms technology.
Yes. You can use the New Employee and Non-employee Registration functionality to enable your users to create their own users. Employees and non-employees can register with the self-service application and create their own user names and passwords.
The Hierarchy, My List, and Search pages are collectively known as the Enter Process pages.
The Hierarchy page is generally the starting point for all manager self-service functions. It enables managers to select a user record for processing in SSHR.
The navigation options from the People in Hierarchy page depend on the path that the manager has taken to navigate to the page. There are two possible paths:
From the generic Manager Actions menu
In this case, the manager first selects a person the from People in Hierarchy page or the People in My List page. This takes the manager to the Actions page. A context-sensitive list the SSHR modules or actions available for the selected person.
From a specific manager self-service menu item
In this case, the manager selects a specific SSHR function and then selects the person for processing in the People in Hierarchy or People in My List page. When the manager selects a person, the selected function appears.
The People in Hierarchy region displays a hierarchical view of the current manager's subordinates. Users can expand or collapse the lower levels of management as desired.
By default, the hierarchy uses a supervisor hierarchy (based either on the supervisor or the supervisor assignment).
When you move the mouse over the Details icon, you can view the photo of the worker, and details such as employment and contact in a pop-up window.
The My List functionality enables managers to store people whose records they frequently access in a list for quick record retrieval. When a manager searches for a person, they can click the Add to My List button to add that person to the list. When the manager next selects the My List option from the People in Hierarchy page, the names of these saved employees are displayed in a table. A pop-up window displays the people in My List when you place the mouse over the My List link.
As an alternative to the simple search, you can select Advanced Search to specify advanced search criteria. When you select this option, the following standard search fields are available:
First Name
Last Name
Assignment Number
Job
If these fields are not sufficient, you can add additional fields from a list. You can also specify whether the search must include all criteria or whether records that meet only some of the criteria are valid. If required, you can save the search criteria to use again.
Note: When you search for employees using the Basic or Advanced Search, SSHR excludes the log-in person from the results.
A manager can access the personal details for any person included in the Hierarchy or My List simply by clicking the Details icon for the person. SSHR displays the Person Detail view for the person, enabling the manager to display Employment, Salary, Performance, Absence, and Application information for the person. Training information is also available although this tab is hidden as standard. When the Person Details are displayed, the views displayed are summary views. To display more detailed information, expand the view.
For more information, see: Employee Information View.
If a person has more than one assignment for a given manager, the manager needs to select the Action icon for the relevant assignment in order to carry out the action. Managers can view multiple assignments depending on the setting of the HR:Enable Multiple Assignments in SSHR profile option.
The Actions page displays a list of actions that can be performed for a selected person and suspended actions. Suspended actions can include actions that a user has saved for later submission or actions that have been returned to the initiator by an approver, for example, to be corrected.
The list is driven by the hidden submenu defined for the HR: Manager Actions Menu profile option. The default menu for this profile option is the predefined Personal Actions Menu (HR_LINE_MANAGER_PERS_FUNCTIONS).
The list of functions displayed in the Actions page is also defined by the person's legislation code.
See: Data Security Menus
The Actions page can be accessed in one of the following ways:
Managers can click on the Actions icon for a specific assignment to display the actions relevant to the employee or worker
Self-service users can select the Personal Actions menu option from their menu and display their personal actions
The Available Actions list is, by default, limited to those actions the user is currently eligible for.
For information on setting up eligibility see: Eligibility Processing Setup Example.
For further information on eligibility see: Initiating a Self Service Action.
Viewing and processing of ineligible actions is controlled by two profile options:
HR:Allow Use of Eligibility for Self Service Actions
HR:Allow Processing of Ineligible Self Service Actions
When HR:Allow Use of Eligibility for Self Service Actions system profile is set to No (the default), this page does not display the Eligibility column and only eligible actions for the selected person are listed. When this profile option is set to Yes, the page displays the Eligibility column and all actions are listed. The Eligibility column distinguishes between eligible and ineligible actions.
However, a user will not be able to process an ineligible action unless HR:Allow Processing of Ineligible Self Service Actions is also set to Yes. This will enable users to process actions for which the selected person is currently ineligible, but may be eligible by the effective date. The action will still fail if the person is not eligible for the action by the given date.
In order to ensure that the list of eligible actions and sub-actions is up to date, you must periodically run the Participation Batch Process (Run Benefits Manage Life Events Process) for that individual. This can be set to run automatically every time a manager initiates an action by setting the profile option, HR:Run BENMNGLE When Processing a Self Service Action, to Yes.
The application supports multiple simultaneous actions on the same person. To activate this feature you need to set the system profile option HR:Allow Concurrent Self Service Actions to Yes. When this profile option is set to No, the Pending column is displayed which indicates to the user whether pending transactions are present. The user can then review the pending transaction. When you set the profile option to Yes, the Pending column will not be displayed, and users will be able to perform actions against all assignments.
When concurrent transactions are activated potential data conflicts may arise. For information on how to deal with these see Managing Dates in SSHR.
This module can be accessed from the following menus and functions:
User Menu Name | Function Name |
---|---|
Manager Self Service | Manager Actions |
Employee Self Service | Personal Actions |
Manager Self Service | Suspended Actions Mgr |
Employee Self Service | Suspended Actions |
See: Defining User Access and Menus
Not applicable
Region | Tip Type | Message Name |
---|---|---|
Actions Awaiting Your Attention | Instruction | PQH_SS_PERSON_NTF_INT |
Available Actions | Instruction | HR_SS_INST_ACTIONS_DUAL |
Selected Action | Instruction | HR_SS_INST_ACTIONS_SINGLE |
Selected Action | Instruction | HR_INST_ACTIONS_SINGLE_SUS |
Region | Tip Type | Message Name |
---|---|---|
Effective Date Options | Instruction | PQH_SS_EFFECTIVE_DT_HDR |
Region | Tip Type | Message name |
---|---|---|
Intervening Actions Found | Instruction | PQH_SS_CONC_REFRESH_INT |
Region | Tip Type | Message name |
---|---|---|
Assignment Header | Instruction | PER_SS_ASOF_APPROVAL_DT_DESC |
Sub Actions | Instruction | PQH_SS_SUB_ACTIONS_INT |
See: Adding Instructions to Web Pages
Not applicable
Profile | Configurable Levels | Values | Default |
---|---|---|---|
HR:Allow Use of Eligibility for Self Service Actions | Site | Yes/No | No |
HR:Allow Processing of Ineligible Self Service Actions | Site | Yes/No | No |
HR:Allow Concurrent Self Service Actions | Site | Yes/No | No |
HR: Manager Actions Menu | All | All Manager Actions menus | Manager Actions Menu |
HR:Personal Actions Menu | All | All Personal Actions menus | Personal Actions Menu |
HR:Contingent Worker Manager Actions Menu | All | All Contingent Worker Manager Actions menus | Contingent Worker Manager Actions Menu |
HR:Contingent Worker Personal Actions Menu | All | All Contingent Worker Personal Actions menus | Contingent Worker Personal Actions Menu |
HR:Actions - Validation | All | All Actions Checked, Preselected Action Checked, All Validation Post Selection | All Actions Checked |
See: User Profiles, Oracle HRMS Configuring, Reporting, and System Administration Guide
The Return for Correction page is available from the Pending Approval Notification page.
When a manager clicks on a Return for Correction link in a notification they navigate to the Return for Correction page. Here they can select a previous approver or the initiator of the action and submit for correction with comments. A notification is sent to the selected user.
The receiver of the Return for Correction can then restart the approval notification from the following places:
All Actions Awaiting Your Attention page
Actions Awaiting Your Attention in Perform Action page
Return for Correction notification
This page can be accessed from the following menus and functions:
User Menu Name | Function Name |
---|---|
HR Self-Service Pages | HR Return for Correction Page |
Not applicable.
Region | Tip Type | Message Name |
---|---|---|
Comments Region | Error | PQH_SS_RFC_RESPONSE_INT |
Person Selection Region | Error | PQH_SS_RFC_SELECT_PERSON_INT |
Top Content Region | Error | PQH_SS_RFC_CONTENT_INT |
Not applicable.
The Release Information function enables an employee or worker to share information about themselves with another person, often a manager, who would not usually have access to their records. Similarly, a manager can use this function to share information about one of their direct reports with a second manager.
See: Security Profiles, Oracle HRMS Configuring, Reporting, and System Administration Guide
If the employee or worker subsequently decides that the information should no longer be shared, they can use the Revoke Access functionality to block access to their information.
The Release Information function is available under predefined Manager and Employee responsibilities. Configuration options enable you to set up approvals processes for granting access.
This module can be accessed from the following menus and functions:
User Menu Name | Function Name |
---|---|
Manager Self Service | Release Information Mgr |
Employee Self Service | Release Information |
See: Defining User Access and Menus
The workflow details for this module are listed below:
Release Employee Information
Not applicable
Region | Tip Type | Message Name |
---|---|---|
CAED: Grant Access to | Instruction | HR_INST_CAED_GRANT_ACCESS |
CAED Granted Employee Header Region | Instruction | HR_INST_CAED_EXISTING_GRANTS |
CAED Pending Employee Header | Instruction | HR_INST_CAED_PENDING_GRANTS |
CAED Control Access To Employee Data | Instruction | HR_INST_CAED_TOP_TEXT |
See: Adding Instructions to Web Pages
Not applicable
Profile | Configurable Levels | Values | Default |
---|---|---|---|
HR:CROSS_BUSINESS_GROUP | Site | Yes/No | No |
The Cross Business Group profile option determines whether employees from other business groups are retrieved in the employee search.
See: User Profiles, Oracle HRMS Configuring, Reporting, and System Administration Guide
Configure the predefined user menus to include the Release Information function.
If you want your managers to have access to employee and worker data, ensure that the Allow Granted Access check box is flagged for the security profile assigned to the manager. This enables the manager to review the user's data.
See: Security Profiles, Oracle HRMS Configuring, Reporting, and System Administration Guide
Most functions display at least the Review page. The Review page displays a corresponding region for each web page section that you have updated as part of the preceding transaction. Inside each region is a list of current database and proposed transaction data. Changed information is highlighted with a blue dot, enabling you to easily identify which information has changed in the transaction.
The Confirm page contains a confirmation message and appropriate navigation buttons.
If your enterprise has setup approvals, then you can enter approvals comments in this page. If dynamic approvals are used, you can view approvers and pre-approval and post-approval notifiers, and add further approvers and notification recipients.
When you click the Submit button on the Review page, the transaction is committed to the Human Resources system or sent for approval. The Confirm page is then displayed. The Confirm page contains a confirmation message describing the status of the transaction.
If the Attachments region is available, you can attach supporting documents to the current transaction. An attachment can be a file, a URL, or text.
When you click Add or View Attachments List, the Attachments page is displayed to edit, delete, or simply view attachments in the Attachments table. The Add displays the Add Attachment page.
Save Attachments
If the Save Attachments check box is available in the Attachments region, then you select this option to save the attachments so that the attachments are available in the relevant windows of Oracle HRMS. For example, when a manager performs the Change Job self-service transaction and saves an attachment, this attachment is available in the Assignment window of Oracle HRMS.
If the What If region is available, you can assess the impact of the change on the employee's eligibility for benefits before committing the change or sending it for approval.
Note: The What If feature will only function if you have Oracle Advanced Benefits (OAB) installed.
The user can print a copy of the submitted transaction for their records if required. Enable the Printable Page button in the Personalization Framework to enable this feature.
When the user clicks on the Printable Page button the transaction data will be formatted for printing. How the data is formatted depends on whether you have configured any documents in Document Management that correspond to this action. You can use Document Management to produce formatted documents containing merged data, using Acrobat Forms technology. See Document Management. If documentation has not been configured, users will simply see a printer-friendly version of the Review page.
The Save for Later functionality enables a user to interrupt transactions before they are complete. The user can then save them so that they can be completed at a later point. When users save a transaction for later the application sends them a notification.
In addition, approvers can return transactions to the initiator or a previous approver for correction. In this case, the initiator can reopen the transaction, correct the information, and resubmit it for approval. The approvers can include informational notes to clarify the reason for returning the transaction.
Both suspended transactions and returned transactions are displayed in the All Actions Awaiting Your Attention list on the Actions page.
Users can also access their saved functions using the All Actions Awaiting Your Attention menu option on the employee and manager menus.
Save for Later Functionality
The graphic above shows how transactions can be saved for later and returned for correction.
Route 1 (Save for Later): When a user initiates a self-service transaction, or receives a transaction for correction, they can either submit the transaction for approval immediately or save the transaction for subsequent processing. If the user submits the transaction immediately, the transaction is subject to the usual approval processes. If the user chooses to save the transaction for later, it is suspended and the user can restart it or delete it from the All Actions Awaiting Your Attention table in the Actions page.
Route 2 (Return for Correction): When a user has submitted a transaction for approval, the approver can either approve the transaction, reject the transaction, or return it for correction. If the approver returns the transaction for correction, the initiator can subsequently restart or delete it from the All Actions Awaiting Your Attention table in the Actions page of the initiator.
Note: If a transaction is interrupted due to user inactivity, or a system failure, the interrupted transaction is also stored as a suspended transaction and the user will receive a notification.
The application will notify users whenever they have saved a transaction for later.
Note: Users save a transaction for later by clicking the Save for Later button. To disable this button you need to set the profile option HR:Self Service Save for Later to No (the default is Yes). This will hide the Save for Later button on all transaction pages and the Review page.
Oracle SSHR uses the HR Save for Later (hrssfl.wft) workflow item type to route the save for later transactions. The HR Save for Later Notification Process within the workflow controls the for save for later transactions. This process sends FYI notifications when save for later transactions occur and recipients can launch the transactions from notifications later.
Document Management features enable you to automatically generate business documents containing data from self-service actions. Examples of business documents might include a Request for Action, Notification of Change, standard letter, or contract. You set up your documents in two stages:
Create formatted PDF documents, using PDF or RTF form fields as place holders for transaction attribute values
Configure document groups and attribute mappings in the HRMS Document Management function
Create formatted documents in any word processing or page layout application, then generate a PDF file. In a PDF editing application, add named form fields to contain data from the action. The form field names are the tags you map to your action's attributes in Document Management.
Alternatively, you can prepare your document in RTF format and add RTF form fields. When you use an RTF template, the application converts it to PDF format when you generate your document. You can also insert conditional programming statements available using RTF technology to display or hide fields based on the values of other fields. For example, you can display or hide data based on the department or e-mail address.
Using an HRMS Manager responsibility, run Document Management from the Main Menu.
Use this page to search for existing document groups. Click the Create Group button to navigate to the Define Group page and create a new document group. Use document groups to define a collection of documents and associate them with their corresponding workflow process. To create the link between the document group and the workflow process, add the function parameter pGroupName=<documentgroupshortname> using a System Administrator responsibility.
From the Results list, you can add, update, or remove documents from the group. You can also delete a document from the database here.
From this page, you can create a new document group by entering a Group Name and Short Name. You can also search for existing groups. Enter a Group Name and Short Name. Once you have defined a group, you can also change the Document Type of any documents belonging to the group here.
Use this page to add a document to the selected group. You can select from a list of documents in the database that are not yet part of a group, or you can add a new document. You can search by Document Name or Short Name, and Effective Date.
Use these pages to define or update a document. On the Define Document page, specify a Document Name, Short Name, and Document Category (such as Self Service Human Resources or Compensation Workbench).
Click the Update icon for an existing document to access the Update Document page. You can view Details pages displaying document and group information by clicking the View Document or View Group icons, respectively. You can also maintain versions of documents when their properties or contents change, and keep version histories showing the effective dates. You specify the document`s effective date (which automatically end dates any previous version), then upload a new file or select a file that already exists in the database.
Here you also specify any FastFormula you want to use to populate document tags with returned values from the database, or override tag values with literals.
Use this page to merge data from transaction data attributes to form fields. The page displays a list of tags (form field names) found in the selected template, with corresponding Transaction Data Attribute fields. To merge data from attribute values to each form field, search for and map available attributes in the attribute field corresponding to the tag.
You can include both current and proposed values in a document, and also Header Information attributes containing details from the selected person's record. For details, see the table Pages and Regions that Support Attribute Mapping. A Value column tells you if the chosen attribute is Current or Proposed. You can delete mappings and maintain datetracked versions within the selected document by changing the effective date of a given tag/attribute combination.
If you select an existing document on the Map Document to Group page and press Continue, the Define Documents Properties page appears. You can also change the Document Type here. Available types include Pre Approval, Post Approval, and Both.
You generate pre-approval versions of documents when you press the Printable Page button on the Review page of an action, while it is still in process. You generate post-approval versions on final approval. Initiators receive a notification containing a link to the Document Information page, containing post-approval versions of available documents.
Use this page to delete a document from the database. Alternatively, you can reinstate a previous document version by clicking Delete for that version and choosing to delete all future changes. You can also access Document Details and Group Details from this page.
HRMS supports the listed mapping attributes from the following pages and regions:
Assignment Header Region
Current Business Group
Current Contingent Worker Name
Current Department Name
Current Derived Locale
Current Employee Name
Current Employee Number
Current Employment Category
Current Grade
Current Job Name
Current Location
Current Manager Name
Current Organization Email Address
Current Payroll
Current Position
Current Salary
Current Salary Basis Name
Current Salary Frequency
Assignment Page
Additional Information
Assignment Attribute 1-30
Assignment Attribute Category
Assignment Status
Billing Title
Ceiling Step
Change Reason
Current Additional Information
Current Assignment Status
Current Ceiling Step
Current Change Reason
Current Department Name
Current Employee Category
Current Employment Category
Current Establishment Name
Current Frequency
Current Grade Ladder
Current Grade Name
Current Internal Address
Current Job Title
Current Location
Current Normal End Time
Current Normal Start Time
Current Notice Period Length
Current Notice Period Units
Current Payroll Name
Current People Group Key Flex
Current Performance Review Frequency
Current Performance Review Period
Current Position Name
Current Probation Period End Date
Current Probation Period Length
Current Probation Period Units
Current Project Title
Current Projected Assignment End
Current Purchase Order Line
Current Purchase Order Number
Current Salary Basis
Current Salary Review Frequency
Current Salary Review Period
Current Supervisor
Current Supplier ID for Assignment
Current Supplier ID for Worker
Assignment Page
Current Supplier Name
Current Supplier Site
Current Title
Current Work Hours
Currently a Home Worker
Department Name
Employee Category
Employee is a Manager
Employee is a Manager Currently
Employment Category
Establishment Name
Frequency
Grade Ladder
Grade Name
Home Worker
Internal Address
Job Title
Location
Normal End Time
Normal Start Time
Notice Period Length
Notice Period Units
Payroll Name
People Group Key Flex
Performance Review Frequency
Performance Review Period
Position Name
Probation Period End Date
Probation Period Length
Probation Period Units
Project Title
Projected Assignment End
Purchase Order Line
Purchase Order Number
Salary Basis
Salary Review Frequency
Salary Review Period
Supervisor
Supplier ID for Assignment
Supplier ID for Worker
Supplier Name
Supplier Site
Work Hours
Change Manager Page
Current Manager Name
Employee Name
Manager Name
Change Pay Page
Annual Change Amount
Change Amount
Change Percentage
Comments
Currency
Current Comments
Current Salary
Current Salary (Annual Equivalent)
Current Salary Effective Date
Pay Basis
Proposal Reason
Proposed Salary
Proposed Salary (Annual Equivalent)
Salary Basis Change Type
Salary Effective Date
Competency Profile Page
Current Level
Current Start Date
Name
Proposed End Date
Proposed Level
Short Name
Education and Qualifications Page
Attendance End Date
Attendance Start Date
Award On
Awarding/Examining Body
Comments
Completed Amount
Completed Units
Current Attendance End Date
Current Attendance Start Date
Current Award On
Current Awarding/Examining Body
Current Comments
Current Completed Amount
Current Completed Units
Current Fee
Current Fee Currency
Current Full-Time
Current Grade
Current Group Ranking
Current Projected/Actual Completion Date
Current Reimbursement Condition
Current School
Current Status
Current Study Start Date
Current Title
Current Total Amount
Current Tuition Method
Current Type
Fee
Fee Currency
Full-Time
Grade
Group Ranking
Projected/Actual Completion Date
Reimbursement Condition
School
Status
Study Start Date
Title
Total Amount
Tuition Method
Type
Other Employment Information Page
Bargaining Unit Code
CAGR Grade
CAGR Key Flex
Collective Agreement
Contract
Current Bargaining Unit Code
Current CAGR Grade
Current CAGR Key Flex
Current Collective Agreement
Current Contract
Current Union Member
Union Member
Other Professional Awards Page
Award On
Awarding/Examining Body
Comments
Completed Amount
Completed Units
Current Award On
Current Awarding/Examining Body
Current Comments
Current Completed Amount
Current Completed Units
Current Fee
Current Fee Currency
Current Grade
Current Group Ranking
Current Projected/Actual Completion Date
Current Reimbursement Condition
Current Status
Current Study Start Date
Current Title
Current Total Amount
Current Tution Method
Current Type
Fee
Fee Currency
Grade
Group Ranking
Projected/Actual Completion Date
Reimbursement Condition
Status
Study Start Date
Title
Total Amount
Tution Method
Type
Personal Information Header Region
Current Business Group
Current Contingent Worker Name
Current Employee Name
Current Employee Number
Current Organization Email Address
Personal Information Page
Current Date of Birth
Current Disability Code
Current Effective Date
Current Employee Number
Current First Name
Current Full Name
Current Honors
Current Last Name
Current Marital Status
Current Middle Name(s)
Current Organization Email Address
Current Preferred Name
Current Prefix
Current Previous Last Name
Current Social Security Number
Current Suffix
Current Title
Date of Birth
Disability Code
Effective Date
Employee Number
First Name
Full Name
Honors
Last Name
Marital Status
Middle Name(s)
Organization Email Address
Preferred Name
Prefix
Previous Last Name
Social Security Number
Suffix
Title
Tenure Status Page
Adjusted Tenure Date
Current Adjusted Tenure Date
Current Date Determined
Current Projected Tenure Date
Current Reason for Adjustment
Current Subject to Tenure Quota
Current Tenure Status
Date Determined
Projected Tenure Date
Reason for Adjustment
Subject to Tenure Quota
Tenure Status
Termination Page
Comments
Notification Date
Reason
Termination Date
Work Schedule Page
Current Employment Category
Current Frequency
Current Normal End Time
Current Normal Start Time
Current Work Hours
Current Work Schedule Key Flex
Employment Category
Frequency
Normal End Time
Normal Start Time
Work Hours
Work Schedule Key Flex
You can do the following using FastFormula:
Set a value into the document
Override an existing value in the document
Your formula must be of the type Document Print.
The application provides three predefined input parameters for your use:
P_SESSION_ID
P_TRANS_ID
P_EFFECTIVE_DATE(TEXT)
Say you want to set the manager name in the document, but the manager name is not a data field found within the workflow process.
Using an HRMS Localization Seed Data responsibility, create three functions, described below in order of invocation.
A FastFormula function that passes the Transaction ID to a database function, returning the manager name
A database function that returns the manager name for the specified transaction
A second FastFormula function that sets the manager name in the tag (form field)
Function | FastFormula Function1 | Database Function | FastFormula Function2 |
---|---|---|---|
Name | My_FF_Get_Mgr_Name | MyPackage.My_DB_Mgr_Name_Function | My_FF_Put_Mgr_Name |
Definition | MyPackage.My_DB_Mgr_Name_Function | PQH_SS.PRINT.set_document_data | |
Data Type | VARCHAR2 | VARCHAR2 | Number |
Class | External | External | |
Parameters | Use predefined parameter: | Use predefined parameter: | Use predefined parameters: |
Name: P_TRAN_ID Type: VARCHAR2 Class: Input Value |
Name: P_TRAN_ID Type: VARCHAR2 Class: Input Value |
Name: P_TAG_NAME Type: Text Class: Input Value |
|
Name: P_TAG_VALUE Type: Text Class: Input Value |
|||
Return Value | mgr_name | db_mgr_name | 0 = success |
The database function returns the manager name (db_mgr_name) to FastFormula Function1:
<local variable1> = My_FF_Get_Mgr_Name(P_TRAN_ID)
The second FastFormula function sets the manager name (mgr_name) in the form field:
<local variable2> = My_FF_Put_Mgr_Name('MANAGER_PDF_TAGNAME',<local variable1>)
Say you want to override the manager's name with a specific manager's name. You can override the existing value with a literal:
<local variable2> = My_FF_Put_Mgr_Name('MANAGER_PDF_TAGNAME','Mark Johnson')
Note: Performing the tasks described in this section assumes knowledge of FastFormula, including the ability to use SQL queries to create Definitions, such as MyPackage.My_DB_Mgr_Name_Function.
See: Oracle HRMS FastFormula User Guide.
The following table lists user menu names and function names for this module.
User Menu Name | Function Name |
---|---|
SSHR Document Management |
Not applicable
The following tables list the configurable tips and instructions for each page.
Region | Tip Type | Message Name |
---|---|---|
Page | Instruction Text | PQH_SS_DEFINE_DOC_INT |
Page | Instruction Text | ICX_POR_INDICATES_REQ_FIELD |
Page | Instruction Text | PQH_SS_DEFINE_DOC_U_INT |
Error | Error | PQH_SS_DUPLICATE_SHORT_NAME |
Error | Error | PQH_PA_NO_TAGS_IN_FILE |
Error | Error | PQH_SS_INVALID_FILE_ERR |
Region | Tip Type | Region Name |
---|---|---|
Page | Instruction Text | PQH_PA_ATTR_MAP_INT |
Region | Tip Type | Region Name |
---|---|---|
Page | Instruction Text | PQH_SS_DOC_DELETE_MSG_INT |
Region | Tip Type | Region Name |
---|---|---|
Select Document Properties | Instruction Text | PQH_PA_DOC_PROP_INT |
Region | Tip Type | Region Name |
---|---|---|
Warning | Error | PQH_PA_DOC_CREATED_INT |
Region | Tip Type | Region Name |
---|---|---|
Page | Instruction Text | PQH_PA_DOCUMENT_DELETE_INT |
Page | Instruction Text | PQH_SS_DOC_DELETE_INT |
Region | Tip Type | Region Name |
---|---|---|
Page | Instruction Text | PQH_PA_DOCUMENT_UPDATE_INT |
Document Information | Instruction Text | PQH_SS_DOC_UPDATE_ALLOWED_TIP |
Region | Tip Type | Region Name |
---|---|---|
Page | Instruction Text | PQH_PA_DOC_MGMT_GRP_INT |
Results | Instruction Text | PQH_PA_DOC_MGMT_HGRID_INT |
Search Group | Instruction Text | PQH_PA_GRP_SRCH_HRD_INT |
Confirmation | Information | PQH_PA_RECORDS_SAVED |
Region | Tip Type | Region Name |
---|---|---|
Description | Instruction Text | PQH_SS_DOC_REMOVE_DESC |
Instruction | Instruction Text | PQH_SS_DOC_REMOVE_INT |
Region | Tip Type | Region Name |
---|---|---|
Results | Instruction text | PQH_PA_DOC_SRCH_RSLT_INT |
Results | Instruction text | PQH_PA_DOC_SRCH_RSLT_U_INT |
Search | Instruction text | PQH_PA_DOC_SRCH_INT |
Region | Tip Type | Region Name |
---|---|---|
Page | Instruction text | PQH_PA_GRP_HDR_INT |
Page | Instruction text | PQH_MANDATORY_MESSAGE_INT |
Region | Tip Type | Region Name |
---|---|---|
Page | Instruction text | PQH_PA_GROUP_DETAILS_INT |
Region | Tip Type | Region Name |
---|---|---|
Description | Instruction text | PQH_SS_DOC_DELETE_GRP_DESC |
Instruction | Instruction text | PQH_SS_DOC_DELETE_INSTRUCTION |
See .Adding Instructions to Web Pages
Not applicable
Not applicable
The following is a best practice example of how to set up automatic calculation of a person's eligibility for a self-service action, using features available in HRMS Compensation and Benefits as a processing engine. When a user initiates an action, the application runs the Compensation and Benefits BENMNGLE engine, and displays whether or not the selected person is eligible.
To enable eligibility processing, turn on the system profile HR:Allow Use of Eligibility for Self Service Actions. If you want to allow users to process actions for which a selected person is not eligible, turn on HR:Allow Processing of Ineligible Self Service Actions.
If you are confident that the BENMNGLE engine runs and updates the results tables on a regular basis, you can improve performance by disabling the profile HR:Run BENMNGLE when processing a Self Service action.
The system profiles described above are off by default.
The following figure describes how SSHR has mapped the Workflow and AOL schema onto the Compensation and Benefits schema to provide a generic eligibility processing engine. In a typical implementation, you link your copied and configured form functions to actions, such as Promotion. The actions take on a parent relationship with sub actions such as Promotion (US) or Promotion (Sales), which you define based on the requirements of, say, differing locales or departments.
Mapping the Workflow/AOL Schema to the Compensation and Benefits Schema
For a person to be eligible for a sub action that is legislation-specific, say, Promotion (US), you set up the sub action (plan) in a US business group. You refine the criteria that make a person eligible by defining eligibility profiles and linking them to the sub action. You can link each form function to multiple actions and sub actions, but you can determine eligibility only for sub actions.
Note: The application considers a person who meets all Required profiles and at least one Optional profile eligible. If you link only one profile to a sub action, you define it as Required.
In this example, you have already decided to use the Benefits engine to process eligibility, and you have configured the form functions your enterprise wants to make available to users. User-friendly names help users recognize the workflow processes. Examples might include:
Promotion (Australia)
Promotion (Manufacturing)
Transfer
Award Bonus
This example assumes that you have copied and configured two form functions based on the predefined function Change Job:
Change Assignment
Change Assignment with Bonus
You have identified the applicable policies and eligibility rules in effect in your organization, and reviewed the available eligibility profile criteria. You have asked and answered appropriate business questions, including:
What are the criteria that govern eligibility for each available form function? Examples include:
Legislation
Organization Unit (department)
Job
Length of Service
Which life events can impact eligibility for actions?
In your organization, an employee is eligible for a bonus after one year of service. You set up eligibility processing so that if a person's length of service is less than one year, the person is eligible only for Change Assignment. If length of service is one year or more, the person is eligible for Change Assignment with Bonus.
The steps below describe the generic process of setting up eligibility for sub actions.
Define eligibility criteria as required
In the Participant Eligibility Profiles window:
Create eligibility profiles
In the Plan Types window:
Define a plan type
In the Plans window:
Create plans (sub actions)
Link each plan to a form function (Miscellaneous tab)
Link eligibility profiles to each plan (Plan Eligibility tab)
In the Reporting Groups window:
Create reporting groups (actions)
Link each reporting group to a form function
Link each reporting group to plans (Components tab)
Using an HRMS Manager responsibility, follow the steps below to set up eligibility based on length of service.
Derived Factors
Specify how the application evaluates length of service criteria by defining two derived factors.
Define the first derived factor, in which length of service is less than one year. In the Derived Factors window (Length of Service tab):
Name = "LOS < 1 yr"
UOM = "Day"
Date to Use Code = "Date of Hire"
Values: Activate the No Min check box; Max = 364
Determination Code = "As of Event Date"
Define the second derived factor, in which length of service is one year or more. In the Derived Factors window (Length of Service tab):
Name = "LOS >= 1 yr"
UOM = "Year"
Values: Activate the No Max check box; Min = 1
Date to Use Code and Determination Code are the same values as the first derived factor
Eligibility Profiles
Set up two eligibility profiles. The first makes a person eligible with less than one year of service, the other makes a person eligible with a year or more of service. You can set up as many eligibility profiles as you need to qualify a person for an action. You specify if a profile is Required or Optional when you link the profile to a plan, below.
Define the first eligibility profile. In the Participant Eligibility Profiles window (Derived Factors tab):
Name = "Less Than 1 yr LOS"
Assignment Type = "Any Assignment" (Primary and Secondary)
Status = "Active"
Applies To = "Benefits Profile"
Select "Length of Service" from the LOV
Length of Service = "LOS < 1 yr"
Define the second eligibility profile. In the Participant Eligibility Profiles window (Derived Factors tab):
Name = "1 yr or More LOS"
Select the same values for Assignment Type, Status, and Applies To as the first profile
Length of Service = "LOS >= 1 yr"
Note: If the Assignment Type is Any Assignment, eligibility processing can consider secondary assignments, enabling the application to find all actions for which the person is eligible. In a good implementation, a person is eligible for only one related sub action for each action. If BENMNGLE retrieves more than one eligible sub action, a Sub Actions page appears and displays the available choices.
Sub Actions (Plans) and Actions (Reporting Groups)
Create a plan type to relate your sub actions (plans) to self-service actions eligibility instead of benefits.
Define a new plan type to use for self-service actions. In the Plan Types window:
Name = "Business Process"
Option Type = "Personnel Action"
Define a sub action that includes only the assignment change. Link it to a form function and an eligibility profile. In the Plans window:
Name = "Change Assignment"
Status = "Active"
Plan Type = "Business Process"
Plan Usage = "May not be in program"
On the Eligibility Rates tab, activate the "Track ineligible persons" check box
On the Miscellaneous tab, Personnel Action Function Name = "Change Assignment" (or any form function name you have configured to change an assignment)
Confirm that you have activated the Plan Years Not Applicable check box
Save your work
Press the Plan Eligibility button to open the Maintain Plan Eligibility window
Press the Eligibility button to open the Eligibility window. Eligibility Profile Name = "Less Than 1 yr LOS"
Activate the Required check box
Save your work
Define a second sub action that additionally includes bonus. The steps are the same as in the first sub action, except for the following:
Name = "Change Assignment with Bonus"
On the Miscellaneous tab, Personnel Action Function Name = "Change Assignment with Bonus" (or any form function name you have configured to change an assignment and award a bonus)
Eligibility Profile Name = "1 yr or More LOS"
Define an action and link it to your two sub actions to complete your setup. In the Reporting Groups window:
Name = "Change Assignment"
Purpose = "Personnel Action"
Function Name = "Change Assignment"
Save your work
Plan = "Change Assignment"; Plan = "Change Assignment with Bonus" (Components tab)
See:
Plan Design, Oracle HRMS Compensation and Benefits Management Guide
Eligibility Requirements for Total Compensation, Oracle HRMS Compensation and Benefits Management Guide
Eligibility Profile Criteria, Oracle HRMS Compensation and Benefits Management Guide
Derived Factors, Oracle HRMS Compensation and Benefits Management Guide
Defining a Reporting Group, Oracle HRMS Compensation and Benefits Management Guide
The Allocated Checklists functionality automatically generates checklists based on HR actions and eligibility profiles and assigns them to a person or assignment. A typical checklist is a New Hire checklist.
The allocated checklists contain tasks associated with a particular life event. For example, for a new employee, the New Hire checklist would contain tasks associated with the New Hire life event.
If you use the Allocated Checklists function as a Manager, you can view checklists allocated to your direct reports. As an HR Professional user, you can view checklists allocated to the workers within your security profile.
For more information on Checklists in general, see: Checklists Overview, Oracle HRMS Enterprise and Workforce Management Guide.
You create and maintain checklists and tasks using an HRMS Manager responsibility.
See: Setting Up Checklists, Oracle HRMS Workforce Sourcing, Deployment, and Talent Management Guide.
When you display an allocated checklist for a worker, you can either perform the associated task actions yourself or reassign the task. When you have processed a task, you can change the task status as appropriate (for example, Completed, Rejected, Outstanding, Suspended).
Note: If you reassign the task, the new performer receives a notification and can update the task status by updating the notification.
From the Allocated Checklists interface, you can delete a checklist for a worker or modify the checklist by adding and deleting tasks and changing task attributes.
Note: You cannot delete a mandatory task from a checklist; however, if necessary, you can change the Mandatory attribute to No and then delete the task. Checklists and tasks remain accessible from the Allocated Checklists interface until you explicitly delete them.
If required, you can also add checklists from the Allocated Checklists interface; however, by selecting a person or assignment and then creating a checklist, you have already implicitly allocated the checklist, and automatic allocation using a life event is not necessary.
Oracle SSHR enables managers and workers to delete any transactions that they have initiated and are in the pending approval stage. You can enable this functionality using the HR: Enable Initiator to Delete a Pending-Approval Transaction profile option.
For more information about the HR: Enable Initiator to Delete a Pending-Approval Transaction user profile, see: User Profiles, Oracle HRMS Configuring, Reporting, and System Administration Guide
When you set this profile option to Yes at any one of the levels: site, application, responsibility (Manager Self-Service and Employee Self-Service), or at the user level, the Delete icon is enabled on the following pages:
All Actions Awaiting your Attention (Employee Self-Service responsibility)
Personal Actions (Employee Self-Service responsibility)
All Actions Awaiting your Attention (Manager Self-Service responsibility)
Manager Actions (Manager Self-Service responsibility)
Initiators can view their transactions in the Pending Approval stage and delete those transactions prior to approval.
When an initiator deletes a transaction that is pending approval, Oracle SSHR performs the following actions:
Closes all the notifications associated with the transaction from the worklist and All actions Awaiting Your Attention region.
Removes the transactions with the Pending-Approval stage from the initiator's list of actions.
Deletes the transaction from the HR_API_TRANSACTIONS table.
Examples Illustrating the Delete Pending Transactions Functionality
An initiator can delete a transaction pending approval at any point in the transaction flow till the transaction is approved.
The following examples describe the different scenarios in a transaction flow. In these examples, John Smith is an employee in the Human Resources department in Vision Corporation and he reports to Tracy Price. Tracy Price reports to James King who is the director of the Human Resources department.
John can delete a transaction in the following scenarios:
John submits a transaction to Tracy and the transaction is in the Pending Approval stage.
John submits a transaction that requires approval from Tracy and James. John can delete the transaction after Tracy's approval, pending approval from James.
James returns a transaction submitted by John, for correction to Tracy. Now, John can delete this transaction as the transaction is in the pending approval.
Tracy corrects the transaction submitted by John, and submits it for approval from James. As the transaction is in the pending approval stage, John can delete the transaction.
James returns the transaction to John for correction. John can delete the transaction as the transaction is yet to be approved.
Note: If you enable the HR: Defer Update After Approval profile option, then initiators can delete the deferred transactions till you run the Workflow Background Process. For more information about the HR: Defer Update After Approval user profile, see: User Profiles, Oracle HRMS Configuring, Reporting, and System Administration Guide
Most enterprises adhere to rules, regulations, and reporting requirements when changing the terms of work. Oracle Self Service Human Resources (SSHR) provides a set of configuration tools and web flows for initiating, updating, and approving self-service actions according to prescribed rules.
Self-service actions represent the business processes, or actions, that change the conditions of employment in your enterprise. Public sector organizations typically refer to these processes as personnel actions, and they include business actions that manage hiring, training, promotion, transfer, compensation, and termination. Self-service actions are useful for any enterprise that wants to configure business processes using rules to determine eligibility and approval requirements, track action history as well as details, or generate standard documents for specific actions.
Self-service actions fall into three overall types, each with its own unique expectations, rules, and requirements:
Hiring
Deployment
Termination
Oracle SSHR emphasizes business process over data maintenance. Though the interface provides an online form that you fill out in the course of navigating a series of web pages, your implementation team organizes the sequence and content of the data to reflect the standards and practices of your organization. With each self-service action, your implementation team defines a process consistent with the way your organization manages changes to personnel records. You design and implement your own version of each process, and specify the business rules that enable you to route each action for approval automatically.
SSHR provides a transition from technical orientation to functional. This approach enables you to initiate and manage self-service actions as business processes with which you are already familiar, rather than maintaining data in the abstract in application windows. Your focus is on the task you need to perform. Some examples of the predefined SSHR workflow modules supported by self-service actions include:
Hiring or termination
Recruitment
New Hire
Applicant Hire
Termination
Termination with compensation
Deployment or status changes
Employee Status Change (assignment, full/part time, grade, movement within pay scale)
Transfer
Leave of Absence (long term absence, sickness, sabbatical)
Special/Extra Information Types (ending training or apprenticeship periods, disciplinary actions)
Other Employment Information (ending training or apprenticeship periods, disciplinary actions)
Individual Compensation Distributions (awarding bonuses or other specific pay and allowance types)
You carry out a self-service action in three overall stages that reflect standard business procedures:
Initiate
Approve
Apply
For each stage, your implementation team has a range of options and features to configure unique process flows you recognize as a reflection of the way you do business. The following process flow diagram displays all the features available. What you see may differ, depending on your organization's requirements.
Life Cycle of a Self - Service Action
Initiate
Advanced search capability helps you confirm that you have selected the correct person before initiating an action. The People List and Actions page tell you whether or not a person is eligible for an action on the specified effective date. The Actions page notifies you of your own pending actions on the selected person, actions you have saved for later, and actions on the selected person awaiting approval of others. If your organization's requirements permit, you can specify that your action take effect on a date you specify, or "on approval". You enter the data that your enterprise, rules, and regulations require. What-If analysis gives you a real-time view of the impact of your proposed action on the selected person's entitlements to compensation and benefits. You can generate formatted documents, such as a pre-approval Request for Action, or a standard letter, containing merged values from your action. In addition, you can attach supporting documents, such as a resume, certificate, or Web address. Before submitting your action for approval, you can add to the list of approvers, or add people to notify.
Approve
Self-service actions use Oracle's standard workflow and approvals management tools. Oracle AME generates a list of approvers and Oracle Workflow routes your action automatically. Approvers retrieve notifications from their Worklist. Approvers with appropriate update privileges can modify the action, including its effective date. Recipients can request additional information, or return the action for correction to previous approvers. If the database encounters intervening or future-dated actions on the same person, it refreshes your action with the appropriate values, or routes your action to a Human Resources representative after approval for manual entry of the changes.
Apply
The application applies the action to the database after final approval.
SSHR workflow features enable you to engage in an online collaborative environment in which you can focus on the task of routing and approving actions based on their merits, with near transparency regarding selection and notification of approvers.
See: Configuring Self-Service Actions
See: Managing Conflicting Actions
See: Initiating a Self-Service Action
See: Approving a Self-Service Action
The sections below describe the process of configuring Self - Service Actions in SSHR. Some procedures are optional, for example, setting up eligibility processing or document management. Implementing the workflow processes and functions your enterprise requires is prerequisite to configuring self - service actions. When you have completed the configuration of workflow processes and functions, you must implement the following procedures:
Set system profile options
Define access roles
Personalize pages
Add a sub menu to user menus
Set up eligibility processing
Set up document management
If previous implementations have not configured Oracle Approvals Management (AME) with the attributes, conditions, approval types, and rules your organization requires to manage routing and approving actions, you must configure these if you want to enhance the default behavior. The default is to route the action to the top of the supervisory hierarchy or 10 levels above the Initiator, whichever comes first.
Note: In order to use the new workflow features associated with self-service actions, you must upgrade to the SSHR V5 approval process.
See: Implementation Steps for Self-Service HR (SSHR)
Configure the system profiles at the Site level. The eight profiles directly relating to configuring self-service actions are as follows:
HR:Allow Approver updates to Self Service actions
HR:Allow concurrent Self Service actions
HR:Manage Self Service actions when future-dated changes exist
HR:Refresh Self Service actions with data from intervening actions
HR:Display Position Hierarchy
HR:Allow use of eligibility for Self Service actions
HR:Allow processing of ineligible Self Service actions
HR:Run BENMNGLE when processing a Self Service action
If you do not enable HR:Allow Approver updates to Self Service actions, only the Initiator is able to update or change the effective date of an action you return for correction. Approvers will be unable to use attachments.
Oracle recommends that you configure two related options in tandem:
HR:Manage Self Service actions when future-dated changes exist
HR:Refresh Self Service actions with data from intervening actions
Enable or disable these two options together. If you set the former to Allow approval (Notify HR Rep), enable the latter as well.
See: User Profiles, Oracle HRMS Configuring, Reporting, and System Administration Guide
Create and assign access roles, to grant update privileges to those who approve self-service actions, or deny them to those who do not. The Initiator of an action has privileges based on menu access, and does not need an access role.
See: Access Roles for Self Service Actions
Personalize self-service pages. Personalizations play a key role in configuring self-service actions, including the following:
Personalizing workflow processes to display or hide pages or data fields (performed when you configure workflow processes)
Personalizing the Review page to display or hide What If analysis or attachments
Personalizing the Effective Date page to allow users to enter the effective date manually, specify that an action takes effect on approval, or both.
Attach the sub menu HR Self-Service Pages sub menu to user menus so that users can see the following pages:
Effective Date
Sub Actions
Return for Correction
Refresh Attributes
Document Manager pages
Optionally, set up automatic determination of a person's eligibility for an action, using SSHR Compensation and Benefits functionality as a generic processing engine. You do this in four stages:
Define Eligibility Profiles
Define Plans (sub actions)
Define Reporting Groups (actions)
See: Eligibility Processing Setup Example
Optionally, configure documents and groups in Document Manager to provide formatted business documents in PDF format, containing merged data from workflow processes. Examples include Request for Change, Notification of Change, correspondence, or contracts.
See: Document Manager
A typical implementation for self-service actions allows you to process multiple changes to a person's record at the same time. Another common configuration allows any approver on the chain of recipients to change the effective date of an action. The ability to process concurrent actions and choose an effective date at any point in the approval process adds both flexibility and complexity. For example, what if another manager submits a status change that affects a person's grade at the same time you are processing a job change on the same person? What if you submit a change of working hours, and another manager approves a transfer while your action is in process? What if choosing a retroactive effective date for a bonus means that another bonus (already approved) becomes effective on a future effective date to your own?
The flexibility of processing multiple changes simultaneously requires the application to handle complex interactions among three dates associated with each action:
Initiation date: the date you submit your action for approval (usually the system date)
Effective date: the date your approved action takes effect (not necessarily the approval date)
Approval date: the date you save your action to the database
The application helps you manage complex situations arising from interactions among multiple actions and dates in three ways. Consider three scenarios:
Concurrent Actions: The application processes multiple actions on a selected person at the same time. On final approval, each action takes effect on its own effective date, superseding any actions with a previous effective date.
Intervening Actions: After your action is in process, the application encounters an approved action on the same person with an effective date that falls between your initiation date and effective date. Your setup can help you manage which information prevails, and (as appropriate) replace values in your action.
Future-Dated and Retroactive Actions: After your action is in process, the application encounters an approved action on the same person with a later effective date. Your setup can allow you to route your action to a Human Resources representative on final approval, for manual entry of all appropriate changes.
When you begin an action, the application checks the person/assignment combination for other actions currently in process:
Saved for Later
Returned for Correction
Awaiting Approval of Others
Most implementations allow concurrent actions. Otherwise, if you try to begin an action on a person with pending changes, you cannot proceed beyond the Actions page. But in a typical setup, existing actions on the selected person appear as actions Awaiting Your Attention or Awaiting the Approval of Others.
Intervening changes can occur for a variety of reasons, most often due to delays between request and approval. Another manager can approve a change to your selected person's record after your own action has entered the approval process. When the application encounters approved changes to your selected person's record, effective somewhere between your own action's initiation date and effective date, it manages them in one of two ways. Consider two scenarios:
After you submit your job change for approval, an HR manager approves a transfer on the same person while your action is still in process. In this case, the intervening change of location prevails, because your action does not specify a location. You may still need to know about the transfer, however, in order to decide whether to approve, update, send back for correction, or cancel your job change.
Your action's proposed job change conflicts with an intervening change from another manager that specifies a different job. Because both your action and the intervening action specify a job, your action's proposed job prevails, because your action has the later effective date. Nevertheless, you may need to know about the intervening job change in order to make a more informed decision about your own proposed job change.
In the following illustrations, broken lines connect the initiation date and effective date of each action. Another manager approves an intervening action while yours is still in the approval process.
Scenario 1: Intervening Action Specifying Different Attributes
Scenario 2: Intervening Action Specifying the Same Attributes
When intervening actions exist, and as an approver when you receive a transaction for approval, you must click Update Action for approval notifications to refresh with data from intervening actions.
Data refresh options enable you to manage potential conflicts by replacing your action's values with the changed information from the intervening action (scenario 1), or preserving the values from your action (scenario 2). The application displays a Refresh page with a table informing you of the original, intervening, and prevailing values.
Note: The application may also display a Refresh page if you change the effective date of your action. A new effective date can create potential conflicts with values in effect at a different point in time.
When the application encounters an approved change to your selected person's record, effective subsequent to your action's effective date, configuration options can help you to manage potential conflicts by routing your action on approval to a person with an HR Representative role. On review, the HR representative applies all necessary changes to the database manually.
You can perform an action on a person retroactively by choosing a past effective date. The application treats changes to the person's record subsequent to your effective date as future-dated actions, and routes your action on final approval to an HR representative.
No automated system can resolve every scenario involving conflicting data. In some cases, an HR representative applies all appropriate changes manually. On the whole, managers prefer to get their actions in process and approve them. Your configuration accommodates most scenarios automatically by setting the following options:
Refresh your action with valid information as of your effective date, or require that your action fail on final approval (intervening actions)
Allow approval of your action with subsequent routing to an HR representative, or terminate it with an error (future-dated actions)
The process flow diagram below describes in greater detail how the application manages data conflicts when intervening or future-dated actions exist. The figure assumes that concurrent transactions are allowed.
Managing Conflicting Actions
Note: If an action has an effective date matching that of an existing change, the application assumes it to be a correction to the existing record.
For more information about date tracking in Oracle HRMS, see the Oracle white paper, How Date Track Works, available on My Oracle Support.
Oracle delivers a powerful and flexible set of tools in self-service actions. Your implementation team has many options to choose from as it decides which features are available, and how your process flow looks and feels. The following sections describe how to initiate an action, and possible exceptions resulting from implementation choices.
Begin a self-service action by opening a list of persons from the Main Menu.
Your implementation team chooses to display a supervisory hierarchy of your direct reports and subordinates, or a position hierarchy. You can also select a MyList view, displaying people you choose. Your implementation team determines whether the hierarchy or MyList view is the default. View options include expanding and collapsing nodes on the tree, and focusing on one person and his or her subordinates.
Note: HR representatives typically use the MyList view to display people for whom they are responsible.
Your implementation team also determines whether multiple assignments appear in person/assignment combinations, and whether contingent workers appear.
Advanced Search criteria enable you to refine a person search by specifying criteria such as business groups, person types, department, or position.
To request a change, choose the Action icon associated with a person. The Actions page appears.
Note: From any person/assignment row, you can optionally choose a Details icon that provides information about that person and assignment.
Your implementation team may choose to display preselected actions on your Main Menu, consistent with older versions of SSHR. Oracle recommends that you open your person list by selecting Manager Actions from the Main Menu. From this single point of entry, you can see all available actions, and the selected person's eligibility for them. With preselected actions, you restrict yourself to the single action you have selected. If your selected person is ineligible, and your setup does not allow processing ineligible actions, you may have to begin again with a new action.
Note: Some processes are only available via preselected actions, such as New Hire or Organization Manager.
If you use Manager Actions to enter the process, the Actions page lists available changes, and the selected person's eligibility for them. Pressing the Start button initiates the selected action, and the Effective Date page appears.
Note: If you use a preselected action from the Main Menu, and no pending actions exist for your selected person, the application skips the Actions page and takes you directly to the Effective Date page.
Your implementation team can configure the application to determine your selected person's eligibility for a proposed action automatically. The application determines eligibility as of the effective date you specify, and displays the results in a table on the Actions page. Eligibility determination is based on personal, employment, or derived-factor criteria, such as Job, Organization, or Length of Service. The process also considers department- or locality-specific criteria to determine eligibility for actions such as Promotion (Sales), or Hire (France).
Infrequently, the selected person may be eligible for more than one version of an action, such as Promotion (Sales) and Promotion (US). In most cases, well-configured eligibility processing will present only one action as a choice. If the person is eligible for more than one version of an action, you select from a list of choices on the Sub-Actions page.
Your implementation team can configure the application to process ineligible actions. For example, you can do this if approvers have the right to override eligibility criteria, or if you want to put an action in process for a person who is not eligible as of the effective date, but may become eligible later.
See: Eligibility Processing Example
When processing your action, you need to know how the application manages data conflicts. If your implementation team has configured the application to support concurrent actions, you may encounter messages and warnings about other pending actions on the selected person's record, or actions on this person you have saved for later. The Actions page displays two lists of pending actions on the selected person:
your own actions
actions awaiting the approval of others
You can also see a complete list of your own pending actions by choosing Actions Requiring Your Attention from the Main Menu. The application may also encounter intervening or future-dated changes that affect a proposed change, some of which may appear after your action is in the approval process.
See: Managing Conflicting Actions
Initiating or approving an action typically begins on the Effective Date page, where you choose one of two options:
Enter an effective date manually
Specify that the action takes effect on approval
This page also provides information and warnings relating to your action, such as the earliest possible effective date, or other approved or pending actions on this person.
Note: If your implementation team decides to have all actions take effect on approval, the Effective Date page does not appear.
Here you enter data related to your action. Available actions may differ, depending on the business processes your implementation team has provided. Examples include:
Hire a person
Change location
Change manager
Change grade
Change salary
Change job
Change hours
Award bonus
Release information for transfer
Initiate Leave of Absence
Termination
SSHR Actions
If you Save for Later at any time in the process, you receive a notification as a reminder. If you inadvertently close your browser, or your browser crashes, the application saves your action for you.
If you are the Initiator, pressing the Cancel button deletes the action. If you are an approver, or have Saved for Later, Cancel reverts to the previously saved data.
In addition to displaying the proposed changes to the person's record and information about the approvers on the chain of recipients, the Review page gives you the opportunity to choose additional approvers, or add people to notify. Other available features include:
Attachments
What-If Analysis
Document Management
Approvals Management
Press the Submit button to send your action to the next approver on the chain. If you are the final approver, you submit the changes to the database.
The Review page includes an Attachments link, which enables you to attach supporting documents, such as a photograph, a copy of a degree or certificate, or a resume. You need update privileges to do this. Oracle does not predefine any document types, so your implementation team supplies the list of available types.
If you choose the What-If Analysis link on the Review page, the application displays information about your selected person's entitlement to compensation and benefits. Choosing this link runs the BENMNGLE process, which gathers and reports information about compensation objects relating to the person's entitlements. Use this page to assess the impact of your proposed action. Here you can review the unit of currency, current amount, current period, What-If amount, and What-If period.
Note: Performing What-If analysis requires that you run Oracle Advanced Benefits.
Your implementation team can create formatted business documents in Acrobat PDF format, and associate them with selected actions. The application can also include information from your action in the document automatically. For example, documents available for your use could include a Request for Change, Notification of Change, letter, or contract describing the changes to the person's status, such as a new job or effective date. Your setup can provide pre-approval and post-approval versions of a document. If you press the Printable Page button on the Review page, you will see a list of pre-approval documents associated with your action that are available for printing. If no documents are available, pressing Printable Page displays a printer-friendly version of the Review Page.
On final approval, the Initiator receives a notification with a link to a list of available post-approval document versions.
SSHR actions use Oracle Approvals Management (AME), a rules-based expert system, to route actions via supervisory hierarchy (default), or routing list. Your implementation team can define business rules that generate a routing list automatically, ensuring that SSHR routes your action to the appropriate parties for approval. Your setup can designate approvers who record decisions by external authorities, such as unions or workers councils.
Pressing the Submit button on the Review page sends your action to an approval process that chooses the appropriate approvers automatically. Approvers receive a notification in their Worklist with a link to open the action, and (with update privileges) they can edit, change the effective date, or attach supporting documents. Approvers can return the action for correction to any previous approver on the chain. If you are the final approver, pressing Submit applies the action to the database.
Note: If the database encounters intervening approved actions on your selected person, workflow sends the action to a Human Resources representative on final approval for manual entry of all appropriate changes. You see a warning message if this is the case.
See: Managing Conflicting Actions
The Review page also provides options to add approvers and select additional notification recipients.
Workflow users receive notifications in their Worklist. Standard formats include:
Approval Required
Saved for Later
Return for Correction
FYI
Queries from other approvers
When an approver or HR representative retrieves a notification requiring approval, the Notification Details page appears, providing notes and warnings related to the action. Notification Details provide the following options:
Approve
Reject
Reassign
Request Information
View Action
Update Action
Return for Correction
Most options include an opportunity to provide comments or ask questions.
Unless your implementation team has decided to have all actions take effect on approval, the Effective Date page appears when an approver opens an action. Any approver in the chain of recipients with update privileges can change the effective date here. Approvers may see messages or warnings about intervening or future-dated actions that the database has encountered. See Managing Conflicting Actions
Any approver can return an action for correction to any previous approver on the chain. In order to make a change, recipients must have a workflow role that grants update privileges.
The FYI notifications display changes to the transactions that are either approved or rejected. The FYI notifications page displays a region with Proposed column to view transaction data changes and a Supporting Documents region to view any attachments added to the transaction. If any attachments are added to a transaction's Review page, then these attachments appear as a link on the FYI Notification page. For example, after a manager approves a leave of absence transaction, the recipient who receives the FYI notification can view the absence details that have been approved. The recipient need not navigate to the relevant self-service pages in the application to understand the changes that have been approved.
Note: The FYI notification page displays transaction data changes only if the value of the pNtfFyiDetails function parameter is set to Y for form functions.
The FYI notifications retrieve information from the transaction table and not from the base table. Therefore if transaction data is dependent on base table and base table data is deleted then relevant data is not displayed in FYI notifications.
See: Menu Function Parameter Descriptions
HR professionals, managers, and workers can use the Transaction Monitor page to track and view details of the self-service transactions. As the list of all self-service transactions is available on a single-page, users can efficiently track the status of their transactions.
Users can track transactions using the following status values and view their details.
Pending Approval
Complete
Defer
Error
Note: In case, data is deleted from base tables, then the transaction details will not be available.
The Transaction Monitor feature helps users to view details of all pending or completed transactions. They can navigate to the details page of the transaction to view approval history, comments, and attachments.
Oracle SSHR displays only those transactions from the date when your enterprise started using the Transaction Monitor functionality.
As, HR professionals, managers, and workers, you can use following search criteria to search for self-service transactions:
Function Name: Select the function for which you want to view self-service transactions.
Transaction Initiator: This field represents the person who initiated the transaction.
For workers, this field is read-only and displays the name of the person who logged in using the Employee Self-Service. By default, the Transaction Monitor functionality is not available from the Contingent Worker Self-Service responsibility.
For managers, this field is read-only and displays the name of the person who logged in as a manager using the Manager Self-Service responsibility.
HR professionals, when they log in using the HR Professional responsibility, can search for workers or managers who initiated self-service transactions.
Transaction Created for: This field represents the person for whom the self-service transaction is initiated.
For workers, this field is read-only and displays the name of the person who logged in using the Employee Self-Service or Contingent Worker Self-Service responsibility.
Managers, when they log in using the Manager Self-Service responsibility, can search for any of their subordinates for whom self-service transactions are initiated. Access to person records depends on the security profile.
HR Professionals, when they log in using the HR Professional responsibility, can search for managers or workers for whom self-service transactions are initiated. Access to person records depends on the security profile.
Specify the period start date from when you would like to view the transactions. Specify the period end date until when you could like to view the transactions.
Select any of the following statuses to view transactions:
Pending Approval
Complete
Defer
Error
You can select only one status at a time. You cannot select multiple or all statuses. For transactions that are at the Error status, users are navigated to the Workflow Status Monitor pages.
Depending on the search criteria that you specify, you can view transactions and their details. To view details of a transaction, click the icon in the Transaction Details column.
Note: The following rules apply to the Transaction Monitor feature:
Managers cannot view transactions initiated by their subordinates.
Users cannot view draft transactions or save for later transactions.
Approvers cannot search for transactions approved by them.
The Action History Details are displayed only for those transactions, where AME is enabled.
This topic provides details about the Transaction Monitor function.
This module can be accessed from the following menus and functions:
User Menu Name | Function Name |
---|---|
Manager Self Service | Transaction Monitor (HR_TRANSACTION_MGR_SS) |
Employee Self Service | Transaction Monitor (HR_TRANSACTION_EMP_SS) |
HR Professional | Transaction Monitor (HR_TRANSACTION_HR_SS) |
Not Applicable
Not Applicable
Not applicable
The Transaction Monitor feature supports the following list of SSHR functions:
Function Name | User Function Name |
---|---|
HR_TERMINATION_SS | Termination |
HR_COMPETENCE_PROFILE_SS | Competency Profile |
HR_PERINFO_SS | Personal Information |
HR_QUALIFICATION_SS | Qualification |
HR_AWARD_SS | Award |
HR_CAED_SS | Release Information |
HR_SIT_SS | Special Information Types |
HR_MANAGER_SS | Change Manager |
HR_TERMINATION_COMP_SS | Termination with Compensation V4.0 |
HR_CHANGE_JOB_SS | Change Job |
HR_CHG_COST_LOC_SUP_SS | Change Cost Center, Location and Manager |
PQH_TENURE_STATUS | Tenure Status |
PQH_ACADEMIC_RANK | Academic Rank |
HR_LOA_SS | Absence Management |
HR_CHANGE_JOB_TERMS_SS | Change Job and Terms |
HR_CHG_COST_TRM_LOC_SUP_SS | Change Cost Center, Terms and Manager |
HR_EIT_SS | Extra Information Types |
PQH_EMP_REVIEWS | Employee Reviews V4.0 |
HR_EIT_A8A_SS | SG IRASLINE Person EIT |
HR_CEI_SS | Contact Extra Information |
PQPVEHINFOPROCESS_SS | SS Vehicle Repository |
HR_DOR_SS | Documents of Record |
HR_EMP_STATUS_CHANGE_SS | Worker Status Change |
HR_CHG_HOURS_SS | Change Hours |
HR_PAY_RATE_CHANGE_SS | Change Pay |
HR_EMP_TRANSFER_SS | Transfer |
HR_EMP_TERMS_CHANGE_SS | Change Worker Status and Terms |
HR_NEW_HIRE_SS | Hire |
HR_APPL_HIRE_SS | Applicant Hire |
BEN_SS_MGR_ADV_ICD | Self Service Individual Compensation Distributions-Internal |
HR_REVERSE_TERMINATION_SS | Reverse Termination |
HR_TERM_SS | Voluntary Termination |
HR_CWKPLACE_SS | Contingent Worker Placement |
HR_GOLD_CREATE_SS | Global Deployments Create Page |
HR_GOLD_UPDATE_SS | Global Deployments Update Page |
Self-service registration for new users helps to reduce the workload and costs of HR administration. HR professionals can use this feature to add new employees to the Oracle HRMS database. The self-service approach reduces the rollout effort for large companies where the HR department is not centrally located. You can add or edit user-friendly tips and text messages in the user interface to reduce the need for end user training.
You can also use self-service registration to help shift the workload from the HR department onto the hiring line manager or even the individual employees by allowing them to register their own employee details.
Using the New Employee Registration function, employees log on with a generic company user name and supplied password or they access the function directly with a "guest login", which is invisible to users. They complete online registration, giving details such as name, address, employment details, and family members. They can create their own self-service user names and passwords (or you can choose to generate these automatically). Alternatively, HR administrators or line managers can create the employee records and self-service user names for their new hires.
Using the Non-employee Registration function, other people can log on to create non-employee records in Oracle HRMS. This is most commonly used by US third party benefits providers using Oracle Advanced Benefits. It enables benefits participants or their dependents who become COBRA qualified due to a life event (such as divorce or termination) to register so they can elect their COBRA coverage through self-service.
Using the Create User Name function, people who already have an HR record in the database can create their own self-service user names and passwords. This function provides an alternative to the existing methods of creating users, which are using the Users window or creating self-service users in a batch.
If you have implemented Standard Benefits or Oracle Advanced Benefits, benefits participants can register directly with you through the World Wide Web or over a corporate intranet. If you are a third party benefits administrator or provider, this means that employees' HR departments are no longer responsible for transferring HR information to your database.
Once a person completes the registration, they can navigate directly to the Self-Service Benefits functions, which process detected life events that enable benefits elections or unrestricted program elections.
You give a generic user name and password to people, enabling them to access self-service initially to register. You can choose how many generic user names you create. For example, a third party benefits provider is likely to create one generic user name for each subscriber organization. Employers might create one user name for the entire business group, or different names based on the organization hierarchy structure.
Each user name is associated with an organization using the profile option OAB:User to Organization Link. This defaults the organization for a new employee assignment, but the user can select another organization from the business group during registration. You can set this profile option at the responsibility level--to link each generic user name with a separate organization--or at the site, or application levels.
Similarly, for each generic user name you can select the default payroll to be assigned, by setting the profile option OAB:User to Payroll Link at the responsibility level. You can also set this profile option at the site, or application levels.
By default, all newly registered users are assigned the seeded Self Registered Employee Default responsibility. This responsibility gives them access to a subset of self-service functions, such as Self-Service Benefits enrollment, person name, address, and contact information. You can create your own responsibilities and assign them to responsibilities, or the whole site by setting the OAB: Self Registered User Responsibility profile option at the appropriate level.
These modules are available under the predefined New User Registration Responsibility. They can be used as part of employee self-service or manager self-service. Using New Employee Registration, users log on with a generic user name to create their own employee records in Oracle HRMS, and their own self-service user name and password. Using Non-employee Registration, other people can log on to create non-employee records in your Oracle HRMS.
User Menu Name | Function Name |
---|---|
New User Registration | New Employee Registration |
New User Registration | Non-employee Registration |
The workflow details for this module are listed below:
New Employee Registration Process and COBRA Registration Process
See: Overview of Oracle Workflow for Users, Oracle Workflow Guide
Note: Approval is not supported by these processes.
Not applicable
Region | Tip Type | Message Name |
---|---|---|
Ben Life Event Cobra | Message | BEN_COBRA_LIFE_EVENT_DATE |
Ben Life Event Cobra | Message | BEN_LIFE_EVENT_COBRA |
Ben Life Event Current | Message | BEN_LIFE_EVENT_DATE |
Ben Life Event Current | Message | BEN_LIFE_EVENT_CURRENT |
Registration user Main Content | Short Tip | HR_INCORRECT_PASSWORD_LENGTH |
Verification Content | DATE_FORMAT |
See: Adding Instructions to Web Pages
Region | Flex Name | Flex Code |
---|---|---|
Verification Content | Additional Personal Details Flex | PER_PEOPLE |
Extra Information Type Update | Extra Person Information | Person Developer DDF |
Profile | Configurable Levels | Values | Default |
---|---|---|---|
OAB: User to Organization Link | All | Organizations | Null |
OAB User to Payroll Link | All | Payrolls | Null |
OAB: Self Registered User Responsibility | All | Responsibilities | Self Registered Employee Default Responsibility |
HR: Business Group | Set at Responsibility level | Business groups | |
HR: Self Service HR Licensed | Site--set to Yes | Yes/No | No |
This module is available under the predefined New User Registration Responsibility. It can be used as part of employee self-service. Using Create User Name, people who already have an HR record in Oracle HRMS can create their own self-service user names and passwords.
User Menu Name | Function Name |
---|---|
New User Registration | Create User Name |
The workflow details for this module are listed below:
Create User Name Process
Note: Approval is not supported by these processes.
Not applicable
Region | Tip Type | Message Name |
---|---|---|
New User Creation Verification Content | DATE_FORMAT | |
Registration User Main Content | Short Tip | HR_INCORRECT_PASSWORD_LENGTH |
See: Adding Instructions to Web Pages
Region | Flex Name | Flex Code |
---|---|---|
New User Creation Verification Content | Additional Personal Details | PER_PEOPLE |
Profile | Configurable Levels | Values | Default |
---|---|---|---|
OAB: Self Registered User Responsibility | All | Responsibilities | Self Registered Employee Default Responsibility |
HR: Business Group | Set at Responsibility level | Business groups | |
HR: Self Service HR Licensed | Site--set to Yes | Yes/No | No |
As supplied, the New User Registration processes (Create New User, New Employee Registration, and Non-employee Registration) include a User ID page where users can enter a user name and password for logging on to self service. Alternatively, you can implement some additional code so that the user name and password are generated by the application when the user clicks a button on this page. You can implement this using user hooks.
There are two user hooks:
BEN_PROCESS_USER_SS_BK1.CREATE_USER_DETAILS_B (which we will call the "Before user hook" because it runs before the user name is created)
BEN_PROCESS_USER_SS_BK1.CREATE_USER_DETAILS_A (which we will call the "After user hook" because it runs after the user name is created)
They are called in the user api BEN_PROCESS_USER_SS_API. The user hooks communicate with this caller api through a set of globals. These globals are defined in the package BEN_PROCESS_USER_UTILITY. The usage notes within this package explain how to use the globals.
Use the Before user hook to set globals with user and responsibility information. To set the globals with user information, use G_FND_USER_RECORD. To associate responsibility and security group/security profile information with the user, use G_FND_RESP_RECORD. If you do not set the responsibility and security information using globals, the application uses the responsibility from the OAB:Self Registered Employee Responsibility profile option.
The minimum you need to do to create a user with today's date as the start date is to put the following two lines in the Before user hook.
ben_process_user_utility.g_fnd_user_record.user_name := 'testuser'; ben_process_user_utility.g_fnd_user_record.password := 'testpassword';
You can also set up globals for start_date, end_date, last_logon_date, password_date, password_accesses_left, password_lifespan_accesses, password_lifespan_days, email_address, fax, description, customer_id, and supplier_id.
Important: Never set the employee_id global within the New User Registration processes. If you do so, the global overwrites the employee id created during the process and so the user will not be associated with the correct employee id. If you want to use the user wrapper api outside of the page for creating user name and password, you can then pass in the global for employee id.
Use the After user hook to accomplish something that needs to be done after a user is created. For example, the Before user hook enables you to pass in information about a responsibility, but it does not handle multiple responsibilities. You could pass no information about responsibility in the Before user hook and instead call the appropriate "fnd" api(s) in the After hook to take care of the responsibility, menu, or any profile value that you want to associate with the user.
Another use for the After hook might be to write code to populate some tables--such as communication or extract tables--from where you can extract the information later.
Follow these steps to create the generic user name and password that will enable new employees, managers, and other users to access self-service to register themselves in your database. These steps are required if you are using any of the following processes:
New Employee Registration
Non-employee Registration
Create User Name
If you are implementing new user registration in more than one business group, see: Setting Up Generic User IDs in Multiple Business Groups. If you are implementing new user registration within a single business group, use the following procedure.
If you are only implementing the Create User Name process (that is, you are using self-service to create new users but not to create HRMS records), you can omit steps 7and8.
To set up self-service registration in a single business group
If you are a third party benefits provider, create an organization to represent each subscriber organization or company in which you are providing benefits.
If you are not a third party benefits provider, you create your HR organization hierarchy as required within your business group. Skip the next step since it applies to third parties who administer multiple companies within a single business group.
See: Creating an Organization, Oracle HRMS Enterprise and Workforce Management Guide
See: Adapting and Creating a New Business Group, Oracle HRMS Enterprise and Workforce Management Guide
Third party benefits providers using Oracle Advanced Benefits only: Establish a link between your organizations and the relevant benefits program. For example, link each subscriber organization to the subscriber's benefit program. Use the Organizations tabbed region of the Programs window.
This link enables the Participation process to select the appropriate benefit programs for a particular organization when processing people within that organization. This enhances system performance by limiting the retrieval of records to the person's organization. The process selects the programs pertaining to that organization and then examines the person's eligibility restrictions.
Note: Set the system profile Limit By Persons Organization to Yes to enable this feature for the Benefit Service Center window. Set the Limit to Organization parameter to limit the Participation batch process.
See: Defining a Benefits Program, Oracle HRMS Compensation and Benefits Management Guide
See: Associating an Organization with a Benefits Program, Oracle HRMS Compensation and Benefits Management Guide
Review the predefined New User Registration responsibility and New User Registration menu, which gives access to the New Employee Registration, Non-employee Registration and Create User Name functions in self-service.
If you only need one generic user name for the business group, you can use the predefined New User Registration responsibility.
Otherwise, create a copy of the New User Registration responsibility for each organization for which you will create a separate generic user name. You might want more than one responsibility for each organization. For example, you might give new employees a responsibility that gives them access to the New Employee Registration function only. You could create a second responsibility for people who already exist in the database but need to create a self-service user name and password. This would reduce errors by giving each person access to one function only.
Create a generic user name and password for the business group or for each organization, so that new people can log on to the Registration page. If users will log in with a guest login, create the guest user instead. For further information on guest users, see: Configuring the Create User Name Process.
See: Users Window, Oracle E-Business Suite System Administrator's Guide - Security
Add the New User Registration responsibility (or the responsibilities you created in step 3) to the generic user name for each organization.
Update the system profile HR:Business Group at the appropriate level so that the generic user name points to the business group in which the person registering belongs.
Update the OAB:User to Organization Link system profile at the responsibility level to link the New User Registration responsibility (or your copies) to the organization in which the person belongs.
Important: Check to ensure that the organization you select is correct. The list of values contains all the organizations in the database. You must select an organization defined in the business group associated with the user name.
See:System Profile Values Window, Oracle E-Business Suite System Administrator's Guide - Security
Update the profile OAB User to Payroll Link at the responsibility level for the New User Registration responsibility (or your copies) to provide a default employee payroll. If this profile is blank and the employee is not assigned to a payroll, OAB processes use the benefits default payroll selected for the business group in which the person will be registered.
Important: Check to ensure that the payroll you select is correct. The list of values contains all the payrolls in the database. You must select a payroll defined in the business group associated with the user name.
Check whether the predefined Self Registered Employee Default responsibility is appropriate for all your organizations. If it is not, create any new self-service responsibilities you require.
Note: The application assigns this responsibility to users when they complete their registration. This responsibility contains the New Employee Default Menu that the participant uses to access the self-service web pages after the initial registration.
If you created just one new responsibility in the previous step, change the profile OAB: Self Registered User Responsibility at the site level to point to your new responsibility. If you created a different responsibility for each organization, add it to the profile OAB: Self Registered User Responsibility at the responsibility level for the New User Registration responsibility (or your copies).
Note: Oracle delivers the system profile OAB: Self Registered User Responsibility with the seeded value of Self Registered Employee Default Responsibility predefined at the site level. The self-service menu for this seeded responsibility gives access to only a subset of employee self-service transactions.
Log into Self-Service with the user name and password you created.
As the system administrator, the first time you log into self-service, you gain access by using the password you created in step 4. After entering it, you must change the password to a generic password you want the new people to use when accessing self-service initially to register.
Use the New Employee Registration function to create a new person and a user name for that person. The application assigns the responsibility set in the OAB: Self Registered User Responsibility profile (step 10) to the new user name.
This procedure is appropriate for third party benefit providers who are creating a separate business group for each company or subscriber organization. It is also appropriate for employers or third party administrators who have multiple business groups on a single database.
To set up self-service registration in multiple business groups
Third party benefits providers: Create a business group to represent each subscriber organization or company in which you are providing benefits. In each business group, create an HR organization for the subscriber.
Employers: Decide how many generic user names you want to create. You will need at least one generic user name for each business group. You may want to create separate user names for the organizational hierarchies within each business group.
See: Creating an Organization, Oracle HRMS Enterprise and Workforce Management Guide
See: Adapting and Creating a New Business Group, Oracle HRMS Enterprise and Workforce Management Guide
Review the predefined New User Registration responsibility and New User Registration menu, which gives access to the New Employee Registration, Non-employee Registration and Create User Name functions in self-service.
Create a copy of the New User Registration responsibility for each business group. You might want more than one responsibility for each business group. For example, you might give new employees a responsibility that gives them access to the New Employee Registration function only. You could create a second responsibility for people who already exist in the database but need to create a self-service user name and password. This would reduce errors by giving each person access to one function only.
Create a generic user name and password for each organization so that new people can log on to the Registration page. If users will log in with a guest login, create the guest user instead. For further information on guest users, see: Configuring the Create User Name Process.
See: Users Window, Oracle E-Business Suite System Administrator's Guide - Security
Add your copy of the New User Registration responsibility to the generic user name for each organization.
Update the system profile HR:Business Group at the appropriate level so that the generic user name points to the business group in which the person registering belongs.
Update the OAB:User to Organization Link system profile at the user or responsibility level to link the New User Registration responsibility (or your copies) to the organization in which the person belongs.
Important: Check to ensure that the organization you select is correct. The list of values contains all the organizations in the database. You must select an organization defined in the business group associated with the user name.
See: System Profile Values Window, Oracle E-Business Suite System Administrator's Guide - Security
Update the profile OAB User to Payroll Link at the responsibility level for the New User Registration responsibility (or your copies) to provide a default employee payroll. If this profile is blank and the employee is not assigned to a payroll, OAB processes use the benefits default payroll selected for the business group in which the person will be registered.
Important: Check to ensure that the payroll you select is correct. The list of values contains all the payrolls in the database. You must select a payroll defined in the business group associated with the user name.
Check whether the predefined Self Registered Employee Default responsibility is appropriate for all your organizations.
If it is not, create any new self-service responsibilities you require.
If it is, create a copy for each organization.
Update the system profile HR:Business Group at the responsibility level to point to the correct business group.
Note: The application assigns this responsibility to users when they complete their registration. This responsibility contains the New Employee Default Menu that the participant uses to access the self-service web pages after the initial registration.
Update the system profile OAB: Self Registered User Responsibility at the responsibility level with the name of the responsibility to use for that organization (created in step ).
Note: Oracle delivers the system profile OAB: Self Registered User Responsibility with the seeded value of Self Registered Employee Default Responsibility predefined at the site level. The self-service menu for this seeded responsibility gives access to only a subset of employee self-service transactions.
Log into Self-Service with the user name and password you created.
As the system administrator, the first time you log into self-service, you gain access by using the password you created in step 3. After entering it, you must change the password to the generic password you want new people to use when accessing self-service initially to register.
Use the New Employee Registration function to create a new person and a user name for that person. The application assigns the responsibility set in the OAB:Self Registered User Responsibility profile (step 9) to the new user name.
These processes are part of the Human Resources Self-Service item type. The New Employee Registration process displays the pages for new employees to create HR records and self-service user names for themselves. The Non-employee Registration process creates person records in the HRMS system for people who are not employees. This process is used by US benefit providers who have licensed Oracle Advanced Benefits to display pages for participants or dependents to register on the system to elect COBRA coverage.
These processes include, by default, the following pages:
Page | Required? | Purpose |
---|---|---|
Introduction | No | This page includes a checklist of information that new users must have when entering their registration, and a legal agreement that users must agree to before proceeding. |
Verification | No | This page has the user enter minimal information about themselves. This way the system can check for their existence on the database before they attempt to register their data. |
Basic Details | Yes | Users enter marital status, and other personal data. |
Main Address | Yes | Users can enter a primary address and two other addresses. |
Phone Numbers | No | Users can enter the phone numbers they require. |
Assignment | Yes, for New Employee process (not in non- employee process) | Employees can fill in information about their organization, job, position, grade, payroll, assignment status, people group, and additional employment information. |
Family Member Coverage | No | This page simply asks users whether they wish to enter details of other family members. If they confirm that they do, the Add Family Members page appears. |
Add Family Members | No | Users can enter names, addresses, phone numbers, and additional personal information for as many contacts as they require. |
Life Events | No | Relevant to US Third Party Benefits providers only. Users can select the life event that has made them eligible for a benefits program. This creates a potential life event for the person. NOTE: Employers must remove this page from the process. |
User Name | No | On this page, users can create their own user id and password. Alternatively you can generate user names and passwords. A user hook is provided so that you can write the PL/SQL to generate the user names and passwords as you require. |
Review | Yes | This page summarizes all the information in the database about the new user. If the user clicks Submit, the data is saved and the Confirmation page displays. |
Confirmation | No | If you want to enable users to enroll themselves in benefits, you can display the Enroll Now button on this page. |
Note: It is not currently possible to route the information entered by the user for approval by workflow. You can set up Alerts to notify the HR administrator that a new person record has been created.
To configure the Registration processes, you make some changes using Workflow Builder and others using the Personalization Framework.
To configure the New Employee and Non-employee Registration workflows
Decide which pages you want to use in the process. You must include Personal Details, Main Address, Review, Cancel, and--for the New Employee Registration process only--Employment Details (to identify the correct organization).
To delete pages, delete the corresponding activities from the workflow process.
Employers must delete the Life Event page from the registration process. Oracle Advanced Benefits customers can use life event triggers in the database to determine benefit enrollment opportunities. There are no life event restriction capabilities in Standard Benefits.
Decide in what sequence you want pages to appear. The Introduction page normally appears first, followed by Personal Details. The only pages that can come before Personal Details are Introduction and Verification. For the Non-employee Registration workflow, the life event page must be before the Personal Details page.
To change the sequence of pages, edit the workflow process diagram.
For each region, decide which region items you want to display. If you have implemented Standard Benefits or Oracle Advanced Benefits, ensure you are including all the fields that capture information required to assess benefits eligibility.
On the Personal Information page:
You must display the Last Name, Gender and Hire Date fields.
If you use rates, and therefore need a Payroll, you must require a birth date.
In non-US countries, you should hide the field Covered Under Medicare.
Make the Employee Number field enterable if you do not generate employee numbers in your business group.
On the Employment Information page (New Employee Registration only):
You must display the Organization field.
If you use rates or element entries, you must display the Payroll field.
In localizations that use GRE, you should display the GRE field.
On the Verification page:
You can add fields to assist the search, such as national identifier (for example, social security number), person descriptive flexfields, employee number, and email address.
If the information entered on the Verification page matches more than one person, the application displays a tables of the duplicates so the user can choose one. Decide what information to include in this table. You can add birth date, Social Security Number, employee number, person descriptive flexfields, and FND username.
For a list of configurable regions, see: New Employee Registration and Non-employee Registration.
See also: Configuring Web Pages
This section is relevant only to third party benefits providers who are including the Life Events page in the process flows. Employers who use Oracle Advanced Benefits should rely on life event triggers to determine the necessary processing instead of using this page.
You determine which life events appear on the Life Events page by the Selectable for Self-Service code you enter when you define the life event in the professional user interface. The code choices are:
All--meaning that the life event can be selected in all self-service processes that use the Life Events page.
Basic Registration--meaning that the life event can be selected in the New Employee Registration process
COBRA Registration--meaning that the life event can be selected in the Non-employee Registration process
Basic and COBRA Registration--meaning that the life event can be selected in both the New Employee and the Non-employee Registration processes
Colliding Life Events
When a person selects a life event from this page, the process will insert the event as a potential life event for the person. By completing the rest of the registration process, the person may have other life events detected due to life event triggers in the business group. Ensure that your life event collapsing and collision logic leaves a user with just one "winning" potential life event during the Participation Process. You could do this by one of the following approaches:
Ensuring that all life events that can be selected in Registration have the Override check box selected (and other life events that might be triggered do not). Then, during setup of collapsing life events, you could choose which event should win if there is more than one overriding event.
Turning off automatic triggering of life events
Removing Life Event page from workflow and configuring life event triggers in the business group to be detected based on data entered by the person during the registration process. This is the approach that employers should use to determine data changes that may give the person an opportunity to make benefit election changes.
The Create User Name Process workflow within the Human Resources Self-Service item type displays the pages for people who already have a record on the HR database to create their own self-service user names and passwords.
This process includes, by default, the following pages:
Page | Required? | Purpose |
---|---|---|
Verification | Yes | This page has the user enter minimal information about themselves. This page must find one and only one person matching the information entered so that the User is connected to the correct HR record |
User Name | Yes | On this page, users can create their own user id and password. Alternatively you can generate user names and passwords. A user hook is provided so that you can write the PL/SQL to generate the user names and passwords as you require. |
Review | Yes | This page summarizes all the information in the database about the new user. If the user clicks Submit, the data is saved and the Confirmation page displays. |
Confirmation | No | If you want to enable users to enroll themselves in benefits, you can display the Enroll Now button on this page. |
To configure the Create User Name process
Decide whether users should log on to use this process with a generic company ID or with a guest ID (which would happen automatically and be invisible to the user).
If you decide to use a company ID for extra security:
Decide whether to create an ID specific to this process, or shared with the new employee registration process. This determines whether the user sees a menu of processes after logging on, or is taken straight to the Create User Name process.
Decide how to communicate the company IDs to your users. One approach--if you have licensed Oracle Advanced Benefits--is to create a new communication type and use the Determine Communications batch process. This approach will only work for people currently in the database.
If you decide to use a guest ID, there are three approaches you can use. Do one of the following:
In the Users window, create the guest user with the user name GUESTOAB and the password GUESTOAB. You can grant this user the predefined New User Registration responsibility or your copy of it. Log on using this user to change the password to WELCOME.
Call the supplied pl/sql procedure ben_guest_user_api without passing a user name and password. The procedure uses user name GUESTOAB and the password WELCOME. It passes the user name and unencrypted password into the call to oraclehomepage.home().
Note: Call ben_guest_user_api from a URL in this way: [APPS_WEB_AGENT]ben_guest_user_api.login?i_1=USERNAME&i_2=PASSWORD&rmode=2
In the Users window, create the guest user with any name and password. Log on using this user to change the password.
Call the supplied pl/sql procedure ben_guest_user_api, passing a user name and unencrypted password. (For the format of the call, see the Note above) If the user name is passed in, the password must be too, or the procedure returns an error. The procedure passes the user name and unencrypted password into the call to oraclehomepage.home().
Call oraclehomepage.home directly passing a user name/password if desired. (For example, oraclehomepage.home?userid=<your user name>&password=<your password>).
On the Verification page:
Decide what information a user must enter on the Verification page of the system to identify the existing HR person record. By default this information is: first name, last name, and birth date. You can add the following fields: national identifier (such as social security number), employee number, email address, supervisor, organization, location, address, and person flexfields.
Decide what to display if the information entered on the Verification page matches more than one person. By default, the application displays an error.
For a list of configurable regions, see: Create User Name.
Decide what should happen if users try to create a user name when they do not have an existing HR record. By default the application issues an error directing the user to retry or Cancel to the menu and contact their administrator. You can configure the message text and the URL associated with the Cancel button. For example, the Cancel button could take them straight to the New Employee Registration process, rather than to the menu.
Determine which responsibility to assign to the new users. By default, all new users are granted the responsibility set in the OAB:Self Registered User Responsibility profile option. You may wish to configure this to vary the responsibility by the person type (especially employee versus non-employee).
To do this, you can create different generic IDs (and responsibilities) for different groups of users and change the OAB:Self Registered User Responsibility profile option at responsibility level.
When a person has registered themselves in the HR database, you can choose to generate their self-service user name and password, rather than have them create their own. You can implement this using user hooks.
To generate user names and passwords
Write the PL/SQL to generate the user names and passwords as you require, using the user hooks.
See: User Hooks To Generate User Names for New User Registration (appendix).
Optionally, edit the instruction text on the User ID page, hide the user name and password fields, and change the button label from Next to Generate.
Consider how you will inform users of their user name. One approach--for Oracle Advanced Benefits customers--is to use a user hook to call your own code that populates the communication tables, and use this information to alert your users. Another approach is to generate the user names in a standard and predictable way from users' names or national identifiers.