Oracle® Fusion Applications Compensation Management Implementation Guide 11g Release 7 (11.1.7) Part Number E20376-07

Home

Contents

Book List

Contact Us

Previous

Next

PDF

17 Common HCM Configuration: Define Workforce Business Processes and Events

This chapter contains the following:

Define Checklists

Workforce Lifecycle Manager

Define Profile Eligibility

Define HCM Events

Manage Payroll Process Configuration

Define Checklists

Checklist Components: How They Fit Together

Use checklists for actions that require the completion of standard tasks, such as creating users or reassigning resources. For example, employee hire and termination actions typically require a number of people to complete standard tasks. You create and maintain tasks within a checklist template. You can create checklist templates that can be allocated to persons either automatically or manually.

The figure shows the components of a checklist template and their major relationships.

This figure shows the components of the checklist allocation process and how they relate to each other.

Action

Actions track changes in personal circumstances, for example, new hire, transfer, or termination. Link an action to a checklist template to allocate the checklist to persons automatically when they experience the action. Note that, the checklist template is still available for manual allocation, even if it is linked to an action.

Task

You create tasks within a checklist template, however, managers can also create and maintain tasks within an allocated checklist. You can enter a task duration and specify if a task is required. When the task appears in an allocated checklist, the date in the target end date field reflects this duration. You can set the checklist status to completed only if all the required tasks are complete.

Eligibility Profile

Link an eligibility profile to a checklist task to control whether that task appears in a specific allocated checklist. The task appears in the allocated checklist of a worker only if the worker matches the eligibility criteria.

Task Performer

Performer is the person carrying out the task. You select the task performers' areas of responsibility when you create a checklist template. During checklist allocation, the persons with the selected responsibilities are automatically assigned as performers for the tasks and notified of the assignment. You can view, but not update, the task performers in the allocated checklist.

Allocated Checklist

Allocated checklists are those that have been allocated to workers and contain the tasks relevant to them.

Task Owner

Task owner, generally synonymous with a manager, is the person responsible for ensuring task completion. Managers can display the tasks within an allocated checklist and monitor the status themselves or assign alternative owners for the tasks.

Checklist and Task Statuses: Explained

Managers can display the allocated checklists for their workers and update the checklist and task statuses as necessary. Performers and owners can view the checklist tasks assigned to them in their worklist and update the task status. Note that these statuses are not used to determine the checklist or task availability, they are for information purposes only.

The checklist and task statuses are:

• Initiated

• Completed

• Rejected

• Outstanding

• In Progress

• Suspended

Initiated

The status of the checklist and the tasks in the checklist is automatically set to initiated when you allocate the checklist.

Completed

Use this status to indicate that the checklist or task is complete. You can set the checklist status to completed only if all the required tasks are complete. The checklist status is automatically set to completed when you set the status of the last required task to completed. Note that the task does not disappear from the allocated checklist or the worklist when you set the status to completed. You must delete it yourself if required.

Rejected

Use this status to reject a checklist, for example, because it was wrongly allocated to a person. Task owners or performers can use this status to decline ownership of a task, for example, if the task has been wrongly assigned to them.

Outstanding

Use this status to indicate that the checklist or task is not complete by the target date.

Other Task Statuses

Use the other statuses to record progress made against the checklist or tasks, for example, to indicate that tasks are in progress or the checklist is suspended because of unavailability of resources.

Creating a Checklist Template: Worked Example

This example demonstrates how to create a checklist template that is allocated automatically to all newly hired workers to track certain tasks involved in hiring a worker. The tasks in the checklist vary according to eligibility rules.

The following table summarizes key decisions for this scenario:

Create a checklist template, associate it with the Hire action, and create three tasks for the template.

Prerequisites

1. Create an eligibility profile Manager_Users for all manager users.
2. Create an eligibility profile Work_Location_India for work location India.
3. Create a responsibility IT Support Representative and assign persons to this responsibility.

Creating a Checklist Template

1. On the Person Management Overview page, click Manage Checklist Templates to open the Manage Checklist Templates page.
2. Click Create.
3. On the Create Checklist Templates page, complete the fields, as shown in this table:

   Field	Value
   Name	New Hire
   Category	On Boarding
   Action	Hire

   
   

Creating Checklist Tasks

1. In the Tasks region, click Create.
2. For each task, complete the fields, as shown in this table:

   Field	Create E-mail Account Task	Issue Laptop Task	Issue Meal Vouchers Task
   Required	Yes	No	No
   Eligibility Profile		Manager_Users	India_Work_Location
   Responsibility Type	IT Support Representative	IT Support Representative	HR Representative

   
   
3. Click Submit.

FAQs for Define Checklists

Can managers make changes in the checklist template after creating it?

No. Managers cannot edit or delete the checklist template that they create using the save as template option. However, they can allocate the checklist template to workers and edit the checklist and task attributes within the allocated checklists. The HR specialist can make changes in the checklist template if required and make the revised template available for allocation to all users.

How do changes in the checklist template affect allocated checklists?

Each allocated checklist is a specific instance of the checklist template. Therefore, changes in the checklist template do not affect the allocated checklists. Similarly, the checklist template is unaffected by changes in the allocated checklists.

Workforce Lifecycle Manager

Workforce Lifecycle Manager: Explained

Oracle Fusion Workforce Lifecycle Manager (WLM) provides end to end lifecycle management for workforce related processes. A workforce business process consists of a sequence of tasks that you can assign to specific people to complete through a set of guided steps.

Predefined Workforce Business Processes

WLM provides you with people-centric business processes that orchestrate disparate content into a coherent process that is easy for users to complete and managers to track and action. For example, managers (and HR Specialists) can track the number of processes started within their organization, the average time taken to complete the processes or the outcome of the tasks within the process (HR Specialists only) using the embedded analytics. Workers can also track their processes that are in progress and view details of completed processes.

WLM includes the following processes:

