Tuesday, 6 January 2026

HDL for Global Transfers in Oracle Fusion HCM – Complete Technical Walkthrough

HDL for Global Transfers: Technical Walkthrough

Description

Learn how to perform Global Transfers using Oracle Fusion HCM HDL with the WorkRelationship data model. This technical walkthrough explains required objects, effective dating, HDL structure, common errors, and best practices.

Introduction

A Global Transfer in Oracle Fusion HCM occurs when an employee moves from one legal employer to another while retaining the same person record. From an HDL perspective, global transfers are one of the most complex Core HR transactions due to effective dating, object relationships, and sequencing rules.

With the current HCM data model, Global Transfers are handled using WorkRelationship , WorkTerms and Assignment

This blog provides a step-by-step technical walkthrough of handling Global Transfers using HCM Data Loader (HDL) based on the correct object structure.

Global Transfer – Correct Data Model Structure

Visual Diagram – Before vs After Global Transfer

BEFORE Global Transfer

Worker (PersonNumber: E1001)
 └─ WorkRelationship (India Legal Employer)
     └─ WorkTerms
         └─ Assignment (Primary)

AFTER Global Transfer

Worker (PersonNumber: E1001)
 ├─ WorkRelationship (India Legal Employer) → End-dated
 │   └─ WorkTerms
 │       └─ Assignment (End-dated)
 │
 └─ WorkRelationship (US Legal Employer)
     └─ WorkTerms
         └─ Assignment (Primary)

This visual clearly shows that during a Global Transfer:

The Person record remains unchanged
A new WorkRelationship is created for the new Legal Employer
WorkTerms and Assignment are never reused across Legal Employers


Worker (same PersonNumber)
 ├─ WorkRelationship (Old Legal Employer) → End-dated
 └─ WorkRelationship (New Legal Employer)
     └─ WorkTerms
         └─ Assignment

Key HDL Objects Involved

To process a Global Transfer using HDL, the following objects are required:

Worker
WorkRelationship (End-date old)
WorkRelationship (Create new)
WorkTerms (Create new)
Assignment (Create new)

⚠️ WorkTerms and Assignments cannot be reused across Legal Employers.

Important Pre-Requisites

Before loading HDL:

New Legal Employer must exist
Business Unit must be correctly mapped
Job, Position, Grade, Location must be valid for the new LE
SourceSystemOwner must remain consistent

Effective Dating Rules for Global Transfers

Follow these critical rules:

New WorkRelationship start date = Global transfer date
Old WorkRelationship end date = Day before new WorkRelationship start date
WorkTerms start date = New WorkRelationship start date
Assignment start date = WorkTerms start date

Violating these rules will cause HDL failures.

HDL Load Sequencing (Mandatory)

Load HDL files in this exact order:

Worker.dat (MERGE – optional updates)
WorkRelationship.dat (End-date old WR)
WorkRelationship.dat (Create new WR)
WorkTerms.dat (Create new WT)
Assignment.dat (Create new Assignment)

Common HDL Errors and Fixes

❌ Assignment Exists Under Old Legal Employer

Error:

Assignment already exists

Fix:

Do not reuse old AssignmentNumber
Create a new Assignment under the new WorkRelationship

❌ Effective Date Validation Error

Error:

Effective start date must be on or after WorkRelationship start date

Fix:

Align WorkRelationship, WorkTerms, and Assignment start dates

❌ Missing WorkRelationship

Error:

No WorkRelationship exists

Fix:

Ensure new WorkRelationship load completed successfully

Post-Load Validation Checklist

After HDL load:

Verify old WorkRelationship is end-dated
Confirm new Legal Employer on WorkRelationship
Validate WorkTerms and Assignment details
Check Person Management UI

Best Practices for Global Transfers via HDL

Always test in lower environments
Use incremental loads only
Keep separate HDL files per object
Maintain clear SourceSystemId strategy
Capture ESS Request IDs

Real Project Scenario

Scenario: Employee transferred from India LE to US LE

Approach:

End-date India WorkRelationship on 31-Mar
Create US WorkRelationship on 01-Apr
Create WorkTerms and Assignment under US LE

Result: Clean Global Transfer without data corruption.

Conclusion

Global Transfers using HDL require precise control over WorkRelationship, WorkTerms, and Assignment objects, along with strict effective dating and sequencing. When executed correctly, HDL provides a reliable and auditable way to manage cross–legal employer movements.

This knowledge is a key differentiator for senior Fusion HCM Technical Consultants.

