Monday, 12 January 2026

HDL Template for Dependent Enrollment in Oracle Fusion HCM (DependentEnrollment.dat)

(Using DependentEnrollment.dat)

Introduction

In Oracle Fusion HCM, Dependent Enrollment is a critical step in Benefits processing when employees opt for Spouse, Child, or Family coverage. Dependents must be correctly created, linked, and enrolled for benefits eligibility and premium calculation.

Oracle provides HCM Data Loader (HDL) to bulk load dependent enrollments efficiently using the DependentEnrollment.dat file.

This blog explains a complete end-to-end process for loading Dependent Benefit Enrollments with a working HDL template, prerequisites, common issues, and validation steps.

When to Use DependentEnrollment.dat

Use DependentEnrollment.dat when:

Enrolling Spouse or Child under an employee’s benefit plan
Processing Family or Dependent coverage
Loading dependents during New Hire or Open Enrollment
Migrating benefit enrollments from a legacy system
Performing mass updates for dependent benefits

Prerequisites

Before loading dependent enrollments, ensure the following data is already available in Fusion HCM:

Employee Prerequisites

Employee record exists and is active
PersonNumber is valid
Employee is already enrolled in a Benefit Program
Life Event (New Hire / Open Enrollment / Marriage) is processed or available
Load the Particiapant Enrollment using ParticipantEnrollment.dat. Click Here for more details.

Dependent Prerequisites

Dependent person record exists
Dependent is linked to employee via Contact.dat
Dependent Date of Birth (DOB) is populated
Relationship type (Spouse, Child, etc.) is valid and effective

Benefits Configuration

Benefit Program, Plan, and Option are configured
Plan allows dependent coverage
Eligibility Profiles include dependents
Coverage values are correctly defined

Date & Security

Effective Date aligns with life event window
User has HCM Data Loader and Benefits access

File Name


DependentEnrollment.dat

HDL File Structure Overview

The file typically includes:

DependentEnrollment – Links dependent to the employee’s benefit plan

Section: DependentEnrollment

Purpose

This section enrolls a dependent under an employee’s selected benefit plan and option.

Metadata Definition


METADATA|DependentEnrollment|PersonNumber|BenefitRelationship|
EffectiveDate|LifeEvent|LifeEventOccuredDate

Sample Data


MERGE|DependentEnrollment|7628|DFLT|2026/01/12|New Hire|2026/01/1

🔹 Important: Plan and Option must exactly match Fusion setup.

Complete Sample DependentEnrollment.dat File


METADATA|DesignateDependent|Plan|Program|Option|DependentPersonNumber|
LineNumber|PersonNumber|DependentLastName|DependentFirstName|
OriginalEnrollmentDate

Sample Data

MERGE|DesignateDependent|Medical PPO|Choice Program (Core)|
Participant Plus One|7629|1|7628|XXTEST|Reena|2026/01/12

HDL Load Steps

Navigate to Data Exchange → HCM Data Loader
Upload DependentEnrollment.dat
Submit the process
Monitor HDL stages until status shows Succeeded

Validation After Load

After the load completes:

Navigate to Benefit Administration
Search for the employee
Verify:
- Dependent appears under selected plan
- Coverage reflects dependent inclusion
- Effective dates are correct

Common Errors & Troubleshooting

Dependent HDL Error

Best Practices

Always load Person and ContactRelationship before DependentEnrollment
Validate dependent DOB and relationship types
Keep Effective Dates aligned with life events
Test loads in lower environments before PROD
Use exact Plan and Option names

Conclusion

Dependent enrollment is a crucial part of Benefits administration in Oracle Fusion HCM. Using DependentEnrollment.dat through HDL ensures accurate, scalable, and efficient processing of dependent benefit enrollments.

By following this end-to-end approach, you can avoid common issues and confidently manage dependent coverage during New Hire, Open Enrollment, and life event scenarios.

The values {attributes} are not valid for the attribute BankAccountId

Error While Loading PersonalPaymentMethod Using HCM Data Loader

Introduction

Oracle Fusion HCM HCM Data Loader (HDL) is commonly used to load payroll-related data such as Personal Payment Methods. However, while loading PersonalPaymentMethod.dat, you may encounter validation errors related to bank account resolution.

One of the most common errors is:

HRC-1035539 – The values {attributes} are not valid for the attribute BankAccountId

