End-to-End Guide to Enterprise Shifts, Work Pattern Types and Work Pattern Template Rules in Oracle HCM

Excerpt:
This article demonstrates how to configure Enterprise Shifts, Work Pattern Types, Work Pattern Templates, and Template Rules in Oracle HCM Cloud. Using a practical example, we assign a work pattern at the Legal Employer level while excluding workers with manual exceptions, and explain how the Process Events job evaluates and applies these rules.

Oracle HCM Cloud Workforce Scheduling provides a structured way to standardize employee schedules across large populations. Instead of assigning schedules manually, organizations can define reusable components and automate assignment using rules.

This blog walks through an end-to-end configuration using:

• Enterprise Shifts
• Work Pattern Types
• Work Pattern Templates
• Work Pattern Template Rules at the Legal Employer level
• Process Events job

Business Requirement

All employees under a specific Legal Employer should receive a standard work pattern:

• 08:00 AM to 05:00 PM - 60 mins unpaid break

However, employees with manual scheduling exceptions must be excluded. For example, employees manually assigned to 01:00 PM to 10:00 PM - 60 mins unpaid break should not be overwritten by the rule-based assignment.

Step 1: Create Enterprise Shifts

Enterprise Shifts act as reusable building blocks for scheduling.

Navigation
My Client Groups > Workforce Scheduling > Shifts
Click the Add button.

Configuration Field	1st Shift	2nd Shift
Shift Name	08:00 AM to 05:00 PM - 60 mins unpaid break	01:00 PM to 10:00 PM - 60 mins unpaid break
Duration	8	8
Work Minutes	0	0
Start Time	08:00 AM	01:00 PM
End Time	05:00 PM	10:00 PM
Unpaid Break Duration	60 Minutes	60 Minutes

Key Insight

• 9-hour span
• 8 paid hours after break deduction

Step 2: Create Work Pattern Types

Work Pattern Types define how shifts are structured.

Navigation
Setup and Maintenance > Workforce Scheduling > Work Pattern Types

Configuration Field	Values for the 1st Work Pattern	Values for the 2nd Work Pattern
Shift Period Type	Start and end times	Start and end times
Name	08:00 AM to 05:00 PM - 60 mins unpaid break	01:00 PM to 10:00 PM - 60 mins unpaid break
Country	United States	United States
Status	Active	Active
Break Name	60 mins unpaid break	60 mins unpaid break
Break Duration	60 Minutes	60 Minutes
Break Type	Any time during shift	Any time during shift
Nature of Break	Unpaid	Unpaid

Because this setup uses exact start and end times, a start/end-based work pattern type is the right choice.

Step 3: Create Work Pattern Templates

Templates define recurring schedules that can be assigned to groups.

Navigation
My Client Groups > Workforce Scheduling > Work Pattern Templates

a) Template Name: 08:00 AM to 05:00 PM - 60 mins unpaid break

Work Pattern Type: Fixed Start-End Pattern
Cycle Length: 1 Week

Day	Shift
Monday	08:00 AM to 05:00 PM - 60 mins unpaid break
Tuesday	08:00 AM to 05:00 PM - 60 mins unpaid break
Wednesday	08:00 AM to 05:00 PM - 60 mins unpaid break
Thursday	08:00 AM to 05:00 PM - 60 mins unpaid break
Friday	08:00 AM to 05:00 PM - 60 mins unpaid break
Saturday	Off
Sunday	Off

b) Template Name: 01:00 PM to 10:00 PM - 60 mins unpaid break

Work Pattern Type: Fixed Start-End Pattern
Cycle Length: 1 Week

Day	Shift
Monday	01:00 PM to 10:00 PM - 60 mins unpaid break
Tuesday	01:00 PM to 10:00 PM - 60 mins unpaid break
Wednesday	01:00 PM to 10:00 PM - 60 mins unpaid break
Thursday	01:00 PM to 10:00 PM - 60 mins unpaid break
Friday	01:00 PM to 10:00 PM - 60 mins unpaid break
Saturday	Off
Sunday	Off

