How to Import/Load Organization/Third Parties Data in Oracle Fusion Using Import Management (CSV Template + Steps)

 

How to Import Organization Data in Oracle Fusion Using Import Management

Oracle Fusion applications provide Import Management to create or update business objects like Organization (Party).
This method is widely used in CX Sales, Fusion Service, and Trading Community Architecture (TCA).

In this blog, you will learn:

✅ How Organization import works

✅Load Third Parties in Oracle Fusion.

✅ Required attributes and validations
✅ How to prepare the CSV template
✅ How to create and submit import activity
✅ How to review import results
✅ Best practices to avoid duplicate data

---

🔥 What is Organization Import in Oracle Fusion?

Organization records represent party type = Organization in TCA.

Using Import Management you can:

• Create new organizations

• Update existing organizations

• Load data from external systems using SourceSystem mapping

---

✅ High-Level Steps (Process Flow)

1. Map source attributes → Oracle target attributes

2. Create CSV file using template

3. Create Import Activity

4. Validate and submit

5. Review import results

---

Step 1: Before You Start (Prerequisites)

Before importing Organization records, verify:

✅ 1. Parent records exist

If you’re importing child objects (like addresses), ensure parent Organization exists first.

✅ 2. Source System is configured

Navigate to:
Setup and Maintenance → Manage Trading Community Source System

You must know:

• SourceSystem

• SourceSystemReferenceValue

✅ 3. Identify unique record key

To avoid duplicates, decide how you will identify records.

---

Step 2: Choose Unique Identifier (Most Important)

All Organization records must be unique in Oracle Fusion.

You can identify organizations using either:

---

Option A: PartyNumber (Public Unique Identifier)

Use this when:

• Organization already exists

• You want to update the record

PartyNumber is visible in UI.

---

Option B: SourceSystem + SourceSystemReferenceValue

Use this when:

• You are creating new organizations

• You are loading from external system

• You want consistent integration keys

---

Step 3: Required Attributes for Organization Import

To successfully create an organization record, your CSV must include at least:

✅ Mandatory for Creating Organization

• OrganizationName

• PartyUsageCode

• SourceSystem (conditional)

• SourceSystemReferenceValue (conditional)

---

⭐ Key Required Fields Explained

1) OrganizationName (Required)

The name of the Organization party.

Example:

ABC Technologies Pvt Ltd

---

2) PartyUsageCode (Required)

This defines how the party is used.

Examples (depends on your setup):

• CUSTOMER

• PROSPECT

• SUPPLIER (if enabled)

• PARTNER

📌 Must exist as active value in:
HZ_PARTY_USAGES_B

---

3) SourceSystem & SourceSystemReferenceValue (Conditional)

Required if you are not using PartyNumber.

---

Step 4: Download Organization CSV Template

To download the template:

Navigate to:
Navigator → Tools → Import Management → Import Objects

Steps:

1. Search for Organization

2. Click Download

3. Edit the file in Excel or Notepad++

---

⚠️ Important Excel Tip

Sometimes Excel changes formatting (especially for large numbers).

Best practice:
✅ Use Notepad++ or Google Sheets for final save.

---

Step 5: Sample Organization CSV (Create)

Example format (basic):

OrganizationName,PartyUsageCode,SourceSystem,SourceSystemReferenceValue,ThirdPartyFlag
ABC Technologies Pvt Ltd,CUSTOMER,LEGACY,ORG_1001,Y

---

Step 6: Create Import Activity

Navigate:
Navigator → Tools → Import Management → Import Queue

Steps:

1. Click Create Import Activity

2. Enter Import Options:

   • Name: Organization_Import_01

   • Object: Organization

3. Upload CSV file

4. Click Next

---

Step 7: Map Fields and Validate

In the Map Fields screen:

• Oracle auto-maps most fields

• Review mappings carefully

• Fix unmapped columns

Then click:

✅ Validate Data

This checks:

• missing required fields

• wrong formats

• invalid values

---

Step 8: Submit Import Activity

On Review & Submit page:

Click:

✅ Submit

---

Step 9: Review Import Results

Go to:

Navigator → Tools → Import Management → Import Queue → All Imports

Search your import name.

Status meanings:

• Completed = Success

• Completed with errors = Partial success

• Unsuccessful = Failed

Click the import to open:
Import Status page

---

⭐ Best Practices (Must Follow)

✅ Avoid Duplicate Organizations

Use one unique identifier consistently:

• PartyNumber OR

• SourceSystem + SourceSystemReferenceValue

Do not mix randomly.

---

✅ Load in Correct Order

1. Organization

2. Organization Address

3. Organization Contacts

4. Child objects

---

✅ Use consistent PartyUsageCode

If PartyUsageCode is wrong/inactive → import fails.

---

🔥 Common Errors & Fixes

❌ Error: PartyUsageCode invalid

✅ Fix:

• Validate the code exists in HZ_PARTY_USAGES_B

• Ensure it is active

---

❌ Error: Duplicate record found

✅ Fix:

• Use correct PartyNumber

• Or use correct SourceSystemReferenceValue

---

❌ Error: Source system not found

✅ Fix:

• Configure source system in Setup and Maintenance

---

🔗 Internal Links 

• Oracle HCM HDL Templates (Worker, Assignment, Supervisor)

• Changes Only HCM Extracts Complete Guide

• Oracle Fusion HCM Technical Interview Questions

• Sample HDL Template for Benefit Enrollments

• Oracle eText Teamplate BIP Report.

---

⭐ FAQs

Q1. What is Import Management in Oracle Fusion?

Import Management is a tool to create or update Oracle Fusion business objects using CSV files.

Q2. Which object is used to import Organization data?

You must select Organization object in Import Management.

Q3. What is the unique identifier for Organization import?

You can use:

• PartyNumber
  OR

• SourceSystem + SourceSystemReferenceValue

Q4. Is OrganizationName mandatory for import?

Yes, OrganizationName is mandatory when creating a new organization.

Q5. Where can I check import status in Oracle Fusion?

Go to:
Navigator → Tools → Import Management → Import Queue → All Imports

🔐 How to Lock and Unlock User Accounts Using HDL in Oracle Fusion HCM (Step-by-Step Guide)

 Step-by-Step Instructions for Administrators

Locking and unlocking user accounts is a common requirement for Oracle Fusion HCM administrators. Whether an employee has left the organization, access must be temporarily restricted, or security compliance requires action, Oracle HCM provides a simple way to lock/unlock accounts using HCM Data Loader (HDL).

In this blog, you’ll learn how to lock and unlock user accounts using HDL, along with the required HDL file format, steps to load it, and the process required to apply changes.

---

✅ Prerequisites

Before you begin, make sure you have:

• Access to perform HDL operations

• Valid Person Numbers for users you want to lock/unlock

• Access to run required ESS process (Send Pending LDAP Requests)

• Admin privileges to verify the user status

---

🔒 Locking a User Account Using HDL

To lock a user account in Oracle Fusion HCM, you need to set the Suspended flag = Y in the User HDL file.

---

Step 1: Prepare the HDL File (User.dat)

Use the following format:

METADATA|User|PersonNumber|Suspended
MERGE|User|<Enter Person Number>|Y

Example:

METADATA|User|PersonNumber|Suspended
MERGE|User|E12345|Y

---

Step 2: Save and Compress the File

1. Save the file as: User.dat

2. Compress it into a ZIP file:

   • Example ZIP name: LockUser.zip

---

Step 3: Upload the HDL File

Navigate to:

My Client Groups → Data Exchange → HCM Data Loader → Import and Load

Then:

1. Click Import File

2. Upload the ZIP file

3. Submit the load

---

Step 4: Run Required Process (Very Important)

After HDL loads successfully, you must run:

✅ Send Pending LDAP Requests

This process applies the account changes to the LDAP directory.

---

Step 5: Verify User is Locked

Go to:

Setup and Maintenance → Create Implementation User

Search using the person number / username and confirm the account is locked.

---

🔓 Unlocking a User Account Using HDL

To unlock a user account, set the Suspended flag = N.

---

Step 1: Prepare the HDL File (User.dat)

METADATA|User|PersonNumber|Suspended
MERGE|User|<Enter Person Number>|N

Example:

METADATA|User|PersonNumber|Suspended
MERGE|User|E12345|N

---

Step 2: Save and Compress the File

1. Save as User.dat

2. Zip it:

   • Example ZIP name: UnlockUser.zip

---

Step 3: Upload the HDL File

Navigate to:

My Client Groups → Data Exchange → HCM Data Loader → Import and Load

1. Click Import File

2. Upload ZIP file

3. Submit

---

Step 4: Run Required Process (Very Important)

After HDL loads successfully, you must run:

✅ Send Pending LDAP Requests

This process applies the account changes to the LDAP directory.

---

Step 5: Verify User is Unlocked

Go to:

Setup and Maintenance → Create Implementation User

Confirm the user is now active/unlocked.

---

⭐ Best Practices and Recommendations

• Always double-check the Person Number before locking/unlocking

• Keep an audit log of user account changes

• Notify users when their account is unlocked (unless security policy says otherwise)

• Regularly review locked accounts to avoid unnecessary access restrictions

• Run Send Pending LDAP Requests after every HDL user suspension change

---

⚠️ Common Issues and Troubleshooting

Issue 1: HDL loads successfully but user is still active

✅ Solution:
Run Send Pending LDAP Requests process.

---

Issue 2: Person number not found

✅ Solution:
Confirm the person exists and has a user account created.

---

Issue 3: Changes not reflecting immediately

✅ Solution:
LDAP sync may take time. Wait 5–10 minutes after process completion.

---

📌 FAQ

1. Can we lock a user account in Oracle Fusion HCM using HDL?

Yes. You can lock a user account using HDL by setting the field Suspended = Y in User.dat.

---

2. What HDL object is used to lock/unlock users?

The HDL object used is:

User

---

3. What does the Suspended flag mean in HDL?

• Y = user is locked/suspended

• N = user is active/unlocked

---

4. Do we need to run any process after loading HDL?

Yes. You must run:

✅ Send Pending LDAP Requests

---

5. Where can we verify if a user is locked/unlocked?

You can verify in:

Setup and Maintenance → Create Implementation User

---

6. Can we lock multiple users in one HDL file?

Yes. Add multiple MERGE lines:

METADATA|User|PersonNumber|Suspended
MERGE|User|E1001|Y
MERGE|User|E1002|Y
MERGE|User|E1003|Y

---

7. Is locking a user same as terminating an employee?

No. Locking only disables login access. Termination affects employment and HR records.

---

✅ Conclusion

Locking and unlocking user accounts using HDL is one of the fastest and cleanest methods available for Oracle Fusion HCM administrators. By updating the Suspended flag and running Send Pending LDAP Requests, you can manage user access securely and efficiently.

 

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:

1. 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

1. Navigate to Data Exchange → HCM Data Loader

2. Upload DependentEnrollment.dat

3. Submit the process

4. Monitor HDL stages until status shows Succeeded

---

Validation After Load

After the load completes:

1. Navigate to Benefit Administration

2. Search for the employee

3. 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

1. Attempt to load new Element Entry records via HDL.

2. 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

1. Navigate to Benefits Administration > Enrollment.

2. Search for and select an employee.

3. Change the Effective As-of Date.

4. Click the Enroll button and make a selection.

5. 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

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:

1. Navigate to Scheduled Processes in Fusion HCM.

2. Search for Maintain Party and Location Current Record Information.

3. Submit the process for affected workers.

4. 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:

1. Navigate to Scheduled Processes.

2. Search for Synchronize Person Records.

3. Submit the process for all affected workers.

4. 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.

---