This blog explains why this error occurs, the root causes, and multiple solutions to fix it using real project scenarios.

Cause Analysis

Cause 1: Missing BankAccountType

Consider a scenario where two bank accounts exist for the same person:

Bank Account 1 → No BankAccountType
Bank Account 2 → Has BankAccountType

In this case:

If you refer to Bank Account 1, HDL can resolve it without BankAccountType
If you refer to Bank Account 2, BankAccountType becomes mandatory

❗ If the existing ExternalBankAccount has a value for BankAccountType, it must be provided in PersonalPaymentMethod.dat.

Cause 2: Invalid Bank Account Attribute Combination

The system is unable to identify a valid BankAccountId because the values provided for:

BankName
BankCountryCode
BankAccountNumber
BankAccountType
BankBranchName
BankBranchNumber

do not match any existing External Bank Account in Oracle Fusion.

Solution 1: Provide BankAccountType When Required

If the External Bank Account already has a BankAccountType, then it must be passed in PersonalPaymentMethod.dat.

Best Practice

✔ Always provide BankAccountType when multiple bank accounts exist
✔ Ensure the value exactly matches what exists in Fusion

This ensures unique resolution of ExternalBankAccount.

Solution 2: Validate Bank Account Details in Fusion

Ensure that the following attributes in PersonalPaymentMethod.dat match an existing bank account:

Bank Name
Bank Country Code
Bank Account Number
Bank Account Type
Bank Branch Name
Bank Branch Number

If any of these values are incorrect, Fusion will fail to resolve the BankAccountId.

Query to Validate Bank Account Data

Use the below SQL query to verify whether the bank account exists and matches the provided details:


SELECT
    ppr.payroll_relationship_id payrollrelationshipid,
    ppr.person_id personid,
    h.party_id partyid,
    eba.bank_account_id bankaccountid,
    eba.bank_account_num bankaccountnumber,
    eba.bank_id bankid,
    eba.bank_name bankname,
    eba.bank_number banknumber,
    eba.branch_number branchnumber,
    eba.branch_id branchid,
    eba.bank_branch_name branchname,
    eba.eft_swift_code eftswiftcode,
    eba.bank_home_country homecountry,
    eba.bank_account_type bankaccounttype
FROM
    pay_bank_accounts eba,
    iby_account_owners ebao,
    hz_parties h,
    pay_pay_relationships_dn ppr,
    per_persons p,
    hz_orig_sys_references hosp
WHERE
    eba.bank_account_id = ebao.ext_bank_account_id
    AND ebao.account_owner_party_id = h.party_id
    AND hosp.owner_table_id = h.party_id
    AND hosp.orig_system_reference = TO_CHAR(ppr.person_id)
    AND hosp.owner_table_name = 'HZ_PARTIES'
    AND hosp.orig_system = 'FUSION_HCM'
    AND ppr.person_id = p.person_id
    AND h.status = 'A'
    AND eba.bank_account_num = <enter bank account num>
    AND eba.bank_name = <enter Bank Name>
    AND eba.bank_branch_name = <bank branch name>;

🔎 Replace data with values from your PersonalPaymentMethod.dat file.

Final Root Causes Summary

Cause 1

BankAccountType not provided even though it exists in the system

Cause 2

No matching BankAccountId exists for the provided bank details

Conclusion

The error occurs when Oracle Fusion HCM cannot uniquely identify the External Bank Account for a Personal Payment Method. By ensuring accurate bank details and providing BankAccountType when required, this issue can be resolved effectively.

This approach is widely used in payroll implementations and data migration projects.

HDL Element Entry Error JBO-27014: Attribute RelationshipId Required

Resolving JBO-27014: Attribute RelationshipId in ElementEntryDEO Required Error in HDL

Description

Learn how to fix the HDL error 'JBO-27014: Attribute RelationshipId in ElementEntryDEO is required' in Oracle Fusion HCM. Step-by-step solution includes work relationship cancellation, Source Key updates, and historical Element Entry reload.

Introduction

During Element Entry record loads using HCM Data Loader (HDL) in Oracle Fusion HCM (version 11.13.22.10.0), you may encounter the following error:

An error occurred. To review details of the error run the HCM Data Loader Error Analysis Report diagnostic test.
Message details: JBO-27014: Attribute RelationshipId in ElementEntryDEO is required