Step 4: Define Work Pattern Template Rule

This is where automation happens.

We will create the work pattern template rule for 08:00 AM to 05:00 PM - 60 mins unpaid break.

Navigation
My Client Groups > Workforce Scheduling > Work Pattern Templates > Assign

Example Rule Logic

Include Criteria

• Legal Employer = ABC Corporation
• Oracle Work Pattern Source <> 'Manually Assigned'

This rule ensures that all eligible workers under the legal employer receive the standard day pattern, while workers already maintained manually are excluded from automated reassignment.

Step 5: Run Process Events

This is the critical activation step.

Navigation
Tools > Scheduled Processes

Process Name: Process Events

Parameters

• Effective Date: 3/18/2026
• Events to Process: Workforce Scheduling

The log files provide details about how many employees were processed and how the rule evaluation was applied.

How Process Events Works

Think of Process Events as the engine that applies your Workforce Scheduling rules.

What it does

1. Detects HCM changes, such as new hires, transfers, legal employer changes, and assignment updates.
2. Evaluates template rules by checking legal employer eligibility and excluding manually assigned work patterns.
3. Generates scheduling assignments by assigning the template to eligible workers and skipping excluded workers.

Currently, Oracle supports multiple Workforce Scheduling events, and Process Events is the process that reacts to those changes and applies the configured logic.

End-to-End Flow Summary

1. Create shift → 08:00 AM to 05:00 PM
2. Create pattern type → Start-End based
3. Create template → Weekly recurring schedule
4. Define rule → Legal Employer based
5. Run Process Events → Apply logic

Testing the Solution

Scenario 1: New Hire

• Legal Employer = ABC
• No manual exception
• Run Process Events
• Expected: Template assigned

Insert screenshot: After new hire

Scenario 2: Position Change and Missing Work Pattern

• Legal Employer = ABC
• Manual Exception = No
• Run Process Events
• Expected: Template assigned

Insert screenshot: Before Position Change

Insert screenshot: After Position Change and running Process Events

Scenario 3: Position Change and Manually Assigned

• Legal Employer = ABC
• Manual Exception = Yes
• Run Process Events
• Expected: No assignment

Insert screenshot: Before Position Change

Insert screenshot: After Position Change and running Process Events

Scenario 4: Job Change and Existing Work Pattern

• Legal Employer = ABC
• Manual Exception = Yes
• Run Process Events
• Expected: No work pattern change

Insert screenshot: Before the position change

Insert screenshot: After Position Change and running Process Events

Troubleshooting

Issue: Template not applied

• Verify rule criteria.
• Check worker attributes.
• Run Process Events.

Issue: New hires not assigned pattern

• Ensure Process Events is scheduled regularly, such as daily or hourly.

Final Thoughts

A well-designed Workforce Scheduling setup in Oracle HCM Cloud should use Enterprise Shifts as reusable units, Templates for scalability, Rules for automation, and Process Events for execution.

In this example, applying scheduling at the Legal Employer level with controlled exclusions ensures both standardization across the workforce and flexibility for exceptions.

Author Note

This blog reflects a practical implementation pattern for Workforce Scheduling in Oracle HCM Cloud. Always validate configurations in your own environment and align rule design with your organization's data governance strategy.

Use Case: Managing Different Public Holiday Schedules for Different Segments of the Workforce

Use Case: Managing Different Public Holiday Schedules for Different Segments of the Workforce

Organizations with diverse operational models often require different public holiday schedules for different segments of the workforce. For example, corporate office employees may observe the full set of public holidays, while manufacturing facilities may operate on reduced holiday schedules to maintain production continuity.

Oracle Fusion Cloud HCM 25D Organization Calendar Events enables organizations to manage holidays and organizational events centrally through configurable calendars. However, when implementing this feature for different worker populations, it is important to understand the current design constraints of the feature.

This use case illustrates how an organization can configure separate public holiday calendars for US manufacturing and US non-manufacturing employees. :contentReference[oaicite:0]{index=0}

---

