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:

1. Worker.dat → create or merge employees

2. WorkRelationship.dat → create or end-date relationships

3. WorkTerms.dat → create or update terms

4. Assignment.dat → create or update assignments

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

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

1. Assignment.dat (MERGE)

Global Transfer

1. WorkRelationship.dat (End-date old)

2. WorkRelationship.dat (Create new)

3. WorkTerms.dat (Create)

4. Assignment.dat (Create)

---

How to Decide: Local vs Global Transfer

Ask these questions:

1. Is the Legal Employer changing?

2. Is the payroll or country changing?

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

---

HDL Template to Disability of Worker

 HDL Template to Person Disability

Please find the below sample template :

File Name- PersonDisability.dat

METADATA|PersonDisability|SourceSystemOwner|SourceSystemId|EffectiveStartDate|EffectiveEndDate|LegislationCode|PersonId|PersonNumber|SelfDisclosedType|Category|QuotaFTE|Status

MERGE|PersonDisability|XXTEST|XXTEST_DIS21|2021/07/07|4712/12/31|US|100000609337422|XXTEST21|ORA_PER_YES_US|NA|1|A

 

HDL Template for Worker Extra Information of Worker (EIT)

HDL Template for Worker Extra Information of Worker (EIT).

For this use Worker.dat

Please find the below sample template :

Sample file for Worker EIT.

METADATA|WorkerExtraInfo|PersonNumber|EffectiveStartDate|EffectiveEndDate|InformationType|PeiInformationCategory|CategoryCode|FLEX:PER_PERSON_EIT_EFF|EFF_CATEGORY_CODE|_CASTE(PER_PERSON_EIT_EFF=HRX_IN_MISCELLANEOUS)|_COMMUNITY(PER_PERSON_EIT_EFF=HRX_IN_MISCELLANEOUS)|_EX_SERVICE_PERSON(PER_PERSON_EIT_EFF=HRX_IN_MISCELLANEOUS)|_HEIGHT(PER_PERSON_EIT_EFF=HRX_IN_MISCELLANEOUS)|_PAN_APPLIED(PER_PERSON_EIT_EFF=HRX_IN_MISCELLANEOUS)|_PAN_REFERENCE_NUMBER(PER_PERSON_EIT_EFF=HRX_IN_MISCELLANEOUS)|_RESIDENTIAL_STATUS(PER_PERSON_EIT_EFF=HRX_IN_MISCELLANEOUS)|_RESIDENTIAL_STATUS_Display(PER_PERSON_EIT_EFF=HRX_IN_MISCELLANEOUS)|_WEIGHT(PER_PERSON_EIT_EFF=HRX_IN_MISCELLANEOUS)

MERGE|WorkerExtraInfo|PS5|2010/11/02||HRX_IN_MISCELLANEOUS|HRX_IN_MISCELLANEOUS|PER_EIT|HRX_IN_MISCELLANEOUS|PER_EIT|Test123|Backward|||||||

HDL Template for Global Temporary Transfer of Worker

For this use Worker.dat

Please find the below sample template :

METADATA|WorkRelationship|PersonNumber|LegalEmployerName|DateStart|ActualTerminationDate|PrimaryFlag|WorkerNumber|WorkerType|RehireRecommendationFlag|OnMilitaryServiceFlag|ActionCode|ReasonCode|DateOfDeath

MERGE|WorkRelationship|XXTEST9|US1 Legal Entity|2018/01/01||Y|XXTEST9|E|Y|N|GLB_TEMP_ASG||

MERGE|WorkRelationship|XXTEST9|UK Legal Entity|2019/01/01||N|XXTEST9|E|Y|N|GLB_TEMP_ASG||

METADATA|WorkTerms|ActionCode|PersonNumber|LegalEmployerName|DateStart|WorkerType|AssignmentNumber|EffectiveStartDate|EffectiveEndDate|EffectiveLatestChange|EffectiveSequence|AssignmentType|PersonTypeCode|AssignmentStatusTypeCode|BusinessUnitShortCode|PrimaryWorkTermsFlag|SystemPersonType|ReasonCode