This error occurs because existing Element Entry records reference Source Keys associated with Payroll Relationships that start before Work Relationship and Assignment records, causing conflicts in date-effective loads.

This blog provides a step-by-step solution, SQL queries for verification, and best practices for handling historical Element Entry records.

Cause of the Error

Existing Element Entry records on Fusion HCM use the same Source Keys as the new HDL file.
Payroll Relationship start dates are earlier than the Work Relationship and Assignment records.
The Attribute RelationshipId is mandatory in ElementEntryDEO to link Element Entries with valid employment records.

Conflicts arise when the existing date-effective records overlap or reference the same keys.

Steps to Reproduce the Error

Attempt to load new Element Entry records via HDL.
Observe the JBO-27014 error.

Step-by-Step Solution

1. Extract Existing Employment Details

If no HDL integration exists with a third-party system (e.g., PeopleSoft):

Navigate to Run Diagnostics Tests via the login icon.
Add the role Application Diagnostics Administrator if the link is unavailable.
Run the Worker Data Extract diagnostic test:
- Input parameters: Person Number, Exclude Highly Restricted Columns = false
- Execute and download the WorkerDataExtract.zip file

If an HDL integration exists, update the Hire or Start Date in the third-party system to match the Payroll Relationship's Start Date.

2. Cancel the Work Relationship

Option A – Source Keys

SET PURGE_FUTURE_CHANGES_N
METADATA|WorkRelationship|DateStart|LegalEmployerName|CancelWorkRelationshipFlag|SourceSystemOwner|SourceSystemId|PersonId(SourceSystemId)
MERGE|WorkRelationship|<DateStart>|<LegalEmployerName>|Y|<SourceSystemId>|<SourceSystemOwner>|<PersonId(SourceSystemId)>

Option B – User Keys

SET PURGE_FUTURE_CHANGES_N
METADATA|WorkRelationship|DateStart|PersonNumber|LegalEmployerName|PeriodType|CancelWorkRelationshipFlag
MERGE|WorkRelationship|<DateStart>|<PersonNumber>|<LegalEmployerName>|<PeriodType>|Y

3. Reload or Recreate Work Relationship, Work Terms, and Assignments

If HDL integration exists, submit historical Worker, WorkTerms, Assignment and child Assignment objects in HDL.
If no integration, use Worker Data Extract or manual UI updates.
Use User Keys for object references; surrogate keys may be used for attributes (Business Unit ID, Organization ID, Job ID).

4. Reload the Original Element Entry HDL File

Update Source Keys for existing Element Entry records to avoid conflicts.
SQL queries for parent and child records:
- Parent Element Entry

select hikm.GUID EE_GUID, hikm.SOURCE_SYSTEM_ID EE_SSID, hikm.SOURCE_SYSTEM_OWNER EE_SSO,

peef.ELEMENT_ENTRY_ID EE_ID, TO_CHAR(peef.EFFECTIVE_START_DATE,'YYYY-MM-DD') EE_ESD,

TO_CHAR(peef.EFFECTIVE_END_DATE,'YYYY-MM-DD') EE_EED, peef.ENTRY_TYPE ENTRY_TYPE
from fusion.HRC_INTEGRATION_KEY_MAP hikm, fusion.PAY_ELEMENT_ENTRIES_F peef
where hikm.OBJECT_NAME = 'ElementEntry'

Child Element Entry Value

select hikm.GUID EEV_GUID, hikm.SOURCE_SYSTEM_ID EEV_SSID, hikm.SOURCE_SYSTEM_OWNER EEV_SSO,

peevf.ELEMENT_ENTRY_VALUE_ID EE_VAL_ID, peevf.ELEMENT_ENTRY_ID EE_ID,

 TO_CHAR(peevf.EFFECTIVE_START_DATE,'YYYY-MM-DD') EE_ESD,

 TO_CHAR(peevf.EFFECTIVE_END_DATE,'YYYY-MM-DD') EE_EED
from fusion.HRC_INTEGRATION_KEY_MAP hikm,

fusion.PAY_ELEMENT_ENTRY_VALUES_F peevf
where hikm.OBJECT_NAME = 'ElementEntryValue'

Use these queries to generate a SourceKey.dat HDL file:

METADATA|SourceKey|FusionGUID|NewSourceSystemOwner|NewSourceSystemId
MERGE|SourceKey|<FusionGUID1>|<SourceSystemOwner>|<SourceSystemId1DONOTUSE>
...

