11g Release 1 (11.1.3)
Part Number E20378-01
Contents
Previous
Next
|
Oracle® Fusion
Applications Coexistence for HCM Implementation Guide 11g Release 1 (11.1.3) Part Number E20378-01 |
Contents |
Previous |
Next |
This chapter contains the following:
Action Components: How They Work Together
Actions and Action Reasons for HCM Coexistence: Explained
Assignment Statuses: How They are Set Up
Assignment Statuses for HCM Coexistence: Explained
Person Types for HCM Coexistence: Explained
Instance Qualifier Sets: Explained
Elements for HCM Coexistence: Explained
FAQs for Define Human Resource Records for Coexistence
Actions track changes to Human Capital Management (HCM) records, for example, changes to employment and assignment records. When you create or update these records, the action identifies the cause of the creation or change.
You can view a history of effective-dated changes (assignment history, for example), and the action and reason details are particularly useful. You sometimes use actions to categorize the type of change. Each predefined termination action is associated with a termination type (either voluntary or involuntary) to help categorize the termination. For example, the termination actions Death and Reduction in Force are categorized as voluntary and involuntary respectively. In certain cases, actions determine the business flow. For example, you can select from a list of employment-related actions, such as Assignment Change, Transfer, or Termination. The action you select determines the path you take through the current business flow. If you want to use your own action names to track changes, you can create new actions and associate them with the appropriate action types.
Note
If you are creating your own termination-related action, it is highly recommended that you specify the termination type for the action, whether it is voluntary or involuntary. This information is useful for analysis and reporting purposes.
You can optionally associate reasons with actions, for example, a generic action of termination could have reasons such as voluntary retirement or involuntary layoff. The primary reason for doing this is for analysis and reporting purposes. You can view the action and reason details in the Employee Termination Report. Line managers can view predictions about who is likely to leave voluntarily, which are based on existing and historical terminations data. The process that generates the predictions uses the action and reason data to identify whether a termination is voluntary or involuntary. When managers allocate compensation to their workers, they can select from a list of action reasons that help identify the type of or reason for the compensation allocation.
Action type identifies the type of business process associated with the action and determines what happens when you select an action. An action type is associated with one or more predefined actions. You can create your own actions and associate them with the predefined action types. For example, the Hire an Employee action type is associated with the Hire action. You could create an action Hire Part-Time and associate it with the Hire an Employee action type. Your action appears in the Action list of values on the Hire an Employee page. To hire a part-time employee, you could select the Hire Part-Time action instead of the predefined Hire action.
Actions track changes to Human Capital Management (HCM) data, such as employment and compensation records. When you create or update a record, the action value identifies the cause of the record creation or change. Action reasons, which are optional, provide additional information about the action. Oracle Fusion Workforce Compensation uses workforce compensation components and salary components, in addition to compensation actions and action reasons, to track changes to compensation records.
Values that are predefined in both Oracle Fusion and your source application are already mapped. If you have created additional action and action reason values in the source application, you must ensure that they are mapped to values in Oracle Fusion. You can:
Map them to predefined Oracle Fusion values.
Create new actions, action reasons, workforce compensation components, or salary components in Oracle Fusion, as appropriate, and map your source-application values to these new values.
You must complete this task before you load data from your source application to Oracle Fusion.
Note
If your source application is Oracle E-Business Suite HRMS, you must map leaving reasons and salary component codes to Oracle Fusion actions and action reasons. For all other relevant transactional changes, the default Oracle Fusion action (Assignment Change, Hire, or Add Contingent Worker, as appropriate) is used automatically.
Each assignment contains an assignment status. The assignment status contains an HR status, a payroll status , and optionally user statuses. The HR status and payroll status values are linked to the assignment status and are set automatically when the assignment status changes.
This table summarizes the values of the three statuses.
|
Assignment Status |
HR Status |
Payroll Status |
|---|---|---|
|
Active - payroll eligible |
Active |
Process |
|
Active - no payroll |
Active |
Do not process |
|
Suspended - payroll eligible |
Suspended |
Process |
|
Suspended - no payroll |
Suspended |
Do not process |
|
Inactive - payroll eligible |
Inactive |
Process |
|
Inactive - no payroll |
Inactive |
Do not process |
When you create or edit an assignment, you select an action that categorizes the change and determines what are the next steps. Some actions make an automatic change to the assignment status. For example, when you create an assignment, its status is set automatically to Active - payroll eligible. The same action sets the HR status to Active and the payroll status to Process. Otherwise, you must set the assignment status directly.
You can define one or more user names for each assignment status value. If multiple user statuses exist for a HR status, you must designate any one user status as the default status corresponding to the HR status. The default assignment status is attached to an assignment unless you specify a default user status. For example, when you create an assignment, its status is set automatically to the default assignment status corresponding to the HR status Active.
In Oracle Fusion, the predefined assignment status values indicate whether an assignment is active, inactive, or suspended and whether the assignment is eligible for payroll processing.
If you have defined assignment status values in your source application, you need to map them to equivalent values in Oracle Fusion. To support this task, in Oracle Fusion you can:
Rename the user status values associated with the predefined assignment status values
Create new assignment status values
You must complete the setup of assignment statuses in Oracle Fusion and map your source values to Oracle Fusion values before you can load data from the source application.
You use person types to identify different groups of people in your enterprise.
For example, for purposes of reporting, you may want to identify contractual workers in your enterprise with the Contingent Worker person type, and regular employees with the Employee person type. You can maintain information for a group of people on the basis of the person type. You can also secure access to information on the basis of the person type.
These are predefined person types that the application uses to identify a group of people. You cannot change, delete, or create additional system person types.
Each system person type contains a user person type that you can configure to your requirements. You can change, remove, or create additional user person types to suit your enterprise requirements. For example, if your enterprise refers to its employees as associates instead of employees, you change the Employee user person type to Associate. In another example, if you want to classify employees further as equity partners, non-equity partners, and associates, you add these user person types under the Employee system person type. There is no limit to the number of user person types that you can add to a system person type.
Person records for employees and contingent workers only are extracted from your source application for upload to Oracle Fusion. Before performing the initial data load, you must define as user person types in Oracle Fusion any employee and contingent worker person types that exist in your source application. The person types that you define in Oracle Fusion must include any that were predefined in the source application and any that you defined.
Ensure that you select the correct system person type for the user person type you are creating. For example, select the employee system person type when you create employee user person types in Oracle Fusion. Person types other than employee and contingent worker are not supported in the HCM coexistence environment.
Content types are the skills, qualities, and qualifications that you want to track in talent profiles. The content library contains predefined content types such as competencies, languages, and degrees, but you can create new content types as needed. You can also create free-form content types.
Content types contain:
Properties
Relationships
Subscribers
Note
Free-form content types do not contain relationships and do not contain properties until you add them to a profile type.
For each content type, you define the properties that all content items of the content type can or must have. To define properties of the content type, you select fields to be displayed when setting up the content items and the attributes of those fields. The attributes that you specify for each field are: field label, default value, whether the field is required, and whether the field is hidden, display-only, or editable. If the field is attached to a predefined list of values, you also specify the source of the list.
Specify where one content type is a parent of another, or where one content type supports another. Content items of content types with relationships inherit the relationship. You cannot create two kinds of relationships between two types or create a relationship between a type and itself. For example, content type A cannot be both the parent and child of content type B. A content type cannot be related to itself.
Specify the subscriber codes of the applications or other Oracle Fusion products that use each content type. If you do not specify a subscriber code for the content type, you cannot view the content type in other applications. For example, if you add a new content type called Corporate Citizenship to the person profile type, you cannot view the content section for Corporate Citizenship in person profiles until you add the new content type to the HRMS content subscriber code.
Profile types include person profile types and model profile types. The person profile type is the template that you use to create profiles of your workers. The person profile contains the skills, qualities, and qualifications that you want to track for your workers. The person profile type is predefined, and you can have only one. Model profile types are templates for workforce structures such as jobs and positions. Model profiles identify the targeted and required skills and qualifications for a job or position, and also identify work requirements, such as work schedule and travel frequency. You can set up multiple model profile types.
To define profile types, you first specify whether the profile type is a person or model profile. For model profiles, you also specify the workforce structures for which the model profile can be used. For example, if you specify that the model profile can be used for jobs and positions, then you can use the profile type to create both job and position profiles. To define the structure of the profile type, you add one or more content sections using content types from the content library and free-form content types. Define the following for each content section:
Instance qualifier sets
Section properties
Role access
If you have defined instance qualifier sets for the content type, you select the instance qualifier set to use for the sections.
The properties determine the fields and how they are displayed when you create profiles based on the type. For example, properties determine the label for the field, whether the field is required, and whether the field should be included in profile searches. For sections with content types from the content library, you can use the field properties as they have been defined in the content library, or add, remove, or change the properties to suit the content section. You define all of the properties for free-form content types.
You can specify the user roles, such as Employee or Manager, that can view the content section, and which user roles have access to update the section.
An instance qualifier set is a group of codes that you use to uniquely identify different occurrences of the same profile item within the Competency content type. Instance qualifiers typically identify the role of the person who edited a competency. For example, if a worker, the worker's peer, and the worker's manager all enter a rating for a competency on the worker's profile, instance qualifier sets uniquely identify each instance, or, the rating given by each different role. Uniquely identifying different instances of competencies enables you to specify which instance is used when you view or compare profiles.
Each instance qualifier contains a code and a description, which indicate the role or the application that updated the competency. For example, P is the code that is used when an employee's peer rates the employee and T is used for the rating that results from the talent review meeting. You can use the predefined codes and descriptions, or you can create your own.
In addition to the code and description, each instance qualifier has the following properties:
Priority
Employer and manager views
Search ability
Default instance qualifier for employer and manager
Priority determines the order in which different instances of a competency are displayed, and also determines which instance to use when searching and comparing profiles. The lowest number indicates the highest priority.
Employer and manager views determine which instances are visible to employees and to managers.
You can specify whether items that have been assigned the instance qualifier code should be included in profile searches. For example, you might not want the ratings for competencies given by peers to display when other workers are searching person profiles.
You can specify the default instance qualifier to use when managers and employees update a competency. Each time an employee or manager updates a competency, the record is assigned the instance qualifier code that is identified as the employee or manager default code.
HCM coexistence uses elements to hold basic compensation data that you transfer from your source application for use by Oracle Fusion Workforce Compensation during a review cycle. Elements are also used to send compensation bonus amounts from Oracle Fusion back to Oracle PeopleSoft HRMS variable compensation plans, so that bonus payments can be made using the PeopleSoft HRMS payroll application. If you are using Workforce Compensation as part of your HCM coexistence implementation, you must set up elements so that you can transfer compensation data from your source application to Oracle Fusion.
This section describes the simplest way for you to set up the elements you need for HCM coexistence. For each currency in which you pay workers, you create the set of elements described in the following table and associate the elements with the relevant legislative data groups. For example, if you pay workers in the United States, the United Kingdom, Ireland, France, and Germany, you need one set of elements in US Dollars, one in GB Pounds, and one in Euros.
|
Name |
Base Pay |
Bonus |
Allowance |
|---|---|---|---|
|
Type |
Recurring |
Recurring |
Recurring |
|
Classification |
Information |
Information |
Information |
|
Input Currency |
Local |
Local |
Local |
|
Allow multiple entries in same period |
No |
Yes |
Yes |
For HCM coexistence, the emphasis is on simplicity of setup, which means that the recommended approach is very different from the approach you would use if Oracle Fusion were your system of record. All you need to create is a simple element to hold the compensation information you transfer from your source application. The recommendation in Oracle Fusion is to use an element of type Recurring with the classification Information.
The following table summarizes the recommended approach to setting up input values for your elements. You must select the special purpose of Primary Input Value for the Amount input value to include the values in compensation history. You can complete the remaining fields as required by your enterprise.
|
Element Name |
Input Value Name |
Entry Sequence |
Special Purpose |
UOM |
Displayed |
Allow User Entry |
Create Database Item |
|---|---|---|---|---|---|---|---|
|
Base Pay |
Rate |
1 |
Rate |
Money |
Y |
Y |
Y |
|
Amount |
2 |
Primary Input Value |
Money |
Y |
Y |
Y |
|
Bonus |
Percentage |
1 |
Percentage |
Money |
Y |
Y |
Y |
|
Amount |
2 |
Primary Input Value |
Money |
Y |
Y |
Y |
|
Allowance |
Amount |
1 |
Primary Input Value |
Money |
Y |
Y |
Y |
You must create element eligibility for each of your elements. The recommended approach is to create open eligibility: you create element eligibility with a name but no criteria, so that the elements are available in all circumstances.
No. If you no longer want users to select an action or action reason you can enter an end date, beyond which the action or reason will be unavailable.
No. Action types are predefined and can contain one or more actions. You may associate your actions with the predefined action types but not create your own action types.
The status of a user person type determines whether it is available across Oracle Fusion HCM.
If you inactivate a user person type, there is no impact on worker assignments that are currently associated with that person type. However, starting from the date of inactivation, you can no longer select that person type to associate with worker assignments.
Note
You cannot inactivate a default user person type; you must first select a different user person type as the default.
Each system person type contains a default user person type that the application uses to associate with person records for reporting and display purposes. When you hire a worker and specify assignment information, the application associates the default user person type with that worker assignment. However, if you select a different person type, then the application considers the selected person type as the default one for that worker.
You need to use grade rates if you want to see compa-ratio values in Oracle Fusion Workforce Compensation; otherwise, grade rates are not required.
HCM coexistence uses salary bases to link base pay and grade rates for the calculation of compa-ratio values in Oracle Fusion Workforce Compensation.
|
 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