Business Requirement

A company operates multiple work locations across the United States with two major workforce populations:

1. Non-Manufacturing Employees

• Corporate offices
• Administrative staff
• Sales and support teams

2. Manufacturing Employees

• Factory workers
• Production teams
• Plant operations staff

The organization follows a standard US public holiday calendar for most employees. However, manufacturing plants operate on a modified holiday schedule due to production requirements.

Non-Manufacturing Employees

Corporate employees observe the full US public holiday schedule:

• New Year’s Day (1/1/2026)
• MLK Day (1/19/2026)
• Presidents’ Day (2/26/2026)
• Memorial Day (5/25/2026)
• Juneteenth (6/19/2026)
• Independence Day (7/4/2026)
• Labor Day (9/7/2026)
• Veterans Day (11/11/2026)
• Thanksgiving Day (11/26/2026)
• Christmas Day (12/25/2026)
• Winter Break 1 (12/26/2026)
• Winter Break 2 (12/27/2026)
• Winter Break 3 (12/28/2026)
• Winter Break 4 (12/29/2026)
• Winter Break 5 (12/30/2026)
• Winter Break 6 (12/31/2026)

Manufacturing Employees

Manufacturing plants observe only a subset of these holidays:

• New Year’s Day (1/1/2026)
• MLK Day (1/19/2026)
• Presidents’ Day (2/26/2026)
• Memorial Day (5/25/2026)
• Juneteenth (6/19/2026)
• Independence Day (7/4/2026)
• Labor Day (9/7/2026)
• Veterans Day (11/11/2026)
• Thanksgiving Day (11/26/2026)
• Christmas Day (12/25/2026)

Winter Break holidays (12/26/2026 – 12/31/2026) are not observed because the plant continues production during those periods.

The organization therefore requires:

• A US Corporate Holiday Calendar for non-manufacturing employees
• A US Manufacturing Holiday Calendar for plant employees

---

Configuration Approach

To implement this requirement using Organization Calendar Events, the organization configures:

1. Define Organization Calendar Events
2. Create Separate Organization Calendars
3. Create Calendar Rules
4. Assign Calendars to Workers

---

Step 1: Define Organization Calendar Events

First, administrators define the public holiday events that will be used across calendars.

Examples include:

• New Year’s Day
• MLK Day

Navigation:

Setup and Maintenance → Calendar Events

Create all 16 calendar events as defined earlier.

Important Note:

If you do not see the Redwood page for Calendar Events, enable the following profile option:

ORA_ANC_VBCS_ORG_CAL_EVENT_ENABLED = Y

Navigation:

Setup and Maintenance → Manage Administrator Profile Values

---

Step 2: Create Separate Holiday Calendars

US Non-Manufacturing Holiday Calendar

This calendar contains the full set of US public holidays observed by corporate employees.

It is assigned to workers in corporate offices and administrative roles through the work location.

US Manufacturing Holiday Calendar

This calendar contains only the holidays applicable to plant operations.

It excludes holidays during which manufacturing plants remain operational.

For example, events such as Winter Break 1 to 6 are omitted.

---

Step 3: Create Calendar Rules

Calendars are assigned to workers using Calendar Rules.

Worker Population	Assigned Calendar
US Corporate Employees	US Non-Manufacturing Holiday Calendar
Manufacturing Plant Employees	US Manufacturing Holiday Calendar

One or more calendar rules can be created using person and assignment attributes.

Once assigned, workers inherit the events defined in their respective calendar.

---

Step 4: Assign Calendars to Workers

To ensure that the correct workers are assigned to the appropriate calendars, Oracle Fusion uses the Evaluate Group Membership scheduled process.

This process evaluates the rules associated with each calendar and updates the membership of the underlying HCM Groups.

Because worker eligibility may change due to updates in calendar attributes, the process must run regularly.

It is recommended to schedule the process to run as frequently as worker data changes within the organization.

Scheduling the Evaluate Group Membership Process

Navigation:

Tools → Scheduled Processes

Steps:

1. Click Schedule New Process
2. Search for Evaluate Group Membership
3. Schedule it to run periodically

Running a Targeted Refresh for Calendar Rules

If administrators need to refresh membership for a specific calendar rule:

• Enter the specific rule name
• Or search using:

%ANC_CALENDAR_RULES

This lists all calendar rules associated with Organization Calendar Events.

---

Important Note About Calendar HCM Groups

The HCM Groups used by Organization Calendar Events are maintained internally by the application.

Because of this:

• These groups cannot be viewed or edited directly from the Define HCM Groups page
• Membership is controlled automatically by the Evaluate Group Membership process

You can query the membership using SQL:

select 
per.person_number,
ppn.last_name,
ppn.first_name,
grp.group_name,
mem.effective_start_date,
mem.effective_end_date
from hwm_grp_members_f mem,
hwm_grps_vl grp,
per_all_people_f per,
per_person_names_f ppn
where grp.grp_id = mem.grp_id
and per.person_id = mem.member_id
and per.person_id = ppn.person_id
and ppn.name_type = 'GLOBAL'
and trunc(sysdate) between mem.effective_start_date and mem.effective_end_date
and trunc(sysdate) between ppn.effective_start_date and ppn.effective_end_date
and trunc(sysdate) between per.effective_start_date and per.effective_end_date

---

Testing the Solution

Corporate employees follow the full US public holiday calendar including winter break holidays.

Manufacturing employees follow the plant-specific holiday calendar without winter break holidays.

---

Business Benefits

• Maintain Production Continuity
  Manufacturing plants can operate during certain holidays without impacting corporate scheduling.
• Provide Accurate Workforce Scheduling
  The scheduling engine automatically respects the correct holiday calendar for each worker.
• Reduce Administrative Effort
  Holiday schedules are managed centrally instead of being manually applied by managers.

---

Summary

The Organization Calendar Events feature in Oracle Fusion Cloud HCM 25D provides a centralized way to manage holidays and organizational events across different workforce populations.

In this case:

• Corporate employees follow a US Non-Manufacturing Holiday Calendar
• Manufacturing employees follow a US Manufacturing Holiday Calendar

Although the feature enables flexible calendar definitions, organizations must design implementations carefully due to the current limitation that calendars can only be defined using Geography or Organization hierarchies.

With proper configuration, the feature provides a scalable solution for managing holiday schedules across diverse operational environments.

How to Restrict Global Assignment EFF Values by Employee Legislation in Oracle Fusion HCM

In global Oracle Fusion HCM implementations, one of the more common configuration challenges is supporting local business requirements without fragmenting the overall design. A field may be global in nature, but the values available for that field often need to vary by country or legislation.

A typical example is a custom field on the Global Assignment Extensible Flexfield (EFF). The business may want one common field for all employees, but the list of available values should differ depending on whether the worker belongs to the US, India, Canada, Great Britain, or another legislation.

The good news is that Oracle Fusion HCM supports this requirement quite elegantly through configuration. By combining a custom lookup, a table-validated value set, and a Global Assignment EFF segment, you can create a clean, scalable, and metadata-driven solution.

In this article, I’ll walk through a practical design pattern for restricting Assignment EFF values based on employee legislation.

Business Requirement

Let’s assume the business wants to add a custom Assignment EFF field called Eligibility Type. This field should behave differently depending on the employee’s legislation.

For example:

• an employee with India legislation should see values relevant to India
• an employee with Great Britain legislation should see UK-specific values
• an employee with US legislation should see US-specific values
• some values should remain available to all employees regardless of country

This is a common global design problem: one field, different valid values by legislation.

Instead of creating separate fields or separate contexts by country, we can keep the design centralized and let the value filtering happen dynamically at runtime.

Solution Overview

The solution has three building blocks:

1. create a custom lookup type to store all possible values
2. create a table-validated value set that filters those values based on legislation
3. assign that value set to a Global Assignment EFF segment

The key idea is straightforward: all possible values are maintained in a single lookup, and the Tag field is used to identify country applicability. The value set then reads those values and decides which ones should be displayed based on the employee’s legislation code.