• Preboard Worker. This process includes tasks that the line manager must complete before the worker joins your enterprise. The process contains business rules to differentiate tasks on the basis of the worker type (employee or contingent worker).

• Onboard Worker. Workforce business processes based on this process launch automatically from the Preboard Worker process before the worker's start date in the enterprise. The process contains tasks for employees and contingent workers to complete after they join the enterprise.

Activity Guides

A guided business process is modelled as an activity guide that is based on a business process. The activity guide provides a unified process with a consistent user interface, includes a set of milestones, and displays for the user (line manager or worker) when they launch the process from the WLM work area. It also moves the user to the next task without the need to navigate to multiple applications and provides a visual gauge indicating progress and the number of tasks completed.

Milestones

Milestones outline the steps the process participants have to complete, and hides the complexity of the business process. A milestone is a container for a set of tasks that the line manager or worker has to complete. A milestone is complete when the user successfully runs a specific set of tasks in the milestone by a certain completion date. Each milestone is a specific set of human workflow tasks.

Register Business Processes

You register the workforce business processes before you begin using WLM. Registering the processes identifies the location and the name of the processes as you want them to appear when users launch the processes from the Start Process menu in the work area.

Security in WLM

Workforce business process security profiles secure the workforce business processes that a user can start from the Start Process menu in the work area. The predefined security profile View All Workforce Business Processes includes all registered workforce business processes. A security profile defines the criteria that identify instances of a human capital management (HCM) object. For example, a workforce business process security profile defines the business processes the user can see in the Start Process menu in the work area. When you include a security profile in an HCM data role and provision the data role to a user, that user can access the data instances identified in the security profile. The type of access available to the user (for example whether the user can edit or simply view the data) depends on the job role identified in the HCM data role.

Preboard Worker Business Process: Explained

A workforce business process consists of a sequence of tasks that you can assign to specific people to complete through a set of guided steps. The predefined preboarding process offers you a starting point to create business processes for hiring new workers.

Preboarding

The preboarding process guides managers through the hiring activities to establish a new worker's personal and employment information, set up goals for the new worker, and enter skills data such as competencies and qualifications. Managers can also set up a checklist of tasks for the new worker to complete during the initial onboarding period. This process includes tasks that the line manager must complete before the new worker joins the enterprise. The process contains business rules to differentiate tasks on the basis of the worker type (employee or contingent worker).

The following figure shows a summarized view of the tasks that the line manager completes:

The preboarding process provides the following tasks:

• Add the new worker's personal, employment, and compensation information, the initial task is either Hire Employee or Add Contingent Worker depending on the worker type.

• View Worker Compensation Information and View Worker Employment Information. The manager can check if the salary information and assignment details for the new worker are correct.

• Edit Skills and Qualifications. This task enables managers to build the new worker's skills profile that could include competencies, qualifications, and other accomplishments.

• Add Goals for Direct Reports. This task enables managers to define goals for the new worker and include goals that are aligned with the organizational goals.

• Manage Allocated Checklist. The manager can allocate a checklist of tasks for the new worker.

• Complete Preboarding lists the tasks completed. For example, skipped tasks, completed tasks, and dates of completion.

The following diagram displays the milestones and tasks within the preboarding process:

Onboard Worker Business Process: Explained

A workforce business process consists of a sequence of tasks that you can assign to specific persons to complete through a set of guided steps. The predefined onboarding process offers employees and contingent workers a template to verify personal information, such as addresses, marital status, and contact information.

Onboarding

The onboard process enables the worker to review and update the personal information entered in the preboarding process. Workers can review employment and compensation information, and the system roles assigned to them. In addition, new employees can also enroll in benefits, and enter bank account information. Once payroll has completed for the first payroll period, new employees can view payslip details. Workforce business processes based on this process template launch automatically from the Preboard Worker process before the worker's start date in the enterprise. The process contains tasks for employees and contingent workers to complete after they join the enterprise.

The following figure shows a summarized view of the tasks that employees and contingent workers complete:

The onboarding process provides the following tasks:

• View Welcome Information. Provides new workers with a welcome message and an overview of tasks to complete in the process.

• Verify Personal Information. Enables new workers to review and update the personal details entered for them during the preboarding process, such as name, address, and dependent details.

• View Employment Information and View Compensation Information. Enables new employees to check that their employment and compensation information are correct.

• Edit Skills and Qualifications enables new employees to view and add to the skills profile entered for them during the preboarding process.

• Add Performance Goals enables employees to view existing goals defined during the preboarding process and add their own goals.

• Review Roles enables workers to view the roles assigned to them during the preboarding process.

• Elect Benefits is the enrolment process for workers to select their benefits plans and coverage.

• Manage Personal Payment Methods is the task for entering the bank account or other payment methods that payroll will use to process payments to the worker.

• View Payslip enables employees to view their first payslip.

• Complete Onboarding task provides summary of all the tasks in the process. For example, skipped tasks, completed tasks, and dates of completion.

The following diagram displays the milestones and tasks within the onboarding employee process:

The following diagram displays the milestones and tasks within the onboarding contingent worker process:

Registering a Business Process in Workforce Lifecycle Manager: Worked Example

In this example, you register a process using the preboard worker template. This example demonstrates how you use Oracle Fusion Workforce Lifecycle Manager to register a business process that suits your business needs. You register the workforce processes to identify the location and the name of the processes as you want them to appear when users launch them from the Start Process menu in the work area.

The following table summarizes key decisions in this scenario:

Registering a Process

1. Log in to Functional Setup Manager (FSM) using any role that inherits the Workforce Lifecycle Business Process Administrator Duty Role. For example a data role based on the Human Capital Management Application Administrator role.

   The purpose of registering a business process is to identify the deployed processes to the WLM application. This means the business processes will be made available in the WLM work area for line managers and workers to use. You register the following processes:

   • Preboarding Employee

   • Preboarding Contingent Workers