MERGE|WorkTerms|GLB_TEMP_ASG|XXTEST9|US1 Legal Entity|2018/01/01|E|XXTEST_WRKTERM9|2019/01/01|4712/12/31|Y|1|ET|Employee|SUSPEND_PROCESS|US1 Business Unit|Y|EMP|

MERGE|WorkTerms|GLB_TEMP_ASG|XXTEST9|UK Legal Entity|2019/01/01|E|XXTEST_WRKTERM9-2|2019/01/01|4712/12/31|Y|1|ET|Employee|ACTIVE_PROCESS|UK Business Unit|Y|EMP|

METADATA|Assignment|ActionCode|PersonNumber|LegalEmployerName|DateStart|WorkerType|AssignmentNumber|WorkTermsNumber|EffectiveStartDate|EffectiveEndDate|EffectiveLatestChange|EffectiveSequence|AssignmentType|PersonTypeCode|AssignmentStatusTypeCode|BusinessUnitShortCode|GradeCode|JobCode|LocationCode|DepartmentName|ManagerFlag|LabourUnionMemberFlag|ReasonCode

MERGE|Assignment|GLB_TEMP_ASG|XXTEST9|US1 Legal Entity|2018/01/01|E|XXTEST_ASSIGN9|XXTEST_WRKTERM9|2019/01/01|4712/12/31|Y|1|E|Employee|SUSPEND_PROCESS|US1 Business Unit|XXTEST_GRADE1|XXTEST_CFO|XXTEST_LOC12|XXTEST Department1|Y|N|

MERGE|Assignment|GLB_TEMP_ASG|XXTEST9|UK Legal Entity|2019/01/01|E|XXTEST_ASSIGN9-2|XXTEST_WRKTERM9-2|2019/01/01|4712/12/31|Y|1|E|Employee|ACTIVE_PROCESS|UK Business Unit|XXTEST_GRADE1|ADM|XXTEST_LOC12|XXTEST Department1|Y|N|

 

 Sample Templates for eText BI Publisher Reports (Delimiter & Fixed Position)

Introduction to eText BI Publisher Reports

Oracle BI Publisher (BIP) provides eText report templates to generate text-based output files such as .txt, .dat, or interface files required for integrations with external systems.

Unlike PDF or Excel outputs, eText reports are mainly used when:

• Data must follow a specific layout

• Files are consumed by external payroll, banking, or legacy systems

• Strict formatting rules (delimiter or fixed length) are required

In this blog, we’ll cover:

• What eText BI Publisher reports are

• how to create eText report in BI Publisher

• Differences between Delimiter-Based and Fixed Position-Based eText

• BI Publisher eText report example

• how to create fixed position eText report

• common errors in BI Publisher eText report

---

Difference Between Delimiter & Fixed Position eText

Delimiter VS Fixed Position eText

You can see step by step video to develop eText BIP Report using this Link

---

🔹 Sample 1: Delimiter-Based eText Template

This template generates output with values separated by a delimiter (for example, |).

You can see step by step video to develop eText BIP Report using this Link

<TEMPLATE TYPE>	DELIMITER_BASED
<OUTPUT CHARACTER SET>	iso-8859-1
<CASE CONVERSION>	UPPER
<NEW RECORD CHARACTER>	Carriage Return

 

<LEVEL>	DATA_DS
<MAXIMUMLENGTH>	<FORMAT>	<DATA>	<COMMENTS>
<NEW RECORD>	TableHeader
20	Alpha	'Person Id'
1	Alpha	'|'
20	Alpha	'Title'
1	Alpha	'|'
20	Alpha	'First Name'
1	Alpha	'|'
20	Alpha	'Last Name'

 

<LEVEL>	G_1
<MAXIMUMLENGTH>	<FORMAT>	<DATA>	<COMMENTS>
<NEW RECORD>	CLRDAta
20	Alpha	PERSON_ID
1	Alpha	'|'
20	Alpha	TITLE
1	Alpha	'|'
20	Alpha	FIRST_NAME
1		'|'
20	Alpha	LAST_NAME
<END LEVEL>	G_1

 

<END LEVEL>

DATA_DS

 This format is useful when the target system expects delimiter-separated text files.

