Oracle® Fusion Applications Workforce Deployment Implementation Guide 11g Release 1 (11.1.4) Part Number E20379-04

Contents

Previous

Next

19 Define Payroll

This chapter contains the following:

Define Payroll Business Definitions

Define Pay Frequency

Manage User-Defined Tables

Define Fast Formulas

Define Balance Definitions

Define Earning and Deduction Definitions

Define Events

Define Payment Methods

Define Payroll Costing

Define Payroll Flow Patterns

Define Payroll Business Definitions

Payroll Employment Hierarchy Profile Option: Critical Choices

You can use profile options to specify the values you want to display for each level of the payroll employment hierarchy. The hierarchy appears in View Person Process Results pages. It can display information for up to three levels, depending on the employment model used in your enterprise:

• Payroll relationship

• Employment terms

• Assignments

You can specify up to three values at each level to help identify the record. For example, you might select legal employer name and job name to identify employment terms records, and assignment name and number to identify assignment records.

Which Values to Use for the Profile Option

The following table lists the profile option codes, available profile values, and default values at the site level for each level of the payroll employment hierarchy.

Overriding Site-level Values with User-level Values

You can override site-level values at the user level. For example, you might use position as the default value and override it with job for the payroll administrator who manages records for a group of workers who are not assigned to positions.

Define Pay Frequency

Pay Frequency Components: How They Work Together

Pay frequency components together provide the flexibility to implement complex time-related objects used in payroll definitions, payroll processes, and payroll tasks that use start and end dates.

It is important to understand how the following pay frequency components work together to provide payroll functionality for your organization. Each may require its own setup and implementation.

• Consolidation Groups

• Payroll Definitions

• Time Definitions

• Run Types

Consolidation Groups

Use consolidation groups to process the results from more than one payroll run in a single action or process the results for one payroll in separate actions. With consolidation groups, you produce one set of results per payment method for several payrolls, one set of reports, and one set of costing results. For example, you may submit a regular payroll run and a supplementary payroll run for the same payroll period. If both the regular and supplementary run belong to the same consolidation group, then you use a single consolidation group to process all the results for the post-run processing. Optionally, you can enter a different consolidation group for the supplementary payroll and use it to process the results of the post-run processing for the supplementary payroll separately from the regular payroll.

Payroll Definitions

Payroll definitions are essential to your payroll implementation because they indicate the payment frequency and processing schedule, and through the payroll relationship, they link the employees with the payroll run.

Time Definitions

Time definitions can be static periods of unusual length based on a given static date, or they can create dates based on dynamic variables that you specify for either a time span, a retrieval date, or a more complex definition type to use with a user-defined date. They are used in many areas, including payroll periods, payroll employment management, balance dimensions, retroactive and proration events, element start and end dates, and overtime periods.

Run Types

Run types control the elements and payment types to process in a payroll run. Two predefined run types, Regular and Supplemental, group the other run types and determine the sequence in which they are processed. The Regular run type includes Regular Normal, Process Separately, and Separate Payment. The Supplemental run type includes Process Separately, Separate Payment, and Supplemental Normal.

For each of the component run types, you can specify payment methods that override the default payment methods for the payroll definition. You can also select the element classifications to be processed by runs of this type, and exclude specific elements from these classifications.

Consolidation Group Usage: Examples

You create consolidation groups by selecting the Manage Consolidation Groups task from the Payroll Calculation work area. The following scenarios provide examples of how you can use consolidation groups.

Post-Run Processing

Consolidation groups facilitate separating payroll run results for supplemental processing. For most payroll post-run processing, you can use the consolidation group as an input parameter. You may want the results of a supplemental payroll run to be kept separately from those of the regular payroll process that was already performed. To use a consolidation group to keep supplemental run results separate from the regular payroll run, you would perform these steps:

1. Create a new consolidation group used to label the supplemental payroll run.

2. Initiate the supplemental payroll run, specifying the new consolidation group as an input parameter.

Separate Costing and Payment

Using multiple consolidation groups you can control processing. For example, you want to process and pay a particular set of employees separately within a single payroll to keep separate records of payment and costing. To process employees separately, you would perform these steps:

1. Create a new consolidation group to specify when running the Calculate Payroll process.

2. Create a payroll relationship groups to separate the employees.

   You can use rules to identify them dynamically or you can specify the employees by their payroll relationship numbers.

3. Run the Calculate Payroll process for each payroll relationship group separately, once specifying the original consolidation and once for the new consolidation group.

Supplemental Processing for Special Circumstances

You may want a supplemental payroll run for a special circumstance. For example, you have a main payroll run and three QuickPay runs. Because one of the QuickPay runs is for a termination, it needs to be processed prior to the others. To process the QuickPay for this special circumstance, you would perform these steps:

1. Create a new consolidation group to specify when you process the QuickPay for the termination.

2. Submit a QuickPay process, specifying the new consolidation group.

3. Process the other three payroll runs using their default consolidation groups.

Payroll Definitions: Explained

Payroll definitions contain calendar and offset information, which determines when payments are calculated and costed. Using payroll definitions, you can specify payment frequency, processing schedule, and other parameters for a particular payroll. Payroll period types, such as weekly or monthly, determine the interval at which you pay employees.

Each payroll definition can use only one payroll period type, and you must set up at least one payroll definition for each payroll period type that you use to pay employees. For example, to pay employees semimonthly, create a payroll definition using the semimonthly payroll period type, ensuring that tax calculations and other calculations will produce correct results for those employees.

When you create a payroll definition, the complete payroll schedule is automatically generated, based on the payroll period type, any offsets or calendar adjustments, and the number of years that you specify. Once you have saved a payroll definition, you can assign employees to it on the Manage Payroll Relationships page.

A common scenario for modifying an existing payroll definition is to increase the number of years and generate more payroll time periods to extend the payroll calendar. A common scenario for creating a payroll definition is to replace one that is expired or end-dated.

Each payroll must belong to a consolidation group, which is required by the application for processing purposes. Before you can create a payroll definition, the legislative data group and the consolidation group to use for it must already be defined.

Managing Payroll Definitions: Points to Consider

When you create or modify payroll definitions, the application automatically generates a calendar of payroll periods based on your selections. The choices you make for the following values determine exactly how the schedule of payroll periods is generated:

• Effective start date

• First period end date

• Number of years

• Offsets

• Changes to specific dates

Effective Start Date

The effective start date is the first date that the payroll definition can be used for employee data. The start date must be on or before the earliest date of any historical data you want to load. For example if you want a payroll to be in use starting on 1/1/2013, and you have 5 years of historical payroll data to load, then the start date of the payroll definition must be on or before 1/1/2008.

The effective start date does not affect the generated calendar of payroll periods. The start date for the first payroll period is based on the first period end date.

First Period End Date

The first period end date is the end date of the first payroll period that the application generates for a payroll definition. It is typically based on the date of implementation, tax year, benefits enrollments, or a particular payment cycle. For example, if your weekly payroll work week is Saturday through Friday, and your first payment date is planned to be on 1/6/12, you could use 12/30/11 as your first period end date.

Number of Years

The number of years you enter represents how many years of time periods to generate starting from the beginning of the first payroll period. For example, a payroll definition with an effective start date of 1/1/1985, a payroll period type of semimonthly, a first period end date of 6/15/2012, and the number of years as 5 would generate a calendar of payroll time periods from 6/1/2012 through 5/31/2017. Once you save a payroll definition, you can later only increase but not reduce its number of years because a calendar of time periods for the payroll has already been generated.

Offsets

Depending on the payroll period type, you can elect for your payroll cycle events to occur on specific dates or be based on offsets from period start or end dates.

This table describes the predefined payroll cycle events that you can offset.

Dynamic Offsets

When creating a payroll definition, you can use dynamic offsets for payroll cycle events. All of the predefined payroll time periods you can use support dynamically generated dates for offsets. Using dynamic offsets, you have the option to offset each payroll cycle event by a specified number of calendar or work days before or after the start date or the end date of the payroll period. For example, you might want to set the payroll run date three work days before the payroll end date, which accommodates differences in the number of days in the payroll period and also accounts for weekends and holidays.

Fixed-Date Offsets

The predefined Monthly (Calendar) payroll time period supports using both dynamic offsets and fixed-date offsets. Using fixed dates, you can adjust the exact date of each of the payroll cycle events for the first payroll period and any adjustments that you make will be reflected in the payroll calendar for subsequent payroll time periods. For example, you might set the cutoff date as the 25th of the month and the payroll run date as the 26th of the month, then all payroll periods in the calendar will have those offsets.

Specific Date Adjustments

Once you have generated the payroll time periods, you can further adjust any specific calendar dates, as desired. For example, if you know of a particular bank holiday that falls on a payroll run date or a payment date, you might want to adjust the dates manually on the payroll calendar's time period. You can make these adjustments when creating a payroll definition or any time after then, as long as the time period is in the future.

Creating Payroll Definitions: Worked Example

This example demonstrates how to create two payroll definitions for different payment frequencies that are associated with one consolidation group and one legislative data group.

The following table summarizes the key decisions for this scenario.

In this example, the InFusion US company is creating payrolls for its employees. There are two sets of employees, permanent employees who are paid a set amount on a semimonthly basis, and temporary employees that are paid using time card data on a monthly basis.

The business requires that a single monthly costing process be run against results from different payroll runs by using the consolidation group name as an input parameter in the costing run. This example creates two payroll definitions with different payment periods, but the same consolidation group. Both definitions are effective starting on 1/1/11 and will generate payroll time periods covering 5 years.

Prerequisites

1. Ensure that the legislative data group for your payrolls exists, such as InFusion US LDG.
2. Ensure that organization payment methods exist for your payrolls, such as InFusion US Emp Check and InFusion US Emp EFT.
3. Create a consolidation group named InFusion US Emp Group assigned to the InFusion US LDG legislative data group.

Create the Payroll Definitions

Create two payroll definitions:

• One for permanent employees that are paid a flat amount by electronic funds transfer (EFT) on a semimonthly basis. This payroll definition includes dynamically generated offset dates.

• One for temporary employees that are paid by check using time card data on a monthly calendar basis.

Perform the following steps twice, first using the semimonthly values and then using the monthly values.

1. In the Payroll Calculation work area, click Manage Payroll Definitions.
2. In the Search Results section of the Manage Payroll Definitions page, click the Createicon.
3. Select the InFusion US LDG legislative data group from the list.
4. Enter 1/1/11 as the effective start date you want the payroll to be available for use, and then click Continue.

   In this example, all employees that will use this payroll definition are hired after 1/1/11, so there is no issue with loading historical employee data.

5. In the Basic Details section, complete the fields as shown in this table, and then click Next..

   Field	Semimonthly Value	Monthly Value
   Name	InFusion US Emp Semimonthly	InFusion US Emp Monthly
   Consolidation Group	InFusion US Emp Group	InFusion US Emp Group
   Period Type	Semimonthly	Monthly (Calendar)
   First Period End Date	6/15/12	6/30/12
   Default Payment Method	InFusion US Emp EFT	InFusion US Emp Check

   
   
6. On the Payroll Offsets page, in the Number of Years field, enter 5.
7. For the semimonthly payroll, use dynamic variables to define offsets as shown in this table, and then click Next.

   Field	Falls Value	Day Type Value	Offset Value	Base Date Value
   Cutoff Date	5	Work Days	Before	Period End Date
   Payroll Run Date	3	Work Days	Before	Period End Date

   
   
8. For the monthly payroll, use fixed dates to define offsets as shown in this table, and then click Next.

   Field	Value
   Fixed Date	Yes
   Cutoff Date	6/25/12
   Date Earned	6/30/12
   Payroll Run Date	6/27/12
   Date Paid	6/30/12

   
   
9. On the Payroll Calendar page, adjust payroll days to account for a bank holiday, as shown in this table.

   Column	Semimonthly Value	Monthly Value
   Payroll Run Date	Old Value: 11/28/13 New Value: 11/27/13	Old Value: 5/27/13 New Value: 5/28/13

   
   
10. Click Next.
11. Review the details of the payroll definition, and then click Submit.

FAQs for Define Pay Frequency

When would I close a payroll period?

Closing a payroll period can interfere with changes to recurring entries. Payroll periods are not like General Ledger periods. You do not need to close payroll periods.

Why can't I select a payment method when creating a payroll definition?

Because the payment method you are looking for is not effective from the start date of the payroll definition. The start date of the organization payment method must be on or before the start date of the payroll definition.

Manage User-Defined Tables

Creating a User-Defined Table for Matched Row Values: Example

This example illustrates how to create a user-defined table to store values for workers schedules.

Scenario

Your organization works on a 10 hour a day, four day a week rotating schedule. The employees work for four consecutive days, 10 hours a day.

User-Defined Table Components

The main components of the user-defined table are the definition, columns, rows, and values.

Analysis

In this example, you will construct a user-defined table containing the schedules available in your organization.

This figure illustrates the user-defined table containing the various schedules that your organization offers.

Resulting User-Defined Table Components

This user-defined table definition consists of the following:

• The name of the table is Scheduled_Hours.

• The table is used to match to a specific day of the week.

• The row title is Days of the Week.

• The unit of measure is text since the row values are days of the week.

The user-defined columns are named the days of the week that the employee works. The data type for each column is number. The date type reflects the data type of the values that will be entered in each column.

There are seven user-defined rows containing the exact value of a day of the week.

The values are the scheduled hours for each day of the week. Since the employees only work four consecutive days of ten hours each, there can only be four different schedules. Each column contains the scheduled hours for each day of the week represented in the row.

Creating a User-Defined Table for a Range of Row Values: Example

This example illustrates how to create a user-defined table to store values for stock option allocations.

Scenario

Each year, your organization offers stock options to its employees. The amount of options depends on years of service and job category of the employee receiving them.

User-Defined Table Components

The main components of the user-defined table are the definition, columns, rows, and values.

Analysis

In this example, you will construct a user-defined table containing stock option allocations by job category and years of service.

This figure illustrates the user-defined table containing the stock option allocation that your organization offers.

Resulting User-Defined Table Components

This user-defined table definition consists of the following:

• The name of the table is Stock_Options.

• The table rows consist of a range of numbers that represent years of service.

• The row title is Years of Service.

• The unit of measure must be number when you are looking at a range of values.

The user-defined columns are named for each job category. The data type for each column is number. The date type reflects the data type of the values in each column.

There are seven user-defined rows containing the range of years of service allotting the same amount of stock options.

The values are the number of stock options. There are only four job categories, in this example. Each column contains the stock option allocation for each job category based on the range of service years.

Define Fast Formulas

Using Formulas: Explained

Fast formulas are generic expressions of calculations or comparisons that you want to repeat with different input variables.

You can use fast formulas to:

• Calculate payrolls

• Define the rules for paid time off accrual plans

• Define custom calculations for benefits administration

• Validate element inputs or user-defined tables

• Edit the rules for object group population for elements or people

• Calculate absence duration

Calculate Payrolls

Write payroll calculations and skip rules for elements that you define to represent earnings and deductions. Associate more than one formula with each element to perform different processing for employee assignments with different statuses. You will define elements and formulas for earnings and deductions with highly complex calculations requiring a number of different calls to the database.

Define the Rules for Paid Time Off Accrual Plans

Edit the delivered accrual type formulas or write your own. Each accrual plan needs two formulas: one to calculate the gross accrual and the other to return information to the PTO carry over process.

Define Custom Calculations for Benefits Administration

Configure your plan design to the requirements of your enterprise. For example, you can write a formula to calculate benefits eligibility for those cases where eligibility determination is most complex.

Validate Element Inputs or User-Defined Tables

Validate user entries into element input values using lookups or maximum and minimum values. However, for more complex validations write a formula to check the entry. Also, use a formula to validate entries in user tables.

Edit the Rules for Object Group Population for Elements or People

Define a payroll relationship group, HR relationship group, or element group by defining a formula based on the criteria entered. If you want to change the sequence in which the criteria are checked for each assignment, edit the formula.

Calculate Absence Duration

Calculate the duration of an absence from the start and end dates.

Using Formula Components: Explained

When developing a formula you must understand formula language, the rules that the application imposes on the formula, and the calculation requirements. Formulas are created using various components.

Formula components include:

• Assignment statements

• Return statements

• Variables

• Input statements

• Expressions

• Conditions

• Comments

To illustrate how each component is used in a formula, suppose you wanted to calculate the pay value for the element WAGE by multiplying the number of hours an employee works each week by the hourly rate. The formula can be written as follows:

WAGE = HOURS_WORKED * HOURLY_RATE
RETURN WAGE

Assignment Statements

The first line is an assignment statement that simply assigns a value to the element WAGE.

Return Statements

The second line is a return statement that passes back the WAGE value to the payroll run. A return statement can be used to stop the formula execution without passing back any values.

Variables

Local variables occur in a single formula only. You can change a local variable within the formula by assigning a value to it using an assignment statement. To calculate the WAGE value, the formula needs to get the value for the variable HOURS_WORKED.

You can use local variables to store data in a formula. You might want to hold data temporarily while you perform some other calculations, or to pass data back to the application. Below is an example showing the use of a variable, ANNUAL_LEAVE.

/* Formula: Annual Leave Formula */
IF YEARS_SERVICE >= 10
THEN
ANNUAL_LEAVE = 25
ELSE
ANNUAL_LEAVE = 20 + FLOOR (YEARS_SERVICE/2)
RETURN ANNUAL_LEAVE

Input Statements

The HOURS_WORKED could be an input value of the element WAGE. To pass the element input values to the formula during processing, define an inputs statement as follows:

INPUTS ARE HOURS_WORKED
WAGE = HOURS_WORKED * HOURLY_RATE
RETURN WAGE

INPUTS ARE START_DATE (DATE)

Expressions

Each function or calculation is one expression, and you can nest expressions to create more complex calculations. Brackets can be used to control the order in which calculations are performed. Expressions within brackets are evaluated first. Within nested brackets, evaluation proceeds from the least inclusive set to the most inclusive set. When brackets are not used the following hierarchal order or execution is implied: multiplication and division then addition and subtraction.

Expressions combine constants and variables with operators (+, -, *, /), array methods, and functions to return a value of a certain data type. For example, the expression (3 + 2) returns a value of 5, and is of NUMBER data type. The format of an expression is:

SUBEXPRESSION [operator SUBEXPRESSION ...]

A number of sub-expressions can combine in a single expression. For example, the sub-expressions (3 + 2) and MONTHS_BETWEEN(start_date, end_date) can combine in a single expression as follows:

(3 + 2) + MONTHS_BETWEEN(start_date, end_date)

Expressions can also be used inside functions, such as:

salary = GREATEST(minimum_wage, (hourly_rate * hours_worked))

Operands in an expression are usually of the same data type which is the data type of the expression as a whole. For example, in the following expression all the operands are numeric and the expression itself is numeric:

GREATEST(MINIMUM_WAGE, (HOURLY_RATE * HOURS_WORKED)) + BONUS

The operands for the above expression are BONUS, and the return value from GREATEST. The arguments for GREATEST are separate expressions.

Conditions

Conditions are used to process expressions based on whether a certain condition occurs. For example,

TRAINING_ALLOWANCE = 0 
IF (AGE < 20) THEN
TRAINING_ALLOWANCE = 30

This formula checks if the condition (AGE < 20) is true or false. If it is true, the formula processes the statement that follows the word THEN. If the condition is not true, the formula ignores this statement.

Comments

Use comments to explain how all or part of a formula is used. Also, you can change some formula lines into comments until they are ready to be used. Comments are designated by the comment delimiters of /* and */. Anything written inside these delimiters is a comment. You can place comments anywhere within a formula. The beginning of a formula should contain the following comments:

• The formula title and a short purpose statement.

• A description of the formula inputs.

• A list of variables and literals that may require updating.

• An explanation of the formula's calculation.

• The dates of any modifications, the name of the person modifying the formula, and the reason for the change.

An example of a comment is:

/* Use this formula to determine the bonus percentage for staff */
INPUTS ARE SALARY_AMOUNT,
START_DATE (DATE),
END_PERIOD_DATE (DATE),
BONUS_PERCENTAGE /* Decided at board level. */

Formula Performance Improvements: Explained

When writing formulas there are a number of techniques to follow to endure your formulas are easy to read, use, understand, and process efficiently.

Variable Names and Aliases

To improve readability, use names that are brief yet meaningful. Use aliases if the names of database items are long. Name length has no effect on performance or memory usage.

Inputs Statements

Use INPUTS statements rather than database items whenever possible. It speeds up the running of your payroll by eliminating the need to access the database for the input variables.

An example of inefficient formula without INPUTS statement is:

SALARY = SALARY_ANNUAL_SALARY / 12
RETURN SALARY

An example of efficient use of INPUTS statements is:

INPUTS ARE ANNUAL_SALARY
SALARY = ANNUAL_SALARY / 12
RETURN SALARY

Database Items

Do not refer to database items until you need them. People sometimes list at the top of a formula all the database items the formula might need, thinking this helps the formula process more quickly. However, this in fact slows processing by causing unnecessary database calls.

An example of an inefficient use of database items is:

S = SALARY
A = AGE
IF S < 20000 THEN
IF A < 20 THEN
TRAINING_ALLOWANCE = 30
ELSE
TRAINING_ALLOWANCE = 0

An example of an efficient use of database items is:

IF SALARY < 20000 THEN
IF AGE < 20 THEN
TRAINING_ALLOWANCE = 30
ELSE
TRAINING_ALLOWANCE = 0

The first example always causes a database fetch for AGE whereas the second only fetches AGE if salary is less than 20000.

Balance Dimensions

Wherever possible, use balance dimensions for single assignments only in formulas. Multiple assignments require more calculation time, leading to slower processing time. The number of multiple assignments in a payroll is not normally high, and the presence of a small number does not lead to any significant increase in overall processing time. However, there could be a problem if you unnecessarily link balance dimensions for multiple assignments into general formulas.

Formula Statements: Explained

Statements are instructions that a formula carries out.

When working with statements, it is important to have knowledge of:

• Statement types

• Ordering statement

• Grouping statements

When using statements in a formula you must enter them in the following order: alias statements, default statements, input statements, then other statements.

Statement Types

Use the alias statement to define another name, or alias, for existing variables. Declare aliases for database items and global values. An example of an alias statement is:

ALIAS OVERTIME_QUALIFYING_LENGTH_OF_SERVICE AS OT_QLS

RATE = HOURLY_RATE + 14
WAGE = HOURS_WORKED * RATE

CHANGE_CONTEXTS(AREA1 = TAX_REPORTING_UNIT_INCOME_TAX_JURISDICTION_GEOGRAPHY_ID)
(
  CHANGE_CONTEXTS(DEDUCTION_TYPE = 'SBJ_TO_REGULAR_TAX')
  (
    L_TAXATION_METHOD = 'NONE'
    EXECUTE('TAXABILITY_RULE_EXISTS')
    IF GET_OUTPUT('TR_EXISTS', 'N') = 'Y' THEN
      L_TAXATION_METHOD = 'REGULAR_TAX'
  ) /* DEDUCTION_TYPE context change undone here. */
) /* AREA1 context change undone here. */

DEFAULT FOR HOURLY_RATE IS 3.00
INPUTS ARE HOURLY_RATE
X = HOURS_WORKED * HOURLY_RATE

FOUND = -1 /* -1 is not a valid index for A. */
I = A.FIRST(-1)
WHILE (A.EXISTS(I)) LOOP
(
  /* EXIT-clause for early exit. */
  IF A[I] = KEY THEN
  (
    FOUND = I
    /* Exit the loop. */
    EXIT;
  )
  I = A.NEXT(I,-1)
)

SET_INPUT('UNIT','Hourly')
EXECUTE('RATE_FORMULA')
HOURLY_RATE = GET_OUTPUT('RATE',0.0)
WAGE = HOURS_WORKED * HOURLY_RATE
RETURN WAGE

IF (AGE < 20) THEN
  TRAINING_ALLOWANCE = 30
ELSETRAINING_ALLOWANCE = 40

INPUTS ARE HOURS_WORKED
WAGE = HOURS_WORKED * HOURLY_RATE
RETURN WAGE

INPUTS ARE HOURS_WORKED
IF HOURS_WORKED <= 10 THEN
(
  RETURN
  /* This is ignored. */
  BONUS = 10
)
/* This is executed if HOURS_WORKED > 10. */
BONUS = 50
RETURN BONUS

/* -1234 is not a valid index for A in this instance, so use as default. */
NI = A.FIRST(-1234)
WHILE A.EXISTS(NI) LOOP
(
  VA = A[NI] /* Do some processing with element at index NI. */
  NI = A.NEXT(NI,-1234) /* Go to next index. */
)

/* Formula: RATE_SETTER */
WSA_SET('RATE:HOURLY1',3.5)
WSA_SET('RATE:HOURLY2',4.0)
WSA_SET('RATE:HOURLY3',4.5)
WSA_SET('RATE_FLAG','Y') /* Flag to say that the rates have been set. */

Ordering Statements

Statements need to be placed in a formula in the following order:

1. ALIAS statements, if any

2. DEFAULT statements, if any

3. INPUT statements, if any

4. Other statements

Grouping Statements

If you want to group more than one statement, under IF - THEN statement, ELSE clauses, WHILE-loop, or CHANGE_CONTEXTS, enclose the group of statements within brackets. In the absence of brackets, the preceding statement only applies to the first statement.

Correct example:

I = A.FIRST
WHILE (A.EXISTS(I)) LOOP
(
  A[I] = I
  I = A.NEXT(I,-1)
)

Incorrect example:

I = A.FIRST
WHILE (A.EXISTS(I)) LOOP
  A[I] = I
  I = A.NEXT(I,-1) /* This is not executed as part of the loop. */

Classes of Variables: Explained

Formula variables can have frequently changing values. The variable's data type determines the type of information it holds. You do not have to specify what type you want a variable to be. The formula works out the type from how you use the variable. For example, if you set a variable to 'J. Smith', this is interpreted as a TEXT variable. The system also warns you if you try to perform any inconsistent operations, such as trying to add a number to a text string.

There are three classes of variables:

• Input variables appear in INPUTS statements and bring values into a formula.

• Output variables appear in RETURN statements and return values from a formula. A variable can be both an input and output.

• Local variables are only used within one formula.

Variable values can be changed using an assignment statement and referenced within expressions. However, if a variable has not been given a value when referenced, the formula will raise an error.

Naming Variables: Explained

There are two naming schemes for variables. In both cases, the maximum size of a variable name is 255 characters.

In the first naming scheme, variables have names comprising one or more words, joined by underscores. The words must each start with a letter and can be followed by a combination of letters, and digits.

In the second naming scheme, variable names begin and end with double quotes ("). Between the quotes, any printable characters can be used such as "This is a quoted variable name!". Note that any word consisting of only digits could be mistaken for numbers.

Formulas are not case sensitive. For example, the variable named EMPLOYEE_NAME is the same as the variable employee_name.

The following reserved words cannot be used as the names of variables:

ALIAS
AND
ARE
AS
CHANGE_CONTEXTS
DEFAULT
DEFAULT_DATA_VALUE
DEFAULTED
ELSE
EMPTY_DATE_NUMBER
EMPTY_NUMBER_NUMBER
EMPTY_TEXT_NUMBER
EMPTY_DATE_TEXT
EMPTY_NUMBER_TEXT
EMPTY_TEXT_TEXT
EXIT
FOR
IF
INPUTS
IS
LIKE
LOOP
NEED_CONTEXT
NOT
OR
RETURN
THEN
USING
WAS
WHILE

Formula Data Types

DATE
DATE_NUMBER
DATE_TEXT
NUMBER
NUMBER_NUMBER
NUMBER_TEXT
TEXT
TEXT_NUMBER
TEXT_TEXT

Array Methods

COUNT
DELETE
EXISTS
FIRST
LAST
NEXT
PREVIOUS
PRIOR

Built-in Calls

CONTEXT_IS_SET
EXECUTE
GET_CONTEXT
GET_OUTPUT
IS_EXECUTABLE
SET_INPUT
WSA_DELETE
WSA_EXISTS
WSA_GET
WSA_SET

Database Items: Explained

Database items exist in the application database and have associated code that the system uses to find the data. All database items are read-only variables. An attempt to write to a database item causes a compiler error.

Database item values cannot be changed within a formula. Database items exist in the application database and have a label, hidden from users, which the system uses to find the data. Database items are specific to the context in which you use them.

There are two types of database items:

• Static

• Dynamic

Static Database Items

Static database items are predefined. They include standard types of information, such as the sex, birth date, and work location of an employee, or the start and end dates of a payroll period.

Dynamic Database Items

Dynamic database items are generated from your definitions of:

• Elements

  The element name is the database item name prefix.

• Balances

  The balance name followed by balance dimension name is the database item name.

• Formula global values

  The global value name is the database item name.

• Input values

  The element and input value names are the database item name prefix.

Array Database Items

There are also array database items. Array database items have an index type of NUMBER with indexes starting at 1 and increasing by 1 without gaps.

/* 1 is the starting index for an array database item. */
I = 1
WHILE DBI.EXISTS(I) LOOP
(
  V = DBI[I] /* Do some processing with element at index I. */
  I = I + 1 /* Array database items indexes go up in steps of 1. */
)

The default data value for a statement is used to set a default value in the case where an array database item could return a NULL value for an element. This is an extension of standard database item behavior. There can only be one default data value for a statement for each array database item and it must appear at the start of the formula.

An example of a default data value for a statement:

DEFAULT_DATA_VALUE FOR A IS 0
INPUTS ARE B, C

An example of an array database item usage error case:

 /* Array database item A. */
A[1] = 1
 A = B
A.DELETE(1)
A.DELETE

Formula Operators: Explained

An expression may contain arithmetic operators, which determine how variables and literals are manipulated. For example, the operator + indicates that two items are added together. It is also used for string concatenation.

Types of Operators

The operator types are described in the following table.

Using Operators

The arithmetic operators, subtraction, multiplication, and division, can only be used with numeric operands. The addition operator can be used with numeric or text operands. The operands can be variables, literals, or sub-expressions. A formula error occurs if:

• The second operand of a division equals zero

• The result of multiplication is too large

  What is too large is determined by the normal limits in the database. For string concatenation, if the result is longer than 255 characters, a formula error is raised.

Expressions are evaluated in order from left to right. The unary minus has precedence over the other operators because it applies directly to a single sub-expression. The multiplication and division operators take precedence over addition and subtraction. For example, the expression 1 + 2 * 3 evaluates to 7 rather than 9. Brackets can be used to change precedence. For example, (1 + 2) * 3 evaluates to 9.

Literals: Explained

Every piece of information that you can manipulate or use in a fast formula is a literal.

There are four types of literals:

• Numeric

• Text

• Date

• Array

Numeric Literals

Enter numeric literals without quotes. Precede negative numbers with a minus sign (-). Numbers may have a decimal component after a decimal point. Do not use exponents and floating point scientific notations. Do not use commas or spaces in a number.

Examples of numeric literals are:

• 63

• 3.55

• -2.3

• -.033

• -.2

• 10000

Text Literals

Enclose text literals in single quotes. They may contain spaces. You can represent the single quote character in a text constant by writing it twice (''). Note that this is not the same as the double quote (").

Examples of text literals are:

• 'J. Smith'

• 'P O''Donnell'

• '1234'

• 'Manager'

• '12 Union Road'

• 'The Bonus this year is 23%'

Date Literals

Enclose dates in single quotes and follow immediately with the word date, in brackets. Use the format YYYY-MM-DD"T" HH:MI:SS.FFF"Z", YYYY-MM-DD HH24:MI:SS, or DD-MON-YYYY. It is recommended that you use the first two formats if you want to compile the formula under different language settings.

Examples of date literals are:

• '2010-11-04T00:00:00.000Z' (DATE)

• '1989-03-12 00:00:00' (DATE)

• '12-MAR-1989' (DATE)

Array Literals

An array holds multiple values that can be accessed using the corresponding index values. Arrays literals are defined only for an empty array of each type.

The array types are:

• Array of date values indexed by a numeric index (EMPTY_DATE_NUMBER)

• Array of number values indexed by a numeric index (EMPTY_NUMBER_NUMBER)

• Array of text values indexed by a numeric index (EMPTY_TEXT_NUMBER)

• Array of date values indexed by a text index (EMPTY_DATE_TEXT)

• Array of numeric values indexed by a text index (EMPTY_NUMBER_TEXT)

• Array of text values indexed by a text index (EMPTY_TEXT_TEXT)

Examples of array literals are:

• A1('One') = 1

• SECONDINDEX = A1.NEXT(FIRSTINDEX, '')

• FIRSTINDEX = A1.FIRST(''`)

Formula Variable Data Types: How They Are Determined

The data type of a variable can be numeric, text or date. The data type determines the type of information the variable holds. You do not have to specify the variable type. Formulas determine the type from how you use the variable. For example, if you set a variable to 'J. Smith', this is interpreted as a text variable. The system also warns you if you try to perform any inconsistent operations, such as trying to add a number to a text string.

Settings That Affect Variable Data Types

A formula will fail to compile where variables are used inconsistently or incorrectly. Examples of such errors are:

• The formula attempts to alter a database item value.

• A variable is initially determined to be of one data type, but is later used as another data type. For example, the assignment C = 1 shows that C is a number variable. This is inconsistent when later in the formula C = 'Hello' is entered. In this case, C is being used as a text variable.

• The compiler can determine that a variable has not been assigned a value when it is used. Note: If the compiler thinks there might be a problem, it generates code to raise an error if the variable is not initialized at the time of use.

• A variable is determined to be a formula context but then is used as an ordinary local variable.

• A variable is determined to be a local variable, but is then used as a context within a context handling statement.

How Variable Data Types Are Determined

The rules that determine the variable data type in a formula are processed in the following order:

1. The variable can be an input you name in the input statement. For example:

   INPUTS ARE SALARY_AMOUNT,
   START_DATE (DATE),
   FREQUENCY (TEXT)
   

    

   If you do not specify the variable data type in the statement, the formula assumes it has data type number.

   The variable data type can be determined from a DEFAULT FOR statement such as:

   DEFAULT FOR A IS EMPTY_NUMBER_NUMBER /* A is a NUMBER_NUMBER array variable. */
   

    

   The type can also be determined from a DEFAULT_DATA_VALUE statement:

   DEFAULT_DATA_VALUE FOR B IS 0 /* B is a NUMBER_NUMBER database item. */
   

    

   The DEFAULT_DATA_VALUE statement applies to array database items. Array database items have a NUMBER index type and the type of default data value determines the array's value type.

2. The formula searches the list of database items. If it is in the list, the data type is known.

3. If the variable appears in a context handling statement then the formula searches the list of contexts. If it is in the list, then the formula knows the data type, otherwise an error is raised.

4. If the variable is not a database item or a context, then it is treated as a local variable. The data type is determined by the way in which the variable is used. For example:

   A = 'abc' /* A is a TEXT variable. */
   

    

Array Variables: Explained

Formulas have array variables holding date, number, or text values. If the data type cannot be determined then the data type is defaulted to number.

Arrays are similar to PL/SQL index-by tables. Do not specify the array size limit. Arrays are provided for convenience and excessive use and large arrays will result in excessive memory consumption.

The index types are either text or number. Text indexes are upper case unique. Gaps in index value sequences are permitted. Number indexes are truncated to remove any fractional part. An array may be iterated in index forwards or backwards. Methods are provided to get the first and last indexes and to get the next or prior index given an index. A method is also provided to test the existence of an index.

Array types are specified as <DATA TYPE>_<INDEX TYPE> giving: NUMBER_NUMBER, NUMBER_TEXT, DATE_NUMBER, DATE_TEXT, TEXT_NUMBER, and TEXT_TEXT. Arrays can be used for input, output, and local formula variables. Contexts cannot be array types. Formula functions cannot return arrays nor take array parameters. Methods for returning first, last, next, prior indexes take a default value to be used if the required indexes do not exist. These methods return the index data type. An attempt to delete a value at a nonexistent index does not cause an error. An attempt to reference an array value at a nonexistent index causes an error to be raised. The array method syntax does not work directly with the array literal values. For example, it is not possible to use a construct such as EMPTY_DATE_NUMBER.COUNT.

Array Methods

Examples of array method syntax:

Iterating Through an Array

In the following example, A is an array variable with a NUMBER index. -1234 is known to be an invalid index for A so it is used as a default value when the FIRST and NEXT calls cannot find an index.

/* -1234 is not a valid index for A in this instance, so use as default. */
NI = A.FIRST(-1234)
WHILE A.EXISTS(NI) LOOP
(
  VA = A[NI] /* Do some processing with element at index NI. */
  NI = A.NEXT(NI,-1234) /* Go to next index. */
)

The following example does the same thing for array variable B with a TEXT index.

/* 'No Index' is not a valid index for A in this instance, so use as default. */
TI = B.FIRST('No Index')
WHILE B.EXISTS(TI) LOOP
(
  VB = B[TI] /* Do some processing with element at index TI. */
  TI = B.NEXT(TI, 'No Index') /* Go to next index. */
)
The following example iterates backwards from through an array C with a NUMBER index.
/* -1234 is not a valid index for C in this instance, so use as default. */
NI = C.LAST(-1234)
WHILE C.EXISTS(NI) LOOP
(
  VC = C[NI] /* Do some processing with element at index NI. */
  NI = C.PRIOR(NI,-1234) /* Go to prior index. */

Formula Contexts: Explained

A formula executes within an application-specific execution context. Formula context variables specify the formula execution context.

Examples of contexts are:

• EFFECTIVE_DATE for the effective date the formula is executing

• PAYROLL_ID for the running payroll

• PERSON_ID identifying the person for whom the formula is executing

Context values act as SQL bind values when database item values are fetched from the database. They can also be passed into formula function calls.

Context Value Setting

The application code calling a formula usually sets all the context values. For some complex applications, such as the payroll run, the code only sets the contexts necessary to meet general processing requirements. A payroll run sets contexts for the legislative data group, date earned, the payroll being processed, the payroll relationship, payroll actions, and the person being processed. Payroll formulas also use additional contexts whose setting is country-specific. For example, the jurisdiction area and tax code context values are localization-specific and are set within formulas using a variety of mechanisms.

Formula Context-Handling Statements

If a variable appears in a context handling statement the formula searches the list of contexts. The variable must appear in the contexts list, otherwise the formula raises an error. The data type is held with the context list entry.

Formula context handling statements are described below.

• CHANGE_CONTEXTS(assignment [,...]) - Context values may be changed within a formula using a context changing block, but after leaving the context changing block any changed context values are restored to their previous values. Inside the context changing block, formula function calls, database items, and called formulas use the new context values. Context changing blocks may be nested where context changes need to be applied in stages.

  For example:

  /*
   * Nested Context changes: DBI1 depends upon SOURCE_ID and SOURCE_TEXT. */
  CHANGE_CONTEXTS(SOURCE_TEXT = 'A')
  (
    /* SOURCE_TEXT = 'A' */
    X = DBI1
   
    /* Nesting used to change Contexts in stages. */
    CHANGE_CONTEXT(SOURCE_ID = 2)
    (
      /* SOURCE_TEXT = 'A', SOURCE_ID  = 2 */
      Y = DBI1
      
      /* Overriding a Context change. */
      CHANGE_CONTEXTS(SOURCE_TEXT = 'B',SOURCE_ID = 3)
      (
        /* SOURCE_TEXT = 'B', SOURCE_ID  = 3 */
        Z = DBI1
      )
    )
  )
  

   

• CONTEXT_IS_SET(context) - Tests whether or not a context value is set.

  For example, the following code tests whether or not the AREA3 context is set.

  IF CONTEXT_IS_SET(AREA3) THEN
  

   

• GET_CONTEXT(context, default value) - Returns a context's value if the context is set, otherwise it returns the default value specified in its second argument.

  For example:

  /* AREA1 is a context of type TEXT. */
  AREA1_VALUE = GET_CONTEXT(AREA1,' ')
  
  

   

Working Storage Area: Explained

The working storage area is a mechanism for storing global values across formulas. The values are accessed by name. The names are case-independent.

There are four working storage area call methods:

• WSA_EXISTS

• WSA_DELETE

• WSA_SET

• WSA_GET

The working storage area methods are described in the below table.

Calling a Formula from a Formula: Explained

A formula can be called from another formula. This enables some modularity in formula organization. The called formula name, and any formula input or output names are specified as TEXT values. The names are case-independent.

When the formula runs, checks are performed to ensure the called formula can be executed, and whether the specified input and output data types are correct. The IS_EXECUTABLE call determines whether an executable formula with a specified name exists. The formula must be compiled and visible according to data partitioning requirements. Also, it must be valid as of the effective date of calling formula execution. Payroll code imposes extra restrictions based on formula type combinations.

This table describes the methods used when calling a formula from a formula.

There are three stages in calling a formula:

• Set the inputs

• Call the formula

• Get the formula outputs

Set the Inputs

Use a SET_INPUT call for each formula input and context whose value needs to be explicitly set for the formula call. It is not necessary to specify all formula inputs and contexts. If a formula input is not specified, it is unset in the called formula. If not specified, context values are inherited from the calling formula. Context values can be explicitly unset in the called formula by using the single argument SET_INPUT call.

Call the Formula

Use an EXECUTE call to call a formula. Any extra inputs specified in SET_INPUT calls are ignored. Errors are raised if the formula is not executable, if the called formula is already executing, or if an input variable's data type, as specified using SET_INPUT, does not match its actual data type within the formula.

Get the Formula Outputs

Use one or more GET_OUTPUT calls to fetch outputs from the last formula call. An error is raised if an output variable's data type, as specified using GET_OUTPUT, does not match its actual data type within the formula. A GET_OUTPUT call has a default value that is returned when the specified output does not exist, or was not set by the called formula.

Proration Formulas: Explained

When the payroll run encounters an event (such as a grade change) that you have defined as a proration event for the element being processed, it creates two run results for the element, one for the payroll period up to the day before the event, and one from the date of the event to the end of the period. You must define a formula to handle this proration processing for the element. There are two ways to create the formula:

• Edit the formula of type Oracle Payroll for the element so that it can handle proration

• Create an additional formula to run after the Oracle Payroll formula only in periods when a proration event is encountered. You select this formula in the Proration Formula field on the Proration section of the Manage Elements page.

Using a separate proration formula has the advantage that proration takes place even when you enter a pay value directly on the element entry. Embedding the proration calculation in the Oracle Payroll formula avoids the processing time of calling the second formula in periods when proration events occur.

If you want to write a proration formula, you must follow these rules:

• Select the formula type Payroll Run Proration.

• Add the formula inputs:

  • Any of the element input values

  • Prorate_start (DATE)

  • Prorate_end (DATE)

• Add the formula outputs of any of the element input values.

There may be predefined example formulas for your localization that you can use.

Writing a Fast Formula using Expression Editor: Worked Example

This example demonstrates how to create a fast formula that groups executive workers for reporting and processing. All executive workers are in department EXECT_10000. Once the formula is created it will be added as object group parameters so that only those workers in department EXECT_10000 are used in processing.

The following table summarizes key decisions for this scenario:

Creating a Fast Formula Using the Expression Editor

1. On the Payroll Calculation Tasks page, click Manage Fast Formulas to open the Manage Fast Formulas page.
2. On the Manage Fast Formula page, click the Create icon to create a new formula.
3. On the Create Fast Formula page, complete the fields as shown in this table.

   Field	Value
   Formula Name	Executive Payroll Relationship Grp
   Formula Type	Payroll Relationship Group
   Description	Executive Workers
   Legislative Data Group	Vision LDG
   Effective Start Date	1-Jan-2010

   
   
4. Click Continue.
5. In the Formula Details section, click Add After to add a row to enter the fields in this table.

   Conjunction	User Name	Data Type	Operand	Value
   IF	DEPARTMENT	Character	=	'EXECT_10000'
   Then	SELECT_EMP	Character	=	'YES'
   ELSE	SELECT_EMP	Character	=	'NO'

   
   
6. Click Compile.
7. Click Save.

Writing a Fast Formula Using Formula Text: Worked Example

This example demonstrates, using the text editor, how to create a fast formula that returns the range of scheduled hours for managers and a different range for other workers.

The following table summarizes key decisions for this scenario:

Creating a Fast Formula Using the Text Editor to Determine a Manager's Scheduled Hours

1. On the Payroll Calculation Tasks page, click Manage Fast Formulas to open the Manage Fast Formulas page.
2. On the Manage Fast Formula page, click the Create icon to create a new formula.
3. On the Create Fast Formula page, complete the fields as shown in this table.

   Field	Value
   Formula Name	Manager Range of Scheduled Hours
   Formula Type	Range of Scheduled Hours
   Description	Manager's Range of Hours
   Effective Start Date	1-Jan-2010

   
   
4. Click Continue.
5. Enter the following formula details in the Formula Text section:

   /* DATABASE ITEM DEFAULTS BEGIN */
   DEFAULT FOR asg_job IS ' '
   /* DATABASE ITEM DEFAULTS END */
   JOB_1 = ASG_JOB
   IF JOB_1 = 'Manager' then
   (MIN_HOURS = 25
   MAX_HOURS = 40
   FREQUENCY = 'H')
   else
   (MIN_HOURS = 20
   MAX_HOURS = 35
   FREQUENCY = 'H')
   return MIN_HOURS, MAX_HOURS, FREQUENCY
   

    

6. Click Compile.
7. Click Save.

Formula Errors

Formula Compilation Errors: Explained

Compilation errors display in the Manage Fast Formulas page when you compile the formula. The formula compiler returns line numbers starting at 1 from the beginning of a formula, and character positions starting at 1 from the beginning of a line in its error messages. The compiler aborts compilation when an error is encountered.

Common Compilation Errors

This table lists the type and description of several common formula compilation errors.

Formula Execution Errors: Explained

Fast formula execution errors occur when a problem arises while a formula is running. The usual cause is a data problem, either in the formula or in the application database. These errors contain the formula line number where the error occurs.

Formula Execution Errors

This table lists the type and description of each formula execution error.

Formula Functions

Formula Functions: Explained

Functions manipulate data in different ways and always return a value. They are restricted to simple data types of date, number, and text. Some functions work on only one type of data, some can work on two, others work on more than one data types.

A function is specified by its name, return data type, parameter data types, and parameter usage behavior. The general form of a function is:

NAME-OF-FUNCTION(operand,operand,...)

Parameters can be optional or mandatory. They may be repeated any number of times, such as with the GREATEST function. The formula compiler resolves functions by matching function calls against function specifications. You can use multiple functions with the same name within a formula provided that they have different return or parameter data types.

Functions can work one or multiple data types:

• Text

• Number

• Date

• Data Conversion

• Miscellaneous

Text Formula Functions

The following formula functions manipulate text data.

CHR(n)

Returns the character having the binary equivalent to a number operand n in the ASCII character set.

GREATEST(expr, expr [,expr]....)

Compares the values of all the text string operands. It returns the value of the last string in alphabetic order.

INITCAP(expr)

Returns the expression expr with the first letter of each word in uppercase, all other letters in lowercase. Words are delimited by white space or characters that are not alphanumeric.

INSTR(expr1, expr2 [,n [,m]])

Searches expr1 beginning with its nth character for the mth occurrence of expr2 and returns the character position in expr1 for the first character of this occurrence. If n is negative, INSTR counts and searches backward from the end of expr1. The value of m must be positive. The default values of both n and m are 1, meaning INSTR begins searching at the first character of expr1 for the first occurrence of expr2. The return value is relative to the beginning of expr1, regardless of the value of n, and is expressed in characters. If the search is unsuccessful (expr1 does not appear m times after the nth character of expr1) the return value is 0.

INSTRB(expr1, expr2 [,n [,m]])

The same as INSTR, except that n and the return value are expressed in bytes, rather than in characters. For a single-byte character set, INSTRB is equivalent to INSTR.

LEAST(expr, expr [,expr]...)

Compares the values of all the text string operands. Returns the first string in alphabetic order from among its operands.

LENGTH(expr)

Returns the number of characters in the text string operand expr.

LENGTHB(expr)

Returns the length of expr in units of bytes.

LOWER(expr)

Converts a text string to lower case.

LPAD(expr, n [,pad])

Returns the text string operand expr left-padded to length n with the sequence of characters in pad. The default for pad is a blank. If expr is longer than n, then LPAD returns the portion of expr that fits in n.

Examples:

/* A is set to 'XYXYXhello' */
A = LPAD ('hello, 10, 'XY')
/* A is set to 'hell' */
A = LPAD ('hello', 4 )

LTRIM(expr [,set])

Returns the text string operand expr with all the left-most characters that appear in set removed. The default for set is a blank. If none of the left-most characters of expr appear in set then expr is returned.

Examples:

/* A is set to 'def' */
A = LTRIM ('abcdef','abc')
/* A is set to 'abcdef' */
A = LTRIM ('abcdef','bc')

REPLACE(expr, search [,replacement])

Returns the text string operand expr with every occurrence of search replaced with replacement. If replacement is omitted, all occurrences of search are removed. Use REPLACE to substitute one string for another as well as to remove character strings.

Example:

/* Set A to 'BLACK and BLUE'. */
A = REPLACE('JACK and JUE', 'J', BL')

RPAD(expr, n [,pad])

Returns the text string operand expr right-padded to length n with the sequence of characters in pad. The default for pad is a blank. If expr is longer than n, then RPAD returns the portion of expr that fits in n.

Examples:

/* A is set to 'helloXYXYX' */
A = RPAD ('hello, 10, 'XY')
/* A is set to 'hell' */
A = RPAD ('hello', 4 )

RTRIM(expr [,set])

Returns the text string operand expr with all the right-most characters that appear in set removed. The default for set is a blank. If none of the right-most characters of expr appear in set then expr is returned.

Examples:

/* A is set to 'abc' */
A = RTRIM ('abcdef','def')
/* A is set to 'abcdef' */
A = RTRIM ('abcdef','de')

SUBSTR(expr, m [,n]) or SUBSTRING(expr, m [,n])

SUBSTRING returns a substring of the text string operand expr of length n characters beginning at the mth character. If n is negative, SUBSTR counts backwards from the end of expr. If you omit the n, the substring starts from m and finishes at the end of expr.

Example:

/* Check that the tax code starts with GG */
IF length(Tax_code) <= 2
THEN
(message = 'Tax code is too short'
RETURN message
)
IF substr( Tax_code, 1, 2) = 'GG' THEN ...

SUBSTRB((expr, m [,n])

The same as SUBSTR, except that the arguments m and n are expressed in bytes, rather than in characters. For a single-byte database character set, SUBSTRB is equivalent to SUBSTR.

TRANSLATE(expr,from,to)

Returns the text string operand expr with all occurrences of each character in from replaced by its corresponding character in to. Characters in expr that are not in from are not replaced. The argument from can contain more characters than to. In this case, the extra characters at the end of from have no corresponding characters in to. If these extra characters appear in expr, they are removed from the return value.

TRIM(expr)

Trims leading and trailing spaces from a character string.

UPPER(expr)

Converts a text string to upper case.

Numeric Formula Functions

The following formula functions manipulate numeric data.

ABS(n)

Returns the magnitude of a numeric operand n as a positive numeric value. If the value of the operand is positive, its value returns unchanged. If the operand is negative then the value's sign inverts, and the value returns as a positive number.

Example:

ABS (-17)

It returns 17.

FLOOR(n)

Returns the integer part of a numeric operand n. If the value of the operand contains information after the decimal point, FLOOR discards that information and returns a whole number.

Example:

FLOOR(35.455)

It returns 35.

GREATEST(n, n [, n] ...) or GREATEST_OF(n, n [, n] ...)

Compares all the operands and returns the largest value.

LEAST(n, n [, n] ...) or LEAST_OF(n, n [, n] ...)

Compares all the operands and returns the smallest value.

MOD(m, n)

Returns the remainder from dividing m by n.

POWER(m, n)

Returns m raised to the nth power.

ROUND(m [,n])

Rounds m to n decimal places. The default number of decimal places is 0.

Examples:

ROUND(2.3401, 2)

It returns 2.34.

ROUND (2.3461, 2)

It returns 2.35.

ROUNDUP(m [,n]) or ROUND_UP(m [,n])

Rounds m up to n decimal places. The default number of places is 0.

Examples:

ROUND_UP(2.3401, 2)

It returns 2.35.

ROUND_UP(2.3400, 2)

It returns 2.34.

TRUNC(n [,m]) or TRUNCATE(n [,m])

Truncates m down to n decimal places. The default number of places is 0.

Examples:

TRUNC(2.3401, 2)

It returns 2.34.

Date Formula Functions

The following formula functions manipulate date data.

ADD_DAYS(date, n)

Adds n whole days to date.

Example:

ADD_DAYS ('30-DEC-1990' (date), 6)

It returns 5 JAN 1991.

ADD_MONTHS(date, n)

Adds n whole months to date.

ADD_YEARS(date, n)

Adds n whole years to date.

DAYS_BETWEEN(date1, date2)

Returns the number of days between date1 and date2. If date1 is later than date2 then the result is a positive number. If date1 is earlier than date2 then the result is a negative number.

Example:

DAYS_BETWEEN('1995/06/27 00:00:00' (date), '1995/07/03 00:00:00' (date))

It returns - 5.

GREATEST(date, date [, date] ...)

Compares its operands and returns the latest date.

LAST_DAY(date)

Returns the last day of the month containing date.

LEAST(date, date [, date] ...)

Compares the operands and returns the earliest date.

MONTHS_BETWEEN(date1, date2)

Returns the number of months between date1 and date2. If date1 is later than date2, the result is a positive number. If date1 is earlier than date2, the result is a negative number. The return value has a numeric data type that can contain a fraction if the dates do not differ by a whole number of months.

NEW_TIME(date, zone1, zone2)

Returns the date and time in zone zone2 when the date and time in zone zone1 are date.

The arguments zone1 and zone2 can be any one of the standard text strings such as:

NEXT_DAY(d, expr)

Returns the first date following d of the weekday named by expr.

ROUND(date [,format])

Returns the result of rounding date according to format. The default format is DDD, which represents the nearest day.

TRUNC(date [,format])

Returns the result of truncating date according to format. The default format is DDD, which represents a whole day.

Data Conversion Formula Functions

The following formula functions perform data conversions.

DATE_TO_TEXT(date [,format]), TO_CHAR(date [,format]), and TO_TEXT(date [,format])

Converts date to a character string with format specified by format. The default format is the application canonical format.

NUM_TO_CHAR(n, format)

Converts the number n to a character string in the specified format. This function is equivalent to the SQL TO_CHAR function.

TO_CHAR(n) and TO_TEXT(n)

Converts the number n to a character string in canonical number format.

TO_DATE (expr [, format])

Converts the character string expr in the specified format to a date. If no format is specified then expr must be in canonical format.

TO_NUMBER(expr) and TO_NUM(expr)

Converts the character string expr to a number. The character string must be in canonical number format. A period is used for the decimal point, such as 1.234. Negative numbers are preceded with a minus, such as -1.234.

Miscellaneous Formula Functions

The following formula functions manipulate messaging data.

GET_MESG(appname, msgname [, token1, value1] [, token2, value2] [, token3, value3] [, token4, value4] [, token5, value5] ) and GET_FND_MESG(appname, msgname [, token1, value1] [, token2, value2] [, token3, value3] [, token4, value4] [, token5, value5] )

Returns an expanded version of the application message specified using appname, msgname and up to five pairs of message tokens and their corresponding values.

HR_TRACE(expr)

Outputs a trace message.

FAQs for Define Fast Formulas

When do I run the Compile Formula process?

If you need to compile many fast formulas at the same time, you can run the Compile Formula process on the Submit a Process or Report page. Also, if you make any changes to a function after you have compiled a formula that uses it, you need to recompile the formula for the changes to take effect.

What's the difference between a formula compilation error and an execution error?

Compilation errors occur in the Manage Fast Formulas page when you compile the formula. An error message explains the nature of the error. Common compilation errors are syntax errors resulting from typing mistakes.

Execution errors occur when a problem arises while a formula is running. The usual cause is a data problem, either in the formula or in the application database.

Define Balance Definitions

Balance Definitions: Explained

Payroll balances show the accumulation of values over a period of time. The values can be currency, hours, or any other numeric value. You manage balance definitions from the Payroll Calculation work area. Most of the balances you require are predefined and additional balances are created automatically when you create elements. You can edit the definition of these generated balances, or create additional balances for calculations or reporting.

When you create a balance definition, you select the balance category and a unit of measure. Each balance definition is grouped in a predefined balance category for quicker processing. Balance categories are legislation-specific and cannot be modified. The predefined units of measure available for selection are Day, Hour (with different combinations of minutes and seconds), Integer, Money, and Number.

Important aspects of balance definitions are:

• Balance Dimensions

• Balance Feeds

• Generated Balances and Database Items

• Base Balances

• Remuneration

Balance Dimensions

Each balance can have multiple dimensions, which define the specific value to be retrieved. Balance dimensions are predefined and typically combine these components:

• Time span, such as run, period to date, or fiscal year to date

• Employment relationship level, either assignment, terms, or payroll relationship

• Context, required for some balances only, such as tax reporting unit, element, or payroll

For example, if you select the dimension Core Assignment Tax Unit Year to Date for the balance Gross Earnings, you create the defined balance GROSS_EARNINGS_ASG_TU_YTD, which accumulates gross earnings for an assignment in a specific tax reporting unit from the beginning of the calendar year to date.

Balance Feeds

You can define balance feeds by element input values or by balance classification run results.

• Balance Feeds by Element

  Balance feeds by element indicate one or more element input values to add or subtract from a balance. For each balance feed, all elements must be of the same data type. For example, you would not mix money and hours in the same balance feed.

  If a balance is fed by a single element, it is called a primary balance.

• Balance Feeds by Classification

  Balance feeds defined by primary or secondary element classification are always payroll run result values.

  If you add a primary classification as a balance feed, you cannot add the children of this classification from the secondary or subclassifications. For example, if you use the Supplemental Earnings primary classification as a balance feed, you cannot also use any secondary or subclassification that are children of Supplemental Earnings. Also, you cannot use both secondary classifications and subclassifications in the same balance feed.

For any balance that you need to initialize, regardless of whether it is fed by elements or classifications during normal processing, you can select elements to feed it for balance initialization purposes only. Select one element for each level of the employment hierarchy associated with a dimension that you want to initialize.

Generated Balances and Database Items

When you create elements, balances and balance feeds are created automatically as determined by the element template. A database item is generated automatically for each balance dimension. You can use the database items in your formulas to check the value of a balance.

Base Balances

You can specify a base balance when there is a relationship between balances that can be relied on when processing and reporting. For example, Loan Repayment could be the base balance for Loan Repayment Arrears.

Remuneration

One balance in a legislation is predefined as the remuneration balance, which is used to generate payments for employees. For example, the remuneration balance might be Net Pay, which is a calculated balance that is the sum of standard earnings and supplemental earnings minus all the deductions calculated for the run.

Load Initial Balances

Initial Balance Loading: Explained

Setting initial balances values is an essential task when you migrate payroll data from another system. First you load balance values into batch views then submit the Load Initial Balances process from the Payroll Calculation work area. The process validates then processes the batch.

Balance Initialization Elements

For each balance to be initialized, you must create elements in the Balance Initialization classification and add them to the balance as balance feeds. You can create up to three elements: one to initialize assignment level balances, one for employment terms level, and one for payroll relationship level.

Each balance initialization element must:

• Be nonrecurring and for balance adjustments only.

• Be processable in the payroll run.

• Have an input value to feed the balance and an input value for each context required by the balance. If you need to set initial values for a large number of balances you can define multiple input values for a single element with each input value feeding a different balance.

Batch Views

Populate the batch views with the balance values for the initialization date. You can use the Batch Loader spreadsheet, or populate the batch directly using the API in the PAY_BALANCE_BATCH_LINES_PKG API package. You can download the Batch Loader spreadsheet in the Payroll Administration work area.

The views are:

• PAY_BALANCE_BATCH_HEADER

• PAY_BALANCE_BATCH_LINES

When you create the batch header and lines, consider the following points:

• Divide your employees into separate batches to limit the size of each batch.

• Within a batch, ensure that you include batch lines for every balance to be initialized for a person. You cannot split lines for a person across multiple batches.

• The date you specify on the batch header applies to all lines unless you enter an override date at the line level. The date at line level must be on or before the date on the header.

• You cannot initialize balances once you have run any payroll processes.

Initial Balances: How They Are Loaded

The Load Initial Balances process validates then processes the initial balance values you load into batch views. It creates balance adjustments to set the required values.

Settings That Affect Initial Balances

The data you load into the batch views determines which defined balances are initialized and the values used. Typically, you group employees into batches to manage the initialization of their balances.

How the Balances Are Initialized

The Load Initial Balances process validates that the entities referenced in the batch data exist, including balances, balance dimensions, tax reporting units, payrolls, payroll relationships, employment terms, and assignments. It checks that values are available for the contexts used by each balance dimension. It does not check, for example, that an employee is assigned to a specified organization. It sets the status of valid batch lines to V.

The process creates balance adjustments. For all the batch lines it successfully processes, the process sets the status to T and updates the PAYROLL_REL_ACTION_ID to point to the balance adjustment.

Examples

The following table shows a simple three-line batch loaded on 18 June.

For this batch, the process creates an adjustment on the first day of the time period relevant to each dimension, as shown in the following table:

Balance Batch Header and Lines Views

The PAY_BALANCE_BATCH_HEADER and PAY_BALANCE_BATCH_LINES views hold the data used by the Load Initial Balances process to initialize balance values.

You must load data into these views using the Batch Loader spreadsheet or API in the PAY_BALANCE_BATCH_LINES_PKG PL/SQL package. Create each batch line with a BATCH_LINE_STATUS of U (unprocessed) and leave the PAYROLL_REL_ACTION_ID column blank. The batch upload process updates these two columns.

Required Columns

In PAY_BALANCE_BATCH_LINES, the columns shown in the following table are required. Where there is both an ID column and a name column for the same entity, for example, PAYROLL_ASSIGNMENT_ID and ASSIGNMENT_NUMBER, you can populate either column, but you must populate at least one. If the ID column is left blank, the batch upload process uses the name column value to derive the ID value.

Core Context

The core contexts shown in the following table must be populated if the balance dimension expects a value for this context.

Legislative or User-defined Context Columns

There are six legislative or user-defined contexts, which must be populated if the balance dimension expects a value for these contexts. For each context, there is a context ID, name, and value. For example:

• CONTEXT1_ID + CONTEXT1_NAME

• CONTEXT1_VALUE if CONTEXT1 is used by the balance dimensions

Populate CONTEXT[1-6]_NAME with the name of the context usage for that legislative or user-defined context, and CONTEXT[1-6]_VALUE with the actual value of that context.

Define Earning and Deduction Definitions

Element Classification Components: How They Work Together

Elements are grouped into primary classifications, such as Earnings and Voluntary Deductions. In a human resources department, you can use the primary classifications to identify groups of elements for information and analysis purposes. In a payroll department, the classifications control processing, including the sequence in which elements are processed and the balances they feed.

Primary Classifications

Oracle Fusion provides you with these primary classifications and some balances, mainly to reflect tax legislation. They are designed to meet the legislative requirements of your country, so you cannot change them. You can create additional balances to be fed by any of the primary classifications.

Secondary Classifications

You can define secondary classifications to feed your own user defined balances. These secondary classifications are subsets of the primary classifications. In some legislations, secondary classifications have been predefined. As with primary classifications, you cannot remove or change any predefined secondary classifications, and you cannot disable any of the predefined balance feeds created for them.

Costing

If the classification is Costable, you can select any costing option for elements when you define the element links. If the classification is Distributable, you can create a distribution set from elements of this classification over which you can distribute costs (such as overheads). You can also view the cost type for elements in the classification, that is, whether they debit or credit the accounts they feed.

Frequency Rules

The payroll run uses a frequency rule to determine in which pay periods it processes a recurring element. You can view which date the payroll run uses, by default, to assess frequency rules in your localization. You can select a different date when you define a frequency rule.

Element Processing Sequence: How it is Determined

Payroll runs process elements in a predefined sequence, which you can determine.

How Processing Order Is Determined

An element's primary classification defines a default processing priority for the element in payroll runs. Lower priority numbers process first

Overriding Default Processing Priority

Most classifications also have a priority range. When you define an element in these classifications, you can overwrite its default processing priority with another number from the range. This is useful if you need to establish the order in which the element processes with respect to other elements in the classification

Sometimes you must prioritize the processing of certain element entries for an individual person. For example, you may need to determine the precise order in which deductions taken for wage attachments process for a person. You can enter a subpriority number for element entries.

Manage Elements

Elements: How They Work in Salary, Absence, Benefits, and Payroll

Elements are building blocks that help determine the payment of base pay, benefits, absences, and other earnings and deductions. The components of elements are set up differently based on how the element is to be used.

Base Pay Management

To manage base pay, you attach a single earning element to each salary basis to hold base pay earnings, and assign a salary basis to each worker. When a manager or compensation specialist enters a base pay amount for a worker, the amount is written to the payroll element input value associated with the worker's salary basis and used in payroll processing to generate payment amounts.

Absence and Accruals

You can manage employee absences and leave time. To facilitate reporting and analysis of employee absences, you can distinguish between absence categories, absence types, and absence reasons. You can associate an absence type with an element to maintain an absence balance for an employee. You can associate absence types and other elements with accrual plans to determine the net accrual of an employee.

Benefits

Attach elements at various levels in the benefits object hierarchy to create deductions and earnings that can be processed in a payroll run to calculate net pay.

Payroll

For Oracle Fusion Global Payroll, you define earning and deduction elements, such as bonus and overtime earnings and involuntary deductions. These elements incorporate all the components required for payroll processing, including formulas, balances, and formula result rules.

Elements: Explained

Elements are the building blocks of payroll and benefits. There is no limit to the number of elements you can define. You define the policies or business rules that govern the allocation of these elements to your workers.

Elements can represent:

• Earnings, such as salary, wages, and bonuses

• Compensation, such as employee stock purchase and insurance plans

• Absences from work

• Tangible items distributed to persons, such as tools, uniforms, mobile phones, or computers

• Statutory deductions, such as taxes, voluntary deductions, such as contributions to charities or savings plans, and involuntary deductions, such as court orders, as well as pretax deductions

• Employer taxes and other employer liabilities

Oracle Fusion supplies many predefined elements while additional elements are generated when you define certain types of compensation and payroll elements through templates.

Predefined Elements

The predefined elements are specific to your localization. They typically include deductions for tax and wage attachments. You cannot make any changes to these predefined elements.

Element Creation

You can create many earnings and deductions from element templates. The templates include the elements, balances, balance feeds, and formulas required for payroll processing. You can configure any of these definitions to match your specific business requirements.

The components of an element's definition are available for entry based on the primary and secondary classification you select, for example a standard earning. This diagram illustrates element definition components and what is defined in each component.

For example, you can define an element called Wage, for hourly paid workers. You classify the element in the predefined classification Earnings, which determines when it is processed in the payroll run and what payroll balances it feeds.

You must specify at least one input value, in this case Hours Worked, which must be entered in each payroll period. If required, you can define multiple input values with fixed values, defaults, or validation.

You associate a formula with the element, to calculate the wage for the payroll period. A simple formula might be hours worked, from the input value, multiplied by an hourly rate, from compensation information on the employment record. You define who is eligible for the element by assigning eligibility criteria to various components in the persons employment record, such as grade, payroll, salary basis, or organization. In this example, the wage element is available to all persons on the weekly payroll.

Maintaining Elements: Explained

After you have defined and used an element, updates to the element are limited to ensure the integrity of the element for retroactive processing and the balances of the input values. You cannot remove existing input values or add new ones if you have created entries for the element. To add an input value to an element before you create any element entries, set the element entries effective date to the element's start date.

You can make the following changes to an element that has been previously processed:

• Change a required input value to be optional.

• Alter the sequence in which input values appear in the Element Entries flow.

• Change the input value validation rules for minimum, maximum, lookup, or formula.

• Change your specification of which input values create database items.

Determining Entry Values for an Element: Critical Choices

You can select rules for the element's entry value to define how you can update the element entries. The options are:

• Automatic entry

• Allow multiple entries in same period

• Additional entry

Automatic Entry

Entry values can be automatically added in element entries in three ways.

1. Elements can be defined to default an input value at creation. The user defining the element can specify the entry value to be defaulted when an element entry is created. Users can override or change the default at any time. Changes to this type of a default value on the element do not affect existing element entries.

2. Elements can be defined to default an input value at run time. When this is selected, the element will automatically default the element entry value. `This value can be updated if needed. A change to the default value for an input value set to default at run time will automatically change the value to be applied at run time for everybody with an entry for that element.

3. Some entry values are automatically created by a service or process used with compensation, benefits, or formula results.

Allow Multiple Entries in Same Period

This option allows you to give a person more than one entry of the element in the same pay period. For example, if you enter overtime hours on a weekly basis for monthly-paid persons, you might need to give a person five entries of an overtime element in each period.

If you are creating a net-to-gross element, you must select Allow multiple entries in same period.

Additional Entry

This option allows you to add an occasional one time entry for recurring elements. This additional entry can override or add to the normal entry amount.

Element Result Rule Options: Explained

At minimum, an element needs one standard processing rule. This identifies the formula the payroll run uses to process the element for persons with an active employment record. It is also the default formula for other assignment statuses. However, you can define additional processing rules if you need to use different formulas for assignments at other statuses. For example, you could have two rules for a Wages element: Standard Wages and Paid Training Leave.

You can add one or more of the following optional results rules to an element:

• Direct result

• Indirect result

• Message

• Order indirect

• Stop

• Target indirect

For all formula result types except Direct Result or Message, select the target element name to which you want to pass the formula result. This element must have a processing priority causing it to process after the element sending the result.

For the formula result types Direct Result, Indirect Result, and Target Indirect, select the target input value to update.

Direct Result Rule

This is the element's run result, or a direct result updating one of the element's input values.

Indirect Result Rule

This result passes as an element entry to another nonrecurring element not yet processed.

Message Rule

The formula issues messages under certain conditions. For example, a formula can check a loan repayment balance and, if the balance is zero, issue the message "Loan is repaid."

There are three severity levels for a message rule:

• Error

  This causes the run to roll back all processing for the employment record.

• Warning

  This does not affect payroll processing but warns you of a possible problem.

• Information

  This does not affect payroll processing.

Order Indirect Rule

This result updates the subpriority of the element you select in the Target Element Name field.

Stop

This formula result uses the Date Earned of the payroll run to put an end date on a recurring entry of this or another element (which must be defined with Allow Multiple Entries not selected).

Target Indirect

This result updates recurring entries of this or another element on the effective date of the payroll run. The receiving element must be defined with Allow Multiple Entries not selected unless you are passing a recurring element's entries to itself, that is updating another entry of the same element. With this result rule, any future-dated changes to the entry will be overwritten by the results of the current payroll run.

Determining the Element's Latest Entry Date: Critical Choices

The element's latest entry date determines how element entries process after a person is terminated. The options are:

• Final close

• Last standard earning date

• Last standard process date

Final Close

This option allows the element to stay open for entries beyond a persons last day worked. For example, you want the element to stay open to pay a severance package to a terminated person.

Last Standard Earning Date

For recurring elements, this option stops all element entries on the date the person leaves. For nonrecurring elements, this option stops all element entries at the end of the pay period in which the person leaves, or on the date the assignment ends if this is earlier.

Last Standard Process Date

The last standard process date defaults to the last day of the pay period in which the person is terminated, but you can set it to a later period when you terminate a person. It enables all recurring and nonrecurring element entries to stop on the last standard process date or on the date the assignment ends, if this is earlier.

Element Eligibility: Explained

Element eligibility determines which people are eligible for an element. To determine eligibility, you assign element eligibility criteria to the components that persons must have to receive entries of the element. While some elements may represent compensation, deductions, and equipment available to all persons, many elements are available only to certain groups of persons. For example, your enterprise might provide company cars only to persons in the Sales Department. Eligibility criteria rule out the possibility of persons getting element entries by mistake. For example, you might want to give a production bonus only to those persons who work full time in Production and are on the weekly payroll. To do this you would define eligibility criteria for the element Production Bonus and the combination of the Production organization, the Full-Time assignment category, and the Weekly payroll.

Eligibility Criteria

Element eligibility can be assigned by many different criteria.

• All payrolls or for specific payrolls

• Payroll statutory unit

• Legal employer

• Payroll relationship type

• Department in which the person works

• Location of person's office

• Job, for example, Associate Professor or Secretary

• Grade

• Groups to which the person belongs. You set up all the groups that are appropriate for your enterprise. For example, you could decide to group persons by company within a multi-company enterprise, and by union membership.

• Position, which is a class of job performed in a particular organization, for example, Associate Professor of Chemistry, or Finance Department Secretary.

Multiple Rules of Eligibility

You can define more than one eligibility criteria for each element but there must be no overlap between them. For example, you could create one criteria for the combination of grade A and the job Accountant. However, you could not create one criteria for grade A and a second for the job Accountant. This would imply that an accountant on grade A is eligible for the same element twice. If you have more than one criteria for an element, you can enter different default values, qualifying conditions, and costing information for each eligibility group.

Maintaining Element Eligibility: Explained

Element eligibility rules always control element entries.

After you have used an element you can make the following changes to the eligibility rules:

• Change the input value default values and validation.

  These changes affect all new entries. Changes to run time defaults affect existing entries. The system also uses the new validation rules to check any updates you make to existing entries.

• Date-effectively end all of the rules that apply to an element and define a new set of rules, which are effective from a later date. For example, suppose you have defined eligibility for a company car based on grade. Following a change of policy you must now define eligibility based on job.

  • You will not be allowed to end the element eligibility if any nonrecurring entries exist at the date you want to end the rule. You must delete existing entries before you end the element's eligibility.

  • You can end the element eligibility if recurring entries exist. Any existing entries will be ended automatically when you end the element's eligibility.

• Change the qualifying conditions of age and length of service that persons must meet to be eligible for the element.

Element Proration: Explained

Proration is the calculation of proportionate element amounts whenever payroll-relevant data is changed during a payroll period. For example, a person joining or leaving the company or a change of pay grade, mid-payroll period, could trigger proration. You add a proration formula to the element and add the element to a proration event group.

Proration Formula

The proration formula determines how to prorate the element. For example, you can prorate based on hours in a pay period or days in a pay period. You can either use a payroll formula that handles proration, or create a separate proration formula that runs after the main payroll formula only in payroll periods in which a proration event occurs.

Proration Event Group

You must assign an event group to an element to prorate it. When you define the event group, you select the events that activate proration calculation, such as hiring a person or terminating employment.

Gross-Up Earning: How It Is Calculated

Gross-up functionality enables you to calculate the gross earnings required to generate a specified net pay for a given earning, if you need to pay a person a guaranteed take home pay (net) per payroll period, or to pay a specified bonus of a set amount (net amount). You define which taxes and other deductions the employer is willing to pay by selecting the balances that can be used in the net-to-gross processing.

Settings That Affect Gross-Up Earning Element

Follow these steps to set up elements for gross-up processing.

1. On the Standard Rules section of the earning element, define the element with the following criteria:

   • Nonrecurring entry

   • Allow multiple entries in same period

   • Enter a skip rule to process once per pay period

2. On the Duration Rules section define the Latest Entry Date to be Final Close.

3. On the Advanced Rules section, define the element with the following criteria:

   • Gross-up during calculation

   • Pay separately from other elements

   • Select Yes to enable iterative calculation

   • Enter an iterative order.

     Note

     Iterative order must be in the reverse sequence of the processing priority numbers. The element with the lowest iterative priority number is reduced first.

   • Enter an iterative formula.

4. Chose the following input values for the element:

   
   

   Input Value Name	Purpose of Entry
   Pay Value	The gross pay is returned to this input value when it has completed the gross-up calculations.
   Amount	The amount gives the iterative formula the desired net pay.
   Low Gross	The low gross is used by the iterative formula to hold the lower gross pay guess, to feed into the next iteration of the formula.
   High Gross	Used by the iterative formula to hold the higher gross pay guess, to feed into the next iteration of the formula.
   Remainder	The amount by which the additional pay to be paid by the employer (gross minus desired net) differs from the total of the balances that are eligible for gross-up processing. Returned by the iterative formula.
   To Within	The amount by which actual net can differ from desired net after normal processing. Must not be zero but can be a nominal amount such as 0.01.
   Method	The method of iterative calculation: binary or interpolation. This determines which function the iterative formula calls. Use the lookup type ITERATIVE_METHOD and select the default interpolation, since this is usually the more efficient method.
   Additional Amount	The amount to add to desired net to calculate gross pay. Returned by the iterative formula.

5. Define element eligibility rules.

6. On the Processing Rule section, enter the following formulas:

   • Add a gross-up formula in the standard processing formula name

   • Create a formula result rule to feed the payment amount result as a direct result to the element's pay value.

7. On the Balance Feeds section, confirm which balances feed your gross-up element.

8. On the Gross Balance Exclusions section, select the deductions to be paid by the employer.

How Gross-Up Earning Is Calculated

The formulas for Net-to-Gross processing do the following:

• The iterative formula takes as input the desired net amount (Amount input value), the amount by which net can differ from the desired amount (To Within input value), and the method of calculation (Method input value).

• In the first run the formula sets the lower gross limit to the desired net amount, and the higher gross limit to twice the desired amount. Then it runs a function to provide the first guess of the gross. The formula returns three values to the element's input values: low gross, high gross, and additional amount.

• The element's payroll formula runs. It adds the additional amount to the desired amount to create the gross amount and returns this value to the element's pay value for the payroll run to process.

• In the next iteration, the iterative formula compares the additional amount to the total value of the balances that are available for gross-up for this element entry. The additional amount must not differ from this balance total by more than the amount you specified in To Within field.

  • If the additional amount equals the balance total, then the iterative processing ends.

  • If the additional amount is above or below the balance total by an acceptable margin, then the processing ends and the formula returns the remainder (additional amount - balance) to the element's Remainder input value.

  • Otherwise, the formula runs the function to generate a better estimate for gross, using the remainder to determine by how much to change the guess. The formula checks the results in another iteration.

Absence Processing in Payroll Runs: Critical Choices

When you create an absence element for an absence type, your choice of element classification determines how absence entries display on the statement of earnings. You must use one of the following classifications:

• Information classification or Absence classification

• Standard Earnings classification

Using the Information or Absence Classification

Use either of these classifications if you want to:

• Process absences in a single calculation.

• Prevent absence entries from appearing on the statement of earnings that the payroll run generates.

Since payroll runs do not process elements in the Information or Absence classifications, you can use an Earnings element to manage the calculation and payment of absences. For example, you can define a skip rule for an Earnings element that triggers processing when it finds an entry for the absence element. The payroll formula associated with the Earnings element uses the database item of the absence element to retrieve the total number of absences. Then the formula uses another database item to retrieve the salary or hourly rate to calculate the total absence pay for the period and, if necessary, reduce the regular earnings.

The following figure depicts the relation between the Absence element, Earnings element, skip rules, and the payroll formula associated with the Earnings element:

Using the Standard Earnings Classification

Use this classification if you want to:

• Process absences individually in each payroll period.

• Treat absence entries as earnings.

This approach creates a one-line entry on the statement of earnings for each absence type. For example, you can use this classification if your employees submit timecards, and you want absences taken by these employees to show on the statement of earnings.

Recurring and Nonrecurring Absence Elements: Critical Choices

When you set up an absence type, you can determine how absences are processed in payroll runs. Choose the type of element to associate with the absence type:

• Use a nonrecurring absence element.

• Use a recurring absence element (only if you use Oracle Fusion Global Payroll and enable proration).

Using a Nonrecurring Absence Element

Nonrecurring absence elements are valid for the payroll period in which the absence starts. The application creates the entry only when you enter the absence end date. The element entry records the full value of the absence duration even if the end date falls beyond the payroll period.

For example, if you enter an absence that starts on May 24 and ends on June 5 for someone on a monthly payroll, the element entry is dated May 1 to May 31 and records the full value of the absence duration (13 days).

Using a Recurring Absence Element

Use a recurring absence element if you want the payroll run to process absences that have not ended. To process the absence element and calculate the absence duration in each payroll period, you use a payroll formula that handles proration.

Recurring absence element entries start on the absence start date and end on the absence end date (if there is an end date). If the absence starts or ends in the middle of a payroll period, the payroll run detects and processes the absence using the proration functionality.

Setting Up an Earnings Element: Worked Example

The example shows how payroll managers create a regular earnings element using an element template.

First you create an earning element then update it to allow for multiple entries.

Creating an Earnings Element

1. In the Payroll Calculation work area, click Manage Elements.
2. Click Create.
3. Complete the fields, as shown in this table.

   Field	Value
   Legislative Data Group	Your Legislative Data Group
   Primary Classification	Standard Earnings
   Secondary Classification	Regular

   
   
4. Click Continue.
5. On the Basic Details page, complete the fields, as shown in this table.:

   Question	Answer
   Name	REGULAR SALARY
   Reporting Name	Regular Salary.
   Effective Date	1/1/2010
   Input Currency	US Dollar
   Should every person eligible for the element automatically receive it?	No.
   What is the earliest entry date for this element?	First Standard Earnings Date
   What is the latest entry date for this element?	Last Standard Earning Date
   At which employment level should this element be attached?	Assignment Level
   Does the element recur each payroll period, or does it require explicit entry?	Recurring
   Process the element only once in each payroll period?	Yes
   Can a person have more than one entry of the element in a payroll period?	No
   Process and pay element separately or with other earnings elements?	Process and pay with other earnings

   
   
6. Click Next.
7. On the Additional Details page, complete the fields, as shown in this table.

   Question	Answer
   What is the calculation rule?	Flat Amount
   How do you want to derive the amount?	Entered value
   What is the time-basis for this element?	Periodically
   Is this element subject to proration?	No
   Is this element subject to retroactive changes?	No
   Use this element to calculate a gross amount from a specified net amount?	No
   Should this element reduce regular earnings?	No

   
   
8. Click Next.
9. Verify the information is correct.
10. Click Submit.

Reviewing an Earnings Element

On the Element Summary page, review the newly created element details for accuracy.

1. Review the basic details for the earnings element, for example Element Name, Classification, and Description.
2. In the Standard Rules section, verify that the element is recurring.
3. Verify that the employment level is assignment level.
4. In the Currency section, verify that the currency is US Dollars.

Updating an Earnings Element

On the Element Summary page, update the newly created element details.

1. Click Edit Element.
2. Select today's date.
3. Click Continue.
4. Scroll to the Standard Rules region.
5. In the Entry Options section, select the Allow multiple entries in same period option.
6. Click Save.
7. In the Element Overview section, select the expand arrow.
8. Expand the Input Value folder.
9. Select Pay Value.
10. Select Edit Element.
11. Select today's day on the window, and click Continue.
12. In the Element Overview section, Select Actions, Create Element Eligibility Criteria.
13. On the Element Eligibility name field, enter REGULAR SALARY ELIG.
14. In the Eligibility Criteria section, select All payrolls eligible.
15. Click Save.
16. Click Submit.

What's the difference between a recurring and nonrecurring elememt?

A recurring element has an entry that applies in every payroll period until the entry is ended.

A nonrecurring element has an entry that applies in one pay period only. It is only processed once per payroll period. The dates of the pay period are determined by the payroll to which the person is assigned.

What's an element's skip rule?

A skip rule is a formula that determines the circumstances in which an element should be processed. If the conditions of the formula are met, then the element is processed. Otherwise the element is skipped from processing.

How can I create an element for retroactive processing?

When an element is subject to retroactive changes, all components for the retroactive element are created automatically. This includes adding the element to the predefined retroactive event group and proration group. You can create your own retroactive event group and proration event group and change the default values for the element in the Manage Element flow.

When does an element get processed with a processing option of process once per period?

An element processes entries only in the first payroll run of each period for this element.

If this option is not available for your localization, you can select a skip rule to process this element once each period.

What happens if the Closed for Entry option is selected on an element?

It prevents all new element entries for the element. Selecting this option will not affect any existing element entries.

Use caution with this feature. When hiring, terminating, or updating assignments, this option will prevent element entry creation for the element, even if the element is used for automatic entries.

What happens if I override an element entry that has a runtime default set at the element's definition?

If you override it, then any subsequent changes to the default value on the element or element eligibility definition will not affect the element entry. However, you can clear your entry if you want to restore the default value.

Manage Deduction Ranges

Deduction Ranges: Explained

Deduction rates and amounts may vary depending on the range in which the earnings balance falls. A deduction range is a table that holds the range of values and associated rates, amounts, or rules to use when calculating a deduction or exemption. For example, a deduction range for a graduated tax might contain two range value rows: one that defines the tax rate for earnings under 50,000 USD and another for earnings above 50,000 USD..

Each localization provides a set of predefined deduction ranges used to calculate statutory and involuntary deductions. You cannot edit predefined deduction ranges. You can add new deduction ranges using the Manage Deduction Ranges task in the Payroll Calculation area. When you create a deduction range, you specify the legislative data group (LDG) to which the range applies. The new range can then be used when processing deductions for the LDG.

Range Groups

Each deduction range belongs to a deduction range group used to categorize related deduction ranges. Examples of deduction range groups include city tax information and social insurance information. A set of standard deduction range groups is delivered with the application and available to all legislations. When you create a deduction range, you can select an existing range group or create a new one.

Associating Deduction Ranges with Calculation Factors

Deduction ranges are building blocks used in the calculation of deductions and exemptions. You associate a deduction range with a calculation factor, which defines the rule for calculating the deduction element for balances in the range table. The deduction range provides the values, but the calculation factor specifies when and how to apply them.

For example, a calculation factor might direct the payroll process to do the following: Calculate the deduction using this deduction range only if the person lives in Region B, and then annualize the calculated result to produce the final deduction amount.

Use the Manage Deduction Group Rules task in the Payroll Calculation work area to view and manage calculation factors.

Deduction Range Values: Examples

The examples that follow illustrate how to use both static and dynamic deduction range values, and how to override the default calculation type for individual range value rows.

Static Range

The deduction range for a regional income tax uses a default calculation type of Flat Rate. However, for the lowest and highest incomes, a flat amount applies. For these two ranges, the Flat Amount calculation type overrides the default type, and uses a monetary value rather than a percentage. No database item is specified in the Basis of Range of Values for the deduction range, so the range values are static.

Dynamic Range

The deduction range for a tax exemption uses a default calculation type of Incremental Rate. The first and last range value rows specify the Flat Amount calculation type, which overrides the default type. The Gross Earnings YTD database item is specified in the Basis of Range Values field, which means that the range values represent a percentage of year-to-date gross earnings. The following sample values define a set of dynamic range values for this deduction range:

The first range value row defines a flat amount of 300 USD that applies to the first 10 percent of gross earnings. The second row defines a 10 percent rate that applies to the next 10 percent of gross earnings. The third row defines a 30 percent rate that applies to between 20 and 90 percent of gross earnings. The final row defines a flat amount of zero between 90 and 100 percent.

Deduction Overrides: Explained

A deduction override refers to a value entered on a deduction card that replaces a value defined in a deduction range. For example, an organization might set a default tax rate at the legislative level, and allow the rate to be overridden by a flat amount entered on a personal deduction card at the payroll relationship level.

When the payroll process runs, it checks for deduction card overrides in the following order:

1. Payroll relationship

2. Tax reporting unit

3. Payroll statutory unit

When the process finds an override record, it stops checking and uses the values defined at that level.

Allowing Overrides on Deduction Cards

Overrides for statutory and involuntary deductions are predefined. You cannot allow new overrides for predefined deduction ranges.

If you create a custom deduction range, you can allow users to override a range value on a deduction card by adding the item to the Overrides Allowed on Deduction Card table on the Create or Edit Deduction Ranges page. You must provide the name to appear on the deduction card for the item. The list of items available for override varies depending on the calculation type for the deduction range. For example, you can allow users to override the percentage value for a flat rate calculation or the monetary value for a flat amount calculation. The following three override items are available for all calculation types except text:

• Deduction Range: Uses the deduction range entered on the deduction card to calculate the deduction amount.

• Total Amount: Uses the amount entered on the deduction card as the total deduction amount.

• Additional Amount: Adds the amount entered on the deduction card to the calculated deduction amount.

If you allow multiple overrides for the same deduction range, the deduction calculation process applies them in the following priority:

1. Total amount

2. Deduction range

3. Range value component, such as rate or flat amount

Creating Overrides on Deduction Cards

Use the Manage Personal Deductions task in the Payroll Calculations or Payroll Administration work area to create deduction card overrides at the payroll relationship level. If overrides are allowed, the Overrides Allowed on Deduction Cards tab appears in the Component Details section of the Manage Deduction Cards page when you select a deduction component. Click Create to define an override. The override value you enter varies based on the type of override item defined in the deduction range, as described in the previous section. For example, you may enter a rate to be used in the deduction calculation or an amount to be added to the calculated amount.

If your localization supports deduction cards at multiple levels, use the Manage Legal Entity Deduction Records task in the Setup and Maintenance work area to create deduction card overrides at the payroll statutory unit level. Use the Manage Legal Reporting Unit Deduction Records task in the Setup and Maintenance work area to create deduction card overrides at the tax reporting unit level.

Calculation Types in Deduction Ranges: Explained

The Calculation Type field on the Create or Edit Deduction Ranges page specifies the default type of calculation to use for all deduction range value rows. You can override the default calculation type for individual rows in the Range Values section by selecting a different calculation type in the Calculation Type Override field. The calculation type determines which values you must provide in the Range Values section. For example, if you select Flat Amount as the calculation type, then you must provide a flat amount value.

Predefined Calculation Types

You can choose from several predefined calculation types, as described in the following table:

Specifying View Objects

You can specify the view objects that define the valid values available to the selected calculation type. A view object is a query result set used to display a list of values. The view objects you can specify vary depending on the calculation type. For example, if the calculation type is Conditional Flat Amount, then you can specify view objects for the condition and flat amount values.

Include the fully qualified path name when you specify a view object, such as: oracle.apps.hcm.locUS.payrollSetup.details.publicView.UsStatePVO

Manage Payroll Deductions

Payroll Deductions, Elements, and Deduction Cards: How They Work Together

Payroll deductions comprise multiple components that are defined and managed at different levels. When a payroll run processes a payroll deduction element, it retrieves information stored at all applicable levels.

The following figure shows how deduction information at the legislative and personal levels feeds into the deduction calculation process.

Element Processing

The deduction element's status processing rule drives the calculation, accessing rates and rules defined for the related payroll deduction and values captured on a personal deduction card.

Use the Manage Elements task in the Payroll Calculation work area to view the deduction elements. If an element is associated with a payroll deduction, the deduction name is displayed in the Deductions section on the Manage Element Summary page.

Payroll Deduction

A payroll deduction comprises the rates and rules used to calculate the deduction amount.

• Wage basis rules define which classifications of earnings to consider when calculating the basis for the deduction element, based on criteria such as a worker's place of residence. The rule is defined at the legislative level, but the context value for the rule is captured on the deduction card.

• Calculation factors associated with the deduction element indicate which deduction range to use when calculating the deduction amount. For example, a calculation factor might identify which set of tax rates to use based on the employee's tax code, as specified on the deduction card. The calculated deductible amount would determine the specific rate to use from that range. A deduction range can also define a processing rule, such as a proration rule for calculating bankruptcy payments.

Use the Manage Deduction Group Rules task in the Payroll Calculation work area to view all wage basis rules, related elements, and calculation factors defined for a particular deduction group. Use the Manage Deduction Ranges task to view deduction ranges and range values.

Personal Deduction Card

A personal deduction card contains person-specific information used to calculate the deduction amount.

• A deduction component on a deduction card typically relates to a deduction element defined at the legislative level. Adding a deduction component to a deduction card creates an entry for the related element.

• Component details, such as tax filing status or social insurance contribution category, are used as input values in the element calculation.

• Rates and rules defined on a personal deduction card override values defined in deduction ranges at the legislative level. For example, a default tax rate may be defined at the legislative level, but an employee qualifies for a special reduced rate, which you enter as an override on their personal deduction card.

  Note

  For some localizations, you can create deduction cards for a specific tax reporting unit (TRU) or payroll statutory unit (PSU) to capture information such as an employer's contribution rate.

• Associations indicate which tax reporting unit is responsible for reporting the deductions. They define how deductions are aggregated and reported.

Use the Manage Personal Deductions task in the Payroll Administration or Payroll Calculation work area to create and edit personal deduction cards.

Payroll Deduction Components at the Legislative Level: How They Fit Together

Deduction information defined at the legislative data group level comprises several different components, including wage basis rules, one or more payroll elements, and rules for calculating the deduction amount. The following figure shows the relationship between these components.

Deduction Group

Each deduction belongs to a deduction group used to categorize related deductions. Predefined deduction groups include social insurance, taxes, retirement plans, involuntary deductions, benefits, and more. The deduction groups available and their names vary by legislation.

Deduction

A payroll deduction is a set of rates and rules used in the calculation or reporting of one or more payroll deduction elements. A set of statutory deductions is predefined for each legislative data group and cannot be changed. Involuntary deductions are created automatically when you create an element for an involuntary deduction classification. Use the Manage Payroll Deductions task to view deductions.

Wage Basis Rules

Wage basis rules determine the earnings that contribute to a deductible amount or, for exemptions, the elements that reduce the amount subject to deduction. For example, wage basis rules might define which classifications of standard and supplemental earnings are subject to a particular tax. If wage basis rules vary based on a factor such as a person's location of residence, then location of residence is defined as a wage basis rule reference. Use the Manage Deduction Group Rules task to create new wage basis rules.

Related Elements

A deduction is typically associated with one or more elements. The element definition specifies how and when the element should be processed and identifies the input values for the element. A deduction element's processing rule drives the calculation of the element, accessing calculation factors and wage basis rules to derive the deduction amount.

Related elements for statutory deductions are predefined. Related elements for involuntary deductions are created when you create the involuntary deduction element. Element entries for deduction elements are created automatically when the deduction component for the element is added to a personal deduction card.

Calculation Factors

A calculation factor is a data-driven rule for calculating an element. For example, a calculation factor for an income tax element would identify the deduction range that holds the tax rates to use in the calculation. If tax rates vary based on a factor such as a person's filing status, then filing status is defined as a calculation factor reference. Thus, an element may have multiple calculation factors, one for each unique set of rules and references values. If element calculation involves multiple steps, each step is defined in a separate calculation factor. Calculation factors are predefined for statutory and involuntary deductions, and should not need to be changed. Technical users can create new calculations factors using the Manage Payroll Deductions task, and then modify an element's processing rule to use the new calculation factors.

Deduction Range Values

A deduction range stores calculation rates and rules, which may vary based on the amount subject to deduction. For example, deduction range values for a graduated tax might define a 10 percent tax rate for earnings under 50,000 USD and a 20 percent rate for earnings above 50,000 USD. Predefined deduction ranges are provided for statutory and involuntary deductions. Use the Manage Deduction Ranges task to view and manage deduction ranges.

Tax Reporting Units

At the legislative level, a deduction can be associated with one or more tax reporting units for reporting purposes. These associations do not impact the deduction calculation or aggregation during a payroll run. You associate tax reporting units with specific deduction components on a personal deduction card.

Payroll Deduction Components at the Legislative Level: Examples

Use these examples of an individual income tax deduction and a social insurance deduction to understand how deduction components work together. Each example provides sample values for the following deduction components:

• Deduction group

• References for wage basis rules

• References for calculation factors

• Wage basis rules

• Related elements

• Calculation factors for elements

• Associations for tax reporting

Individual Income Tax Deduction

A particular legislation has a statutory deduction for an individual income tax. The exemption amount for the tax varies based on a person's residential status. The earnings classifications included in the wage basis for the tax vary by geographical region. Thus, references are defined for both the wage basis rules and the calculation factors. The calculation is a two-step process: calculate the exemption and then calculate the tax amount based on the reduced deductible amount.

• Deduction group: Taxes

• Deduction name: Individual Income Tax Deduction

• References for wage basis rules:

  
  

  Reference Name	Reference Value
  Geographical Region	Mainland
  Geographical Region	Territory

• References for calculation factors:

  
  

  Reference Name	Reference Value
  Residential Status	Resident
  Residential Status	Nonresident

• Wage basis rules:

  
  

  Geographical Region Reference Value	Primary Classification	Secondary Classification	Use in Wage Basis?
  Mainland	Standard Earnings	All secondary classifications selected	Y
  Territory	Standard Earnings	All secondary classifications selected	Y
  Mainland	Supplemental Earnings	Commission	Y
  Territory	Supplemental Earnings	Commission	N
  Mainland	Supplemental Earnings	Personal Use of Company Car	Y
  Territory	Supplemental Earnings	Personal Use of Company Car	N

• Related element: Individual Income Tax Processor

  The processing rule (a fast formula) associated with this element drives the income tax deduction calculation. It accesses the appropriate calculation factor, based on the resident status reference value and the current step in the calculation process.

• Calculation factors for Individual Income Tax Processor element:

  
  

  Resident Status Reference Value	Calculation Step	Calculation Method	Deduction Range	Range Values
  Nonresident	Calculate exemption amount	None	Tax Exemption Amount for Nonresident	4800
  Resident	Calculate exemption amount	None	Tax Exemption for Resident	2000
  (None)	Calculate individual income tax	None	Individual Income Tax Rate	0-50000:3% 50000-100000:4% Over 10000: 5%

• Tax reporting units: All tax reporting units defined for this legislation can report this deduction. (You associate deductions with a specific tax reporting unit on the personal deduction card.)

Social Insurance Deduction

The same legislation has a statutory deduction for a social insurance tax. Both the employer and the employee contribute to the social insurance tax, but their contribution rates are different. Calculation of the deduction has several steps:

1. Calculate the base amount for the employee's contribution.

2. Calculate the base amount for the employer's contribution.

3. Calculate the employee's contribution amount.

4. Calculate the employer's contribution amount.

The following component values define this deduction at the legislative level:

• Deduction group: Social Insurance

• Deduction name: Medical Insurance Deduction

• References for wage basis rules: None

• References for calculation factors:

  
  

  Reference Name	Reference Value
  Contribution Level	Employee
  Contribution Level	Employer

• Wage basis rules:

  
  

  Primary Classification	Secondary Classification	Use in Wage Basis?
  Standard Earnings	All secondary classifications selected	Y
  Supplemental Earnings	All secondary classifications selected	Y

• Related elements: Medical Insurance Calculation element

  The processing rule (fast formula) associated with this element drives the social insurance deduction calculation. It accesses the appropriate calculation factor, based on the contribution level reference value and the current step in the calculation process.

• Calculation factors for Medical Insurance Calculation element:

  
  

  Contribution Level Reference Value	Calculation Step	Calculation Method	Deduction Range	Range Values
  Employee	Calculate Employee Base Amount	None	Employee Contribution Upper Limit	8000
  Employee	Calculate Employer Base Amount	None	Employer Contribution Upper Limit	5000
  Employer	Calculate Employee Contribution Amount	None	Employee Contribution Amount	4%
  Employer	Calculate Employer Contribution Amount	None	Employer Contribution Amount	3%

• Tax reporting units: All tax reporting units defined for this legislation can report this deduction. (You associate deductions with a specific tax reporting unit on the personal deduction card.)

Wage Basis Rules: Explained

Wage basis rules determine the earnings that contribute to a deductible amount or, for exemptions, the elements that reduce the amount subject to deduction.

Element Classifications

Each wage basis rule is associated with a primary or secondary element classification. For deduction elements, the classifications identify which types of earnings are subject to the deduction. For exemption elements, the classifications identify which type of earnings reduce the amount subject to deduction.

References for Wage Basis Rules

A wage basis rule may be associated with up to six references that define the context for the rule. Each reference has a sequence number that determines the order in which it is evaluated for processing relative to other references. For example, if a wage basis rule for a regional tax deduction has references for both county and city, then the county reference should have a higher sequence number than the city so that it will be evaluated first.

The wage basis rules and related references for statutory and involuntary deductions are predefined for each legislation. You cannot edit predefined rules or references.

Creating Wage Basis Rules

You can create new wage basis rules for existing deductions using the Manage Deduction Group Rules task in the Payroll Calculation work area. The process is summarized below:

1. On the Manage Deduction Group Rules page, select the deduction group to which the new rule applies.

2. In the Deduction Group Overview section, click the deduction group name and then click Wage Basis Rules. If wage basis rule references have been defined, click the reference.

3. In the Wage Basis Rules section, click Create.

4. Select the deduction to which the rule applies.

5. Select the primary and secondary classifications to be used in the wage basis for the deduction.

6. Provide the reference value for the rule, if applicable.

Wage Basis Rules: Example

The following example illustrates how to define a set of wage basis rules for a tax deduction when the earnings included in the wage basis vary depending upon where a person lives.

Taxable Earnings by Region

Brittany is a waitress who receives a salary of 5,000 USD each month plus tips. Brittany is subject to an income tax that is calculated at the rate of 10 percent of the deductible amount, which may vary based on where an employee lives. In Dover County, tips are included in the deductible amount, but in Smith County, tips are not included. This table shows the tax calculations that apply for each region.

The wage basis rules for this tax deduction are as follows:

Calculation Factors: Explained

A calculation factor defines a data-driven rule for calculating a deduction or exemption element. For example, a calculation factor for a tax deduction element might define a context reference (such as a city or state), the deduction range value (such as a 4 percent tax rate on balances under 50,000), and optionally a calculation method and calculation step. Some elements may have a large number of calculation factors, one for each unique set of rules, ranges, and references values. The element calculation process determines which calculation factor to use based on the reference values and calculation rules of the element being processed. Calculation factors are predefined for statutory and involuntary deductions, and should not need to be changed.

Aspects of a calculation factor are shown in the following figure:

Reference Values

A calculation factor may be associated with up to six references that define its context. For example, calculation of a social insurance deduction might vary based on a person's age and employment status. Each reference has a sequence number that determines the order in which it is evaluated for processing relative to other references.

To view the references associated with a calculation factor, click the deduction in the Deduction Overview pane on the Manage Payroll Deductions page.

Deduction Range

Each calculation factor is associated with a deduction range that defines the calculation type, such as flat amount or flat rate, and a set of calculation rates and rules, which may vary based on the amount subject to deduction. For example, a deduction range for a graduated tax might define a 10 percent tax rate for earnings under 50,000 USD and a 20 percent rate for earnings above 50,000 USD. Predefined deduction ranges are provided for statutory and involuntary deductions. Use the Manage Deduction Ranges task to view and manage deduction ranges.

Calculation Step

A calculation step is a label you assign to a calculation factor to identify its role in a complex calculation. For example, when calculating an income tax deduction, the process might first calculate the allowance, then any exemption amount, and then apply the tax rate to the reduced deductible amount. For such deductions, you can define multiple elements to be processed separately or define a single element with multiple calculation steps, each defined in a separate calculation factor. You can assign the same calculation step to more than one calculation factor. Calculation steps are optional.

Calculation Method

A calculation method references a single fast formula. It is an optional component of a calculation factor. Calculation methods operate at a higher level than the calculation types defined in the deduction range. They provide a wrapper around the calculation of a deduction by retrieving values from a deduction range, applying a fast formula, and returning the final deduction amount for the current run. For example, if the calculation method is set to Cumulative, which references the Core Cumulative fast formula, then the calculation process returns the total deduction amount as a cumulative year-to-date amount.

Calculation Factors for Payroll Deductions: Examples

The following examples illustrate how calculation factors are used to calculate different types of deductions.

Social Insurance Deduction

Employers in many countries deduct social insurance payments from employees and also make contributions. Employee and employer rates are typically different. Such deductions often have wage limits.

To process this type of deduction, you might create a social insurance deduction processor element with the following calculation factors:

National Income Tax Deduction Using Calculation Steps

A national income tax deduction involves the multiple steps. First, it calculates the allowance, then any exemption amount, and then it applies the tax rate. The following table shows a subset of calculation factors that might be associated with a tax processor element.

Creating Involuntary Deductions: Overview

Oracle Payroll supports a set of involuntary deduction types, such as bankruptcy orders, garnishments, child support payments, tax levies, and educational loans. Oracle Payroll provides element templates for each involuntary deduction type supported by your localization. You can create involuntary deduction elements as needed using these predefined templates. You can then add the corresponding involuntary deduction component to a personal deduction card so the deduction will be processed during a payroll run.

This figure shows the steps involved in creating an involuntary deduction.

Create Third-Party Payment Methods

Use the Manage Third-Party Payment Methods task in the Payment Distribution work area to create payment methods for all external payees. For example, you might set up direct deposit for the payee of a child support deduction. A payee can be either a person or an organization.

• If you create a third-party person payee, you must select the payroll relationship for the employee whose pay is subject to the deduction. This makes the person payment method available for selection as a payee on the employee's involuntary deduction card.

  For example, you might set up electronic file transfer (EFT) for Mary Smith, payee of a child support deduction for John Smith. When you create the person payment method, you select the payroll relationship for John Smith. When you add the child support order to John Smith's involuntary deduction card, you can select Mary Smith in the Order Amount Payee field.

• If you create a third-party organization payee, you must select External Payee in the Party Usage Code field on the Create Third-Party Organization Payee page. This makes the organization payment method available for selection as a payee on the employee's deduction card.

  For example, you might set up an EFT payment method for a County Sheriff that receives a processing fee on garnishment payments. When you create the organization payment method, you designate the County Sheriff as an External Payee. When you add the garnishment order to the employee's involuntary deduction card, you can select the County Sheriff in the Processing Fee Payee field.

  You can create a third-party organization payee for a court or other issuing authority, even if the organization is not being paid. This allows you to record address and contact information that you can later associate with the deduction on the involuntary deduction card.

For both types of third-party payment methods, you must select a previously defined organization payment method to use. (Use the Manage Organization Payment Methods task in the Payment Distribution work area to define the payment source for third-party payments, if not already defined.)

Create an Involuntary Deduction Element

An involuntary deduction element must be defined for each involuntary deduction type you need to process. Involuntary deduction elements can be created during initial setup and as the need arises later. You can create multiple elements for the same involuntary deduction type if processing information or other details vary. For example, court orders from different jurisdictions might have different processing rules. The involuntary deduction element creation process is summarized here. You can skip this task if an element has already been defined for the type of involuntary deduction you want to add to a person's deduction card and the element's processing rules meet your needs.

1. Using the Manage Elements task in the Payroll Calculation work area, create a new element with a primary classification of Involuntary Deduction and a secondary classification that reflects the deduction type, such as tax levy or child support. (Secondary element classification names vary by localization.)

2. Answer the questions on each page of the Create Element flow. For example, you must indicate whether or not to create arrears if the full deduction amount cannot be taken. A predefined set of rules, plus the answers you provide, determine which earnings contribute to the deductible amount and how the deduction will be processed.

3. Define eligibility for the element. To define open eligibility, enter a name for the element eligibility record but do not specify any criteria.

4. Define costing for the element as appropriate.

   Note

   To define costing for related elements, you must open and edit each element individually.

When you save the element, the application automatically creates all associated balances, feeds, input values, formulas, and related elements required for payroll processing. It also creates a deduction component that you can add to an employee's involuntary deduction card. Fee rules and proration rules are predefined in deduction ranges, based on statutory rules that vary by localization. Rules for core payroll are as follows:

• Fee rule: Deduct the fee first, before calculating and paying the deduction amount.

• Proration rule: First come, first serve. If a person has multiple orders and there is insufficient money to pay them all, deductions are paid in order by the date they were received, as recorded on the deduction card. (Oldest is paid first.)

• No fee amounts or protected pay amounts are predefined for core payroll. You can enter these amounts as overrides on the involuntary deduction card.

Create an Involuntary Deduction Card

Using the Manage Personal Deductions task in the Payroll Administration or Payroll Calculation work area, search for and select a payroll relationship. Create a new deduction card of the type Involuntary Deductions.

Add the Involuntary Deduction Component to the Deduction Card

On the Manage Deduction Cards page:

1. Create a deduction component with the same name as the previously defined involuntary deduction element.

   Adding the involuntary deduction component to the card automatically creates an element entry for the related deduction element.

2. If the deduction card will include more than one involuntary deduction component, you can specify the order in which the deductions should be processed in the Subprocessing Order field. For example, if you set the Subprocessing Order to 103 for a child support deduction and set it to 104 for a court order, the payroll run processes the child support deduction before the court order. By default, involuntary deduction elements are processed in order by date received; the oldest is processed first.

3. Enter a reference code to uniquely identify this deduction, such as a court order number, case number, or other identifier provided by the issuing authority.

4. Complete the fields on the Deduction Component Details tab.

   • In the Involuntary Deduction Payment Details section, select all payees for the deduction. The payee fields display all third-party person payees associated with this payroll relationship and all external payees defined for your legislative data group.

   • In the Involuntary Deduction Rules section, specify the date the involuntary deduction order was received, the issuing authority (such as a court), the frequency of the deduction, and any other pertinent information.

     Note

     Use the Frequency field to specify how often the deduction should be taken, such as monthly or weekly, regardless of the payroll frequency. If you leave the Frequency field blank, the application uses the payroll frequency.

You can add multiple involuntary deduction components for the same or different types. For example, you could add two child support and one garnishment components to the same deduction card. Assign each component a unique reference number and, optionally, specify the subprocessing order.

Create Overrides for the Deduction Amounts

You define the order amount by creating an override on the deduction card. You can also create overrides for fees and other amounts used in the calculation. These overrides replace default values defined in deduction ranges at the legislative level. The default order amount for an involuntary deduction is typically zero.

The process of creating overrides is summarized here:

1. On the Overrides Allowed on Deduction Card tab, create an override for Order Amount (Rate) or Order Amount (Amount).

   For example, if you specified a frequency of monthly in the component details, enter the amount to deduct each month, regardless of the payroll period; the application automatically calculates the correct amount to deduct in each payroll run. If you did not specify a frequency, this amount will be deducted at the payroll frequency defined for the payroll relationship.

2. Create additional overrides, as needed, for fees, protected pay amount, minimum and maximum withholding amounts, and other values applicable to this deduction.

   Make sure that you have selected a payee on the component details for each fee override you create.

Process the Payroll with Deductions

During a payroll run, the status processing rule for the deduction element calculates the correct deduction amount based on rules predefined for the deduction type plus information defined on the deduction card.

Creating Overrides for Involuntary Deductions: Critical Choices

You define the order amount for an involuntary deduction by creating an override on the person's involuntary deduction card. You can also create overrides for fees and other amounts used in the calculation. These overrides replace default values defined in deduction ranges at the legislative level.

Overrides Allowed on Deduction Card

The overrides allowed on a deduction card may vary by legislation, but typically include the items described in this table.

Involuntary Deduction Processing: Examples

Use these examples to understand how involuntary deductions are processed in different scenarios for core payroll. Processing rules may vary by legislation or legal authority issuing the order for the deduction.

Involuntary Deduction Has Initial Fee and Processing Fee

Scenario: A US employee is issued a court order for a monthly garnishment for 500 USD. The order is subject to a 10 USD one-time initial fee and a 10 USD monthly processing fee, which are both paid to the agency responsible for administering the account and forwarding payment to the recipient.

Involuntary Deduction Card Setup: Add a deduction component for a garnishment and then:

1. Select the Order Amount Payee and the Processing Fee Payee. (The processing fee payee is also the initial fee payee.)

2. Set the Frequency to monthly.

3. Create an Order Amount override, and set the amount to 500.

4. Create a Processing Fee Amount override, and set the amount to 10.

5. Create an Initial Fee Amount override, and set the amount to 10.

Payroll Run Results:

• The amount of the employee's pay subject to deduction is 1000 USD.

• During the first monthly payroll after the court order is received, both the initial fee amount and the processing fee are deducted, for a total deduction amount of 520 USD.

• In subsequent payroll runs, only the processing fee is deducted, so the total deduction amount is 510 USD.

Deduction Amount Exceeds Protected Pay Amount

Scenario: A UK employee is issued a court order in the amount of 100 GBP per month. However, protected pay rules defined for the deduction require that the employee take home at least 700 GBP, after all deductions.

Involuntary Deduction Card Setup: Add a deduction component for a court order and then:

1. Select the Order Amount Payee.

2. Set the Frequency to monthly.

3. Create an Order Amount override, and set the amount to 100,

4. Create a Protected Pay Amount override, and set the amount to 700.

Payroll Run Results:

• The amount of the employee's pay subject to the deduction is 750 GBP.

• A 100 GBP deduction amount would leave only 650 GBP for the final pay amount. Therefore, only 50 GBP is deducted for the month.

• The remaining balance of 50 GBP is not placed in arrears, based on processing rules defined for this deduction.

Employee Has Multiple Assignments and Payrolls

Scenario: An employee has 2 assignments, both for the same payroll relationship, and is assigned to 2 different payrolls. One of the assignments is on a weekly payroll, and the other assignment is on a monthly payroll. The employer receives a court order to deduct 200 USD per month from the employee's wages. The court order amount must be deducted from all available money, regardless of the payroll. If the total order amount cannot be deducted from the first payroll run, then the remaining balance must be deducted from one or more subsequent runs during the month, until the full amount is paid.

Involuntary Deduction Card Setup: Add a deduction component for a court order and then:

1. Select the Order Amount Payee.

2. Set the Frequency to monthly.

3. Create an Order Amount override for 200 USD.

Payroll Run Results:

• During the first weekly payroll run, only 50 USD can be deducted, leaving an amount owed of 150 USD for the month.

• When the next weekly payroll is run, no deduction can be taken due to insufficient pay. The balance for the month remains 150 USD.

• The monthly payroll runs before the next weekly payroll is run. The remaining 150 USD owed for the deduction is taken during the monthly payroll run.

• No money is deducted during the subsequent weekly payroll runs for this month.

Multiple Orders Exist with Different Protected Pay Amounts

Scenario: A UK employee has 3 court orders, and each has a different protected pay amount.

Deduction Card Setup: Add 3 deduction components to the employee's deduction card. Set the frequency of each one to monthly. Define protected pay and order amount overrides for each as shown in this table.

Payroll Run Results:

The net amount available for involuntary deductions in the payroll run is 2000 GBP. Based on the processing priority defined for child support payments, the payroll run processes the involuntary deductions in order by date received.

• Child Support 1 is paid in full, leaving 1000 GBP available for other deductions.

• Child Support 2 is paid an amount of 400 GBP (1000 less protected pay of 600).

• Child Support 3 is not paid. The total amount is placed in arrears, based on processing rules defined for the deduction.

How do I view and manage calculation factors?

Select the Manage Payroll Deductions task and open the deduction. In the Deduction Overview section, expand the Related Elements node and then expand the Calculation Factors node to display a list of all calculation factors associated with the element. You can create new calculation factors and edit existing ones that have an update status of Unlocked. You cannot edit predefined calculation factors. Note that if you create a new calculation factor, you must edit the element's processing rule (a fast formula) to use the new factor.

Why can't I create payroll deductions?

Oracle Payroll provides a set of predefined statutory deductions. You can view predefined deductions from the Manage Payroll Deductions page, but you cannot create new deductions. You can create new involuntary deduction elements using the Manage Elements task. The predefined involuntary deduction element templates automatically create a payroll deduction object and associated deduction component when you save the involuntary deduction element. You can add deduction components to a personal deduction card using the Manage Personal Deductions task. Adding a deduction component to a deduction card creates an element entry for the related deduction element.

Add Eligibility Rules for Predefined Elements

Element Eligibility: Explained

Element eligibility determines which people are eligible for an element. To determine eligibility, you assign element eligibility criteria to the components that persons must have to receive entries of the element. While some elements may represent compensation, deductions, and equipment available to all persons, many elements are available only to certain groups of persons. For example, your enterprise might provide company cars only to persons in the Sales Department. Eligibility criteria rule out the possibility of persons getting element entries by mistake. For example, you might want to give a production bonus only to those persons who work full time in Production and are on the weekly payroll. To do this you would define eligibility criteria for the element Production Bonus and the combination of the Production organization, the Full-Time assignment category, and the Weekly payroll.

Eligibility Criteria

Element eligibility can be assigned by many different criteria.

• All payrolls or for specific payrolls

• Payroll statutory unit

• Legal employer

• Payroll relationship type

• Department in which the person works

• Location of person's office

• Job, for example, Associate Professor or Secretary

• Grade

• Groups to which the person belongs. You set up all the groups that are appropriate for your enterprise. For example, you could decide to group persons by company within a multi-company enterprise, and by union membership.

• Position, which is a class of job performed in a particular organization, for example, Associate Professor of Chemistry, or Finance Department Secretary.

Multiple Rules of Eligibility

You can define more than one eligibility criteria for each element but there must be no overlap between them. For example, you could create one criteria for the combination of grade A and the job Accountant. However, you could not create one criteria for grade A and a second for the job Accountant. This would imply that an accountant on grade A is eligible for the same element twice. If you have more than one criteria for an element, you can enter different default values, qualifying conditions, and costing information for each eligibility group.

Maintaining Element Eligibility: Explained

Element eligibility rules always control element entries.

After you have used an element you can make the following changes to the eligibility rules:

• Change the input value default values and validation.

  These changes affect all new entries. Changes to run time defaults affect existing entries. The system also uses the new validation rules to check any updates you make to existing entries.

• Date-effectively end all of the rules that apply to an element and define a new set of rules, which are effective from a later date. For example, suppose you have defined eligibility for a company car based on grade. Following a change of policy you must now define eligibility based on job.

  • You will not be allowed to end the element eligibility if any nonrecurring entries exist at the date you want to end the rule. You must delete existing entries before you end the element's eligibility.

  • You can end the element eligibility if recurring entries exist. Any existing entries will be ended automatically when you end the element's eligibility.

• Change the qualifying conditions of age and length of service that persons must meet to be eligible for the element.

Define Events

Payroll Event Groups: Explained

A payroll event group is a group of types of data changes that trigger retroactive event notifications or prorated calculation of a person's earnings.

There are two types of payroll event groups:

• Proration

• Retroactive

Proration

Using proration, you can calculate proportionate earning and deduction amounts whenever payroll-relevant data is changed during a payroll period, for example, if a person joins or leaves an organization or if a person's pay grade changes during a payroll period.

If you want to prorate an earnings element, such as basic salary, assign a proration event group to it containing the proration points that affect a person's salary. When you define the event group, you select the events that activates proration calculation, such as changes to:

• Pay grades or grade rates

• Pay scales and progression points

• Hourly or annual pay rates

• Working hours

• Allowances or deductions

Retroactive

Retroactive processing ensures that your payroll run for the current period reflects any backdated payments and deductions from previous payroll periods. A retroactive event group defines the types of changes that trigger a retroactive event notification.

Within a retroactive event group, select the events that produce notifications if a backdated change occurs. Specify the entity, update type, and attribute, such as the examples provided in the following table.

Define Payment Methods

Bank, Branch, and Account Components: How They Work Together

Banks, branches, and accounts fit together on the premise of the Bank Account model. The Bank Account model enables you to define and keep track of all bank accounts in one place and explicitly grant account access to multiple business units, functions, and users. This eliminates the redundant duplicate bank account setup under different business units when these business units share the same bank account.

Banks

Creating a bank is the first step in the bank account creation. The user can search for existing banks, view and update them, or create new banks. You can create a new bank from an existing party. The option to create from an existing party is implicitly implemented by the matching option. The option is available only after the existing party has been found with the same bank. If you choose the matching option, the page repopulates the information from the matched party.

Branches

Once you have created your bank, the next step is create a branch or branches associated to the bank. The matching option is also available when creating branches. To create a new branch without using the matching option, manually enter in the information required. You can define other branch-related attributes in the page. If you do not use the matching option when an existing party is found, a branch with the same party name is created.

Accounts

Once the bank and branch are created, you can proceed to the bank account setup. Select the bank branch you want to associate to your bank account. Assign the owner of the bank account. There are four areas associated to defining the account: general information, control of the account, security access to the account, and business unit assignment. If this is a Payable or Receivable account, the accounts are identified by business unit, and if a Payroll account, by legal entity.

Creating Accounts: Points to Consider

Banks, branches and accounts fit together on the premise of the Bank Account model. The Bank Account model allows you to define and keep track of all bank accounts in one place and explicitly grant account access to multiple business units, functions, and users. Consider the following when you set up bank accounts:

• Assigning a unique general ledger cash account to each account and use it to record all cash transactions for the account. This will facilitate book to bank reconciliation

• Granting bank account security; bank account security consists of bank account use security, bank account access security, and user and role security.

Account Use

Account use refers to accounts created for Oracle Fusion Payables, Oracle Fusion Receivables and Oracle Fusion Payroll. When creating an account to be used in one or more of these applications you must select the appropriate use or uses.

Account Access

Payables and Receivables account access is secured by business unit. In addition to selecting the appropriate application use or uses, one or more business units must be granted access before the bank account can be used by Payables and Receivables. Only business units who use the same ledger as the bank accounts owning legal entity can be assigned access

User and Role Security

You have the option to further secure the bank account so that it can only be used by certain users and roles. The default value for secure bank account by users and roles is No. In Payables and Receivables even if the secure bank account by users and roles is no, you must have the proper Multi-Organization Access Control (also known as MOAC) to access a bank account. If the secure bank account by users and roles is set to Yes, you must be named or you must carry a role that is named expressly on the bank account in order to use it.

Organization Payment Methods: Explained

Organization payment methods identify the payment type and the currency to use for payroll payments to workers and for disbursing employee deductions to third parties.

You must define at least one organization payment method for each type of payment and currency that you use to disburse wages and other compensation to your employees. You can also define rules for validating or processing the distribution of payments when you offer more than one option.

A typical configuration is to have one organization payment method for each combination of legislative data group, payment type, and currency.

Payment Types

Any payment method that you define must belong to one of the payment types that your enterprise supports.

Each payroll must have at least one valid organization payment method for each payment type available to employees on that payroll. There may be more than one payment method with the same payment type.

The most common payment types are:

• Electronic funds transfer (EFT)

• Check

• Cash

Your enterprise may support a different range of types that are appropriate for your localization. For example, some localizations do not allow cash, some do not support checks, and very few support postal money orders.

The names of payment types can vary by localization. For example, in the US, the payment type for EFT is NACHA; in the UK it is BACS, and in Australia it is BECS.

Payment Sources

Payment sources associate bank accounts and other sources of funds with organization payment methods.

Each organization payment method that is in use must have at least one valid payment source. For check and EFT payment methods, the payment source must be associated with an active bank account defined in Oracle Fusion Cash Management. If an organization payment method is associated with multiple payment sources, then the payment method rules determine which payment source is to be used for each disbursement.

You can use the same bank account as a payment source in more than one organization payment method. For example, one checking account may be used to pay both check and EFT payments. The application will not prevent specifying the same name for different payment sources, but it is best practice to use different naming for each occurrence.

When you have one organization payment method for each combination of legislative data group and payment type, you can use payment rules to determine the appropriate payment source based on tax reporting unit. However, there are several reasons why a company might need multiple organization payment methods and multiple payment sources, such as these examples:

• Company X has only one tax reporting unit, but prefers to pay its executive staff from a separate bank account for security and confidentiality.

• Company Y must comply with state laws and union agreements requiring that checks are drawn on an in-state bank. It uses different organization payment methods for each bank used to pay people based upon their locale.

• Company Z may use different currencies to pay foreign nationals and expatriates working in a different country than their home.

Payment Rules

The first payment source defined is the default payment source. If you add more payment sources, you can add subsidiary information as payment rules. For example, if you have multiple tax reporting units, you can specify which payment source to use for each tax reporting unit.

Having a default payment source ensures that employees are paid if there is a change in tax reporting unit. For example, Company A has multiple independent franchises, each with its own tax reporting unit. If a franchise sells, it will have a new tax reporting unit number, and the payment rule will fail. Instead of issuing errors, payment is made using the default payment source.

You might rather not specify a default payment source when payments cannot be made from the specified payment source in the payment rule. For example, Company B has 30 bank accounts and is very careful not to comingle funds. They leave the default unspecified to instead receive notifications that they can resolve manually.

Default Payment Methods

You can define as many payment methods as required for your enterprise. When you create a payroll, you can select which of these methods are valid for employees assigned to that payroll. You select one method as the default method for the payroll. The default payment method is used to determine how to disburse a payment when an employee does not have any personal payment methods specified.

Relationship to Other Objects

You select organization payment methods when defining other objects, such as payroll definitions and other payment methods. Organization payment methods are only available for selection if they are effective as of the date the object is being defined or updated.

For example, if you create a payroll definition effective as of 4/1/2012 and want to associate a particular organization payment method as the default, the organization payment method must have an effective start date on or before 4/1/2012. Similarly, when updating or correcting objects to change the organization payment method, the organization must have an effective start date on or before the effective date of the change.

The functional relationship of organization payment methods with other objects is described in this table.

Setting Up Payment Sources in Organization Payment Methods: Worked Example

This example demonstrates how to set up payment sources when defining organization payment methods for your enterprise.

The following table summarizes the key decisions for this scenario.

In this example, the InFusion US company pays its employees by check and electronic funds transfer (EFT) payments. Two bank accounts have been set up for funds used to pay the executive staff and the regular employees separately. The company occasionally distributes payments to external third-party consultants, but must comply with state regulations and pays them from two different banks based on their tax reporting unit.

Prerequisites

This worked example assumes that the following prerequisites of organization payment methods have already been set up:

1. The primary ledger is set up in Oracle Fusion General Ledger and is available for use.
2. The banks, branches, and account information to use as the payment sources are set up in Oracle Fusion Cash Management and are available for use.
3. The legal entity associated with the legislative data group has been assigned to a general ledger.
4. Tax reporting units have been set up and are available for use.

Setting Up Organization Payment Methods

Perform the following steps three times, once for each of the three organization payment methods.

1. In Payment Distribution work area, click Manage Organization Payment Methods.
2. In the Search Results section, click Create.
3. Select the legislative data group, for example, InFusion US LDG.
4. Select the date when you want this payment to start being available for use, and then click Continue.
5. In the Basic Details section, complete the fields as shown in this table, and then click Save.

   Field	Non-Executive Value	Executive Value	Consultant Value
   Name	Employee Payroll Check	Executive Payroll Direct Deposit	In-State Consultant Check
   Payment Type	Check	NACHA	Check
   Currency	US Dollar	US Dollar	US Dollar

   
   
6. For the non-executive and executive employee organization payment methods, in the Payment Sources section under Employee Payment Sources, click Create.

   On the Create Payment Source page, complete the fields as shown in this table, and then click Continue.

   Field	Non-Executive Value	Executive Value
   Name	Employee Check Source	Executive Direct Deposit Source
   Bank Account Name	InFusion US Your Bank	InFusion US Bank of America

   
   

   Note

   Keep your payment source names as specific as possible for each scenario. This will help when managing more complicated combinations of organization payment methods and payment rules.

7. For the third-party organization payment method for non-employee payments, in the Payment Sources section under Third-Party Payment Sources, click Create.

   Perform this step twice, once for each payment source.

   On the Create Payment Source page, complete the fields as shown in this table, and then click Continue.

   Field	First Source Value	Second Source Value
   Name	Texas Check Source	California Check Source
   Bank Account Name	Comerica Bank	Bank of the West

   
   

   Note

   If a single organization payment method has payment sources defined for both employees and third parties, the names of the payment sources must not be the same.

8. Click Submit.

Creating Payment Rules

In this example, the organization payment method you set up for the external third-party payments with two different payment sources requires payment rules to determine how payments are distributed.

Perform these steps for the In-State Consultant Check organization payment method created in the previous task.

1. In the Search section of the Manage Organization Payment Methods page, select your legislative data group, and then click Search.
2. In the Search Results section, click the Edit icon in the Update Status column for the row showing the In-State Consultant organization payment method.
3. Click Yes if a message displays confirming you want to correct the record.
4. In the Payment Method Rules section under Third-Party Payment Sources, click Create and select the values shown in this table to create two payment rules that map a payment source to a tax reporting unit.

   Field	Texas Check Source	California Check Source
   Default	No	No
   Tax Reporting Unit	Texas TRU	California TRU
   Payment Source	Texas Check Source	California Check Source

   
   
5. Click Submit.

Adding EFT File Information

In this example, the bank information for the EFT payments to executive employees must be added.

When you select the EFT payment type, you can enter EFT information at the organization payment method level, the payment source level, or both. Entries at payment source level take priority over entries at organization payment level. In this example, the EFT information is set at the organization payment method level because the US company requires notification of any electronic transfers of funds 10 days prior to the planned transfer date.

1. In the Search section of the Manage Organization Payment Methods page, select your legislative data group, and then click Search.
2. In the Search Results section, click the Edit icon in the Update Status column for the row showing the Executive Direct Deposit organization payment method.
3. Click Yes if a message displays confirming you want to correct the record.
4. In the Electronic Funds Transfer File Information section, enter values as shown in this table.

   Field	Value
   Prenotification Required	Yes.
   Prenote Days	10

   
   
5. In the Payment Rules area, ensure that the Executive Direct Deposit Source is selected as the default payment source.
6. Click Submit.

Third-Party Payment Methods: Explained

Use the Manage Third-Party Payment Methods task to create payment methods for all external payees who are not on the payroll. A third party can be either a person or an organization. Payments to third parties are normally involuntary deductions, such as court-ordered garnishments.

For all third-party payment methods, the organization method that determines the payment source to use must already be defined. Use the Manage Organization Payment Methods task in the Payment Distribution work area to define the payment source for third-party payments.

Payments to Persons

When you create a third-party payment method for a person, you select the payroll relationship for the employee whose pay is subject to the deduction. This makes the third-party person payment method available for selection as a payee on the employee's involuntary deduction card.

For example, you might set up an electronic funds transfer (EFT) payment to Mary Smith for a child-support deduction for employee John Smith. When you create the third-party payment method, you select the payroll relationship for John Smith. When you add the child support order to John Smith's involuntary deduction card, you can select Mary Smith in the Order Amount Payee field.

Payments to Organizations

When you create a third-party payment method for an organization, you select External Payee in the Party Usage Code field to make the organization available for selection as a payee on the employee's deduction card.

For example, you might set up an EFT payment method for a County Sheriff that receives a processing fee on garnishment payments. When you create the payment method, you designate the County Sheriff as an External Payee. When you add the garnishment order to the employee's involuntary deduction card, you can select the County Sheriff in the Processing Fee Payee field.

Define Payroll Costing

Payroll Cost Allocation Key Flexfield: Critical Choices

The cost allocation key flexfield creates a structure that captures the account codes you use to create accounting entries, and to report and track your labor costs. When planning how to create a key flexfield structure, consider the following choices:

• Structure of the cost allocation key flexfield

  Decide how many segments you require and in what sequence, and whether you need additional segments not required by the chart of accounts flexfield.

• Segment Value Sets

  Confirm that you have created value sets or can reuse existing value sets that supply the values for each segment you create in your flexfield structure.

• Cost hierarchy levels required for each cost account segment

  For the cost account, for each column heading, you select the segment labels that correspond to the levels of the cost hierarchy where the user can enter account information: payroll, element, department, job, position, and person levels.

• Identify which segments should be available for entry for the offset account

  For the offset account, for each column heading, you select offset as the segment label, if you want to enable entry of the segment for the offset account.

  Decide if the account number you enter for a segment of the cost account is the same account number you enter for the offset account. You only need to specify that a segment is applicable for the offset account, if you expect the segment to record different account number than the cost account. For example, for a segment where the account number seldom changes, such as the number that identifies the company, you would not specify that the company number is applicable for the offset. When the application builds the offset account for the company segment , it would use the account number for the company segment that you entered for the cost account.

• Number of different instances of the cost allocation key flexfield structure

  Determine if a legislative data group requires different value sets for the flexfield segments. You can create separate instances for these legislative data groups.

Structure of the Cost Allocation Key Flexfield

Use the predefined cost allocation key flexfield code to create a cost allocation key flexfield structure. The structure specifies the segments to include, their order, and the value sets to validate the data entered in the segments. The segments correspond to each part of the account number, such as the company identifier, cost center code, and the activity or expenditure type.

As a best practice, you create the cost allocation key flexfield structure based on the key flexfield structure used by the chart of accounts flexfield that receives the costing entries from payroll. By using a similar sequence of segments and naming conventions, you can facilitate setup, avoid discrepancies, and minimize effort. For example, when you define the accounting rules in Oracle Fusion Subledger Accounting, you can more easily map the segment names of the cost flexfield to the heading names in the chart of accounts flexfield.

When you create your cost allocation key flexfield, also consider whether you want to add segments for:

• Future use

  You can include segments in your flexfield and not display them until you start using them, such as segments that accommodate new lines of business as the enterprise expands.

• Context sensitive information used by legislation

  For example, if you maintain separate liability accounts for each state and state tax, you might create additional segments to record this context sensitive information.

• Project and task information used by other applications

  For example, you might choose to break down costs of a project for reporting purposes.

Segment Value Sets

You associate each segment in your structure to a value set, which validates the data entered for that segment.

When planning which value sets to create for your segments, consider which segments require a:

• Value set that is shared, such as value sets created for the chart of accounts flexfield

• Value set specific to payroll

  You might create a separate value set if you require a small subset of the value set created by Financials. In this example, a separate value set could reduce input errors.

• Single value when segments share the same value for all accounts

  For example, if you add a segment for future use to your flexfield structure, you might create a value set with a single value of zeros to serve as a placeholder for a future account number.

Cost Hierarchy Levels

When you create the cost allocation key flexfield structure, you determine at which levels of the cost hierarchy each cost account segment is available for entry. This structure controls which cost account segments the application displays on the costing setup pages.

Each column heading of the cost key flexfield structure corresponds to a segment of your account structure. Each segment label of the flexfield structure corresponds to a cost hierarchy level, which qualifies where you can enter account information. For example, you might select the column heading for the segment that records the natural account and select element as the segment label. The Manage Costing of Elements page would then include the natural account segment for the cost account, and you could enter that account for the appropriate element eligibility records.

The following figure illustrates how the flexfield structure determines which segments you can specify for the cost account on the costing setup pages.

You do not have to enter a costing segment at each level of the cost hierarchy where it is available for entry. The cost hierarchy determines how a segment inherits an account number. If you enter an account number at a higher level, such as the company account at the payroll level, each lower level of the cost hierarchy inherits that number. If you do not want all the levels to inherit the same number, you can specify the levels at which to override the account number. Overrides identify costs at a more granular level.

The level at which you enter costs is a key determinant in how the application builds the account number. The application starts with the lowest level (element entry) and ends with the highest level (payroll), checking for a value at each level until a value is found. For example, if you specify that a cost center segment is available for entry at the department and job levels, if the application finds a cost center number at the job level, it uses that number and not values at any higher levels.

The following figure shows the different levels of the cost hierarchy.

When setting up the segment labels for the cost allocation key flexfield, consider which level of the cost hierarchy to enable the segment for entry. The following table includes example of the segment labels you might specify for costing.

Number of Key Flexfield Structure Instances

You create structure instances of your cost allocation key flexfield that you then associate to legislative data groups. Structure instances share the same set, arrangement, and properties of the cost allocation key flexfield structure.

Before creating structure instances, determine how many instances you require. You associate a single instance to a legislative data group on the Manage Legislative Data Groups page, but you can associate the same instance to several legislative data groups, as long as they all use the same value sets.

To fully implement the cost allocation key flexfield, you specify rules in Oracle Subledger Accounting that identify the flexfield instance to use as the source for entries in the chart of accounts flexfield.

Payroll Costing Components: How They Work Together

Payroll costing integrates components required to accurately report labor costs and generate journal entries for your payroll run results and payments. To set up and manage payroll costing, you must have the appropriate duty roles to create components used by payroll costing, such as ledgers that you associate to legal entities, accounting methods and rules, and banking information.

Payroll costing involves creating the following components:

• Financial ledgers, calendars, accounting periods, and legal entities

• Cost allocation key flexfield

• Subledger accounting methods and rules

• Cash Management bank account and reconciliation information

• Payroll cost accounts

The following figure illustrates how Oracle Fusion Global Payroll works with the following applications: Oracle Fusion Financials to maintain ledgers, accounting periods, and calendars for legal entities; Oracle Fusion Cash Management to reconcile payments with bank statements; and Oracle Fusion Subledger to create journal entries and post to General Ledger.

The following figure shows the different components you set up for payroll costing grouped by application.

Financial Information

You create components in Financials that support payroll costing, such as general ledgers, accounting calendars, and accounting periods. For example, you create ledgers in Financials that you later associate to your payrolls.

You create an accounting key flexfield structure for the chart of accounts and create General Ledger accounts that receive costing entries, such as cost, offset, payroll liability, cash clearing, and cash accounts. Most enterprises use the structure of this key flexfield and the value sets as a basis for the structure of the cost allocation key flexfield. When you create the equivalent accounts in payroll, you should ensure that the same natural account is used in payroll that you use in your General Ledger accounts. By using a similar structure, you avoid discrepancies, minimize maintenance, and improve communication between departments when resolving questions about account entries. For example, you would want to ensure that the Cash account used the same natural account in Payroll as in General Ledger so that you can easily reconcile the cash account balance with the bank balance for transactions for the same bank account. The Application Implementation Consultant with the appropriate Financial duty roles can perform these tasks.

Cost Allocation Key Flexfield

You create an account key flexfield structure based on the cost allocation key flexfield code, and then create a structure instance that you associate to appropriate value sets. You map the structure instance to a legislative data group. You specify rules in Subledger Accounting on the Manage Account Rules page to use the cost allocation key flexfield instance as the source for segments in the accounting key flexfield for the chart of accounts.

The cost flexfield structure determines at which levels of the payroll cost hierarchy you can enter account information when you create your payroll accounts. Specifying different levels at which to enter account information for a segment enables you to override account information. For example, you might specify that the department and job level can hold account information for a cost center segment, which would then enable you to specify a different cost center for a job than the department.

Subledger Accounting Methods and Rules

Subledger Accounting generates subledger journals, creates subledger balances, and generates general ledger journals. Payroll supplies predefined data for Subledger Accounting, such as event classes for event entities. You create accounting methods, and journal line and entry rules that Subledger Accounting uses to create accounting entries and post them to general ledger. You must have the Subledger Accounting duty roles required to perform these tasks.

Cash Management Bank Account and Reconciliation Information

Payroll requires bank account information for Check and EFT payment types, and optionally for Cash and Money Order payment types. If you plan to cost the payments that you issue, complete the bank, branch, and bank account information for the payment source and specify the General Ledger cash account. To reconcile your payments, you create reconciliation rules, map transaction types to payment types, create bank statement transaction codes, and specify the General Ledger accounts for cash clearing and reconciliation differences. You must have the Cash Management duty roles required to perform these tasks

Payroll Cost Accounts

After creating the components that support payroll costing in the other applications, you create the costing setup information for the different payroll accounts you intend to use, such as the cost, offset, suspense, default, payroll liability, cash clearing, and cash accounts. You enter the account information and any overrides for the different levels of the cost hierarchy. You must ensure when you set up the cash and cash clearing accounts that the natural account segment you specify for these accounts is the same as the natural account specified in the equivalent general ledger accounts.

Payroll Costing and Payroll Accounts Setup: Critical Choices

Payroll accounts capture the account information required to generate journal entries for the ledgers used by your legal entities, and to produce the data required to accurately report and track labor costs based on regulatory and corporate requirements. The framework for payroll accounts accommodates cash and accrual accounting, distribution of costs over earnings elements, allocation of costs to multiple accounts, and the reconciliation of payments.

The payroll accounts you create store cost, payment, and offset costing results. The application places cost results with errors in a suspense account and unallocated costs in a default account for review and corrective action. Review the following choices about the payroll accounts and the options for managing the costing results:

• Offset accounts

• Payment accounts

• Suspense and default accounts

• Cost account overrides

• Cost allocation and distribution

• Transfer to General Ledger

• Retroactive costing

Offset Accounts

Identify which accounts your enterprise uses to create balancing entries required for double-entry bookkeeping. Create offset accounts on the Manage Costing of Elements page for each element eligibility record that you cost.

For elements that affect net pay, the offset for cash accounting is usually an asset account, such as Cash in Bank, and for accrual accounting a payroll liability account, such as Wages Payable. Employer taxes and benefit expenses generally use offset accounts specific to the types of liability.

The cost allocation key flexfield determines the segments available for entry for the offset account. You do not have to complete all the segments. If you leave a segment blank, the application builds the account information based on the corresponding segment entered for the cost account.

Payment Accounts

The number of payment accounts you create depends on whether your company uses cash or accrual accounting, and whether you reconcile your payments.

For both cash and accrual accounting, create a cash account for each separate bank account, entering the appropriate natural account for each record. If you use accrual accounting, create payroll liability accounts for your payment sources. If you reconcile your payments, create a cash clearing account to generate costing entries when the payments clear. When you create these accounts, ensure that you select the same account numbers for the segments as the General Ledger accounts you select when specifying the bank account information in Cash Management. By using the same account information, you avoid discrepancies and minimize maintenance.

Suspense and Default Accounts

You can create payroll suspense and default accounts at the payroll or department level of the cost hierarchy. Suspense and default entries for a department override those at the payroll level.

Review your enterprise requirements to decide at which level you resolve invalid or unallocated cost results. For example, you may decide to create the default account at the department level, to aggregate unallocated cost results so that they are more easily identified and processed.

Cost Account Overrides

You can override the costing information to meet specific conditions, such as costing for a job or person or for a specific payroll period. You can also override the standard process of building the cost account by creating a Priority account to cost element results.

You can control the level of granularity for costing by entering costing information for:

• An object at a lower levels of the cost hierarchy

  You enter account information on separate pages that correspond to the levels of the cost hierarchy: Manage Costing of Payrolls, Manage Costing of Elements, Manage Costing of Departments, Manage Costing of Jobs, and Manage Costing of Positions. You can override account information entered at a higher level of the cost hierarchy by entering information at a lower level. For example, if you enter an account number for the cost center segment for a department on the Manage Costing of Departments page, you could override the account number for a job within that department, by entering its cost center account number on the Manage Costing of Jobs page.

• A person

  After you conclude your implementation and create your person records, you can override costing account information on the Manage Costing of Persons page by specifying costing at the payroll relationship, terms, or assignment level.

• A payroll period

  You can enter cost information on the element entry records for people in your enterprise to apply to a specific payroll period.

You can override the standard process for calculating the cost account by creating a Priority cost account. You might create a Priority account to ensure that the application costs the entire cost or a portion of the cost to a single account number. If you specify a percentage of the cost to a Priority account, the application creates a costing entry for the percentage allocated to the Priority account, and a costing entry for the remaining percentage, by using the standard costing process to derive the cost account number.

Cost Allocation and Distribution

You have a choice to divide a cost among accounts, for example to divide labor costs over more than one cost center. You can also distribute your overhead expenses across earnings elements, such as employer liability and tax charges.

You can allocate costs when creating:

• Cost accounts for departments, jobs, and positions

• Priority accounts

• Person accounts

  You create cost accounts for people after you complete your implementation and create person records.

You set up distributed costing by creating the cost account information for the distributed element on the Manage Costing of Elements page and the distribution element groups that include earnings elements on the Manage Object Groups page. You can control whether to include all or a portion of each earning element, and whether to include the earnings element in more than one distribution group.

Transfer to General Ledger

If you plan to transfer payroll and payment costs to Oracle Fusion General Ledger, you select options on the costing setup pages. Specify on the Manage Costing of Elements page and the Manage Costing of Payment Sources the elements and payment sources that you intend to post to general ledger.

Default configuration parameters specify the basis for accounting dates, which you can review and update as required on the Manage Payroll Process Configuration.

Retroactive Costing

There are two retroactive costing processes, one which calculates costs after you retroactively change the costing setup, and one which calculates costs when you calculate retroactive pay.

Before you can run:

• Calculate Retroactive Costing, correct the information you set up at the different levels of the cost hierarchy

  The process recalculates cost results after you retroactively edit the costing setups. The application compares the recalculated and original entries, and where different, offsets the original entries and creates new ones.

• Recalculate Payroll for Retroactive Changes, cost the eligibility records of each retroactive element whose run results the application should automatically cost when calculating retroactive pay

  The process calculates costing for retroactive pay changes that were not included in the original payroll run, and records the difference found between the original entry and the retroactive result.

  For the costing of retroactive pay, a default configuration parameters specifies the basis for accounting date used to cost the run results. You can review and update the parameter on the Manage Payroll Process Configuration page

  
  

  Parameter Name	Parameter Description	Default Value
  Cost Retroactive Entries on Date Paid Rather than Date Earned	Controls whether the application uses the date earned (E) or the date paid (P) as the basis for the accounting date to costing the retroactive entries.	E

Payroll Costing and Financials Setup: Explained

Oracle Fusion Global Payroll integrates with Oracle Fusion Financials, so that you can generate and post accounting entries posted to the appropriate ledgers and accounting periods. You create components such as ledgers, accounting calendars, and account periods. You create general ledger accounts for each payroll account that records payroll costs.

Financial Setup Tasks

You perform the following tasks as part of the common application configuration setup for Financials. Complete these tasks for payroll costing.

If Payroll and Financials are integrated in a single system, an application implementation consultant role or appropriate duty role must be given to a Financials or Global Payroll manager.

Payroll Costing and Subledger Accounting Setup: Explained

Oracle Fusion Global Payroll integrates with Oracle Fusion Subledger Accounting to streamline accounting tasks. Payroll transactions generate accounting events such as the costing of the payroll run, payments, and partial period accruals. Subledger Accounting applies rules to the transaction data and creates subledger journal entries and subledger balances for each payroll cost, and posts this information to Oracle Fusion General Ledger. This integration simplifies the management of corporate and statutory audit and reporting requirements by recording detailed and summary information, and facilitates the reconciliation of payments with Oracle Cash Management.

Global Payroll provides predefined data for Subledger Accounting. Subledger Accounting uses this data when creating accounting entries for payroll transactions and posting the resulting journal entries to General Ledger. You create additional components in Subledger Accounting to support costing, such as accounting methods and rules.

Predefined Tasks

When you create your implementation project, you can configure the Financials offering by selecting the Define Subledger Application and Sources task list from the Select Features Choices page. You can include this task list to view the Subledger Accounting information that supports payroll costing. The information includes the definition of attribute values, process categories, event classes and event class options, sources, source assignments and accounting attribute assignments, journal line types, account derivation rules, journal lines definitions, and application accounting definitions.

Required Tasks

The Define Subledger Accounting Methods task list includes tasks you must complete to integrate Subledger Accounting with Payroll.

You perform the following tasks as part of the setup required for defining payroll costing.

Optional Tasks

Complete the following optional tasks.

Payroll Costing and Cash Management Setup: Explained

Oracle Fusion Global Payroll integrates with Oracle Fusion Cash Management, which facilitates the reconciliation of bank statements with payment transactions, and monitoring those payments throughout the reconciliation cycle.

Payroll processes transfer your payment entries to Cash Management for manual or automatic reconciliation with bank statements, and cost the unreconciled and cleared payments to the appropriate account, such as the cash clearing, and cash accounts. A reconciliation difference account records discrepancies, such as over or under payments.

Tasks for Payroll

You must set up bank accounts in Cash Management before you can set up your organization payment methods in Global Payroll. A manager with the appropriate duty role performs this task, usually a Cash Management cash manager. Complete the following tasks in Cash Management to create the banking information and to support the reconciliation of payroll payments through the bank accounts.

Payroll Costing of Elements: Critical Choices

The Manage Costing of Elements page records your choices about how to cost the element eligibility records for an element. You can decide which input values for the element to cost and which offset account to use to balance the cost account. You also have the choice of creating an override cost account, a Priority account, to ensure that you cost the run results to only one account number.

After you complete the initial implementation and create your person records, you can further define the costing of elements for specific people in your enterprise to cover situations where, for example, you need to cost the person's element run results to a different natural account or activity, such as specifying a separate account for commission bonuses for a group of sales people.

When you create costing for elements, review the following points:

• Element eligibility records

• Costing type

• Offset account

• Priority account

Element Eligibility Records

If you plan to cost the run results for an element processed in a payroll run, you must specify at least one element eligibility record when you create the element. You do not need to specify element eligibility criteria, but you must create a name for the element eligibility record. Cost the element eligibility records for the element that includes the primary output value, either the base element or the results element.

When you cost the base or the related results element, cost all its element eligibility records, even if the costing is the same for all the eligibility records. If you do not cost all the eligibility records, the application costs only those entries that have eligibility records with costing information.

The element classification determines whether the costing results for the cost and offset accounts for the element eligibility record create credits or debits, and whether the application can include the element as a member of a distribution group.

Costing Type

The costing type determines whether the application should cost the payroll run results and distribute the cost over earnings elements. The costing type is also one factor in determining which levels of the cost hierarchy the application checks when building the account number for each segment.

• Costed: The application costs the run result value and checks for costing details at levels of the cost hierarchy based on the type of account. This account type is used most frequently for earnings elements.

• Distributed: The application costs and distributes the results over the elements included in a distribution group.

  You might select this option to spread employer charges, taxes, and liabilities over employee earnings.

• Fixed Costed: The application costs the payroll run result value but restricts the check for costing details to three levels of the cost hierarchy: element entry, element, and payroll levels.

  You might use fixed costing for deductions, which are commonly assigned at the payroll relationship level, and do not require cost overrides at other levels of the cost hierarchy. For example, if you have multiple companies for a ledger that use the same account structure, you might use fixed costing and record the company segment at the payroll level and the remaining segments for the cost account at the element level.

• Not Costed: Optionally, select this option to record your decision not to cost the run result value for this element. The application only costs elements with a costing type of Costed, Distributed, or Fixed Costing. You might specify this option for elements that do not affect net pay, such as absence accruals, information elements, and some taxable benefits where the amount the employee is taxed is not the employer's cost of providing the benefit.

Offset Accounts

The cost allocation key flexfield determines the segments available for entry for the offset account. You do not have to complete all the segments. If you leave a segment blank, the application builds the account information based on the corresponding segment entered for the cost account.

Distributed Costing

Distributed costing allocates costs for the payroll run result values of distributed elements over earnings elements. For example, the costs for employer taxes, charges, and liabilities are generally distributed over earnings elements such as wages, overtime, and shift pay.

Identify which elements have costs that you plan to distribute, and which earnings elements to include as members of the distribution group. You create distribution groups on the Manage Object Groups page. Create an object group of element group type, and distribution usage type, and select the elements to include in the group.

When payroll calculates the costs for the distributed element, the application allocates the costs based on the ratio that each element in the distribution group contributes to the total cost. The application creates the distributed cost entries for each earnings element in the distribution group, replacing the account numbers for the segments of the earnings elements with the account numbers for the corresponding segments defined for the distributed element.

Priority Accounts

Decide whether to use a Priority account as a separate cost account to ensure that all cost results for the element are allocated to one account and that no overrides occur at other levels of the cost hierarchy. You might choose this option if you fund a specific labor cost entirely or partially by one account.

For example, if a percentage of wages are funded by a matching grant, you might enter a cost account and a priority account. You would specify the percentage of the element that receives this funding and enter the priority account information, and then enter the appropriate segments for the cost account. The application would apply the specified percentage of the costs for the element's run results to the priority account and use the standard costing process to derive the cost account for the remaining percentage.

Payroll Cost Results: How They Are Calculated

The payroll application generates cost entries and journal entries for payroll run results and payments that you can transfer to subledger accounting and post to general ledger to record labor costs.

Settings That Affect Payroll Run Cost Results

Several settings affect how the application costs a payroll run result for a payroll relationship:

• Element classification costing options

  Costing options specified on the Manage Element Classifications page determine whether the application costs elements with a specified classification and whether the application creates the costing entries as credits or debits. The costing options on this page also determine if the application can include the elements with that classification in a distribution group.

• Cost allocations

  When setting up costing information, you can specify whether a cost is allocated to a single account or allocated across several accounts, in which case a costing entry is created for each account based on the percentage of the cost it should receive. For example, if you split the cost of a payroll run result value for an earnings element between two different cost centers, the costing process produces two cost entries and two offset entries.

  When the application calculates the costing results, if the total allocation does not equal 100 percent, the remaining allocation is placed in a default account. After you correct the costing setup, you can process a corrective action to cost the run result value to the appropriate account.

• Element's costing type

  The costing options on Manage Costing of Elements page specify the costing type and which element input values to cost. The costing types determines how the application costs the payroll run result value.

  • Not Costed: The application does not cost the run result value for this element.

    Enterprises use this option for absence accruals, information elements, and some taxable (imputed) benefits.

  • Costed: The application costs the run result value and checks for costing details at levels of the cost hierarchy based on the type of account.

  • Distributed: The application costs and distributes the results over the elements included a distribution group.

    Enterprises use distributed costing to spread employer charges, taxes, and liabilities over employee earnings.

  • Fixed Costed: The application costs the payroll run result value but restricts the check for costing details to three levels of the cost hierarchy: element entry, element, and payroll levels.

    Enterprises use fixed costing for deductions when they capture costing details only on the payroll and element levels of the cost hierarchy. For example, if the enterprise has multiple companies for a set of books and uses the same account structure for each corporation, the enterprise might use fixed costing and record the company segment at the payroll level and the remaining segments for the account that records the deduction at the element level.

• Type of account

  The type of account determines which levels the costing process checks when building the account number. The implementation determines which levels of the costing hierarchy can include costing details. When managing the costing setup information, you can review the combined information in tables accessible from the Context area of the Accounting Distribution work area list.

  • Cost accounts: The application checks all levels of the costing hierarchy for costing details. Segments entered at each level depend on which levels the implementation restricts for entry.

  • Suspense and default accounts: The application checks the department and payroll levels of the costing hierarchy. You enter the entire number at either the department or payroll level depending on the implementation.

  • Priority accounts: The application checks the element eligibility level. If some of the segments are entered, the application completes the account number using the standard costing process. If the entire account number is entered, the application bypasses the standard costing process and uses only the priority account to cost the payroll run result value.

  • Offset number: The application checks the element eligibility level when generating the offsetting entry that balances the payroll run result values. The application completes any blank segments using the value for the same segment from the cost account.

    Enterprises might leave a segment blank when they have multiple legal entities or other levels within the organization that maintain separate balance sheets. Completing the account number by inserting the remaining values for the segments from the cost account ensures, that the appropriate segment for the company or ledger is entered in the offset account and avoids additional setup time.

How the Costing is Calculated

The different costing processes generate costing entries for payroll run results or payments generated at the payroll relationship level, and offset entries to balance those entries. For example, when calculating the payroll, the application costs a salary run result value as a debit to an expense account and offsets the same amount as a credit to a payroll liability account. When costing a cleared payment, the application costs a payment as a debit to a clearing account and offsets the same amount as a credit to a cash account.

The application calculates the costing result for a payroll run result value and a payment value in different ways. When building the cost account for:

• Payroll run results: The application checks the costing hierarchy levels.

  The type of account, costing type, costing allocation, and implementation determine which levels of the costing hierarchy the application checks. The application builds the account number segment by segment, starting with the lowest and most detailed level (element entry) and checking each subsequent level to the highest and most general level (payroll) until it locates a number for a segment of the account number. The application repeats this process for each segment until the entire number is built.

  For example, to build the number for a cost center segment, the application starts with the element entry level. If it does not find a number for the cost center segment at that level, it continues up the hierarchy. If it finds a cost center number at the job level, it uses that number and does not use the one at the next higher level, the department level. When building the account number, the costing process uses the account information effective for the date earned of the payroll run.

• Payment results: The application uses the account number for the payment source as specified on the Manage Payment Source page.

The application places invalid entries for costed payroll run result values and payments in a suspense account and incomplete entries in a default account. After editing the costing setup, you can process a corrective action to cost the entry to the appropriate account. The application offsets the original costing when the corrected account number is generated, which clears the suspense or default account.

This table lists the standard costing hierarchy levels checked when the application builds the account number for payroll run result values and where to manage these settings.

When building the account number for the payroll run result values for a retroactive pay element, the Recalculate Payroll for Retroactive Changes process checks for costing details as of the current payroll period and the original payroll period. This table lists the costing hierarchy levels checked when the application builds the account number for retroactive payroll run result values and where to manage these settings.

This table lists the payroll processes that generate costing entries and describes the calculations.

.

Distributed Payroll Costs: How They Are Calculated

Distributed costing allocates costs for the payroll run result values of distributed elements over earnings elements. For example, the costs for employer taxes, charges, and liabilities are generally distributed over earnings elements such as wages, overtime, and shift pay.

Settings That Affect Distributed Payroll Costs

Several settings control how the costs for an earnings element are calculated:

• Element classification of the distributed element

  The element classification determines whether you can include an element in a distribution group and whether its cost result generates a debit or credit entry. For example, deductions reduce the net pay which generates a credit entry.

• The distribution group for the distributed element specified on the Manage Costing of Element page

  The application allocates the costing result of a distributed element over the costed run result values for the elements included in the distribution group. The distribution is based on the ratio each element contributes to the total for the distribution group.

• The primary output value specified on the Manage Costing of Element page

  The application uses the primary output value as the input value when calculating the cost for the distributed element.

How Distributed Payroll Costs Are Calculated

The application allocates the cost for the distributed element's run result value over the costed run result values for the elements in the distribution group. The application allocates the cost proportionately based on the amount each element contributes to the total for the distribution group. Only elements in the distribution group that produce actual run result values have costs distributed over them.

This distribution maintains the ratio that each element's costed run result value contributes to the total for the distribution group. For example, if a salary element contributes 70 percent of the total costed run results for the distribution group, the overtime contributes 20 percent, and the commission 10 percent, the application allocates 70 percent of the employer liability to the salary, 20 percent to the overtime, and 10 percent to the commission. If the distribution group does not include a run result value for the commission, then the application distributes the liability cost over the two remaining elements proportionate to the amount each contributes to the total.

If none of the earnings elements produce actual results, the application enters the costing result for the distributed element in a suspense account.

The application creates cost and offset entries for distributed elements. The distribution depends on how you set up costing for the distributed element on the Manage Costing of Element page. If you:

• Set up element eligibility costing for the distributed element, the application adds the costing result proportionately to the elements in the distribution group using the standard costing hierarchy, except when it reaches the element eligibility level, the application replaces the cost flexfield segments of the elements in the distribution group with the segments specified for the distributed element.

  For example, if the costing result for the overtime wage is costed to account 50.053.5130, and the account number for the distributed element is 5220, then the amount of the distributed element allocated to the overtime wage is costed to account 50.053.5220.

• Did not setup element eligibility costing for the distributed element, the application adds the costing result proportionately to the elements in the distribution group using the standard costing hierarchy.

  For example, if the costing result for the overtime wage is costed to account 50.053.5130, then the amount of the distributed element allocated to the overtime wage is also costed to account 50.053.5130.

Example

In the following example, the distributed element is the employer pension tax and the distribution group consists of the costed run result values for the regular and overtime wages for Departments 120 and 053.

This table lists the liability and expense accounts used in the example.

This table shows the primary output values calculated for the employee's regular and overtime pay while working for two different departments.

The employer and employee each contribute a rate of 6.2 percent of the employee's gross pay to the pension fund. In this example, the elements in the distribution group constitute the gross pay. The total for the elements in the distribution group is 490 USD. The employee and employer each pay 6.2 percent of the gross pay, or 30.38 USD. The employer's share is distributed over the elements in the distribution group.

This table shows the percentage of the distributed element allocated to each department based on the amount each element contributes to the total for the distribution group.

This table shows the costing entries calculated for the distributed element.

Define Payroll Flow Patterns

Payroll Flow Patterns: Explained

A payroll flow pattern consists of a sequence of tasks, which represent the tasks you complete in each phase of the payroll cycle. You can use the predefined flow patterns or create new ones for tasks you normally perform during a payroll period.

When you create a flow pattern, you can:

• Include predefined tasks

• Rename tasks and reorder the task sequence

• Specify flow parameters that a person enters when submitting a flow

• Specify optional information, such as duration dates, notifications, task and flow ownership

The task pane of the payroll work areas include a task to submit a flow pattern. Submitting a flow pattern generates a payroll flow, which you can monitor from the Payroll Dashboard, and with a payroll checklist that lists the tasks on a single page, so that you can easily monitor, perform, and reassign the tasks to someone else.

Include Predefined Tasks

Predefined tasks are the building blocks of flow patterns. Predefined tasks are associated to an activity, which corresponds to a phase of the payroll cycle, and optionally to a task group within the activity.

All payroll flow patterns begin with a start task and conclude with an end task. Flow patterns can include:

• A single task

  The predefined tasks that form the building blocks of composite flows consist of single tasks that you can submit as standalone flows. You submit report and process single task flows using the Submit Report or Process Flow task in the navigation tree from the Payroll Checklist work area or the work area that corresponds to the task's activity.

• Multiple tasks ordered in a sequence that corresponds to a phase of a typical payroll activity, such as the tasks involved in hiring someone or the tasks involved in paying people after running the payroll.

  You submit flow patterns consisting of multiple tasks using the Submit Payroll Flow task in the navigation tree from the Payroll Checklist work area or the work area that corresponds to the activities for tasks included in the flow.

This figure shows a payroll flow pattern for a single task.

This figure shows a payroll flow pattern of several tasks.

Task Action

Each payroll task has subordinate task actions. Task actions are based on the work the task performs and how it does this work within the application. They describe how the task is executed, such as submit, roll back, mark for retry, retry, and view. Each task action includes task parameters that control how the application processes a task and how the task relates to other tasks in the flow pattern. When you create a flow pattern, you can review the predefined task-action parameters and edit them, for example, to specify a different lookup value set.

This figure shows the relationship of a task to its subordinate task actions and their parameters.

Rename and Rearrange Task Sequence

You can rename tasks on the Tasks Sequence page and add descriptions to tasks to more clearly identify their use. For example, if you have a payments flow pattern that includes two payment processes, you might add a manual task after each payment task, rename these tasks and add descriptions to reflect the type of payment and validation to perform.

The sequence in which you initially select the tasks for your flow pattern on the Basic Information page determines the order in which you view the tasks on the Task Sequence page. You can rearrange the order on the Task Sequence page, as well as remove and add tasks. For example, you might remove a report task from the Calculations activity and add it to the Statutory activity.

Specify Flow Parameters

When you create a flow pattern, you specify flow parameters, the subset of input task parameters that a person submitting the flow enters and that the application uses to derive values needed to successfully complete the tasks included in the flow pattern.

Specify Optional Information

You can specify optional information for a flow pattern, including when a task starts or is due, and which types of notifications to send the task owner, such as overdue reminders, and error and warning messages.

You can restrict who can perform the tasks in it by designating owners for specific tasks. After you create a flow pattern, you can control access to it by creating a security profile and associating it to the appropriate data roles.

Payroll Flow Pattern Parameters: Explained

The payroll flow pattern parameters capture the information necessary to complete the tasks in the flow pattern. Tasks parameters determine how the application processes a task, and how the task relates to other tasks in the flow pattern. Flow parameters consist of a subset of the input task parameters that the person submitting the flow enters and that the application uses to derive values when processing the tasks in the flow pattern.

You can review and update the task and flow parameters for the flow patterns you create.

The following figure shows how the flow parameters are a subset of task-action parameters required to generate the entire payroll flow and complete the tasks successfully.

When you create a flow pattern, you review and update the parameters for the submission and initialization task actions. After you submit the flow pattern, you can edit the other task-action parameters, such as those for Mark for Retry, Retry, and Roll Back. The parameter details you can update include:

• Display and Display Format

• Lookups and Value Sets

• Usage

• Sequence

• Parameter Basis and Basis Value

Display and Display Format

Display parameters determine whether someone can view and enter parameters and the format for displaying them.

The Display option controls whether the person submitting a standalone task flow can enter the parameter, add it as a search criteria to a work area Overview page, or view it in the Parameters region of the payroll flow.

The Display Format option identifies the type of data displayed, such as a date or text, or choice list. The Display Format works in conjunction with other parameters such as the Parameter Basis and Basis Value, and the Lookup and Value Set details. For example, the Request parameter is not displayed because the application obtains it from the context.

Lookups and Value Sets

Use lookups and value sets to control and validate the data used in the payroll flow pattern. Specify lookups for parameters and value sets for descriptive flexfields.

The following table describes the type of methods used for lookups.

If you create value sets for descriptive flexfields to validate the values someone can enter for the parameter, you can specify that value set.

Usage

A parameter can receive information (input) or generate information (output) that subsequent tasks can use as input. For example, the Calculate Payroll Submit task action includes a Payroll Process parameter that generates an output value for the payroll action ID which is used as an input for the Calculate Payroll Retry task action.

Parameters that use the output of other tasks are not usually displayed in the UI. If the parameter is an output parameter, then the type of binding is Bind to Flow or null. If the binding is:

• Bind to Flow, the default value is picked up from the flow parameter and the output value is updated in the flow parameters table which is consumed as the flow's output. The parameter is not shown in the flow submission.

• Null, the value is the result of a task's output

Sequence

You can control the order in which the application processes and displays the parameters by specifying the sequence. Sequence numbers provide the application with the default logic to derive the parameter order in which to process the parameters. For example, if you have two lookups and the values of the second lookup depends on the value selected for the first lookup, the first lookup would have a lower sequence number than the second lookup. For example, in the Calculate Payroll task, the lookup for the Payroll parameter would have a lower sequence number than the lookup for the Payroll Period parameter, so that the values for the Payroll Period list the payroll periods defined for the selected payroll.

Parameter Basis and Basis Value

The Parameter Basis tells the application how to derive the value for the parameter and the Basis Value further specifies the value the application should use for the parameter.

The following table lists the Parameter Basis options and gives examples of when you might select them.

Payroll Flow Pattern Tasks Start and Due Dates: Critical Choices

You can specify the start and due date for any task in the flow pattern by selecting a duration date and further adjust the start or due date by entering an offset. The application then uses the resulting dates as a basis for sending notifications, such as overdue reminders. The list of values for the duration dates consists of the dates specified as flow level parameters, such as process date or date earned.

By specifying duration dates and notifications, you can ensure that task owners have adequate time to prepare material before the task starts or to address issues that arise before the task is due. Notifications with details about the task are sent by e-mail or to the worklist and are also displayed in the Payroll Dashboard.

Task Start and Due Dates

When a person submits a payroll flow, the payroll flow task begins after the completion of the previous task unless you schedule the task by entering a start date. The due date sets the date by which the task owner should complete the task.

You can control the start or due date by specifying:

• The flow parameter date to use as the basis for the duration date

  If you schedule a start date when the previous task concludes successfully, if the next task is an automatic task, the application waits to begin the task until the start date is reached. If the next task is a manual task, the task owner can wait or begin the task ahead of its scheduled start date.

• An offset to indicate the number of days from the flow parameter date that the duration date should occur

  You can specify a plus or minus value depending on whether you want the date to fall before or after the duration date.

Notifications

Select notifications to have the application send error and warning messages to the task owner, as well as notifications that a task has started or ended or is overdue.

The receipt of notifications about the start date or due date depends on the dates and their offsets. For example, if the process date is the date paid, you might specify an offset of 3 days in advance of the process date for the verification of the prepayment results to give the task owner adequate time to review the results and make any necessary corrections before generating the payments.

Handling Corrective Tasks in a Payroll Flow Pattern: Critical Choices

Most predefined process and report tasks support corrective task actions such as retrying or rolling back a task. Corrective payroll and payment tasks are usually submitted as separate flows. For example, the cancellation flow pattern includes tasks to view the person process results, void the payment, process an external payment to prevent reissue of the original payment, and reverse the original payroll run calculations to negate the run results.

Before adding a corrective task to your flow pattern, consider whether people working with a flow based on your pattern will correct errors by:

• Selecting task actions from the Actions menu at the task level or individual record level

• Submitting a flow pattern that combines corrective tasks

Using Corrective Task Actions in a Flow Pattern

You do not need to incorporate task actions for payroll and payment corrective tasks in your flow pattern, such as marking for retry, retrying, reversing, or rolling back processes and report results. Most tasks support these task actions at the task level or individual record level. The type of task and the status of the task and resulting records determine which actions you can select from the Actions menu on the View Person Process Results page or from the Payroll Checklist or Processes and Reports tab of the payroll flow.

The following figure shows the task actions such as Mark for Retry, Retry, and Roll Back that you can choose as task actions from the Actions menu when working on the Payroll Flow Checklist or the Processes and Reports tab of the payroll flow.

Corrective Flow Patterns

If you have sequential tasks you perform to correct a problem, you can create a flow pattern that consists of those tasks. For example, a flow pattern to reissue a lost check might include tasks to void the payment, issue an external payment, and view the person process results.

Payroll Flow Checklist and Flow Tasks: Explained

The payroll flow pattern determines the sequence of payroll flow tasks executed in a payroll flow. Submitting a payroll flow generates a payroll flow checklist.

You can manage a payroll flow by working in:

• The Payroll Checklist work area

• Other payroll work areas for the specific activity phase

Payroll Checklist Work Area

The payroll flow checklist contains the payroll flow tasks required to complete each activity phase of the payroll: preparation, calculation, payment distribution, accounting, and regulatory reporting.

A payroll flow task by default is associated to an activity, but it can recur in the same activity. For example, a payment distribution flow pattern might include a verification task after each type of payment, such as EFT payment and check payment.

The payroll flow checklist shows you the progression of the individual tasks that comprise the payroll flow. You can use the checklist to monitor the status of the payroll flow tasks and to manage the tasks. The checklist owner or flow task owner manages the flow tasks, for example, by reassigning tasks, revising due dates, marking tasks as complete, and performing actions the task supports, such as roll back and retry.

From the payroll checklist, you can navigate directly to the payroll flow task details. For example, you can navigate from the payroll calculation task directly to the Person Process Results page to view a list of workers processed in the payroll run.

Other Payroll Work Areas

While working with payroll flows, you can remain in the Payroll Checklist work area or navigate to the other payroll work areas to work on payroll flow tasks and access related payroll tasks.

The activities in the payroll flow checklist correspond to the individual payroll work areas. Each payroll work area includes additional tasks to manage the information processed for that phase of the payroll. For example, the Accounting work area includes tasks to view subledger journal entries and revise cost allocations, and the Payroll Calculation work area includes tasks to manage payroll relationship information.

Creating a Payroll Flow Pattern to Reissue a Check: Worked Example

This example demonstrates how to create a payroll flow pattern to issue a replacement check that an employee lost or did not receive.

The following table summarizes the key decisions for this scenario.

Create the Payroll Flow Pattern

1. In the Payroll Checklist work area, select the Manage Payroll Flow Patterns task from the task pane.
2. On the Manage Payroll Flow Patterns page, click the Create icon.
3. Select the legislative data group, and click Continue.
4. On the Create Payroll Flow Pattern: Basic Information page, complete the fields, as shown in this table.

   Region	Field	Value
   Basic Information	Flow Pattern	InFusion Reissue Check
   Activities	Activities to Include	Payment
   Tasks	Available Tasks	Void Payment, Generate Check Payments, Verify a Payment

   
   
5. Click Next.
6. On the Create Payroll Flow Pattern: Tasks page, select the Verify the Payment task.
7. In the Owner and Checklist region, click the Owner field.
8. Select an owner.
9. Click Next.
10. On the Create Flow Pattern: Tasks Sequence page, confirm the order in which the tasks occur: Verify a Payment, Void Payment, Generate Check Payment.
11. Correct the sequence of tasks, if necessary. Select the row, click the Edit icon, and select a different following task. Repeat this process for each task.
12. Click Next.
13. On the Create Payroll Flow Pattern: Flow Parameters page, click the Select and Add icon.
14. In the Select and Add window, select the parameters, as shown in this table.

    You can select multiple parameters from the Select and Add window.

    Field	Value
    Void Payment	Start Check Number, End Check Number, Process Configuration Group, Process Date, Payroll Process, Reason Note With the exception of the Reason parameter, these task parameters are used by the Generate Check Payment task. Add them only once as flow parameters to cover both tasks.
    Generate Check Payment	Payroll, Start Date, Consolidation Group, Organization Payment Method, Overriding Payment Date, Payment Source, Payment Type

    
    
15. Select the row for the Process Configuration Group flow parameter and click the Edit icon.
16. Edit the flow parameters as shown in this table:

    Field	Action
    Display	No
    Display Format	Text
    Lookups	blank
    Parameter Basis	Use Specified Value
    Basis Value	InFusion Process Configuration Group

    
    
17. Click Next to display the Create Payroll Flow Pattern: Task Parameters page.

    You do not need to edit the Process Configuration task parameter. The application uses the details specified for the flow parameter, not the details specified for the task parameter.

18. Click Next.
19. On the Create Payroll Flow Pattern: Review page, preview the resulting payroll checklist.
20. Click Submit.

Editing Payroll Flow Patterns: Points to Consider

The activities of a payroll cycle include predefined tasks that you can include or exclude to correspond to the way in which your enterprise typically processes payroll. When you create a payroll flow pattern or edit it later, you can revise the initial list of tasks. You can add and delete tasks, move them to a different activity, rename them, and edit their descriptions.

Editing Tasks

You can edit flow patterns you create, but not predefined flow patterns. While editing flow patterns, it is helpful to keep in mind the following points when you add, delete, or move a task.

• Add a task

  Adding a new task automatically places it at the end of the sequence of tasks for that task group or activity. Update the task sequence so that this task occurs in the order in which you want it processed.

• Repeat a task used previously

  When you repeat a task, the task name is the same. Rename it to more easily understand its purpose in the payroll checklist. For example, if different managers review report results, you might repeat a verification task and rename them to identify the type of report results the manager will review.

• Delete a task

  Deleting a task may impact tasks that depend on the results of the deleted task. Review the subsequent tasks to ensure, for example, that a task parameter is not Bind to Task with the deleted task specified as its Value.

• Move a task to a different activity

  The activity determines the availability of the flow from a work area. For example, if you move a reporting task from the Payments activity to the Statutory activity, the person working with the payroll flow can view the report results from the Checklist or Regulatory and Tax Reporting work area, but not the Payments work area.

Editing Payroll Flow Patterns: Examples

Use these scenarios to understand the types of updates you might make to a flow pattern.

Updating a Parameter to Use a Specified Value

The payrolls you run use a single Process Configuration Group. On the Parameter tab for the Calculate Payroll task, you can update the flow parameters to specify the name of that configuration group so that the person submitting the payroll flow does not have to complete that information but relies on the application to supply the value.

The following table lists the values to enter for the task parameter details for the Calculate Payroll task to enter a constant for the Process Configuration Group.

Supplying a Reason for a Corrective Action

You have decided to add the Reason parameter to one of your tasks to better track why managers submit standalone tasks during a payroll cycle.

The following table lists the values to enter for the task parameter details for the Calculate QuickPay task to enter a reason for processing the task.

After completing the task parameter information, you would add the Reason parameter as a flow parameter, so that the user completes the Reason when submitting the flow.

Adding Tasks and Reordering the Task Sequence

Your flow pattern includes payroll calculation reports. You decide that you need to run specific reports such as Gross-to-Net report before other reports such as the Element Register report and to validate the results of each report before the application runs the next report. You can rearrange the sequence of reporting tasks, add a manual verification task after each report, and rename the manual tasks to more clearly identify them, such as Verify Gross-to-Net Report and Verify Element Register Report.

Editing a Payroll Flow Pattern: Worked Example

This example demonstrates how to edit a QuickPay flow pattern that you have created so that a person whose role carries a specific level of authority reviews the prepayment results before the flow owner generates the payment.

The following table summarizes the key decisions for this scenario.

Prerequisites

1. Create a QuickPay flow pattern.
2. Include the same tasks and flow parameters as the predefined QuickPay flow pattern.

Specifying a Task Owner

1. In the Payroll Checklist work area, click the Manage Payroll Flow Patterns task from the task pane.
2. On the Manage Payroll Flow Patterns page, search for the QuickPay flow pattern that you created.
3. In the search results region, click the Edit icon on the row of your QuickPay flow pattern.
4. On the Tasks tab, select the Verify Prepayment Results task, and click the Edit Task icon.
5. On the Edit Task Details: Basic Information page, click Next.
6. On the Edit Task Details: Owner and Checklist page, select a role or a user name.
7. Click Next.
8. On the Edit Task Details: Duration and Notifications page, in the Duration region, complete the fields, as shown in this table.

   Field	Value
   Due Date	Process Date
   Offset	-1

   
   
9. In the Notifications region, complete the fields, as shown in this table.

   Field	Value
   Flow Task Start Notification	Yes
   Overdue Notification	Yes

   
   
10. Click Submit to submit your changes, and to return to the Manage Payroll Flow Patterns page.
11. On the Manage Payroll Flow Patterns page, click Submit.

FAQs for Manage Payroll Flow Patterns

Can I edit a locked flow pattern?

You cannot edit predefined single or composite flow patterns, but you can edit payroll flow patterns that you create. For example, if all your payrolls reference the same legislative data group, you could edit the legislative data group flow parameter for your payroll cycle flow, and select the Parameter Basis as Use Specified Value, the Display Format as text, and then enter the name of the legislative data group for the Basis Value.

Can I skip the flow parameters for a single-task payroll flow pattern?

No, you must specify the flow parameters required to successfully complete the task. You can also include optional parameters that the person submitting the flow enters, or that the application can derive from the information entered for the required parameters.

How can I rearrange tasks in a flow pattern?

Edit the task sequence by selecting a different task in the Following Task column. Every payroll flow pattern begins with a Start Flow task, which does not belong to an Activity or Task Group. The payroll flow concludes with the End Flow task, which is listed for the last task in the Following Tasks column.

The sequence in which you select the tasks for a flow pattern on the Create Flow Pattern: Basic Information page determines the order of the tasks displayed on the Task Sequence page. Edit this task list on the Task Sequence page by selecting a different following task for the task you want to reposition. Confirm the order of the tasks on the Review page before submitting the flow pattern.

What happens if I don't enter a task owner in a payroll flow pattern?

The person who submits the payroll flow becomes the payroll flow owner and the task owner. The person's security privileges determine whether the person can submit the payroll flow.

When do I enter a destination for a payroll flow task?

Enter a destination URL for a task when the task type is the application interface, such as the batch loader, or user interface, such as a page in the user interface where the task owner views process and report results.

Why did the payroll flow pattern duration dates not display?

The payroll flow pattern duration dates for the start and due dates are based on the flow parameter dates. Enter the flow parameters and then navigate back to the Tasks page to enter the duration dates and the offsets for those dates.

If your flow pattern does not specify dates as flow parameters, the duration list of values is blank.

Previous Next

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

Contents Contact Us