2. Search and launch the Register Workforce Business Process task.
3. Select Create from the Actions menu.
4. Enter a unique process code. Enter %Preboard%11.1.6% to search for valid processes.
5. Search and select the process endpoint. The endpoint URL is the location of the deployed process and the WLM application uses this URL to launch the process.
6. Enter a unique process name.

   This name appears in the Start Process menu and in embedded analytics.

7. Select the Include in process menu option to make this process available in the Start Process menu in the work area.
8. Select a worker type for the preboarding process. The worker type identifies whether the process is for an employee or contingent worker.

   Note

   Do not select the Pending and NonWorker worker types.

9. Save and close.

Implementing Security in Workforce Lifecycle Manager: Worked Example

In this example you perform two activities: assigning the View All Workforce Business Process Security profile to an abstract role and creating a new security profile and assigning it to an abstract role. This example demonstrates that the security profile you assign to a role determines the workforce business processes that role can view in the Start Process menu in the Workforce Processes work area.

In most cases, you would assign the View All Workforce Business Process security profile to a role, however you can create new security profiles if you want to separate the responsibility of the processes amongst different roles. For example, you can create one security profile for preboarding employees and assign it to the Line Manager role and create another security profile for preboarding contingent workers and assign it to another data or abstract role.

The following table summarizes key decisions in this scenario:

Assigning the View All Workforce Business Process Security Profile to an Abstract Role

1. Log in to Functional Setup Manager (FSM) using the IT Security Manager user and launch the Manage Data Role and Security Profiles task.
2. Search and select the role to which you want to assign the security profile to, for example, the Line Manager role.
3. Select Assign, and assign the View All Workforce Business Processes security profile from the Workforce Business Process section.

   Assigning security profiles is a general implementation step, therefore you can assign security profiles for multiple areas at the same time.

4. Click Submit.

Creating a New Security Profile and Assigning it to an Abstract Role

1. Log in to Functional Setup Manager (FSM) using the IT Security Manager role and launch the Manage Workforce Business Process Security Profiles task.
2. Click Create and enter the unique name for the security profile. For example, View Preboard Worker Workforce Business Process. The check box is enabled by default.
3. Click the Add Row icon to select the workforce business processes the user can launch if assigned this security profile. In this example, select the Preboard Worker process.

   The View All check box is not available because a security profile with View All privileges is available.

4. Select Save and Close. You can now assign the security profile(s) to an existing role.
5. Click on the link in the Name column of the search results table to view the security profile. The Workforce Business Process Security Profile page displays showing the security profile details.
6. Use FSM to search and select the Manage Data Role and Security Profiles task.
7. Search for the role you created, for example the Line Manager role, and select Assign.
8. Assign the View Preboard Worker Workforce Business Processes security profile from the Workforce Business Process section.

   Assigning security profiles is a general implementation step, therefore you can assign security profiles for multiple areas at the same time.

9. Click Submit.

Define Profile Eligibility

Eligibility Components: How They Work Together

You add eligibility criteria to an eligibility profile, and then associate the profile with an object that restricts eligibility.

The following figure shows the relationships between eligibility components.

Eligibility Criteria

You can add different types of eligibility criteria to an eligibility profile. For many common criteria, such as gender or employment status, you can select from a list of predefined criteria values. However, you must create user-defined criteria and derived factors before you can add them to an eligibility profile.

Eligibility Profile

When you add an eligibility criterion to a profile, you define how to use it to determine eligibility. For example, when you add gender as a criterion, you must specify a gender value (male or female) and whether to include or exclude persons who match that value.

Associating the Profile with Objects

You can associate an eligibility profile with different kinds of objects:

• Associate an eligibility profile with a variable rate or variable coverage profile to establish the criteria required to qualify for that rate or coverage.

• Associate an eligibility profile with a checklist task to control whether that task appears in an allocated checklist.

• Associate an eligibility profile with a total compensation statement to apply additional eligibility criteria after statement generation population parameters.

• Associate one or more eligibility profiles with a benefits or compensation object to establish the eligibility criteria for specific plans and options.

Derived Factors: Explained

Derived factors define how to calculate certain eligibility criteria that change over time, such as a person's age or length of service. You add derived factors to eligibility profiles and then associate the profiles with objects that restrict eligibility.

Derived Factor Types

You can create six different types of derived factors: age, compensation, length of service, hours worked, full-time equivalent, and a combination of age and length of service.

Determination Rules and Other Settings

For each factor that you create, you specify one or more rules about how eligibility is determined. For example, the determination rule for an age derived factor specifies the day on which to evaluate the person's calculated age for eligibility. If the determination rule is set to the first of the year, then the person's age as of the first of the year is used to determine eligibility.

For the full-time equivalent factor, you specify the minimum and maximum full-time equivalent percentage and whether to use the primary assignment or the sum of all assignments when evaluating eligibility. For example, if the percentage range is 90 to 100 percent for the sum of all assignments, then a person who works 50 percent full-time on two different assignments is considered eligible.

Other settings define the unit of measure for time or monetary amounts, rounding rules, and minimums and maximums.

Derived Factors: Examples

The following scenarios illustrate how to define different types of derived factors:

Age

Benefits administrators frequently use age factors to determine dependent eligibility. You can also use age as a factor when determining life insurance rates. Age factors typically define a range of ages, referred to as age bands, and rules for evaluating the person's age. The following table illustrates a set of age bands that could be used to determine eligibility for life insurance rates that vary based on age.

The determination rule and other settings for each age band are the same:

Length of Service

A derived factor for length of service defines a range of values and rules for calculating an employee's length of service. The following table illustrates a set of length-of-service bands that could be used to determine eligibility for compensation objects such as bonuses or severance pay.

The determination rule and other settings for each length-of-service band are the same:

Compensation

A derived factor for compensation defines a range of values and rules for calculating an employee's compensation amount. The following table illustrates a set of compensation bands that could be used to determine eligibility for compensation objects such as bonuses or stock options.

The determination rule and other settings for each compensation band are the same:

Age to Use: Points to Consider