Reload original Element Entry HDL file, referencing updated Source Keys.
Include historical date-effective records to maintain continuity.

Verification Queries

Work Relationship

select papf.PERSON_NUMBER PER_NUM, TO_CHAR(ppos.DATE_START,'YYYY-MM-DD') DATE_START,

ppos.PERIOD_TYPE POS_TYPE, houftl.NAME LE_NAME
from fusion.PER_ALL_PEOPLE_F papf, fusion.PER_PERIODS_OF_SERVICE ppos,

fusion.HR_ORGANIZATION_UNITS_F_TL houftl
where papf.PERSON_NUMBER = '<PersonNumber>'

Payroll Relationship

select papf.PERSON_NUMBER PER_NUM, TO_CHAR(pprdn.START_DATE,'YYYY-MM-DD') START_DATE,

pprdn.PAYROLL_RELATIONSHIP_NUMBER PR_NUMBER, prttl.RELATIONSHIP_TYPE_NAME REL_NAME
from fusion.PAY_PAY_RELATIONSHIPS_DN pprdn, fusion.PAY_RELATIONSHIP_TYPES_TL prttl
where pprdn.PERSON_ID = papf.PERSON_ID

Ensure Work Relationship Period Type matches Payroll Relationship Type Name.

Best Practices

Maintain consistent Source Keys for Element Entry records.
Align Hire/Start Dates between Payroll Relationship and Work Relationship.
Use User Keys wherever possible; surrogate keys only for attributes.
Run diagnostic Worker Data Extracts before HDL reloads.
Test in lower environments before production loads.

HDL Benefits Enrollment Error: Payroll Relationship or Assignment Isn't Eligible

Resolving Payroll Relationship Eligibility Error in HDL Benefits Enrollment

Description

Learn how to fix the HDL error 'The payroll relationship or assignment isn't eligible for the element' in Oracle Fusion HCM Benefits Enrollment. Understand causes, steps to create new elements, and best practices for successful enrollments.

Introduction

When loading participant files or performing enrollments through HDL in Oracle Fusion HCM, you may encounter the following error:

Error occurred processing election information.
ORA-20001: The payroll relationship or assignment isn't eligible for the element XYZ on the date YYYY-MM-DD.

This error occurs because the employment record for the employee does not meet the eligibility criteria defined for the benefits element. It often happens when elements are incorrectly configured at the Assignment level instead of Payroll relationship level.

This blog provides a detailed explanation of the cause and a step-by-step solution to resolve this error.

Cause of the Error

The root cause is related to the element setup for benefits:

Elements have been configured with Employment Level = Assignment Level.
Benefits elements must always use Employment Level = Payroll Relationship.
Once an element is created, the Employment Level cannot be changed.

Incorrect configuration prevents the employee's payroll relationship from being eligible for the element, causing the HDL enrollment error.

Steps to Reproduce the Issue

Navigate to Benefits Administration > Enrollment.
Search for and select an employee.
Change the Effective As-of Date.
Click the Enroll button and make a selection.
The system throws the eligibility error.

This reproduction confirms the setup problem is at the element configuration level.

Step-by-Step Solution

1. Create New Elements for Benefits

Create new benefit elements with Employment Level = Payroll Relationship.
Use consistent naming conventions to differentiate from old elements.

2. Verify Employment Level

Ensure that Employment Level for new elements is correctly set to Payroll Relationship.
This is critical because the value cannot be changed once the element is created.

3. Replace Incorrect Elements

Identify all activity rates or dependent records using the old elements.
Replace them with the newly created elements to maintain correct configuration.

4. Retest the Enrollment

Perform the enrollment again in the system.
Confirm that the ORA-20001 error no longer appears.

5. Migrate to Other Environments

Once validated in the development environment, migrate new elements and updates to QA and production environments using HDL or migration tools.

Best Practices

Always set Employment Level = Payroll Relationship when creating new benefits elements.
Validate eligibility rules before using elements in HDL loads.
Maintain a list of incorrectly configured elements for cleanup in legacy systems.
Use incremental testing for HDL participant file loads to catch errors early.
Document element creation steps for repeatable migration.

Resolving payroll eligibility error in HDL Flow

"The Party Identified by the Specified Party ID Does Not Exist" Error in HDL