How to Roll Back a Failed HDL Load Safely in Oracle Fusion HCM – Best Practices & Scenarios

How to Roll Back a Failed HDL Load Safely

Description

Learn how to safely roll back a failed HDL load in Oracle Fusion HCM. This blog explains rollback strategies, corrective approaches, common mistakes, and best practices for Fusion HCM technical consultants.

Introduction

Failures during HCM Data Loader (HDL) runs are common in Oracle Fusion HCM projects. However, HDL does not provide a one-click rollback option like traditional database transactions.

This makes it critical for Fusion HCM Technical Consultants to understand safe rollback and recovery strategies after a failed HDL load.

This blog explains:

What rollback means in HDL
Safe ways to reverse or correct failed loads
Real project scenarios and best practices

Understanding HDL Load Behaviour

Before discussing rollback, it is important to understand how HDL works.

Key Characteristics of HDL

HDL commits data object by object, not as a single transaction
Partial data may be loaded even if the job fails
Parent records may succeed while child records fail

⚠️ This is why careful rollback planning is essential.

Common HDL Failure Scenarios

Worker created but Assignment failed
Assignment loaded with wrong effective date
Duplicate records due to incorrect operation type
Invalid SourceSystemOwner or lookup values

Each scenario requires a different rollback approach.

What “Rollback” Means in HDL

In Fusion HCM HDL, rollback usually means:

Correcting incorrect data
Reversing records using effective dating
Deleting test or invalid records (when allowed)
Rollback Provided for limited objects like Element Entry.

It rarely means a full data wipe.

Safe Rollback Strategies in HDL

1️⃣ Correct-and-Reprocess (Most Recommended)

When to Use

Partial load success
Data exists but contains errors

Approach

Fix incorrect HDL data
Use MERGE operation
Re-load only failed or incorrect records

Example

Correcting assignment effective start date and reloading Assignment.dat.

2️⃣ End-Date Incorrect Records

When to Use

Data loaded with wrong effective dates
Historical correction required

Approach

End-date incorrect records
Reload correct data with new effective dates

This approach maintains audit history.

3️⃣ Delete Records (Use with Extreme Caution)

When to Use

Test data in lower environments
Duplicate or invalid records created

Approach

Use HDL DELETE operation (only where supported)
Validate object supports deletion

⚠️ Avoid DELETE in Production unless approved.

4️⃣ Full Reload After Environment Refresh

When to Use

Massive data corruption
Implementation or test environments

Approach

Refresh environment
Perform controlled Full Load

Not recommended for Production environments.

HDL Rollback Decision Flow

HDL Rollback Flow

What NOT to Do During Rollback

❌ Do not reload the same file blindly
❌ Do not switch CREATE to MERGE without analysis
❌ Do not perform Full Load for small issues
❌ Do not delete Production data casually

Best Practices for Safe HDL Rollback

Always capture Request IDs
Keep HDL files version-controlled
Use incremental loads wherever possible
Validate data using reports before and after reload
Test rollback strategy in lower PODs

Real Project Rollback Example

Scenario: Assignment load failed due to incorrect effective date

Solution:

Identify failed records from .out file
Correct effective dates
Reload Assignment.dat using MERGE
Validate using Person Management UI

Preventing Rollback Situations

Validate HDL files before load
Use smaller file batches
Perform dry-run validation in lower environments
Follow strict SourceSystemOwner governance

Conclusion

Rollback in HDL is about controlled correction, not reversal. A well-planned recovery strategy ensures data integrity while minimizing business impact.

Understanding rollback techniques is a key skill that differentiates a confident Fusion HCM Technical Consultant from an average one.

Troubleshooting Oracle Fusion HCM HDL Load Failures Using ESS Logs – A Step-by-Step Guide

Troubleshooting HDL Load Failures Using ESS Logs

Description

Learn how to troubleshoot Oracle Fusion HCM HDL load failures using ESS logs. This guide explains ESS job flow, key log files, common errors, and practical debugging techniques for Fusion HCM technical consultants.

Introduction

HCM Data Loader (HDL) issues are common in Oracle Fusion HCM projects, especially during data migration, integrations, and post–go-live support. Most HDL failures can be diagnosed effectively by understanding ESS jobs and log files.

This blog provides a practical, step-by-step approach to troubleshooting HDL load failures using ESS logs, based on real implementation and support experience.

Understanding the HDL ESS Job Flow

When an HDL load is submitted, Fusion HCM internally runs multiple ESS jobs. Understanding this sequence is the first step in troubleshooting.

Typical HDL Job Flow

Load HCM Data (Parent ESS Job)
Import and Load Data
HCM Data Loader
Object-specific processing jobs (Worker, Assignment, etc.)

⚠️ Even if the parent job shows Succeeded, child jobs may still have errors.

Where to Find ESS Logs

Navigation Path

Tools → Scheduled Processes → Search → Enter Request ID

Click on the job and navigate to:

Log Files
Output Files

These files are the primary sources for HDL troubleshooting.

Key HDL Log and Output Files Explained

1️⃣ .log File

Technical execution details
Object processing sequence
Database-level validations
Best for identifying root cause

2️⃣ .out File

Business-friendly error messages
Validation and data issues
Often references line numbers from HDL files

3️⃣ .err File (if generated)

Summarized critical errors
Usually points to blocking failures

Step-by-Step HDL Troubleshooting Approach

Step 1: Check ESS Job Status

Identify whether failure occurred at parent or child job level
Drill down to the lowest failed child job

Step 2: Review the .out File First

Look for messages like:

Record rejected
Invalid value
Effective date error

Example:

No Assignment record exists from 2018-10-27

This usually indicates data or effective dating issues.

Step 3: Analyze the .log File for Root Cause

Search keywords:

ERROR
SEVERE
ORA-

The .log file explains why the system rejected the record.

Step 4: Validate HDL File Data

Check for:

Correct object sequencing
SourceSystemOwner consistency
Effective start and end dates
Operation type (CREATE vs MERGE)

Step 5: Correct and Reload

Fix only failed records where possible
Use MERGE to avoid duplicates
Re-run HDL with corrected files

Common HDL Errors and Log Indicators

❌ Missing Assignment Record

Log Indicator:

No Assignment record exists

Fix:

Ensure Assignment exists for the effective date

❌ Source System Owner Errors

Log Indicator:

SourceSystemOwner is invalid

Fix:

Validate lookup under HRC_SOURCE_SYSTEM_OWNER

❌ Effective Date Validation Errors

Log Indicator:

Effective start date must be on or after Period of Service start date

Fix:

Align Worker, PeriodOfService, and Assignment dates

❌ Duplicate Records

Log Indicator:

Duplicate record found

Fix:

Use MERGE instead of CREATE
Verify SourceSystemId uniqueness

Best Practices for HDL Troubleshooting

Always start with the .out file, then deep dive into .log
Track Request IDs for every HDL load
Maintain a common HDL error resolution document
Test fixes in lower environments
Avoid Full Loads for minor corrections

Pro Tips from Real Projects

One ESS job can generate multiple log files—check all
Do not trust parent job status alone
HDL errors are mostly data-related, not system bugs
Keep HDL files small for faster troubleshooting

Incremental vs Full Loads in HDL – When and Why

Incremental vs Full Loads in Oracle Fusion HCM HDL – When to Use Which and Why

Description

Understand the difference between Incremental and Full Loads in Oracle Fusion HCM HDL. Learn when to use each approach, with real project scenarios, best practices, and common pitfalls.

Introduction

Oracle Fusion HCM Data Loader (HDL) supports two primary data loading strategies: Incremental Loads and Full Loads. Choosing the wrong approach can lead to data corruption, missing records, or unnecessary rework.

This blog explains what incremental and full loads are, how they work in HDL, and when you should use each, based on real-world Fusion HCM implementation and support scenarios.

What Is a Full Load in HDL?

A Full Load means loading the entire dataset for an object, regardless of whether the data already exists in Fusion HCM.

Key Characteristics

Loads all records (existing + new)
Often uses CREATE or MERGE operations
Commonly used during initial data migration
Higher processing time and system impact

Example Scenarios

Initial employee migration during implementation
POD refresh followed by complete data reload
Rebuilding corrupted or missing data

Sample Use Case

Loading all employees, assignments, jobs, and positions into a new Fusion environment before go-live.

What Is an Incremental Load in HDL?

An Incremental Load updates or inserts only changed or new records since the last successful load.

Key Characteristics

Loads delta data only
Typically uses MERGE operation
Faster execution
Lower risk when handled correctly

Example Scenarios

Daily employee hires, updates, or terminations
Compensation changes
Assignment changes

Key Differences: Incremental vs Full Load

When Should You Use a Full Load?

Use Full Load when:

Performing initial data migration
Reloading data after environment refresh
Correcting major data inconsistencies
Migrating large master data like jobs, grades, or positions

⚠️ Caution

Full loads can:

Overwrite data unintentionally
Impact system performance
Cause duplicate or effective-dating issues

Always test in a lower environment first.

When Should You Use Incremental Load?

Use Incremental Load when:

Making day-to-day HR updates
Loading new hires or assignment changes
Updating compensation or manager changes
Handling regular integrations from source systems

Best Practice

Track changes using Last Updated Date from source systems
Maintain strict SourceSystemOwner consistency

Common Mistakes to Avoid

❌ Using Full Load for Daily Updates

This increases risk and processing time.

❌ Incorrect Operation Type

Using CREATE instead of MERGE can cause duplicate records.

❌ Poor Effective Date Management

Misaligned dates can lead to missing assignment or period of service errors.

Best Practices for HDL Load Strategy

Use Full Load only when absolutely necessary
Default to Incremental Loads for production support
Validate effective dates before every load
Maintain a load control and audit mechanism
Review HDL .log and .out files after each run

Real Project Recommendation

Implementation Phase: Full Load
Post Go-Live: Incremental Load only
Post Refresh: Full Load (selective objects)

This hybrid approach minimizes risk and ensures data integrity.

Conclusion

Understanding when to use Incremental vs Full Loads in HDL is critical for a successful Fusion HCM implementation and support model. The right strategy improves performance, reduces errors, and protects production data.

A disciplined approach to HDL loading separates an average consultant from a strong Fusion HCM Technical expert.

Monday, 5 January 2026

Error during Balance Adjustment HDL load

Error Message1 : You Must submit an entry value for input value amount.

Solution: Input Value amount is blank.

Error Message2 : A Previous Process that was run for this payroll relationship couldn't be complete or marked to be run again.

Solution: Please check whether any process or flow has errored out for the person in Person Results.

Thursday, 1 January 2026

Common Errors During Worker HDL Load in Oracle Fusion HCM (With Solutions)

Loading worker data using HDL (HCM Data Loader) in Oracle Fusion HCM is powerful—but even small configuration or data issues can cause errors that block the load process.

In this blog, we’ll cover 10 common Worker HDL load errors, explain why they occur, and provide clear, step-by-step solutions to resolve them quickly.

1️⃣ Error: You Must a Primary Value

🔍 Cause

The system requires a primary work term for the worker, but it is missing.

✅ Solution

Add the PrimaryWorkTermsFlag attribute in the WorkTerms metadata and set it to Y.

Tip:
Each worker must have exactly one primary work term.

2️⃣ Error: Person can have only 1 active Primary WorkRelationship

🔍 Cause

The worker already has an active primary work relationship, and a new one is being created.

✅ Solution

Update the termination date of the previously terminated work relationship to ensure only one active primary work relationship exists.

3️⃣ Error: SourceSystemOwner is unknown

🔍 Cause

The SourceSystemOwner value in the HDL file does not match the lookup configuration.

✅ Solution

Navigate to Setup & Maintenance
Search for Manage Common Lookups
Open lookup type HRC_SOURCE_SYSTEM_OWNER
Remove FUSION from the custom lookup code
Update the same value in the Worker.dat (or relevant HDL file)
Zip and reload the file via
My Client Groups → Data Exchange → Import and Load Data
Refresh and verify successful completion

4️⃣ Error:

JBO-FND:::FND_FLEX_SEG_VAL_NOT_IN_LIST: xxx is not in the list

🔍 Cause

The Site Code linked to the Position is invalid or expired.

✅ Solution

Remove the end date for the Site Code
OR
Extend the end date for the Site Code

After correction, reload the Worker HDL file.

5️⃣ Error: You must enter a valid value for the GradeId field

🔍 Cause

An invalid or missing grade is passed for a position-based assignment.

✅ Solution (Choose one):

Provide the correct GradeId or GradeCode
Pass #NULL (with PER_ENFORCE_VALID_GRADE = Y)
Set PER_ENFORCE_VALID_GRADE = N to skip grade validation

📌 After loading, run the ESS job:
Synchronize Person Assignment from Position

This syncs grade, job, and other position attributes.

6️⃣ Error: The values xxxx aren't valid for the attribute LegislationCode

🔍 Cause

The Legal Entity registration setup is incomplete or duplicated.

✅ Solution

Go to Setup & Maintenance
Navigate to Legal Structures
Open Manage Legal Reporting Unit Registrations
Assign a unique Registration Number
Save and reload the Worker HDL file

7️⃣ Error:

METADATA line for the {BO_NAME} business object is invalid
(While loading Person Extra Information)

🔍 Cause

Outdated Worker HDL template or missing EFF attributes.

✅ Solution

Refresh the Worker HDL object
Download the latest Worker template
Update the file with:
- PEI EFF
- EFF_CATEGORY_CODE
- FLEX attributes
Follow Oracle documentation for Extensible Flexfields
Zip and reload via Import and Load Data

8️⃣ Error:

You cannot update this record because the SourceSystemId and SourceSystemOwner are invalid
(Assignment Supervisor)

🔍 Cause

Mismatch between source keys and Fusion surrogate keys.

✅ Solution (Best Options):

Remove SourceSystemId/Owner and use Fusion surrogate or user keys
Ensure parent and child objects use the same key type
For integrations:
- Update mappings using HRC_INTEGRATION_KEY_MAP
- Load mappings via SourceKeys.dat
- Reload AssignmentSupervisor data

9️⃣ Error:

You must provide only one parent record Worker and it must start on the earliest effective start date

🔍 Cause

Incorrect Worker effective dates or duplicate Worker records.

✅ Solution

Ensure StartDate = EffectiveStartDate
Match the earliest date from PER_ALL_PEOPLE_F
If creating only a new assignment or work relationship:
- Remove METADATA Worker
- Remove MERGE Worker records

🔟 Error: No Assignment record from 2018-10-27

🔍 Cause

Assignment data is missing from the Worker HDL file for the specified effective date.

✅ Solution

Add the Assignment record in Worker.dat starting from 2018-10-27, then reload the file.

✅ Best Practices for Worker HDL Loads

Always use the latest HDL templates
Validate effective dates carefully
Avoid mixing Fusion surrogate keys and source keys
Run required ESS jobs after position-based updates
Test loads in DEV or TEST before PROD

🔚 Conclusion

Worker HDL errors in Oracle Fusion HCM are common—but most are caused by data inconsistencies, configuration gaps, or outdated templates. Understanding these errors and applying the correct solution can save hours of troubleshooting and ensure smooth data loads.

💬 Have questions or faced a different error?
Drop them in the comments—I’ll help you troubleshoot.

Not Able to End Date Person Contact Relationship Using HDL in Oracle Fusion HCM

Overview

While working with HCM Data Loader (HDL) in Oracle Fusion HCM, you may encounter a scenario where you try to end date a Person Contact Relationship using HDL—but the load fails or does not behave as expected.

This blog explains why end dating a Person Contact Relationship is not possible using HDL, and what the supported workaround is.

Problem Description

You are attempting to end date an existing Person Contact Relationship (such as Emergency Contact, Spouse, or Dependent) using HDL.

Despite providing correct effective dates in the HDL file, the relationship does not get end dated, or the load results in an error.

Why This Happens

Oracle Fusion HCM does not support end dating Person Contact Relationships through HDL.

This is a product limitation, not a data issue or configuration problem. The HDL framework currently allows you to:

Create Person Contact Relationships
Delete Person Contact Relationships

But it does not allow updating or end dating existing contact relationships.

Resolution / Supported Approach

✅ Delete the Person Contact Relationship Using HDL

Since end dating is not supported, the only available option is to delete the Person Contact Relationship using HDL.

When the contact relationship is no longer required:

Identify the relationship record
Use a DELETE operation in the HDL file
Load the file using standard HDL steps

This approach fully removes the relationship from the system.

Important Notes

HDL cannot update or end date Person Contact Relationships
This limitation applies across all environments (DEV, TEST, PROD)
Functional UI may still allow updates depending on the relationship type
Always validate business impact before deleting relationships

Best Practices

Confirm with functional teams before deleting contact relationships
Maintain backup of original HDL files
Test DELETE operations in lower environments
Document deleted relationships for audit purposes

Alternative Options

If end dating is required for reporting or compliance:

Consider managing the relationship manually through the Fusion UI (if supported)
Evaluate custom reporting logic to handle deleted relationships
Log the change history externally if required

Conclusion

If you are not able to end date a Person Contact Relationship using HDL, it is due to an Oracle-supported limitation. The only supported workaround is to delete the relationship using HDL.

Understanding such limitations helps avoid unnecessary troubleshooting and ensures your data loads remain compliant with Oracle Fusion HCM standards.

💬 Have you faced similar HDL limitations or different contact-related errors? Share your experience in the comments.