The Age to Use value that you select is an important aspect of an age derived factor. This value determines whose birth date is used to calculate the derived age.

Selecting Person's Age to Use

In most cases, you use the Person's value in the Age to Use field to define an age derived factor for either a participant or dependent eligibility profile. In this case, each person's birth date is used to calculate the age criterion by which eligibility is evaluated for that person.

Example

For example, if you select Person's as the Age to Use value, and associate the age derived factor with a dependent eligibility profile, each dependent's eligibility is evaluated based on the age calculated from his or her own birth date.

Selecting Other Age to Use Values

You might select another predefined value in the Age to Use field if you intend to evaluate participant or dependent eligibility or rates based on someone else's age, such as a spouse, child, or other dependent.

Example

If you select Person's oldest child as the Age to Use value, and associate this derived factor with a dependent eligibility profile, eligibility for all dependents is evaluated based on the age of the participant's oldest child. Consequently, when the oldest child reaches the maximum age of eligibility, for instance, all dependents become ineligible.

User-Defined Criteria: Explained

You can define your own criteria to meet any special needs of your organization. For example, if your organization employs deep sea divers and offers different benefits or benefits rates based on how deep they dive, you can create Depth of Diving as a new eligibility criterion.

The data for the eligibility criterion must be stored in a table that is accessible to the application. If the data is stored in either the Person or Assignment table, you can select the table and column from a list, and then specify the lookup type used to validate input values. You can also allow a range of valid values if the field stores a numeric value or a date.

If the data is stored in a table other than the Person or Assignment table, you must first create a formula to retrieve the data from the table, and then set the formula type to User-Defined Criteria.

You can define two sets of criteria on the User-Defined Criteria page. The participant must meet the criteria defined in either set to be considered eligible (or to be excluded from eligibility if the Exclude check box is selected when the criteria is added to an eligibility profile).

After you have created your user-defined criteria, you can add it to an eligibility profile.

User-Defined Criteria: Examples

The following scenarios illustrate how to define different types of user-defined criteria. In each example, you must first create the user-defined criteria and then add it to an eligibility profile and set the criteria values to use in the profile.

Set Eligibility Based on Custom Attribute

A commercial diving company wants to offer different benefit rates to employees who dive to depths greater than 330 feet. This data is stored for each employee in a custom attribute called Dive_Depth in the Person table. To define eligibility based on diving depth, set the following values on the Create or Edit User-Defined Criteria page:

Save the user-defined criteria, and then add it to an eligibility profile. Set the following values on the User-Defined Criteria tab, which is under the Other tab on the Create or Edit Eligibility Profile page:

Save the eligibility profile and associate it with a variable rate profile.

Exclude Work-at-Home Assignments from Eligibility

An employer wants to exclude work-at-home assignment from eligibility for a transportation benefit option. To accomplish this, set the following values on the Create or Edit User-Defined Criteria page:

Save the user-defined criteria, and then add it to an eligibility profile. Set the following values on the User-Defined Criteria tab:

Save the eligibility profile and associate it with the transportation benefit option.

Use a Formula to Determine Eligibility

A company wants to offer a spot incentive bonus to hourly employees who worked 100 percent of their scheduled shift hours in a three month period. To determine eligibility for the bonus, create a formula that calculates scheduled hours less worked hours for each week in the previous three months. If the result of successive calculations is less than or equal to zero, then the formula returns a result of Yes. The first step is to create the formula. Once the formula has been defined, create a user-defined criterion to run the formula. Enter the following values on the Create or Edit User-Defined Criteria page:

Save the user-defined criteria, and then add it to an eligibility profile. Set the following values on the User-Defined Criteria tab:

Save the eligibility profile and associate it with the bonus compensation object.

Range of Scheduled Hours: Example

This example illustrates how to define eligibility criteria based on the number of hours an employee is scheduled to work within a specified period of time.

Weekly and Monthly Ranges

You want to limit eligibility for a benefits offering to employees who were scheduled to work between 30 and 40 hours each week or between 130-160 each month as of the end of the previous quarter. To do this, add two different ranges on the Range of Scheduled Hours tab, which is under the Employment tab on the Create or Edit Eligibility Profile page.

Set the values for the first range as shown in this table:

Set the values for the second range as shown in this table:

Eligibility Profiles: Explained

An eligibility profile defines criteria used to determine whether a person qualifies for a benefits offering, variable rate profile, variable coverage profile, compensation object, checklist task, or other object for which eligibility must be established.

The following are key aspects of working with eligibility profiles:

• Planning and prerequisites

• Specifying the profile type, usage, and assignment usage

• Defining eligibility criteria

• Excluding from eligibility

• Assigning sequence numbers

• Adding multiple criteria

• Viewing the criteria hierarchy

Planning and Prerequisites

Before you create an eligibility profile, consider the following:

• If an eligibility profile uses derived factors, user-defined formulas, or user-defined criteria to establish eligibility, you must create these items before you create the eligibility profile.

• If you are defining eligibility criteria for a checklist task, variable rate profile, or variable coverage profile, you must include all criteria in a single eligibility profile, because these objects can be associated with only one eligibility profile. You can, however, associate multiple eligibility profiles with benefits offerings , compensation objects and the Performance Management object.

• Eligibility profiles are reusable, so use names that identify the criteria being defined rather than the object with which the profile is associated. For example, use "Age-20-25+NonSmoker" rather than "Supplemental Life-Min Rate."

Specifying Profile Types, Usage, and Assignment Usage

When you create an eligibility profile, you specify whether the profile applies to participants or dependents.

• Use participant profiles to define criteria for a person who has a work relationship with the legal employer as an employee, contingent worker, or nonworker.

• Use dependent profiles for participants' spouses, family members, or other individuals who qualify as dependents. Dependent profiles can be associated with only benefit plans and plan types.

An eligibility profile's usage determines the type of objects with which the profile can be associated. For example, set the profile usage to:

• Benefits to make the profile available to associate with benefits objects, such as programs, plans, plan types, options, variable rate profiles, and variable coverage profiles

• Compensation to make the profile available to associate with individual and workforce compensation plans as well as total compensation statements

• Global to make the profile available to multiple business processes

• Goals to make the profile available to associate with goals when creating a goal plan or mass assigning goals, or to associate with goal plans

For Performance Management, you can select any usage.

When you create an eligibility profile, you specify which assignment to use with it. For profiles where usage is Compensation or Performance, select Specific Assignment. For Performance Management eligibility profiles, you must select the Participant type and Specific Assignment as the assignment to use.

Defining Eligibility Criteria

Criteria defined in an eligibility profile are divided into categories:

• Personal: Includes gender, person type, postal code ranges, and other person-specific criteria

• Employment: Includes assignment status, hourly or salaried, job, grade, and other employment-specific criteria

• Derived factors: Includes age, compensation, length of service, hours worked, full-time equivalent, and a combination of age and length of service

• Other: Includes miscellaneous and user-defined criteria

• Related coverage: Includes criteria based on whether a person is covered by, eligible for, or enrolled in other benefits offerings.

Some criteria, such as gender, provide a fixed set of choices. The choices for other criteria, such as person type, are based on values defined in tables. You can define multiple criteria for a given criteria type.

Excluding from Eligibility

For each eligibility criterion that you add to a profile, you can indicate whether persons who meet the criterion are considered eligible or are excluded from eligibility. For example, an age factor can include persons between 20 and 25 years old or exclude persons over 65. If you exclude certain age bands, then all age bands not explicitly excluded are automatically included. Similarly, if you include certain age bands, then all age bands not explicitly included are automatically excluded.

Assigning Sequence Numbers

You must assign a sequence number to each criterion. The sequence determines the order in which the criterion is evaluated relative to other criteria of the same type.

Adding Multiple Criteria

If you define multiple values for the same criteria type, such as two postal code ranges, a person needs to satisfy at least one of the criteria to be considered eligible. For example, a person who resides in either postal range is eligible.

If you include multiple criteria of different types, such as gender and age, a person must meet at least one criterion defined for each criteria type.

Viewing the Criteria Hierarchy

Select the View Hierarchy tab to see a list of all criteria that you have saved for this profile. The list is arranged by criteria type.

Combining Eligibility Criteria or Creating Separate Profiles: Points to Consider

You can define multiple criteria in an eligibility profile or create separate profiles for individual criterion. To determine the best approach, consider the following:

• Does the object you are defining eligibility for support multiple eligibility profiles?

• What is the best approach in terms of efficiency and performance?

Support for Multiple Eligibility Profiles

If you are defining eligibility criteria for a checklist task, variable rate profile, or variable coverage profile, you must include all criteria in a single eligibility profile, because these objects can be associated with only one eligibility profile. You can, however, associate multiple eligibility profiles with benefits offerings and compensation objects.

Efficiency and Performance

For optimum performance and efficiency, you should usually attach profiles at the highest possible level in the benefits object hierarchy and avoid duplicating criteria at lower levels. Plan types in program, plans in program, plans, and options in plans inherit the eligibility criteria associated with the program. For example, to be eligible for a benefits plan type, a person must satisfy eligibility profiles defined at the program level and at the plan type in program level.

However, it is sometimes faster to create more than one profile and attach the profiles at various levels in the hierarchy. For example, you might exclude employees from eligibility at the program level who do not have an active assignment. At the level of plan type in program, you might exclude employees who do not have a full-time assignment. Finally, at the plan level, you might exclude employees whose primary address is not within a service area you define.

Eligibility Profiles: Examples

The following examples illustrate scenarios where eligibility profiles are needed and briefly describe the setup required for each scenario.

401(k) Eligibility

A 401(k) savings plan is restricted to full-time employees under 65 years of age. To restrict eligibility for the plan, you must first create a derived factor for the age band of 65 and older, if one does not already exist. Then create an eligibility profile. Set the Profile Usage to Benefits and the Profile Type to Participant. Add the following criteria:

Associate the eligibility profile with the 401(k) plan.

Bonus Eligibility

A bonus is offered to all employees who received the highest possible performance rating in all rating categories. To restrict eligibility for the bonus, create an eligibility profile. Set the participant type to Participant, profile usage to Compensation or Global, and use in assignment to Specific Assignment. Add the following criteria for each rating category:

Associate the eligibility profile with the bonus compensation object.

Checklist Task Eligibility

A new hire checklist contains tasks that do not apply to employees who work in India. To restrict eligibility for the tasks, create a participant eligibility profile. Set the Profile Usage to Checklist and the Profile Type to Participant. Add the following criteria:

Associate the eligibility profile with each checklist task that does not apply to workers in India.

Creating a Participant Eligibility Profile: Worked Example

This example demonstrates how to create a participant eligibility profile used to determine eligibility for variable life insurance rates. The profile includes two eligibility criteria: age and tobacco. Once the eligibility profile is complete, you can associate it with a variable rate profile.

The following table summarizes key decisions for this scenario.

The following figure shows the tasks to complete in this example:

Prerequisites

1. Create an age derived factor for ages less than 30.

Creating the Eligibility Profile

1. In the Plan Configuration work area, click Manage Eligibility Profiles.
2. Click the Create menu, and then click Create Participant Profile.
3. In the Eligibility Profile Definition region of the Create Participant Eligibility Profile page, complete the fields as shown in this table. Use the default values except where indicated.

   Field	Value
   Name	Age Under 30+Non-Smoking
   Profile Usage	Benefits
   Description	Participant, age under 30, non smoker
   Status	Active
   Assignment to Use	Any assignment

   
   

Adding the Derived Factor for Age

1. In the Eligibility Criteria region, select the Derived Factors tab.
2. On the Age tab, click Create.
3. In the Sequence field, enter 1.
4. In the Age field, select the derived factor that you previously defined for ages under 30.
5. Do not select the Exclude check box.

Adding the Criteria for Tobacco Use

1. Select the Personal tab.
2. On the Uses Tobacco tab, click Create.
3. In the Sequence field, enter 1.
4. In the Tobacco Use field, select None.
5. Do not select the Exclude check box.
6. Click Save and Close.

Associating the Eligibility Profile with a Variable Rate Profile

1. In the Plan Configuration work area, click Manage Benefits Rates.
2. Select the Variable Rates tab.
3. Click Create.
4. In the Eligibility Profile field, select the eligibility profile you just created.
5. Complete other fields as appropriate for the rate.
6. Click Save and Close.

   Note

   You can reuse this eligibility profile by associating it with other objects that restrict eligibility, including benefits offerings, compensation plans, and checklist tasks.

Define HCM Events

HCM Events: Explained

A common events model for Oracle Fusion Human Capital Management (HCM) products defines how to respond to certain data changes or business process trigger points. A common model enables a single event definition to drive both externally published business events and internal processes.

The events model comprises the following key components:

• Event definitions

• Event types

• Event handlers

• Published business events

• Archived event data

Event Definitions

An event definition identifies a set of registered HCM event objects, such as entity objects, that can be used to raise events.

Event Types

Event types define the type of object to be detected, the particular DML mode for the type of data change, such as update, insert, or delete, along with any rules or conditions that further qualify the event. These conditions determine whether an event triggers further processing activities, such as archiving information relating to the event, internal processing initiated by the event, or publication of business events to the SOA framework. A common example of an event type is updates to a particular object attribute.

Event Handlers

When the conditions of an event type are satisfied, an internal handler can specify how related functional areas within HCM are notified or an external handler can specify a published event to be raised.

Published Business Events

An implementer can associate a particular published business event with a particular event definition so that when the change is detected, the associated published business event is raised to the SOA application server. Published business events can be raised from any of the registered HCM event objects.

Archived Event Data

When defining event types, the implementer can indicate which attribute data should be stored for auditing purposes. The availability of archived events data also can assist internal HCM products to determine the nature of specific data changes when they are notified of the occurrence of an event.

When defining which data should be archived for a particular event type, the implementer can also specify the number of calendar days after the detected event that the data must be stored. After the specified number of days, the data can be purged from the database.

Managing HCM Events Types: Points to Consider

You can create or modify HCM event types when the predefined event types do not sufficiently meet the needs of your enterprise.

To determine your approach, consider the following questions:

• Do the predefined event types cover the conditions you want to capture for data change event detection?

• Does your enterprise have custom processes or services associated with a published business event?

  For example, you can modify an existing event type to add a different published business event to be consumed by the new process or service if that is the only modification. If there other modifications you want, such as additional detection conditions or data changes, you can create a new event type.

• Do any required SOA services already exist?

  Examples of published business events as external handlers that invoke SOA processes include ChangedPersonDetails, that invokes a process in Oracle Fusion Trading Community Model, and ChangeLocation, that invokes a process in Oracle Fusion Financials. You can review existing published services in the Oracle Enterprise Repository.

Event Type Customization

The following figure illustrates the decision points for HCM event type customization.

Creating an Event Type from an Existing Event Type: Worked Example

This example demonstrates how to create an event type that is based on a predefined event type but captures additional data.

The following table summarizes the key decisions for this scenario.

In this example, the organization wants to capture changes to telephone extension number data for people within a particular building, and notify the operator who handles incoming calls for that building. The predefined event type does not contain the extension information or publishing conditions for that data, so you add a new condition that is defined to publish only where extension data is changed.

Choosing the Event Type to Extend

Find a predefined event type that best suits your needs by looking for object and attribute similarities. The predefined event types cannot be changed, so instead you create a copy after noting its values to use in the new event type.

1. In the regional search pane of the Setup and Maintenance work area, search for the Manage HCM Event Types task.
2. In the search results table, click Go to Task.
3. In the Source Object field on the Manage HCM Event Types search page, enter PhoneEO and click Search.
4. Select the row for PhoneUpdate and click Edit.
5. Note the values for this event type as shown in the following table:
   

   Field or Tab	Value
   Source Object	PhoneEO
   Rule	eo.New("PhoneType") > "W" & eo.New("PhoneType") < "X"
   DML Mode	Update
   External Handlers Published Event Name	ChangedPersonKeywords

Creating a Copy of the Event Type

Copy the values from the event type you want to extend into a new event type.

1. On the Manage HCM Event Types page, click Create.
2. In the Name field, enter a new name for the event, such as PhoneExtUpdate.
3. In the Source Object field, enter PhoneEO.
4. In the DML Mode list, select Update.
5. In the Storage Duration field, enter the number of days to store any archived data for this event.
6. On the External Handlers tab, click Add Row.
7. Search for and select the ChangedPersonKeywords published event, and then click OK.

Adding Detection Rules

1. In the Rule field in Event Type Details region, enter the following rule that picks up changes on all Phone entity objects whose Phone Type attribute is Work Telephone:

   eo.New("PhoneType") > "W" & eo.New("PhoneType") < "X".)
   

    

2. Run a test to make sure the rule syntax is correct.

   Note

   There is no built-in syntax validation so testing that the rule is working as designed is strongly recommended. You can test the rule and monitor the event publication or examine the log files.

Adding a New Data Attribute

1. On the Condition Attributes tab, select Extension and move it to the Selected Attributes list.
2. Click Save and Close.

Creating an Event Type for a Custom Process: Worked Example

This example demonstrates how to create an event type that invokes a custom business process.

The following table summarizes the key decisions for this scenario.

In this example, the business requires that the application initiates a special process whenever an administrator terminates an employee. This example creates a new event type that detects changes to termination date for employees' period of service.

Prerequisites

1. Create the custom process (external handler) to be triggered as a result of this event detection and name it NotifiedTerminationDate.
2. Ensure that NotifiedTerminationDate exists as a published event in a namespace accessible to the application, adhering to your company standards.

   Note

   If an internal handler is used with an event type, its class name must be fully qualified and must exist in the system classpath.

Creating an Event Type for Termination Notification

1. In the regional search pane of the Setup and Maintenance work area, search for the Manage HCM Event Types task.
2. In the search results table, click Go to Task.
3. On the Manage HCM Event Types page, click Create.
4. In the Name field, enter a new name for the event, such as TerminationDateUpdate.
5. In the Source Object field, enter PeriodOfServiceEO.
6. In the DML Mode list, select Update.
7. In the Storage Duration field, enter the number of days to store any archived data for this event.

Adding a Condition Attribute

1. On the Condition Attributes tab, select one or more of the following related attributes and move them to the Selected Attributes list.

   • AcceptedTerminationDate

   • ActualTerminationDate

   • AdjustedSycDate

   • LastWorkingDate

   • NotifiedTerminationDate

   • OriginalDateOfHire

   • ProjectedTerminationDate

   • RehireRecommendation

Adding a Custom Process

1. On the External Handlers tab, click Add Row.
2. Search for and select the NotifiedTerminationDate published event, and then click OK.
3. Click Save and Close.

Using Rules in Event Types: Examples

Rules in event types define the conditions under which changes to data are detected. Rules must be written using Groovy syntax. All attributes that you include as part of a rule must exist on the object for which the event type is built.

Comparing Attributes

Rule syntax for attribute names is case sensitive, so be sure to enter attributes correctly and enclose them in double quotation marks.

When referring to an object's old value, use the following syntax:

eo.Old("attrName")

When referring to an object's new value, use the following syntax:

eo.New("attrName")

Using Operators

Operators in rule syntax are useful for creating the conditional criteria that you want an event to detect.

The following scenarios illustrate using operators with proper rule syntax:

Detection Based on Object Status

This example shows the proper syntax for the event detection to occur only when the status for an object has a particular value, in this case, when the performance document approval status attribute (PerformanceDocApproveStatusUpdate) is changed to Submitted.

eo.New("StatusCode") == "SUBMITTED"

Detection Only For Specific Object Type

This example shows the proper syntax for the event detection to occur only for a specific object type, in this case, only when the Phone Type attribute of the Phone entity object is Work Telephone.

eo.New("PhoneType") > "W" & eo.New("PhoneType") < "X"

PhoneType represents the lookup table, PHONE_TYPE, which contains three lookup codes for work telephones: W1 W2, and W3. The rule above applies to phone types greater than W and less than X, the next letter of the alphabet, so that detection occurs for all phone types that begin with the letter W. This way, if you later add another lookup code for a fourth work telephone, W4 for example, the rule still applies correctly.

Using Published Events and SOA Services with HCM Events: Highlights

Understanding how HCM events work with external processes requires some knowledge of service-oriented architecture (SOA). The following resources provide key information about using SOA services and how to create, publish, and subscribe to business events in your enterprise using Oracle SOA Suite and Oracle Enterprise Repository.

Details about the SOA framework are in the Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite. The Oracle Enterprise Repository for Oracle Fusion Applications home page describes how to locate and view business events.

SOA Services and Published Events

• You can create and publish business events to the SOA framework. Refer to the Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.
  See: Using Business Events and the Event Delivery Network
• You can use Oracle Enterprise Repository for Oracle Fusion Applications to locate existing assets, such as published events and services. Refer to the Oracle Enterprise Repository home page, http://fusionappsoer.oracle.com.

Purging Archived HCM Event Data: Worked Example

This example demonstrates how to purge object change data that was stored as a result of published event detection.

Purging Archived Data by Date

1. From the Setup and Maintenance work area, search for Purge HCM Events Archive Data, and then click Go to Task.
2. In the Purge Date field, enter the date when you want the application to purge the archived HCM events data.

   Note

   You cannot purge archived data that has not met or exceeded its storage duration. For example, if a particular event is defined to store data for 365 days, and you enter a purge date of 5 March 2012, only data that was archived for that event before 5 March 2011 will be purged.

3. Click Submit.

FAQs for Define HCM Events

When should I purge archived HCM events data?

Purge data from the tables that contain archived data for HCM events when a database administrator determines that the size of the tables is too big.

The archive tables to monitor for archived HCM events data are:

• HRC_EVT_OBJ_CHANGES

• HRC_EVT_OBJ_CHANGE_COMPONENTS

• HRC_EVT_OBJ_CHG_ATTRIBUTES

Manage Payroll Process Configuration

Payroll Process Configuration Groups: Explained

Payroll process configuration groups provide sets of payroll action parameters, primarily related to logging and performance, for your processes and reports. When you run a process, you can select a process configuration group. If you do not select a process configuration group, the application uses the parameters in the default group.

You must specify the default group in the Process Configuration Group ACTION_PARAMETER_GROUPS profile option. You can set the profile option in the Setup and Maintenance work area using the Manage Default Process Configuration Group Profile Option Values task or the Manage Administrator Profile Values task.

A default process configuration group is predefined. You can edit the predefined group on the Default Group tab of the Manage Payroll Process Configuration page. You can select this group or another one as the default for your sites using the Process Configuration Group ACTION_PARAMETER_GROUPS profile option.

You can also create as many additional groups as you require on the Group Overrides tab on the Manage Process Configuration Group page. For example, you might want to create a group with the logging parameters turned on to troubleshoot processes. You can also specify different performance parameter values (such as chunk size and buffer size) for running different processes.

Payroll Process Configuration Group Parameters

Payroll action parameters are system-level parameters that control aspects of the payroll batch processes. The effects of setting values for specific parameters may be system wide. Payroll batch processes read values from the PAY_ACTION_PARAMETERS table on startup, or provide appropriate values by default, if specific parameter values are not specified.

For some parameters you should understand the concept of array processing and how this affects performance. Values for each parameter are predefined with the system, but you can override these values as part of your initial implementation and for performance tuning. Use the Manage Payroll Process Configuration task in the Setup and Maintenance work area.

The following table describes action parameters and lists values and predefined default values:

Parallel Processing Parameters

Oracle Fusion Global Payroll is designed to take advantage of multiprocessor machines. This means that you can improve performance of your batch processes by splitting the processing into a number of threads, or subprocesses, which run in parallel.

When you submit a batch process, the THREADS parameter determines the total number of subprocesses that run concurrently. The process submits THREADS minus 1 subprocesses.

Set this parameter to the value that provides optimal performance on your server. The default value of 1 is set for a single-processor machine. Benchmark tests on multiprocessor machines show that the optimal value is approximately 2 processes per processor. So, for example, if the server has 6 processors, you should set the initial value to 12 and test the impact on performance of variations on this value.

Size of each commit unit for the batch process. This parameter determines the number of assignment actions that are inserted during the initial phase of processing and the number of assignment actions that are processed at one time during the main processing phase. Parameter values range from 1 to 16,000. The default value is 20.

During the initial phase of processing, this parameter defines the array size for insert. Large chunk size values are not desirable and the default value has been set as a result of benchmark tests. Each thread processes one chunk at a time.

Logging Parameters

During implementation and testing, you may need to turn on logging to provide a large volume of detailed information that is useful for investigating problems.

Use this parameter only when you need to investigate problems that are not easily identified in other ways. The logging activities can impact the overall performance of the process you are logging. Usually, this feature is needed during your initial implementation and testing before you go live. In a normal operation you should disable detailed logging.

Logging categories define the type of information included in the log. You can set any number of these categories by specifying multiple values so you can focus attention on specific areas that you think may be causing a problem. Parameter values are one or more logging categories, as described below. The default value is No logging.

The following table explains each logging category:

Formula execution logging is the code area where logging is performed. This action parameter mechanism is only available for formula logging in the Payroll run. It is possible to perform logging with a combinations of characters. For example, the 'di' string corresponds to the logging of database item cache access and formula input and output values. The default is no logging.

Here are the values that you can use for formula execution logging:

• d = database item cache access

• D = database item cache dump

• f = formula cache access

• F = formula cache dump

• i = formula input/output values

• w = working storage area access

• W = working storage area dump

• n = nested calls

• c = change contexts

• s = SQL execution (database item and PLSQL formula function calls)

• m = miscellaneous

• T = trace (very large level that provides the inputs and outputs of every call made when executing a formula)

• 1 = level 1 (combination of i, m, f, and C)

• 2 = level 2 (combination of 1, d, w, c, and n)

• 3 = level 3 (combination of 2, D, W, and s)

• 4 = level 4 (combination of 3 and F)

• 5 = level 5 (combination of 4 and T)

Payroll License Configuration: Critical Choices

The Payroll License parameter on the Manage Payroll Process Configuration page has three allowable values that determine how payroll-related features function within Oracle Fusion Applications. You must ensure that the value for the Payroll License parameter in your default configuration group is appropriate for your licensing agreement.

The three allowable values for the Payroll License parameter for the following product licenses are:

• Oracle Fusion Global Payroll: PAYROLL

• Oracle Fusion Global Payroll Interface: PAYROLL_INTERFACE

• Other HCM Products: HR_ONLY

Global Payroll

Global Payroll customers must set the Payroll License parameter to PAYROLL to ensure the complete set of payroll-related element templates is available when creating elements. These element templates assist in element creation and automatically create and generate fast formulas for new elements. Elements created without this set of element templates will not be suitable for costing or payment processing in Global Payroll.

The PAYROLL license setting also prevents any organization payment methods without a payment source from being associated when creating payroll definitions, which reduces potential problems during payment processing. For some localizations, the PAYROLL license setting enables deduction cards to be automatically generated as part of the new-hire process.

Global Payroll Interface

Global Payroll Interface customers must set the Payroll License parameter to PAYROLL_INTERFACE to ensure the correct set of element templates is available. Earnings elements created without this license setting will not automatically generate the associated features, such as the formulas and balances required when calculating gross earnings for employees.

Other HCM Products

Customers of other HCM products must set the Payroll License parameter to HR_ONLY to ensure the correct set of element templates is available. These element templates are simplified to facilitate creating elements to capture just the required information. Elements created without this license setting will include formulas and balances, which are required for payroll purposes but are unnecessary for HR purposes.

Setting the Payroll License for the Default Process Configuration Group: Worked Example

This example demonstrates how to configure the default process configuration group to use the Payroll license setting. The Payroll setting enables all of the features of Oracle Fusion Global Payroll and Oracle Fusion Global Payroll Interface.

You first set your site to use the default process configuration group and then you set the default process configuration group to use the Payroll license setting.

Specify the Default Process Configuration Group

1. From the Setup and Maintenance work area, search for the Manage Default Process Configuration Group Profile Option Values task, and then click Go to Task.
2. In the Profile Values section, click Add.
3. In the new row, select Site as the profile level and select DEFAULT_GROUP as the profile value.
4. Click Save and Close.

Set the Payroll License

1. From the Setup and Maintenance work area, search for the Manage Payroll Process Configuration task, and then click Go to Task.
2. Navigate to the Default Group tab.
3. Click Add.
4. In the Parameter Name field, select Payroll License.
5. In the Default Value field, enter PAYROLL.
6. Click Save and Close.
7. Click Save.

FAQs for Manage Payroll Process Configuration

How can I improve performance and troubleshoot payroll processes?

Add parameters to a payroll process configuration group to optimize performance and troubleshoot your payroll processes. To process large volumes of records, use the Threads and Chunk Size parameters. To troubleshoot processes, add the Logging Category or Formula Execution Logging parameters to a configuration group and rerun the process using that configuration group. Using these parameters enables you to investigate formula code problems.

Previous

Next

Copyright ©  2011-2013, Oracle and/or its affiliates. All rights reserved. Legal Notices

Home

Contents

Book List

Contact Us