Resolving "The Party Identified by the Specified Party ID Does Not Exist" Error in HDL

Description

Learn why the "The party identified by the specified party ID does not exist" error occurs in Oracle Fusion HCM HDL when loading Personal Payment Methods, and how to fix it using Party and Location maintenance and Person synchronization.

Introduction

While loading Personal Payment Methods in Oracle Fusion HCM using HCM Data Loader (HDL), you may encounter the following error:

"The party identified by the specified party ID does not exist."

This error usually occurs for workers whose Party record has not been created. Without a valid Party ID, HDL cannot link the Personal Payment Method to the worker.

This blog explains the cause of this error and provides a step-by-step solution to resolve it efficiently.

Reason for the Error

The primary reason for this error is:

Party ID not created for the worker: In Fusion HCM, every worker requires a Party record to store personal information. If the Party record is missing, HDL cannot load dependent objects like Personal Payment Methods.

Other potential causes include:

Missing or incomplete Location current records
Delayed or incomplete Person synchronization processes

Note: Party IDs are crucial for linking workers to all personal data in Fusion HCM.

Step-by-Step Solution

To resolve this issue, follow these two scheduled processes in Fusion HCM:

1. Maintain Party and Location Current Record Information

This process ensures that all workers have valid Party and Location current records.

Steps:

Navigate to Scheduled Processes in Fusion HCM.
Search for Maintain Party and Location Current Record Information.
Submit the process for affected workers.
Verify the process completes successfully.

Tip: Run this process for all workers missing Party records to avoid partial issues.

2. Synchronize Person Records

After maintaining Party and Location records, synchronize Person records to update the Party IDs for workers.

Steps:

Navigate to Scheduled Processes.
Search for Synchronize Person Records.
Submit the process for all affected workers.
Verify successful completion and check that Party IDs are now created.

Post-Process Verification

After completing both scheduled processes:

Retry loading the Personal Payment Method HDL file.
Check ESS request logs to confirm the error is resolved.
Validate that Personal Payment Methods are correctly assigned in Person Management → Payments.

The error should no longer appear if Party IDs exist for all workers.

Best Practices

Always pre-check Party and Location records before loading dependent objects in HDL.
Schedule Person synchronization regularly in mass load scenarios.
Validate HDL files with a small test load before full-scale processing.
Maintain a list of workers who have missing Party IDs to proactively fix issues.

Conclusion

The "The party identified by the specified party ID does not exist" error occurs because workers lack Party records. Running the scheduled processes Maintain Party and Location Current Record Information and Synchronize Person Records resolves this issue and ensures successful Personal Payment Method loads in HDL.

By following these steps and best practices, Fusion HCM consultants can avoid this common HDL error and maintain clean, accurate payroll and payment data.

HCM Conversion Strategy in Oracle Fusion HCM – Best Practices for Successful Data Migration

Conversion Strategy for HCM Conversions in Oracle Fusion HCM

Description

Learn the best practices and strategies for successful HCM conversions in Oracle Fusion HCM. This blog covers HDL, data cleansing, mapping, testing, and migration techniques for seamless employee data transition.

Introduction

Data conversion is a critical part of Oracle Fusion HCM implementation. Accurate and efficient conversion ensures that historical and current employee data is migrated seamlessly from legacy systems to Fusion HCM. Poorly executed conversions lead to errors, failed HDL loads, and downstream payroll or reporting issues.

This blog provides a comprehensive HCM conversion strategy, including HDL usage, data cleansing, mapping, testing, and best practices.

Step 1: Data Assessment and Inventory

Before starting a conversion, perform a detailed data assessment:

Identify all legacy HR objects (Employee, Assignment, Compensation, Payroll, etc.)
Determine data quality and completeness
Check for duplicate records or missing information
Document object relationships and dependencies

Tip: Maintain a data dictionary for each object to streamline mapping.

Step 2: Data Cleansing

Clean your legacy data to avoid errors during HDL loads:

Remove duplicate employees and assignments
Correct invalid dates (hire, termination, assignment start/end)
Standardize codes for Job, Position, Department, Legal Employer
Validate mandatory fields required by Fusion HCM

Data quality at this stage significantly reduces load errors.

Step 3: Data Mapping

Map legacy system fields to Fusion HCM objects:

Worker → Worker.dat
WorkRelationship → WorkRelationship.dat
WorkTerms → WorkTerms.dat
Assignment → Assignment.dat
Payroll & Compensation → respective HDL objects

Mapping Tips:

Maintain source system codes for reference
Handle value conversions (e.g., department codes, job codes)
Document default values for missing fields

Step 4: HDL Load Design

Design HDL files carefully for conversions:

Use incremental or batch loads based on data volume
Split files object-wise (Worker, WorkRelationship, WorkTerms, Assignment)
Maintain consistent SourceSystemOwner
Use MERGE for existing employees, CREATE for new ones

Tip: Maintain clear file naming (e.g., Worker_0001_to_5000.dat).

Step 5: Load Sequencing

Proper sequencing avoids dependency errors:

Worker.dat → create or merge employees
WorkRelationship.dat → create or end-date relationships
WorkTerms.dat → create or update terms
Assignment.dat → create or update assignments
Payroll, Compensation, and Benefits → load after core HR data

Step 6: Validation and Testing

Test all HDL loads in lower environments:

Validate successful load of all employees and assignments
Check for duplicate records and missing dependencies
Verify effective dates and assignment categories
Test edge cases like rehires, global transfers, multiple assignments

Tip: Use sample audit reports to cross-check conversion accuracy.

Step 7: Go-Live Strategy

Schedule staged loads during off-peak hours
Maintain backup of legacy data before final load
Monitor ESS requests and capture logs for failures
Communicate with HR and Payroll teams for verification

Post go-live, perform parallel verification before decommissioning legacy systems.

Common Challenges and Solutions

Challenge	Solution
Data inconsistency	Pre-cleanse and validate legacy data
Missing dependencies	Correct sequencing of HDL objects
Large volume load failures	Split files, incremental loads, schedule ESS jobs off-peak
Incorrect mappings	Maintain mapping documents and value conversion tables

Best Practices for HCM Conversions

Document all steps and mappings for repeatability
Use incremental HDL loads for testing and full loads for go-live
Pre-validate and cleanse data before conversion
Maintain audit logs and ESS request IDs
Include functional and technical consultants in validation
Run mock conversions to simulate real data loads

HCM Conversion strategy workflow

Conclusion

A well-planned HCM conversion strategy is key to a successful Fusion HCM implementation. Focus on data quality, mapping accuracy, HDL sequencing, and thorough validation to minimize errors and ensure seamless migration.

Mastering these steps not only improves conversion success but also builds trust with clients and HR teams.

Local Transfer vs Global Transfer in Oracle Fusion HCM HDL – Technical Differences, Use Cases, and Best Practices

Local Transfer vs Global Transfer (HDL)

Description

Understand the difference between Local and Global Transfers in Oracle Fusion HCM HDL. Learn object-level changes, effective dating rules, HDL sequencing, and common errors with a clear technical comparison.

Introduction

Employee transfers are common in enterprise organizations, but in Oracle Fusion HCM, not all transfers are the same. From an HDL (HCM Data Loader) perspective, Local Transfers and Global Transfers behave very differently and impact different Core HR objects.

Misunderstanding this difference often leads to:

Assignment failures
WorkRelationship errors
Incorrect legal employer data

This blog provides a complete technical comparison of Local vs Global Transfers using HDL, including object structure, effective dating rules, HDL sequencing, and real project guidance.

High-Level Difference

Local Vs Global Transfer Comparison Flow

Local Transfer – Technical Overview

What Is a Local Transfer?

A Local Transfer occurs when an employee moves within the same Legal Employer, such as:

Department change
Job or position change
Location or manager change

The WorkRelationship remains unchanged.

Local Transfer – Data Model Impact

Worker
 └─ WorkRelationship (Same LE)
     └─ WorkTerms (Same)
         └─ Assignment (Updated)

Local Transfer – HDL Approach

Use MERGE on Assignment
No need to create new WorkRelationship or WorkTerms
Effective date reflects the transfer date

Objects Used

Worker (optional)
Assignment (MERGE)

Common Local Transfer Errors

Incorrect effective start date
Using CREATE instead of MERGE
Overwriting historical assignment data

Global Transfer – Technical Overview

What Is a Global Transfer?

A Global Transfer occurs when an employee moves from one Legal Employer to another, often across countries.

This requires creation of a new WorkRelationship.

Global Transfer – Data Model Impact