This approach keeps the design simple, maintainable, and easy to extend later.

Step 1: Create a Custom Lookup Type

The first step is to create a custom lookup that will act as the source for the field values.

Navigation
Setup and Maintenance → Manage Common Lookups

Create the following lookup type:

Field	Value
Lookup Type	XX_CUSTOM_ELIGIBILITY
Meaning	XX_CUSTOM_ELIGIBILITY
Description	XX_CUSTOM_ELIGIBILITY
Module	Global Human Resources

Once the lookup type is created, add the lookup codes that will represent the values shown in the EFF.

Sample Lookup Codes

Lookup Code	Meaning	Start Date	Tag
GRND_FATHER	Grandfathered in	1/1/1951	+IN
HAZARD_ALLOWANCE	Hazard Allowance	1/1/1951	+GB
ONCALL	On Call	1/1/1951	+US,+CA,+IN
STIPEND_INCENTIVE	Stipend Incentive	1/1/1951	(blank)

Using the Tag Column to Drive Legislation Logic

The Tag column is central to this pattern.

In this configuration:

• +IN means the value is available only for India
• +GB means the value is available only for Great Britain
• +US,+CA,+IN means the value is available for multiple legislations
• a blank tag means the value is available globally

This gives you a very practical mechanism for managing legislation-specific behavior without overcomplicating the EFF structure itself.

It also makes future maintenance easier. If the business wants to add a new value or expand eligibility to another legislation, the update can often be handled directly in the lookup.

Step 2: Create a Table-Validated Value Set

The next step is to create a value set that reads the lookup values and filters them using the legislation code of the employee.

Navigation
Setup and Maintenance → Manage Value Sets

Create the value set with the following definition:

Field	Value
Value Set Code	XX_CUSTOM_ELIGIBILITY_VS
Description	XX_CUSTOM_ELIGIBILITY_VS
Module	Global Human Resources
Validation Type	Table
Value Data Type	Character

Table Validation Details

Field	Value
From Clause	fnd_lookup_values
Value Column Name	meaning
Description Column Name	meaning
ID Column Name	meaning

Where Clause

LOOKUP_TYPE = 'XX_CUSTOM_ELIGIBILITY'
AND (
  DECODE(
    TAG,
    NULL, 'Y',
    DECODE(
      SUBSTR(TAG,1,1),
      '+', DECODE(SIGN(INSTR(TAG, :{PARAMETER.LEGISLATION_CODE_VALUE})), 1, 'Y', 'N'),
      '-', DECODE(SIGN(INSTR(TAG, :{PARAMETER.LEGISLATION_CODE_VALUE})), 1, 'N', 'Y'),
      'Y'
    )
  ) = 'Y'
)
AND LANGUAGE = 'US'

This is the heart of the solution.

How the Value Set Logic Works

At runtime, the value set checks the TAG value for each lookup row.

The logic works like this:

• if the TAG is null, the value is treated as global and shown to everyone
• if the TAG starts with +, the value is shown only if the employee’s legislation code exists in the tag
• if the TAG starts with -, the value is hidden if the employee’s legislation code exists in the tag

This creates a flexible filtering mechanism while keeping the actual list of values centrally managed.

From a design perspective, this is a strong pattern because it separates value maintenance in the lookup, filtering logic in the value set, and user entry in the EFF.

Step 3: Create the Global Assignment EFF Context and Segment

Once the lookup and value set are ready, the next step is to create the Global Assignment EFF segment that uses this value set.

Navigation
Setup and Maintenance → Manage Extensible Flexfields

Search for the Assignment Extensible Flexfield and create a new context and segment.

High-Level Steps

1. open the Assignment EFF
2. create a new context
3. add a new segment
4. assign the value set XX_CUSTOM_ELIGIBILITY_VS
5. save and deploy the flexfield

The segment should be a character-based field configured to display as a list of values.

Important Detail: Legislation Code Parameter

The most important part of this configuration is the parameter referenced in the value set:

:{PARAMETER.LEGISLATION_CODE_VALUE}

This parameter must receive the employee’s legislation code at runtime. That is what enables the value set to determine which rows should be displayed.

If this parameter is not mapped correctly, the LOV may not behave as expected. In most cases, the issue will show up as one of the following:

• all values are displayed
• no values are displayed
• values appear inconsistently for different employees

Because of that, parameter mapping is usually the first thing to verify during testing.

Testing the Configuration

Once the EFF is deployed, test the setup with employees from different legislations.

Based on the sample configuration above, the expected results are:

Employee Legislation	Values Displayed
US	On Call, Stipend Incentive
IN	Grandfathered in, On Call, Stipend Incentive
CA	On Call, Stipend Incentive
GB	Hazard Allowance, Stipend Incentive

This confirms that the same field can support different value sets depending on employee context, without requiring country-specific duplication in the flexfield design.

US Employee

India Employee

Canada Employee

GB Employee - redwood UI

Why This Design Works Well

What makes this approach especially useful in global implementations is its balance between flexibility and simplicity.

Rather than designing multiple country-specific fields or managing complex configurations in several places, you keep the setup centralized:

• the lookup stores all available values
• the Tag defines country applicability
• the value set handles runtime filtering
• the EFF consumes the filtered result

This makes the solution easier to maintain, easier to explain, and easier to extend over time.

It also aligns well with a broader Oracle HCM design principle: whenever possible, solve requirements through configurable metadata rather than proliferating structures.

Final Thoughts

For global Oracle Fusion HCM implementations, legislation-sensitive value restriction is a requirement that comes up often. The combination of a custom lookup, country-tagged values, a table-validated value set, and a Global Assignment EFF provides a neat and reusable way to address it.

It keeps the configuration centralized, supports local variation, and avoids unnecessary duplication in your flexfield design.

If you are working on a global HCM rollout and need different LOV values for the same field across legislations, this is a pattern well worth keeping in your implementation toolkit.

Key Takeaways

• a single Assignment EFF field can support different values by legislation
• the lookup Tag column is a simple way to define country applicability
• a table-validated value set can dynamically filter values at runtime
• this pattern is scalable, maintainable, and well suited for global HCM implementations

How to Configure Context-Sensitive Descriptive Flexfields (DFF) for Absence Types in Oracle Fusion HCM

Introduction

Organizations frequently need to capture different information depending on the absence type selected by an employee.

Absence Type	Additional Information Required
Paid Time Off	Paid Time Off Attribute
Sick Leave	Sick Leave Attribute

Instead of customizing the application, Oracle Fusion Absence Management provides this capability through Context-Sensitive Descriptive Flexfields (DFF). This configuration allows the system to automatically display relevant fields depending on the selected absence type.

Solution Overview

This solution uses the Absence Recording Descriptive Flexfield (DFF) available in Oracle Fusion Absence Management.

1. Access the Absence Recording DFF
2. Configure the Context
3. Create contexts and context sensitive segments
4. Deploy the flexfield

(1) Access the Absence Recording DFF

Navigate to:

Setup and Maintenance → Manage Descriptive Flexfields

Search for Absence Recording DFF and click the Edit icon.

Step 2 – Configure the Context

Parameter	Value
Default Type	Parameter
Default Value	Absence Type
Derivation Value	Absence Type
Display Type	Hidden

This ensures the context is automatically derived from the absence type.

Step 3 – Define Context and Context Sensitive Segments

Create Contexts for Each Absence Type

Next, click the Manage Contexts button to view existing contexts or create new ones.

On the Manage Contexts page, click the “+” (Add) icon to create a new context.

When creating a context:

• You can enter any value for the Display Name

• The Context Code must be the absence_type_id

The system uses this value to determine which set of fields should be displayed for the selected absence type.

Retrieve the Absence Type ID

To obtain the absence_type_id, run the following SQL query:

SELECT *
FROM ANC_ABSENCE_TYPES_F_TL
WHERE language = 'US'
AND name IN ('Paid Time Off','Sick Leave');

This query retrieves the IDs for the required absence types. Use the corresponding absence_type_id as the Context Code when creating the context.

Once the context is created, you can define context-specific segments that should appear when that absence type is selected.

Paid Time Off

• Paid Time Off Attribute

Let's define another context and related segments

Sick Leave

• Sick Leave Attribute

Step 4 – Deploy the Flexfield

Save the configuration and click Deploy Flexfield. Ensure deployment status shows successful compilation.

Testing the Configuration

Navigate to:

My Client Groups → Absence → Absences and Entitlements

Create a new absence request and verify the fields appear dynamically based on absence type.

Best Practices

• Use Global Segments only for fields applicable to all absence types
• Ensure context code matches absence_type_id
• Keep Context Segment hidden
• Always deploy flexfields after configuration

Conclusion

Using Context-Sensitive Descriptive Flexfields in Oracle Fusion Absence Management, organizations can dynamically capture absence-specific information without customization. This improves data accuracy, user experience, and system flexibility.

Oracle Cloud Payroll - US Retiree Payroll Configuration

US RETIREE PAYROLL IN ORACLE CLOUD HCM — MUST-DO CONFIGURATION

This article is designed to help Oracle Cloud HCM practitioners implement US retiree payroll in a clean, auditable way. It focuses on practical configuration choices, common setup gaps, and testable outcomes—so teams can enable learning, reduce rework, and deliver reliable payroll operations.

This checklist is based on hands-on implementation patterns and guidance from Oracle documentation/support material, including:

• Oracle Support Document ID 2461709.1 — “Oracle Fusion Human Capital Management for RETIREES US: Implementation and Use (v1.9)”

• Oracle Cloud Human Capital Management for the United States: How do I perform tax filing through a third-party? KB160976

• Audience: Payroll implementers, HCM functional consultants, payroll admins supporting US retiree pay

• Scope: US retirees paid via Oracle Cloud Payroll (commonly pension/annuity payments; often reported via 1099-R depending on your program design)

————————————————————————————————————

Retiree payroll has a few “small” setup decisions that create big downstream impact: tax card creation, TRU/PSU structure, registrations, reporting card associations, and address quality. If you get right early, year-end, reconciliation, and ongoing maintenance become predictable.

————————————————————————————————————

SECTION A — FOUNDATION (NON-NEGOTIABLE)

If you are already payroll customer running employee's payroll then this would be already configured.

A1) Set the United States Selected Extension correctly

• Confirm your US “Selected Extension” setting aligns with how you plan to process retirees (HR-only vs payroll-enabled configuration).

A2) Address Validation + geographies maintenance (strongly recommended)

• Enable Address Validation (if your governance permits).
• Establish an operational cadence to refresh geographies (as applicable).

————————————————————————————————————

SECTION B — ORG STRUCTURE (BUILD RETIREE BOUNDARIES EARLY)

B1) Separate retiree PSUs from employee PSUs (recommended baseline)

• Create retiree Payroll Statutory Units (PSUs) separately from employee PSUs where your business/legal reporting model supports it.

B2) Create retiree TRUs separately; lock down distribution code governance

• Create retiree TRUs separately from employee TRUs.

• If your program requires different 1099-R distribution codes, segment TRUs accordingly.

• Governance rule: do not change TRU’s 1099-R distribution code after creation—create a new TRU if the code changes.

        Manage LRU HCM Information => Enter the distribution code

————————————————————————————————————

SECTION C — TAX REGISTRATIONS (REQUIRED FOR STABLE PAYROLL PROCESSES)

This configuration is same as your regular employee(Non-Retiree) payroll configuration.

C1) US Federal registration at LRU level (FEIN)

• Create the US Federal Tax registration at the LRU level.
• Enter the Employer FEIN.

C2) State registrations (as applicable)

• Populate state registrations for jurisdictions where you withhold/report, based on your compliance model and filing responsibilities.

————————————————————————————————————

SECTION D — TRU CALCULATION RULES (PUT WITHHOLDING LOGIC IN THE RIGHT PLACE)

This configuration is same as your regular employee(Non-Retiree) payroll configuration.

D1) Create TRU calculation rules card

Create “Calculation Rules for Tax Reporting and Payroll Statutory Unit” at the TRU level.

D2) Flat-rate override governance (if your retiree program uses it)

Recommended override priority (high → low)
1. Retiree person tax card overrides
2. TRU-level overrides
3. Tax engine defaults

Note –

Retiree payments that are subject to 1099-R rules are not subject to SUI, SDI, FLI, Social Security, or Medicare taxes. Therefore, the payroll process does not calculate them.

————————————————————————————————————

SECTION E — CONSOLIDATION GROUP AND PAYROLL GROUP

E1) It would be better to create separate consolidation group and payroll definition for retiree payroll processing

————————————————————————————————————

SECTION F — RETIREE TAX CARDS (ENSURE THEY AUTO-CREATE AND STAY CORRECT)

F1) Confirm the retiree tax card model

• Validate the retiree tax card behavior for your program (commonly “Tax Withholding for Pensions and Annuities”).

F2) Validate auto-creation is working (don’t assume)

F3) State-tax edge case validation

When you onboard or convert employee to retiree; you will see below calculation created and TRU association created auto

————————————————————————————————————

SECTION G — REPORTING INFORMATION CARD (OFTEN MISSED, HIGH IMPACT)

G1) Confirm TRU components are associated to the correct assignment

• Validate that Reporting Information Card components created per TRU are correctly associated to the retiree assignment number—especially when multiple TRUs exist.

————————————————————————————————————

SECTION H — RETIREE ASSIGNMENT (MINIMUM REQUIRED FIELDS)

This data point is same as your regular employee(non-retiree) payroll data point.

H1) Retiree must have a payroll-eligible assignment

• Payroll relationships are assigned
• Ensure retiree assignment is Active and Payroll Eligible

————————————————————————————————————

SECTION I — HOME ADDRESS, LOCATION AND WFH FLAG FOR RETIREES (WHAT IT MEANS IN ORACLE)

Key point (clear definition)

Retirees aren’t “working,” but Oracle still requires a Work Location on the retiree assignment. For WFH/Remote retirees, treat Work Location as a required data field for consistency and reporting—not as a local tax driver.

I1) All Retirees must have valid US Home Address for payroll processing. Retirees can have overseas mailing address for communication.

I2) Create a dedicated retiree remote location and assign it to all retirees and check 'Work From Home' flag for them.

————————————————————————————————————

SECTION J — PAYMENTS (DIRECT DEPOSIT MUST BE OPERATIONALLY SUPPORTED)

This data point is same as your regular employee(Non-Retiree) payroll data point.

J1) Run prerequisite process for new retirees

• Run “Maintain Party and Location Current Record” before entering personal payment methods (for newly onboarded retirees).

J2) Enter payment methods

• Use “Manage Personal Payment Methods” to add direct deposit details.

————————————————————————————————————

SECTION K — KNOWN CONSTRAINTS (DESIGN AROUND THEM EARLY)

• Local taxes for retirees may not be supported in retiree processing models; plan your retiree withholding accordingly.
• Involuntary deductions may not be supported for retiree processing; define an alternative approach if required.
• Confirm territory/jurisdiction scope early if you have retirees outside standard US states.

————————————————————————————————————

Finally Let's add earning elements and run QuickPay to see the results

————————————————————————————————————

Disclaimer: 

The checklist provided here focuses on foundational setup patterns and common “must-do” configurations for US retiree processing in Oracle Cloud HCM. Actual implementations can vary by retiree plan design, bargaining agreements, legal/tax requirements, and reporting needs. Most projects also require additional configuration, including elements and balance definitions, fast formulas, eligibility, costing rules, payroll calendars, retro and correction processes, and integrations with third-party or downstream systems (e.g., tax services, payment files, benefits providers, and financial/GL systems) to deliver end-to-end processing and statutory reporting.