⭐ HDL Template for Personal Payment Method in Oracle Fusion HCM (PersonalPaymentMethod.dat + Direct Deposit Example)

 HDL Template for Personal Payment Method in Oracle Fusion HCM

PersonalPaymentMethod.dat Step-by-Step Guide (Direct Deposit Example)

Personal Payment Method is used in Oracle Fusion HCM Payroll to define how an employee receives salary payments, such as:

• Direct Deposit (Bank Transfer)

• Check

• Cash (based on country setup)

Instead of manually entering payment methods for each employee, you can load them in bulk using HCM Data Loader (HDL).

This blog explains how to load Personal Payment Method details using:

📌 PersonalPaymentMethod.dat

---

✅ Prerequisites (Mandatory)

Before loading Personal Payment Method details, ensure the following are already loaded:

1) Bank and Bank Branch

You must load:

• Bank.dat

• BankBranch.dat

2) External Bank Account

You must load:

• ExternalBankAccount.dat

⚠️ If these are missing, the PersonalPaymentMethod HDL will fail.

Links : 

1. Bank and Bank Branches data should be loaded. Click here to find the sample bank details.  

2. External bank Account should be loaded. Click here to find the sample file.  

Video Link - You can see step by step video to load Personal Payment Method Details using this Link

---

✅ HDL File Used

For Personal Payment Method, use:

📌 PersonalPaymentMethod.dat

---

✅ Business Object Used

• PersonalPaymentMethod

This object creates the payment method record for the assignment.

---

📌 Sample HDL Template (Personal Payment Method)

1) PersonalPaymentMethod HDL Example (Direct Deposit)

METADATA|PersonalPaymentMethod|SourceSystemOwner|SourceSystemId|LegislativeDataGroupName|AssignmentNumber|PersonalPaymentMethodCode|EffectiveStartDate|PaymentAmountType|Amount|Percentage|ProcessingOrder|OrganizationPaymentMethodCode|BankName|BankBranchNumber|BankCountryCode|BankAccountNumber|BankAccountType

MERGE|PersonalPaymentMethod|XXTEST|XXTEST_PAYMETHOD2|US Legislative Data Group|XXTEST_ASSIGN2|XXTEST_PAYMETHOD2|2021/04/19|P||100|1|Direct Deposit|American Bank|000000123|US|3456|Checking

⭐ HDL Template for External Bank Account Details in Oracle Fusion HCM (ExternalBankAccount.dat + Example)

⭐ HDL Template for External Bank Account Details in Oracle Fusion HCM

ExternalBankAccount.dat + ExternalBankAccountOwner.dat Step-by-Step Guide

In Oracle Fusion HCM, employee bank account details are required for payroll processing and payments.
Instead of entering bank accounts manually in the UI, you can load them in bulk using HCM Data Loader (HDL).

This blog explains how to load:

✅ External Bank Account (Account details)
✅ External Bank Account Owner (Employee mapping)

using ExternalBankAccount.dat.

For this use ExternalBankAccount.dat file.

You can see step by step video to load External Bank Account Details using this Link

---

✅ Prerequisite (Mandatory)

Before loading external bank accounts:

1) Bank and Bank Branch must already exist in Fusion

You must load:

• Bank.dat

• BankBranch.dat

📌 If Bank / Branch does not exist, the ExternalBankAccount load will fail.

---

✅ HDL File Used

For this requirement use:

📌 ExternalBankAccount.dat

---

✅ Business Objects Used

HDL requires these objects:

1) ExternalBankAccount

Stores bank account master information.

2) ExternalBankAccountOwner

Links the bank account to the employee/person.

Click here to find the sample bank details.   

---

📌 Sample HDL Template (External Bank Account)

1) ExternalBankAccount (Bank Account Master)

METADATA|ExternalBankAccount|SourceSystemOwner|SourceSystemId|AccountNumber|BankBranchName|BankName|CountryCode|CurrencyCode|AccountType
MERGE|ExternalBankAccount|XXTEST|XXTEST_BANKACCT2|123456|AMC123|American Bank|US|USD|CheckingImportant Notes

• AccountNumber must be valid format as per business rules

• BankBranchName + BankName must match the existing bank setup

• CountryCode / CurrencyCode should match bank country

---

2) ExternalBankAccountOwner (Link to Employee)

METADATA|ExternalBankAccountOwner|SourceSystemOwner|SourceSystemId|PersonNumber|AccountNumber|BankBranchNumber|BankNumber|CountryCode|CurrencyCode|BankBranchName|BankName|ExternalBankAccountId(SourceSystemId)
MERGE|ExternalBankAccountOwner|XXTEST|XXTEST_ACCTOWNER2|XXTEST2|123456|123|Test123|US|USD|AMC123|American Bank|XXTEST_BANKACCT2Key Fields Explained

• PersonNumber → Employee person number

• ExternalBankAccountId(SourceSystemId) → must match the ExternalBankAccount SourceSystemId

• BankNumber + BankBranchNumber → must match what you loaded in Bank.dat and BankBranch.dat

---

✅ Step-by-Step Process to Load External Bank Account Using HDL

Step 1: Prepare the ExternalBankAccount.dat file

Include both sections:

• ExternalBankAccount

• ExternalBankAccountOwner

---

Step 2: Save and ZIP the file

Save as:

✅ ExternalBankAccount.dat

Compress into:

✅ ExternalBankAccount.zip

---

Step 3: Upload via HDL

Go to:

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

Upload and submit the ZIP file.

---

Step 4: Verify the results

After successful load, validate from UI:

Navigation (Common)

My Client Groups → Person Management → Search Person → Payment Methods / Bank Accounts

(Exact path depends on your security role.)

---

⭐ Best Practices (Recommended)

• Always load Bank + Bank Branch first

• Use meaningful SourceSystemId format like:

  • EXTBANK_E12345_01

  • EXTBANKOWNER_E12345_01

• Ensure BankName and BankBranchName match exactly

• Keep one bank account per row (avoid duplicates)

• Maintain separate IDs for each person and account mapping

• Use consistent CountryCode + CurrencyCode

---

⚠️ Common Errors and Fixes

❌ Error: “Bank branch not found”

✅ Fix:
Load BankBranch.dat first and ensure BankBranchName matches.

---

❌ Error: “Invalid PersonNumber”

✅ Fix:
Confirm the worker exists and PersonNumber is correct.

---

❌ Error: “ExternalBankAccountId not found”

✅ Fix:
Make sure:

ExternalBankAccountId(SourceSystemId) = SourceSystemId of ExternalBankAccount row.

---

❌ Error: “Duplicate bank account”

✅ Fix:
Use unique SourceSystemId for each account record.

---

🔗 Internal Links Section

Add this section near the end of the blog:

🔗 Related HDL Templates (Must Read)

• HDL Template for Bank and Bank Branch Details (Bank.dat + BankBranch.dat)

• HDL Template for Worker.dat

• HDL Template for Assignment Changes

• HDL Template for Element Entry

• HDL Template for Dependent Enrollment

(Replace these with your actual post links.)

---

❓ FAQ 

1) Which HDL file is used to load external bank accounts in Oracle Fusion HCM?

External bank accounts are loaded using ExternalBankAccount.dat.

---

2) What is ExternalBankAccountOwner used for?

ExternalBankAccountOwner is used to link the bank account to a person (employee) using PersonNumber.

---

3) Can I load external bank account without loading bank and branch?

No. Bank and branch must exist first, otherwise HDL will fail.

---

4) What is the key linking field between account and owner?

The linking happens using:

ExternalBankAccountId(SourceSystemId)

---

5) Can I load multiple accounts for the same employee?

Yes. Create separate ExternalBankAccount and ExternalBankAccountOwner rows with unique SourceSystemId.

🏦 How to Load Bank and Bank Branch Details Using HDL in Oracle Fusion HCM (Bank.dat + BankBranch.dat)

Using Bank.dat and BankBranch.dat (Step-by-Step Guide)

In Oracle Fusion HCM, bank and bank branch records are commonly required for payroll implementations, employee payment methods, and external bank integrations.

Instead of manually creating bank and branch records in the UI, Oracle provides a faster method using HCM Data Loader (HDL).

In this guide, you’ll learn:

• How to load Bank using Bank.dat

• How to load Bank Branch using BankBranch.dat

• Sample HDL templates

• Best practices, common issues, FAQs

You can see step by step video to load Bank and Bank Branch Details using this Link

---

✅ Prerequisites

Before loading bank data using HDL, ensure:

• You have access to HCM Data Loader

• You have required roles to load banking data

• You have correct details like:

  • Bank Name

  • Country Code

  • Bank Number

  • Branch Number

  • Swift Code (optional)

---

📌 Important Note

✔ Always load Bank first, then load Bank Branch.

Because Bank Branch uses BankName as a reference.

---

🏦 Part 1: Load Bank Details Using Bank.dat

Step 1: Create Bank.dat file

Use the below HDL template:

✅ Sample HDL File for Bank

METADATA|Bank|BankName|CountryCode|BankNumber|
SourceSystemOwner|SourceSystemId

MERGE|Bank|American Bank|US|Test123|XXTEST|
XXTEST_BANKTest123

Field Explanation (Quick)

• BankName → Bank name as required in Fusion

• CountryCode → Example: US, IN, AE

• BankNumber → Unique identifier for the bank

• SourceSystemOwner → Your HDL source (example XXTEST)

• SourceSystemId → Unique record ID (must be unique)

---

Step 2: Zip and Upload

1. Save file name as: Bank.dat

2. Compress into zip file:

   • Example: Bank.zip

3. Navigate to:

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

4. Upload ZIP and load

---

🏦 Part 2: Load Bank Branch Details Using BankBranch.dat

Once Bank is created successfully, load branches.

---

Step 1: Create BankBranch.dat file

✅ Sample HDL File for Bank Branch

METADATA|BankBranch|BankName|BankBranchNumber|BankBranchName|CountryCode|
EftSwiftCode|SourceSystemOwner|SourceSystemId
MERGE|BankBranch|American Bank|123|AMC123|US||XXTEST
|XXTEST_BANKBRANCHAM123

Field Explanation (Quick)

• BankName → Must match the bank name already loaded

• BankBranchNumber → Branch identifier

• BankBranchName → Branch name

• CountryCode → Same as bank country

• EftSwiftCode → Optional (Swift/BIC code)

• SourceSystemId → Unique record ID

---

Step 2: Zip and Upload

1. Save file name as: BankBranch.dat

2. Zip it:

   • Example: BankBranch.zip

3. Upload using:

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

---

✅ Best Practices (Highly Recommended)

• Always load Bank first, then BankBranch

• Keep SourceSystemId unique for every record

• Use meaningful SourceSystemId naming like:

  • XX_BANK_US_001

  • XX_BRANCH_US_001

• Maintain a tracker Excel for:

  • Bank Name

  • Bank Number

  • Branch Number

  • Swift Code

• Validate country code is correct (ISO format)

---

⚠️ Common Issues and Fixes

Issue 1: Bank Branch fails with “Bank not found”

✅ Fix:
Bank must exist before branch load. Load Bank.dat first.

Check Bank reference in Bank Branch file is correct.

---

Issue 2: Duplicate record error

✅ Fix:
Change SourceSystemId and ensure it is unique.

---

Issue 3: CountryCode mismatch

✅ Fix:
CountryCode in BankBranch must match the Bank’s country.

---

⭐ FAQ

1. Which HDL files are used to load bank and bank branches?

You should use:

• Bank.dat for bank records

• BankBranch.dat for branch records

---

2. Do we need to load bank before bank branch?

Yes. Bank must exist first because bank branch references the bank name.

---

3. Can we load multiple banks in one HDL file?

Yes. Add multiple MERGE lines:

METADATA|Bank|BankName|CountryCode|BankNumber|SourceSystemOwner|SourceSystemId
MERGE|Bank|American Bank|US|Test123|XXTEST|XXTEST_BANK_001
MERGE|Bank|Global Bank|IN|GB001|XXTEST|XXTEST_BANK_002

---

4. Can we load multiple branches for the same bank?

Yes. Add multiple MERGE lines in BankBranch.dat.

---

5. Is Swift Code mandatory in BankBranch.dat?

No. It is optional, but recommended if required for EFT / international payments.

---

6. Where can we verify banks and branches in Fusion?

You can verify from:

Setup and Maintenance → Manage Banks
(or Bank-related setup tasks depending on your configuration)