Worker
 ├─ WorkRelationship (Old LE) → End-dated
 └─ WorkRelationship (New LE)
     └─ WorkTerms
         └─ Assignment

Global Transfer – HDL Approach

End-date old WorkRelationship
Create new WorkRelationship
Create new WorkTerms
Create new Assignment

Objects Used

Worker (MERGE – optional)
WorkRelationship (MERGE + CREATE)
WorkTerms (CREATE)
Assignment (CREATE)

Effective Dating Comparison

Rule	Local Transfer	Global Transfer
WorkRelationship	No change	End-date old, create new
WorkTerms	No change	Start with new WR
Assignment Start Date	Transfer date	Same as new WR
Historical Data	Preserved	Preserved

HDL Sequencing Comparison

Local Transfer

Assignment.dat (MERGE)

Global Transfer

WorkRelationship.dat (End-date old)
WorkRelationship.dat (Create new)
WorkTerms.dat (Create)
Assignment.dat (Create)

How to Decide: Local vs Global Transfer

Ask these questions:

Is the Legal Employer changing?
Is the payroll or country changing?
Is a new WorkRelationship required?

If the answer to #1 is YES, it is a Global Transfer.

Common Mistakes to Avoid

❌ Treating Global Transfer as Local Transfer
❌ Reusing Assignment across Legal Employers
❌ Missing WorkTerms during Global Transfer
❌ Incorrect effective dating across objects

Best Practices

Always confirm Legal Employer change first
Use incremental HDL loads
Keep separate files for each object
Test transfer scenarios in lower environments
Validate results in Person Management UI

Conclusion

Understanding the technical difference between Local and Global Transfers in HDL is essential for accurate data management in Oracle Fusion HCM. While Local Transfers are assignment-level changes, Global Transfers require precise handling of WorkRelationship, WorkTerms, and Assignment objects.

Mastering this distinction is a key skill for senior Fusion HCM Technical Consultants.

Monday, 12 January 2026

HDL Template for Dependent Enrollment in Oracle Fusion HCM (DependentEnrollment.dat)

Introduction

When to Use DependentEnrollment.dat

Prerequisites

Employee Prerequisites

Dependent Prerequisites

Benefits Configuration

Date & Security

File Name

HDL File Structure Overview

Section: DependentEnrollment

Purpose

Metadata Definition

Sample Data

Complete Sample DependentEnrollment.dat File

Sample Data

HDL Load Steps

Validation After Load

Common Errors & Troubleshooting

Best Practices

Conclusion

Wednesday, 7 January 2026

Error While Loading PersonalPaymentMethod Using HCM Data Loader

Introduction

Cause Analysis

Cause 1: Missing BankAccountType

Cause 2: Invalid Bank Account Attribute Combination

Solution 1: Provide BankAccountType When Required

Best Practice

Solution 2: Validate Bank Account Details in Fusion

Query to Validate Bank Account Data

Final Root Causes Summary

Cause 1

Cause 2

Conclusion

Tuesday, 6 January 2026

Resolving JBO-27014: Attribute RelationshipId in ElementEntryDEO Required Error in HDL

Description

Introduction

Cause of the Error

Steps to Reproduce the Error

Step-by-Step Solution

1. Extract Existing Employment Details

2. Cancel the Work Relationship

3. Reload or Recreate Work Relationship, Work Terms, and Assignments

4. Reload the Original Element Entry HDL File

Verification Queries

Best Practices

Resolving Payroll Relationship Eligibility Error in HDL Benefits Enrollment

Description

Introduction

Cause of the Error

Steps to Reproduce the Issue

Step-by-Step Solution

1. Create New Elements for Benefits

2. Verify Employment Level

3. Replace Incorrect Elements

4. Retest the Enrollment

5. Migrate to Other Environments

Best Practices

Resolving payroll eligibility error in HDL Flow

Resolving payroll eligibility error in HDL Flow

Resolving "The Party Identified by the Specified Party ID Does Not Exist" Error in HDL

Description

Introduction

Reason for the Error

Step-by-Step Solution

1. Maintain Party and Location Current Record Information

2. Synchronize Person Records

Post-Process Verification

Best Practices

Conclusion

Conversion Strategy for HCM Conversions in Oracle Fusion HCM

Description

Introduction

Step 1: Data Assessment and Inventory

Step 2: Data Cleansing

Step 3: Data Mapping

Mapping Tips: